Es scheint, dass dies so ist? Wir verbinden das Fabric8-Maven-Plugin mit dem Projekt und gehen: Erstellen, Ausführen der Anwendung in OpenShift. Aber als ich studierte, wollte ich mehr Verständnis für diesen Prozess und dann mehr Kontrolle und Freiheit über den Prozess des Erstellens und Bereitstellens der Anwendung in OpenShift. Das folgende Szenario stellte sich daher mit solchen Funktionen heraus.- Ich baue das Artefakt selbst mit meinem Werkzeug (Maven, Gradle usw.)
- Ich steuere die Erstellung von Docker Image über die Docker-Datei
- Der Erstellungs- und Bereitstellungsprozess in Openshift ist in der Vorlage konfiguriert, d. H. Alle Containerspezifikationen und Pods können angepasst werden.
- Somit kann der Prozess selbst auf ein externes Assembly-Bereitstellungssystem übertragen werden
Dazu nutze ich natürlich die zahlreichen Funktionen von OpenShift selbst.Und so habe ich ein Java-Artefakt vorbereitet, dann bereite ich eine Docker-Datei mit den Eigenschaften und Funktionen vor, die ich benötigeDockerfile
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" ]
Daher befinden sich zwei Dateien im Ordner: das Artefakt und die Docker-Datei.
Die Zusammensetzung der Dateien ist bedingt. Wenn beispielsweise in der Docker-Datei zusätzliche Dateien für das Docker-Image benötigt werden, fügen wir diese hier hinzu. Jetzt werden das grundlegende Java-Image und meine Spring-Boot-Anwendung in der Docker-Datei angegeben, zwei Ports sind offen usw.In diesem Schritt haben wir die Wahl / Freiheit im Tool zum Erstellen der Anwendung und zum Zusammenstellen des Docker-Images.Als nächstes bereite ich die OpenShift-Vorlage für die Anwendung vor. Dieser Vorgang kann einmalig sein und muss nur parametrisiert werden. Da es alles enthalten kann, was zum Erstellen, Starten und Betreiben der Anwendung möglich ist, werden wir diese Prozesse über sie verwalten. Es wird für mich ganz einfach sein und aus den drei wichtigsten Konfigurationen bestehen- Imagestream
- Buildconfig
- DeploymentConfig
Vorlage Java-App-Beispielkind: 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: {}
Einige Containerparameter werden in der Vorlage als Beispiel angegeben, z. B. Ressourcen / Grenzwerte, TZ-Umgebungsvariable, ein Vorlagenparameter wird angegeben - Anwendungsname (APP_NAME). Die Registrierungs-Docker-Adresse wird für die Minishift-Version (ich verwende sie lokal für die Entwicklung 172.30.1.1/10000/myproject/) und andere angegeben.Für mein Szenario ist hier jedoch das Wichtigste angegeben - kind: BuildConfig
spec:
source:
binary: {}
type: Binary
strategy:
type: Docker
Laut BuildConfig handelt es sich bei der Quelle um die Binärdatei (en). Zum Verwalten der Docker-Image-Vorbereitungsstrategie - Dockerfile (Typ: Docker)Erstellen wir diese Vorlage in OpenShift oc create -f template.yaml
Diese Vorlage wird im Vorlagenverzeichnis angezeigt (es ist möglich, den Prozess über die Web-UI-Konsole zu organisieren, jedoch nicht hier).
Mit dieser Vorlage erstellen wir eine Anwendung (tatsächlich ist dies nur ein Name und nicht mehr).oc new-app java-app-sample -p APP_NAME=app-sample
Geben Sie den Vorlagennamen und den Anwendungsnamenparameter an.
Drei meiner Konfigurationen wurden erstellt.Wir starten den Prozess der Montage und Bereitstellung der Anwendung im Container.>oc start-build app-sample --from-dir . --follow
Es ist wichtig, dass Sie von dem Ordner aus ausführen, in dem die Binärdatei und die Docker-Datei angegeben sind. Nur der Parameter --from-dir gibt an, dass der gesamte Ordner zum Laden in OpenShift vorbereitet wird, um ein Image in der Docker-Registrierung zu erstellen und bereitzustellen. Es gibt andere Parameter dieses Befehls, beispielsweise aus dem Archiv.
Wir sehen, dass der Inhalt des Ordners in OpenShift geladen wurde, wodurch der Docker-Prozess gestartet wurde, um das Image für die Docker-Datei vorzubereiten, und das Image schließlich in die Docker-Registrierung gestellt wurde.Die Anwendung wurde
in der OpenShift-Webkonsole gestartet. Die in der Konfiguration
angegebenen Containerparameter werden angegeben. Die in der Konfiguration angegebene Umgebungsvariable wird
protokolliert.
Daher konnten wir die Anwendung ohne zusätzliche Plugins mit maximaler Kontrolle und Wahlfreiheit in OpenShift platzieren.MaterialienWenn SieMinishift installieren , um mehr über OpenShift zu erfahren, würde ich empfehlen, mit Minishift zu beginnen