CoreOS とその関連技術に関するここ半年間の私の活動まとめ

00-README.md

CoreOS とその関連技術に関するここ半年間の私の活動まとめ

はじめに

最近、社内で私が「何者で何をしているのか見えないので可視化して欲しい」という案件が出ているらしいので、ヘコヘコと徒然なるままに書いていきたいと思うのであります。

社内向けというだけでなく社外の人にも発信出来る内容に、との仕様も要求され、社外向けには出来るだけ旬なネタで、かつ、社内向けにはそれを理解する上で必要な関連する技術を個々に触れながら基礎知識が無くても理解出来るように、との追加仕様も提示されております。

で、何をネタにしてどのように書けばいいのか迷った訳ですが、自分が実際にやって来た内容である CoreOS であればそこそこ旬であるし、それをおさらいしつつ、関連技術も Docker、Omaha、systemd、BtrFS、Golang、etcd、Kubernetes 等々多岐にわたるので、それらに関して私見も含めてわかりやすく書ければいいかなぁと、とりあえず書き始めようとしている次第であります。

何者か

ネットではここ10年程 YungSang として活動しておりまして、ハンドルがそんな感じなので韓国人に間違われたりしているようなのですが生粋の日本人です。10年前に業務で必要に迫られてブログを開設する際に、当時自分の中でブームだったハングルの音を自分の名前に当てただけなのです。実際はこのような名前は韓国では存在しないようです。

アイコンのカリフォルニア・ジリスは、私がこちらに来てリスに出会い、自分で撮った写真の中から一番良い物を選びました。リス、可愛いよ、リス。

元々は C のプログラマで、日立ソフトという会社での最初の２、３年で得たプログラムとエンジニアリングの知識と経験が殆ど全てです。それ以降は JavaScript から Golang まで全て独学で手探りでやってきました。なので、正式な方法を習得していない可能性が高いですw

また、日立ソフトを退社して以降、長年 Web のバックエンドとフロントエンドの開発をやっていまして、インフラは既に用意されている環境で育ったので、インフラの経験はあまりありません。なので、中途半端な情報になっている可能性も高いですw

それらを予めご承知おきして頂き、生温かくふふーんと読んで頂ければ幸いです。

目次

という訳で、目標は CoreOS ですが、いろいろ脇道にそれながら、その都度、個々の要素に焦点を当てながら、現在までの進捗をまとめて行きたいと思います。 以下、暫定項目を列挙します。

1. CoreOS の概要
   1. Read-only Linux Kernel
   2. Update like App
   3. Docker centric
   4. Cluster ready
2. テスト環境の構築
   1. VirtualBox
   2. Vagrant
      • CoreOS with Vagrant
      • Docker provisioner
      • Docker provider
      • Vagrant Cloud
      • VagrantBar
      • Pecrant
        • Peco
   3. Packer
      • Golang
   4. boot2docker
      • boot2docker.iso
      • boot2docker-cli
      • boot2docker.box
   5. Parallels Desktop
      • vagrant-parallels
      • packer-parallels
   6. Git
   7. GitHub
3. Customization
   1. systemd
   2. networkd
   3. cloud-config
4. Docker
   1. Container
      • namespaces
      • cgroup
   2. Image、File System
      • BtrFS
   3. Command line
   4. Dockerfile
   5. Docker Hub
   6. nsenter
   7. nsinit
5. Update
   1. Configuration
   2. Omaha server
6. Cluster
   1. etcd
   2. fleet
7. Kubernetes

Appendix 1. Code Layout
Appendix 2. Release Channels

01-CoreOS.md

1. CoreOS の概要

• https://coreos.com/

• CoreOS 入門 - Qiita
  http://qiita.com/mopemope/items/fa9424b094aae3eac580

• CoreOS入門 - SlideShare
  http://www.slideshare.net/YutakaMatsubara/coreos-35320632

とか、かなりいいリソースがあるので、そちらを参照して頂ければ OK なのですが、それではアカンでしょうから私の言葉で書いていきますよと。

Read-only Linux Kernel

CoreOS にはいくつかのキーになる特徴があるのですが、まず一つ目は「カーネルとシステム系の領域は書き込み出来ない」ことが上げられるでしょう。

この特徴は次の項目で述べる「Update like App」や「Docker centric」にも絡んで来るので重要です。

