Besser spéit wéi ni. Oder wéi mir bal e seriéise Feeler gemaach hunn andeems mir keng Ënnerstëtzung fir regelméisseg Dockerfiles hunn fir Applikatiounsbilder ze bauen.
Mir schwätzen iwwer - GitOps Utility déi mat all CI / CD System integréiert a Gestioun vum ganzen Applikatiounsliewenszyklus ubitt, wat erlaabt:
- Biller sammelen a publizéieren,
- Deploy Applikatiounen an Kubernetes,
- läschen onbenotzt Biller mat spezielle Politiken.
D'Philosophie vum Projet ass Low-Level Tools an een eenzegen vereenegt System ze sammelen deen DevOps Ingenieuren Kontroll iwwer Uwendungen gëtt. Wa méiglech, bestehend Utilities (wéi Helm an Docker) solle benotzt ginn. Wann et keng Léisung fir e Problem gëtt, kënne mir alles erstellen an ënnerstëtzen, wat fir dëst néideg ass.
Hannergrond: Ären eegene Bildsammler
Dat ass wat mam Bildsammler zu werf geschitt ass: den üblechen Dockerfile goung eis net duer. Wann Dir e séiere Bléck op d'Geschicht vum Projet kuckt, ass dëse Problem schonn an den éischte Versioune vu werf opgetaucht (dan nach ëmmer ).
Wärend en Tool erstallt fir Uwendungen an Docker Biller ze bauen, hu mir séier gemierkt datt Dockerfile net fir eis fir e puer ganz spezifesch Aufgaben gëeegent war:
- De Besoin fir typesch kleng Webapplikatiounen no dem folgenden Standardschema ze bauen:
- installéieren System-breet Applikatioun Ofhängegkeeten,
- installéiert e Bündel vun Applikatioun Ofhängegkeet Bibliothéiken,
- Verméigen sammelen,
- an am wichtegsten, Update de Code am Bild séier an effizient.
- Wann Ännerunge fir Projetsdateien gemaach ginn, muss de Builder séier eng nei Schicht erstellen andeems Dir e Patch op déi geännert Dateien applizéiert.
- Wa verschidde Dateien geännert hunn, ass et néideg déi entspriechend ofhängeg Etapp opzebauen.
Eise Sammler huet haut nach vill aner Méiglechkeeten, mee dat waren déi éischt Wënsch an Ufuerderungen.
Am Allgemengen, ouni zweemol ze denken, hu mir eis mat der Programméierungssprooch bewaffnet, déi mir benotzt hunn (kuckt ënnen) an op de Wee getraff fir ëmzesetzen eegen DSL! Am Aklang mat den Ziler war et virgesinn de Montageprozess an Etappen ze beschreiwen an d'Ofhängegkeet vun dësen Etappen op Dateien ze bestëmmen. An ergänzt et eegene Sammler, deen den DSL zum Schlussziel ëmgewandelt huet - e versammelt Bild. Am Ufank war den DSL am Rubin, awer als - d'Konfiguratioun vun eisem Sammler huet ugefaang an enger YAML Datei beschriwwe ze ginn.
Al Configuratioun fir Dapp am Ruby
Aktuell Configuratioun fir werf op YAML
De Mechanismus vum Sammler huet och mat der Zäit geännert. Am Ufank hu mir einfach eng temporär Dockerfile op der Flucht vun eiser Konfiguratioun generéiert, an dunn hu mir ugefaang d'Versammlungsinstruktiounen an temporäre Container ze lafen an ze engagéieren.
NB: Am Moment ass eise Sammler, dee mat senger eegener Configuratioun (am YAML) funktionnéiert an de Stapel Sammler genannt gëtt, schonn zu engem zimlech mächtege Tool entwéckelt. Seng detailléiert Beschreiwung verdéngt getrennten Artikelen, a Basisdetailer kënne fonnt ginn .
Bewosstsinn vum Problem
Awer mir hu gemierkt, an net direkt, datt mir ee Feeler gemaach hunn: mir hunn d'Fäegkeet net derbäigesat bauen Biller iwwer Standard Dockerfile an integréieren se an déi selwecht Enn-zu-Enn Applikatioun Gestioun Infrastruktur (dh Biller sammelen, deployéieren a propper se). Wéi kéint et méiglech sinn en Tool fir d'Deployment an Kubernetes ze maachen an net Dockerfile Support ëmzesetzen, d.h. Standard Manéier fir Biller fir déi meescht Projeten ze beschreiwen? ..
Amplaz dës Fro ze beäntweren, bidde mir eng Léisung. Wat wann Dir schonn eng Dockerfile hutt (oder e Set vun Dockerfiles) a wëllt werf benotzen?
NB: Iwwregens, firwat wëllt Dir iwwerhaapt werf benotzen? D'Haaptmerkmale kommen op déi folgend erof:
- voll Applikatioun Gestioun Zyklus dorënner Bild Botzen;
- d'Fäegkeet fir d'Versammlung vu verschiddene Biller gläichzäiteg aus enger eenzeger Konfiguratioun ze managen;
- Verbesserte Deploymentprozess fir Helm-kompatibel Charts.
Eng méi komplett Lëscht vun hinnen kann op fonnt ginn .
Also, wa mir virdru ugebueden hätten d'Dockerfile an eiser Configuratioun ëmzeschreiwen, elo wäerte mir glécklech soen: "Loosst werfen Är Dockerfiles bauen!"
Wéi benotzen?
Déi voll Ëmsetzung vun dëser Feature erschéngt an der Verëffentlechung . Den allgemenge Prinzip ass einfach: de Benotzer spezifizéiert de Wee op eng existent Dockerfile an der Werf Configuratioun, a leeft dann de Kommando werf build... an dat ass et - werf wäert d'Bild zesummestellen. Loosst eis en abstrakt Beispill kucken.
Loosst eis déi nächst annoncéieren Dockerfile am Projet root:
FROM ubuntu:18.04
RUN echo Building ...
A mir wäerten annoncéieren werf.yamldéi dëst benotzt Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Alles! Lénks lafen werf build:
Zousätzlech kënnt Dir déi folgend deklaréieren werf.yaml fir e puer Biller aus verschiddene Dockerfiles gläichzäiteg ze bauen:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Schlussendlech ënnerstëtzt et och weider Build Parameteren, wéi z --build-arg и --add-host - via werf config. Eng komplett Beschreiwung vun der Dockerfile Bildkonfiguratioun ass verfügbar op .
Wéi heescht et schaffen?
Wärend dem Bauprozess funktionnéiert de Standardcache vu lokalen Schichten an Docker. Wat awer wichteg ass, ass och, datt d'werft integréiert Dockerfile Konfiguratioun a seng Infrastruktur. Wat heescht dat?
- All Bild aus engem Dockerfile gebaut besteet aus enger Etapp genannt
dockerfile(Dir kënnt méi liesen iwwer wéi eng Etappe am werf sinn ). - Fir Bühn
dockerfilewerf berechent eng Ënnerschrëft déi vum Inhalt vun der Dockerfile Konfiguratioun hänkt. Wann d'Dockerfile Konfiguratioun ännert, ännert d'Bühnsignaturdockerfilea werf initiéiert eng Neiopbau vun dëser Etapp mat enger neier Dockerfile Config. Wann d'Ënnerschrëft net ännert, da hëlt werf d'Bild aus dem Cache (méi Detailer iwwer d'Benotzung vun den Ënnerschrëften am werf goufen an ). - Als nächst kënnen déi gesammelt Biller mam Kommando publizéiert ginn
werf publish(oderwerf build-and-publish) a benotzt se fir d'Deployment op Kubernetes. Verëffentlecht Biller an den Docker Registry ginn mat Standard werf Cleanup Tools gebotzt, d.h. Al Biller (méi al wéi N Deeg), Biller verbonne mat net existente Git Filialen, an aner Politik ginn automatesch gebotzt.
Méi Detailer iwwer d'Punkten hei beschriwwe ginn an der Dokumentatioun fonnt:
- ;
- ;
- .
Notizen a Virsiichtsmoossnamen
1. Extern URL gëtt net an ADD ënnerstëtzt
De Moment gëtt et net ënnerstëtzt eng extern URL an enger Direktiv ze benotzen ADD. Werf wäert net eng Rekonstruktioun initiéieren wann d'Ressource op der spezifizéierter URL ännert. Mir plangen dës Feature geschwënn ze addéieren.
2. Dir kënnt net .git op d'Bild derbäi
Am allgemengen, e Verzeichnis derbäisetzen .git am Bild - eng béis schlecht Praxis an hei ass firwat:
- wann
.gitbleift am Finale Bild, dëst verstéisst d'Prinzipien : Well d'Finale Bild muss un engem eenzege commit verbonne ginn, et soll net méiglech sinn ze maachengit checkoutarbiträr Verpflichtung. -
.gitvergréissert d'Gréisst vum Bild (de Repository ka grouss sinn wéinst der Tatsaach datt grouss Dateien eemol derbäigesat goufen an duerno geläscht goufen). D'Gréisst vun engem Aarbechtsbaum assoziéiert nëmme mat engem spezifeschen Engagement hänkt net vun der Geschicht vun den Operatiounen am Git of. An dësem Fall, d'Ergänzung a spéider Entfernung.gitvum leschte Bild funktionnéiert net: d'Bild kritt nach ëmmer eng extra Schicht - sou funktionnéiert Docker. - Docker kann en onnéideg Neiopbau initiéieren, och wann deeselwechten Engagement gebaut gëtt, awer aus verschiddene Aarbechtsbeem. Zum Beispill, GitLab erstellt separat gekloont Verzeichnungen an
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectwann parallel Assemblée aktivéiert ass. Déi extra Remontage wäert wéinst der Tatsaach sinn datt de Verzeechnes.gitass anescht a verschiddene gekloonten Versioune vum selwechte Repository, och wann dee selwechte Verpflichtung gebaut ass.
De leschte Punkt huet och Konsequenzen wann Dir werf benotzt. Werf erfuerdert de gebaute Cache fir präsent ze sinn wann Dir e puer Kommandoen leeft (z. werf deploy). Wann dës Kommandoen lafen, berechent werf Etapp Ënnerschrëfte fir d'Biller spezifizéiert an werf.yaml, a si mussen am Assemblée Cache sinn - soss kann de Kommando net weider schaffen. Wann d'Bühn Ënnerschrëft hänkt vum Inhalt of .git, da kréie mir e Cache deen onbestänneg ass fir Ännerungen an irrelevanten Dateien, a werf wäert sou eng Iwwersiicht net verzeien (fir méi Detailer, kuckt ).
Allgemeng derbäi nëmmen bestëmmte néideg Fichieren duerch d'Instruktioune ADD an all Fall vergréissert d'Effizienz an Zouverlässegkeet vun der geschriwen Dockerfile, a verbessert och d'Stabilitéit vum Cache, deen dofir gesammelt gëtt Dockerfile, op irrelevant Ännerungen am Git.
D 'Resultat
Eisen initialen Wee fir eisen eegene Builder fir spezifesch Bedierfnesser ze schreiwen war schwéier, éierlech an einfach: Amplaz vu Krutzen uewen op der Standard Dockerfile ze benotzen, hu mir eis Léisung mat personaliséierter Syntax geschriwwen. An dat hat seng Virdeeler: de Stapel-Sammler këmmert sech perfekt mat senger Aufgab.
Wéi och ëmmer, am Prozess fir eisen eegene Builder ze schreiwen, hu mir d'Ënnerstëtzung fir existent Dockerfiles aus den Ae verluer. Dëse Feeler ass elo fixéiert ginn, an an Zukunft plangen mir Dockerfile Support zesumme mat eisem personaliséierte Stapel Builder fir verdeelt Assemblée a fir Assemblée mat Kubernetes (dh Assemblée op Leefer bannent Kubernetes, wéi et am Kaniko gemaach gëtt).
Also, wann Dir op eemol e puer Dockerfiles ronderëm leien ... probéieren !
PS Lëscht vun Dokumentatioun zum Thema
- ;
- ;
- ;
- ;
- ;
- ;
- .
Liest och an eisem Blog: "".
Source: will.com