Ang pag-tag nga nakabase sa sulud sa werf builder: ngano ug giunsa kini paglihok?

werf mao ang among open source GitOps CLI utility para sa pagtukod ug paghatud sa mga aplikasyon sa Kubernetes. SA buhian v1.1 usa ka bag-ong bahin ang gipaila sa tigkolekta sa imahe: pag-tag sa mga imahe pinaagi sa sulud o tag-tag nga gibase sa sulod. Hangtud karon, ang kasagaran nga pamaagi sa pag-tag sa werf nag-apil sa pag-tag sa mga imahe sa Docker pinaagi sa Git tag, Git branch o Git commit. Apan kining tanan nga mga laraw adunay mga disbentaha nga hingpit nga nasulbad sa bag-ong estratehiya sa pag-tag. Ang mga detalye bahin niini ug kung ngano nga kini maayo kaayo naa sa ilawom sa pagputol.

Paglunsad og usa ka set sa microservices gikan sa usa ka Git repository

Ang usa ka sitwasyon kasagaran mahitabo kung ang usa ka aplikasyon gibahin sa daghan pa o dili kaayo independente nga mga serbisyo. Ang mga pagpagawas niini nga mga serbisyo mahimong mahitabo nga independente: ang usa o daghan pa nga mga serbisyo mahimong i-release sa usa ka higayon, samtang ang uban kinahanglan magpadayon sa pagtrabaho nga wala’y mga pagbag-o. Apan gikan sa punto sa pagtan-aw sa pagtipig sa code ug pagdumala sa proyekto, mas sayon ​​​​ang pagtipig sa maong mga serbisyo sa aplikasyon sa usa ka repositoryo.

Adunay mga sitwasyon nga ang mga serbisyo tinuod nga independente ug wala'y kalabutan sa usa ka aplikasyon. Sa kini nga kaso, sila mahimutang sa lainlain nga mga proyekto ug ang ilang pagpagawas himuon pinaagi sa lainlaing mga proseso sa CI/CD sa matag usa sa mga proyekto.

Bisan pa, sa tinuud, kanunay nga gibahin sa mga developer ang usa ka aplikasyon sa daghang mga microservice, apan ang paghimo og usa ka bulag nga repository ug proyekto alang sa matag usa ... usa ka tin-aw nga overkill. Kini nga sitwasyon ang hisgutan sa dugang: daghang mga microservice ang nahimutang sa usa ka repository sa proyekto ug ang mga pagpagawas mahitabo pinaagi sa usa ka proseso sa CI/CD.

Pag-tag pinaagi sa Git branch ug Git tag

Ingnon ta nga ang labing kasagaran nga estratehiya sa pag-tag gigamit - tag-o-sanga. Alang sa mga sanga sa Git, ang mga imahe gi-tag sa ngalan sa sanga, alang sa usa ka sanga sa usa ka higayon adunay usa ra nga gipatik nga imahe sa ngalan sa sanga. Alang sa Git tags, ang mga hulagway gi-tag sumala sa tag name.

Kung ang usa ka bag-ong Git tag gihimo-pananglitan, kung ang usa ka bag-ong bersyon gipagawas-usa ka bag-ong tag sa Docker ang himuon para sa tanan nga mga imahe sa proyekto sa Docker Registry:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

Kining bag-ong mga ngalan sa hulagway gipasa pinaagi sa Helm templates ngadto sa Kubernetes configuration. Sa pagsugod sa pag-deploy gamit ang command werf deploy field kay gina-update image sa Kubernetes nga kapanguhaan nagpakita ug gi-restart ang katugbang nga mga kapanguhaan tungod sa giusab nga ngalan sa imahe.

problema: sa kaso kung, sa tinuud, ang mga sulud sa imahe wala mausab sukad sa miaging rollout (Git tag), apan ang Docker tag lamang niini, kini mahitabo dugang pagsugod pag-usab niini nga aplikasyon ug, sumala niana, posible ang pipila ka downtime. Bisan kung wala’y tinuud nga hinungdan nga himuon kini nga pag-restart.

Ingon usa ka sangputanan, sa karon nga laraw sa pag-tag kinahanglan nga koral ang daghang bulag nga mga repositoryo sa Git ug ang problema mitungha sa pag-organisar sa paglansad niining daghang mga repositoryo. Sa kinatibuk-an, ang ingon nga laraw nahimo nga sobra nga gibug-aton ug komplikado. Mas maayo nga maghiusa sa daghang mga serbisyo sa usa ka repository ug maghimo mga tag sa Docker aron wala’y wala kinahanglana nga pag-restart.

Pag-tag pinaagi sa Git commit

Ang werf usab adunay usa ka estratehiya sa pag-tag nga may kalabutan sa Git commits.

Ang Git-commit usa ka identifier alang sa mga sulud sa usa ka Git repository ug nagdepende sa kasaysayan sa pag-edit sa mga file sa Git repository, mao nga ingon og makatarunganon nga gamiton kini alang sa pag-tag sa mga imahe sa Docker Registry.

Bisan pa, ang pag-tag pinaagi sa Git commit adunay parehas nga mga disbentaha sama sa pag-tag sa mga sanga sa Git o mga tag sa Git:

• Ang usa ka walay sulod nga pasalig mahimong mabuhat nga wala magbag-o sa bisan unsang mga file, apan ang tag sa Docker sa imahe mausab.
• Ang usa ka merge commit mahimong mabuhat nga dili mag-usab sa mga file, apan ang Docker tag sa imahe mausab.
• Ang usa ka komit mahimo nga magbag-o sa mga file sa Git nga wala gi-import sa imahe, ug ang tag sa Docker sa imahe mausab pag-usab.

Ang pag-tag sa ngalan sa sanga sa Git wala magpakita sa bersyon sa hulagway

Adunay laing problema nga nalangkit sa estratehiya sa pag-tag alang sa mga sanga sa Git.

Ang pag-tag pinaagi sa ngalan sa sanga molihok basta ang mga commit sa kana nga sanga kolektahon nga sunud-sunod sa kronolohikal nga pagkasunod-sunod.

Kung sa kasamtangan nga laraw ang user magsugod sa pagtukod pag-usab sa usa ka daan nga commit nga may kalabutan sa usa ka sanga, unya ang werf isulat pag-usab ang imahe gamit ang katugbang nga Docker tag nga adunay bag-ong bersyon sa imahe alang sa daan nga commit. Ang mga deployment nga naggamit niini nga tag gikan karon nagpadagan sa peligro sa pagbira sa usa ka lahi nga bersyon sa imahe kung mag-restart ang mga pod, ingon usa ka sangputanan diin ang among aplikasyon mawad-an koneksyon sa sistema sa CI ug ma-desynchronize.

Dugang pa, sa sunud-sunod nga pagduso sa usa ka sanga nga adunay mubu nga panahon sa taliwala nila, ang daan nga commit mahimong matipon sa ulahi kaysa sa bag-o: ang daan nga bersyon sa imahe mag-overwrite sa bag-o gamit ang tag sa sanga sa Git. Ang ingon nga mga problema mahimong masulbad pinaagi sa usa ka sistema sa CI / CD (pananglitan, sa GitLab CI ang pipeline sa ulahi gilunsad alang sa usa ka serye sa mga commit). Bisan pa, dili tanan nga mga sistema nagsuporta niini ug kinahanglan adunay usa ka mas kasaligan nga paagi aron mapugngan ang ingon nga sukaranan nga problema.

Unsa ang content-based tagging?

Mao nga, unsa ang pag-tag nga nakabase sa sulud - pag-tag sa mga imahe pinaagi sa sulud.

Aron makahimo og mga tag sa Docker, dili Git primitives (Git branch, Git tag...) ang gigamit, apan usa ka checksum nga nalangkit sa:

• sulod sa hulagway. Ang image ID tag nagpakita sa sulod niini. Kung magtukod og bag-ong bersyon, kini nga identifier dili mausab kung ang mga file sa imahe wala mausab;
• kasaysayan sa paghimo niini nga imahe sa Git. Ang mga hulagway nga nalangkit sa lain-laing mga sanga sa Git ug lain-laing kasaysayan sa pagtukod pinaagi sa werf adunay lain-laing mga ID tag.

Ang ingon nga tag identifier mao ang gitawag nga pirma sa entablado sa imahe.

Ang matag imahe naglangkob sa usa ka hugpong sa mga yugto: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch ug uban pa. Ang matag yugto adunay usa ka identifier nga nagpakita sa mga sulod niini − pirma sa entablado (pirma sa entablado).

Ang katapusan nga imahe, nga gilangkuban niini nga mga yugto, gi-tag sa gitawag nga pirma sa set sa kini nga mga yugto - yugto nga pirma, - nga mao ang pag-generalize alang sa tanan nga mga yugto sa imahe.

Para sa matag hulagway gikan sa configuration werf.yaml sa kinatibuk-ang kaso, adunay kaugalingon nga pirma ug, sumala niana, usa ka tag sa Docker.

Ang pirma sa entablado nagsulbad sa tanan niini nga mga problema:

• Makasukol sa walay sulod nga Git commits.
• Ang Resistant sa Git nagpasalig nga magbag-o sa mga file nga dili angay sa imahe.
• Dili mosangpot sa problema sa pag-overhauling sa kasamtangan nga bersyon sa hulagway sa dihang i-restart ang pagtukod alang sa daan nga Git commit sa usa ka sanga.

