Hello, I’m experiencing some weirdness rendering t...
# ory-selfhosting
b
Hello, I’m experiencing some weirdness rendering the Kratos helm chart. using the following in
values.yaml
the chart doesnt render as expected:
Copy code
kratos:
  config:
    courier:
      smtp:
        connection_uri: "<smtps://test:test@mailslurper:1025/?skip_ssl_verify=true>"
        foo: bar
the resulting configmap is this:
Copy code
# Source: kratos/templates/configmap-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-kratos-config
  namespace: default
  labels:
    <http://app.kubernetes.io/name|app.kubernetes.io/name>: kratos
    <http://helm.sh/chart|helm.sh/chart>: kratos-0.26.3
    <http://app.kubernetes.io/instance|app.kubernetes.io/instance>: release-name
    <http://app.kubernetes.io/version|app.kubernetes.io/version>: "v0.10.1"
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
  annotations:
data:
  # Render the kratos config:
  "kratos.yaml": |
    courier:
      smtp:
        foo: bar
...
It seems the random
foo
value was added, but the necessary smtp.connection_uri was not. any idea what might be happening?
w
Hi there! this is done on purpose 🙂 The uri is considered by us a secret and therefore it is contained here https://github.com/ory/k8s/blob/master/helm/charts/kratos/templates/secrets.yaml#L21 while it is being pruned from the configmap. Both secret and cm are mounted within the deployment tho
👍 1
b
I see. that makes sense. I must have overlooked that detail in the documentation. if that is the case, should I expect it to be here alongside other values?
Copy code
apiVersion: v1
data:
  dsn: ....
  secretsCipher: ...
  secretsCookie: ...
  secretsDefault: ...
kind: Secret
metadata:
  ...
type: Opaque
It does not seem to be present and in fact my kratos pod is not starting:
Copy code
kubectl logs -n kratos local-kratos-6786d7456d-n7dgf 

The configuration contains values or keys which are invalid:
The configuration contains values or keys which are invalid:
identity.schemas: <nil>
                  ^-- one or more required properties are missing

The configuration contains values or keys which are invalid:
courier.smtp.connection_uri: <nil>
                             ^-- one or more required properties are missing

The configuration contains values or keys which are invalid:
selfservice.default_browser_return_url: <nil>
                                        ^-- one or more required properties are missing

time=2022-12-17T18:39:23Z level=fatal msg=Unable to instantiate configuration. audience=application error=map[message:I[#] S[#] validation failed
  I[#/identity] S[#/properties/identity/required] missing properties: "schemas"
  I[#/courier/smtp] S[#/properties/courier/properties/smtp/required] missing properties: "connection_uri"
  I[#/selfservice] S[#/properties/selfservice/required] missing properties: "default_browser_return_url"] service_name=Ory Kratos service_version=v0.10.1
I can’t for the life of me figure out why my
values.yaml
isnt rendering correctly and have been trying every which way to get it to work
Hi @worried-kitchen-94392 do you mind giving me a hand with this? Been banging my head against the wall for quite some time and am not sure if I am just doing something silly or neglected something obvious. Maybe there have been others with the same problem? I found this issue, but its the closest I have found to anything similar: https://github.com/ory/k8s/issues/449 Thanks again!
w
You can try comparing your values to this https://github.com/ory/k8s/blob/master/hacks/values/kratos.yaml
this is the config we use for our CI, so it has to work 😉 If you have problems like fields not lining up or fields missing that would be the easiest way to see that
installing the sample from our k8s repo with
Copy code
helm install kratos ./helm/charts/kratos -f hacks/values/kratos.yaml --debug --atomic
works and produces a secret with the sample values
Copy code
apiVersion: v1
data:
  dsn: cG9zdGdyZXM6Ly9wb3N0Z3JlczpvcnlAcG9zdGdyZXNxbC5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsL29yeV9rcmF0b3M/c3NsbW9kZT1kaXNhYmxlJm1heF9jb25uX2xpZmV0aW1lPTEwcw==
  secretsCipher: UFJpVkQzQVlCUFhYMW1tZzJUdnhFbElFM1JVeGpxb0Y=
  secretsCookie: UkJUR0RFU0lSeTAyeWlGMW5JdXlpOTFzd0hmdVlKZ0E=
  secretsDefault: IlBMRUFTRS1DSEFOR0UtTUUtSS1BTS1WRVJZLUlOU0VDVVJFIiwiT0c1WGJteFhhM2RZZUdwbFFYcFFhbll4ZUVGdVJVRmEiLCJmb28gYmFyIDEyMyA0NTYgbG9yZW0iLCJmb28gYmFyIDEyMyA0NTYgbG9yZW0gMSIsImZvbyBiYXIgMTIzIDQ1NiBsb3JlbSAyIiwiZm9vIGJhciAxMjMgNDU2IGxvcmVtIDMi
  smtpConnectionURI: c210cHM6Ly90ZXN0OnRlc3RAbWFpbHNsdXJwZXI6MTAyNS8/c2tpcF9zc2xfdmVyaWZ5PXRydWU=
kind: Secret
metadata:
  annotations:
    <http://helm.sh/hook|helm.sh/hook>: pre-install, pre-upgrade
    <http://helm.sh/hook-delete-policy|helm.sh/hook-delete-policy>: before-hook-creation
    <http://helm.sh/hook-weight|helm.sh/hook-weight>: "0"
    <http://helm.sh/resource-policy|helm.sh/resource-policy>: keep
  creationTimestamp: "2022-12-20T07:27:43Z"
  labels:
    <http://app.kubernetes.io/instance|app.kubernetes.io/instance>: kratos
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
    <http://app.kubernetes.io/name|app.kubernetes.io/name>: kratos
    <http://app.kubernetes.io/version|app.kubernetes.io/version>: v0.10.1
    <http://helm.sh/chart|helm.sh/chart>: kratos-0.26.5
    <http://ory.sh/watcher|ory.sh/watcher>: kratos
  name: kratos
  namespace: default
  resourceVersion: "1123"
  uid: e35afa9f-8d32-4bc1-afe8-746c37f11072
type: Opaque
i would recommending comparing your values to this and try installing it for example using the k3d cluster you can get up and running with make from the repo 🙂
feel free to ping me if you need more help. I would need to see your values.yaml and how you install the chart to be able to help more
b
I used that exact values.yaml from your github and it is not working. Deployment to my minikube is performed by Argo CD using Argo CD Autopilot
In terms of my overall deployment strategy, I have a repository containing charts belonging to my live EKS cluster which is also managed by Argo CD. I am currently working out the best way to do local development, but so far what I have come up with is to have a separate personal repo which is bootstrapped using argocd autopilot and referencing charts which are contained in the first repo used by the live cluster’s argo. that way I can use essentially the same config which is used in prod, with Kustomizations allowing it to run locally such as through specifying local db connection details, local SMTP details, etc. currently other apps which are deployed by Argo have no issue, just Kratos
w
wierd 😕 We also used argoCD ourself for deployment and kratos is not complaining. What if you specify to not create the secret but supply it on your own in a sideloaded secret?
b
I could try that, but I wonder why my set up necessitates doing this sort of thing. I was hoping configurations to he as straightforward (mostly) as it seems in the docs/on here. Do you have any idea what I could do to try to figure out why just using the helm chart is not working?
How is that done, anyway? It seems it's not just the smtp connection URI that is not being picked up by config, but really any of the config..