WIP: Reset app.ini on every init-run to have a clean state
#450
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/helm-chart#450
Reference in New Issue
Block a user
No description provided.
Delete Branch "clean-app-ini"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
fix #356
This conflicts with the logic if "rewrite of secret keys if an app.ini already exists" within the env-to-ini script. Yet I am not sure if this is really needed - I think a clean start would also be better.
OTOH,
env2ini::generate_initial_secrets()states that these secrets "won't harm existing app.ini files".Needs testing!
Settings which need to be preserved as secrets:
server.LFS_JWT_SECREToauth2.JWT_SECRETsecurity.SECRET_KEYsecurity.INTERNAL_TOKENOnce a app.ini is created, certain values must remain the same across the lifetime of that Gitea instance. I see the issue with not cleaning up the app.ini. What we can do is store the one-time generated values in a K8s secret and reuse them while recreate the app.ini completely.
At least, the SECRET can't be reset, otherwise there would be bugs: eg: the 2FA can't be decrypted.
I agree. We need to save all auto-generated settings to k8s secrets first and regenerate
app.iniusing those secrets and the remaining values fromvalues.yaml.For handling K8s Secrets - if we decide to use that approach - the Serviceaccount topic becomes very useful in combination with RBAC.
I've moved the persistent secrets creation before the removal of
app.ini. The new logic nowapp.inidoes not exist (this should ideally only happen on the very first start)app.inito have a clean startapp.iniusingvalues.yamland the initially created secretsI am only a bit worried about race conditions when using multiple replicas: if one pod just removed
app.iniand another arrives at the if condition which checks if there is anapp.ini, it might recreate the secrets. So maybe we need to find a better way to check if we are on the "first" init run...The last commit only moves the function that generates the secrets and makes it's definition conditional. The actual call of the function is still unconditional. This will break due to non-defined function when the app.ini does exists.
I suggest we split the topic of recreating the app.ini into two subsequent PRs to simplify review and testing:
This would eliminate race conditions within replicas.
With such approach we would need a new job resource that generates/extracts/processes the values and generates the K8s secret. This job could later be extended to recreate the app.ini itself.
Well spotted! Missed to move the actual execution.
The question is: how do we define when that "once" is? It probably must be done whenever the secret is missing - regardless of the reason?
I agree that the key could be to do it outside of the init-containers in some side-job to avoid running it multiple times. But this will be complicated if
app.iniis still generated within ini-containers in each replica then.Overall yes, the cleanest and probably only save way to have a single clean init of
app.iniwould be to do it as a "job" outside of the replicas and only let them consume the result.With the above in mind, I am happy to close here and move to a more complex but sophisticated solution. Overall this behavior is not blocking HA in it's current form - but a rewrite should account for HA and avoid introducing race conditions.
Checkout
From your project repository, check out a new branch and test the changes.