Docker Compose: Bind Mount au Volume Iliyopewa Jina?

Bind mount au volume nommé : réponse courte

Les volumes Docker Compose sont de deux types. Le choix dépend de l’utilisateur qui gère les fichiers. Utilisez un bind mount pour les fichiers que vous écrivez et lisez vous-même, par exemple la configuration, les modèles et les sites statiques. Utilisez un volume nommé pour les données gérées par l’application, par exemple les fichiers de base de données, les index de recherche et les médias téléversés. Un bind mount pointe vers un chemin de l’hôte que vous pouvez ouvrir dans un éditeur. Un volume nommé est un espace de stockage que Docker crée et suit pour vous, et auquel vous accédez par Docker.

Les deux apparaissent sous la même clé volumes: dans un service, ce qui explique la confusion. La différence se trouve à gauche des deux-points. Si la partie gauche commence par . ou /, il s’agit d’un chemin de l’hôte, donc d’un bind mount. Toute autre valeur est un nom, donc un volume nommé, et ce nom doit également être déclaré dans le bloc de niveau supérieur volumes:.

Sintaksia mbili katika faili ya compose

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: changeme
    volumes:
      - pgdata:/var/lib/postgresql/data
  web:
    image: nginx:1.27
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./site:/usr/share/nginx/html:ro

volumes:
  pgdata:

pgdata:/var/lib/postgresql/data ni volume iliyopewa jina. ./nginx.conf:/etc/nginx/nginx.conf ni bind mount, na :ro huiweka katika hali ya kusoma tu. Huo ndio mpangilio sahihi wa kawaida kwa usanidi ambao container haipaswi kuandika upya kamwe. Ukisahau ingizo la kiwango cha juu volumes:, Compose husitisha kazi kwa service "db" refers to undefined volume pgdata.

Iwashe na uorodheshe vitu vilivyoundwa na Docker:

docker compose up -d
docker volume ls

Volume hiyo haiitwi pgdata. Inaitwa <project>_pgdata, kwa sababu jina la mradi kwa chaguo-msingi huwa jina la saraka iliyo na faili ya compose. Saraka inayoitwa myapp hutoa myapp_pgdata. Hili ni muhimu kwa sababu kubadilisha jina la saraka hukupa volume mpya iliyo tupu, na programu huonekana kana kwamba imepoteza data yake. Haikupoteza data hiyo: volume ya zamani bado imeorodheshwa na docker volume ls. Weka jina hilo kwa name: katika faili ya compose, au weka COMPOSE_PROJECT_NAME, ikiwa saraka inaweza kuhamishwa. Mipangilio kama hiyo inapaswa kuwekwa pamoja na faili za mazingira na siri za Compose.

Kwa nini hitilafu za ruhusa hutokea tu kwenye bind mounts

Hii ndiyo tofauti kuu ya kiutendaji. Inatokana na kanuni moja: named volume iliyo tupu wakati wa matumizi ya kwanza hujazwa kutoka kwenye image, lakini bind mount haijazwi hivyo.

Docker inapoweka named volume tupu juu ya directory ambayo tayari ina data kwenye image, inanakili data hiyo kwenye volume pamoja na umiliki na modes zilizowekwa na image. Official Postgres image hutoa /var/lib/postgresql/data ikiwa inamilikiwa na mtumiaji wake wa postgres. Kwa hiyo, volume huja ikiwa inamilikiwa na numeric id hiyo hiyo, na database huanza.

Bind mount hufanya kinyume. Kila kilicho kwenye host ndicho container huona, pamoja na umiliki wake, na data ya image katika path hiyo hufichwa. Ikiwa directory ya host haipo, Docker daemon huiunda. Daemon huendesha kama root, kwa hiyo unapata directory inayomilikiwa na root:root. Mchakato wa container unaoendesha kama mtumiaji asiye root hauwezi kuiandikia:

PermissionError: [Errno 13] Permission denied: '/data/app.db'

