OT: Is rkt pronounced 'are kay tee'?
It says 'rock it' in the README [1].
The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
21–30 of 38 posts
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#22Security 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?
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.
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#23Earlier quoted context omitted.
more like, "you will be able to", its not released yet. but lots of active work.
rkt support in k8s has been in for a while. See: http://kubernetes.io/v1.1/docs/admin/kubelet.html (search for "rkt") and https://github.com/kubernetes/kubernetes/tree/master/docs/ge... .
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.
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#24Security 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?
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.
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#25Earlier quoted context omitted.
rkt support in k8s has been in for a while. See: http://kubernetes.io/v1.1/docs/admin/kubelet.html (search for "rkt") and https://github.com/kubernetes/kubernetes/tree/master/docs/ge... .
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 com…
Care to elaborate whats missing?
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#26I 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.
I'm pretty sure that comparing Swarm/Compose's feature set to Kubernetes would yield large gap.
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#27Earlier quoted context omitted.
rkt support in k8s has been in for a while. See: http://kubernetes.io/v1.1/docs/admin/kubelet.html (search for "rkt") and https://github.com/kubernetes/kubernetes/tree/master/docs/ge... .
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 com…
I don't have a list handy but can throw an example
a simple thing that was missing was managing /etc/resolv.conf (see rkt 1.0 release notes that this was added so now kubernetes can take advantage of it going forward).
Without it, one either has to jump through some hoops (not impossible) to manage it yourself or your system just wont work (i.e. trying using GCE metadata server from within GCE without being setup for GCE's dns server).
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#28Systemd-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.”
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#29Earlier quoted context omitted.
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 com…
Care to elaborate whats missing?
A lot of the remaining work is being tracked at https://github.com/kubernetes/kubernetes/issues/8262 and https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+...
Re: The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
#30> "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 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.