Java in the Cloud: برنامج تعليمي لإعداد التكامل المستمر

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

عززت منهجيات مثل Agile و DevOps والتكامل المستمر والنشر - جنبًا إلى جنب مع تطور الخدمات المصغرة - بشكل جماعي إنتاجية عملية تطوير البرامج لدرجة أنه من دواعي سروري تطوير البرامج أكثر من أي وقت مضى. يمكن أن يؤدي استخدام الأتمتة وإعداد مجموعة الأدوات الصحيحة إلى جعل تطوير منتجات البرامج وتسليمها أمرًا سهلاً للغاية.

ستلقي هذه المقالة نظرة على هذا العالم الجديد من منظور مطور Java الذي ينتقل إلى DevOps ويبحث لتحسين تطوير المنتج وتسليمه إلى أقصى حد.

اليوم ، تُستخدم مصطلحات مثل Spring Boot و Docker و Cloud و Amazon Web Services و Continuous Delivery على نطاق واسع ولكنها أقل فهمًا على نطاق واسع. ستأخذ هذه المقالة أسهل طريق ممكن لتقديم كل هذه التقنيات وشرح هذه المصطلحات ، ونختتمها في شكل برنامج تعليمي حيث سنطور برنامجًا صغيرًا ونعده لتسليم الإنتاج باستخدام جميع الأدوات المذكورة.

لماذا هذه الأدوات؟

تبسيط عمليات النشر باستخدام Docker

"اكتب مرة واحدة ، وتشغيل في أي مكان" كان الاختراق المفاهيمي الذي أسفر عن تقنيات مثل Java Virtual Machine (JVM) التي مكنت الكود الخاص بك من العمل في أي مكان. وها نحن الآن ، بعد عقدين من الزمان ، مع شيء يسمى Docker يتم تقديمه إلى مجتمع تكنولوجيا المعلومات. Docker هي أداة احتواء يمكنك من خلالها وضع برنامجك وتشغيله دون عناء ، في أي مكان تريده تقريبًا.

ومع ذلك ، قد ينظر مطور Java إلى Docker ويقول "لماذا نحتاج إلى ذلك ، لدينا بالفعل JVM ، المعروف جيدًا باعتباره الحل المحمول الرئيسي." لكن هل هو كذلك؟

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

وهنا يأتي دور Docker للمساعدة في إنقاذ الموقف.

يبسط Docker تطوير البرامج واختبارها وشحنها. إذا كان لديك البرنامج الذي تريد اختباره ، فضعه في حاوية Docker ، وسيتم تشغيله وسيكون تثبيته سهلًا لجميع الأطراف المعنية.

تسريع التطوير مع Spring Boot

بعد أقل من عقد من تقديم شعار "اركض في أي مكان" ، ظهر إطار الربيع على الساحة. اليوم ، يستمر نظام الربيع البيئي في الازدهار ، وقد أنتج الكثير من المشاريع القيّمة القائمة على الربيع ، ولعل أبرزها Spring Boot. كما هو مذكور على موقع Spring Boot:

يجعل Spring Boot من السهل إنشاء تطبيقات قائمة بذاتها ومستندة إلى فئة الإنتاج يمكنك تشغيلها.

يتيح لك Spring Boot تشغيل التطبيق في غضون دقائق. يمكن لمطوري البرامج التركيز على تطوير البرامج ومن ثم يمكنهم الاستفادة من الأداة التي تقوم بكل عمليات التكوين لهم.

في هذا البرنامج التعليمي ، سوف نستخدم Spring Boot لتطوير خدماتنا المصغرة.

التكامل المستمر (CI) مع جنكينز

DevOps هي حركة سريعة النمو تعمل على دمج فرق تطوير البرامج وإدارة الأنظمة بإحكام ، بهدف جعل دورة حياة تطوير البرامج وتقديمها غير مؤلمة وسلسة ومثمرة قدر الإمكان لجميع الأطراف المعنية: المطورين ومسؤولي النظام والمختبرين ، وفي النهاية ، المستخدمين النهائيين.

يعد التكامل المستمر (CI) أحد الأركان الأساسية لثورة DevOps. الفكرة هي أنه عندما يلتزم مطور برمز إلى مستودع الكود ، يتم اختباره تلقائيًا وتعبئته للتسليم (النشر) إلى الإنتاج.

يسير CI جنبًا إلى جنب مع:

