Provide: ZStack Cloud Computing
Series of tutorials
This tutorial is for CoreOS Upper Finger Guide The third of nine articles in the series.
Content introduction
CoreOS provides us with a Docker container management platform across multi-server environments, and fleet services can significantly simplify the management of the entire cluster.
Fleet allows users to manage the entire cluster using Docker containers as services. It exists not only as an interface, but also as an abstraction layer of system D init system among cluster members. Users can set constraints to limit the way services operate. In this way, administrators can require specific applications to run on the same or different hosts, thereby realizing infrastructure adjustments.
In today's tutorial, we'll learn about fleet and how to use the fleetctl tool to control the daemon.
Precondition
To complete this tutorial, you first need to have a set of CoreOS clusters available.
Previous series of tutorials How to Create a CoreOS Cluster with DigitalOcean Among them, we have completed the cluster creation work.
This cluster configuration consists of three nodes. They can communicate with each other using proprietary network interfaces. These three nodes also have public interfaces to run public services. Each node name is:
- coreos-1
- coreos-2
- coreos-3
After the cluster is ready, we will continue the fleet tour.
Processing Service Unit Files
Before discussing fleetctl tools, we should first talk about service unit files.
The unit file is used by the system D init system to describe each available service, define the necessary commands to manage it, and set the relevant information to ensure that the system is in a normal state when the service is started. Flet daemon is built on the basis of system d, which is based on the cluster level for service management. In view of this, it uses a slightly different system D unit file from the standard version.
For further information on fleet unit files, see Depth analysis One article. In today's tutorial, we will only give an overview of the format of these documents. We will also provide a sample unit file to help you understand fleetctl.
Analysis of Fleet Unit File Sections
Most cell files contain the following basic sections:
- Unit: This section is used to provide general information about the unit and is independent of the "type" of the unit. It includes metadata information and relevance information. It is mainly used in fleet to provide descriptions and specify how the unit interacts with other service units.
- Unit Type Section: Flet daemon can accommodate a variety of different cell types, including:
- Service
- Socket
- Device
- Mount
- Automount
- Timer
- Path
If the type already has specific options, it is allowed to include a section related to the type. Service section types are the most common, which are used to define properties of a particular type. For Service units, these attributes usually include defining the start and stop of commands, or starting or stopping commands in a pre-and post-set manner.
- X-Fleet: This section is used to provide specific fleet configuration options. Specifically, this means that you can specify that a service must or must not be scheduled in a specific way, including device ID, currently running services, metadata information, and so on.
The general format of the unit file is as follows:
[Unit]Generic_option_1Generic_option_2[Service]Service_specific_option_1Service_specific_option_2[X-Fleet]Fleet_option_1Fleet_option_2
Examples of Service Unit Files
To begin this tutorial, we need to get the unit files first. You can go through it. CoreOS Quick Start Page Get in. In any CoreOS device, enter:
vim hello.service
Then, enter our sample service file:
[Unit]Description=My ServiceAfter=docker.service[Service]TimeoutStartSec=0ExecStartPre=-/usr/bin/docker kill helloExecStartPre=-/usr/bin/docker rm helloExecStartPre=/usr/bin/docker pull busyboxExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"ExecStop=/usr/bin/docker stop hello
Here's how it works.
Setting a description in the [Unit] section means that we tell system d that the service can only start after the docker.service unit starts. This is because our unit needs to cooperate with Docker to work properly.
In the [Service] section, we disable startup timeouts and then set up a series of operations to complete the components that need to be run first before the service starts. ExecStartPre is executed before the main ExecStart operation. If it is invoked by = - it indicates that the service itself will not be affected whether it is successfully started or not. This is very important because our pre-startup operations basically remove any previously running services. If you can't find a service already running, the operation will naturally fail -- but because it's only a cleanup process, we don't want it to affect the normal execution of the service.
The final pre-start section is responsible for extracting the basic busybox image needed to run the command. Since this operation is necessary, we can't use the=-grammar. Next, we use this image to start a set of containers and output "Hello World" once a second in the initial loop. When it stops operation, it closes the container directly.
If you want to know more about fleet file development, please consult Our Flet Unit Document Guide.
Basic Equipment Management Order
Let's first introduce fleetctl tools. As a cluster management tool, fleetctl will become the main interface for us to manage the cluster of devices. Most of these grammars are directly copied from the system ctl, the management tool of system D.
As a first step, we use the following commands to obtain a list of cluster members:
fleetctl list-machines MACHINE IP METADATA 14ffe4c3... 10.132.249.212 - 1af37f7c... 10.132.249.206 - 9e389e93... 10.132.248.177 -
As you can see, every available device is listed. Each member boots itself with a cloud-config file at startup, generates a unique device ID and distinguishes the nodes. This information is written to the / etc/machine-id file.
By default, fleet uses the device's common IPv4 address to communicate between different members. However, in our cloud-config file, fleet can also be required to communicate using proprietary interfaces. The above output is exactly these IP addresses.
The column "METADATA" is still blank. We can add any key-value pair to the metadata attribute in the cloud-config file. As follows:
#cloud-config . . . coreos: fleet: public-ip: $private_ipv4 metadata: region=europe,public_ip=$public_ipv4
If you set this up in the cloud-config file to boot all devices, the output should be as follows:
MACHINE IP METADATA 14ffe4c3... 10.132.249.212 public_ip=104.131.36.200,region=europe 1af37f7c... 10.132.249.206 public_ip=104.131.15.192,region=europe 9e389e93... 10.132.248.177 public_ip=104.131.15.192,region=europe
This extra data can be used to quickly extract information from nodes in management, but it can also be used to point to specific hosts in service definition.
To access specific devices in the cluster, you can use the fleetctl ssh command. In this way, we can identify the accessed device according to the device ID or the device corresponding to the given unit name.
For example, if you have a running unit named nginx.service, you can directly access the corresponding host running the service by the following commands:
fleetctl ssh nginx
After running, we will go directly to the shell session in the corresponding host. You can also run a single command on a remote host in the same way as running a normal ssh executable. For example, to obtain COREOS_PRIVATE_IPV4 and COREOS_PUBLIC_IPV4 variables set by CoreOS from the / etc/environment file (based on cloud-config parameters and available network interfaces), you can use the following commands:
fleetctl ssh nginx cat /etc/environment COREOS_PRIVATE_IPV4=10.132.249.212 COREOS_PUBLIC_IPV4=104.131.29.80
Service management
Most of the other commands available for fleetctl are related to service management.
Start a service
Starting a service involves multiple steps. The service file must be loaded into fleet to ensure that it is aware of the target unit. Next, it needs to be scheduled to specific devices in the cluster before it can be started. Each step requires the use of fleetctl commands, which are responsible for performing corresponding operations at each stage.
You can only submit our unit files to fleet using the submit command. In this way, fleet reads the contents of the file into memory for subsequent operations.
fleetctl submit hello.service
Our hello.service file is now fleet aware. To view the completed unit files submitted, you can use the following commands:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 inactive inactive -
As you can see, the unit file appears as above, but has not been scheduled to any host or actually started.
To view the contents of the unit files that fleet has identified, you can use the following commands:
fleetctl cat hello.service [Unit] Description=My Service After=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill hello ExecStartPre=-/usr/bin/docker rm hello ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop hello
This allows you to view fleet's perception of the current file content.
Note: The submit command is idempotent, meaning that fleet will not update the in-memory unit files when repeated submissions are made. If you need to update your own unit files, you must remove them completely and resubmit them. We will discuss it in the back.
After the cell submission is completed, the next step is to dispatch it to a device. During cell scheduling, fleet engine checks the cell to ensure that it runs on the most suitable cluster node. The specific results depend on the constraints of the [X-Fleet] section in the cell and the current load of each device in the cluster. When the unit is scheduled, it is passed to a specific device and added to the local system D instance.
Use the load command to load and schedule the cell:
fleetctl load hello.service Unit hello.service loaded on 14ffe4c3.../10.132.249.212
If you haven't loaded the unit manually before, the process will search the appropriate file name in the current directory and load it automatically.
Now, if we check our unit files, we will find that they have been loaded. We can even see which device it is dispatched to:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212
This is the first time we have used the list-units command. This command is used to display any running or dispatched unit and its status:
fleetctl list-units UNIT MACHINE ACTIVE SUB hello.service 14ffe4c3.../10.132.249.212 inactive dead
To start a unit, you can use the start command. It starts the unit on a specific device according to the start command defined in the unit file:
fleetctl start hello.service Unit hello.service launched on 14ffe4c3.../10.132.249.212
Check list-unit-files again:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212
From the above output, we can see that the service has been started and completed. The DSTATE column shows the "ideal state" and the STATE indicates the actual state. If the two match, it means that the operation has been successful.
Look again at list-units:
fleetctl list-units UNIT MACHINE ACTIVE SUB hello.service 14ffe4c3.../10.132.249.212 active running
Here we can see information about system D status. It is collected directly from the local daemon process, so it can help us to better grasp the service status obtained by the local system. ACTIVE is listed as the general state of the unit, while SUB is a lower level state.
Stop a service
Each of the above commands has a corresponding antonym command.
For example, we can stop a running service using the stop command. After execution, the system D instance of the local device executes the stop instruction in the unit definition:
fleetctl stop hello.service Unit hello.service loaded on 14ffe4c3.../10.132.249.212
As you can see, the service has been restored to the loaded state. This means that it is still loaded into the system D of the device, but it is no longer running. We can confirm it by the following order:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212
To remove the unit in the device system D and ensure its availability in fleet, we can unload the unit. If the unit is currently active, it will stop before being unloaded:
fleetctl unload hello.service
If you check this state, you can see that it is now marked inactive. In addition, the target equipment was also left empty:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 inactive inactive -
If we need to remove the unit completely from fleet, we can use the destroy command. It stops and uninstalls the unit and then removes it from fleet:
fleetctl destroy hello.service
If we modify a unit file, we must destroy the existing unit in fleet and then resubmit/start it.
Get the cell state
You should already know several ways to get cell status information.
For example, list-units lists all units currently scheduled to a device:
fleetctl list-units UNIT MACHINE ACTIVE SUB hello.service 14ffe4c3.../10.132.249.212 active running
list-unit-files, on the other hand, provides a list of known units containing _all_fleet. It will also provide ideal and actual state information:
fleetctl list-unit-files UNIT HASH DSTATE STATE TMACHINE hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212
To get more specific information about booted units, we can use several other commands. The status command returns the system CTL status of the running unit on the target host:
fleetctl status hello.service
● hello.service - My Service
Loaded: loaded (/run/fleet/units/hello.service; linked-runtime)
Active: active (running) since Mon 2014-09-08 21:51:22 UTC; 3min 57s ago
Process: 7630 ExecStartPre=/usr/bin/docker pull busybox (code=exited, status=0/SUCCESS)
Process: 7618 ExecStartPre=/usr/bin/docker rm hello (code=exited, status=0/SUCCESS)
Process: 7609 ExecStartPre=/usr/bin/docker kill hello (code=exited, status=0/SUCCESS)
Main PID: 7638 (docker)
CGroup: /system.slice/hello.service
└─7638 /usr/bin/docker run --name hello busybox /bin/sh -c while true; do echo Hello World; sleep 1; done
Sep 08 21:55:11 coreos-3 docker[7638]: Hello World
Sep 08 21:55:12 coreos-3 docker[7638]: Hello World
Sep 08 21:55:13 coreos-3 docker[7638]: Hello World
Sep 08 21:55:14 coreos-3 docker[7638]: Hello World
Sep 08 21:55:15 coreos-3 docker[7638]: Hello World
Sep 08 21:55:16 coreos-3 docker[7638]: Hello World
Sep 08 21:55:17 coreos-3 docker[7638]: Hello World
Sep 08 21:55:18 coreos-3 docker[7638]: Hello World
Sep 08 21:55:19 coreos-3 docker[7638]: Hello World
Sep 08 21:55:20 coreos-3 docker[7638]: Hello World
As you can see, we finally prove that the output of the sample unit is being displayed properly.
Similarly, if you want to view the journal entry of the service on the relevant device, you can use the Journal command:
fleetctl journal hello.service -- Logs begin at Mon 2014-09-08 14:22:14 UTC, end at Mon 2014-09-08 21:55:47 UTC. -- Sep 08 21:55:38 coreos-3 docker[7638]: Hello World Sep 08 21:55:39 coreos-3 docker[7638]: Hello World Sep 08 21:55:40 coreos-3 docker[7638]: Hello World Sep 08 21:55:41 coreos-3 docker[7638]: Hello World Sep 08 21:55:42 coreos-3 docker[7638]: Hello World Sep 08 21:55:43 coreos-3 docker[7638]: Hello World Sep 08 21:55:44 coreos-3 docker[7638]: Hello World Sep 08 21:55:45 coreos-3 docker[7638]: Hello World Sep 08 21:55:46 coreos-3 docker[7638]: Hello World Sep 08 21:55:47 coreos-3 docker[7638]: Hello World
By default, it displays the last ten lines. You can also adjust this by adding line parameters:
fleetctl journal --lines 20 hello.service
You can also use the - f parameter, which stands for "follow". By adding the command with the - f parameter, the system sends back the latest log entries continuously:
fleetctl journal -f hello.service
summary
By learning how to use fleet and fleetctl, you can easily control your own CoreOS cluster. Our services and containers can also migrate very smoothly between different devices.
In the next tutorial, we'll go into more depth. how to create fleet unit files How to create fleet unit files . In this way, we can create flexible and powerful services that can give full play to the advantages of CoreOS architecture.
The source of this article is from DigitalOcean Community . English text: How To Use Fleet and Fleetctl to Manage your CoreOS Cluster By Justin Ellingwood
Translation: diradw