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

This article mainly introduces "how to make CoreOS Rkt container image". In daily operation, I believe many people have doubts about how to make CoreOS Rkt container image. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to make CoreOS Rkt container image". Next, please follow the editor to study!

What exactly does the AppC specification agree on?

People who use open source software may not be in the mood to read the contents of various open source protocols carefully. Most users of container products are not necessarily interested in the contents of the container specification.

However, in order to better understand the relevant tools that will be introduced later, you might as well take a closer look at some of the AppC specification conventions. Its content can be summarized in four aspects, which are listed in turn below, and make a brief comparison with the current mainstream container Docker.

PS: strictly speaking, there is a difference between the words AppC and AppC Spec. The former refers to the App Container project of CoreOS, including specifications and related tools, while the latter refers specifically to the container specifications specified in AppC. However, in many places, especially in translated articles, it is often seen that these two words are mixed, so generally there is no need to pay too much attention to them.

1. The image format of the container

Essentially, a container image is a file archive that conforms to a specific directory structure. The contents of the image are expanded after the container is started, then copied into a separate namespace space, and the system resources that can be used by the container are limited by cgroup. When creating an image later, the image directory structure specified by AppC Spec will be described in detail. Just to point out here, the image of AppC does not support a hierarchical structure like Docker. This design simplifies some operations of the container runtime, but the drawback is obvious: the same part of the image cannot be reused. Therefore, it not only wastes the utilization of disk space, but also increases the transmission cost of container image in the network.

In addition to the structure of the directory, the image also needs a file that describes the contents of the image, which is called the "image property manifest file (Image Manifest)". The definition includes the author information of the image, the port exposed by the container, the exposed mount point, the required system resources (CPU/ memory), and so on. In addition, the attribute list of AppC Spec's convention also contains a lot of information needed for scheduling, such as other containers and container tags on which the container runs.

In this respect, the AppC image contains far more information than the Docker image. This is equivalent to including the Docker image itself, the Compose orchestration configuration, and some of the Docker running parameters.

In addition, the AppC specification also prescribes the method of generating mirror ID and signature. The role of mirrored ID and signature has been described in the previous Rkt article, and the method of generating mirror signature will be described in detail later.

two。 Mirrored distribution protocol

The distribution protocol is mainly about the type of protocol used for image download and the style of URL. AppC's mirror URL is in a format similar to Docker's domain.com/image-name, but the actual handling is somewhat different. In addition, when no domain name is specified, Docker will by default look for an image in the official DockerHub. The image of AppC does not have an "official source", so there is no such rule.

Rkt/AppC currently supports the following URL formats:

/

Https://

Http://

Docker://

The first is the image distribution URL recommended by AppC, which is a bit like Docker Repository, but is actually an abbreviation for the HTTPS protocol. AppC translates to the full URL address according to the domain name and path of the instruction, and then downloads the specified image.

The second method is equivalent to importing a local image. It is worth mentioning that even if a local image is used, AppC also requires the image to have signature authentication, and the details of the signature file will be discussed in detail later.

The third and fourth methods are to obtain the image directly through the full URL. It is not recommended to use the naked HTTPS URL directly in the specification, because this arbitrarily named image address is not conducive to the management and unification of the image. In particular, the URL of the HTTP protocol should only appear in the private network environment.

The fifth approach is not the type of protocol supported by the AppC specification, which is currently supported by Rkt (essentially HTTP or HTTPS). For URL that is compatible with Docker image, you only need to add docker:// in front of it, and it will be automatically converted to AppC image format after download. Since signature verification is not supported in Docker's image repository, users need to add a parameter to display when using this kind of URL-insecure-skip-verify allows the use of unauthenticated image sources.

3. The arrangement structure of the container

The container orchestration and cluster description in the AppC specification is very similar to Kubernetes and is described by the Container Group property Checklist File (Pod Manifest). It follows the concepts of Kubernetes, such as Pods and labels, which are used to plan and manage scheduling policies in clusters.

Pods literal translation is "pod", which refers to a collection of containers composed of a series of interrelated containers that can provide independent service functions. For example, containers for data collection functions, caching services, and search services are combined to expose to external users as a complete data query service provided by Pod. Pod can be provided to the cluster manager as a separate collection of containers participating in cluster scheduling. In cluster management models such as Kubernetes, Pod is actually the smallest unit for service scheduling across nodes.

Labels is used to mark containers with the same kind of characteristics, which provides a very flexible strategy for container filtering and selection. Many cluster managers are able to filter the Pods using the selected tag when scheduling.

Considering the background of the cooperation between CoreOS and Google (the Tectonic CaaS platform has been launched), this design provides a good technical basis for the deep integration of Kubernetes with containers that conform to AppC specifications in the future.

