開発環境の作成とコンテナ
第1回でも解説した通り、Dockerを利用したコンテナ環境の構築はDockerfileを作成してコマンドを実行するだけで開発者自らが環境構築できる。プロジェクト開始時にインフラの準備を待つ必要なく、開発作業を素早く立ち上げることが可能だ。コンテナで環境を作成すると、簡単に開発用の端末でコンテナプロセスを立ち上げることもでき、コードの実行とテストを行うために共用の開発環境にデプロイして挙動を確認する必要がなくなる。コーディングと手元での実行、単体テストを細かく行うことができるため、開発の生産性が向上する。
加えて、テスト用のDBなどもスタブとしてコンテナを用意し、同時にローカルで実行することで、他の開発者のテストに影響を受けることなく、自分のコードの検証をローカルで実行し、効率よく開発を進めることが可能となるのも大きなメリットだ。また、Dockerに慣れている開発者であれば、手順書不要でDockerfileを配布するだけで開発環境を数分で立ち上げることが可能となる。
また、同じDockerfileを利用し環境構築を行うことができるため、開発者の机上では正しく動作したのに、テスト環境や本番環境では設定が違うために想定外の動作をしてしまう、というよくある環境差異の課題も回避できる。
CI/CDとコンテナ
CI/CDとは、Continuous Integration（継続的インテグレーション）とContinuous Delivery（継続的デリバリー）を組み合わせた言葉で、アプリケーション開発におけるビルドやテスト、デプロイを自動化し、短期間、高頻度で安全にソフトウェアデリバリーすることを可能とするためのものだ。これらの概念とコンテナとの関わりを解説していく。
Continuous Integrationとコンテナ
一般的な開発において、アプリケーションのソースコードを作成または修正した場合、自分でビルドして開発環境などでテストを行い、アプリケーションの動作を確認するという作業が日々発生しており、かなりの時間を割いているケースが多い。また、チームで開発する場合は、複数の開発者が同時に同じアプリケーションのソースコードを変更することも多く、他のエンジニアの意図しない変更にともなう不正な挙動や、テスト実行のための共用の開発環境の取り合いという課題も発生している。
Continuous Integrationにおいては、ツールを利用することでソースコードレポジトリのコードが変更されるたびにビルド、テストを自動で実行し、開発作業の省力化と、不具合の早期発見を目指す。ここで使用するテスト環境としてコンテナの環境を利用することで、複数の変更が同時に発生しても、変更ごとにDockerfileで作成された別々の環境を立ち上げてテストを行うことが可能となるため、不具合の早期発見を実現することができる。
Continuous Deliveryとコンテナ
今までのデプロイ作業は、利用しているミドルウェアごとにデプロイの方法が違い、デプロイ作業も自動化されていないことが多く、手動でインフラ担当者がデプロイ作業を、アプリケーション開発者が動作確認を実施し、ロールバック作業に備えて完了まで待機している、という手間も人手もかかる作業だったため、数ヵ月に一度まとめて行われるということが多かった。Continuous Deliveryにおいて、コンテナを利用することでコンテナイメージの差し替えという形でデプロイ方法を統一化することができ、デプロイ作業自体もツールで自動化することで人の手を介さないデプロイ作業を実現することが可能となる。また、ロールバックもツールにより自動で前のバージョンのコンテナに差し替えることが可能となり、インフラ担当者の関与は不要でアプリケーションのデプロイを行うことが可能となる。
上記のようにCI/CDを開発現場に取り入れ、短期間、高頻度なソフトウェアデリバリーを目指す際にはコンテナの採用は不可欠なものとなっており、コンテナを採用することで、これらの効果を最大化することができる。
