Automation_tech_casual_talks_1_puppet
Upcoming SlideShare
Loading in...5
×
 

Automation_tech_casual_talks_1_puppet

on

  • 6,975 views

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

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

Statistics

Views

Total Views
6,975
Views on SlideShare
1,766
Embed Views
5,209

Actions

Likes
3
Downloads
13
Comments
0

7 Embeds 5,209

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

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Automation_tech_casual_talks_1_puppet Automation_tech_casual_talks_1_puppet Presentation Transcript

  • 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/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
  • サーバ構成● たくさんの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)のより よい関係が築ける● システム設計が甘いと自動化 も構成そのものも破綻するの で将来性を常に気にすること
  • おわりご静聴ありがとうございました