CI/CD チェーンの作成と Docker による作業の自動化

私が最初のウェブサイトを書いたのは 90 年代後半でした。 当時、それらを正常に動作させるのは非常に簡単でした。 いくつかの共有ホスティング上に Apache サーバーがあり、次のように記述することで FTP 経由でこのサーバーにログインできます。 ftp://ftp.example.com。 次に、名前とパスワードを入力し、ファイルをサーバーにアップロードする必要がありました。 さまざまな時代があり、当時は今よりもすべてがシンプルでした。

それから XNUMX 年が経ち、すべてが大きく変わりました。 Web サイトはより複雑になっており、運用環境にリリースする前に組み立てる必要があります。 XNUMX つのサーバーがロード バランサーの背後で実行される多数のサーバーになり、バージョン管理システムの使用が一般的になりました。

私の個人的なプロジェクトでは、特別な構成を使用しました。 そして、ブランチにコードを書き込むという XNUMX つのアクションを実行するだけでサイトを運用環境にデプロイできる機能が必要であることもわかっていました。 master GitHub 上で。 さらに、小規模な Web アプリケーションを確実に動作させるためには、巨大な Kubernetes クラスターを管理したり、Docker Swarm テクノロジーを使用したり、ポッド、エージェント、その他あらゆる種類のサーバーを維持したりしたくないこともわかっていました。複雑さ。 作業をできるだけ簡単にするという目標を達成するには、CI/CD に慣れる必要がありました。

小規模なプロジェクト (この場合は Node.js プロジェクト) があり、リポジトリに保存されている内容が運用環境で動作する内容と正確に一致していることを確認しながら、このプロジェクトのデプロイメントを自動化する方法を知りたい場合は、次のようにします。この記事に興味があるかもしれません。

前提条件

この記事の読者は、コマンド ラインと Bash スクリプトの作成についての基本を理解していることが期待されます。 さらに、アカウントも必要になります トラビスCI и Dockerハブ.

目標

この記事が無条件に「チュートリアル」と言えるとは言いません。 これは、私が学んだことについて話し、コードをテストして運用環境にデプロイするための、XNUMX つの自動化されたパスで実行される、私に適したプロセスについて説明するドキュメントです。

これが私のワークフローになりました。

を除くリポジトリ ブランチに投稿されたコードの場合 master、次のアクションが実行されます。

• Travis CI 上でのプロジェクトのビルドが開始されます。
• すべての単体テスト、統合テスト、およびエンドツーエンドのテストが実行されます。

に該当するコードのみ masterの場合、次の処理が実行されます。

• 上記のすべてに加えて...
• 現在のコード、設定、環境に基づいて Docker イメージを構築します。
• イメージを Docker Hub にデプロイします。
• 運用サーバーへの接続。
• Docker Hub からサーバーへのイメージのアップロード。
• 現在のコンテナを停止し、新しいイメージに基づいて新しいコンテナを開始します。

Docker、イメージ、コンテナーについてまったく知らなくても、心配する必要はありません。 それについてすべてお話します。

CI/CDとは何ですか?

CI/CD の略語は、「継続的インテグレーション/継続的デプロイメント」を表します。

▍継続的統合

継続的インテグレーションは、開発者がプロ​​ジェクトのメイン ソース コード リポジトリ (通常はブランチ) にコミットするプロセスです。 master）。 同時に、コードの品質は自動テストによって保証されます。

▍継続的な導入

継続的デプロイメントとは、コードを実稼働環境に頻繁に自動的にデプロイすることです。 CI/CD の頭字語の XNUMX 番目の部分は、「継続的デリバリー」と表記されることがあります。 これは基本的に「継続的デプロイメント」と同じですが、「継続的デリバリー」はプロジェクトのデプロイメントプロセスを開始する前に変更を手動で確認する必要があることを意味します。

はじめに

これらすべてを学ぶために私が使用したアプリは次のとおりです メモを取る。 これは私が取り組んでいる Web プロジェクトで、メモを取るために設計されています。 最初にやろうとしたのは ジャムスタック-project、またはサーバーを持たない単なるフロントエンド アプリケーション。提供する標準のホスティング機能とプロジェクト展開機能を利用します。 Netlify。 アプリケーションの複雑さが増すにつれて、そのサーバー部分を作成する必要がありました。つまり、プロジェクトの自動統合と自動デプロイメントのための独自の戦略を策定する必要がありました。