• التسليم المستمر - التسليم التلقائي للحزمة المعدة لاختبار أعمال المستخدم النهائي مع الزناد اليدوي لنشر الإنتاج.
• النشر المستمر - النشر التلقائي للمنتج المعبأ مباشرةً في الإنتاج.

يوجد أكثر من عدد قليل من الأدوات التي يمكن استخدامها لتنفيذ عملية CI. واحدة من أكثرها شيوعًا هي Jenkins ، وهي أداة مفتوحة المصدر CI. مع وجود أكثر من ألف مكون إضافي ومجتمع ضخم وراءه ، يعد Jenkins خيارًا سهلاً عند البدء في التفكير في تنفيذ التكامل أو التسليم أو النشر المستمر.

في برنامجنا التعليمي ، سيتم استخدام Jenkins لتقديم منتجنا إلى السحابة ، وبشكل أكثر تحديدًا ، سحابة Amazon (AWS).

الحوسبة السحابية مع AWS

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

بالطبع ، هناك التحدي المتمثل في تحديد المزود الذي يجب اختياره. حروب السحابة لا تزال جارية. Clash of Microsoft و Amazon و Google لمستقبل الحوسبة هو مثال على العنوان يمكنك أن تجده مؤخرًا في أخبار عالم التكنولوجيا. بالنسبة لهذه المدونة ، اخترت Amazon Web Services (AWS) ، إلى حد كبير بناءً على شعبيتها الحالية وحصتها في السوق.

تتمثل إحدى مزايا AWS في أن Amazon تقدم الكثير من الخدمات بعد التسجيل:

في هذا البرنامج التعليمي ، سنستخدم خدمتي AWS التاليتين: Elastic Compute Cloud EC2 (بشكل أكثر تحديدًا ، Amazon EC2 Container Registry ، أو Amazon ECR) ، و Amazon S3 (خدمات التخزين البسيطة).

أمازون ECR

سنحتاج إلى تخزين صور Docker الخاصة بنا في مكان ما. Amazon ECR هي خدمة تسجيل AWS Docker مُدارة. كما هو مذكور على موقع الويب Amazon ECR:

... يجعل من السهل على المطورين تخزين صور حاوية Docker وإدارتها ونشرها. تم دمج Amazon ECR مع Amazon EC2 Container Service (ECS) ، مما يبسط تطورك إلى سير عمل الإنتاج. يلغي Amazon ECR الحاجة إلى تشغيل مستودعات الحاويات الخاصة بك أو القلق بشأن توسيع البنية التحتية الأساسية.

أمازون S3

كما ذكرنا ، سيكون التطبيق الذي نقوم بتطويره عبارة عن خدمة صغيرة من Spring Boot والتي ستقوم بتحميل الملفات إلى Amazon S3. كما هو مذكور على موقع الويب Amazon S3:

... يزود المطورين وفرق تكنولوجيا المعلومات بتخزين سحابي آمن ودائم وقابل للتطوير بدرجة كبيرة. Amazon S3 سهل الاستخدام لتخزين الكائنات ، مع واجهة خدمة ويب بسيطة لتخزين واسترداد أي كمية من البيانات من أي مكان على الويب.

برنامج تعليمي "كيف" عملي

الهدف هو التحضير لنشر خدمة صغيرة من Spring Boot والتي ستقوم بتحميل الملفات إلى Amazon S3. الخطوات هي التالية:

• تطوير الخدمة المصغرة
• حدد عملية الإنشاء التي سيتم فيها إرساء الخدمة
• استخدم Bitbucket لاستضافة مستودع كود Git
• ادمج Bitbucket مع Jenkins لحزم التطبيق باستخدام Gradle
• ادفعه إلى Amazon ECR بعيد

ما يلي هو برنامج تعليمي لإعداد جميع المكونات المطلوبة:

• مثال على تطبيق Spring Boot - خدمة مصغرة مجمعة ومرسومة باستخدام Gradle
• تثبيت Jenkins على خادم Ubuntu جديد
• تكامل Bitbucket مع Jenkins عبر خطاف الويب
• تكوين وظيفة جينكينز
• Amazon ECR لتخزين صور Docker التي تحتوي على تطبيقنا

المتطلبات الأساسية

لكي نتمكن من استخدام موارد AWS السحابية ، نحتاج إلى التسجيل في Amazon أولاً. من خلال التسجيل ، سنحصل على حساب بمزايا الاستخدام المجاني للفئة الفورية ، لأغراض تمكين الخبرة العملية خلال الأشهر الـ 12 التالية للتسجيل.

كما ذكرنا ، سنستخدم Amazon S3 و Amazon ECR في هذا البرنامج التعليمي. لكليهما ، سنحتاج إلى مفاتيح وصول للاتصال بالخدمات.

بعد الاشتراك في AWS ، ننتقل إلى بيانات اعتماد أمان الحساب ، حيث نختار مفاتيح الوصول ونضغط على "إنشاء مفتاح وصول جديد". بعد النقر ، يتم إنشاء مفتاح مع معرفه. تحتاج إلى تخزين هذا في مكان آمن ، حيث سنستخدمه لاحقًا عند تكوين تكامل AWS Jenkins وتطوير تحميل ملف S3 الخاص بنا.

الشرط الأساسي التالي هو أننا بحاجة إلى حاوية Amazon S3 (حاوية تخزين). ستقوم خدمة Spring Boot Service بتحميل وتنزيل الملفات من وإلى تخزين Amazon S3. يعد إنشاء الدلو أمرًا بسيطًا ولا يتطلب سوى نقرات قليلة. يتوفر وصف كامل لكيفية القيام بذلك في وثائق إنشاء مجموعة.

سنستخدم أيضًا Bitbucket لاستضافة الكود الخاص بنا وإطلاق الطلبات إلى Jenkins ، لذلك نحتاج أيضًا إلى حساب Bitbucket. يعد Bitbucket خيارًا رائعًا للمطورين ، حيث تتمثل إحدى فوائده الرئيسية في العدد غير المحدود من المستودعات الخاصة التي يمكنك إنشاؤها.

تطوير التطبيقات

بدلاً من الدخول في جميع تفاصيل التعليقات التوضيحية لفصل الربيع وكيفية عملها ، سأركز بدلاً من ذلك ، من منظور مطور خالص ، على الجزء الأكثر تحديًا من الإعداد بأكمله ؛ وهي تثبيت وتكوين Linux و Jenkins والأدوات الأخرى اللازمة لـ CI. تتوفر جميع أمثلة التعليمات البرمجية المستخدمة في هذا البرنامج التعليمي ، بما في ذلك تطبيق Spring Boot microservice ، في مستودع Bickbucket الخاص بالمشروع.

تكوين التطبيق لدينا بسيط. لدينا نقطة دخول لتطبيق Spring Boot في ملف StorageWebserviceApplication.java بنا. منطق تحميل الملفات وتنزيلها موجود في StorageService.java . StorageController.java عبارة عن وحدة تحكم في الراحة ، تحتوي على نقاط نهاية API المستخدمة لتحميل الملفات وتنزيلها. هنا هو التسلسل الهرمي للمشروع:

لقد اخترنا Gradle كأداة بناء ، وسوف يحزم تطبيقنا ويؤلف صورة Docker. بعد ذلك ، سنناقش ملف إنشاء Gradle ومكون الخدمة وملف Dockerfile.

لكي نتمكن من استخدام AWS API ، نحتاج إلى تضمين التبعيات في ملف البناء الخاص بنا ، على النحو المحدد في وثائق AWS لاستخدام Gradle.

باختصار ، سيبدو جزء تكوين تبعية AWS في برنامج Gradle النصي كما يلي:

 buildscript { ... repositories { mavenCentral() } dependencies { ... classpath("io.spring.gradle:dependency-management-plugin:0.5.4.RELEASE") } } .. apply plugin: "io.spring.dependency-management" dependencyManagement { imports { mavenBom ('com.amazonaws:aws-java-sdk-bom:1.10.47') } } dependencies { .. compile ('com.amazonaws:aws-java-sdk-s3') }

كما ذكرنا سابقًا ، عند تحميل الملفات إلى Amazon S3 ، نقوم بذلك عن طريق تحميل الملفات إلى حاوية S3 .

للاتصال بالحاوية ، يحتاج عميل Amazon S3 إلى توفير بيانات اعتماد. أوراق الاعتماد هي مفاتيح الوصول التي أنشأناها مسبقًا. نحدد معرف مفتاح الوصول والقيمة في ملف application.properties ؛ لقد قمنا بتسمية toptal-s3-example .

