Repository navigation
feat(swarm): convert file bind mounts to swarm configs - #325
Draft
dargmuesli wants to merge 2 commits into
Draft
dargmuesli wants to merge 2 commits into
dargmuesli wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.yamlmoves 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-prodconfig 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 lson the manager should show the nine new config objects (the development-only jobber name stays in the dev swarm).