Dockerのコンテナーでアプリケーションを起動する場合、専用の起動スクリプトからアプリケーションを起動して、最後に（後からdocker attachできるように）bashを起動しておくことがあります。 次は、httpdサービスを起動するコンテナーを作成する簡単なDockerfileですが、コンテナー起動時にスクリプト「init.sh」を実行するようにしています。 Dockerfile FROM centos:centos6 MAINTAINER enakai RUN yum -y install httpd ADD src /var/www/html RUN chmod -R 644 /var/www/html/* ADD init.sh /usr/local/bin/init.sh RUN chmod u+x /usr/local/bin/init.sh CMD ["/usr/loca

何の話かというと Dockerイメージは複数のレイヤーが重なった形になっています。このあたりを内部構造とあわせて解説します。前提の環境は、CentOS7です。（つまり、ローカルのイメージ管理は、dm-thinが前提。） # rpm -q docker docker-0.11.1-22.el7.centos.x86_64 ローカルにイメージをpullする時の動作 まず、ローカルのイメージをすべて消してキレイな体にしておきます。 # systemctl stop docker.service # rm -rf /var/lib/docker/* # systemctl start docker.serviceCentOSの公式イメージをpullします。この時、4つのイメージ（b1bd49907d55、b157b77b1a65、511136ea3c5a、34e94e67e63a）がダウンロードさ

参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール（biosdevname）がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name

何の話かというと RHEL7/CentOS7では最小構成でインストールすると、ifconfig、route、netstat、arpなどのネットワーク関連のコマンドが使えません。これは、次のコマンドで「net-tools」パッケージを導入すると解決します。 # yum -y install net-tools しかしながら！ RHEL7/CentOS7では、net-toolsを「deprecated（廃止予定）」としており、今後は、iproute2パッケージに含まれる「ip」「ss」などのコマンドを使用することが推奨されています。 ・お客さんのRHEL7サーバーのメンテを頼まれたらnet-toolsが入ってなかった！ ・「えー。まだifconfigつかってんのー。」と若い同僚に冷たい目で見られた！ ・などなど といった事態に備えて、RHEL7/CentOS7を導入した際には、iproute2

RHEL7RC+EPEL版Dockerの前提で解説します。RHEL7RCを最小構成で入れて、次の手順でDockerを導入します。 # yum -y install bridge-utils net-tools # yum -y install http://download.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm # yum -y install docker-io # systemctl enable docker.serviceDockerが設定するiptablesの内容を見るために（見やすくするために）、firewalldを停止した上でdockerサービスを起動します。 # systemctl stop firewalld.service # systemctl mask firew

何の話かというと LevelDBというのは、組み込み型のKeyValue Storeです。SQLiteのような感じでデーモンを立ち上げずにローカルファイルシステムを使って、KeyValue Storeが利用できます。 これをローカルファイルシステムではなくて、GlusterFSのボリュームで使えないか試したのですが、FUSEマウントを利用すれば、あっさりと動くことが確認できました。LevelDBは複数ファイルにデータをばらまくので、ファイル単位で分散するGlusterFSとの相性はよいかも知れません。 で、次のチャレンジというか思いつきで、巷で話題のlibgfapi[1]を使うようにLevelDBを改造できないかと、週末をつぶして頑張りました。結果としては、無事に動くものができあがりました[2]。この際、LevelDBのI/O処理がなかなかおもしろい構造になっていることに気づいたので、メモ

「Systemd入門(4) - serviceタイプUnitの設定ファイル」で、[Service]セクションのオプション「PrivateTmp」を紹介しました。実はこの他にも、ファイルシステムのセキュリティ保護を図るオプションがあります。今回は、これらオプションの紹介に加えて、それがどのような仕組みで実装されているのかを解説します。 参考資料 systemd for Administrators, Part VI - Changing Roots systemd for Administrators, Part XII - Securing Your Services ファイルシステム保護オプション serviceタイプのUnitについて、[Service]セクションで次のようなオプションを指定できます。（念のため、PrivateTmpも再掲しています。） オプション 説明 ReadOnl

この連載では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明します。今後出てくる予定のRHEL7での実装とは異なる部分があるかも知れませんが、その点はご了承ください。 今回は、serviceタイプのUnitについて、設定ファイルの書き方を説明します。 Unit設定ファイル 参考資料 ・systemd.unitのmanページ：設定ファイルの一般的な説明 ・systemd.serviceのmanページ：serviceタイプUnitの設定オプションの説明 「Systemd入門(1) - Unitの概念を理解する」で説明したように、各Unitの設定ファイルは、/usr/lib/systemd/system/以下と/etc/systemd/system/以下にあります。両方のディレクトリに同名の設定ファイルがある場合は、後者（/etc/systemd/sys

この連載では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明します。今後出てくる予定のRHEL7での実装とは異なる部分があるかも知れませんが、その点はご了承ください。 今回は、表題の小ネタを2つお届けします。 cgroups systemdの管理下では、すべてのプロセスについて、cgroupsによる分類が行われます。cgroupsでは、グループに階層構造を持たせることができますが、systemdは「systemグループ」と「userグループ」を用意した上で、その下にサブグループを作成していきます。 グループ 説明 system systemdから起動するserviceについて、この下に該当service用のサブグループを作成します。 user この下にユーザアカウントごとのサブグループを作成します。その下には、さらに、ログイン端末ごとのサブグループ

この連載では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明します。今後出てくる予定のRHEL7での実装とは異なる部分があるかも知れませんが、その点はご了承ください。 前回は、systemdの基本概念となるUnitの説明をしました。今回は、日々のオペレーションで必要となる、serviceの操作方法をまとめます。旧来のchkconfigコマンド、serviceコマンドに相当する部分ですね。 サービスの確認 現在稼働中のサービス一覧 # systemctl list-units --type=service UNIT LOAD ACTIVE SUB JOB DESCRIPTION auditd.service loaded active running Security Auditing Service crond.service loaded act

Linuxの起動処理は、これまでinit/upstartと呼ばれる仕組みで行われていました。Red Hat Enterprise Linux 7 (RHEL7)では、これが、systemdと呼ばれるまったく新しい仕組みに置き換わります。Fedoraでは、すでに先行してsystemdが採用されていますが、この連載（？）では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明していきます。今回は、systemdの動作の基礎となる「Unit」の概念を理解します。 systemdを採用したFedoraでLinuxの基礎を学びなそう！という方には、「「独習Linux専科」サーバ構築/運用/管理――あなたに伝えたい技と知恵と鉄則」がお勧めです。(^^/ systemdの考え方 参考資料 ・Rethinking PID 1：systemdの開発者であるLennart

何の話かというと 微妙な違いではあるのですが、RHEL5とRHEL6では、cronとanacronの関係が若干変わっています。 RHEL5を運用していた方は、cronとanacronの関係を cronが実行しそこねた定期ジョブをanacronが代わりに再実行する と捉えているのではないでしょうか？ これは間違いではないのですが、実は、もともとcronとanacronにはこのような関係はありません。それぞれ独立したジョブ実行ツールであり、目的に応じて使い分けることになります。なのですが、RHEL5では、あえてcronとanacronを連携させるような設定を行なって、上記のような使い方をしていました。おそらくこれは、「cronしか無かった時代の設定を引き継ぎつつ、anacronのジョブ再実行機能も使いたくなった」という歴史的な理由によるものです。 一方、RHEL6では、このような連携はなくなっ