Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running containers without Docker

jvns.ca

Post reply on HN
Print view View original

121–130 of 140 posts

Re: Running containers without Docker

#121

Post by thockingoog »

shykes wrote: post #78
chc wrote: post #66

Earlier quoted context omitted.

All of the early Kubernetes resources I can find describe it as involving Docker. Was running it without Docker really a thing early on?

No. Kubernetes was launched at the first Dockercon, with a very specific focus of "we want to help expand what can be done with Docker by leveraging the significant operational experience we accumulated at Google". They delivered very successfully on that promise. The focus on diversifying away from Docker is very recent, and is the direct result of the competitive tension I talk about earlier in the thread. It's com…

> The focus on diversifying away from Docker is very recent, > and is the direct result of the competitive tension

I think you miss a reason at least equally as important, if not more: There are a lot of people who want to do non-container runtimes but still leverage the rest of Kubernetes. I don't want to say no to them (who am I to decide what tech is "good"?) but I don't want their code in my tree (too big already, too hard to maintain, too much email, etc).

Ergo: plugins.

Re: Running containers without Docker

#122

Post by wlamartin »

cyphar wrote: post #92
wlamartin wrote: post #86

Earlier quoted context omitted.

Yep, the OCI is doing great stuff. At the bottom of the Cloud Foundry stack we have Garden-Runc ( https://github.com/cloudfoundry/garden-runc-release ). In past we had our own homegrown containerization technology and we're super happy to have been able to swap that out entirely in place of runc - it allows us to make use of the significant engineering talent contributed and has enabled us to move faster and reduce r…

> Yep, the OCI is doing great stuff. At the bottom of the Cloud Foundry stack we have Garden-Runc ( https://github.com/cloudfoundry/garden-runc-release ). In past we had our own homegrown containerization technology and we're super happy to have been able to swap that out entirely in place of runc - it allows us to make use of the significant engineering talent contributed and has enabled us to move faster and reduce…

Sweet. runC is awesome and using it is awesome. We are also super excited about the rootless work you personally have been doing, so thanks for your hard work in that area.

Re: Running containers without Docker

#123

Post by shykes »

thockingoog wrote: post #121
shykes wrote: post #78

Earlier quoted context omitted.

No. Kubernetes was launched at the first Dockercon, with a very specific focus of "we want to help expand what can be done with Docker by leveraging the significant operational experience we accumulated at Google". They delivered very successfully on that promise. The focus on diversifying away from Docker is very recent, and is the direct result of the competitive tension I talk about earlier in the thread. It's com…

> The focus on diversifying away from Docker is very recent, > and is the direct result of the competitive tension I think you miss a reason at least equally as important, if not more: There are a lot of people who want to do non-container runtimes but still leverage the rest of Kubernetes. I don't want to say no to them (who am I to decide what tech is "good"?) but I don't want their code in my tree (too big already…

You're absolutely right. I was focused on the subset of kub-based platforms which are container-focused and are overlapping more and more with Docker.

But you're right, kub itself is a neatly generic orchestration component which can be used with non-container things. That is an excellent reason for decoupling the underlying container runtime.

Re: Running containers without Docker

#124

Post by schmichael »

simstein wrote: post #71
schmichael wrote: post #36

Earlier quoted context omitted.

One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers. The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.

Could you please give a hint on what kind of stability issues you experienced? Do they still exist? My team is thinking about using Docker for high loaded system in production, and stability is one of our priorities here.

I don't personally operate docker in production, but googling "docker stability" or perusing their github issues should lead to the same anecdotes I'm referring to.

If you'll indulge me putting on my corporate hat for a minute: we've had some customers very happy scheduling a high volume of containers at a high rate on nomad:

- https://www.hashicorp.com/c1m.html (mentions a docker bug even)

- https://www.youtube.com/watch?v=MRtRwhL5lwM

If at all possible I'd recommend using our Java or exec drivers as they use builtin containerization and avoid the overhead of docker or rkt.

Re: Running containers without Docker

#125

Post by cakeface »

moondev wrote: 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…

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.

Re: Running containers without Docker

#126

Post by apeace »

daeken wrote: post #48
apeace wrote: 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/

Thank you! Caught this too late to edit.

Re: Running containers without Docker

#127

Post by tinco »

ex_amazon_sde wrote: post #113
Annatar wrote: post #106

Earlier quoted context omitted.

As I wrote previously, the question is for the founder of Docker and him alone, but since you volunteered your opinion, I am extremely pleased to inform you that I love making OS packages and performing configuration management at scale that way. I especially enjoy being able to ask the operating system's software management subsystem exactly which configuration changes have been done to it, and get a precise respons…

> by just using Kickstart, JumpStart(TM), or SDC, without any additional code. No Chef. No Puppet. No cfxengine. No Salt. No Ansible. No Docker. No KVM. No XEN. No Kubernetes. No Mesos. Thank you for saying this! Building OS packages and OS images and provisioning servers was done automatically 10 to 12 years ago with much less work. It's still the preferred choice for many large tech companies and nobody talks about…

Much less work than what?

Re: Running containers without Docker

#128

Post by cyphar »

wlamartin wrote: post #122
cyphar wrote: post #92

Earlier quoted context omitted.

> Yep, the OCI is doing great stuff. At the bottom of the Cloud Foundry stack we have Garden-Runc ( https://github.com/cloudfoundry/garden-runc-release ). In past we had our own homegrown containerization technology and we're super happy to have been able to swap that out entirely in place of runc - it allows us to make use of the significant engineering talent contributed and has enabled us to move faster and reduce…

Sweet. runC is awesome and using it is awesome. We are also super excited about the rootless work you personally have been doing, so thanks for your hard work in that area.

I can't take all the credit, Jess Frazelle was the reason that I started to work on an upstream version of binctr. But one of the cool things we can do with the rootless containers work (aside from making the lives of researchers easier -- something I've experienced personally) is to add OCI image building to KIWI (which is (open)SUSE's image building tool) and thus add it to OBS (the Open Build Service which is (open)SUSE's package building tool). I think there's a lot of cool things that will come out of rootless containers. :D

I'm going to be giving a talk about rootless containers at Linux.conf.au 2017 in case anyone is going to be attending.

Re: Running containers without Docker

#129

Post by cyphar »

schmichael wrote: post #17

The nomad[0] team was just discussing today how much effort to put into our rkt support[1] (our support for rkt lags behind our docker support). So far we don't see a lot of evidence of our users taking rkt into production over Docker, but I'm very curious if there's a significant number of users like Julia looking to avoid running docker in production. From a nomad developer standpoint, while building long command s…

Have you considered adding OCI support to Nomad? Is this something you're interested in? Currently we're working on getting an OCI-powered container runtime that works with k8s called ocid[1]. It'd be really awesome if nomad was interested in getting OCI (or even ocid) to work as a runner as well. :D

[1]: https://github.com/kubernetes-incubator/cri-o

Re: Running containers without Docker

#130

Post by TheDong »

fapjacks wrote: post #61
orthecreedence wrote: post #58

Earlier quoted context omitted.

Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).

The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.

Wrong. Without usernamespacing your containers do run as root. If you type `docker run busybox id` it will print uid=0, and that uid is 0 in the container and out of it.

You are namespaced, so the linux kernel promises that even though you're root, you're not dangerous, and there is syscall filtering and shit going on.... but that historically has not really fared that well!

But your statement is false. You're root with and without privileged. Privileged gives you back CAPABILITIES which are different than USER, so your claim is bullshit.

Post reply on HN