Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

of

Dev ops Slide 1 Dev ops Slide 2 Dev ops Slide 3 Dev ops Slide 4 Dev ops Slide 5 Dev ops Slide 6 Dev ops Slide 7 Dev ops Slide 8 Dev ops Slide 9 Dev ops Slide 10 Dev ops Slide 11 Dev ops Slide 12 Dev ops Slide 13 Dev ops Slide 14 Dev ops Slide 15 Dev ops Slide 16 Dev ops Slide 17 Dev ops Slide 18 Dev ops Slide 19 Dev ops Slide 20 Dev ops Slide 21 Dev ops Slide 22 Dev ops Slide 23 Dev ops Slide 24 Dev ops Slide 25 Dev ops Slide 26 Dev ops Slide 27 Dev ops Slide 28 Dev ops Slide 29 Dev ops Slide 30 Dev ops Slide 31 Dev ops Slide 32 Dev ops Slide 33 Dev ops Slide 34 Dev ops Slide 35 Dev ops Slide 36 Dev ops Slide 37 Dev ops Slide 38 Dev ops Slide 39 Dev ops Slide 40 Dev ops Slide 41 Dev ops Slide 42 Dev ops Slide 43
Upcoming SlideShare
Play!
Next
Download to read offline and view in fullscreen.

2 Likes

Share

Download to read offline

Dev ops

Download to read offline

