نقوم بتنفيذ نشر التطبيق - "مشروع Java من الألف إلى الياء"

أهلاً بكم. نواصل سلسلة المقالات حول كتابة مشروعك.

فرز الفروع

وللأهمية، لكي لا أضيع في الفروع وترتيبها في المستودع، قررت إعادة تسميتها بإضافة البادئة STEP_{number} . على سبيل المثال، لدينا ثلاثة فروع بالإضافة إلى الفرع الرئيسي:

• جي آر تي بي-0
• جي آر تي بي-2
• جي آر تي بي-3

لن تفهم على الفور أي واحد يجب أن يتبعه. لذلك سأعيد تسميتها على النحو التالي:

• STEP_1_JRTB-0 - الخطوة الأولى
• STEP_2_JRTB-2 - الخطوة الثانية
• STEP_3_JRTB-3 - الخطوة الثالثة

وهكذا في المقالات القادمة. لإعادة تسمية الفروع، انتقل إلى صفحة المستودع ، ابحث عن مربع الفروع ، اتبعه: تحت كل فرع، انقر فوق قلم الرصاص وأعد تسمية الفرع: ونتيجة لذلك نحصل على: بالمناسبة ، تم العثور على كل من اشترك في قناتي على التليجرام على الفور أنني إعادة تسمية الفروع.

قليلا عن دوكر

ما هو دوكر؟ باختصار، إنها أداة يمكنك من خلالها نشر (نشر) التطبيقات بسرعة وأمان، وإنشاء بنية تحتية مغلقة ضرورية لها فقط. لا يزال الأمر صعبًا، أفهم ذلك. بشكل عام، يمكن فهم Docker على أنها منصة تطوير حيث يمكنك العمل بسرعة وكفاءة. يمكن فهم Docker على أنه برنامج يعمل على الخادم. هذا البرنامج لديه القدرة على تخزين الحاويات مع التطبيقات. ما هي الحاوية؟ هذه بنية أساسية منفصلة يمكنك إضافة كل ما تحتاجه إليها. على سبيل المثال، بالنسبة لتطبيق Java، نحتاج إلى JRE لتشغيل التطبيق، وستحتوي الحاوية على هذا، وسنحتاج إلى بعض البرامج الأخرى - يمكننا إضافة هذا. أو ربما نحتاج إلى Linux وحاوية Tomcat servlet. ويمكن القيام بذلك أيضًا. يتم إنشاء الحاويات بناءً على صورة: أي أن هذا قالب محدد يحتوي على كل ما هو ضروري لإنشاء حاوية Docker. كيفية إنشاء هذه الصورة؟ في حالتنا، سنحتاج إلى إنشاء ملف Dockerfile في جذر المشروع لوصف ما يجب أن يكون في الحاوية. نظرًا لأننا لا نريد الكشف عن الرمز المميز للروبوت في أي مكان، فسيتعين علينا اللجوء إلى تمريره في كل مرة نريد فيها نشر التطبيق. يمكنك قراءة المزيد عن هذا الموضوع هنا وهنا .

نكتب JRTB-13

نحتاج إلى إعداد عملية نشر سريعة وسهلة لتطبيقنا على الخادم. أي لجهاز يعمل على مدار الساعة طوال أيام الأسبوع. لنأخذ Docker كأساس. ولكن لا توجد مهمة في قائمتنا تكون مسؤولة عن إضافة هذه الوظيفة. بطريقة ما فاتني ذلك عند إنشائه. لا مشكلة، سنقوم بإنشائه الآن. نذهب إلى علامة تبويب إنشاء المشكلة على GitHub ونختار طلب الميزة: أضف وصفًا للمهمة ومعايير قبولها وحدد المشروع الذي تنتمي إليه هذه المشكلة ويمكنك إنشاء مشكلة جديدة: الآن لإظهار أن المهمة قد تم مقبولة للعمل، قم بتغيير حالة المهمة من "تنفيذ" إلى "قيد التقدم": ستكون هذه مقالة صعبة. إذا كان لديك أي مشاكل، فاكتب في التعليقات: سأراقبها وأجيب عليها بأفضل ما أستطيع. سيكون هذا دعمًا صغيرًا للعملاء :D

إنشاء ملف دوكر

ما هو ملف الإرساء؟ بالنسبة إلى Docker، هذا عبارة عن برنامج نصي (تعليمات خطوة بخطوة) حول كيفية إنشاء صورة لحاوية Docker. لكي يعمل تطبيقنا، نحتاج إلى الإصدار 11 من JDK. أي أننا بحاجة إلى العثور على صورة عامل الإرساء JDK 11 وإضافتها إلى صورتنا. هذا شيء مشابه لكيفية إضافة تبعية إلى الذاكرة. لدى Docker DockerHub لهذا الغرض . لتنزيل الصور محليًا، يجب عليك التسجيل هناك. بعد التسجيل، دعنا نذهب للبحث عن JDK11. مما وجدته، هذه هي الحاوية: تبنىopenjdk/openjdk11 . يحتوي وصف هذه الحاوية على ما هو مطلوب لملف الإرساء:

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

لنقم بإصلاح المجلد الذي نأخذ منه ملف الجرة. لدينا في المجلد الهدف بعد أن نقوم بتشغيل مهمة حزمة mvn. قبل القيام بكل هذا، استنادًا إلى الفرع الرئيسي المحدث، قمنا بإنشاء فرع جديد لمهمتنا: STEP_4_JRTB-13 . الآن يمكنك العمل. في جذر المشروع، أنشئ ملفًا بدون ملحق Dockerfile وأضف ما يلي بداخله:

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

السطر الأول هو ما ستستند إليه الصورة -تبنىopenjdk/openjdk11. السطر الثاني هو إضافة وسيطة إلى الصورة المسماة JAR_FILE، الموجودة في المجلد الهدف. علاوة على ذلك، يتم تحديد المجلد الحالي حسب موقع ملف Dockerfile. السطر الثالث - انسخ جرة مشروعنا إلى صورة عامل الإرساء. يحتوي السطر الأخير بشكل أساسي على مصفوفة تم إنشاؤها من الأمر الموجود في الوحدة الطرفية، والتي تم فصلها بمسافة. أي أنه في النهاية سيتم تنفيذ ما يلي: "java -jar /app.jar" للحفاظ على سرية الرمز المميز للبوت، عند بدء الحاوية، سنحتاج إلى تمرير متغيرين - اسم الروبوت والرمز المميز الخاص به. للقيام بذلك، سنكتب استعلامًا يجب أن يبدأ مشروعنا بالمتغيرات. وكيف نفعل ذلك؟ تحتاج إلى البحث عنه في Google: هذا هو الرابط الأول الذي يحتوي على وصف عادي. ماذا نريد أن نفعل؟ لدينا متغيرين في ملف application.properties الذي نحدده هناك:

• bot.username
• bot.token

أرغب في تشغيل حاوية عامل إرساء وتمرير القيمة الخاصة بي هناك في كل مرة حتى لا يتمكن أحد من رؤية هذه القيم. أعلم أنه في SpringBoot، ستكون لمتغيرات البيئة التي يتم تعيينها عند تشغيل مشروع الجرة الأسبقية على تلك الموجودة في ملف application.properties. لتمرير متغير في طلب، تحتاج إلى إضافة البناء التالي: -D{variable name}=”{variable value}” . نحن لا نضيف أقواسًا متعرجة ؛) سنتلقى طلبًا لتشغيل تطبيقنا بقيم محددة مسبقًا - اسم الروبوت ورمزه المميز: java -jar -Dbot.username=”test.javarush.community_bot” -Dbot. token=”dfgkdjfglkdjfglkdjfgk” *.jar الآن نحتاج إلى تمرير هذه المتغيرات داخل حاوية عامل الإرساء. هذا هو متغير البيئة. للتأكد من أن قاعدة البيانات الخاصة بنا تعمل بسلاسة في المستقبل ودون مشاكل في تطبيقنا، سوف نستخدم docker-compose. هذه أداة منفصلة يمكنك من خلالها تنظيم العمل وبدء التشغيل والتبعيات بين الحاويات. بمعنى آخر، إنها وظيفة إضافية أعلى Docker لإدارة حاويات بنية تحتية واحدة. بالإضافة إلى ذلك، قبل تشغيل docker-compose، نحتاج إلى التأكد من أننا سحبنا جميع تغييرات التعليمات البرمجية من الخادم، وقمنا ببناء التطبيق وإيقاف الإصدار القديم. لهذا سوف نستخدم البرنامج النصي باش. واو... يبدو الأمر صعبًا، أوافق على ذلك. لكن العمل على إعداد نشر التطبيق دائمًا ما يكون عملية شاقة ومعقدة. ولذلك، لدينا مخطط جيد جدا:

1. لنقم بتشغيل البرنامج النصي bash.
2. يقوم البرنامج النصي bash بتشغيل docker-compose.
3. يُطلق Docker-compose حاوية عامل إرساء مع تطبيقنا.
4. تقوم حاوية Docker بتشغيل تطبيقنا.

