20120927 findjob4 dev_ops
•
33 gostaram•4,291 visualizações
DevOpsな現場で求められる「インフラがわかるデベロッパ」とは？ http://atnd.org/events/31930
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 20120927 findjob4 dev_ops
Semelhante a 20120927 findjob4 dev_ops (20)
Último
Último (9)
20120927 findjob4 dev_ops
- 1. DevOpsな現場で求められる 「インフラがわかる デベロッパとは？」 2012/09/27 Find your Ability ! forデベロッパ #4
- 2. 自己紹介 ● ㈱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を知ることでインフラの範囲を探ろう
- 7. Opsとは ウェブアプリケーションを 構築・運用・保守の面か ら支える人 ○ サーバエンジニア ○ インフラエンジニア ○ ウェブオペレーション(!?)
- 8. ウェブオペレーション ● 「ウェブオペレーショ ンは技芸であり、科 学ではない。」[1] ● 技芸は経験から得る ● 経験：悪い判断・理 論と実践の衝突 ● Opsを語る良書 ○ インフラの人を知るのにDevに オススメな一冊 [1] 引用元：ウェブオペレーション ―サイト運用管理の実践テクニック まえがき
- 9. 今までのOps データセンタに行ってサーバを 構築。帰ったらサーバの保守手 順書を作成して、夜間メンテナ ンスの運用準備もしなきゃな。 日曜日は自宅監視の日なんだ よなー。 あー！人も時間も足りない。
- 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もさわる
- 23. 図解 Opsの日常
- 24. DevOpsにおけるOpsとは ● OpsでありDevもやるということ ○ 求められる技芸はコードがかける力 ○ ツールを使いこなすだけではなく、文化の浸透も必要 ということは、Devも... Devであり、Opsもやることが求 められるているのでは？
- 25. 前半のまとめ ● 技芸が一部陳腐化 ○ クラウドは今までのOpsを必要としない ● 運用の技芸の時代 ○ コードとツール ● Opsは自然とDevを求めた ○ 変わらなければいけない文化
- 26. Devが語るDevの話はしない ● Agileの哲学 ● テストコード手法 ● CIツール ● 継続的デプロイ ● etc ... Opsの視点から、Devに求めら れていることを語ります
- 28. なぜインフラを知る必要があるのか クラウドが 登場したから
- 30. ちがいます
- 32. スモールスタートの時代 ● スタートアップにコストをかけたくない ● 3人チームが主流 クラウドを使えばインフラ 専任者いらなくね？ Dev NoOps Designer Director
- 33. Devにも革命を与えたクラウド ● NoOpsで開発が進められる時代 ○ クラウドの登場がそれを現実化した ○ サーバを用意する負担が減った分、人がいらない ● スマホアプリの開発者は例外 ○ すでにNoOps？ ○ インフラをあまり意識しない（いいか悪いかは別） NoOpsなら インフラはDevが触るしかない
- 34. NoOpsはむずかしい ● Opsはいつ登場するのか ○ プロジェクトスタート時の出番は少ない ○ リリース直前や直後 ○ 運用を考えるとOpsがいないことはありえない ● プロジェクトやチームごとにOpsは必要か？ ○ たまに顔をだすのがクラウド時代のOpsの未来像 基本的にOpsはいる
- 35. DevとOpsの境界線が曖昧に ● システムの複雑化・冗長化 ○ クラウドならサーバのスケールアップ・アウトが容易に ○ パフォーマンス設計よりレスポンス設計 ○ 豊富な役割を持つサーバとミドルウェアの選択肢 ○ 疎結合 ● Devの人のインフラの操作範囲が広がった Devは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に知っていてほしい インフラの接点の一例を紹介
- 40. Pull Reqestする文化 ● 例：Ops管理の設定ファイルを変更したい ○ DevがOpsへPull Requestして確認後、Merge
- 42. クラウドを活用したい ● AWSならこれをつかいたい！ ○ サーバ→EC2 ○ MySQL→RDS ○ ロードバランサ→ELB ○ DNS→Route53 ○ 画像置き場→S3 ○ CDN化→Cloudfront ● インフラの選択肢を知る ● クラウドはDevとOpsの制約を開放する ○ Devは、ハードウェアをAPIとして見ることができる ○ Opsは、本来やりたいことに時間をかけることができる ○ これやりたい！をいいあえる関係へ
- 43. 開発環境の構築はDevがやる ● Opsが構成管理したVM(仮想マシン)を使う ○ Opsがやるのは環境イメージを渡す、まで ● Devがある程度管理する ○ 本番環境でも必要な設定があれば、Pull Request ○ root権限も開発環境ならさわっちゃう Devでできるインフラのことは OpsにまかせずDevでやる
- 44. 様々なログを気にする ● 線引が曖昧なログの管理 ○ DevOpsっぷりを探る ● 様々なログたちを気にしているか ○ MySQLのスロークエリ ○ Webサーバのアクセスログ ○ メトリクスの採取、性能監視のグラフ化 ○ cron,バッチ処理のログ, etc... ● 今時ならFluentdでログ採取 ○ Opsが、 採取閲覧の仕組みを用意 ○ Devが、 閲覧する。気にする
- 45. CIツールでcron処理 ● DevからOpsへの作業依頼代表例 ○ 「cronに〇〇のバッチ処理の登録をお願いします」 ● DevはJenkinsで定期的な処理を実施 ○ Opsを介さない
- 46. DevOpsへのモヤモヤ ・Opsに任せすぎていたかも ・サーバ操作することが増えた ・コードに集中したいけど ・Devとコミュニケーションするなら コードかなー
- 47. 時代が求めるDevOps ● バズワードや言葉の定義が先ではない ○ 結果そうなっただけのこと ● 文化を知る ● アウトプットから知る ● 現場で起きていることを知る 理想：俺達がやっていたことは DevOpsだったんだー！
- 48. 後半のまとめ ● クラウドはDevをも変える ○ NoOpsな環境もあり、求められる ● DevだけOpsだけがよくない ○ DevOpsで行こう ● DevOpsは歩み寄りではない ○ 互いの接点を刺激しあう
- 49. とはいえ、これからどうするDevOps ● Devはコードを書くことに集中したい ● DevはOpsに興味がもてるか ● DevはOpsがOpsはDevが苦手分野なことも ● NoOpsが未来なのか ● DevOpsを一人でやることが理想なのか ● プログラマの時代。コードの時代 ● Opsはコード書く技術力がなければ今後は... ● それでも、密接なデータセンタとOpsの関係 ● クラウドを使わない現場に理想のDevOpsな し、って言いたいのかよ！ 皆で考えていきたい課題は山積み