CoreOS Practice Guide (ii): Erection of CoreOS clusters

"Editor's note" as an operating system, CoreOS uses a highly streamlined system kernel and peripheral customization to implement many of the functions that require complex human operations or Third-party software support at the operating system level, while excluding other software that is not core to the server system, such as GUI and package manager. Linfan, a software engineer from ThoughtWorks, will bring the "Walk Cloud: CoreOS Practice Guide" series to take you through the CoreOS essence and recommended practice. This article is based on the second chapter: Erecting CoreOS cluster.

The erection of CoreOS clusters is easier than erecting a traditional server cluster. On the one hand, because CoreOS uses Cloud-init to automate the configuration of cluster information, on the other hand, it benefits from ETCD distributed storage implementation of the message distribution and server self discovery mechanism. These conveniences are precisely the COREOS system designed to improve the efficiency of cluster architecture considerations.

Author Introduction:

Linfan, born in the tail of the IT siege Lions, thoughtworks Chengdu Office Cloudops team members, usually like in the spare time to study DevOps related applications, currently in preparation for AWS certification and promotion of Docker related technologies.

Installation CoreOS

The CoreOS installation method differs greatly from the traditional Linux system. Given that this is the basic tutorial, in this article, we will use the official Vagrant mirroring step-by-step construction of the CoreOS VirtualBox virtual machine cluster. This article uses LINUX/MAC as a test environment, vagrant from version 1.6 has supported windows, but need to install Putty as a login tool, slightly different, the specific use of the link.

Incidentally, the more careful user may have found that one of the official mirrors is an "ISO image file," but this mirror is actually just a Live CD and is free of the installed trial image. Systems that directly use this ISO boot do not have the ability to discover services and distribute distributed messages. How to install the cluster through an ISO image we'll put it in the detail of the topic. OK, let's get to the point.

As mentioned in the first installment of the series, Cloud-init often relies on the implementation of a specific platform for customization, and using it directly on the physical machine is not a mainstream use. For this installation, an official document provides detailed steps, which are no longer discussed in detail.

First look at the CoreOS support platform. As of now, the latest version of the CoreOS v540 has been supported by the following image platform.

You can see the removal of the Bare Metal installed to the local, and the rest is basically a customized version of the mainstream cloud service platform. The customization here is primarily the configuration of cloud-init, such as startup services, so how do you know what CoreOS has to support the automated cluster deployment platform? We can get the answer from the Coreos-base directory of the CoreOS source code.

The beginning of these OEM directories is the implementation of platform customization. The files/cloud-config.yml file in each directory is the Cloud-init configuration file. There are different ways to install CoreOS on each platform, and you can find the appropriate steps from the corresponding pages in the official website. Here we select the vagrant as the target platform for the demo.

deploy CoreOS clusters on vagrant

Using vagrant to build a CoreOS cluster can be said to be the simplest and most economical way to use a local virtual institution, especially for quick validation of CoreOS features.

Preparation

Things to prepare, including a MAC or desktop Linux computer connected to the Internet, and installing Git, VirtualBox, and vagrant.

Download the official Vagrant Warehouse via Git:

git clone https://github.com/coreos/coreos-vagrant.git

After the download is complete, we then configure the CoreOS cluster.

Configuration

To use the cluster server's Self discovery feature, we need an address that uniquely identifies a cluster and provides cluster information. CoreOS officially provides this service, and of course we can use our own private cluster to identify the server. Since building a private identity server is a relatively advanced content, we will detail the following articles in this series.

Access to address via the browser or command line Curl Https://discovery.etcd.io/new can get a new cluster identity URL (if it is under Windows, you can access the URL directly using the browser), this URL will be in the configuration User-data when used.

Curl Https://discovery.etcd.io/new

Enter the Coreos-vagrant directory, user-data.sample and config.rb.sample two files each backup, and remove the. Sample suffix. Get User-data and config.rb files.

First modify the User-data file, which will be provided as a startup profile to the CoreOS operating system. It is worth mentioning that in this configuration, you can use two variables $private _ipv4 and $public _ipv4, they will be automatically replaced by the actual operation of the host's real extranet IP and intranet IP address.

All we need to do here is to discovery the comment in front of the line where it is located, and then replace it with the cluster ID URL address that we just obtained. In simple terms, all host instances that use the same identity URL are automatically added to the same cluster at the start of the CoreOS, which enables the cluster server to discover itself without human intervention.

#cloud-config


CoreOS:


ETCD:


# Generate a new token for each unique cluster from Https://discovery.etcd.io/new


# warning:replace ' vagrant Destroy '


Discovery: < cluster identification URL address >


addr: $public _ipv4:4001


peer-addr: $public _ipv4:7001


... ...

Then modify the Config.rb file, which contains the configuration of the vagrant virtual machine. This file can actually overwrite any vagrantfile parameters, but for now we just need to focus on the values $num _instances and $update _channel these two parameters.

$num _instances represents the number of host instances that will need to be included in the CoreOS cluster to be started, $update _channel represents the upgrade channel used by the CoreOS instance that is started, which can be ' stable ', ' beta ' or ' alpha '.

$num _instances=3


$update _channel= ' stable '

Instead of a leapfrog version release, CoreOS uses a smooth rolling upgrade similar to Arch Linux to ensure that users are downloaded at any time by the latest system mirroring, and that the server system is fundamentally resolved after a few years of running and being forced to reinstall due to the inability to smooth upgrades. In addition, CoreOS provides Stable, Beta, and Alpha three upgrade channels to meet the different user's new characteristics and stability of the system balance. For an upgrade channel switch, refer to the official documentation.

Start

Start Cluster, execute:

vagrant up

View cluster run status, all cluster instances have been started.

vagrant up


Current machine states:


core-01 Running (VirtualBox)


core-02 Running (VirtualBox)


core-03 Running (VirtualBox)

At this point, a lot of stories are happening inside the CoreOS cluster, where the instances of the cluster are known to each other and are established through the discovery service. They have the ability to control the entire cluster in any instance node in the cluster. Yes, a full-featured CoreOS server cluster is fully operational.

Explore CoreOS

In the next section, we will go into the CoreOS instance of the launch and continue to explore the mysteries. (Author/linfan revisers/Zhou Xiaolu)

Content reference to: Running CoreOS on vagrant

If you need to know more Docker relevant information or technical documentation to access the Docker technology community; If you have more questions, please submit it in the Dcoker Technical Forum and we will invite expert answers. CSDN Docker Technology Exchange QQ Group: 303806405.