والآن نحتاج إلى التأكد من أن متغيرين - اسم الروبوت والرمز المميز الخاص به - ينتقلان من النقطة 1 إلى النقطة 4. وذلك لاستخدام هذين المتغيرين عند تشغيل تطبيق جافا الخاص بنا. دعنا نذهب من النهاية إلى البداية. نحن نعلم بالفعل ما هو الأمر الذي يجب تنفيذه لبدء الجرنيك. لذلك، سنقوم بتكوين ملف 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"]

يمكنك أن ترى أننا أضفنا سطرين وقمنا بتحديث ENTRYPOINT. خطوط:

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

قم بتعريف المتغيرات داخل ملف التشفير. بشكل افتراضي لديهم قيمة محددة. إذا تم تمرير متغيرات البيئة بهذه الأسماء عند إنشاء صورة من ملف الإرساء هذا، فستكون القيم مختلفة. وفي ENTRYPOINT أضفنا بعض العناصر الإضافية التي ستقرأ متغيرات البيئة هذه:

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

هنا يمكنك أن ترى أنه داخل السطر، باستخدام البنية ${}، سيتم تمرير قيم BOT_NAME وBOT_TOKEN. بعد ذلك، نحتاج إلى تعليم كيفية تلقي هذه المتغيرات وتمريرها إلى docker-compose.

قم بإنشاء docker-compose.yml

سيكون من الجيد أن تقرأ عن تنسيق YAML بشكل منفصل، وإلا فإن المقالة تنمو بالفعل على قدم وساق. بالنسبة لنا، هذا مجرد وصف آخر للمتغيرات من النوع ‎.properties. فقط في الخصائص يتم كتابتها من خلال نقطة، ولكن في YAML يتم ذلك بشكل أكثر جمالًا. على سبيل المثال، مثل هذا. هناك متغيران في .properties: javarush.telegram.bot.name=ivan javarush.telegram.bot.token=pupkin ولكن في .yaml (مثل .yml) سيكون الأمر كما يلي:

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

الخيار الثاني أجمل ومفهوم. يجب أن تكون المساحات تمامًا كما هو موضح أعلاه. دعونا نترجم 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. الخدمات: تقول أن جميع الأسطر التالية بعد ذلك (سيتم نقلها) تشير إلى الخدمات التي نقوم بتكوينها. لدينا واحد فقط من هذه التطبيقات حتى الآن - وهو تطبيق جافا يسمى jrtb . وتحته بالفعل ستكون جميع إعداداته. على سبيل المثال، إنشاء: السياق: . يقول أننا سنبحث عن ملف Dockerfile في نفس الدليل مثل docker-compose.yml. لكن قسم البيئة: سيكون مسؤولاً عن ضمان تمرير متغيرات البيئة الضرورية إلى ملف Dockerfile. فقط ما نحتاجه. ولذلك، فإننا نمرر المتغيرات أدناه. سيبحث Docker-compose عنها في متغيرات بيئة تشغيل الخادم. دعونا نضيفهم إلى البرنامج النصي باش.

إنشاء البرامج النصية باش

الخطوة الأخيرة هي إنشاء برنامج نصي 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. باستخدام أمر التصدير، ستتم إضافتها إلى متغيرات الخادم وقراءتها في 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

هنا نتوقف عن إنشاء عامل الإرساء وننظف جارنيك المشروع، الذي كان موجودًا منذ آخر بناء. نحن نفعل ذلك للتأكد من إعادة بناء مشروعنا بدقة. كانت هناك سوابق، ولهذا السبب أقوم بإضافتها) ونتيجة لذلك، انتهى بنا الأمر إلى 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 لفهم كيفية إعادة توجيه المتغيرات بشكل صحيح. من الآن فصاعدًا، سيعمل روبوت التليجرام دائمًا على أحدث إصدار من الفرع الرئيسي . رابط بوت التليجرام . اليوم لن تكون هناك روابط للمواد التي من الجيد قراءتها: المسؤولية تقع على عاتقك. عليك أن تتعلم كيفية البحث عن المعلومات. علم كل من اشترك في قناتي على التلغرام بنشر الروبوت على الفور تقريبًا. أصدقائي، هل أعجبكم المشروع؟ أعطيه نجمة ! بهذه الطريقة ستصبح أكثر شعبية وسيتمكن المزيد من الأشخاص من التعرف عليها والتعلم منها. كالعادة أقترح التسجيل في GitHub ومتابعة حسابي لمتابعة هذه السلسلة ومشاريعي الأخرى التي أعمل عليها هناك. الآن نحن على استعداد لربط قاعدة البيانات. ستكون المقالة التالية أطول وسنقوم فيها بكل ما هو ضروري للعمل مع قاعدة البيانات. جميع الأوصاف موجودة في JRTB-1 .

توجد قائمة بجميع المواد الموجودة في السلسلة في بداية هذه المقالة.