31–40 of 166 posts
Is there a "proper" way to have per host configs? I have a setup where I need to set "hostname: " depending on the system I'm on and right now I'm having to resort to using "docker compose -f compose. .yml up -d" where compose. .yml extends compose.yml
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.
They care a LOT about what you're serving to other people from their network though as there might be some legal issues directed back at them.
"August 18, 2022"
Earlier quoted context omitted.
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.
Your ISP doesn't care about what you're connecting to and accessing, at least not until they get a court order demanding that info. They care a LOT about what you're serving to other people from their network though as there might be some legal issues directed back at them.
https://arstechnica.com/information-technology/2015/03/atts-...
Is there a "proper" way to have per host configs? I have a setup where I need to set "hostname: " depending on the system I'm on and right now I'm having to resort to using "docker compose -f compose. .yml up -d" where compose. .yml extends compose.yml
Ex:
docker-compose.yml:
hostname: ${HOSTNAME}
.env:
HOSTNAME=foo.bar.com
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 }}
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 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…
Update: reading comprehension, it's a thing! :) Thanks chrsig for pointing out that this is under an appropriate sub-heading. D'oh!
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.