Megliu tardu chè mai. O cumu avemu quasi fattu un sbagliu seriu per ùn avè micca supportu per Dockerfiles regulare per custruisce l'imaghjini di l'applicazione.
Parlaremu - Utilità GitOps chì si integra cù qualsiasi sistema CI/CD è furnisce a gestione di tuttu u ciclu di vita di l'applicazione, chì permette:
- raccoglie è pubblicà l'imaghjini,
- implementà applicazioni in Kubernetes,
- sguassate l'imaghjini inutilizate usendu pulitiche speciali.
A filusufìa di u prugettu hè di cullà strumenti di livellu bassu in un unicu sistema unificatu chì dà à l'ingegneri DevOps u cuntrollu di l'applicazioni. Sè pussibule, l'utilità esistenti (cum'è Helm è Docker) deve esse usatu. Se ùn ci hè micca suluzione à un prublema, pudemu creà è sustene tuttu ciò chì hè necessariu per questu.
Sfondate: u vostru propiu cullettore d'imaghjini
Hè ciò chì hè accadutu cù u cullettore di l'imaghjini in werf: u solitu Dockerfile ùn era micca abbastanza per noi. Se fate un ochju rapidu à a storia di u prugettu, stu prublema hè apparsu digià in e prime versioni di werf (poi sempre ).
Mentre creava un strumentu per custruisce l'applicazioni in l'imaghjini di Docker, avemu capitu rapidamente chì Dockerfile ùn era micca adattatu per noi per alcuni compiti assai specifichi:
- A necessità di custruisce applicazioni web tipiche petite secondu u schema standard seguente:
- installà dipendenze di l'applicazioni in tuttu u sistema,
- installà un bundle di biblioteche di dipendenza di l'applicazioni,
- raccoglie i beni,
- è più importantemente, aghjurnà u codice in l'imaghjini rapidamente è efficace.
- Quandu i cambiamenti sò fatti à i schedarii di prughjettu, u custruttore deve creà rapidamente una nova capa appliendu un patch à i schedarii cambiati.
- Se certi schedari sò cambiati, allora hè necessariu di ricustruisce u stadiu dipendente currispundente.
Oghje u nostru cullettore hà parechje altre pussibulità, ma questi eranu i desideri iniziali è i urge.
In generale, senza pensà duie volte, avemu armatu cù a lingua di prugrammazione chì avemu usatu (vede sottu) è pigliate a strada per implementà propriu DSL! In cunfurmità cù l'ugettivi, era destinatu à discriva u prucessu di assemblea in tappe è determinà a dependenza di sti tappe nantu à i schedari. È cumplementatu cullezzione propiu, chì hà turnatu u DSL in u scopu finale - una maghjina assemblata. In prima u DSL era in Ruby, ma cum'è - a cunfigurazione di u nostru cullettore hà cuminciatu à esse descrittu in un schedariu YAML.
Vecchia cunfigurazione per dapp in Ruby
Configurazione attuale per werf in YAML
U miccanisimu di u cullettore hà ancu cambiatu cù u tempu. À u principiu, simpricimenti generatu un Dockerfile tempurane nantu à a mosca da a nostra cunfigurazione, è dopu avemu principiatu à eseguisce struzzioni di assemblea in cuntenituri tempuranee è cummit.
NB: À u mumentu, u nostru cullettore, chì travaglia cù a so propria cunfigurazione (in YAML) è hè chjamatu u cullettore Stapel, hà digià sviluppatu in un strumentu abbastanza putente. A so descrizzione dettagliata meriteghja articuli separati, è i dettagli basi ponu esse truvati in .
Cuscenza di u prublema
Ma avemu capitu, è micca subitu, chì avemu fattu un sbagliu: ùn avemu micca aghjustatu a capacità custruite imagine via Dockerfile standard è integrali in a listessa infrastruttura di gestione di l'applicazioni end-to-end (vale à dì cullà l'imaghjini, implementate è pulite). Cumu puderia esse pussibule di fà un strumentu per a implementazione in Kubernetes è micca implementà u supportu Dockerfile, i.e. modu standard per discrive l'imaghjini per a maiò parte di i prughjetti?
Invece di risponde à sta quistione, offremu una suluzione. E se avete digià un Dockerfile (o un set di Dockerfiles) è vulete usà werf?
NB: Per via, perchè vulete ancu aduprà werf ? E caratteristiche principali venenu à i seguenti:
- ciclu cumpletu di gestione di l'applicazioni cumprese a pulizia di l'imaghjini;
- a capacità di gestisce l'assemblea di parechje imagine à una volta da una sola cunfigurazione;
- Prucessu di implementazione migliuratu per i grafici compatibili Helm.
Una lista più cumpleta di elli pò esse truvata à .
Allora, se prima avemu avutu prupostu di riscrive u Dockerfile in a nostra cunfigurazione, ora diceremu felice: "Lasciate werf custruisce i vostri Dockerfiles!"
Cumu usu?
L'implementazione cumpleta di sta funzione apparsu in a liberazione . U principiu generale hè simplice: l'utilizatore specifica u percorsu à un Dockerfile esistente in a cunfigurazione werf, è poi eseguisce u cumandimu. werf build... è questu hè - werf assemblerà l'imaghjini. Fighjemu un esempiu astrattu.
Annunziamu u prossimu Dockerfile in a radica di u prughjettu:
FROM ubuntu:18.04
RUN echo Building ...
È annunceremu werf.yamlchì usa questu Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Tuttu ! Manca corri werf build:
Inoltre, pudete dichjarà i seguenti werf.yaml per custruisce parechje imagine da diversi Dockerfiles à una volta:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Infine, sustene ancu u passaghju di parametri di custruzzione supplementari, cum'è --build-arg и --add-host - via werf config. Una descrizzione cumpleta di a cunfigurazione di l'imaghjini Dockerfile hè dispunibule à .
Cumu viaghja?
Durante u prucessu di creazione, a cache standard di strati lucali in funzioni Docker. Tuttavia, ciò chì hè impurtante hè ancu chì werf integra a cunfigurazione di Dockerfile in a so infrastruttura. Chì significà questu?
- Ogni imagine custruita da un Dockerfile hè custituitu da una tappa chjamata
dockerfile(pudete leghje più nantu à quali tappe sò in werf ). - Per stage
dockerfilewerf calcula una firma chì dipende da u cuntenutu di a cunfigurazione Dockerfile. Quandu a cunfigurazione di Dockerfile cambia, a signatura di scena cambiadockerfileè werf inizia una ricustruzione di sta tappa cù una nova cunfigurazione Dockerfile. Se a firma ùn cambia micca, allora werf piglia l'imaghjini da a cache (più dettagli nantu à l'usu di e firme in werf sò stati descritti in ). - In seguitu, l'imaghjini recullati ponu esse publicati cù u cumandamentu
werf publish(owerf build-and-publish) è l'utilizanu per a distribuzione in Kubernetes. L'imaghjini publicati in u Registru Docker seranu puliti cù l'arnesi di pulizia standard di werf, i.e. L'imaghjini vechji (più vechji di N ghjorni), l'imaghjini assuciati cù rami Git inesistenti, è altre pulitiche seranu pulite automaticamente.
Più dettagli nantu à i punti descritti quì ponu esse truvati in a documentazione:
- ;
- ;
- .
Note è precautions
1. L'URL esternu ùn hè micca supportatu in ADD
Attualmente ùn hè micca supportatu per utilizà un URL esternu in una direttiva ADD. Werf ùn hà micca iniziatu una ricustruzione quandu a risorsa à l'URL specificata cambia. Avemu pensatu à aghjunghje sta funzione prestu.
2. Ùn pudete micca aghjunghje .git à l'imaghjini
In generale, aghjunghje un annuariu .git in l'imaghjini - una mala pratica viciosa è eccu perchè:
- se
.gitferma in l'imaghjini finali, questu viola i principii : Siccomu l'imaghjini finali deve esse ligata à una sola cummissione, ùn deve esse pussibule di fàgit checkoutimpegnu arbitrariu. -
.gitaumenta a dimensione di l'imaghjini (u repository pò esse grande per via di u fattu chì i fugliali grossi sò stati aghjuntu à questu è dopu sguassati). A dimensione di un arbre di travagliu assuciatu solu cù un impegnu specificu ùn dependerà micca di a storia di l'operazioni in Git. In questu casu, l'aghjunzione è l'eliminazione successiva.gitda l'imaghjini finali ùn funzionerà micca: l'imaghjina ancu acquistà una capa extra - questu hè cumu Docker travaglia. - Docker pò inizià una ricustruzzione innecessaria, ancu s'ellu hè custruitu u stessu impegnu, ma da diversi arburi di travagliu. Per esempiu, GitLab crea repertorii clonati separati in
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectquandu l'assemblea parallela hè attivata. A riunione extra serà duvuta à u fattu chì u cartulare.githè diversu in diverse versioni clonate di u stessu repository, ancu s'ellu hè custruitu u listessu cummit.
L'ultimu puntu hà ancu cunsiquenzi quandu si usa werf. Werf richiede chì a cache custruita sia presente durante l'esecuzione di certi cumandamenti (per esempiu. werf deploy). Quandu questi cumandamenti sò eseguiti, werf calculate signature di scena per l'imaghjini specificate in werf.yaml, è devenu esse in a cache di l'assemblea - altrimenti u cumandamentu ùn serà micca capaci di cuntinuà à travaglià. Se a signatura di scena dipende di u cuntenutu .git, allora avemu un cache chì hè inestabile à i cambiamenti in i schedarii irrilevanti, è werf ùn serà micca capaci di pardunà un tali oversight (per più dettagli, vede ).
In generale aghjunghje solu certi schedarii nicissariu attraversu l'istruzzioni ADD in ogni casu aumenta l'efficienza è l'affidabilità di u scrittu Dockerfile, è ancu migliurà a stabilità di u cache cullatu per questu Dockerfile, à cambiamenti irrilevanti in Git.
U risultatu
A nostra strada iniziale per scrive u nostru propiu costruttore per bisogni specifichi era dura, onesta è diretta: invece di utilizà crutches in cima à u Dockerfile standard, avemu scrittu a nostra suluzione cù sintassi persunalizata. E questu hà avutu i so vantaghji: u cullettore Stapel face bè cù u so compitu.
Tuttavia, in u prucessu di scrive u nostru propiu custruttore, avemu persu di vista u supportu per i Dockerfiles esistenti. Stu difettu hè statu riparatu, è in u futuru avemu intenzione di sviluppà u supportu di Dockerfile cù u nostru custruttore Stapel persunalizatu per e custruzzioni distribuite è per e custruzzioni chì utilizanu Kubernetes (vale à dì, custruite nantu à i corridori in Kubernetes, cum'è hè fattu in kaniko).
Allora, se di colpu avete un coppiu di Dockerfiles in giru... pruvà !
PS Lista di documentazioni nantu à u tema
- ;
- ;
- ;
- ;
- ;
- ;
- .
Leghjite puru in u nostru blog: "».
Source: www.habr.com