Kitematic: Feature Request: let users 'upgrade' containers

Created on 25 Sep 2017  路  3Comments  路  Source: docker/kitematic

I use docker to distribute my app to non-technical users. They are not developer, they know nothing about docker, they are scared of the terminal window, etc. So far Kitematic does a great job at acting like a standard app store; most users can download my app and start / stop it with simple instructions.

Now when a new version of the image is available it's still possible to use the UI to pull the latest version of the image and recreate the container but it's not straightforward. It would be nice if this was a single operation.

Ideally Kitematic could check at regular interval for all containers if there is a more recent version of the image locally or on Dockerhub. If so an 'upgrade' button could be shown next to the container label on the right. A click on that button would pull the newest image from dockerhub and recreate the container with the same name and configuration (volumes, port mapping, etc.).

One issue with that is determining what is a 'newer' version. That's probably a separate discussion and I'm not sure if there is a consensus about it. 'latest' is problematic as it's just a tag that can be set to anything and can possibly be older than the newest version. Also a local 'latest' may point to an older image than 'latest' on dockerhub. Perhaps the detection for a newest image should check for and be based on a x.y.z versioning format.

Most helpful comment

Hi @FrenchBen , thanks for the response.

By default docker will always try and use the latest image.

Actually 'latest' is a misleading concept in Docker! Kitematic will try the latest tag from 'My Images' screen. If 'latest' tag now points to a new Image on Dockerhub, well Kitematic will not try not pull the latest image because it has 'a' latest tag already.

Just to be clear, I'm not suggesting a completely automatic redeployment by Kitematic. The Feature Request could be split in two parts. Let's take the simplest case: the users have created a container based on image X:latest. I push a new 'latest' image on Dockerhub. At the moment there's no way for the users to know there's a new image. You can compare that with some traditional desktop apps that send the user a notification when a new version is ready to be downloaded (e.g. VirtualBox): either via regular polling or when the user explicitly asks whether a new version is available. Giving the user at least a way to check for new versions from Kitematic would be great.

The second part of the Feature Request is the simplification of the upgrade procedure. Right now if someone wants to upgrade a container, they have to: remove the container, search again for the image name (because the one in My Image will not allow them to pull new tags), and create a new Container from the Image they have found then possibly re-configure the the Container (e.g. port mapping, enabled volumes). Having a button to do all that with one click would be a great step forward; bringing Kitematic and Docker closer to what basic end users expect from a modern app or app store. At the moment I think it's 90% there, what's left doesn't look too difficult to implement logically as long as the mechanism are well designed.

My point for supporting this feature(s) is that Docker has an image versioning system built-in and I find it surprising that it's not better exploited by Kitematic at least to provide an experience that many users of desktop application expect from softwares that can be upgraded from the web.

All 3 comments

By default docker will always try and use the latest image.
If a "pinned" version is desired, it is usually recommended to use something else than latest.

What you're referring to is an automated deployment based on a tag, which is IMHO a bit out of scope for Kitematic at this point in time.

Hi @FrenchBen , thanks for the response.

By default docker will always try and use the latest image.

Actually 'latest' is a misleading concept in Docker! Kitematic will try the latest tag from 'My Images' screen. If 'latest' tag now points to a new Image on Dockerhub, well Kitematic will not try not pull the latest image because it has 'a' latest tag already.

Just to be clear, I'm not suggesting a completely automatic redeployment by Kitematic. The Feature Request could be split in two parts. Let's take the simplest case: the users have created a container based on image X:latest. I push a new 'latest' image on Dockerhub. At the moment there's no way for the users to know there's a new image. You can compare that with some traditional desktop apps that send the user a notification when a new version is ready to be downloaded (e.g. VirtualBox): either via regular polling or when the user explicitly asks whether a new version is available. Giving the user at least a way to check for new versions from Kitematic would be great.

The second part of the Feature Request is the simplification of the upgrade procedure. Right now if someone wants to upgrade a container, they have to: remove the container, search again for the image name (because the one in My Image will not allow them to pull new tags), and create a new Container from the Image they have found then possibly re-configure the the Container (e.g. port mapping, enabled volumes). Having a button to do all that with one click would be a great step forward; bringing Kitematic and Docker closer to what basic end users expect from a modern app or app store. At the moment I think it's 90% there, what's left doesn't look too difficult to implement logically as long as the mechanism are well designed.

My point for supporting this feature(s) is that Docker has an image versioning system built-in and I find it surprising that it's not better exploited by Kitematic at least to provide an experience that many users of desktop application expect from softwares that can be upgraded from the web.

This is definitely one of the most missing features in Kitematic. Just being able to re-create an existing container based on another specific tag is a must have! Container management applications like Rancher and Portainer have this feature, and I use it all the time.

This is a must have feature when you are switching between various container versions while maintaining the current configuration.

And it shouldn't be too hard to implement, because when you change a container setting in Kitematic the container is already recreated. The only thing that it needs to do is use another image tag and create the container with the old settings like environment variables, volume's etc. etc.

+1

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ClemMakesApps picture ClemMakesApps  路  3Comments

noahgift picture noahgift  路  3Comments

djsowa picture djsowa  路  3Comments

EliotSlevin picture EliotSlevin  路  3Comments

foverzar picture foverzar  路  4Comments