4. Container actuator

An executor is also a container tool like Rkt. This section specifies the principles and functions that should be followed in designing AppC Spec-compliant container executors.

For example, a unique UUID; must be provided for each container at least one local Loopback Nic and 0 or more other TCP/IP NICs must be provided in the context of the container's operation; details such as the logging of the programs in the container to Stdout and Stderr should be printed and displayed.

It also details how the executor should handle many of the attributes in the list of mirror attributes. These contents can only be used as a reference for most users, or need to be based on the specific implementation of the container product documentation.

Mirror tool

In addition to a wide range of specification documents, a number of demonstration tools related to AppC mirroring are provided in AppC's project. Unlike Docker, which integrates all functions with one command, each of these tools focuses on some aspect of the container's functionality. For example, the production of general type images, packaging, format conversion and the production of specific types of images.

At present, the existing tools include:

Actool-for image construction and verification

Docker2Aci-used to convert Docker exported images to AppC images

Goaci-An one-click packaging and build image tool for projects in the Golang language

Acbuild-build the image by instruction

Among them, Actool and Acbuild are both tools for image construction, and their differences are similar to building images through docker commit and Dockerfile. It should be pointed out that the Acbuild project, which was established not long ago, is still a plan and has not released any actual available version, which is intended to replace another previous project, baci. The latter is no longer available and is no longer updated.

The role of Goaci is to get the specified path of the project, automatically compile, and then make the compiled executable into an image, all these operations can be completed with only one command: goaci, the project path supports all the code hosting sites supported by go get commands, including BitBucket, GitHub, Google Code and Launchpad, etc. However, it can only be used for open source projects that use the Golang language and are hosted on the above site. It does not have universal applicability.

Actool and Docker2Aci are two tools that will be highlighted below. For the convenience of non-CoreOS users, the installation methods of these tools in other 64-bit Linux distributions will also be introduced.

The production of mirror image

The tool associated with image creation is Actool, which is pre-installed on a newer version of the CoreOS system and can be verified and obtained as an Actool version through the actool-help command. Other users of 64-bit Linux can install it with the following command:

Wget https://github.com/AppC/spec/releases/download/v0.5.2/AppC-v0.5.2.tar.gztar zxf AppC-v0.5.2.tar.gzsudo mv AppC-v0.5.2/actool / usr/local/bin/

Speaking of building images, as mentioned earlier, Acbuild, the new imperative build image tool, has not yet released any available version. Therefore, the current situation is that to build an AppC image, you can only manually create the image property manifest file, copy the files needed in the container, and then package directly to generate the image. Simply, in addition to losing benefits such as "infrastructure is code," creating an image in this way is not much to blame, and the building process itself is not complex.

Let's make a very simple AppC container image that contains only one executable file.

First, create a working directory for making images, such as AppC-image:

> mkdir AppC-image

Next, to make this example simple enough, we need a program that can run independently without relying on any external dynamic libraries or runtime environments. Let's write a "Hello World" in C language. Create a new file called hello.c, which reads as follows:

# include int main (int argc, char* argv []) {printf ("Hello AppC\ n"); / / output anything return 0;}

Then, you need a C language compiler, which some Linux systems already have, which can be verified with the gcc-- version command. If it is not installed, then. It's up to you. For example, under the Ubuntu system, you can obtain it through apt-get:

Sudo apt-get install gcc

The CoreOS system is a little more cumbersome and needs to be done with an extra container. As a hint, Docker has an official image of the CAccord Clipper + language runtime called gcc. You can get it by docker pull gcc or rkt-- insecure-skip-verify fetch docker://gcc, and then start a container. Note that you need to map a Volumn to the host to facilitate copying the generated executable program after compilation.

The compiled commands are as follows, in which the-static parameter is required, otherwise the compiled program will need to rely on external dynamic libraries for execution:

Gcc-- static-o hello hello.c

Create a new directory called rootfs in the working directory and copy the compiled hello executable file into it. The contents of this rootfs directory are the contents of the files contained in the container in the future, so it is recommended to establish some standard directory structure in it, such as / bin directory, and put executable programs in this directory.

Mkdir-p AppC-image/rootfs/bincp hello AppC-image/rootfs/bin/

Now the directory structure of the mirror has been formed. Now you can start to create a property manifest file for the image, and create a new file named manifest in the working directory, as follows:

{"acKind": "ImageManifest", "acVersion": "0.5.2", "name": "my-app", "labels": [{"name": "os", "value": "linux"}, {"name": "arch", "value": "amd64"}] "app": {"exec": ["/ bin/hello"], "user": "0", "group": "0"}}

At this point, the file structure in the working directory should look like this:

AppC-image ├── manifest └── rootfs └── bin └── hello

