O temi monorepozitorija se raspravljalo više puta i po pravilu izaziva vrlo aktivnu debatu. Kreiranje Kao alat otvorenog koda dizajniran da poboljša proces izgradnje koda aplikacije iz Git-a u Docker slike (i zatim isporuku u Kubernetes), ne razmišljamo mnogo o tome koji je izbor najbolji. Za nas je primarno da obezbedimo sve što je potrebno za pristalice različitih mišljenja (ako to nije u suprotnosti sa zdravim razumom, naravno).
Nedavno uvedena podrška za mono-repo u werf-u je dobar primjer za to. Ali prvo, hajde da shvatimo kako je ova podrška općenito povezana s upotrebom werf-a i kakve veze Docker Registry ima s tim...
Problemi
Zamislimo ovu situaciju. Kompanija ima mnogo razvojnih timova koji rade na nezavisnim projektima. Većina aplikacija radi u Kubernetesu i prema tome su kontejnerizirane. Za pohranjivanje kontejnera i slika potreban je registar. Kompanija koristi Docker Hub sa jednim nalogom kao takav registar. COMPANY. Slično većini sistema za skladištenje izvornog koda, Docker Hub vam ne dozvoljava da kreirate ugniježđenu hijerarhiju spremišta, kao što je COMPANY/PROJECT/IMAGE. U ovom slučaju... kako možemo pohraniti nemonolitne aplikacije u registar sa ovim ograničenjem bez kreiranja posebnog naloga za svaki projekat?
Možda je opisana situacija nekome poznata iz prve ruke, ali pogledajmo pitanje organizacije pohrane aplikacija općenito, tj. bez pozivanja na gornji primjer i Docker Hub.
Rešenja
Ako je aplikacija monolitno, dolazi u jednoj slici, onda se ne postavljaju pitanja i mi jednostavno spremamo slike u registar kontejnera projekta.
Kada je aplikacija predstavljena kao više komponenti, mikrousluge, tada morate odabrati određeni pristup. Koristeći primjer tipične web aplikacije koja se sastoji od dvije slike: frontend и backend - moguće opcije su:
- Spremite slike u odvojena ugniježđena spremišta:
- Spremite sve u jedno spremište i uključite ime slike u oznaku, na primjer, na sljedeći način:
NB: Zapravo, postoji još jedna opcija sa čuvanjem u raznim spremištima, PROJECT-frontend и PROJECT-backend, ali ga nećemo razmatrati zbog složenosti podrške, organizacije i raspodjele prava između korisnika.
werf podrška
U početku, werf je bio ograničen na ugniježđena spremišta - na sreću, većina registara podržava ovu funkciju. Od verzije , dodao rad sa registrima u kojima ugniježđenje nije podržano, a Docker Hub je jedan od njih. Od ovog trenutka, korisnik je imao izbor kako pohraniti slike aplikacije.
Implementacija dostupna kao dio opcije --images-repo-mode=multirepo|monorepo (podrazumevano multirepo, tj. skladištenje u ugniježđenim spremištima). Definira obrasce po kojima se slike pohranjuju u registar. Dovoljno je odabrati željeni način rada kada koristite osnovne komande, a sve ostalo će ostati nepromijenjeno.
Budući da se većina werf opcija može podesiti varijable okruženja, u CI/CD sistemima, režim skladištenja je obično lako postaviti globalno za ceo projekat. Na primjer, u slučaju GitLaba Samo dodajte varijablu okruženja u postavkama projekta: Postavke -> CI / CD -> Varijable: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ako govorimo o objavljivanju slika i puštanju aplikacija (o ovim procesima možete detaljno pročitati u relevantnim dokumentacijskim člancima: и ), tada režim samo određuje šablon po kojem možete raditi sa slikom.
Đavo je u detaljima
Razlika i glavna poteškoća pri dodavanju nove metode skladištenja je u procesu čišćenja registra (funkcije čišćenja podržane u werf-u, vidi ).
Prilikom čišćenja, werf uzima u obzir slike koje se koriste u Kubernetes klasterima, kao i politike koje je konfigurirao korisnik. Politike se zasnivaju na podjeli oznaka u strategije. Trenutno podržane strategije:
- 3 strategije vezane za Git primitive kao što su tag, grana i urezivanje;
- 1 strategija za prilagođene prilagođene oznake.
Mi spremamo informacije o strategiji oznaka kada objavljujemo sliku u naljepnicama završne slike. Samo značenje je tzv meta tag — neophodno za primjenu nekih politika. Na primjer, kada brišete granu ili oznaku iz Git spremišta, logično je izbrisati povezane neiskorišćen slike iz registra, što je pokriveno dijelom naših politika.
Prilikom spremanja u jedno spremište (monorepo), u oznaci slike, osim meta oznake, može se pohraniti i naziv slike: PROJECT:frontend-META-TAG. Da bismo ih razdvojili, nismo uveli nikakav poseban separator, već smo jednostavno dodali potrebnu vrijednost oznaci završne slike prilikom objavljivanja.
NB: Ako ste zainteresovani da pogledate sve što je opisano u werf izvornom kodu, onda početna tačka može biti .
U ovom članku nećemo obraćati više pažnje na probleme i opravdanost našeg pristupa: o strategijama označavanja, skladištenju podataka u etiketama i procesu objavljivanja općenito - sve je to detaljno opisano u nedavnom izvještaju Dmitrija Stoljarova: “".
Da rezimiramo
Nedostatak podrške za registre bez ugniježđenja nije bio blokirajući faktor za nas ili poznate nama poznate korisnike - uostalom, uvijek možete podići poseban registar slika (ili se prebaciti na uslovni registar kontejnera u Google Cloud-u)... Međutim , uklanjanje takvog ograničenja se činilo logičnim kako bi alat bio pogodniji za širu DevOps zajednicu. Tokom implementacije, naišli smo na glavnu poteškoću u preradi mehanizma čišćenja registra kontejnera. Sada kada je sve spremno, lijepo je znati da je nekome postalo lakše, a mi (kao glavni programeri projekta) ne predviđamo značajnije poteškoće u daljoj podršci ove mogućnosti.
Ostanite s nama i vrlo brzo ćemo vam pričati o ostalim inovacijama u !
PS
Pročitajte i na našem blogu:
- «»;
- «".
izvor: www.habr.com