2015年 7月 の投稿一覧

Red Hat Enterprise Linuxでの独自コンテナイメージの作成

Docker上で動作するコンテナイメージは『docker-buildコマンド』と、『Dockerfile』を作成することで、カスタマイズして作成することができます。 今回は、この2つを使って簡単なコンテナイメージを作成してみようと思います。

独自コンテナイメージの作成

サイオステクノロジー杉崎です。
前回は、「Red Hat Enterprise LinuxでのDocker利用方法」の中で、Dockerって何?という記事を書かせていただきました。今回は、さらに一歩進めた内容で、Dockerを紹介をさせていただきます。

Dockerfileの作成

『Dockerfile』に必要な内容を記述することで独自のコンテナイメージを作成することができます。
それでは、最低限の記述でコンテナイメージを作成してみましょう。
『Dockerfile』に、以下の内容を記述するだけで、doucker-buildコマンドは実行することができます。

# cat Dockerfile
From centos
MAINTAINER test<test@test.com>

《From centos》で、利用するコンテナイメージとして《CentOS》を選択したことになります。
《From fedora》した場合《fedora》を選択したことになります。
「MAINTAINER test<test@test.com>』 で、作成するコンテナイメージの管理者を設定します。

コンテナイメージを作成

コンテナを作成するときには、『docker-buildコマンド』を使用します。
簡単にイメージを作成するには、以下のパラメータのみで作成することができます。

 # docker build -t [ {イメージ名} [ : {タグ名} ] ] {Dockerfileのあるディレクトリ}

それでは、実際にdocker-buildを使ってみましょう。実行例の様に入力し”Enter”を押してみましょう。

# docker build -t centos-test .
Sending build context to Docker daemon 12.29 kB
Sending build context to Docker daemon 
Step 0 : FROM centos
    == snip ==
Status: Downloaded newer image for docker.io/centos:latest
 ---> 7322fbe74aa5
Step 1 : MAINTAINER test<test@test.com>
 ---> Running in 97c22992c485
 ---> ad6a0dee9cda
Removing intermediate container 97c22992c485
Successfully built ad6a0dee9cda

Successfully built 〜 が出力されたことから、『docker-buildコマンド』を利用してのコンテナイメージの作成は成功したことになります。

では、『docker-imagesコマンド』を使って、ローカルに作成されたコンテナイメージの結果を見てみましょう。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
centos-test         latest              ad6a0dee9cda        About an hour ago   172.2 MB
docker.io/centos    latest              7322fbe74aa5        5 weeks ago         172.2 MB

実行結果から、centos-testが作成されていることが確認できます。

コンテナイメージの起動

コンテナイメージを起動してみましょう。
起動コマンドに使用するコマンドは、docker-runコマンドになります。
簡単にイメージを起動するには、以下のパラメータのみで作成することができます。

 # docker run -i -t [ {イメージ名} [ : {タグ名} ] ] /bin/bash

それでは、実際にdocker-runを使ってみましょう。

# docker run -i -t centos-test /bin/bash
[root@localhost ~]# docker run -i -t centos-test /bin/bash
    == snip ==
[root@ca1d9f6746ab /]#

プロンプトが表示されれたことで、コンテナイメージが起動した事になります。
では起動したコンテナイメージがCentOSであるかを確認する為に、確認の一例として、/etc/redhat-releaseの内容を確認してみましょう。

# cat /etc/redhat-release 
CentOS Linux release 7.1.1503 (Core)

“CentOS Linux release 7.1.1503” と表示されていることから、CentOS 7.1 が起動している事が確認できます。

バージョン指定のコンテナイメージを作成する場合

タグ名に、バージョンとすることで任意のバージョンのコンテナイメージを作成することができます。
以下は、CentOS 6.6 のコンテナイメージを作成する場合の、Dockerfile になります。

# cat Dockerfile 
From centos:6.6
MAINTAINER test<test@test.com>

『Dockerfile』更新後に、『docker-buildコマンド』にてコンテナイメージを作成します。
タグ名に、バージョン番号を入れる事で作成したコンテナイメージの区別ができます。今回は、”6.6″ とバージョンを入れて作成します。

# docker build -t centos-test:6.6 .
Sending build context to Docker daemon 12.29 kB
Sending build context to Docker daemon 
Step 0 : FROM centos:6.6
   == snip ==
Step 1 : MAINTAINER test<test@test.com>
 ---> Running in f580b080006f
 ---> 92592636623e
Removing intermediate container f580b080006f
Successfully built 92592636623e

