Docker Vs Rocket
Docker has been flying high for over 20 months. It’s totally evident that Docker was on its ways to becoming the existing standard for container technology, the steaming thing in cloud computing in 2014. Then along came CoreOS which was one of the leading backers of Docker until Dec 1, 2014 when it dropped a bomb or we could say a rocket and announced a competitive container virtualization technology called Rocket.
Is Docker losing its way?
CoreOS CEO Alex Polvi stated that Docker is losing sight of its goal of making sure that its core container technology lives up to its promise. Docker was once a benchmark composable unit. He even stated that Docker is a platform that is currently building up tools for launching systems for clustering, cloud server provisioning, a wide range of functions that includes building images, running images, uploading, downloading and in the end even overlay networking, all organized into one powerful binary running especially as root on your server.
Polvi also said that Docker initially assured that their containers would be “lightweight” and “portable” components but if seen in present scenario Docker is distended and is just a different product than what we all signed up for.
CoreOs team’s main focus is on the idea of a container as an elementary structure of application development. All containers contribute a “microservice” that can be merged with other microservices so as to form distributed applications.
In the development design one always wants that the software they are using to run their containers should perform only that task leaving everything aside. Any additional platform services that software is providing would be no longer needed if you are already building it on another platform.
Docker software becomes more prone to danger as it allows the addition of features that increase the complexity of the software and probability of increase in exploitable vulnerabilities in the code. Docker is not becoming an appropriate and simple composable building block that we had visualized.
CoreOS intends to differentiate Rocket by keeping their container model simple and allowing users to avoid the “baggage” of Docker, while providing some novel security enhancements such as giving a unique identity to each instance of a running container and an HSM-like service for signing.
What is Rocket?
Rocket is a new container runtime which is another possibility or choice to the Docker runtime, also it is designed for server environments with the most resolved security, composability, speed and production requirements.
The software consists of two elements, each of which is a simple and standalone command-line tool.
1). Actool:– It is the first component that administers the building of containers. It even handles container validation and discovery.
2). Rkt:– It is named so, as all the prime UNIX commands used in Rocket are three letters. It helps in taking care of the fetching and running container images.
Contrary to Dockers’ approach, Rocket does not involve exterior daemon and these tools are not just a UI to converse to any other server. Whenever you call forth rkt to run a container it will do so without any delay inside the range of its own process tree and cgroup.
It was claimed that the Docker process model is fundamentally flawed as it allows everything to run through a central daemon. Now Rocket makes an attempt to accomplish and build things differently from Docker in many aspects. Following are the key points that have been kept in mind to build up a flawless runtime container.
1). Composition:- All the tools that are used for downloading, installing, and running containers should be independent and composable.
2). Security:– For providing a better security isolation should be pluggable, with image auditing, application identity and crypto primitives for strong trust.
3). Image distribution:- Discovery of container images should be simple, facilitate a federated namespace and distributed with pluggable alternative protocols such as BitTorrent and deployments to private environments without the requirement of a registry.
4). Open:– The format and runtime should be well-specified and developed by a community, allowing independent implementations of tools to be consistent.
What is the difference between Rocket and App Container?
“App Container” explains specifications of all the special feature and facilities that are surrounding the container and Rocket implements these facilities as a command line tool. An open specification gives the necessary opportunity to every other system to do their own implementation of App Container without using Rocket at all. CoreOS fully supports and embraces alternative implementations. Rocket is the first implementation of an App Container.
Rocket runs and implements the App Container specification created by CoreOS for an open portable container format that is composed of:
1). App Container Image (ACI): Signed and optionally encrypted tgz that includes all the bits to run an application container. Encryption allows distribution via BitTorrent, public object storage, or mirror networks.
2). App Container runtime: Environment in which the container should run, including devices, environment variables, privileges and a definition of a meta-data service interface for exposing data to the environment from outside the container.
3). App Container discovery: Federated protocol for finding and downloading images, inspired by golang’s vanity URL convention for import paths. Images can be referred with names such as coreos.com/etcd, allowing federated downloads without running a registry.
Linux operating system distribution vendor i.e. CoreOS aims to inflate its own vision and concept for container-based virtualization.
CoreOS is on the road that they had planned ah d are moving forward on its plan to take over the Docker application virtualization technology.
The Rocket striving efforts:
First announcement by CoreOs on Rocket was released on December 2014 together with the associated App Container Specification which officially is signified as appc. In sometime development is rolling up at great speed with new releases of appc and Rocket. The latest update for Rocket was version 0.2.0 which was released on Jan 23rd 2015. This new update comes up with an automation signature validation feature. As we all know that Docker basically volunteered little in the route of verifying containers integrity and was unable to add up more firm features for verifying signatures until version 1.3, that was released on last October. CoreOS, on the other hand learning from Docker’s history, is building integrity-guaranteeing functionality into Rocket as early on as possible.
On Jan 28th, CoreOS came up with another announcement of releasing etcd version 2.0 and tagged it as the first major stable release of the technology. Earlier to etcd 2.0, the most recent version was 0.4.6. The resolution was made to call the new release 2.0 for the reason that applications were already making use of the etcd code against what was referred to as the etcd v2 API.
Docker an open-source project that is till now being used by CoreOS for its production builds announced various moves to open up its development process on Jan 28th. Even though the Docker project is trying their level best to enhance its development process, CoreOS still has many concerns regarding the containers to be a standard composable unit.
1). Docker Project Enhances Structure to Address Unprecedented Growth; Announces Additional Leadership
Docker an open-source project that which develops the Docker open platform for distributed application on Jan 28th announced changes to the project’s operational structure to enable it to scale to address its unprecedented growth.
The new operational structure for the Docker project was established in the same way project features are; through its open design process and documented in a pull request (PR) – PR #9137
– that has been commented on, modified and ultimately merged into the project. The changes were structured in a way to allow the project to scale 10X and beyond, with the objectives being to:
● Make the project more open and accessible;
● Make the project more scalable;
● Do this in an incremental way, without unnecessary refactoring.
2). Docker Project Announces Open-Source-a-thon to Support Whale and Marine Wildlife
On Feb 19th 2015 Docker came up with new announcement, Docker Project Partners with Oceanic Society for Open-source-a-thon to Support Whale and Marine Wildlife Conservation. Docker core team members will teach and mentor people in how to contribute to open-source. Now this contribution includes code, documentation, tutorials, videos as well as mentoring. Each contribution to the Docker Project will also support the Oceanic Society and its mission to conserve oceans. This charitable program will start on March 23 and will span a total of five weeks.
3). Docker Expands Broadest Orchestration Ecosystem to Ensure Distributed Application Portability
On Feb 26th, Docker announced to Expands Broadest Orchestration Ecosystem to Ensure Distributed Application Portability. It announced a significant expansion of its “batteries included but swappable” ecosystem to include over thirty working and proposed partner and community integrations. This ecosystem development overlap with the first downloadable versions of its orchestration tools that includes Machine Beta, Swarm Beta and Compose 1.1 – announced in December 2014 at DockerCon EU. The comprehensive set of orchestration capabilities is designed to empower developers and sysadmins to create and manage a new generation of 100 percent portable distributed applications. Seamless application portability in this context means that an individual developer can leverage the same orchestration tooling as the apps are built and shipped from dev to build to test.
4). Docker Acquires SocketPlane to Drive an Open Collaborative Networking Ecosystem
On March 4th 2015, Docker announced the acquisition of software-defined networking (SDN) startup SocketPlane to drive an open collaborative networking ecosystem. SocketPlane, which was founded in Q4, 2014 with a vision of delivering Docker-native networking, has been an active participant in shaping the initial efforts around Docker’s open API for networking. The
explicit focus of the SocketPlane team within Docker will be on collaborating with the partner community to complete a rich set of networking APIs that addresses the needs of application developers and network and system administrators alike.
Similar to Rocket, Docker is also an open source project which in some way or the other is controlled by the company behind it. Rocket is an effort to create a project that is “more open” and permits contributions from a much extensive community. Rocket’s main focus is to build a world where your application can be packaged once and ran in the environment that you choose. CoreOS believes that Rocket and a definition around the App Container is a necessary condition to achieve this kind of environment.
But still it’s far too early to tell whether Rocket’s container technology will catch fire the way Dockers’ did. Regardless, the pressure is on Docker to distinguish itself now that it has a competitor that seems to be coming out guns blazing. Despite the announcement, CoreOS will continue to ship Docker fully integrated in the operating system, and will continue to contribute and be present on the Docker governance board, where Brandon Phillips, co-founder and CTO of CoreOS, serves already.