Bash を使用して Docker 化されたアプリをリモート Ubuntu サーバーにデプロイする |クリスティアナ シェドラック著 | 2025 年 10 月

導入

のステージ 1 で展開自動化タスクを受け取ったとき HNG インターンシップ、正直、少し怖気づいていました。手順は紙の上では簡単そうに見えました。bash スクリプトを使用して、Docker 化されたアプリケーションのリモート Ubuntu サーバーへのデプロイメントを自動化します。しかし、調べていくうちに、答えよりも疑問の方が早く増えてきました。どのリポジトリを使用すればよいですか?何個必要ですか?どのファイルがどこに行くのか?グループチャンネルにはインターン仲間からの同様の質問が殺到し、私たちは皆、指示が欠けているパズルを組み立てるような気分で理解しようとしていました。

このドキュメントでは、最初の混乱から実用的なソリューションに至るまで、展開スクリプトを構築する際に行った手順を説明します。あなたが私のような初心者で、DevOps、Docker、Nginx、自動化の世界をナビゲートしている場合、これがプロセスの分かりやすさに役立つことを願っています。私がこれを個人的な考察と技術ガイドの両方として書いたのは、「理由」を理解することは「方法」を知ることと同じくらい重要であると信じているからです。

このタスクでは、Docker 化されたアプリケーションを取得してリモート サーバーにデプロイし、リバース プロキシの構成と検証チェックを完了する bash スクリプトを作成する必要がありました。試行錯誤し、ドキュメント ページを何度も訪れて学んだことは、DevOps はコマンドを覚えることではなく、さまざまなコンポーネントがどのように相互作用するかを理解し、再現可能で信頼性が高く、透過的なシステムを構築することであるということです。

複雑さを分析する:

技術的なフローを明確にし、よくある質問に答えるために、この展開は半自動化されています。スクリプトはセットアップと展開の手順を自動化しますが、最初はユーザーによる手動入力から始まります。ユーザーに、Git リポジトリ URL、PAT (必要な場合)、ブランチ名、SSH ユーザー名とホスト、SSH 秘密キー パス、およびアプリケーションの内部ポートの入力を求めます。これらのパラメーターが検証されると、スクリプトが引き継ぎます。リモート ホストに SSH で接続し、環境を準備し (Docker、Docker Compose、Nginx をインストールし、ユーザーを Docker グループに追加します)、アプリケーション ファイルを転送し、コンテナーを構築して実行し、Nginx を構成し、デプロイメントを検証し、必要に応じてクリーンアップします。ユーザーはデプロイメントのターゲットと資格情報を指定する必要があるため、これは完全な CI/CD パイプラインではなく、人間が実行時にトリガーして構成する自動化されたデプロイメントの実行です。

ファイル転送: cp を介して rsync する理由

rsync を使用して、プロジェクト ディレクトリをローカル マシンからリモート サーバーにコピーしました。ローカル コピーには cp を使用できますが、リモート ファイル転送にはいくつかの理由から rsync の方が優れています。変更されたファイルのみを送信するため、その後の展開で帯域幅と時間を節約できます。ファイルのアクセス許可とタイムスタンプが保存されます。これは、適切な実行権限とメタデータを維持するために重要です。また、ディレクトリの同期もより効率的で、cp にはない組み込みの進行状況レポートとエラー処理も提供します。

転送する必要があるファイルは、アプリケーションのソース コードと Docker アーティファクトです。通常は、Dockerfile (または dockerfile)、docker-compose.yml (compose を使用している場合)、アプリケーション ファイル (Python の app.py、Node の server.js など)、依存関係ファイル (requirements.txt、package.json など)、アプリに必要なテンプレート、静的アセット、または構成ファイルです。私の場合、個人プロジェクトとしてすでに構築した見積アプリを使用しました。これには、templates/index.html と quotes.json が含まれていました。あなたにとって、それは、作業している Docker 化されたアプリケーションになります。まだ Docker 化していない場合は、まず Docker 化してから、rsync を使用してローカル ホストからリモート サーバーにコピーする必要があります。これらのファイルをリモート ホスト上に置くと、スクリプトでイメージを構築したり、サーバー上で直接 docker-compose を実行したりできるようになります。

「Docker化」の意味

「Docker 化されたアプリ」とは、コンテナー内で実行するために必要なメタデータがアプリケーションに含まれていることを意味します。つまり、実行可能なイメージを構築するための Dockerfile (依存関係のインストール、コードのコピー、エントリーポイントの設定)、またはマルチサービスのセットアップとポート マッピングを記述するための docker-compose.yml です。このスクリプトは、単一イメージ アプリの場合は docker build と docker run を実行するか、compose ベースのプロジェクトの場合はデタッチおよびビルド フラグを使用して docker-compose up を実行し、コンテナーが制御された方法で停止、削除、再構築、再起動されるようにします。

Nginxの役割

コンテナーの実行後、スクリプトは Nginx をリバース プロキシとして構成します。実際には、スクリプトはポート 80 でリッスンし、受信した HTTP リクエストをアプリの内部ポート (例: proxy_pass) に転送する Nginx サーバー ブロックを作成します。 http://127.0.0.1:5000;)。 リバース プロキシはいくつかの役割を果たします。コンテナ内部を公開せずに標準の HTTP/HTTPS ポートでアプリケーションを公開し、複数のバックエンド インスタンス間でトラフィックをルーティングまたはバランスさせることができ、構成時に TLS を終了し、キャッシュまたはリクエスト フィルタリングのためのレイヤーを追加します。単一サービス アプリの場合、Nginx は http:// でアプリにアクセスできるようにします。/ 一方、Flask (私の場合) プロセスはポート 5000 の Docker 内に隔離されたままです。

