We don't want to use the Alpine image here?

We could also use the alpine version of the node Docker image.

Sorry guys, just realized I had custom notifications for CfA repos to goto my CfA email which I really only check weekly. 😨

Short answer is we don't care as much about tiny single-instance images as we do about ease of use, and with alpine not using glibc or apt-get it'll make it trickier and a higher learning curve for new people. For example: I was getting build failures on npm install in alpine due to bugs unique to alpines c complier. Using default node skips all those issues.

Really? What kinds of issues?

Most common is npm module build failures that require c compiler with some issue related to their lack of glibc. Things are getting better all the time, but doesn't mean we need to be bleeding edge in this area for little benefit

I really don't like the idea of multiple Docker Compose files, it makes the original intent of just using docker-compose up a bit more difficult when differentiating between environments.

Although I heard from a previous co-worker that at your talk, you mentioned Docker Compose eventually going away and/or only used as a development tool? Is that because of the improvements in Swarm?

You're correct that Docker Compose is only intended for local development. It's preferred to use Docker Swarm instead in production.

Well, what about this then?

Ask @BretFisher

I'm not sure what we're talking about here.

the goal of a single docker-compose up is a local-dev-only goal. CI/CD will do all the extra things we'd need for testing and production deploy.

docker-compose cli is for dev and testing only. It doesn't understand multi-server clusters like Swarm

docker-compose.yml file is for dev, test, and prod docker Swarm. (using docker stack deploy in swarm)

We'll likely use override files with docker-compose config for production deploy, but not sure yet until we get everything needed into compose file and see what the dev-vs-prod differences are. We can't use extends, but overrides work great.

Does that help?

put another way:

The process I typically go through is making local dev as easy as possible because it's hand-typed commands by humans.

Ideally the dev should be able to install Docker, then:

git clone xxxxx
docker-compose up

Then get to work ;)

CI/CD will be automated so it can have more complex commands that combine compose files with docker-compose config and dealing with secrets, env vars, etc.

So, how is that the case (Compose is for local dev only) when they have explicit production environment support on the roadmap?

Not to mention, how would you do the same thing with Compose does (orchestrating lots of containers with a single configuration file) using Swarm only? Would that mean you'd have to translate the Compose config into a bash script or some sort of configuration management platform like Chef or Ansible to get this set up in production?

If that's the case, then why use Compose at all?

EDIT: I just saw docker stack deploy, so does that mean we'd use this Compose config to create a DAB, then deploy the DAB to a Swarm cluster? That would answer pretty much all my questions.

I think you're getting it. docker-compose cli and docker-compose.yml file have different scopes and purposes. The yaml file is used in dev+test+prod (everywhere). It is used by both docker-compose cli for dev/test and docker cli for prod swarm. Different parts of that file work in different scenarios.

No DAB needed in swarm, DAB is legacy and you can use compose file directly.

Local dev:

docker-compose up
That uses docker-compose.yml to start all the containers with proper settings and build stuff. build: objects under each service in compose file are used by docker-compose cli only and ignored by docker stack commands. See docs on build: in yaml

Docker Swarm Prod:

docker stack deploy -c docker-compose.yml mystackname
Will deploy all the containers with proper deploy settings like how many replicas of each container to run, healthchecks, how to update the service, etc. See deploy: docs

Also @rydente that readme for compose you referenced predates any of the modern features like Docker Swarm, and needs to be clarified. I recommend ignoring it. Eventually, the docker-compose cli is expected to go away, as its features are implemented in the docker cli, not become more important as that readme suggests.

Oh sweet, I didn't know they did away with DABs, awesome! Thanks for the info, Bret!

Re: that readme, thank you. I think someone should make a PR/issue... 🤔

HMMMMM

But how would the CLI go away? Do they plan on using a single Docker engine to make that happen, but still use the file format for the orchestration?

👍