Vi nun povas konstrui Docker-bildojn en werf uzante regulan Dockerfile

Pli bone malfrue ol neniam. Aŭ kiel ni preskaŭ faris gravan eraron ne havante subtenon por regulaj Dockerfiles por konstrui aplikajn bildojn.

Ni parolos pri werf — GitOps-ilaĵo, kiu integriĝas kun iu ajn CI/KD-sistemo kaj disponigas administradon de la tuta aplikaĵa vivociklo, permesante:

• kolekti kaj publikigi bildojn,
• deploji aplikaĵojn en Kubernetes,
• forigu neuzatajn bildojn uzante specialajn politikojn.

La filozofio de la projekto estas kolekti malaltnivelajn ilojn en ununuran unuigitan sistemon, kiu donas al DevOps-inĝenieroj kontrolon de aplikoj. Se eble, ekzistantaj iloj (kiel Helm kaj Docker) estu uzataj. Se ne ekzistas solvo al problemo, ni povas krei kaj subteni ĉion necesan por ĉi tio.

Fono: via propra bildkolektanto

Jen kio okazis kun la bildkolektilo en werf: la kutima Dockerfile ne sufiĉis al ni. Se vi rapide rigardas la historion de la projekto, ĉi tiu problemo aperis jam en la unuaj versioj de werf (tiam ankoraŭ konata kiel dapp).

Kreante ilon por konstrui aplikojn en Docker-bildojn, ni rapide rimarkis, ke Dockerfile ne taŭgas por ni por iuj tre specifaj taskoj:

1. La bezono konstrui tipajn malgrandajn TTT-aplikaĵojn laŭ la sekva norma skemo:
   • instali tutsistemajn aplikaĵajn dependecojn,
   • instali aron da aplikaĵaj dependecaj bibliotekoj,
   • kolekti aktivaĵojn,
   • kaj plej grave, ĝisdatigi la kodon en la bildo rapide kaj efike.
2. Kiam ŝanĝoj estas faritaj al projektdosieroj, la konstruanto devas rapide krei novan tavolon aplikante diakilon al la ŝanĝitaj dosieroj.
3. Se iuj dosieroj ŝanĝiĝis, tiam necesas rekonstrui la respondan dependan stadion.

Hodiaŭ nia kolektanto havas multajn aliajn eblecojn, sed ĉi tiuj estis la komencaj deziroj kaj instigoj.

Ĝenerale, sen pripensi dufoje, ni armis nin per la programlingvo, kiun ni uzis (Vidu suben) kaj trafis la vojon por efektivigi propra DSL! Konforme al la celoj, oni intencis priskribi la kunigprocezon en etapoj kaj determini la dependecojn de ĉi tiuj etapoj en dosieroj. Kaj kompletigis ĝin propra kolektanto, kiu turnis la DSL en la fina celo - kunmetita bildo. Komence la DSL estis en Ruby, sed kiel transiro al Golang — la agordo de nia kolektanto komencis esti priskribita en YAML-dosiero.

Malnova agordo por dapp en Ruby

Nuna agordo por werf sur YAML

La mekanismo de la kolektanto ankaŭ ŝanĝiĝis kun la tempo. Komence, ni simple generis provizoran Dockerfile sur la flugo de nia agordo, kaj tiam ni komencis ruli kunig instrukciojn en provizoraj ujoj kaj fari.

NB: Nuntempe nia kolektanto, kiu funkcias per sia propra agordo (en YAML) kaj nomiĝas Stapel-kolektilo, jam evoluis al sufiĉe potenca ilo. Ĝia detala priskribo meritas apartajn artikolojn, kaj bazaj detaloj troviĝas en dokumentado.

Konscio pri la problemo

Sed ni konstatis, kaj ne tuj, ke ni faris unu eraron: ni ne aldonis la kapablon konstrui bildojn per norma Dockerfile kaj integru ilin en la saman fin-al-finan aplikaĵan administradinfrastrukturon (t.e. kolektu bildojn, deploji kaj purigi ilin). Kiel povus ebli fari ilon por deplojo en Kubernetes kaj ne efektivigi Dockerfile-subtenon, t.e. norma maniero priskribi bildojn por plej multaj projektoj?...