Suluhisho ni kufanya namba hizo zilingane. Umiliki katika bind mount hulinganishwa kwa numeric user id, si kwa jina, kwa sababu container ina /etc/passwd yake. Mtumiaji anayeitwa app ndani ya container hana maana yoyote kwenye host. Uid 1000 humaanisha uid 1000 katika pande zote mbili.

id -u
mkdir -p ./data
docker compose exec web id
sudo chown -R 1000:1000 ./data

docker compose exec web id huchapisha uid ambayo mchakato wa container unaendesha nayo kwa kweli. Linganisha directory ya host na namba hiyo, au weka container itumie namba yako kwa user: "1000:1000" katika service. Kuweka user: ni safi zaidi kwa application uliyoandika mwenyewe. Kubadilisha umiliki wa directory ya host ni salama zaidi kwa image ambayo hukuandika, kwa sababu baadhi ya images huanzisha entrypoint kama root, kisha hupunguza privileges na kutarajia umiliki maalumu katika sehemu zilizo chini yake.

Kuna mitego mingine miwili inayofaa kujulikana. Kwenye Fedora, RHEL na mifumo mingine yenye SELinux (security-enhanced Linux) ikiwa katika hali ya enforcing, bind mount hukataliwa hadi ipatiwe lebo mpya. Kwa hiyo, ongeza :z kwa path inayoshirikiwa kati ya containers au :Z kwa path ambayo container moja pekee inapaswa kutumia, ukiandika kama - ./data:/data:Z. Pia, bind mount ya file moja badala ya directory huvunjika wakati editor inapobadilisha file badala ya kuandika ndani yake, kwa sababu mount hufuata inode ya awali. Container huendelea kuona data ya zamani hadi uiwashe upya. Weka mount kwenye directory mama wakati file huhaririwa mara kwa mara.

Utendaji: tofauti ilipo halisi

Kwenye seva ya Linux, aina zote mbili hupitia njia ileile ya kernel. Kwa hiyo, tofauti ya throughput ni ndogo kiasi kwamba hupaswi kuchagua kwa kuzingatia jambo hilo. Volumu zenye majina zinazotumia driver chaguo-msingi local huhifadhiwa kwenye mfumo uleule wa faili unaotumiwa na Docker, chini ya /var/lib/docker/volumes/. Bind mount huhifadhiwa mahali ulipoelekeza.

Tofauti huonekana kwenye Docker Desktop ya macOS na Windows, ambapo kontena huendeshwa ndani ya mashine pepe. Bind mount hapo hupitia kutoka kwenye mfumo wa faili wa hosti hadi kwenye mashine hiyo pepe kupitia safu ya kushiriki faili. Workload zenye utendaji mwingi wa faili ndogo, kama mti wa utegemezi wa Node.js au akiba ya mfumo wa PHP, hupungua kasi kwa kiasi kinachoonekana. Volumu zenye majina hubaki ndani ya mashine pepe na hazibebi gharama hiyo. Ndiyo sababu faili nyingi za compose za maendeleo huunganisha saraka ya msimbo kwa bind mount, lakini hutangaza volumu yenye jina juu ya node_modules.

Tofauti nyingine halisi ni mahali baiti zinapohifadhiwa. Bind mount ya /mnt/backup huweka data kwenye diski hiyo. Volumu yenye jina huwekwa kwenye mfumo wowote wa faili unaoshikilia /var/lib/docker, ambao kwenye VPS kwa kawaida huwa diski ya root. Database inayokua ndani ya volumu yenye jina hujaza diski ileile inayohifadhi logi za mfumo wako. Ikague kabla haijasababisha tukio:

docker system df -v
df -h /var/lib/docker

docker system df -v huorodhesha kila volumu pamoja na ukubwa wake, na huweka alama kwenye volumu ambazo hakuna kontena inayozirejelea tena.

Kukagua volume yenye jina

