Dereng ji qet çêtir e. An jî çawa me hema xeletiyek cidî kir ku ji bo avakirina wêneyên serîlêdanê piştgirî nedan Dockerfiles-ên birêkûpêk.
Em ê biaxivin - Karsaziya GitOps ku bi her pergalek CI/CD-ê re yek dike û rêveberiya tevahiya jiyana serîlêdanê peyda dike, ku destûrê dide:
- berhevkirin û weşandina wêneyan,
- sepanan li Kubernetes bicîh bikin,
- wêneyên neyên bikar anîn bi karanîna polîtîkayên taybetî jêbirin.
Felsefeya projeyê komkirina amûrên nizm di pergalek yekbûyî de ye ku ji endezyarên DevOps re li ser sepanan kontrol dike. Ger gengaz be, pêdivî ye ku karûbarên heyî (mîna Helm û Docker) werin bikar anîn. Ger pirsgirêkek çareser nebe, em dikarin ji bo vê yekê her tiştê hewce çêbikin û piştgirî bikin.
Paş: berhevkarê wêneya xweya xwe
Tiştê ku bi berhevkarê wêneyê di werfê de qewimî ev e: Dockerfile ya asayî ji me re ne bes bû. Ger hûn bi lez li dîroka projeyê binêrin, ev pirsgirêk jixwe di guhertoyên yekem ên werf de xuya bû (wê hingê hîn ).
Dema ku amûrek ji bo avakirina sepanan di nav wêneyên Docker de diafirand, me zû fêm kir ku Dockerfile ji bo hin karên pir taybetî ji me re ne maqûl e:
- Pêdivî ye ku li gorî nexşeya standard a jêrîn serîlêdanên malperê yên piçûk ên tîpîk ava bikin:
- girêdanên serîlêdanê yên li seranserê pergalê saz bikin,
- komek pirtûkxaneyên pêwendiya serîlêdanê saz bikin,
- berhevkirina hebûnên,
- û ya herî girîng, koda di wêneyê de zû û bi bandor nûve bikin.
- Dema ku guhertin di pelên projeyê de têne çêkirin, çêker pêdivî ye ku zû bi sepandina patchek li pelên guhertî qatek nû biafirîne.
- Ger hin pelan hatine guhertin, wê hingê pêdivî ye ku qonaxa girêdayî têkildar ji nû ve were avakirin.
Îro kolektorê me gelek îmkanên din hene, lê ev daxwaz û daxwazên destpêkê bûn.
Bi gelemperî, bêyî ku du caran bifikirin, me xwe bi zimanê bernamesaziyê ku me bikar anî, çekdar kir (li jêr binêre) û ketin rê ji bo pêkanîna xwe DSL! Li gorî armancan hate xwestin ku pêvajoya meclîsê bi qonaxan were vegotin û girêdayîbûna van qonaxan bi dosyayan re were destnîşankirin. Û temam kir berhevkarê xwe, ku DSL veguherand armanca dawîn - wêneyek komkirî. Di destpêkê de DSL li Ruby bû, lê wekî - veavakirina berhevkarê me di pelek YAML de dest pê kir ku were vegotin.
Veavakirina kevn ji bo dapp di Ruby de
Veavakirina heyî ji bo werf li ser YAML
Mekanîzmaya koleksiyonê jî bi demê re guherî. Di destpêkê de, me bi tenê ji veavakirina xwe Dockerfileyek demkî di firînê de hilberand, û dûv re me dest bi meşandina rêwerzên meclîsê di konteynerên demkî de kir û kir.
NB: Heya nuha, berhevkarê me, ku bi konfigurasyona xwe (li YAML) dixebite û jê re kolektorê Stapel tê gotin, jixwe di nav amûrek pir bi hêz de pêşketiye. Danasîna wê ya berfireh hêjayî gotarên cihê ye, û hûrguliyên bingehîn dikarin tê de werin dîtin .
Hişmendiya pirsgirêkê
Lê me fehm kir, û ne tavilê, ku me xeletiyek kir: me jêhatî zêde nekir wêneyan bi Dockerfile standard ava bikin û wan di heman binesaziya rêveberiya serîlêdanê ya dawî-bi-dawî de yek bikin (ango berhevkirina wêneyan, danîn û paqijkirina wan). Çawa dibe ku meriv amûrek ji bo bicîhkirinê li Kubernetes çêbike û piştgiriya Dockerfile bicîh neke, ango. awayê standard ji bo danasîna wêneyan ji bo pir projeyan?..
Li şûna ku em bersiva vê pirsê bidin, em çareseriyê pêşkêş dikin. Ger we berê xwedan Dockerfile (an komek Dockerfiles) hebe û hûn bixwazin werf bikar bînin?
NB: Werhasil, çima hûn dixwazin werf bikar bînin? Taybetmendiyên sereke yên jêrîn têne:
- çerxa rêveberiya serîlêdanê ya tevahî tevî paqijkirina wêneyê;
- şiyana birêvebirina kombûna çend wêneyan bi yekcarî ji yek mîhengê;
- Ji bo nexşeyên Helm-lihevhatî pêvajoya bicîhkirinê ya çêtir.
Navnîşek bêkêmasî ya wan dikare li vir were dîtin .
Ji ber vê yekê, heke berê me pêşkêşî ji nû ve nivîsandina Dockerfile di mîhengê xwe de bikira, naha em ê bi kêfxweşî bibêjin: "Bila werf Dockerfilesên xwe ava bike!"
Çawa bikar bînin?
Tevahiya pêkanîna vê taybetmendiyê di berdanê de xuya bû . Prensîba gelemperî hêsan e: bikarhêner di veavakirina werf de riya Dockerfile-ya heyî diyar dike, û dûv re fermanê dimeşîne. werf build... û ew e - werf dê wêneyê bicivîne. Ka em li mînakek razber binêrin.
Ka em ya din ragihînin Dockerfile di koka projeyê de:
FROM ubuntu:18.04
RUN echo Building ...
Û em ê ragihînin werf.yamlku vê bikar tîne Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Gişt! Çep rev werf build:
Digel vê yekê, hûn dikarin jêrîn ragihînin werf.yaml ji bo avakirina çend wêneyan ji Dockerfilesên cûda yekcar:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Di dawiyê de, ew di heman demê de derbaskirina pîvanên avahîsaziyê yên din jî piştgirî dike, wek mînak --build-arg и --add-host - bi rêya konfigurasyona werf. Danasînek bêkêmasî ya veavakirina wêneya Dockerfile li vir heye .
Çawa dixebite?
Di dema pêvajoya çêkirinê de, cache standard a qatên herêmî di fonksiyonên Docker de. Lêbelê, ya girîng ew e ku werf jî veavakirina Dockerfile di binesaziya xwe de yek dike. Ev tê çi wateyê?
- Her wêneyek ku ji Dockerfile hatî çêkirin ji qonaxek ku jê re tê gotin pêk tê
dockerfile(hûn dikarin bêtir bixwînin ka çi qonax di werfê de ne ). - Ji bo qonaxa
dockerfilewerf îmzeyek ku bi naveroka veavakirina Dockerfile ve girêdayî ye hesab dike. Dema ku veavakirina Dockerfile diguhere, îmzeya qonaxê diguheredockerfileû werf bi mîhengek nû ya Dockerfile ve avakirina vê qonaxê dest pê dike. Ger îmze neguhere, wê demê werf wêneyê ji kaşê digire (Zêdetir hûrguliyên li ser bikaranîna îmzeyan di werfê de hatine vegotin ). - Dûv re, wêneyên berhevkirî dikarin bi fermanê werin weşandin
werf publish(an jîwerf build-and-publish) û wê ji bo bicihkirina Kubernetes bikar bînin. Wêneyên hatine weşandin li Docker Registry dê bi karanîna amûrên paqijkirina werf standard werin paqij kirin, ango. Wêneyên kevn (ji N rojan kevntir), wêneyên ku bi şaxên Git-ê yên neheyî ve girêdayî ne, û polîtîkayên din dê bixweber werin paqij kirin.
Zêdetir hûrgulî di derbarê xalên ku li vir têne diyar kirin dikarin di belgeyê de werin dîtin:
- ;
- ;
- .
Têbînî û tedbîr
1. URL-ya derve di ADD de nayê piştgirî kirin
Heya nuha ew nayê piştgirî kirin ku meriv URLek derveyî di rêwerzekê de bikar bîne ADD. Werf dê ji nû ve avakirina dest pê neke dema ku çavkanî li URL-ya diyarkirî biguhere. Em plan dikin ku di demek nêzîk de vê taybetmendiyê zêde bikin.
2. Hûn nikarin .git li wêneyê zêde bikin
Bi gelemperî, pelrêçek lê zêde bike .git di wêneyê de - pratîkek xirab a xirab û li vir çima ye:
- ger
.gitdi wêneya dawî de dimîne, ev prensîban binpê dike : Ji ber ku wêneya paşîn divê bi yek commit ve were girêdan, nabe ku ew were kiringit checkoutcommit keyfî. -
.gitmezinahiya wêneyê zêde dike (depo dikare mezin be ji ber vê yekê ku pelên mezin carekê li wê hatine zêdekirin û dûv re jêbirin). Mezinahiya dara xebatê ya ku tenê bi peywirek taybetî ve girêdayî ye dê bi dîroka operasyonên li Git ve girêdayî nebe. Di vê rewşê de, zêdekirin û paşê jêbirin.gitji wêneya paşîn dê nexebite: Wêne hîn jî qateyek zêde werdigire - bi vî rengî Docker dixebite. - Docker dikare nûavakirinek nepêwist bide destpêkirin, hetta ku heman peywir tê çêkirin, lê ji darên xebatê yên cûda. Mînakî, GitLab pelrêçiyên klonkirî yên cihê diafirîne
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectdema ku kombûna paralel çalak e. Veavakirina zêde dê ji ber vê rastiyê be ku pelrêça.gitdi guhertoyên cihêreng ên klonkirî yên heman depoyê de cûda ye, her çend heman commit were çêkirin.
Di dema bikaranîna werfê de xala dawî jî encamên wê hene. Werf hewce dike ku cache-ya çêkirî dema ku hin fermanan dimeşîne hebe (mînak. werf deploy). Dema ku ev ferman dimeşin, werf ji bo wêneyên ku tê de hatine destnîşan kirin îmzeyên qonaxê hesab dike werf.yaml, û divê ew di cache civînê de bin - wekî din ferman dê nikaribe xebata xwe bidomîne. Ger îmzeya qonaxê bi naverokê ve girêdayî ye .git, wê hingê em cacheyek werdigirin ku ji guheztinên pelên negirêdayî ne aram e, û werf dê nikaribe çavdêriyek weha efû bike (ji bo bêtir agahdarî, binêre ).
Bi giştî tenê hin pelên pêwîst lê zêde bike bi rêya talîmatan ADD di her halî de karîgerî û pêbaweriya nivîsê zêde dike Dockerfile, û di heman demê de aramiya cache ya ku ji bo vê hatî berhev kirin jî baştir dike Dockerfile, ji bo guhertinên negirêdayî yên Git.
Encam
Rêya meya destpêkê ya nivîsandina avakerê xwe ji bo hewcedariyên taybetî dijwar, rast û rasterast bû: li şûna ku em li ser Dockerfile standard qiloç bikar bînin, me çareseriya xwe bi hevoksaziya xwerû nivîsand. Û ev avantajên wê hebûn: kolektorê Stapel bi karê xwe re bi rengek bêkêmasî radibe.
Lêbelê, di pêvajoya nivîsandina avakerê xwe de, me piştgiriya Dockerfiles-a heyî winda kir. Ev xeletî naha hatî rast kirin, û di pêşerojê de em plan dikin ku piştgirîya Dockerfile digel avakerê xweya Stapel-ê ya xwerû ji bo avahîyên belavkirî û ji bo avahîyên ku Kubernetes bikar tînin pêşve bixin (ango avahîyên li ser bezê di hundurê Kubernetes de, wekî ku di kaniko de tê kirin).
Ji ber vê yekê, heke we ji nişka ve çend Dockerfiles li dora we derewan kirin ... biceribîne !
PS Lîsteya belgeyên li ser mijarê
- ;
- ;
- ;
- ;
- ;
- ;
- .
Di bloga me de jî bixwînin: "".
Source: www.habr.com