ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

Puppetの使用方法 ーインフラ、設定、フェイルオーバー、配備

当社ではここ数年間Server Densityのインフラを管理するためにPuppetを使用してきました。それにより、いろいろな利点があり、標準設定管理として使用しています。実際には自社での使用は約25%程度です。

当社では主にインフラ、設定、フェイルオーバー、配備の4つの分野でPuppetを使用しています。ここではそれぞれの分野について説明させて頂きます。まずはインフラでのPuppetの使用方法です。

Puppetの使用方法 ーインフラ

当社は自社の環境をSoftlayerに移管した時にPuppetを使用し始めました。この環境ではメタルサーバーやパブリッククラウドインスタンスなどが混在しておりその数は約75-100あります。このように設定された際には、Softlayerからサーバーを調達して、自社のマニフェストを適用して設定を行う前にマニュアルでPuppetをインストールしました。

当社は最近、共同の場所のデーターセンター内の自社の運用環境の移行を検討し、 自社の環境をSoftlayerからGoogle Cloudに移行することを決定しました。私自身の見解としては長期的に見れば、共同の場所のデーターセンターの方がかなりコストが低いはずですが、 初期投資にかかる費用を抑えたいと思いました。また、BigQueryのようなGoogleの製品を利用したいと思いました。

私はこの点について、今後移行を完了するにあたり、更に詳細に述べていきます。また私は– 6月19日にBay Area 及び 7月2日ロンドンで 発表もさせて頂きます。

Google Cloud (特に, Google Compute Engine)か他の主要などのクラウドのプロバイダーを使用する場合には、自社のコードのリソースを定義するためにPuppetのモジュールを使用できます。コントロールパネルからマニュアルでオーダーをするのではなく、Puppetのマニフェストの中で設定と共に定義できます。当社ではgce computeモジュール を使用していますが、Amazon や他のモジュールもあります。

例えば、F 200GB のボリュームのインスタンスを定義する場合、


gce_instance { 'mms-app1':
ensure         => present,
machine_type   => 'n1-highmem-2',
zone           => 'us-central1-a',
network        => 'private',
tags           => ['mms-app', 'mongodb'],
image          => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140605',
}

gce_disk { 'mms-app1-var-lib-mongodb':
ensure      => present,
description => 'mms-app1:/var/lib/mongodb',
size_gb     => '200',
zone        => 'us-central1-a',
}

ここで重要なのは、当社がコード内でインスタンスとそれらの上で稼働している設定を定義することができ、Puppetにその作業をさせるということです。

Puppetの使用方法 ー 設定管理

これはPuppetのオリジナルのユースケースです。– それは単一の場所で自社のサーバーにインストールしたすべてを定義できます。そのため、新規のサーバーを配備しやすく、すべて一貫性があります。

またこれは異常な変化、修正や微調整が完全にバージョンで制御、ドキュメント化されていて、時間が経過しても失うことはないことを意味します。例えば、時間をかけてまたは様々なサポートの要望で積み重なってきた問題を回避したり、最適化するために多岐にわたる MongoDBの修正が出てきますが、これはすべてPuppetでドキュメント化されています。

当社ではPuppet Labsが推奨する標準のモジュールレイアウトを使用しています。これは, Github レポの中に含まれて、コミットする前にpuppet lintでチェックされます。そのため、設定についての記述されたきっちり構築されたライブラリーができています。変更については、通常のコードのリビューのプロセスを経ており、Puppet Masterを配備により、変更点をすべて吸い上げてくれます。

以前はすべてを記述するために自社で独自のカスタムモジュールを書いていましたが、今ではPuppet Forgeのモジュールをできるだけ使用しています。それはPuppet Forgeがより多くのオプションをサポートしていて、自社のカスタムモジュールよりも標準化されているためです。例えば、, MongoDBのモジュール はサーバーとクライアントのインストール、オプションの設定、レプリカの設定のなどを可能にしてくれます。


include site::mongodb_org

class {'::mongodb::server':
ensure    => present,
bind_ip   => '',
replset   => 'mms-app',
}

