Implement containerized solutions -II

Azure Container Instances

With Azure Container Instances (ACI), you can deploy and manage containers without worrying about the underlying infrastructure thanks to this serverless, on-demand container orchestration service. This service is perfect for testing, running microservices or lightweight applications, and rapid deployments.

You can run Docker containers directly in the cloud with Azure Container Instances, eliminating the need to manage virtual machines or orchestrators like Kubernetes. ACI offers a simple, scalable, and affordable solution for containerized workloads that require flexibility and quick provisioning.

Key benefits:

Serverless Container Hosting - no need to manage underlying infra and automatically scales resources based on container requirements
Custom resource allocation like CPU, memory
Quick Deployment and Fast startup
Cost Efficiency as you pay only for the compute and memory resources you use and ideal for burst workloads and temporary environments
Networking Options support like VNET and public IP addresses
Container access: container can be accessed over internet with an IP address and a fully qualified domain name (FQDN)
Hypervisor-level security similar to VM
Supports both Linux and Windows
Persistent Storage by mounting Azure Files shares(only on Linux)

Container Groups

A container group is a set of containers deployed together on the same host, sharing resources such as network, storage, and lifecycle. Container groups facilitate the development of multi-container applications within Azure Container Instances.

Example container group with two containers, one listening on port 80 and the other listening on port 5000.

Source: Microsoft

Use Cases

Ideal for scenarios where containers must operate in close coordination, such as an application with a front-end container alongside a logging or sidecar container or a front-end container and a back-end container.

Key Features:

Shared Networking - Containers within a group share a single public IP address and port space. They communicate with each other using localhost.
Shared Storage Volumes - Containers can share data through these mounted volumes.
Custom resource allocation, such as CPU and memory, can be set individually for each container in the group.
All containers in a group start, stop, and scale together.

Run Containerized Tasks with Restart Policies

Azure Container Instances supports the configuration of restart policies for containers, providing enhanced control over task execution and behavior upon completion or failure.

Supported Restart Policies

Always: Containers will restart automatically if they stop or fail. Useful for long-running or continuously available workloads. This is the default setting applied when no restart policy is specified at container creation.

OnFailure: Containers restart only if they fail with a non-zero exit code. Ideal for batch jobs or task processing where retry on failure is necessary.

Never: Containers do not restart under any circumstances. Suitable for one-off tasks or processes that should not retry.

//Specify the --restart-policy parameter when you call az container create.
az container create \
    --resource-group myResourceGroup \
    --name mycontainer \
    --image mycontainerimage \
    --restart-policy OnFailure

Note: When the container's application, or script, terminates, Azure Container Instances stops the container. The status of a container with a restart policy of Never or OnFailure is set to Terminated when Azure Container Instances stops it.

Set environment variables in container instances

az container create \
    --resource-group myResourceGroup \
    --name mycontainer2 \
    --image mcr.microsoft.com/azuredocs/aci-wordcount:latest 
    --restart-policy OnFailure \
    --environment-variables 'NumWords'='5' 'MinLength'='8'\

Similarly you can also set secure values to hold sensitive information like passwords or keys for your application. Environment variables with secure values aren't visible in your container's properties. Their values can be accessed only from within the container.

apiVersion: 2018-10-01
location: eastus
name: securetest
properties:
  containers:
  - name: mycontainer
    properties:
      environmentVariables:
        - name: 'NOTSECRET'
          value: 'my-exposed-value'
        - name: 'SECRET'
          secureValue: 'my-secret-value'
      image: nginx
      ports: []
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
  osType: Linux
  restartPolicy: Always
tags: null
type: Microsoft.ContainerInstance/containerGroups

Run the following command to deploy the container group with YAML:

az container create --resource-group myResourceGroup \
    --file secure-env.yaml \

By default, Azure Container Instances are stateless. If the container crashes or stops, all of its state is lost. To persist state beyond the lifetime of the container, you must mount a volume from an external store.

Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard Server Message Block (SMB) protocol. Using an Azure file share with Azure Container Instances provides file-sharing features similar to using an Azure file share with Azure virtual machines.

Limitations

Mounting Azure Files shares is supported only in Linux containers (run as root).

az container create \
--resource-group $ACI_PERS_RESOURCE_GROUP \
--name hellofiles \
--image mcr.microsoft.com/azuredocs/aci-hellofiles \
--dns-name-label aci-demo --ports 80 \
--azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
--azure-file-volume-account-key $STORAGE_KEY \
--azure-file-volume-share-name $ACI_PERS_SHARE_NAME \
--azure-file-volume-mount-path /aci/logs/