私の場合、アプリケーションは Node.js 環境で実行されている Express サーバーであり、単一ページの React アプリケーションを提供し、安全なサーバー側 API をサポートしています。 このアーキテクチャは、次の戦略に従っています。 本 フルスタック認証ガイド。

と相談しました другом自動化の専門家である彼に、すべてを思いどおりに機能させるには何をする必要があるかを尋ねました。 彼は、この記事の目標セクションで概説されている、自動化されたワークフローがどのようなものであるべきかというアイデアを私に教えてくれました。 これらの目標を達成するには、Docker の使用方法を理解する必要がありました。

デッカー

Docker は、コンテナ化テクノロジーのおかげで、Docker プラットフォーム自体が異なる環境で実行されている場合でも、アプリケーションを同じ環境で簡単に配布、デプロイ、実行できるようにするツールです。 まず、Docker コマンド ライン ツール (CLI) を手に入れる必要がありました。 命令 Docker インストール ガイドは、あまり明確でわかりやすいとは言えませんが、最初のインストール手順を実行するには、Docker Desktop (Mac または Windows 用) をダウンロードする必要があることがわかります。

Docker Hub はほぼ同じものです GitHubの git リポジトリまたはレジストリの場合 npm JavaScript パッケージの場合。 これは、Docker イメージのオンライン リポジトリです。 これが Docker Desktop の接続先です。

したがって、Docker を使い始めるには、次の XNUMX つのことを行う必要があります。

• セット Dockerデスクトップ.
• 登録します Dockerハブ.

この後、次のコマンドを実行して Docker のバージョンを確認することで、Docker CLI が動作しているかどうかを確認できます。

docker -v

次に、要求されたらユーザー名とパスワードを入力して Docker Hub にログインします。

docker login

Docker を使用するには、イメージとコンテナーの概念を理解する必要があります。

▍画像

イメージは、コンテナーを組み立てるための指示が含まれる設計図のようなものです。 これは、アプリケーションのファイル システムと設定の不変のスナップショットです。 開発者は画像を簡単に共有できます。

# Вывод сведений обо всех образах
docker images

このコマンドは、次のヘッダーを持つテーブルを出力します。

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

次に、同じ形式のコマンドの例をいくつか見ていきます。最初にコメント付きのコマンドがあり、次にそれが出力できるものの例があります。

▍コンテナ

コンテナは、アプリケーションの実行に必要なものがすべて含まれた実行可能パッケージです。 このアプローチを採用したアプリケーションは、インフラストラクチャに関係なく、分離された環境でも同じ環境でも常に同じように動作します。 重要なのは、同じイメージのインスタンスが異なる環境で起動されるということです。

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍タグ

タグは、イメージの特定のバージョンを示します。

▍Docker コマンドのクイックリファレンス

ここでは、一般的に使用されるいくつかの Docker コマンドの概要を示します。

チーム

コンテキスト

アクション

Dockerビルド

イメージ

Dockerfile からイメージを構築する

ドッカータグ

イメージ

画像のタグ付け

ドッカー画像

イメージ

画像の一覧表示

ドッカーラン

コンテナ

イメージに基づいてコンテナを実行する

Dockerプッシュ

イメージ

レジストリへのイメージのアップロード

ドッカープル

イメージ

レジストリからイメージをロードする

ドッカーのps

コンテナ

コンテナのリスト表示

ドッカーシステムプルーン

イメージ/コンテナ

使用されていないコンテナとイメージの削除

▍Dockerfile

本番アプリケーションをローカルで実行する方法を知っています。 既製の React アプリケーションを構築するように設計された Webpack 構成があります。 次に、ポート上で Node.js ベースのサーバーを起動するコマンドがあります。 5000。 次のようになります。

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

この資料の応用例はないことに注意してください。 ただし、ここでは実験のため、単純な Node アプリケーションで十分です。

コンテナを使用するには、Docker に指示を与える必要があります。 これは、というファイルを通じて行われます。 Dockerfile、プロジェクトのルート ディレクトリにあります。 このファイルは、最初はまったく理解できないように思えます。

ただし、そこに含まれるのは、特別なコマンドを使用して、作業環境のセットアップに似た内容を説明するだけです。 これらのコマンドの一部を次に示します。

