41–50 of 295 posts
Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...
Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...
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.
How will App Container Images be built? I'm guessing that unlike Docker, the standard App Container build tool(s), if any, will be separate from Rocket.
Earlier quoted context omitted.
Docker's MO is to become "that thing that is on all servers" so that when they flip the switch and start monetizing off support and tertiary services, people will be more-or-less locked in. It has indeed surprised me how quickly a normally-slow-to-accept-new-things community has adopted Docker (even well before it was considered "stable").
> how quickly a normally-slow-to-accept-new-things community I think you're referring to the sysadmin community - but I think the driver for this has been the search for deployment nirvana. Deployment is a much more fragmented field, so it makes sense that a good solution would find fertile ground.
Interesting takeaways from the post: * Despite Brandon Philips (CoreOS CTO) serving on the Docker governance board, Docker has aggressively expanded their scope well beyond their original container manifesto. * CoreOS believes the Docker runtime is now too unwieldy and "fundamentally flawed"; the unwritten word that really sprung to mind was that Docker was getting "greedy." * CoreOS reaffirms their original operatin…
This is great news, particularly for Enterprise customers adopting containers. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities. But crucially, they also crossed the business models of many startups (including CoreOS, Weave, Flocker, etc.) that rely on Docker maintaining an Open Platform. So this is an entirely logical response. I'll b…
I have been concerned that Docker's scope was expanding too far for a while now, so I'm glad to see an alternative that might work appear on the horizon. That said, I am somewhat concerned that CoreOS has a suspiciously similar business model to where Docker would probably like to be. It's in a business's best interest, and exceedingly common practice, to "land and expand" with something clear and compelling, and fol…
What features were recently introduced that it increased Docker's scope?
How will App Container Images be built? I'm guessing that unlike Docker, the standard App Container build tool(s), if any, will be separate from Rocket.
Right now there is a `actool build` subcommand that will build an ACI given a root filesystem. That tool is used to build the validation ACI's and the etcd ACI. It is rough right now and we will make it simpler to use overtime; and as rkt gets better people can run the build tool from inside of a container given source code.
Earlier quoted context omitted.
I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.
Interestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial. I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools. Links? Nah just use ips/…