21–30 of 208 posts
There's some (namespaces) knob to avoid that, but the lack of nod to it makes me worried.
OTOH containers as security boundary is iffy. But I still like them to not be root in case of compromise
So the problem is 1) port mapping and 2) backing up data volumes? There are simple solutions to each 1) you simple have a separate docker-compose file for a different environment, ie docker-compose.dev.yml for your dev server. in this file you simply define the parts that differ from the primary / prod compose file. that way it's a simple command. line variable that initiates a dev vs prod vs any other type. for deta…
Comparing oneself to docker compose is a straw man, when docker’s production option is docker swarm.
And Swarm is barely more complicated than compose anyway. Don't know why people who are claiming they use compose in production just don't learn the few extra steps to do what Docker recommends.
So the problem is 1) port mapping and 2) backing up data volumes? There are simple solutions to each 1) you simple have a separate docker-compose file for a different environment, ie docker-compose.dev.yml for your dev server. in this file you simply define the parts that differ from the primary / prod compose file. that way it's a simple command. line variable that initiates a dev vs prod vs any other type. for deta…
people dramatically overestimate how difficult it is to write a program that controls docker for you. This is one of those things where you can write like two pages of Python and ignore... all this: > Tealok is a runtime we’re building for running containers. If you have one machine and docker-compose is falling short, really, just write a Python script with the official docker Python package, you'll be fine.
I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`.
Probably took me an hour.
Then I added the ability to purge images before each update, because my tiny VM kept running out of disk space in the Docker partition. Oops. Scripts FTW.
I was already using the suggestion in the article about having a single reverse proxy server to redirect different paths (and different domains) to different servers hosted in the Compose file. Seemed like the obvious answer.
And I've configured k8s for my day job, so I could be using that. But I'm using Compose because I know how much of a pain k8s can be, especially around upgrades, where it has a habit of deprecating older versions of various interfaces. I'll put in the work for someone who's paying me to do it, but I'd rather work on my side project, not on configuring k8s.
I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/
people dramatically overestimate how difficult it is to write a program that controls docker for you. This is one of those things where you can write like two pages of Python and ignore... all this: > Tealok is a runtime we’re building for running containers. If you have one machine and docker-compose is falling short, really, just write a Python script with the official docker Python package, you'll be fine.
I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/
i've run production instances with 2PB of data being scraped per month by 100+ CPUs and 256GB of RAM using docker compose. some of the machines (smaller instances) have run flawlessly with zero reboots for years on end. both on cloud and on-prem.
i'd say its 100% production ready.
I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/
That plus a decent backup system would work for a small array of servers with fail-safes. Though I would die inside if a production user-focused app under any level of proper load was set up like that.
Definitely burying the lede that Tealok is building an alternative to docker compose. Interesting
It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.
It has a very brief introduction to Docker and Docker Compose, but then it mostly has a lot of FUD that's designed to scare people off of Docker Compose but is not remotely convincing to someone who's actually worked with it. The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly.
Looking at their website, I think they started out trying to make self-hosting really easy for a barely-technical user [0], which accounts for their attitude towards docker-compose, but it also means that the post was pretty devoid of useful information for someone who actually wants to self-host with the tech that's already ubiquitous today.