9 ms·

What is the motivation and benefit for running containers without docker? Docker is by far the more mature and adopted development tool. It also runs great on

by moondev 10y ago

What is the motivation and benefit for running containers without docker? Docker is by far the more mature and adopted development tool. It also runs great on windows, macos and linux. While k8s can run containers via the rkt runtime, it's still pretty new and will probably introduce unnecessary headache and edge cases. Docker also has a head start on a vibrant ecosystem for base images. In my opinion it would be better to focus on docker, and when rkt gets there it shouldn't be much of an issue to switch if desired.

jsmthrowaway 10y ago
Containers existed before Docker and will exist after Docker, and articles like these are desperate attempts to remind everyone of that in the face of Docker's unilateral destruction of the concept. I know I'm right because of comments like these that presuppose "well, if you're doing containers, use Docker, the alternatives just aren't there." Except they were, before Docker, and after Docker. Docker is a developer tool, not a container runtime. The 'containers' it presents require you to commit a daemon on every machine, commit to a weird storage and distribution story when, you know, files of containers served in a flat directory are totally adequate, and so on. Docker made extremely complicated choices for a lot of things and now everybody wishing to advance containers has to deal with presuppositions like these, where Docker exists and the motivation for not using it is unclear to a lot of people, you included.
- twblalock 10y ago
  Docker is a container runtime, not merely a developer tool. It was intended as such from the beginning. It is successfully used in production at large scale by a number of companies, including Uber. The fact that you don't like Docker doesn't change any of that. If you don't like it, don't use it. But there is no justification for you to claim it is only a developer tool when it is obviously more than that.
  - secstate 10y ago
    Docker was originally built on top of LXC. It is now becoming more flexible with what is underneath, but there's a reason you need a VM running in the background on macOS to use Docker. Docker is tool to interact with LXC (and hopefully other container systems).
    - icebraining 10y ago
      Docker doesn't use LXC anymore[1]. The reason you need a VM is to get the Linux kernel, not LXC, and the reason you need that is because the macOS kernel (Darwin) doesn't have the necessary containerization features. On FreeBSD, for example, Docker runs natively, without a VM. [1] https://www.infoq.com/news/2014/03/docker_0_9 https://www.infoq.com/news/2014/03/docker_0_9
      - fnj 10y ago
        If MacOS doesn't have certain linux kernel features, neither does FreeBSD. How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference.
        tonyhb 10y ago
        xhyve and bhyve virtualization built into the BSD kernels. docker for mac now runs a tiny linux vm directly on osx
        2trill2spill 10y ago
        > How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference. FreeBSD can run 64 bit and 32 bit Linux binaries via it's Linux emulator[1]. Plus FreeBSD has had containers since FreeBSD 4 which was released in March of 2000, except containers on FreeBSD are called jails. > If MacOS doesn't have certain linux kernel features, neither does FreeBSD. Just because one operating system doesn't have a feature that does not mean a different operating system does not have that feature. [1] https://www.freebsd.org/doc/handbook/linuxemu.html https://www.freebsd.org/doc/handbook/linuxemu.html
- moondev 10y ago
  So what is your alternative? Run containers your own unique way and roll your own distribution mechanism and networking to fragment yourself from the tools in the "container" space?
  - ex_amazon_sde 10y ago
    When "your own unique way" requires less development time and efforts and it's easier to learn for new hires, yes. That's why you hire system engineers - to write good automation.
philips 10y ago
Just to clarify two things: - rkt can run any docker image in the vibrant ecosystem: https://coreos.com/rkt/docs/latest/running-docker-images.html https://coreos.com/rkt/docs/latest/running-docker-images.htm... - Help test Kubernetes and rkt with minikube, it is working nicely today: https://github.com/kubernetes/minikube#using-rkt-container-engine https://github.com/kubernetes/minikube#using-rkt-container-e...
- moondev 10y ago
  Good to know about rkt and docker images, I stand corrected. Looks like it supports remote docker registries as well.
  - philips 10y ago
    Yes, it supports remote docker image registries and authentication to those registries.
