AWSとCircleCIで実現するDevOps

 AWSとCircleCIで実現するDevOps

B32c18d03687577950da29542d0a9180?s=128

Noboru Kurumai

March 13, 2019
Tweet

Transcript

  1. 12.

    12 アジェンダ 時間 内容 14:15 - 開場 14:30 - 14:45

    ご挨拶とCircleCIユーザーコミュニティの紹介 by CircleCI 14:45 - 15:45 AWS と CircleCI で実現する DevOps by AWS 15:45 - 16:00 休憩 16:00 - 17:00 AWS と CircleCI で実現する DevOps by CircleCI 17:00 - 18:00 ネットワーキング
  2. 16.

    16 DevOpsの歴史 2001 Agile Software Development 開発対象を厳格に扱うことで変化を管理するの ではなく、アジャイル方法論は変化を許容する。 リスクは完璧な計画によって減少できるもので はなく、プロジェクトを小さく分割しつつ、それら

    を素早く結合させることによって減らすことがで きる。 2008 Continuous Delivery & Deployment 継続的デリバリーは継続的インテグレーションの拡張として登場。 ソフトウェアが常にデプロイ可能な状態を保つというプラクティスで ある。 責務(とリスク)を開発者と運用者の間で共有すること - DevOpsカ ルチャーの登場。 チームはテストの自動化だけではなく、テストをパスした際のデプ ロイの自動化を目指す。 1970 Waterfall 開発プロセス全体がいくつかのフェーズから構成 されていて、次のフェーズに進むためには前の フェーズを終えていなければならない。 ただし、隣接するフェーズ間の小さなイテレーショ ンは例外的に実施する場合がある。 (ハードウェアの開発方法論に似ている) 1994 Automated Testing & Continuous Integration (Inception & Evolution: 1994-2008) 開発者は、失敗をより快適なものとして捉え、それが受け入れられないものではなく、む しろ自信をつけるものになってきた。 JUnitやCucumberなどのテスティングフレームワー クの登場がそれを反映している。 マイクロプロセスの要求によって登場した継続的インテグレーション (CI)は、開発者が数 多くの内部リリースを行うことを可能にした。 すなわち、継続的インテグレーションは常に少量のコードをマージするための方法論で あり、開発の最終フェーズで競合を発生させるような巨大なコードのコミットを防ぐ 2010 - Present
  3. 20.

    20 が解決する問題 • 全てのコミットに対してCIする ◦ 早い段階でバグを発見できる ◦ 設定で制御可能 • 静的解析などでの標準化

    ◦ コードの品質UP • テスト失敗したコードのマージブロック ◦ masterブランチの安全保証
  4. 25.

    25 5 Metrics You Should Know to Understand Your Engineering

    Efficiency https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf 1. Commit-to-Deploy Time (CDT)  コードがコミットされてからデプロイされるまでの時間 3. Queue Time  CIビルドが始まるまでに待たされる時間 2. Build Time  CIビルドに掛かる時間 5. Engineering Overhead  ツールのメンテナンスなど開発以外に掛かっている時間 4. How often Master is Red  masterブランチが壊れている時間
  5. 39.

    39 の種類 - Orbs Registry https://circleci.com/orbs/registry/ - Certified (CircleCI) -

    Partner (CircleCI認定パートナー) - 3rd party (その他)
  6. 41.

    41 継続的デプロイに必要なこと(機能面) - アーティファクト(成果物)がきっちり管理されていること - 品質が自動的・機械的に確認できること - CIの延長線上で実行できること - デプロイに必要なトークンなどの情報が秘匿できること

    - デプロイ設定がコンフィグとして管理できること - ダウンタイムを最小にできること - 切り戻しが容易であること その他、DevOpsを実現するためには、 モニタリングを含めたシステム運用・サービス運用が必要
  7. 49.

    49 version: 2.1 orbs: aws-ecr: circleci/aws-ecr@1.0.0 # ECRのOrbをインポート workflows: build-and-deploy:

    jobs: - aws-ecr/build_and_push_image: # 用意されているジョブにパラメータを渡して呼ぶ account-url: AWS_ECR_ACCOUNT_URL # ECRのアカウントの環境変数 repo: 'nginx' # イメージのレポジトリ tag: '${CIRCLE_SHA1}' # イメージのタグにコミットの SHAを使う へ イメージのデプロイ
  8. 50.

    50 version: 2.1 orbs: aws-ecs: circleci/aws-ecs@0.0.6 # ECSのOrbをインポート workflows: build-and-deploy:

    jobs: - aws-ecr/build_and_push_image: ... - aws-ecs/deploy-service-update: # 用意されているジョブにパラメータを渡して呼ぶ requires: - aws-ecr/build_and_push_image # 最初にnginxイメージをビルド family: 'kim-app-nginx' # ECSのタスク定義 cluster-name: 'default-kim5' # ECSのクラスター名 # タスクで使うコンテナイメージを指定 container-image-name-updates: 'container=nginx,image-and-tag=833371238208.dkr.ecr.us-east-1.amazonaws.com/nginx:${CIRCLE_SHA1}' へサービスのデプロイ
  9. 52.

    52 継続的デプロイに必要なこと(再掲) - アーティファクト(成果物)がきっちり管理されていること - 品質が自動的・機械的に確認できること - CIの延長線上で実行できること - デプロイに必要なトークンなどの情報が秘匿できること

    - デプロイ設定がコンフィグとして管理できること - ダウンタイムを最小にできること - 切り戻しが容易であること CircleCIとAWSを組み合わせることで、 CI/CDを簡単に始めることができます!!
  10. 55.

    55