Tema mono-repozitorija raspravljala se više puta i, u pravilu, izaziva vrlo aktivnu polemiku. Stvaranjem kao alat otvorenog koda osmišljen za poboljšanje procesa izgradnje aplikacijskog koda od Git do Docker slika (i zatim njihovog dostavljanja Kubernetesu), ne razmišljamo puno o tome koji je izbor najbolji. Za nas je primarno osigurati sve što je potrebno za pobornike drugačijih mišljenja (ako to nije u suprotnosti sa zdravim razumom, naravno).
werfova nedavna mono-repo podrška je dobar primjer za to. Ali prvo, shvatimo kako je ova podrška općenito povezana s korištenjem werf-a i kakve veze s tim ima Docker Registry ...
pitanja
Zamislimo takvu situaciju. Tvrtka ima mnogo razvojnih timova koji rade na neovisnim projektima. Većina aplikacija radi na Kubernetesu i stoga su kontejnerizirane. Za pohranu spremnika, slika, potreban vam je registar (registar). Kao takav registar, tvrtka koristi Docker Hub s jednim računom COMPANY. Slično većini sustava za pohranu izvornog koda, Docker Hub ne dopušta hijerarhiju ugniježđenog repozitorija, kao što je COMPANY/PROJECT/IMAGE. U tom slučaju… kako možete pohraniti nemonolitne aplikacije u registar s ovim ograničenjem bez stvaranja zasebnog računa za svaki projekt?
Možda je opisana situacija nekome poznata iz prve ruke, ali razmotrimo pitanje organiziranja pohrane aplikacija općenito, tj. bez pozivanja na gornji primjer i Docker Hub.
Rješenja
Ako je aplikacija monolitna, dolazi u jednoj slici, tada nema pitanja i jednostavno spremamo slike u registar spremnika projekta.
Kada je aplikacija predstavljena kao više komponenti, mikrousluge, tada je potreban određeni pristup. Na primjeru tipične web aplikacije koja se sastoji od dvije slike: frontend и backend - moguće opcije su:
- Spremite slike u odvojena ugniježđena spremišta:
- Pohranite sve u jedno spremište i razmislite o nazivu slike u oznaci, na primjer, kako slijedi:
NB: Zapravo, postoji još jedna opcija sa spremanjem u različitim spremištima, PROJECT-frontend и PROJECT-backend, ali ga nećemo razmatrati zbog složenosti podrške, organizacije i raspodjele prava među korisnicima.
werf podrška
U početku se werf ograničio na ugniježđena spremišta - na sreću, većina registara podržava ovu značajku. Počevši od verzije , dodan rad s registrima u kojima gniježđenje nije podržano, a Docker Hub je jedan od njih. Od tog trenutka nadalje, korisnik ima izbor kako će pohraniti slike aplikacije.
Mogućnost implementacije --images-repo-mode=multirepo|monorepo (zadano multirepo, tj. pohranjivanje u ugniježđena spremišta). Definira uzorke po kojima se slike pohranjuju u registar. Dovoljno je odabrati željeni mod pri korištenju osnovnih naredbi, a sve ostalo će ostati nepromijenjeno.
Budući da se većina werf opcija može postaviti varijable okoline, u CI/CD sustavima, način pohrane obično je lako postaviti globalno za cijeli projekt. 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 izvođenju aplikacija (detaljnije o tim procesima možete pročitati u relevantnim dokumentacijskim člancima: и ), tada način rada isključivo određuje predložak po kojem možete raditi sa slikom.
Đavao je u detaljima
Razlika i glavna poteškoća pri dodavanju nove metode pohrane je u procesu čišćenja registra (za značajke čišćenja koje podržava werf, pogledajte ).
Prilikom čišćenja werf uzima u obzir slike koje se koriste u Kubernetes klasterima, kao i pravila koja konfigurira korisnik. Politike se temelje na podjeli oznaka na strategije. Trenutačno podržane strategije:
- 3 strategije povezane Git primitivima kao što su tag, grananje i commit;
- 1 strategija za proizvoljne prilagođene oznake.
Podatke o strategiji oznake spremamo prilikom objave slike u oznake konačne slike. Sam smisao je tzv meta oznaka - Obavezno primijeniti neke od pravila. Na primjer, kada brišete granu ili oznaku iz Git repozitorija, logično je izbrisati srodne neiskorištena slike iz registra, što je obuhvaćeno dijelom naših pravila.
Kada se spremi u jedno spremište (monorepo), u oznaci slike, osim meta oznake, može biti pohranjen i naziv slike: PROJECT:frontend-META-TAG. Kako bismo ih razdvojili, nismo uveli nikakav poseban separator, već smo jednostavno dodali potrebnu vrijednost na oznaku konačne slike prilikom objave.
NB: Ako ste zainteresirani pogledati sve što je opisano u werf izvornom kodu, onda početna toč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, pohranjivanju podataka u naljepnicama i procesu objavljivanja u cjelini - sve je to detaljno opisano u nedavnom izvješću Dmitrija Stolyarova: “".
sažimanje
Nedostatak podrške za neugniježđene registre nije bio faktor blokiranja za nas ili nama poznate werf korisnike - uostalom, uvijek možete podići zasebni registar slika (ili se prebaciti na uvjetni registar spremnika u Google Cloudu) ... Međutim, uklanjanje takvog ograničenja činilo se logičnim kako bi alat bio praktičniji široj DevOps zajednici. Implementirajući ga, suočili smo se s glavnom poteškoćom u preradi mehanizma čišćenja registra spremnika. Sada kada je sve spremno, lijepo je shvatiti da je nekome postalo lakše, a mi (kao glavni developeri projekta) nećemo imati primjetnih poteškoća u daljnjoj podršci ove mogućnosti.
Ostanite s nama i uskoro ćemo vas obavijestiti o drugim inovacijama u !
PS
Pročitajte i na našem blogu:
- «»;
- «".
Izvor: www.habr.com
