[JAVA] 4. Erstellen eines Manifests und Ausführen eines Webmoduls
Einführung
Dieser Artikel ist eine Fortsetzung von 3 unten.
- Java-Webmodul schnell mit Google Kubernetes Engine (GKE) ausführen
- Docker-Image erstellen und Registrierung registrieren
- Erstellen einer Datenbank, auf die über das Webmodul zugegriffen wird
- Manifest erstellen und Webmodul ausführen (https://qiita.com/Turtle-child-No2/items/23982059d188e44618df)
4-1. Erstellen eines Manifests und Ausführen eines Webmoduls
Schritt 4-1.1
Erstellen Sie die Manifestdatei, die zum Platzieren der App (diesmal des Webmoduls) in GKE erforderlich ist. Starten Sie vi und erstellen Sie sample-app_dev.yaml mit den folgenden Inhalten.
- Stellen Sie sicher, dass Sie die beiden [project_id] entsprechend Ihrer eigenen Umgebung neu schreiben.
[userid]@cloudshell:~ ([project_id])$ vi sample-app_dev.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
#Der Name der Bereitstellung. Muss innerhalb des Namespace eindeutig sein
name: sample-app
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: sample-app
#Gibt die Wartezeit zwischen der Bereitschaft eines Pods und der Verwendung an.
#Der Standardwert ist 0 Sekunden. Wenn Sie es nicht angeben, wird es daher als sofort verwendbar behandelt.
minReadySeconds: 5
#Gibt die maximale Verarbeitungszeit für die Bereitstellungsverarbeitung an.
#Wenn die Verarbeitungszeit der Bereitstellung diese Zeit überschreitet
#Der Vorgang schlägt fehl, ProgressDeadlineExceeded wird auf den Status gesetzt und automatisch zurückgesetzt.
#Der Standardwert beträgt 600 Sekunden.
progressDeadlineSeconds: 600
strategy:
#Führen Sie ein fortlaufendes Update durch
type: RollingUpdate
rollingUpdate:
#Wie viel Reduzierung (Scale-In) ist zum Zeitpunkt der Aktualisierung für die Anzahl der aktuell ausgeführten Pods zulässig?
#Beispielsweise werden derzeit zwei Pods ausgeführt und maxUnavailable=50%(Oder 1)Wenn Sie einstellen
#Ermöglicht, dass 1 von 2 Pods aufgrund des Updates nicht verfügbar ist.
maxUnavailable: 50%
#Wie viel Erhöhung (Scale-Out) ist für die Anzahl der Pods zulässig, die zum Zeitpunkt der Aktualisierung ausgeführt werden?
#Beispielsweise werden derzeit zwei Pods und maxSurge ausgeführt=50%(Oder 1)Wenn diese Option aktiviert ist, ist aufgrund des Updates eine Skalierung von bis zu 1 Pod zulässig.
#Mit anderen Worten, während des Updates können bis zu 3 Einheiten einschließlich der alten Version den Pod starten.
maxSurge: 50%
#Dieser Teil ist das Temlate of Pod. Eine fortlaufende Aktualisierung erfolgt, wenn sich die Beschreibung hier ändert
template:
metadata:
labels:
#Etikettenspezifikation erforderlich spez.selector.Muss mit matchLabels übereinstimmen
app: sample-app
spec:
containers:
- name: sample-app-container
image: gcr.io/[project_id]/sample-app:latest
ports:
- containerPort: 8080
name: api-port
protocol: TCP
#Überprüfen Sie, ob es normal gestartet wurde. Wenn die Integritätsprüfung fehlschlägt, wird der Pod neu gestartet.
#initialDelaySeconds zeigt an, wie viele Sekunden nach dem Start der App die Integritätsprüfung gestartet wird.
#Beispielsweise ist es praktisch, diese Einstellung für Anwendungen festzulegen, deren Start lange dauert.
#timeoutSeconds gibt an, wie viele Sekunden auf die Antwort auf die Integritätsprüfung gewartet werden soll. Im Fall von livenessProbe ist es schneller zu erkennen, wenn es so kurz wie möglich ist, sodass die Wiederherstellung schnell erfolgt.
#Es gibt jedoch etwas zu beachten, und Sie müssen auch unter Last ein angemessenes Zeitlimit festlegen.
#Die App wird neu gestartet, obwohl es die geschäftigste Zeit ist und die Leistung beeinträchtigt wird. Daher ist es wichtig, die entsprechenden timeoutSeconds anzugeben.
#Wenn Sie keine Verbindung zum Liveness Test der Anwendung herstellen können oder ein HTTP-Fehlercode zurückgegeben wird
#periodSeconds ist ein geplanter Ausführungsplan.
#failThreshold startet den Container neu, wenn der angegebene Wert fehlschlägt.
livenessProbe:
httpGet:
scheme: HTTP
path: /sample-app/views/NewFile.jsp
port: api-port
initialDelaySeconds: 10
timeoutSeconds: 5
periodSeconds: 30
failureThreshold: 20
#Überprüfen Sie, ob der Pod in Betrieb ist. Senden Sie keinen Datenverkehr, wenn die Integritätsprüfung fehlschlägt(Startet den Pod nicht neu.
#Wenn die ReadinessProbe fehlschlägt, wird der Pod vom Service-Endpunkt entfernt.
#Wenn ich beispielsweise Updates rollte oder skalierte, funktionierte der neue Pod.
#Wenn eine Anfrage eingeht, bei der Sie noch keinen Datenverkehr empfangen können, sind Sie in Schwierigkeiten. Readiness Probe verhindert dies.
readinessProbe:
httpGet:
scheme: HTTP
path: /sample-app/servlet/MyServlet
port: api-port
initialDelaySeconds: 10
timeoutSeconds: 5
periodSeconds: 60
failureThreshold: 5
resources:
#Ressourcen, die für die Bereitstellung eines Pods benötigt werden(CPU/Erinnerung)Konkretisieren.
#Der Pod kann jedoch mehr Ressourcen als die angegebenen Ressourcenanforderungen verwenden.(Verwenden Sie limit, um die Ressourcennutzung zu begrenzen)
#Der Punkt ist, dass bei der Bereitstellung eines Pods die Bereitstellung durch Betrachten von Ressourcenanforderungen erfolgt, ohne die Ressourcennutzung des Knotens zu berücksichtigen.
#CPU 200m ist eine Abkürzung für 200-Milli-Kerne, was 1 CPU für 1000-Milli-Kerne entspricht.
#1 bei 200 Mill Kern/Es bedeutet, 5 CPUs zu verwenden.(Übrigens, CPU:Wenn Sie 1 angeben, CPU:Interpretiert als 1000m)
#500Mi ist 500mebibyte.
requests:
memory: "500Mi"
#Von Pods verwendete Ressourcen(CPU/Erinnerung)Kann eingeschränkt werden.
#Selbst wenn der Knoten über freie Ressourcen verfügt, können Ressourcen über den angegebenen Ressourcengrenzen nicht verwendet werden.
#Wenn Sie keine Ressourcenlimits angeben, können Sie unbegrenzte Ressourcen verwenden.
#Wenn keine Ressourcenanforderungen angegeben werden, wird in Ressourcenanforderungen ein Wert festgelegt, der dem Grenzwert ähnelt.
limits:
memory: "600Mi"
#Umgebungsvariablen für Datenbankhost und PostgreSQL-Instanz
#Legen Sie den Benutzer und das Kennwort für die Verbindung fest.
#Für den Datenbankhost wird eine Loopback-Adresse angegeben, da diese über den Cloud-SQL-Proxy eine Verbindung zur Datenbank herstellt.
env:
- name: POSTGRES_DB_HOST
value: 127.0.0.1:5432
# [START cloudsql_secrets]
#Verwenden Sie den in Artikel 3 erstellten geheimen Benutzernamen und das Kennwort
- name: POSTGRES_DB_USER
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: username
- name: POSTGRES_DB_PASSWORD
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: password
# [END cloudsql_secrets]
# [START proxy_container]
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.13
#Starten Sie das Proxing mit der Datenbank mit dem in Artikel 3 erstellten Secret Service-Konto
command: ["/cloud_sql_proxy",
"-instances=[project_id]:us-central1:sample-app-ist=tcp:5432",
"-credential_file=/secrets/cloudsql/credentials.json"]
# [START cloudsql_security_context]
securityContext:
runAsUser: 2 # non-root user
allowPrivilegeEscalation: false
# [END cloudsql_security_context]
#Hängen Sie das in Artikel 3 erstellte Geheimdienstkonto ein
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
# [END proxy_container]
#Die Zeit zwischen dem Start des Pod-Shutdown-Prozesses und dem Senden von SIGKILL.
#Wenn preStop eingestellt ist, wird SIGTERM gesendet, nachdem die preStop-Verarbeitung abgeschlossen ist.
#SIGLKILL wird gesendet, wenn der Prozess nicht innerhalb der in terminierungGracePeriodSeconds seit dem Start des Herunterfahrens angegebenen Anzahl von Sekunden abgeschlossen wurde.
#Der Standardwert sollte 30 Sekunden betragen.
terminationGracePeriodSeconds: 30
# [START volumes]
volumes:
- name: cloudsql-instance-credentials
secret:
secretName: cloudsql-instance-credentials
# [END volumes]
Schritt 4-1.2
Führen Sie die erstellte Manifestdatei aus. Es wurde erfolgreich erstellt.
[userid]@cloudshell:~ ([project_id])$ kubectl apply -f sample-app_dev.yaml --record
deployment.apps "sample-app" created
Schritt 4-1.3
Überprüfen Sie nach einer Weile, ob der Pod mit dem folgenden Befehl normal gestartet wird. Wenn READY 2/2 ist, haben die beiden Container normal gestartet.
[userid]@cloudshell:~ ([project_id])$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
[pod_name] 2/2 Running 0 40s 10.40.1.10 [node_name]
Schritt 4-1.4
Wenn es nicht normal gestartet wird, überprüfen Sie das Containerprotokoll mit dem folgenden Befehl. Das Folgende ist ein Protokoll, wenn der Beispiel-App-Container und der CloudSQL-Proxy-Container normal gestartet werden.
[userid]@cloudshell:~ ([project_id])$ kubectl logs [pod_name] -c sample-app-container
・
・
・
12-Mar-2019 12:02:50.933 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
12-Mar-2019 12:02:50.935 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.16]
12-Mar-2019 12:02:50.960 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/opt/apache-tomcat-9.0.16/webapps/sample-app]
12-Mar-2019 12:02:52.609 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
12-Mar-2019 12:02:52.705 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/opt/apache-tomcat-9.0.16/webapps/sample-app] has finished in [1,744] ms
12-Mar-2019 12:02:52.714 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
12-Mar-2019 12:02:52.786 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"]
12-Mar-2019 12:02:52.817 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [2,069] milliseconds
[userid]@cloudshell:~ ([project_id])$ kubectl logs [pod_name] -c cloudsql-proxy
2019/03/12 11:55:17 current FDs rlimit set to 1048576, wanted limit is 8500. Nothing to do here.
2019/03/12 11:55:17 using credential file for authentication; email=sample-app-db-client@[project_id].iam.gserviceaccount.com
2019/03/12 11:55:17 Listening on 127.0.0.1:5432 for [project_id]:us-central1:sample-app-ist
2019/03/12 11:55:17 Ready for new connections
Schritt 4-1.5
Erstellen Sie ein Manifest, das den Dienst definiert, damit Sie von der Internetseite aus auf den Pod zugreifen können, den Sie gerade gestartet haben.
[userid]@cloudshell:~ ([project_id])$ vi sample-app_svc.yaml
apiVersion: v1
kind: Service
metadata:
name: sample-app-svc
namespace: default
spec:
selector:
app: sample-app
type:
LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 8080
Schritt 4-1.6
Führen Sie sofort das Manifest aus, das den Service definiert.
[userid]@cloudshell:~ ([project_id])$ kubectl apply -f sample-app_svc.yaml
service "sample-app-svc" created
Schritt 4-1.7
Überprüfen Sie nach einer Weile die EXTERNE-IP von sample-app-svc mit dem folgenden Befehl.
[userid]@cloudshell:~ ([project_id])$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP xxx.xxx.xxx.xxx <none> 443/TCP 3d
sample-app-svc LoadBalancer yyy.yyy.yyy.yyy zzz.zzz.zzz.zzz 80:31004/TCP 3m
Schritt 4-1.8
Starten Sie einen anderen Browser und zeigen Sie die folgende URL mit der EXTERNAL-IP an. Das aktuelle Datum und die aktuelle Uhrzeit sowie der Inhalt der Tabelle werden angezeigt.
http://zzz.zzz.zzz.zzz/sample-app/views/NewFile.jsp
http://zzz.zzz.zzz.zzz/sample-app/servlet/MyServlet
abschließend
Die Referenzen sind unten. Kubernetes Complete Guide-Shinya Aoyama (Autor) Docker / Kubernetes Einführung in die praktische Containerentwicklung --Akinori Yamada (Autor) das ist alles
Recommended Posts