نشر تطبيقات Java في OpenShift

يبدو أن الأمر كذلك؟ نقوم بتوصيل النسيج 8-maven-plugin بالمشروع ونذهب: إنشاء التطبيق وتشغيله في OpenShift. ولكن عندما درست ، أردت مزيدًا من الفهم لهذه العملية ، ثم أردت مزيدًا من التحكم والحرية في عملية إنشاء التطبيق ونشره في OpenShift. وهكذا ، تحول السيناريو التالي مع هذه الميزات.

  • أنا أصنع الأداة بنفسي باستخدام أداتي (مخضرم ، خريج ، إلخ.)
  • أتحكم في إنشاء صورة Docker من خلال ملف Dockerfile
  • يتم تكوين عملية الإنشاء والنشر في Openshift في القالب ، أي أي مواصفات حاوية ، جراب للتخصيص.
  • وبالتالي ، يمكن نقل العملية نفسها إلى نظام نشر خارجي للتجميع

بالطبع ، لهذا أستخدم الميزات المتاحة لـ OpenShift نفسها ، والتي تتوفر بكثرة.
وبالتالي لدي قطعة أثرية جافا جاهزة ، ثم أقوم بإعداد ملف Dockerfile بالخصائص والوظائف التي أحتاجها

ملف Dockerfile

FROM openjdk

MAINTAINER Rylkov Alexander <arylkov@.>

COPY demo.springboot.mvn-0.0.1-SNAPSHOT.jar /deployments/app.jar

ENV JAVA_OPTS="$JAVA_OPTS -Xms500m -Xmx1024m"

EXPOSE 8080
EXPOSE 5005

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /deployments/app.jar" ]

وبالتالي ، سيكون هناك ملفان في المجلد: الأداة و Dockerfile.



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

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

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

  • Imagestream
  • Buildconfig
  • النشر

قالب java-app-sample
kind: Template
apiVersion: v1
metadata:
  labels:
    app: java-app-sample
  name: java-app-sample
  annotations:
    description: >-
      This example shows how to create a simple Java application in openshift
    tags: java
parameters:
  - name: APP_NAME
    description: application name
    value: app-sample
    required: true
objects:
  - kind: ImageStream
    apiVersion: v1
    metadata:
      name: "${APP_NAME}"
    spec:
      tags:
        - from:
            kind: DockerImage
            name: 172.30.1.1:5000/myproject/${APP_NAME}:latest
          name: latest
  - kind: BuildConfig
    apiVersion: v1
    metadata:
      name: "${APP_NAME}"
      labels:
        name: "${APP_NAME}"
    spec:
      source:
        binary: {}
        type: Binary
      strategy:
        type: Docker
      output:
        to:
          kind: DockerImage
          name: 172.30.1.1:5000/myproject/${APP_NAME}:latest
      postCommit: {}
      resources: {}
  - kind: DeploymentConfig
    apiVersion: v1
    metadata:
      name: "${APP_NAME}"
    spec:
      strategy:
        type: Rolling
        rollingParams:
          updatePeriodSeconds: 1
          intervalSeconds: 1
          timeoutSeconds: 120
        resources: {}
      replicas: 1
      selector:
        app: "${APP_NAME}"
      template:
        metadata:
          labels:
            app: "${APP_NAME}"
        spec:
          containers:
            - name: "${APP_NAME}"
              image: 172.30.1.1:5000/myproject/${APP_NAME}:latest
              ports:
                - containerPort: 8080
                  protocol: TCP
                - containerPort: 5005
                  protocol: TCP
              env:
                - name: TZ
                  value: Europe/Moscow
              resources:
                limits:
                  cpu: '0.5'
                  memory: 1000Mi
                requests:
                  cpu: '0.2'
                  memory: 500Mi
              imagePullPolicy: Always
          restartPolicy: Always
          dnsPolicy: ClusterFirst
    triggers:
      - type: ConfigChange
        imageChangeParams:
          automatic: true
          containerNames:
            - "${APP_NAME}"
          from:
            kind: ImageStreamTag
            name: 172.30.1.1:5000/myproject/${APP_NAME}:latest
      - type: ImageChange
    status: {}


يشار إلى بعض معلمات الحاوية في النموذج كمثال ، على سبيل المثال ، الموارد / الحدود ، متغير البيئة TZ ، يتم تحديد معلمة قالب واحدة - اسم التطبيق (APP_NAME). تم تحديد عنوان عامل إرساء التسجيل لإصدار minishift (أستخدمه محليًا للتطوير 172.30.1.1►000 / myproject /) وغيرها.

ولكن بالنسبة إلى السيناريو الخاص بي ، فإن أهم شيء موضح هنا

  - kind: BuildConfig
    spec:
      source:
        binary: {}
        type: Binary
      strategy:
        type: Docker

يقول BuildConfig أن المصدر سيكون الملف (الملفات) الثنائية ، ولإدارة استراتيجية إعداد صورة عامل الميناء - Dockerfile (النوع: Docker)

فلنقم بإنشاء هذا القالب في OpenShift

 oc create -f template.yaml


سيظهر هذا القالب في دليل القوالب (سيكون من الممكن تنظيم العملية من وحدة تحكم واجهة مستخدم الويب ، ولكن ليس هنا).



باستخدام هذا النموذج ، سننشئ تطبيقًا (في الواقع ، هذا مجرد اسم وليس أكثر)

oc new-app java-app-sample -p APP_NAME=app-sample

تحديد اسم القالب ومعلمة اسم التطبيق



تم إنشاء ثلاثة من التكوينات الخاصة بي.

نبدأ عملية التجميع ونشر التطبيق في الحاوية.

>oc start-build app-sample --from-dir . --follow

من المهم التنفيذ من المجلد حيث يشار إلى الملف الثنائي وملف Dockerfile ، تشير المعلمة --from-dir فقط إلى أنه سيتم تحضير المجلد بأكمله للتحميل في OpenShift لبناء ونشر الصورة في سجل عامل الميناء. هناك معلمات أخرى لهذا الأمر ، على سبيل المثال من الأرشيف.



نرى أن محتويات المجلد تم تحميلها في OpenShift ، والتي أطلقت عملية Docker لتحضير صورة لملف Dockerfile وأخيرًا وضعت الصورة في سجل عامل الميناء.

بدء تشغيل التطبيق



في وحدة OpenShift على شبكة الإنترنت. والمعلمات حاوية المحدد في التكوين



المحدد. ومتغير البيئة المحددة في تكوين



تسجيل



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

المواد

تثبيت Minishift
لمعرفة المزيد عن OpenShift ، أوصي بالبدء بـ Minishift

All Articles