検証とロギング

このスクリプトには検証とログも含まれています。アクションをローカルに記録し (タイムスタンプ付きのdeploy_YYYYMMDD_HHMMSS.log)、システム サービス (Docker、Nginx) がアクティブであることを確認し、コンテナーが実行されていることを確認し、リモート ホストとローカル マシンの両方から HTTP チェック (curl) を実行してアプリが応答することを確認します。これにより、問題を迅速に表面化し、デプロイメントが失敗した場合のデバッグに役立つアーティファクトが提供されます。

SSL対応

最後に、「SSL の準備を確認する」とは、後で HTTPS を有効にできるように展開が準備されていることを意味します。ただし、このタスクでは運用証明書はオプションです。このスクリプトは、小さな自己署名証明書の作成手順 (内部テストには便利ですが、ブラウザーは信頼できないと警告します) を提供するか、明確なプレースホルダーと後で certbot 経由で Let’s Encrypt を追加する手順を残します。運用環境で完全な SSL を有効にするには、ドメイン名 (サーバー IP を指すレコード) が必要であり、実際の証明書を取得して自動更新するために Certbot を実行する必要があります。このステップは DNS と到達可能なドメインを必要とするため、意図的にオプションとして残されました。

実装手順

1. 申請書の準備

前に述べたように、私は以前のプロジェクト (docker-quote-api) から Dockerized Flask アプリをすでに持っていました。アプリには既に Dockerfile、docker-compose.yml、app.py、requirements.txt、およびテンプレートが含まれていたため、新しいアプリを作成する必要はありませんでした。これをデプロイするアプリケーションとして再利用しただけです。

2. デプロイメントリポジトリの作成

デプロイ スクリプト、Docker 化アプリ ディレクトリ、README.md、および .gitignore を保持する docker-deploy-task という新しいリポジトリを作成しました。このリポジトリは、スクリプトがリモートでデプロイする完全なプロジェクトを表します。

deploy.sh
docker-quote-api/   (my Dockerized app)
README.md
.gitignore

3. Bash デプロイメント スクリプト (deploy.sh) の作成

このスクリプトは、ユーザーに入力 (Git リポジトリ URL、ブランチ、サーバー IP、SSH キー パス、アプリ ポートなど) を求めるプロンプトを表示し、それらの入力を検証し、リモート Ubuntu サーバーに SSH で接続し、必要なパッケージ (Docker、Docker Compose、Nginx) をインストールし、ユーザーを Docker グループに追加してサービスを有効にし、サーバー上の Git リポジトリを複製または更新し、rsync を使用してプロジェクト ファイルを効率的にコピーし、Docker をビルドして実行するように設計されています。 コンテナーを作成し、アプリにトラフィックを転送するリバース プロキシとして Nginx を構成し、展開プロセスをテストしてログに記録し、オプションで SSL セットアップの準備を (Certbot または自己署名証明書経由で)、一時ファイルをクリーンアップします。

私の GitHub リポジトリで、完全なデプロイメント スクリプトとすべてのプロジェクト ファイルを表示できます。 HNG-docker-デプロイ-スクリプト

4. SSH アクセスのセットアップ

~/.ssh/my-app-key にある既存の秘密キーを使用しました。スクリプトがキーのパスを要求したときに、この値を入力しました。これにより、スクリプトは AWS 上のリモート Ubuntu サーバーに安全に接続できるようになりました。

5. スクリプトの実行

スクリプトを実行可能にしました。

chmod +x deploy.sh

それからそれを実行しました:

./deploy.sh

パラメーターの入力を求められ、SSH 経由でサーバーに自動的に接続され、依存関係がインストールされ、コンテナー化された Flask アプリがデプロイされました。

Enterを押すかクリックして画像をフルサイズで表示します

6. リモートサーバーへの展開

接続すると、スクリプトは Docker、Docker Compose、Nginx をインストールし、GitHub リポジトリを /opt/app にクローンし、rsync を使用してファイルを同期し、Dockerfile を使用してアプリ イメージを構築し、ポート 5000 で実行されるアプリでコンテナを起動し、Nginx をリバース プロキシとして構成し (ユーザーがポート 80 経由でアクセスできるように)、curl localhost を使用してアプリの応答を確認しました。

Enterを押すかクリックして画像をフルサイズで表示します

Enterを押すかクリックして画像をフルサイズで表示します

7. ロギングと検証

スクリプトは、プロセスのすべてのステップを、deploy_20251021_1432.log などのタイムスタンプ付きのログ ファイルに記録します。また、Docker と Nginx が実行されていること、コンテナーがアクティブであること、アプリが正常に応答していることも検証しました。

8. クリーンアップとファイナライズ

最後に、一時セットアップ ファイルを削除し、展開が完了したことを確認して、正常に終了しました。次に、最終的なリポジトリ (スクリプトとアプリを含む) を GitHub にプッシュして送信しました。

結論

このタスク全体では、環境セットアップ、ファイル同期、コンテナーのライフサイクル、リバースプロキシ構成、検証、クリーンアップが調整され、人間の入力によってデプロイメントパラメーターと承認が提供されます。このアプローチにより、プロセスは反復可能かつ監査可能に保たれますが、レビュー担当者や新規参入者にとっては依然としてシンプルかつ透明であり、これが基本的に私が呼びたい DevOps の方法です。