mysql 8 konfiguralasa es inditasa non-root user alatt

Linux-haladó

Sziasztok,

hogy tudnek non-root userkent mysql 8-t telepiteni Kubernetes alatt?

Asszem, letezik a docker image-ben default mysql user (uid=999) es group (gid=999).

Nem latok benne azonban systemctl-t demon inditasra. Gondolom, ha lenne is telepitve, root-kent amugy se koser kubernetes

alatt inditani.

Hogyan lehet igy korrekt modon leallitani, restartolni es inditani a mysql adatbazist? Linux alatt ez teljesen maskepp mukodik...

Hogyan tudnam megvaltoztatni a default telepitesi utat ? (mondjuk egy altalam letrehozott) pvc-be

Ezek lennenek bevezeteskent ... tobbit talan kesobb.

Koszonet a valaszokert.

Ardi

  • 785 megtekintés

( denton | 2024. 01. 09., k – 17:00 )

Lehet csak én nem értem 100%-osan. Szeretnéd a mysql docker konténer alatt ki-be kapcsolgatni a mysql szoftvert?

Leállítani a konténer leállításával tudod, újraindítani annak a restartolásával.

 

Kubernetes pont arra való, hogy állandóan életben tartsa a konténereket és felügyelje őket. Egyébként ott is van restart policy, hogy ne indítsa újra ha leállítod. (bár még nem próbáltam, nekem mindig az kellett, hogy újrainduljon)

perzisztens tárolásra megmondja a mysql, hogy hova kell felmountolnod.

https://hub.docker.com/_/mysql

The -v /my/own/datadir:/var/lib/mysql part of the command mounts the /my/own/datadir directory from the underlying host system as /var/lib/mysql inside the container, where MySQL by default will write its data files.

Azt érdemes tudni, hogy felhős megoldásoknál ha samba mount van, ott nem fog működni. Replika docker/kubernetes szinten szintén nem megy egy mountra, csak master-slave módiban.

 

Mi az amit itt, így akarsz megoldani?

Koszi a helyrerako valaszokat - ami docker alatti kontener stop, start parancsot illeti, ezt ismerem.

En inkabb kubernetes fele orientalodnek - ott szeretnek kezdetnek egy sima mysql 8-t feltenni es iranyitani (tudni a statusat es esetleg leallitani es ujra inditani non-root userkent).

Azt a megoldast is lattam, hogy siman le kell loni (delete) a podot kubernetes alatt.

De nem voltam benne biztos, nem letezik-e elegansabb megoldas. Az a restart policy jo otlet - rakeresek a letezo parameterekre.

A pvc mountolasat en yaml fajlban szoktam beirni - gondolom, a fenti -v megoldas a jo oreg docker alatti csatolas.

Ami a replikat illeti, arra meg kesobb visszaternek.

Ardi

Tényleg az a gond, hogy nem érted még ezt a témát ezek szerint.

 

Nincs olyan, hogy Docker VAGY Kubernetes. Docker ÉS Kubernetes van.

Kubernetes alatt docker konténereket futtatsz, csak épp nem a klasszikus docker paranccsal és nem docker-composer.yaml -al, hanem a kubernetes -en belül. Mögötte ugyanazok a dolgok futnak így is, kibővítve a lehetőségeket.

Amikor a kubernetes elindít egy POD-ot, akkor abban több konténer futhat egyszerre, a konténereken belül ugyanaz a parancs fut le ami docker start -ra is indulna, hacsak nem definiálod felül.

A Kubernetes arra jó, hogy le tudj írni előre több lehetőséget, eshetőséget amire figyelni kell és ezeket automatizáltan figyelje, futtassa, kezelje.

 

Egy kubernetes yaml konfigot jórészt le tudsz írni docker-compose-yaml -al is. Tehát amikor docker -es -v -ről beszélünk, annak megvan a kubernetes megfelelője is, csak épp a felcsatolt tech más. Docker alatt jellemzően mezei local volume-t és bind mountot használunk, kubernetes alatt szélesebb a skála, felhős szintű disk-ek mountolása, samba, nfs, stb...

 

