Mono-arkiston aiheesta on keskusteltu useammin kuin kerran ja se aiheuttaa pääsääntöisesti erittäin aktiivista keskustelua. Luomalla avoimen lähdekoodin työkaluna, joka on suunniteltu parantamaan sovelluskoodin rakentamisprosessia Gitistä Docker-kuviin (ja sitten niiden toimittamiseen Kubernetesiin), emme juurikaan ajattele, mikä on paras vaihtoehto. Meille on ensisijaista tarjota kaikki tarvittava eri mielipiteiden kannattajille (jos tämä ei tietysti ole ristiriidassa terveen järjen kanssa).
werfin äskettäinen mono-repo-tuki on hyvä esimerkki tästä. Mutta ensin selvitetään, kuinka tämä tuki liittyy yleensä werfin käyttöön ja mitä Docker-rekisterillä on tekemistä sen kanssa ...
Ongelmat
Kuvitellaanpa tällainen tilanne. Yrityksellä on useita itsenäisissä projekteissa työskenteleviä kehitystiimejä. Useimmat sovellukset toimivat Kubernetesissa ja ovat siksi säiliöissä. Säilöjen, kuvien tallentamiseen tarvitset rekisterin (rekisterin). Tällaisena rekisterinä yritys käyttää Docker Hubia yhdellä tilillä COMPANY. Kuten useimmat lähdekoodin tallennusjärjestelmät, Docker Hub ei salli sisäkkäistä arkistohierarkiaa, kuten COMPANY/PROJECT/IMAGE. Siinä tapauksessa… kuinka voit tallentaa ei-monoliittisia sovelluksia rekisteriin tällä rajoituksella luomatta erillistä tiliä jokaiselle projektille?
Ehkä kuvattu tilanne on jollekulle tuttu, mutta pohditaanpa kysymystä sovellusten tallennustilan järjestämisestä yleisesti, ts. viittaamatta yllä olevaan esimerkkiin ja Docker Hubiin.
Ratkaisut
Jos sovellus monoliittinen, tulee yhdessä kuvassa, silloin ei ole kysymyksiä ja tallennamme kuvat vain projektin konttirekisteriin.
Kun sovellus esitetään useana komponenttina, mikropalvelut, silloin tarvitaan tietty lähestymistapa. Esimerkki tyypillisestä verkkosovelluksesta, joka koostuu kahdesta kuvasta: frontend и backend - mahdollisia vaihtoehtoja ovat:
- Tallenna kuvat erillisiin sisäkkäisiin arkistoihin:
- Tallenna kaikki yhteen arkistoon ja harkitse kuvan nimeä tagissa esimerkiksi seuraavasti:
NB: Itse asiassa on toinenkin vaihtoehto tallentamalla eri arkistoihin, PROJECT-frontend и PROJECT-backend, mutta emme ota sitä huomioon, koska tuki, organisointi ja oikeuksien jakaminen käyttäjien välillä on monimutkainen.
werf-tuki
Aluksi werf rajoittui sisäkkäisiin tietovarastoihin - onneksi useimmat rekisterit tukevat tätä ominaisuutta. Versiosta alkaen , lisäsi työtä rekistereiden kanssa, joissa sisäkkäisyyttä ei tueta, ja Docker Hub on yksi niistä. Siitä lähtien käyttäjä voi valita, kuinka sovelluskuvat tallennetaan.
Toteutus saatavilla lisävarusteena --images-repo-mode=multirepo|monorepo (oletus multirepo, eli tallennus sisäkkäisissä arkistoissa). Se määrittää kuviot, joiden mukaan kuvat tallennetaan rekisteriin. Riittää, kun valitset halutun tilan peruskomentoja käytettäessä, ja kaikki muu pysyy ennallaan.
Koska useimmat werf-asetukset voidaan asettaa ympäristömuuttujatCI/CD-järjestelmissä tallennustila on yleensä helppo asettaa globaalisti koko projektille. Esimerkiksi, GitLabin tapauksessa lisää vain ympäristömuuttuja projektin asetuksiin: Asetukset -> CI / CD -> Muuttujat: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Jos puhumme kuvien julkaisemisesta ja sovellusten käyttöönotosta (voit lukea näistä prosesseista yksityiskohtaisesti asiaankuuluvista dokumentaatioartikkeleista: и ), tila määrittää vain mallin, jonka avulla voit käsitellä kuvaa.
Paholainen on yksityiskohdissa
Ero ja suurin vaikeus uuden tallennustavan lisäämisessä on rekisterin puhdistaminen (werf:n tukemat puhdistusominaisuudet, katso ).
Puhdistuksessa werf ottaa huomioon Kubernetes-klustereissa käytetyt kuvat sekä käyttäjän määrittämät käytännöt. Käytännöt perustuvat tunnisteiden jakamiseen strategioihin. Tällä hetkellä tuetut strategiat:
- 3 Git-primitiivien, kuten tagin, haaran ja sitoumuksen, yhdistämää strategiaa;
- 1 strategia mielivaltaisille mukautetuille tunnisteille.
Tallennamme tiedot tag-strategiasta kuvan julkaisemisen yhteydessä lopullisen kuvan tarroihin. Itse merkitys on ns sisällönkuvauskenttä - Joidenkin käytäntöjen soveltaminen vaaditaan. Esimerkiksi poistettaessa haara tai tagi Git-arkistosta on loogista poistaa liittyvät käyttämätön kuvia rekisteristä, joka on osa käytäntöjämme.
Kun tallennetaan yhteen arkistoon (monorepo), kuvatunnisteeseen voidaan tallentaa sisällönkuvauskentän lisäksi myös kuvan nimi: PROJECT:frontend-META-TAG. Niiden erottamiseksi emme ottaneet käyttöön mitään erityistä erotinta, vaan lisäsimme tarvittavan arvon lopullisen kuvan etikettiin julkaisun yhteydessä.
NB: Jos olet kiinnostunut katsomaan kaikkea mitä werf-lähdekoodissa on kuvattu, niin aloituskohta voi olla .
Tässä artikkelissa emme kiinnitä enempää huomiota lähestymistapamme ongelmiin ja perusteluihin: merkintästrategioista, tietojen tallentamisesta etiketteihin ja julkaisuprosessiin kokonaisuudessaan - kaikki tämä on kuvattu yksityiskohtaisesti Dmitri Stolyarovin äskettäisessä raportissa: "'.
yhteenveto
Sisäkkäisten rekisterien tuen puute ei ollut estävä tekijä meille tai meille tutuille werf-käyttäjille - voithan aina luoda erillisen kuvarekisterin (tai vaihtaa ehdolliseen säilörekisteriin Google Cloudissa)... Kuitenkin, Tällaisen rajoituksen poistaminen vaikutti loogiselta, jotta työkalu olisi kätevämpi laajemmalle DevOps-yhteisölle. Sitä toteutettaessa kohtasimme suurimman vaikeuden säilön rekisterin puhdistusmekanismin muokkaamisessa. Nyt kun kaikki on valmista, on mukava huomata, että siitä on jollekin tullut helpompaa, eikä meillä (projektin pääkehittäjillä) tule olemaan huomattavia vaikeuksia tukea tätä ominaisuutta edelleen.
Pysy kanssamme ja kerromme pian muista innovaatioista !
PS.
Lue myös blogistamme:
- «";
- «'.
Lähde: will.com