7 ms·

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

191 points by polvi 11y ago

mkobit 11y ago
> "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 think there is a more urgent need – and a more open, industry-wide upside – for a standard container image specification." I haven't been following the OCI at all, but could somebody shed some light as to why the runtime is the most important part to standardize? Also, any insight as to whether or not the container image format should be standardized?
- wmf 11y ago
  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?
  - justincormack 11y ago
    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.
    - wmf 11y ago
      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.
  - shykes 11y ago
    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.
- nzoschke 11y ago
  I work with containers all day every day and the image format is really important I have code on my laptop and I need to package it for many environments: A development VM A CI service Pushed and stored at rest in a registry Run on multiple runtime services like AWS ECS and Lambda It would be really nice if one image worked everywhere. Having to rebuild is at the very least inefficient, but sometimes disastrous if a different dependency or language version sneaks in. The Docker image format and registry API is becoming ubiquitous. We have also been using tarballs for builds for decades. Does it need to be standardized? Probably not. But it would be nice if we can do a better job of cooperating this generation than we did with VM images.
- shykes 11y ago
  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".
Perceptes 11y ago
Congratulations to CoreOS and the rkt team. I've been waiting for this to really dig into rkt, as I am a big fan of how CoreOS has been approaching this project, and eager for a container system that is not Docker.
DoubleMalt 11y ago
Any plans on supporting rkt for ARM? That would be a killer feature for me :)
- jzelinskie 11y ago
  >Huawei has contributed to rkt in multiple ways, both with a container registry and by providing ARM support. It looks like it already supports a bunch of different ARM targets[0]. [0]: https://github.com/appc/spec/blob/3972f6a1b657f38e30100d2a7ef377cc8690c8db/schema/types/labels.go#L23-L27 https://github.com/appc/spec/blob/3972f6a1b657f38e30100d2a7e...
- jzxcv 11y ago
  We aren't actively testing against it yet (although plan to in future), but have heard reports from the community that it works fine: https://github.com/coreos/rkt/pull/1766#issuecomment-157839411 https://github.com/coreos/rkt/pull/1766#issuecomment-1578394...
- glevand 11y ago
  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/master/app-emulation/rkt https://github.com/glevand/coreos--coreos-overlay/tree/maste...
tychuz 11y ago
Open source project hitting 1.0 - truly breaking news, especially when looking at all these JavaScript libraries.
inquisitiveio 11y ago
Good to see they are confident enough to cut a 1.0 release. We have been happily mixing the cgroup and kvm/Clear Containers runtimes for a for a couple of months now.
kentt 11y ago
OT: Is rkt pronounced 'are kay tee'?
- u320 11y ago
  It's pronounced "rocket".
- deleted 11y ago
  [deleted]
- squiguy7 11y ago
  It says 'rock it' in the README [1]. [1]: https://github.com/coreos/rkt https://github.com/coreos/rkt
jamra 11y ago
If I'm developing on OS X, would it still be possible to use rkt? How are the tools for managing your rkt deployments? Since Hashicorp supports it, I'm starting to think that I would be better off using their tooling to abstract myself from the specific container implementation.
- u320 11y ago
  You can use kubernetes to deploy rkt containers.
  - compsciphd 11y ago
    more like, "you will be able to", its not released yet. but lots of active work.
    - mjibson 11y ago
      rkt support in k8s has been in for a while. See: http://kubernetes.io/v1.1/docs/admin/kubelet.html http://kubernetes.io/v1.1/docs/admin/kubelet.html (search for "rkt") and https://github.com/kubernetes/kubernetes/tree/master/docs/getting-started-guides/rkt https://github.com/kubernetes/kubernetes/tree/master/docs/ge....
      - compsciphd 11y ago
        yes, support exists today, its just not complete, i.e. its close but not completely feature parity with docker as the runtime. When it does get there we will all be happy. So I should have been more clear, you can specify rkt today, but many things wont work, a lot of things have improved for the upcoming 1.2 k8s release but still not perfect. hence what I meant by "released", something that is can be viewed as a complete replacement for the docker runtime.
        ownagefool 11y ago
        Care to elaborate whats missing?
