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システムによって使用され、利用可能な各サービスを記述し、それを管理するために必要なコマンドを定義し、依存関係情報を設定して、各サービスの開始時にシステムが実行可能な状態になるようにします。 fleetデーモンは、クラスター全体のレベルでサービスを管理するために、systemdの上に構築されています。このため、標準のsystemdユニットファイルのわずかに変更されたバージョンを使用します。

fleetユニットファイルの詳細を確認するには、このテーマの詳細に従ってください。このガイドでは、これらのファイルの形式の概要を説明します。また、fleetctlについて学習するために使用できるサンプルユニットファイルも提供します。

フリートユニットファイルセクション

ほとんどのユニットファイルに含まれる基本的なセクションは次のとおりです。

ユニット：このセクションは、ユニットの「タイプ」に依存しないユニットに関する一般的な情報を提供するために使用されます。これには、メタデータ情報と依存関係情報が含まれます。これは主にfleetで説明を提供し、他のサービスユニットとの接続でこのユニットを指定するために使用されます。
ユニットタイプセクション：fleetデーモンは、次のようなさまざまなタイプのユニットを受け取ることができます。

タイプに特定のオプションがある場合、関連するタイプのセクションが許可されます。 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]セクションでは、開始タイムアウトを無効にしてから、サービスを開始する前に実行するいくつかのアクションを設定します。 ExecStartPreは、メインのExecStartアクションの前に実行されます。これらが=-で呼び出された場合、アクションが失敗し、サービスの完了に影響を与えない可能性があることを意味します。これが必要なのは、開始前のアクションが基本的に、以前に実行されていた可能性のあるサービスをすべて破棄するためです。何も見つからない場合、これは失敗します。これは単なるクリーンアップ手順であるため、サービスの開始を停止したくありません。

最後のpre-startアクションは、コマンドの実行に使用される基本的なbusyboxイメージをプルダウンします。これは必要なので、=-構文は使用しません。次に、「Hello World」を1秒に1回出力する無限ループで、この画像を使用してコンテナーを開始します。停止アクションは、単にこのコンテナーを停止します。

これは、あなたを立ち上げて実行するのにちょうど十分です。フリートファイルの開発方法の詳細については、フリートユニットファイルに関するガイドをご覧ください。

基本的なマシン管理コマンド

最初に行うことは、fleetctlユーティリティを紹介することです。クラスタ管理者として、このツールは、マシンのフリートを管理するためのメインインターフェイスになります。構文の多くは、systemdの管理ツールであるsystemctlから引き継がれています。

まず、次のように入力して、すべてのクラスターメンバーのリストを取得できます。

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」列は現在空白です。ただし、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実行可能ファイルで実行する場合と同様に、リモートホストで単一のコマンドを実行することもできます。たとえば、CoreOSが/etc/environmentというファイルに設定するCOREOS_PRIVATE_IPV4およびCOREOS_PUBLIC_IPV4変数の値を取得するには（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

上記の出力では、サービスが開始されたことがわかります。 DSTATE列は「望ましい状態」を示し、STATEは実際の状態を示します。これら2つが一致する場合、これは通常、アクションが成功したことを意味します。

list-unitsももう一度確認する必要があります。

fleetctl list-units

UNIT     MACHINE             ACTIVE  SUB
hello.service   14ffe4c3.../10.132.249.212  active  running

これにより、systemdの状態に関する情報が得られます。これはローカルデーモンから直接収集されるため、これはローカルシステムがサービス状態をどのように認識しているかをよりよく示しています。 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

list-unit-filesは、fleetが認識しているすべてのユニットのリストを提供します。また、望ましい実際の状態に関する情報も提供します。

fleetctl list-unit-files

UNIT     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

「follow」を表す-fパラメーターを使用することもできます。これは、tail -fと同様に動作し、最新のログエントリを引き続き返します。

fleetctl journal -f hello.service

結論

fleetとfleetctlを効果的に使用する方法を学ぶことで、CoreOSクラスターを簡単に制御できます。サービスとコンテナは、ほとんど問題なく別のマシンに移動できます。

後のガイドで、より詳細なフリートユニットファイルの作成方法について説明します。これにより、CoreOSアーキテクチャを活用する柔軟で強力なサービスを作成できます。