feat(cryostat): deploy cryostat 3.0 #111
Conversation
charts/cryostat/README.md
Outdated
| | `Configuration` | for Cryostat's object storage provider | | | ||
| | `storage.image.repository` | Repository for the storage container image | `quay.io/cryostat/cryostat-storage` | | ||
| | `storage.image.pullPolicy` | Image pull policy for the storage container image | `Always` | | ||
| | `storage.image.tag` | Tag for the storage container image | `2023-12-19` | |
There was a problem hiding this comment.
I think the README/schema need to be regenerated after changing the default to latest.
| {{- end }} | ||
| - name: CRYOSTAT_JMX_CREDENTIALS_DB_PASSWORD | ||
| - name: QUARKUS_S3_AWS_REGION | ||
| value: us-east-1 |
There was a problem hiding this comment.
Is this just a dummy value for now? Does it do something with SeaweedFS?
There was a problem hiding this comment.
It doesn't actually do anything when using SeaweedFS, or probably when using any other "self-hosted" kind of S3 provider, but the SDK client wants this variable to be set to something - presumably because the actual AWS S3 requires it.
There was a problem hiding this comment.
https://docs.quarkiverse.io/quarkus-amazon-services/dev/amazon-s3.html#_configuring_s3_clients
quarkus.s3.aws.region - It’s required by the client, but since you’re using a local S3 instance you can pick any valid AWS region.
There was a problem hiding this comment.
It would also be possible to hardcode a default value for this property in https://github.com/cryostatio/cryostat3/blob/main/src/main/resources/application.properties , so that end users can still override it if necessary but have a fallback if they don't, but I'm not sure if that's worthwhile. In the end if the user is going to choose some other S3 provider than the one we ship, they'll have to change all these related configuration knobs anyway.
| - name: QUARKUS_S3_AWS_CREDENTIALS_STATIC_PROVIDER_ACCESS_KEY_ID | ||
| value: cryostat | ||
| - name: AWS_ACCESS_KEY_ID | ||
| value: cryostat | ||
| - name: QUARKUS_S3_AWS_CREDENTIALS_STATIC_PROVIDER_SECRET_ACCESS_KEY | ||
| valueFrom: | ||
| secretKeyRef: | ||
| name: {{ default (printf "%s-jmx-credentials-db" .Release.Name) .Values.core.databaseSecretName }} | ||
| key: CRYOSTAT_JMX_CREDENTIALS_DB_PASSWORD | ||
| name: {{ printf "%s-storage-secret-key" .Release.Name }} | ||
| key: SECRET_KEY | ||
| optional: false | ||
| - name: CRYOSTAT_AUTH_MANAGER | ||
| {{- if (.Values.authentication).basicAuth.enabled }} | ||
| value: io.cryostat.net.BasicAuthManager | ||
| {{- else }} | ||
| value: io.cryostat.net.NoopAuthManager | ||
| - name: AWS_SECRET_ACCESS_KEY | ||
| valueFrom: | ||
| secretKeyRef: | ||
| name: {{ printf "%s-storage-secret-key" .Release.Name }} | ||
| key: SECRET_KEY | ||
| optional: false |
There was a problem hiding this comment.
For my own info, why are there two pairs of these environment variables? (e.g. QUARKUS_S3_AWS_CREDENTIALS_STATIC_PROVIDER_SECRET_ACCESS_KEY and AWS_SECRET_ACCESS_KEY).
There was a problem hiding this comment.
I need to double-check that myself, actually. I think the QUARKUS_ one is what is actually needed on the Cryostat side, and the AWS_ one was needed for Minio previously? Or perhaps the SDK client does actually need both, for some reason.
There was a problem hiding this comment.
I think this was probably just a configuration hold-over:
If using the env-variable credentials type then the AWS_SECRET_ACCESS_KEY would be checked. Since in any case this configuration is going to expose the credentials to the container via environment variables, just using static with the QUARKUS_-prefixed pair is simpler.
There was a problem hiding this comment.
Looks like this was actually used for something after all: #120
Related to #110
Fixes #113
Depends on cryostatio/cryostat#209
Depends on cryostatio/cryostat-storage#1
This is a very rough first pass at getting Cryostat 3.0.0-snapshot deployed. A cryostat-db instance and cryostat-storage instance are deployed alongside the Cryostat container as part of the same Pod.
These things are still TODO and I intend to tackle them as follow-up PRs either into this same feature branch, or into the upstream base branch I'm targeting:
figure out minio root user config issue. Works on OpenShift (partially solved in latest changes and with https://github.com/cryostatio/cryostat-storage . Probably needs more robust checks and will affect permissions for mounted volumes for the next point down:crc), complains onkind:Error: container has runAsNonRoot and image will run as root (pod: "cryostat-74cd7858bc-sgj5d_default(7e38eae9-9189-441c-816c-4bd4db57f219)", container: cryostat-s3)htpasswdproviding Basic auth using the existing configuration options [Task] Deploy oauth2-proxy in front of Cryostat, storage, db, jfr-datasource, and Grafana #114 [Task] Reimplement Basic auth via oauth2-proxy htpasswd config #116