tree: 4c165ca7f26da89e70b3a80b3000402ab12e7cb2 [path history] [tgz]
  1. build.sh
  2. Dockerfile
  3. README.md
  4. shutdown.sh
  5. start_swarm_bot.sh
docker/swarm_docker/README.md

The files here are used to build a docker image suitable for Swarming. Recommended usage is for lightweight bots running mainly swarming trigger/collect.

The docker image

The build.sh script will create a local image named swarm_docker tagged with the date and time of creation. The image itself is simply an Ubuntu flavor (bionic as of writing this) with a number of packages and utilities installed. When launched as a container, this image is configured to run the start_swarm_bot.sh script here which fetches and runs the bot code of the swarming server pointed to by the $SWARM_URL env var. Note that running the image locally on a developer workstation is unsupported.

Automatic image building

Everyday at 8am PST, a builder on the internal.infra.cron waterfall builds a fresh version of the image. This builder essentially runs ./build.sh and uploads the resultant image to a docker container registry. The registry, hosted by gcloud, is located at chops-public-images-prod. Similarly, this builder builds arm64 images and uploads them here.

Shutting container down from within

Because a swarming bot may trigger a reboot of the bot at any time (see docs), it should also be able to shut its container down from within. By conventional means, that's impossible; a container has no access to the docker engine running outside of it. Nor can it run many of the utilities in /sbin/ since the hardware layer of the machine is not available to the container. However, because a swarming bot uses the /sbin/shutdown executable to reboot, this file is replaced with our own bash script here (shutdown.sh) that simply sends SIGUSR1 to init (pid 1). For a container, init is whatever command the container was configured to run (as opposed to actual /sbin/init). In our case, this is start_swarm_bot.sh, which conveniently traps SIGUSR1 at the very beginning and exits upon catching it. Consequently, running /sbin/shutdown from within a container will cause the container to immediately shutdown.

Image deployment

Image deployment is done via puppet. When a new image needs to be rolled out, grab the image name in the step-text of the “Push image” step on the image-building bot. It should look like swarm_docker:$date. (The bot runs once a day, but you can manually trigger a build if you don't want to wait.) To deploy, update the image pins in puppet here. Note that only swarm_docker_arm64 images are used on bots at the moment.

Launching the containers

On the bots, container launching and managing is controlled via the python service here, which ensures that a configured number of containers is running. It will gracefully tear down containers that are too old or reboot the host. Called every 5 minutes via cron.

More information can be found here.