Hoidla hargitamine
Hargitagete kogu tootmiskeskkond (rakendus, andmebaas, konfiguratsioonifailid) sekundites. Ükskõik kui suur. Nullkasutus kettalt. Hargi nii palju kui tahate.
Lühisõnum: kloonige tootmine, ärge rikuge midagi.
Vaata õpetust
Ettevalmistus: midagi kaduma pandava loomine
Kõigepealt andke käivitavale rakendusele fail, et saaksite tõestada forgi isolatsiooni. Avage hoidla VS Code’is, seejärel looge hoidlas märkerfail:
rdc vscode connect -m my-server -r my-appecho "Hello from production" > index.htmlNüüd hargitagete.
Hargitamine
rdc repo fork --parent my-app -m <machine-name> --tag experiment --upÜks käsk kloonib kogu repo: rakenduse, andmebaasi ja konfiguratsioonifailid. Fork'i aeg on konstantne sõltumata repo suurusest, olgu see üks gigabait, sada gigabaiti või üks terabait.
Üks käsk. See kloonis kõike (rakendus, andmebaas, konfiguratsioonifailid) ja see toimus sekundites. Käivitage uuesti ja saate veel ühe sõltumatu kloon.
Miks on see nii kiire?
Põhjuseks on btrfs reflinks. Fork loob uue failisüsteemi puu, mis osutab samadele andmeplokidele kui ema hoidla. Forkimise ajal ei kopeerita ühtegi andmeid. Selleks on vaid metaandmed, seega ei mõjuta ema suurus forkimise kestust.
Hargitamine toimib samal viisil. 1 GB, 100 GB, 1 TB. Alati sama kestus.
Mis on jagatud, mis on sinu
Kujutage ette, et ema hoidla on fikseeritud allikas. Teie fork on selle copy-on-write vaade. Kirjutage forki ja kirjutised jäävad forki. Ema ei liigu, olenemata sellest, kui palju forke sellele osutavad.
Sa ei saa päikest kinni pidada, kuid sa saad seda peegli abil kinni pidada.
Mis juhtub, kui ema muutub hiljem?
Nüüd mõelge piltkillust. Kui te hargigate, jääditate ema täpselt sellele hetkele. Ema jätkab liikumist. Teie fork ei liigu.
Kui ema hoidla hiljem muutub, teie fork jääb sinna, kus ta oli.
Te ei saa jõge kinni pidada, kuid te saate seda fotoga kinni pidada.
Kettakasutus jääb tasaseks
Sel põhjusel teie ketas ei plahvaata. Viis 100 GB hoidla forki? Kokku veel umbes 100 GB. Te maksate kettale ainult selle eest, mida te igas forkis muudate.
Hargi viis korda, kui soovid. Teie ketas ei märka seda isegi.
Mida forkid EI saa: saladused
On üks asi, mida fork tahtlikult ei järgi: saladused. Fork algab ilma API võtmete, andmebaasi paroolideta, Stripe’ tokenideta. Sel põhjusel tegelikult toimib “kloonige tootmine, ärge rikuge midagi”. Teie liivakast ei saa päris kliente arveldada, sest see ei saa väärata olevat te. Me seisime seda õigesti üles Saladuste haldamise õpetuses.
Isolatsiooni kontrollimine
Loetlege mõlemad hoidlad kõrvuti:
rdc repo list -m <machine-name>Mõlemad repos asuvad nüüd samal masinal ja kettal kahe täiesti sõltumatu keskkonnana.
Näete my-app ja my-app:experiment töötavat korraga. Originaalis asub märkerfail täpselt seal, kus te selle jätsite:
rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'Kontrollige isolatsiooni, uurides algset repo: markerfail on endiselt oma kohal. Ülemrepo jääb fork'i loomisel muutmata.
Nüüd tehke hävitav muudatus, kuid ainult forkis:
rdc term connect -m <machine-name> --repository my-app:experiment --command 'rm index.html && echo removed'Kustutage markerfail ainult fork'i sees. See on hävitav muutus, mis piirdub fork'iga.
Hüppake tagasi originaalile ja kontrollige:
rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'Lülitage tagasi algse repo juurde: markerfail on endiselt puutumata. Ülemrepo ja fork jagavad sama pilti, kuid töötavad eraldi Docker daemonidel ja eraldi failisüsteemidel.
Märkerfail on siin veel, puutumata. Forgi muudatused jäid forki. Samad pildid, eraldi Docker juhatajad, eraldi failisüsteemid.
Puhastamine
Kui olete valmis, kustutage lihtsalt fork:
rdc repo delete --name my-app:experiment -m <machine-name>Kustutage fork, kui olete lõpetanud. Algne repo jääb mõjutamata, võimaldades turvalist fork, katse ja kõrvaldamise töövoogu.
Original jääb täpselt nii, nagu ta oli. Hargi, katsetage, rikuge asju, kustutage. Ilma riskita.
Järgmine: Forgi isoleerimine praktikas.