Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Compose best practices for dev and prod

prod.releasehub.com

Post reply on HN
Print view View original

101–110 of 166 posts

Re: Docker Compose best practices for dev and prod

#101

Post by lazide »

switchbak wrote: post #40
CincinnatiMan wrote: post #15

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.

There's something about that decision that violates my mental model. Feels similar to a referential transparency issue: the state of the system should be the same regardless of the name of the directory something lives in.

Docker has tons of smells/irritations like this. Overall, it is worth it, but damn is it weird sometimes.

Re: Docker Compose best practices for dev and prod

#102

Post by lazide »

Gordonjcp wrote: post #65
switchbak wrote: post #40

Earlier quoted context omitted.

There's something about that decision that violates my mental model. Feels similar to a referential transparency issue: the state of the system should be the same regardless of the name of the directory something lives in.

You can specify a project name, but giving things rigidly-defined names breaks the whole idea of it. Why would you want two different instances of the same project to have the same name?

Who said it’s a different instance?! Renaming a directory structure doesn’t have side effects like this in pretty much any other infra stuff. It’s like nc or curl deciding what Server to connect to based on the current directory name. Whacky.

Re: Docker Compose best practices for dev and prod

#103

Post by kh_hk »

Gordonjcp wrote: post #82
kh_hk wrote: post #17

Earlier 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 }}

Why do you want to set things conditionally like that? This feels like it's a very incorrect solution to a problem that you're making far more complicated than it needs to be.

I apply this solution exclusively on the development environment. I have found that having the power to bail out to a shell whenever docker compose does not support something helps me iterate faster on my local dev (without affecting others).

The following is just a contrived example. Why would I do that? Because I can

    # Bring up services without a command
    #
    # usage:
    # nocmd.sh up -d service_name
    
    function _compose {
      docker-compose -f docker-compose.yml $@
    }
    
    function nocmd {
    cat

Re: Docker Compose best practices for dev and prod

#104

Post by lazide »

kh_hk wrote: post #5
jayd16 wrote: post #4

Earlier quoted context omitted.

So whats the complaint? Compose seems pretty easy to work with to me.

For me the problem is that yaml (and the compose specificatio n) is not self sufficient to support complex scenarios. You will start by setting things and discovering that ENV vars * on the global scope of the compose specification are not supported so you end up having to template and output yaml. Try having 40 microservices and quickly iterate between fixing bugs in them. Some you want mounted, others you want runn…

This is literally ‘why kubernetes?’

Re: Docker Compose best practices for dev and prod

#105

Post by sandGorgon »

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 will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....but entirely on Compose files.

I really hope someone does a startup here.

Re: Docker Compose best practices for dev and prod

#106

Post by Gordonjcp »

lazide wrote: post #102
Gordonjcp wrote: post #65

Earlier quoted context omitted.

You can specify a project name, but giving things rigidly-defined names breaks the whole idea of it. Why would you want two different instances of the same project to have the same name?

Who said it’s a different instance?! Renaming a directory structure doesn’t have side effects like this in pretty much any other infra stuff. It’s like nc or curl deciding what Server to connect to based on the current directory name. Whacky.

That is specifically how it's designed. If you want to create a bunch of identical but differently-named projects, put them in separate directories.

Why on earth would you want to have lots of different directories that all point to the same instance? That's simply idiotic.

Re: Docker Compose best practices for dev and prod

#107

Post by biggerChris »

aidos wrote: post #6
biggerChris wrote: post #3

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.

What’s port 433? You mean 443?

Yes. I meant port 443.

Re: Docker Compose best practices for dev and prod

#108

Post by KronisLV »

nickjj wrote: post #72
JadoJodo wrote: post #62

One 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…

> 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) Docker Desktop volume performance on Windows is great if you're using WSL 2 as long as your source code is in the WSL 2 file system. It also works great with WSL 1. I've been using it for a long time for full time dev. In fact, volume performanc…

> Docker Desktop volume performance on Windows is great if you're using WSL 2 as long as your source code is in the WSL 2 file system. It also works great with WSL 1. I've been using it for a long time for full time dev.

My experience actually was the exact opposite. This one project had horrible IO performance on Windows, when running a bunch of PHP containers, with the WSL2 integration in Docker Desktop set to enabled.

It was bad to the point of the app taking half a minute to just load a CRUD page with some tables, whereas after switching to Hyper-V back end for running Docker, things sped up to where the page load was around 3 seconds.

I have no idea why that was, but after switching to something other than WSL2, things did indeed improve by an order of magnitude.

Re: Docker Compose best practices for dev and prod

#109

Post by 0xbadcafebee »

twblalock wrote: post #80
0xbadcafebee wrote: post #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 Do…

Also, don't use Docker Compose in dev if you use Kubernetes in prod. Just use the same thing everywhere. Otherwise the fact that something works in dev tells you nothing about whether it would work in prod.

^ 1000%

Re: Docker Compose best practices for dev and prod

#110

Post by frenchman99 »

sandGorgon wrote: post #105

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…

What do you mean with monitoring tools? You could deploy Prometheus/Grafana or an ELK stack on Compose so I'm not sure I understand what you mean
Post reply on HN