DevSecOpsを学ぶ

第5章. デプロイに向けて動き出す

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、コードのリリースとデプロイに関わる要素のいくつかを検討する。この章は、構成ファイルをコードとして管理することの概要から始まる。そうすることで、プロジェクトやサービスに必要なファイルを含む集中リポジトリを作成するという、ソースコード管理（SCM）と同じ利点が得られる。DevSecOpsを考えるとき、構成をコードとして管理することは、左遷の基本である。構成ファイルは、開発環境から本番環境まで、あらゆる環境で使用することができる。

この章では、コンテナ化、特にDockerについて説明を続ける。コンテナ化は、テストとデプロイが本質的に再現可能である、分離されたマイクロサービスアーキテクチャを促進する。構成をコードとして管理するのと同様に、コンテナ化によって再現性が迅速かつ容易になる。開発環境でデプロイされた同じコンフィギュレーションとコンテナを、テスト環境と本番環境にデプロイすることができる。最後に、この章では、ブルーグリーンデプロイ戦略と、DevSecOps の成熟度を高めるために組織を前進させるための次のステップについて簡単に説明する。

コードとしての構成とソフトウェア部品表（SBOM）を管理する

開発者によって作成されたコードは、 プロジェクトの一部として、GitのようなSCMツールを使って管理される。SCMツールでコードを管理することで、新機能の追加やバグの修正に伴うコードの変更を追跡することができる。最も基本的なこととして、コードは、コードが書かれた言語に関係なく、単なるテキストファイルである。Rust、Perl、Pascal、あるいはどんな言語で書かれたコードも、最初はテキストファイルとして始まる。

ソースコードとしてのインフラがテキストファイルであるように、最新のインフラではサービスの振る舞いを構成するファイルもテキストファイルである。例えば、nginxやApacheのようなウェブサーバの構成ファイルは、サーバの振る舞い、リッスンするポート、利用可能なサイト、その他の振る舞いを決定する特定の構文とキーワードを持つテキストファイルである。ソースコードの変更と同じように、サービスのコンフィギュレーションも、新機能の追加や開発者からの変更要求、その他コンフィギュレーション変更の同様の理由によって変更される。SCMを使って構成ファイルを管理することには、ソースコードを管理するのと同じ利点がある。変更を時系列で追跡し、デプロイツールを使って管理し、必要に応じて既知の良いバージョンにロールバックすることができる。

リポジトリの構造化構成ファイルの構造化は、運用環境とインフラによって大きく異なる。たとえば、本番環境と同じ構成ファイルの内容を必要とする品質保証環境があるかもしれないが、本番データベースの資格情報やホスト名などは例外である。

リポジトリ構造の1つのメソッドは、環境ごとに構成ファイルを格納することである。この構造では、意図せず構成ファイルが異なってしまう可能性がある。例えば、テスト環境のウェブサーバの設定に変更が必要な場合、その変更を他の環境に手動で反映させる必要がある。もしその変更が含まれていなければ、プロジェクトが本番環境に向かうときに、他の環境の停止時間につながるかもしれない。

アプリケーションごとのリポジトリ構造を使用することで、環境ごとのリポジトリによる環境の懸念を軽減することができる。例えば、ウェブサーバの構成をトップレベルを ...