How can we improve Azure Container Instances?

Cache the downloaded container image in the Container Instances (preview)

Each time I start a new container, the image is pulled from the repository. Even if I start 10 times the same image. I would like to have the image cached (maybe on the resource group level) so that I only get the penalty of pull once.

128 votes
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Radu shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

20 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Anonymous commented  ·   ·  Flag as inappropriate

    This is a total deal breaker. I would love to modernise our cloud architecture with containers to service a queue, rather than using cloud services, but I can't when it's so incredibly slow to start

  • DKG commented  ·   ·  Flag as inappropriate

    This would be a game changer for our system. We use .net core in the MS alpine runtime container to make the image as small as possible. With a 140 MB image stored in ACR it still take 30 seconds on average. If the image was started on a VM with the base image it would take a few seconds at most...and oh boy would that rock! Please please please...

  • Bnx2018 commented  ·   ·  Flag as inappropriate

    There are comments here that it takes a long time to deploy a container on ACI. For me, this is the Windows LTSC image that takes over ten minutes on ACI. I did a lot of experimentation, and the 1803 base image can start in ten *seconds* on a docker VM because it does not download and unpack the base image. So it is possible to get a good startup time, it just hasn't been enabled by getting a base image that matches the ACI servers. Containers should start "in seconds" as per the advertising.

  • Uffe Hansen commented  ·   ·  Flag as inappropriate

    This is a major blocker preventing me using ACI, I love the serverless concept of ACI - but the pull times just simply prevent me from using it

  • Omer Raviv commented  ·   ·  Flag as inappropriate

    For me, this is probably the biggest blocking issue in using ACI. While the idea of having "serverless" pay-as-you-go billing structure for containers, I'm finding the reality is that when using ACI I am forced to keep at least minimal elastic pool of containers running 24/7 to compensate for the slow start-up times, which offset a lot of the cost savings when comparing costs with a ServiceFabric-based solution.

  • Omer Raviv commented  ·   ·  Flag as inappropriate

    For me, this is probably the biggest blocking issue in using ACI. While the idea of having "serverless" pay-as-you-go billing structure for containers, I'm finding the reality is that when using ACI I am forced to keep at least minimal elastic pool of containers running 24/7 to compensate for the slow start-up times, which offset a lot of the cost savings when comparing costs with a ServiceFabric-based solution.

  • Poul commented  ·   ·  Flag as inappropriate

    I am also running into this being a blocker for me right now. To much time is used to download large images, even with a registry deployed to same resourcegroup/location

  • Nick Caruso commented  ·   ·  Flag as inappropriate

    I'm not sure if this is a Kubernetes thing, but when I used Kubernetes on Google's Kubernetes Engine the server would cache the image local, and check the version tag being requested. If it matched the cache it would use it. This same capability would be great. I just had my underlying app server restart, which prompted all of my running containers to have to redownloaded the image. It took 15 minutes for my application to come back up.

  • Alexander Trauzzi commented  ·   ·  Flag as inappropriate

    Right now when I deploy, multiple image pull timeout events are posted. Following that, the speed leaves a lot to be desired.

    If I'm to configure an on-demand Jenkins executor setup using the official Microsoft Jenkins ACI plugin, you need some minimum standard of performance that people can bank on. It makes no sense to have to wait upwards of 30 minutes just for a container to be started.

    That effectively nullifies all the benefits of something as transient and flexible as ACI.

    When the request for a container to be instantiated comes in, you need to aim to have it up and running within 30 seconds. Ideally less, in the 5-10 second range.

    Anything more makes the service feel unresponsive.

  • Andrew Kanieski commented  ·   ·  Flag as inappropriate

    This is a pretty significant draw back when using a "larger" container.. like windows containers (non-nano).

    The time it takes to spin up a container makes it basically unviable for larger containers.

Feedback and Knowledge Base