Dockerfile mysql, fedora

Virtualizáció

Üdv,

Fedora konténerben mivel lehet indítani a mysql-servert?

FROM fedora:latest

RUN dnf install mysql-server -y

ENTRYPOINT ["..."]

A "mysld" operation not permitted üzenetet ad.

  • 811 megtekintés

( slinky v | 2024. 10. 03., cs – 11:59 )

megnézted h a systemd unit mit akar behúzni?

alapvetoen a systemd nem fog elindulni a containeren belul ket okbol:

1. Neki kell lennie a PID1 -nek, de ehhez systemd-vel kell bootolni a rendszert, azaz az /sbin/init kell az entrypointba (kulonben: "System has not been booted with systemd as init system (PID 1)"  meg "Host is down")

2. A fentivel meg mindig nem fog mukodni, mert a systemd-nek szuksege can a sysfs-en levo cgroups-ra, azaz bele kellene mountolni a containerbe. Ha ezt rw-ben teszed mar el is van baszva a hostod, szoval legyen inkabb ro-ban mountolva

3. A fentiekhez persze kell, hogy az egesz hobelebanc privileged modban fusson, ami egy kb tokonszuras security szempontbol

Ha mindezek mellett meg mindig kotod az ebet a karohoz, hat rajta :D

Ha kezzel akarod inditani akkor arra ott a "mysqld" parancs amivel a systemd is inditja. De egy containeren belul kurva sok mindennek ott kell lennie hozza, amit mondjuk az official mysqld image megcsinal neked (csak nezz ra a github-jara, nem szarral gurigaznak)

A fedora image nem tudom milyen, a redhat-ubiba egyébként bele van gyógyítva a systemd. Nem tudom, mennyire jajj, nyilván azért csinálták, hogy a legacyt könnyen lehessen konténerbe tenni. De rémlik, hogy egy darabig a systemdnél is ment a matek, hogy ez azért usecase, lehet, hogy nem kő undor ma már

annyi az egesz, hogy antipattern. A kontenerizacio lenyege hogy izolalva futtassunk egyetlen process-t bezarva a sajat vilagaba (namespaces) adott erofirrasokat engedejezve neki (cgroups) es capability-ket. Egyet. Ha mgedoglik az a jo, nem akarjuk hogy ujrainduljon (bar mar ugy ez is lehetseges)

Mit irtam is. A docker es tarsai "ugyanazt" csinalja, mint a systemd. Kihasit cgroup-ot, namespace-be tesz, es felugyeli a container process-t ha kell. Semmi ertelme egy container-nek amiben 30 darab szerviz fut es ha megdoglenek, akkor majd a systemd mindegyiket ujrainditgatja. Ezzel el is jutottunk a virtualizaciohoz. De ha meg ekkora mennyisegu process-t kell futtatgatni, akkor sem celszeru egyetelen konteiner-be belepakolni mindent, szoval akkor meg ott a dockercompose, swarm, k8s, etc. Hogy megint csak egyetelen process-t futtassunk foreground-ban egyetlen containerkent, de abbol szamosat.

Nem "ko undor"-rol van szo, hanem hogy olyan, mintha autoval akarnal kenyeret megvajazni. Lehet persze :D

Arra reagáltam, hogy nem fog elindulni, mert mint a fedoratól nem messze álló példa pont mutatja, de simán lehet. Akkor is, ha antipattern.

Egyébként köszi, értem én a patternt, és szerintem is kő felesleges egy mysqldt systemdvel indítani, de valóságban azért nem mindig ilyen fekete fehér az élet. Nyilván a redhat se viccből csinálta. Egyrészt az egyetlen processz az azért nem mindig lesz igaz, simán lehet, hogy kell ez-az még mellé, vagy maga az alkalmazás olyan, vagy kell vmi preprocesszing, és ezekre pl dockerben nem nagyon van értelmes megoldás (és régebben még ennyire se volt), nem véletlen van a k8sben a sidecar pl. Márpedig, ha nem egy, akkor azt valamivel managelni kell, akkor kell valami a konténerbe. Van is jószerével olyan, ahol valami runit, vagy supervisord, vagy s6, vagy valami ilyen van belegyógyitva.