• FROM — このコマンドはファイルを開始します。 コンテナーが構築されるベースイメージを指定します。
• COPY — ローカル ソースからコンテナへのファイルのコピー。
• 作業ディレクトリ — 次のコマンドの作業ディレクトリを設定します。
• RUN - コマンドの実行。
• 露出 — ポート設定。
• エントリーポイント — 実行するコマンドを示します。

Dockerfile 次のようになります:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

選択した基本イメージによっては、追加の依存関係をインストールする必要がある場合があります。 実際、一部の基本イメージ (Node Alpine Linux など) は、できるだけコンパクトにすることを目的として作成されています。 その結果、期待されるプログラムの一部が提供されない可能性があります。

▍コンテナの構築、タグ付け、実行

現地での組み立てとコンテナの打ち上げは、 Dockerfile, タスクは非常に簡単です。 イメージを Docker Hub にプッシュする前に、ローカルでテストする必要があります。

▍組み立て

まず収集する必要があります イメージ、名前を指定し、オプションでタグを指定します (タグが指定されていない場合、システムは自動的に画像にタグを割り当てます) latest).

# Сборка образа
docker build -t <image>:<tag> .

このコマンドを実行すると、Docker がイメージを構築するのを確認できます。

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

ビルドには数分かかる場合があります。すべては依存関係の数によって異なります。 ビルドが完了したら、次のコマンドを実行できます。 docker images そして、新しいイメージの説明を見てください。

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍起動

画像が作成されました。 これは、それに基づいてコンテナーを実行できることを意味します。 コンテナ内で実行されているアプリケーションにアクセスできるようにしたいためです。 localhost:5000ペアの左側が私です 5000:5000 次にインストールされるコマンドで 5000。 右側がコンテナポートです。

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

コンテナが作成され実行されているので、次のコマンドを使用できます。 docker ps このコンテナに関する情報を確認するには (または、次のコマンドを使用できます) docker ps -a、実行中のコンテナだけでなく、すべてのコンテナに関する情報が表示されます)。

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

今そのアドレスに行くと localhost:5000 — 運用環境で実行されているアプリケーションのページとまったく同じように見える、実行中のアプリケーションのページが表示されます。

▍タグ付けと公開

実稼働サーバー上で作成されたイメージの XNUMX つを使用するには、このイメージを Docker Hub からダウンロードできる必要があります。 これは、まず Docker Hub 上にプロジェクトのリポジトリを作成する必要があることを意味します。 この後、画像を送る場所ができます。 イメージの名前が Docker Hub ユーザー名で始まるように名前を変更する必要があります。 この後にリポジトリの名前を続ける必要があります。 名前の最後には任意のタグを配置できます。 以下は、このスキームを使用してイメージに名前を付ける例です。

これで、新しい名前でイメージをビルドし、コマンドを実行できるようになります。 docker push それを Docker Hub リポジトリにプッシュします。

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

すべてがうまくいけば、イメージは Docker Hub で利用できるようになり、サーバーに簡単にアップロードしたり、他の開発者に転送したりできます。

次のステップ

ここまでで、アプリケーションが Docker コンテナの形式でローカルで実行されていることを確認しました。 コンテナを Docker Hub にアップロードしました。 これらすべては、私たちがすでに目標に向かって非常に良い進歩を遂げていることを意味します。 ここで、さらに XNUMX つの質問を解決する必要があります。

• コードのテストとデプロイのための CI ツールのセットアップ。
• コードをダウンロードして実行できるように実稼働サーバーをセットアップします。

私たちの場合、使用するのは、 トラビスCI。 サーバーとして - デジタルオーシャン.

ここでは、サービスの別の組み合わせを使用できることに注意してください。 たとえば、Travis CI の代わりに、CircleCI または Github Actions を使用できます。 DigitalOcean の代わりに、AWS または Linode を使用します。

Travis CI を使用することに決めましたが、このサービスにはすでに何かが設定されています。 したがって、ここでは仕事のためにそれを準備する方法について簡単に説明します。

トラビスCI

Travis CI は、コードをテストおよびデプロイするためのツールです。 Travis CI の設定の複雑さについては触れたくありません。各プロジェクトは独自であり、あまりメリットがありません。 ただし、Travis CI を使用することに決めた場合に、開始するための基本について説明します。 Travis CI、CircleCI、Jenkins、またはその他のものを選択した場合でも、同様の構成方法がどこでも使用されます。

