BÀttre sent Àn aldrig. Eller hur vi nÀstan gjorde ett allvarligt misstag genom att inte ha stöd för vanliga Dockerfiles för att bygga applikationsbilder.
Det handlar om â GitOps-verktyget som integreras med alla CI/CD-system och möjliggör hantering av hela applikationens livscykel, vilket gör det möjligt att:
- samla och publicera bilder,
- distribuera applikationer i Kubernetes,
- ta bort oanvÀnda bilder med hjÀlp av speciella policyer.
Projektets filosofi Àr att samla lÄgnivÄverktyg i ett enhetligt system som ger DevOps-ingenjörer kontroll över applikationer. Befintliga verktyg (som Helm och Docker) ska anvÀndas i största möjliga mÄn. Om det inte finns nÄgra lösningar för ett visst problem kan vi skapa och underhÄlla allt som behövs för detta.
Bakgrund: vÄr bildsamlar
SÄ hÀnde det sig med bildsamlaren i werf: den vanliga Dockerfile saknades. Om vi blickar tillbaka pÄ projektets historia framtrÀdde detta problem redan i de första versionerna av werf (dÄ Ànnu ).
NÀr vi skapade ett verktyg för att bygga applikationer till Docker-bilder insÄg vi snabbt att Dockerfile inte passade för vissa specifika uppgifter:
- Behovet av att samla typiska smÄ webbapplikationer enligt följande standardmönster:
- installera systemberoenden för applikationen,
- installera en bundle av applikationens beroendebibliotek,
- samla tillgÄngar,
- och viktigast av allt â snabbt och effektivt uppdatera koden i bilden.
- Vid Àndringar i projektfilerna ska samlaren snabbt skapa ett nytt lager genom att applicera en patch pÄ de Àndrade filerna.
- Om vissa specifika filer Àndras mÄste den motsvarande beroende etappen byggas om.
I dagslÀget har vi mÄnga andra funktioner i vÄr samlare, men de ursprungliga önskemÄlen och impulserna sÄg ut sÄ hÀr.
Kort sagt, utan att tveka bevĂ€pnade vi oss med det anvĂ€nda programsprĂ„ket (se nedan) och gav oss ut för att implementera vĂ„rt eget DSL! För att uppfylla de stĂ€llda mĂ„len var det avsett att beskriva byggprocessen i steg och definiera beroenden mellan dessa steg och filer. Och det kompletterades av vĂ„r egen samlare, som omvandlade DSL till det slutgiltiga mĂ„let â den byggda bilden. Först var DSL pĂ„ Ruby, men med tiden â vĂ„r samlare har nu sin konfiguration beskrivna i en YAML-fil.
Den gamla konfigurationen för dapp pÄ Ruby
Den aktuella konfigurationen för werf i YAML
Arbetsmekanismen för samlaren har ocksÄ förÀndrats över tid. Först genererade vi helt enkelt en tillfÀllig Dockerfile frÄn vÄr konfiguration, och senare började vi köra bygginstruktioner i tillfÀlliga containrar och göra commit.
NB: För nÀrvarande har vÄr samlare, som arbetar med sin egen konfiguration (i YAML) och kallas Stapel-samlare, redan utvecklats till ett ganska kraftfullt verktyg. Dess utförliga beskrivning förtjÀnar separata artiklar, och de viktigaste detaljerna kan du ta reda pÄ frÄn .
Medvetenheten om problemet
Men vi insÄg, dock inte omedelbart, att vi hade gjort ett misstag: vi lade inte till möjligheten att bygga bilder via standard-Dockerfile och integrera dem i samma infrastruktur för applikationshantering (d.v.s. bygga bilder, deploya och rensa dem). Hur kunde vi skapa ett verktyg för deployment i Kubernetes och inte implementera stöd för Dockerfile, det vill sÀga det standardiserade sÀttet att beskriva bilder för de flesta projekt?..
IstÀllet för att svara pÄ en sÄdan frÄga erbjuder vi dess lösning. Vad ska man göra om du redan har en Dockerfile (eller en uppsÀttning Dockerfile:ar) och vill anvÀnda werf?
NB: För övrigt, varför skulle ni ens vilja anvÀnda werf? De viktigaste funktionerna kan sammanfattas enligt följande:
- fullstÀndig cykel för applikationshantering inklusive rensning av bilder;
- möjlighet att hantera byggandet av flera bilder frÄn en enda konfiguration;
- förbÀttrad deployment-process för chart som Àr kompatibla med Helm.
För en mer komplett lista kan du se pÄ .
SÄ om vi tidigare skulle föreslÄ att skriva om Dockerfile pÄ vÄr konfiguration, sÄ sÀger vi nu gÀrna: "LÄt werf bygga dina Dockerfiles!"
Hur man anvÀnder?
Den fullstĂ€ndiga implementeringen av denna möjlighet kom i release . Den allmĂ€nna principen Ă€r enkel: anvĂ€ndaren anger sökvĂ€gen till den befintliga Dockerfile i werf-konfigurationen, varefter de kör kommandot werf build⊠och allt â werf kommer att bygga bilden. LĂ„t oss titta pĂ„ ett abstrakt exempel.
Skriv följande Dockerfile i projektets rot:
FROM ubuntu:18.04
RUN echo Bygger ... Och skriv werf.yaml, som anvÀnder denna Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: .\/Dockerfile Det Àr allt! Det ÄterstÄr , men den processen gick inte sÄ smidigt som deras grundare skulle önska. werf build:
Dessutom kan du skriv nÀsta werf.yaml för att bygga flera bilder frÄn olika Dockerfile:ar:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: .\/dockerfiles\/Dockerfile-backend
---
image: frontend
dockerfile: .\/dockerfiles\/Dockerfile-frontend Ăntligen stöds Ă€ven överföring av ytterligare byggparametrar â sĂ„som --build-arg och --add-host â via werf-konfigurationen. En fullstĂ€ndig beskrivning av Dockerfile-bildens konfiguration finns pĂ„ .
Hur fungerar det?
Under byggprocessen fungerar den standardiserade cachen för lokala lager i Docker. Men det Àr viktigt att notera att werf ocksÄ integrerar Dockerfile-konfigurationen i sin infrastruktur. Vad innebÀr detta?
- Varje bild som byggs frÄn en Dockerfile bestÄr av en stage som kallas
dockerfile(mer information om vad stages Ă€r i werf kan lĂ€sas ). - För stageân
dockerfileberÀknar werf en signatur som beror pÄ innehÄllet i Dockerfile-konfigurationen. Vid Àndring av Dockerfile-konfigurationen förÀndras signaturen för stadietdockerfileoch werf initierar ombyggnad av detta stadium med den nya Dockerfile-konfigurationen. Om signaturen inte Àndras, tar werf bilden frÄn cachen (mer om anvÀndning av signaturer i werf har diskuterats i ). - DÀrefter kan de byggda bilderna publiceras med kommandot
werf publish(ellerwerf build-and-publish) och anvÀndas för deployment i Kubernetes. Publicerade bilder i Docker Registry kommer att rensas med standardrengöringsverktyg frÄn werf, vilket innebÀr att gamla bilder (Àldre Àn N dagar), bilder relaterade till icke-existerande Git-grenar, och enligt andra policyer kommer att rensas automatiskt.
Mer om dessa hÀr beskrivna punkter kan hittas i dokumentationen:
- ;
- ;
- .
Kommentarer och försiktighetsÄtgÀrder
1. Extern URL i ADD stöds inte
För nÀrvarande stöds inte anvÀndningen av extern URL i direktivet ADD. Werf kommer inte att initiera ombyggnad vid förÀndring av resursen enligt den angivna URL:en. Snart planeras det att lÀgga till denna funktion.
2. Det gÄr inte att lÀgga till .git i bilden
Generellt sett Àr det en dÄlig praxis att lÀgga till katalogen .git i bilden och hÀr Àr varför:
- Om
.gitden förblir i den slutliga bilden, strider det mot principerna för : eftersom den slutliga bilden ska vara kopplad till en enda commit, bör det inte finnas nÄgot sÀtt att göragit checkoutav en godtycklig commit. -
.gitökar storleken pĂ„ bilden (arkivet kan vara stort om stora filer har lagts till och sedan raderats). Storleken pĂ„ work-tree, som endast Ă€r kopplad till ett specifikt commit, kommer inte att pĂ„verkas av historiken för operationer i Git. Att lĂ€gga till och sedan ta bort.gitfrĂ„n den slutliga bilden kommer inte att fungera: bilden kommer Ă€ndĂ„ att fĂ„ ett extra lager â sĂ„ fungerar Docker. - Docker kan initiera onödig ombyggnation, Ă€ven om det handlar om att bygga samma commit, men frĂ„n olika work-trees. Till exempel, GitLab skapar separata klonade kataloger i
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectmed parallellbyggnation aktiverad. Den onödiga ombyggnationen kommer att bero pÄ att katalogen.gitskiljer sig i olika klonade versioner av samma arkiv, Àven om samma commit byggs.
Den senaste punkten har konsekvenser Ă€ven vid anvĂ€ndning av werf. Werf krĂ€ver att den byggda cachen finns nĂ€r vissa kommandon körs (till exempel, werf deploy). Under körningen av dessa kommandon berĂ€knar werf signaturerna för stadierna för bilderna som anges i werf.yaml, och de mĂ„ste finnas i byggcachen â annars kan kommandot inte fortsĂ€tta. Om signaturen för stadierna beror pĂ„ innehĂ„llet .git, fĂ„r vi en instabil cache som Ă€r kĂ€nslig för Ă€ndringar i irrelevanta filer, och werf kan inte förlĂ„ta ett sĂ„dant misstag (mer information finns i ).
Generellt ökar tillÀgget av endast nödvÀndiga filer genom instruktionen ADD i vilket fall som helst effektiviteten och tillförlitligheten av det skrivna Dockerfile, samt förbÀttrar cachen som byggts av detta Dockerfile, mot irrelevanta Àndringar i Git.
Resultat
VÄr ursprungliga vÀg med att skriva vÄr egen byggare för specifika behov var tuff, Àrlig och rak: istÀllet för att anvÀnda provisoriska lösningar ovanpÄ standard Dockerfile skrev vi vÄr egen lösning med ett anpassat syntax. Och det gav sina fördelar: Stapel-byggaren fungerar utmÀrkt för sitt syfte.
Men under skrivandet av vÄr egen byggare missade vi stödet för redan existerande Dockerfiles. Denna brist har nu ÄtgÀrdats, och i framtiden planerar vi att utveckla stödet för Dockerfiles parallellt med vÄr anpassade Stapel-byggare för distribuerad byggnation och för byggning med hjÀlp av Kubernetes (dvs. byggande pÄ runners inom Kubernetes, som det görs med kaniko).
SÄ om du har nÄgra Dockerfile-liknande liggande⊠försök !
P.S. Lista med dokumentation i Àmnet
- ;
- ;
- ;
- ;
- ;
- ;
- .
LÀs ocksÄ pÄ vÄr blogg: «».
KĂ€lla: habr.com
