"KOF 2016" の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
![Linux コンテナの基礎 / KOF 2016](https://cdn-ak-scissors.b.st-hatena.com/image/square/9b5cdf59093c0fde0a66a51bfb994355d52eba26/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F8588fffca4cb4551bf3cfb4d4594c5fa%2Fslide_0.jpg%3F7171580)
これはだいぶ前に書いたエントリです。MINCS作者による最新の解説があるのでそちらもご覧ください。 (2016-11-21追記) コンテナは使いたいけど、たくさんコンテナを起動すると結局それぞれのコンテナに対するセキュリティアップデートなどのメンテナンスは必要だし、コンテナ内独自のプログラムやライブラリ以外はホストと共有したいよね、って話が出てきたりします。みんな考えることは同じで、bind mount を使えば良いよね、って話はでてきてました。 こないだもブログで紹介した kazuho さんの jailing 私が LXC でも結構簡単にできるよ、っていう提案を兼ねて作った lxc-bind こないだのLinuxConでもDockerでたくさんのオプションを並べて、色々工夫して bind mount を使ってやってる発表もありました (Using Docker for existing
今回からはLXCがコンテナイメージを置く領域に使えるいろいろなストレージバックエンドを利用し、LXCを便利に使う方法を紹介していきます。 LXCでいろいろなストレージバックエンドを利用する方法を紹介する前に、今後コンテナでの利用が増えそうな、3.18カーネルで新たに追加されたoverlayfsについて紹介しておきましょう。 タイトルは「Linuxカーネルのコンテナ機能」としていますが、これまでの機能と同様にoverlayfsもコンテナ専用として使う機能ではありません。名前空間やCgroup以上にコンテナ以外でさまざまなシーンで使えそうですね。 overlayfsとは overlayfsはunion filesystemの実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーが構成できます。 話題のDockerが持つ特長として、よくコンテナイメージの差分管理ができることが挙げられま
Kazuho's Weblog: jailing - chroot jailを構築・運用するためのスクリプトを書いた virtuald + ipalias + cgroup + これで快適に「そこそこ隔離したサービス環境」作っていきましょー / “Kazuho's Weblog: jailing - chroot jailを構築・運用するためのス…” http://t.co/aweVwa9kDX— MATSUMOTO, Ryosuke (@matsumotory) 2015, 5月 14 まずは昨日サクッとこういうのを作られたkazuhoさんのjailingを見ていて、こういうのやっぱり面白いなー素晴らしいなーと思いつつ、そういえば僕もmrubyでこういうの書くとか宣言していたなーというの思い出しました。 mruby-cgroup、mruby-capability、mruby-criuがで
lxc-checkpoint が動かないのでデバッグしたり、パッチ書いたり、リジェクトされたりしてる時に気づいたどうでも良い知識。 cgroup の devices サブシステムは デバイスタイプ デバイスノード番号 アクセス権 をスペース区切りした文字列を devices.allow, devices.deny に書き込みます。 # cat devices.list # echo 'c 1:7 rwm' > devices.allow # cat devices.list c 1:7 rwmこれは普通にやった場合。 この書き込む文字列の後に何か文字列があっても無視されます。 # cat devices.list # echo 'c 1:7 rwm # This is Test.' > devices.allow # cat devices.list c 1:7 rwmLXCの設定ファイル
今回からはいよいよLXCの話題です。まずは開発の歴史と現在の開発体制を少し紹介したあと、LXC自身が持つ特徴を紹介したいと思います。 LXCの歴史 LXCはLinuxカーネルにコンテナ関連の機能が実装されはじめた2008年頃から、当時IBMフランスのDaniel Lezcano氏を中心にして、カーネルの機能を使用してコンテナの操作を行うためのツールとして開発がはじまっています。当時の文書を読むと、カーネルに実装されたコンテナ関連の機能をカーネル開発者が簡単に試せるようにすることを目的としていたようです。 その後、開発はかなり活発に行われ2009年にはバージョンは0.6に達しています。筆者が初めてLXCを使い始めたのは2009年の年末で0.6.4の頃です。この頃にはすでに簡単にコンテナの起動や管理ができていました。この後はAppArmorのサポートのようにセキュアにコンテナを使用するための機
コンテナに関係する主要な機能2つの説明が済んだので、今回はLXCで使われることが多いネットワーク関連の機能を紹介しましょう。 コンテナとネットワーク名前空間 コンテナでのネットワークの使用と密接に関係するのが第2回で紹介したネットワーク名前空間です。 コンテナでネットワークを使用する場合、一般的にはネットワーク名前空間を作成します。そして、ホスト上に存在するネットワークインターフェースを、作成したネットワーク名前空間に割り当てます。そうすると、ホストや他のコンテナからは見えない、コンテナからだけ見えるネットワークインターフェースとなります。 もちろん、ネットワーク名前空間を作らなくてもコンテナは作れます。しかし、システムコンテナを使う場合、最近はupstartやsystemdといったソケットを使用するinitが使われることが多いので、ネットワーク名前空間をホストと分けておくのが普通です。
サブシステム紹介(続き) 今回は前回紹介できなかったサブシステムを紹介したあと、cgroup開発の現状に少し触れたいと思います。 Memoryサブシステム コンテナに対してメモリの制限を行いたい場合に使用するのがmemoryサブシステムです。cgroupに対して制限値を設定したり、cgroupのメモリ使用量の監視をしたりできます。 まずは制限を設定してみましょう。制限を設定するには以下の2つのファイルに値を書き込みます。 memory.limit_in_bytes メモリ消費量の制限値の設定と表示(バイト) memory.memsw.limit_in_bytes メモリ+スワップメモリの消費量の制限値の設定と表示(バイト) スワップの消費量も含めた制限を設定したい場合は後者を、スワップの消費量はカウントしない場合は前者を使用します。制限値の設定にはk、K、m、M、g、Gといった単位の文字が
Docker長らくブログ書いてなかったので、どうでもいい話をちょっと書こう。Blue-Greenでチヤホヤされる運命のDockerで、DBを動かすという需要はあんまりないとは思いますが、コンテナでDBを動かすというのもそれはまた一興です。DBを動かすとなると共有メモリをたくさん使うことになるかと思います。そういう共有メモリの設定に関して、バージョン1.0が出てからいままでのやり方が通用しなくなったので、それについて書きます。これまでこれまで、僕はDockerでPostgreSQLコンテナを動かすとき、まずコンテナ内で起動スクリプト的なシェルを実行するようにしていました。そのなかで、以下のようにカーネルパラメータshmmaxの値を大きくしていました。 sysctl -w kernel.shmmax=4418740224 なぜならコンテナ内のshmmaxの値がなぜか小さく設定されているために、
表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
最近注目されている仮想化技術の1つにLXC(Linux Containers)がある。LXCはコンテナ型仮想化技術と呼ばれるものの1つで、OS上に別の隔離された環境を構築するものだ。今回はLXCの仕組みと、基本的なインストールについて紹介する。 さまざまな仮想化技術とLXC 仮想化技術を使って一台のマシン上に複数の隔離された環境を構築する、というのはメインフレームの世界では古くから行われていたが、近年ではマシンの性能向上により、エントリレベルのサーバーでもこのような使われ方が実用的になっている。そういった背景の下注目されているのがLXC(Linux Container)と呼ばれる仮想化技術だ。 広く使われている仮想化技術としてはXenやKVMがあるが、これらはホストOS(もしくはハイパーバイザ)上で演算によって仮想的なマシン環境を作り出し、その上でOSを実行させることで複数のOS環境の構築
前回は、Linuxで使えるコンテナの実装を説明したあと、LXCを使って簡単にコンテナの作成、起動、停止が行えるところを紹介しました。今回は、そのコンテナの仕組みを簡単に説明し、その仕組みからくるメリット・デメリットを紹介した後、コンテナはカーネルのどのような仕組みを使って動作しているのかを簡単に説明していきたいと思います。 コンテナの仕組み コンテナをまだ使ったことがない方でも、VMwareやVirtualBox、KVMといった仮想マシン(VM)を使ったことはあるという方は多いのではないでしょうか。まずはVMとの比較をしながら、コンテナの仕組みを説明してみましょう。 図1 VMとコンテナの仕組み(1)仮想マシン VMでは図1のように、コンピュータの上で動くOSやVMを実現するためのハイパーバイザの上で、実際のハードウェアをエミュレートするVMが動きます。つまり実際の物理的なコンピュータと同
kernel に入るぞ、と言われつつ入ってない overlayfs。いつですかね? なかなか凝ったことを試す時間が取れない今日このごろ、非常に薄い内容のエントリです。 (2014-05-15 追記) LXC では、ファイルシステムの機能を利用した snapshot による clone をサポートしています。しかし、非特権コンテナで clone を作成する場合、どうしても通常の rsync による clone になってしまいます。しかし、Ubuntu のカーネルだと overlayfs が利用可能で、非特権コンテナの場合でも使用可能です。一般ユーザが overlayfs の操作が可能ということでなく、User Namespace 内の root の権限で overlayfs のマウントが可能になっているためです。(追記終わり) (2014-10-08 追記) 今はオプションで "workdi
はじめに みなさま、はじめまして。加藤と申します。最近注目を集めている仮想化技術の『コンテナ』に関する連載を始めることになりました。よろしくお願いいたします。 コンピュータの性能が向上し、仮想化という言葉も一般的になりました。従来はVPS等のサービスやIaaS、クラウドといったキーワードと共に語られることが多かった仮想化ですが、最近では開発者自身のPC上で仮想化を使ってテスト環境を作成し、使い終わったら消去するという使われ方が増え、仮想化技術を扱うエンジニアも、インフラエンジニアからアプリ開発者まで広くなりました。 また、従来は仮想的なマシンをコンピュータ上で実現するVMware、Hyper-V、KVMといった技術が話題になることが多かったことに対し、最近ではImmutable Infrastructureといったキーワードと共に『コンテナ』が話題になることが増えました。『コンテナ』とは
Passive benchmarking with docker LXC and KVM using OpenStack hosted in SoftLayer. These results provide initial incite as to why LXC as a technology choice offers benefits over traditional VMs and seek to provide answers as to the typical initial LXC question -- "why would I consider Linux Containers over VMs" from a performance perspective. Results here provide insight as to: - Cloudy ops times (
変更履歴 2014/04/20 公開 2014/04/27 構成情報ファイルの説明追加 2014/06/15 dm-thinprovisiongのデバイスメタデータファイル変更 背景 先だって、「Linuxコンテナ(LXC)の基礎をまとめ直す」というコラムに、「来るべきDockerの波に向けて、まずは、コンテナの基礎を理解しましょう!」的な話を書きました。この中で、比較的に原始的なコンテナ利用法として、「RHEL6.2のlibvirtからLinuxコンテナを利用」という記事を紹介しています。 この記事では、busyboxを使った簡易httpサーバのコンテナを起動していますが、この手順に従うと(気づく人は)容易に気づくのが、コンテナに見せるファイルシステムの準備がいかに面倒か、という事実です。コンテナから見えるルートファイルシステムは、基本的には、ホスト上の特定のディレクトリにchrootし
(2014-07-06 追記してます) (2014-05-11 追記してます) (2014-04-24 追記してます) ついにリリースされましたね.Ubuntu の新しい LTS.これを目標に LXC 1.0 の開発は進められてきたわけで,きっと特に苦労する事もなく一般ユーザでのコンテナの作成と実行が出来るのだろうなあと思って試してみました.結論から言うと出来ました.なので特にこのブログエントリを読む事なく作る事が出来るのでお急ぎの方はこの後読まずにさっさとやってしまいましょう :-D 過去,Ubuntu 上で 一般ユーザでの lxc コンテナの実行 - TenForwardの日記 LXCの非特権コンテナ 〜 Ubuntu Trusty 編 - TenForwardの日記 と 2 度ほどためしていますが,徐々に簡単になって,ついに完成型になりました. まず Ubuntu 14.04 LTS
4/12 に大阪でコンテナに関する仮想化の勉強会を開催し,『Linux コンテナ入門』というお題で発表してきました. 前日はDocker Meetup Tokyo #2で,最終の新幹線に飛び乗り,翌日午前から準備をして (前日,私がいない間に準備してくれて助かった!!),午後から勉強会ということで,アラフィフ予備軍のおっさんにはちょっと強行軍だったのですが,年間を通じて最もコンテナ分の濃い二日間になり,非常に楽しく,ためになる時間を過ごすことができました. この勉強会はは広く「コンテナに少しでもかすれば良い」という考えで開催しています.私がどちらかというとベースとなる仕組みの勉強ばかりなので,実際の応用事例とかも聞きたい,自分が使ってないコンテナ技術についても聞きたいと思っているからです.自分が聞きたい話を聞くために勉強会を開く,という考えですね.プログラムについても仕組みから徐々に応用に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く