Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps_新卒エンジニア研修.pdf

 DevOps_新卒エンジニア研修.pdf

norinux

May 13, 2018
Tweet

More Decks by norinux

Other Decks in Education

Transcript

  1. 本講義の目的 • DevOps の本質を理解する • DevOps の文脈でよく登場するキーワードについて理解する ◦ 継続的インテグレーション、継続的デリバリー、継続的デプロイ ◦

    Immutable Infrastracture、Infrastracture as Code、Blue Green Deployment • DevOps のための主要なツールとその使い方を知り、事業配属後の導入や運用に 役立てる
  2. 本講義の内容 • DevOps とは ◦ 30min • DevOps の実践 ◦

    30min • 課題 ◦ 30min • Immutable Infrastracture / Infrastracture as Code / Blue Green Deployment ◦ 30min • 課題 ◦ 60min • TRUSTDOCK での DevOps ◦ 15min
  3. DevOps の定義 DevOps を調べると、働き方や文化、組織構造、ツール、アーキテクチャなどを内包する 広い概念であることが分かる ここで、DevOps という言葉の理解が皆バラバラだと • 自分たちに DevOps

    が必要なのか? • 自分たちは DevOps の何から始めるべきか?どこを取り入れるべきか? が判断しにくい だから、DevOps の本質を正しく理解する必要がある そこで、DevOps が誕生した背景を知り、DevOps が必要になった状況について考えて みよう
  4. アジャイル開発による継続的な改善への変化 ビジネスニーズの変化の早さに対応するため、ウォーターフォール開発からアジャイル 開発へシフトした結果、従来では考えられなかった頻度でのリリースに対応する必要が 生まれた • ウォーターフォール開発 ◦ 要件定義・開発・テスト・リリースの工程を一つ一つ時間をかけて作り上げていく • アジャイル開発

    ◦ 必要最小限の製品を作り上げ、その後も小さな変更を頻繁にリリースして改善していく そこで「効率化や自動化を行い、リリースまでにかかる時間を短縮しよう」という考え方 が生まれ、継続的に成果物を仕上げていく体制へと進化した
  5. DevOps の誕生 2009年に O'Reilly 主催のカンファレンス Velocity にて、Flickr のエンジニアが“10+ Deploys per

    Day” という発表を行い、ここで初めて「DevOps」という言葉が登場した 開発と運用で達成すべきミッションが異なるため、対 立関係が起こりやすいが... • 開発は「改善のために変更したい」 • 運用は「安定稼働のために変更したい」 開発も運用も「変化するビジネスニーズに応える」と いう同じミッションに向かおう 変更のリスクは手法と文化によって軽減しよう = DevOps だ!
  6. 継続的インテグレーション 1. 開発者は自分のローカル環境にコードをチェックアウトする 2. コードの変更が完了したら、変更をコミットし、リポジトリにプッシュする 3. CI サーバはリポジトリを監視し、変更が発生したときにチェックアウトする 4. CI

    サーバは設定ファイルに記されたとおりに環境を構築し、コードのビルド、ユニッ トテストと統合テストを実行する 5. CI サーバは成功をチームに通知する 6. ビルドまたはテストが失敗した場合、CI サーバは失敗をチームに通知する 7. チームはできるだけ早く問題を修正する 8. 継続的にプロジェクト全体の統合とテストを継続する
  7. Infrastructure as Code Infrastructure as Code とは、インフラの設定変更手順を自動化するためにコード化す ること。これにより、ソフトウェア開発の手法をインフラの構築にも適用可能とすること • インフラの構成や設定を共有できる

    • 誰でも再現でき、属人性を排除できる • 自動化により迅速に確実に設定が適用できる • バージョン管理やテスト駆動開発などの開発手法を適用可能になる
  8. Blue Green Deployment Blue Green Deployment とは、Blue と Green と呼ばれる2種類の環境を用意し、どち

    らか一方のみユーザが利用するようにする ユーザが利用していない環境にリリース作業を行い、Blue と Green の接続先を切り替 えることで、サービス停止なく切り替え完了させる トラブル発生時には、ユーザの接続先を戻すだけで復旧が可能となる。切り替え後、トラ ブルに対する調査や対応はもう一方の環境に対して行えば良い • サービス停止なしに変更をリリース可能 • ロールバックが簡単
  9. 応用課題 • CircleCI でプロジェクトを作り、ビルドしてみよう • Github と CircleCI を連携し、ビルドが通るまで master

    ブランチにマージできない ようにしよう • CodeDeploy を使って既存のサーバに最新のコードを自動デプロイしよう • CI でビルドが成功したら、CodeDeploy でデプロイが実行されるようにしよう • Ansible でサーバに設定を適用しよう • CodeDeploy を使って Blue-Green Deployment をやってみよう