アプリケーションのデプロイメントを実装します - 「Java プロジェクトの A to Z」

こんにちは、みんな。プロジェクトの作成に関する一連の記事を続けます。

枝を並べ替える

最も重要なことは、リポジトリ内のブランチとその順序を迷わないようにするために、接頭辞STEP_{number}を追加してブランチの名前を変更することにしました。たとえば、メインのブランチに加えて 3 つのブランチがあります。

• JRTB-0
• JRTB-2
• JRTB-3

どれを次に行えばよいのか、すぐにはわかりません。そこで、次のように名前を変更します。

• STEP_1_JRTB-0 - 最初のステップ
• STEP_2_JRTB-2 - 2 番目のステップ
• STEP_3_JRTB-3 - 3 番目のステップ

など、次の記事で続きます。ブランチの名前を変更するには、リポジトリ ページに移動し、ブランチボックスを見つけて、それに従ってください:各ブランチの下で、鉛筆をクリックしてブランチの名前を変更します:そして、その結果、次の結果が得られます:ちなみに、私の電報チャンネルに登録している人は全員、ブランチの名前を変更したことはすぐにわかりました。

Docker について少し

ドッカーとは何ですか? つまり、アプリケーションを迅速かつ安全に展開（デプロイ）し、そのアプリケーションだけに必要な、そのアプリケーションのためのクローズドなインフラストラクチャを作成できるツールです。やはり難しいですね、分かります。一般に、Docker は、迅速かつ効率的に作業できる開発プラットフォームとして理解できます。Docker は、サーバー上で実行されるプログラムとして理解できます。このプログラムには、アプリケーションを含むコンテナを保存する機能があります。コンテナとは何ですか? これは、必要なものすべてを追加できる個別のインフラストラクチャです。たとえば、Java アプリケーションの場合、アプリケーションを実行するには JRE が必要です。コンテナにはこれがあり、他のソフトウェアが必要になります。これを追加できます。あるいは、Linux と Tomcat サーブレット コンテナが必要になるかもしれません。これも可能です。コンテナーはイメージに基づいて作成されます。つまり、これは、Docker コンテナーの作成に必要なものがすべて含まれた特定のテンプレートです。この画像を作成するにはどうすればよいですか? 私たちの場合、コンテナ内に何を含めるべきかを記述する Dockerfile をプロジェクトのルートに作成する必要があります。ボットのトークンをどこにも公開したくないため、アプリケーションをデプロイするたびにボットのトークンを渡す必要があります。このトピックの詳細については、こことここを参照してください。

JRTB-13と書きます

アプリケーションをサーバーに迅速かつ簡単に展開するプロセスをセットアップする必要があります。つまり、24時間365日稼働するマシンの場合です。Dockerを基礎として考えてみましょう。しかし、私たちのリストには、この機能を追加する役割を担うタスクはありません。作成時になぜか見落としてしまいました。問題ありません。今すぐ作成します。GitHub の課題作成タブに移動し、機能リクエストを選択します。タスクの説明、承認基準を追加し、この課題が属するプロジェクトを設定すると、新しい課題を作成できます。次に、タスクが完了したことを示します。仕事に受け入れられたら、タスクのステータスを To do から In Progress に変更します。これは難しい記事になります。何か問題がある場合は、コメントに書いてください。私はできる限り監視し、回答します。これは小規模なカスタマーサポートになります:D

Dockerfileの作成

dockerfile とは何ですか? Docker の場合、これは Docker コンテナーのイメージを作成する方法に関するスクリプト (段階的な説明) です。アプリケーションが動作するには、JDK バージョン 11 が必要です。つまり、JDK 11 Docker イメージを見つけてイメージに追加する必要があります。これは、メモリに依存関係を追加する方法に似ています。Docker にはこの目的のためにDockerHubがあります。画像をローカルにダウンロードするには、そこに登録する必要があります。登録したら、JDK11を探してみましょう。私が見つけたところによると、これはコンテナーです: Adoptopenjdk/openjdk11。このコンテナの説明には、dockerfile に必要なものが含まれています。

FROM adoptopenjdk/openjdk11:ubi
RUN mkdir /opt/app
COPY japp.jar /opt/app
CMD ["java", "-jar", "/opt/app/japp.jar"]

jar ファイルを取得するフォルダーを修正しましょう。mvn package maven タスクを実行すると、ターゲット フォルダーにそれが保存されます。これらすべてを行う前に、更新されたメイン ブランチに基づいて、タスク用に新しいメイン ブランチを作成します: STEP_4_JRTB-13。これで仕事ができるようになりました。プロジェクトのルートで、Dockerfile拡張子のないファイルを作成し、その中に次の内容を追加します。

FROM adoptopenjdk/openjdk11:ubi
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

