> "The Dockerfile format is completely fucking useless at this kind of thing." Right... which is why we have Docker Compose. The point of the image is to provi

> "The Dockerfile format is completely fucking useless at this kind of thing." Right... which is why we have Docker Compose. The point of the image is to provide the code and the harness for launching it WITHOUT those assumptions. > "But wait - how do we configure these services for multiple environments (test/prod clusters)? They don't read our ENVvars, nor do they know of our internal service discovery tools." This is why docker containers are composed out of other containers. You use an elasticsearch container as a basis and extend it out with your tools to make your unique flavor of deployable search unit. This is not a new technique to anyone, as even the es docker image itself is built off another base image. I get the impression the writer of this has yet to really internalize what docker containers are. > "Tools like pyinfra and Ansible are much more suitable for this kind of work (and don't install useless crap to generate a config file)." Are they though? This is said without really any justification. To me, I'd 100% rather do it via Docker. Next to actually locking everything into one big solid lump via Nix, Docker actually gives you reproducible and reusable chunks of code with nearly infinite and modular configurability, without any care about installations stepping over one another or even library conflicts. Sure, things like an unprunable stale image cache filling up small disks is annoying. But the alternative is a continuous and inscrutable agglomeration of code and configuration files onto a box, eventually leading to total disaster. But kinda typical of someone who wants to run Go. If you're building Go you've already accepted that you'll never ship the same executable twice.