Why container-optimized compute instance uses cached image instead of the latest one?

1
votes

I'm running a container-optimized compute instance with this startup-script:

#!/bin/bash

mkdir /home/my-app
cd /home/my-app
export HOME=/home/my-app

docker-credential-gcr configure-docker


docker run --rm --security-opt seccomp=./config.json gcr.io/my-project/my-app:latest

This scripts works well when creating a new instance. But when I restart an existing instance it doesnt't pull the latest image.

I've tried to delete all images from the gcr, the instance was able to start anyways, which proves that it doesn't even try to pull the latest image from gcr.

Also, for some reason startup-script logs are not showing up in Cloud Logger.

1
google-cloud-platformgoogle-compute-engine
Are you sure the script doesn't do anytning ? Maybe do some dubugging and add something like touch ~/testfile1 - or anythnig that would indicate that will make a mark and tell you the script actually ran. Maybe you can pull some logs (from the VM itself) ? If so please update your question with as much details of what you've tried and what were the results. - Wojtek_B
Log into your instance. Use journalctl to view the boot logs. You will find the startup script logging in the boot logs. - John Hanley
Thanks @JohnHanley, will do. Is there way to send boot logs to Cloud Logger? - stkvtflw
Yes, install Stackdriver. jhanley.com/… - John Hanley

1 Answers

1
votes

As per kubernetes, With Docker, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.

As a workaround you can add step 1 and 2 in to your script:

1- docker images // will show you the list of images including (gcr.io/my-project/my-app:latest)

2- docker rmi --force gcr.io/my-project/my-app:latest // will delete local image

3- docker run (rest of your command, it will download the latest image again from the gcr.io)