Másrészt persze sok a technológia átfedés, de az pl a linux egyik legnagyobb tragédiája, hogy mire lett egy viszonylag használható de-facto default service manager és felügyelő, addigra pont jött a docker, amiben ezt nem lehetett, hanem a mindenki által összetákolt foshalom entrypoint.sh-k lettek (és annyira fosom volt az egész, hogy sokáig a fél világ szórta a zombikat, mert a docker még tisztességes initként se volt hajlandó működni, évekig tartott, mire beemelték a dumb-initet vagy melyiket, az shkban meg fasztak megírni rendesen az emberek.) És hát azért valahol az is van (bár azért mostmár egyre kevésbé), hogy normális systemd unitot jobban elhitte az ember, hogy a fejlesztők tudnak írni, mint normális entrypoint.sh-t (amikből hát azért tényleg horror dolgok sikerültek néha). Ráadásul ahány konténer, annyiképp csinálta máshogy alapvetően ugyanazt a feladatot. Valahol értem, hogy miért akarná valaki a szabvány dolgokkal kezelni ezeket. (És egyébként hamar kiderülne szerintem, ha jobban belegondolnál, hogy ebben a usecaseben a systemdt kell a dockerbe, hanem el kell felejteni a dockert, tanulja meg a systemd a konténereket is kezelni, mert valójában a mindenféle kerneles izolációt és felügyeletet alapvetően már úgy is tudja, mint mondtad)

* A container egy izolalt process, ennyi. Ha tobb process-t is kell futtatni, akkor tobb container-t kell inditani ugyanabban a namespace-ben. Attol, hogy a RedHat csinalt egy syste,d-s container lehetoseget, az meg nem jo

* A sima talpas dockerben az init container (ami egy specialis sidecar) az az entrypoint.sh. Az o feladata, hogy megcsinalja azokat a dolgokat amiket kell. A legtobb (es jo) container-ben ez igy van. Es lehet hogy millio kis shellscriptet hiv meg, de bezony ennek igy kell lennie (pl. oracle db,  mysql db, es minden aminek valami pre-warm kell). Az init container es az entrypoint.sh ugyanazt csinalja, amikor elindul a container/pod egyszer lefut es kesz, legkozelebb majd a restartnal

* A sidecar az viszont az amit arra irtal, hogy na de kell oda meg mas is. Pl. envoy proxy, akarmi. Ez ugye ugyanabban a namespace-ben indul el es folyamatosan fut. Lass csodat ugyanez tortenik a talpas dockerben, ha ugyanabban a namesspace-ben inditasz tobb containert

A fentiek alapjan nem, nem kell a containereknek semmilyen process supervison sajat magukon belul(!!!), Ha szukseg van a containerek-ben futo process-ek provisionjere, akkor azt azokon kivul meg lehet oldani. Peldaul ilyen a kubernetes, a swarm, de je meg a systemd is tudja (podman generate systemd ...)

* A systemd 2014-2015 tajekan lett widely used amikor meg egy foshalom volt, ugyanakkor a docker 2013-ban mar stabil volt. Cgroups-t mind a ketto hasznal a kezdetek ota, de mondjuk a systemd meg 2018-ban dadogott a namsepace-ekkel. Ma mar a systemd-nspawn mar majdnem tudja azt ami egy containernek kell. Szoval nem, nem valtja ki a systemd a container technologiara epulo megoldasokat

* A containerben nem kell init. Pont ez a lenyeg!!!! Egy process indul a foreground-ban. NEM. KELL. INIT. A dumb-init egy ugynolyan meserseges szar mint a tobbi. Valaki nem ertette a kontenereket es ezert kitalalta. Ha egy processnek meg kell doglenie akkor annak meg kell doglenie es nem, nem szabad ujraindulnia. Pont ezert inditjuk izolalva.

* Azt a kontainert ami nem indul el nem kell hasznalni. Az official containerekben 99%-ban tokeletes entrypoint.sh-k vannak. En meg csak takolt szarokban lattam rosszul megirva meg lyukasan implementalva dolgokat (myqld -u root), aki olyanokat akar hasznalni lelke rajta 

* Mint irtam a systemd tudja kezelni a containereket tobb fele keppen is, tudja provisionolni a contaioner processt, sot maga is tud lightweight containereket inditani a PID namespace-t hasznalva (Isten mentsen meg mindenkit tole!!!)

Szoval gyorsan osszegzem: Nem, nem kell a systemd a konteineren belulre(!!!) es semmilyen mas INIT sem, de ha valaki nagyon akarja akkor hasznalhatja kivulrol barmelyiket

Legközelebb próbáld már meg értelmezni kérlek, amit írtam, mert a felét nem érted, a másik felét meg hozzá képzelted. A harmadik fele meg mese arról, amit tudok. :)

