11 ms·

I still can't really figure out what a container is. Every time I think of a use case for one, I read something like this which says that's a terrible idea. Th

by ender7 10y ago

I still can't really figure out what a container is. Every time I think of a use case for one, I read something like this which says that's a terrible idea. The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the other "servers" I have running. Do I just want a bunch of VMs? Or docker instances that all point to some other DB (that's apparently not in a docker instance...?). But then they're no longer independent from one another because they all use the same DB. So do I need a separate DB for each serverlet? Which lives where? On its own VM?

NikolaeVarius 10y ago
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.
typicalrunt 10y ago
> I still can't really figure out what a container is. If you mean this in a general sense... One use case at Unbounce (where I worked in infrastructure) was to encapsulate the runtime dependencies for different services that were on a machine. Our monolith required Ruby 2.1 and a bunch of gems. Then we were using Scout for centralized monitoring, which required 1.8 with a separate set of gems. We only noticed the problem when our monolith moved from Ruby 1.8 to 2.1. To fix this problem of dual-Ruby runtimes, we encapsulated the Ruby 1.8 + gems into a Docker image for Scout, then ran the Scout container on the machine. It works perfectly and never conflicts with the monolith's Ruby runtime.
sp332 10y ago
Docker is designed around the idea that you only have a single process running in a container. That's not an inherent property of containers though. LXD is a better tool for managing containers that are more like VMs. The kernel is shared between the host and the containers, but they can each have their own userspace. They could each have their own database right inside them, no problem.
mwpmaybe 10y ago
I am still on the journey to wholesale container acceptance, but I have been finding more and more use-cases that are delightfully solved by them. My favorite so far is a WordPress hosting platform with some shared infrastructure (web server, caching reverse proxy, and database) but each PHP-FPM instance jailed in its own container. This lets me: * easily chroot PHP (this is surprisingly difficult otherwise) * restrict MariaDB access by IP address * constrain the resource consumption of each application as necessary (i.e. to prevent an out-of-control PHP script from swamping the box) * independently determine each application's PHP version And because each managed application is (basically) a Docker image and a Caddyfile, it's easily extensible to non-PHP things. I can feel the lightbulb flickering but I'm not yet at full k8s awareness. The shared infrastructure isn't containerized, but it could easily be, and it's all running on one VM, but it could be distributed across multiple. Containers don't solve the common problems, they just give you more tools to work with. With databases, for example, you still need to figure out whether each application gets its own database instance? schema? user?, a replication strategy, a failover strategy, a backup strategy, etc. You can use either a bind-mounted host directory or a shared-storage volume for the backing store, just like always, or a newfangled data volume container. I am more comfortable sharing a database instance between multiple schemas and users because I can do IP-specific grants, but if I wanted to do one per application, I could do that too!
donpark 10y ago
A container is just changes you make to a file system to get something running. To run a container, Docker applies changes listed in its image then executes its entry point. When it stops, changes to file systems are preserved but memory is not. When removed, everything is gone so next time it runs you're starting fresh from original image. Magic with container are: 1) those changes are only visible from code running in the container, and 2) changes can be layered on top of each other (FROM in Dockerfile).
general_ai 10y ago
You're thinking about it incorrectly. Docker is not a VM. Docker is more like a chroot and a set of additional capability restrictions on top. Basically there are several things that are namespaced in Linux. Processes, network, users, IPC, mount, etc. Docker simply manages these namespaces. At a high level, when you fire up a container, a namespace gets created for it. So unless you explicitly tell Docker to expose things from the host, there's only a very limited set of things your container will see. Crucially, everything uses the same kernel, same drivers, etc, and there's zero overhead. Think of your Linux host as simply a default namespace.
pmontra 10y ago
You might want to create your own containers with standard bash commands instead of using docker. You can try cgroups, which are a standard Linux kernel feature. For Ubuntu https://help.ubuntu.com/lts/serverguide/cgroups.html https://help.ubuntu.com/lts/serverguide/cgroups.html For RedHat https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... Everything should be easier to understand after that.
davesque 10y ago
It's basically just a chroot but with additional levels of isolation that make a process think it's running in its own copy of an OS in addition to running on its own filesystem (as with a simple chroot). So it's similar to the concept of a virtual machine but it "virtualizes" the OS kernel instead of the hardware. See here: https://en.wikipedia.org/wiki/LXC https://en.wikipedia.org/wiki/LXC
throwawayish 10y ago
Unix has process groups. Unix has access control (ie. memory protection, FS access protection, FS root aka chroot). Containers are process groups with access control. The actual entity has a different name pretty much everywhere, eg. Solaris Zone, Linux namespace and Linux cgroups. Usually the OS throws in a wider bunch of stuff that is only loosely related to access control in the classic sense, eg. CPU and memory limiting, I/O rate limiting and such (so rusage access control, in a sense).
audleman 10y ago
> The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the other "servers" I have running. SaltStack, Ansible, Chef are all configuration management tools that serve this purpose. They let you configure a standalone box any way you want. The only use case I see for Docker over one of them is if you want to run multiple, independent services on one server. But why would you want to do that when you're running in the cloud? I don't see the benefit over separate instances, each tailored to be the exact size you need.
- icebraining 10y ago
  1) They let you be more fine-grained. Not all services need a full VM (even one of the small ones). 2) They let you have burstable instances, but controlling all the services sharing those resources, rather than being subjected to unknown neighbours. 3) Related to the previous points, they let you take advantage of free resources by distributing batch operations over VMs not under peak capacity.