社内勉強会の資料です。

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Dev ops

  1. 1. + DevOps勉強会
  2. 2. + DevOpsってなんなの?  最近流行ってますよね?  名前は聞くけど、それってなんなの、ってのを説明します。
  3. 3. + DevOpsとは?  Dev(開発)とOps(運用)が仲良くやろう  ツールの話じゃないんだ、文化の話なんだ! (本当は両方必要です) http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  4. 4. + なんとかしたいこと 新機能を追加しようとする開発部隊 VS 安定稼働を求める運用部隊  でもどうしたらアプリケーションエンジニアとインフラエンジ ニアが協力できるの?
  5. 5. + そもそもなんで協力できないの?  属人性が発生させる特権  最終確認者、デプロイ担当、インフラ担当  開発を邪魔する多くは「特権」  特権は必ず腐敗する  みんななかよくやりましょうよ!  at Velocity 2009 , Flickr, J.Allspaw& P. Hammound  DevOpsの10ヶ条 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  6. 6. + DevOpsの10ヶ条 【意訳】 1. インフラを自動化しよう 2. バージョン管理を共有しよう 3. ビルドとデプロイを1ステップで 4. 機能毎にブランチを切ろう 5. システムの指標を見えるようにしよう 6. 現状をIRCにつぶやくbotを使おう 7. 他のメンバに敬意を払おう 8. 他のメンバを信頼しよう 9. 失敗に対して健全に対処しよう 10.非難は無視しよう http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  7. 7. + DevOpsの目指すところは?  その前に、本当に必要な機能を作れていますか? http://www.ryuzee.com/contents/blog/6729
  8. 8. + DevOpsの目指すところは?  「ビジネスにおいて試行錯誤を多数繰り返したい」  アジャイルな開発、継続的デリバリー http://www.ryuzee.com/contents/blog/4241
  9. 9. + DevOpsの事例  Obama for America(大統領選)  ボランティア開発  EC2でVM 4,000台規模 / Puppetで管理  Githubですべて管理  1日10回デプロイできますか? @ Flickr , @cookpad  1日1000回デプロイできますか? @amazon  日本でもWeb系で採用例がどんどん増えているみたいですよ  Web系のスタートアップ企業はほとんどが採用しているようです。
  10. 10. + 再掲:DevOpsの目指すところは?  「ビジネスにおいて試行錯誤を多数繰り返したい」  アジャイルな開発、継続的デリバリー http://www.ryuzee.com/contents/blog/4241
  11. 11. + Continuous Deliveryをするためには?  開発・運用プロセスをなるべく自動化してデプロイの苦痛を減 らしましょう Infrastructure as Code  そのためのツールがいろいろあります。  でもその前に、、、
  12. 12. + デプロイ・リリース手法いろいろ その1  デプロイ・リリースの方法にもいろいろあるようです。  ブルー・グリーン・デプロイメント  2系統を持っておいて、1系統に新しい機能をデプロイして問題なければ切り替える デプロイ方法  AWSとか使うと安くなるみたいですよ? 1系統 2系統 ルーター 等 問題なし!切り替え!
  13. 13. + デプロイ・リリース手法いろいろ その2  カナリアリリース  最初に一部ユーザに先行して使ってもらって、問題なければ全体に リリースする手法 アプリA 試用期間 アプリA’ _ アプリA’ 大多数ユーザ 一部ユーザ 問題なし! 全員移行
  14. 14. + デプロイ・リリース手法いろいろ その3  ABテスト  一部ユーザに尐し違うAとBを使ってもらって、どっちのほうが結果が良くなるかをテストする手法。  文字サイズが1ピクセル小さくなったら20%もクリック率が下がったってこともあるらしいですよ?  UIの改善手法では公開前のユーザビリティテストと加えてデファクトスタンダートな手法みたいです よ? 現行アプリA アプリA’-1 アプリA’-2 大多数ユーザ 一部ユーザ A郡 全員移行 一部ユーザ B郡 アプリA’-2 良くなった 悪くなった
  15. 15. + 再掲:Continuous Deliveryをするために は?  開発・運用プロセスをなるべく自動化してデプロイの苦痛を減 らしましょう Infrastructure as Code  そのためのツールがいろいろあります。
  16. 16. + ツール群  インフラ周り  OS仮想化(VMWare / KVM / Vagrant )  クラウド構築(OpenStack / CloudStack / Eucaliptus)  ネットワーク仮想化(OpenFlow)  設定反映周り  マシン状態管理(Chef / Puppet / Ansible)  デプロイ(Capistrano / Fabric )  テスト周り  マシン状態 ( serverspec )  アプリケーション( selenium / silktest )  BDDツール( Cucumber )  管理関連  プロジェクト管理( Trac / redmine)  CIツール( Jenkins )  バージョン管理( git /mercurial / subversion )  監視関連  サーバ監視( Zabbix / Nagios / Hinemos )  ロギング( fluentd )
  17. 17. + インフラ周り  VMWare / KVM  OS仮想化基盤、OSの上にOSを載せましょう  OpenStack / CloudStack / Eucaliptus  仮想化基盤の管理。AWSみたいなのを作りましょう  Vagrant  仮想化基盤の操作をコマンド化/コード化しよう  OpenFlow  ネットワークを仮想化/コード化しよう
  18. 18. + VMWare / KVM / Xen / VirtualBox  皆さんご存知、OSの仮想化。  OS on OS (Hyper-visor)  メリットの出る場面例  物理マシン1台のリソースを余すところ無く使いたい  HWが今にも壊れそうなので移行したい  物理マシンが1台しかないけど、いろんなテスト環境がほしい  デメリット  オンプレと比較するとオーバーヘッドが大きい
  19. 19. + OpenStack / CloudStack / Eucaliptus  クラウド環境構築・運用ソフトウェア  OS仮想化したけど、台数増えるとコマンドとか1台1台Hyper-visorにロ グインしてVMを操作するの大変ですよね?  AWSみたいに使いたいですよね?  メリットの出る場面  人手で余るような大規模さや、そもそも人手でやっていてはどうしよう もないときに効果を発揮する  DCとかHDDが1日1個壊れる環境とか、アクセスが増えた時に自動的 にVMの台数を増やすとか  GUIも一緒についてくるので、コマンド叩けなくてもなんとかなる!  デメリット  マシンが1台しかないのならESXiで十分
  20. 20. + Vagrant  開発でいちいちGUIなんて使いたくねぇよ。インストール作業も 面倒くさい!コマンドだけでVMたちあげたい!  そんなあなたにオススメなVagrant。開発のお供に  メリットの出る場面  インストール環境をコマンド一発で準備(事前準備は必要)  まっさらなVMが1分で立ち上がります@MBA。事前にVMコピー、リ ソース設定は必要です。  仮想環境を何度も壊すような検証作業や、まっさらな状態からインス トールする手順を作るときとかに有効(失敗してもまっさらな状態に戻 すのに1分でできます)  デメリット  vagrantbox.esで誰が作ったかわからないVMを使う必要 or 専用のVMイ メージを作成する必要がある vagrant up
  21. 21. + OpenFlow  ネットワークの仮想化技術。インフラのコード化。  OSも仮想化したらネットワークも仮想化したいですよね?  メリットの出る場面  同じ物理ネットワーク上でプライベートネットワークを作りたいと き。いちいちDCに行くのが面倒くさい時。  VLAN IDの壁を突破できるよ!  東海地震起こった時に、ネットワークを北陸経由にできるよ!  デメリット  まだ実績がDCや国のプロジェクトに限られている
  22. 22. + 設定周り  Chef / Puppet / Ansible  サーバの状態・バージョン管理。サーバ状態をコード化しよう  Capistrano / Fabric  デプロイの自動化。デプロイ手順をコード化しよう
  23. 23. + Chef / Puppet / Ansible  サーバ構成自動化ツール。インストール後のパッケージ管理や環境設定な どをコード化。何度実行しても同じ結果になる冪等性という特徴。  ChefとPuppetはpush型、pull型(サバクラ)の両方ができますがサーバにイ ンストールが必要です。Ansibleはpush型のみですが、サーバにSSHが 入っていれば利用できます。最近流行ってます。ChefはRubyでかけます。  メリットの出る場面  試験環境と同じアプリケーションをインストールしたいですよね?環境構築手順 書を書くなら、そのまま動く手順書を作りたいですよね?  インストールとかでミスしませんか?私はよくします。マシン10台で初期設定し ろとか言われたら泣きますよね?  AWSでOS起動を自動化してもインストール手作業だったら意味ないじゃない!  デメリット  ChefとPuppetはリモートマシンに専用のインストールが必要。  Linux専用です。WindowsにはSystemCenter?があるそうです。
  24. 24. + Capistrano / Fabric  デプロイの自動化ツール。リモートマシンで指定のコマンドを叩 きます。サーバにsshが入っていれば利用できます。  CapistranoはRubyでかけます。FabricはPythonでかけます。  メリットの出る場面  テスト環境と同じデプロイ手順を行いたい場合。デプロイの手順書はい つも最新化されていますか?  幾つものサーバで同じ操作をする必要が有る場合  あなたはデプロイでミスをしませんか?私はします  開発環境をいちいち作るの面倒じゃないですか?  デメリット  Linux専用。Windowsでは「DevOps workbench」というのがでたそう な。(capistranoはWinRDでWindowsでも使えるみたいなノリの表示は 出るけど、試してません)
  25. 25. + テスト周り  serverspec  インフラのテストをコード化しよう。サーバのインストール状態、 サービス状態、リッスン状態など  selenium / silktest  ブラウザのテストツール。アプリケーションのテストをコード化し よう  Cucumber  BDD用ツール。  詳しく知らないものなので、パスします。動作を記述して、そのテ ストを行うツールだそうです。
  26. 26. + serverspec  OS環境のテストツール。パッケージインストール状態やサービス の起動状態、ポートのlisten状態などをテストできる。  メリットのある場面  chef/puppet/ansible/capistrano/Fabricなどを利用している場合、テスト と一緒にどうぞ!  本当にインストール・設定ができているか、証跡などを残したい場合に。  デプロイチェックに。  デメリット  学習コスト  Linux専用
  27. 27. + selenium / SilkTest  UIテスト自動化ツール。回帰テストなどの何度もテストを実施 するときのお供に。  メリットの出る場面  回帰テストがたくさん出るプロジェクト  アジャイル/TDDをやっているプロジェクト  リファクタリングするときに  デメリット  2度目以降のUIテストを自動化するツールなので、テストを1回しか しないのであれば、手動の方が早いです。  SilkTestは有料です。
  28. 28. + デモ  Vagrant + AWS ConoHa+ Capistrano + serverspec
  29. 29. + 管理関連  Jenkins  継続的インテグレーション(Continunious Integration)ツール。アプ リケーション開発支援など。  git / mercurial / Subversion  コードのバージョン管理  Trac / Redmine  プロジェクト管理  JIRA  バグ・課題管理。詳しくは知らないので、パスします。
  30. 30. + Jenkinsおじさん  継続的インテグレーションツール。かなり簡単に導入できます。  メリットの出る場面  アジャイル/TDDのお供に。リポジトリにpushしたらテスト、pull requestが来たらテスト!そしてデプロイ!  クロスブラウザテスト。デプロイしたら/1日1回、ブラウザのイン ストールされた仮想マシン4台でテストしてテスト結果を実施でき ます。  今まで説明した自動化ツール/テストツールと連携すると強力。  デメリット  仮想化するとうまく使えないことがあるらしい。
  31. 31. + Git / mercurial / Subversion  バージョン管理ツール。git/mercurialは分散型。subversionは中央 集中型。  Githubとか有名ですよね?  メリット  コードのバージョン管理・開発の状態管理。  先のインフラ自動化ツールを使えば、環境のバージョン管理や、デプロ イ手順のバージョン管理が行える。  Jenkinsおじさんと連携すれば、pull requestされた時にテストして結果 を返してくれる。  デメリット  学習コスト
  32. 32. + 監視  Zabbix / Nagios / Hinemos  サーバ監視  fluentd  ログ管理
  33. 33. + Zabbix / Nagios / Hinemos  監視システム。監視・通知をする運用ツール  Zabbix/Nagiosはmunin/gangliaなどのリソースモニタリングツー ルと一緒にどうぞ。  Hinemosはジョブ設定などもできるらしいですが、皆さんのほう が詳しいんじゃないんでしょうか?  メリットのある場面  商用環境なら入れましょう  アクセス負荷などでサーバがやばい状態になったかどうかわかります。 通知とかできます。  デメリット  アプリケーションのインストールが必要
  34. 34. + fluentd  ログ収集基盤。インプットされたログをJSONに加工して出力 する。パイプライン処理のように多段階で処理し、リアルタイ ムにアクセス解析をすることも可能。  メリットのある場面  アクセス分析をリアルタイムでしたいとき  エラーが起こったすぐのタイミングで分析を始めたいとき  デメリット  fluentdにログを転送する設定が必要
  35. 35. + ツールがいっぱい  どうやって使えばいいの・・・?
  36. 36. + 例えば〜その1  アクセスが増えてきたらVM増やそう! アクセスリアルタイム集計 仮想マシン ①作成 ②構成変更 ③アプリデプロイ ServerSepc ④構成テスト 現行系 発火する何か ⑤構成変更・VM追加
  37. 37. + 例えば〜その2  新しい機能のPullRequestが来たら毎回テスト! 仮想マシン ③作成 ④構成変更 ⑤アプリデプロイ ServerSepc ⑥構成テスト ①PullRequest ②PullReq通知 ⑦構成テスト ⑧結果通知
  38. 38. + 例えば〜その3  デプロイ失敗した!バージョン戻そう! ServerSepc ①コード clone 現行系 ローカル マシンとか ②構成変更 ②デプロイ し直し ③構成テスト ④動作テスト
  39. 39. + 例えば〜その4  新しい人が入ってきた?40秒で支度しな!  Chefで仮想マシンの準備  10分くらいあればできます。  Mac向けですが、Boxenなんてものも最近流行ってます
  40. 40. + 他に嬉しい事は?  サーバの状態って、今どうなってたっけ?がなくなる  コードを見ればわかる  デプロイが簡単になる  テスト環境でデプロイ手順をコード化すれば、その通り動く。1コマン ドデプロイとか夢じゃないですよ?  手作業によるミスが減る  コード化されているのでケアレスミスが減る  手順が常に最新  コードなのでお客様に出すの難しいかもしれない・・
  41. 41. + 理想は?  インフラも、アプリケーションも、管理も、監視も 全部コード化!自動化!  そのためには、 手作業は手順を作るとき以外はやらない。 と私は考えています。
  42. 42. + まとめ  開発と運用が仲良くしよう(DevOps)  そのためにツールを色々使って文化を整えよう!  いいもの届けていこう!  目指せフルスタックエンジニア!
  43. 43. + 参考資料  http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and- ops-cooperation-at-flickr  https://speakerdeck.com/naoya/devopsfalsejin-tokorekara- number-init-devops  http://www.ryuzee.com/contents/blog/4241  http://www.zusaar.com/event/838007  http://www.slideshare.net/tomohn/10devops-20004973  http://atnd.org/events/41286
  • YohHoshino1

    Oct. 3, 2015
  • KasumiChida

    May. 20, 2014

社内勉強会の資料です。

Views

Total views

990

On Slideshare

0

From embeds

0

Number of embeds

73

Actions

Downloads

26

Shares

0

Comments

0

Likes

2

×