この記事は、 PMOB Advent Calendar 2017 の記事です。
現在研究室でCoreOSを使っています。 現在単機で動かしているのであんまり面白い話はできませんが、 CoreOSに関する雑記書きます。
CoreOSとは
CoreOSはContainer Linux、 コンテナ利用を着眼点を置いたLinuxディストリビューションです。 主な特徴として、
- 最小限のツール
/usr
に書き込めない- パッケージマネージャはない
- プロセスはコンテナで実行する
といったものがあります。 簡単に言うと、 ソフトウェアをインストールする通常の手段がない。 アプリケーションを走らせたかったらコンテナのイメージを作成or取得して、 コンテナランタイムで走らせるという環境です。
CoreOSとその関連ツールの開発は非常に活発で、 ドキュメンテーションの内容も頻繁に更新されているので、 見ているだけでも楽しいOSです。
インストール時にちょっと癖があるので主にその辺のことを書きます。
CoreOSのインストール
ドキュメントではCoreOSのインストールについて、 ベアメタルとクラウド両方へのガイドが記述されています。 私はできるならクラウドでの利用を推奨します。 理由はその方が圧倒的に楽だからです。 CoreOS自体主にクラウドでの利用を想定して作られているため、 例えばクラスタリングや分散の機能はクラウド上で利用する方が設定が楽ですし、 ドキュメントも充実しています。
他にインストール時に他に注意することはチャンネルです。 CoreOSには update-engine というプロセスがあり、 OSのバージョンを自動でアップデートします。 なのでOSのバージョンを意識してインストールする必要はありませんが、 アップデート方針についてチャンネルという概念が導入されています。
チャンネルには stable
beta
alpha
の3つが用意されていて、
利用者のCoreOSの運用方針によってアップデート方針を設定することができます。
ちなみに stable
は安定すぎて使いづらい面もあります。
最新のDockerの安定バージョンは17.09.0ですが、
stable
チャンネルのDocker Engineは昨日まで1.12.0で、
最新の機能をいくつか諦めていました。
昨日のアップデートでstable
チャンネルのDockerも急に17.09.0に上がりましたけど。
アクティブな環境下ではとりあえず beta
チャンネルの利用をお勧めします。
リリースノートも結構読みやすいので、チャンネル選択に役立ちます。
もちろんOSのバージョンを固定することもできます。 systemdからupdate-engineプロセスを殺せば自動アップデートが切られます。
CoreOSの構成設定
CoreOSをインストールする際、 ネットワーク設定やsystemdのユニットなどは設定ファイルで指定することになります。 同じ設定ファイルから同じシステム構成のCoreOSマシンが作成されるというのが目的です。
CoreOSの初期設定には Ignition というツールが使われています。 (以前使われていた cloud-config はdeprecatedです)
設定ファイルの記述にはまず CL-Config (Container Linux Config) というフォーマットのYAMLを用います。 フォーマットはドキュメントで指定されており、例えば、
- ユーザー
core
にログイン用のsshキーを登録 - sshdのListenポートを変更
- パスワード認証を切る
といった設定の cl-config.yml は以下のようになります。
# ユーザー `core` のauthorized_keyに自分のpublic keyを追加
passwd:
users:
- name: core
ssh_authorized_keys:
- ssh-rsa ......
# sshd のListenポートを2222に変更
systemd:
units:
- name: sshd.socket
dropins:
- name: 10-sshd-port.conf
contents: |
[Socket]
ListenStream=
ListenStream=2222
# パスワード認証を切ったりなんだりする
storage:
files:
- path: /etc/ssh/sshd_config
filesystem: root
mode: 0600
contents:
inline: |
UsePrivilegeSeparation sandbox
PermitRootLogin no
AllowUsers core
PasswordAuthentication no
まあ、何やりたいかはわかる感じになってると思います。 このYAMLはそのままでは使えません。 Ignitionは ignition.json のフォーマットを要求するので、 container-linux-config-transpiler を用いて cl-config.yml をJSONに変換する必要があります。
$ ct < cl-config.yml > ignition.json
ignition.json 設定ファイルを直で書いてもいいのですが、 以前使われていた cloud-config がYAMLだったこともあり、 私は CL-Config を使ってます。
追加のソフトウェアをインストールする
ソフトウェアをインストールする正攻法がないと書きましたが、
一応PATHに/opt/bin
が含まれているので、
ここに入れれば走ります。
例えばdocker-composeをインストールする際、
以下のようなスクリプトをよく見ます。
DOCKER_COMPOSE_VERSION="1.17.0"
mkdir -p /opt/bin
curl -L https://github.com/docker/compose/releases/download/$DOCKER_COMPOSE_VERSION/docker-compose-`uname -s`-`uname -m` > /opt/bin/docker-compose
chmod +x /opt/bin/docker-compose
まあこれやりたかったらCoreOS使うなって話でしょうけど。 ちなみに、コンテナ構成の管理はKubernetesの使用が想定されています。
また、SDKを用いてCoreOSのイメージを自分でビルドすることで、 追加のソフトウェアをインストールしたイメージを作ることもできます。
余談: コンテナランタイム
この記事の最初から「コンテナランタイム」と言う言葉を使っていますが、 CoreOSはDockerの他に rkt というコンテナランタイムをサポートしています。 これはCoreOS, Incが開発しているPodネイティブなコンテナエンジンだそうですよ。 使ったことないです。 ちなみにPodというのはk8sで使われている単位で、コンテナの集合です。 例えばアプリケーションサーバーとDBのコンテナをまとめて1Podみたいな。
この辺の話だとかetcdとflannelの話が多分CoreOSの一番面白いところなんですけど、 触ってないので話せない。そんなことより卒論を終わらせなければいけない。
来週は走らせてるイメージの話とかします。 関係ないけど core と kernel って英語的にどういう違いがあるんですかね。 おしまい。