Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to install Rkt in 64-bit Ubuntu". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The past Life and present Life of Rkt

As a young application container rookie, open source Rkt is not alone in the fight, behind it is a huge community force that seems to be in order.

Birth background

The original sponsor of the Rkt project is CoreOS.

CoreOS and its core product CoreOS operating system are the earliest enterprise users of Docker, accompanied by Docker from the initial version 0.1 to the official release of version 1.0. At first, the two promoted each other and cooperated very well. However, as the dominant trend of Docker in the container industry is becoming more and more obvious, the ecology around it has gradually developed from simply building containerized application services to a top-down cluster specification system, and even partially replaced the service process scheduling of the operating system. This bloated container specification, which is unilaterally controlled by Docker, is not popular with CoreOS systems, and they want a more open and neutral container standard.

In December 2014, CoreOS announced its own container plan, and a few months later, combined with the container practice in the community, began to develop a new open application container specification, and Rkt continued to develop as a concrete implementation of this specification.

AppC standard application container specification

The full name of AppC is "Application Container Specification (Standard Application Container Specification)". The purpose of this specification is not to serve a specific Linux system environment, but to formulate a set of container virtualization specifications that do not depend on specific platforms, technologies, operating systems and programming languages, so as to solve the crisis of incompatibility and closed development of enterprise container products, and prevent the emergence of more technical barriers.

The design goals of the AppC container specification under development include:

Component tools: operational tools for downloading, deploying, and running virtual container environments should be independent, independent, and replaceable.

Image security: images should use encryption protocols when downloading and transmitting on the Internet, and container tools should have built-in authentication mechanisms to reject images from insecure sources.

Operation decentralization: image distribution should support scalable transport protocols. P2P or even BitTorrent protocols will be allowed to improve the efficiency of image distribution in the future, and containers should not need to log in to specific image repositories before use.

Open standard: the format and metadata definition of container images should be uniformly negotiated by the community, so that different container products that meet this specification can share image files.

In order to ensure the openness of the specification and take into account the interests of many parties, CoreOS is the advocate, participant and implementer of the specification, but it will not be the only one who makes it.

At present, there are AppC-compliant open source application containers in addition to Rkt, Jet Pack for the FreeDBSD platform and Nose Cone for the Linux platform implemented through C++. Better versatility, less intrusiveness, and higher openness, it is precisely because of the ingenuity of these AppC specifications that it brings a gust of breeze to the industry at the height of Docker, causing many technical players and enterprises to stop and think.

Use Rkt container to taste fresh

No matter what the future development of AppC will be, distant water will not quench your thirst. Since the Rkt container itself is open source and free, why not try it yourself.

As a model project for open container standards, Rkt will not be used only in CoreOS's own systems. Like Docker, Rkt is pre-installed on CoreOS systems, but it can be installed and used by any other Linux distribution. In the next section, we will take the more common 64-bit Ubuntu system as an example to demonstrate the installation and use of Rkt.

Install Rkt in 64-bit Ubuntu

In fact, in any 64-bit Linux of Intel architecture, installing Rkt is extremely simple. Thanks to the native static compilation of the Golang language, almost all compiled Golang programs can be downloaded and run without installing additional dependencies.

The packaged Rkt binaries can be downloaded directly from the GitHub website, and the latest version is v0.5.4. Rkt only provides a 64-bit compiled version, and although 32-bit executable files can be obtained by compiling the source code by yourself, running Rkt on 32-bit systems is not officially recommended and supported.

Wget https://github.com/coreos/rkt/releases/download/v0.5.4/rkt-v0.5.4.tar.gz

Download and get a compressed file. And then, uh, decompress it.

Tar xzvf rkt-v0.5.4.tar.gz

Put all the extracted files into the executable directory of the system, and the installation is complete.

Sudo cp rkt-v0.5.4/* / usr/local/bin/

Next, try to execute the rkt version command without any parameters from the command line, and you can see that the program returns the version information of the Rkt tool and the AppC standard, indicating that Rkt has been installed correctly.

Composition of the $rkt versionrkt version 0.5.4appc version 0.5.1+gitRkt tool

If you want to do good work, you must first sharpen its tools. Before we installed Rkt, we threw the unzipped files into the system directory before we had a chance to take a look. Although this kind of deployment is convenient, it is also simple and rough. Now that you're done with the installation, at least look back at what's available in this directory.

However, this look is simply disappointing, such a large compressed package, there are only two files inside.

$ls rkt-v0.5.4rkt stage1.aci

The first file has just been tried, it is the main program of the Rkt container, and all commands that operate on the container will use this command as an entry. And the second document is a very clever design. First of all, its aci suffix indicates its identity and is a standard AppC image. If you unpack this image, you will see that it contains a complete systemd runtime environment. In fact, its function is to provide replaceable container virtualization implementation components for Rkt.

By default, the Rkt container uses a systemd-nspawn command-based mechanism to handle kernel cgroup and namespace-related operations, and this part is the core part of providing the entire container virtualization capability. Rkt supports extending other virtualization implementations (such as novm or qemu-kvm) by separating these functions into a container that can be quickly plug-in and replaced, and can quickly switch between these implementations. Specifically, you can only specify the-- stage1-image parameter when running the container and set it to the image address of other virtualization implementations that meet the requirements.

In addition, the AppC specification provides a set of tools for making and transforming "AppC container standards-compliant" images, which will be detailed in the second part of the series.

Permissions and image signatures

At this stage, Rkt must also execute most commands through root users, but in the future it is planned to support running with ordinary users like Docker. If a "permission denied" error occurs when running the Rkt command, check to see if you have forgotten sudo.

Most users who use Docker are more accustomed to finding a mirror address on the Internet and then pull it directly. Therefore, even if Docker officials find some malicious image publishers, it can not effectively stop the spread of these images in the network.

In the AppC specification, special emphasis is placed on the security of images. For this reason, by default, all images must explicitly add the signature trust of the image publisher before downloading and running, to ensure that the source of the image will not be forged. The following command gets the signature information with the prefix "coreos.com/etcd" from the official repository and adds it to the local trust list.

$sudo rkt trust-prefix coreos.com/etcdPrefix: "coreos.com/etcd" Key: "https://coreos.com/dist/pubkeys/aci-pubkeys.gpg"GPG key fingerprint is: 8B86 DE38 890D DB72 9186 7B02 5210 BD88 8818 2190 CoreOS ACI Builder Are you sure you want to trust this key (yes/no)? Yes

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.