Azure Container Apps, a service for running apps and microservices with serverless containers now offers support for running init containers.
Azure Container App Init Containers are specialized containers that run to completion before application containers are started in a replica, and they can contain utilities or setup scripts not present in your container app image. Init containers are useful for performing initialization logic such as setting up accounts, running setup scripts, and configuring databases.
Init containers are exactly like regular containers, except:
- Init containers always run to completion.
- Each init container must complete successfully before the next one starts.
NOTE : Init containers are defined in the initContainers array of the container app template. The containers run in the order they're defined in the array and must complete successfully before the primary app container starts unlike sidecar containers (such as Dapr) which runs through the complete lifecycle of main app container.
The main containers will start concurrently without waiting for one another. Though the pod will only consider a pod ready if all of its main containers are running successfully.
Also, init containers do not support livenessProbe, readinessProbe, or startupProbe because they must run to completion before the Pod can be ready.
For more information about Init container in general please refer to the following page: Init Containers | Kubernetes
The feature to use init containers in Azure Container Apps is Generally Available as of 16th August 2023: Generally available: Init containers in Azure Container Apps | Azure updates | Microsoft Azure
Please refer to the below diagram to understand the flow of init containers on Azure Container App:
In this blog we will explore several real-world scenarios where init containers can be incredibly useful. Let's deep-dive into some easy to start samples which can help you in getting started with init containers and leverage them on Azure Container Apps.
Use Case 1: Dependency Check
Init Containers can be used to check dependencies or prerequisites before your main application starts. For example, if your application relies on external services or APIs, you can use an Init Container to perform connectivity checks. If the checks fail, the Init Container can delay the startup of the main container or retry the checks until the dependencies are available. This improves the reliability of your application.
In this example we define two init containers in the POD and one main app which has a dependency on the webapp pythontestdep.azurewebsites.net webapp. The first init container does nslookup on the external dependency while the second init container performs a netcat on the dependency to check the availability and connectivity to an external api service which is required by the main app container on Azure Container App. Once both the init containers completes the successful availability check and finishes the execution successfully, the main app container initialization starts.
Dockerfile for Init container 1 [nslookup-init]
FROM busybox:1.28
WORKDIR /
EXPOSE 8000
ENTRYPOINT ["/bin/sh", "-c", "until nslookup pythondeptest.azurewebsites.net; do echo waiting; sleep 2; done"]
Dockerfile for Init container 2 [nc-init]
FROM busybox:1.28
ENTRYPOINT ["/bin/sh", "-c", "until nc -zv pythontestdep.azurewebsites.net 80; do echo waiting; sleep 2; done"]
Output:
Use Case 2 : File Processing Using Init
Use Case 3: Database Initialization Using Init