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

CoreOS is building a container runtime, Rocket

coreos.com

Post reply on HN
Print view View original

271–280 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#271

Post by darkarmani »

api wrote: post #72
tree_of_item wrote: post #21

Earlier quoted context omitted.

How does additional container management software fragment GNU/Linux?

Think a few steps ahead. These aren't really containers. They're giant statically linked binaries, more or less. The actual operating system is now just a VM host for running containerized giant WIMPs (weakly interacting massive programs). Fast-forward a few years and the host can wither and die and be replaced with a proprietary or custom/fragmented management layer. Linux survives only as an internal pseudo-OS with…

> The fact that we need containers at all stems from the difficulty of managing software installations, configuration, etc on the actual operating system.

Great post. However, containers are an easy concept to grasp. Even if the actual OS could be fixed, you'd still want some similar concepts even if the names were different.

Re: CoreOS is building a container runtime, Rocket

#272

Post by drewcrawford »

darkarmani wrote: post #223
_mikz wrote: post #191

I hope Rocket will be more stability oriented than Docker. After runing few hundreds containers on machine for almost a year know I would not chosen Docker again. Docker has stability issues all the time and it is taking months to solve them. Offering strace logs to developers without feedback and finally it was fixed by someone from outside the project. https://github.com/docker/docker/issues/7348 Allocating ports p…

> Even stupidest things like allowing to have more dockerfiles in one folder. Wow. That issue has been open for a long time.

I've been involved in that ticket since the dark ages. There's a philosophical disconnect between how (some) people want to use Docker and how the maintainers want it to be used, and it comes to a head in that thread.

Re: CoreOS is building a container runtime, Rocket

#273

Post by darkarmani »

drewcrawford wrote: post #272
darkarmani wrote: post #223

Earlier quoted context omitted.

> Even stupidest things like allowing to have more dockerfiles in one folder. Wow. That issue has been open for a long time.

I've been involved in that ticket since the dark ages. There's a philosophical disconnect between how (some) people want to use Docker and how the maintainers want it to be used, and it comes to a head in that thread.

I saw your articulate response in that thread. Thank you for that response. I don't need multiple dockerfiles right now, but if i invest more into docker, I will. I think your responses might have convinced shykes that the need won't be going away.

There was a similar disconnect on data volumes a while ago that took some convincing before the discussion moved forward. It has always been trivial in OpenVZ to bind mount into a container (ie: share a very large read-only mount between containers).

Re: CoreOS is building a container runtime, Rocket

#274

Post by philips »

darren0 wrote: post #219
philips wrote: post #42

Earlier quoted context omitted.

It isn't tied to systemd. The stage1 that is in the current prototype uses systemd to monitor and fork processes but we would love to see other stage1's that configure other process runners. For example configure and run a qemu-kvm filesystem as the container. Also, even though it is using systemd to monitor and fork processes a design goal is to run on all Linux's that have a modern Kernel.

The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.

Socket activation isn't mandated and completely optional. If an application detects it didn't get its sockets it can certainly just start listening instead if it wishes.

Re: CoreOS is building a container runtime, Rocket

#275

Post by jsprogrammer »

mbreese wrote: post #266
jsprogrammer wrote: post #245

Earlier quoted context omitted.

This is a pretty cynical point of view. Why can't we all work something out here?