Volume yenye jina si kisanduku kisichoeleweka. Uliza Docker iko wapi:

docker volume inspect myapp_pgdata

Sehemu ya Mountpoint hutoa njia halisi ya mwenyeji, kwa kawaida /var/lib/docker/volumes/myapp_pgdata/_data. Unaweza kuisoma kwa sudo ls, na hilo linafaa kwa ukaguzi wa haraka. Usiichukulie kama mahali pa kuhariri faili. Kuandika humo ukiwa root kunasababisha tena tatizo la umiliki lililoelezwa hapo juu, na njia hiyo ni maelezo ya kiendeshi cha local ambayo viendeshi vingine vya volume havitumii.

Njia salama ya kuangalia ndani ni kutumia kontena ya muda inayoweka volume:

docker run --rm -v myapp_pgdata:/vol alpine ls -la /vol

Hii hufanya kazi kwa kiendeshi chochote, huona ruhusa zilezile zinazoonekana na kontena halisi, na haiachi chochote kwa sababu ya --rm.

Kuhifadhi nakala za kila aina

Bind mount ni saraka ya kawaida, kwa hiyo zana yoyote ya kuhifadhi nakala za kiwango cha faili tayari inaihudumia. Elekeza uhifadhi wa nakala kwenye njia ya mwenyeji, na umemaliza. Volume yenye jina inahitaji hatua moja ya ziada, kwa sababu zana lazima iingie ndani yake. Mount volume na saraka ya mwenyeji kwenye container ileile ya muda mfupi, kisha uandike archive:

docker run --rm \
  -v myapp_pgdata:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

Rejesha kwa kufanya kinyume chake kwenye volume mpya:

docker volume create myapp_pgdata_restored
docker run --rm \
  -v myapp_pgdata_restored:/data \
  -v "$PWD":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

tar huhifadhi umiliki wa nambari inapotekelezwa kama root ndani ya container. Hilo ndilo linalofanya volume iliyorejeshwa itumike na programu.

Onyo moja linahusu aina zote mbili. Kunakili faili za database wakati database inaendelea kufanya kazi hukupa archive ya hali inayobadilika, na kunaweza kuirejesha katika hali iliyoharibika. Simamisha service kwanza, au tumia zana yenyewe ya database kufanya dump, kama ilivyo katika docker compose exec -T db pg_dump -U postgres appdb > appdb.sql. Hilo hutengeneza faili wazi ambayo unaweza kuijumuisha katika utaratibu wa kawaida wa kuhifadhi nakala uliosimbwa kwa restic pamoja na faili zako za compose.

Kuhamisha bind mount hadi named volume

Uhamishaji ni wa kunakili, si kubadilisha jina, na huchukua takriban dakika moja.

docker compose down
docker volume create myapp_pgdata
docker run --rm \
  -v "$PWD/data":/from \
  -v myapp_pgdata:/to \
  alpine sh -c 'cp -a /from/. /to/'

cp -a huhifadhi umiliki, ruhusa na mihuri ya muda, kwa hiyo mtumiaji wa kontena aliyekuwa na uwezo wa kusoma saraka ya zamani bado anaweza kusoma volume mpya. Kisha badilisha huduma itumie pgdata:/var/lib/postgresql/data, ongeza pgdata kwenye bloku ya kiwango cha juu ya volumes:, endesha docker compose up -d, na soma kumbukumbu za programu kabla hujafuta saraka ya zamani. Kuhamisha kwa mwelekeo mwingine hutumia amri hiyo hiyo, huku /from na /to zikiwa zimebadilishana.

Kumbuka jambo moja unapojaribu. docker compose down huacha named volumes bila kuzigusa, lakini docker compose down -v hufuta kila named volume ambayo mradi umetangaza, na huwezi kutendua kitendo hicho. Bind mount hubaki baada ya amri zote mbili, kwa sababu Docker haikuwahi kumiliki saraka hiyo. Ikiwa amri za mzunguko wa maisha bado ni mpya kwako, mwongozo wa misingi ya Docker Compose kwa VPS unaeleza hatua hizo.