Szóval csak párat  ragadnék ki, for the fun of it :D

Attol, hogy a RedHat csinalta meg nem jo

Nem azt mondtam, hogy jó, hanem hogy nyilván volt rá valós business igény? Értem én, hogy mindent ki kell dobni, ami nem úgy van, ahogy a nagykönyvben leírták, de a gyakorlat meg nem ez. És kérlek találd már ki, hogy az RHnál hülyék a konténerizációhoz :D :D :D

az az entrypoint.sh. Az o feladata, hogy megcsinalja azokat a dolgokat amiket kell

Ja. Szép megoldás, itt kéne vmit csinálni, tessék baszki, szopjál egyedül :D

A dumb-init egy ugynolyan meserseges szar mint a tobbi. Valaki nem ertette a kontenereket es ezert kitalalta. Ha egy processnek meg kell doglenie akkor annak meg kell doglenie es nem, nem szabad ujraindulnia. Pont ezert inditjuk izolalva.

Az a jó, hogy osztod az észt, miközben fingod sincs miről van szó. A dumb-init nem indít ujra semmit, nem spawnol több processzt, kurvára nem csinál semmit sem, kizárólag annyit, amit a PID1-nek muszáj megcsinálni. Azért van, mert a sok tökéletesen megírt entrypoint.sh baszott kezelni a sigtermet, meg nem waitelt a reparentelt childokra, uh gyűltek a zombik, mintha nem lenne holnap. De egyébként ja, mea maxima culpa, rosszul emlékeztem, végül nem a dumb-initet, hanem a tini-t (ami kb pont ugyanazt csinálja) emelték be a dockerba, annyira hülyeség volt :D

ugyanakkor a docker 2013-ban mar stabil volt.

Az, ja. Nem akkor tartotunk ott, hogy az overlayre éppen rájöttek, hogy annyira fos, hogy inkább újrakezdik overlay2 néven, a devicemapperes nem tetszett nekik, a valami nemtommármi meg rendszeresen összefosta magát :D

Arra a busibess igenyre amit irtal es amit a RedHat megoldott maga a containerizacio kepes. Maximum a business igney annyi lehetett, hogy akik keptelenek megerteni hogy mikent mukodik ez az ize azok azt is hasznalhassak. Ettol meg rossz. Nem mondtam, hogy nem ertenek hozza. Hoztak egy penzugyi dontest hogy egy rossz technologiat is eladnak inkabb, mert arra is van igeny. Azert lattunk mar ilyet mashol is. 

Okes a dumb-init-re es a tinit-re nem emlekeztem. Megneztem oket. Jok. Nem futottunk bele soha a zombie-kba. Szerencsenk volt. Mondjuk kerdes hogy mennyire jo workaroundok a taknyolt entrypoint.sh-kra. Valamennyire vedenek, de tovabbra sem 100%-as a vdelem. Az akkor lesz ha rendesen megirjak es tesztelik oket. 

Tehat azt mondod, hogy azert mert fejlesztenek egy szoftveren az azt jelenti, hogy nem stabil. Amugy meg az overley2 bar jobb mint az overlay annak is megvannak a hatulutoi. Amugy nem ok talaltak ki hanem implementaltak azt ami uj lett a linux kernelben. Pl. az overlay eseten ha jol emlekszem volt egy 40+ layer limit az aufs miatt. Az overlay2 mar generikusabb lett, de ott is vannak bajok, bar nehezebb belefutni. Amire viszont emlekszem, hogy ment devicemapperrel (megneztem a v25-tol deprecated azaz iden januartol :D. Most nem akarom elohozni, hogy osztod itt az eszt mikozben fingod sincs mirol van szo, mert nem emlekeztel valamire mint ahogy Te mondtad nekem, de ejnye)

Tisztazzunk valamit. Eloszor is lejott hogy erttesz hozza. Masodszor. Szerintem nem kell init a containerekbe. Mert ha helyesen es odafigyelessel/korultekintessel all az ember a kontenerekhez (es ezt mondjuk auditaljak is) nem lesz gondod. Elfogadom ha nem ertesz ezzel egyet, mert sok rossz tapasztalatod volt. De en nem talalkoztam veluk (igen, soha egy zombie ottragadt szarral sem), mert nalunk azokon a helyeken ahol dolgoztam nagyon komolyan vettek a dolgokat (meg csak official image-eket sem hasznaltunk, hanem buildroot-tal keszitett es security altal szenne tesztelt image-ek mehettek csak ki hasznalatra, olyan nem volt, hogy valami public repo-bol csak ugy behuztunk valamit). Vagy a masik, hogy tenyleg egyetlen binaris fuott csak benne es semmi de semmi de semmi mas, meg egy kibebaszott shell sem, se tool-ok :D