sysexit 10y ago
> What is the motivation and benefit for running containers without docker? I believe that Docker bet the company on the wrong business model. Therefore knowing that you can run containers without Docker can be desirable, as it gives you options in case Docker turns out to be not viable. Docker made it easy to build and run containers from the command line. This technology was released at the right time and in the right place. And it got huge traction. Docker used this traction to get a very large amount of VC capital. Therefore they now need to show a very large return. How do you go about achieving that large return? A common way to do this is to use one piece of technology that is popular as an anchor to lock customers into an entire stack. And then you monetize the stack, which is easier as it has higher value. The technology in this case is the container runtime, and the stack would be an full enterprise grade container orchestration system. This strategy worked for others. Microsoft was a master in this. VMware as well, and so is Oracle. The reason I believe it will not work for Docker is: 1. The anchor technology is open source. Microsoft managed their lock-in via Windows, VMware via ESX, Oracle via their DB. It worked because those are proprietary. In the open source world you can just take Docker. 2. Even though the technology is open source, you can still try the ecosystem approach where you exploit certain network effects attached to your distribution of the code that protect you (e.g. vendor certifications). This is what worked for Red Hat. In my view it is unlikely to work for Docker. I don't think certifications are required as most container apps today are not vendor apps. And I would not know what else they could use. 3. For orchestration solution they are engineering against Google's Kubernetes. With all respect for Docker, this is going to be very hard as Google has a huge amount of experience in this area. 4. Due to Docker's need to protect their business model, there is no true community in the sense that there is an open exchange of ideas. The docker agenda prevails over technical decision making (like: should you have a docker daemon? Should Swarm be part of the Docker Engine?). Contrast that with Kubernetes which run in a very open manner by Google. This is why OpenStack got the traction, and why Eucalyptus and CloudStack died off. OpenStack had the most open community. All of this can lead, IMHO, to a situation where Docker will not succeed in delivering Swarm as they see it. Kubernetes will become the default container orchestration system, and Docker is relegated to a small place in the stack. This situation would make it hard for Docker to justify their valuation.
- jacques_chester 10y ago
deleted 10y ago
[deleted]
shykes 10y ago
Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning. It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience. Early versions of Docker were quite buggy, and we initially struggled to keep up with the colossal growth in usage and feature requests. As a result, many of the people who tried Docker in production too early were badly disappointed. Some of them decided Docker wasn't for them, and started looking for alternatives. 3. Extremely custom use case. If your deployment is larger, or more complex, or more specialized than 99.99% of deployments out there, then "mainstream" platforms like Docker might not be the right fit for you. Of course we try to make Docker as customizable as possible, to support more a wider spectrum of use cases with plugins. But realistically, no single platform can cover all use cases, and I don't think any platform ever will. Docker is no exception. 4. Philosophy disagreement. Different people have different opinions on how applications should be developed and deployed. Docker tries very hard to be agnostic - to accommodate as many opinions as possible. But we can't please everybody. If Docker does not fit your philosophy of development and deployment, then the natural response is to look for an alternative. 5. Competition. Many Docker competitors started out as extensions or modifications of Docker, and over time are looking to reduce their dependency on Docker. I'm probably missing other reasons, but these are the ones I've been most exposed to. These are all reasonable reasons to not want to use Docker. Our approach is that, if you want to run containers without Docker, we should make it as easy as possible. In practice that means spinning out as many of the underlying components as possible (what we call the "plumbing") so that you can assemble it yourself without being stuck using the entire Docker platform. For example: - containerd [https://github.com/docker/containerd https://github.com/docker/containerd] is our low-level container runtime. - runc [https://runc.io https://runc.io] is a standardized "container executor", which we donated to the Linux Foundation as the reference foundation for the OCI spec. - libnetwork [https://github.com/docker/libnetwork https://github.com/docker/libnetwork] is the low-level networking implementation (including overlay networking which is a very useful primitive for container clustering) - swarmkit [https://github.com/docker/swarmkit https://github.com/docker/swarmkit] is a clustering/orchestration implementation - notary [https://github.com/docker/notary https://github.com/docker/notary] is a cryptographic content verification tool, which you can use to sign and verify container images. - infrakit [https://github.com/docker/infrakit https://github.com/docker/infrakit] automates the provisioning of infrastructure capable of running containers. Our opinion is that, even if you don't use Docker, by using these components for your own purposes, you are indirectly contributing to making Docker better. Splitting out these components has also forced us to refactor Docker into a more modular, more robust design. We even send Docker employees to explain how to run containers without Docker :) For example here's a talk we gave at Linuxcon: https://linuxconcontainerconeurope2016.sched.org/event/7oHM/building-distributed-systems-without-docker-using-docker-plumbing-projects-patrick-chanezon-docker https://linuxconcontainerconeurope2016.sched.org/event/7oHM/...
zzzcpan 10y ago
Recently tried to run docker on Ubuntu Desktop 14.04. After googling a bunch of errors, trying different versions, but still failing decided to try rkt. That one worked out of the box, but apart from a bunch of simple images failed to run the caffe docker image. So, my motivation of running without docker would be to understand every little thing they do to actually be able to use them and rely on them.
- moondev 10y ago
  curl -sSL https://get.docker.com/ https://get.docker.com/ | sh sudo usermod -aG docker $your_user There ya go. In newer distros its as easy as apt-get install docker.io
  - zzzcpan 10y ago
    It installs fine, it just doesn't work. There is an issue on github with the same errors as I saw, where they discuss not fixing it, because of how uncommon the system is.
    - moondev 10y ago
      Can you link it here? I'm just curious. I run docker on trusty all the time
      - tonyhb 10y ago
        Me too. Never seen an error.
  - imtringued 10y ago
    Adding a user to the dockergroup is a bad idea on a desktop.
