You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
zitadel currently uses hooks to wait for a database to be ready, but database will not deploy because zitadel is using hooks, creating a chicken/egg scenario when using helm dependencies.
Either the application itself could watch for the ready status of dependencies, or initContainers could be used to wait for ready status.
Example use case:
I use an initContainer with sealed-secrets because I use external-secrets to provide a "common" secret shared among clusters, external-secrets provides the secret but I need sealed-secrets to wait to start until after the secret is created, because sealed-secrets will not notice the secret if its created after the pod is started.
Version
latest
Environment
Self-hosted
Additional Context
No response
The text was updated successfully, but these errors were encountered:
When learning kubeapi, it can be useful to pass --v=8 to any kubectl command, this let's you see what the full url was used to perform the action. e.g. k get pods --v=8
Here's an example to wait for a secret, maybe you could use something similar:
(for this to work you have to grant the default service account the necessary RBAC to get/list secrets)
initContainers:
- name: wait-for-secret
image: alpine/curl
imagePullPolicy: Always
command: ['sh', '-c']
args:
- |
# Point to the internal API server hostname
APISERVER=https://kubernetes.default.svc
# Path to ServiceAccount token
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
# Read this Pod's namespace
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
# Read the ServiceAccount bearer token
TOKEN=$(cat ${SERVICEACCOUNT}/token)
# Reference the internal certificate authority (CA)
CACERT=${SERVICEACCOUNT}/ca.crt
# Explore the API with TOKEN
while [ 200 -ne $(curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" \
-X GET ${APISERVER}/api/v1/namespaces/sealed-secrets/secrets/sealed-secrets-shared-key \
--head \
--silent \
--output /dev/null \
--write-out '%{http_code}') ]
do
echo "waiting for secret: sealed-secrets-shared-key"
sleep 5
done
echo "waiting for secret: sealed-secrets-shared-key"
echo " detected"
Preflight Checklist
Describe your problem
Per discussion:
#270 (reply in thread)
Summary:
zitadel currently uses hooks to wait for a database to be ready, but database will not deploy because zitadel is using hooks, creating a chicken/egg scenario when using helm dependencies.
e.g. Chart.yaml:
Describe your ideal solution
Either the application itself could watch for the ready status of dependencies, or initContainers could be used to wait for ready status.
Example use case:
I use an initContainer with sealed-secrets because I use external-secrets to provide a "common" secret shared among clusters, external-secrets provides the secret but I need sealed-secrets to wait to start until after the secret is created, because sealed-secrets will not notice the secret if its created after the pod is started.
Version
latest
Environment
Self-hosted
Additional Context
No response
The text was updated successfully, but these errors were encountered: