FleetとFleetctlを使用してCoreOSクラスターを管理する方法

投稿日: 2019-11-08 2022-10-17
タグ: Clustering, CoreOS, Networking, Scaling, System Tools

ステータス：非推奨

理由： 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アーキテクチャを活用する柔軟で強力なサービスを作成できます。

getdocs

13036