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

81–90 of 166 posts

Re: Docker Compose best practices for dev and prod

#81

Post by shroompasta »

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…

This is a questionable comment

>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.

Anyone ever developing a react project on docker compose would never run a build step for development.

In fact for most setups, I probably wouldn't even run react on docker-compose for development, and just use the dev server straight up on my machine.

Furthermore, working with any python http servers is substantially easier when working with a dev server in development, rather than running your server through gunicorn or other wsgi servers - not to mention the ability to hot reload for development.

I'm sure that there are many other cases where it's necessary and convenient to separate production and development docker compose files.

I don't think it's fair to say that there is no point in having separate docker-compose files as the lion's share of dependencies that need to be consistent is inside each container, not on the docker-compose configuration level.

Re: Docker Compose best practices for dev and prod

#82

Post by Gordonjcp »

kh_hk wrote: post #17
fio_ini wrote: 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 }}

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.

Re: Docker Compose best practices for dev and prod

#83

Post by jjtheblunt »

dijksterhuis wrote: post #11
aidos wrote: post #6

Earlier quoted context omitted.

What’s port 433? You mean 443?

433 for those who didn't know (like me) https://en.wikipedia.org/wiki/Network_News_Transfer_Protocol > The Network News Transfer Protocol (NNTP) is an application protocol used for transporting Usenet news articles (netnews) between news servers, and for reading/posting articles by the end user client applications. > Well-known TCP port 433 (NNSP) may be used when doing a bulk transfer of articles from one server to…

on many unix variants, /etc/services lists the ports and normal uses

Re: Docker Compose best practices for dev and prod

#85

Post by hu3 »

jaimehrubiks wrote: post #61

Do people here set CPU limits? (in either docker or kube) In my company we only set CPU requests + Memory req+limits. I read somewhere that CPU limits are kinda broken and are not reliable. In some experiments CPU limits tend to cause unnecessary throttling, which is why some people don't recommend them. However, I've also found some cases where I can't make the app to use only some of the CPUs, some frameworks tend…

In Windows dev machines, under wsl2, I always set CPU and RAM limits by creating a file in %USERPROFILE%/.wslconfig with something like:

  [wsl2]
  memory=10GB
  processors=4
  swap=2GB
By limiting wsl2 I also limit the docker containers that run inside wsl2.

Re: Docker Compose best practices for dev and prod

#87

Post by rdsubhas »

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…

> ... if Dev and Prod run differently, there's really no point to ...

"If dev and prod run differently" — Why is there an "if" here at all? Isn't it obvious to verify with two eyes in the real world? Is there any company in the world that runs production from somebody's laptop at home? Or distributes server racks for people to take home? It looks like an extremely disillusioned question out of touch with reality.

1. For development, engineers want to run a local throwaway mysql/redis. In production, engineer want to use a proper managed mysql/redis. The compose file, and envvars/links will be different. This is extremely normal, it makes sense.

2. Development laptops will always be underpowered than servers. The cpu/memory requirements will be different. Again makes sense.

3. For development, engineers will build and run the docker image locally. In production, these are separate, you would build and publish the image separately in CI, and run only published images in prod. Again, makes sense.

These are all perfectly logical things that make practical sense.

Trying to share/ reuse/ resemble is fine. But saying "dev===prod" is just a disillusion out of touch with reality.

Edit: For context, yes I do docker for a living for last 10 years, since v0.4 (lxc) days. I've been to and presented in meetups. If someone says they're trying to get dev as close functionally to prod, by doing X, Y, Z and sharing practical tips — you know you can listen to them. If someone says "dev===prod" and when you ask how they talk abstract principles, you quietly get out of there.

Re: Docker Compose best practices for dev and prod

#88

Post by adamckay »

pcorsaro wrote: post #77
edfletcher_t137 wrote: post #39

The article is titled "for dev and prod" (emphasis on the latter), yet the very first suggestion is to bind-mount your source outside the container so you can mess with it at any time? How is this good advice for production?! (Update: this is indeed great advice for development, and it's actually in a sub-section dedicated to that! My bad.) Update: reading comprehension, it's a thing! :) Thanks chrsig for pointing ou…

Just curious, why would a bind-mount be bad in production? I understand if you're running multiple app servers and need the code to be deployed in a lot of places that they'd be bad, but if you're just using a single server, what's the downside of using bind-mounts? You could use git to push code changes up to your server, and they'd be picked up immediately without having to rebuild and push an image.

Usually for production you want to know with 100% certainty what version of the software is running. Whilst you can do that with Git commit hashes you can't be sure no one has performed a hotfix and modified code on the production server which is not committed to source control. Then there's also the potential problem of pulling the latest updates from source control but forgetting to restart the container so it's not obvious you're actually running outdated code.

It's also a lot easier if there's a bad deploy to roll back the update by reverting the image tag in the compose file and restarting rather than checking out specific older commits and risk getting into a funky state with detached heads and the like.

Re: Docker Compose best practices for dev and prod

#89

Post by user3939382 »

solardev wrote: post #48

If you happen to be unlucky enough to need Docker for LAMP/LEMP stacks, Lando is a neat open-source util one level of abstraction above Docker Compose: https://lando.dev/ Like with `lando init` and then `lando start`, it'll fetch a LEMP "recipe" (say, for Wordpress or Drupal), configure all the Docker containers for you, set up all the networking between them, get PHP xdebug and such working automatically, and leave…

I was kind of puzzled by your preamble:

> If you happen to be unlucky enough to need Docker for LAMP/LEMP stacks

We run Docker LAMP and have a new version underway that's LEMP, haven't run into any problems. xdebug works fine, I even got it working recently in ECS. I'm not sure what's different about LAMP/LEMP in Docker vs any other stack.

Re: Docker Compose best practices for dev and prod

#90

Post by DrBenCarson »

bluedino wrote: post #78
tmpz22 wrote: post #69

Earlier quoted context omitted.

You're trying to create a uniform developer experience across two platforms that are wildly different. If you find yourself spending a ton of time on a one-size-fits-all-disappoints-everybody solution, maybe its time to build two effective solutions instead.

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

Post reply on HN