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

161–166 of 166 posts

Re: Docker Compose best practices for dev and prod

#161

Post by pkrumins »

kh_hk wrote: post #14
pkrumins wrote: post #10

Earlier quoted context omitted.

Docker-compose just works and my team gets shit done. Does your team get shit done? If they do then what are you complaining about? If it hits production then it’s all good!

All I am saying is: * docker compose could be better * docker compose does not improve that much * by mixing docker compose with templates you can get complex stuff going, but is not a much advertised feature. Most of the "cool dev tool env" that appear are based on kubernetes, or something that is _not_ docker compose, which makes them difficult to adopt. I would like docker compose to improve on a direction that ma…

gg

Re: Docker Compose best practices for dev and prod

#162

Post by switchbak »

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.

Precisely my point. It's surprising behavior that breaks the mental model of more than a few people I've mentioned it to.

Re: Docker Compose best practices for dev and prod

#163

Post by xorcist »

heliodor wrote: post #138
xorcist wrote: post #97

Earlier quoted context omitted.

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.

That could be something like "debuger = 0" in the prod config. It's preferable to configuration drift.

Re: Docker Compose best practices for dev and prod

#164

Post by heliodor »

xorcist wrote: post #163
heliodor wrote: post #138

Earlier quoted context omitted.

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.

That could be something like "debuger = 0" in the prod config. It's preferable to configuration drift.

I'm not talking about a simple debug=true/false. I'm talking about debug=true followed by various debugger settings. I don't want to see ten or twenty debugger settings in my prod config.

Similarly, in dev, you can set the email config to output to a file and be done with it. I don't want to see all the email server settings in my dev config: the host, the port, the username, the password, the protocol, etc.

Re: Docker Compose best practices for dev and prod

#165

Post by fio_ini »

DangitBobby wrote: post #129
fio_ini wrote: post #52

Earlier quoted context omitted.

the point of docker-compose is partly so that your stack is ephemeral? you stand things up and shut it down with one simple switch and it can move between different environments and use the same declaration as the last environment. so now I gotta drag your bash script around and embed my yaml file in it? lol

The point of docker compose is to orchestrate containers. It's great for you to have lines that you always color inside, but other people choose different lines.

you're coloring outside the lines and making a mess you should grab a different coloring book this ones not for you.

Re: Docker Compose best practices for dev and prod

#166

Post by fio_ini »

kh_hk wrote: post #103
Gordonjcp wrote: post #82

Earlier quoted context omitted.

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

I can punch myself in the dick but I don't
Post reply on HN