Az 1. kubernetes leckében telepítettünk egy virtuális gépet (VM), abba egy microk8s-t, amire pedig egy dokuwiki weboldalt. A dokuwiki-deployment.yml öt különböző erőforrást tartalmazott. Lehet, hogy valakinek ez zavaró, ezért a mai leckében a zabbix szerver telepítést sok kis yaml fáj segítségével fogom bemutatni.
Egy kis segítség: ha a yaml fájlokat a virtuális szerver /vagrant mappájába hozzátok létre, akkor a VM törlése után is megmaradnak. Így később is fel tudjátok használni.
A zabbix szerver egy alkalmazás, de mit sem ér a webes felülete nélkül, sőt, adatbázis szerver nélkül sem fog működni. Így máris három podnál tartunk. Két lehetőség van:
- külső, már létező adatbázis szerveren hozunk létre a zabbix számára egy adatbázist
- vagy dedikálunk egy adatbázis szervert a zabbixnak a kubernetes alatt
Mi a 2. változatot fogjuk használni.
1. lépés: a MariaDB telepítése
Hozzunk létre egy „1.configmap.yml” nevű fájlt az alábbi tartalommal:
apiVersion: v1
kind: ConfigMap
metadata:
name: zabbix
namespace: default
labels:
app1: zabbix-server
app2: zabbix-web
app3: mariadb
type: monitoring
data:
# közös változók
DB_SERVER_HOST: mariadb
DB_SERVER_PORT: "3306"
MYSQL_DATABASE: zabbix
MYSQL_USER: zabbix
MYSQL_PASSWORD: zabbixtitkosjelszo
ZBX_SERVER_HOST: zabbix-server
ZBX_SERVER_PORT: "10051"
# server
ZBX_STARTPINGERS: "3"
ZBX_LISTENPORT: "10051"
# web
ZBX_SERVER_NAME: microk8s.vagrant
PHP_TZ: Europe/Budapest
# mariadb
MYSQL_ROOT_PASSWORD: titokEbben benne van mindhárom alkalmazás által használt összes változó. Kevesebb nem nagyon lehet, szükség esetén több igen.
Hozzunk létre egy „2.pvc.yml” fájlt az alábbi tartalommal:
apiVersion: v1
kind: PersistentVolume
metadata:
name: mariadb-pv
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/data/pvc/mariadb"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mariadb-pvc
namespace: default
labels:
app: mariadb
type: local-storage
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5GiEz már ismerős lehet az előző cikkből, csak a mappa neve változott.
Jöhet a „3.mariadb-deploy.yml” fájlt az alábbi tartalommal:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mariadb
namespace: default
labels:
app: mariadb
type: database
storage: local
spec:
replicas: 1
selector:
matchLabels:
app: mariadb
strategy:
type: Recreate
template:
metadata:
labels:
app: mariadb
type: database
storage: local
spec:
containers:
- name: mariadb
image: mariadb:10.6
envFrom:
- configMapRef:
name: zabbix
volumeMounts:
- mountPath: /var/lib/mysql
name: mariadbdata
volumes:
- name: mariadbdata
persistentVolumeClaim:
claimName: mariadb-pvc
restartPolicy: AlwaysVégezetül hozzuk létre a „4.mariadb-service.yml” fájlt az alábbi tartalommal:
apiVersion: v1
kind: Service
metadata:
name: mariadb
namespace: default
labels:
app: mariadb
type: database
spec:
clusterIP: None
ports:
- name: mysql
port: 3306
protocol: TCP
selector:
app: mariadbA MariaDB működéséhez elég az első három fájl, de a zabbix a 4. nélkül nem fogja megtalálni, így mind a négyet töltsük be (vesszővel elválasztva, szóközök nélkül többet is be lehet tölteni):
kubectl apply -f 1.configmap.yml,2.pvc.yml,3.mariadb-deploy.yml,4.mariadb-service.yml
Ellenőrizzük le az eddigieket:
Létrejöttek-e az adatbázis fájlok: „ls -l /data/pvc/mariadb/„
Ezzel két legyet is lecsaptunk, ugyanis ha a Persistent Volume és a Persistent Volume Claims nem jön létre, akkor a MariaDB sem tuja létrehozni a fájljait.
A biztonság kedvéért nézzük meg a MariaDB logjait. Nyissuk meg a dashboardot a „Pods” menüpontnál, kattintsunk a mariadb kezdetű linkre, majd a megnyíló adatlapon a jobb felső sarokban találunk egy 3,5 soros ikont, ha az egeret fölé visszük, mutatni fogja, hogy „View logs„. Nálam ez látszik:
Nincs hibaüzenet, minden rendben van. Szándékosan úgy írtam meg a „4.mariadb-service.yml” fájlt, hogy az adatbázist csak bentről lehet elérni, kintről nem. Mivel ez dedikáltan a zabbixé lesz, teljesen jó így.
2. lépés: a Zabbix telepítése
Hozzuk létre az „5.zabbix-services.yml” nevű fájlt az alábbi tartalommal:
apiVersion: v1
kind: Service
metadata:
name: zabbix-web
namespace: default
labels:
app: zabbix-web
type: frontend
spec:
type: NodePort
ports:
- targetPort: 8080
port: 8080
nodePort: 30280
name: http
selector:
app: zabbix-web
---
apiVersion: v1
kind: Service
metadata:
name: zabbix-server
namespace: default
labels:
app: zabbix-server
type: monitoring
spec:
type: NodePort
ports:
- targetPort: 10051
port: 10051
nodePort: 30051
name: server
selector:
app: zabbix-serverVégül jöjjön az utolsó fájl, „6.zabbix-deploy.yml” néven az alábbi tartalommal:
apiVersion: apps/v1
kind: Deployment
metadata:
name: zabbix-server
namespace: default
labels:
app: zabbix-server
type: server
storage: stateless
db: internal
spec:
replicas: 1
selector:
matchLabels:
app: zabbix-server
strategy:
type: Recreate
template:
metadata:
labels:
app: zabbix-server
type: server
storage: stateless
db: internal
spec:
containers:
- name: zabbix-server-pod
image: zabbix/zabbix-server-mysql:alpine-6.4-latest
envFrom:
- configMapRef:
name: zabbix
restartPolicy: Always
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: zabbix-web
namespace: default
labels:
app: zabbix-web
type: frontend
storage: stateless
db: internal
spec:
replicas: 1
selector:
matchLabels:
app: zabbix-web
strategy:
type: Recreate
template:
metadata:
labels:
app: zabbix-web
type: frontend
storage: stateless
db: internal
spec:
containers:
- name: zabbix-web-pod
image: zabbix/zabbix-web-apache-mysql:alpine-6.4-latest
envFrom:
- configMapRef:
name: zabbix
restartPolicy: AlwaysEzeket is töltsük be:
kubectl apply -f 5.zabbix-services.yml,6.zabbix-deploy.yml
Ezt is ellenőrizzük:
kubectl get pod
vagy a dashboardon a Pods menüpont alatt:
Nézzük meg a zabbix szerver logjait (részlet):
Nézzük meg a zabbix-web logjait is:
Minden rendben van, nincs más hátra, mint megnyitni a zabbix weboldalát:
A default username/password a szokásos „Admin” és „zabbix”.
És kész is vagyunk! A zabbixról itt nem írok többet, korábban már megtettem. Ez most a kubernetes alatti telepítéséről szólt. Illetve egy dolgot még meg kell említenem vele kapcsolatban, a zabbix szerver 30051-es tcp porton figyel, kintről így tudnak hozzá az agentek , proxyk csatlakozni:
Van még valami?
A korábbi cikkben meséltem a replicaset-ről. Ugyanúgy érvényes a zabbixra vagy a mariadb-re, ha változtatunk a deploy erőforráson, automatikusan létrejön 1-1 új replicaset.
A törlés is ugyanúgy történik, csak le kell cserélni az „apply„-t „delete„-re. Egyszerre így törölhetünk mindent:
kubectl delete -f 1.configmap.yml,2.pvc.yml,3.mariadb-deploy.yml,4.mariadb-service.yml,5.zabbix-services.yml,6.zabbix-deploy.yml
Ha szeretnél bejelentkezni az adatbázisba, a mariadb podból (vagy a zabbix-web podból) megteheted. Parancssorból így tudsz rá belépni, és onnan az adatbázisba lépni:
Előbb lekérdezzük a podok aktuális neveit: „kubectl get pod„:
Most, hogy megvan a mariadb pod teljes neve, be is léphetünk az adatbázisba:
kubectl exec -it mariadb-8b8874cb6-ds784 -- mysql -h mariadb -u root -ptitok
Természetesen a dashboardból is be tudunk lépni az adatbázisba. Keressétek meg a Podok között a mariadb-t (nem meglepő módon ugyanaz a neve, mint a parancssorban látottnak), és a jobb felső sarokban lesz egy ikon, „Exec into pod„.
Végszó
Én jobban szeretem, ha az itt látott 6 yaml fájl egyben van, persze ez már csak ízlés kérdése. Ha összemásoljátok egy fájlba, a sorrend teljesen mindegy, csak el kell választani őket egymástól 3 kötőjellel (---).