how to freeze an image that was built with "latest"

Product support
1

I built and deployed an image using the latest suffix on the docker base image a long time ago. Now I want to update the code, but would like to use the same base image. This is probably a very noobie question but how do I figure out what base build image the latest mapped to in a deployed container so I can then freeze it in the Dockerfile, presumably resulting in a smaller delta.

2

Is the device running the old Dockerfile with the latest tag still running and accessible ? If so we might be able to run some commands to query balenaEngine.

4

Yes, I can ssh into it from the dashboard.

5

Can you share the uuid for that device in a private message so we can take a look? You would also need to enable support access for us to be able to ssh to it

8

Hi, we will get back to you here with our conclusions. In the future, see https://www.balena.io/docs/learn/more/anti-patterns/#not-pinning-base-image-versions for base image pinning

9

Thanks. Saw that antipattern too late. Question: if I am using a build image such as

FROM balenalib/raspberry-pi-alpine-python:3.7-build as build

Is that necessarily versioned to be fixed, or is it possible that the underlying alpine or even python version may change, causing this image to change? With a new project I often start with latest but then it’s not obvious to me how to freeze that before deployment.

10

Hi there – you can get an idea of the tagging we do on images by looking on this page for the image you’re using. As a rule, I’d be very surprised if (in the case you mention) the Python version for the image raspberry-pi-alpine-python:3.7-build changed from 3.7 to 3.8 – but I would not be surprised to see it change from 3.7.x to 3.7.y, or to find out that some of the underlying tooling had changed.

I would recommend picking an image and pinning it earlier in the development process. For increased certainty, have a look at the images tagged by build dateYYYYMMDD – see this Docker Hub page for the builds for raspberry-pi-alpine-python, for example. If you do that early, you can be sure that what you’re working with is the same throughout the development process.

Thanks,
Hugh

12

Hi,

I’ve checked your devices, the solmon service is usingbalenalib/raspberry-pi-debian-node:10.10.0-stretch-build and 2 other services are using balenalib/raspberry-pi-alpine-node:12.6.0 since we never delete any images so you can go to the dockerhub repository and search for these tags there. However I’m not quite sure if these tags will be the same as the images you’re using in your application since these are moving tags which will be weekly rebuilt but you can try some datetags that go with balenalib/raspberry-pi-debian-node:10.10.0-stretch-build or balenalib/raspberry-pi-alpine-node:12.6.0 to find the correct one.

As my colleague mentioned above, if you want a stable build, you should always use base images with datestamped tag (YYYYMMDD) since they will never be rebuilt and you can just jump to any recent datetags when you want to update the base images.

14

Thanks for looking into it. Based upon your response, my understanding is that there isn’t a way to map a build to a particular instance of a base image. My mental model of images with generic logical image specifications (such as latest or alpine) was as links, which point to a particular build instance (similar in model to shared libraries on a linux system, for e.g.). But either that is not the case, or if it is, the actual image used isn’t encoded in the downloaded image.

I take your point to always use datestamped tags.

15

Hi there – you can think of the tag (whether latest or anything else) as a convenient, mutable label that gets applied to a container with a particular checksum. Which particular container (and checksum) latest happens to point to can change. In theory, that’s also true of tags like YYYYMMDD – however, we’ve committed to not rebuilding images pointed to by those date tags, which is why we so strongly recommend them for stable builds. This article does a decent job of explaining the difference.

Hope that helps,

Hugh

17

Is there a checksum in the deployed image that can be mapped to a particular dated build? How would I know if a bug seen in the field in a particular service is possibly fixed in a later version of the base?

18

Hi,

We don’t provide that information but I think you can inspect the deployed image to get the checksum of both images (the base image and deployed one) map them yourself. If you find a bug in our base images, please raise it and we will get back to you as soon as the issue is resolved then you can move your base to the next datestamp with the fix included.