前書き
CoreOSは、マルチサーバー環境でDockerコンテナーを管理するための優れた環境を提供します。 このクラスター管理をシンプルにするための最も重要なコンポーネントの1つは、*フリート*と呼ばれるサービスです。
Fleetを使用すると、ユーザーはクラスター全体のサービスとしてDockerコンテナーを管理できます。 インターフェースとして機能し、各クラスターメンバーのsystemd initシステムに対する抽象化レベルとして機能します。 ユーザーは、サービスが実行される条件に影響する制約を設定できます。 これにより、管理者は、指定された基準に基づいて特定のアプリケーションを同じホストまたは別のホストで実行するように指示することで、インフラストラクチャの外観を定義できます。
このガイドでは、フリートと、デーモンを制御できる「+ fleetctl +」ユーティリティについて説明します。
前提条件
このガイドに従うには、CoreOSクラスターが利用可能である必要があります。
このガイドで使用しているクラスターは、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean [how to DigitalOceanでCoreOSクラスターを作成します]。 そのガイドで説明されているクラスター構成があると仮定します。
構成されたクラスターには3つのノードがあります。 これらは、プライベートネットワークインターフェイスを使用して相互に通信するように構成されています。 パブリックサービスを実行するために、これらの各ノードでパブリックインターフェイスを使用できます。 ノード名は次のとおりです。
-
coreos-1
-
coreos-2
-
coreos-3
クラスターの準備ができたら、引き続きフリートの詳細をご覧ください。
サービスユニットファイルの操作
`+ fleetctl +`ツールに入る前に、サービスユニットファイルについて少し話す必要があります。
ユニットファイルは、 + systemd + initシステムで使用可能な各サービスを記述し、それを管理するために必要なコマンドを定義し、各サービスの開始時にシステムが実行可能な状態になるように依存関係情報を設定します。 クラスタ全体のレベルでサービスを管理するために、「+ fleet 」デーモンは「 systemd 」の上に構築されています。 このため、標準の ` systemd +`ユニットファイルのわずかに変更されたバージョンを使用します。
`+ fleet `ユニットファイルの詳細を見るには、https：//www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-withをご覧ください。 -fleet-unit-files [deep dive]サブジェクト。 このガイドでは、これらのファイルの形式の大まかな概要を示します。 また、 ` fleetctl +`について学ぶために使用できるサンプルユニットファイルも提供します。
フリートユニットファイルセクション
ほとんどのユニットファイルに含まれる基本セクションは次のとおりです。
-
ユニット：このセクションは、ユニットの「タイプ」に依存しないユニットに関する一般的な情報を提供するために使用されます。 これには、メタデータ情報と依存関係情報が含まれます。 これは主に `+ fleet +`で説明を提供し、他のサービスユニットに関連してこのユニットを指定するために使用されます。
-
ユニットタイプセクション： `+ fleet +`デーモンは、以下を含むさまざまなタイプのユニットを取ることができます。
-
サービス
-
ソケット
-
デバイス
-
マウント
-
自動マウント
-
タイマー
-
Path
タイプに特定のオプションがある場合、関連するタイプのセクションが許可されます。 `+ Service `セクションタイプは、断然最も一般的です。 このセクションは、タイプ固有の属性を定義するために使用されます。 ` Service +`ユニットの場合、これには通常、関連するアクションを実行する可能性のある事前および事後の開始または停止コマンドだけでなく、開始および停止コマンドの定義が含まれます。
-
* X-Fleet *：このセクションは、フリート固有の構成オプションを提供するために使用されます。 これは主に、マシンID、現在実行中のサービス、メタデータ情報などの基準に基づいて、特定の方法でサービスをスケジュールする必要があるかどうかを指定できることを意味します。
ユニットファイルの一般的な形式は次のとおりです。
[Unit]
[Service]
[X-Fleet]サンプルサービスユニットファイル
このチュートリアルを開始するために、使用するユニットファイルを提供します。 これは、例としてhttps://coreos.com/docs/quickstart/[CoreOSクイックスタートページ]から取得されます。 CoreOSマシンの1つで、次を入力します。
vim 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これが何をするのかを簡単に見てみましょう。
`+ [Unit] `セクションでは説明が設定され、このサービスは ` docker.service `ユニットが開始された後にのみ実行できることを ` systemd +`に伝えます。 これは、ユニットが機能するためにDockerに依存しているためです。
`+ [Service] `セクションでは、開始タイムアウトを無効にし、サービスを開始する前に実行するアクションを設定します。 ` ExecStartPre `は、メインの ` ExecStart `アクションの前に実行されます。 これらが「 =-+」で呼び出された場合、アクションが失敗し、サービスの完了に影響しないことを意味します。 これは、開始前アクションが実行されていた可能性のある以前実行中のサービスを基本的に破棄するために必要です。 何も見つからない場合、これは失敗します。これは単なるクリーンアップ手順であるため、サービスの開始を停止することは望ましくありません。
最後の事前開始アクションは、コマンドの実行に使用される基本的なbusyboxイメージをプルダウンします。 これが必要なので、 `+ =-+`構文を使用しません。 次に、「Hello World」を1秒に1回出力する無限ループを使用して、このイメージでコンテナーを開始します。 停止アクションは、単にこのコンテナを停止します。
これはあなたを立ち上げて走らせるのにちょうど十分でしょう。 フリートファイルの開発方法に関する詳細情報が必要な場合は、https：//www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with-fleet-をご覧ください。ユニットファイル[フリートユニットファイルに関するガイド]。
基本的なマシン管理コマンド
最初に行うことは、 `+ fleetctl `ユーティリティを紹介することです。 クラスタ管理者として、このツールは、マシンのフリートを管理するためのメインインターフェイスになります。 構文の多くは、systemdの管理ツールである「 systemctl +」から引き継がれています。
まず、次のように入力して、すべてのクラスターメンバーのリストを取得できます。
fleetctl list-machinesMACHINE IP METADATA
14ffe4c3... 10.132.249.212 -
1af37f7c... 10.132.249.206 -
9e389e93... 10.132.248.177 -ご覧のとおり、各マシンは使用可能としてここにリストされています。 各メンバーは、cloud-configファイルを使用して自分自身をブートストラップするときに、各ノードを識別するために使用される一意のマシンIDを生成します。 これは `+ / etc / machine-id`のファイルに書き込まれます。
デフォルトでは、フリートは他のメンバーとの通信にマシンのパブリックIPv4アドレスを使用します。 ただし、cloud-configファイルでは、通信にプライベートインターフェイスを使用するよう艦隊に指示しました。 これらは、上記の出力に示されているIPアドレスです。
上記の例では、「METADATA」列は現在空白です。 ただし、cloud-configのフリートの `+ metadata +`属性の下に任意のキーと値のペアを追加することもできます。 これは次のようになります。
#cloud-config
. . .
coreos:
fleet:
public-ip: $private_ipv4
metadata: region=europe,public_ip=$public_ipv4すべてのマシンをブートストラップするようにcloud-configでこれを設定すると、出力は次のようになります。
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この追加データは、管理の観点からノードに関する情報をすばやく取得するのに役立ちますが、特定のホストを対象とするサービス定義で使用することもできます。
クラスター内の特定のマシンに接続するには、 `+ fleetctl ssh +`コマンドを使用できます。 これにより、指定したユニット名に関連付けられたマシンIDまたはマシンに基づいて、接続するマシンを識別できます。
たとえば、「+ nginx.service +」というユニットを実行している場合、次のように入力することで、そのサービスを実行しているホストに接続できます。
fleetctl ssh nginx関連付けられたホストのシェルセッションにドロップされます。 通常の + ssh +`実行可能ファイルで実行するときと同じように、リモートホストで単一のコマンドを実行することもできます。 たとえば、（+ / etc / environment + `というファイルにCoreOSが設定する + COREOS_PRIVATE_IPV4 + および + COREOS_PUBLIC_IPV4 + `変数の値を取得するには（利用可能なcloud-configおよびネットワークインターフェイスのパラメーターに基づいて）、次のように入力できます：
fleetctl ssh nginx cat /etc/environmentCOREOS_PRIVATE_IPV4=10.132.249.212
COREOS_PUBLIC_IPV4=104.131.29.80サービス管理
`+ fleetctl +`で利用できる他のコマンドのほとんどは、サービス管理に基づいています。
サービスを開始する
サービスを開始するには、かなりの手順が必要です。 サービスファイルは、ユニットを認識できるように「+ fleet 」にアップロードする必要があります。 その後、クラスタから特定のマシンにスケジュールする必要があります。 その後、開始できます。 これらのそれぞれに ` fleetctl +`を使用したコマンドがあり、必要に応じて、後者のステージを担当するコマンドも前者を実行します。
`+ submit `コマンドを使用して、ユニットファイルを ` fleet `に送信できます。 これにより、 ` fleet +`がファイルの内容をメモリに読み込むだけで、以降のアクションで使用できるようになります。
fleetctl submit hello.serviceこれで、 `+ hello.service `ファイルは ` fleet +`に認識されます。 送信されたユニットファイルを表示するには、次のように入力します。
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 inactive inactive -ご覧のとおり、ユニットファイルは存在しますが、ホストでスケジュールされていないか、開始されていません。
`+ fleet +`が知っているユニットファイルの内容を表示するには、次のように入力します。
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これにより、 `+ fleet +`が知っている現在のファイルを見ることができます。
注：submitコマンドはi等です。つまり、再送信した場合、 `+ fleet +`はメモリ内ユニットファイルを更新しません。 ユニットファイルを更新する必要がある場合は、完全に削除してから再送信する必要があります。 これを行う方法については後で説明します。
ユニットが送信されると、次のステップはマシン上でユニットをスケジュールすることです。 ユニットのスケジューリングには、ユニットを参照する「+ fleet 」エンジンが関与し、クラスター内でユニットを渡す最適なマシンを決定します。 これは、ユニットの「 [X-Fleet] 」セクション内の条件と、クラスター内の各マシンの現在の作業量に基づいています。 ユニットがスケジュールされると、特定のマシンに渡され、ローカルの「 systemd +」インスタンスにロードされます。
`+ load +`コマンドを使用して、ユニットをロードおよびスケジュールします。
fleetctl load hello.serviceUnit hello.service loaded on 14ffe4c3.../10.132.249.212以前にユニットを手動でロードしていなかった場合、現在のディレクトリで適切なファイル名を検索することにより、このプロセスの一部としてユニットが自動的にロードされます。
ユニットファイルを確認すると、ロードされていることがわかります。 スケジュールされているマシンも確認できます。
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212これは、 `+ list-units +`コマンドをチェックアウトする最初の機会でもあります。 このコマンドは、実行中またはスケジュール済みのユニットとそのステータスを表示するために使用されます。
fleetctl list-unitsUNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 inactive dead実際にユニットを起動するには、 `+ start +`コマンドを使用できます。 これにより、ユニットファイルで定義された開始コマンドを実行することにより、ロードされたマシンでユニットが開始されます。
fleetctl start hello.serviceUnit hello.service launched on 14ffe4c3.../10.132.249.212もう一度、 `+ list-unit-files`を確認する必要があります。
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212上記の出力では、サービスが起動されていることがわかります。 「+ STATE」列は「望ましい状態」を示し、「+ STATE」列は実際の状態を示します。 これら2つが一致する場合、これは通常、アクションが成功したことを意味します。
また、 `+ list-units +`をもう一度見る必要があります。
fleetctl list-unitsUNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 active runningこれにより、「+ systemd 」状態に関する情報が得られます。 これはローカルデーモンから直接収集されるため、ローカルシステムがサービス状態をどのように認識するかをより適切に把握できます。 「 ACTIVE 」列はユニットの一般的な状態であり、「 SUB +」列はより低レベルの説明です。
サービスを停止する
上記の各コマンドには、状態を反転するコンパニオンコマンドがあります。
たとえば、サービスの実行を停止するには、 `+ stop `コマンドを使用します。 これにより、ローカルマシンの「 systemd +」インスタンスがユニットで定義された停止コマンドを実行します。
fleetctl stop hello.serviceUnit hello.service loaded on 14ffe4c3.../10.132.249.212ご覧のとおり、サービスは「+ loaded 」状態に戻りました。 これは、マシンの「 systemd +」にまだロードされているが、現在実行されていないことを意味します。 ここで確認できます：
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212そのマシンのsystemdからユニットを削除し、「+ fleet 」で使用できるようにするには、ユニットを「 unload +」することができます。 ユニットが現在アクティブな場合、アンロードされる前に停止されます。
fleetctl unload hello.service状態を確認すると、現在非アクティブとしてマークされていることがわかります。 また、ターゲットマシンもリストされていません。
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 inactive inactive -`+ fleet `からユニットを完全に削除したい場合は、 ` destroy `コマンドを使用できます。 これにより、必要に応じてユニットが停止およびアンロードされ、 ` fleet +`からユニットが削除されます。
fleetctl destroy hello.serviceユニットファイルを変更する場合、それを再度サブミット/開始する前に、 `+ fleet +`で現在のユニットを破壊する必要があります。
ユニットステータスの取得
ユニットのステータスに関する情報を取得する方法のいくつかを見てきました。
たとえば、マシンで現在スケジュールされているすべてのユニットを「+ list-units +」でリストする方法について説明しました。
fleetctl list-unitsUNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 active running`+ list-unit-files `は、 ` fleet +`が知っている_all_ユニットのリストを提供します。 また、望ましい状態と実際の状態に関する情報も提供します。
fleetctl list-unit-filesUNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212開始されたユニットに関するより具体的な情報については、他のいくつかのコマンドがあります。 `+ status `コマンドは、ユニットを実行しているホスト上のサービスの ` systemctl status +`の結果を返します：
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ご覧のように、ユニットの出力が生成されていることを最終的に確認できます。
同様に、関連するマシンで利用可能なサービスのジャーナルエントリを表示したい場合は、 `+ journal +`コマンドを使用できます。
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デフォルトでは、これにより最後の10行が表示されます。 次のように `+-lines +`パラメータを追加することでこれを調整できます：
fleetctl journal --lines 20 hello.service「フォロー」の略である「+ -f 」パラメータを使用することもできます。 これは、最新のログエントリを引き続き返すという点で、「 tail -f +」と同様に動作します。
fleetctl journal -f hello.service結論
`+ fleet `と ` fleetctl +`を効果的に使用する方法を学ぶことで、CoreOSクラスターを簡単に制御できます。 サービスとコンテナは、多くの問題なく別のマシンに移動できます。
後のガイドで、さらに詳しくhttps://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with-fleet-unitについて説明します-files [フリートユニットファイルの作成方法]。 これにより、CoreOSアーキテクチャを活用する柔軟で強力なサービスを作成できます。