Es de, 2013-ban mar stabilan business-ben hasznaltuk es penzt termeltunk vele, mikozben a systemd-vel meg kivartunk es csomo helyen nem valtottunk ra. Szaros enterprise tudom. De mondjuk ahogy irtam meg 2018-ban is problema volt a namespace kezelesevel, a resolved-vel, meg egy csomo minden alrendszerevel (igaz ezek kozul csomo minden nem volt meg benne 2013-ban sem).  

Arra a busibess igenyre amit irtal es amit a RedHat megoldott maga a containerizacio kepes. Maximum a business igney annyi lehetett, hogy akik keptelenek megerteni hogy mikent mukodik ez az ize azok azt is hasznalhassak. Ettol meg rossz. Nem mondtam, hogy nem ertenek hozza. Hoztak egy penzugyi dontest hogy egy rossz technologiat is eladnak inkabb, mert arra is van igeny. Azert lattunk mar ilyet mashol is. 

Vagy csak a világ nem fekete-fehér? Ne érts félre, nem akarom én bántani a kedvenc dockeredet, összességében nincs vele különösebb bajom, de az a fajta szemellenzős mentalitás, ami szokott (volt) áradni, hogy rosszul tartod, mindennek az elképzelt skálázódós mentalitásban kell működni, és aki mást akar csinálni, az lendületből biztosan hülye. Holott lehet még egy csomó más ok is, ami miatt az ott úgy jó lenne, mert oda jól illeszkedik. Akár csak ilyen "ostobaságok" miatt is, hogy szeretnél belepaszírozni egy működő szoftvert a megoldásodba, és őt még nem a "szent igaz" módon csinálták. Vagy mert van már megoldásod, ami mondjuk csinál már valami dinamizmust, és drága lenne, hogy ezt ezentúl konténer managementtel tegye, haszna meg még nem volna. Vagy csak szeretnél lépésenként haladni. Vagy eleve csak az izoláció meg az inmutable futtatókörnyezet érdekelt. Vagy akármi.

Okes a dumb-init-re es a tinit-re nem emlekeztem. Megneztem oket. Jok. Nem futottunk bele soha a zombie-kba. Szerencsenk volt. Mondjuk kerdes hogy mennyire jo workaroundok a taknyolt entrypoint.sh-kra. Valamennyire vedenek, de tovabbra sem 100%-as a vdelem. Az akkor lesz ha rendesen megirjak es tesztelik oket. 

... Szerintem nem kell init a containerekbe. Mert ha helyesen es odafigyelessel/korultekintessel all az ember a kontenerekhez (es ezt mondjuk auditaljak is) nem lesz gondod. ...

Csak a tisztázás végett, mert szerintem valójában érted te ezt, csak kicsit beszaladtál az erdőbe, mert összemostad a kettőt: Szerintem te azt akarod mondani, hogy service manager nem kell a konténerbe, nem azt, hogy init. A tini és tsai initek, és azok bizony kellenek a konténerbe. Azt csinálják meg, amit minden unix rendszeren elvárunk a PID1-től, hogy történni fog. És épp ezért de, rohadtul kell, és rohadtul szállítania kellett volna a dockernek eleve, mikor terveztek valamit, ami pid namespacekben futtat dolgokat. Be is emelték végül, nyilván nem véletlenül. Az, hogy figyeljél oda, hogy az entry point méretű lukba olyat tegyél, ami megcsinálja ezt-meg ezt (mert az mindig kell), az simán csak szar design. Akkor is, ha nyilván meg lehet oldani minden alkalommal újra feltalálva a kereket.

Elfogadom ha nem ertesz ezzel egyet, mert sok rossz tapasztalatod volt. De en nem talalkoztam veluk (igen, soha egy zombie ottragadt szarral sem), mert nalunk azokon a helyeken ahol dolgoztam nagyon komolyan vettek a dolgokat (meg csak official image-eket sem hasznaltunk, hanem buildroot-tal keszitett es security altal szenne tesztelt image-ek mehettek csak ki hasznalatra, olyan nem volt, hogy valami public repo-bol csak ugy behuztunk valamit)