Kini karon ang girekomenda nga estratehiya sa pag-tag ug mao ang default sa werf alang sa tanan nga mga sistema sa CI.

Giunsa pag-enable ug paggamit sa werf

Ang sugo karon adunay katugbang nga kapilian werf publish: --tag-by-stages-signature=true|false

Sa usa ka sistema sa CI, ang estratehiya sa pag-tag gitino sa mando werf ci-env. Kaniadto, ang parameter gihubit alang niini werf ci-env --tagging-strategy=tag-or-branch. Karon, kung imong gitino werf ci-env --tagging-strategy=stages-signature o ayaw ipiho kini nga kapilian, gamiton sa werf ang estratehiya sa pag-tag pinaagi sa default stages-signature. Team werf ci-env awtomatik nga itakda ang gikinahanglan nga mga bandila alang sa mando werf build-and-publish (o werf publish), mao nga walay dugang nga mga kapilian ang kinahanglan nga itakda alang niini nga mga sugo.

Pananglitan, ang sugo:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...makahimo sa mosunod nga mga hulagway:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

kini mao ang 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d usa ka pirma sa mga yugto sa imahe backendug f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - pirma sa mga yugto sa imahe frontend.

Sa diha nga ang paggamit sa espesyal nga mga gimbuhaton werf_container_image и werf_container_env Dili kinahanglan nga usbon ang bisan unsa sa mga template sa Helm: kini nga mga gimbuhaton awtomatiko nga makamugna sa husto nga mga ngalan sa imahe.

Pananglitan nga pagsumpo sa usa ka sistema sa CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Dugang nga impormasyon sa pag-configure anaa sa dokumentasyon:

• Direktoryo → Publikasyon (imantala);
• Pagtrabaho uban sa CI/CD → Kinatibuk-ang impormasyon → yugto-pirma;
• Paghiusa sa GitLab CI/CD → .gitlab-ci.yml.

Total

• Bag-ong kapilian werf publish --tag-by-stages-signature=true|false.
• Bag-ong bili sa opsyon werf ci-env --tagging-strategy=stages-signature|tag-or-branch (kung wala gipiho, ang default mao ang stages-signature).
• Kung gigamit nimo kaniadto ang mga kapilian sa pag-tag alang sa Git commits (WERF_TAG_GIT_COMMIT o kapilian werf publish --tag-git-commit COMMIT), unya siguroha nga mobalhin sa estratehiya sa pag-tag yugto-pirma.
• Mas maayo nga ibalhin dayon ang mga bag-ong proyekto sa bag-ong laraw sa pag-tag.
• Kung nagbalhin sa werf 1.1, gisugyot nga ibalhin ang mga daan nga proyekto sa bag-ong laraw sa pag-tag, apan ang daan tag-o-sanga gisuportahan gihapon.

Ang pag-tag nga nakabase sa sulud nagsulbad sa tanan nga mga problema nga nasakup sa artikulo:

• Ang pagbatok sa ngalan sa tag sa Docker sa walay sulod nga Git commit.
• Ang pagsukol sa ngalan sa tag sa Docker sa Git nagpasalig nga nagbag-o sa mga file nga wala’y kalabotan sa imahe.
• Dili mosangpot sa problema sa pag-overhauling sa kasamtangan nga bersyon sa hulagway sa dihang ang pagsugod pag-usab sa pagtukod alang sa daan nga Git commit alang sa mga sanga sa Git.

Gamita na! Ug ayaw kalimot sa pagbisita kanamo sa GitHubsa paghimo og usa ka isyu o pagpangita sa usa nga anaa na, paghatag og usa ka plus, paghimo sa usa ka PR, o yano nga pagtan-aw sa kalamboan sa proyekto.

PS

Basaha usab sa among blog:

• «werf 1.1 release: mga kalamboan sa magtutukod karon ug mga plano alang sa umaabot»
• «Pagpaila sa werf 1.0 stable: unsa may kalabotan sa GitOps niini, kahimtang ug mga plano»
• «werf - among himan alang sa CI / CD sa Kubernetes (kinatibuk-ang pagtan-aw ug taho sa video)";
• Usa ka serye sa mga nota bahin sa mga inobasyon sa werf:
  • «3-way merge to werf: deployment sa Kubernetes nga adunay Helm "sa mga steroid"";
  • «Ang paggamit sa werf aron ma-roll out ang komplikado nga mga tsart sa Helm";
  • «Suporta alang sa monorepo ug multirepo sa werf ug unsa ang kalabotan sa Docker Registry niini";
  • «Mahimo ka na karon magtukod mga imahe sa Docker sa werf gamit ang usa ka regular nga Dockerfile".

Source: www.habr.com