レガシーアプリケーションをコンテナ化する方法

はじめに

世界中の組織が、ソフトウェア配信にマイクロサービスベースのコンテナ主導のアプローチを採用しています。ただし、ほとんどのソフトウェアは、最新の画像ベースのコンテナが存在する前に設計および作成されました。

Dockerコンテナーデプロイメントモデルへの移行を計画している場合は、移行が既存のアプリケーションに与える影響を考慮する必要があります。

このチュートリアルでは、レガシーアプリケーションをコンテナ化するために必要な準備作業と基本的なDockerコマンドの概要を説明します。

レガシーアプリをコンテナ化する理由

コンテナソフトウェアの展開を採用する企業は、新しいコンテナワークフローのプロセスを反映するように組織を再構築する必要があります。コンテナ導入の潜在的なメリットを分析することは、アプリケーションに最適なアプローチを決定するのに役立ちます。

効率と移植性

コンテナーは通常数秒で開始されるため、コンテナーのデプロイメントは効果的なソリューションになる可能性があります。コンテナイメージには、すべてのバイナリ、ライブラリ、および依存関係が保持されます。つまり、環境固有の構成を追加する必要はありません。同じイメージが複数のシステム間で移植可能になりました。このイメージには環境上の制限がないため、展開の信頼性、移植性、拡張性が向上します。アプリケーションをコンテナ化することで、ファイルシステムとランタイムをそのホストから分離します。

保守性とスケーリング

大規模なモノリシックアプリケーションを管理する代わりに、複雑なアプリケーションがAPIを使用して相互に通信する小さな独立したプロセスで構成されるアーキテクチャパターンを作成します。

異なる環境間のアプリケーションの競合を解決することにより、開発者はソフトウェアと依存関係をIT運用および実稼働環境と共有できます。開発者とIT運用は緊密に結びついており、効果的にコラボレーションできます。コンテナワークフローは、DevOpsに必要な継続性を提供します。開発サイクルの早い段階で問題を特定できるため、後の段階で大規模なオーバーホールのコストを削減できます。

コンテナ管理ツール

サードパーティのコンテナ管理ツールは、コンテナ化されたアプリケーションのネットワーク、監視、および永続ストレージのメカニズムを提供します。レガシーアプリケーションは、Kubernetesなどの最先端のオーケストレーションフレームワークを利用できます。

これらのツールは、稼働時間と分析機能を改善し、アプリケーションの状態を簡単に監視できるようにします。

コンテナの計画

アプリケーションを正常に移行するには、コンテナーの性質と組み合わせてアプリケーションのニーズを調べる戦略を開発する必要があります。技術レベルでは、任意のアプリケーションをコンテナーにデプロイできます。レガシーアプリケーションをコンテナにデプロイするためのいくつかの可能な解決策があります：

1。レガシーアプリケーションを完全に書き直して再設計します。

2。単一のコンテナ内で既存のモノリシックアプリケーションを実行します。

3。新しい分散アーキテクチャを利用できるように、アプリケーションを拡張および再形成します。

選択したパスに関係なく、アプリケーションが最初にコンテナー環境にデプロイするのに適した候補であるかどうかを正しく識別することが重要です。アーキテクチャ、パフォーマンス、セキュリティに焦点を当てる必要があります。

アーキテクチャ

アプリケーションを個別のサービスに分解して、個別にスケーリングおよび展開できるようにする必要があります。コンテナの導入を最大限に活用するには、既存のアプリケーションを複数のコンテナに分割できるかどうかを判断してください。

理想的には、単一のプロセスを単一のコンテナに割り当てる必要があります。 cronジョブでさえ、個別のコンテナーに外部化する必要があります。これには、アプリのアーキテクチャのやり直しが必要になる場合があります。

パフォーマンス

アプリケーションに特定のハードウェア要件があるかどうかを判断します。コンテナは、基盤となるカーネルを分割するLinux機能を使用します。固有のパラメータを使用して個々のコンテナを構成するか、特定のリソースを提供する必要がある場合があります。

さらに、Dockerにはinitデーモンがないことを考慮してください。ゾンビプロセスをクリーンアップします。 dockerfileのENTRYPOINTとして必ず1つ指定してください。可能な軽量ソリューションとしてdumb.inoを検討してください。

セキュリティ

コンテナはVMよりも分離が少ないため、アプリケーションに必要なセキュリティのレベルを定義することが重要です。ユーザーアカウントとサービスアカウントの厳格な制約を設定します。シークレットとパスワードをコンテナイメージから分離し、最小特権の原則に準拠し、多層防御を維持してKubernetesクラスタを保護します。

永続メモリ要件

コンテナオーケストレーションでは、すべての永続データがコンテナの書き込み可能レイヤー内に保存されるわけではありません。代わりに、永続データは明確に定義された永続ボリュームに保存されます。このアプローチにより、永続的なデータによってコンテナーのサイズが大きくなることはなく、コンテナーのライフサイクルから独立して存在することが保証されます。

従来のアプリの永続データがファイルシステム全体に分散している場合、またはアプリケーション自体と共有されるパスに書き込まれる場合は、すべての永続データがファイルシステム内の単一のパスに書き込まれるようにアプリケーションを再構築することをお勧めします。これにより、アプリデータをコンテナ化された環境に簡単に移行できます。

サービスの外部化