Nem a rossz tapasztalataim miatt, egyszerűen ez csak rossz design. Mint mondtam, én alapvetően egy tök jó cuccnak tartom a dockert, de ettől még van benne egy csomó ostobaság. Igazából egy kicsit annak ellenére jó. Azért tudott nagyot menni, mert adott egy funkcionális, egységesen kezelhető, a problématér jó részét lefedő megoldást, aminek ráadásul termék formája volt. De az a megoldás helyenként bizony igen vacak volt, mert az architektúra nem sikerült annyira jól. Érdemes megnézni a podman és környéke áfészt, az általában véve arch szempontból szerintem sokkal helytállóbb. Nyilván, volt miben felismerni a bajt, meg mivel összességében a toolchain azért kicsit gondolkozósabb, valószínűleg ha eleve ilyen lett volna, akkor nem terjedt volna ennyire rapidan el ez az egész. (Még akkor se, ha a doksija nem lett volna olyan fos, mint amilyen).

És néha még tetézték is azzal, hogy Pötyit megszégyenítő arogáns faszság beszéléssel magyarázták, hogy mindenki hülye, aki rosszul fogja.

Tehat azt mondod, hogy azert mert fejlesztenek egy szoftveren az azt jelenti, hogy nem stabil.

Es de, 2013-ban mar stabilan business-ben hasznaltuk es penzt termeltunk vele, mikozben a systemd-vel meg kivartunk es csomo helyen nem valtottunk ra.

Nem azt mondtam, hogy nem lehet vele pénzt keresni, hanem azt, hogy messze nem volt problémamentes. És  nem az a baj, hogy fejlődik, hanem az, hogy volt egy időszak (bár most így belegondolva, ez szerintem kicsit később lehetett), amikor viszonylag hosszan az volt, hogy az overlayt gyakorlatilag már elengedték, az overlay2 még kb mindenki szerint is max beta volt, az aufs meg, hát maradjunk annyiban, hogy személyes tapasztalataim alapján nem véletlen, hogy nem engedték bemergelni a kernelbe. Mi viszonylag hosszan devicemappereztünk, mert az volt kb az egyetlen, amiről el lehetett hinni, hogy működik.

(És persze, ettől még a systemdnek is volt mindenféle baja, ezt nem akarnám elvitatni. Hasonló állatok, az is azért jó, mert komplex problémákra ad használható megoldást, nem azért mert nincs benne a motorzháztető alatt egy vödör faszság)

az az erzesem hogy folyamatosan a Balatonrol beszelunk csak Te mondjuk az eszaki partjan allva irod le en meg a delirol.

* Igen, arra gondoltam hogy process provisioning nem kell a konteneren belul, errol is irtam, csak aztan init-nek hivtam, ugyanakkor tenyleg nem futottunk bele sose zombikba, that vakon vagdaloztam a tini ellen :D

* Masik, hogy process-t irtam ott ahol siman "alakalmazaz"-ra gondoltam. Presicsb fel is hivta a figyelmemet ra. Termeszetesen nem arra gontoltam, hogy egy apache-nak vagy nginx-nek vagy egy java alkalmazasnak nem lehet-nek processei vagy thread-jei, hanem hogy nem futtatunk egy containeren belul egy mysqld-t, egy apache-ot, egy graphite-ot, meg egy SSH szervert. 

* A fentivel kapcsolatban rengetegszer belefutottunk, hogy egyes cegek borzalmas dolgokat muveltek, mert pl. inditottak mindenfelet a containeren belul (ssh!!!) es futott 8-10 process is akar, ahelyett, hogy 8-10 containert futtattak volna ugyanabban a namespace-ben. Fenntartim, hogy ez bezony semmilyen modon nem jo. Ha mar rossz design akkor ezt valahogy meg kellett volna oldani :D (persze nem tudom hogyan :D)

* Sose szerettem a dockert csak penzt termeltunk vele (ahogy a kubernetest se szeretem, csak egy technologia amivel dolgozom es penzt keresek, de ugytanigy vagyok a felhovel, bigdata-val is. A gyerekemet szeretem, nem technologiakat. Az olyan lenne, mintha a leveseskanalat szeretnem, mert tudok vele levest enni :D)

* Ahogy irtam mi is devicemappareztunk, szoval igen tudom hogy szar volt az overlay, meg meg csomo minden (default net-ben nem volt dns/service discovery, lehet most sincs, nem tudom mert mar reg nem kovetem, 2013-2019 kozotti dolgokrol tudunk vitatkozni :D)

* A systemd-t SEM szeretem :D (ha nem kellene vele szopni folyton biztos szeretnem, mint a leveseskanalat, vagy a kubernetest :D)  

az az erzesem hogy folyamatosan a Balatonrol beszelunk csak Te mondjuk az eszaki partjan allva irod le en meg a delirol.

Ámen. :)

* A fentivel kapcsolatban rengetegszer belefutottunk, hogy egyes cegek borzalmas dolgokat muveltek, mert pl. inditottak mindenfelet a containeren belul (ssh!!!) es futott 8-10 process is akar, ahelyett, hogy 8-10 containert futtattak volna ugyanabban a namespace-ben. Fenntartim, hogy ez bezony semmilyen modon nem jo. Ha mar rossz design akkor ezt valahogy meg kellett volna oldani :D (persze nem tudom hogyan :D)

Jep, a probléma része volt, hogy ezeket rohadtul nem volt jó dockerrel kezelni valójában, ph ha jól rémlik a PID namespacek is elég későn érkeztek meg pl bele eleve a composeba, meg ugye értelmes dependencia kezelés nem igazán van benne (másik ilyen kedvenc good luck, mint az entrypoint.sh szopjál magad az ugye pont a wait-for-it.sh nyolcvankét különböző permutációja, mert persze ott is ment a mutogatás, hogy az az app dolga... értem én, csak hát egy csomó minden, ami docker előtt keletkezett nem csinálta). De tettem én már bele syslogot is konténerbe a main processz mellé, mert úgy sikerült megoldani a logolást kultúr módon, ahogy a docker nagykönyv szerint kellett volna, úgy nem volt jó.

gyerekemet szeretem, nem technologiakat.

A kettő nyilván nem ugyanaz a "szeretet", de én bevallom, van szoftverből is, ami szimpatkus, meg van, ami nem. Nyilván, ha a nem szimpatikussal kell vmit megoldani, akkor azzal fogjuk, nem erről van szó, de szerintem ér néha élvezni a szakmádat kicsit :)

A container egy izolalt process,

Ez így nem igaz. Egy processz, meg amit forkol magából -a container az egy önálló process tree. Szóval egy konténerben (namespace-ben) futhat ezer processz is akár, senkit nem érdekel. Például a postgres is rengeteg processzként fut, de akár egy apache is, vagy bármi egyéb.

> Lass csodat ugyanez tortenik a talpas dockerben, ha ugyanabban a namesspace-ben inditasz tobb containert

Akkor már lehet egyszerűbb egy konténerben futtatni őket. Nem nagyon lesz előnye annak, hogy külön konténer, ha ugyanott futtatod.

Én sem szeretem azokat a cuccokat, amik a fél világot egy konténerben indítanak el (Gitlab, rád nézek), ugyanakkor az is igaz, hogy sok legacy alkalmazásnál nem igazán van jó megoldás a konténerizációra. Én nem látom ezt a dolgot ennyire fekete-fehéren, én inkább azt mondanám, hogy törekedni kell arra, hogy egy konténer - egy alkalmazás.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

törekedni kell arra, hogy egy konténer - egy alkalmazás.

Egy alkalmazás állhat több, egymástól teljesen eltérő processztől - rád nézek, Gitlab. A Gitlab egy alkalmazás, amiben van mindenféle dolog. Webszerver, adatbázisszerver, adminisztratív folyamatok, minden finomság.

Ez akkor most egy konténer?

 

Erre való ugye a k8s pod fogalma - összefüggő, de mégis külön kezelendő konténerek.

Mondjuk pot a gitlab tenyleg egy hell, megha van is ra Helm chart es szepen minden komponense lehet mashol, hiszen a legtobb service alapu (ip:port) mint a db, consule, object store, minden szirszar. 

Szoval igen lehet docker composolni, meg k8s-ben futtatni, de meg a GitLab is azt mondja, hogy menjen az omniinstall  (mondjuk regen neztem mar ra, lehet azota jobb a helyzet)

Bizonyos szinten egyeteertek. Latom sajna hogy igy 20+ ev utan is vannak dev-ek, akik keptelenek ugy megirni egy app-ot, hogy az komponensekbol alljon, hogy esetleg ki lehessen szervezni oket mas kontenerbe, gepre, felhobe, kenyerpiritora, vagy csak tobb peldanyt lehessen beloluk futtatni, hogy a rendszer kicsit hibaturobb, flexibilisebb legyen (egy appa belerakjak a mindent is es megirjak nullarol a queue managementet, az ETL-t, minden faszomat is meg lehet embedded DB-t is riottyentenek hozza :D).

