DevOps、CI/CDパイプラインでもコンテナは大活躍!

コンテナとDevOps

前回まで、本連載ではコンテナの登場から、その概要、コンテナの実行基盤であるコンテナエンジン「Docker」、そしてコンテナのオーケストレーションツール「Kubernetes」について紹介してきました。

今回は、コンテナが利用される場面に焦点を当て、「DevOps」と「CI/CDパイプライン」におけるコンテナの活用について紹介していきます。

DevOpsのはなし

冒頭からいきなり登場した「DevOps」と「CI/CD」ですが、これらはそもそも何でしょうか。まず、その概念から説明します。

DevOpsとは

DevOps(「デブオプス」と読みます)とは、システム導入においてソフトウェア開発(Development)と運用(Operations)が互いに協力することで、システム開発のライフサイクルを短縮し、高品質なソフトウェアを提供し続けることを目的とした考え方です。

これは、DevOpsの説明として一般的に使われているものですが、私の知る限り厳密な定義を見つけることはできていません。

また、Wikipediaによると、オーストラリア連邦科学産業研究機構(CSIRO)とソフトウェア工学研究所に所属する3人のコンピュータサイエンス研究者、Len Bass、Ingo Weber、Liming ZhuがDevOpsの定義を「高い品質を確保しつつ、システムへの変更をコミットしてから通常の運用に移るまでの時間を短縮することを目的とした一連のプラクティス」とすることを提案しているそうです(図1)。

結局、「DevOpsとは何か」について私の解釈でお話しすると、「システム開発のプロセスにおいて役割がサイロ化されることにより発生する課題を解決するための考え方」になります。

「サイロ化」とは、企業のある部門が他の部門と情報共有や連携をせず独自に業務を遂行し、孤立した状態になることを指します。サイロ化された部門では、図2に示すような課題が発生します。

DevOpsは、これらの課題を解決するために生まれました。モノづくりの最初から各役割の組織が連携して進めていくことで組織間の不要な対立に労力をかけるのではなく、全体最適を考慮したモノづくりを目指す考え方であると言えます(図3)。

DevOpsの成り立ち

ここまで組織のサイロ化について触れましたが、システムを提供するうえでソフトウェア開発(Dev)と運用(Ops)との隔たりがに課題があることが分かったのでないでしょうか。そこで、なぜそのような隔たりができてしまったのか、DevOpsの歴史と成り立ちを見ていきたいと思います。

DevOpsは、ソフトウェア開発手法の発展(歴史)の中で発生した課題から生み出されたものなのです(図4)。

従来のソフトウェア開発の手法では、ウォーターフォール開発と呼ばれる手法が主流でした。リリースまでの工程を上流から下流まで予め定義しておき、上流から順に進めていく手法で、原則として前工程が完了しないと次の工程に進むことはできません(図5)。

一方で、2001年にアメリカ・ユタ州に集まった17名の技術者・プログラマーらによりアジャイルソフトウェア開発が提唱されたことに始まり、アジャイル開発という手法が使われるようになりました(図6)。

DevOpsの考え方は、2008年以降のAgile ConferenceやVelocity Conferenceが起源とされています。

●Agile 2008 conference
ベルギーのITコンサルタントPatrick Debois氏が「Agile Infrastructure & Operations」というプレゼンテーションの中で、運用(Operations)と開発(Dev)の意図的な分離について議論されるところから始まる。

●Velocity 2009 - O’Reilly Conferences
2009年にFlickrのエンジニア(John Allspaw氏, Paul Hammond氏)によって発表された「10 Deploys per Day: Dev and Ops Cooperation at Flickr(1日10回のデプロイ：FlickerにおけるDevとOpsの協力)」というプレゼンテーションがDevOpsという言葉を生み出すきっかけとなったと言われている。

DevOpsにおけるDockerの活用

これまで解説してきたように、DevOpsの考え方で重要なのは「開発(Development)と運用(Operations)を隔てる壁をなくし、ソフトウェア開発のライフサイクルを効率化し、質の高いシステムを迅速かつ継続的に届けることでビジネス価値を高める」ことです。

