I think that process is fine and it is a pretty reasonable way of putting together a container. Part of what Docker is, is that Dockerfile and that Docker build process. Yeah, you can imagine doing that, there's no direct tool right now. Would you be able to create an application image in Rocket from a Dockerfile?
Does it do that through the Dockerfile or through the image itself?
Those projects now live at /appc and so there is a tool that converts from a Docker container to an App Container image. Another thing is that we have worked with a number of people and groups within this "container eco-system" and got some feedback and created a separate spec outside of Rocket which defines what we are calling an App Container, an App Container image, and an App Container runtime. Yes, there is a community project that someone announced yesterday that converts a Docker image into the App Container image.
Could you take some of the Docker images in the Docker hub and run them under Rocket, in theory? Before we get into why you did this, let's understand the technology a little bit better. Because the (Docker) daemon will, when you do "docker run" will be underneath the PID namespace of the Docker daemon. This can be a little bit of a tricky point if you're using Docker for these sorts of use cases. So you already have an init system like upstart or systemd or daemon tools or runit, when you do "rocket run" it actually gets monitored and run under that init system. In a way, in that Docker runs these things in separate process. Is that kind of the difference between Docker and Rocket? With Go you compile it and there's no "Go interpreter" running, you're just running your code.
#DOCKER FOR MAC BETA CHANNEL CODE#
So, with Ruby you have an interpreter that runs your code, the Ruby interpreter and your code is running. Much in the same way when you compile a Go program and run that it executes directly underneath your initial process. This is a pretty substantial design difference, we wanted to have Rocket be essentially a view on a static binary. So, you know your bash is PID 400, then "rocket run" is going to be 401. So how is Rocket different from Docker?Ī few things that we have done a little bit differently first is that Rocket does not have a daemon so when you run "rocket run coreos/etcd" that is actually executing directly under the process that you started it from. A lot of people have a good sense of what a container is, but in simple terms a container is a process that is running on your host and it is isolated from other processes. The first is that it downloads images of the application over the Internet, and in future versions it will verify those, and it runs those inside of a container. Rocket is a container runtime, which means a few things. Instead of starting with the controversy, let's talk about the tech. Before that he did kernel infrastructure and kernel hacking at SuSE and the SuSE Labs Group. He worked on a platform called Lubbock where they did LUA sort of a Node.js style LUA thing. Prior to starting CoreOS, Brandon spent some time at Rackspace where he worked on monitoring products. Backgroundīrandon Philips is the Co-founder and CTO of CoreOS This week, we interview the brain behind Rocket to ask what is Rocket and why they built it. Recently, CoreOS launched their own project named Rocket which has some architecturally different approaches to managing containers. Docker is not the only Linux Container manager available.
0 kommentar(er)