Sajnos az ilyen rendszerekkel nem lehet mit kezdeni. A legnagyobb hiba mikor ezeket aztan egy fonoki utasitasra belegyomoszolik egy kontenerebe. Aztan jon hogy lassu. Es meg nem mondod, hogy mi? Mit lehetne benne feljebb skalazni. Jonnek az 7GB meretu kontenerek, amikbol egy fut egy 32GB RAM-os hoszton ami 16 vcpu-val rendelkezik. Igen semmi ertelme, de lattam mar ilyet. :D

Régi melóhelyemen ősrégi fedora alatt futott az ősrégi legacy mysql.

A fejlesztői környezetekhez abban raktam össze mindent, a legrégebben fellelhető dockeres fedora-ban raktam össze én is amit lehetett. Szerencsére végül sikerült átállni 8-asra és utána már nem kellett.

Szóval ez pl lehet indok.

 

Kérdezőnek:

Viszont a kérdés itt nem az ,hogy dockerben hogy lehet elindítani, hanem az, hogy fedora alatt hogy lehet, annak kell utánanézni. Google alatt valszeg fél perc. Nekem nincs hozzá kedvem.

ugye itt az a baj, hogy a docker egyetlen process-t indit foreground, azaz ha az kell, hogy egy process supervisor inditsa a docker helyett, akkor bezony azt be kell konfigolni, meg gondozni is kell. De az egesz ott szarodik el, hogy ennek semmi ertelme. Egy container egy process. Nincs init, nincs process provisioning (jo, lehet supervisrod vagy akar systemd is). De mondom, semmi ertelme systemd-t inditani egy containerben, hogy elinditson egy process-t es esetleg ujra-es-ujra inditgassa ha az szar. Akkor bezony annak meg kell doglenie ha baja van. 

Amugy a podman tamogatja a systemd-t (de megint csak minek is?). A systemd cgroup-ol, namespace-el es elindit egy process-t, he varj, ugyanezt csinalja a docker is vagy a podman. :D

Amubgy Fedora-n ugyanugy indul mint mindenhol mashol, systemd start mysql.service :D 

( kassaiviktor | 2024. 10. 03., cs – 13:49 )

hogy indítod el a konténert?

próbáld:

docker run --cap-add=sys_nice -d kontenernev

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

A kerdes itt arra vonatkozott hogy inditja el a containeren belul a myslq-t. Itt aztan bedobtak a systemd-t ami nem jo otlet. Lehet talpasan is elinditani (man mysqld), de kurvara sok mindent kell meg ballitani utana ha hasznalni is akarja. Ezt oldana meg az official mysql image. Ha nagyon akarja akkor az elejere odavagja a fedora image-et  FROM-ba es atirja az osszes shell scriptet meg minden istennyilat fedorasra. De minek, az istenert minek????!!!?!?!?!?!

Nekem közben felugrott pár emlék régebbről pont amikor még fedora alatt dockereztem régi mysql-el, hogy számított az is, hogy hogyan mountolom az adatokat. Pl a full mysql-es data könyvtárat nem lehetett felmountolni mert oda akarta tenni a process fájlokat vagy mit és azt nem bírta. Így a cnf-ben külön át kellett írni, hogy hol van a data mappa és azt lehetett mountolni.

Nem tudom, hogy nálad ilyen gond van e, ha mountolsz, akkor kezdetnek kommenteld vagy vágd ki az összes mount pontot és próbáld úgy, hogy mi történik.

ismetlem magam:

1. irany a github es nezd meg az official-t

2. az alapjan ganyold ossze amit szeretnel

Amugy az operation not permitted helye es ideje elegge beszedes szokott lenni a logokban. Az egyik dolgo lehet ugye, hogy a container egy bizonyos user ID-val fut, vagy a benne levo process, ami aztan hozza aakr ferni mondjuk a mlountolt volume-hoz amit viszont a host jogosultsagi rendszere megfog (megoldas az ACL). Aztan lehet az is ugye, hogy a mysql process fut a 1000-es UID-el es letre akarja hozni a db-t a container filerendszereben, de ugye ott mindent a UID XXXX (fasz se tudja) birtokol. Es akkor meg ezer masik dolgot nem is emlitettunk, mint peldaul a socket letrahozasat (unix vagy tcp? es ha TCP mapped port tuti hasznalhato neki? stb stb) 

A fenti hibak mindegyike siman megoldhato ha tudod miert irja ki az opertaion not permitted-et

Azert egy operation not permitted-hez meg nem kell strace :D

