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

151–160 of 166 posts

Re: Docker Compose best practices for dev and prod

#151

Post by kalev »

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…

This is something i’ve been thinking about for a long time and your comment made me think about it again. I’ve seen many companies developing using docker-compose but deploying their software in a different way (on bare metal, kubernetes or nomad). Why hasn’t anyone build this yet? I’m afraid I’m missing something so starting on this my own is risky.

Re: Docker Compose best practices for dev and prod

#152

Post by jeremy_k »

sandGorgon wrote: post #148
jeremy_k wrote: post #122

Earlier quoted context omitted.

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…

yes. basically. and this is a path that multiple people are trying to solve. e.g. AWS CDK8s, https://tanka.dev/ , etc Compose would be awesome.

Disclaimer: I work for the company which wrote the blog post.

We basically do this at ReleaseHub, however there is a level of indirection we introduced. We basically have our own version of Kompose which generates our own YAML file, which we call an Application Template[1]. The Application Template then gets parsed into Kubernetes YAML and deployed, however as an end user, you never have you deal with the Kubernetes YAML.

The main piece missing is that we set everything up to parse the docker-compose file once and then expect people to interact with our YAML. However, having seen the level of interest about compose in this thread I'm wondering if maybe there is a feature to be built where we remove the need for interacting with our YAML, an end user can push changes to their compose and through GitOps we update everything and deploy new changes to Kubernetes.

The compose spec has come a long way since we started (we were attending the spec meetings back in 2020 to see how the project was going to kick off) and is in an even better place to support this direct Compose -> Kubernetes idea.

If you're curious, feel free to reach out jeremy@releasehub.com.

[1] - https://docs.releasehub.com/reference-documentation/applicat...

Re: Docker Compose best practices for dev and prod

#153

Post by lazyant »

glintik wrote: post #147
lazyant wrote: post #123

Earlier quoted context omitted.

same as if the database binary is running in the host? no difference with the db binary running in a container.

Looks like you never run docker compose in prod.

I have, for several years, let me know what I'm missing :-)

Re: Docker Compose best practices for dev and prod

#154

Post by 0xbadcafebee »

remram wrote: post #118
dijksterhuis wrote: post #71

Earlier quoted context omitted.

This wasn't a real example. Just a generic thing that happens everywhere I go. There's always one in the crowd that refuses to give up local development.

As long as you have CI or staging with the proper config, what does it matter how the devs write code?

The two aren't separate. There is a direct link between how devs write code and whether something works in production. And there is a ton of productivity loss and reliability loss when these two things are not in sync.

Re: Docker Compose best practices for dev and prod

#155

Post by kyriakos »

KronisLV wrote: post #108
nickjj wrote: post #72

Earlier quoted context omitted.

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

I have had great performance with Windows 10, docker desktop and wsl2. Code in wsl2 partition. Used to use an ec2 host for it but this setup performs better and the code sync step is eliminated.

Re: Docker Compose best practices for dev and prod

#157

Post by [deleted] »

0xbadcafebee wrote: post #113
rdsubhas wrote: post #87

Earlier quoted context omitted.

> ... 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. Bad idea. You develop against a completely different local system, then you push to prod, and "oh no it doesn't work". Yeah - because you're developing against a completely different system! It behaves differently. It causes different bugs. You take a ton of time setting up both di…

[deleted]

Re: Docker Compose best practices for dev and prod

#158

Post by sandGorgon »

jeremy_k wrote: post #152
sandGorgon wrote: post #148

Earlier quoted context omitted.

yes. basically. and this is a path that multiple people are trying to solve. e.g. AWS CDK8s, https://tanka.dev/ , etc Compose would be awesome.

Disclaimer: I work for the company which wrote the blog post. We basically do this at ReleaseHub, however there is a level of indirection we introduced. We basically have our own version of Kompose which generates our own YAML file, which we call an Application Template[1]. The Application Template then gets parsed into Kubernetes YAML and deployed, however as an end user, you never have you deal with the Kubernetes…

here's the thing - people have a degree of discomfort with "your own YAML". I'm not trying to flame, but genuinely tell you what the evolution of FUD has been.

At this point, you are sitting in a landscape which has already argued around Borg vs Kubernetes and consequently YAML vs Jsonnet vs Cue (e.g. https://github.com/cue-lang/cue/discussions/669). We have original Borg and k8s architects who have spilled lot of ink on this.

It is going to be super hard to digest another custom markup. This is really your battleground. People will ask - why not the standrdised Compose specification or standardised jsonnet/cue. In this context, Compose is kind of loved by all (though not the technically superior choice here)

the good news is - ur asking the same question probably and thats a good direction. You also have the steps to build up on (k3s, k11s, k9s - yes they are all different things and very cool). Best wishes if you go down this path.

Re: Docker Compose best practices for dev and prod

#159

Post by GordonS »

glintik wrote: post #147
lazyant wrote: post #123

Earlier quoted context omitted.

same as if the database binary is running in the host? no difference with the db binary running in a container.

Looks like you never run docker compose in prod.

I do, and use the same tooling for Postgres containers as when running Postgres outwith containers - WAL-E.
Post reply on HN