Anstataŭ respondi ĉi tiun demandon, ni proponas solvon. Kio se vi jam havas Dockerfile (aŭ aron de Dockerfiles) kaj volas uzi werf?

NB: Cetere, kial vi eĉ volus uzi werf? La ĉefaj trajtoj estas la jenaj:

• plena aplika administradciklo inkluzive de bilda purigado;
• la kapablo administri la kunigon de pluraj bildoj samtempe de ununura agordo;
• Plibonigita deploja procezo por Helm-kongruaj leteroj.

Pli kompleta listo de ili troveblas ĉe projekto paĝo.

Do, se pli frue ni proponus reverki la Dockerfile en nia agordo, nun ni ĝoje diros: "Lasu werf konstrui viajn Dockerfile!"

Kiel uzi?

La plena efektivigo de ĉi tiu funkcio aperis en la eldono werf v1.0.3-beta.1. La ĝenerala principo estas simpla: la uzanto specifas la vojon al ekzistanta Dockerfile en la werf-agordo, kaj poste rulas la komandon. werf build... kaj jen ĝi - werf kunvenos la bildon. Ni rigardu abstraktan ekzemplon.

Ni anoncu la sekvan Dockerfile en la projekta radiko:

FROM ubuntu:18.04
RUN echo Building ...

Kaj ni anoncos werf.yamlkiu uzas ĉi tion Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Ĉiuj! Maldekstre kuri werf build:

Krome, vi povas deklari la jenon werf.yaml konstrui plurajn bildojn de malsamaj Dockerfiles samtempe:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Fine, ĝi ankaŭ subtenas pasi pliajn konstruajn parametrojn, kiel ekzemple --build-arg и --add-host - per werf-agordo. Kompleta priskribo de la bilda agordo de Dockerfile estas havebla ĉe dokumenta paĝo.

Kiel ĝi funkcias?

Dum la konstruprocezo, la norma kaŝmemoro de lokaj tavoloj en Docker funkcias. Tamen, kio gravas ankaŭ tiu werf integras Dockerfile-agordon en ĝian infrastrukturon. Kion ĉi tio signifas?

1. Ĉiu bildo konstruita el Dockerfile konsistas el unu etapo nomita dockerfile (Vi povas legi pli pri kiuj stadioj estas en werf tie).
2. Por scenejo dockerfile werf kalkulas subskribon kiu dependas de la enhavo de la agordo Dockerfile. Kiam la agordo de Dockerfile ŝanĝiĝas, la sceneja subskribo ŝanĝiĝas dockerfile kaj werf iniciatas rekonstruon de ĉi tiu etapo kun nova agordo de Dockerfile. Se la subskribo ne ŝanĝiĝas, tiam werf prenas la bildon el la kaŝmemoro (pli da detaloj pri la uzo de subskriboj en werf estis priskribitaj en ĉi tiu raporto).
3. Poste, la kolektitaj bildoj povas esti publikigitaj per la komando werf publish (aŭ werf build-and-publish) kaj uzu ĝin por deplojo al Kubernetes. Eldonitaj bildoj al la Docker-Registro estos purigitaj per normaj werf-purigaj iloj, t.e. Malnovaj bildoj (pli aĝaj ol N tagoj), bildoj asociitaj kun neekzistantaj Git-filioj kaj aliaj politikoj estos aŭtomate purigitaj.

Pli da detaloj pri la punktoj priskribitaj ĉi tie troveblas en la dokumentado:

• Eldonprocezo;
• Integriĝo kun la procezo de deplojo de Kubernetes;
• Puriga procezo.

Notoj kaj antaŭzorgoj

1. Ekstera URL ne estas subtenata en ADD

Nuntempe ne estas subtenata uzi eksteran URL en direktivo ADD. Werf ne iniciatos rekonstruon kiam la rimedo ĉe la specifita URL ŝanĝiĝas. Ni planas aldoni ĉi tiun funkcion baldaŭ.

2. Vi ne povas aldoni .git al la bildo

Ĝenerale, aldonante dosierujon .git en la bildo - malbona malbona praktiko kaj jen kial:

1. se .git restas en la fina bildo, ĉi tio malobservas la principojn 12 faktoro-apo: Ĉar la fina bildo devas esti ligita al ununura kommit, ĝi ne devus esti ebla git checkout arbitra komito.
2. .git pliigas la grandecon de la bildo (la deponejo povas esti granda pro tio, ke grandaj dosieroj iam estis aldonitaj al ĝi kaj poste forigitaj). La grandeco de labor-arbo asociita nur kun specifa kommit ne dependos de la historio de operacioj en Git. En ĉi tiu kazo, la aldono kaj posta forigo .git de la fina bildo ne funkcios: la bildo ankoraŭ akiros kroman tavolon - jen kiel funkcias Docker.
3. Docker povas iniciati nenecesan rekonstruon, eĉ se la sama komit estas konstruita, sed de malsamaj labor-arboj. Ekzemple, GitLab kreas apartajn klonitajn dosierujojn en /home/gitlab-runner/builds/HASH/[0-N]/yourproject kiam paralela asembleo estas ebligita. La ekstra remuntado estos pro la fakto ke la dosierujo .git estas malsama en malsamaj klonitaj versioj de la sama deponejo, eĉ se la sama komit estas konstruita.

La lasta punkto ankaŭ havas konsekvencojn kiam oni uzas werf. Werf postulas, ke la konstruita kaŝmemoro ĉeestu dum rulado de kelkaj komandoj (ekz. werf deploy). Kiam ĉi tiuj komandoj funkcias, werf kalkulas scenejajn subskribojn por la bildoj specifitaj en werf.yaml, kaj ili devas esti en la asemblea kaŝmemoro - alie la komando ne povos daŭrigi labori. Se la sceneja subskribo dependas de la enhavo .git, tiam ni ricevas kaŝmemoron, kiu estas malstabila al ŝanĝoj en senrilataj dosieroj, kaj werf ne povos pardoni tian preterrigardon (por pliaj detaloj, vidu dokumentado).

Ĝenerale aldonante nur certajn necesajn dosierojn per la instrukcioj ADD ĉiukaze pliigas la efikecon kaj fidindecon de la skribita Dockerfile, kaj ankaŭ plibonigas la stabilecon de la kaŝmemoro kolektita por tio Dockerfile, al sensignivaj ŝanĝoj en Git.

La rezulto

Nia komenca vojo por verki nian propran konstruilon por specifaj bezonoj estis malfacila, honesta kaj simpla: anstataŭ uzi lambastonojn sur la norma Dockerfile, ni skribis nian solvon kun kutima sintakso. Kaj ĉi tio havis siajn avantaĝojn: la Stapel-kolektanto perfekte plenumas sian taskon.

Tamen, en la procezo de verkado de nia propra konstruanto, ni perdis vidon pri la subteno por ekzistantaj Dockerfiles. Ĉi tiu difekto nun estis riparita, kaj estonte ni planas evoluigi Dockerfile-subtenon kune kun nia kutima Stapel-konstruanto por distribuita kunigo kaj por kunigo uzante Kubernetes (t.e. kunigo sur kuriloj ene de Kubernetes, kiel estas farita en kaniko).

Do, se vi subite havas kelkajn Dockerfiles kuŝantajn ĉirkaŭe... provu werf!

PS Listo de dokumentado pri la temo

• Gvidiloj por rapida komenco;
• agordoj de dockerfile-konstruilo;
• Etapoj aparato en werf;
• Procezo de eldonado de bildoj;
• Integriĝo kun la procezo de deplojo de Kubernetes;
• Puriga procezo;
• Stapel-konstruanto kiel alternativo al Dockerfile.

Legu ankaŭ en nia blogo: "werf - nia ilo por CI / KD en Kubernetes (superrigardo kaj videoraporto)".

fonto: www.habr.com