コンテナホスト向けOS環境「CentOS Atomic Host」や「Snappy Ubuntu Core」を試す
コンテナの普及に伴い、アプリケーションはすべてコンテナ内で稼動させるという構成を採用する例も珍しくなくなってきたが、こういった構成を取る際に検討が必要なのが、どのOSをコンテナのホストとして利用するかという点だ。そこで今回は、このような運用スタイルに向けたOS環境である「CentOS Atomic Host」と「Snappy Ubuntu Core」を紹介する。
Red HatやUbuntuがリリースする特化型OS
近年普及が進んでいるDockerでは、基本的にすべてのアプリケーションはコンテナ上で動作させることになる。この場合、Dockerホスト上にはDockerを実行させるための必要最小限のソフトウェアのみが含まれていれば良い。こういったDockerホストに特化したOSが最近注目されている。
コンテナの稼動に特化したOSとしてよく知られているのが以前にも紹介した「CoreOS」だが、昨今ではこれ以外にも似たようなコンセプトのOSが登場している。今回はそのうち、CentOSベースの「CentOS Atomic Host」（図1）と、Ubuntuをベースとした「Snappy Ubuntu Core」（図2）について紹介する。
コンテナに特化したOSを利用する利点
コンテナを使ってアプリケーションを実行させる場合、アプリケーションの実行に必要となるライブラリや関連コンポーネントなどはすべてコンテナ内に配置しておくのが一般的だ。そのため、コンテナを仮想させるホスト上では、コンテナ管理ソフトウェア（一般的にはDocker）を実行させるのに必要なソフトウェアのみがあれば良い。しかし、一般的なLinuxディストリビューションではコンテナ管理ソフトウェアの実行に不要なソフトウェアまでもインストールされてしまう。コンテナに特化したOSでは、このような不要なソフトウェアがインストールされず、必要最小限のソフトウェアのみを含む環境を容易に構築できるのが特徴となる。
また、こういったOSでは管理者であってもルートファイルシステムや/usr/ディレクトリ以下にアクセスできないなど、ファイルシステムへのアクセスに制限があることが多い。そのため、もしアプリケーションに脆弱性があり、任意のファイル/ディレクトリへのアクセスが可能な特権を奪取された場合でも被害を抑えられるというメリットがある。
いっぽうで、こういったOS上でアプリケーションを実行させる際にはコンテナの利用が必須となり、直接アプリケーションを実行させることができない点から開発環境としてはやや使いにくいというデメリットも存在する。開発環境には一般的なOSを使用し、運用環境としてコンテナに特化したOSを利用する、といった切り分けが必要になるだろう。
CentOS Atomic Hostを使う
CentOS Atomic Hostは、Red Hat傘下のProject Atomicによって進められている、Dockerコンテナの実行に特化したOS環境だ。同プロジェクトの成果物は「Red Hat Enterprise Linux 7 Atomic Host」という製品としてリリースされているほか、無償で利用できる「Fedora Atomic Host」や「CentOS Atomic Host」という形でも提供されている。Ret Hat Enterprise Linux（RHEL）とFedora、CentOSの関係と同様、Fedora Atomic Hostは実験的、CentOS Atomic HostはRHEL Atomic Hostとの互換性を保つという位置付けになっている。
今回はCentOS Atomic Hostについて紹介するが、各OSとも基本的な操作法や管理方法は同じだ。ただし、搭載されるソフトウェアのバージョンや機能、利用できるリポジトリなどが異なっている点には注意したい。
ISOイメージからのインストール
CentOS Atomic Hostは仮想化ソフトウェア向けのイメージファイルおよびインストーラを含むISOイメージの形で配布されている。イメージファイルはQEMUで利用されるqcow2形式やLibvirt/KVM向け、VirtualBox向け、Amazon AMI形式のものが提供されている。これらのイメージが利用できない場合はISOイメージファイルからのインストールを行うことになる。
ISOイメージファイルからのインストール作業はCentOSの場合とほぼ同様で、ISOイメージからシステムを起動するとインストーラ（Anaconda）が実行される（図3）。最低限必要なのはインストール先ストレージやネットワークの設定、そしてrootアカウントの作成のみだ。また、さくらのクラウドなどDHCPによるIPアドレスが割り当てが行えない環境の場合は静的なIPアドレス割り当てが必要となるので、あらかじめ割り当てるIPアドレスやデフォルトゲートウェイなどの情報を確認しておこう。
Atomic Hostのディレクトリ/ファイル構成
Atomic Hostでは一般的なLinuxディストリビューションとは異なり、/usr/ディレクトリがリードオンリーでマウントされている。また、/home/や/mnt、/opt、/root、/srvといったディレクトリは/var/ディレクトリ以下の別ディレクトリ（/var/home/や/var/mnt/、/var/opt/、/var/roothome、/var/srv）へのシンボリックリンクとなっている。通常書き込みが行えるのは/var/および/etc/ディレクトリ以下のみで、管理者であってもルートディレクトリ（/）や/usr/ディレクトリ以下への書き込みは行えず、yumコマンドやrpmコマンドによるパッケージのインストールも行えない。OSのアップデートにはその代わりとして後述する「rpm-ostree」というコマンドを利用するようになっている。
Atomic HostでのDockerの利用設定
Atomic Hostでは標準でDockerやetcd、Kubernetes、Flannelといった、コンテナを利用したクラスタ環境を構築するためのソフトウェアが含まれている。これらの設定・利用法については以前「kubernetesによるDockerコンテナ管理入門」という記事で紹介した流れとほぼ同じなので、今回は割愛する。
また、ISOイメージからAtomic Hostをインストールした場合、デフォルト設定ではLVMを使って複数の論理ボリュームが作成されるようになっており、そのうち「cah-docker--pool」という論理ボリュームをDockerが使用するよう自動的に設定される。この設定は、次のように「docker info」コマンドで確認できる。
# docker info Containers: 0 Images: 0 Storage Driver: devicemapper Pool Name: cah-docker--pool Pool Blocksize: 524.3 kB Backing Filesystem: xfs Data file: Metadata file: Data Space Used: 62.39 MB Data Space Total: 6.304 GB Data Space Available: 6.242 GB Metadata Space Used: 40.96 kB Metadata Space Total: 25.17 MB Metadata Space Available: 25.12 MB Udev Sync Supported: true Deferred Removal Enabled: false Library Version: 1.02.93-RHEL7 (2015-01-28) Execution Driver: native-0.2 Logging Driver: json-file Kernel Version: 3.10.0-229.20.1.el7.x86_64 Operating System: CentOS Linux 7 (Core) CPUs: 1 Total Memory: 993.4 MiB Name: atomic7 ID: I3CQ:FJ7R:JWXF:XEL6:BP4W:SV4K:GUJG:PCVH:CMIW:67YL:FNVJ:5ZZG
ISOイメージからのインストールを行っていない場合や手動でパーティション設定を行った場合などは、この設定をユーザー側で行っておく必要がある。具体的な手順としては、まず/etc/sysconfig/docker-storage-setup」ファイルに「DEVS="＜使用するパーティションに対応するデバイスファイル＞"」のようにして使用するパーティションを記述する。たとえば「/dev/vdb」を使用する場合、以下のように記述することになる。
DEVS="/dev/vdb"
続いて「docker-storage-setup」コマンドを実行すると、この設定ファイルに記述された設定に従ってDockerの設定が行われる。設定後は「docker info」コマンドを実行して設定が正しく反映されているかを確認しておこう。
OSのアップデート
一般的なLinuxディストリビューションでは付属するパッケージマネージャ経由でカーネルや各種コンポーネントを個別にアップデートするのが一般的だが、Atomic HostではOSの全コンポーネントが含まれたイメージファイルをダウンロードし、それをローカルのファイルシステムに適用することでアップデートを行う仕組みになっている。この処理を行うのがrpm-ostreeコマンドだ。
rpm-ostreeコマンドは、OSTreeというファイルシステム管理ツールを利用してAtoic Hostの環境を管理する仕組みとなっている。OSTreeは「OSバイナリ向けのgit」を標榜して開発が進められているもので、ファイルシステムの世代管理や切り替え、マージといった機能を提供している。これを利用することでAtomic HostではOS全体の容易なアップデートを実現している。
まず、OSのアップデートを行うには以下のように「upgrade」サブコマンドを付けてrpm-ostreeコマンドを実行する。
# rpm-ostree upgrade
rpm-ostreeコマンドが実行されると、/etc/ostree/remotes.d/ディレクトリ内にある設定ファイルに記述されているアップデートの配布先（CentOS Atomic Hostの場合、デフォルトではmirror.centos.org）で公開されているイメージファイルのバージョンを確認し、現在のバージョンよりも新しいものがあれば自動的に/ostree/ディレクトリ以下にダウンロードおよび展開され、続いてファイルシステム上のディレクトリの置き換えが行われる。インストールの完了後、「systemctl reboot」コマンドを実行して再起動を行えばアップデートが反映されるようになる。
また、アップデート後に不具合が発生した場合、「rollback」サブコマンドを利用することで簡単にロールバックを行える。
なお、現在のバージョンについては「status」サブコマンド付きでrpm-ostreeコマンドを実行することで確認できる。
# rpm-ostree status TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC * 2015-11-18 10:59:15 7.20151118 4916c22d5c centos-atomic-host centos-atomic-host:centos-atomic-host/7/x86_64/standard GPG: Found 1 signature on the booted deployment (*): Signature made Wed Nov 18 20:05:05 2015 using RSA key ID F17E745691BA8335 Good signature from "CentOS Atomic SIG <[email protected]>"
ちなみにOSTreeではより詳細なファイルシステムのバージョン管理が可能だが、Atomic Hostを利用する一般的なケースでは直接それを利用する必要はない。OSTreeについて詳しく知りたい方は、OSTreeのWebサイトなどを参照して欲しい。
atomicコマンドによるコンテナの管理
Atomic Hostのもう1つの特徴が、「atomic」コマンドだ。atomicコマンドは2つの役割があり、まず1つはAtomic Hostのシステム全体の管理だ。たとえばrpm-ostreeコマンドの代わりに「atomic host upgrade」コマンドでOSのアップデートを実行したり、「atomic host rollback」コマンドでロールバックを行うことが可能だ。ただし、現時点ではrpm-ostreeコマンドの単なるフロントエンドとしての役割しかないため、積極的に利用する意味はあまりない。
もう1つの役割は、およびホスト上で稼動するコンテナの管理だ。たとえば「docker run」コマンドの代わりに「atomic run」コマンドでコンテナを実行したり、「docker images」コマンドの代わりに「atomic images」コマンドでコンテナイメージ一覧を表示することもできる。ただし、dockerコマンドを置き換えるものではなく、dockerコマンドで指定できるオプションがatomicコマンドでは利用できないといったケースもある。そのため、通常はdockerコマンドと併用することになるだろう。
atomicコマンドが持つ独自の機能としては、「Nulecule」と呼ばれる規格に沿って作成されたイメージファイルのサポートがある。Nuleculeでは、Dockerfileの「LABEL」コマンドを使ってDockerfile内にメタデータを埋め込み、コンテナのインストール時や実行時、アンインストール時などに特定の処理を実行させられるようになっている。詳しくはNuleculeのドキュメントなどを参照してほしいが、たとえばDockerfileで「RUN」というラベルが指定されていれば、「atomic run」コマンドの実行時にそこで指定されたコマンドが実行される。そのほか参照されるラベルとしては「atomic install」コマンドの実行時に実行される「INSTALL」や「atomic uninstall」コマンドの実行時に実行される「UNINSTALL」などがある。また、「Vendor」や「Version」といったラベルでその配布者やバージョンといった情報を埋め込むこともできる。
Nuleculeに対応しているコンテナはまだ多くないが、その1つに「CentOS Tools」がある。これは各種管理機能や診断ツールが含まれているコンテナだ。Atomic Hostではホスト上に必要最低限のソフトウェアしかインストールされていないため、アプリケーションのデバッグやOSの状態の診断を行うためのツールもそのままでは利用できないが、このコンテナを利用することで各種デバッグツールや診断ツールをホスト上で実行できるようになる。コンテナは通常そのホストの環境にはアクセスできないが、CentOS Toolsではスーパー特権コンテナ（SPC）という技術を利用することでコンテナではなくホスト自体を対象に管理ツールや診断ツールを実行できるようになっている。
このコンテナは、次のように「atomic install」コマンドを実行することでインストールできる。
# atomic install centos/tools Using default tag: latest Trying to pull repository docker.io/centos/tools ... latest: Pulling from centos/tools 47d44cb6f252: Pull complete 838c1c5c4f83: Pull complete 5764f0a31317: Pull complete 60e65a8e4030: Pull complete e968914fe097: Pull complete ec608b4847e0: Pull complete c90278e57745: Pull complete 2a04136a9dfd: Pull complete e1bfecacf3de: Pull complete 41b47b260ffc: Pull complete 15d8f7e8bce6: Pull complete Digest: sha256:e8b354eff013b648a7e6cc7a97069708f46400239e2719280d8b814dce91855c Status: Downloaded newer image for docker.io/centos/tools:latest /usr/bin/docker run -t -i --rm --privileged -v /:/host --net=host --ipc=host --pid=host -e HOST=/host -e NAME=tools -e IMAGE=centos/tools -e CONFDIR=/host/etc/tools -e LOGDIR=/host/var/log/tools -e DATADIR=/host/var/lib/tools --name tools centos/tools [root@atomic7 /]#
インストールが完了すると自動的にコンテナが実行され、コンテナ内のシェルが起動した状態となる。ここでexitもしくはCtrl-Dを入力するとコンテナが終了し、Atomic Host環境に戻ることができる。
Atomic Host環境から再度コンテナを実行するには、「atomic run」コマンドを実行する。
# atomic run centos/tools
なお、コンテナに付加されているラベルの情報は「atomic info」コマンドで確認できる。
# atomic info centos/tools vendor: CentOS build-date: 2015-12-23 RUN: docker run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/localtime:/etc/localtime -v /:/host IMAGE name: CentOS Base Image license: GPLv2
ここで表示されるように、このコンテナでは「RUN」というラベルが指定されており、ここで「--privileged」などのオプションを指定することでコンテナに特権を与えるようになっている。
CentOS Toolsイメージは上記のようなラベルが設定されている以外は通常のDocker用イメージと変わらない。そのため、「docker run」コマンドを使って直接実行することも可能だ。ただしその場合、手動で先の「--privileged」オプションなどを指定する必要がある。
ちなみにRed Hat Enterprise Linux Atomic HostやFedora Atomic Hostでも「Red Hat Enterprise Linux Atomic Tools Container」や「fedora-tools」といった名称で同様のコンテナが提供されている。
Snappy Ubuntu Coreを使う
続いて紹介するSnappy Ubuntu Core（以下、Snappy）は、Ubuntuをベースとしたディストリビューションだ。ただし、SnappyはCoreOSやAtomic Hostとは異なり、コンテナの実行に特化しているわけではない。公式サイトなどではクラウド環境での利用もアピールされているものの、組み込み機器などに向けたOS環境という側面も強く、Raspberry PiやBeagleboneといったARM CPU搭載の小型PC向けイメージも公開されている。
Snappyの大きな特徴として、「Snap」と呼ばれるパッケージ単位でソフトウェアを管理する点がある。通常のUbuntuと異なり、Snappyではapt-getコマンドによるソフトウェアのインストールは行えない。apt-getコマンドの代わりとなるのが、システム管理ツールである「snappy」コマンドだ。snappyコマンドではパッケージのインストールだけでなく各パッケージの設定やサービスの起動/停止、ハードウェアの設定、各種診断といった機能も備えており、OS環境の管理作業は基本的にこのsnappyコマンドを通じて行う形となっている。
また、サンドボックス機構を備えている点も特徴だ。SnappyではWebサーバーや各種Webサービスといったアプリケーションパッケージが提供されているが、これらはサービス毎に独立した環境で実行される仕組みになっている。各アプリケーションは依存するバイナリファイルをすべてパッケージ内に含んでおり、パッケージに含まれていないファイルやリソースへのアクセスは制限される。これらはDockerではなく、Linuxのリソース管理システムであるcgroupやseccomp、そしてUbuntuで使われているセキュリティ機構であるAppArmorを使って行われる仕組みとなっている。
また、SnappyではOS自体も「ubuntu-core」というパッケージで提供されており、このパッケージをアップデートすることでOS全体の更新を行う仕組みになっている。
Snappyのインストール
SnappyもAtomic Hostと同様、KVMイメージやOVAイメージ、Vagrant向けBoxファイル、イメージファイルといったさまざまな形式で提供されている。Snappyの「Get started」ページでは対象とするデバイス/サービスごとの導入方法が紹介されているが、今回はx86版のイメージを利用する方法を紹介する。
まず、https://developer.ubuntu.com/en/snappy/start/#try-x86よりx86向けのイメージをダウンロードする。安定版（stable）と開発版（edge）があるが、今回は安定版の「15.04/stable」を選択した。
このイメージファイルはxz形式で圧縮されており、unxzコマンドでファイルを展開し、ddコマンドを使って適当なストレージデバイスにコピーすると、そのストレージからそのままSnappyをブートできるようになる。インストーラが含まれているわけではなく、展開したストレージにそのままSnappyのルートディレクトリが作成される点に注意したい。
たとえばさくらのクラウドの場合、アーカイブ機能を使ってイメージをアップロードし、そこから作成した仮想ディスクをサーバーに接続することでSnappyがインストールされたサーバーを作成できる。ただし、この場合圧縮されたイメージをローカルで展開してからアップロードする必要がある。圧縮されたイメージは約160MBだが、展開後は約3.63GBという大容量になるため、アップロードに時間がかかってしまう。そのため、今回はすでにさくらのクラウド上で作成済みのマシンを利用してインストールを行った。
具体的な手順としては、まずSnappyをインストールする空の仮想ディスクを作成する（図4）。
続いて作業に使用するマシンに作成したディスクを接続する（図5）。このとき、作業に使用するマシンは停止している必要がある。
次に作業用マシンを起動し、そこに圧縮されたイメージファイルをコピーして展開し、ddコマンドでディスクイメージをディスクに書き込む。今回は追加したディスクには「/dev/vdb」というデバイスファイルが割り当てられていたので、次のように実行した。
# unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz | dd of=/dev/vdb bs=32M 0+472155 records in 0+472155 records out 3899999744 bytes (3.9 GB) copied, 32.4884 s, 120 MB/s
書き込みが完了したら作業用マシンをシャットダウンし、Snappyを書き込んだディスクを取り外す（図6）。
最後に、Snappyを書き込んだディスクを接続したサーバーを作成して起動すれば良い（図7）
この方法でインストールした環境ではあらかじめ「ubuntu」というアカウントが作成されており、「ubuntu」というパスワードでログインできる。ログイン後直ちにpasswdコマンドでパスワードを変更しておこう。
Snappyのネットワーク設定
Snappyのデフォルト設定では、DHCPを使ってIPアドレスを取得するようになっている。さくらのクラウドで利用する場合などDHCPサーバーが利用できない場合は、使用するIPアドレスを静的に設定しておく必要がある。直接設定ファイルを編集しても良いのだが、Snappyでは、「snappy config」コマンドを使ってYAML形式で設定ファイルを読み書きする仕組みがあるので、今回はこれを使って設定を行った。
まず、次のように「snappy config」コマンドを実行して現時点での設定情報をYAMLファイルに出力する。ここでは引数として「ubuntu-core」を指定することで、OS自体の設定情報を出力させている。
$ snappy config ubuntu-core > config.yml
続いて出力されたconfig.ymlファイルをviコマンドなどで編集し、設定情報を追加していく。ネットワークの設定は、「network」→「interfaces」→「interfaces」以下、対応するネットワークインターフェイスの「content」以下に、「etc/network/interfaces」以下に記述するのと同じフォーマットで記載できる。たとえばIPアドレスが「192.0.2.0/24」、デフォルトゲートウェイが「192.0.2.1」、DNSサーバーが「192.0.2.2」および「192.0.2.3」だった場合は次のようになる。
config:
ubuntu-core:
autopilot: true
timezone: Etc/UTC
hostname: localhost.localdomain
modprobe: ""
network:
interfaces:
- name: eth0
content: |
auto lo eth0
allow-hotplug eth0
iface eth0 inet static
address 192.0.2.0/24
gateway 192.0.2.1
dns-nameservers 192.0.2.2 192.0.2.3
ファイルの保存後、再度snappy configコマンドを実行してこれを読み込ませ、「networking」サービスをリスタートすることで設定の変更と反映が行われる。
$ sudo snappy config ubuntu-core config.yml $ sudo service networking restart
パッケージのインストールとアップデート
前述のとおり、Snappyではsnappyコマンドでパッケージのインストールやアップデートが行える。また、SnappyではOSもパッケージの1つとして提供されており、OS自体のアップデートもパッケージのアップデートと同じように行える。
インストールされているパッケージ一覧は、「snappy list」コマンドで確認できる。
$ snappy list Name Date Version Developer ubuntu-core 2015-11-13 10 ubuntu webdm 2015-11-13 0.9.4 canonical generic-amd64 2015-11-13 1.4 canonical
「-uv」オプションを付けて実行すると、利用できる最新バージョンのパッケージが確認できる。
$ snappy list -uv Name Date Version ubuntu-core* 2016-01-20 13 webdm* 1-01-01 0.11 generic-amd64 2015-11-13 1.4
アップデートは「snappy update」コマンドで実行できる。
$ sudo snappy update Updating ubuntu-core (13) Syncing boot files Starting download of ubuntu-core Applying update[-] Apply done Updating boot files 124.18 MB / 124.18 MB [=========================================================>_] 100.00 % 414.27 KB/s Done Updating webdm (0.11) Starting download of webdm 13.29 MB / 13.29 MB [==============================================================] 100.00 % 38.46 KB/s Done Starting download of icon for package 38.97 KB / 38.97 KB [==============================================================] 100.00 % 53.50 KB/s Done Waiting for webdm_snappyd_0.9.4.service to stop. Name Date Version Developer ubuntu-core 2016-01-20 13 ubuntu! webdm 1-01-01 0.11 canonical Reboot to use the new ubuntu-core.
なお、一般的なパッケージではアップデート後すぐにそれが反映されるが、Snappyのコア部分であるubuntu-coreのアップデート時には再起動が必要となる。
$ sudo reboot
また、パッケージのインストールは「snappy install」コマンドで行える。たとえば「docker」パッケージをインストールする場合、次のようになる。
$ sudo snappy install docker Installing docker Starting download of docker 8.36 MB / 8.36 MB [=================================================================] 100.00 % 3.41 MB/s Done Starting download of icon for package 21.58 KB / 21.58 KB [==============================================================] 100.00 % 77.92 KB/s Done Name Date Version Developer ubuntu-core 2016-01-20 13 ubuntu docker 2016-01-21 1.6.2.005 canonical webdm 2016-01-22 0.11 canonical generic-amd64 2015-11-13 1.4 canonical
なお、アンインストールは「snappy remove」コマンドで行える。また、インストールできるパッケージ一覧は「snappy search」コマンドで表示できる。
$ snappy search Name Version Summary snake.mectors 0.0.5 Snake overo.gumstix 0.1 overo beagle.gumstix 0.1 beagle webcam-demo 1.0.2 webcam-demo go-example-webserver 1.0.9 go-example-webserver ： ：
Webブラウザ経由でパッケージ管理を行える「webdm」
イメージファイルを使ってSnappyをインストールした場合、デフォルトでは「webdm」というパッケージがインストールされている。webdmはWebブラウザ経由でパッケージ管理を行うためのサーバーソフトウェアだ。デフォルト設定では、サーバーの4200番ポートにWebブラウザでアクセスすることで操作できる。
たとえばサーバーに192.0.2.2というIPアドレスが割り当てられている場合、「http://192.0.2.2:4200/」というURLにアクセスするとwebdmを利用できる（図8）。
ここで「snappy store」をクリックすると利用できるパッケージが表示され、ここからインストール作業も行える（図9）。
ただし、インターネットから直接アクセスできるサーバー上でSnappyを運用している場合、Webdmを外部から操作されてしまう可能性がある。そのため、「snappy deactivate」コマンドでサービスを停止させておくことをおすすめする。
$ sudo snappy deactivate webdm Waiting for webdm_snappyd_0.11.service to stop.
なお、停止させたサービスは「snappy activate」コマンドで再度起動できる。
$ sudo snappy activate webdm
また、Webdmが完全に不要であれば、パッケージ自体をアンインストールしても良いだろう。
$ sudo snappy remove webdm Removing webdm
Snappyのファイルシステム
最後に、Snappyのファイルシステム構造についても簡単に紹介しておこう。Snappyでは/writable/ディレクトリ以下が書き込み可能になっており、/（ルートディレクトリ）を含むそれ以外のディレクトリについてリードオンリーでマウントされている。
また、ストレージには複数のパーティションが作成されている。次の例はlsblkコマンドの実行結果だが、ここでは「system-a」および「system-b」、「writable」という3つのパーティションがあり、ここでは「system-b」がルートディレクトリ、「writable」が/writable/ディレクトリにマウントされている。また、残る「system-a」はアップデートを実行する前のファイルシステムのルートディレクトリに相当する。
$ lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sr0 sr1 vda tqvda1 tqvda2 vfat system-boot 08AA-380D /boot/efi tqvda3 ext4 system-a 45525604-d7e1-464b-990b-a63155607ea2 /writable/cache/system tqvda4 ext4 system-b 45ad8532-0b80-496e-90f2-3cf53778e19d / mqvda5 ext4 writable 55193672-5ae8-4054-9c48-a35a2f725c99 /writable
Snappyではルートファイルシステムを格納するパーティションを2つ用意し、アップデート時にはその片方に更新後のファイルシステムを展開し、ルートファイルシステムを置き換えるという方法で更新を行っており、これにより簡単にアップデート前の環境にロールバックできるようになっている。
また、パッケージについては/apps/＜アプリケーション名＞/＜バージョン＞/ディレクトリ以下などにインストールされる（表1）。パッケージ内のファイルはそのバージョン毎に別のディレクトリに格納されるようになっており、アップデート後も簡単に巻き戻せるようになっている。
| ディレクトリ | 書き込みの可否 | 含まれるファイル |
| /apps/＜パッケージ名＞/＜バージョン＞/ | 不可 | バイナリや関連ライブラリ、リソースなど |
| /var/lib/apps/＜パッケージ名＞/＜バージョン＞/ | 可 | 設定ファイルやデータなど書き込みが必要になるデータ |
| /home/user/apps/＜パッケージ名＞/＜バージョン＞/ | 可 | ユーザーごとに必要となる設定ファイルやデータなど |
コンセプトの異なるAtomic HostとSnappy
さて、Atomic HostとSnappyという、大手ディストリビューションベンダーが提供する2つのディストリビューションを紹介したが、Atomic HostはDockerに特化しているいっぽう、Snappyは独自にアプリケーションのモジュール化機構を実装している点が対照的だ。そのため、現時点では一般的なクラウド環境やクラスタで利用するにはAtomic Hostのほうが扱いやすいという印象を受けた。いっぽうでSnappyはアプリケーションストア的な仕組みを用意するなど、今後エコシステムが発展すればアプライアンス的な分野での利用が進みそうな雰囲気である。
Dockerに特化したOS環境というとCoreOSがすでに広く知られているが、CoreOSは独自の設定管理機構を導入しているため、利用するためにはそれらを習得する必要があった。Atomic HostはそれよりもRHELやCentOSに近い感覚で利用でき、扱いやすい。Dockerコンテナを使ってサービスを運用するのであれば、十分検討に値するOS環境だと言えるだろう。