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

11–20 of 140 posts

Re: Running containers without Docker

#11

Post by jsmthrowaway »

twblalock wrote: post #10
jsmthrowaway wrote: post #9

I've successfully used Docker in production since it was a hobby project of dotCloud. I was answering the OP's question about why anybody would ever consider not using Docker for containers, so it's ironic that I'm now responding to your comment as the followup about my personal preferences. Clever commentary trap: why not? Here's why. Oh, well, nobody's forcing you to use it.

This is what you wrote: > Docker is a developer tool, not a container runtime. It's just not true, and that's why I responded.

The bloody comment I replied to called it that, and it's not controversial. Docker did not suggest running in production for many years and the production stuff is largely an afterthought. Again, I developed this opinion from running it for years.

It was not intended for production usage from the beginning, as you claimed, but I'm already tired of responding to this thread because I'm turning instantly gray for not buying into Docker so why would I bother proving that you're not correct?

Re: Running containers without Docker

#12

Post by twblalock »

jsmthrowaway wrote: post #11
twblalock wrote: post #10

Earlier quoted context omitted.

This is what you wrote: > Docker is a developer tool, not a container runtime. It's just not true, and that's why I responded.

The bloody comment I replied to called it that, and it's not controversial. Docker did not suggest running in production for many years and the production stuff is largely an afterthought. Again, I developed this opinion from running it for years . It was not intended for production usage from the beginning, as you claimed, but I'm already tired of responding to this thread because I'm turning instantly gray for not…

You called it that. Read what you wrote. Here, I'll paste your entire comment as it is now, since you keep editing it:

> 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.

See the first sentence in the second paragraph? That's you. You wrote that. You did not present it as an opinion, but as a fact.

Re: Running containers without Docker

#13

Post by philips »

moondev wrote: post #6
philips wrote: post #5

Earlier quoted context omitted.

Just to clarify two things: - rkt can run any docker image in the vibrant ecosystem: 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-e...

Good to know about rkt and docker images, I stand corrected. Looks like it supports remote docker registries as well.

Yes, it supports remote docker image registries and authentication to those registries.

Re: Running containers without Docker

#14

Post by jsmthrowaway »

twblalock wrote: post #12
jsmthrowaway wrote: post #11

Earlier quoted context omitted.

The bloody comment I replied to called it that, and it's not controversial. Docker did not suggest running in production for many years and the production stuff is largely an afterthought. Again, I developed this opinion from running it for years . It was not intended for production usage from the beginning, as you claimed, but I'm already tired of responding to this thread because I'm turning instantly gray for not…

You called it that. Read what you wrote. Here, I'll paste your entire comment as it is now, since you keep editing it: > 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, u…

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 because you're making it extremely hard to remain civil.

But since you're the expert on Docker's production intentions, could you perhaps discuss Swarm and how it compares against competitive technology in the field? We can start small: what kind of scheduler does Swarm employ? Two-level, optimistic? What is your understanding of the runtime and performance bounds of the selected scheduling strategy? What is the expected latency for scheduling decisions as the number of executing containers grows? How does Swarm handle failure to schedule?

Could we then compare that scheduler against Aurora, Marathon, Kubernetes, Omega, and Borg? Why do you feel that Docker is production ready in light of the competitive work being done in this space? What do you feel is the difference between Mesos and Aurora? Between Docker and Kubernetes? Since Docker is intended for production usage, can you elaborate on some of the challenges you've experienced running it in production?

Re: Running containers without Docker

#15

Post by twblalock »

jsmthrowaway wrote: post #14
twblalock wrote: post #12

Earlier quoted context omitted.

You called it that. Read what you wrote. Here, I'll paste your entire comment as it is now, since you keep editing it: > 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, u…

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 tools: "docker can run on any x64 machine with a modern linux kernel - whether it's a laptop, a bare metal server or a VM. This makes it perfect for multi-cloud deployments." That sounds like production deployment to me.

Whether or not you like Docker, or think it works well in production, is immaterial to this. Docker is a container runtime, it is intended for production deployment, and that means it is not merely a development tool as you claimed. The first website Docker ever published is proof of Docker's intentions. It was intended as a production tool from the very beginning.

Re: Running containers without Docker

#16

Post by secstate »

twblalock wrote: post #7
jsmthrowaway wrote: post #3

Earlier quoted context omitted.

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…

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.

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).

Re: Running containers without Docker

#17

Post by schmichael »

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 strings is a bit awkward compared to calling docker's API, it's quite easy to support new features and manually run generated commands to test our driver's behavior.

[0] https://github.com/hashicorp/nomad

[1] https://www.nomadproject.io/docs/drivers/rkt.html

Re: Running containers without Docker

#18

Post by icebraining »

secstate wrote: post #16
twblalock wrote: post #7

Earlier quoted context omitted.

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.

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).

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

Re: Running containers without Docker

#19

Post by alex- »

I was introduced to linux cgroups and namespaces via my use of docker. It is a fantastic tool for using these concepts quickly and I don't currently see rocket etc overthrowing dockers dominance in the market place.

However I do sense (and feel my self at times) a growing upset with the usability/ stability of the docker engine.

The OCI (Open Container Initiative) should allow new solutions to come to market without fragmenting the space. i.e. it should be possible to run any image with any container engine/Linux.

Docker is valued at $1B. It appears that justifying that valuation has taken them into a number of adjacent markets. I wish they were more focused on the Docker Engine itself.

Re: Running containers without Docker

#20

Post by philips »

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…

Hey Michael! Could you email rkt-dev about your questions as well? Particularly around the long command strings. There are other ways to launch rkt containers besides long args.

https://groups.google.com/forum/#!forum/rkt-dev

Post reply on HN