Röviden, elkadtam... :/
Kicsit hosszabban, az van hogy szeretnék ~ 30 konténert futtatni dockerben. Hogy legyen valami formája a gyereknek: proxmox host, ezen egy deban 12-es VM. A VM-en rootless modban fut a docker.
Van nekem egy NFS kiszolgálom, mert gondoltam NFS-el osztanam meg a docker hostnak, a volumeokat.
User akinek a nevében fut a docker: docker_user
NFS kiszolgálón létrehoztam szintén ezt a docker_user felhasználót, ügyelve arra, hogy az UID-k megegyezzenek. Doksikból kiderül, hogy NFS-nél nem a felhasználónév számít alap esetben, hanem az azonosítók. Ez pipa.
Adott a megosztás, 755-ös beállításokkal. docker_user olvassa/írja, stb... - többi userem 755 alapján tudja tenni a dolgokat. Boldogság.
De... a konténereket compose-al szeretném felügyelni, nekem ez egyszerű 1 file-ban bent van minden.
Gondoltam létre is hozom az elsőt, ez egy mongo adatbázis.
A compose:
version: '2.24'
services:
# 1. mongo adatbazis graylog-hoz
mongo_db:
container_name: mongo_db
image: mongo:6.0.13-jammy
restart: unless-stopped
volumes:
- type: bind
source: /home/docker_volumes/mongo_db
target: /data/db
bind:
create_host_path: true
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
networks:
docker_intra_net:
ipv4_address: 172.28.0.5
networks:
docker_intra_net:
ipam:
driver: default
config:
- subnet: 172.28.0.0/24
gateway: 172.28.0.254
Ahogy compose up-al létrehoznám a konténert, az alábbi hibaüzenet jön: mongo_db | chown: changing ownership of '/data/db': Operation not permitted
És én most nem tudom, hogy mi a csöcs van. Ha local-ban hozom létre, akkor rendben van természetesen. Ebben az esetben a mongo 999-es UID-ra állítja a könyvtárat.
Feltételezésem, hogy ugyan ezt szeretné elkövetni az NFS megosztáson is, de ott ugye ne tudja.
Kérdésem, hogy hogyan lehetne megugrani ezt a problémát?
Most nekem 999-es UID-al létre kellene hoznom, az NFS szerveren is "valakit", sőt minden konténernél ahol chown "change" lenne, ott ugyan ezt meg kellene csinálni.
Az NFS beállításai(tudom, hogy nem elegáns a gyökérből megosztani, de ez most egyelőre ilyen):
/data/docker_volumes 192.168.54.0/24(rw,sync,no_subtree_check)
Dockerben jártas személyeket kérdeznék:
Ott ahol még nem kubernetes van, de szintén NFS-el van megoldva a storage a volume-ok alá, ott hogyan működik? Feltétetelezem, hogy nem a rootless mode a gond, hiszen az NFS kiszolgáló "rootja" és a cliens "rootja" nem egyezik meg.
Vaagy, fordítva kellene indulni, és létre kell hozni az NFS szerveren a mappa struktúrát, majd NFS volume-ként becsatolni compose-al a konténerhez?
Ebben az esetben az a gond, hogy local volume-ként szeretném kezelni az NFS-t, ami eleve nem tud ebben a formában működni, és csak úgy fog menni, ha NFS-ként van mountolva a konténer alá?
Köszi a segítséget előre is!
- 474 megtekintés
Hozzászólások
Na most akkor a /home/docker_volumes/mongo_db mar letre lett hozva es a jogosultsaga a mongodb container userenek a UI-javal lett megadva (ami ezek szerint 999)? Jol ertem?
Amugy nem ertem mi a baj azzal, ha letrehozol NFS docker volumeokat es azokat csatolod fel es nem az OS local konyvtarait, amik amugy az NFS-en vannak.
docker volume create --driver local --opt type=nfs --opt o=addr=[nfs-ip-address],rw --opt device=:/home/docker_volumes/mongo_db mongodb_vol(a fentit a docker composban is meg tudod csinalni es akkor nem kell elore megcsinalni)
Aztan ezt mountolod fel mint "source: mongodb_vol"
A masik, hogy ha hozzafereseket kell allitani millio kulobozo usernek akkor kapcsold be az NFS-en az ACL-t es azzal adj inkabb jogosultsagokat a filerendszeren a konyvtaraknak es hagyd hogy az NFS ezeket figyelje.
- A hozzászóláshoz be kell jelentkezni
Majdnem! - az van, hogy most egy zsír új telepítés után, létre kellene hozni a konténereket, és el kellene indítani őket. Nyilván ez nem életszerű, de most innen indulnék.
Szoval a compose létre hozza a "mappát" az nfs megosztáson. docker_user:dockeruser tulajdonossal Ez eddig oké. Ide szeretne a docker vagy az image vagy valaki, ezt igazaból nem tudom ki végzi, de a lényeg, hogy fájlokat kellene ide bemásolni, és a mappára a 999-es UID-t beállítani. Ez nem megy neki.
Közben meglepetés... rootless mode-ban a compose nem tudja mountolni az nfs volume-ot. :)
Szóval lassan az lenne a kérdés, hogy VM felett a docker, root vagy rootless számít-e?
- A hozzászóláshoz be kell jelentkezni
Hogyan is menne. Nem fogja tudni a jogosultsagokat allitani rajta a dockeren belul futo 999-es UID-s process, ha a dockeruser a tulajdonos aaminek meg mondjuk 3000 az UID-ja.
Erre irtam hogy ACL. Bekapcsolod a filerendszeren es az NFS-ben is. Aztan azt monod a szerveren hogy "setfacl -R -d -m u:999:rwx /data/docker_volumes" meg az osszes tobbi conteiner UIDra is csak tudnod kell mik az uid-ok a containerekben
Innentol ha ezen belul valami letrehoz egy konyvtarat az is orokli a jogokat (-R -d) es igy majd ha azon belul akar letrehozni valamit es futtatni az initjebol (pl egy chown-t) akkor majd fogja tudni
Aztan meg tisztazzuk, hogy az image nem hoz letre semmit, hanem a container azaz az image-re rakott rw layer az ami barmit is csinal, itt ebben az esetben valoszinuleg az entrypoint script csinalja ami meghivja a szukseges setup-okat a containeren belul azzal a userrel amivel a process fut. Meg ilyenek.
- A hozzászóláshoz be kell jelentkezni
a compose tud olyat, hogy a container useret es groupjat "kivulrol" bemappeli:
user: ${USERID}
ahol $userid valami ilyesmi lehet: 1001:1001 (a hoston levo docker_user id:gid-je)
https://docs.docker.com/compose/compose-file/05-services/#user
- A hozzászóláshoz be kell jelentkezni
Az első problémát én a jogosultság kezelésben és az userek "felfogásábban" látom.
A docker_user illúzió. A dockerd daemon-nak root userrel kell futnia, hogy tudjon csatolni. El kell indítania a konténeren belüli processzt - olyan userrel, ameylyet a konténer kért, ha semmit nem mondott, akkor root userrel fut a processz. Tehát ezen a ponton a dockerd daemon root userként fut, a konténeren belüli processz meg olyan userrel, amilyet a konténer kér. Esélyesen ezek egyike sem a doker_user.
Olyat lehet csinálni, hogy kinevezek egy usert, akinek jogot adok arra, hogy a dockerd daemon socketjét írhassa is és így kommunikáljon a dokerd-vel utsítást adjon különböző konténerekkel kapcsolatos műveletekre - de ez teljesen más irány. (A hátterében az lehet, hogy így megse root userrel kell docker parancsokat kiadni.)
Tehát a jogosultság kezelés erősen eltérő, ennek megfelelően esélyesen az NFS megosztásnál is hiába kap docker_user jogot adott mappára, a procssz nem a docker_user nevében fog futni.
A másik csavar a VOLUME kezelés. Az első lehetőség, hogy a dockerre bízod. Ez azért másabb,mint a többi, mert ha a konténer definíióban ez a mappa nem üres és a docker első alkalommal lövi fel a konténert ,akkor a konténeren belül a VOLUME alatti mappa tartalommal inicializálja a frissen létre hozott VOLUME-ot - ugyanez ha bind-mountot használsz, vagy hálózati csatolást végzel, akkor ez elmarad, ha a VOLUME-on induláskor már lennie kell adatnak, akkor az a te feladatod, hogy elhelyezd ott.
A másik: a docker ismeri az nfs csatolást - tehát fölösleges becsatolni az alapgépen (még akkor is, ha ez az "alapgép" valójában csupán egy VM egy ProcxMox alatt), hanem a VOLUME kapcsán eleve azt kell megmondani, hogy ez egy hálózati megosztás, amely adott helyen érhető el. (Erre már van példa példa az első hozzászólásban.)
- A hozzászóláshoz be kell jelentkezni
En hasonlokepp hasznalok egy 3 nodeos swarm-ot. En (ahogy itt irtak) a Docker en beluli, beepitett NFS-el hozom letre a volume-okat.
Nekem akkor volt hasonlo jogosultsag hibam, ha az NFS servert V3-al hasznaltam. V4-el ok lett minden.
Side note. Nagyon gondold at, hogy DB-t teszel NFS-re!! en ezzel szopok regota.. van egy postgresql, ami egy NFSv4-en csucsul (v3-on amugy nem is ment) de folyton ossze fossa magat.. A neten 100+1 helyen le van iva hogy NE CSINALD, de persze en azert is (meg jelenleg meg alternativam sincs egyeb shared storage-re...iSCSI-n gondolkodom, de nem talalom a doksiban, hogyan kell dockeren belul felcsatolni ... Pedig peldakban szerepel.)
Amugy ha ezzel kapcsolatban van valakinek otlete (marmint hogyan lehet a stabilitason javitani) azt orommel fogadom :) Az NFS server egy TrueNAS core.
- A hozzászóláshoz be kell jelentkezni
Bár nem válasz a kérdésre, de valamelyest kapcsolódik: ne használj NFS-t adatbázis jellegű file-ok (mint pl. mongodb) tárolására.
- A hozzászóláshoz be kell jelentkezni
gondolkodtam alternativan. Minio mennyire jo db tarolasra (volume-kent hasznalva)? vagy ez teljesen rossz irany?
- A hozzászóláshoz be kell jelentkezni
Mivel a minio object storage az meg nem szereti az appendet nem eppen jo irany. neked egy block storage kell nem object store (ceph+rook, vagy gluster, vagy akarmi a mi block alapu)
- A hozzászóláshoz be kell jelentkezni
ertelek. iSCSI lesz sztm az irany, OCFS2 Clusterel.
- A hozzászóláshoz be kell jelentkezni
NA kozben elokerultem.
A megoldas, a kontenerhez direktben felcsatolni a volume-ot, NFS-el. Ehhez elengedhetetlen a root, ahogy fentebb is irtak.
Koszonom a segitsegeteket, ez igy mukodni latszik.
- A hozzászóláshoz be kell jelentkezni