[CoreOS Reprint] CoreOS Practice Guide (iv): Cluster command post Fleet

Reprint: HTTP://WWW.CSDN.NET/ARTICLE/2015-01-14/2823554/2

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 to the Cloud: CoreOS Practice Guide" series of articles on CoreOS essence and recommended practice methods. This article is based on the fourth: Cluster command post fleet.

Service life cycle on a cluster

The start-up process looks simple, doesn't it? In the actual use, if in order to save trouble, use Fleet to start a service, this can be done. But this practice can actually bring the service management trouble, especially when the startup error. So a more comprehensive understanding of fleet in the back silently do what work, detailed understanding of the fleet model, the service life cycle on the cluster is very necessary.

The following diagram depicts the actual phases of a service in fleet, from initial to run, to the end of the final termination. service life cycle in the fleet

• Submit Service

The commit phase of the service, which is done only in the fleet service, to add the specified unit file to the fleet record cache. Fleet does not communicate with SYSTEMD at this time. by              Fleetctl List-unit-files and Fleetctl The list-units command can see that the unit file is submitted and does not appear in the latter's record. At this point the unit file has been registered as a fleet identifiable unit name, but it is not yet a service that can be executed.

$ fleetctl Submit ${home}/hello.service $ fleetctl list-unit-files Unit HASH dstate State TARGET Hello.service 4bff33d Inactive Inactive-$ fleetctl list-units UNIT MAC HINE ACTIVE SUB

It is worth noting that this step needs to pass the full unit file path as a parameter to Fleetctl, which is the only place where the service needs to provide the full path for the entire fleet life cycle of the cluster.

Use the Fleetctl Cat command to print out the contents of a unit file that has already been cached.

$ fleetctl Cat hello.service                  [unit]                  Description=hello world                  after=docker.service                  requires=docker.service                  [service]                  timeoutstartsec=0                  Execstartpre=-/usr/bin/docker Kill busybox1                  Execstartpre=-/usr/bin/docker RM busybox1                 ExecStartPre=/usr/bin/ Docker Pull busybox                  Execstart=/usr/bin/docker run--name busybox1 busybox/bin/sh-c "while                 true; do Echo Hello world; Sleep 1; Done "                 execstop= /usr/bin/docker Kill busybox1                  [x-fleet]                  X-conflicts=hello.service

Similar to SYSTEMD, there is also an easy place to make mistakes. Since fleet has cached the entire unit file, then if the original unit file content changes, simply stopping and restarting the service does not load the newly changed content. If you need to have a new unit file to be used, you need to resubmit the file, that is, to perform the submit operation again. Therefore, it is emphasized again that users should have a certain understanding of the life cycle of fleet management services.

• Load Service

The load service is actually the process of passing the service to the local systemd system of a specific node that meets the conditions, based on the X-fleet configuration segment condition of the unit file, which Fleet communicates with the systemd of the node through the Dbus API.

$ fleetctl Load hello.service               Unit Hello.service loaded on 0acdd9bf.../110.0.2.15              $ fleetctl list-unit-files               unit  hash  dstate  state  target                hello.service  4bff33d  loaded  loaded  0acdd9bf.../10.0.2.15              $ fleetctl list-units                unit  machine  active  sub                hello.service  0acdd9bf.../10.0.2.15  failed   Failed

As you can see, now Fleetctl List-units has identified this service. At this point, the preparation of this service is all ready.

• Start the service

Starting a service is the last step in completing the service run cycle. As mentioned before, if the parameter passed is not the name of the service but the path of the unit file, fleet will also automatically complete the submission and loading of the unit file and start the corresponding service. This practice is only desirable in manual operation, if the automatic operation of the script, if the service started abnormally, simply from the script output is difficult to determine which part of the problem, will bring management and troubleshooting difficulties.

