How do I start a container in ACI Container Group which is already deployed and in terminated state. Can it be done either through some automation or from logic app? CLI commands show az container restart but not start. The logic app connectors seem to pull the image every time and start it.Is there no means to just start an existing terminated container?
Asked
Active
Viewed 1,201 times
0
-
This is a good question: it's an issue which is poorly documented in Azure's docs, as far as I can tell (after spending many hours on this), at the current date. When I re-deploy my container to the container group, the container group remains in its terminated state. I have a solution below. – David Jul 19 '22 at 21:29
2 Answers
0
Once a container is terminated there is not a start action you can do. You can deploy a new container which will pull the image you have setup and run whatever app is setup.
If the container is in a failed state you could issue a restart command but the results are basically the same. It re-initializes the container, pulls the image and deploys the app.
This is how containers work. They are not a persistent item such as a Virtual Machine. They are designed to be removed, added, and upgraded as needed.
micahmckittrick
- 1,476
- 8
- 11
-
1Thanks for clarification. Is there any recommended means to pull the image from the registry faster/ cache the image? – Iam Techie Jan 04 '19 at 22:04
-
I am not aware f a way to speed this up. The image needs to reach out to the repository, download the image than build it. It should be fairly quick though. How long are you finding this takes you on average? – micahmckittrick Jan 07 '19 at 19:34
-
@Micah_MSFT You misunderstood what sits in container registries. Container registries contain images. Images are already built. That's what makes them images, rather than pre-built artifacts like Dockerfiles. – David Jul 19 '22 at 21:50
0
This is a pain point on Azure. While container instances are not meant to be restarted after being terminated, the container groups they sit inside are meant to be flexible enough to be restarted. And they have that capability - Microsoft Azure's docs just don't really talk about it. It's left for you to figure out.
The main problem is that when you deploy an updated container instance to an existing container group in Azure, and the matching container instance in Azure is terminated, the deployment will not automatically trigger the new version of that container instance to run again.
In my case, I'm scheduling a container deployment to occur from inside an Logic App using the "Create or update a container group" connector (because Microsoft removed the cloud scheduler earlier this year, forcing people to use Logic Apps for simple tasks like this). If I delete the existing container group and run the Logic App, then it will automatically start the Docker container instance as expected. When I re-run it subsequent times, it fails to start the container, because the previous instance inside the container group is in a terminated state. The solution is to add an additional "Start containers in a container group" action, which will start the container instances anew and allow them to run to completion (at which point my containers terminate again, because they're one-off ETL jobs).
David
- 300
- 1
- 14
-
I have been rather unimpressed with Azure Container Instances. They're a bigger pain to work with than I had anticipated. For some other limitations of ACIs, check this (rather opinionated) blog post, if you're considering whether to use them in your project: https://josefbajada.medium.com/8-reasons-why-azure-container-instances-suck-a8a81fa91f92 If you're on Azure and want to make use of Docker containers, without the additional overhead of something like Kubernetes, they still may be the best choice. Just be aware of their limitations, and if those limitations matter to your deployment. – David Jul 19 '22 at 21:46