『docker-imagesコマンド』を使って、ローカルに作成されたコンテナイメージの結果を見てみます。
《centos-test:6.6》が作成されている事が解ります。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
centos-test         6.6                 92592636623e        About a minute ago   202.6 MB
docker.io/centos    6.6                 8b44529354f3        3 months ago         202.6 MB

docker-runコマンドを使って、実際、CentOS 6.6 のイメージが作成出来ているか確認してみましょう。
今回も、redhat-releaseの中身でバージョンの確認をします。

# docker run -i -t centos-test:6.6 /bin/bash
[root@01cd50d320f7 /]# cat /etc/redhat-release 
CentOS release 6.6 (Final)

redhat-release の中が、CentOS release 6.6 となっている事から、CentOS 6.6のコンテナイメージが作成されたと判断できます。

このようにコンテナイメージは簡単に作成することが出来ますので、皆さんも試してみては如何でしょうか?

systemd-journaldを活用しよう

Red Hat Enterprise Linux 7 ではsystemd-journald(以下journald)が導入されています。journaldは従来からあるsyslogと比較すると、細かな時間を表現できたり、ログの中に従来は失われていた優先度などの情報を保持できる、インデックスによる高速な検索、ログのローテートをjournald自身で行うなどの様々な特長を持っています。

レッドハットの森若です。今回はRHEL7でロギングの仕組みとして導入されたsystemd-journaldを紹介します。journaldは従来のsyslogとは大きく異なっており様々な特長を持っています。デフォルトでは各種のログをrsyslogへ配送するための中継ぎとして構成されていますが、永続化して利用することで大変強力なツールとして活用できます。

journaldでのログはどこに保存されるのか?

デフォルトでは/run/log/journal/以下に保存されています。/run以下はtmpfsで、再起動などをすると消えてしまいます。

mkdir /var/log/journal すると/run以下ではなく/var以下に保存します。journaldを活用したいときは迷わず mkdir /var/log/journal しましょう。永続化することによりrsyslogと二重にログを保存することになりますが、ディスク容量を食う以外には特に悪いことは起きません。journaldで一本化できると確信ができたらrsyslogの利用をやめてしまってもかまいません。

実はこのディレクトリ構成はjournaldの特長である、起動直後からのログを統一した形で取り扱えるという性質に関連しています。

initramfs内で起動直後にjournaldを起動します。この時点ではroot fsをmountしていないので、まずはtmpfsで作成された/run 上にログ蓄積をはじめます。この状態のまま継続して動作することもできますが、初期化が順調に進んでroot fsをmountしたあとに、/var以下に/run以下のログを移動させる処理をおこなってログを永続化します。

systemd-journaldでのログ拡張

systemd-journaldではログを幅広く拡張しています。ログに含まれている情報の例を見てみましょう。

  • (アプリケーションが対応していれば)メッセージの文面によらない一意なIDやソースコード上の位置を付加できるためトラブルシュート時に活用しやすい

  • 優先度が保持されるのでログ蓄積後に任意の優先度で検索できる

  • ログを送信したプロセスについての各種情報を保存しているのでIdentifierを正しく設定しないプログラムや偽装するプログラムへの対応にもなる

  • タイムスタンプがマイクロ秒単位となっており、クラスタ環境などで複数マシンにまたがっていてもログの前後関係が把握しやすい

下の図はログ1行分の出力例です。ピンク色の部分が従来のsyslogで保存されていた情報ですので、たくさんの情報が含まれていることがわかります。

ログの表示とフィルタによる検索

journaldのログはバイナリフォーマットになっているのでjournalctlコマンドにより表示をおこないます。journalctlコマンドをただ叩くと一番古いものからページャで表示されます。

単純に保存したログを読むだけでもよいのですが、journaldはそれぞれのフィールドを利用してフィルタを指定し、高速に検索できます。

  • 実行ファイルでのフィルタ

journalctl /usr/bin/pcscd のように実行ファイルのパスをオプションとして渡すことで、実行ファイルによるフィルタをおこないます。

  • 優先度によるフィルタ

journalct -p 4 のように数字0(emerg)から7(debug)までの間で優先度を指定します。たとえば4であればwarning以上の全ての優先度のログを表示します。

  • systemd unit でのフィルタ

systemdのunitでの絞り込みができます。systemdは関連プロセスを追跡しているため、子プロセスの出力も確認できます。たとえば journalctl -u NetworkManager  とすることでNetworkManagerが呼びだす dhclientやModemManagerによるログも確認することができます。

  • 複数条件によるAND検索

journalctl -p 4 /usr/bin/su のように複数の条件を指定することで「Warning以上の優先度で/usr/bin/suから出力されたもの」のようにAND検索による絞り込みがおこなえます。

その他にも起動毎のBOOT IDを保持しているので「journalctl -b -1」として前回の起動時からのログを見たり「journalctl -k」としてカーネルから出力されたログのみを確認することができます。

ログ表示フォーマットの変更

journalctlのデフォルトでは読みだした内容を馴染み深いsyslog風にフォーマットしてくれます。しかしjournaldが保持している情報をどう整形するかは -o オプションで選択できます。

  • journalctl -o short-precise  時刻のみをマイクロ秒単位の表記にし、あとはsyslog風のまま

Jul 16 16:04:11.535406 rhel71.example.com systemd-journal[104]: Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).
  • journalctl -o json 全てのフィールドを含んだJSON形式での出力

{ "__CURSOR" : "s=ef196eeafe92413cba33aab060cb9029;i=1;b=58f89813972d401ba3591da7067616a3;m=ad1eb;t=51af8adac9c2e;x=cce32c6f2c25f849", "__REALTIME_TIMESTAMP" : "1437030251535406", "__MONOTONIC_TIMESTAMP" : "709099", "_BOOT_ID" : "58f89813972d401ba3591da7067616a3", "PRIORITY" : "6", "_TRANSPORT" : "driver", "MESSAGE" : "Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).", "MESSAGE_ID" : "ec387f577b844b8fa948f33cad9a75e6", "_PID" : "104", "_UID" : "0", "_GID" : "0", "_COMM" : "systemd-journal", "_EXE" : "/usr/lib/systemd/systemd-journald", "_CMDLINE" : "/usr/lib/systemd/systemd-journald", "_CAP_EFFECTIVE" : "4402800cf", "_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service", "_SYSTEMD_UNIT" : "systemd-journald.service", "_SYSTEMD_SLICE" : "system.slice", "_SELINUX_CONTEXT" : "kernel", "_MACHINE_ID" : "1e5c5682191d4edcbdb0ff3725e3fdc1", "_HOSTNAME" : "rhel71.example.com" }
  • journalctl -o export  export/import用のテキスト形式

__CURSOR=s=ef196eeafe92413cba33aab060cb9029;i=1;b=58f89813972d401ba3591da7067616a3;m=ad1eb;t=51af8adac9c2e;x=cce32c6f2c25f849
__REALTIME_TIMESTAMP=1437030251535406
__MONOTONIC_TIMESTAMP=709099
_BOOT_ID=58f89813972d401ba3591da7067616a3
PRIORITY=6
_TRANSPORT=driver
MESSAGE=Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).
MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
_PID=104
_UID=0
_GID=0
_COMM=systemd-journal
_EXE=/usr/lib/systemd/systemd-journald
_CMDLINE=/usr/lib/systemd/systemd-journald
_CAP_EFFECTIVE=4402800cf
_SYSTEMD_CGROUP=/system.slice/systemd-journald.service
_SYSTEMD_UNIT=systemd-journald.service
_SYSTEMD_SLICE=system.slice
_SELINUX_CONTEXT=kernel
_MACHINE_ID=1e5c5682191d4edcbdb0ff3725e3fdc1
_HOSTNAME=rhel71.example.com

journaldへのログ送付

journaldへログ出力するにはどうすればいいのでしょうか? 拡張機能を利用しないのであれば、従来のsyslogとおなじように利用できます。

たとえばloggerコマンドを以下のように実行すると

# logger “foobar”

このようなログが保存されます。

__CURSOR=s=ef196eeafe92413cba33aab060cb9029;i=b32;b=58f89813972d401ba3591da7067616a3;m=222d7fb47;t=51afad079c589;x=b44e2b3141f0b6eb
__REALTIME_TIMESTAMP=1437039425340809
__MONOTONIC_TIMESTAMP=9174514503
_BOOT_ID=58f89813972d401ba3591da7067616a3
_UID=0
_GID=0
_MACHINE_ID=1e5c5682191d4edcbdb0ff3725e3fdc1
_HOSTNAME=rhel71.example.com
PRIORITY=5
_TRANSPORT=syslog
SYSLOG_FACILITY=1
SYSLOG_IDENTIFIER=root
MESSAGE=foobar
_PID=18822
_SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
_SOURCE_REALTIME_TIMESTAMP=1437039425340049

アプリケーション用には、標準でCとPython用のライブラリが用意されています。systemd作者のLennertのblogに開発者むけの利用例が記載されています。

関連資料

systemdはmanページが非常に充実しています。

    man systemd-journald.service

    man systemd.journal-fields

    systemd作者のblogにも解説があり参考になります http://0pointer.de/blog/projects/journalctl.html

早くからsystemdを採用していたArch Linuxのwikiには利用に関するhowtoの知識が蓄積されています。

    https://wiki.archlinuxjp.org/index.php/Systemd

 

小ネタ

ページャで行を折り返したい

journalctlで表示をするときに、デフォルトでは行を折り返さずに長い行は横スクロールで読むように設定されています。lessのデフォルトと異なっているのでおどろく方もいるかと思います。

環境変数 SYSTEMD_LESS にページャへのオプションを指定することで折り返しの表示にすることができます。lessの行折り返しをしないオプションは-Sですので、デフォルトの”FRXSMK”からSをのぞいて以下のようにオプションを指定します。

export SYSTEMD_LESS=FRXMK

もろもろの事情で環境変数の設定がむずかしい場合、journalctl -b | less のようにパイプで接続することでオプションなしのlessが利用できます。

tailf /var/log/messages のような監視がしたい

tailfに近い動作をする「journalctl -f」として出力をリアルタイムで継続的に監視できます。この時もフィルタを利用できるので、tailとgrepを利用するよりも便利なケースも多いはず。

シェルでいろいろ属性がついたログ出力をしたい

Fedora 22に含まれているutil-linux ではloggerコマンドに–journald オプションが追加されており、journaldが処理できる各種の属性を付加したログ出力が可能になっています。RHEL7.1で確認したところまだ対応していないので、はやくRHELのutil-linuxも対応するといいですね。

Red Hatテクニカルサポートのつかいかた

Red Hatの製品には問いあわせ回数無制限(!!)のサポートが含まれています。しかし実際には「RHELは利用しているけどサポートにといあわせたことはないよ」という方も多くいるかと思います。今回はレッドハットのサポート利用方法についてご紹介していきます。

レッドハットの森若です。今回はレッドハットの製品サポートについてご紹介します。

テクニカルサポートへの問い合わせ窓口

まず、レッドハットのテクニカルサポートの問いあわせ窓口はどこでしょうか?

レッドハットでは、電話とWebで問い合わせ窓口を用意しています。

電話: 0120-266-668

英語での電話: 0120-655-103

Web: https://access.redhat.com/support/cases/

カスタマーポータル(https://access.redhat.com/ 以下スクリーンショット)の「サポートケースを管理」からサポートケースの一覧を確認したり、「サポートケースを作成」から新規に問い合わせをおこなうことができます。カスタマーポータルのアカウントでログインの上おといあわせください。

 

もしも「質問したいけどカスタマーポータルのアカウントやパスワードがわからない!」という場合には、カスタマーサービスでご対応いたします。 0120-266-668 (オプション 2) までお電話いただくか、customerservice-jp@redhat.com までメールでお問いあわせください。

 

ケースを登録する

「サポートケースを作成」リンクを押すと新規にサポートケースを作成する画面がでてきます。ここに、製品名やバージョン、質問内容を記述することで問いあわせをおこないます。

サポートレベルは24×365のプレミアムか、9時〜17時平日のスタンダードを選択します。該当する製品のサポートレベルをご記載ください。

 

 

重大度とは?

サポートケースを作成するとき「重大度」を設定します。これはたくさんのお客様から同時にお問いあわせをうける中で、どのケースを優先するべきかを決めるために利用されます。

基本的に本番環境での利用で、お客様の業務にインパクトがあり、回避策がないものが高い重大度となります。逆に開発中の問題や、回避策を用いてなんとか業務を継続できるような場合には重大度が低くなります。通常は4で、特別に深刻な場合に重大度をあげて利用します。

  • 重大度1 (緊急) プロダクション用途において、業務を停止せざるを得ない状況で、回避策がない。

  • 重大度2 (高) プロダクション用途において、業務の一部に深刻な影響を与える状況で、回避策がない。

  • 重大度3 (中) プロダクション用途におい て、お客様のビジネスに中から低程度の影響があるが、回避策があり、業務は続けられる場合。 開発用途において、プロジェクトを続行できない、またはプロダクションに移ることのできない状態。

  • 重大度4 (低)  一般的な使用に関する質問、文書エラーの報告、将来の製品改善または修正の推奨。

たとえば「明日ローンチするサイトのテストをしていたらシステムが応答しなくなった!」というような場合、もちろんこの問題はお客様にとって重大な問題なのですが、ここでは重大度は3になります。

重大度はサポート対応のSLAに直結します。24時間対応の対象となるのは重大度1および2 のケースです。重大度1, 2のケースを営業時間外に登録された場合は、初動を早くするためお電話にてご一報ください。

重大度の正式な定義はこちらをご確認ください。 https://access.redhat.com/ja/support/policy/severity

 

サポートにどんな問いあわせができるの?

基本的には製品の使いかたや、発生した問題とその回避策、製品の修正についてのお問いあわせに対応いたします。その他にもドキュメントの問題の指摘や、品質保証チームへのテストケースのご提案もうけつけております。

一方対応できないものとしては、コード開発、システムの設計、セキュリティポリシーを策定すること、既知の修正内容や製品に含まれるプログラムの解説などは範囲に含まれません。

たとえばRHELにはOpenJDKのサポートが含まれています。これを例にしてサポート可否をみてみましょう。

「OpenJDKでヒープメモリ4GBに設定したいんだけどどうしたらいいの?」「今までのバージョンでは動作していたプログラムをOpenJDKの新しいパッケージで起動したらJDKごとクラッシュするようになったのでOpenJDKの問題じゃない? 」というようなお問いあわせはサポート対象になります。

しかし「OpenJDK上で動作するプログラムを作っているけどNullPointerExceptionがでてこまるので助けて」というような場合はコード開発にあたりサポート対象にはなりません。

正式な定義はこちらをご確認ください。https://access.redhat.com/ja/support/offerings/production/soc

サポートされるパッケージとサポートされないパッケージ

「Red Hat Enterprise Linux」を購入すると入手・利用できるパッケージは多数ありますが、この全てがサポート対象になるわけではありません。サポート範囲の定義のページに記載がありますが「コア機能」と呼ばれるものがサポートの対象になります。たとえばfirefoxはコア機能ですが、firefoxを動作させるために必要となる多くのライブラリはコア機能ではありません。

あるパッケージがコア機能に含まれるかはRHELドキュメント中の「Package Manifest」というドキュメントに記載されています。どのパッケージがコア機能になるかはサーバ版やデスクトップ版といった版によっても変わります。たとえばLibreOfficeはサーバ版ではコア機能ではありませんが、ワークステーションではコア機能としてサポート対象になります。

また「Optional」および「Supplementary」とされているリポジトリ(またはチャネル)経由で配られている追加のソフトウェア群があります。これらはデフォルトでは利用できず、リポジトリを有効にすることで利用できるようになりますがサポート対象とはなりません。

問い合わせ対応をスムーズにするsosreport

テクニカルサポートへの問いあわせをおこなう場合、多くのお客様がログや画面出力から自分が気になった部分を送ってくださるのですが、それだけでは何とも言えないケースが多くあります。一口にRHELといっても様々なバージョンや設定・構成があり、同じような問題にも複数の原因が考えられることが理由のひとつです。多くのケースでは問題を絞り込むためにお客様の環境を把握することが必要で、お客様へ各種の情報収集をお願いすることになります。

トラブルシュート時に典型的に必要な情報はわかっていますので、レッドハットではこの情報収集を sosreport とよばれるソフトウェアで自動化しています。sosパッケージをRHELにインストールし、root権限でsosreportコマンドを実行することで、各種の設定やログを収集したアーカイブを作成してくれます。このアーカイブをあらかじめサポートケースに添付していただくことで、スムーズな対応が可能になります。

sosreport実行例:
[root@rhel7 ~]# sosreport
sosreport (version 3.2)

This command will collect diagnostic and configuration information from
this Red Hat Enterprise Linux system and installed applications.

An archive containing the collected information will be generated in
/var/tmp and may be provided to a Red Hat support representative.

Any information provided to Red Hat will be treated in accordance with
the published support policies at:

  https://access.redhat.com/support/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.

No changes will be made to system configuration.

Press ENTER to continue, or CTRL-C to quit.

Please enter your first initial and last name [rhel7.example.com]:
Please enter the case id that you are generating this report for:

 Setting up archive ...
 Setting up plugins ...
 Running plugins. Please wait ...

  Running 10/86: cluster...       

sosreportについて詳しくは以下のナレッジベースをごらんください。

https://access.redhat.com/ja/solutions/78443

参考情報

レッドハットの製品サポートについての各種ポリシーを以下でご案内しています。

https://access.redhat.com/support/offerings/production/

Red Hat Enterprise Linux のサポートポリシーについてよく利用されるナレッジ