Automation_tech_casual_talks_1_puppet

LAMP環境をPuppet化してみて2012/07/17Automation Tech Casual Talks #1Twitter:@ume3_

要点● サーバ構成の自動化のお話 ○ 主にPuppet ○ インフラ側でやる構成管理● DevOps● AWS

構成管理とは ● バージョン管理 ● 依存関係の管理 ● ソフトウェアの管理構成管理とはプロジェクトに関連するあらゆる成果物とそれらの間にある関係性が、保存され、検索され、一意に特定され、修正されるプロセスのことである。（p.69）[1][1]：継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化　　出版社: アスキー・メディアワークス

わたし● Ops ○ AWSなプロジェクトに顔出すインフラ屋● 今日はプロジェクトAのサーバ構成自動化のお話がメイン ○ インフラはわたし一人で管理※　わたし：http://twitter.com/ume3_※　DevOps ： http://en.wikipedia.org/wiki/DevOps

プロジェクトAとは● 既存システムを踏襲しつつAWS化し、かつ、別システムとして再利用するプロジェクト(!?)● 現行踏襲をベースとした構成管理 ○ LAMP環境（Apache＋PHP） ○ 枯れたシステム ○ 自動化への課題 ■ 一部、Puppet化(Version:0.24.8)上記、条件を踏まえた上でPuppetによるサーバの構成管理を実施した

図）プロジェクトAのサーバ構成

自動化する要素（本番環境）● AWS ○ EC2● Cloud-init ○ EC2に適用するKickstartのようなものとして使用 ○ userdataとして定義。実体はシェルスクリプト● Puppet (Version:2.7.9)＋Passenger ○ Roleごとに必要なマニフェストを用意 ○ GitHub(Private Repository)でバージョン管理※　Role : 役割※　Puppet+Passenger： http://rh7.hateblo.jp/entry/20110224/1298564977

自動化する要素（開発環境）● Maglica ○ 社内インターナルクラウドツール ○ PuppetとOSイメージのVMを使ってベースを作成 ○ 開発者(Dev)は適用後のVMを個別コピーして使用● 起動スクリプト ○ 前述のCloud-initの内容を元に適用 ○ ホスト名割り当てなど● Puppet ○ 本場環境と同様。 ○ Puppetサーバは本番環境とは別に用意※　Maglica ：： https://github.com/mizzy/maglica

サーバ構成を自動化する前に● 既存構成をベースに、Puppetで一人もくもくとサーバ構成を管理していたが... ○ Ops側だけで構成管理を設計するには限界がある ○ Dev側と構成管理についてきちんと設計した上で、自動化について考える必要がある● 今回は既存踏襲なので、依存関係やソフトウェア管理を考える必要があった→話し合い

Devとの構成管理雑談Dev ● 既存踏襲があると楽だなー。Ops側で大変なら、整理していいよ。こちらのソースもあわせるし。開発環境はVMをコピーして自由につくれるのはいいね。設定箇所はきっちりわけすぎるとお見合いの発生やとりこぼしがあるから、共通でわかっている部分は意識・遊びが必要かな。 php.iniとか、Apacheの一部パラメータとか。ログの保存先決めたいね。PEARの呼び出しとか curlの呼び出しの実行PATHとか。cronとか。Ops ちゃんと構成管理した上で自動化してー！

開発環境でのDevとOpsの住み分け Dev Ops ● サーバは構築・管 ● VM管理して！理してほしい ● Puppetでデフォル ● ソフトのバージョントのphp.iniは管理管理お願いするよ ● php.iniの管理はし ● 自作SSL証明書用たい。いじりたい。意するよ ● ApacheのVirtual ● Apacheの HostsでRoleを個 VirtualHostsは上別管理したい書きしないDevとOpsがお互いに話し合いをして接点を探ることが大事 →Puppetのマニフェストやコミット時のログに記録する

Automatin Tech Casual Agenda● ローンチ● サーバ構成● EC2のAMI管理はやっていた→やめた● userdata適用後のAMIを管理にするには● 既存踏襲と構成管理● 開発環境と本番環境の分岐● PHPの扱い● PEALとPECLはModule化● PuppetのModuleはGitHubで探す● 展望

ローンチ● できる限り自動化● 例：本場環境（AWS） ○ Cloud-initでホスト名を指定してAMIを読み込みPuppetをインストール。その後、各Roleにあわせてマニフェストを適用するとAWS上にサーバができあがる % ec2-run-instances ami-xxx -t t1.micro -- availability-zone=ap-northeast-1a -f /tmp/cloudinit/role001.hoge.com.ini -g base -g role_a -k hoge- key※　AMI：http://aws.amazon.com/jp/amazon-linux-ami/※　Cloud-init ： https://help.ubuntu.com/community/CloudInit