最初の行は、イメージのベースとなるもの (adoptopenjdk/openjdk11) です。2 行目は、ターゲット フォルダーにある JAR_FILE という名前のイメージに引数を追加します。さらに、現在のフォルダーは Dockerfile の場所によって決まります。3 行目 - プロジェクトの jar を Docker イメージにコピーします。最後の行には基本的に、ターミナルのコマンドから作成された配列が含まれており、スペースで区切られています。つまり、最終的には次のコードが実行されます: “java -jar /app.jar” ボット トークンを秘密に保つために、コンテナーの起動時に 2 つの変数 (ボットの名前とそのトークン) を渡す必要があります。これを行うには、変数を使用してプロジェクトを起動するクエリを作成します。そしてそれをどうやって行うか？Google で調べてください。通常の説明が記載された最初のリンクがここにあります。私たちは何をしたいのでしょうか？application.properties ファイルには 2 つの変数があり、そこで定義します。

• bot.ユーザー名
• ボットトークン

Docker コンテナを実行し、毎回そこに値を渡して、これらの値が誰にも見られないようにしたいと考えています。SpringBoot では、jar プロジェクトの起動時に設定される環境変数が application.properties ファイル内の環境変数よりも優先されることはわかっています。リクエストで変数を渡すには、-D{変数名}=”{変数値}”という構造を追加する必要があります。中括弧は追加しません ;) 事前定義された値 (ボットの名前とトークン) を使用してアプリケーションを起動するリクエストを受け取ります: java -jar -Dbot.username=”test.javarush.community_bot” -Dbot。 token=”dfgkdjfglkdjfglkdjfgk” *.jar 次に、これらの変数を Docker コンテナ内で渡す必要があります。これは環境変数です。将来的にデータベースがスムーズに動作し、アプリケーションで問題が発生しないようにするために、docker-compose を使用します。これは、作業、起動、コンテナ間の依存関係を整理できる別個のツールです。言い換えれば、これは 1 つのインフラストラクチャのコンテナーを管理するための Docker 上のアドオンです。さらに、docker-compose を実行する前に、サーバーからすべてのコード変更を取得し、アプリケーションを構築し、古いバージョンを停止したことを確認する必要があります。このために、bash スクリプトを使用します。うわー...すべてが難しそうに聞こえますが、私もそう思います。しかし、アプリケーションのデプロイメントの設定は、常に面倒で複雑なプロセスです。したがって、非常に優れたスキームが用意されています。

1. bash スクリプトを実行してみましょう。
2. bash スクリプトは docker-compose を実行します。
3. Docker-compose は、アプリケーションを含む Docker コンテナを起動します。
4. Docker コンテナはアプリケーションを実行します。

次に、2 つの変数 (ボットの名前とそのトークン) がポイント 1 からポイント 4 に移動することを確認する必要があります。そして、これらの 2 つの変数が Java アプリケーションの起動時に使用されるようにします。終わりから始まりまで行きましょう。jarnik を開始するためにどのコマンドを実行する必要があるかはすでにわかっています。したがって、2 つの変数を受け入れてリクエストに渡すことを学習するように Dockerfile を構成します。これを行うには、Dockerfile を次の形式に縮小しましょう。

FROM adoptopenjdk/openjdk11:ubi
ARG JAR_FILE=target/*.jar
ENV BOT_NAME=test.javarush_community_bot
ENV BOT_TOKEN=1375780501:AAE4A6Rz0BSnIGzeu896OjQnjzsMEG6_uso
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-Dbot.username=${BOT_NAME}", "-Dbot.token=${BOT_TOKEN}", "-jar", "/app.jar"]

2 行を追加し、ENTRYPOINT を更新したことがわかります。行数:

ENV BOT_NAME=test.javarush_community_bot
ENV BOT_TOKEN=1375780501:AAE4A6Rz0BSnIGzeu896OjQnjzsMEG6_uso

エンコーダ ファイル内で変数を宣言します。デフォルトでは値が指定されています。このdockerfileからイメージを作成する際に、そのような名前の環境変数を渡すと、値が異なります。そして、ENTRYPOINT では、これらの環境変数を読み取る要素をさらにいくつか追加しました。

"-Dbot.username=${BOT_NAME}", "-Dbot.token=${BOT_TOKEN}"

ここでは、行内で ${} 構造を使用して、BOT_NAME と BOT_TOKEN の値が渡されることがわかります。次に、これらの変数を受け取って docker-compose に渡す方法を教える必要があります。

docker-compose.yml を作成する

YAML 形式については別途お読みいただくことをお勧めします。そうでない場合、記事はすでに飛躍的に増大しています。私たちにとって、これは .properties 型の変数の単なる説明です。プロパティの場合のみドットで記述されますが、YAML ではもう少し美しく記述されます。たとえば、このように。.properties の 2 つの変数: javarush.telegram.bot.name=ivan javarush.telegram.bot.token=pupkin しかし、.yaml (.yml と同じ) では次のようになります。

javarush:
	telegram:
		bot:
		  name: ivan
		  token: pupkin

2 番目のオプションは、より美しく、理解しやすいものです。スペースは上で示したとおりである必要があります。application.properties と application.yml を何らかの方法で翻訳してみましょう。まずそれを作成する必要があります。プロジェクトのルートにdocker-compose.ymlファイルを作成し、そこに次の内容を書き込みます。

version: '3.1'

services:
 jrtb:
   build:
     context: .
   environment:
     - BOT_NAME=${BOT_NAME}
     - BOT_TOKEN=${BOT_TOKEN}
   restart: always

最初の行は docker-compose のバージョンです。 services:これ以降のすべての行 (移動されます) が、構成中のサービスを参照していることを示します。今のところ、そのうちの 1 つだけが、 jrtbという Java アプリケーションです。そして、その下にはすべての設定がすでにあります。たとえば、build: context: 。docker-compose.yml と同じディレクトリで Dockerfile を探すことになります。ただし、environment:セクションは、必要な環境変数を Dockerfile に確実に渡す責任を負います。必要なものだけを。したがって、以下に変数を渡します。Docker-compose は、サーバーの動作環境変数内でそれらを検索します。それらを bash スクリプトに追加しましょう。

bash スクリプトの作成

最後のステップは、bash スクリプトを作成することです。プロジェクトのルートに start.sh というファイルを作成し、そこに次の内容を書き込みます。

#!/bin/bash

# Pull new changes
git pull

# Prepare Jar
mvn clean
mvn package

# Ensure, that docker-compose stopped
docker-compose stop

# Add environment variables
export BOT_NAME=$1
export BOT_TOKEN=$2

# Start new deployment
docker-compose up --build -d

最初の行はすべての bash スクリプトに必要です。これがないと動作しません。そして、実行する必要があるターミナル内のコマンドのセットだけです。各コマンドにコメントを追加したので、明確になるはずです。私が説明したいのは、$1 と $2 が何を意味するかということだけです。これらは、bash スクリプトの起動時に渡される 2 つの変数です。export コマンドを使用すると、それらはサーバー変数に追加され、docker-compose で読み取られます。これは Ubuntu では機能しますが、おそらく Windows では機能しませんが、わかりません。ここで、作業を停止する stop.sh スクリプトを追加する必要があります。これには、次のような複数の行が含まれます。

#!/bin/bash

# Ensure, that docker-compose stopped
docker-compose stop

# Ensure, that the old application won't be deployed again.
mvn clean

ここでは、docker-compose を停止し、前回のビルド以来放置されていたプロジェクト jarnik をクリーンアップします。これは、プロジェクトが正確に再構築されることを保証するために行われます。前例があったので付け加えます) その結果、4 つの新しいファイルが作成されました。

• Dockerfile - アプリケーションのイメージを作成するためのファイル。
• docker-compose.yml - コンテナーの起動方法に関する設定が含まれるファイル。
• start.sh - アプリケーションをデプロイするための bash スクリプト。
• stop.sh はアプリケーションを停止する bash スクリプトです。

また、アプリケーションのバージョンも 0.2.0-SNAPSHOT から 0.3.0-SNAPSHOT に更新します。新しいバージョンの説明を RELEASE_NOTES に追加し、そこにあった内容を少しリファクタリングしましょう。 また、README には、アプリケーションのデプロイ方法を説明する新しい段落を追加します。 もちろん全て英語で書かれています。いつものように、新しく作成したブランチ STEP_4_JRTB-13 で、JRTB-13 という名前の新しいコミットを作成します。docker 経由でデプロイメント プロセスを実装し、プッシュします。以前の記事ですでに説明したことについて詳しく説明するのはやめます。同じことを繰り返す意味がわかりません。それに、それを自分で考えて実行した人には何の疑問もありません。これは、新しいブランチの作成方法、コミットの作成方法、コミットをリポジトリにプッシュする方法について話している私です。

結論

今日は、慎重に検討し、さらに読み進める必要がある新しい情報を大量に示しました。最も重要なことは、1 つの (!!!) コマンドを使用するだけで、アプリケーションのデプロイに必要なすべての作業が完了するということです。これはもう言い表せないほどカッコいいです。はい、変数を正しく転送する方法を理解するために、Docker ドキュメントにかなりの時間を費やす必要がありました。今後、テレグラム ボットは常にメインブランチの最新バージョンで動作します。 電報ボットへのリンク。 今日は、読んでおくとよい資料へのリンクはありません。責任はあなたにあります。情報を検索する方法を学ぶ必要があります。私の電報チャンネルに登録した人は皆、ほぼすぐにボットの導入について知りました。友達、このプロジェクトは好きですか？彼に星をあげましょう！このようにして、それはより人気があり、より多くの人がそれについて学び、そこから学ぶことができるようになります。 いつものように、GitHub に登録し、自分のアカウントをフォローして、このシリーズやそこで取り組んでいる他のプロジェクトをフォローすることをお勧めします。 これでデータベースに接続する準備が整いました。次の記事は長くなり、その中でデータベースを操作するために必要なすべてのことを行います。すべての説明はJRTB-1にあります。

シリーズのすべてのマテリアルのリストは、この記事の冒頭にあります。