はじめてのPHPプロフェッショナル開発 ch15 デプロイの自動化

Docker勉強メモ開発環境

Webアプリケーションの公開

  • 全部自分でやるのは大変

    • Webサーバー用意
    • DB用意
    • M/Wインストール
    • SSL設定
  • マネージドの仕組みをつかおう

Heroku

  • PaaS
  • アプリケーションの開発から実行、運用まですべてをクラウドで完結できる
  • 手軽さがウリ

    • 30分くらいで公開まで持っていける
  • ネットワークやサーバーの専門的な知識いらず
  • GitHub連携、pushするだけでCDできる

AWS

  • IaaS、PaaS
  • いろんなサービスを組み合わせる。ネットワークの設定なども自分でやる

    • EC2: Elastic Cloud Computing

      • 従量課金の仮想サーバー
    • S3: Simple Storage Service

      • eleven nineなオブジェクトストレージサービス
      • 静的コンテンツの保管・ホスティング
    • RDS: Relational Database Service

      • フルマネージドなRDBサービス

        • MySQLとかPostgreSQLとか
      • 専門知識が必要なDBA業務を簡単に行うことが出来る

        • セットアップ
        • オペレーション
        • スケール
    • ELB: Elastic Load Balancing

      • ロードバランサ
      • 複数サーバへの分配を用意に行える
      • ALB: Application Load Balancer

        • L7(アプリケーション層)レベルのルーティングも簡単に行える
  • うまく組み合わせて使うことで、運用コストを下げつつ自由度高くサービスを構築できる

ソフトウェアのデプロイメントサイクル

サイクル(循環)要素なくないか

  • 開発環境

    • 日頃開発
    • なるべくプロダクション環境に寄せたいが難しい
    • 他の開発者を意識せず使えること

      • 【所感】前いた現場ではDBが共用でした…
  • ステージング環境

    • プロダクションと同じ環境が理想
    • ここで「プロダクション環境で起こるバグ」を出し尽くす
  • プロダクション環境

    • エンドユーザにサービスを提供
    • バグを出さない

デプロイ自動化のメリット

  • 属人性を排する

    • ボタンワンクリックでステージング構築できるくらいまで
    • オペレーションミスなくなる
  • すばやいDelivery

小さい単位でのデプロイ

  • なるべく小さな単位でプロダクションにデプロイしていくのが最近のトレンド

    • 【補】そのたびにサービス停止したらユーザーは怒るので、無停止メンテの仕組みが不可欠でしょうね
  • ロールバックの自動化も一緒に整備する
  • 本番リリース後にバグが発見されたら速やかに切り戻せる

リアルタイム監視も一緒に整備しよう

  • 速やかに切り戻せる仕組みを用意しました
  • 速やかにバグを見つけられないとあまり意味がない

ここまでのソフトウェアデプロイメント

  • 昔話
  • 手作業に則り丹精込めて手動オペレーション

    • 学習コスト
    • オペレーションミスのリスク
    • オペレーションコスト
    • 心的ハードル
  • デプロイでしくじったら高度な切り分けが始まる

    • オペレーションミス?
    • デプロイ先の環境側に何か問題?
    • 複数の変更をデプロイしたらさらに深刻
  • エンジニアの本分は、サービスを開発し価値を届けることなのに…本末転倒
  • 【注意】オペレーションを自動化した場合でも、中身を理解すること自体は重要

コンテナベースのビルド&デプロイ

  • ローカル開発環境からプロダクション環境まで一貫してコンテナベースで運用することによるメリット

インフラレイヤの変更を伴う際のフロー

  • インフラレイヤの変更

    • 言語やフレームワークのバージョンアップ
    • 新しいライブラリの導入
  • インフラエンジニアとの調整コストが甚大
  • 環境の数だけ行う必要がある

    • 開発
    • ステージング
    • プロダクション
  • しくじると、「本番でのみ起こる不具合」が生じる

Immutable Infrastracture

  • コンテナ以前の時代のサーバー管理

    • 既存環境を上書きする
    • 構成管理ツールで冪等性を保つ

      • Chef
      • Ansible
    • 構成管理ツールでインフラを完璧にコード化するのは難しい

      • HotFix的に適用した構成変更は、いつ誰が本家に反映するのか?
    • 一つほころびが生じるともはや意味を失う

      • 必ずフローに組み込む
      • 「運用でカバー」
  • コンテナ

    • 新しい環境との入れ替え

      • 古い環境を変更しない … Immutable
    • ローカル開発環境で動作確認済のものにすげ替えるだけ
    • ロールバックも容易

OSレイヤまでコードで管理できるからローカルから移送できる

  • OSからアプリケーションまでをイメージとしてパッケージング
  • 迅速・効率的にソフトウェア開発サイクルを回していけるようになる

    • ブラックボックスだった部分がコード化され変更可能に
    • アプリケーション開発者はOSレイヤも含めたアプリケーション実行環境全体に責任を持つことが出来るようになる
  • Microservice Architecture

    • サービス単位にチーム編成
    • 言語・環境はチームごとに自由にハンドリング
    • コンテナ運用と相性が良い

コンテナのデプロイサイクル

  • ポータビリティ高い

    • ローカル開発環境で動いたものはクラウドサーバー上でも動く

コンテナデプロイの一般的なフロー

  1. Dockerイメージをbuild
  2. Dockerイメージをリポジトリにpush

    • DockerHub
    • Amazon ECR
  3. 最新のDockerイメージをもとにコンテナ入れ替え

コンテナのデプロイを楽にするオーケストレーションツール

  • 数百数千のコンテナをオーケストレーションツール無しで管理するのは無理ゲー

コンテナオーケストレーションツールが行ってくれること

最新のDockerイメージをもとにコンテナ入れ替え

  • イメージのbuild、リポジトリへのpushは別途実施する必要がある

    • CIのタスク等で

多機能なコンテナオーケストレーションツール

  • コンテナのヘルスチェック
  • コンテナのセルフヒーリング
  • コンテナを役割ごとにグルーピング

    • ECSのServiceとか
    • KubernetesのReplicaSetとか
  • コンテナの負荷に応じたオートスケール
  • 実行ホストマシンをクラスタとしてグルーピング
  • ロードバランサとの連携

    • rolling updateとかできる