With the release of Rocket 0.2.0, CoreOS hints that its developers are trying to learn from Docker's legacy.
CoreOS, makers of the Docker-powered superminimal Linux distribution, turned heads and rattled eyeteeth when it announced an alternative container technology.
Amid arguments both for and against CoreOS' App Container and Rocket, a new revision -- Rocket 0.2.0 -- surfaced late last week and brought with it a clearer idea of how CoreOS wants the new App Container format to embody simplicity and security by default.
In a blog post last Friday, Jonathan Boulle of CoreOS announced new features for Rocket 0.2.0 and new details for the still-evolving container spec used by Rocket. The client now has a number of lifecycle commands for checking and disposing of containers, as well as a signature validation mechanism, "a small but important step towards our goal of Rocket being as secure as possible by default," Boulle wrote.
That last feature -- and its implementation this early in Rocket's lifecycle -- is meant to contrast with Docker's approach to container signatures and validation. Docker originally offered little in the way of verifying container integrity and didn't add more rigid features for verifying signatures until version 1.3, released last October. CoreOS, however, perhaps learning from Docker's history, is building integrity-guaranteeing functionality into Rocket as early on as possible.
CoreOS is also trying to ensure that at least as much work is done around the App Container (appc) spec, rather than only the client itself (an implementation of the spec). The spec "continues to evolve but is now stabilizing," and two new implementations have also surfaced: jetpack (for executing appc containers on FreeBSD) and libappc (a C++ library for appc).
The single biggest challenge that CoreOS faces with App Container and Rocket isn't to make it a point-for-point technological match for Docker or even a superior project from a technical standpoint. Both Docker and App Container/Rocket are open source projects, so rapid evolution and keeping abreast of other developments are par for their respective courses.
Rather, the challenge is in how Docker has managed -- in a startlingly short time -- to generate a large culture of related third-party software, tools, and platforms. Making current Docker-powered services and Docker-centric tools support Rocket/App Container is more than a technical decision; the demand and tangible benefits have to be there. CoreOS may be able to accomplish some of that through its existing following, but little question remains that Docker is still the default for most people considering containers.
Read More News :- Techies | Update Or InfoWorld
Amid arguments both for and against CoreOS' App Container and Rocket, a new revision -- Rocket 0.2.0 -- surfaced late last week and brought with it a clearer idea of how CoreOS wants the new App Container format to embody simplicity and security by default.
In a blog post last Friday, Jonathan Boulle of CoreOS announced new features for Rocket 0.2.0 and new details for the still-evolving container spec used by Rocket. The client now has a number of lifecycle commands for checking and disposing of containers, as well as a signature validation mechanism, "a small but important step towards our goal of Rocket being as secure as possible by default," Boulle wrote.
That last feature -- and its implementation this early in Rocket's lifecycle -- is meant to contrast with Docker's approach to container signatures and validation. Docker originally offered little in the way of verifying container integrity and didn't add more rigid features for verifying signatures until version 1.3, released last October. CoreOS, however, perhaps learning from Docker's history, is building integrity-guaranteeing functionality into Rocket as early on as possible.
CoreOS is also trying to ensure that at least as much work is done around the App Container (appc) spec, rather than only the client itself (an implementation of the spec). The spec "continues to evolve but is now stabilizing," and two new implementations have also surfaced: jetpack (for executing appc containers on FreeBSD) and libappc (a C++ library for appc).
The single biggest challenge that CoreOS faces with App Container and Rocket isn't to make it a point-for-point technological match for Docker or even a superior project from a technical standpoint. Both Docker and App Container/Rocket are open source projects, so rapid evolution and keeping abreast of other developments are par for their respective courses.
Rather, the challenge is in how Docker has managed -- in a startlingly short time -- to generate a large culture of related third-party software, tools, and platforms. Making current Docker-powered services and Docker-centric tools support Rocket/App Container is more than a technical decision; the demand and tangible benefits have to be there. CoreOS may be able to accomplish some of that through its existing following, but little question remains that Docker is still the default for most people considering containers.
Read More News :- Techies | Update Or InfoWorld
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment