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 }}
Docker Compose best practices for dev and prod
141–150 of 166 posts
Re: Docker Compose best practices for dev and prod
#142Re: Docker Compose best practices for dev and prod
#143I 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.
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
#144Surprised 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.
Re: Docker Compose best practices for dev and prod
#145Re: Docker Compose best practices for dev and prod
#146Earlier 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!
dockerd for windows isn’t even free software, last I looked.
Re: Docker Compose best practices for dev and prod
#147Re: Docker Compose best practices for dev and prod
#148docker 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…
Compose would be awesome.
Re: Docker Compose best practices for dev and prod
#149docker 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.
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
#150One 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…