Destination aware container names #71
Merged
+81
−25
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.
I started looking into having role aware container names but that turned out to be quite a big undertaking. So I started with destinations instead to see where it could head.
This PR is a start to have destination aware container names so different destinations of the same service can run on the same server.
This doesn't work right now:
… as both docker containers would have the same name
app-<version>
on 1.1.1.1. The PR adds - if present - the destination as part of the container name, ending up asapp-staging-<version>
andapp-demo-<version>
.Mrsk::Commands::App
andMrsk::Commands::Healthcheck
should be the only commands that are affected. Accessories might be a candidate, but not sure.Also,
Mrsk::Commands::Healthcheck
isn't really affected as the fix port3999
shouldn't allow parallel deployment of different mrsk apps either way, but it doesn't hurt to have the container name be ready for that in the future.@dhh: Is this the way we want to pursue with destinations?