CoreOSを使っている話

CoreOS


この記事は、 PMOB Advent Calendar 2017 の記事です。

現在研究室でCoreOSを使っています。 現在単機で動かしているのであんまり面白い話はできませんが、 CoreOSに関する雑記書きます。

CoreOSとは

CoreOSはContainer Linux、 コンテナ利用を着眼点を置いたLinuxディストリビューションです。 主な特徴として、

といったものがあります。 簡単に言うと、 ソフトウェアをインストールする通常の手段がない。 アプリケーションを走らせたかったらコンテナのイメージを作成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 チャンネルの利用をお勧めします。

リリースノートも結構読みやすいので、チャンネル選択に役立ちます。

https://coreos.com/releases/

もちろんOSのバージョンを固定することもできます。 systemdからupdate-engineプロセスを殺せば自動アップデートが切られます。

CoreOSの構成設定

CoreOSをインストールする際、 ネットワーク設定やsystemdのユニットなどは設定ファイルで指定することになります。 同じ設定ファイルから同じシステム構成のCoreOSマシンが作成されるというのが目的です。

CoreOSの初期設定には Ignition というツールが使われています。 (以前使われていた cloud-config はdeprecatedです)

設定ファイルの記述にはまず CL-Config (Container Linux Config) というフォーマットのYAMLを用います。 フォーマットはドキュメントで指定されており、例えば、

といった設定の 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 って英語的にどういう違いがあるんですかね。 おしまい。