Finally, you can use the actool command to build the image:

Verification of actool build AppC-image hello.aci image

There are only two sources of container images: local or remote.

Therefore, the verification of the image consists of two parts.

Verify that the local file conforms to the image of the AppC specification

Verify that the remote URL is a valid AppC mirror address

In the former case, as mentioned earlier, a container image is actually a packaged file that conforms to a certain standard structure.

$file hello.acihello.aci: gzip compressed data

In the AppC specification, the suffix name of an image file should be .aci, but a package file with this suffix name is not necessarily the correct image. Therefore, a method is needed to verify the correctness of the image file, and the corresponding command is actool validate.

When executing this command directly, actool will only indicate the result of verification by the return value of the command, and return 0 to indicate that the verification is passed:

$actool validate hello.aci$ echo $? 0

You can add the-debug parameter to have actool print the results directly on the console:

$actool-debug validate hello.acihello.aci: valid app container image

In the latter case, URL verification can also be done through the actool tool, and the corresponding command is actool discover.

This command returns the actual download address of the image:

$actool discover coreos.com/etcdACI: https://github.com/coreos/etcd/releases/download/latest/etcd-latest-linux-amd64.aci, ASC: https://github.com/coreos/etcd/releases/download/latest/etcd-latest-linux-amd64.aci.ascKeys: https://coreos.com/dist/pubkeys/aci-pubkeys.gpg

Try the Docker image address used in Rkt and you will find that this address is invalid.

$actool discover docker://ubuntuerror fetching docker://ubuntu: Get https://docker?ac-discovery=1: dial tcp: lookup docker: no such host

This also confirms that as mentioned earlier, the docker:// protocol is only an additional image acquisition method supported by Rkt, not a standard protocol in the AppC specification.

Conversion of mirror image

The specification makers of AppC clearly know which wheels should be rebuilt and which wheels can be reused directly. At a time when all kinds of Docker images are overwhelming, the best way for a new container tool to accumulate the number of images as quickly as possible is to be compatible with Docker images or convert Docker images.

In fact, the new standards have different approaches to the issue of image compatibility. Red Hat's Nulecule chooses to support Dockerfile format. You only need to add some additional configuration files to the existing image code and rebuild it again. AppC has made the same attempt (there was a baci project that did this, but it has not been updated), the effect is somewhat different, so it is more straightforward, providing a tool that allows any Docker image to be exported and directly converted to its own image format.

Let's talk about the conversion from Docker to AppC images, and the corresponding tool is Docker2Aci.

This tool is not preinstalled on either Ubuntu or CoreOS, so it needs to be installed separately. The tool has not yet been officially released, so no compiled binaries are officially available, and it can only be compiled from source code. Fortunately, the compilation of the Golang language is relatively friendly. If the local development environment of the Golang language has been installed, the whole download and compilation process can be completed directly through the go get github.com/AppC/docker2aci command.

Considering that most users do not have a Golang development environment, another relatively simple approach is through the container. Because Docker has officially provided a container image for Golang development, which is called golang. Compilation can be done with the following command.

Sudo docker run-v $(pwd): / pkg-I-t golang:1.4 / bin/bash-c "go get github.com/AppC/docker2aci; cp\ $GOPATH/bin/docker2aci / pkg/"

The compiled docker2aci binaries are copied to the current directory and placed in any directory indicated by the system variable PATH, such as:

Sudo mv docker2aci / usr/local/bin/

Execute the docker2aci-- version command to print out help for the use of the software to prove that it has been successfully installed.

$docker2aciUsage of docker2aci:docker2aci [--debug] [--nosquash] IMAGE Where IMAGE is [--image=IMAGE_NAME [: TAG]] FILEPATH or docker:// [REGISTRY URL /] IMAGE_NAME [: TAG] Flags:-debug=false: Enables debug messages-image= "": When converting a local file, it selects a particular image to convert. Format: IMAGE_NAME [: TAG]-nosquash=false: Don't squash layers and output every layer as ACI

Export a Docker image, which can then be converted to an AppC image through the docker2aci command.

$docker pull ubuntu$ docker save-o ubuntu.docker ubuntu$. / docker2aci ubuntu.docker... ... Generated ACI (s): ubuntu-latest.aci

The converted image is saved in the current directory and automatically named in the "-" format.

In addition, what is more practical is that docker2aci also supports URL of docker:// protocol to directly obtain images on the Internet.

$docker2aci docker://busybox... ... Generated ACI (s): signature of busybox-latest.aci image

At this point, if you run the hello.aci image you just created with Rkt, you will find that Rkt prompts you to refuse to run the image because you cannot find a valid signature file.

$sudo rkt run hello.acierror opening signature file: open / home/core/hello.aci.asc: no such file or directory

