4 ms·

There is nothing special about containers to really understand Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. You can

There is nothing special about containers to really understand Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. You can run multiple containers on a single VM in the same way you can run multiple VMs on a single host. Ideally a container should be stateless. If a container crashes, you should be able to bring it up again without anything actually caring that it is technically a different process. A container doesn't solve a "real problem" it mostly makes it easier to manage applications and processes by abstracting out any dependencies from the host VM and keeping everything packaged into a single thing. A container can run any application that it is configured to run on any VM regardless of the state of the VM (Assuming the VM has a kernel that supports containers)

vegabook 10y ago
the "stateless" bit precludes a whole bunch of use cases, for example databases as per the post. For me the issue with containers is that they don't feel very "contained" when you have files ("images") all over the shop that don't get eliminated easily, or when attached volumes have storage in some location, and compose files elsewhere, and having to inject all sorts of environment variables. In other words, files and details scattered around everywhere. It's not nearly as clean as a VM, even though I do get it that for scaling tons of identical web servers, for example, they would be great.
- spacemanmatt 10y ago
  The reason I prefer external (mounted from the host) storage for PGDATA is so I can easily manage it from the host. Otherwise it's tied to the image, which I consider ephemeral.
wwwtyro 10y ago
I'd argue that the stateless bit is more of a Docker idiom than something intrinsic to containers. LXC/LXD, for example, treats containers as machines instead of processes.
metaphorm 10y ago
> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. can you go into a little more depth? my understanding of a VM is that it installs the OS in a dedicated memory partition, and allocates hardware resources separately from that of the host machine, such that resource contention between host and VM never happens. the VM allocated resources just go dark for the host machine while the VM is running. what is a lower level than that? I've understood containers to be thin wrappers around VMs, which would make them higher level, not lower level. do I have this wrong?
- tracker1 10y ago
  Containers aren't VMs... they're more of a sandboxed model of execution with a virtual network/disk abstraction. But lower/higher you are right, VM is probably lower-level abstraction of an entire system. But a container can be a single executable, it doesn't have to be an entire OS structure. For example, a lot of the go app containers are just the single executable by itself as a default. Many will rely on a debian/ubuntu base as they want other systems to work. This is mainly because of shared environments/libraries that some non-dockerized systems need, but isn't a requirement.
- NikolaeVarius 10y ago
  I'm doing a bit of a simplification here so please someone correct me if I'm not saying this correctly Every single instance of a VM has its own Kernel. When a VM boots up, it gets allocated a portion of hardware and boots up a kernel and allocates memory to itself. VMs each are isolated from each other in that they don't share resources and each VM is free to do whatever it wants to do with the hardware it is given. Like you said, to the host machine, that hardware is no longer available for any other VM to use. For Containers, they all live on a SINGLE kernel. They share resources across each other and the Kernel handles the multiple processes much like it would handle any other multithreaded process. If you have 3 VMs that all require a specific set of resources to run an application, you need 3x that hardware. This is not true for containers. You can get away with less because the containers will share the resources that the kernel as access to. I call them "lower level" in the sense that they do so much less than VMs. You CAN use containers as a VM in that a container can boot an entire Kernel, but generally you don't do this.
twic 10y ago
> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. We tend to use containers and VMs for similar purposes, but i think this the wrong way to explain what they actually are. A container is like a much thicker-skinned process. You know how when you run a program as a process, it can't read other processes' memory, and you can control how much CPU it uses with renice, and it can have anonymous files that no other process can read, and you can specifically kill it, and track its resource usage? Containers are like that but more so. With containers, programs can't even read each others' filesystems, and have completely separate network interfaces, and you can measure and control CPU usage for a whole tree of processes, not just one. Containers are processes beefed up to the level where they compete with running a VM.

vegabook 10y ago

the "stateless" bit precludes a whole bunch of use cases, for example databases as per the post. For me the issue with containers is that they don't feel very "contained" when you have files ("images") all over the shop that don't get eliminated easily, or when attached volumes have storage in some location, and compose files elsewhere, and having to inject all sorts of environment variables. In other words, files and details scattered around everywhere. It's not nearly as clean as a VM, even though I do get it that for scaling tons of identical web servers, for example, they would be great.

spacemanmatt 10y ago
The reason I prefer external (mounted from the host) storage for PGDATA is so I can easily manage it from the host. Otherwise it's tied to the image, which I consider ephemeral.

wwwtyro 10y ago

I'd argue that the stateless bit is more of a Docker idiom than something intrinsic to containers. LXC/LXD, for example, treats containers as machines instead of processes.

metaphorm 10y ago

> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. can you go into a little more depth? my understanding of a VM is that it installs the OS in a dedicated memory partition, and allocates hardware resources separately from that of the host machine, such that resource contention between host and VM never happens. the VM allocated resources just go dark for the host machine while the VM is running. what is a lower level than that? I've understood containers to be thin wrappers around VMs, which would make them higher level, not lower level. do I have this wrong?

tracker1 10y ago
Containers aren't VMs... they're more of a sandboxed model of execution with a virtual network/disk abstraction. But lower/higher you are right, VM is probably lower-level abstraction of an entire system. But a container can be a single executable, it doesn't have to be an entire OS structure. For example, a lot of the go app containers are just the single executable by itself as a default. Many will rely on a debian/ubuntu base as they want other systems to work. This is mainly because of shared environments/libraries that some non-dockerized systems need, but isn't a requirement.
NikolaeVarius 10y ago
I'm doing a bit of a simplification here so please someone correct me if I'm not saying this correctly Every single instance of a VM has its own Kernel. When a VM boots up, it gets allocated a portion of hardware and boots up a kernel and allocates memory to itself. VMs each are isolated from each other in that they don't share resources and each VM is free to do whatever it wants to do with the hardware it is given. Like you said, to the host machine, that hardware is no longer available for any other VM to use. For Containers, they all live on a SINGLE kernel. They share resources across each other and the Kernel handles the multiple processes much like it would handle any other multithreaded process. If you have 3 VMs that all require a specific set of resources to run an application, you need 3x that hardware. This is not true for containers. You can get away with less because the containers will share the resources that the kernel as access to. I call them "lower level" in the sense that they do so much less than VMs. You CAN use containers as a VM in that a container can boot an entire Kernel, but generally you don't do this.

twic 10y ago

> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. We tend to use containers and VMs for similar purposes, but i think this the wrong way to explain what they actually are. A container is like a much thicker-skinned process. You know how when you run a program as a process, it can't read other processes' memory, and you can control how much CPU it uses with renice, and it can have anonymous files that no other process can read, and you can specifically kill it, and track its resource usage? Containers are like that but more so. With containers, programs can't even read each others' filesystems, and have completely separate network interfaces, and you can measure and control CPU usage for a whole tree of processes, not just one. Containers are processes beefed up to the level where they compete with running a VM.