[CoreOS Reprint] CoreOS Practice Guide (i)

Reprint: http://www.csdn.net/article/2014-12-29/2823356

Summary: The CoreOS is a highly streamlined system core and a custom built-in operating system. ThoughtWorks's software engineer Linfan will bring the "Walk the Cloud: CoreOS Practice Guide" series of articles on CoreOS's essence and recommended practices. This article is based on the first article: CoreOS Overlook.

"Editor 's note" Both Docker and CoreOS are excellent "graduates" of the Silicon Valley entrepreneurial incubator, which is said to have a good personal relationship with two bosses, Docker as a container engine, CoreOS for container management, and a very enjoyable collaboration, just as Rocket's release gradually "parted". Although Docker and CoreOS are all seeking "Jane", but Docker's "Jane" is to strive for the user to achieve the simplest use, CoreOS "Jane" is the pursuit of the ultimate light weight, which will be the future of container technology, in fact, it is difficult to say. Today, Linfan, a software engineer from ThoughtWorks, will bring a series of articles "Walk the Cloud: A CoreOS Practice Guide", with an understanding of the essence of CoreOS and recommended practices. This article is based on the first article: CoreOS Overlook.

Author Profile:

Linfan, an IT siege lion born in Gen Y, thoughtworks Chengdu Office Cloudops team member, usually likes to study devops-related applications in his spare time and is currently preparing for AWS Certification and promotion of Docker-related technologies.

Introduction

It is believed that many people are beginning to understand that CoreOS is a news from the end of July 2014: The operating system of the built-in Docker container Coeros released its first official stable version. In the six months after that, CoreOS all the way. Mid-August CoreOS acquisition of private Docker warehouse service provider quay.io,9 Digitalocean and CoreOS reached a strategic cooperation, at the end of September, Microsoft Azure Cloud service began to support CoreOS system mirroring, mid-October, the UK's leading cloud provider Brightbox also joined the support Cor The EOS system Image faction, along with the world's leading cloud service providers that have previously supported CoreOS mirroring, including Amazon's AWS, cloud giants Rackspace and Google computer Engine,coreos, are everywhere.

As a more than a year old operating system (the first release in March 2013), CoreOS in the cloud-related open source community and large-scale server clusters are already emerging, directly competing with the mainstream Linux server operating system. As for the later Redhat offering built-in container management Services system Atomic, and canonical just launched Ubuntu Core, gradually set off the tide of Containerops, a brand-new cluster operation and maintenance era is open. And the CoreOS is the pioneer of this trend, it is not just "another Linux distribution", but a subversion of the concept of the times.

This series of tutorials will start with the most basic concepts, along with large-scale cluster management and application containerized these two main lines to understand the unique features of the CoreOS system, so that users who have not contacted the system can also quickly understand the essence of the function and recommended practice methods.

What is CoreOS?

Simply put, it's a lightweight Linux distribution based on Chrome OS re-customization.

As an operating system, CoreOS uses a highly streamlined system core and peripheral customization to implement many features that would otherwise require complex manual operations or third-party software support at the operating system level, while eliminating other non-core software for server systems, such as the GUI and package manager.

In particular, CoreOS's attitude to the package manager and the native support for Docker are particularly noteworthy. This is the most unaccustomed place for many users who are accustomed to the traditional Linux management approach when they first touch CoreOS, because CoreOS does not offer ready-made package management tools. A typical puzzle is that installing software in CoreOS is too inconvenient. In fact, CoreOS does not encourage users to install a variety of applications directly on the operating system, but instead advocates that all services be run in a separate application container, where the application container provides the basic functional environment required by the application. This approach separates the operating system and application responsibilities more thoroughly, reducing the coupling between the operating system and the application, so that the companies running these servers can update their online business more quickly and cheaply.

CoreOS Walking in the clouds

It's no exaggeration to say that CoreOS is a cloud-born operating system.

This "Born for the Cloud" contains two meanings:

1. First of all, CoreOS's design standpoint fully considers the distributed deployment of cloud ecosystems, large scale scaling (scaling) requirements, and we will be fully aware of this in the following content;
2. On the other hand, CoreOS has a considerable reliance on specific cloud environments, and its start-up configuration service cloud-init needs to be highly customizable, CoreOS officially provides vagrant, VMWare, AZure, AWS, RackSpace A custom version of a virtual machine or a cloud service provider, so local CoreOS installed directly via ISO will not be able to obtain cloud-init-related functionality, such as cluster self-discovery and fleet cross-host management.

CoreOS's user Experience

CoreOS's core ideas come from the user experience of Chrome: Quick Start, background updates, seamless updates across versions, a separate sandbox for each tab, a quick fix for a single tab crash, and an entire browser that doesn't crash because of a single sandbox process. On the server, imagine moving a service that is hosted in an application container from one server to another, as simple as dragging the Tab page from one browser to another using the mouse. And these are the experiences that CoreOS want to bring to every user.

• Faster start-up speed

Because light, so fast. As the product of the server of modern network, the CoreOS team has made the biggest simplification to this server operating system, the result not only makes the system and the application highly separate, but also obtains the great boot speed promotion. According to official data, the system runs with only 114M memory usage ( author Note: This is official data, measured in the vagrant environment only about 80M, less than propaganda), only a few more than half of the common Linux Server system (about 60%).

