Live data from Hacker News

Docker Compose best practices for dev and prod

prod.releasehub.com

141–150 of 166 posts

Re: Docker Compose best practices for dev and prod

#141
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 }}

The compose file is declarative for clarity, so instead of fighting it, do the things you want to do at other levels. Variables? Pass in some env vars. Conditionals? You can specify multiple configuration files so that whatever calls `docker compose up` can deal with the conditionals of deciding which config files to include.

Re: Docker Compose best practices for dev and prod

#142
With the rising popularity of podman and its native support (and preference) of kube pod, it will be interesting to see whether people sticking to compose or moving. I personally use podman-compose and still not convinced to convert the compose file to pod, which podman can facilitate. However with podman-compose I found host network mode is not working for me.

Re: Docker Compose best practices for dev and prod

#143

I recently learned that moving the compose file around and running commands on it with it in different directories puts things into a bad state. This is because it apparently tags images and containers with context on where the compose file was run from. However, you can negate this by always passing in a custom project name with -p.

That's a feature not a bug and it's one of the things I like :-)

It means that if I run multiple instances of a compose setup, they are completely isolated from each other because they live in separate namespaces. It's a very handy feature (for example, if I'm working on 3 branches of the code, just check them out in 3 different directories etc).

Of course it has the consequence that if you move it around it's going to break things, but that's actually the idea. They should break! Because to compose they are meant to be segregated, and if they interacted it would actually be a bug.

Re: Docker Compose best practices for dev and prod

#144

Surprised it didn't mention profiles, which let you launch only part of your "stack" (think background processing in addition to web app, etc) https://docs.docker.com/compose/profiles/ Prior to that feature, I had a hand-rolled approach using bash scripts and using overrides. Worked well enough, but felt like a dirty dependency.

I just wasted so much duplication effort in a new monorepo by not knowing about this feature - know what my next commit will be I guess!

Re: Docker Compose best practices for dev and prod

#146

Earlier quoted context omitted.

No definitely not. In fact to this day containers only run on Linux. Your Mac or PC just runs a Linux VM in order to be able to run any containers. Containers are not meant to make anything OS-agnostic. Containers are just a way of running Linux

Not quite true: Windows containers run natively on Windows. As of Windows 11, even Server 2022 containers can run using process isolation. Something hilarious to me is that "multi-arch" images are a thing, and can result in the same dockerfile building a Windows image on a Windows PC, and a Linux image on a Linux PC!

This is a red herring and this feature only exists as a Microsoft platform strategy. I don’t know of anyone real using Windows executable docker containers on Windows hosts.

dockerd for windows isn’t even free software, last I looked.

Re: Docker Compose best practices for dev and prod

#147
post #98

Earlier quoted context omitted.

ok, how do you backup your database volumes? when db is running.

same as if the database binary is running in the host? no difference with the db binary running in a container.

Looks like you never run docker compose in prod.

Re: Docker Compose best practices for dev and prod

#148

docker compose was one of the most spectacular and developer friendly deployment tool i have used. unfortunately the ecosystem is on kubernetes. you want to integrate with spot instance bidding on AWS...u need kubernetes. you want monitoring tools...u need kubernetes, etc the Compose spec is now open and standardised - https://www.compose-spec.io/ a kubernetes distro that can be managed entirely using compose files w…

When you say 'a kubernetes distro that can be managed entirely using compose files will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....' Do you mean from the your perspective, you set up your docker-compose and this startup ends up deploying pods into Kubernetes based on your compose file? Basically cutting out the middleman of you having to deal with Kubernetes ya…

yes. basically. and this is a path that multiple people are trying to solve. e.g. AWS CDK8s, https://tanka.dev/, etc

Compose would be awesome.

Re: Docker Compose best practices for dev and prod

#149
post #134

docker compose was one of the most spectacular and developer friendly deployment tool i have used. unfortunately the ecosystem is on kubernetes. you want to integrate with spot instance bidding on AWS...u need kubernetes. you want monitoring tools...u need kubernetes, etc the Compose spec is now open and standardised - https://www.compose-spec.io/ a kubernetes distro that can be managed entirely using compose files w…

Perhaps I'm missing something but you can throw containers at Fargate Spot on AWS and it works just fine.

sure. and it works great.

Docker Compose is also unnecessary for that. I'm talking to the demographic of users who want to run Compose/K8s/Rancher by themselves. For most people, i dont recommend it - you should use Fargate.

Re: Docker Compose best practices for dev and prod

#150

One topic I'd like to see more discussion around is how best to set up staging environments for Docker Compose projects. Ever since the V2 migration, I've been banging my head against multiple bugs in Docker Compose itself, which has severely damaged my trust in it as a production-ready utility. I no longer feel like I can safely update Compose without running extensive testing on each release. For example, my journe…

[deleted]
Post reply on HN