Containers are taking over the world. From VPSs to application hosting, more and more companies now use container technologies such as Docker, LXC and OpenVZ. The latest entrant to this list is rkt, pronounced as rocket.

What is Rocket (rkt)?

rkt is a container system developed by CoreOS as a light weight and secure alternative to Docker. It is built based on an open container standard known as “App Container” or “appc” specification. This allows rkt images to be portable across many container systems (such as Kurma, JetPack, etc.) that follow the “appc” open format.

Let’s see all that’s different in a bit more detail:

How is rkt different from other containers?

Secure by design = Better for production deployment

Containers are basically glorified user groups. A set of processes of one user cannot view another user’s processes. All’s well and good as long as users do not execute kernel exploits.

In some systems such as Docker, if a user can break out of a container using a kernel exploit, the attacker can control the whole physical server and any attached data store. Of course, Docker can be secured to prevent a user breaking out, but that’s “additional” security, which requires time and effort.

In contrast, rkt runs containers as un-privileged users, so that even if a user breaks out, they cannot affect other containers or take control of the server. Further, rkt allows cryptographic signature checks on downloaded images so that only trusted containers can be run on the server.

Light weight design = Good for application packaging

To run an application such as WordPress, you need only a web server and a database server. There’s no need for cron schedulers, print servers or bluetooth managers. But when you use a “full system container” such as LXC or OpenVZ, that’s exactly what you get – A full server instance that uses more resources than is required.

By comparison, rkt just runs only those processes that are absolutely required by the app. In that aspect it is comparable to Docker or runC. By minimizing the number of processes, resource utilization can be maximized in the servers, and it is easier to put all application dependencies into a small image and ship it to any server, anywhere.

Portable image format = Easier to switch to a better container system

New container systems come out all the time. What if tomorrow there’s a better container technology than rkt? No problem. As long as the new technology follows the open source container format known as “appc”, all the images created for rkt can be run on that one.

By adhering to an open standard, rkt doesn’t enforce a vendor lock-in. This helps system owners migrate painlessly to another container system that suits their requirements better.

Pluggable feature set = More choice of features from different sources

Your business needs differ from another’s. It extends that the choice of features you need in your container system may not be the same as another’s. This is where systems such as Docker have an issue. All features are built into one big program, and everything is developed by one provider. There are two issues with this:

1. The bigger the program, the greater the chance for a bug, and more the chance of a security incident.
2. There’s a limit to the number of features that can be imagined and developed by a single provider. So, the feature set will always be lesser than an “open” alternative.

rkt uses a pluggable architecture whereby multiple providers can add their specialist capabilities to an rkt container system. For eg. rkt can be enabled with “Intel Clear Container” support. This then delivers hardware level isolation to each container, thereby enhancing the security comparable to true virtualization systems like VMWare.

As time goes on, more vendors can add more features, helping users of rkt to pick and choose only what’s critical to their business, and keeping their vulnerability footprint small.

Should you use rkt?

As with any other software system, there’s no absolute answer to this question. If you have already invested well into a Docker system, and have locked it down tight, you don’t have a reason to switch. But if you are planning on moving away from traditional dedicated servers to a virtualized system rkt might be worth checking out.

Either way, it is important to know that site reliability is dependent on how well you are able to predict production system fault points, and design system redundancies to counter it. A knowledge of pros and cons of competing technologies can come in handy while designing such a system.

Bobcares helps business applications achieve world-class performance and uptime, using tried and tested server architectures. If you’d like to know how to make your server infrastructure and operations more efficient, we’d be happy to talk to you.