u320 11y ago
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.
- wmf 11y ago
  If only Docker was working on orchestration... oh hey Swarm/Compose, I didn't see you over there.
  - u320 11y ago
    Given the glacial pace of Swarm development, it's not going to be a serious contender in this space anytime soon.
  - jjm 11y ago
    I'm pretty sure that comparing Swarm/Compose's feature set to Kubernetes would yield large gap.
  - jtblin 11y ago
    Their orchestration product is Docker Universal Control Plane [1] [1]: https://www.docker.com/products/docker-universal-control-plane https://www.docker.com/products/docker-universal-control-pla...
- nzoschke 11y ago
  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.
mixmastamyk 11y ago
Security is good, but it isn't a big problem for my current local container apps. However, I've found Docker clumsy in various areas. Does this improve on the design any? Also, is there a PPA planned for Ubuntu, or plans to get it into Debian soon, now that it has reached 1.0?
- fidget 11y ago
  God yes. No more fucking docker daemon with lots of lovely shared state to fuck up, just one simple command that runs the container I ask it to.
- xaduha 11y ago
  I can only speak for myself, but for me it does, by forcing you to do stuff differently. Eventually you realise that Dockerfiles are fine and dandy, but this mechanism isn't really needed and it can be an obstacle. You realise that a good package manager is your real friend. So now I use wonderful xbps-install from Void Linux to create a complete rootfs + actool to make an ACI file and that's it. A basic webserver can work as a repo for your xbps packages and your ACI images. No need to use Docker Hub or Quay, etc.
23david 11y ago
Systemd-approved, nonetheless? “I believe in the rkt model,” said Lennart Poettering, systemd lead developer. “Integrating container and service management, so that there’s a 1:1 mapping between containers and host services is an excellent idea. Resource management, introspection, life-cycle management of containers and services – all that tightly integrated with the OS; that’s how a container manager should be designed.”
jvoorhis 11y ago
TPM support caught my eye. Brushing off the controversy surrounding EFI secure boot, the TPM is the under-appreciated "Secure Element" in business laptops and high end servers.

191 points by polvi 11y ago

> "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 think there is a more urgent need – and a more open, industry-wide upside – for a standard container image specification." I haven't been following the OCI at all, but could somebody shed some light as to why the runtime is the most important part to standardize? Also, any insight as to whether or not the container image format should be standardized?

wmf 11y ago
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?
- justincormack 11y ago
  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.
  - wmf 11y ago
    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.
- shykes 11y ago
  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.
nzoschke 11y ago
I work with containers all day every day and the image format is really important I have code on my laptop and I need to package it for many environments: A development VM A CI service Pushed and stored at rest in a registry Run on multiple runtime services like AWS ECS and Lambda It would be really nice if one image worked everywhere. Having to rebuild is at the very least inefficient, but sometimes disastrous if a different dependency or language version sneaks in. The Docker image format and registry API is becoming ubiquitous. We have also been using tarballs for builds for decades. Does it need to be standardized? Probably not. But it would be nice if we can do a better job of cooperating this generation than we did with VM images.
shykes 11y ago
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".

Perceptes 11y ago

Congratulations to CoreOS and the rkt team. I've been waiting for this to really dig into rkt, as I am a big fan of how CoreOS has been approaching this project, and eager for a container system that is not Docker.

DoubleMalt 11y ago

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

jzelinskie 11y ago
>Huawei has contributed to rkt in multiple ways, both with a container registry and by providing ARM support. It looks like it already supports a bunch of different ARM targets[0]. [0]: https://github.com/appc/spec/blob/3972f6a1b657f38e30100d2a7ef377cc8690c8db/schema/types/labels.go#L23-L27 https://github.com/appc/spec/blob/3972f6a1b657f38e30100d2a7e...
jzxcv 11y ago
We aren't actively testing against it yet (although plan to in future), but have heard reports from the community that it works fine: https://github.com/coreos/rkt/pull/1766#issuecomment-157839411 https://github.com/coreos/rkt/pull/1766#issuecomment-1578394...
glevand 11y ago
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/master/app-emulation/rkt https://github.com/glevand/coreos--coreos-overlay/tree/maste...