cakeface 10y ago
The motivation is to make a smaller change to their operations and infrastructure. Right now they are running application services on linux machines using puppet to make the machine environment work. Switching to a container gives them reproducible environments that work on a developer workstation and a server. It also gives some operational benefits for how you run a process I think. You can do this without buying into the docker daemon, network overlay, orchestration. If you are currently able to deploy services on linux to production then you can do that, but with containers. This is an incremental win.

by moondev 10y ago

jsmthrowaway 10y ago

Containers existed before Docker and will exist after Docker, and articles like these are desperate attempts to remind everyone of that in the face of Docker's unilateral destruction of the concept. I know I'm right because of comments like these that presuppose "well, if you're doing containers, use Docker, the alternatives just aren't there." Except they were, before Docker, and after Docker. Docker is a developer tool, not a container runtime. The 'containers' it presents require you to commit a daemon on every machine, commit to a weird storage and distribution story when, you know, files of containers served in a flat directory are totally adequate, and so on. Docker made extremely complicated choices for a lot of things and now everybody wishing to advance containers has to deal with presuppositions like these, where Docker exists and the motivation for not using it is unclear to a lot of people, you included.

twblalock 10y ago
Docker is a container runtime, not merely a developer tool. It was intended as such from the beginning. It is successfully used in production at large scale by a number of companies, including Uber. The fact that you don't like Docker doesn't change any of that. If you don't like it, don't use it. But there is no justification for you to claim it is only a developer tool when it is obviously more than that.
- secstate 10y ago
  Docker was originally built on top of LXC. It is now becoming more flexible with what is underneath, but there's a reason you need a VM running in the background on macOS to use Docker. Docker is tool to interact with LXC (and hopefully other container systems).
  - icebraining 10y ago
    Docker doesn't use LXC anymore[1]. The reason you need a VM is to get the Linux kernel, not LXC, and the reason you need that is because the macOS kernel (Darwin) doesn't have the necessary containerization features. On FreeBSD, for example, Docker runs natively, without a VM. [1] https://www.infoq.com/news/2014/03/docker_0_9 https://www.infoq.com/news/2014/03/docker_0_9
    - fnj 10y ago
      If MacOS doesn't have certain linux kernel features, neither does FreeBSD. How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference.
      - tonyhb 10y ago
        xhyve and bhyve virtualization built into the BSD kernels. docker for mac now runs a tiny linux vm directly on osx
      - 2trill2spill 10y ago
        > How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference. FreeBSD can run 64 bit and 32 bit Linux binaries via it's Linux emulator[1]. Plus FreeBSD has had containers since FreeBSD 4 which was released in March of 2000, except containers on FreeBSD are called jails. > If MacOS doesn't have certain linux kernel features, neither does FreeBSD. Just because one operating system doesn't have a feature that does not mean a different operating system does not have that feature. [1] https://www.freebsd.org/doc/handbook/linuxemu.html https://www.freebsd.org/doc/handbook/linuxemu.html
