Live data from Hacker News

The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

coreos.com

31–38 of 38 posts

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#31
post #14

I think we're seeing a shift in focus in the container world from container runtimes such as Docker, to container orchestration systems such as Kubernetes. At some point the container runtime becomes just an implementation detail. Unless Docker finds a way of moving up the stack they are going to have a hard time defending their current valuation. Their current efforts provides close to zero monetizable value.

Orchestration isn't monetizable either. Amazon is giving it away for free on ECS.

Fleet, Mesos, swarm and kubernetes are effectively different implementation details too.

Operating these things as infrastructure services with high SLAs is a money making business.

I hope there are other ways to make this stuff a good business because CoreOS, Docker, Hashicorp, and Mesosphere et al are doing pretty darn excellent engineering.

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#32

Any plans on supporting rkt for ARM? That would be a killer feature for me :)

I have CoreOS building rkt stage0 for ARM64, but have just done minimal runtime testing so far. It is on my todo list to do more work with it to get full ARM64 support. Contributions welcome! https://github.com/glevand/coreos--coreos-overlay/tree/maste...

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#33
post #7
post #2

> "Despite the importance of a shared standard, after six months of effort the Open Container Initiative (OCI) body has yet to decide whether it should or should not develop and standardize an image format. Today, the primary focus of the OCI community is creating standards for the container runtime environment, rather than the container image. Specs for container runtime features are also a worthy discussion, but we…

I want to assume good faith, but OCI is starting to look like standard-washing. What good is runC if you have to use docker pull to download images first?

runc doesnt use docker format containers, you just provide a filesystem. You can store your containers for runc by curling a tarfile if you like.

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#35
post #7

Earlier quoted context omitted.

I want to assume good faith, but OCI is starting to look like standard-washing. What good is runC if you have to use docker pull to download images first?

runc doesnt use docker format containers, you just provide a filesystem. You can store your containers for runc by curling a tarfile if you like.

That isn't adequate. The reason LXC languished and Docker took off is because of immutable images, layers, Dockerfiles, and push/pull. If OCI has none of those then it is pointless.

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#36
post #7
post #2

> "Despite the importance of a shared standard, after six months of effort the Open Container Initiative (OCI) body has yet to decide whether it should or should not develop and standardize an image format. Today, the primary focus of the OCI community is creating standards for the container runtime environment, rather than the container image. Specs for container runtime features are also a worthy discussion, but we…

I want to assume good faith, but OCI is starting to look like standard-washing. What good is runC if you have to use docker pull to download images first?

You don't have to use docker pull. You can use any system capable of distributing a standard OCI bundle, including (but not limited to) docker.

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#37
post #2

> "Despite the importance of a shared standard, after six months of effort the Open Container Initiative (OCI) body has yet to decide whether it should or should not develop and standardize an image format. Today, the primary focus of the OCI community is creating standards for the container runtime environment, rather than the container image. Specs for container runtime features are also a worthy discussion, but we…

OCI focuses on the intermediary runnable format (think "ELF for containers") for a simple pragmatic reason: to accomodate pre-existing container packaging systems which were not compatible with each other. A good analogy would be designing a common vm that different programming languages can compile to, without forcing all developers to adopt the same syntax (a hopeless task).

Ironically this was specifically to accomodate the ACI format pushed by CoreOS, which is completely incompatible with Docker images. We designed OCI and runc to allow both Docker and ACI to target a common format and low-level runtime. The reasoning was "let's deliver a solid building blick which everybody can use instead of boiling the ocean with a giant over-reaching spec".

Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0

#38
post #16
post #14

I think we're seeing a shift in focus in the container world from container runtimes such as Docker, to container orchestration systems such as Kubernetes. At some point the container runtime becomes just an implementation detail. Unless Docker finds a way of moving up the stack they are going to have a hard time defending their current valuation. Their current efforts provides close to zero monetizable value.

If only Docker was working on orchestration... oh hey Swarm/Compose, I didn't see you over there.

Their orchestration product is Docker Universal Control Plane [1]

[1]: https://www.docker.com/products/docker-universal-control-pla...

Post reply on HN