Skip to content

Instantly share code, notes, and snippets.

@wnoguchi
Forked from YungSang/00-README.md
Last active August 29, 2015 14:09
Show Gist options
  • Save wnoguchi/5766ec0f1e2a16187bae to your computer and use it in GitHub Desktop.
Save wnoguchi/5766ec0f1e2a16187bae to your computer and use it in GitHub Desktop.

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
    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

1. CoreOS の抂芁

ずか、かなりいいリ゜ヌスがあるので、そちらを参照しお頂ければ 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 を䜿甚しおいきたいず思いたす。

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」の項目で詳しく取り䞊げたいず思っおいたす。

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

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 をご存知の方は圓然のレむアりトなのでしょうね。

それでは、実際に私がチェックしおいる䞻なレポゞトリをご玹介したいず思いたす。

  • 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 を起動する為のシェル・スクリプトになっおいたす。

Appendix 2. Release Channels

CoreOS にはリリヌス甚チャンネルが぀がありたす。

さらにもう䞀぀、開発テスト甚チャンネルである Master (Developer) を含め、Master → Alpha → Beta → Stable の順にリリヌスされたす。

2014幎月25日には、初めおの安定版である Stable 367.1.0 がリリヌスされたした。通垞で蚀う v1.0 です。

ただし、CoreOS の根幹である OS の郚分は Stable になりたしたが、䞋蚘に曞かれおいるように、クラスタを構成する etcd や fleet 等のツヌル矀はただ安定版がリリヌスされおないので泚意が必芁です。

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幎月日からの日数になっおいたす。

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」のずころでご玹介したしたレポゞトリ、

の最新コミットから数時間埌にビルドされおいる堎合が倚いです。

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 になっおいたす。

のトップペヌゞに衚瀺されおいる 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

最埌に、実際にはあたり䜿われないずは思いたすが、運甚䞭のリリヌス・チャンネルを次回自動曎新時に切り替える方法をご玹介したいず思いたす。

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"

で行いたす。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment