検索
連載

GitやDockerと連携するPuppet運用テクニック、filebucketによる自動バックアップ、GUIのPuppet Dashboard：新人インフラ技術者のためのサーバー構築／運用自動化入門（終）（2/2 ページ）

サーバー構築の自動化で利用される技術、自動化ツールとして「Kickstart」「Puppet」を紹介し、構築から運用まで、システムライフサイクル全体にわたる運用管理の自動化についても解説する連載。今回は、filebucketによる自動バックアップやGitやDockerと連携する運用テクニック、GUIのPuppet Dashboardなどを紹介する。

Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

マニフェストの変更管理――Gitを使ったバージョン管理

R子　マニフェストに不具合があったので、filebucketで取り出したファイルをサーバーにコピーしても勝手に元に戻っちゃいます（＞＜）。

K男　Puppetは定期的にマニフェストで定義された状態に戻そうとするからね。ファイルをサーバーに上書きコピーしても駄目だよ。

R子　どーしたらいいですか？

K男　そんなときは、マニフェストのバージョン管理をきちんと行って、不具合があったらマニフェストを元の状態に戻せるようにすることだね。


　先ほど、filebucketを利用すれば、バックアップしたファイルを取り出せることを紹介しました。しかしながら、マニフェスト適用時に不具合が発生した場合、バックアップファイルを取り出しただけでは、すぐに修正できるわけではありません。例えば、不具合が発生する前のファイルをfilebucketで取り出してサーバーに配置すると、Puppet Master上のマニフェストと異なる状態になるため、時間が経つとPuppetにより元の不具合がある状態にファイルが戻されてしまいます。

　根本的な解決を行うには、マニフェストの修正が必要となります。Gitなどのバージョン管理システムでマニフェストを管理しておくと、不具合が発生する前の状態にマニフェストを簡単に戻すことができるようになります。

　また、filebucketでは変更があった理由まで記録できませんが、バージョン管理システムを利用すれば、環境変更があった理由をコメントとして残すことができ、変更の理由を確認しやすくなります。

　具体的な利用構成例を図2に示します。ここでは、運用環境と試験環境が分かれたケースで紹介していますが、問題があったときに元に戻せるという点で、一環境しかない場合でもバージョン管理は有効です。


図2　Gitによるマニフェスト管理のイメージ

　図では、Puppet Masterを構成管理サーバーと表記していますが、この考え方自身はChefなどの他の構成管理ツールでも利用できるので、構成管理サーバーと記載しています。

　では、実際にどのような流れになるか見ていきましょう。

【1】マニフェストの作成・試験

　まず、試験環境の構成管理サーバー上では、マニフェストの作成・変更と試験を行います。試験時のマニフェストは、試験環境にある構成管理サーバー上のローカルリポジトリでバージョン管理を行っておきます。そうすると、試験が失敗したときに、ローカルリポジトリに保存した以前の状態にすぐに戻せるようになります。

【2】マスターリポジトリへのマニフェストの登録

　試験が終わったら、マスターリポジトリへ編集内容を反映（プッシュ）します。

【3】運用環境へのマニフェストの反映

　運用環境の構成管理サーバーでは、マスターリポジトリを定期的に監視しておき、マスターリポジトリに変更があると、差分を取り込みます（プル）。これで、試験済みのマニフェストを運用環境のサーバーに適用できます。

　運用環境へマニフェストを反映するときは注意が必要です。かなり低い確率ではありますが、マスターリポジトリの変更を構成管理サーバーが反映している途中で構成変更が実行されると、変更前と変更後のマニフェストが混ざった状態で各サーバーに変更が適用される可能性があります。

　そのため、変更を反映する際には、構成管理サーバー（puppet master）をいったん停止してからマスターリポジトリの反映を行うのが安全です。

　また、運用環境へ反映する際には、タグを利用することで、本番環境に適用したマニフェストを管理できます。例えば、「REL20150213」などの日付のタグを付けて管理するとよいでしょう。タグを付けることにより、タグとタグの間のファイルの差分を確認することにより、前回の環境変更から何が変更されたか分かりやすく管理できます。

マニフェスト開発の強い味方――Dockerでマニフェスト開発

R子　そういえば「強い味方があるんだよ」って言ってましたよね？

K男　ん？ バックアップしたVMの復元に時間がかかって大変だって話だっけ？

R子　そうです！ それです！ イジワルしないで教えてくださいよぉ〜。

K男　分かった、分かった。


　マニフェスト開発に専用の環境を用意できれば申し分ないですが、一般的には個人PC上でVMを使って初期開発してから試験環境に持っていき、試験しながら仕上げをするケースが多いと思います。

　また、マニフェストを適用すると環境を汚してしまうため、クリーンな環境からの構築試験を繰り返し実施するために、VMイメージをバックアップしておいて、試験のたびにコピーし直す方も多いでしょう。

　この方法は確かに便利ですが、VMイメージ保管のために多くのハードディスク容量を必要とすることと、イメージを戻すのに多少の時間がかかることが欠点です。また複数のVMを立ち上げて開発する場合は、相当量のメモリを必要としますし、動作も重くなりがちでしょう。

　そのようなときは、Linux環境限定ですがコンテナー技術の「Docker」をマニフェスト開発環境として使うと、以下のようなさまざまなメリットがあります。


図3　VMとDockerの比較
  1. どんなに環境を汚しても、コンテナーを起動し直すだけでクリーンな環境に戻せる
  2. VMを使う場合に比べて少ないリソースで動作するため、複数コンテナーを同時起動してもサクサク動作する
  3. コンテナーのイメージが小さいためハードディスク容量を圧迫しない

　「--noop」オプションでマニフェストのドライランができますが、実際にマニフェストを適用してみないと出てこない問題もたくさんありますし、気軽にトライ＆エラーができるようになりますので、マニフェスト開発における1.のメリットはとても大きなものです。

　実際に運用するシステムのサーバー数が多い場合、試験環境をコンテナで作れば集約率を上げることができるので、2.も大きなメリットになるでしょう。

　3.についてはVMイメージに比べて10分の1くらいのサイズまで抑えられますので、「さまざまな環境を常備しておかないとならない」という用途には大きなメリットになります。

　うまく応用することで、開発環境のみならず本番環境などの構築時に可搬型のPuppet masterとして運用することもできるでしょう。他のシチュエーションにもさまざまな応用が利くと思います。

DockerでPuppetを利用するには

　DockerでPuppetを利用するには、三つの方法があります。

  1. 通常のPuppetの利用方法と同じように、CentOSなどのOSをインストールしたコンテナーを起動し、そのコンテナーにPuppetをインストールする
  2. Dockerコンテナーを定義するDockerfileにPuppetのインストール手順を記載しておき、コンテナーをビルドしてPuppetがインストールされたイメージを作成
  3. さまざまなDockerイメージが登録されている「Docker Hub」からPuppetをインストール済みのイメージを探して利用

　上記の中で、3.の方法がイメージを探して利用するだけなので一番楽ですが、Docker Hubで提供されているコンテナーは、タイムゾーンが日本のタイムゾーンに設定されていなかったり、Puppetのバージョンが古かったりします。

　また、Dockerでは基本IPアドレスが勝手に割り振られるので、agentに指定するmasterのIPアドレスをagentのコンテナを起動する都度指定する必要があります。

　ここからは、タイムゾーンとIPアドレスの問題を解決できる2.の方法を利用したPuppetがインストールされたイメージの作成方法を紹介します。


図4　Dockerを使った開発環境の例

　筆者の開発環境のDockerfileは以下のようなものです。

FROM centos:centos6
MAINTAINER Ryo Sugahara
 
# change timezone to Asia/Tokyo
RUN echo "ZONE=\"Asia/Tokyo\"" > /etc/sysconfig/clock
RUN rm -f /etc/localtime
RUN ln -fs /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
 
# install puppet server
RUN rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm
RUN yum install -y puppet-server
RUN echo "*" > /etc/puppet/autosign.conf
 
# Entrypoint
CMD echo '#' > /etc/resolv.conf ; /sbin/service puppetmaster start ; puppet apply -e 'file{"/host_files/hosts": content=>"${ipaddress_eth0} puppet\n", ensure=>present,}' ; /bin/bash
master側
FROM centos:centos6
MAINTAINER Ryo Sugahara
 
# change timezone to Asia/Tokyo
RUN echo "ZONE=\"Asia/Tokyo\"" > /etc/sysconfig/clock
RUN rm -f /etc/localtime
RUN ln -fs /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
 
# install puppet
RUN rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm
RUN yum install -y puppet
 
# Entrypoint
CMD cat /host_files/hosts >> /etc/hosts ; /bin/bash
agent側

　筆者は公式のCentOS 6イメージを利用して開発環境のイメージを構築しています。またagent側からmaster側に「puppet」というホスト名でアクセス可能になるように、ホスト側のディレクトリをバインドマウントしてmaster側のアドレス情報を共有する仕掛けにしています。

　Dockerfileからコンテナーを作成するには、Dockerfileをそれぞれ別のディレクトリに配置して、Dockerfileを配置したディレクトリで次のように実行します。

# docker build -t sugaharar/puppet:master .
master用のコンテナー
# docker build -t sugaharar/puppet:agent .
agent用のコンテナー

　Dockerイメージの作り方についての詳細は、記事「Dockerfileとdocker buildコマンドでDockerイメージの作成」をご覧ください。

　コンテナーを起動するには、以下のようなコマンドを使います。

# docker run -i -t -h puppet -v ~/container_files:/host_files --rm sugaharar/puppet:master
master側
# docker run -i -t -v /root/container_files:/host_files --rm sugaharar/puppet:agent
agent側

　なお、起動し直せばクリーンな環境に戻せるメリットの裏返しで、起動し直すとマニフェストも消えてしまいますので、バインドしているディレクトリにコピーする、後述するGitサーバーにpushするなどの手段で、作成済みのマニフェストを退避することを忘れないように気を付けましょう。

運用は続くよ。どこまでも――Puppet Dashboard

K男　R子さん、一人でも大抵のことはできるようになったね。

R子　はい！ K男さんのおかげです！（喜）

K男　まだ教えてないけど、Puppetにはパラメーターを管理するのに使える「Hiera」という仕組みがあるんだよ。これを使うと、すごく便利な「Roles／Profilesデザインパターン」というマニフェストの書き方があるんだ。

R子　私、ちょうどクラスへパラメーターをどうやって渡すのか勉強していたところなんですよ〜。

K男　さらにGUIの「Puppet Dashboard」というのを使うとマニフェストを書かなくてもクラスを適用できるんだよ。

R子　えっ！？ それ、すご〜い！！ ぜひ教えてください！（願）

K男　残念だけど、今回はここまで。またの機会にね。

R子　そ、そんなぁ（泣）。


　最後にK男さんが話した「Puppet Dashboard」を紹介します。以下のようなWeb画面でリポート分析、インベントリ情報の閲覧、ノードに対するクラスの適用といった操作ができる便利なものです。Puppetの商用プロダクトである「Puppet Enterprise」は、このPuppet Dashboardをベースに拡張しています。


図5　Puppet Dashboard画面

　Puppet Dashboardについての詳細は「Puppet Dashboard Documentation - Documentation - Puppet Labs」を参照してください。

　また「Roles／Profilesデザインパターン」について「Designing Puppet - Roles and Profiles. - - Craig Dunn's Blog」（英文）に説明があるので、興味があれば参照してみてください。

　それでは、またの機会にお会いしましょう。

「新人インフラ技術者のためのサーバー構築／運用自動化入門」バックナンバー

著者プロフィール

菅原亮（すがはら　りょう）

所属：NTT OSSセンタ シニア・エキスパート

1973年生まれ。10歳の時にプログラミングに目覚める。

1994年にFM-TOWNS上でLinuxを使い始めて以来、仕事趣味問わずOSSシステムを構築するようになる。

2012年よりOSSシステムの構築自動化に取り組み始め、昔の苦労を懐かしみつつ自動化の普及促進に取り組んでいる。

個人ではNTSyslog日本語対応版など主にWindows用アプリを手掛ける。趣味は家庭菜園と料理の手動構築で愛車はシルビア。


著者プロフィール

岡本 隆史（おかもと　たかし）

所属：NTT OSSセンタ シニア・エキスパート

「楽をすること」に興味があり、単純作業はスクリプト・マクロなどでできるだけ自動化するようにしている。しかしながら、楽をするためにツールを作成する苦労も伴い、苦労が実っているどうかは定かではない。

楽をする仕組みを共有することこそ、その本質だと気付き、環境構築の自動化ツールの社内外への展開を行っている。


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る