مكون الخدمة الرئيسي لدينا الآن هو كما يلي:

 @Service public class StorageService { @Value("${aws.accesKeyId}") private String awsAccessKeyId; @Value("${aws.secretKey}") private String awsSecretKey; @Value("${aws.bucketName}") private String awsBucketName; private AWSCredentials credentials; private AmazonS3 s3client;; @PostConstruct public void init(){ credentials = new BasicAWSCredentials(awsAccessKeyId, awsSecretKey); s3client = new AmazonS3Client(credentials); } public void uploadFile(MultipartFile file) throws IOException { File fileForUpload = transformMultipartToFile(file); s3client.putObject(new PutObjectRequest(awsBucketName, file.getOriginalFilename(), fileForUpload)); } public InputStream downloadFile(String amazonFileKey) throws IOException { S3Object fetchFile = s3client.getObject(new GetObjectRequest(awsBucketName, amazonFileKey)); InputStream objectData = fetchFile.getObjectContent(); return objectData; } …

تقرأ StorageService بيانات الاعتماد من ملف application.properties وتستخدمها لإنشاء مثيل لكائن BasicAWSCredentials ، وبالتالي كائن AmazonS3Client . ما يلي هو مجرد استدعاء putObject لتحميل الملف و getObject لتنزيل الملف ، على كائن عميل Amazon S3.

سنقوم بتشغيل الخدمة داخل حاوية Docker ، وأثناء عملية إنشاء Gradle ، سنبني صورة Docker. سنفعل ذلك عن طريق تكوين ملف build.gradle ، على النحو التالي:

 buildscript { ... dependencies { ... classpath('se.transmode.gradle:gradle-docker:1.2') } } ..... apply plugin: 'docker' ... task buildDocker(type: Docker, dependsOn: build) { push = false applicationName = "storageservice" dockerfile = file('src/main/docker/Dockerfile') doFirst { copy { from jar into stageDir } } }

يعتبر جزء Buildscript apply plugin قياسيًا جدًا. لقد حددنا أيضًا مهمة buildDocker تقرأ تهيئة Docker المخزنة في src/main/docker/Dockerfile ، وتقوم بنسخ ملف JAR إلى بناء Docker.

يحتوي Dockerfile على قائمة بأوامر Docker الخالصة التي سنجهز بها صورتنا:

 FROM frolvlad/alpine-oraclejdk8 ADD storageWebService-0.0.1-SNAPSHOT.jar storageService.jar EXPOSE 8080 CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/storageService.jar"]

من المتطلبات الأساسية لتشغيل تطبيقنا تثبيت Java Virtual Machine (JVM). يوفر Docker قائمة بالصور مثبت عليها Java ، وسوف نختار واحدة من أصغرها ، استنادًا إلى الحد الأدنى من 5 ميغابايت Alpine Linux. تحتوي صورة frolvlad/alpine-oraclejdk8 على كل ما نحتاجه وهي صغيرة جدًا (فقط 170 ميجا بايت).

يقوم الأمر FROM بتعيين الصورة المذكورة كقاعدة سيتم بناء صورتنا عليها. storageService.jar ADD بعد ذلك ، نحدد حاوية Docker للاستماع على المنفذ 8080 في وقت التشغيل باستخدام الأمر EXPOSE . ومع ذلك ، لن يؤدي هذا إلى تمكين الاتصال بـ 8080 من المضيف. عند الانتهاء من الصورة ، ونريد تشغيلها ، سنحتاج أيضًا إلى نشر المنفذ على الحاوية باستخدام الأمر التالي docker run -p 8080:8080 amazonRepository/storageservice ، حيث amazonRepository هو مستودع سنقوم بتكوينه لاحقًا في هذا الدورة التعليمية. باستخدام CMD ، نحدد الأوامر التي سيتم تنفيذها عند تشغيل الحاوية. القيم الموجودة بين قوسين من أمر CMD تعني ببساطة أنه سيتم تنفيذ ما يلي عندما نقوم بتشغيل الحاوية:

 java -Djava.security.egd=file:/dev/./urandom -jar /storageService.jar

الخيار -Djava.security.egd=file:/dev/./urandom مطلوب للمساعدة في تخفيف تأخيرات JVM أثناء بدء التشغيل. إذا تم حذفه ، فسيؤدي ذلك إلى جعل تشغيل التطبيق بطيئًا للغاية بسبب عملية إنشاء الأرقام العشوائية اللازمة أثناء عملية التمهيد.

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

عمليات التطبيق والنظام

أولاً ، نحتاج إلى خادم Linux نظيف لإعداد أداة Jenkins CI عليه. لاحظ أن الإرشادات التالية خاصة بـ Ubuntu 14.04. ضع في اعتبارك أن التعليمات قد تختلف قليلاً بالنسبة لتوزيعات Linux الأخرى. إصدار Jenkins المستخدم هو 2.7.1 وقد تختلف الشاشات والتعليمات قليلاً اعتمادًا على إصدار Jenkins المستخدم.

لذلك ، نذهب إلى وحدة تحكم خادم Linux الخاصة بنا ونبدأ في تثبيت المتطلبات الأساسية.

متطلب JDK

نحن بحاجة إلى تثبيت JDK. فيما يلي تعليمات لتثبيت JDK8.

 sudo add-apt-repository ppa:webupd8team/java sudo apt-get install python-software-properties sudo apt-get update sudo apt-get install oracle-java8-installer java -version

تثبيت Docker

لكي يتمكن Jenkins من تشغيل تصميمات Docker ، نحتاج إلى تثبيت docker-engine النحو التالي:

 sudo apt-get install apt-transport-https ca-certificates sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D #create a docker list file sudo vi /etc/apt/sources.list.d/docker.list #add the following entry in the docker.list file (change trusty to #the release you are running on if you are running on different, ie. #xenial, precise...): deb https://apt.dockerproject.org/repo ubuntu-trusty main #save and exit the file sudo apt-get update apt-cache policy docker-engine sudo apt-get install docker-engine

نظرًا لأننا قمنا الآن بتثبيت محرك Docker ، سنبدأ باستخدام الأمر التالي صورة hello-world لتأكيد عمل Docker بشكل صحيح.

 sudo docker run hello-world

سيبدو إخراج صورة Hello-world على النحو التالي ، وبهذا ، يمكننا تأكيد أن المحرك يعمل بشكل جيد.

تثبيت واجهة سطر أوامر AWS (CLI)

بعد ذلك ، سنقوم بتثبيت AWS CLI. لاحقًا ، في تكوين وظيفة Jenkins ، سنستخدم CLI لتنفيذ أوامر مصادقة AWS ودفع صورة Docker إلى سجل حاوية Amazon EC2.

لتثبيت AWS CLI ، نتبع الإرشادات الموضحة بالتفصيل في وثائق Amazon CLI.

من بين خياري التثبيت ، سنختار التثبيت باستخدام Pip ، وهو نظام إدارة الحزم المستخدم لتثبيت وإدارة برامج Python. سنقوم بتثبيت Pip و AWS CLI ببساطة عن طريق تشغيل الأوامر الثلاثة التالية:

 #install Python version 2.7 if it was not already installed during the JDK #prerequisite installation sudo apt-get install python2.7 #install Pip package management for python sudo apt-get install python-pip #install AWS CLI sudo pip install awscli

AWS ECR

كخطوة أخيرة في عملية الإنشاء ، سنقوم بدفع صورة Docker الخاصة بنا إلى سجل حاوية Amazon. في وحدة تحكم خدمات الويب في Amazon ، نجد AWS EC2 Container Service.

نختار قائمة المستودعات الفرعية على اليسار ونضغط على البدء .

بعد ذلك يتم تقديم الشاشة الأولى لتكوين المستودع حيث ندخل اسم المستودع ونضغط على زر الخطوة التالية .

يؤدي النقر فوق الخطوة التالية إلى إظهار شاشة تحتوي على إرشادات حول كيفية دفع الصور إلى المستودع.

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

تثبيت وتكوين Jenkins

لتثبيت Jenkins ، نقوم بإدخال الأوامر التالية في الغلاف:

 #Download Jenkins key and pipe it to apt-key tool, apt-key command #add will read from input stream, as defined by „–„. When added #apt will be able to authenticate package to be installed. wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - #create a sources list for jenkins sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list' #update your local package list sudo apt-get update #install jenkins sudo apt-get install jenkins

عند انتهاء التثبيت ، يبدأ Jenkins تلقائيًا. تحقق من حالة الخدمة باستخدام الأمر التالي:

 sudo service jenkins status

سيتصل Jenkins بمستودع Bitbucket Git ، وللقيام بذلك ، نحتاج إلى تثبيت Git.

 #install Git sudo apt-get install git

سيقوم Jenkins بتشغيل عملية بناء Gradle ، والتي سيتم خلالها إنشاء صورة Docker. لتتمكن من القيام بذلك ، يجب إضافة مستخدم Jenkins إلى مجموعة مستخدم docker :

 #add Jenkins user to docker user group sudo usermod -aG docker jenkins

أثناء عملية الإنشاء ، ستدفع Jenkins صور Docker إلى Amazon ECR. لتمكين ذلك ، نحتاج إلى تكوين AWS لمستخدم Jenkins.

أولاً ، نحتاج إلى التبديل إلى مستخدم jenkins . للقيام بذلك ، نحتاج إلى تعيين كلمة مرور.

 #change Jenkins password sudo passwd jenkins #switch to Jenkins user su – jenkins #configure AWS aws configure

بعد إدخال أمر aws configure ، نبدأ في إدخال مفتاح الوصول السري الذي تم إنشاؤه ومعرف المفتاح (هذه هي بيانات الاعتماد التي أنشأناها مسبقًا في العملية). في حالتي ، منطقة الحساب هي us-west-2 ، ولذا فقد قمت بإدخال ذلك. قمنا أيضًا بتعيين تنسيق الإخراج الافتراضي لأوامر AWS ليكون JSON.

يمكننا الآن الانتقال إلى تكوين Jenkins من خلال وحدة تحكم الويب التي يمكن الوصول إليها على المنفذ 8080.

عندما نصل إلى عنوان URL ، تظهر لنا شاشة البدء التالية.

كما هو موضح على الشاشة ، نحتاج إلى إدخال كلمة المرور. بعد القيام بذلك ، يطلب منا معالج الإعداد القيام بما يلي:

• اختر المكونات الإضافية المراد تثبيتها - سنختار تثبيت المكونات الإضافية المقترحة .
• قم بإنشاء أول مستخدم إداري عن طريق إدخال بيانات اعتماد المستخدم

عند الانتهاء ، انقر فوق حفظ وإنهاء . بهذا نكون قد انتهينا من تكوين إعداد Jenkins.

قبل أن نبدأ في تحديد وظيفة الإنشاء ، نحتاج إلى إضافة بعض المكونات الإضافية الإضافية. سنذهب إلى Manage Jenkins ونضغط على Manage plugins . في علامة التبويب المتوفرة ، نجد أولاً المكون الإضافي لـ Bitbucket ، وحدد المربع ، وانقر فوق تنزيل وتثبيت بعد إعادة التشغيل .

سيتم تقديمك بعد ذلك بشيء مثل الشاشة التالية.

بعد تثبيت البرنامج المساعد ، نكرر العملية للإضافات التالية التي ستكون ضرورية لإعداد الوظيفة:

• البرنامج المساعد Gradle
• Docker build step plugin
• Cloudbees Docker مخصص لبيئة البناء
• المكون الإضافي Amazon ECR

سيرسل المكون الإضافي لخطوة Docker الذي نستخدمه الطلبات إلى Docker daemon. لهذا الغرض ، نحتاج إلى تمكين مقبس TCP على المنفذ 2375. للقيام بذلك ، ندخل ملف تكوين Docker الموجود في etc/default/docker .

 sudo vi /etc/default/docker

هنا نضيف السطر التالي في التكوين:

 DOCKER_OPTS='-H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock'

نحفظ الملف ونخرج منه ونعيد تشغيل خدمة Docker و Jenkins.

 sudo service docker restart sudo service jenkins restart

بعد إعادة تشغيل Jenkins ، ننتقل إلى وحدة تحكم Jenkins ، ومن Manage Jenkins ، نختار Configure System .

نجد قسم Docker builder وأدخل http://localhost:2375 لعنوان URL الخاص بـ REST API ، انقر فوق تطبيق لتأكيد التغيير. ثم نضغط على اختبار الاتصال لنأمل أن نؤكد أن كل شيء على ما يرام.

نحفظ التكوين وننتقل إلى تكوين وظيفة Jenkins.

تكوين الوظيفة

نذهب إلى صفحة Jenkins الرئيسية وننشئ عنصرًا جديدًا .

نختار مشروع Freestyle وندخل اسم المشروع كما هو موضح بالشاشة التالية:

بالضغط على " موافق " ، تظهر لنا صفحة تكوين الوظيفة. نريد أن يتم بناء المشروع على كل دفعة إلى مستودع Bitbucket Git الخاص بنا. لتحقيق ذلك ، نحتاج أولاً إلى تحديد المستودع الذي نتصل به.

الخطوة 1: إدارة كود المصدر

تحت إدارة كود المصدر ، نختار Git وأدخل عنوان URL لمستودع Bitbucket الخاص بنا. عنوان URL له شكل https://bitbucket.org/bitbucketUsername/repositoryName .

بعد إدخال عنوان URL ، سيحاول Jenkins تلقائيًا اختبار الاتصال. نظرًا لأننا لم ندخل بيانات الاعتماد بعد ، فسيظهر خطأ يشير إلى أنه لا يمكن الاتصال.

افتح القائمة المنسدلة إضافة ، وانقر على موفر Credentials Jenkins .

يتم تقديم الشاشة التالية ، حيث نقوم بإدخال اسم المستخدم وكلمة المرور لحساب Bitbucket الخاص بنا.

بعد إضافة سجل بيانات الاعتماد الجديد ، نتأكد من تحديده في القائمة المنسدلة لبيانات الاعتماد ، وهذا ينهي إعداد إدارة رمز المصدر .

الخطوة 2: بناء المشغلات

تحقق من Trigger يبني عن بعد ويحدد رمز المصادقة. تأكد من تحديد رمز عشوائي وآمن.

الخطوة 3: Bitbucket Webhook

قدم لنا Jenkins بالفعل عنوان URL الذي سنستخدمه في Bitbucket. نذهب إلى صفحة مستودع Bitbucket الخاصة بنا ، وفي قائمة الإعدادات ، انقر فوق خطافات الويب . بعد ذلك ، يؤدي النقر فوق Add webhook إلى عرض الشاشة التالية ، والتي نقوم بملئها على النحو التالي:

يحتوي عنوان URL على البنية التالية: http://JENKINS_URL _HOST:PORT/job/JOB_NAME/build?token=TOKEN .

أدخل القيم أعلاه على التوالي باستخدام عنوان URL الخاص بـ Jenkins ، والمنفذ الذي يعمل عليه ، واسم الوظيفة التي قمت بإنشائها ، والرمز المميز الذي حددته مسبقًا.

بعد حفظ Webhook ، سيتم تزويدك بالشاشة التالية ، والتي يمكنك تعديلها إذا لزم الأمر ، أو عرض الطلبات التي تم إنشاؤها في كل مرة نقوم فيها بدفع رمز جديد.

باستخدام هذا التكوين ، يتم تشغيل webhook في كل دفعة للمستودع ، بغض النظر عن الفرع. على جانب Jenkins ، يمكننا تحديد دفع الفرع الذي سيؤدي إلى الإنشاء.

لكي تتمكن Bitbucket من دفع التعليمات البرمجية إلى Jenkins ، نحتاج إلى إعادة تكوين أمان Jenkins العالمي للسماح بالوصول المجهول للقراءة. بالإضافة إلى ذلك ، من أجل الإعداد لدينا ، يتعين علينا تعطيل خيار Jenkins الافتراضي الذي يمنع تزوير طلبات المواقع المشتركة. للقيام بذلك ، انتقل إلى إدارة Jenkins واختر تكوين الأمان العالمي . حدد السماح بالوصول المجهول للقراءة وتحقق من منع عمليات استغلال التزوير عبر المواقع . ثم احفظ التكوين.

يرجى ملاحظة أن هذا يتم فقط لأسباب بسيطة. يتجاوز الإعداد الكامل تغطية هذا البرنامج التعليمي ، وسيشمل المزيد من تأمين Jenkins خلف وكيل عكسي ، على اتصال TLS ، وتمكين منع CSRF.

الخطوة 4: بناء Gradle

يمكننا الآن العودة إلى وظيفة Jenkins ومواصلة تكوينها. في قسم الإنشاء ، نضيف خطوة بناء: استدعاء برنامج gradle script .

في هذا النموذج ، ندخل ما يلي:

كما هو موضح على الشاشة ، سنستخدم غلاف Gradle ، وهي ميزة ملائمة لـ Gradle لا تتطلب منك تثبيت Gradle على المضيف. تأكد من تحديد مربع Make gradlew القابل للتنفيذ .

في المهام ، نحدد build و buildDocker .

الخطوة 5: صورة Docker Tag

يقوم هذا الجزء من البناء بوضع علامة على صورة Docker التي تم إعدادها مسبقًا بواسطة مهمة dockerBuild الخاصة بشركة Gradle. لهذا ، أضفنا خطوة بناء جديدة إلى الوظيفة: تنفيذ أمر Docker . نختار أمر Tag image وقمنا بتعيين اسم الصورة والمستودع الهدف حيث سنقوم بدفع الصورة والعلامة:

الخطوة 6: دفع عامل الإرساء إلى Amazon ECR

أخيرًا ، نحتاج إلى تحديد كيفية دفع صورتنا إلى Amazon ECR. لهذا الغرض ، أضفنا خطوة جديدة لبناء قذيفة Execute وقمنا بتعيين الأوامر للمصادقة على AWS ودفع الصورة إلى Amazon ECR:

 #region for our account is us-west-2 aws ecr get-login --region us-west-2 | bash #push the previously tagged image docker push 058432294874.dkr.ecr.us-west-2.amazonaws.com/springbootdocker:${BUILD_NUMBER} 

بهذا نكون قد انتهينا من عملية البناء. بعد دفع رمز جديد إلى الريبو ، سيتم تنشيط هذه الوظيفة ، وسيكون لدينا صورة Docker جديدة تم تحميلها إلى سجل Docker "تلقائيًا بطريقة سحرية".

يمكن بعد ذلك سحب الصورة إلى أي مكان تم تثبيت docker-engine لدينا ، ويمكن تشغيله باستخدام الأمر التالي:

 docker run -p 8080:8080 amazonRepository/springbootdocker

سيبدأ هذا الأمر الخدمة المصغرة لـ Spring Boot ، مع نقاط النهاية التالية لتحميل وتنزيل ملفاتنا إلى حاوية S3:

• http://hostnameURL:8080/api/storage/upload
• http://hostnameURL:8080/api/storage/download?fileName=xyz

خطوات أخرى مع Java والتكامل المستمر

هناك دائما المزيد من الأشياء للقيام بها. تمت تغطية الكثير من الأمور في هذا البرنامج التعليمي ، لكنني سأعتبر هذا مجرد نقطة بداية يمكن من خلالها التعلم بشكل أكبر. إن وضع Jenkins خلف خادم وكيل ويب ، مثل Nginx ، وإنشاء اتصال TLS ، هما مثالان فقط لما يمكن ، ويمكن القول أنه ينبغي القيام به.

صورة Docker الخاصة بنا متاحة على Amazon ECR وجاهزة للنشر. يمكننا الآن أخذه ونشره يدويًا. ومع ذلك ، فإن الحل الأفضل هو أتمتة ذلك بشكل أكبر. CI هي الخطوة الأولى فقط ، والخطوة التالية هي التسليم المستمر. ماذا عن التوافر العالي؟ يوفر Amazon AWS EC2 ميزات لتسجيل الحاويات في السحابة في بيئة مجمعة وهو أمر إلزامي للخدمة القائمة على الإنتاج. يمكن العثور على مثال عملي جيد لتطوير عملية التسليم المستمر في منشور مدونة AWS التالي.

خاتمة

بشكل عام ، قمنا بتنفيذ عملية تطوير برمجيات سلسة ونظيفة. باستخدام الأدوات المتاحة ، أنشأنا بنية تحتية تساعد على زيادة إنتاجيتنا. الآن ، لا داعي للقلق بشأن تكوين خدمة Java الخاصة بنا وهي خدمة ويب بسيطة بنقطة نهاية REST. نترك اتفاقية Spring Boot تهتم بكل شيء وتركز فقط على منطق الخدمة. نستخدم Jenkins لإنشاء صورة Docker جديدة في كل مرة نقوم فيها بدفع الكود الخاص بنا إلى مستودع Bitbucket Git الخاص بنا ، وفي النهاية ، قمنا بتعيين السحابة لتكون مسؤولة عن تخزين صور وملفات Docker الخاصة بنا. عندما ننشر خدمتنا المضمنة في صورة Docker ، سنحرص على عدم وجود أي قيود من نظام التشغيل (طالما أن نظام التشغيل به docker-engine مثبت).