Nincs elegánsabb megoldás. Nem véletlenül kérdeztem, hogy mit akarsz csinálni, mi a pontos cél, mivel az eddigi infók alapján azt mondom, hogy rossz az irányod, ilyet jellemzően nem szoktunk Kubernetes alatt csinálni.

Nincs olyan, hogy Docker VAGY Kubernetes. Docker ÉS Kubernetes van.

Igazából a k8s mindenféle container runtimeot támogat, és igazából az 1.24-ben kivették a dockershimet, szóval nem fut dockerdn keresztül, hanem vagy direketben tolja a containerd-t docker nélkül, vagy az ocr-i-t használja, amit direkt alá csináltak (van egy cri-dockerd, amit a shim kivezetése után csináltak, de ez nem az upstream része)

Igazából a k8s mindenféle container runtimeot támogat

Hát ez azért nem igaz. 1.29-től kezdve csak CRI-kompatibilis runtime van. Azért van élet a CRI-n túl is ám.

 

ocr-i-t használja, amit direkt alá csináltak

Nem a CRI-O-ra gondolsz?

Hát ez azért nem igaz. 1.29-től kezdve csak CRI-kompatibilis runtime van. Azért van élet a CRI-n túl is ám.

Oh, persze. Kérlek kontextusában értelmezd: ahhoz képest, hogy "k8s csak dockerrel van", ahhoz képest csak a doksi 4 félét linkel, erre reagáltam, szóval nem azt akartam mondani, hogy a világ összes kontérizációjával megy :)

Nem a CRI-O-ra gondolsz?

De, csak össze betűket a keverem. :) 

Precizitását tekintve igazad van, gyakorlatilag ez az eredeti kérdezőnek nem segít.

Úgy talán mindenkinek tetsző a meghatározás, hogy: "kubernetes nincs konténerizáció nélkül"

Tehát először a konténerizációt kéne megérteni, utána jön a kubernetes (ez nagyon sokszor nem így van, látszik is, baj is)

zászló, zászló, szív

Annyiban talán, hogy nem feltétlen kell a docker, ami imho a k8s-el együtt csak megkeveri a kezdő fejét, hogy most akkor honnan látom a mit, és akkor most mit kell docker commanddal, és mit nem, ha nincs belekeverve, akkor ezzel nem szenved, ha egyszerre csinálja. Szóval az kicsit félrevezető info.

De igen, a konténerizációt kell kell fogni, ebben egyetértünk, látszik, hogy itt az alapvető paradigmaváltás még nem ért földet a kérdezőnél.

Értem, de ettől még itt vagyunk, hogy az op odament :)

És igen, valószínűleg segít a dolgok megértésében, ha használtál már mezítlábas dockert (bár nem hiszem, hogy megugorhatatlan volna nélküle), de ami a te fejedben van így kb, hogy értsd meg a dockert, aztán nézd meg, ehhez képest mit ad hozzá a k8s, és mi van másképp, az nagyon nem ugyanaz, mintha valamiért egy valójában k8sbe keveredik neki bele az, hogy van itt egy docker runtime.

... de hát amikor azt se tudja mi az hogy konténer, akkor honnan tudna a bármilyen további fogalmakról.
Mysql-on-k8s következő lépés, hogy jah, statefulSet, nagyon jó, emeljük meg az instance countot kettőre, kész is a high-availability adatbázis.
Change my mind.

zászló, zászló, szív

Nagyjából meg lehet érteni, persze. Amikor minden jó és szép akkor tényleg minden egyszerű.
Nekem az a bajom (a kubernetessel) hogy "túl sok minden van" és egyszerre ezeknek mindnek stimmelnie kell ahhoz, hogy "működjön".
Amíg nem ismered addig baromi nehéz debugolni ha éppen valami hanyattesik.
Amíg nem ismered fogalmad nincs hogy melyik tünet éppen melyik réteget jelenti. Az image szar? A deployment? A service esett el? Az ingress? Vagy valami teljesen más (dns, dhcp, whatever?)

És szerintem a kubernetes networking pl. tipikusan irtó szarul van dokumentálva.
Nem olyan régen raktam össze from scratch egy bare-metal kubernetest, hát nagyon jó hogy van a chatgpt (meg a medium.com).

Ehhez képest a docker (v docker compose) egy faék - de pont jó.
A docker stack (service) már se nem olyan egyszerű, se nem olyan jól debugolható, se nem olyan megbízható. 
Akkor már inkább kubernetes. 

zászló, zászló, szív

Azért mert mysql docker image-ről van szó, fent mysql image-ről. A dockert ismeri valamennyire, azt is használja, annak a működését kell értenie ahhoz, hogy értse, mi történik a kubernetesen belül. Főleg, hogy a leírása alapján inkább sima docker konténerekre van szükséges és nem kubernetesre. Bár még mindig nem árulta el, hogy mi is a célja.

Oh, valóban volt ott egy docker image. Mondjuk azt, hogy azt már ismeri, őszintén szólva kétlem :) És ha k8s az elvárás, akkor simán lehet, hogy nem is kell. (Mmint összerakni úgy tippre bonyolultabb, mintha a "gyárit" használnád. Gondolom managed kubernetesben se dockert tolnak már, ha olyat nézne.)

Az szerintem, hogy sima konténerekre vagy k8s-re van-e szüksége, az egyáltalán nem derült ki, mert fingunk sincs, valójában mit akar.

Az igazából mind1, hogy a kubernetes hogy oldja meg a háttérben, a lényeg, hogy docker hub-ról lehúzott vagy az alapján összerakott image-kat használ az ember, én is.

 

Nekem általában az a célom, hogy egy adott service működjön docker-compose alatt is fejlesztőnél és managed kubernetes alatt is. Ennek a docker image a közös pontja.

Az igazából mind1, hogy a kubernetes hogy oldja meg a háttérben, a lényeg, hogy docker hub-ról lehúzott vagy az alapján összerakott image-kat használ az ember, én is.

 Na jó, de azt azért érzed ugye, hogy a dockerhubról lehúzott, vagy docker builddel készített imaget használni, az nagyon nem egyelő azzal, hogy "Docker ÉS Kubernetes van.". Runtime teljesen irreleváns, hogy docker builddel készült az az image, vagy valami mással.

Tisztelettel, te nem érted :) Mondtál valamit, ami miatt a kérdező jó eséllyel teljesen feleslegesen elindul az építsünk docker engine container runttimemal k8s-t irányba, miközben erre semmi szüksége, mert azt mondtad neki, hogy a kettő csak együtt van, holott ez nem igaz, és ha tényleg k8s kell neki, akkor felesleges komplexitást adsz alá.

És egy kicsit úgy tűnik, mintha te nem nagyon értenéd, hogy az image előállítás mikéntjének nem sok köze van a container runtimehoz, mert egy másik dolog.

(Azt meg már ne is feszegessük, hogy imaget előállítani se csak dockerrel lehet, sőt néha napján még olyan is történik, hogy a nem docker builddel épített imaget futtatunk dockerben :) )

( golgota | 2024. 01. 09., k – 18:47 )

Szerkesztve: 2024. 01. 09., k – 18:49

A legfontosabb talan az lenne, ha megertened hogyan mukodnek a kontenerek. Aztan utanaolvasnal az egesz kubernetes dolgonak. Nem bantasbol mondom, de a kerdesed alapjan a legalapvetobb dolgokkal sem vagy tisztaban. "Telepiteni mysql-t kontenerben?????" <- ez most komoly???

A legelso problema, hogy azt hiszed a kontenerben tobb process fut es hogy a hatterben service-kent vagy daemon-kent). 

Ajanlott olvasmanyok: cgroups, namespaces, layered FS, containers - processes, volumes, shared resources...aztan ehhez mar johet majd a kubernetes quick start guide