core@localhost ~ $ sudo df
Filesystem     1K-blocks   Used Available Use% Mounted on
rootfs          38468588  29724  38202820   1% /
devtmpfs          499512      0    499512   0% /dev
tmpfs             511100      0    511100   0% /dev/shm
tmpfs             511100    260    510840   1% /run
tmpfs             511100      0    511100   0% /sys/fs/cgroup
/dev/sda9       38468588  29724  38202820   1% /
/dev/sda3        1032088 327224    652436  34% /usr
tmpfs             511100      0    511100   0% /tmp
tmpfs             511100      0    511100   0% /media
/dev/sda6         110576     76    101328   1% /usr/share/oem
/dev/sda9       38468588  29724  38202820   1% /var/lib/docker/btrfs
core@localhost ~ $ ls -l /
total 20
lrwxrwxrwx  1 root root    7 Aug  5 00:03 bin -> usr/bin
drwxr-xr-x  1 root root    6 Aug  5 00:03 boot
drwxr-xr-x 15 root root 2760 Aug  7 22:23 dev
drwxr-xr-x  1 root root 1030 Aug  7 22:23 etc
drwxr-xr-x  1 root root    8 Aug  5 00:03 home
lrwxrwxrwx  1 root root    5 Aug  5 00:04 lib -> lib64
lrwxrwxrwx  1 root root    9 Aug  5 00:03 lib64 -> usr/lib64
drwxrwxrwt  2 root root   40 Aug  7 22:23 media
drwxr-xr-x  1 root root    0 Aug  5 00:03 mnt
drwxr-xr-x  1 root root    6 Aug  7 22:23 opt
dr-xr-xr-x 95 root root    0 Aug  7 22:23 proc
drwx------  1 root root    0 Aug  5 00:03 root
drwxr-xr-x 17 root root  420 Aug  7 22:23 run
lrwxrwxrwx  1 root root    8 Aug  5 00:03 sbin -> usr/sbin
drwxr-xr-x  1 root root    0 Aug  5 00:03 srv
dr-xr-xr-x 13 root root    0 Aug  7 22:23 sys
drwxrwxrwt  8 root root  160 Aug  7 22:23 tmp
drwxr-xr-x 11 root root 4096 Aug  5 00:08 usr
drwxr-xr-x  1 root root   82 Aug  7 22:23 var

上記が CoreOS のディレクトリ構成ですが、この中で /usr のパーティションが書き込み不可になっています。ですから、そこへのリンクになっている /bin、/sbin、/lib、/lib64 が /usr/local/ も含めて全て書き込み出来ません。

ユーザが基本的に使用する領域は、core ユーザのホームである /home/core 以下か、/opt 以下になるでしょう。/opt/bin はデフォルトで $PATH に入っているのでここにツールを入れると便利です。クラスタ管理ツールである Kubernetes もここを利用しています。

設定に関しては /etc 以下が普通に使用できます。(初期 Alpha 版は /etc の書き込みも出来なかったそうです。)

このように、カーネルやシステムの書き換えが出来ないので、不用意にシステムに変更が加えられることがありません。これは、ユーザから見ると不便である反面、システム管理者からすればシステムの維持に払う負荷がかなり低減されるでしょう。

Update like App

前項のように、カーネルやシステムの書き換えが出来ないことにより、システムのアップデートも機械的に自動的にやってしまうことが出来るようになります。

CoreOS は Chrome OS 派生の OS でもあるのですが、そのアップデートも Chrome OS、Chrome Browser やその拡張機能の更新に使われている方法と同様に Omaha という Update Engine(Server and Protocol) を使って自動的に行われます。