このDevOpsの考え方は、実はコンテナ技術との相性がとても良く、今回のもう1つのテーマである「CI/CD」というプラクティスにとてもよく表われています。

CI/CDとは

ここからは、CI/CDについて解説します。

開発者は、アプリケーションのソースコードを作成または修正した場合、自分でビルドしてテストを実施し、アプリケーションが仕様通りに動作することを確認します。開発中のアプリケーションでは、この一連の作業が日々発生するほか、大規模なアプリケーションであれば、複数の開発者が同時に同じアプリケーションのソースコードに手を入れることも日常茶飯事です。

このような状況で、開発者が自分の書いたソースコードのみを個々にテストするだけで、アプリケーションの修正や機能追加が正しくできたと言えるのでしょうか。アプリケーションは、多くのソースコードで作られた機能が連携して正しく動作します。この状態を保持するには、不具合の混入を早期に発見し対処する必要があります。このように、複数の開発者で実装したソースコードを常に最新の状態に保ち、アプリケーション全体で正しく機能する状態を維持するための考え方がCI/CDです。

CI(Continuous Integration)継続的インテグレーション

ソースコードを変更したらすぐにビルド・テストをします。複数の開発者でアプリケーション開発をする場合、ソースコードの変更を管理するバージョン管理ツールを使用します。CIはバージョン管理ツールへのソースコードのコミットをトリガーに、ビルド、単体テスト実施の流れを自動化し、容易に繰り返し実行できるようにします。

ソースコードを変更する度にビルドと単体テストの実行を自動化することで、プログラムの修正や機能追加に対する不整合を早期に発見し、バグを見落とす事態を防ぐことができます。また、自動化により開発者の定常作業の効率化を見込むことができます。

CD(Continuous Delivery)継続的デリバリー

CDは、修正や変更を加えてCIを完了したアプリケーションを定期的にテスト環境へ配置し、常に動作可能な最新の状態のアプリケーションを維持するプロセスを自動化します。ちなみに、同じCDでも、実際に本番環境にリリースするまでのプロセスをも自動化したアプローチを継続的デプロイ(Continuous Deploy)といいます。

このように、CI/CDによってアプリケーション変更のリリースをより迅速にすることで、ビジネス価値を高めることがDevOpsの考え方の1つです(図7)。

DockerはCI/CDと仲良し

一般的に、CI/CDはデリバリーまでを指すことが多いですが、そこにDockerを組み込むことで、より迅速にアプリケーションを提供できるようになります。

第2回や第3回でも解説した通り、Dockerをはじめとしたコンテナ技術のメリットは、アプリケーションをHWやOSから切り離して可搬性を高めるところにあります。

開発者の机上からテスト環境、本番環境へと複数の環境で開発されたアプリケーションは、実行環境(HWやOSおよびその設定)が異なることで、開発者の机上ではきちんと動作したのにテスト環境や本番環境では想定外の動作をしてしまう、なんてこともよくある話です。

DockerやKubernetesに代表されるコンテナ技術は、環境の差異を吸収し、開発、テストしたアプリケーションを実際に稼動する本番環境で同じように動作させることができます。

CI/CDのプロセスでは、継続的にビルド、テスト、デリバリーを繰り返すため、起動の早いDockerコンテナは、それだけでCI/CDプロセスの短縮に役立ちます。また、継続的にデリバリー(デプロイ)先はテスト環境や本番環境であり、可搬性の高いDockerコンテナであれば、その環境差異にも容易に対応できるわけです。

Dockerを使ったCI/CD

それでは、CI/CDのプラクティスをコンテナベースのアプリケーションに適用する場合、どのようなプロセスで実現できるのでしょうか。

先ほどの図7で言うと、Dockerを使用する場合はテストプロセス以降でDockerが登場します。順番に見ていきましょう(図9)。