Travis CI の使用を開始するには、次のサイトにアクセスしてください。 プロジェクトのウェブサイト そしてアカウントを作成します。 次に、Travis CI を GitHub アカウントと統合します。 システムをセットアップするときは、作業を自動化するリポジトリを指定し、そのリポジトリへのアクセスを有効にする必要があります。 (私は GitHub を使用していますが、Travis CI は BitBucket、GitLab、およびその他の同様のサービスと統合できると確信しています)。

Travis CI が起動されるたびに、対応するリポジトリ ブランチのデプロイなど、構成ファイルで指定されたコマンドを実行するサーバーが起動されます。

▍ジョブのライフサイクル

Travis CI 構成ファイルと呼ばれる .travis.yml プロジェクトのルート ディレクトリに保存され、イベントの概念をサポートします ライフサイクル タスク。 これらのイベントは発生順にリストされています。

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍テスト

構成ファイルでは、ローカルの Travis CI サーバーを構成します。 言語としてノード 12 を選択し、Docker を使用するために必要な依存関係をインストールするようにシステムに指示しました。

に記載されているものはすべて、 .travis.yml、特に指定されていない限り、すべてのプル リクエストがリポジトリのすべてのブランチに対して行われたときに実行されます。 これは、リポジトリに入るすべてのコードをテストできることを意味するため、便利な機能です。 これにより、コードをブランチに書き込む準備ができているかどうかがわかります。 master、プロジェクトのビルドプロセスが中断されるかどうか。 このグローバル構成では、すべてをローカルにインストールし、Webpack 開発サーバーをバックグラウンドで実行し (これが私のワークフローの機能です)、テストを実行します。

リポジトリにテスト カバレッジ アイコンを表示したい場合は、 ここで Jest、Travis CI、および Coveralls を使用してこの情報を収集および表示するための簡単な手順を参照してください。

ファイルの内容は次のとおりです .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

ここで、リポジトリのすべてのブランチとプル リクエストに対して実行されるアクションが終了します。

▍展開

すべての自動テストが正常に完了したという前提に基づいて、オプションでコードを実稼働サーバーにデプロイできます。 ブランチのコードに対してのみこれを実行したいので、 master、展開設定でシステムに適切な指示を与えます。 次に説明するコードをプロジェクトで使用する前に、デプロイメント用に実際のスクリプトを呼び出す必要があることを警告したいと思います。

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

デプロイメント スクリプトは、次の XNUMX つの問題を解決します。

• CI ツール (この場合は Travis CI) を使用して、イメージをビルドし、タグ付けし、Docker Hub に送信します。
• サーバーにイメージをロードし、古いコンテナーを停止して、新しいコンテナーを開始します (この場合、サーバーは DigitalOcean プラットフォームで実行されます)。

まず、イメージをビルド、タグ付け、Docker Hub にプッシュするための自動プロセスを設定する必要があります。 これはすべて、画像に一意のタグを割り当て、ログインを自動化する戦略が必要であることを除いて、すでに手動で行ったことと非常に似ています。 タグ付け戦略、ログイン、SSH キーのエンコード、SSH 接続の確立など、デプロイメント スクリプトの詳細のいくつかに問題がありました。 しかし幸いなことに、私のボーイフレンドは、他の多くのことと同様に、bash についても非常に上手です。 彼は私がこの脚本を書くのを手伝ってくれました。

したがって、スクリプトの最初の部分は、イメージを Docker Hub にアップロードすることです。 これは非常に簡単です。 私が使用したタグ付けスキームでは、git ハッシュと git タグ (存在する場合) を組み合わせます。 これにより、タグが一意であることが保証され、そのタグの基になっているアセンブリを識別しやすくなります。 DOCKER_USERNAME и DOCKER_PASSWORD Travis CI インターフェイスを使用して設定できるユーザー環境変数です。 Travis CI は機密データが悪者の手に渡らないように自動的に処理します。

スクリプトの最初の部分は次のとおりです deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

スクリプトの XNUMX 番目の部分がどのようになるかは、使用しているホストと、そのホストへの接続がどのように構成されているかによって完全に異なります。 私の場合、Digital Oceanを使用しているので、コマンドを使用してサーバーに接続します 博士。 AWS と連携する場合、ユーティリティが使用されます aws、など