Valoszinuleg filerendszer jogosultsagi problemaja van a mysqld-nek a kontaineren belul. Szerintem meg kellene neznie milyen userrel fut a container es milyen user-rel akar futni a mysql service (meg megnezni hogy a my.cnf-ben hol van a data dir). Meg ha mountolt volume akkor azon hogyan allnak a jogosultsagok a host-on.

Az operation not permitted tipikusan a db letrahozasa/inicializalasa vagy a socket krealasakor jon elo, ha nincs meg a jogosultsag

Na kidebuggoltam neki:

[root@22ab9cc1cc1a /]# cat /etc/redhat-release 
Fedora release 40 (Forty)
[root@22ab9cc1cc1a /]# mysqld -v
bash: /usr/sbin/mysqld: Operation not permitted
[root@22ab9cc1cc1a my.cnf.d]# grep datadir mysql-server.cnf 
datadir=/var/lib/mysql
root@22ab9cc1cc1a my.cnf.d]# su - mysql -s /bin/bash
[mysql@22ab9cc1cc1a ~]$ id
uid=27(mysql) gid=27(mysql) groups=27(mysql)
[mysql@22ab9cc1cc1a ~]$ cd /var/lib/mysql
[mysql@22ab9cc1cc1a mysql]$ touch xxx
[mysql@22ab9cc1cc1a mysql]$ # Ez bezony megyen
[mysql@22ab9cc1cc1a mysql]$ cd
[mysql@22ab9cc1cc1a ~]$ /usr/libexec/mysqld --log-error-verbosity=3 --console
bash: /usr/libexec/mysqld: Operation not permitted

Szoval bezony maga a binaris keptelen megcsinalni a dolgokat, de miert is? Mert bezony a containernek nincs meg a capabilitije hozza

Ha "--privileged" akkor meg siman indulna, de bezony ott meg az a baj, hogy root-kent nem akarja futtatni magat :D

$ podman run --privileged --name mysql -d fedora:latest /bin/sh -c "while true; do sleep 5000;done"
505e08d85ba2f18a2bf3389ac1b87ab82349c30bda98e34f85c2474a6038ca1c
$ podman exec -ti mysql /bin/bash                                                      
[root@505e08d85ba2 /]# dnf install -y mysql-server
...
[root@505e08d85ba2 /]# mysqld
2024-10-04T07:05:37.423911Z 0 [System] [MY-010116] [Server] /usr/libexec/mysqld (mysqld 8.0.39) starting as process 239
2024-10-04T07:05:37.425570Z 0 [ERROR] [MY-010123] [Server] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
2024-10-04T07:05:37.425622Z 0 [ERROR] [MY-010119] [Server] Aborting
2024-10-04T07:05:37.425830Z 0 [System] [MY-010910] [Server] /usr/libexec/mysqld: Shutdown complete (mysqld 8.0.39)  Source distribution.

Szoval tehat a megoldas hogy a containernek meg kell adni a CAP-et es kesz, de ne inditsuk privileged-del :D

( makgab v | 2024. 10. 04., p – 10:48 )

Köszönöm a segítséget! Elindult:

# Dockerfile

FROM fedora:latest

RUN dnf update -y && dnf install ... mysql-server -y
# RUN mkdir -p /var/run/mysql /var/lib/mysql && chown -R mysql:mysql /var/run/mysqld /var/lib/mysql
RUN setcap -r /usr/libexec/mysqld
RUN mysqld_pre_systemd

EXPOSE 3306

ENTRYPOINT ["mysqld","-u","root"]

Persze finomítani lehet rajta. ;)

Es a vege egy olyan szorny lett amit jobb sehol sem elinditani inkabb :D

Rootkent inditod a mysqlt es leszeded a capabilitiket a binarisrol. Azt azert tudod, hogy a process valojaban a host-odon fut ugye (megha namespace-ben is)? A munkaban ilyet azert ne csinalj :D (mondjuk nekem meg hobbibol is szurja a szemem)

Az a baj, hogy annyira már nem érdekelt, hogy értsd, hogy mit csinálsz, és hogy miért rossz amit csinálsz, egyszerűen felmentél a chatGPT-re/StackOverflow-ra, és copy-paste megoldottad. Látszik a megoldásodon.

Üzemeltetőkén elengedhetetlen, hogy értsük mit csinálunk. Nem feltétlen kell jó megoldásnak lennie, nem feltétlenül kell jó patternek alapján csinálni - de értsük, hogy mit csinálunk, és hol lehet ez rossz. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-