The page claims that:
Update the container group with a new DNS name label, myapplication, and leave the remaining properties unchanged:
But this does not seem to be the case. Running the command to update the image erased environment variables and port bindings, which existing container had.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Here is a reproduction. I create a container using:
az container create --resource-group my-group --name dummy --image nginx:stable --memory 2 --ports 80 443 --dns-name-label dummy
Now I can verify that it has ports and DNS label assigned correctly. Then I run a command to update the image:
az container create --resource-group my-group --name dummy --image nginx:latest
It fails because memory does not match:
The updates on container group 'dummy' are invalid. If you are going to update the os type, restart policy, network profile, CPU, memory or GPU resources for a container group, you must delete it first and then create a new one.
To fix it I have to include memory parameter again:
az container create --resource-group my-group --name dummy --image nginx:stable --memory 2
It succeeds but removes existing ports and DNS label configurations.
My Azure CLI version:
az --version
azure-cli 2.0.80 *
command-modules-nspkg 2.0.3
core 2.0.80 *
nspkg 3.0.4
telemetry 1.0.4
@devoto13
You need to all the flags during update also.
If we leave some, Then container instances will be configured according to the latest command. ie erases the flags which are not there in the current command
I know that this will be difficult to maintain the all those flags in azure cli.
Suggested option is to create a ACI with yaml file. You can also export a yaml out of the existing ACI.
Then you can edit or update the YAML to update the ACI.
This command will work
az container create --resource-group my-group --name newLabel --image nginx:stable --memory 2 --ports 80 443 --dns-name-label dummy
Thanks for the reply @jakaruna-MSFT. This is what I have suspected. But in this case the documentation should be updated as currently it sounds like all the existing configurations are preserved:
Update the container group with a new DNS name label, myapplication, and leave the remaining properties unchanged:
Modify at least one valid property of the group when you issue the create command to trigger the redeployment, and leave the remaining properties unchanged (or continue to use default values).
I thinks this should be very clear that it will reset all unspecified configurations to their default values. I find "and leave the remaining properties unchanged" very confusing and would prefer this to be removed from the article. I would rather expect something like:
Update the container group with a new DNS name label, myapplication. Note that this will reset all unspecified configuration properties to their default values. If you want to preserve existing values you will have to specify all of them in the update command.
Maybe even update/add an example to demonstrate it.
@devoto13 i will update the doc as needed. Thank you
Btw I solved this by doing as @jakaruna-MSFT suggested: using az container export --file template.yaml, then modifying the template.yaml using script and running az container create --file template.yaml to deploy an updated configuration.
The drawback is that Docker registry password and any secret environment variables are not present in the exported template.yaml, so I had to add them back in a script. While the solution is not perfect at least I don't have to manually specify all the data from the original ARM template, when I only want to update the image. Maybe this solution will help other people, who only want to update the image version.
@dlepow Can we add a note to include a link to export a container instances via yaml file?
We have a line in the document already like this
Update the container group with a new DNS name label, myapplication, and leave the remaining properties unchanged:
Above link asks the users to change the required parameters and leave the remaining parameteres as is.
Do you think we can add a note explicitly to specify that?
@dlepow Please check if you can add these details in the doc
@devoto13 @jakaruna-MSFT - Thank you for the feedback, and apologies for slow response. I agree that documented details around parameter changes/preservation during update can be improved in this article. Your suggestions will help. I created a work item referencing this issue and plan to address in an upcoming doc sprint.