Live data from Hacker News

Docker Compose best practices for dev and prod

prod.releasehub.com

21–30 of 166 posts

Re: Docker Compose best practices for dev and prod

#21
I find docker compose override files whilst powerful ultimately much more confusing and error prone to work with. Instead I would recommend just duplicating your compose files and changing each separately, perhaps using a templating engine. It is often much easier to work with a single compose file containing all the config in one easy to read block. This compared to having to do a yaml merge of all the various blocks in your head whilst reasoning about override files.

Similarly yaml anchors are cool and can easily reduce duplication in your files. However I've found the majority of Devs and users find them confusing and unexpected in a compose file. As a result I would recommend not using them and just sticking with plain yaml for simplicity's sake and not being afraid of duplication.

One other alternative to yaml anchors is instead using the env_file: property on your services (https://docs.docker.com/compose/environment-variables/#the-e...) . This way you can place all of your env variables in a single file and share this same of env variables between many services without having to have large duplicate env blocks in your compose file.

Re: Docker Compose best practices for dev and prod

#22
I think the YAML anchors section would lead to an unparseable compose file?

No `services` block above the `api` and `web` services, on the same level as `x-app:`.

So the `(I've not tested as currently on the windows gaming box. this is purely from reading it, so happy to be corrected).

Re: Docker Compose best practices for dev and prod

#23
post #9

Earlier quoted context omitted.

Your problem is that you can't set ENV variables at the global level? Have you looked at YAML anchors? Makes things more DRY for longer/complex compose files.

That's just the tip of the iceberg. My problem is that YAML is not a turing complete language (and dev environments are usually messy by their nature).

Given that YAML it's a configuration language I'd say that not being turing complete it's a feature, not a bug nor a limitation; I always want my language files to be declarative to not suffer the perils of logic.

Edit: Also, I don't see the need for a turing complete language for something like docker compose, if you need something really complex you can always script a docker-compose.yml generator with all the logic and complexity you need.

Re: Docker Compose best practices for dev and prod

#24

Docker is cool and all. Kids these days don’t know anything about Tmux and port 433. Exposing localhost to the internet and getting your internet monitored by your ISP and getting letters in the mail; for hosting movies and Storage services. Lol.

Love your comment! Come work for me!

Love your compliment and belief in other people. Come work for me.

Re: Docker Compose best practices for dev and prod

#28
post #17
post #13

Earlier quoted context omitted.

You can accomplish the same thing using environment variables. You can pass them in at build time or deploy time. `ENVIRONMENT=dev docker-compose up` or `docker-compose build --build-arg ENVIRONMENT=dev` and in your case maybe you write some function `find_answer() { something-async ... }; ENVIRONMENT=$(find_answer) docker-compose ...` You can also read in .env files... Which in my opinion is cleaner since you can ch…

It's a simple example, maybe too simple to get the point. What I want is to conditionally set things on a yaml file. If you have ever used a templating language, you know this problem services: redis: ... {{ if some_condition }} volumes: bla bla {{ end if }} {{ if some_other_condition }} another_service: ... {{ end if }} volumes: {{ for volume in volumes }} - ... {{ end for }}

Podman allows for Kubernetes templates, so theoretically you could use Helm for this potentially.. otherwise, Minikube on Podman. I wish they had Go templating in the compose files though, that would be rad.

Re: Docker Compose best practices for dev and prod

#29

Is there a "proper" way to have per host configs? I have a setup where I need to set "hostname: " depending on the system I'm on and right now I'm having to resort to using "docker compose -f compose. .yml up -d" where compose. .yml extends compose.yml

Is there a reason why you wouldn't be able to use environment variables for this? Or am I misunderstanding your issue?

Re: Docker Compose best practices for dev and prod

#30
If you don't use the same Docker Compose file for Production, don't use it for Development. Your two different systems will diverge in behavior, leading you to troubleshoot two separate sets of problems, and testing being unreliable, defeating the whole "it just runs everywhere" premise.

Docker Compose is fine for running smoke tests/unit tests, but if Dev and Prod run differently, there's really no point to using Docker Compose other than developing without internet access.

(It goes without saying that Docker Compose only works on a single host, so that won't work for Prod if you need more than one host, but single-host-everything seems to be HN's current fetish)

Post reply on HN