In addition, CoreOS uses the SYSTEMD developed by MAC system LAUNCHD as the default system boot and Service Manager (CentOS 7 also uses SYSTEMD to replace the previous SysV boot service). Compared with SysV, Systemd not only can better track the process of the system, but also has excellent parallelization capabilities, coupled with the characteristics of on-demand startup, and combined with the rapid start-up capabilities of Docker, in the CoreOS cluster large-scale deployment of Docker Containers The performance advantage over other operating systems is more pronounced.

• Smooth Version Upgrade

Traditional server operating systems, including most Linux distributions, will be replaced every few years. During this time, developers will continue to use security patches and updates to improve the system, but will not be particularly large changes, and eventually the operating system and the software on it will slowly become rigid. But CoreOS's idea is to be a ready-to-be-updated operating system that itself does not have the concept of a cross-release version upgrade, but instead uses an upgrade channel like the Arch Linux (update channels) and a rolling Update method, The system can be upgraded directly to the latest release version at any time. Even during the entire update process, the operation of the application is not interrupted. With CoreOS, the infrastructure is automatically upgraded, just like a Chrome browser upgrade without the user's worries.

CoreOS has two system partitions (dual root partition are translated into a dual-boot partition, which should actually be a system partition, including directories such as/bin/sbin/lib, which are read-only). Two partitions are set to active mode and passive mode respectively and perform their duties during system operation. The active partition is responsible for system operation, and the passive partition is responsible for system upgrade. Once a new version of the operating system is released, a full system file will be downloaded to the passive partition, and the original passive partition will be switched to the active partition when the system is restarted from the new version partition, and the former active partition is switched to the passive partition. In this process, the updated machine does not need to be removed from the load cluster. Also, to ensure that other applications are not interrupted, CoreOS will limit the hard drives and network I/O during the update process through the Linux cgroups.

It is worth mentioning that, unlike traditional Linux servers, the CoreOS system partition is designed to remain read-only during system operation, which ensures the security of the CoreOS and further reflects the CoreOS's attitude of not wanting the user to install the application directly on the operating system. At the same time, the highly consistent system kernel and the perimeter application version in the cluster simplifies the operational complexity of the version issue, making it easier to maintain the operating system itself.

• Application containerized

In CoreOS, all applications are installed in a Docker container, which is like a container of software code, running on the operating system through the simplest interface. This means that they can be easily transferred between the operating system and the computer, like carrying a box on a ship and a train, and it also means that the operating system can be updated without interrupting the application.

Docker is becoming increasingly popular when developers deploy applications to the cloud infrastructure. By providing computing resources to applications through containerized (containerized) computing environments, applications share system cores and resources without interfering with each other's operations. Failure of a single container can be quickly repaired, and application failures within the container will not cause the entire system to crash. The idea is the same as the browser sandbox.

Distributed System Services for CoreOS

Cloud issues, mostly from centralized to distributed thinking mode of transformation, distributed services, distributed deployment, distributed management, distributed data storage ... And these are all part of the CoreOS to the server revolution.

To address these distributed thinking issues at the system level, the CoreOS team provides important tools to help users manage CoreOS clusters and deploy Docker containers.

• Cloud-init

at system startup, CoreOS reads a platform-customized user profile (called Cloud-config) to complete the initialization configuration of the system. With the information in the configuration, the new startup CoreOS Server initializes the necessary service processes and automatically discovers and specifies additional server interaction information for the cluster and then joins the cluster. This cluster-based "self-discovery" organization makes cluster management simple and efficient.

Typically, the Cloud-config configuration file should include at least the cluster communication address to which the server belongs, as well as the parameters for starting the services required by ETCD and fleet. Users can add more customized services to the configuration as needed, enabling the node to run as a fully functional cluster member as soon as it is started.

• Etcd

In the CoreOS cluster, the ETCD is in the skeleton position. ETCD is a distributed key/value storage service that CoreOS programs and services in a cluster can share information or service discovery through ETCD. ETCD is based on a well-known raft consistency algorithm: To synchronize data by electing leads through the server in the form of an election, ensuring that the information within the cluster is always consistent and available. The ETCD is installed in the default form in each CoreOS system.

Under the default configuration, ETCD uses two ports in the system: 4001 and 7001, where 4001 provides external applications to read and write data in Http+json form, while 7001 is used to synchronize data between each ETCD. Users can further ensure the security of data information by configuring CA cert to allow ETCD to read and write data in an HTTPS manner.

• Fleet

Fleet is a tool for controlling and managing CoreOS clusters through SYSTEMD. Fleet and SYSTEMD interact through the D-bus API, registering and synchronizing data between each fleet agent through a ETCD service. Fleet provides a rich range of features, including viewing the status of servers in a cluster, starting or terminating Docker containers, reading log content, and more. More importantly, fleet can ensure that the services in the cluster are always in a usable state. When a service created through fleet is unavailable in a cluster, such as when a host is detached from the cluster because of a hardware or network failure, a series of services originally running on this server will be reassigned to other available servers through fleet. Although the current fleet is in a very early state, its ability to manage CoreOS clusters is very effective, and there is still much room for expansion, and a simple API interface is now available for user integration.

End

From the next chapter, we'll start with building a CoreOS cluster, step-by-step, and familiarize yourself with every aspect of the system. (Author/linfan reviewer/Zhou Xiaolu)

[CoreOS Reprint] CoreOS Practice Guide (i)