Helm charts for Hyrax and FCRepo #4496
Conversation
|
at some point i imagine we'll want a separate charts repo for shared components like fcrepo (and possibly solr helm/charts#22863 (comment)); in that case would we want to move application charts like hyrax as well? how hard would that be? |
👍 for moving the fcrepo out, but I think having the chart for the application live with the code is a very devops way of handling it. That way simple things like "where is this value used" pick up the infrastructure as code along with the application code. |
no-reply
force-pushed
the
cn-helm
branch
2 times, most recently
from
b5a3e29
to
cd3cd76
Compare
|
💯 x 👍 on extracting the i mentioned to @orangewolf that my default mode has become putting everything in the same version control repository (owing to positive experiences with the Surfliner monorepo). having lock-step updates across charts has been important up to this point, but maybe it's already a good time to look at extracting? |
|
@no-reply you know I want to see it separate and published, but I'm wondering if this should go in as is and extract as a next action, just so this work isn't held up at all. |
|
i'm finding that the fedora db setup init container isn't as reliable as i'd hope. sometimes it complains that it might be worth considering whether a smaller container than |
|
Hello! 👋 If you want to extract it, here are some steps to help (we'll be publishing a post on this soon, but in the meantime): prometheus-community/helm-charts#3 (in an example from another migrated helm repo, @torstenwalter has combined those steps with a checklist for all the other steps needed in this nice summary issue: grafana/helm-charts#3). You can see this working demo of Helm GitHub Actions for CI (chart testing), and CD (for releasing chart version packages). The README has detailed steps to emulate them in your own Helm repo: https://github.com/helm/charts-repo-actions-demo Also you'll want to add your helm repo to the CNCF Artifact Hub (the successor to Helm Hub) for discoverability 😄 Hope that helps! |
|
@scottrigby thanks for this input! it's very helpful indeed! |
ports the parts of #4496 that relate to container build. installs UV via rails asset precompile. this makes `.dassie` pass the one test that depends on UV's presence. it's also needed generally for UV in the docker development and test environments.
ports the parts of #4496 that relate to container build. installs UV via rails asset precompile. this makes `.dassie` pass the one test that depends on UV's presence. it's also needed generally for UV in the docker development and test environments.
ports the parts of #4496 that relate to container build. installs UV via rails asset precompile. this makes `.dassie` pass the one test that depends on UV's presence. it's also needed generally for UV in the docker development and test environments.
ports the parts of #4496 that relate to container build. installs UV via rails asset precompile. this makes `.dassie` pass the one test that depends on UV's presence. it's also needed generally for UV in the docker development and test environments.
ran `mkdir chart; cd chart; helm new hyrax` with:
```sh
$ helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}
```
this chart is being developed to allow deployment of the Hyrax application using
containers based on the `hyrax` image (see: `Dockerfile`).
the description text is taken from hyrax.samvera.org.
move this configuration from the `.env` to the container image---it's the container image that this setting is specific to, not the engine or its `docker-compose`.
switch postgresql.enabled to `true` by default and configure the database connection. in the current state, the Hyrax rails app pod hangs waiting for fcrepo to connect; we need a sub-chart for fedora.
we need a sub-chart for fcrepo, we're hoping to extract this to samvera labs before too long, but getting it in here will help us keep it stable. Co-authored-by: @orangewolf
support servicePort configuration for fcrepo Fedora won't let us use port 80 explictly: we either need to use another service port (e.g. 8080, as here), or configure the application to use no port at all. since the second option involves changing application code and configuration, using 8080 seems easier.
adds values.yaml files for two actual hyrax/dassie deployments; makes some small changes to image generation to ensure precompiled assets work correctly in image building and production. bump the chart versions.
| command: | ||
| - sh | ||
| - -c | ||
| - export PGPASSWORD=$DATABASE_PASSWORD PGHOST=$DATABASE_HOST PGUSER=$DATABASE_USER |
There was a problem hiding this comment.
can these be set in an environment block below?
There was a problem hiding this comment.
probably. i'm going to suggest we merge and tweak from there.
this is now deploying successfully and i'm keen on being able to work both on improving the chart and on getting some fashion of CD in place. nurax's current issues are worrisome since only a few people can work on its infra.
http://dassie.dld.library.ucsb.edu is deployed from this chart.
This Helm chart provides configurable deployments for Hyrax applications
to Kubernetes clusters. It seeks to be a complete but flexible
production-ready setup for Hyrax applications. By default it deploys:
A base Hyrax deployment
Because Hyrax is a Rails Engine---not a stand-alone application---
deploying it requires us to have a specific application. This chart assumes that
the user has a container image based on
samveralabs/hyrax(see:CONTAINERS.md) that includes their application. Point the chart at
your image by setting the
image.repositoryandimage.tagvalues.By default, the chart deploys [images][dassie-images] for Hyrax's development
application,
dassie.For application configuration, we take our queues from [12-factor][twelve]
methodology. Applications using environment variables to manage their
configuration can be easily reconfigured across different releases using this
chart; e.g. the same chart can be used to deploy sandbox, staging, and
production environments.
The chart populates the following environment variables:
|-------------------|--------------------------------|------------------------|
postgresql.enabledpostgresql.enabledmemcached.enabledredis.enabledfcrepo.enabledfcrepo.enabledfcrepo.enabledsolr.enabledsolr.enabledsolr.enabledFor DevOps:
For those interested in trying out or contributing to this Chart, it's helpful
to setup a simple cluster locally. Various projects exist to make this easy; we
recommend
k3dor minikube.For example, with
k3d:@samvera/hyrax-code-reviewers