De ha nem akarod erteni csak brute-force-al nyomni akkor itt van ez: https://kubernetes.io/docs/tasks/run-application/run-single-instance-st…

Valójában direkt nem tértem ki erre a kommentemben mert nem akartam megkavarni, de van mód a több processre természetesen, ha pl egy ubuntu:22.04 -es imaget felhasználva telepítesz egyet. Tehát fel lehet telepíteni benne egy full LAMP-ot vagy amit akarunk és lesz benne /etc/init.d indítás meg ami kell. Kezdőként így csináltam annó még. Aztán persze rájöttem, hogy az official konyhakész image-k a nyerőek amik egy service-re vannak kihegyezve. 

Van amikor működhet a fenti megoldás, de 99%-ban valóban maradni kell az 1 konténer 1 service elvnél.

Futatthatsz persze tobb processt is es hasznalhatsz benne valamilyen process managert is mint systemd vagy supervisord, de akkor rohadtul nem azt csinalod amire a kontener van.

Pont az a lenyege a kontenernek, hogy egyetlen process-t izolalsz benne (namespaces) es annak adod csak az eroforrasokat (cgroups). Lehet persze mindenfelet taknyolni, hiszen a namespace-k shared-ek lesznek, igy mindenki mindent eler localhoston meg shared disk-en (brrrr), de rohadtul nem erre valo.

A konyhakesz imagek sem service-re vannak kihegyezve hanem egyetlen process-re. Mondjuk nekem mas a servcie es mas egy talpas process. 

A kedvencem az, amikor a kontenerbe beleraknak egy ssh-t hogy tavolrol bele tudjanak lepni. Bravo :D

Szoval ha te kezdokent ezt csinaltad azzal semmi baj nincs, de ne vigyuk mar erre azokat akik most kezdik. Ne tanitsunk nekik anti-patterneket.

Nem tanítok neki semmit ezzel kapcs. Elhalgatni nem kell, hogy ilyet is lehet. Van amikor kifejezetten hasznos, ha pl ki akarsz próbálni valamit egy eldobható konténerben. Tudod Harry Potterben is tanultak a sötét mágiáról.

A többivel kapcs nem látom értelmét itt mélyen vitázni a technológiai dolgokról, lévén, hogy nem ez volt a téma, nem erről szólt a kérdés és csak elflameljük vele a post-ot.

Lehet, persze. Meg hasznalhatjuk shared volume-kent, meg minden istennyilanak is. Csak eppen anti-pattern az egesz. Szoktassuk hozza azt aki most kezd vele foglalkozni, hogy a helyes utat jarja es ne egy virtualis gepkent gondoljon a kontenerekre, hanem egy process "jail"-kent.

Meg tegyuk hozza, hogy a containerekben foreground-ban kell futnia a processeknek. Szoval futhat tobb, de az egyik lesz az "init" a tobbi meg nem. Ha meghal benne az init, meghal a tobbi is, mivel az init-tel leall a kontener. Hameg nem az init all le hanem mas, akkor meg fogalmunk se lesz rola. Persze lehet a supervisord az init es akkor faszasan VM-kent hasznalhatjuk a kontenert.

De komolyan ezt akarjuk???

Nem ilyen egyszerű ez, hogy 1 konténer = 1 process jail, mert egész egyszerűen ez nem igaz.

Főleg, hogy K8s alatt 1 podban lévő konténerek ugyanazt az IPC és network névteret használják megosztva, azaz bizonyos értelemben ugyanabban a jailben van több processz.

Az, hogy a konténerben lévő processzek melyik kernel cgroup, melyik IPC névtér és melyik network névtér alá tartoznak, azt a konténer runtime/orchestrator határozza meg. A k8s/cri csinálja valahogy, a Docker máshogy, az lxd megint máshogy.

Meg kell érteni, hogy mi a konténer igazából, és sajnos meg kell érteni a mélyebb cgroups/namespaces dolgokat, mert nagyon nem intuitív az, hogy teljesen eltérő viselkedésekre rámondjuk, hogy konténer ez is, konténer az is, aztán nézünk, hogy egyszer valami megy, máskor meg nem.

Persze hogy nem egyszeru. Es igen van, hogy tobb process fut egy pod-ban. De azok mind kulon ontenerek. Nem egy contenerben fut tobb process. Persze azt is meg lehet csinalni, de jobb ha nem. Szoval a pod-ban fut tobb container, de azoban egyesevel egy process. De altalaban igaz, hogy a pod-ban is probaljuk minimalizalni a parhuzamosan futo cotainereket. Mehet az init container, de miutan lefut alljon le. Persze van amikor musazj a sidecar, mert mondjuk a proxy-t ott akarod futtatni, vagy az authentikacios reteget, vagy a key-valu store klienset, stb stb. De azert erre is vannak megoldasok, hogy inkabb ne sidecar-kent futtasd.

A docker ugy csinalta, hogy egy container egy namespace. A Pod ugy csinalja, hogy egy pod az egy namespace es mehet benne akarhany container. Sot az en sajat gepemen container nelkul is hasznalok namespaceket, mivel anem a kontenerekre lett kitalalva, csak jo arra is. Ezert is irtam a kerdezonek, hogy bezony olvasson utana mindennek.

De egyetertunk. Bezony meg kell erteni hogy mukodnek a dolgok. Azert ide nem tudunk mindenre is peldat hozni a sok szaz oldalas doksikbol.

De akkor is allitom, hogy antipatternt ne tanitsunk senkinek. Ne legyen LAMP kontener, mikor lehet 4 kontener ugyanabban a network naemspace-ben, vagy akar masikban is, mivel tudnak kommunkalni. Plane kubernetesen belul nem kell ezen nagyon varazsolni.

Koszi golgota a sorokat. Nem bantodtam meg - szoktam en mar kemenyebb kioktatast is kapni. :-))

A celom ugysem azt, hogy megbantodjak, hanem hogy megtanuljam azoktol, akiknek ez mar a kisujjaban van...

Szoval az altalad emlitett linkhez hasonloan van egy mysql 8 deploymentem, de rajottem, hogy ha shell alatt bejelentkezem, root-ot kapok, ami ugye security meggondolasokbol nem ajanlott. vhogy meg kene oldanom a docker image-ben, hogy mysql user-kent induljon az egesz (es a megfelelo konyvtarakhoz a mysql user megfelelo acl-lel hozzaferjenek) es a logokban lassam, hogy elindult.

Ardi

a mysql nem rootkent valo futtatasahoz semmi koze se a kontenernek se a kobernetesnek. A mysql ini-ben meg kell mondanod, hogy a process milyen userrel fusson. 

[mysqld]
user=user_name

Az mondjuk fontos, hogy a /var/lib/mysql es a /var/run/mysqld konyvtar tulajdonosa is az legyen meg a container is az o neveben fusson.

Nem neztem a mysql official image-et, hogy mikent fut, de ha az tud mas UID-dal futni, akkor csak szedd be a mysql.ini-t egy configmapbol es ott ird be a magfelelo usernevet. Aztan ennek a UID-javal futtasd a kontenert. Aztan mar csak abban kell remenykedni, hogy az official mysql docker image ezt kezeli. Ha nem, akkor csinalj egy sajatot, amiben van egy plusz chwon, vagy egy initcontainer-ben csinald meg a chown uid:uid /var/lib/mysql-t.

Na megneztem a docker image doskijat. Ebben a szekcioban "Running as an arbitrary user" azt irjak csak siman allitsd be a UID-t es kesz, nem kell semmi varazslat. A PVC-n meg majd olyan jogokkal jonnek lere az allomanyok amivel ugye fut a mysql, szoval az sem lesz gond. Kieve ha ujra akarod csatolni egy masikhoz ahol mas a UID.

