LFCA: コンテナの基本概念を学ぶ - パート22
時間が経つにつれ、アプリケーションの迅速なテストと展開に対する需要が高まり、ビジネスサイクルが速くなる中で、組織は迅速なビジネス環境に対応するために革新することを余儀なくされました。
アプリケーションを現代化し、新しいアプリケーションを構築して機敏なワークフローを生み出すという探求は、コンテナを使用するという概念につながりました。コンテナ化技術は、仮想化とほぼ同じくらい古いものです。しかし、コンテナは2013年にDockerが登場するまで大きな興奮を呼ぶことはありませんでした。そして、それは開発者や他のIT専門家たちの間で狂乱的な関心を呼び起こしました。
現在、Google、Amazon、Microsoft、Red Hatなどのすべての巨大技術企業がこの流行に乗っています。
なぜコンテナなのか?
開発者が直面した課題の1つは、ソフトウェア開発の各段階でのコンピューティング環境の違いです。ソフトウェア環境が段階ごとに異なると、問題が発生します。
例えば、アプリケーションはPython 3.6を使用しているテスト環境で問題なく動作します。しかし、Python 3.9を実行している生産環境に移行すると、アプリケーションは奇妙な動作をし、エラーが返されたり、全くクラッシュしたりします。
コンテナはこの課題に対処し、アプリケーションがソフトウェア開発の各段階 - 開発者のPCから生産環境まで - で、あるコンピュータ環境から別のコンピュータ環境に移動した際にも信頼性を持って実行されることを保証するために登場しました。そして、こうした不整合を引き起こすのはソフトウェア環境だけでなく、ネットワークのトポロジーやセキュリティポリシーの違いもあります。
コンテナとは何ですか?
コンテナは、すべてのバイナリコード、ライブラリ、実行可能ファイル、依存関係、および設定ファイルを単一のパッケージにまとめた隔離されたソフトウェアユニットであり、アプリケーションが異なるコンピューティング環境に移植されるときにスムーズに動作するようになっています。オペレーティングシステムのイメージを持たないため、軽量で簡単に移植可能です。
コンテナイメージは、アプリケーションを実行するために必要なすべてをバンドルしたスタンドアロンで軽量な実行可能パッケージです。実行時には、コンテナイメージはコンテナに変換されます。例えば、Dockerの場合、DockerイメージはDocker Engine上で実行されるとドッカーコンテナになります。Dockerは、コンテナ化されたアプリケーションを構築するために使用される実行環境です。
コンテナは基盤となるオペレーティングシステムから完全に隔離されて実行され、コンテナ化されたアプリケーションは、計算環境やインフラストラクチャに関係なく、一貫して実行されます。このため、開発者はこのラップトップの快適さからアプリケーションを開発し、サーバーに簡単にデプロイできるのです。
コンテナの一貫性と信頼性は、開発者に安心感を与え、アプリケーションが展開される場所に関係なく、期待通りに動作することを保証します。
コンテナは仮想マシンとどのように異なりますか?
コンテナと仮想マシンが共有する一般的な点は、どちらも仮想化環境で動作するということです。コンテナ化は、ある意味では仮想化技術の一形態です。しかし、コンテナは複数の点で仮想マシンと異なります。
仮想マシン
仮想マシンは、仮想インスタンスとも呼ばれ、略してVMと呼ばれるもので、物理サーバーやPCのエミュレーションです。仮想化は、仮想マシンを作成することを可能にする技術です。仮想化の概念は1970年代初頭に遡り、最初のクラウド技術の基盤を築きました。
仮想化では、ベアメタルサーバーやコンピュータハードウェアの上に抽象化層が作成されます。これにより、単一サーバーのハードウェアリソースを複数の仮想マシンで共有することが可能になります。
抽象化層を作成するために使用されるソフトウェアは、ハイパーバイザーと呼ばれます。ハイパーバイザーは、仮想マシンとゲストOSを実際のハードウェアから抽象化します。したがって、仮想マシンはハイパーバイザーの上に位置し、抽象化層のおかげでハードウェアリソースが利用可能になります。
仮想マシンは、ハイパーバイザーがインストールされている基盤となるオペレーティングシステム(ホスト OS)とは独立した完全なオペレーティングシステム(ゲスト OS)を実行します。ゲスト OS は、そのライブラリやバイナリと一緒にアプリケーションを構築、テスト、展開するためのプラットフォームを提供します。
ハイパーバイザーには2種類あります。
タイプ1ハイパーバイザー(ベアメタルハイパーバイザー)
このハイパーバイザーは、物理サーバーまたは基盤となるハードウェアに直接インストールされます。ハイパーバイザーとコンピュータハードウェアの間にオペレーティングシステムは存在せず、そのためベアメタルハイパーバイザーと呼ばれています。リソースがホストオペレーティングシステムと共有されないため、優れたサポートを提供します。
効率性のため、タイプ1ハイパーバイザーは主に企業環境で使用されます。タイプ1ハイパーバイザーのベンダーにはVMware EsxiやKVMが含まれます。
タイプ2ハイパーバイザー:
これはホスティングされたハイパーバイザーとも見なされます。これはホストオペレーティングシステムの上にインストールされ、ホストOSと基盤となるハードウェアリソースを共有します。
タイプ2ハイパーバイザーは、小規模なコンピュータ環境に最適で、主にオペレーティングシステムのテストや研究に使用されます。タイプ2ハイパーバイザーのベンダーには、Oracle VirtualBoxやVMware Workstation Proが含まれます。
仮想マシンの欠点
仮想マシンはサイズが非常に大きく(数GBを占めることもあります)、起動と停止が遅く、システムリソースを大量に消費するため、リソースが制限されているとハングアップやパフォーマンスの低下を引き起こすことがあります。そのため、仮想マシンは重く、管理コストが高いとされています。
コンテナ
仮想マシンとは異なり、コンテナはハイパーバイザーを必要としません。コンテナは物理サーバーとそのオペレーティングシステムの上に位置し、他のライブラリやバイナリなどのOSと同じカーネルを共有します。複数のコンテナが同じシステム上で実行でき、各コンテナは他のコンテナとは異なるアプリケーションやプロセスのセットを実行します。人気のあるコンテナプラットフォームにはDockerやPodmanがあります。
仮想マシンとは異なり、コンテナは基盤となるオペレーティングシステムから完全に隔離されて動作します。コンテナは非常に軽量で、数メガバイト程度のサイズしかなく、より少ないスペースを使用し、リソースに優しいです。起動と停止が簡単で、仮想マシンよりも多くのアプリケーションを扱うことができます。
コンテナを使用する利点
コンテナは、PCからオンプレミスまたはクラウドの本番環境にアプリケーションを設計、テスト、デプロイするための便利な方法を提供します。ここでは、コンテナ化されたアプリケーションを使用することのいくつかの利点を挙げます。
1. より大きなモジュラリティ
コンテナが登場する前は、フロントエンドとバックエンドのコンポーネントを含む1つのアプリケーション全体が単一のパッケージにまとめられる、古風なモノリシックモデルがありました。コンテナのおかげで、アプリケーションを相互に通信できる複数の個別のコンポーネントに分割することが可能になりました。
このようにして、開発チームはアプリケーション同士の相互作用に関して大きな変更が加えられない限り、アプリケーションのさまざまな部分で協力することができます。
これがマイクロサービスの概念の基礎です。
2. 生産性の向上
モジュール性が高まることで、生産性も向上します。なぜなら、開発者はアプリケーションの個々のコンポーネントに取り組むことができ、以前よりも遙かに速くエラーをデバッグできるからです。
3. 削減されたオーバーヘッドコスト
仮想マシンや他の従来のコンピューティング環境と比較して、コンテナはオペレーティングシステムを含まないため、システムリソースを少なく使用します。これにより、アプリケーションを構築およびテストするための高価なサーバーを調達する無駄な支出を回避できます。
4. ポータビリティの向上
その小さなフットプリントのおかげで、コンテナ化されたアプリケーションは複数のコンピュータ環境やオペレーティングシステムに簡単にデプロイできます。
5. より高い効率性と柔軟性
コンテナはアプリケーションの迅速な展開とスケーリングを可能にします。また、複数のソフトウェア環境でアプリケーションを展開するために必要な柔軟性も提供します。
コンテナはDevOpsチームにどのように役立ちますか?
コンテナはDevOpsにおいて重要な役割を果たしており、コンテナ化されたアプリケーションがなければ状況を想像することは不可能です。それでは、コンテナは何をもたらすのでしょうか?
まず、コンテナはマイクロサービスアーキテクチャを支えており、アプリケーション全体の基本要素を独立して開発、展開、スケーリングできるようにします。これにより、より大きなコラボレーションと迅速なアプリケーションの展開が可能になります。
コンテナ化は、アプリケーションを構築するための制御された一貫した環境を提供することによって、CI/CDパイプラインを促進する上で重要な役割を果たします。すべてのライブラリと依存関係は、迅速かつ容易なデプロイのために、コードとともに1つの単位にパッケージ化されます。テストされたアプリケーションは、本番環境にデプロイされる正確なソフトウェアです。
さらに、コンテナはアプリケーションを複数のマイクロサービスに分割し、それぞれを別々のコンテナで実行することで、パッチや更新の展開を強化します。個々のコンテナは、アプリケーションの残りの部分を中断することなく、調査、パッチ適用、再起動が可能です。
結論
成熟したDevOpsを達成しようとする組織は、アジャイルでシームレスなデプロイのためにコンテナの力を活用することを検討すべきです。課題は、それらを複数の環境にどのように設定し、保護し、シームレスにデプロイするかを理解することです。


