Dockerコンテナを使用してプロキシ転送とデータバックアップを実装する方法

序文

アプリケーションを Docker コンテナとしてサーバーにデプロイする場合、通常はネットワークとストレージという 2 つの側面を考慮する必要があります。

ネットワークに関しては、一部のアプリケーションはポートを占有する必要があり、さらに外部アクセスを提供する必要があるアプリケーションもあります。

セキュリティ上の理由から、ファイアウォールポートを直接開くよりも、プロキシ転送の方が適切です。

ストレージに関しては、コンテナはデータの永続化には適していないため、ボリュームをマウントしてサーバーのディスクにデータを保存するのが一般的です。

ただし、サーバーは絶対的なセキュリティを保証することはできないため、データをクラウドにバックアップする必要もあります。

プロキシ転送

デフォルトでは、コンテナ間のネットワークは互いに分離されていますが、一部の関連アプリケーション（Web フロントエンドコンテナ、サーバーコンテナ、データベースコンテナ）では、コンテナ同士が通信可能でありながら外部から分離されるように、独立したブリッジサブネット（以下、サブネット）に分割されるのが一般的です。

サブネット外部へのアクセスを提供する必要のあるコンテナーの場合は、ポートをサーバーホストにマップできます。全体の構造は次のようになります。

上記のポートマッピングは、サーバー (ホスト) がコンテナーネットワークサービスにアクセスする問題のみを解決します。ローカルマシンからインターネット経由でサーバー上のコンテナーにアクセスする場合、セキュリティ上の考慮事項に加えて、サーバーはデフォルトでファイアウォールを有効にし、22 などのいくつかのポートのみを開くため、通常は不可能です。

従来のネットワークプロセスの場合、実装方法は、Nginx を使用して次のプロキシを構成するなど、リバースプロキシサーバーを介してネットワーク要求を転送することです。

# 異なるパスへの転送 server {
 聞く 80;               
 サーバー名 www.xx.com;            

 場所 /a {
  プロキシパス ローカルホスト:1234;
 }
 場所 /b {
  プロキシパス ローカルホスト:2234;
 }
}
# 異なるドメイン名の転送サーバー {
 聞く 80;               
 サーバー名 www.yy.com;            

 位置 / {
  プロキシパス ローカルホスト:1234;
 }
}

この時点で問題は解決されたように見えますが、Nginx もコンテナー内で実行されている場合はどうなるでしょうか?

先ほど、サブネットは外部コンテナから分離されているため、Nginx コンテナはこれらの外部サービスにアクセスできないと述べました。

Nginx コンテナを対応するサブネットに分割することは簡単に思いつくかもしれません。コンテナは複数のサブネットの構成をサポートしていますが、この操作方法の問題は、新しいサブネットが追加されるたびに、Nginx コンテナのネットワーク構成を変更し、コンテナを再起動する必要があることです。

したがって、より良い方法は、Nginx を HOST ネットワークモードに設定することです。 Nginx コンテナとサーバー間の分離を放棄し、ネットワークとポートをサーバーと直接共有します。その後、Nginx コンテナはマップされたポートを持つすべてのコンテナに直接アクセスできるようになります。

次の図に示すように:

データのバックアップ

アプリケーションシナリオ

速度とセキュリティを考慮して、企業では通常、イントラネット経由でのみアクセスできるサーバーがいくつか存在します。ただし、サーバー自体も含め、これらのサーバー上のデータはいつでも変更されたり、障害が発生したりする可能性があります。

したがって、データのバックアップは特に重要です。ここでは、小規模なデータのバックアップについて説明します。

私が最近チーム用に構築したナレッジベースサーバーを例に挙げてみましょう。

この Web アプリケーションは、コンテナの形式でイントラネットサーバーに展開される小さな Python サービスです。オンライン編集をサポートし、データを md ファイル形式で保存します。

コンテナに障害が発生すると、内部データにアクセスできなくなります。したがって、コンテナ内にデータを直接配置することは絶対に安全ではありません。コンテナとサーバーがデータの読み取りと書き込みを共有できるようにする唯一の方法は、ファイルをマウントすることです。

では、データをどのようにバックアップすればよいのでしょうか?ここでは、保存先として GitHub のプライベートリポジトリを選択します。理由は3つあります。

安全性。データは簡単に紛失したり盗まれたりすることはありません。
便利です。バックアップには git コマンドを使用するだけです。
速い。バックアップされたデータの容量や量が大きくないためです。

方法は決定されましたが、解決すべき問題がまだ 2 つ残っています。

GitHub リポジトリにアクセスするには、権限認証が必要です。
GitHub にデータをスケジュールまたは自動的に送信する方法。

実装

まず、コンテナの単一責任の原則に従って、バックアップタスクを実行するための新しいコンテナを作成する必要があります。

ここでは、docker-compose またはその他のオーケストレーションツールを使用して複数のコンテナを作成できます。

次に権限認証を行います。ローカルマシンに SSH キーを作成し、それを GitHub 設定に追加して、コンテナーが対応するウェアハウスにファイルをプッシュできるようにします。

ただし、現在コードをプッシュできるのはコンテナではなくサーバーのみなので、.ssh ファイルもコンテナにコピーする必要があります。

最後に、自動バックアップの実装です。より良い方法は、ファイルが変更されるたびにコードを送信してプッシュすることですが、現在、コンテナ内のファイルを監視する簡単な方法はありません。そのため、次善の策は、スケジュールされたタスク戦略を使用することです。つまり、対応する git コマンドを 5 分ごとに実行して、ファイルをウェアハウスに送信してプッシュします。

ここでは、busybox イメージパッケージに基づく軽量コンテナーを使用し、プロジェクトコードをコンテナーにマウントしてファイルの同期更新を確実に行い、cron サービスを開始して操作を実装できます。

要約する

上記はこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。

以下もご興味があるかもしれません: