3 ms·
Most of the comments here are missing the point of the article. Yes, Docker containers != VMs. That's the point: An old-school VM had all the components neede
by gwd 4y ago
Most of the comments here are missing the point of the article.
Yes, Docker containers != VMs. That's the point: An old-school VM had all the components needed to run one instance of a service; this might include the core app itself, along with "support processes", like a reverse proxy for TLS termination, and maybe some other services. By design, you cannot run all of those in a single docker container.
The point of the article is to say that Kubernetes pods ~= VMs: A pod has all the components required for a single instance of a service, each one in its own docker container, but with increased access to other containers in the pod (just as processes have increased access to other processes in the same VM). So if you're coming from a VM deployment world, when you see "pod" think "vm", and when you see "sidecar" think "support process".
- datalopers 4y ago> By design, you cannot run all of those in a single docker container. Sure you can. The notion that “one container, one process” is the biggest misstep of containerization.
- mccorrinall 4y agoWhy do you think so? In my opinion it makes debugging, deployment and keeping the architecture clean much easier.
- gwd 4y agoNote that I said "Docker container". And that's an oversimplification, but from the article: > Docker containers have been deliberately designed to contain just one application. One container - one Nginx; one container - one Python web server; one container - one daemon. The lifecycle of a container would be bound to the lifecycle of that application. And running an init process like systemd as a top-level entrypoint was specifically discouraged. My guess is that the goal of this is to leave "lifecycle" issues at the container boundary. If you put nginx and your golang webapp in the same container, and one of them crashes, Docker / kubernetes you have to have logic inside the container to detect that and restart the correct one. If the goal is to have Docker / Kubernetes is to take care of all that for you, making it one thing per container is the best option.
- mr_toad 4y ago> If you put nginx and your golang webapp in the same container, and one of them crashes, Docker / kubernetes you have to have logic inside the container to detect that and restart the correct one. If the proxy only serves the app you can just shrug and restart the container. If the proxy and the web app are both stateless it shouldn’t matter. What you don’t want to do is mix stateless processes with statefull services, or have intertwined dependencies.
- lamontcg 4y ago> And running an init process like systemd as a top-level entrypoint was specifically discouraged. I spent years abusing docker to run images with systemd in them to test system configuration management tools running as many processes as you like. Once you hit it hard enough with a wrench you can make it do that just fine. Makes it very easy and extremely quick to test things in docker containers on your laptop which are meant to eventually wind up on VMs/metal. Horrible things like entire RHEL distros running systemd in one docker image... "I watched C-beams glitter in the dark near the Tannhäuser Gate..."
- rektide 4y agoI'd rather use infrastructure to package orthogonal concerns than to figure out how to shoehorn all my concerns into each of many container builds. Keep the containers simpler, no? This also makes containers more dev friendly, dev accessible.
- deleted 4y ago[deleted]