Reading the comments here is giving me a headache. Will nobody admit that this is all a nightmare?
Docker Compose best practices for dev and prod
131–140 of 166 posts
Re: Docker Compose best practices for dev and prod
#132Earlier quoted context omitted.
That's kind of the point if containers, isn't it?
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!
Re: Docker Compose best practices for dev and prod
#133We've found https://tilt.dev/ to actually be a great alternative to docker-compose that also keeps the local setup and knowledge more inline with production (which is Kubernetes hosted)
Running Kubernetes in production, we've also decided to adopt tilt and get rid of Docker compose. Our own tooling with docker compose has been to painful to maintain, and there was too many workaround to try to replicate what we have in production.
Re: Docker Compose best practices for dev and prod
#134docker 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.
Re: Docker Compose best practices for dev and prod
#135Reading the comments here is giving me a headache. Will nobody admit that this is all a nightmare?
If this gives you headaches, don't read anything k8s - you may end up changing profession.
Re: Docker Compose best practices for dev and prod
#136docker compose in prod?? what???
who would do this??
Re: Docker Compose best practices for dev and prod
#137One of the things we've really struggled with is sharing dev compose files between Windows and macOS. We were unable to make bind mounts work correctly with Windows, due to performance issues (this used to be documented in the Docker docs, but I can't seem to locate it now). This resulted in us falling back to VSCode's remote container tooling. Has anyone else had this issue with Windows? The last time I looked into…
If you’re using WSL 2, but your project files are in windows-land and vscode is reading them via the mnt path (like /mnt/c/code/myproject), then you’re going to have show-stopping performance problems.
Re: Docker Compose best practices for dev and prod
#138I like to divide up my compose files into three: 1. A `docker-compose.yaml` for basic configuration common among all environments 2. A `docker-compose.dev.yaml` for configuration overrides specific to development 3. A `docker-compose.prod.yaml` for configuration overrides specific to production Then I have `COMPOSE_FILE=docker-compose.yaml:docker-compose.dev.yaml` in my `.env` file in the root of the project so I can…
In my experience, the "base" configuration should always be in use somewhere. Otherwise you inevitably end up with cruft, when default values turns out to have no practical value. In your example, "dev" should probably be the default configuration, which "prod" overrides. It's a tiny detail but I think it pays over time. A similar situation is when you have lots of almost-identical settings between many (micro)servic…
Sometimes dev and prod go in different directions so it makes more sense to inherit a common file. For example, dev might have a whole bunch of settings for some debug tool whereas prod might have a whole bunch of settings for the email server config.
Re: Docker Compose best practices for dev and prod
#139Surprised 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.
Wohoo! Pretty neat, i have been making multiple docker compose files.
Re: Docker Compose best practices for dev and prod
#140Earlier quoted context omitted.
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 }}
no haha I get the point but it's just another example I see someone over engineering a problem where it should be declarative. In what use case would you dynamically provision some arbitrary n number of volumes without knowing the path names to them? for volumes why wouldn't you just use "volume_name:/some/path" ... "another_volume:/another/path" and let docker manage the volume for you? you're going to end up writin…
[deleted]