Live data from Hacker News

Running containers without Docker

jvns.ca

41–50 of 140 posts

Re: Running containers without Docker

#41
post #24
post #2

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 bet…

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…

You missed another, big reason: "Fewer, simpler moving parts" is the main reason I would prefer if Kubernetes could run without Docker as a container runtime.

At the moment, Kubelet needs to control the Docker daemon (a somewhat brittle relationship), and a bunch of concepts — from networking to volume management — could be simplified by making the container runtime more K8s-specific and less general-purpose. A tighter coupling would also mean you'd always be running K8s against the exact container logic it was made for, as opposed to now, where the loose coupling means you'll be subject to bugs (and there are so many) in new Docker versions.

That and the fact that Docker is increasingly building in competing concepts (services, etc.) via swarm mode, which I don't care for.

Docker still has a place for things like image building, of course.

Re: Running containers without Docker

#42
post #31
post #24

Earlier quoted context omitted.

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…

My main concern is coming across a an issue only to research it and find a "won't fix"[closed] and 100 +1s asking for it. When I have something super important in actual production this scares me way too much to trust.

1000x this. Pretty much sums up my experience with Docker so far.

Great concept, poor execution.

Re: Running containers without Docker

#43
post #30
post #29

Earlier quoted context omitted.

curl -sSL 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

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.

Can you link it here? I'm just curious. I run docker on trusty all the time

Re: Running containers without Docker

#44

Earlier quoted context omitted.

I edit to add because I'm on a phone. Nothing you've (annoyingly) pasted has been touched since it was submitted the first time. Please take your overly aggressive abuse of me to someone who cares, and reread what moondev wrote: > Docker is by far the more mature and adopted development tool. That's him. He wrote that. I added to it with something that you disagree with, and I'm rapidly tiring of interacting with you…

Here is the oldest copy of the Docker website on Wayback Machine, from the month that Docker was first released: https://web.archive.org/web/20130323002800/http://docker.io/ The title is "Docker: the Linux container runtime." So, your assertion that "Docker is a developer tool, not a container runtime" is simply false. The text clearly describes deployment of docker containers as much more than simple development too…

You're bring incredibly hostile over something very trivial.

Docker wasn't 'recommended' for production until 1.0: https://blog.docker.com/2014/06/its-here-docker-1-0/

Re: Running containers without Docker

#45
I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that it was a good plan in her situation.

There are lots of great tools in the Docker/container ecosystem these days, but I can see the argument that a major infrastructure migration should be done in incremental steps. Using containers as simply a Puppet replacement strikes me as a really good idea! You want your application to be _ready_ for containerization, before you try to introduce an orchestration system.

Although, when she mentioned that her team is meant to be "Heroku for the rest of the company", I couldn't help but think of Convox [0]. It's a great tool, it's open-source, and using it is really just like having your own Heroku. We used Convox at my last company, had amazing success with it, and I've been recommending it ever since.

[0] https://jvns.ca/blog/2016/10/26/running-container-without-do...

Re: Running containers without Docker

#46
post #24
post #2

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 bet…

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…

I can't comment much on docker as I have little experience but can I say this is a really honest and courageous post - I would have expected some corporate-speak not "we got things wrong early on", and a self-awareness and openness about the challenges being faced at a corporate level that has made me change my mind about the amount of trust to put in Docker the company.

Mad props.

Re: Running containers without Docker

#47
post #44

Earlier quoted context omitted.

Here is the oldest copy of the Docker website on Wayback Machine, from the month that Docker was first released: https://web.archive.org/web/20130323002800/http://docker.io/ The title is "Docker: the Linux container runtime." So, your assertion that "Docker is a developer tool, not a container runtime" is simply false. The text clearly describes deployment of docker containers as much more than simple development too…

You're bring incredibly hostile over something very trivial. Docker wasn't 'recommended' for production until 1.0: https://blog.docker.com/2014/06/its-here-docker-1-0/

Docker was always intended to run in production. That was the goal from the beginning. The developers recommended against running it in production before the 1.0 release because it was in beta. Developers of many products that are intended to run in production do the same thing before the first stable version is released.

That is not the same thing as saying that Docker was never intended to be used in production, and was only ever intended to be a development tool. That's the view I'm arguing against, and it's not trivial -- it denies the fundamental purpose of Docker.

Re: Running containers without Docker

#48
post #45

I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that it was a good plan in her situation. There are lots of great tools in the Docker/container ecosystem these days, but I can see the argument that a major infrastructure migration should be done in incremental steps. Using containers as simply a Puppet replacemen…

FYI, your link is pointing to the OP. I think you meant https://convox.com/

Re: Running containers without Docker

#49
post #45

I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that it was a good plan in her situation. There are lots of great tools in the Docker/container ecosystem these days, but I can see the argument that a major infrastructure migration should be done in incremental steps. Using containers as simply a Puppet replacemen…

Convox founder here. Thanks for the shout out! We are indeed building a private Heroku like platform so you don't have to.

It's a simple of layer around AWS so it doesn't add extra craziness some other approaches do.

As for the OP, her approach is spot on!

Containerizing your app is the first step in future proofing it. Doing so correctly will remove layers and therefore simplify things.

You now are looking at a package that can run on a laptop and run on a server with traditional techniques (upstart, systemd, etc).

You may take this to the next step and enter the orchestration world. Or not! Patience is a virtue, wait 6 more months and all the orchestration tools will be that much better.

It's all about simplifying. Adopt Dockerfile and shed Homebrew and Chef. Run containers on a "dumb" box with systemd and shed Packer.

Run containers on ECS and shed custom AMIs and userdata and nagios and...

Re: Running containers without Docker

#50
post #24

Earlier quoted context omitted.

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…

You missed another, big reason: "Fewer, simpler moving parts" is the main reason I would prefer if Kubernetes could run without Docker as a container runtime. At the moment, Kubelet needs to control the Docker daemon (a somewhat brittle relationship), and a bunch of concepts — from networking to volume management — could be simplified by making the container runtime more K8s-specific and less general-purpose. A tight…

I would categorize that under 5: competition. Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms.

Personally I think the long-term solution is for kubernetes to adopt containerd - it's the small, stable, rock-solid container runtime that it needs.

Whether the Kubernetes community continues to build primarily on Docker, or switches to containerd - either way we will support them and help in every way we can. Behind the superficial internet drama, there is a solid engineering collaboration between both communities, particularly between Docker and Google. We may disagree on a lot, but at the end of the day we have a lot of users who rely on us, and we have a responsibility to work together to solve their problems.

Post reply on HN