Automating Hyrax Container and Helm Chart Publishing

Owned by James Griffin
Last updated: Dec 03, 2021
3 min read

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

  • 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:

  • 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

    • 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