Mirror signature is a mirror source verification mechanism introduced by AppC, which is essentially a standard digital signature using asymmetric encryption. By encrypting the private key of the mirror provider and the image file itself to produce a set of signature strings, the public key provided by the publisher can unlock the string of characters and get the information that matches the mirror. In this way, you can verify whether the image really comes from a particular author or source.

The standard signature algorithm of AppC is RSA, which is implemented by open source GPG. Refer to this article for a detailed introduction to GPG.

First, prepare a key configuration file, named gpg-batch, with the following contents:

% echo Generating a default keyKey-Type: RSA Key-Length: 2048Subkey-Type: RSA Subkey-Length: 2048Name-Real: your English name Name-Email: your email address Name-Comment: ACI signing keyExpire-Date: 0Passphrase: signature password% pubring rkt.pub%secring rkt.sec%commit%echo done

Then generate a key pair with the following command:

Gpg--batch-- gen-key gpg-batch

When the execution is complete, two more files, rkt.sec and rkt.pub, will be added to the directory, which is the private key and public key.

You can then use this pair of keys to sign the image:

Gpg-no-default-keyring-armor-secret-keyring. / rkt.sec-keyring. / rkt.pub-output hello.aci.asc-detach-sig hello.aci

When prompted for a password, enter the password set in gpg-batch. Then you get the signature file hello.aci.asc of the hello.aci image.

Try running the container again:

$sudo rkt run hello.aciopenpgp: signature made by unknown entity

The error of this prompt is that although the signature file has been found, the source of the signature is not in the trust list. To add the signature to the trust, first export the binary key file, rkt.sec and rkt.pub, as a text public key file.

Gpg--no-default-keyring-- armor-- secret-keyring. / rkt.sec-- keyring. / rkt.pub-- export mailbox in gpg-batch > pubkeys.gpg

Then add the public key in this text file to Rkt's trust list.

$sudo rkt trust-root pubkeys.gpgPrefix: "" Key: "pubkeys.gpg" GPG key fingerprint is: 37E2 6071 5382 5868 5A0D 1356 98A9 5E24 6E19 7AED Subkey fingerprint: 46AF 81E4 77D4 BFCA DFCE 73C6 3D94 79C2 2611 F243 Kelsey Hightower (ACI signing key) Are you sure you want to trust this key (yes/no)? YesTrusting "pubkeys.gpg" for prefix ".added root key at" / etc/rkt/trustedkeys/root.d/37e26071538258685a0d135698a95e246e197aed "

By running the container this time, you can see that the Hello program in the container has been executed correctly.

$sudo rkt run hello.acirkt: signature verified: Kelsey Hightower (ACI signing key) Hello AppC image repository

Finally, a brief introduction to AppC's image repository (Image Repository).

The AppC specification defines the URL to obtain the image, which is roughly in the form of domain name / image path: version, for example, the image provided by CoreOS containing Etcd can be obtained by using the command rkt fetch coreos.com/etcd:v2.0.9.

There are only two interesting places here.

First of all, there is no so-called "official image repository" in AppC, so the domain name section of URL will always exist. The images provided by CoreOS are placed in a normal warehouse under the coreos.com domain name. This is also in line with the original intention of the openness of the AppC standard.

Second, AppC parses the user's URL attempts in two ways. In other words, there are two ways to implement an image repository. The first method requires almost no additional configuration work. You can put the image under the corresponding path of the domain name according to certain naming rules, such as coreos.com/etcd:v2.0.9. If you use the first method to build a repository, the corresponding image should be saved in https://coreos.com/etcd-v2.0.9-linux-amd64.aci (of course, the image of CoreOS is actually the second way, so this path does not exist). The second approach is more flexible, but requires additional programs to handle the mapping of mirror addresses, and the specific process is not detailed.

In addition, as mentioned earlier, for a private network environment, you can directly use the HTTP path to obtain the image. For example, put the previously created image file hello.aci and signature file hello.aci.asc into a directory, and then start a simple HTTP service in this directory:

$python-m SimpleHTTPServerServing HTTP on 0.0.0.0 port 8000.

You can download the image directly using HTTP on any other host.

$sudo rkt fetch http://:8000/hello.aci... ... Downloading ACI: [] 1.26 KB/358 KBsha512-f7a2feff02a07ed7c604c14133b7aede

This incomparably crude approach may be a boon to the lazy, but it is weak in terms of security and the manageability of the mirror version. This shows from one side that some convenient channels provided for developers may bring great hidden dangers if there are no normative constraints. In practical application, it is recommended to follow the URL parsing specification of AppC to design the warehouse.

At this point, the study on "how to make CoreOS Rkt container images" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.