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

11–20 of 166 posts

Re: Docker Compose best practices for dev and prod

#11

Post by dijksterhuis »

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?

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

Re: Docker Compose best practices for dev and prod

#12

Post by pkrumins »

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.

Love your comment! Come work for me!

Re: Docker Compose best practices for dev and prod

#13

Post by fio_ini »

kh_hk wrote: post #2

docker compose is unnecessarily nerfed for using in development. I swear every company I work with has this problem and I always end up carrying along my hybrid bash-to-docker-compose cmd line tool that makes the dev experience under compose nice. Did you know that compose accepts stdin for `-f` files? Anything that outputs yaml is a valid "compose provider". Self plug, more on that, https://eskerda.com/complex-docke…

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 check the configurations into source control for YAML or .env files which is easier to read than hundreds of lines of bash and it's esoteric syntax. I love bash but I'm just sayin.

Re: Docker Compose best practices for dev and prod

#14

Post by kh_hk »

pkrumins wrote: post #10
kh_hk wrote: post #2

docker compose is unnecessarily nerfed for using in development. I swear every company I work with has this problem and I always end up carrying along my hybrid bash-to-docker-compose cmd line tool that makes the dev experience under compose nice. Did you know that compose accepts stdin for `-f` files? Anything that outputs yaml is a valid "compose provider". Self plug, more on that, https://eskerda.com/complex-docke…

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 makes development easier, that's all.

Re: Docker Compose best practices for dev and prod

#15

Post by CincinnatiMan »

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.

Re: Docker Compose best practices for dev and prod

#16

Post by dugmartin »

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.

I think it is just the parent directory name plus the service name (at least that is what I've seen at work where we have many docker-compose files with common "app"/"db" service names).

Re: Docker Compose best practices for dev and prod

#17

Post by kh_hk »

fio_ini wrote: post #13
kh_hk wrote: post #2

docker compose is unnecessarily nerfed for using in development. I swear every company I work with has this problem and I always end up carrying along my hybrid bash-to-docker-compose cmd line tool that makes the dev experience under compose nice. Did you know that compose accepts stdin for `-f` files? Anything that outputs yaml is a valid "compose provider". Self plug, more on that, https://eskerda.com/complex-docke…

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

Re: Docker Compose best practices for dev and prod

#18

Post by bdcravens »

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

Re: Docker Compose best practices for dev and prod

#20

Post by jjice »

siftrics wrote: post #8
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.

If it's going over port 443, how would your ISP know you're hosting movies? The way ISPs catch you is by seeing that you're connecting to IPs that are known to host content illegally. There's now way for your ISP to know what's going _out_ of your port 443 without breaking TLS.

The post said 433, not 443. I read it as the HTTPS port as well at first.
Post reply on HN