外部化され、別々のコンテナーで実行される可能性のあるローカルサービスを特定します。キャッシングとデータベースサービスを探してください。これらは最も簡単に外部化できます。別の方法として、自分で構成および管理するのではなく、マネージドサービスを使用することもできます。

複数の環境用に画像を準備する

開発、QA、および本番環境では、単一のDockerイメージを使用することが期待されます。環境固有の構成変数を考慮に入れてください。何かを特定した場合は、デフォルトのアプリケーション構成ファイルを更新する起動スクリプトを作成する必要があります。

レガシーアプリケーションをコンテナにデプロイする

Dockerがシステム上で稼働していると仮定すると、Dockerイメージを作成する方法はいくつかあります。

空の画像を使用し、外部ファイルのセットをインポートしてレイヤーを追加します。
コマンドラインを使用して、個々のDockerコマンドをインタラクティブに入力し、 docker commitで新しいイメージを作成します 。
複雑な展開には、高度な構成管理ツール（PuppetやChefなど）を採用します。
既存のベースイメージを使用し、Dockerfileで一連のコマンドを指定します。

Dockerfileは、コンテナーランタイムを使用してイメージを作成する方法を理解するための優れた出発点です。間違えた場合は、1つのコマンドでファイルを簡単に修正し、新しいコンテナイメージを作成できます。

レガシーアプリDockerfile

Dockerfileは、一連のコマンドが厳密な順序で実行される単純なテキストファイルです。 Dockerfileは通常、既存のイメージに基づいており、いくつかの追加設定があります。コマンドラインインターフェイスを使用して、ビルドに必要なファイルを含むディレクトリを作成します。

mkdir ImageForLegacyApp

cd ImageForLegacyApp

ビルドプロセスが開始されると、そのディレクトリ内のファイルがDockerデーモンに送信されます。ファイルの数を制限することで、ビルドプロセスを高速化し、ディスク容量を節約します。

ImageForLegacyApp 内に、コーディングまたはプログラミング（vimを使用）に使用するテキストエディターを使用して、空のDockerfileを作成します。ディレクトリ：

vim Dockerfile

次のビルド手順は、単純なPHPアプリケーション用です。まず、PHPとApacheがインストールされたオペレーティングシステムをプルします。

FROM php:apache

FROM Dockerfileの最初の命令です。ベースイメージを定義します。この例では、PHPとApacheがインストールされたDebianOSです。ベースイメージの特定のバージョンが必要な場合は、必ず対応するタグを使用してください（たとえば、 php：7.0-apache 。

COPY ./var/www/html

COPYを使用します PHPコードを画像にコピーするコマンド。 ADDを使用します tar抽出が必要な場合は、代わりにコマンドを実行してください。

WORKDIR /var/www/html

これにより、作業フォルダーが定義されます。以降のすべてのコマンドは、このフォルダーに適用されます。

EXPOSE 80

EXPOSEでリッスンするアプリケーションのポートを設定します 指図。イメージを開始し、実行中の1つを別のコンテナーにリンクすると、公開されたポートは、同じローカルシステム上にあるかのように、他のコンテナーで使用できるようになります。

CMD [“php”, “./legacy_app.php”]

CMDを使用します 画像から実行するデフォルトのコマンドと、画像に渡すオプションを識別するコマンド。 Dockerfileに含めることができるCMD行は1つだけです。

LABEL version="1.1"

LABELを使用します 画像にメタデータを追加するための指示。割り当てたラベルに加えて、画像は FROMで呼び出された親画像に割り当てられたすべてのラベルをプルします コマンド。

Dockerイメージの構築

Dockerfile内の命令を正常に定義しました。コマンドターミナルで次のコマンドを入力して、ビルドプロセスを開始します。

docker build -t legacyapp [location_of_Dockerfile]

ビルドプロセス中に、各イメージは一意のIDを受け取ります。レジストリ内の画像を簡単に見つけて識別するには、 -tを使用します 画像に名前を付けるコマンド。この例では、画像の名前は legacyapp になります。。

docker build -t legacyapp .

dockerビルド コマンドは、Dockerファイルに基づいてイメージを作成するようにDockerデーモンに指示します。
dockerビルドに提供されるパス コマンドは、ファイルとディレクトリのアップロードに使用されます。
DockerデーモンがDockerfileからコマンドの実行を進めると、各ビルドステップに番号が付けられます。

各コマンドは新しい画像になります。また、画像IDが画面に表示されます。
ディスク領域を維持するために次の手順に進む前に、各中間Dockerコンテナが削除されます。

Dockerイメージの準備が整い、一意のID参照を受け取りました。さらに、バージョンタグを使用しなかったため、Dockerは画像に ：latestのタグを自動的に付けました。 。

Dockerイメージの実行

これで、イメージをデプロイする準備が整いました。 ドッカーラン サブコマンドはコンテナを開始します：

sudo docker run --name apache2 legacyapp

-名前 引数はコンテナに一意の名前を提供し、 legacyapp 引数は、作成した静的Dockerイメージの名前を表します。

 
 開始および削除されたコンテナーのリストを表示するには、次のコマンドを入力します。
 docker ps -a
 
 出力には、コンテナIDとステータスとともに概要が表示されます。
  
  localhostに移動します アプリがApacheサーバーによって適切に提供されているかどうかを確認します。