コンテナは、アプリケーションのすべてのコードと依存関係を標準形式でパッケージ化するパッケージ形式であり、コンピューティング環境全体で迅速かつ確実に実行できます。Dockerのコンテナは、ライブラリ、システムツール、コード、ランタイムなど、アプリケーションの実行に必要なすべてのものを含む、人気のある軽量のスタンドアロンの実行可能なコンテナです。Dockerは、開発者がコンテナ化されたアプリケーションをすばやく構築、テスト、および導入できるようにするソフトウェアプラットフォームでもあります。
Containers as a Service (CaaS) またはコンテナサービスは、コンテナのライフサイクルを管理するマネージド・クラウドサービスです。コンテナサービスは、コンテナの実行時間を調整(開始、停止、スケーリング)するのに役立ちます。コンテナサービスを使用すると、アプリ開発と導入のライフサイクルを簡素化、自動化、および加速できます。
Dockerとコンテナサービスは急速に採用されており、過去数年間で大きな成功を収めています。Dockerは、2013年、ほとんど知られておらず、かなり技術的なオープンソース・テクノロジーでしたが、現在、オラクルの多くのエンタープライズ製品で公式にサポートされている標準的なランタイム環境に進化しています。
コンテナ・テクノロジーを活用するアプリケーションを開発、出荷、および実行するために設計されたソフトウェア・コンテナ・プラットフォーム。Dockerには、Enterprise EditionとCommunity Editionの2つがあります。
コンテナは、ハードウェア仮想化を実行するVMと異なり、ユーザー空間を抽象化して、軽量でオペレーティングシステムレベルの仮想化を実行します。コンテナはホスト・システムのカーネルを他のコンテナと共有します。ホスト・オペレーティング・システムで動作するコンテナはコードとそのすべての依存関係をパッケージする標準的なソフトウェア単位であるため、アプリケーションは環境間で迅速で確実に動作できます。コンテナは、非永続的であり、イメージからスピンアップされます。
コンテナを構築および実行するオープンソースのホスト・ソフトウェア。Dockerエンジンは、さまざまなWindows Server、およびOracle Linux、CentOS、Debian、Fedora、RHEL、SUSE、UbuntuなどのLinuxオペレーティング・システム上のコンテナをサポートするクライアントサーバー・アプリケーションとして機能します。
Dockerプラットフォームで実行できるコンテナを作成するための手順を含むコンテナとして実行されるソフトウェアの集合。イメージは不変であり、イメージを変更するには、新しいイメージを構築する必要があります。
イメージを保存およびダウンロードする場所。レジストリはDockerイメージを保存および配布するステートレスでスケーラブルなサーバーサイド・アプリケーションです。
Dockerはオープンなアプリケーション開発フレームワークで、DevOpsと開発者に利益をもたらすように設計されています。Dockerを使用すると、開発者は、アプリケーションを軽量でポータブルな自給自足のコンテナとして簡単に構築、パック、出荷、および実行でき、事実上どこでも実行できます。コンテナを使用すると、開発者はアプリケーションをそのすべての依存関係とともにパッケージ化し、単一のユニットとして導入できます。構築済みで自立したアプリケーションコンテナを提供することにより、開発者は、基盤となるオペレーティングシステムや導入システムを気にすることなく、アプリケーションコードに集中して使用できます。
さらに、開発者は、Dockerコンテナ内で実行するようにすでに設計されている何千ものオープンソースのコンテナアプリケーションを活用できます。DevOpsチームの場合、Dockerは継続的インテグレーションと開発ツールチェーンに役立ち、アプリケーションを導入および管理するためにシステムアーキテクチャ内で必要な制約と複雑さを軽減します。コンテナ・オーケストレーション・クラウドサービスの導入により、すべての開発者は、コンテナ化されたアプリケーションを開発環境でローカルに開発し、それらのコンテナ化されたアプリケーションを、管理されたKubernetesサービスなどのクラウドサービスで本番環境に移動して実行できます。
コンテナは、どのような開発者もパッケージできます。ソフトウェア業界では、開発者をフロントエンド、バックエンド、またはその中間という専門性で分類することがよくあります。バックエンドの開発者がコンテナをパッケージすることがほとんどですが、CaaSの基本コンセプトをよく理解していれば、誰でもソフトウェア開発ライフサイクルのこの特定の領域に成功できます。アプリケーションの依存関係をパッケージする準備ができる前に、developer.oracle.comをチェックし、アプリケーションまたはプログラムの構築に使用できるツールをよく理解してください。
Linuxコンテナは2008年からありましたが、2013年にDockerコンテナが登場するまではあまり知られていませんでした。Dockerコンテナの登場により、コンテナ化されたアプリケーションの開発と導入への関心が爆発的に高まりました。コンテナ化されたアプリケーションの数が複数のサーバーに展開され、数百もののコンテナにまたがるようになり、それらの操作はより複雑になりました。何百ものコンテナをどのように調整、スケーリング、管理、スケジュールしますか?そこで、Kubernetesが役立ちます。Kubernetesは、Dockerコンテナとワークロードを実行できるオープンソースのオーケストレーションシステムです。複数のサーバーに展開された複数のコンテナを拡張するために移動する場合、操作の複雑さを管理するのに役立ちます。Kubernetesエンジンは、コンテナのライフサイクルを自動的に調整し、ホストしているインフラストラクチャ全体にアプリケーションコンテナを分散します。Kubernetesは、需要に応じてリソースをすばやくスケールアップまたはスケールダウンできます。コンテナの状態を継続的にプロビジョニング、スケジュール、削除、および監視します。
Dockerのコアコンセプトは、イメージとコンテナです。Dockerイメージには、コード、ランタイム(Java仮想マシン(JVM)など)、ドライバ、ツール、スクリプト、ライブラリ、デプロイメントなど、ソフトウェアの実行に必要なすべてが含まれています。
Dockerコンテナは、Dockerイメージの実行中のインスタンスです。ただし、タイプ1またはタイプ2のハイパーバイザーを使用した従来の仮想化とは異なり、Dockerのコンテナはホストのオペレーティングシステムのカーネルで実行されます。図1に示すように、Dockerイメージ内には個別のオペレーティングシステムはありません。
Dockerコンテナはすべて、独自のファイルシステム、独自のネットワークスタック(したがって、独自のIPアドレス)、独自のプロセススペース、およびCPUとメモリの定義済みリソース制限があります。Dockerのコンテナはオペレーティングシステムを起動する必要がないため、すぐに起動します。Dockerは、仮想化とは対照的に、分離、つまりホストのオペレーティングシステムのリソースの分離、つまりホストのオペレーティングシステム上にゲストオペレーティングシステムを提供することです。
Dockerイメージのファイルシステムは、コピーオンライトのセマンティクスで階層化されています。これにより、継承と再利用が可能になり、ディスク上のリソースが節約され、イメージの増分ダウンロードが可能になります。
図2に示すように、WebLogic導入を使用したDockerイメージは、Oracle WebLogic Serverドメインを使用したイメージに基づくことができ、Oracle Linuxのベースイメージに基づくJava Development Kit (JDK) イメージに基づいています。
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のパブリックリポジトリまたはプライベートリポジトリにプッシュすることもできます。
モノリシックアプリケーションをマイクロサービスの小さなチャンクに分割するというアイデアは、最近、ソフトウェア開発者の間で大きな注目を集めています。
マイクロサービスはプロセスとして独立して導入され、軽量プロトコルを使用して相互に通信し、すべてのサービスがそのデータを所有します。マイクロサービスは分散型ガバナンスアプローチに従うため、かなり大量のインフラストラクチャの自動化、自動化されたテスト、完全に自動化されたCDパイプライン、および熟練したアジャイルなDevOpsチームが必要です。
このアーキテクチャスタイルについてはまだ多くの議論がありますが、マイクロサービスに分解されたアプリケーションを一連のプロセスとして簡単に操作できると考えるのは単純すぎます。いくつかの要件を挙げれば、マイクロサービスはホストに依存せず、オペレーティングシステムレベルで分離されている必要があります。リソース制限内で実行し、スケールアップおよびスケールダウンし、失敗した場合は再起動し、ソフトウェア定義のネットワーク層を介して検出して他のマイクロサービスに接続する必要があります。
したがって、Dockerコンテナでマイクロサービスを実行すると、これらの目標のほとんどを達成するための優れた出発点になります。
Dockerは、ソフトウェアの構築、出荷、実行の方法を2つの異なる次元で変更します。
両方の次元については、次の段落で詳しく説明します。
すべての依存関係を含むDockerイメージを作成すると、「開発マシンでは機能しました」という問題が解決します。重要なアイデアは、DockerイメージがGitなどのソースコードリポジトリからビルドパイプラインによって自動的に作成され、最初に開発環境でテストされることです。この不変のイメージは、Dockerレジストリに保存されます。
図4に示すように、同じイメージが、さらなる負荷テスト、統合テスト、受け入れテストなどに使用されます。すべての環境で、同じイメージが使用されます。本番データベースのJDBC URLなど、小さいながらも必要な環境固有の違いを、環境変数またはファイルとしてコンテナにフィードできます。
統計によると、現在のすべてのDockerユースケースの65%が開発中であり、48%が継続的インテグレーションにDockerを使用しています。
Dockerによって、パブリック・クラウドの導入は変化しました。一方、Dockerイメージによって、歴史上初めて、すべての主要なクラウド・プロバイダーだけでなく、オンプレミスでも実行できる共通のパッケージ形式が存在するようになりました。Dockerコンテナは、Oracle Cloudで実行されるのと同じ方法でノートパソコンで実行されます。
一方Dockerコンテナはすべての主要なパブリッククラウドで実行されるため、パブリッククラウド、ベンダー・ロックインに対する長期にわたる偏見を克服するための主要な貢献です。現在、すべての主要なクラウドプロバイダーがDockerをPaaSとして提供しています。
Dockerのリリースのペースは、従来のエンタープライズソフトウェアのリリースサイクルよりもはるかに高速です。Dockerリリースのペースの速さと、Dockerプロジェクトの新しさにより、Dockerのセキュリティと安定性について懸念が生じることがあります。
Dockerとそのコマンドライン、Dockerデーモン、そのAPI、およびDocker Swarm、Docker Machine、Docker Composeなどのツールは過去3年間でのみ進化しましたが、基盤となるカーネル機能は10年近くにわたりすべてのLinuxカーネルで利用可能になっています。
コンテナテクノロジーの早期導入の顕著な例がGoogleです。Googleは、Dockerが登場する前から、Linuxコンテナを使用してきました。さらに、Googleはすべてをコンテナ内で実行します。Googleは1週間に数十億個のコンテナを起動していると言われています。
Dockerが使用する基本的なLinuxカーネル機能は、cgroupと名前空間です。2008年、Googleの開発者が以前行った作業に基づいて、cgroupsがLinuxカーネルに導入されました。1Cgroupは、一連のオペレーティングシステムプロセスのリソース使用量を制限および考慮します。
Linuxカーネルは、名前空間を使用して、プロセスのシステムリソースを相互に分離します。最初の名前空間、つまりマウント名前空間は、早くも2002年に導入されました。2
この記事の最初の部分では、いくつかの重要な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と略されることもあります)を使用します。
コンテナは、どのような開発者もパッケージできます。ソフトウェア業界では、開発者をフロントエンド、バックエンド、またはその中間という専門性で分類することがよくあります。バックエンドの開発者がコンテナをパッケージすることがほとんどですが、CaaSの基本コンセプトをよく理解していれば、誰でもソフトウェア開発ライフサイクルのこの特定の領域に成功できます。アプリケーションの依存関係をパッケージする準備ができる前に、developer.oracle.comをチェックし、アプリケーションまたはプログラムの構築に使用できるツールをよく理解してください。
オラクル製品のDockerイメージを入手または構築するためのソースは次のとおりです。DockerイメージのOracle GitHubリポジトリには、オラクル商用製品およびオラクルがスポンサーとなっているオープンソースプロジェクトのDockerイメージを構築するためのDockerfilesとサンプルが含まれています。