3 ms·

Binaries are one thing, but there are the other abstractions that containers bring in regard to networking and storage. You expose what are the network APIs of

Binaries are one thing, but there are the other abstractions that containers bring in regard to networking and storage. You expose what are the network APIs of your apps (e.g open ports), filesystem mounts, variables (12 factors), etc. Your application becomes a block that you can assemble for a particular deployment; add some environment variables, connect a volume with a particular driver to a different storage backend, connect with an overlay to be able to talk to other containers privately across different servers or even DCs, etc. It's really all about layers of abstraction for operating an application and deploying it to different environments. With the latest container orchestration tools, you can have a catalog of application templates defined simply in Yaml and it's very easy to make it run anywhere. Add some autoscaling and rolling upgrades and it becomes magic for ops (not perfect yet, but checkout latest Kubernetes to see new advancements in this space). With the proper tools and processes, this removes a lot of complexity.

Svenskunganka 10y ago
> add some environment variables, connect a volume with a particular driver to a different storage backend, connect with an overlay to be able to talk to other containers privately across different servers or even DCs, etc. But environment variables already exists without docker. Volumes already exists, aka partitions. "Overlay network" already exists, aka unix sockets or plain TCP/UDP/etc over the loopback interface. I'm not trying to be a dick here, it's just that the points you brought up doesn't really bring anything new to the table. How is this different from just having a couple bare-metal or virtual machines behind a proxy? There are some aspects to containerization that are very feasible, but only at certain scales and the points you brought up makes me question whether you perhaps might be over-engineering things a bit.
- alexandre_m 10y ago
  It's about the automation of these things. You now have generic interfaces (Dockerfile, docker-compose, Kubernetes/Rancher templates, etc.) to define your app and how to tie it together with the infrastructure. Having these declarative definitions make it easy to link your app with different SDN or SDS solutions. For example, RexRay for the storage backend abstraction of your container: http://rexray.readthedocs.io/en/stable/ http://rexray.readthedocs.io/en/stable/ You can have the same app connected to either ScaleIO in your enterprise or EBS as storage. We are closer than ever to true hybrid cloud apps and it's now much more easier to streamline the development process from your workstation to production. I think it's pretty exciting :)
  - pavlov 10y ago
    We are closer than ever to true hybrid cloud apps and it's now much more easier to streamline the development process from your workstation to production. This sounds exactly like the "It's the future!" guy in the original post...
- lobster_johnson 10y ago
  Those things exist, but you need the "setup" bit to achieve the level of isolation that you want. For example, volumes: With Kubernetes (on Docker), the lifetime of the volume mount is handled for you. No other containers have access to the mount. Container dies, mount dies. Whereas on plain Linux, mounts stay. You need cleanup, or you need to statically bind apps to their machines, which will seriously limit your ability to launch new machines -- there will be a lot of state associated with the bootstrapping of each node. Statefulness is the enemy of deployment, so really what you want is some networked block storage (EBS on AWS, for example) plus an automatic mount/unmount controller, thereby decoupling the app from the machine and allowing the app to run anywhere. Environment vars are inherited and follow the process tree, so those are solved by Linux itself. Process trees also handle "nesting": Parent dies, children die. But you will end up in a situation where a child process might spawn a child process that detaches. This is particularly hard to fix when a parent terminates, because the child doesn't want to be killed. Now you have orphaned process trees. The Linux solution is called cgroups, which allows you to associate process trees with groups, which children cannot escape from. So you use cgroups, and write state management code to clean up an app's processes. I could go on, but in short: You want the things that containerization gives you. It might not be Docker, although any attempt to fulfill the principles of containerization will eventually resemble Docker.

Svenskunganka 10y ago

> add some environment variables, connect a volume with a particular driver to a different storage backend, connect with an overlay to be able to talk to other containers privately across different servers or even DCs, etc. But environment variables already exists without docker. Volumes already exists, aka partitions. "Overlay network" already exists, aka unix sockets or plain TCP/UDP/etc over the loopback interface. I'm not trying to be a dick here, it's just that the points you brought up doesn't really bring anything new to the table. How is this different from just having a couple bare-metal or virtual machines behind a proxy? There are some aspects to containerization that are very feasible, but only at certain scales and the points you brought up makes me question whether you perhaps might be over-engineering things a bit.

alexandre_m 10y ago
It's about the automation of these things. You now have generic interfaces (Dockerfile, docker-compose, Kubernetes/Rancher templates, etc.) to define your app and how to tie it together with the infrastructure. Having these declarative definitions make it easy to link your app with different SDN or SDS solutions. For example, RexRay for the storage backend abstraction of your container: http://rexray.readthedocs.io/en/stable/ http://rexray.readthedocs.io/en/stable/ You can have the same app connected to either ScaleIO in your enterprise or EBS as storage. We are closer than ever to true hybrid cloud apps and it's now much more easier to streamline the development process from your workstation to production. I think it's pretty exciting :)
- pavlov 10y ago
  We are closer than ever to true hybrid cloud apps and it's now much more easier to streamline the development process from your workstation to production. This sounds exactly like the "It's the future!" guy in the original post...
lobster_johnson 10y ago
Those things exist, but you need the "setup" bit to achieve the level of isolation that you want. For example, volumes: With Kubernetes (on Docker), the lifetime of the volume mount is handled for you. No other containers have access to the mount. Container dies, mount dies. Whereas on plain Linux, mounts stay. You need cleanup, or you need to statically bind apps to their machines, which will seriously limit your ability to launch new machines -- there will be a lot of state associated with the bootstrapping of each node. Statefulness is the enemy of deployment, so really what you want is some networked block storage (EBS on AWS, for example) plus an automatic mount/unmount controller, thereby decoupling the app from the machine and allowing the app to run anywhere. Environment vars are inherited and follow the process tree, so those are solved by Linux itself. Process trees also handle "nesting": Parent dies, children die. But you will end up in a situation where a child process might spawn a child process that detaches. This is particularly hard to fix when a parent terminates, because the child doesn't want to be killed. Now you have orphaned process trees. The Linux solution is called cgroups, which allows you to associate process trees with groups, which children cannot escape from. So you use cgroups, and write state management code to clean up an app's processes. I could go on, but in short: You want the things that containerization gives you. It might not be Docker, although any attempt to fulfill the principles of containerization will eventually resemble Docker.