Building a deployable Docker image#
Release builds of container images should be built by the github CI on release, ad-hoc builds can be performed via manual invocation of the Publish Docker Image workflow.
Development builds of container images can be made by running the utility_scripts/build_docker_image.sh script.
By default it will both build and push the image unless you specify --no-build or --no-push. To push an image
you will first need to create a GH personal access token and then log in with podman as described below.
Pushing the docker image#
Obtaining a GitHub access token#
You will need to obtain a GitHub personal access token (classic) - not the new fine-grained token. It will need the specific permission scopes as detailed in the ghcr documentation
Building the image#
If building a test image, the image should be pushed to your personal GH account:
cat <mysecretfile> | podman login ghcr.io --username <your gh login> --password-stdin
where mysecretfile contains your personal access token
Then run the build_docker_image.sh script.
Troubleshooting#
If you run into issues with podman build . failing with the error message
io: read/write on closed pipe then you may be running out of disk space - try setting TMPDIR environment variable
Building image on ubuntu#
If you run into issues such as
potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument
Ensure newuidmap is installed
sudo apt-get install uidmap
Add appropriate entries to
/etc/subuidand/etc/subgide.g.
# subuid/subgid file
myuser:10000000:65536
kill any existing podman processes and retry
For further information, see containers/podman#2542
Deploying to kubernetes#
Once the docker image is built, the image can be deployed to kubernetes using the deploy_hyperion_to_k8s.sh script
Production deployment#
Then create and deploy the helm release
./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --beamline=<beamline> --checkout-to-prod hyperion
This will run the deploy_hyperion.py script to deploy the latest hyperion to /dls_sw.
You will be prompted to log into the beamline cluster, then it will create a helm release “hyperion”.
The source folders will be mounted as bind mounts to allow the pod to pick up changes in production.
For production these are expected to be in the normal place defined in values.yaml.
Development deployment#
From a development hyperion workspace, either with a release image or using a development image built with the
script
above, you install a dev deployment to the cluster you are currently logged into with kubectl:
./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --dev --beamline=<beamline> --repository=<your image repo> hyperion-test
The dev deployment bind-mounts the current hyperion workspace and ../dodal into the container so that you can
run against your own development code. Clusters do not allow bind mounts from arbitrary directories so
your workspace will have to be in a permitted directory such as your home directory.
By default the script will log into the argus cluster, if you want to deploy to an alternate cluster,
log in with kubectl set-context --current --namespace=<NAMESPACE> and then specify --no-login when running the
script
Please note, the deployment script is intended to be run from a checked-out matching version of the git repository.
helm list should then show details of the installed release on a successful install