【ITニュース解説】DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 2

開発を進める上で、作ったアプリケーションをきちんと動かし、世の中に公開するまでには多くの作業が必要になる。この記事では、アプリケーション開発の次のステップとして、より本番環境に近い形でプロジェクトを準備する方法を解説する。具体的には、GitHubというコード管理サービスと連携し、自動的にテストやビルド、デプロイを行うための仕組み、つまり「CI/CDパイプライン」を構築する。また、アプリケーションをどこでも一貫して動かせるようにするための「コンテナ化」技術、そして開発環境を簡単に立ち上げるためのツールについても学ぶことができる。これらの技術は、現代のソフトウェア開発において「DevOps」と呼ばれる考え方の中心であり、コードを書く開発者と、それを運用するチームとの連携をスムーズにし、高品質なソフトウェアを素早く提供するために不可欠な要素である。

まず、開発したコードを自動的にチェックし、本番環境にデプロイするまでの流れを自動化する「GitHub Actions CI/CDパイプライン」の構築から始める。これは、コードがGitHubにプッシュされたり、変更を提案するプルリクエストが出されたりするたびに、自動的に設定された一連のタスクを実行する仕組みである。このパイプラインは、まずコードの品質をチェックするリンティング、プログラムの誤りを検出するテスト、そして潜在的な脆弱性を探すセキュリティ監査を実行する。これらのチェックが全て問題なく通れば、次にアプリケーションを「Dockerイメージ」という形でパッケージ化し、GitHubのコンテナレジストリという場所に保存する。このイメージは、アプリケーションとその実行に必要な全てを一つにまとめたもので、どこでも同じように動作することを保証する。さらに、ビルドされたイメージに対して脆弱性スキャンを行い、セキュリティ上の問題がないかを確認する。そして最後に、開発用ブランチ（develop）への変更は「ステージング環境」へ、本番用ブランチ（main）への変更は「本番環境」へ、自動的にアプリケーションをデプロイする。この一連の自動化されたプロセスは、手動での介入を最小限に抑え、コードが常にテストされ、安全にパッケージ化され、デプロイの準備が整っている状態を保つ。

次に、アプリケーションをコンテナ化するための「Dockerfile」の作成について解説する。Dockerfileは、Dockerイメージを構築するための指示書であり、アプリケーションをどのような環境で、どのように実行するかを詳細に定義する。この記事で作成するDockerfileは、イメージのサイズを最小限に抑えるための「マルチステージビルド」という手法を用いる。これは、まず開発に必要なツールを含んだイメージで依存関係をインストールし、その後、実行に必要なものだけを別の軽量なイメージにコピーすることで、最終的なイメージの肥大化を防ぐものである。また、セキュリティを高めるために、アプリケーションを「非rootユーザー」として実行する設定や、アプリケーションの健康状態を監視するための「ヘルスチェック」、そしてコンテナが安全に停止するための「シグナルハンドリング」の仕組みも組み込む。これらの設定により、アプリケーションはどこでも一貫して、より安全に、そして信頼性高く動作するようになる。

プロジェクトの設定を円滑に進めるための重要な設定ファイルも作成する。.dockerignoreファイルは、Dockerイメージをビルドする際に、不要なファイルをイメージに含めないようにするためのリストである。これにより、ビルド時間を短縮し、イメージサイズを小さく保つことができる。.gitignoreファイルは、Gitで管理しないファイル（例えば、自動生成されるログファイルや一時ファイル、開発環境固有の設定ファイルなど）を指定し、リポジトリが不要な情報で cluttered になるのを防ぐ。.env.exampleは、環境変数の設定例を提供するファイルで、アプリケーションが動作するために必要な設定値（ポート番号やログレベルなど）をチーム内で共有しやすくする。最後に、.eslintrc.jsファイルは、コードの書き方を統一するための「ESLint」というツールを設定する。これにより、複数の開発者が関わるプロジェクトでも、コードの品質と一貫性を保つことができる。

ローカル環境での開発を簡単にするために、「Docker Compose」というツールも導入する。Dockerfileが単一のアプリケーションをコンテナ化する方法を定義するのに対し、Docker Composeは複数のコンテナを連携させて動かすことを容易にする。docker-compose.ymlというファイルに、アプリケーションのコンテナだけでなく、もしデータベースなどの別のサービスが必要な場合もまとめて定義できる。このファイルを使えば、たった一つのコマンドで、アプリケーションのビルドから起動までをまとめて行い、複雑な開発環境を簡単に立ち上げ、停止することができる。

これらの準備が整ったら、実際にコードをGitHubにプッシュし、構築したCI/CDパイプラインが動作するかを確認する。最初のプッシュ後、セキュリティスキャンでエラーが発生するかもしれない。これは、スキャンツールが参照しようとしたイメージタグがまだ存在していなかったためである。この問題を解決するには、ci.ymlファイルを修正し、スキャンツールがビルドジョブによって実際に作成された正確なイメージタグを参照するように変更する。この修正をGitHubにプッシュすると、パイプラインが再実行され、セキュリティスキャンが正常に機能するはずである。

さらに、アプリケーションをKubernetesというコンテナオーケストレーションシステムにデプロイするための設定ファイルも準備する。k8s/staging/deployment.ymlとk8s/production/deployment.ymlという二つのファイルを作成し、それぞれステージング環境と本番環境でのアプリケーションの動作方法を定義する。これらのファイルでは、アプリケーションの複数のコピー（レプリカ）をどのように動かすか、アプリケーションが使用できるCPUやメモリの量、そしてアプリケーションの健康状態を監視する方法（livenessProbeとreadinessProbe）などを指定する。ステージング環境では2つのレプリカ、本番環境では3つのレプリカを設定し、本番環境ではリソースの要求と制限も定義することで、安定した運用を目指す。また、外部からアプリケーションにアクセスできるようにするためのServiceも定義し、LoadBalancerタイプを使用することで、自動的に負荷分散される設定とする。

最後に、これらの設定を使って完全なデプロイワークフローを体験する。developブランチにコードをプッシュすると、CI/CDパイプラインが自動的にトリガーされ、アプリケーションがステージング環境にデプロイされる。ステージング環境で問題がないことを確認した後、developブランチの変更をmainブランチにマージしてプッシュすると、今度はCI/CDパイプラインが本番環境へのデプロイを自動的に実行する。この流れを通じて、コードの変更が自動的にテストされ、コンテナ化され、ステージングから本番へと安全にリリースされるプロセスを体験できる。デプロイの状況はGitHub Actionsのページで確認でき、GitHubのコンテナレジストリでビルドされたイメージも確認できる。最終的に、デプロイされたアプリケーションが正常に動作しているか、健康チェックのエンドポイントにアクセスすることで確認することができる。

これらのステップを通して、開発したアプリケーションを自動的にテスト、ビルド、デプロイし、セキュリティを確保しながら、安定した運用を行うための現代的なDevOpsワークフローを構築する。これは、コードを書くことから、それが実際にユーザーに届くまでの一連の流れを効率的かつ確実にするための重要な知識と技術であり、現代の多くの開発チームで実践されている手法である。この経験を通じて、変更がリポジトリにプッシュされるたびに、アプリケーションが自動的にテストされ、ビルドされ、デプロイされるというDevOpsの核心を理解し、自信を持ってプロジェクトを進められるようになるだろう。