It's not cynical, it's PR 101. You shouldn't respond publicly to something until you've calmed down. (It's actually good advice overall). No good can come from posting in the heat of the moment. Hell, you had the founder of Docker calling some of the people in this thread "trolls". That's not a win for anyone. The problem for the Docker folks was that they were making things into a much bigger deal than they otherwis…

If these projects are using 'open design processes', then the conversations do need to happen in the public.

What I felt as cynical about your post were things like:

>and made it seem like you were the leader of the market

I feel this is cynical because it's advocating not for facts and technical solutions, but arguably, willful misleading of the public. Docker should be open and honest about its software and its positions, not trying to create narratives where it 'seems' like you are something that you might not be.

>you just made the PR that much stronger for the CoreOS POV

The reason I advocated for not 'doing PR' is that, in my book, PR is an exercise in charade. Tell us what you feel, what you're working on, and why these things are good. Don't try to 'manage' appearances. If you have a problem with something, let it be known.

I think there are some things that might be able to be worked out. Docker and CoreOS/Rocket may be able to co-exist. Rocket doesn't seem to have the tools to easily produce the ACI's. Dockerfiles are widely used and pretty decent. Docker could focus on tooling while CoreOS handles execution. Both companies have contributed useful technology and it's not exactly clear that one company can/should own the entire solution.

Re: CoreOS is building a container runtime, Rocket

#276

Post by jsprogrammer »

lgs wrote: post #260
jsprogrammer wrote: post #253

Earlier quoted context omitted.

I only meant it as a statement of fact. When all we really get from each other is pieces of text, it is viewed as 'suspicious' when someone copies something verbatim without acknowledging that they have done so. Of course, the context plays a big part of whether it's viewed like that. In a forum like this, where we are supposedly typing our own 'comments' to the conversation, it's a little strange to see a sentence l…

Thanks for clarifying @jsprogrammer. What I'd really like, would be an Open Source model able to be COOPERATIVE over COMPETITIVE, as it was at the beginning of the movement. We all are here because of that disruptive vision and willing to cooperate beyond personal & corps interests, not to compete between startups to get funds and be quoted to the NASDAQ. No Linux or Docker or even Google, would be here without that…

That is difficult to achieve when you're embedded in a culture that often puts money above everything. Everyone (as in, those competing [often corporations]) are focused on the dollars and market share over the technical merits of the solutions.

There is a strong desire to own and control solutions. The facts are that image registries and container execution are lightweight abstractions over already existing protocols [DNS, HTTP] and technologies [Linux Containers]. There's not much to own in the space other than through having the 'best' technical solution.

Re: CoreOS is building a container runtime, Rocket

#277

Post by jtolds »

kentonv wrote: post #237
jtolds wrote: post #32

Improving the security model of docker is mentioned. Docker is known to be currently unsafe to run untrusted containers. Does anyone know yet if Rocket plans to support running untrusted containers safely, ala sandstorm.io?

Unlikely. Doing that requires a willingness to break things (disabling vast swaths of the kernel API in order to reduce attack surface). Sandstorm is fine with breaking things because Sandstorm is all about rethinking the platform and that means apps already need to be tweaked in a number of ways (see: https://blog.sandstorm.io/news/2014-08-19-why-not-run-docker... ). Docker and Rocket are very much designed to provi…

kentonv ftw

Re: CoreOS is building a container runtime, Rocket

#278

Post by gizzlon »

rst wrote: post #68
vito wrote: post #39

The post mentions not having a daemon running as root, but then you have to run `rkt` as root anyway. Won't this just mean that instead of having a single implementation of a Rocket daemon running as root, there is now one custom one every time it needs to be automated? It's great to see this problem broken up into reusable pieces though. It totally makes sense to function without a daemon, especially out of the box.

There actually is a significant difference between having 'rkt' as a setuid-root process that's invoked from the command line, and having a docker server always running waiting for commands. There are more ways for a potential attacker to get at the server. So, Rocket at least looks like they're trying to shrink the attack surface.

> There are more ways for a potential attacker to get at the server. So, Rocket at least looks like they're trying to shrink the attack surface.

hm.. I don't think that's a given at all! There's been many issues with setuid-root programs. And I've seen that the OpenBSD guys favor privilege separation by breaking breaking up daemons into several parts that communicate using a very strict set of commands. For example a dockerd that does most of the work, but talks to another daemon (dockerd-root) when it needs to do anything privileged.

OpenSMTPD example: https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd...

OpenSSH: Initial efort, 2002: http://www.citi.umich.edu/u/provos/ssh/privsep.html

http://www.openbsd.org/papers/openssh-measures-asiabsdcon200... - Page 16 ->

Re: CoreOS is building a container runtime, Rocket

#279

Post by mbreese »

jsprogrammer wrote: post #275
mbreese wrote: post #266

Earlier quoted context omitted.

It's not cynical, it's PR 101. You shouldn't respond publicly to something until you've calmed down. (It's actually good advice overall). No good can come from posting in the heat of the moment. Hell, you had the founder of Docker calling some of the people in this thread "trolls". That's not a win for anyone. The problem for the Docker folks was that they were making things into a much bigger deal than they otherwis…

If these projects are using 'open design processes', then the conversations do need to happen in the public. What I felt as cynical about your post were things like: >and made it seem like you were the leader of the market I feel this is cynical because it's advocating not for facts and technical solutions, but arguably, willful misleading of the public. Docker should be open and honest about its software and its pos…

Docker wants to be the leader in the market for containerized deployments, right? This is largely a competition for mind-share and users. How you act in a matters. Messaging matters. If Docker wants to be perceived as the leader in containers, then they should act like it.

PR isn't just standing in front of a microphone and saying what you're working on or how awesome you are. It's how you act in public, how you treat customers and competitors. You want to be authentic, but you don't have to share everything about how you feel to the public. Similarly, overly managed responses can be just as bad. There are good and bad ways to make an argument. Sometimes, it doesn't matter if you're right or not, if the way you make your argument turns people off, you are going to lose.

I think that the whole Docker/Rocket thing was vastly blown out of proportion, and wasn't the big deal that they made it out to be. Let's see who can make the best solution. But it is a mistake to think that this was a technical issue - it wasn't. The way that the situation was handled clouded what could have been a technical discussion of the merits or need for Rocket. At the same time, don't think that the best technical solution always wins.

Re: CoreOS is building a container runtime, Rocket

#280

Post by spb »

vishvananda wrote: post #170
spb wrote: post #90

Earlier quoted context omitted.

The thing I like about the link model is that they hide your containers from other containers and only expose the connections you want (I think using iptables?) I'd like a tool that makes this linking easier outside of Docker, but for now this is one of the features I like about it (although holy moly do Docker links have a lot of baggage you have to bring along for the ride, like giving everything names).

Shameless self plug, but not sure if you saw my project that does something along these lines: https://github.com/vishvananda/wormhole

From the docs, it looks like that has a dependency on Docker, which kind of defeats the purpose. If I'm stuck with Docker, I'm better off just sticking with links: I'm looking for something that could work with systemd-nspawn, etc.
Post reply on HN