$ fleetctl start hello.service               Unit Hello.service launched on 0acdd9bf.../10.0.2.15              $ fleetctl list-unit-files               unit  hash  dstate  state  target                hello.service  4bff33d  launched  launched              0acdd9bf.../10.0.2.15              $ fleetctl list-units                unit  Machine  ACTIVE  sub                hello.service  0acdd9bf.../10.0.2.15  ACTIVATING   &NBsp;         Start-pre

The service that you just started is in the Start-pre state (the service is performing the Execstartpre section of the unit file), and the service status changes to running after a few minutes to see the status of the service again.

$ fleetctl list-units UNIT machine ACTIVE SUB hello.service 0acdd9bf.../10.0.2 . Active Running

• Stop Service

Service can not run endlessly, after all, there is a time to stop. Service stops also go through three processes, in turn, stop, unload, and destroy, which correspond essentially to the boot process one by one.

$ fleetctl Stop Hello.service Unit hello.service loaded on 0acdd9bf.../10.0.2.15 $ fleetctl Unload Hello.service Unit hello.service inactive $ fleetctl Destroy Hello.service destroyed Hello.service

After the service has been removed, the system is back to its original state.

$ fleetctl list-unit-files Unit HASH dstate State TARGET $ fle Etctl list-units UNIT Machine ACTIVE SUB

• Service Auto-start

Readers who are actually working on one side may have discovered that the Fleet management tool Fleetctl does not have both the Enable and disable operations. In fact, as long as the service is running through Fleetctl start, it is automatically started. It can be confirmed by running the local systemd of the node (it is best to remove the local Hello service previously added through SYSTEMD before doing this validation, so as not to affect the confidence of the result).

$ fleetctl ssh Hello # jump to the node running Hello service $ systemctl list-units | grep Hello Hello2.service Loaded active running Hello World $ systemctl List-unit-files | grep Hello Hello2.service enabled

Service Status and logs

Fleet also has the ability to view service status and logs across nodes. By Fleetctl status plus the name of the service, you can see the basic state of the service without worrying about which node the service is running on.

$ FLEETCTL Status hello.service                    ...                    is you sure want to continue connecting (yes/no)? yes                 <= Need confirmation for first use                    Hello.service-hello world                    ...                     main pid:4964 (Docker)                       CGroup:/system.slice/hello.service                     └─4964/usr/bin/docker run--name busybox1 busybox/bin/sh  & nbsp;             -C while true; do Echo Hello world; Sleep 1; done                   Jan Ten 08:58:07 core-03 docker[4964]: Hello world                    Jan 08:58:08 core-03 docker[4964]: Hello world     & nbsp;             Jan 08:58:09 core-03 docker[4964]: Hello world                   ...

The same way you can view the log of the service output on any node, the corresponding command is FLEETCTL journal. Incidentally, when the service program is managed using Systemd/fleet, it is output to std::out           during its run            content will be redirected to the log.

$ fleetctl Journal hello.service                       -Logs begin at Sat 2015-01-10 02:41:59 UTC, end at Sat 2015-01-10&nbsp ;                   08:58:56 UTC. --                        Jan 08:58:46 core-03 docker[4964]: Hello world        & nbsp;              Jan 08:58:47 core-03 docker[4964]: Hello world                        Jan 08:58:48 core-03 docker[4964]: Hello world      & Nbsp;                ...

Fleetctl fournal commonly used parameters are: Specify the number of output log lines--lines and follow the log output--follow (or-f).

fleetctl Journal--lines hello.service fleetctl

journal-f hello.service

Summary

In this article, we learned more about the operation of viewing and managing clusters in a CoreOS cluster through fleet. The fleet service in CoreOS obtains the service information of the cluster through ETCD (a kind of distributed data storage service) and controls the service status of any node in the cluster through Dbus interface operation, and provides cross-node, distributed, high fault-tolerant service deployment and management capability on the SYSTEMD cluster.

In the next article, we'll dive into another service module in CoreOS, fleet behind the scenes of data hero--etcd's use. Please look forward to it. (Author/linfan Zebian/Zhou Xiaolu)

[CoreOS Reprint] CoreOS Practice Guide (iv): Cluster command post Fleet