Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to update a docker image? #145

Open
ghost opened this issue Jul 4, 2016 · 14 comments
Open

How to update a docker image? #145

ghost opened this issue Jul 4, 2016 · 14 comments
Labels
Milestone

Comments

@ghost
Copy link

ghost commented Jul 4, 2016

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?

@julien-duponchelle
Copy link
Contributor

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
Copy link
Contributor

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?

@ghost
Copy link
Author

ghost commented Jul 4, 2016

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.

@julien-duponchelle
Copy link
Contributor

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

@julien-duponchelle
Copy link
Contributor

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

@ghost
Copy link
Author

ghost commented Jul 4, 2016

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.

@julien-duponchelle
Copy link
Contributor

Mmm back to the initial problem :(

@ghost
Copy link
Author

ghost commented Jul 12, 2016

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.

@julien-duponchelle
Copy link
Contributor

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

@ghost
Copy link
Author

ghost commented Nov 8, 2017

No interest from GNS3 side

@grossmj
Copy link
Member

grossmj commented Apr 22, 2019

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.

@adosztal
Copy link
Contributor

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
Copy link
Contributor

adosztal commented Apr 22, 2019

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}")

@ghost
Copy link

ghost commented Jun 14, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants