4 ms·

Even if I wasn't using containers for production, the ability to make a repeatable build allows you to make software with complex dependencies extremely easy to

Even if I wasn't using containers for production, the ability to make a repeatable build allows you to make software with complex dependencies extremely easy to develop in. Making it possible for a new developer in a new environment to get a build working on their own laptop, in the first day on the job, didn't use to be simple. And being able to make hermetic environments for integration tests used to be almost impossible, and today, depending on your stack, it is trivial with libraries like testcontainers.

verdverm 3y ago
You have been able to do that with VMs for a long time
- jchw 3y ago
  As a long time user of VMs for this purpose, this is definitely missing the point. Containers are sort of a technology, or perhaps some combination of technologies, but the actual value of containers for development has nothing to do with cgroups, seccomp, etc. In fact, using firecracker/ignite/whatever would probably be just as effective as using Docker or Podman. It really does come down to the concepts that underlie OCI images and Dockerfiles. Why? - Immutable root design promotes hygienic containers that keep state only in mounts. This makes upgrading, backup, etc. of containers very easy. Containerized software can be written around the assumption that this is how things work, by having a way to e.g. run database migrations at startup. - Composable images: Rather than having every environment ever made try to perfect making a reproducible Go development setup, you can just use FROM statements to use other images. With multi-stage builds you can even compose multiple images together to an extent. - Single-process design: Prior to containers, most VMs operated like full machines that could standalone, with just emulated or paravirtual hardware. Containers are designed around running a single process. In practice, this dramatically lowers the complexity of containers and their lifecycle. Of course, you Can and sometimes even will need to have multiple processes in containers sometimes, but the general mantra holds well. - Composable containers: Because of the previous point, it's natural to compose containers too, using features like Podman or Kubernetes pods, or Docker Compose. Containers in the same pod can share resources that would otherwise be isolated across typical containers, such as a network namespace. This makes for concepts like sidecars that allow composable functionality, and the ability to e.g. re-use PostgreSQL and Redis containers. - As a bonus, these approaches avoid plenty of typical pitfalls of configuration management systems often used with e.g. Vagrant such as Ansible. Because the environment is built up from scratch to your specifications, rather than working backwards from a mutable Linux system and trying to bring it to match a certain specification. Some of the problems that can lead to configuration drift still exist, but they are somewhat contained, especially if you use tags and/or image digests to pin your images. Virtual machines are technically fine, but containers elegantly offer solutions for both development and production deployment issues that VM setups never really did prior. Indeed, you could make something like testcontainers but for VMs... but then what do you use in place of OCI images and Dockerfiles for the base images? And you need to handle networking between VMs and the host, probably across multiple different VM runtimes. Eventually you realize you're just making worse containers!
  - verdverm 3y ago
    I won't go point-by-point, just point out that they are so similar, that there are products enterprises are buying that allow them to run their VM workloads in k8s like a container. It's also worth pointing out that containers sold themselves as VMs without the overhead (that was Google's goal with cgroups and namespaces that enabled things like Docker to come after) Much of what you talk about is tooling and patterns around containers, not containers themselves, such as networking and volume mounts. I would also point out that there are better options to Dockerfiles for containers these days as well, that unlock the real potential of buildkit.
    - hnaccount_rng 3y ago
      But that is the whole point! It's not about the technology or the isolation (while running). It's about the ability to simplify the generation of a new set of containers. Yes that's mostly tooling. But tooling is the single most important difference between something that's cool and something that's useful! We moved from "here is an (incomplete) description of what I did", which rounds to "please guess all the previous stuff that I did to my environment, before even starting to work on getting my instructions to work" to "download this binary and execute these 5 lines". The incompleteness problem of the description of _the actual thing you want to do_ hasn't gone away, but the largely not even mentioned description of where you have to do the thing... that has been replaced by Dockerfiles
      - verdverm 3y ago
        You seem not to have worked with the VM tools that do the same thing as a Dockerfile. Had you, you would realize that your points are invalid and I can have the same guarantees with VM as containers If you think Dockerfiles are great, then you haven't hit the day 2 problems yet or explored the better alternatives for defining containers. Also, the whole point of the original post is to point out that what you are saying is not magically true for containers
        jchw 3y ago

verdverm 3y ago

You have been able to do that with VMs for a long time

jchw 3y ago
As a long time user of VMs for this purpose, this is definitely missing the point. Containers are sort of a technology, or perhaps some combination of technologies, but the actual value of containers for development has nothing to do with cgroups, seccomp, etc. In fact, using firecracker/ignite/whatever would probably be just as effective as using Docker or Podman. It really does come down to the concepts that underlie OCI images and Dockerfiles. Why? - Immutable root design promotes hygienic containers that keep state only in mounts. This makes upgrading, backup, etc. of containers very easy. Containerized software can be written around the assumption that this is how things work, by having a way to e.g. run database migrations at startup. - Composable images: Rather than having every environment ever made try to perfect making a reproducible Go development setup, you can just use FROM statements to use other images. With multi-stage builds you can even compose multiple images together to an extent. - Single-process design: Prior to containers, most VMs operated like full machines that could standalone, with just emulated or paravirtual hardware. Containers are designed around running a single process. In practice, this dramatically lowers the complexity of containers and their lifecycle. Of course, you Can and sometimes even will need to have multiple processes in containers sometimes, but the general mantra holds well. - Composable containers: Because of the previous point, it's natural to compose containers too, using features like Podman or Kubernetes pods, or Docker Compose. Containers in the same pod can share resources that would otherwise be isolated across typical containers, such as a network namespace. This makes for concepts like sidecars that allow composable functionality, and the ability to e.g. re-use PostgreSQL and Redis containers. - As a bonus, these approaches avoid plenty of typical pitfalls of configuration management systems often used with e.g. Vagrant such as Ansible. Because the environment is built up from scratch to your specifications, rather than working backwards from a mutable Linux system and trying to bring it to match a certain specification. Some of the problems that can lead to configuration drift still exist, but they are somewhat contained, especially if you use tags and/or image digests to pin your images. Virtual machines are technically fine, but containers elegantly offer solutions for both development and production deployment issues that VM setups never really did prior. Indeed, you could make something like testcontainers but for VMs... but then what do you use in place of OCI images and Dockerfiles for the base images? And you need to handle networking between VMs and the host, probably across multiple different VM runtimes. Eventually you realize you're just making worse containers!
- verdverm 3y ago
  I won't go point-by-point, just point out that they are so similar, that there are products enterprises are buying that allow them to run their VM workloads in k8s like a container. It's also worth pointing out that containers sold themselves as VMs without the overhead (that was Google's goal with cgroups and namespaces that enabled things like Docker to come after) Much of what you talk about is tooling and patterns around containers, not containers themselves, such as networking and volume mounts. I would also point out that there are better options to Dockerfiles for containers these days as well, that unlock the real potential of buildkit.
  - hnaccount_rng 3y ago
    But that is the whole point! It's not about the technology or the isolation (while running). It's about the ability to simplify the generation of a new set of containers. Yes that's mostly tooling. But tooling is the single most important difference between something that's cool and something that's useful! We moved from "here is an (incomplete) description of what I did", which rounds to "please guess all the previous stuff that I did to my environment, before even starting to work on getting my instructions to work" to "download this binary and execute these 5 lines". The incompleteness problem of the description of _the actual thing you want to do_ hasn't gone away, but the largely not even mentioned description of where you have to do the thing... that has been replaced by Dockerfiles
    - verdverm 3y ago
      You seem not to have worked with the VM tools that do the same thing as a Dockerfile. Had you, you would realize that your points are invalid and I can have the same guarantees with VM as containers If you think Dockerfiles are great, then you haven't hit the day 2 problems yet or explored the better alternatives for defining containers. Also, the whole point of the original post is to point out that what you are saying is not magically true for containers
      - jchw 3y ago