Más contenido relacionado La actualidad más candente (20) Similar a 20120927 findjob4 dev_ops (20) 20120927 findjob4 dev_ops2. 自己紹介
● ㈱paperboy&co. 梅谷 敦
○ Twitter : @ume3_
○ ブログ : インフラエンジニアに成る
○ Ops : 4年目
● 普段のお仕事
○ AWS上でのサーバ構築
● 最近の活動
○ LAMP環境をPuppet化してみて
ふつうのインフラエンジニアです
4. 定義
● DevOps
○ 運用者と開発者の壁をなくすこと
○ 参考:DevOpsって何?
■ @gosukenator さん
● Dev(Development)
○ 開発者 / デベロッパ
● Ops(Operations) ※[1]
10+ Deploys Per Day: Dev and Ops
○ 運用者 / インフラエンジニア Cooperation at Flickr
[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
5. Agenda
● 前半
○ インフラの昔と今
○ 私が扱うようになったツール2012
○ Opsが今求められていること
● 後半
○ Opsが変わる。Devも変わる
○ 現場のインフラの人が求める開発者
○ DevOpsな現場
● まとめ
○ インフラがわかるデベロッパとは?
ふつうのOpsが現場を語ってみます
6. Opsってイッタイゼンタイなんなのさ
● 普段何しているの?知らない
● そもそも、いっしょに仕事しない
● データセンタにいったりきたりするイメージ
● 障害対応に忙しそうだ
● 夜中に対応したのか、朝帰ったりしている
● 今日いないな?と思ったら夜間メンテナンス
Opsを知ることでインフラの範囲を探ろう
8. ウェブオペレーション
● 「ウェブオペレーショ
ンは技芸であり、科
学ではない。」[1]
● 技芸は経験から得る
● 経験:悪い判断・理
論と実践の衝突
● Opsを語る良書
○ インフラの人を知るのにDevに
オススメな一冊
[1] 引用元:ウェブオペレーション ―サイト運用管理の実践テクニック まえがき
11. 運用の技芸が求められている時代
構築 構築
運用
運用
保守
保守
今までのOpsは、物理障害の 今のOpsは、運用の時間を確
対応に依頼作業や監視など 保し、変化に常に対応できる
の保守に時間をとられていた ことが求められる
12. 運用で必要な技芸とは何か?
● 手動作業の自動化
○ コードが書ける
○ ツールを使いこなせる
● パフォーマンスチューニング
○ 性能監視
○ ハードウェアやミドルウェアのチューニング
● 結果、いいシステムを設計することができる
守り(保守)から攻め(運用)へ
13. Opsな私が扱うツール2012
● クラウド
○ AWS
● 構成管理
○ Puppet
● リビジョン管理
○ Git
● 情報共有
○ IRC,GitHub
● デプロイメント
○ Webistrano
● プロジェクト管理
○ Agile, 付箋紙
14. AWS(Amazon Web Services)
● クラウドの登場はインフラの世界を変えた
○ データセンタ+ハードウェアという制約から開放
○ サーバの構築をプログラマブルに扱うことが可能
インフラのコード化
NoOps(インフラの人がいらない)と思えるぐらい
ハードウェアがAPIと化している
15. Puppet
● 構成管理ツール
○ Ruby製。外部DSL
● 手順書をコード化する
○ サーバ構築の自動化
○ 独自のレシピでミドルウェアの「ふるまい」や設定ファイ
ルを役割ごとに管理できる
実行例)Apacheの設定ファイルの差分を変更後、サービスを自動起動
16. 例)手順書のコード化
< Puppet のレシピ >
・init.pp
wwwという役割のサー
バにboto[1]を導入する
・config.pp
固有の設定ファイルを
指定。このとき、インス
トールが先と定義。
・install.pp
事前に定義したpipモ
ジュールをインストール
[1] boto:https://github.com/boto/boto
17. Git+GitHub
● リビジョン管理
○ ご存知Gitでコードの世代管理
○ お一人様Gitでもやる
● GitHubでソーシャルコーディング
○ Devとのコミュニケーションにかかせない
○ issueやwikiを活用
例)GitHubでPuppetの設定管理
18. Webistrano
● 自動デプロイツール
○ capistranoをWebアプリでラッパしたもの(Ruby製)
○ 誰もが操作できることに意味がある。Opsもデプロイ
Dev
Designer
Deploy
Ops
19. IRC
● DevのIRC文化にのる
○ Opsも他職種も同様。同じツールを使う
● Botがはびこるチャンネル達
○ テストの成否通知
○ デプロイ通知
○ git push検知
○ サーバ障害のアラート
(例)IRCにデプロイ通知Botが流れたとき。トリガーはツールによる。
20. Agile
● Devの文化にのる
● Devはツールや文化
が整っている
● 意識が高い
● 荒ぶる四天王
○ コスト
○ 時間
○ スコープ
○ 品質
アジャイルサムライは良書。というよ
り、最低限これぐらいのことは意識しな
いとちょっと...と思えるか。
22. その他のツール
● Jenkins
○ Devが扱うCIツール
○ ビルド作業やバッチ処理としてOpsも扱いたい
● Chef
○ Devが好む構成管理ツール(Ruby製)
○ 設定ファイルがRubyの内部DSL
○ OpsもDevの作業内容を把握したい
DevなツールをOpsもさわる
25. 前半のまとめ
● 技芸が一部陳腐化
○ クラウドは今までのOpsを必要としない
● 運用の技芸の時代
○ コードとツール
● Opsは自然とDevを求めた
○ 変わらなければいけない文化
26. Devが語るDevの話はしない
● Agileの哲学
● テストコード手法
● CIツール
● 継続的デプロイ
● etc ...
Opsの視点から、Devに求めら
れていることを語ります
34. NoOpsはむずかしい
● Opsはいつ登場するのか
○ プロジェクトスタート時の出番は少ない
○ リリース直前や直後
○ 運用を考えるとOpsがいないことはありえない
● プロジェクトやチームごとにOpsは必要か?
○ たまに顔をだすのがクラウド時代のOpsの未来像
基本的にOpsはいる
36. DevとOpsの壁をなくす
Dev Ops
※[1]
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
37. Opsが求めるDevとは
● Devだけでなく、Opsもやると
いう意識と行動がある人
● 「だけ」がダメ
● インフラに口出ししてほしい
38. こんなDevはイヤだ
● DevはDev、OpsはOpsと線引をする
● サーバの設計・構築はOpsまかせ
● ミドルウェアの設定変更作業はすべてOpsに
● 監視ツールの計測結果を見ない
● root権限で出来ない操作はしないしおまかせ
今までがそうだからってこれか
らもそうとは限らないじゃないか
39. DevとOpsが幸せになるために
● DevからOpsへのお願い作業を減らす
● GitHubでPull Requestする関係
● 積極的なクラウドの活用
● 開発環境の構築管理
● ログを気にする
● 定時処理のDev管理
Devに知っていてほしい
インフラの接点の一例を紹介
42. クラウドを活用したい
● AWSならこれをつかいたい!
○ サーバ→EC2
○ MySQL→RDS
○ ロードバランサ→ELB
○ DNS→Route53
○ 画像置き場→S3
○ CDN化→Cloudfront
● インフラの選択肢を知る
● クラウドはDevとOpsの制約を開放する
○ Devは、ハードウェアをAPIとして見ることができる
○ Opsは、本来やりたいことに時間をかけることができる
○ これやりたい!をいいあえる関係へ
44. 様々なログを気にする
● 線引が曖昧なログの管理
○ DevOpsっぷりを探る
● 様々なログたちを気にしているか
○ MySQLのスロークエリ
○ Webサーバのアクセスログ
○ メトリクスの採取、性能監視のグラフ化
○ cron,バッチ処理のログ, etc...
● 今時ならFluentdでログ採取
○ Opsが、 採取閲覧の仕組みを用意
○ Devが、 閲覧する。気にする
48. 後半のまとめ
● クラウドはDevをも変える
○ NoOpsな環境もあり、求められる
● DevだけOpsだけがよくない
○ DevOpsで行こう
● DevOpsは歩み寄りではない
○ 互いの接点を刺激しあう
49. とはいえ、これからどうするDevOps
● Devはコードを書くことに集中したい
● DevはOpsに興味がもてるか
● DevはOpsがOpsはDevが苦手分野なことも
● NoOpsが未来なのか
● DevOpsを一人でやることが理想なのか
● プログラマの時代。コードの時代
● Opsはコード書く技術力がなければ今後は...
● それでも、密接なデータセンタとOpsの関係
● クラウドを使わない現場に理想のDevOpsな
し、って言いたいのかよ!
皆で考えていきたい課題は山積み