Google Cloud supports running a virtual machine instance using CoS
CoS is a slim OS distribution providing a docker CLI and containerd service to run a single docker container. The single container can be configured to be ran directly on instance startup from the cloud console itself.
However, for more advanced use cases sadly, docker compose is not available by default. By leveraging the official docker image, the docker compose CLI plugin can be made available as a side-car container.
Additionally, its makes docker-gcr-credentials available to enable pulling images from GCR securely using service account credentials.
Included in this gist is a shell script example and cloud-init YAML to configure a VM instance with docker-compose enabled. The technical details section explains more.
The virtual machine is configured to pull the official docker image and start this on boot-up. Google's konlet image will take care of the startup procedure.
By mapping /var/run/docker.sock
into the docker image, docker compose can now interact with the host docker daemon.
The docker compose CLI plugin is initialized with the following command arguments:
compose
--project-directory=/home/compose
up
--build
--force-recreate
--no-color
--pull=all
--remove-orphans
--renew-anon-volumes
By ensuring its project working directory is /home/compose
, we can ensure it looks for a docker-compose.yml
file in this location.
This home folder is mapped from the host into the docker image and is populated on startup through cloud-init.yaml write-files
instructions.
Additionally the cloud-init.yaml places a ~/.docker/config.json
file which configures docker-credential-gcr binary for any Google container registry domains.
In order to ensure docker compose reads this configuration file, the environment variable HOME=/home/compose
is set for the docker compose container.
docker-credential-gcr
is made available by mapping /usr/bin/docker-credential-gcr
to /usr/local/bin/docker-credential-gcr
.
Additionally the /lib64
folder from the host operating system is mapped into the container to ensure the dynamically linked credential executable works.