donarb 10y ago
One use that I love is pre-packaged containers. I'm designing a system for a client that does headless web automation. I spent a couple of weeks trying to get various separate versions of selenium/Firefox/Chrome running along with Xvfb without much luck. The selenium project has fully tested and functioning container images that work every time.

by ender7 10y ago

NikolaeVarius 10y ago

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.

typicalrunt 10y ago

> I still can't really figure out what a container is. If you mean this in a general sense... One use case at Unbounce (where I worked in infrastructure) was to encapsulate the runtime dependencies for different services that were on a machine. Our monolith required Ruby 2.1 and a bunch of gems. Then we were using Scout for centralized monitoring, which required 1.8 with a separate set of gems. We only noticed the problem when our monolith moved from Ruby 1.8 to 2.1. To fix this problem of dual-Ruby runtimes, we encapsulated the Ruby 1.8 + gems into a Docker image for Scout, then ran the Scout container on the machine. It works perfectly and never conflicts with the monolith's Ruby runtime.

sp332 10y ago

Docker is designed around the idea that you only have a single process running in a container. That's not an inherent property of containers though. LXD is a better tool for managing containers that are more like VMs. The kernel is shared between the host and the containers, but they can each have their own userspace. They could each have their own database right inside them, no problem.

mwpmaybe 10y ago

I am still on the journey to wholesale container acceptance, but I have been finding more and more use-cases that are delightfully solved by them. My favorite so far is a WordPress hosting platform with some shared infrastructure (web server, caching reverse proxy, and database) but each PHP-FPM instance jailed in its own container. This lets me: * easily chroot PHP (this is surprisingly difficult otherwise) * restrict MariaDB access by IP address * constrain the resource consumption of each application as necessary (i.e. to prevent an out-of-control PHP script from swamping the box) * independently determine each application's PHP version And because each managed application is (basically) a Docker image and a Caddyfile, it's easily extensible to non-PHP things. I can feel the lightbulb flickering but I'm not yet at full k8s awareness. The shared infrastructure isn't containerized, but it could easily be, and it's all running on one VM, but it could be distributed across multiple. Containers don't solve the common problems, they just give you more tools to work with. With databases, for example, you still need to figure out whether each application gets its own database instance? schema? user?, a replication strategy, a failover strategy, a backup strategy, etc. You can use either a bind-mounted host directory or a shared-storage volume for the backing store, just like always, or a newfangled data volume container. I am more comfortable sharing a database instance between multiple schemas and users because I can do IP-specific grants, but if I wanted to do one per application, I could do that too!

donpark 10y ago

A container is just changes you make to a file system to get something running. To run a container, Docker applies changes listed in its image then executes its entry point. When it stops, changes to file systems are preserved but memory is not. When removed, everything is gone so next time it runs you're starting fresh from original image. Magic with container are: 1) those changes are only visible from code running in the container, and 2) changes can be layered on top of each other (FROM in Dockerfile).

general_ai 10y ago

You're thinking about it incorrectly. Docker is not a VM. Docker is more like a chroot and a set of additional capability restrictions on top. Basically there are several things that are namespaced in Linux. Processes, network, users, IPC, mount, etc. Docker simply manages these namespaces. At a high level, when you fire up a container, a namespace gets created for it. So unless you explicitly tell Docker to expose things from the host, there's only a very limited set of things your container will see. Crucially, everything uses the same kernel, same drivers, etc, and there's zero overhead. Think of your Linux host as simply a default namespace.

pmontra 10y ago

You might want to create your own containers with standard bash commands instead of using docker. You can try cgroups, which are a standard Linux kernel feature. For Ubuntu https://help.ubuntu.com/lts/serverguide/cgroups.html https://help.ubuntu.com/lts/serverguide/cgroups.html For RedHat https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... Everything should be easier to understand after that.

davesque 10y ago

It's basically just a chroot but with additional levels of isolation that make a process think it's running in its own copy of an OS in addition to running on its own filesystem (as with a simple chroot). So it's similar to the concept of a virtual machine but it "virtualizes" the OS kernel instead of the hardware. See here: https://en.wikipedia.org/wiki/LXC https://en.wikipedia.org/wiki/LXC

throwawayish 10y ago

Unix has process groups. Unix has access control (ie. memory protection, FS access protection, FS root aka chroot). Containers are process groups with access control. The actual entity has a different name pretty much everywhere, eg. Solaris Zone, Linux namespace and Linux cgroups. Usually the OS throws in a wider bunch of stuff that is only loosely related to access control in the classic sense, eg. CPU and memory limiting, I/O rate limiting and such (so rusage access control, in a sense).

audleman 10y ago

> The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the other "servers" I have running. SaltStack, Ansible, Chef are all configuration management tools that serve this purpose. They let you configure a standalone box any way you want. The only use case I see for Docker over one of them is if you want to run multiple, independent services on one server. But why would you want to do that when you're running in the cloud? I don't see the benefit over separate instances, each tailored to be the exact size you need.

icebraining 10y ago
1) They let you be more fine-grained. Not all services need a full VM (even one of the small ones). 2) They let you have burstable instances, but controlling all the services sharing those resources, rather than being subjected to unknown neighbours. 3) Related to the previous points, they let you take advantage of free resources by distributing batch operations over VMs not under peak capacity.

donarb 10y ago

One use that I love is pre-packaged containers. I'm designing a system for a client that does headless web automation. I spent a couple of weeks trying to get various separate versions of selenium/Firefox/Chrome running along with Xvfb without much luck. The selenium project has fully tested and functioning container images that work every time.