サーバ構成● たくさんのRoleが存在する ○ Web、メール、画像、ストレージ、DB、etc ...● Puppetで各Roleを階層管理例：Puppetのmanifestフォルダより % ls -1 base % ls -1 www db apache % ls -1 www/apache dev config.pp config.pp img init.pp init.pp mail memcached.pp install.pp storage mysql.pp service.pp www nfs.pp user.pp php

EC2のAMI管理はやっていた→やめた● 共通箇所をCloud-initで導入後、AMI管理● AMI→カスタマイズ→複数のAMIを管理 ○ AMI001 ... postfixをデフォルトでインストール ○ AMI002 ... qmailをソースから導入（既存踏襲） ○ etc● 既存踏襲の構成を見直してから自動化を考えるべきだ、に落ち着く● 共通箇所はPuppetで管理 ○ AMIはオリジナルだけ ○ 開発環境も同様の構成で管理できる ○ 共通箇所＋Roleごとにマニフェストを適用

userdata適用後のAMIを管理するには● userdataは一度適用すると書き換えは不可能といわれているが、できる % sudo rm -f /var/lib/cloud/sem/* #再起動で無効● 起動後のログ % /var/log/cloud-init.log % /var/lib/cloud/data/scripts/part-000● 本体 % rpm -qf /usr/bin/run-parts % crontabs-1.10-32.1.8.amzn1.noarch

既存踏襲と構成管理● 基本的には踏襲するとまずい構成は引き継がないでPuppetで一新 ○ Dev負担(コード依存)でもOpsとしてゆずれないことも例）Apache Role : バージョン, パッケージ, ログ保存先 RoleA : Apache2.2.x, RPM, /usr/local/apach2/logs RoleB : Apache2.2.y, RPM, /var/log/httpd RoleC : Apache2.0.z, ソース, /usr/local/aapche1/logsこんな状態を構成管理して自動化とかしないこと

本番環境と開発環境の分岐● PuppetのEnvironmentsを利用 ○ 本番環境：production(デフォルト） ○ 開発環境：development● puppet.confで定義 ○ 定義時の分岐はホスト名を利用。 ○ hoge.comであれば本番。hoge.devなら開発など # puppet.conf [agent] environment = development※　Docs: Environments ：http://docs.puppetlabs.com/guides/environment.html

PHPの扱い● Devの強い要望 ○ PHPは5.x.yのyまで管理したい ○ 本番では、Roleごとにバージョンアップを気にしたい● 解決策 ○ 自作のRPMパッケージを自作Yumリポジトリで管理 ○ PuppetでRoleごとにPHPを管理● マニフェスト # role_a/php/install.pp より class role_a::php::install ( $php_package = php-5.3.10.role_a, ){ package { php: name => $php_package, } }

PEARとPECLはModule化# modules/pear を使って　 manifests/role_a/php/init.pp　を定義した例 class role_a::php { include pear::role } class pear::role_a { ## module pear::module { XML_RPC: # define } }● defineを使用しているので、dry-run時にエラーが出るという残念仕様→tarで固めて展開するという手もある(exec)

PuppetのModuleはGitHubで探す● 再利用が基本(fork)● puppet module installはあまり使わない● 環境依存しやすい ○ OS分岐(prams.ppでよくある) ○ FacterのVersion気にする仕様もある# やりすぎな例 ... facterによるOS分岐name => $operatingsystem ? {　Linux => "php-pecl-${name}",　Scientific => "php-pecl-${name}",　default => "pear-${name}",},

展望● PuppetのExternal Nodeは使いたい ○ nodes.ppの管理は自動化すべき● ローンチはもっと自動化できる● PuppetのDeployはWebistrano使いたい ○ Funcでrsyncしているだけなので● Puppetで管理しているDevな箇所はカジュアルにDevに操作してもらいたい ○ GitHubでpull requestをもらう仕組み作り● 参考：@lamanotrama

結論● 構成管理を自動化すると開発者(Dev)と運用者(Ops)のよりよい関係が築ける● システム設計が甘いと自動化も構成そのものも破綻するので将来性を常に気にすること

おわりご静聴ありがとうございました

http://blog.livedoor.jp	3523
http://spring-mt.tumblr.com	1103
http://webcache.googleusercontent.com	8
http://getpocket.com	6
http://localhost	1
http://s.deeeki.com	1
http://cache.yahoofs.jp	1

Automation_tech_casual_talks_1_puppet

by ume3_ on Jul 17, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 4,643

Statistics

Automation_tech_casual_talks_1_puppet Presentation Transcript