حاوية تطبيقات Kotlin باستخدام Docker: دليل شامل

لماذا تعتبر حاوية Kotlin أمرًا لا بد منه للمطور الحديث؟

تخيل الموقف: لقد كتبت تطبيق Kotlin رائع على جهاز MacBook الخاص بك. كل شيء يعمل بشكل مثالي. ترسل الكود إلى زميل على Windows - قاعدة البيانات لا تتصل. وآخر على Linux - إصدار JDK ليس صحيحًا. مألوف؟ Docker يحل هذه المشكلة مرة واحدة وإلى الأبد.

حاوية تطبيقات Kotlin ليست مجرد موضة عابرة. إنها طريقة لضمان أن تطبيقك سيعمل بنفس الطريقة على أي جهاز: من كمبيوتر محمول لمبتدئ إلى خادم إنتاج في AWS. في هذه المقالة، سنشرح كيفية تعبئة تطبيق Kotlin بشكل صحيح في صورة Docker، وتحسين حجمها، وإعدادها للإنتاج.

ما ستتعلمه:

\n
• كيفية كتابة Dockerfile لتطبيق Kotlin باستخدام Gradle
\n
• كيفية تقليل حجم الصورة بمقدار 3-5 مرات
\n
• كيفية استخدام Docker Compose لربط Kotlin + قاعدة البيانات
\n
• أفضل الممارسات لحاوية الإنتاج
\n

Dockerfile أساسي لتطبيق Kotlin

لنبدأ بشيء بسيط. لنفترض أن لديك تطبيق Kotlin قياسي يتم بناؤه باستخدام Gradle. أول ما يتبادر إلى الذهن هو أخذ صورة JDK، ونسخ المصادر، وتشغيل البناء. دعنا نفعل ذلك، ولكن مع مراعاة أفضل الممارسات على الفور.

البناء المتكامل (لا تفعل هذا في الإنتاج)

# Dockerfile\nFROM gradle:7.6-jdk17 AS build\nWORKDIR /app\nCOPY build.gradle.kts settings.gradle.kts ./\nCOPY src ./src\nRUN gradle build --no-daemon -x test\n\nFROM openjdk:17-jdk-slim\nWORKDIR /app\nCOPY --from=build /app/build/libs/app.jar app.jar\nEXPOSE 8080\nCMD ["java", "-jar", "app.jar"]

هذا الأسلوب يعمل، لكن له ثلاثة عيوب خطيرة:

\n
• الحجم: تزن الصورة حوالي 400-500 ميجابايت بسبب JDK الكامل
\n
• التخزين المؤقت: مع أي تغيير في المصادر، سيقوم Gradle بتنزيل التبعيات مرة أخرى
\n
• الأمان: تبقى أدوات البناء في الصورة وهي غير ضرورية في وقت التشغيل
\n

البناء المحسّن: تعدد المراحل والتخزين المؤقت

السحر الحقيقي لـ Docker هو multi-stage builds. سنقسم العملية إلى ثلاث مراحل:

\n
• تحميل التبعيات (مخزنة مؤقتًا)
\n
• بناء التطبيق
\n
• الصورة النهائية المصغرة
\n

Dockerfile الصحيح لـ Kotlin + Gradle

# Stage 1: تحميل التبعيات\nFROM gradle:7.6-jdk17 AS dependencies\nWORKDIR /app\nCOPY build.gradle.kts settings.gradle.kts ./\nRUN gradle dependencies --no-daemon\n\n# Stage 2: البناء\nFROM dependencies AS build\nCOPY src ./src\nRUN gradle build --no-daemon -x test\n\n# Stage 3: الصورة النهائية\nFROM eclipse-temurin:17-jre-alpine\nWORKDIR /app\nCOPY --from=build /app/build/libs/app.jar app.jar\nRUN addgroup -S appgroup && adduser -S appuser -G appgroup\nUSER appuser\nEXPOSE 8080\nCMD ["java", "-jar", "app.jar"]

ما الذي تغير؟

\n
• Alpine JRE بدلاً من JDK الكامل - تقل الصورة إلى ~120 ميجابايت
\n
• التخزين المؤقت للتبعيات - إذا لم يتغير build.gradle.kts، يستخدم Docker ذاكرة التخزين المؤقت
\n
• الأمان - يتم تشغيل التطبيق بواسطة مستخدم غير مميز
\n

البناء باستخدام Gradle Wrapper (الطريقة الموصى بها)

إذا كنت تستخدم Gradle Wrapper (ويجب عليك!)، يصبح Dockerfile أكثر أناقة. يضمن Wrapper أن إصدار Gradle سيكون هو نفسه لجميع المطورين وفي CI/CD.

FROM eclipse-temurin:17-jdk-alpine AS builder\nWORKDIR /app\nCOPY gradlew gradlew.bat ./\nCOPY gradle ./gradle\nRUN ./gradlew --version\n\nCOPY build.gradle.kts settings.gradle.kts ./\nRUN ./gradlew dependencies --no-daemon\n\nCOPY src ./src\nRUN ./gradlew build --no-daemon -x test\n\nFROM eclipse-temurin:17-jre-alpine\nWORKDIR /app\nCOPY --from=builder