Skip to content

Container Development Guide

This document contains instructions for OSG Technology Team members, including:

  • How to to develop OSG Software container images that are automatically pushed to Docker Hub that adhere to our container release policy
  • How to build a new version of an existing image
  • How to manage tags for images in the OSG DockerHub organization
  • Tips for container image development

Creating New OSG Software Containers

OSG Software service container images intended for OSG site admin use need to be automatically updated once per week to pick up any OS updates, as well as upon any changes to the images themselves. To do this, we use GitHub Actions to:

  1. Build new images on commits to master
  2. Update the docker-software-base on a schedule, which triggers builds for all image repos through repository dispatch
  3. Push container images to Docker Hub.

Prepare the GitHub repository

  1. Create a Git repository in the opensciencegrid organization whose name is prefixed with docker-, e.g. docker-frontier-squid
  2. Create a README.md file describing the software provided by the image
  3. Create a LICENSE file containing the Apache 2.0 license text
  4. Set the repository topic to container

  5. Create a Dockerfile based off of the OSG Software Base image:

    FROM opensciencegrid/software-base:<OSG RELEASE SERIES>-<EL MAJOR VERSION>-release

LABEL maintainer OSG Software <[email protected]>

RUN yum update -y && \
    yum clean all && \
    rm -rf /var/cache/yum/*

RUN yum install -y <PACKAGE> && \
    yum clean all && \
    rm -rf /var/cache/yum/*

    Replacing <PACKAGE> with the name of the RPM you'd like to provide in this container image, <OSG RELEASE SERIES> with the OSG release series version (e.g., 3.6), and <EL MAJOR VERSION> with the Enterprise Linux major version (e.g., 7).

  6. Add the pre-defined OSG Software container publishing GitHub Actions workflow. From the GitHub repository, perform the following steps:

    1. Go to the Actions tab
    2. Select the Publish OSG Software container image workflow (you may have to click Add new workflow first if the repository has existing workflows)
    3. Click Start commit then Commit new file
  7. Give write permissions to the "osg-bot" user for this GitHub repo, navigating to:
    1. "Settings"
    2. "Manage access"
    3. "Invite teams or people"
    4. Search for and select "osg-bot"
    5. Choose the "Write" role, and click the button to Add osg-bot to the repo. (The osg-bot user needs this permission in order to trigger automatic builds.)
  8. Ask the Software Manager to give this repo access to the following organizational secrets
    • DOCKER_USERNAME
    • DOCKER_PASSWORD
    • OSG_HARBOR_ROBOT_USER
    • OSG_HARBOR_ROBOT_PASSWORD

Repository dispatch

Any repository that sends dispatches to another repository (e.g. docker-software-base, docker-compute-entrypoint) needs access to the REPO_ACCESS_TOKEN organization secret. Ask the Software Manager for access.

Prepare the Docker Hub repository

  1. Ask the Software Manager to create a Docker Hub repo in the OSG organization. The name should generally match the GitHub repo name, without the docker- prefix.
  2. Go to the permissions tab and give the robots and technology teams Read & Write access

Set up repository dispatch from docker-software-base

  1. Edit the GitHub Actions workflow for docker-software-base, and add the new GitHub repo name to the dispatch-repo: list (under jobs: dispatch: strategy: matrix:).
  2. Make a Pull Request for your change.

Triggering Container Image Builds

To build a new version of an existing container image, e.g. for a new RPM version of software in the container, you can kick off a new build in one of two ways:

  • If there are no changes necessary to the container packaging: go to the GitHub repository's latest build under Actions, e.g. https://github.com/opensciencegrid/docker-frontier-squid/actions/, and click "Re-run jobs" -> "Re-run all jobs".
  • If changes need to be made to the container packaging: submit a pull request with your changes to the relevant GitHub repository and request that another team member review it. Once merged into master, a GitHub Actions build should start automatically.

If the GitHub Actions build completes successfully, you should shortly see new fresh and timestamp tags appear in the DockerHub repository.

Automatic weekly rebuilds

If the repo's GitHub Actions are configured as above, container images will automatically rebuild, and therefore pick up new packages available in minefield once per week.

Managing Tags in DockerHub

Adding tags

Images that have passed acceptance testing should be tagged as stable:

  1. Install the jq utility:

    yum install jq

  2. Get the sha256 repo digest of the image that the user has tested. All you need is the part that starts with sha256:... (aka the <DIGEST>).

    A Kubernetes user can get the digest from the "Image ID" line obtained by running:

     kubectl describe pod <POD>

    A Docker user can get the digest by running:

     docker image inspect <IMAGE NAME>:<TAG> | jq '.[0].Id'

  3. (Optional) If you are tagging multiple images, you can enter your Docker Hub username and password into environment variables, to avoid having to re-type them. Otherwise the script will prompt for them.

    read user     # enter dockerhub username
read -s pass  # enter dockerhub password
export user pass

  4. Run the Docker container image tagging command from release-tools:

    ./dockerhub-tag-fresh-to-stable.sh <IMAGE NAME> <DIGEST>

Removing tags

Run the Docker container image pruning command from release-tools:

./dockerhub-prune-tags.py <IMAGE NAME>

Making Slim Containers

Here are some resources for creating slim, efficient containers: