dockerfile maven

ملف دوكر فايل مافن

الحالة : ناضجة

في هذه المرحلة، نحن لا نقوم بتطوير أو قبول ميزات جديدة أو حتى إصلاح الأخطاء غير الحرجة.

يدمج هذا المكون الإضافي Maven بين Maven وDocker.

أهداف التصميم هي:

• لا تفعل أي شيء خيالي. Dockerfile هي الطريقة التي يمكنك من خلالها إنشاء مشاريع Docker؛ هذا ما يستخدمه هذا البرنامج المساعد. فهي إلزامية.
• اجعل عملية بناء Docker تتكامل مع عملية بناء Maven. إذا قمت بربط المراحل الافتراضية، فعند كتابة mvn package ، ستحصل على صورة Docker. عندما تكتب mvn deploy ، يتم دفع صورتك.
• اجعل الأهداف تتذكر ما تفعله. يمكنك كتابة mvn dockerfile:build و mvn dockerfile:tag و mvn dockerfile:push دون مشاكل. وهذا أيضًا يلغي الحاجة إلى شيء مثل mvn dockerfile:build -DalsoPush ؛ بدلاً من ذلك، يمكنك فقط قول mvn dockerfile:build dockerfile:push .
• التكامل مع مفاعل بناء Maven. يمكنك الاعتماد على صورة Docker لمشروع واحد في مشروع آخر، وسيقوم Maven ببناء المشاريع بالترتيب الصحيح. يعد هذا مفيدًا عندما تريد تشغيل اختبارات التكامل التي تتضمن خدمات متعددة.

يلتزم هذا المشروع بمدونة قواعد السلوك المفتوحة. من خلال المشاركة، يتوقع منك احترام هذا الرمز.

راجع سجل التغيير للحصول على قائمة الإصدارات

يثبت

يتطلب هذا المكون الإضافي Java 7 أو إصدارًا أحدث وApache Maven 3 أو إصدارًا أحدث (يحتاج dockerfile-maven-plugin <=1.4.6 إلى Maven >= 3، وفي الحالات الأخرى، Maven >= 3.5.2). لإجراء اختبارات التكامل أو استخدام المكون الإضافي عمليًا، يلزم إعداد Docker فعال.

مثال

لمزيد من الأمثلة، راجع دليل اختبار التكامل.

على وجه الخصوص، يعرض الاختبار المتقدم خدمة كاملة تتكون من خدمتين صغيرتين تم اختبار تكاملهما باستخدام helios-testing .

يؤدي هذا إلى تهيئة المكوّن الإضافي الفعلي لإنشاء صورتك باستخدام mvn package ودفعها باستخدام mvn deploy . بالطبع يمكنك أيضًا قول mvn dockerfile:build صراحة.

< plugin >
  < groupId >com.spotify</ groupId >
  < artifactId >dockerfile-maven-plugin</ artifactId >
  < version >${dockerfile-maven-version}</ version >
  < executions >
    < execution >
      < id >default</ id >
      < goals >
        < goal >build</ goal >
        < goal >push</ goal >
      </ goals >
    </ execution >
  </ executions >
  < configuration >
    < repository >spotify/foobar</ repository >
    < tag >${project.version}</ tag >
    < buildArgs >
      < JAR_FILE >${project.build.finalName}.jar</ JAR_FILE >
    </ buildArgs >
  </ configuration >
</ plugin >

يمكن أن يبدو Dockerfile المقابل كما يلي:

 FROM openjdk:8-jre
MAINTAINER David Flemström <[email protected]>

ENTRYPOINT ["/usr/bin/java", "-jar", "/usr/share/myservice/myservice.jar"]

# Add Maven dependencies (not shaded into the artifact; Docker-cached)
ADD target/lib           /usr/share/myservice/lib
# Add the service itself
ARG JAR_FILE
ADD target/${JAR_FILE} /usr/share/myservice/myservice.jar

ملاحظة هامة

من المحتمل أن تكون الطريقة الأكثر شيوعًا للإشارة إلى قطعة البناء هي استخدام متغير project.build.directory للإشارة إلى دليل "الهدف". ومع ذلك، يؤدي هذا إلى مسار مطلق، وهو غير مدعوم بواسطة أمر ADD في ملف Dockerfile. يجب أن يكون أي مصدر من هذا القبيل داخل سياق بنية Docker وبالتالي يجب الرجوع إليه بواسطة مسار نسبي . انظر رقم 101

لا تستخدم ${project.build.directory} كطريقة للإشارة إلى دليل البناء الخاص بك.

ماذا يعطيني؟

هناك العديد من المزايا لاستخدام هذا البرنامج المساعد للبنيات الخاصة بك.

أوقات بناء أسرع

يتيح لك هذا المكون الإضافي الاستفادة من ذاكرة التخزين المؤقت لـ Docker بشكل أكثر اتساقًا، مما يؤدي إلى تسريع إصداراتك بشكل كبير من خلال السماح لك بتخزين تبعيات Maven في صورتك. كما أنه يشجع على تجنب البرنامج maven-shade-plugin ، والذي يعمل أيضًا على تسريع عملية البناء بشكل كبير.

دورة حياة بناء متسقة

لم يعد عليك أن تقول شيئًا مثل:

 mvn package
mvn dockerfile:build
mvn verify
mvn dockerfile:push
mvn deploy

وبدلا من ذلك، يكفي أن نقول ببساطة:

 mvn deploy

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

تعتمد على صور Docker للخدمات الأخرى

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

< dependency >
  < groupId >com.spotify</ groupId >
  < artifactId >foobar</ artifactId >
  < version >1.0-SNAPSHOT</ version >
  < type >docker-info</ type >
</ dependency >

يمكنك الآن قراءة معلومات حول صورة Docker الخاصة بالمشروع الذي اعتمدت عليه:

 String imageName = getResource ( "META-INF/docker/com.spotify/foobar/image-name" );

يعد هذا أمرًا رائعًا لاختبار التكامل حيث تريد أحدث إصدار من صورة Docker لمشروع آخر.

لاحظ أنه يتعين عليك تسجيل ملحق Maven في POM الخاص بك (أو POM الأصلي) حتى يتم دعم نوع docker-info :

< build >
  < extensions >
    < extension >
      < groupId >com.spotify</ groupId >
      < artifactId >dockerfile-maven-extension</ artifactId >
      < version >${version}</ version >
    </ extension >
  </ extensions >
</ build >

استخدم أدوات Docker الأخرى التي تعتمد على Dockerfiles

يبدو مشروعك (مشاريعك) كما يلي:

 a/
  Dockerfile
  pom.xml
b/
  Dockerfile
  pom.xml

يمكنك الآن استخدام هذه المشاريع مع Fig أو docker-compose أو أي نظام آخر يعمل مع Dockerfiles. على سبيل المثال، قد يبدو docker-compose.yml بالشكل التالي:

 service-a :
  build : a/
  ports :
  - ' 80 '

service-b :
  build : b/
  links :
  - service-a

الآن، سيعمل docker-compose up و docker-compose build كما هو متوقع.

الاستخدام

انظر مستندات الاستخدام.

المصادقة

راجع مستندات المصادقة.

الافراج

لقطع إصدار Maven:

 mvn clean [-B -Dinvoker.skip -DskipTests -Darguments='-Dinvoker.skip -DskipTests'] 
  -Dgpg.keyname=<key ID used for signing artifacts> 
  release:clean release:prepare release:perform

نستخدم gren لإنشاء الإصدارات في Github:

 gren release