Amugy ahogy latom a Docker container lehet root-kent indul, de a mysql a "mysql" usert hasznalja (https://github.com/docker-library/mysql/blob/c0c45e2e135f8f60b2d02350d0… vagy https://github.com/docker-library/mysql/blob/c0c45e2e135f8f60b2d02350d0…) ami valami veletlenszeru szam lesz. Aztan chown-ol: https://github.com/docker-library/mysql/blob/c0c45e2e135f8f60b2d02350d0…

Na ezzel van a gond, mert ha a containert egy masik UID-dal inditod, akkor a PVC-t azzal mountolja fel, de abban akarja letrehozni az adatbazist a mysql user UID-javal, amit lehet majd nem tud megtenni.

A mzsql root userenek az egeszhez semmi koze ugye, az egy masik user a mysql-en belul.

Szoval hivatalosan mysql-el indul nem root-kent, csak a pod indul root-kent, de siman indithato nem root-kent is. Probald ki

letrehozva a pvc-t majd mysql:8.0.31 imaget hasznalva letrejott a deployment is.

a yaml-ba beirtam, hogy:

containers:
     - name: mysql4cont
       image: mysql:8.0.31
       args:
         - "--default-authentication-plugin=mysql_native_password"
       env:
       - name: MYSQL_ROOT_PASSWORD
         value: <jelszo>
       ports:
       - containerPort: 3306
       volumeMounts:
       - name: mysql-pers-stor
         mountPath: /var/lib/mysql
     securityContext:
        fsGroup: 999
        runAsGroup: 999
        runAsUser: 999
     volumes:
     - name: mysql-pers-stor
       persistentVolumeClaim:
         claimName: mysql-pvc4

 

kul get pod
NAME                                 READY   STATUS    RESTARTS   AGE
mysql-deployment4-6984dc57d9-hcwn5   1/1     Running   0          27m

 

$ kul exec -it  mysql-deployment4-6984dc57d9-hcwn5 -- /bin/bash
bash-4.4$ id
uid=999(mysql) gid=999(mysql) groups=999(mysql)
bash-4.4$

Nos, ez mar jobb, hogy nem root-ot latok itt ...:-)

#Belepes root-kent mukodik:

bash-4.4$ /usr/bin/mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.31 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.00 sec)

mysql>

mysql> exit
Bye
bash-4.4$

 

exit

# kul logs -f mysql-deployment4-6984dc57d9-hcwn5
2024-01-11 09:32:54+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.31-1.el8 started.
2024-01-11 09:32:54+00:00 [Note] [Entrypoint]: Initializing database files
2024-01-11T09:32:54.267809Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
2024-01-11T09:32:54.267921Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authentication_policy instead.
2024-01-11T09:32:54.267951Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.31) initializing of server in progress as process 42
2024-01-11T09:32:54.279099Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-01-11T09:32:54.912413Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-01-11T09:32:57.335033Z 6 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
2024-01-11 09:33:01+00:00 [Note] [Entrypoint]: Database files initialized
2024-01-11 09:33:01+00:00 [Note] [Entrypoint]: Starting temporary server
2024-01-11T09:33:02.184580Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
2024-01-11T09:33:02.187221Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authenticatio
n_policy instead.
2024-01-11T09:33:02.187269Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.31) starting as process 93
2024-01-11T09:33:02.215544Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-01-11T09:33:02.423401Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-01-11T09:33:02.767790Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-01-11T09:33:02.767848Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-01-11T09:33:02.770423Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Co
nsider choosing a different directory.
2024-01-11T09:33:02.795262Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: /var/run/mysqld/mysqlx.sock
2024-01-11T09:33:02.795400Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.31'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server - GPL.
2024-01-11 09:33:02+00:00 [Note] [Entrypoint]: Temporary server started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leapseconds' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/tzdata.zi' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.

2024-01-11 09:33:05+00:00 [Note] [Entrypoint]: Stopping temporary server
2024-01-11T09:33:05.375520Z 10 [System] [MY-013172] [Server] Received SHUTDOWN from user root. Shutting down mysqld (Version: 8.0.31).
2024-01-11T09:33:06.624422Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.31)  MySQL Community Server - GPL.
2024-01-11 09:33:07+00:00 [Note] [Entrypoint]: Temporary server stopped

2024-01-11 09:33:07+00:00 [Note] [Entrypoint]: MySQL init process done. Ready for start up.

2024-01-11T09:33:07.723650Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
2024-01-11T09:33:07.726162Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authentication_policy instead.
2024-01-11T09:33:07.726211Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.31) starting as process 1
2024-01-11T09:33:07.734903Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-01-11T09:33:07.925597Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-01-11T09:33:08.272792Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-01-11T09:33:08.272913Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-01-11T09:33:08.275364Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/ru/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2024-01-11T09:33:08.299055Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2024-01-11T09:33:08.299387Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.31'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL

 

Hol nezhetem meg root vagy mysql userkent, hogy a mysql mukodik? Csak a logokban?

bash-4.4$ id
uid=999(mysql) gid=999(mysql) groups=999(mysql)
bash-4.4$ /usr/bin/mysqladmin status
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'mysql'@'localhost' (using password: NO)'
bash-4.4$

Amit latok root-kent:

mysql> show status like '%uptime%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Uptime                    | 2738  |
| Uptime_since_flush_status | 2738  |
+---------------------------+-------+
2 rows in set (0.00 sec)

UPDATE 2024-jan-11 11:38:

mysql> status;
--------------
/usr/bin/mysql  Ver 8.0.31 for Linux on x86_64 (MySQL Community Server - GPL)

Connection id:          15
Current database:
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         8.0.31 MySQL Community Server - GPL
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /var/run/mysqld/mysqld.sock
Binary data as:         Hexadecimal
Uptime:                 1 hour 3 min 54 sec

Threads: 2  Questions: 110  Slow queries: 0  Opens: 245  Flush tables: 3  Open tables: 164  Queries per second avg: 0.028
--------------

mysql>

 

Koszonet a hozzaszolasokert.

Ard

Amit kerdezel annak mar koze nincs a kontenerekhez vagy a kuberneteshez. 

A fenti hibat azert kapod, mert a mysql-en belul nincs olyan user hogy mysql. A MySQL nem hasznalja az operacios rendszer felhasznaloit a PAM-on keresztul, vagy direktben (az enterprise verzioban lehetseges). 

Ne keverd a system usereket a mysql userekkel. Nem azonosak. A mysql csak olyan hulye, hogy az adott system user usernevet hasznalva rpobal meg a mysql userkent belepni. 

Szoval ha a mysql system userkent akarod futtatni a parancsot, akkor kell egy mysql user a mysql-en belul is olyan jogokkal amiket szeretnel neki adni (grant-olni).

A mysql mukodik a kubernetesben, ha fut es nem chrash-el el. Ha running state-ben van akkor megy. Hogy running state-ben van e azt meg a livenes es readiness probe-ok dontik el. Pl, hogy nyitva van e a port, lehet e vele kommunikalni, stb stb. Mivel a liveness es readiness is a namespace-ben fut, igy hasznalhatoak azok a parancsok, amik benne vannak a kontainerben. Szoval rediness-nek en mondjuk beallitanek egy "mysql -h 127.0.0.1 -e 'select 1'"-et a lvenessnek meg megneznem hogy nyitva van e a portja.

Had ne google-zzam ki neked :D

( trying | 2024. 01. 09., k – 23:44 )

Szerkesztve: 2024. 01. 10., sze – 00:03

Nem vagyok tapasztalt Kubernetes üzemeltető, csak tanultam, az alapján válaszolok.

Nem latok benne azonban systemctl-t demon inditasra.

Nincs benne. Általában egy /entrypoint.sh szkript indítja a konténerben lévő dolgokat a konténer indításakor.

Hogyan lehet igy korrekt modon leallitani, restartolni es inditani a mysql adatbazist? Linux alatt ez teljesen maskepp mukodik...

A konténeren belül nem szokták leállítani, majd újra elindítani az alkalmazást, hanem magát a konténert (podot) szüntetik meg, majd újra létrehozzák.

Szerintem amúgy először a Dockert kéne megtanulni és utána a Kubernetest, mert a kettő egymásra épül.