Automating Hyrax Container and Helm Chart Publishing

Date: 12/02/2021

Time: 14:00 PST/17:00 EST

Zoom URL: Join our Cloud HD Video Meeting

Attendees

• @tamsin johnson (UC Santa Barbara)

• @Alexandra Dunn (UC Santa Barbara)

• @James Griffin (Princeton University Library)

Notes

• Hyrax Containers

  • What is Docker?

• Kubernetes (k8s)

  • Many Containers, there is a need to configure these into a set of services which can interface/communicate

  • Typically, the architecture is oriented towards running one (or a limited number of processes) per container

    • Hence, a Rails application runs in one container, a key/value store in another container, Solr in another container…

  • This is similar to Docker Compose, but at a much larger scale, with an extensive API for clients to query or update

    • API provides users to declare and set the state of the entire system of Containers

• Helm Charts for Hyrax

  • Helm | Charts

    • Package manager for k8s

      • Essentially, k8s will take a set of YAML files to define the state of the cluster of the containers

      • As such, Helm provides a templating language/domain-specific language (with variables) for describing the state of the container cluster

        • The actual application code within the container, then, can be set

        • (e. g. setting the version of Solr, or certain customizations, etc.)

        • A repeatable pattern for deploying many Hyrax applications

• Container Registries

  • Open Container Initiative (OCI) artifact registry

    • Artifacts can be container images, but also, other binaries (e. g. software binaries)

    • Providing authentication is supported

      • UCSB and UCSD have had experience sharing a registry

    • Helm charts permit one to define the images deployed, the ports exposed, and the network topology (to some extent)

    • k8s itself manages the pulling of the container images and manages the resources used to provision the container

      • Hence, k8s needs to be able to access the credentials required to query and pull the container registry

    • Registry can serve as a repository for other artifacts, including Helm Charts

      • This is experimentally supported at the moment

      • With a generalized registry, there can also be Ruby Gems, etc.

      • GitHub is taking this approach

  • GitHub Packages

    • Working with the Container registry - GitHub Docs

    • Question: Credentials need to be provided to CircleCI in order to explore pushing to the Container registry

      • With an auth. token present, one needs to be mindful of there needs to be some QA involved if pushing the image is in direct response to merging to main

      • It is definitely not sustainable to have it remain a burden on one person

      • Additionally, having a small group isn’t the ideal approach, given the human coordination involved

    • Alternative approach

      • Perhaps another system can be used?

      • For example, if there were a cronjob running on a server, where a k8s server had credentials would check synchronously to determine if there were any updates to the Helm Chart

      • For Samvera, this would be a daily or hourly check

      • One example:

        • https://circleci.com/docs/2.0/workflows/#nightly-example

• Action Items for Hyrax

  • Using nightly with a datestamp (by following the CircleCI approach) would still provide some automation

  • CircleCI can also then trigger updates for Helm Charts on a git tag rather than a merge or pull request

  • James can test being granted the permissions to publish the Helm Charts and Docker images

• Next Steps

  • Even with just the image push in CircleCI, this would be very helpful

    • Run Docker commands - CircleCI

  • Just getting this configured so that this can run within Circle is something James can address

    • @James Griffin can provide a pull request with some feedback regarding any difficulties

Meeting adjourned at 14:52 PST/17:52 EST