開発者は、変更したソースコードをバージョン管理ツールのソースコードリポジトリ(GitHubなど)にコミットします。すると、ビルドパイプラインツール(Jenkinsなど)により自動的にビルドとテストが実行され、テスト済みのアプリケーションを取得できます。もちろん、各プロセスでエラーがあれば、メールやチャットツール(Slackなど)ですぐにま開発者へ通知することもできます。

次は、いよいよDockerイメージの作成とコンテナの生成です。第3回の図8で解説したプロセスにおいて、テスト済みアプリケーションを含めたDockerイメージを作成する流れになります(図10)。

ビルドパイプラインツールは、テストが完了したアプリケーションを含むDockerイメージを作成し、Dockerリポジトリ(Docker Hubなど)にプッシュします。その後、そのDockerイメージはテスト環境に移され、コンテナの生成と動作が可能となります。

このプロセスではDockerリポジトリが重要な役割を果たしています。ビルドパイプラインツールがDockerリポジトリと連携することで、Dockerイメージの作成からテスト環境上でのコンテナ生成と起動までをCI/CDのプロセスの中にうまく組み込むことができます。

自動化は大事

CI/CDのプロセスは全て定型作業なので、ビルドパイプラインツールで自動化することが前提です。しかし、CI/CDの考え方が登場する以前は、そのプロセス1つ1つを開発者が毎回手動で行っていました。

Dockerベースのアプリケーションで、配置までのプロセスも含めすべて手動で行おうとすると、品質を保ったままリリース頻度と速度を上げることはとても難しくなります。

このように、軽量で起動が早く環境差異を吸収してくれるDockerは、自動化されたCI/CDのプロセスにおいて、そのメリットが最大化されることがお分かりいただけたのではないでしょうか。

環境の用途によらずDockerベースの環境であれば、コンテナの可搬性を生かしたデプロイが可能です。Dockerを使うことで、Dockerベースの複数の環境を同じ構成で構築して常に最新の状態に維持することはもちろん、CI/CDのメリットである不具合の早期発見による品質向上、自動化による作業効率と作業スピード向上をより確固たるものにできます。その結果、ユーザにアプリケーションの価値を迅速に提供できるのです。

DevOpsの考え方にハマるツール

最後に、CI/CDのプラクティスを実現する代表的なツールを紹介します。なお、コンテナについては前回までに紹介しているので割愛します。

●GitHub/Subversion
いわずと知れた、ソースコードのバージョン管理ツールです。CI/CDはこのツールでソースコードをリポジトリにコミットするところから始まります。

●Jenkins
CI/CDのビルドパイプラインツールです。CI/CDの中心的な役割を果たします。開発者が手作業で行う一連の作業を、コマンドの組み合わせで簡単に自動化できます。

●Docker Hub
Dockerリポジトリといえばこれでしょう。プライベートでもパブリックでも利用できます。

●AWS CodePipeline
AWSで使用できるビルドパイプラインツールです。インフラ部分も含めて構築、テスト、デプロイを自動化します。GitHubやJenkinsとの統合もサポートされています。

●Azure DevOps
Azure Pipelines、Azure Repos、Azure Test Plansなどの複数のサービスの総称です。GitHubやDockerとの統合もサポートされています。

●Ansible
OSやHWの設定をコード化(yaml形式)し、状態を定義することで、インフラ部分の構築を自動化し冪等性を保つ構成管理ツールです。近年インフラ構築界隈で急速に普及しています。ビルド工程でインフラ構築をCI/CDに組み込む際にかなり強力なツールとなります。

●Serverspec
OSやミドルウェアの設定をテストするツールです。アプリケーション開発の単体テストにあたるテストをコード化することで、インフラ構築における設定の確認・テストを自動化して繰り返し実行できるようにします。

おわりに

今回は、DevOpsとそのプラクティスの1つであるCI/CD、DevOpsにおけるコンテナ活用について紹介しました。変化の激しいビジネス環境に対抗すべく、品質の高いシステムを迅速に提供する。そういったビジネスシーンにおいて、コンテナそしてCI/CDは、間違いなく大きな武器となり得るのではないでしょうか。