Docker ContainersとContainer Cloud Services
コンテナは、アプリケーションのすべてのコードと依存関係を標準形式でパッケージ化するパッケージ形式であり、コンピューティング環境全体で迅速かつ確実に実行できます。Dockerのコンテナは、ライブラリ、システムツール、コード、ランタイムなど、アプリケーションの実行に必要なすべてのものを含む、人気のある軽量のスタンドアロンの実行可能なコンテナです。Dockerは、開発者がコンテナ化されたアプリケーションをすばやく構築、テスト、および導入できるようにするソフトウェアプラットフォームでもあります。
Containers as a Service (CaaS) またはコンテナサービスは、コンテナのライフサイクルを管理するマネージド・クラウドサービスです。コンテナサービスは、コンテナの実行時間を調整（開始、停止、スケーリング）するのに役立ちます。コンテナサービスを使用すると、アプリ開発と導入のライフサイクルを簡素化、自動化、および加速できます。
Dockerとコンテナサービスは急速に採用されており、過去数年間で大きな成功を収めています。2013年のほとんど知られていないかなり技術的なオープンソーステクノロジーから、Dockerは、多くのOracle Enterprise製品で正式にサポートされるようになった標準化されたランタイム環境に進化しました。
Dockerの使用者
Dockerはオープンなアプリ開発フレームワークで、DevOpsと開発者に利益をもたらすように設計されています。Dockerを使用すると、開発者は、アプリケーションを軽量でポータブルな自給自足のコンテナとして簡単に構築、パック、出荷、および実行でき、事実上どこでも実行できます。コンテナを使用すると、開発者はアプリケーションをそのすべての依存関係とともにパッケージ化し、単一のユニットとして導入できます。構築済みで自立したアプリケーションコンテナを提供することにより、開発者は、基盤となるオペレーティングシステムや導入システムを気にすることなく、アプリケーションコードに集中して使用できます。
さらに、開発者は、Dockerコンテナ内で実行するようにすでに設計されている何千ものオープンソースのコンテナアプリケーションを活用できます。DevOpsチームの場合、Dockerは継続的インテグレーションと開発ツールチェーンに役立ち、アプリケーションを導入および管理するためにシステムアーキテクチャ内で必要な制約と複雑さを軽減します。コンテナ・オーケストレーション・クラウドサービスの導入により、すべての開発者は、コンテナ化されたアプリケーションを開発環境でローカルに開発し、それらのコンテナ化されたアプリケーションを、管理されたKubernetesサービスなどのクラウドサービスで本番環境に移動して実行できます。
Docker 対 Kubernetes
Linuxコンテナは2008年からありましたが、2013年にDockerコンテナが登場するまではあまり知られていませんでした。Dockerコンテナの登場により、コンテナ化されたアプリケーションの開発と導入への関心が爆発的に高まりました。コンテナ化されたアプリケーションの数が複数のサーバーに展開され、数百もののコンテナにまたがるようになり、それらの操作はより複雑になりました。何百ものコンテナをどのように調整、スケーリング、管理、スケジュールしますか？そこで、Kubernetesが役立ちます。Kubernetesは、Dockerコンテナとワークロードを実行できるオープンソースのオーケストレーションシステムです。複数のサーバーに展開された複数のコンテナを拡張するために移動する場合、操作の複雑さを管理するのに役立ちます。Kubernetesエンジンは、コンテナのライフサイクルを自動的に調整し、ホストしているインフラストラクチャ全体にアプリケーションコンテナを分散します。Kubernetesは、需要に応じてリソースをすばやくスケールアップまたはスケールダウンできます。コンテナの状態を継続的にプロビジョニング、スケジュール、削除、および監視します。
Dockerの基本
Dockerのコアコンセプトは、イメージとコンテナです。Dockerのイメージには、ソフトウェアの実行に必要なすべてのものが含まれています。コード、ランタイム（たとえば、Java Virtual Machine (JVM)、ドライバー、ツール、スクリプト、ライブラリ、導入など。
Dockerコンテナは、Dockerイメージの実行中のインスタンスです。ただし、タイプ1またはタイプ2のハイパーバイザーを使用した従来の仮想化とは異なり、Dockerのコンテナはホストのオペレーティングシステムのカーネルで実行されます。図1に示すように、Dockerイメージ内には個別のオペレーティングシステムはありません。
図1
分離 対 仮想化
Dockerコンテナはすべて、独自のファイルシステム、独自のネットワークスタック（したがって、独自のIPアドレス）、独自のプロセススペース、およびCPUとメモリの定義済みリソース制限があります。Dockerのコンテナはオペレーティングシステムを起動する必要がないため、すぐに起動します。Dockerは、仮想化とは対照的に、分離、つまりホストのオペレーティングシステムのリソースの分離、つまりホストのオペレーティングシステム上にゲストオペレーティングシステムを提供することです。
VM 対 Kubernetes - 導入インフラストラクチャ
図2
インクリメンタルファイルシステム
Dockerイメージのファイルシステムは、コピーオンライトのセマンティクスで階層化されています。これにより、継承と再利用が可能になり、ディスク上のリソースが節約され、イメージの増分ダウンロードが可能になります。
図2に示すように、WebLogic導入を使用したDockerイメージは、Oracle WebLogic Serverドメインを使用したイメージに基づくことができ、Oracle Linuxのベースイメージに基づくJava Development Kit ( JDK) イメージに基づいています。
Dockerレジストリ
Dockerイメージは簡単に作成でき、開発者はDockerイメージのシンプルさと移植性を気に入っていますが、数千のDockerイメージの管理が非常に難しいことにすぐに気付きました。Dockerレジストリはこの課題に対処します。Dockerレジストリは、Dockerイメージを保存および配布するための標準的な方法です。レジストリは、任意のApacheライセンスに基づくオープンソースベースのリポジトリです。
Dockerレジストリは、リポジトリに保存されているDockerイメージのアクセス制御とセキュリティの向上にも役立ちます。画像の配布を管理し、アプリ開発ワークフローと統合することもできます。開発者は、独自のDockerレジストリを設定するか、Docker、Oracle Container Registry、Azure Container RegistryなどのホストされたDockerレジストリサービスを使用できます。
Docker Hubは、Dockerによって管理されるホストされたDockerレジストリです。Docker Hubには、ソフトウェアベンダー、オープンソースプロジェクト、およびコミュニティからの100,000を超えるコンテナイメージがあります。Docker Hubには、Nginx、Logstash、Apache HTTP、Grafana、MySQL、Ubuntu、Oracle Linuxなどの公式リポジトリのソフトウェアとアプリケーションが含まれています。
コンテナを起動すると、ローカルで利用できない場合、デフォルトでDockerは対応するイメージをパブリックDocker Hubから自動的に引き出します。さらに、独自のイメージを作成して、それらをDocker Hubのパブリックリポジトリまたはプライベートリポジトリにプッシュすることもできます。
図3
マイクロサービス・ランタイムとしてのDocker
モノリシックアプリケーションをマイクロサービスの小さなチャンクに分割するというアイデアは、最近、ソフトウェア開発者の間で大きな注目を集めています。
マイクロサービスはプロセスとして独立して導入され、軽量プロトコルを使用して相互に通信し、すべてのサービスがそのデータを所有します[7]。マイクロサービスは分散型ガバナンスアプローチに従うため、かなり大量のインフラストラクチャの自動化、自動化されたテスト、完全に自動化されたCDパイプライン、および熟練したアジャイルなDevOpsチームが必要です。
このアーキテクチャスタイルについてはまだ多くの議論がありますが、マイクロサービスに分解されたアプリケーションを一連のプロセスとして簡単に操作できると考えるのは単純すぎます。いくつかの要件を挙げれば、マイクロサービスはホストに依存せず、オペレーティングシステムレベルで分離されている必要があります。リソース制限内で実行し、スケールアップおよびスケールダウンし、失敗した場合は再起動し、ソフトウェア定義のネットワーク層を介して検出して他のマイクロサービスに接続する必要があります。
したがって、Dockerコンテナでマイクロサービスを実行すると、これらの目標のほとんどを達成するための優れた出発点になります。
Docker—2つの重要な側面
Dockerは、ソフトウェアの構築、出荷、実行の方法を2つの異なる次元で変更します。
- これにより、開発から本番までアプリケーションを確実に取得するプロセスが強化されます。
- オンプレミスからクラウドに移行するための標準の画像形式を提供します。
両方の次元については、次の段落で詳しく説明します。
Dockerのイメージ開発から生産まで
すべての依存関係を含むDockerイメージを作成すると、「開発マシンでは機能しました」という問題が解決します。重要なアイデアは、DockerイメージがGitなどのソースコードリポジトリからビルドパイプラインによって自動的に作成され、最初に開発環境でテストされることです。この不変のイメージは、Dockerレジストリに保存されます。
図4に示すように、同じイメージが、さらなる負荷テスト、統合テスト、受け入れテストなどに使用されます。すべての環境で、同じイメージが使用されます。本番データベースのJDBC URLなど、小さいながらも必要な環境固有の違いを、環境変数またはファイルとしてコンテナにフィードできます。
図4
統計によると、現在のすべてのDockerユースケースの65％が開発中であり、48％が継続的インテグレーションにDockerを使用しています[5]。
クラウドからオンプレミス
Dockerは、パブリッククラウドの採用を変更しました。一方では、Dockerイメージを使用して、歴史上初、オンプレミスおよびすべての主要なクラウドプロバイダーで実行できる共通のパッケージ形式が存在します。Dockerコンテナは、Oracle Cloudで実行されるのと同じ方法でノートパソコンで実行されます。
一方—Dockerコンテナはすべての主要なパブリッククラウドで実行されるため、パブリッククラウドに対する長期にわたる偏見を克服するための主要な貢献です。ベンダーロックイン。現在、すべての主要なクラウドプロバイダーがDockerをPaaSとして提供しています。
Dockerのバージョン—基盤となるテクノロジーの成熟度
Dockerのリリースのペースは、従来のエンタープライズソフトウェアのリリースサイクルよりもはるかに高速です。Dockerリリースのペースの速さと、Dockerプロジェクトの新しさにより、Dockerのセキュリティと安定性について懸念が生じることがあります。
Dockerとそのコマンドライン、Dockerデーモン、そのAPI、およびDocker Swarm、Docker Machine、Docker Composeなどのツールは過去3年間でのみ進化しましたが、基盤となるカーネル機能は10年近くにわたりすべてのLinuxカーネルで利用可能になっています。
コンテナテクノロジーの早期導入の顕著な例がGoogleです。Googleは、Dockerが登場する前から、Linuxコンテナを使用してきました。さらに、Googleはすべてをコンテナ内で実行します。Googleは週に20億個のコンテナを開始すると推定されています[3]。
Cgroupsと名前空間の履歴
Dockerが使用する基本的なLinuxカーネル機能は、cgroupと名前空間です。2008年に、以前にGoogle開発者によって行われた作業に基づいてcgroupがLinuxカーネルに導入されました[1]。Cgroupは、一連のオペレーティングシステムプロセスのリソース使用量を制限および考慮します。
Linuxカーネルは、名前空間を使用して、プロセスのシステムリソースを相互に分離します。最初の名前空間、つまりマウント名前空間は、早くも2002年に導入されました。
Container Cloud Services
この記事の最初の部分では、いくつかの重要なDockerの概念について説明しました。ただし、本番環境では、Dockerコンテナでアプリケーションを実行するだけでは不十分です。
本番環境をセットアップして運用するには、コンテナを実行するためのハードウェアが必要です。Dockerなどのソフトウェアは、リポジトリやクラスターマネージャーとともに、インストール、アップグレード、およびパッチを適用する必要があります。複数のDockerコンテナがホスト間で通信する場合は、ネットワークを作成する必要があります。クラスター化されたコンテナは、失敗した場合は再起動する必要があります。さらに、相互にリンクされたコンテナのセットは、単一の論理アプリケーションインスタンスと同じくらい簡単に導入できる必要があります。この例としては、ロードバランサー、いくつかのWebサーバー、管理サーバー、管理対象サーバー、およびデータベースを備えたいくつかのOracle WebLogic Serverインスタンスがあります。コンテナ化されたアプリケーションを大規模に管理するには、KubernetesやDocker Swarmなどのコンテナのオーケストレーションシステムが必要です。Kubernetesのようなオーケストレーションシステムの展開、管理、運用は、困難で時間がかかる場合があります。
開発者がコンテナ化されたアプリケーションを簡単かつ効率的に作成できるようにするために、クラウドプロバイダーはContainer Cloud ServicesまたはContainers as a Service（CaaS）を提供しています。Container Cloud Servicesは、開発者と運用チームがコンテナのライフサイクルを自動化された方法で合理化および管理するのに役立ちます。これらのオーケストレーションサービスは、通常Kubernetesを使用して構築され、DevOpsチームがコンテナ化されたアプリケーションを大規模に管理および運用することを容易にします。Oracle Container Engine for KubernetesとAzure Kubernetesサービスは、人気のあるコンテナのオーケストレーション管理Cloud Serviceの2つの例です。
Oracle Container Engine for Kubernetesは、コンテナ化されたアプリケーションをクラウドに導入するために使用できる、完全に管理され、スケーラブルで、可用性の高いサービスです。開発チームがクラウドネイティブアプリケーションを確実に構築、導入、管理したい場合は、Container Engine for Kubernetes（単にOKEと略されることもあります）を使用します。
OracleからのDockerイメージ—以下は、オラクル製品のDockerイメージを取得または構築するためのいくつかのソースです。DockerイメージのOracle GitHubリポジトリには、オラクル商用製品およびオラクルがスポンサーとなっているオープンソースプロジェクトのDockerイメージを構築するためのDockerfilesとサンプルが含まれています。
Dockerハンズオンラボ—Dockerによるコンテナ化された開発
参考文献
- Cgroups（ウィキペディア）
- Linux名前空間（ウィキペディア）
- Googleのすべてがコンテナで実行されます、ジャック・クラーク
- Docker Hubが50億プルにヒット
- 現代のソフトウェアサプライチェーンの進化、2016年 Docker Survey
- MOS Doc ID 2216342.1：Oracle DBのDockerサポート
- マイクロサービス、マーティン・ファウラー
- Oracle Container Engineとレジストリのデモ（3:13）
- Container Engine for Kubernetesの資料