Kuchagua, huduma kwa huduma

Uliza ni nani anayeandika faili. Usanidi unaohariri katika kihariri cha maandishi na kuhifadhi kwenye git unapaswa kuwa katika bind mount, iliyowekwa kupitia :ro, kwa sababu unataka ionekane na iwe na historia ya matoleo. Hali ya programu ambayo huifungui kamwe kwa mkono inapaswa kuwa katika named volume, kwa sababu Docker huweka ruhusa kwa usahihi na data haitegemei njia ya mwenyeji.

Kesi mchanganyiko ni midia. Maktaba ya picha huandikwa na programu, lakini pia husimamiwa na wewe, na mara nyingi huwa kubwa kiasi cha kuhitaji diski maalum. Iweke kwenye bind mount inayoelekeza kwenye njia iliyo kwenye diski hiyo, kisha weka umiliki kwa makusudi mara moja. Huo ndio mpangilio unaotumiwa na mifumo mingi ya self-hosted: named volumes kwa hifadhidata na akiba, na bind mounts kwa usanidi na kwa saraka kubwa unayoihitaji.

FAQ

Kuna tofauti gani kati ya bind mount na named volume?

Bind mount huunganisha path kwenye host na container, kwa hiyo pande zote mbili huona directory hiyo hiyo na unaweza kuihariri kwa zana za kawaida. Named volume ni hifadhi ambayo Docker huunda na kuidhibiti, na hutajwa kwa jina na kutangazwa katika block ya kiwango cha juu ya volumes:. Tofauti ya kiutendaji ni umiliki: tumia bind mounts kwa usanidi unaoudumisha, na named volumes kwa data ambayo programu huihudumia.

Kwa nini napata "permission denied" kwa bind mount lakini si kwa named volume?

Named volume tupu hujazwa kutoka kwenye image, kwa hiyo hurithi umiliki uliowekwa na image na mtumiaji wa container anaweza kuiandikia. Bind mount huonyesha directory ya host jinsi ilivyo, na ikiwa Docker ililazimika kuunda directory hiyo, iliifanya imilikiwe na root. Tekeleza docker compose exec <service> id ili kuona kitambulisho cha namba kinachotumiwa na container, kisha sudo chown -R <uid>:<gid> directory ya host, au weka user: "1000:1000" kwenye service.

Docker huhifadhi wapi named volumes kwenye diski?

Kwa driver chaguo-msingi ya local, huhifadhiwa chini ya /var/lib/docker/volumes/<volume>/_data, na docker volume inspect <volume> huchapisha Mountpoint kamili. Isome ikiwa unahitaji kukagua jambo, lakini iandikie tu kupitia container, kwa sababu kuihariri kama root kwenye host hubadilisha umiliki kwa njia ambayo container haitatarajia.

Ninawezaje kuhifadhi nakala rudufu ya named volume?

Tekeleza container ya muda mfupi iliyo na volume na directory ya host zote zimeunganishwa, kisha hifadhi kumbukumbu kutoka moja hadi nyingine kwa kutumia docker run --rm -v myvol:/data:ro -v "$PWD":/backup alpine tar czf /backup/myvol.tar.gz -C /data .. Kwa database, toa dump kwa kutumia zana yake yenyewe badala ya kunakili faili zinazoendelea kutumiwa, kwa sababu nakala ya faili inayochukuliwa wakati wa uandishi inaweza kurejeshwa katika hali iliyoharibika.

Je, docker compose down hufuta volumes zangu?

docker compose down huondoa containers na networks na huacha named volumes mahali pake. docker compose down -v pia hufuta kila named volume ambayo mradi umetangaza, bila uwezekano wa kurejeshwa. Bind mounts haziondolewi na amri yoyote kati ya hizo, kwa sababu directory hiyo ni ya host na si ya Docker.