CODEWITHSUNDEEP
azuredockercontainersazure-container-instances
Olivier Thierie
Olivier Thierie

Reputation: 171

Deploying Azure container s without running them

I am new to running containers in Azure and I am puzzled with the use case below, If you feel I am wrongly using containers, feel free to give me an alternative approach.

Core problem: I am not able/ don't know how to create a container instance in the "stopped" state either via command line or ARM template deployment

Long read use case:

I created a docker image that runs a python job.

The job needs to run daily and is triggered via a data factory. The data factory will figure out the environment, set up the docker commands, update the container image and then execute the container via a batch account. The job itself does an api call and writes some data to sql. This part works fine, the container status goes to running and stops afterwards (I put auto-restart off)

In Azure DevOps, I have a pipeline that builds the image of the job and stores it in an azure repo. this works fine.

As I need a container instance as a resource in my resource group, I decided to put them in my infra ARM template. The problem: When deploying the container using DevOps / Arm template deployment, It deploys and runs the job instance and this is not great, I would like to have the container created in a "stopped" state. The reason for this is that the job otherwise writes data to our database, and that is unwanted.

I am wondering what would be the best approach / what the best guidelines are, I thought about these two scenarios, but for both, my intuition says no.

scenario 1: have an all-time running container (let it execute bin/bash) and deliver the command using "az container exec". Why I don't want to do this: I currently have an image per environment that has the exact job for that environment and I don't see the usefulness of having 3 standby containers running all the time to be triggered once a day

scenario 2: Instead of handling the container instance creation via DevOps, ignore the problem and create it using data-factory and the batch account. This implies that, when the job is triggered, It will create (and therefore run the container). Subsequently, I could delete it after usage.

Why I don't want to do this: I see a container instance as part of the infrastructure (as it is something you deploy inside a resource group, correct me if my point of view is wrong) So in that sense, managing resources via a scheduled data factory job doesn't look good and is a kind of hack to overcome the problem that you cannot deploy a container instance in a stopped state.


# set base image (host OS)
FROM python:3.7-buster
# Argument for environment selection
ARG environment
ENV environment ${environment}
# set the working directory in the container
WORKDIR /

# copy the dependencies file to the working directory
COPY requirements.txt .

# install FreeTDS and dependencies
RUN apt-get update && apt-get -y install apt-transport-https curl
RUN curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
RUN curl https://packages.microsoft.com/config/debian/10/prod.list > /etc/apt/sources.list.d/mssql-release.list
RUN exit
RUN apt-get update
RUN ACCEPT_EULA=Y apt-get -y install msodbcsql17
RUN apt-get install unixodbc-dev
RUN pip install pyodbc
RUN pip install -r requirements.txt

# copy the content of the local src directory to the working directory
COPY /src .

# command to run on container start
CMD python "./my_data_job.py" "./my_config.ini" ${environment}

Upvotes: 4

Views: 1121

Answers (1)

Charles Xu
Charles Xu

Reputation: 31462

For Azure Container Instance, the container group will always be in the running state until you stop it. But containers inside it can be in the terminated state. In fact, if your image is a one-time image, then the container will be in the terminated state when the job is finished. You can use the CLI command az container exec to run the job again as you need.

So it's impossible to create an ACI in the stopped state. Maybe you can use the AKS, create different deployments for different environments, and when you need a container to run the job, then scale up to one replica. When you don't need the container, you can scale down to zero.

Upvotes: 6

Related Questions