moondev 10y ago
So what is your alternative? Run containers your own unique way and roll your own distribution mechanism and networking to fragment yourself from the tools in the "container" space?
- ex_amazon_sde 10y ago
  When "your own unique way" requires less development time and efforts and it's easier to learn for new hires, yes. That's why you hire system engineers - to write good automation.

philips 10y ago

Just to clarify two things: - rkt can run any docker image in the vibrant ecosystem: https://coreos.com/rkt/docs/latest/running-docker-images.html https://coreos.com/rkt/docs/latest/running-docker-images.htm... - Help test Kubernetes and rkt with minikube, it is working nicely today: https://github.com/kubernetes/minikube#using-rkt-container-engine https://github.com/kubernetes/minikube#using-rkt-container-e...

moondev 10y ago
Good to know about rkt and docker images, I stand corrected. Looks like it supports remote docker registries as well.
- philips 10y ago
  Yes, it supports remote docker image registries and authentication to those registries.

sysexit 10y ago

> What is the motivation and benefit for running containers without docker? I believe that Docker bet the company on the wrong business model. Therefore knowing that you can run containers without Docker can be desirable, as it gives you options in case Docker turns out to be not viable. Docker made it easy to build and run containers from the command line. This technology was released at the right time and in the right place. And it got huge traction. Docker used this traction to get a very large amount of VC capital. Therefore they now need to show a very large return. How do you go about achieving that large return? A common way to do this is to use one piece of technology that is popular as an anchor to lock customers into an entire stack. And then you monetize the stack, which is easier as it has higher value. The technology in this case is the container runtime, and the stack would be an full enterprise grade container orchestration system. This strategy worked for others. Microsoft was a master in this. VMware as well, and so is Oracle. The reason I believe it will not work for Docker is: 1. The anchor technology is open source. Microsoft managed their lock-in via Windows, VMware via ESX, Oracle via their DB. It worked because those are proprietary. In the open source world you can just take Docker. 2. Even though the technology is open source, you can still try the ecosystem approach where you exploit certain network effects attached to your distribution of the code that protect you (e.g. vendor certifications). This is what worked for Red Hat. In my view it is unlikely to work for Docker. I don't think certifications are required as most container apps today are not vendor apps. And I would not know what else they could use. 3. For orchestration solution they are engineering against Google's Kubernetes. With all respect for Docker, this is going to be very hard as Google has a huge amount of experience in this area. 4. Due to Docker's need to protect their business model, there is no true community in the sense that there is an open exchange of ideas. The docker agenda prevails over technical decision making (like: should you have a docker daemon? Should Swarm be part of the Docker Engine?). Contrast that with Kubernetes which run in a very open manner by Google. This is why OpenStack got the traction, and why Eucalyptus and CloudStack died off. OpenStack had the most open community. All of this can lead, IMHO, to a situation where Docker will not succeed in delivering Swarm as they see it. Kubernetes will become the default container orchestration system, and Docker is relegated to a small place in the stack. This situation would make it hard for Docker to justify their valuation.

jacques_chester 10y ago

deleted 10y ago

[deleted]

