4 ms·

All of us want containers to be successful, they solve a ton of problems. But, part of that success is getting the format and the security correct. And we want

by philips 12y ago

All of us want containers to be successful, they solve a ton of problems. But, part of that success is getting the format and the security correct. And we want to have that technical discussion and settle on those best practices for all implementations. There are things in the App Container spec that we would like to see in Docker, this is why we put in the work to make a spec, write the code to make it work and start a technical discussion. This has been the goal since the beginning. The problems that exist in the current Docker Engine that we would like to address are technical and real: 1) We believe in having a decentralized and user controlled signing mechanism. In the appc specification and rocket we use the DNS federated namespace. See the `rkt trust` subcommand and the signing section of the ACI spec. 2) We believe that image IDs should be backed by a cryptographic identity. It should be possible for a user to say: "run container `sha512-abed`" and have the result be identical on every machine because it is backed by a cryptographic hash. In rocket another thing we wanted to do was enable running the download/import steps outside of being a root user. For example today you can download and import an image from disk in the native ACI format with rkt. And in the next release `rkt fetch` will be runnable as a user in the same unix group as `/var/lib/rkt/`.

ABS 12y ago
I agree with everything you say from a technical point of view, it just doesn't change the political/business/marketing consideration IMHO
dmourati 12y ago
"they solve a ton of problems" Name two?
- m_mueller 12y ago
  Deploying to a cleanly defined fresh state without paying any performance penalty. Documenting your dependencies by writing the deployment script (=Dockerfile) and not having to reinvent the wheel everytime (image inheritance). Sandboxing linux applications without paying any performance penalty. Creating a PaaS where your services internally always see the same standard port, externally they're linked together through docker, thus separating the routing concerns from your application logic.
  - iso8859-1 12y ago
    Why do you mention like Linux? Containers shouldn't be specific to Linux.
    - m_mueller 12y ago
      Well.. in Docker's case they are? It's based on lxc, a Linux kernel technology. Of course BSD had it before that, although with a different name.
      - vezzy-fnord 12y ago
        Docker hasn't been based on LXC since 0.9 by now. It uses its own libcontainer.
        m_mueller 12y ago
        Which to my knowledge ist still linux-only, so while it's good to be technically correct, it doesn't change my point.
        vezzy-fnord 12y ago
        That much is correct, it's still tied to namespaces, cgroups and the standard mechanisms for implementing jailing on Linux. The point is it stands at a layer of abstraction designed for easier portability than outright depending on LXC.
  - dmourati 12y ago
    These are all great but I get the most of the same benefits from VMs and many more: fresh state/ no performance penalty (AMI+autoscaling) Document dependencies, not reinvent (Packer file) Sandboxing (same) Always use same standard port (easier with VMs as 1:1 map) I know most people think that containers/docker/whatever new stack does these things better and they may be right. The benefits however don't outweigh the costs in weaker toolset and less mature stack. For my use cases, the biggest problem is that containers don't solve the "where does this run" question. Whenever I ask this, people loudly exclaim "anywhere!" which is the same as "I don't know" to me. AWS AMIs run in 11 regions x N AZs around the world. This solves a much bigger technical problem for me than "it's lighter weight and easier to do incremental releases on top of" which seem to be the only things in favor of containers. Many people, including Amazon, say "run containers on VMs!" This seems unnecessarily complex for little additional gain. I'm really curious if the containerization folks are using Packer and if not why not.
rdtsc 12y ago
> All of us want containers to be successful, they solve a ton of problems. Not sure I want containers to be successful (unless of course the main business is building and marketing containers). I want my problem solved but whether they are solved with containers, mocks, jails, VMs, and so on doesn't matter as much.

by philips 12y ago

ABS 12y ago

I agree with everything you say from a technical point of view, it just doesn't change the political/business/marketing consideration IMHO

dmourati 12y ago

"they solve a ton of problems" Name two?

m_mueller 12y ago
Deploying to a cleanly defined fresh state without paying any performance penalty. Documenting your dependencies by writing the deployment script (=Dockerfile) and not having to reinvent the wheel everytime (image inheritance). Sandboxing linux applications without paying any performance penalty. Creating a PaaS where your services internally always see the same standard port, externally they're linked together through docker, thus separating the routing concerns from your application logic.
- iso8859-1 12y ago
  Why do you mention like Linux? Containers shouldn't be specific to Linux.
  - m_mueller 12y ago
    Well.. in Docker's case they are? It's based on lxc, a Linux kernel technology. Of course BSD had it before that, although with a different name.
    - vezzy-fnord 12y ago
      Docker hasn't been based on LXC since 0.9 by now. It uses its own libcontainer.
      - m_mueller 12y ago
        Which to my knowledge ist still linux-only, so while it's good to be technically correct, it doesn't change my point.
        vezzy-fnord 12y ago
        That much is correct, it's still tied to namespaces, cgroups and the standard mechanisms for implementing jailing on Linux. The point is it stands at a layer of abstraction designed for easier portability than outright depending on LXC.
- dmourati 12y ago
  These are all great but I get the most of the same benefits from VMs and many more: fresh state/ no performance penalty (AMI+autoscaling) Document dependencies, not reinvent (Packer file) Sandboxing (same) Always use same standard port (easier with VMs as 1:1 map) I know most people think that containers/docker/whatever new stack does these things better and they may be right. The benefits however don't outweigh the costs in weaker toolset and less mature stack. For my use cases, the biggest problem is that containers don't solve the "where does this run" question. Whenever I ask this, people loudly exclaim "anywhere!" which is the same as "I don't know" to me. AWS AMIs run in 11 regions x N AZs around the world. This solves a much bigger technical problem for me than "it's lighter weight and easier to do incremental releases on top of" which seem to be the only things in favor of containers. Many people, including Amazon, say "run containers on VMs!" This seems unnecessarily complex for little additional gain. I'm really curious if the containerization folks are using Packer and if not why not.

rdtsc 12y ago

> All of us want containers to be successful, they solve a ton of problems. Not sure I want containers to be successful (unless of course the main business is building and marketing containers). I want my problem solved but whether they are solved with containers, mocks, jails, VMs, and so on doesn't matter as much.