LAMP環境をPuppet化してみて2012/07/17Automation Tech Casual Talks #1Twitter:@ume3_
要点● サーバ構成の自動化のお話 ○ 主にPuppet ○ インフラ側でやる構成管理● DevOps● AWS
構成管理とは                            ● バージョン管理                            ● 依存関係の管理                            ● ソフトウェアの管理   ...
わたし● Ops  ○ AWSなプロジェクトに顔出すインフラ屋● 今日はプロジェクトAのサーバ構成自動化のお  話がメイン  ○ インフラはわたし一人で管理※ わたし:http://twitter.com/ume3_※ DevOps : htt...
プロジェクトAとは● 既存システムを踏襲しつつAWS化し、かつ、別  システムとして再利用するプロジェクト(!?)● 現行踏襲をベースとした構成管理  ○ LAMP環境(Apache+PHP)  ○ 枯れたシステム  ○ 自動化への課題    ...
図)プロジェクトAのサーバ構成
自動化する要素(本番環境)● AWS  ○ EC2● Cloud-init  ○ EC2に適用するKickstartのようなものとして使用  ○ userdataとして定義。実体はシェルスクリプト● Puppet (Version:2.7.9)...
自動化する要素(開発環境)● Maglica  ○ 社内インターナルクラウドツール  ○ PuppetとOSイメージのVMを使ってベースを作成  ○ 開発者(Dev)は適用後のVMを個別コピーして使用● 起動スクリプト  ○ 前述のCloud-...
サーバ構成を自動化する前に● 既存構成をベースに、Puppetで一人もくもくと  サーバ構成を管理していたが...  ○ Ops側だけで構成管理を設計するには限界がある  ○ Dev側と構成管理についてきちんと設計した上で、自動   化について...
Devとの構成管理雑談Dev   ● 既存踏襲があると楽だなー。Ops側で大変な        ら、整理していいよ。こちらのソースもあわせる        し。開発環境はVMをコピーして自由につくれる        のはいいね。設定箇所はきっち...
開発環境でのDevとOpsの住み分け         Dev                  Ops  ●   サーバは構築・管         ●   VM管理して!      理してほしい           ●   Puppetでデフォ...
Automatin Tech Casual Agenda●   ローンチ●   サーバ構成●   EC2のAMI管理はやっていた→やめた●   userdata適用後のAMIを管理にするには●   既存踏襲と構成管理●   開発環境と本番環境の...
ローンチ● できる限り自動化● 例:本場環境(AWS)  ○ Cloud-initでホスト名を指定してAMIを読み込みPuppetを          インストール。その後、各Roleにあわせてマニフェストを          適用するとAWS...
サーバ構成● たくさんのRoleが存在する  ○ Web、メール、画像、ストレージ、DB、etc ...● Puppetで各Roleを階層管理 例:Puppetのmanifestフォルダより % ls -1 base      % ls -1 ...
EC2のAMI管理はやっていた→やめた● 共通箇所をCloud-initで導入後、AMI管理● AMI→カスタマイズ→複数のAMIを管理 ○ AMI001 ... postfixをデフォルトでインストール ○ AMI002 ... qmailを...
userdata適用後のAMIを管理するには● userdataは一度適用すると書き換えは不可能  といわれているが、できる % sudo rm -f /var/lib/cloud/sem/* #再起動で無効● 起動後のログ % /var/lo...
既存踏襲と構成管理● 基本的には踏襲するとまずい構成は引き継が  ないでPuppetで一新  ○ Dev負担(コード依存)でもOpsとしてゆずれないことも例)Apache Role : バージョン, パッケージ, ログ保存先 RoleA : A...
本番環境と開発環境の分岐● PuppetのEnvironmentsを利用    ○ 本番環境:production(デフォルト)    ○ 開発環境:development● puppet.confで定義    ○ 定義時の分岐はホスト名を利用...
PHPの扱い● Devの強い要望 ○ PHPは5.x.yのyまで管理したい ○ 本番では、Roleごとにバージョンアップを気にしたい● 解決策 ○ 自作のRPMパッケージを自作Yumリポジトリで管理 ○ PuppetでRoleごとにPHPを管理...
PEARとPECLはModule化# modules/pear を使って  manifests/role_a/php/init.pp を定義した例 class role_a::php {   include pear::role } class...
PuppetのModuleはGitHubで探す● 再利用が基本(fork)● puppet module installはあまり使わない● 環境依存しやすい  ○ OS分岐(prams.ppでよくある)  ○ FacterのVersion気にす...
展望● PuppetのExternal Nodeは使いたい  ○ nodes.ppの管理は自動化すべき● ローンチはもっと自動化できる● PuppetのDeployはWebistrano使いたい  ○ Funcでrsyncしているだけなので● ...
結論● 構成管理を自動化すると開発  者(Dev)と運用者(Ops)のより  よい関係が築ける● システム設計が甘いと自動化  も構成そのものも破綻するの  で将来性を常に気にすること
おわりご静聴ありがとうございました
Upcoming SlideShare
Loading in...5
×

Automation_tech_casual_talks_1_puppet

7,270

Published on

Automation Tech Casual Talks #1 http://www.zusaar.com/event/332008

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,270
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Automation_tech_casual_talks_1_puppet

  1. 1. LAMP環境をPuppet化してみて2012/07/17Automation Tech Casual Talks #1Twitter:@ume3_
  2. 2. 要点● サーバ構成の自動化のお話 ○ 主にPuppet ○ インフラ側でやる構成管理● DevOps● AWS
  3. 3. 構成管理とは ● バージョン管理 ● 依存関係の管理 ● ソフトウェアの管理 構成管理とはプロジェクトに 関連するあらゆる成果物とそ れらの間にある関係性が、保 存され、検索され、一意に特 定され、修正されるプロセス のことである。 (p.69)[1][1]:継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化   出版社: アスキー・メディアワークス
  4. 4. わたし● Ops ○ AWSなプロジェクトに顔出すインフラ屋● 今日はプロジェクトAのサーバ構成自動化のお 話がメイン ○ インフラはわたし一人で管理※ わたし:http://twitter.com/ume3_※ DevOps : http://en.wikipedia.org/wiki/DevOps
  5. 5. プロジェクトAとは● 既存システムを踏襲しつつAWS化し、かつ、別 システムとして再利用するプロジェクト(!?)● 現行踏襲をベースとした構成管理 ○ LAMP環境(Apache+PHP) ○ 枯れたシステム ○ 自動化への課題 ■ 一部、Puppet化(Version:0.24.8)上記、条件を踏まえた上でPuppetによるサーバの構成管理を実施した
  6. 6. 図)プロジェクトAのサーバ構成
  7. 7. 自動化する要素(本番環境)● 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
  8. 8. 自動化する要素(開発環境)● Maglica ○ 社内インターナルクラウドツール ○ PuppetとOSイメージのVMを使ってベースを作成 ○ 開発者(Dev)は適用後のVMを個別コピーして使用● 起動スクリプト ○ 前述のCloud-initの内容を元に適用 ○ ホスト名割り当てなど● Puppet ○ 本場環境と同様。 ○ Puppetサーバは本番環境とは別に用意※ Maglica :: https://github.com/mizzy/maglica
  9. 9. サーバ構成を自動化する前に● 既存構成をベースに、Puppetで一人もくもくと サーバ構成を管理していたが... ○ Ops側だけで構成管理を設計するには限界がある ○ Dev側と構成管理についてきちんと設計した上で、自動 化について考える必要がある● 今回は既存踏襲なので、依存関係やソフトウェ ア管理を考える必要があった→話し合い
  10. 10. Devとの構成管理雑談Dev ● 既存踏襲があると楽だなー。Ops側で大変な ら、整理していいよ。こちらのソースもあわせる し。開発環境はVMをコピーして自由につくれる のはいいね。設定箇所はきっちりわけすぎると お見合いの発生やとりこぼしがあるから、共通 でわかっている部分は意識・遊びが必要かな。 php.iniとか、Apacheの一部パラメータとか。ログ の保存先決めたいね。PEARの呼び出しとか curlの呼び出しの実行PATHとか。cronとか。Ops ちゃんと構成管理した上で 自動化してー!
  11. 11. 開発環境でのDevとOpsの住み分け Dev Ops ● サーバは構築・管 ● VM管理して! 理してほしい ● Puppetでデフォル ● ソフトのバージョン トのphp.iniは管理 管理お願い するよ ● php.iniの管理はし ● 自作SSL証明書用 たい。いじりたい。 意するよ ● ApacheのVirtual ● Apacheの HostsでRoleを個 VirtualHostsは上 別管理したい 書きしないDevとOpsがお互いに話し合いをして接点を探ることが大事 →Puppetのマニフェストやコミット時のログに記録する
  12. 12. Automatin Tech Casual Agenda● ローンチ● サーバ構成● EC2のAMI管理はやっていた→やめた● userdata適用後のAMIを管理にするには● 既存踏襲と構成管理● 開発環境と本番環境の分岐● PHPの扱い● PEALとPECLはModule化● PuppetのModuleはGitHubで探す● 展望
  13. 13. ローンチ● できる限り自動化● 例:本場環境(AWS) ○ Cloud-initでホスト名を指定してAMIを読み込みPuppetを インストール。その後、各Roleにあわせてマニフェストを 適用するとAWS上にサーバができあがる % ec2-run-instances ami-xxx -t t1.micro -- availability-zone=ap-northeast-1a -f /tmp/cloud- init/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
  14. 14. サーバ構成● たくさんの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
  15. 15. EC2のAMI管理はやっていた→やめた● 共通箇所をCloud-initで導入後、AMI管理● AMI→カスタマイズ→複数のAMIを管理 ○ AMI001 ... postfixをデフォルトでインストール ○ AMI002 ... qmailをソースから導入(既存踏襲) ○ etc● 既存踏襲の構成を見直してから自動化を考える べきだ、に落ち着く● 共通箇所はPuppetで管理 ○ AMIはオリジナルだけ ○ 開発環境も同様の構成で管理できる ○ 共通箇所+Roleごとにマニフェストを適用
  16. 16. 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
  17. 17. 既存踏襲と構成管理● 基本的には踏襲するとまずい構成は引き継が ないで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こんな状態を構成管理して自動化とかしないこと
  18. 18. 本番環境と開発環境の分岐● PuppetのEnvironmentsを利用 ○ 本番環境:production(デフォルト) ○ 開発環境:development● puppet.confで定義 ○ 定義時の分岐はホスト名を利用。 ○ hoge.comであれば本番。hoge.devなら開発など # puppet.conf [agent] environment = development※ Docs: Environments :http://docs.puppetlabs.com/guides/environment.html
  19. 19. 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, } }
  20. 20. 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)
  21. 21. 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}",},
  22. 22. 展望● PuppetのExternal Nodeは使いたい ○ nodes.ppの管理は自動化すべき● ローンチはもっと自動化できる● PuppetのDeployはWebistrano使いたい ○ Funcでrsyncしているだけなので● Puppetで管理しているDevな箇所はカジュアル にDevに操作してもらいたい ○ GitHubでpull requestをもらう仕組み作り● 参考:@lamanotrama
  23. 23. 結論● 構成管理を自動化すると開発 者(Dev)と運用者(Ops)のより よい関係が築ける● システム設計が甘いと自動化 も構成そのものも破綻するの で将来性を常に気にすること
  24. 24. おわりご静聴ありがとうございました
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×