7,540
edits
Changes
→Minishfit repository
</source>
Az openjdk-11 base image-ből indulunk ki, majd belemásoljuk az összes függőséget, rárakjuk classPath-ra az összes bemásolt jar-t, amjd elindítjuk az alkalmazást a '''com.adam.testapp.App''' main osztállyal. A cél, hogy az ebből készült image-et másoljuk fel az opensfhit repository-ba, majd készítsünk belőle egy Kubernetes deploymentet-et service-el együtt.
A Dokcerfile és az abban hivatkozott összes további fájl lehet a host gépen lesz, de mivel a docker-kliens a minishift-en lévő démonhoz csatlakozik, mikor kiadjuk majd a build parancsot, az anyagépenimage a minishfit VM ottani lokális docker repository-ába fog bekerülni.
<br>
===Belépés az openshfit registriy-be===
Ahogy azt már korábban írtuk, át fogjuk irányítani a host gépen futó docker klienst, hogy a minisfhit VM-en futó docker démonhoz kapcsolódjon, így a lokálisan kiadott docker parancsok mind a minishift VM-en futó docker-en fognak végrehajtódni. Irányítsuk át a lokális docker kliensünket a minishfit VM docker démonjára, ugyan úgyEz megegyezik azzal, ahogy ezt a docker swarm esetében is tennénkcsatlakozunk a swarm master node-on futó démonhoz:
<pre>
# minishift docker-env
Ezt le tudjuk ellenőrizni, ha listázzuk vagy a futó konténereket vagy az elérhető image-eketa docker démonon, ahova a docker kliens csatlakozik:
<pre>
# docker image ls
A célunk, hogy a minisfhit VM-en futó docker démon belépjen a minshift saját docker registry-ébe, és oda push-olja a saját lokális registryrepository-ében ban lévő image-et. Ehhez szereznünk kell egy openShift login toke-ent és meg kell szerezzük a registry repository címét.
A '''docker login''' paranccsal léphetünk be a minishift registriy-be. Ha ezt lokálisan kiadjuk, akkor már a minishit VM-en fog futni lefutni így el fogjuk érni a '''172.30.1.1:5000''' címen a repositoryregistry-t (A docker kliens átirányítása nélkül nem érnénk el a lokális gépről ezt a címet). Tehát ezzel Ezzel a minisfhit VM-en futó docker démon csatlakozik a minisfhit repositoryregistry-bahez, tehát nem az anyagépen futó docker démon.
<pre>
# docker login -u developer -p $(oc whoami -t) $(minishift openshift registry)
Login Succeeded
</pre>
Fontos, hogy csak token-el engedi a belépést a az openshfit registry, jelszóval nem.
<br>
===docker build és push===
Az openshfitregistry-be szánt image-nek a neve az alábbi szintaxist kell kövesse:
<registry-host>:<port>/<névtér>/<image-név>:<tag>
Ahhoz hogy push-olni tudjuk az OpenShift registry-be az image-et a "172.30.1.1:5000/" prefixel kell kezdődjön a neve. Innen fogja tudni a docker, hogy melyik registry-be akarjuk push-olni. A második elem a névtér neve, amihez az image tartozni fog. Az image-ek ugyan úgy névterekbe kerülnek mint minden kubernetes objektum.
A '''docker build''' paranccsal építsük meg az image-t. Ezt az image-et is tegyük a '''mynamespace''' névtérebe.
# docker build -t 172.30.1.1:5000/mynamespace/test-app:1.1.0 .
Sending build context to Docker daemon 14.99MB
<br>
Nem maradt más dolgunk, mint hogy a '''docker push''' paranccsal felküldjük az image-t az opensfhit repositoryregistry-babe. A nevéből fogja tudni a '''docker push''' hogy melyik repository-ba kell küldeni és ott melyik névtérbe.
<pre>
# docker push 172.30.1.1:5000/mynamespace/test-app:1.1.0
A minishift registry-ben úgynevezett '''imageScream'''-ek vannak. A frissen push-olt '''test-api''' image-hez is létrejött egy imageScream. Az oc paranccsal listázhatjuk a imageScream-eket:
<pre>
# oc get is -n mynamespace
===Teszt alkalmazás futtatása===
Az egyszerűség kedvéért a '''kubectl run''' paranccsal fogjuk futtatni az alkalmazást. Ha nem adjuk meg a -it kapcsolót, akkor létre fog hozzá hozni egy deployment-et és egy replicaSet-et is, nem csak a pod-ot fogja elindítani.
<pre>
# kubectl run test-app --image=172.30.1.1:5000/mynamespace/test-app:1.1.0 --replicas=1 --port=8080 -n mynamespace
Ellenőrizzük, hogy létrejött e a test-app nevű deployment.
<pre>
# kubectl get deployment -n mynamespace
test-app 1 1 1 1 2m
</pre>
Nézzük meg a deployment definícióját (csak a releváns részeket tüntetem fel):
# kubectl get deployment test-app -n mynamespace -o yaml
<source lang="C++">
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
run: test-app
name: test-app
namespace: mynamespace
spec:
replicas: 1
selector:
matchLabels:
run: test-app
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
run: test-app
spec:
containers:
- image: 172.30.1.1:5000/mynamespace/test-app:1.1.0
imagePullPolicy: IfNotPresent
name: test-app
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
</source>
<br>
A '''kubectl run''' parancshoz hasonlóan a '''kubectl expose''' paranccsal instant módon készíthetünk service-t a deployment-hez. A deployment-ben megadott portot (8080) fogja kinyitni a pod-ok felé:
<pre>
# kubectl expose deployment test-app --type=LoadBalancer --name=test-app-service -n mynamespace
</pre>
<br>Ellenőrizzük, hogy létrejött e a service. Láthatjuk, hogy a '''30534''' porton érhető el kívülről a service.
<pre>
# kubectl get svc -n mynamespace
</pre>
<br>Ha a minishift VM publikus címét beírjuk a fenti port számmal, akkor meg kell tudjuk szólítani az alkalmazásunkat: <br>
http://192.168.42.185:30534/test/slowresponse/2000
:[[File:ClipCapIt-190725-235129.PNG]]
