How to version production image?

Hi,
I have a question regarding the VSCode deployment.
As described here Deploying Container Images to Torizon OS | Toradex Developer Center
there are different ways to deploy the docker images.

I am currently using VSCode Build, Test and Push Applications for Production | Toradex Developer Center

I run the :

  1. “run-container-torizon-release-” task
  2. than the “create-production-image” task
  3. than load the generated “docker-compose.prod.yml” to the torizon cloud
  4. trigger the update via the torizon cloud

But how to version the generated docker images?

The generated “docker-compose.prod.yml” looks like:

version: "3.9"
services:
  project-name-cannot-be-changed:
    image: dockerregistry/project-name-cannot-be-changed:arm64
    privileged: true

Lets say this is version V1.0.0.
Now a new feature or fix has to be implemented.
And I run the “create-production-image” task again ->V1.0.1, this will overwrite my old image in the registry, or ?
And it is not possible to change the docker image name → “project-name-cannot-be-changed” nor the docker image tag → “arm64”

Both are used in all the scripts in the .env folder in VSCode extensivly.
And now the docker registry has a new image but torizon cloud still thinks it is up to date because it uses the same docker-compose.prod.yml like before.

Any ideas on how to bring versioning into this.
How can I deploy V1.0.0 to the board again.

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Versioning Docker images in a CI/CD pipeline, such as the one you’re using with VSCode for Torizon, is crucial for managing releases and ensuring the correct deployment of your application. To implement versioning for your Docker images and avoid overwriting previous versions, you can use a combination of Docker tags and modifications in your project’s configuration.

  1. Modify Docker Tags in the VSCode Task: When you run the create-production-image task, you should specify a unique Docker tag that reflects the version of the image you’re creating. Instead of using a generic tag like arm64, use semantic versioning, for example, 1.0.1. This tag should be updated in the .vscode/settings.json file or directly in the command palette inputs when you trigger the task if the extension supports it.

  2. Update .env and docker-compose.prod.yml: To ensure that the Torizon Cloud recognizes the new version of your Docker image, you must update the docker-compose.prod.yml file with the new image tag. Since you mentioned that the project name and image tag seem to be fixed and extensively used in scripts, you’ll need to manually update these references to match the new versioned tag you’ve created. This might involve a search and replace operation in your .env files and any scripts that reference the Docker image.

  3. Automate Versioning: To streamline the versioning process, consider implementing a versioning strategy in your development workflow. This can involve scripting or using VSCode tasks that automatically increment version numbers based on the type of changes (major, minor, patch) and update all necessary files accordingly.

  4. Use Version Tags in Torizon Cloud: When loading the docker-compose.prod.yml to the Torizon Cloud, ensure that the version tag in the image reference matches the new version you’ve created. This way, when you trigger an update via the Torizon Cloud, it will pull the correct version of the image based on the updated docker-compose.prod.yml.

  5. Re-deploying Older Versions: If you need to deploy an older version (e.g., V1.0.0) to the board again, ensure that the docker-compose.prod.yml on the Torizon Cloud references the correct version tag for that image. You might need to maintain multiple versions of the docker-compose.prod.yml file for different versions of your application.

Remember, the key to versioning Docker images effectively is in the consistent

Please, also check if these links can help you solve your problem:

Build, Test and Push Applications for Production | Toradex Developer Center.

Sorry but this AI generated answer does not help at all

I should automate the versioning but do it manually?

Greetings @dan,

You should be able to version your container images quite easily. First of all let’s talk about Dockerhub. When you push an image with something like jeremiascordoba/test:1.0.0. It will use the tag 1.0.0. If you repeat the same process but with a different tag like jeremiascordoba/test:1.1.0 then it will go to the same registry location but with a different tag. This will not overwrite the previous tag. If you use the same tag then it will overwrite in the registry.

As an example see my registry here: https://hub.docker.com/repository/docker/jeremiascordoba/test/tags

I used two different tags to differentiate the version and I can refer to either image with the appropriate tag. Same should go for your image as well.

And it is not possible to change the docker image name → “project-name-cannot-be-changed”

I don’t think it’s possible to easily change the project name, at least that I know of. As you said the project name is used extensively throughout the project tasks and scripts when the project gets initially generated.

nor the docker image tag → “arm64”

As I said you should be able to easily change the docker image tag via settings.json.

In summary you should be able to control container image versioning via changing the respective tag. This will create multiple images in your docker registry. For the compose file however, it will get overwritten in the VSCode project if you re-run the publish task. So if you want to keep the old compose file you should version control this somewhere with git or something similar.

Best Regards,
Jeremias

Thanx for your fast answer,
Maybe I confused the docker image parameter IMAGE_ARCH with the docker tag?


I think this can not be changed because the whole build process is based on this, or?

And this is also used to create the production image tag, or?

So I currently have in my vscode.settings.json

...
  "docker_tag": "arm64",
...

Did I understand you correct that I can just do

“docker_tag”: “V1.2.3”,

Maybe I confused the docker image parameter IMAGE_ARCH with the docker tag?

Yes, these are two different things. The IMAGE_ARCH is just used by the various tasks executed by our extension to make sure the right system architecture is being built for. The docker tag is just an identifier that is part of the overall container image name. It can be whatever you want.

So I currently have in my vscode.settings.json

When you first ran the create-production-image task it should have asked you for a docker tag to give your container image. You must have put arm64 the first time for some reason.

Did I understand you correct that I can just do

Correct, when you define the docker tag the first time you run the create-production-image it gets saved to settings.json. You can change this value yourself at any time and it will affect future executions of the task.

Best Regards,
Jeremias

Thank you for your fast help. It works

Glad we were able to assist!