サーバーのセットアップは特に難しくありませんでした。 そこで、ベース画像を基にドロップレットを設定しました。 私が選択したシステムでは、Docker の手動インストールと Docker の手動起動を 18.04 回だけ行う必要があることに注意してください。 Docker のインストールには Ubuntu XNUMX を使用したため、Ubuntu を使用して同じことを行っている場合は、次のようにしてください。 この 簡単なガイド。

この側面はケースによって大きく異なる可能性があるため、ここではサービスの特定のコマンドについては話していません。 プロジェクトがデプロイされるサーバーに SSH 経由で接続した後に実行するアクションの一般的な計画を示します。

• 現在実行中のコンテナを見つけて停止する必要があります。
• 次に、バックグラウンドで新しいコンテナを起動する必要があります。
• サーバーのローカルポートを次のように設定する必要があります。 80 - これにより、次のようなアドレスでサイトにアクセスできるようになります。 example.comのようなアドレスを使用するのではなく、ポートを指定せずに、 example.com:5000.
• 最後に、古いコンテナーとイメージをすべて削除する必要があります。

スクリプトの続きは次のとおりです。

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

注意すべき点

Travis CI から SSH 経由でサーバーに接続すると、システムがユーザーの応答を待機するため、インストールを続行できない警告が表示される可能性があります。

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

文字列キーを便利かつ確実に操作できる形式で保存するには、base64 でエンコードできることを学びました。 インストール段階で、公開キーをデコードしてファイルに書き込むことができます。 known_hosts 上記のエラーを取り除くために。

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

実際には、このコマンドは次のようになります。

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

そして、生成されるものは次のとおりです。base64 でエンコードされた文字列です。

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

上記のコマンドは次のとおりです

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

サーバーにアクセスするには秘密キーが必要になる場合があるため、接続を確立するときに同じアプローチを秘密キーで使用できます。 キーを操作するときは、キーが Travis CI 環境変数に安全に保存されていて、どこにも表示されていないことを確認するだけで済みます。

もう XNUMX つ注意すべき点は、展開スクリプト全体を XNUMX 行として実行する必要がある場合があることです。たとえば、 doctl。 これには追加の努力が必要になる場合があります。

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL とロード バランシング

上記のすべてを行った後、最後に遭遇した問題は、サーバーに SSL が搭載されていないということでした。 Node.jsサーバーを使用しているので、強制的に работать リバース プロキシ Nginx と Let's Encrypt については、かなり工夫する必要があります。

この SSL 構成をすべて手動で行うのは本当に嫌だったので、ロード バランサーを作成し、その詳細を DNS に記録することにしました。 たとえば、DigitalOcean の場合、ロード バランサー上で自動更新の自己署名証明書を作成するのは、簡単かつ無料で迅速な手順です。 このアプローチには、必要に応じてロード バランサーの背後で実行されている複数のサーバー上で SSL をセットアップするのが非常に簡単になるという追加の利点もあります。 これにより、サーバー自体は SSL についてまったく「考える」必要がなく、同時に通常どおりポートを使用できます。 80。 したがって、ロード バランサーでの SSL のセットアップは、SSL をセットアップする他の方法よりもはるかに簡単で便利です。

これで、受信接続を受け入れるサーバー上のすべてのポート (ポートを除く) を閉じることができます。 80、ロードバランサーとの通信に使用され、ポート 22 SSH用。 その結果、これら XNUMX つ以外のポートでサーバーに直接アクセスしようとすると失敗します。

結果

この資料で説明したことをすべて実行した後は、Docker プラットフォームも自動化された CI/CD チェーンの概念も怖くなくなりました。 継続的インテグレーション チェーンをセットアップすることができました。このチェーンでは、実稼働環境に入る前にコードがテストされ、コードが自動的にサーバーにデプロイされます。 これは私にとってまだ比較的新しいことですが、自動化されたワークフローを改善してより効率的にする方法があると確信しています。 したがって、この件に関して何かアイデアがありましたら、ぜひお知らせください。 私に 知る。 この記事があなたの取り組みの一助になれば幸いです。 この本を読んだ後、私がその中で話したすべてを理解しながら学んだのと同じくらい多くのことをあなたも学んだのだと信じたいです。

PS Внашем 市場 画像があります デッカー、ワンクリックでインストールできます。 コンテナの動作は次の場所で確認できます。 VPS。 すべての新規顧客には 3 日間の無料テストが与えられます。

親愛なる読者！ プロジェクトで CI/CD テクノロジーを使用していますか?

出所： habr.com