新たなサーバー環境構築ツールとして普及が始まっているDockerは、その開発も積極的に行われている。そこで本連載記事では、4回に渡って最近Dockerに実装された新機能について紹介していく。今回は、Dockerのボリュームプラグインとストレージドライバについて紹介する。 Dockerの「ボリュームプラグイン」と「ストレージドライバ」 昨今のDockerでは、各機能を個別のコンポーネントに分離する方向で開発が進められている。ストレージ関連の処理もすでに分離されており、「ボリュームプラグイン」やストレージドライバ」を使って目的や環境に応じた設定を行うことが可能になっている。この2つは名前が似通っているため混乱しやすいが、まったく別のものだ（図1）。 図1 ボリュームプラグインとストレージドライバ まずボリュームプラグインだが、これはコンテナ外のストレージをコンテナ内に「ボリューム」としてマウン

「--memory」（もしくは「-m」）オプションでは、そのコンテナが利用できる最大メモリ量を指定できる。指定の際は「k」や「m」、「g」といった単位および「b」（バイト）も利用可能だ。たとえばコンテナが利用できるメモリ量を最大256MBに制限するには、以下のオプションを指定してコンテナを起動すれば良い。 --memory=256mb なお、実際の制限値はOSのページサイズの倍数に丸められるため、指定した値がそのまま制限値になるわけでは無い。たとえば上記のように「--memory=256mb」を指定したコンテナについて「docker stats」コマンドでリソース使用状況を確認すると、メモリのリミット（MEM LIMIT）が「268.4MB」となっていることが分かる。 # docker stats CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/

今回からはLXCがコンテナイメージを置く領域に使えるいろいろなストレージバックエンドを利用し、LXCを便利に使う方法を紹介していきます。 LXCでいろいろなストレージバックエンドを利用する方法を紹介する前に、今後コンテナでの利用が増えそうな、3.18カーネルで新たに追加されたoverlayfsについて紹介しておきましょう。 タイトルは「Linuxカーネルのコンテナ機能」としていますが、これまでの機能と同様にoverlayfsもコンテナ専用として使う機能ではありません。名前空間やCgroup以上にコンテナ以外でさまざまなシーンで使えそうですね。 overlayfsとは overlayfsはunion filesystemの実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーが構成できます。 話題のDockerが持つ特長として、よくコンテナイメージの差分管理ができることが挙げられま

Dockerのファイルシステムやマウント方法について記載しています。 またデータボリュームのマウントについて記載し、データの永続化についても記載しています。Read less

「docker run/stop/start/rm/commit」の各コマンドの役割を整理しておきます。全体像はこんな感じ。 前提環境はこちらです。 # cat /etc/redhat-release Fedora release 20 (Heisenbug) # uname -a Linux fedora20 3.14.6-200.fc20.x86_64 #1 SMP Sun Jun 8 01:21:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # rpm -q docker-io docker-io-1.0.0-1.fc20.x86_64まず、「docker run」で新たなコンテナを起動します。「--name」オプションで名前「web01」を付けておきます。「docker ps」は起動中のコンテナを表示します。 # docker run -it

「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事（コミット、ブランチ、マージ、リベース）について解説します。

この記事は、Docker 102レベルを意図して書かれている。Dockerが何か分からない、または仮想マシンや構成管理ツールと比べてどうなのか分からないという方には、この記事は現時点ではやや高度すぎるかもしれない。 この記事が、dockerコマンドラインの習得に悪戦苦闘している人、中でも特に、コンテナとイメージの違いを正確に知っている人の助けとなれば良いと思っている。さらに具体的に言えば、この記事では、普通のコンテナと起動中のコンテナを見分けていくつもりだ。 私はこれを、下層の細かい部分、つまりユニオンファイルシステムに注意しながら書いている。私はdocker技術の経験が比較的浅く、dockerコマンドラインを習得するのが難しいと感じていたため、私自身、このプロセスに数週間にわたって取り組んだ。 脱線：私が思うに、短期間で学び、かつツールを正しく使えているという自信をつける最良の方法は、技

2016年3月22日(月) 18:30 ～ JAWS-UGコンテナ支部×JAWS-UG CLI専門支部 #1　発表資料 jawsug-container.connpass.com/event/27537/ 会場：NHN テコラス株式会社 #jawsug #jawsug_cli #jawsug_ct Read less

年末を迎えて今年もAdvent Calendarが多数作られていますね。この連載の今回の記事はLinuxカーネルの機能を紹介するので、Linux Advent Calendar 2014の16日目の記事としても書きました。興味深い記事が並んでいて勉強になりますね。 さて、第13回から3回、田向さんにPlamo LinuxでのLXCの利用に焦点を当てて記事を書いていただきました。テンプレート内部の詳しい解説から、Plamo Linuxでのコンテナの作成、ネットワーク構成の応用的な解説、コンテナでサウンドを扱う話まで、面白い記事が続きましたね。 ネットワークの話やサウンドの話はPlamo Linux以外でも十分に応用ができる話でしたし、サウンドの記事に関してはサウンド以外のデバイスをコンテナで使う場合にも非常に参考になる話だったと思います。 田向さん担当の記事のうち、第14回と第15回では一般

前回の記事は、私が所属する会社のAdvent Calendarの5日目の記事でした。これまでは、この連載記事でAdvent Calendarに参加するのは1回だけでした。 今年はcgroup v2の話題を書こうと決めたときに、内容から考えて1回では済まない量になるだろうと思いました。そこで、続けて2回でcgroup v2の紹介をして、2つのAdvent Calendarに参加しようと決めました。1回目はちょうど社内で募集が始まっていた会社のAdvent Calendar、2回目は例年どおりLinux Advent Calendarに参加することにしました。 そういうわけで、今回の記事は昨年まで何度か参加していたLinux Advent Calendar 2017の19日目の記事です。 今回は、実際にcgroup v2を操作しながら、前回紹介したcgroup v2の特徴をおさらいしましょう。

この連載をはじめてから、毎年この連載の記事でAdvent Calendarに参加してきました。昨年までは、この連載の記事で"Linux Advent Calendar"に参加してきました。 今年は参加するカレンダーを少し変えて、まずはこの記事で私が所属する会社のAdvent Calendarであるファーストサーバ Advent Calendar 2017の5日目に参加してみます。あまりたくさんの人が興味を持たなさそうな話題なので、会社のAdvent Calendarにマッチするのか心配です (^_^;)。 さて、Linuxでコンテナでリソース制限を行うための機能として、この連載では第3回から第5回まで3回に渡ってcgroupについて解説しました。 cgroupは、多くのLinuxディストリビューションでinitとして採用されているsystemdが使っていますので、今やLinuxをお使いであ

サブシステム紹介（続き） 今回は前回紹介できなかったサブシステムを紹介したあと、cgroup開発の現状に少し触れたいと思います。 Memoryサブシステム コンテナに対してメモリの制限を行いたい場合に使用するのがmemoryサブシステムです。cgroupに対して制限値を設定したり、cgroupのメモリ使用量の監視をしたりできます。 まずは制限を設定してみましょう。制限を設定するには以下の2つのファイルに値を書き込みます。 memory.limit_in_bytes メモリ消費量の制限値の設定と表示（バイト） memory.memsw.limit_in_bytes メモリ+スワップメモリの消費量の制限値の設定と表示（バイト） スワップの消費量も含めた制限を設定したい場合は後者を、スワップの消費量はカウントしない場合は前者を使用します。制限値の設定にはk、K、m、M、g、Gといった単位の文字が

表1にある「実装されたバージョン」はカーネルに実装されたバージョンで、ディストリビューションによってはこれよりも古いバージョンのカーネルにバックポートされている場合もあります。また、実装された時点では階層構造がサポートされておらず、後のバージョンで実装されたものもあります。 お使いのシステムで使用可能なサブシステムは、カーネルのバージョンだけでなく、カーネルをどのような設定で作成したかによっても違います。使用可能なサブシステムは以下のように/proc/cgroupsで確認できます。 $ cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 0 1 1 cpu 0 1 1 cpuacct 0 1 1 memory 0 1 1 devices 0 1 1 freezer 0 1 1 blkio 0 1 1 per

前回は、コンテナの仕組みとLinuxカーネルに実装されているコンテナ関連機能のひとつである名前空間について説明しました。今回は名前空間と並んでコンテナの実現に重要な役割を担っているcgroupについて説明していきます。 cgroupは2006年9月にGoogleのエンジニアによって最初のパッチが投稿され、2.6.24カーネルで最初のマージがなされた機能です。2010年にリリースされたRed Hat Enterprise Linux 6.0にこの機能が搭載され、専用のマニュアルが存在したことから、使ったことのある方や、名前をご存知の方も多いのではないでしょうか。 cgroupは"Control Group"の略です。プロセスをグループ化して、そのグループ内に存在するプロセスに対して共通の管理を行うために使います。たとえば、ホストOSが持つCPUやメモリなどのリソースに対して、グループごとに制

前回は、Linuxで使えるコンテナの実装を説明したあと、LXCを使って簡単にコンテナの作成、起動、停止が行えるところを紹介しました。今回は、そのコンテナの仕組みを簡単に説明し、その仕組みからくるメリット・デメリットを紹介した後、コンテナはカーネルのどのような仕組みを使って動作しているのかを簡単に説明していきたいと思います。 コンテナの仕組み コンテナをまだ使ったことがない方でも、VMwareやVirtualBox、KVMといった仮想マシン（VM）を使ったことはあるという方は多いのではないでしょうか。まずはVMとの比較をしながら、コンテナの仕組みを説明してみましょう。 図1　VMとコンテナの仕組み（1）仮想マシン VMでは図1のように、コンピュータの上で動くOSやVMを実現するためのハイパーバイザの上で、実際のハードウェアをエミュレートするVMが動きます。つまり実際の物理的なコンピュータと同