fix(filebrowser): run the file manager inside the pod of the agent on 2.0.0 #398
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/filebrowser-v2"
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?
What was wrong
Two things at once, one of them the reason the other had to be done here rather than in place.
2.0.0-stableimage since the Renovate major bump, and the application refuses the configuration of 1.x:What this fixes
kubernetes/apps/grachevko/filebrowser/app/configmap.yaml— the configuration in the shape of 2.0.0:http.portand the singlehttp.trustProxyHeadersin place of the trusted-headers list;server.databaseon SQLite withmigrateFrom;server.sources[].config.defaultPermissionsin place of the account permissions (withview, a right of its own in 2.0.0);userDefaults.account.permissionsnarrowed to what stays global. What changed is where each of our settings lives, not what it is: the port stays 8080 with no capability to bind a privileged port, the login stays pocket-id only, the session stays 24 hours, the source stays the whole volume of the agent.kubernetes/apps/grachevko/hermes/app/helmrelease.yaml— the file manager becomes a container of the agent's pod (its image, limits, probes and login read from the ConfigMap and the Secret of the filebrowser directory), and an init container renames the BoltDB file of 1.x once (database.db→database.db.old, with a copy outside the working directory on the claim of the agent), which is what the import of 2.0.0 waits for. The volumes of the file manager are mounted for its own containers (advancedMounts), the claim of the agent only as before. Its Service ishermes-filebrowser, as app-template names one after the release and the key of the service map.kubernetes/apps/grachevko/hermes/app/filebrowser-httproute.yaml— the route ofhermes-files.<domain>moves here from the filebrowser directory, itsbackendRefnaming that Service.kubernetes/apps/grachevko/filebrowser/— the HelmRelease, its kustomization and the Kustomization of the application are gone; the directory keeps what the pod of the agent reads: the configuration from git, the claim of the file manager itself and its own pocket-id login (config/,secrets/). The claim keeps theprune: disabledannotation, so nothing about this change can take the data with it.kubernetes/apps/grachevko/hermes/ks.yaml— the Kustomization of the agent depends on those three, so the file, the claim and the client exist before the container is created.What it costs: the readiness of the file manager is now the readiness of the pod, so a broken file manager takes the agent's own routes out of their Services. The memory of the node is not part of the price — the limit is the container's own, and the pod keeps the quality-of-service class it had (its requests are below its limit either way).
Verified
flate test all -p ./kubernetes/flux/cluster— 307 passed;flate build hr hermes -n grachevkorenders the pod withappandfilebrowser, the two init containers,/etc/filebrowserand/home/filebrowser/datamounted for the file manager's containers only, and the Servicehermes-filebrowseron port 8080;flate build ks filebrowser -n grachevkorenders the ConfigMap and the claim.http.port,http.trustProxyHeaders,server.database.path|migrateFrom,server.cacheDir,server.sources[].config.defaultEnabled|defaultPermissions,auth.tokenExpirationHours(the field isAuth.TokenExpirationHours, tagtokenExpirationHours, inbackend/pkg/settings/auth.go),auth.methods.password|oidc,userDefaults.account.permissions(backend/pkg/settings/validConfig.yaml). The file parses toserver.database.pathandserver.sources[0].config.defaultPermissions, and no key of 1.x is left in it.files, nothttp: the namehttpin this pod belongs to the agent's own port, and port names are unique within a pod.After the merge
filebrowsercontainer showsStarting migration from BoltDB to SQLite…Migration completed successfully!, and the UI must show the users, the shares, the API tokens and the index.migrateFromcan be dropped from the ConfigMap (phase 3 of the upstream guide), and both copies of the database —database.db.oldon the claim of the file manager and.filebrowser-database.db.backupon the volume of the agent — can be deleted.hermes-files.<domain>keeps answering through the same route; its backend is now thehermes-filebrowserService of the agent's release, and the oldfilebrowserService disappears with the old release.Rollback
git revertof the merge commit restores the second pod and the configuration of 1.x, which the 2.0.0 image refuses: the way back to a working file manager is the1.5.8-stableimage with the reverted configuration, plusdatabase.db.oldrenamed back todatabase.db. The volumes are untouched by the migration itself.Failed to update PR description
Rendered diff of the HelmReleases in this pull request:
PR Reviewer Guide 🔍
Here are some key observations to aid the review process:
PR Code Suggestions ✨
No code suggestions found for the PR.
fix(filebrowser): migrate the configuration and the database to 2.0.0to fix(filebrowser): run the file manager inside the pod of the agent on 2.0.0The review of the first commit found a real defect: rewriting the Kustomization of the filebrowser directory dropped its postBuild, while the issuer of the login inside the mounted config.yaml still carries ${SECRET_DOMAIN} - the placeholder would reach the API server and the operator as a literal, and the OIDC login of the file manager would break. The substitution is back, on that Kustomization, with the reason spelled out. The second finding of the same review - `cacheDir` read as a child of `server.database` - does not reproduce: the config parses to server keys [database, cacheDir, sources], and `cacheDir` is a direct child of `server`, which is where 2.0.0 keeps it (`backend/pkg/settings/validConfig.yaml`). No edit follows from it. On the same line, the two state paths become absolute: the working directory of the image is not a contract, and a relative path would land the database outside the claim that exists for it.