Skip to content

feat(swarm): convert file bind mounts to swarm configs - #325

Draft
dargmuesli wants to merge 2 commits into
mainfrom
feat/swarm/configs
Draft

dargmuesli wants to merge 2 commits into
mainfrom
feat/swarm/configs

Conversation

@dargmuesli

Copy link
Copy Markdown
Member

Converts the configurations/ bind mounts of adminer, debezium-postgres-connector, jobber, prometheus, redpanda-console and all six zammad services to Docker swarm configs with byte-identical content. A bind mount of a file resolves to an absolute path on the node the stack was deployed from, and on any other node Docker silently creates an empty directory in its place, so the service starts misconfigured instead of failing. This removes that invisible pin, which is the prerequisite for moving the helpdesk group to the second node.

Each mount becomes a config at the same container path. The sentry sink scripts and the zammad docker-entrypoint are executed as programs and keep the execute bit (mode 0555); everything else is read-only (0444). The jobber sinks directory becomes three individual configs, one per script.

Config names follow the content hash suffix convention from dargstack 4.21.0: the name carries the first 8 hex characters of the SHA-256 of the file, so a content change produces a new config object instead of failing the deploy with "only updates to Labels are allowed", and the deploy prunes the orphaned object afterwards. The compatibility floor in dargstack.yaml moves to 4.21.0 for that reason.

Jobber is the one service whose config content intentionally differs between environments: development notifies by system email, production posts to the sentry sinks and activates the venv. A single name can only carry one content hash, so the production delta declares its own jobber-prod config and prunes the development one from the production merge with spruce; the two names rotate independently per environment.

Existing tasks keep running on deploy; the eleven affected services roll once because their specs change from a bind mount to a config, and from that point on they carry no node-local file dependency. After deploy, sudo docker config ls on the manager should show the nine new config objects (the development-only jobber name stays in the dev swarm).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant