gns3-registry icon indicating copy to clipboard operation
gns3-registry copied to clipboard

How to update a docker image?

Open ghost opened this issue 8 years ago • 14 comments

Currently I don't know, what's the best way to update a docker image in the registry. When I just change the Dockerfile the :latest version is updated on docker hub, but users, who are already using the previous version of that image have no way within GNS3 to get this update.

Some ideas I got:

  1. The user has to go into the CLI of the GNS3 server/VM and manually pull the new version.
  2. We tag each image with a version and use this tag in the .gns3a file. By downloading and importing the most recent .gns3a file the user will get the latest image. But how to tag a image? The GNS3 developers can do that manually, when a new pull request with a docker image is merged. But that manual process defeats the idea of automatic docker image builds.
  3. GNS3 implements an image update feature. It can use a docker pull <image> followed by a image cleanup docker rmi $(docker images -f "dangling=true" -q). If the local image is a recent one, docker pullwill not re-download the image. So only an updated image triggers a download. This update feature should be started only, when the user agrees to it.

For me the cleanest way is tagging the image. Then it's well defined, what version will be used. But how to do that without requiring too much efforts from the maintainers?

ghost avatar Jul 04 '16 07:07 ghost

Tag seem to be the best answer to the question.

  1. Problem it will work for new gns3a import but your old topologies will use the old version. If you want to upgrade the container. You will need to modify your topologies.

I think we have two kind of container:

  • container where version is important (Open Daylight, Open vSwitch...)
  • container where we don't care about version, the last is best (webterm, ipterm, ostinato...)

We can in the registry force user to ask for a tag a latest in order to make things clear.

julien-duponchelle avatar Jul 04 '16 07:07 julien-duponchelle

If we want tag for our container in this repo I think we need to found a way to build them using travis: https://docs.travis-ci.com/user/docker/#Building-a-Docker-Image-from-a-Dockerfile

But how to give the version number to tag to travis?

julien-duponchelle avatar Jul 04 '16 07:07 julien-duponchelle

But even containers, where we don't care about the version, have to be tagged. Otherwise an existing customer can't easily upgrade to the lastet version.

ghost avatar Jul 04 '16 08:07 ghost

Tag make upgrade more harder because GNS3 will remember the tag and will use the old tag :(

julien-duponchelle avatar Jul 04 '16 08:07 julien-duponchelle

A topology made with a tag will use it for ever.

julien-duponchelle avatar Jul 04 '16 08:07 julien-duponchelle

Oh, I see. But then a user has no way to upgrade an existing docker VM without using docker commands in the CLI of the GNS3 server/VM.

ghost avatar Jul 04 '16 08:07 ghost

Mmm back to the initial problem :(

julien-duponchelle avatar Jul 04 '16 08:07 julien-duponchelle

To make things worse: On every update of the gns3-registry, no matter if a docker image is changed or not, docker hub rebuilds all gns3 docker images from scratch. As at least the timestamps of the files are changing this normally results in updated images.

So looking at the docker hub doesn't tell you, if an image is really changed or just rebuild with no real changes.

ghost avatar Jul 12 '16 12:07 ghost

This mean we probably need a more smart system for building images :(

julien-duponchelle avatar Jul 13 '16 07:07 julien-duponchelle

No interest from GNS3 side

ghost avatar Nov 08 '17 16:11 ghost

I would like to investigate this to see if something can be done. Julien implemented most of the Docker support back in the days, so I need to check how things could be modified.

grossmj avatar Apr 22 '19 06:04 grossmj

What about this?

  1. We add a key to the appliance schema that stores the URL of the Dockerfile.
  2. When a node is dragged into the topology, GNS3 checks if the Dockerfile in the URL is different from the one stored locally.
  3. If yes, it initiates a "docker pull " because a change in the Dockerfile means the image is updated as well. The new Dockerfile is also downloaded to the local storage.

It's automated (no need for user interaction) and efficient (doesn't pull every image just because a new build was triggered by a commit). The only drawback is the schema extension. Example:

    "docker": {
        "adapters": 1,
        "image": "adosztal/aaa:latest",
        "console_type": "telnet",
        "dockerfile": "https://raw.githubusercontent.com/adosztal/gns3-containers/master/aaa/Dockerfile"
    }

adosztal avatar Apr 22 '19 06:04 adosztal

Note: the old images with <none> tags should be deleted after the update. Here's a shell command for that: docker rmi $(docker images | grep "<none>" | awk "{print $3}")

adosztal avatar Apr 22 '19 06:04 adosztal

Note: the old images with <none> tags should be deleted after the update. Here's a shell command for that: docker rmi $(docker images | grep "<none>" | awk "{print $3}")

Since docker v1.13.0 (2017-01-18) it's easier with docker image prune --force

b-ehlers avatar Jun 14 '23 08:06 b-ehlers