51–60 of 166 posts
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.
Earlier quoted context omitted.
no haha I get the point but it's just another example I see someone over engineering a problem where it should be declarative. In what use case would you dynamically provision some arbitrary n number of volumes without knowing the path names to them? for volumes why wouldn't you just use "volume_name:/some/path" ... "another_volume:/another/path" and let docker manage the volume for you? you're going to end up writin…
Everything is simple until someone asks you to try and diagnose (and hopefully fix) a bug on an upgrade between two different versions of a piece of software that can be deployed using 5 different strategies or that has 20 moving services...
Earlier quoted context omitted.
Everything is simple until someone asks you to try and diagnose (and hopefully fix) a bug on an upgrade between two different versions of a piece of software that can be deployed using 5 different strategies or that has 20 moving services...
your volume example is an anti-pattern in regard to something like the 12 factor app. you're conditionally changing and setting the volumes based on an environment your in? your code and service is gonna be busted. how would you even know if anything worked in prod if it's not reproducible in dev since # if dev then volume xyz else volume abc #
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.
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…
I think the YAML anchors section would lead to an unparseable compose file? No `services` block above the `api` and `web` services, on the same level as `x-app:`. So the ` (I've not tested as currently on the windows gaming box. this is purely from reading it, so happy to be corrected).
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…
That is an absurdly black-and-white view.
I then find out that no-one bothered to run the compose file that matches what gets put into prod on their local machines.
My point is: your view might become more black and white on this matter after the N-th "but it works fine on MY machine" comment.
EDIT: Where N = your personal tolerance level of bullshit.
Earlier quoted context omitted.
That is an absurdly black-and-white view.
I have lost count of the times I've heard "but it works fine on MY machine, it must be the CI/CD that's broken" I then find out that no-one bothered to run the compose file that matches what gets put into prod on their local machines. My point is: your view might become more black and white on this matter after the N-th "but it works fine on MY machine" comment. EDIT: Where N = your personal tolerance level of bullsh…
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.
Earlier quoted context omitted.
Your problem is that you can't set ENV variables at the global level? Have you looked at YAML anchors? Makes things more DRY for longer/complex compose files.
That's just the tip of the iceberg. My problem is that YAML is not a turing complete language (and dev environments are usually messy by their nature).