shykes 10y ago

Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning. It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience. Early versions of Docker were quite buggy, and we initially struggled to keep up with the colossal growth in usage and feature requests. As a result, many of the people who tried Docker in production too early were badly disappointed. Some of them decided Docker wasn't for them, and started looking for alternatives. 3. Extremely custom use case. If your deployment is larger, or more complex, or more specialized than 99.99% of deployments out there, then "mainstream" platforms like Docker might not be the right fit for you. Of course we try to make Docker as customizable as possible, to support more a wider spectrum of use cases with plugins. But realistically, no single platform can cover all use cases, and I don't think any platform ever will. Docker is no exception. 4. Philosophy disagreement. Different people have different opinions on how applications should be developed and deployed. Docker tries very hard to be agnostic - to accommodate as many opinions as possible. But we can't please everybody. If Docker does not fit your philosophy of development and deployment, then the natural response is to look for an alternative. 5. Competition. Many Docker competitors started out as extensions or modifications of Docker, and over time are looking to reduce their dependency on Docker. I'm probably missing other reasons, but these are the ones I've been most exposed to. These are all reasonable reasons to not want to use Docker. Our approach is that, if you want to run containers without Docker, we should make it as easy as possible. In practice that means spinning out as many of the underlying components as possible (what we call the "plumbing") so that you can assemble it yourself without being stuck using the entire Docker platform. For example: - containerd [https://github.com/docker/containerd https://github.com/docker/containerd] is our low-level container runtime. - runc [https://runc.io https://runc.io] is a standardized "container executor", which we donated to the Linux Foundation as the reference foundation for the OCI spec. - libnetwork [https://github.com/docker/libnetwork https://github.com/docker/libnetwork] is the low-level networking implementation (including overlay networking which is a very useful primitive for container clustering) - swarmkit [https://github.com/docker/swarmkit https://github.com/docker/swarmkit] is a clustering/orchestration implementation - notary [https://github.com/docker/notary https://github.com/docker/notary] is a cryptographic content verification tool, which you can use to sign and verify container images. - infrakit [https://github.com/docker/infrakit https://github.com/docker/infrakit] automates the provisioning of infrastructure capable of running containers. Our opinion is that, even if you don't use Docker, by using these components for your own purposes, you are indirectly contributing to making Docker better. Splitting out these components has also forced us to refactor Docker into a more modular, more robust design. We even send Docker employees to explain how to run containers without Docker :) For example here's a talk we gave at Linuxcon: https://linuxconcontainerconeurope2016.sched.org/event/7oHM/building-distributed-systems-without-docker-using-docker-plumbing-projects-patrick-chanezon-docker https://linuxconcontainerconeurope2016.sched.org/event/7oHM/...

zzzcpan 10y ago

Recently tried to run docker on Ubuntu Desktop 14.04. After googling a bunch of errors, trying different versions, but still failing decided to try rkt. That one worked out of the box, but apart from a bunch of simple images failed to run the caffe docker image. So, my motivation of running without docker would be to understand every little thing they do to actually be able to use them and rely on them.

moondev 10y ago
curl -sSL https://get.docker.com/ https://get.docker.com/ | sh sudo usermod -aG docker $your_user There ya go. In newer distros its as easy as apt-get install docker.io
- zzzcpan 10y ago
  It installs fine, it just doesn't work. There is an issue on github with the same errors as I saw, where they discuss not fixing it, because of how uncommon the system is.
  - moondev 10y ago
    Can you link it here? I'm just curious. I run docker on trusty all the time
    - tonyhb 10y ago
      Me too. Never seen an error.
- imtringued 10y ago
  Adding a user to the dockergroup is a bad idea on a desktop.

cakeface 10y ago

The motivation is to make a smaller change to their operations and infrastructure. Right now they are running application services on linux machines using puppet to make the machine environment work. Switching to a container gives them reproducible environments that work on a developer workstation and a server. It also gives some operational benefits for how you run a process I think. You can do this without buying into the docker daemon, network overlay, orchestration. If you are currently able to deploy services on linux to production then you can do that, but with containers. This is an incremental win.