購入した書籍「インフラCI実践ガイド」を試した際のメモの続きです。
第10章の「インテグレーションからデリバリーへ」と第11章の「自動化を超えて継続的改善へ」になります。いよいよ最後です。
ここまでかなり道のりが長くて大変でした(特に8章と9章）
10.1 CIとCD
CIとCDの違いについて整理してみましょう。
CIでは1サイクルが回ると「利用可能な成果物」が作成されます。
CDにおける1サイクルが完了すると1回のデリバリーが行われて、本番で利用可能な環境が構築されます。ただし、この環境は必ずしも本番環境でなければならないわけではなく、本番環境の場合もあれば、ステージング環境、テスト環境のケースもあります。
これはプロジェクトやシステムのどの領域にインフラCI/CDが適用されるかによって異なります。
10.1.1 CDのサイクル
デリバリーのブランチとパイプライン
第9章ではシステムテストのためのstagingというブランチを作成していますが、同様にデリバリー用のproductionブランチを準備します。
これらのブランチでは、dev->master->staging->productionとマージリクエストが流れてきます。
さらに進んだデリバリー方法
チケットをトリガーにデリバリーする以外にも、定期的にデリバリーを実施する場合もあります。
運用ポリシーとして1度構築したシステムを30日以上運用しないというルールを定めているプロジェクトもある。
システムを長期で利用しているとどうしても様々なズレが生じるためです。
10.1.2 デリバリーとリリース
CDを実践するうえで意識すべきなのは「デリバリー」と「リリース」の境界です。
デリバリーは環境を整備して使える状態にすること
リリースはこの環境を利用者に開放すること
リリースとCI/CDの適用範囲
リリースにおいて考慮すべき事項は2つあります。ひとつは「リリースが簡単に行える」ということです。リリース方法が複雑であれば無理にCDまで実践する必要はないでしょう。
リリースのパイプライン
もうひとつは「リリース作業をCI/CDのパイプラインへ組み込むか、組み込まないか」ということです。
ただし、組み込む場合には全体のパイプラインに高い完成度が求められます。ここまでのレベルを最初から実践することが難しいのは想像できるでしょう。
その一歩前の段階としてリリース用のプロジェクト(リポジトリ)を作成して、CI/CDとは別の独立したパイプラインを構成する方法があります。
10.2 代表的なデリバリーとリリース方式
10.2.1 Blue/Greenデプロイメント
最も代表的なデリバリー方式です。
2つの同じ環境を構築して、ロードバランサーなどでリリース後に本番環境を切り替えていう方式です。
ダイナミックインフラストラクチャとの組み合わせ
Blue/Greenデプロイメントはダイナミックインフラストラクチャの上では驚くほど簡単におこなうことができます。クラウドのオーケストレーターを利用することで、システムの構成情報をコード化しておき、簡単に本番と同一のグリーン系を作成することが可能になるからです。
Blue/GreenとImmutable
ブルー系が破棄されずに役割が入れ替わるような場合を「Blue/Greenデプロイメント」と呼び、旧環境に対しては変更を行わずに旧環境を破棄して毎回新規環境を構築する方法を「イミュータブル(Immutable)デプロイメント」と呼びます
10.2.2 カナリアリリース
この方法は現在の本番環境の隣に新しい本番環境を準備します。ここまではBlue/Greenデプロイメントと同じですが、リリース方法が異なります。
リリース時は段階的にトラフィックを旧環境から新環境へ移していきます。問題がないことを確認しながら徐々に新環境へ移行します。
ダークカナリアリリース
リリースの際に一部の開発者やプロジェクトメンバー、もしくは同一企業の社員などの特定の利用者を意図的に新環境に分配する方法をダークカナリアリリースといいます。
大規模環境でのカナリアリリース
カナリアリリースは、大規模なシステムで本番に近いシステムテスト環境が準備できない場合に有効に活用できます。
10.3 使い捨てにできない本番環境への対処
ここまでのインフラCI/CDはクラウドネイティブといえるシステムを対象とした話でした。
「環境を使い捨てにできない」システムも世の中には数多く存在します。
一つのケースとしてテスト環境を使ったCIまでは実施できるが、デリバリーとリリースは唯一無二の本番環境に対して実施するしかないという状況を想定します。
10.3.1 本番環境へ変更を積み重ねる
自動化による環境の再現
初期構築はこれまでのCIと同じです。構成定義ファイルを開発し、ユニットテスト、インテグレーションテストを実施します。
本番環境が変わっていった場合もその差分となる作業を積み重ねた構成定義ファイルを作成していきます。
運用での回避の必要性
人がズレを持ち込む可能性を排除するため直接ログオンを禁止して、すべての操作を自動化とパイプラインを経緯してのみ行うようにする、などの対応が考えられます。
また、1年に1回などの比較的長いスパンで本番環境をゼロから再構築し、蓄積されたズレをリセットするのも有効です。
システム外の変化を考慮する
手順のなかで外部からリソースやデータを取得するようなケースには十分な検証が必要です。
典型的な例としてはパッケージのバージョンアップによる依存があります。
バージョンを固定した場合は、あらゆるパッケージのバージョンを明記する必要が出てきます。この方法は現実的ではありません。
対応方法として、システムの外側にある要因をシステムへ取り込む方法があります、具体的にはリポジトリサーバーをシステム専用として準備する方法です。
10.3.2 ブランチとパイプラインによる変更の再現
過去の作業を保存する
使い捨てができない環境の場合は、過去におこなった手順は未来でも必ず同じ手順を追い粉わなければならないという点です。
ブランチを使うことで対応できます。リリース時のブランチを更新禁止としておくことで「過去に行われた作業」を保存しておくことができます。
10.4 サイクルを改善するためのフィードバック
10.4.1 インフラCI/CDのサイクルから得られる情報例
さまざまな情報がインフラCI/CDのサイクルを行うことで自動的に蓄積されます。
チケットの平均クローズ時間
オープン状態とクローズ状態のチケット件数の推移
アサインされた担当者がチケットをクローズした数
パイプラインの実行時間
パイプラインの実行回数
テスト件数
パイプラインのエラー発生箇所と頻度
10.4.2 ビジネスとの乖離を防ぐ
プロジェクトに貢献しないインフラCI/CDには意味がありません。
インフラCI/CDを回すこと自体が目的になってしまいがちだからです。
10.5 まとめ
CIをCDに発展させていく方法とその注意点、使い捨てにできない環境への対応、そしてサイクルを改善するための情報源について解説しました。
特に押さえておくべきポイントは「簡単にリリース可能」なシステムをあらかじめ設計しておくという部分です。
11.1 インフラCIとは
演習した内容を振り返ります。
5章では、手順を自動化する方法について解説しました。手作業をプログラムに置き換えることで「何度でも同じ環境を再現できる」ことができるようになります。
6章では、テストを自動化する方法について解説しました。記述した構成定義ファイルの確かさを検証するため、コードレビュー、ユニットテスト、インテグレーションテストを実施します。
第7章では、自動テストをパイプラインへと組み込み、開発時に守るべき手続きをシステム化してメンバーへと強制しました。
第8章では、チームとしてインフラCIのサイクルを回すための手法について解説しました。タスクをチケットとして発行して作業を行う関係者間での情報共有を実現しました。そして、ブランチを使って本番と開発コードを分離し、マージリクエストによってコミュニケーション取りながら成果物の品質を高めていきます。
第9章では、システムテストを組み込む方法と、より変化に強い成果物を作るためにコンテナイメージを作成する方法を解説しました。
これらの演習を通じて身につけた方法を利用すると、インフラエンジニアの業務にはどのような効果があるのでしょうか。
インフラの作業には2つの大きな工程がありました。「準備作業や検証」と「実際の変更作業」です。
この2つに対して手順書の作成や動作確認テストなどの準備作業や検証を効率化してくれるのが「インフラCI」であり、実際の作業を効率化してくれるのが「インフラCIの成果物である自動化」です。
従来は作業の準備に多くの工数が費やされていましたが、インフラCIにより大幅に効率化できることで、2つの工程を含めた全体のサイクルを細かく短く回せるようになります。
この効果があるからこそ継続的な改善を行い、システムの「変化への対応」を実現できるようになります。これは単純に手順を自動化に置き換えただけでは実現できないことにはもうお気づきのはずです。
このように、どこに、何が、どういう理由で効果があるかを理解したうえで、インフラCIを適用していきましょう。
11.2 インフラCIの限界
インフラCIは開発手法のひとつでしかありません。
インフラに対する知識は依然として必要です。システムの可用性や性能など、非機能要件を考慮してインフラをデザインすることは依然として必要です。
むしろ、直接サーバーやストレージ、ネットワーク機器をさわる機会が少なくなるため、インフラの基礎知識というものはより重要になるといえます。
11.3 どこから始めるのか
インフラCIを始めるうえで最も難しいのが「どこから手を付けるか」という点です。
「故に上兵は謀を伐つ、其の次は交を伐つ、其の次は兵を伐つ、其の下は城を攻む」
①簡単にできるところでまずは小さくインフラCIを実践する
②やり方を覚えたうえで、難しい箇所は簡単にできるように環境を変える
③その経験を活かして、初めから簡単にインフラCIができるシステムを作る
「新規仮想マシンの払い出し作業」や「ネットワークへのルーティング追加作業」「サーバーの設定変更作業」など
作業内容を詳細に可視化する際に「バリューストーム」という手法も利用できます。
個人の感想
ようやく「インフラCI実践ガイド」を完読することができました。
当初想定していたものよりもかなりボリュームのある内容だったので演習にもやっとついていったという感じです。
しかし、そのおかげでこれまでもやっとしていたインフラにCIを適用する部分がかなり明確化されて理解できるようになってきた気がします。
特に感じたのはチーム全体として最低限GitやDockerなどのスキルをもっていることが必須ということです。
私のメンバーにいる半分以上のインフラエンジニアはプログラム開発はしたことがなく、Gitを使ったことがなかったり、DockerやAnsibleのようなPlaybookで使われているYAML形式などになじみがないメンバーです。
まずはそのようなメンバーを少しずつ教育しながら私の理解も深めていくことが優先かなと感じました。
実際にチームでインフラCIのサイクルが回せて、効率化や品質の確保などなどのインフラCIのメリットを感ることができて、他チームなど周りにも広めていくことができれば・・・
そのレベルまで道のりは長そうですがコツコツとやってみたいと思います。
今回は以上となります。
記事をまとめました。
コメント