tychuz 11y ago

Open source project hitting 1.0 - truly breaking news, especially when looking at all these JavaScript libraries.

inquisitiveio 11y ago

Good to see they are confident enough to cut a 1.0 release. We have been happily mixing the cgroup and kvm/Clear Containers runtimes for a for a couple of months now.

kentt 11y ago

OT: Is rkt pronounced 'are kay tee'?

u320 11y ago
It's pronounced "rocket".
deleted 11y ago
[deleted]
squiguy7 11y ago
It says 'rock it' in the README [1]. [1]: https://github.com/coreos/rkt https://github.com/coreos/rkt

jamra 11y ago

If I'm developing on OS X, would it still be possible to use rkt? How are the tools for managing your rkt deployments? Since Hashicorp supports it, I'm starting to think that I would be better off using their tooling to abstract myself from the specific container implementation.

u320 11y ago
You can use kubernetes to deploy rkt containers.
- compsciphd 11y ago
  more like, "you will be able to", its not released yet. but lots of active work.
  - mjibson 11y ago
    rkt support in k8s has been in for a while. See: http://kubernetes.io/v1.1/docs/admin/kubelet.html http://kubernetes.io/v1.1/docs/admin/kubelet.html (search for "rkt") and https://github.com/kubernetes/kubernetes/tree/master/docs/getting-started-guides/rkt https://github.com/kubernetes/kubernetes/tree/master/docs/ge....
    - compsciphd 11y ago
      yes, support exists today, its just not complete, i.e. its close but not completely feature parity with docker as the runtime. When it does get there we will all be happy. So I should have been more clear, you can specify rkt today, but many things wont work, a lot of things have improved for the upcoming 1.2 k8s release but still not perfect. hence what I meant by "released", something that is can be viewed as a complete replacement for the docker runtime.
      - ownagefool 11y ago
        Care to elaborate whats missing?

u320 11y ago

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.

wmf 11y ago
If only Docker was working on orchestration... oh hey Swarm/Compose, I didn't see you over there.
- u320 11y ago
  Given the glacial pace of Swarm development, it's not going to be a serious contender in this space anytime soon.
- jjm 11y ago
  I'm pretty sure that comparing Swarm/Compose's feature set to Kubernetes would yield large gap.
- jtblin 11y ago
  Their orchestration product is Docker Universal Control Plane [1] [1]: https://www.docker.com/products/docker-universal-control-plane https://www.docker.com/products/docker-universal-control-pla...
nzoschke 11y ago
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.

mixmastamyk 11y ago

Security is good, but it isn't a big problem for my current local container apps. However, I've found Docker clumsy in various areas. Does this improve on the design any? Also, is there a PPA planned for Ubuntu, or plans to get it into Debian soon, now that it has reached 1.0?

fidget 11y ago
God yes. No more fucking docker daemon with lots of lovely shared state to fuck up, just one simple command that runs the container I ask it to.
xaduha 11y ago
I can only speak for myself, but for me it does, by forcing you to do stuff differently. Eventually you realise that Dockerfiles are fine and dandy, but this mechanism isn't really needed and it can be an obstacle. You realise that a good package manager is your real friend. So now I use wonderful xbps-install from Void Linux to create a complete rootfs + actool to make an ACI file and that's it. A basic webserver can work as a repo for your xbps packages and your ACI images. No need to use Docker Hub or Quay, etc.

23david 11y ago

Systemd-approved, nonetheless? “I believe in the rkt model,” said Lennart Poettering, systemd lead developer. “Integrating container and service management, so that there’s a 1:1 mapping between containers and host services is an excellent idea. Resource management, introspection, life-cycle management of containers and services – all that tightly integrated with the OS; that’s how a container manager should be designed.”

jvoorhis 11y ago

TPM support caught my eye. Brushing off the controversy surrounding EFI secure boot, the TPM is the under-appreciated "Secure Element" in business laptops and high end servers.