mount {'/var/lib/mongodb':
ensure  => mounted,
atboot  => true,
device  => '/dev/sdb',
fstype  => 'ext4',
options => 'defaults,noatime',
require => Class['::mongodb::server'],
}

mongodb_replset { 'mms-app':
ensure  => present,
members => ['mms-app1:27017', 'mms-app2:27017', 'mms-app3:27017']
}

当社では同じバージョンを常にインストールされることを確認するために特定のパッケージのバージョンを固定し、アップグレードを管理することができます。これはデータベースなどの重要なパッケージの突然のアップグレードなどを避けるためにも重要です!

Server Density のモニターリングのエージェントもPuppet Forge moduleでは利用することができます。 それにより、自動的にエージェントをインストールしたり、登録したり、独自のアラートも設定できます。

すべてを組合せて、当社の MongoDBバックアップはGoogle Compute Engineの上で稼働しており、, deployed using Puppet を使用して配備され、Server Densityでモニターされていることになります。

mms

Puppetの使用方法 ー フェイルオーバー

当社はロードバランサーとしてNginx を使用しており、 proxyプールのメンバーをリスト化するためPuppetの変数を使用しています。これはPuppet Forge nginxモジュールを使用して、配備されていており、当社はその改善に貢献しています。

ロードバランサーのローテーションからノードを削除する必要がある時には、マニュアルのプロセスで Puppet web UI かAPIを使用して、それが実現できます。 UIは人的なエラーの可能性を最小限に抑えて、変更を適用することができます。  API により一つのノードに障害が発生した場合など特定の条件でフェイルオーバーを自動化することができます。

Puppetの使用方法 ー 配備

これは通常Puppetを使うやり方ではないですが、配備のメカニズムの一部の構築に専念することを手助けしてくれます。この方法では、すでにサーバーで稼働しているPuppet agentを利用します。これにより、カスタムの SSHコマンドを使用したり、独自にエージェントを書いたり、自社の要望に合うためのワークフローをカスタマイズするといったこと必要なくなります。

これは以下のような仕組みです。:

  • コードはGithubの中でマスターにコミットされる。 (通常はプルリクエストを合わせることですが、これは自社のコードリビューするやり方です。).
  • テストを行うBuildbot によって新しいビルドが引き起こされ、ビルドのアーチファクトを作成する。 – 必要最低限のコードが実際にプロダクションサーバーにコピーされる。
  • 社内のコントールパネル内の配備のボタンを押して、どのサーバーに配備されるか(枝分かれした配備も可能)選択して、実際に配備されるものを反映して内部のバージョン番号がアップデートされる。
  • /opt/puppet/bin/mco puppetd runonce -Iが特定のホストによって引き起こされ、Puppet が配備されたバージョンがリクエストされたバージョンと違うことを通知する。
  • 新規のビルドがサーバーにコピーされる。

buildbot

ステータスのメッセージがこのプロセスの期間中 Hipchatにポスティングされ、どのエンジニアもいつでもコードを配備できます。しかしながら、当社ではウイークデーの5時以降と金曜日の3時以降重要ではない変更を行わないことをルール化しています。

このためにPuppetの使用により不利な点もいくつかあります。 まず初めにPuppet エージェントは低いスペックのハードではかなり遅いことです。当社の世界中のリモート監視のノードは一般的に低電力のノードであるために、エージェントは非常にゆっくり実行されます。また最終的には配備は必ずしも同時に起きず、配備するコードにそのことを頭に入れておく必要がるので、一貫性があります。

Puppetがほとんどのドキュメンテーション

これら4つのユースケースは当社のインフラの設定とほとんどがテキストファイルに含まれることを意味します。これにより以下のようないくつかの利点があります。:

  • バージョンが管理されている-誰でも変更点を確認でき、すべてリビュープロセスの一環である。
  • 誰でも見ることができる– もし、どのように機能しているか知りたい場合には、マニフェストを読めばすぐに理解することができる。
  • すべてに一貫性がある– 真実はすべて一つのソースからであり、一つの場所ですべてが定義されている。

それは 当社のすべてのドキュメントではありません。, しかしながら、使用されていてライブの状態にあるので大部分であるということがいえます。皆さんもご存知のように、すべてのドキュメントをアップデートをしておくは嫌なことです!