最近、 RancherOSオペレーティングシステムを含む新しいイメージをVirtual Private Cloud サービスに追加し、 CoreOSイメージを更新しました。
これらのオペレーティングシステムは、コンテナ内の多数のアプリケーションを簡単に管理し、 Kubernetes 、 Docker Swarm 、 Apache Mesosなどのさまざまなコンテナクラスタリングシステムを使用するツールを必要とするユーザーにとって重要です。
CoreOSとRancherOSは、最も一般的なLinuxディストリビューションとは異なります。コンテナ内でアプリケーションを実行するための最小限のソフトウェアセットのみが含まれています。 これらのシステムには、さまざまなプログラミング言語（Python、Rubyなど）のパッケージマネージャーとインタープリターがありません。
以下では、CoreOSとRancherOSの詳細を見て、etcdおよびフリートサービスの構成機能を分析し、RancherOSに基づいてDocker Swarmクラスターを設定する例を示します。
Coreos
CoreOSディストリビューションは 、隔離されたコンテナに多数のユーザーアプリケーションを迅速かつ大量に展開するために特別に設計されています。
CoreOSには、クラスター内の複数のノードとコンテナーを便利に管理するためのツールが事前にインストールされています。
- etcd-クラスター内の利用可能なサービス、構成、および一時ファイルに関する情報を取得するためにノードによって使用される分散データウェアハウス。
- Docker-コンテナー内でアプリケーションを配信および実行するためのメインプラットフォーム。
- rktは、CoreOSの作成者によって開発されたDockerの代替です。
- フリートは、クラスターの個別のノードで多くのsystemdインスタンスを管理し、負荷の少ないノードで必要なサービスを起動できる分散初期化システムです。
構成
システムパラメータを変更する主な方法は、cloud-config.yml設定ファイルで宣言型言語YAMLを使用して必要な設定を記述することです。 このファイルは、システムを構成するためにCloud-initユーティリティによって使用されます。
CoreOSはCloud-initの独自の実装を使用することに注意してください。その構成ファイルは、サービスを含むさまざまなクラウドサービスでシステムを構成するためにほとんどの通常のディストリビューションで使用されるLaunchpad-cloud-initのより一般的なバージョンの設定と部分的にのみ互換性があります仮想プライベートクラウド。
以下にcloud-config.ymlファイルの例を示します。
#cloud-config # Set hostname hostname: "node01" # Set ntp servers write_files: - path: /etc/systemd/timesyncd.conf content: | [Time] NTP=0.ru.pool.ntp.org 1.ru.pool.ntp.org coreos: units: # Configure static network on eth0 interface - name: iface-eth0.network runtime: true content: | [Match] Name=eth0 [Network] DNS=188.93.16.19 DNS=188.93.17.19 DNS=109.234.159.91 Address=10.11.12.13/24 Gateway=10.11.12.1 # Change standard SSH port - name: sshd.socket command: restart runtime: true content: | [Socket] ListenStream=2345 FreeBind=true Accept=yes
Cloud-initユーティリティは、指定されたパラメーターを使用して、SSHサービスのホスト名と標準ポート22を変更し、eth0インターフェイスで静的ネットワークを構成し、時刻同期のためにntp-serversを追加します。
cloud-config.yml設定ファイルの構造の詳細については、 公式ドキュメントをご覧ください。
Virtual Private Cloudサービスで既製のCoreOSイメージからサーバーを作成する場合、cloud-config.ymlを使用して基本的なシステム構成を実行する必要はありません。 ネットワークインターフェイスの構成など、標準のサーバー構成が自動的に実行されるように、イメージに必要な変更を既に行っています。
CoreOSを実行しているサーバーへのSSH経由のアクセスは、最初はサーバーの作成時に指定されたキーでのみ可能になります。 指定したキーがコアユーザーに追加されます。
独自のバージョンのcloud-initに加えて、CoreOSの作成者はIgnitionユーティリティを開発しました。 このツールはcloud-initの機能を複製し、ディスクパーティションテーブルの変更やファイルシステムのフォーマットなど、低レベルのシステム設定を行うこともできます。 これは、 initramfsの起動プロセス中に、システム起動の初期段階でIgnitionが動作を開始するという事実により可能です。
Ignitionは、構成ファイルにJSON形式を使用します。
以下は、IgnitionがBtrfsのルートパーティションをフォーマットし、Cloud-initの上記の例と同様のパラメーターでシステムを構成するサンプルファイルです。
{ "ignition": { "version": "2.0.0" }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "create": { "force": true, "options": [ "--label=ROOT" ] } } }], "files": [{ "filesystem": "root", "path": "/etc/systemd/timesyncd.conf", "mode": 420, "contents": { "source": "data:,%5BTime%5D%0ANTP=0.ru.pool.ntp.org%201.ru.pool.ntp.org%0A" } }, { "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,node01" } } ] }, "networkd": { "units": [{ "name": "iface-eth0.network", "contents": "[Match]\nName=eth0\n\n[Network]\nDNS=188.93.16.19\nDNS=188.93.17.19\nDNS=109.234.159.91\nAddress=10.11.12.13/24\nGateway=10.11.12.1" }] }, "systemd": { "units": [{ "name": "sshd.socket", "command": "restart", "runtime": true, "contents": "[Socket]\nListenStream=2345\nFreeBind=true\nAccept=yes" }] } }
Ignitionのすべての機能の詳細については、 公式ドキュメントをご覧ください。
CoreOSクラスタの構成例
この例では、VPCコントロールパネルで次のパラメーターを使用してCoreOSを実行する3つのサーバーを事前に作成する必要があります。
サーバーを作成したら、etcdサービスのdiscovery-urlが必要になります。 これを行うには、パブリック無料サービスdiscovery.etcd.ioを使用できます。 ホストnode00で次のコマンドを実行します。
core@node00 ~ $ curl -w "\n" 'https://discovery.etcd.io/new?size=3' https://discovery.etcd.io/ec42cfef0450bd8a99090ee3d3294493
結果のURLと追加のetcdパラメーターを各サーバーの/usr/share/oem/cloud-config.ymlファイルに追加します。
coreos: etcd2: discovery: https://discovery.etcd.io/ec42cfef0450bd8a99090ee3d3294493 advertise-client-urls: http://192.168.0.10:2379,http://192.168.0.10:4001 initial-advertise-peer-urls: http://192.168.0.10:2380 listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 listen-peer-urls: http://192.168.0.10:2380 units: - name: etcd2.service command: start - name: fleet.service command: start
etcd2セクションのパラメーターは、 プロトコルのアドレスを示します。// アドレス：ポート 。これは、ノードをアナウンスし、クラスターの他のメンバーとデータを交換するために必要です。
単位セクションでは、システム内のsystemdユニットを制御できます。 私たちの場合、 etc2d.serviceおよびfleet.serviceユニットを起動します 。
node01およびnode02サーバーの場合、同様の変更をcloud-config.ymlに追加し、 node01サーバーのIPアドレスを192.168.0.10から192.168.0.11に、 node02サーバーのアドレス192.168.0.12に変更する必要があります。
新しい設定を追加した後、3つのサーバーすべてでCloud-initユーティリティを実行します（または、これらのサーバーを単純に再起動できます）。
core@node00 ~ $ sudo coreos-cloudinit --from-file /usr/share/oem/cloud-config.yml
etcdサービスのステータスも確認します。
core@node00 ~ $ etcdctl cluster-health member 3aaf91fd1172594e is healthy: got healthy result from http://192.168.0.11:2379 member 8cf40790248e1dcd is healthy: got healthy result from http://192.168.0.12:2379 member 96b61f40c082cd0b is healthy: got healthy result from http://192.168.0.10:2379 cluster is healthy
分散ストレージの可用性を確認し、 node00サーバー上の値を使用して新しい用語（用語etcd-キー）を追加します。
core@node00 ~ $ etcdctl set /common/cluster-name selectel-test-cluster selectel-test-cluster
次に、値を持つ新しいキーがクラスターの他のノードから利用できることを確認します。
core@node01 ~ $ etcdctl get common/cluster-name selectel-test-cluster
素晴らしい、etcdは機能しており、フリートサービスの使用を開始できます。
この例では、フリートを使用して、隔離されたDockerコンテナーでNginxを実行します。 まず、systemdユニット/etc/systemd/system/nginx.serviceを作成します。
[Unit] Description=Nginx Test Service [Service] EnvironmentFile=/etc/environment ExecStartPre=/usr/bin/docker pull nginx ExecStart=/usr/bin/docker run --rm --name nginx -p 80:80 nginx ExecStop=/usr/bin/docker kill nginx [X-Fleet] Conflicts=nginx.service
X-FleetセクションのConflictsパラメーターは、同じノードで2つ以上のNginxサービスを起動することを禁止します。これにより、クラスターの負荷が「スミア」され、サービスの可用性が高まります。 systemdユニット内で使用できる追加のXフリートパラメーターについては、 フリートのドキュメントで説明しています 。
ファイル内の残りのセクションはsystemdの標準です。たとえば、CoreOSからの短い紹介命令で見ることができます。
fleetctlを使用して、クラスターで新しいnginx.serviceユニットを実行します。
core@node00 ~ $ fleetctl start /etc/systemd/system/nginx.service Unit nginx.service inactive Unit nginx.service launched on 1ad018e0.../192.168.0.11
その後、クラスターの任意のノードのユニットのリストにNginxが存在することがわかります。
core@node02 ~ $ fleetctl list-units UNIT MACHINE ACTIVE SUB nginx.service 1ad018e0.../192.168.0.11 active running
core@node02 ~ $ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET nginx.service 0c112c1 launched launched 1ad018e0.../192.168.0.11
ご覧のとおり、Nginxを含むコンテナは、 node01サーバーに対応するIPアドレス192.168.0.11のサーバーで起動しました。
node01サーバーを無効にするか完全に削除することができます。その後、フリートは自動的にNginxを別の使用可能なノードに転送します。
Etcdは、クラスターのステータスを確認するときにメンバーが利用できないことを報告します。
core@node00 ~ $ etcdctl cluster-health failed to check the health of member 3aaf91fd1172594e on http://192.168.0.11:2379: Get http://192.168.0.11:2379/health: dial tcp 192.168.0.11:2379: i/o timeout failed to check the health of member 3aaf91fd1172594e on http://192.168.0.11:4001: Get http://192.168.0.11:4001/health: dial tcp 192.168.0.11:4001: i/o timeout member 3aaf91fd1172594e is unreachable: [http://192.168.0.11:2379 http://192.168.0.11:4001] are all unreachable member 8cf40790248e1dcd is healthy: got healthy result from http://192.168.0.12:2379 member 96b61f40c082cd0b is healthy: got healthy result from http://192.168.0.10:2379 cluster is healthy
しかし、ご覧のとおり、Nginxサービスのステータスは正常であり、別の作業ノードで開始されています。
core@node00 ~ $ fleetctl list-units UNIT MACHINE ACTIVE SUB nginx.service 4a1ff11c.../192.168.0.10 active running
CoreOSに基づくクラスターetcd + Docker +フリートの構成の基本的な例を確認しました。 次のセクションでは、CoreOSに基づいており、コンテナを積極的に使用するために設計された別のディストリビューションRancherOSを見ていきます。
RancherOS
RancherOSディストリビューションはCoreOSのフォークです。 このシステムの特徴は、ユーザーアプリケーションがコンテナーで起動されるだけでなく、すべてのシステムサービスも起動されることです。 さらに、RancherOSでは、DockerのPID = 1であるため、システムのカーネルの直後に起動します。
オペレーティングシステムには2つのDockerインスタンスが含まれています。 それらの1つはシステム1で、システムが機能するために必要なコンテナudev、acpid、syslog、ntpおよびその他の基本サービスを実行します。 システムDockerインスタンスは、通常のLinuxディストリビューションに存在する従来の初期化システム（systemd、Upstart、SysV）を置き換えます。
2番目のDockerインスタンスは、カスタムアプリケーションを起動するために使用され、システムDocker内で起動される特別なコンテナーです。
この分離により、システムコンテナが誤ったユーザーアクションから保護されます。
RancherOSのDockerインスタンスは通常のDocker環境であるため、Docker コマンドの標準セットを使用してユーザーコンテナとシステムコンテナの両方を管理できます 。
# Docker [rancher@rancher-os ~]$ docker --version Docker version 1.12.1, build 23cf638
# Docker Hub [rancher@rancher-os ~]$ docker run -d nginx Unable to find image 'nginx:latest' locally latest: Pulling from library/nginx … Status: Downloaded newer image for nginx:latest
# [rancher@rancher-os ~]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 2ec5126e8dd5 nginx "nginx -g 'daemon off" About a minute ago Up About a minute 80/tcp, 443/tcp sad_fermat
システムコンテナにアクセスするには、 sudoユーティリティと共にsystem-dockerコマンドを使用する必要があります。
次のコマンドを使用して、オペレーティングシステムの実行中の基本サービスのリストを表示できます。
[rancher@rancher-os ~]$ sudo system-docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a566d0c7cc4c rancher/os-docker:1.12.1 "/usr/bin/user-docker" 8 minutes ago Up 8 minutes docker 8697a04e90a4 rancher/os-console:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes console c8c337282aaa rancher/os-base:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes network 1e55244fc99c rancher/os-base:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes ntp fd6a03fdb28f rancher/os-udev:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes udev 7e9e50c28651 rancher/os-acpid:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes acpid 5fec48b060f2 rancher/os-syslog:v0.6.1 "/usr/bin/ros entrypo" 8 minutes ago Up 8 minutes syslog
システムコンテナは次のように再起動されます。
[rancher@rancher-os ~]$ sudo system-docker restart ntp
構成
システムの自動構成のための主要なツールは、cloud-initの独自の実装です。これは、 cloud-init-executeとcloud-init-saveの 2つの別個のユーティリティに分割されました。 他のcloud-init実装と同様に、RancherOSバージョンは宣言型言語YAMLを使用しますが、別のディストリビューションのcloud-config.ymlはRancherOSと互換性がありません。
可能なすべての構成ファイルディレクティブは、 docs.rancher.com / osの公式ドキュメントに記載されています。
システムサービスは、以下に説明する順序でファイルから取得したパラメーターを使用します（指定したリストの後続の各ファイルは、一致する場合、以前のパラメーターを上書きします）。
- /usr/share/ros/os-config.yml-デフォルトのシステム設定。
- /usr/share/ros/oem/oem-config.yml-この場合、これはVPCコントロールパネルの設定に従って、静的ネットワーク設定の自動構成を可能にするファイルです。
- ディレクトリ/var/lib/rancher/conf/cloud-config.d/の YAMLファイル。
- /var/lib/rancher/conf/cloud-config.yml-rosユーティリティによって設定された値を保存するファイル。これについては後で説明します。
- キーワード「rancher」で始まるカーネルオプション。
- / var / lib / rancher / conf / metadata -cloud-init-saveユーティリティによって追加された使用済みクラウドサービスのメタデータ。
rosユーティリティを使用してシステム構成を変更できます。その後、 / var / lib / rancher / conf / cloud-config.ymlファイルに新しいパラメーターが表示されます。
[rancher@rancher-os ~]$ sudo ros config set rancher.network.dns.nameservers "['188.93.16.19','188.93.17.19', '109.234.159.91']"
[rancher@rancher-os ~]$ sudo cat /var/lib/rancher/conf/cloud-config.yml rancher: network: dns: nameservers: - 188.93.16.19 - 188.93.17.19 - 109.234.159.91
システムサービスの構成の変更に加えて、rosはオペレーティングシステムのバージョン、Dockerバージョン、TLS、およびSELinux設定の管理にも使用されます。
Virtual Private Cloudサービスで既製のRancherOSイメージを使用する場合、基本的なシステムパラメーター（ネットワークインターフェイスの構成など）を構成する必要はありません。
インストール後、サーバーはVPCコントロールパネルで選択したIPアドレスで利用可能になります。 SSHプロトコルを使用してサーバーに接続できますが、最初は、サーバーの作成時に指定されたキーでのみ認証が可能になります。 このキーは、 牧場主ユーザーに追加されます。
バージョン管理
オペレーティングシステムの現在のバージョンを確認するには、次のコマンドを使用します。
[rancher@rancher-os ~]$ sudo ros os version v0.6.1
そして、利用可能なすべてのリリースを確認するには：
[rancher@rancher-os ~]$ sudo ros os list rancher/os:v0.4.0 remote rancher/os:v0.4.1 remote rancher/os:v0.4.2 remote rancher/os:v0.4.3 remote rancher/os:v0.4.4 remote rancher/os:v0.4.5 remote rancher/os:v0.5.0 remote rancher/os:v0.6.0 remote rancher/os:v0.6.1 remote
sudo ros os upgradeコマンドを使用してシステムの最新の安定バージョンをインストールするか、 -iオプションを指定して必要なバージョンを選択できます。
[rancher@rancher-os ~]$ sudo ros os upgrade -i rancher/os:v0.5.0
弊社が示すバージョン0.5.0はインストールされているバージョン6.0.1よりも古いため、システムを更新する代わりに、ダウングレードが発生します
Dockerバージョンの管理も同様に簡単です。 以下に例を示します。
# [rancher@rancher-os ~]$ sudo ros engine list disabled docker-1.10.3 disabled docker-1.11.2 current docker-1.12.1
# 1.11.2 [rancher@rancher-os ~]$ sudo ros engine switch docker-1.11.2 INFO[0000] Project [os]: Starting project INFO[0000] [0/19] [docker]: Starting … INFO[0010] Recreating docker INFO[0010] [1/19] [docker]: Started
RancherOS上のDocker Swarmクラスター
Docker 1.12では、Docker Swarmコンテナーのクラスターを管理するための統合ツールが導入され、完成したクラスターのセットアップがはるかに簡単になりました。
この例では、Virtual Private Cloudサービスで既製のRancherOSイメージを使用します。 Dockerバージョン1.12.1を使用します。
次のパラメーターを持つ3つのサーバーを作成する必要があります。
まず、Docker Swarmクラスターの作成を初期化する必要があります。そのために、manager0 ノードで次のコマンドを実行します。
[rancher@manager0 ~]$ docker swarm init --advertise-addr 192.168.0.100 Swarm initialized: current node (8gf95qb6l61v5s6561qx5vfy6) is now a manager. To add a worker to this swarm, run the following command: docker swarm join \ --token SWMTKN-1-0hlhela57gsvxzoaqol70n2b9wos6qlu3ukriry3pcxyb9j2k6-0n1if4hkvdvmrpbb7f3clx1yg \ 192.168.0.100:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
表示されるプロンプトからわかるように、ノードworker0およびworker1でコマンドを実行する必要があります。
docker swarm join \ --token SWMTKN-1-0hlhela57gsvxzoaqol70n2b9wos6qlu3ukriry3pcxyb9j2k6-0n1if4hkvdvmrpbb7f3clx1yg \ 192.168.0.100:2377
クラスターノードのステータスを確認してみましょう。 そのためには、 manager0でコマンドを実行します 。
[rancher@manager0 ~]$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 366euocei01dw3ay66uwzb3pv worker0 Ready Active 67pt4fo5gi13cxkphtfzfbfbo worker1 Ready Active 8gf95qb6l61v5s6561qx5vfy6 * manager0 Ready Active Leader
Docker Swarmはすぐに使用できます！
デフォルトでは、クラスターのすべてのノードで新しいサービスが起動されます。 これらの設定を調整して、すべてのサービスがworker0およびworker1ノードで開始され、 manager0ノードには制御ロールのみがあるようにします。
これらのパラメーターを作成するには、 manager0ノードの「可用性」を変更します。
[rancher@manager0 ~]$ docker node update --availability drain manager0
Nginxコンテナーでサービスを実行します。
[rancher@manager0 ~]$ docker service create --name webserver --replicas 1 --publish 80:80 nginx
応答として、サービス識別子を取得します。
av1qvj32mz8vwkwihf0lauiz8
最初は、レプリカの数は0になり、このサービスに関連する唯一のタスクは「準備中」ステータスになります。
[rancher@manager0 ~]$ docker service ls ID NAME REPLICAS IMAGE COMMAND av1qvj32mz8v webserver 0/1 nginx
[rancher@manager0 ~]$ docker service ps webserver ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR cjxkza3qzx5m73bgbls0r26m6 webserver.1 nginx worker1 Running Preparing about a minute ago
数秒後、必要なNginxイメージがDocker Hubから自動的にダウンロードされ、その後サービスステータスが「実行中」に変わります。
[rancher@manager0 ~]$ docker service ls ID NAME REPLICAS IMAGE COMMAND av1qvj32mz8v webserver 1/1 nginx
[rancher@manager0 ~]$ docker service ps webserver ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR cjxkza3qzx5m73bgbls0r26m6 webserver.1 nginx worker1 Running Running 8 minutes ago
ご覧のとおり、サービスはworker1 ノードで開始されました（「NODE」列の値）。 VPCコントロールパネルでこのノードを無効にし、 ウェブサーバーサービスのステータスを再度確認します。
[rancher@manager0 ~]$ docker service ps webserver ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 5lwf4z54p74qtoopuilshw204 webserver.1 nginx worker0 Running Preparing 32 seconds ago cjxkza3qzx5m73bgbls0r26m6 \_ webserver.1 nginx worker1 Shutdown Running 16 minutes ago
サービスのステータスが「準備中」に変更され、Docker Swarmはサービスを別の作業ノードworker0に転送しようとしています。遅延は、ノードworker0で実行する前にDocker HubからNginxイメージを追加する必要があるためです。
イメージが自動的に追加された後、webserverサービスはworker0 ノードで正常に開始されます ：
[rancher@manager0 ~]$ docker service ps webserver ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 5lwf4z54p74qtoopuilshw204 webserver.1 nginx worker0 Running Running about a minute ago cjxkza3qzx5m73bgbls0r26m6 \_ webserver.1 nginx worker1 Shutdown Running 19 minutes ago
落ちたノードからサービスを転送する際のダウンタイムを避けるために、このサービスのレプリカの数を増やすことができます。
コマンドを実行しましょう（ worker1ノードをオンにすることを忘れないでください）：
[rancher@manager0 ~]$ docker service update --replicas 2 webserver
サービスは2番目のノードworker1への複製を開始します。
[rancher@manager0 ~]$ docker service ps webserver ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 5lwf4z54p74qtoopuilshw204 webserver.1 nginx worker0 Running Running 11 minutes ago cjxkza3qzx5m73bgbls0r26m6 \_ webserver.1 nginx worker1 Shutdown Complete 6 minutes ago f3o7icke69zw83ag92ywol0dr webserver.2 nginx worker1 Running Preparing 2 seconds ago
おわりに
この記事では、分離されたコンテナーのクラスターを迅速に展開し、便利に管理するように設計されたLinuxディストリビューションを確認しました。
CoreOS、RancherOS、および類似のオペレーティングシステムを使用して、ご自身の経験を共有していただければ幸いです。