FleetとFleetctlを使用してCoreOSクラスターを管理する方法
ステータス:非推奨
理由: 2016年12月22日、CoreOSはフリートを維持しないことを発表しました。 CoreOSから削除される2017年2月まで、セキュリティアップデートとバグ修正を受け取ります。 プロジェクトでは、すべてのクラスタリングのニーズにKubernetesを使用することを推奨しています。
代わりに参照してください:フリートなしでCoreOSでKubernetesを使用するガイダンスについては、CoreOSドキュメントのKubernetesを参照してください。
序章
CoreOSは、マルチサーバー環境全体でDockerコンテナーを管理するための優れた環境を提供します。 このクラスター管理をシンプルにするための最も重要なコンポーネントの1つは、フリートと呼ばれるサービスです。
Fleetを使用すると、ユーザーはDockerコンテナーをクラスター全体のサービスとして管理できます。 これは、各クラスターメンバーのsystemdinitシステムに対するインターフェイスおよび抽象化レベルとして機能することで機能します。 ユーザーは、サービスが実行される条件に影響を与える制約を設定できます。 これにより、管理者は、提供された基準に基づいて同じまたは別々のホストで実行するように特定のアプリケーションに指示することにより、インフラストラクチャをどのように見せたいかを定義できます。
このガイドでは、フリートと fleetctl
デーモンを制御できるようにするユーティリティ。
前提条件
このガイドに従うには、CoreOSクラスターが利用可能である必要があります。
このガイドで使用しているクラスターは、DigitalOceanでCoreOSクラスターを作成する方法に関するガイドに従って作成できます。 そのガイドで説明されているクラスター構成があることを前提としています。
構成されたクラスターには3つのノードがあります。 これらは、プライベートネットワークインターフェイスを使用して相互に通信するように構成されています。 公共サービスを実行するために、これらの各ノードで公共インターフェースを利用できます。 ノード名は次のとおりです。
- coreos-1
- coreos-2
- coreos-3
クラスターの準備ができたら、引き続きフリートについて学習します。
サービスユニットファイルの操作
に入る前に fleetctl
ツールについては、サービスユニットファイルについて少し説明する必要があります。
ユニットファイルは、 systemd
initシステムは、利用可能な各サービスを記述し、それを管理するために必要なコマンドを定義し、依存関係情報を設定して、各サービスの開始時にシステムが実行可能な状態になるようにします。 The fleet
デーモンは上に構築されます systemd
クラスタ全体のレベルでサービスを管理するため。 このため、標準のわずかに変更されたバージョンを使用します systemd
ユニットファイル。
詳細を確認するには fleet
ユニットファイルについては、詳細に従ってください。 このガイドでは、これらのファイルの形式の概要を説明します。 また、学習に使用できるユニットファイルの例も提供します。 fleetctl
.
フリートユニットファイルセクション
ほとんどのユニットファイルに含まれる基本的なセクションは次のとおりです。
- ユニット:このセクションは、ユニットの「タイプ」に依存しないユニットに関する一般的な情報を提供するために使用されます。 これには、メタデータ情報と依存関係情報が含まれます。 これは主に
fleet
説明を提供し、他のサービスユニットに関連してこのユニットを配置することを指定します。 - ユニットタイプセクション:
fleet
デーモンは、次のようなさまざまなタイプのユニットを取ることができます。- サービス
- ソケット
- デバイス
- マウント
- 自動マウント
- タイマー
- 道
タイプに特定のオプションがある場合、関連するタイプのセクションが許可されます。 The Service
セクションタイプが最も一般的です。 このセクションは、タイプ固有の属性を定義するために使用されます。 為に Service
ユニットの場合、これには通常、開始コマンドと停止コマンド、および関連するアクションを実行する可能性のある開始前または停止後のコマンドの定義が含まれます。
- X-Fleet :このセクションは、フリート固有の構成オプションを提供するために使用されます。 これは主に、マシンID、現在実行中のサービス、メタデータ情報などの基準に基づいて、サービスを特定の方法でスケジュールする必要があるかどうかを指定できることを意味します。
ユニットファイルの一般的な形式は次のとおりです。
[Unit]
Generic_option_1
Generic_option_2
[Service]
Service_specific_option_1
Service_specific_option_2
[X-Fleet]
Fleet_option_1
Fleet_option_2
サンプルサービスユニットファイル
このチュートリアルを開始するために、使用するユニットファイルを提供します。 これは、例として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]
セクション、説明が設定され、私たちは伝えます systemd
このサービスは、 docker.service
ユニットが起動しました。 これは、ユニットが機能するためにDockerに依存しているためです。
の中に [Service]
セクションでは、開始タイムアウトを無効にしてから、サービスを開始する前に実行するいくつかのアクションを設定します。 The ExecStartPre
メインの前に実行されます ExecStart
アクション。 これらがで呼び出された場合 =-
これは、アクションが失敗し、サービスの完了に影響を与えない可能性があることを意味します。 これが必要なのは、開始前のアクションが基本的に、以前に実行されていた可能性のあるサービスをすべて破棄するためです。 何も見つからない場合、これは失敗します。これは単なるクリーンアップ手順であるため、サービスの開始を停止したくありません。
最後のpre-startアクションは、コマンドの実行に使用される基本的なbusyboxイメージをプルダウンします。 これは必要なので、使用しません =-
構文。 次に、「Hello World」を1秒に1回出力する無限ループで、この画像を使用してコンテナーを開始します。 停止アクションは、単にこのコンテナーを停止します。
これは、あなたを立ち上げて実行するのにちょうど十分です。 フリートファイルの開発方法の詳細については、フリートユニットファイルに関するガイドをご覧ください。
基本的なマシン管理コマンド
最初に行うことは、 fleetctl
効用。 クラスタ管理者として、このツールは、マシンのフリートを管理するためのメインインターフェイスになります。 構文の多くはから引き継がれています systemctl
、systemdの管理ツール。
まず、次のように入力して、すべてのクラスターメンバーのリストを取得できます。
fleetctl list-machines
MACHINE 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」列は現在空白です。 ただし、下に任意のキーと値のペアを追加することもできます。 metadata
cloud-configのフリートの属性。 これは次のようになります。
#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
実行可能。 たとえば、の値を取得するには COREOS_PRIVATE_IPV4
と COREOS_PUBLIC_IPV4
CoreOSがファイルに設定する変数 /etc/environment
(cloud-configのパラメーターと使用可能なネットワークインターフェースに基づいて)、次のように入力できます。
fleetctl ssh nginx cat /etc/environment
COREOS_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-files
UNIT 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
知っている。
注:送信コマンドはべき等です。つまり、 fleet
再送信した場合、メモリ内のユニットファイルは更新されません。 ユニットファイルを更新する必要がある場合は、完全に削除してから再送信する必要があります。 これを行う方法については後で説明します。
ユニットが送信されたら、次のステップはマシンでそれをスケジュールすることです。 ユニットのスケジューリングには、 fleet
エンジンはユニットを調べて、ユニットを渡すクラスター内の最適なマシンを決定します。 これは、内の条件に基づいています [X-Fleet]
ユニットのセクション、およびクラスター内の各マシンの現在の作業量。 ユニットがスケジュールされると、特定のマシンに渡され、ローカルにロードされます。 systemd
実例。
使用 load
ユニットをロードしてスケジュールするコマンド:
fleetctl load hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212
以前にユニットを手動でロードしていなかった場合は、現在のディレクトリで適切なファイル名を検索することにより、このプロセスの一部として自動的にロードされます。
ここで、ユニットファイルを確認すると、ロードされていることがわかります。 どのマシンでスケジュールされているかを確認することもできます。
fleetctl list-unit-files
UNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212
これはまた、チェックアウトする私たちの最初の機会です list-units
指図。 このコマンドは、実行中またはスケジュール済みのユニットとそのステータスを表示するために使用されます。
fleetctl list-units
UNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 inactive dead
実際にユニットを起動するには、 start
指図。 これにより、ユニットファイルで定義されている開始コマンドを実行して、ユニットがロードされているマシンでユニットが起動します。
fleetctl start hello.service
Unit hello.service launched on 14ffe4c3.../10.132.249.212
もう一度、確認する必要があります list-unit-files
:
fleetctl list-unit-files
UNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212
上記の出力では、サービスが開始されたことがわかります。 The DSTATE
列は「望ましい状態」と STATE
実際の状態を示します。 これら2つが一致する場合、これは通常、アクションが成功したことを意味します。
私たちも見る必要があります list-units
また:
fleetctl list-units
UNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 active running
これにより、 systemd
州。 これはローカルデーモンから直接収集されるため、これはローカルシステムがサービス状態をどのように認識しているかをよりよく示しています。 The ACTIVE
列はユニットの一般化された状態ですが、 SUB
より低レベルの説明です。
サービスの停止
上記の各コマンドには、状態を逆にするコンパニオンコマンドがあります。
たとえば、サービスの実行を停止するには、 stop
指図。 これにより、ローカルマシンの systemd
ユニットで定義された停止コマンドを実行するインスタンス:
fleetctl stop hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212
ご覧のとおり、サービスは元に戻っています loaded
州。 これは、それがまだマシンにロードされていることを意味します systemd
、しかし現在は実行されていません。 ここで確認できます:
fleetctl list-unit-files
UNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 loaded loaded 14ffe4c3.../10.132.249.212
そのマシンのsystemdからユニットを削除しますが、 fleet
、 あなたはできる unload
ユニット。 ユニットが現在アクティブな場合、アンロードされる前に停止されます。
fleetctl unload hello.service
状態を確認すると、非アクティブとしてマークされていることがわかります。 また、ターゲットマシンがリストされていません。
fleetctl list-unit-files
UNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 inactive inactive -
からユニットを削除したい場合 fleet
完全に、私たちは使用することができます destroy
指図。 これにより、必要に応じてユニットが停止およびアンロードされ、ユニットが fleet
:
fleetctl destroy hello.service
ユニットファイルを変更する場合は、現在のユニットを破棄する必要があります fleet
送信/再開する前に。
ユニットステータスの取得
ユニットのステータスに関する情報を取得する方法のいくつかはすでに見てきました。
たとえば、私たちはどのようにカバーしました list-units
マシンで現在スケジュールされているすべてのユニットが一覧表示されます。
fleetctl list-units
UNIT MACHINE ACTIVE SUB
hello.service 14ffe4c3.../10.132.249.212 active running
The list-unit-files
すべてのユニットのリストを提供します fleet
知っている。 また、望ましい実際の状態に関する情報も提供します。
fleetctl list-unit-files
UNIT HASH DSTATE STATE TMACHINE
hello.service 0d1c468 launched launched 14ffe4c3.../10.132.249.212
起動されたユニットに関するより具体的な情報については、他のいくつかのコマンドがあります。 The 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クラスターを簡単に制御できます。 サービスとコンテナは、ほとんど問題なく別のマシンに移動できます。
後のガイドで、より詳細なフリートユニットファイルの作成方法について説明します。 これにより、CoreOSアーキテクチャを活用する柔軟で強力なサービスを作成できます。