core@localhost ~ $ sudo lsblk -o NAME,FSTYPE,SIZE,PARTLABEL,MOUNTPOINT
NAME   FSTYPE  SIZE PARTLABEL  MOUNTPOINT
sda           39.1G
|-sda1 vfat    128M EFI-SYSTEM
|-sda2          64M BOOT-B
|-sda3 ext4      1G USR-A      /usr
|-sda4           1G USR-B
|-sda6 ext4    128M OEM        /usr/share/oem
|-sda7          64M OEM-CONFIG
`-sda9 btrfs  36.7G            /var/lib/docker/btrfs

上記が CoreOS のパーティションですが、現在 /usr には /dev/sda3 である USR-A が使われています。 update_engine デーモンが定期的に Update Server に問い合わせを行い、新しい CoreOS のイメージがあると、自動的にダウンロードし、現在サブになっている USR-B のパーティションにインストールし、USR-B のプライオリティを上げてリブートをかけます。

これにより、ユーザ領域はそのままに、システム領域を常に最新の状態に、しかも自動的に更新することが可能になっています。

Docker centric

Docker については巷にたくさんの解説があふれているのでそちらを参照して頂きつつ、ここでも別項を設けて説明しないとならないとは思っているのですが、ここで敢えて一言で言うならば、Linux カーネル上のリソース・パーティショニング(コンテナ)とそのコンテナ内のイメージを管理する為のツールとなるでしょうか。仮想化という言葉を使うと、カーネルの仮想化、アプリケーション実行環境の仮想化と言えるかも知れません。

前項「Read-only Linux Kernel」で述べたように、CoreOS のカーネル／ライブラリは書き込み不可になっているので、アプリケーションをインストール／実行するには、基本的にこの Docker を使ってコンテナを作成し、このコンテナ内で実行することが求められます。

逆に言うと、コンテナ内で必要なライブラリやツール／アプリケーションを構築して実行するが故に、CoreOS のカーネルは基本的な機能に留めることが出来、コンパクトで管理しやすいものになっているとも言えます。

ちなみに、Docker 以外でアプリケーションを直接 CoreOS 上にインストールするとなると、利用できるライブラリが限られるので、そのオブジェクトにはスタティックにライブラリをリンクしておく必要があります。この点、Go言語で書かれたコードから生成されたオブジェクトであれば、元々「一つのオブジェクトに全てを含む」という特徴を持っているので最適です。前述の Kubernetes も Go言語で書かれており、直接 /opt/bin にインストールして使うことが出来ます。

もう一つの方法として、systemd-nspawn というもう一つの軽量なコンテナ型仮想化ツールを持っており、CoreOS では toolbox というラッパーで簡単に利用できるようになっています。このコンテナからは、ホストのネットワークとファイルシステムへのアクセスが可能になっているので、自分の好きな環境で開発やデバッグを行いつつ、成果物を CoreOS に持って行くことが出来ます。

core@localhost ~ $ toolbox
Pulling repository fedora
88b42ffd1f7c: Download complete
511136ea3c5a: Download complete
c69cab00d6ef: Download complete
core-fedora-latest
Spawning container core-fedora-latest on /var/lib/toolbox/core-fedora-latest.
Press ^] three times within 1s to kill container.
[root@localhost ~]# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/sda9       38468588 843844  37469948   3% /
devtmpfs          511100      0    511100   0% /dev
tmpfs             511100      0    511100   0% /dev/shm
tmpfs             511100      0    511100   0% /run
tmpfs           38468588 843844  37469948   3% /media
tmpfs           38468588 843844  37469948   3% /tmp
/dev/sda9       38468588 843844  37469948   3% /
tmpfs             511100      0    511100   0% /dev
tmpfs             511100      0    511100   0% /dev/shm
tmpfs             511100      0    511100   0% /run
/dev/sda3        1032088 327248    652412  34% /media/root/usr

上記のように、デフォルトでは Docker の fedora イメージがダウンロードされて展開されたあと、そのファイルシステム( /var/lib/toolbox/core-fedora-latest )を使って systemd-nspawn が起動され、/media/root/ にホストの / がマップされます。

Cluster ready

CoreOS のカーネルはコンパクトであるとはいえ、Cluster を構築するためのツールはしっかり備えています。

etcd がそれで、Cluster 内で情報を共有するための分散 Key-Value データ・ストレージを提供し、前述のコンテナ・クラスタ管理ツール Kubernetes や CoreOS に内蔵されている fleet と呼ばれる分散実行ツールもこれを利用しています。

fleet では、etcd と systemd (Linux の新しい init 管理ツール：unit と呼ばれるファイルを使って定義された情報を元に、スクリプトやアプリの起動を管理する。) を使って、クラスタ単位での unit の実行を管理します。

また、locksmith は、前述の「Update like App」におけるクラスタ内での自動更新時の不用意なリブートを制御し、クラスタとしての機能を維持します。

まとめ

このように、これら4つの特徴／機能が密接に関係しながら CoreOS を形成し、新しい、これからのインフラの姿の一つとして注目を集めています。

さて、これらを踏まえまして、実際に CoreOS を使用していきたいと思います。

02-VirtualBox.md

2. テスト環境の構築

CoreOS を使用する環境の構築方法を記述します。

私は MacBook Air で全ての作業をしているので、Mac OS X が前提となりますが、ここで紹介するツールの殆どは Windows 等でも利用可能だと思います。

CoreOS はいろいろなプラットフォームで利用することが出来るように様々なオブジェクトとそれを利用する為の解説を公開しています。 直接 Bare Metal のハードにインストールすることも出来ますし、EC2、GCE をはじめとした Public Cloud Providers や OpenStack 等の Private Cloud にも対応しています。また、VMware や VirtualBox といった仮想マシン環境上でも利用することが可能になっています。

2.1 VirtualBox

その中でも一番手軽に無料で利用できる方法は VirtualBox でしょう。

公式ではさらに簡単にするために Vagrant という環境構築ツールを利用する方法が紹介されています。 Vagrant 使った簡単な方法については次項で触れますが、ここでは敢えて手間のかかる方法でインストールしていきたいと思います。この方法であれば、その他のプラットフォームでも応用出来るのではないかと思いますし、VirtualBox の紹介には良いサンプルになるとも思います。

この方法のポイントは、

• 汎用的な Linux を利用し、CoreOS のインストーラをダウンロードする。
• その Linux 上で、インストーラを起動し、空のディスクに CoreOS をインストールする。
• その際、初期ユーザのログイン情報を設定する。
• CoreOS がインストールされたディスクを使ってブートする。

です。

若干異なりますが、公式での解説が「Installing to Disk」にあります。

なぜわざわざこんな方法を取るのかと言うと、公式で提供されている CoreOS の ISO は初期ユーザのログイン情報が全く無い状態なので、たとえブートしてもそのままではログインすることが出来ないからです。EC2 等の Cloud System ではブート時に設定する仕掛けが提供されているのですが、VirtualBox には無い為、手動でその部分を補わなければなりません。

では、具体的な手順ですが、

1. VirtualBox をダウンロードして、ローカルマシンにインストールする。
2. Linux 系 OS の ISO イメージをダウンロードする。
3. VirtualBox で新規に仮想マシンを作成する。
4. 仮想マシンに仮想ディスクを追加する。
5. ブート順序を「ハードディスク」「CD/DVD」の順番に変更する。
6. ISO を使ってブートする。
7. CoreOS のインストーラ (coreos-install) をダウンロードする。
8. インストーラが必要とするツールをインストールする。
9. インストーラを使って仮想ディスクに CoreOS をインストールする。
10. 初期ユーザ (core) 用のログイン情報を設定する。
11. リブートさせ、仮想ディスクから CoreOS を起動する。

これで、次回以降、CoreOS が起動するようになります。

では、作業を始めます。

1. VirtualBox をダウンロードして、ローカルマシンにインストールする。

   • https://www.virtualbox.org/wiki/Downloads からローカルマシンの OS にあったバイナリをダウンロードします。
   • バイナリを OS の作法にしたがってインストールします。

2. Linux 系 OS の ISO イメージをダウンロードする。
   この ISO は CoreOS をインストールするためだけのものなので、インストール後は不要です。ですから、なるべく小さくシンプルなものがいいでしょう。
   ここでは、Tiny Core Linux の 64 bit 版を利用したいと思います。
   http://distro.ibiblio.org/tinycorelinux/5.x/x86_64/release/TinyCorePure64-5.3.iso

3. VirtualBox で新規に仮想マシンを作成する。

   • VirtualBox を起動し、左上にある「新規」をクリックします。
   • 上図のように、名前(任意)、タイプ、バージョン、メモリーサイズ(任意)、ハードドライブを設定し、「作成」をクリックします。

4. 仮想マシンに仮想ディスクを追加する。

   • 上図のように、ファイルサイズ(任意)、ファイルタイプを設定し、「作成」をクリックします。
   • すると、仮想マシンのリストに「CoreOS」が「電源オフ」の状態で作成されます。

5. ブート順序を「ハードディスク」「CD/DVD」の順番に変更する。

   • 左上の「設定」をクリックします。
   • 上図のように、「システム」を選択し、「起動順序」の項目で、右隣の矢印アイコンを使って「ハードディスク」を「CD/DVD」よりも上にし、「OK」をクリックします。

6. ISO を使ってブートする。

   • 左上の「起動」をクリックします。
   • ここでブートするための ISO の選択を求められますので、先程ダウンロードしたTinyCorePure64-5.3.isoを選択して、「start」をクリックします。
   • Tiny Core のブートマネージャが起動しますので、「↓」キーを使って「Boot Core (command line only)」を選択し、「Return/Enter」キーを押します。
   • ほんの数秒で起動します。

   tc@box:~$ 
   

7. CoreOS のインストーラ (coreos-install) をダウンロードする。
   ここからの作業はコマンドラインで行います。

   残念ながらコピー・アンド・ペーストが使えない(※これは GuestAddition という VirtualBox のサポート・ユティリティが Tiny Core Linux では利用できないという特殊な事情によるもので、他の Linux では可能です。)手動での作業になるので、Tiny Core Linux専用のスクリプトを用意しました。具体的な内容はスクリプトを参照してください。

   もちろん、このスクリプトをダウンロードし、実行する部分の作業は必要になります。

   • ダウンロードする為のツール curl をインストールします。

   tc@box:~$ tce-load -wi curl
   

   • スクリプトをダウンロードし、実行属性を付与します。(goo.gl を利用して URL を短くしています。)

   tc@box:~$ curl -L http://goo.gl/r2yw8u -o coreos-install.sh
   tc@box:~$ chmod +x coreos-install.sh
   

   • スクリプトを実行します。

   tc@box:~$ ./coreos-install.sh
   =====> Setup utilities to install CoreOS
   curl is already installed!
   ncurses.tcz.dep OK
   .
   .
   .
   =====> Download CoreOS Install Script
   .
   .
   =====> Set Password for the default user(core)
   Password: 
   

   • ここで、初期ユーザ (core) 用のパスワードを入力します。

   Verifying - Password: 
   

   • 再度入力します。

   =====> Install CoreOS
   

   • CoreOS のダウンロードと仮想ディスクへのインストールが始まります。

   Downloading and verifying coreos_production_image.bin.bz2...
   Writing coreos_production_image.bin.bz2 to /dev/sda...
   Success! CoreOS stable current is installed on /dev/sda
   tc@box:~$ 
   

8. リブートさせ、仮想ディスクから CoreOS を起動する。
   最後にリブートさせます。最初のブート順序の設定で「ハードディスク」上にしたので、これで CoreOS をインストールした仮想ディスクからブートされ、CoreOS が起動されます。

   tc@box:~$ sudo reboot
   

9. CoreOS にログインします。
   ブートが完了すると、CoreOS のログイン・プロンプトが表示されますので、ユーザ (core)、パスワードは先程入力したものでログインします。

   localhost login: core
   Password: 
   CoreOS (stable)
   core@localhost ~ $ 
   

これで、CoreOS の環境が作成されました。ただ、これでは、複数のマシンを構築したり、破棄して再構築するのに手間がかかるので、次回は、公式でも使われている Vagrant を使って簡単に一発で環境を作成する方法をご紹介したいと思います。

補足

上記の Tiny Core Linux 専用のスクリプトの中で一番重要な部分は、手順10の「初期ユーザ (core) 用のログイン情報を設定する。」を実行する部分なのですが、ここは cloud-config というコンフィグレーションの仕組みを使ってユーザのパスワードを設定しています。この cloud-config については、「Customization」の項目で詳しく取り上げたいと思っています。

0221-Vagrant.md

2.2 Vagrant

前項では素の VirtualBox を使って CoreOS を仮想マシンにインストールする方法をご紹介しました。

今回は開発環境作成ツール Vagrant を使って簡単に CoreOS の環境を構築してみます。

Vagrant には、様々なプラットフォーム上に開発／テスト環境を構築するための機能と、それを簡単に実現するための仕組みが備わっています。

まず、Vagrant で使われる用語等をご説明します。

• Provider
  Provider は環境を構築する先のターゲットとなるプラットフォームを示し、Vagrant は、標準で VirtualBox、Hyper-V、Docker に対応しています。
  また、プラグインの機能があり、サードパーティ製の Provider を追加することが出来るようになっています。それらには、AWS や Parallels、VMware(有料) 等があります。
  Vagrant ではこれらの Provider に対して、ローカルマシンのコマンドラインから開発環境の管理を実行していくことになります。
  なお、Vagrant は一度に一つの Provider の操作しか出来ません。

• Vagrantfile
  Vagrant では Vagrantfile と名付けられた定義ファイルを元に、Provider のリソースを管理します。ファイル名は Vagrantfile に固定されているので、複数の Vagrantfile を利用するには別々のディレクトリに保存する必要があります。
  ファイルの書式は Ruby 言語になっています(Vagrant 自身も Ruby 言語で書かれています)が、プログラムを書く程のものではなく、簡単な記述のみで定義することが出来るようになっています。(もちらん、Ruby 言語をご存知の方は高度な記述も可能です。)
  一つの Vagrantfile で複数マシン構成の開発環境を作成・管理することも出来ます。

• Box
  Vagrant は、Provider 上に開発環境を作成する際に、そのベースとなる OS やハードディスクを予めまとめた Box と呼ばれるパッケージを元に実行します。Box の指定は Vagrantfile によって行います。
  Box には OS をインストールする為の ISO イメージを含めることも出来ますし、予め OS やツール類をインストールしたハードディスクを含めることも出来ます。 さらに、Vagrant で作成した開発環境を別の Box としてパッケージングすることも出来ます。

• Provisioning / Provisioner
  Vagrant は、ターゲットとなる Provider を指定し Box をベースに作成された開発環境に対して、Provisioning と呼ばれる、開発／テストに必要となる設定やツールをインストールする仕組みも提供します。
  Provisioning するための方法 (Provisioner) には、ファイルをコピーする簡単なものからシェルの実行、Chef、Puppet や Ansible のような構成管理ツールを利用するものまで標準で用意されています。
  CoreOS で使用する可能性の高いものを以下に上げます。

  • File
    ローカルマシンから仮想マシンにファイルを転送します。

  • Shell
    シェル・スクリプトを仮想マシン上で実行します。

  • Docker
    CoreOS は標準で Docker がインストールされていますので、Docker を使ってコンテナを作成することも出来ます。

• vagrant コマンド
  Vagrant のインストーラを公式サイトからダウンロードし、ローカルマシンで実行すると、vagrant というコマンドがインストールされます。インストーラには Mac OS X 用、Windows 用、Linux 用がそれぞれ用意されていますので、各自の環境に合ったものをダウンロード／インストールして下さい。

  

  Vagrant では、この vagrant コマンドをコマンドラインから実行することで開発環境の管理を行います。

  主なコマンドをご紹介します。

  • vagrant init
    カレント・ディレクトリに Vagrantfile の雛形を生成します。
  • vagrant up
    Provider を指定し、Vagrantfile の定義に従って、開発環境を新規に作成します。
  • vagrant status
    開発環境の状態を表示します。
  • vagrant ssh
    開発環境内のマシンに SSH を使ってログインします。
  • vagrant suspend
    開発環境の状態を保存します。
  • vagrant resume
    保存された開発環境を復帰させます。
  • vagrant reload
    開発環境のリブートを実行します。
  • vagrant provision
    Vagrantfile の定義に従って Provisioning を実行します。
  • vagrant halt
    開発環境を停止させます。
  • vagrant destroy
    開発環境を Provider から破棄します。
  • vagrant box
    Box の管理をします。
  • vagrant package
    開発環境を Box にパッケージングします。

  なお、それぞれのコマンドの後ろに -h オプションを付けるとサブコマンドの一覧やコマンド・オプションのヘルプを表示させることが出来ます。

• Vagrant Cloud
  Vagrant v1.5 からは、Vagrant Cloud という個人や企業が作成した Box を公開／共有する場所も提供されるようになりました。 また、Vagrant Cloud と連携し、コマンドラインから直接 Box をダウンロードしたりアップデートすることも可能になりました。

CoreOS with Vagrant

それでは、実際に Vagrant を使って CoreOS をベースにした開発環境を作成していきましょう。

まず、先程紹介した Vagrant 公式サイトのダウンロードページからインストーラをダウンロードして vagrant をインストールしましょう。(VirtualBox は前項でインストール済みのものとします。)

作業ディレクトリの作成

適当な作業用ディレクトリを作成し、vagrant を実行してみます。

$ mkdir demo
$ cd demo
$ vagrant --version
Vagrant 1.6.3

現時点での最新バージョンは 1.6.3 です。

CoreOS では公式で CoreOS 用の Box とそれを利用する為の Vagrantfile を公開しているのですが、Vagrant 初心者が簡単に利用するには煩雑になり過ぎているので、私自身がパッケージして Vagrant Cloud に公開したもの を利用してご説明したいと思います。

Vagrantfile の雛形生成

$ vagrant init yungsang/coreos -m
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

yungsang/coreos の / の前は Vagrant Cloud でのアカウント名を、後は当該アカウント内の Box 名を示し、それらを組み合わせることによって、Vagrant Cloud 内の Box を特定することが可能になっています。
最後の -m オプションはデフォルトで Vagratfile に書き出される雛形の冗長なコメントを抑制する為のものです。ここでは説明用に出力をシンプルにする為に使用していますが、オプションを外して実行しても機能は変わりません。

このコマンドで以下の Vagrantfile がカレント・ディレクトリに生成されているはずです。

$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "yungsang/coreos"
end

上記のように、Ruby 言語の書式の定義が出力されます。

• VAGRANTFILE_API_VERSION は Vagrantfile の書式のバージョンを示しており、現在は 2 に固定です。

• Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| ... end 内が実際の定義で、この中に開発環境の定義を記述していきます。

• config.vm.box にこの開発環境で使用する Box を指定します。
  ここでは、先程 vagrant init で指定した値 yungsang/coreos が代入されています。
  vagrant init は単純に雛形を生成するだけなので、訂正や変更が必要な場合はエディタを使って変更することが可能です。
  ただし、開発環境の作成後に変更すると誤動作しますので、Box を変更する場合は、まず vagrant destroy を実行して現在の環境を破棄して下さい。

構築の実行

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'yungsang/coreos'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'yungsang/coreos' is up to date...
==> default: Setting the name of the VM: demo_default_1408585788816_41075
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: core
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!

上記コマンドで、開発環境の構築が実行されます。デフォルト Provider として VirtualBox が設定されており、VirtualBox 内に CoreOS の仮想マシンが構築されます。

VirtualBox のマネージャを起動すると、一覧に demo_default_9999999999999_99999 と名前が付いた仮想マシンが追加されていると思います。 この demo は当開発環境の Vagrantfile のあるディレクトリを示し、default は開発環境の名前(デフォルトでは default)になります。
開発環境の名前はこのままでも機能的には問題無いのですが、コマンドラインでの指定や識別に必要になるケースが出てきますので、指定方法については別途ご説明します。
最後の数字は一意にするための数列です。

デフォルト Provider の設定方法、実行時の Provider の指定方法については別途ご説明します。

稼働状況の確認

$ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

vagrant status を使って状況を確認すると、上記のようになります。 default という名前の仮想マシンが VirtualBox で稼働中 running となっています。

CoreOS へのログイン

それでは稼働中のマシンにログインしてみましょう。

$ vagrant ssh
   ______                ____  _____
  / ____/___  ________  / __ \/ ___/
 / /   / __ \/ ___/ _ \/ / / /\__ \
/ /___/ /_/ / /  /  __/ /_/ /___/ /
\____/\____/_/   \___/\____//____/
(stable 367.1.0)
core@localhost ~ $

なお、vagrant ssh-config を使用すると、SSH の為の情報を得ることが出来ます。

$ vagrant ssh-config
Host default
  HostName 127.0.0.1
  User core
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile ~/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

この情報から、127.0.0.1 (localhost) のポート 2222 がリモートの SSH ポートにフォワードされていて、ユーザ名 core で、 RSA のプライベート・キー・ファイルとして ~/.vagrant.d/insecure_private_key を使用してログインしていることが分かります。
つまり以下と等価です。

$ ssh -p 2222 -i ~/.vagrant.d/insecure_private_key core@127.0.0.1
   ______                ____  _____
  / ____/___  ________  / __ \/ ___/
 / /   / __ \/ ___/ _ \/ / / /\__ \
/ /___/ /_/ / /  /  __/ /_/ /___/ /
\____/\____/_/   \___/\____//____/
(stable 367.1.0)
core@localhost ~ $

まとめ

このように、Vagrant を利用することによって、前回の素の VirtualBox を使用した CoreOS のインストールとログインまでの作業が、以下のようなコマンドラインのみで可能になりました。

$ mkdir demo
$ cd demo
$ vagrant init yungsang/coreos -m
$ vagrant up
$ vagrant ssh

91-Appendix-1.md

Appendix 1. Code Layout

何か気になるプログラム／ソフトウェアに出会うと、特に、気になる動作をしていた場合、そのソース・コードを読んでみたくなるのですが、最近はオープンソースで開発されていてコードが公開されているものが多いので大変助かりますw

私の場合、このコード・リーディングが特に好きで、と言うか、独学での先生は素晴らしい沢山のコードたちでした。最初の頃は先行投資と銘打ってプログラム本を買い漁っていましたが、最近は、この手の本はすぐに内容が古くなってしまうことが多く、ネットにも情報が溢れているので、書籍を買うことは少なくなってしまいました。

コード・リーディングは、C言語でのプログラムに慣れてきたばかりの時に参加したプロジェクトで --- NetWare for Unix を移植するものだったのですが --- その膨大なコードと格闘した時に鍛えられたような気がします。 ネットワーク OS ということで、デバイス・ドライバからプロトコル・スタック、サーバ・アプリケーションまで、文字通りフルスタックのコードを全く動かない状態から読み込んで、単純に移植するだけじゃなく、そこに元々存在していたバグもデバッグする必要がありました。おかげで、大量のコードを見ても怯まないようになりましたw

こんな感じで今でも結構コードを読むことから始まったりすることが多いです。これは Web でも同じで、新しい SNS に参加したらまず JavaScript を読み、API のパケットを見たり、機能を補完するためのツールを作ったりしています。 jQuery もまだ JSONP の機能も内蔵されてなかった初期のころですがパッチを当てたりしていましたし、Tombloo や Taberareloo のコードも大変勉強になりました。Google の難読化されたコードはもうあまり見たくないですがw

さて、肝心の CoreOS のコードですが、

レポジトリのレイアウトが他と変わっていて一箇所ではなく、各コンポーネント毎に別々のレポジトリになっていて、ビルド時に、それらのコミット・ハッシュをキーにして、一つのレポジトリに集められるようになっているようで、最初は取っ付き難かったです。

このレイアウトと作法はどこから来るのか？正確には調べてないのですが、CoreOS の派生元である Chrome OS の、さらにベースとなっている Gentoo から来ていると思われます。たぶん、Gentoo をご存知の方は当然のレイアウトなのでしょうね。

• Modifying CoreOS
  https://coreos.com/docs/sdk-distributors/sdk/modifying-coreos/#making-changes
• CoreOS 入門 - Qiita
  http://qiita.com/mopemope/items/fa9424b094aae3eac580#2-4
• Google Chrome OS - Wikipedia
  http://ja.wikipedia.org/wiki/Google_Chrome_OS
• Portage - Wikipedia
  http://ja.wikipedia.org/wiki/Portage

それでは、実際に私がチェックしている主なレポジトリをご紹介したいと思います。

• coreos/coreos-overlay
  https://github.com/coreos/coreos-overlay

  最終的に全てのコンポーネントのコミット情報が集まってくるレポジトリ。 CoreOS の中ではここのみ (GitHub で言うところの) Watch をしています。ここをチェックしていると次にリリースされるものには何が追加／変更になるのかが大体わかります。

  それ以外は、全てを Watch していると大変なことになるので、各レポジトリの master ブランチのコミット RSS を RSS リーダーでチェックするようにしています。

  この中でも、
  https://github.com/coreos/coreos-overlay/tree/master/coreos-base
  がコアになっていて、各プラットフォーム用にカスタマイズするためのコードもここにあります。
  例えば、GCE 用であれば
  https://github.com/coreos/coreos-overlay/tree/master/coreos-base/oem-gce/files
  Vagrant 用であれば
  https://github.com/coreos/coreos-overlay/tree/master/coreos-base/oem-vagrant/files
  という感じです。

• coreos/init
  https://github.com/coreos/init

  ここに CoreOS 起動時のスクリプト、及び systemd の unit ファイルがあります。CoreOS 全体に関わるカスタマイズはここに対して行います。

• coreos/coreos-cloudinit
  https://github.com/coreos/coreos-cloudinit

  CoreOS 用 cloud-config の実装がここにあります。CoreOS を SDK を使ってビルドし直さない限り、ユーザ・レベルではこの cloud-config を使ったカスタマイズ／設定がメインになりますので、ここのドキュメントは目を通しておいた方が良いと思います。

以下、「CoreOS の概要」の中でご紹介した CoreOS に内蔵されているツール郡もそれぞれレポジトリを持っています。

• coreos/etcd
  https://github.com/coreos/etcd

  Go言語で書かれていて、サーバである etcd だけでなく、それをコントロールするための etcdctl もここからバイナリをダウンロード出来るようになっています。CoreOS で使われる Linux 用だけでなく、Mac OS X 用や Windows 用のバイナリも配布されており、etcdctl を使えばローカルマシンでリモートからクラスタの情報にアクセス出来るようになります。

• coreos/etcdctl
  https://github.com/coreos/etcdctl

• coreos/fleet
  https://github.com/coreos/fleet

  etcd と同じように Go言語で書かれていて、サーバ本体である fleet とともに、それをコントロールする fleetctl もここで配布されています。Linux 用と Mac OS X 用があり(なぜか Windows 版は無い)、ローカルマシンにインストールすればリモートからクラスタをコントロールすることが可能になります。

• coreos/update_engine
  https://github.com/coreos/update_engine

  CoreOS の更新をチェックするクライアント・デーモンで、C++言語で書かれています。また、このデーモンに関する unit ファイルも格納されいます。

• coreos/locksmith
  https://github.com/coreos/locksmith

  上記 update_engine が更新を実行した際にクラスタ内のマシンのリブートを制御する為のツール。Go言語で書かれています。

• coreos/toolbox
  https://github.com/coreos/toolbox

  「CoreOS の概要」の「Docker centric 」でご紹介したデバッグ用ツール。ベースとなるファイルシステムをダウンロードし systemd-nspawn を起動する為のシェル・スクリプトになっています。

92-Appendix-2.md

Appendix 2. Release Channels

CoreOS にはリリース用チャンネルが３つがあります。

• CoreOS Release Notes
  https://coreos.com/releases/

さらにもう一つ、開発／テスト用チャンネルである Master (Developer) を含め、Master → Alpha → Beta → Stable の順にリリースされます。

2014年７月25日には、初めての安定版である Stable 367.1.0 がリリースされました。通常で言う v1.0 です。

ただし、CoreOS の根幹である OS の部分は Stable になりましたが、下記に書かれているように、クラスタを構成する etcd や fleet 等のツール群はまだ安定版がリリースされてないので注意が必要です。

• CoreOS Stable Release
  https://coreos.com/blog/stable-release/

Please note: The stable release is not including etcd and fleet as stable, this release is only targeted at the base OS and Docker 1.0. etcd/fleet stable support will be in subsequent releases.

主なコンポーネントのバージョンは CoreOS Release Notes で確認することが出来ます。

なお、CoreOS のバージョン番号の振り方はちょっと変わっていて、メジャー・バージョン番号は CoreOS の開発がスタートした 2013年７月１日からの日数になっています。

• The CoreOS Epoch
  https://coreos.com/blog/coreos-epoch/

CoreOS has a rapidly incrementing version, 197.0.0, 247.0.0, and so on. It is a little known fact, but the version represents the number of days since the CoreOS epoch on July 1, 2013.

ただし、基本的に X.0.0 は最初にビルドされた日付を指していて、最初にビルドされるのは Master チャンネルなので、実際にリリースされる日とは異なることになります。 現在の Stable バージョン 367.1.0 で言えば、最初に Master として 367.0.0 がビルドされたのは 2014年７月２日、その後、３日に Alpha、13日に Alpha 367.1.0 になり、16日に Beta、25日に Stable という流れになっていました。

さて、それぞれのチャンネルについてですが、

Master(Developer) Channel

ほぼ毎日更新されているチャンネルで、１日に複数回更新されることもあります。これは単純に最新のコードを追うためのデバッグ用ビルドの位置付けでしょう。

「Appendix 1. Code Layout」のところでご紹介しましたレポジトリ、

• coreos/coreos-overlay
  https://github.com/coreos/coreos-overlay

の最新コミットから数時間後にビルドされている場合が多いです。

http://storage.core-os.net/coreos/amd64-usr/master/

に最新のビルドが置かれています。

現在は coreos-install の対象にはなっていません。
Master をインストールしたい場合は、

https://github.com/YungSang/coreos-packer/blob/master/oem/coreos-install.dev

に、 -C master を指定しても動作するものを置いています。

Alpha Channel

Master の中でテストされたものが Alpha になりますが、直接 Master と Alpha が同時にリリースされることもあります。ここでバグが発見されると、マイナー・バージョンアップされることもあります。

最新のコードに近いので、機能、コンポーネントも最新で、特に Docker の最新版を使いたい場合はこのチャンネルを選ぶことになります。 現在で言えば、Stable 367.1.0 の Docker は v1.0.1 ですが、Alpha 402.2.0 では現行の v1.1.2 になっています。

• CoreOS is Linux for Massive Server Deployments
  https://coreos.com/

のトップページに表示されている Latest Release Info はこのチャンネルのものとなっていますので、CoreOS はこの Alpha チャンネル押しなのかも知れません。

http://alpha.release.core-os.net/amd64-usr/current/

に最新のビルドが置かれています。

Beta Channel

Alpha チャンネルでテストされたもので、Stable へのリリース候補が Beta になります。ですので、Beta には大きな動きは無く、Stable を運用中のシステムに対しての次期リリースの評価テスト用としての存在となるでしょう。

ちなみに、最初の Beta は 2014年５月９日にリリースされ(310.1.0)、324.3.0、324.5.0、353.0.0 を経て、367.1.0 が７月16日リリースされ、その後 Stable になっています。

http://beta.release.core-os.net/amd64-usr/current/

に最新のビルドが置かれています。

Stable Channel

安定リリース版です。Beta の中からさらに安定しているものが Stable に移行します。

http://stable.release.core-os.net/amd64-usr/current/

に最新のビルドが置かれています。

「CoreOS の概要」のところでご紹介したように、CoreOS はカーネルとシステム系を、主要コンポーネントを含めて、ユーザが更新出来ない仕組みになっていますので、安定しているとは言え、リリース・サイクルによっては古いままの運用が長く続き、ちょっと微妙な気もします。 ただ、あまり頻繁にリリースされても、その度に自動的に更新されてしまうので、安定的に運用出来ないのはそれはそれで困りものですね。
常に Beta をチェックして、いつ自動更新されてもいいように準備していなければなりません。

この辺は Chrome Browser とその拡張機能の関係と同じで、いつの間にか Chrome が更新されて拡張機能が動かなくなったとか良く耳にするので、今後どのような運用がベストなのか注意する必要があると思います。

Channel Switching

最後に、実際にはあまり使われないとは思いますが、運用中のリリース・チャンネルを次回自動更新時に切り替える方法をご紹介したいと思います。

• Switching Release Channels
  https://coreos.com/docs/cluster-management/setup/switching-channels/

core@localhost ~ $ cat /etc/coreos/update.conf
GROUP=stable

この GROUP の値を変更することによって、自動更新する対象のチャンネルを変更することが出来ます。ただし、チャンネルを上位に変更してもダウングレードすることは無く、変更後のチャンネルで運用中のバージョンより新しい、最新のものに更新されます。
(※なお、Master Channel の GROUP は developer となります。)

ちなみに、運用中のチャンネルの確認は上記で行いますが、運用中のバージョンの確認は、

core@localhost ~ $ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=367.1.0
VERSION_ID=367.1.0
BUILD_ID=
PRETTY_NAME="CoreOS 367.1.0"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

で行います。

Packer と boot2docker は余計かも知れん。

こちら読ませて頂きました！
知らないことも多々あり、大変勉強になりました、ありがとうございます 👍