Artefaktien hallinta ei ehkä ole kaikkein innostavin tehtävä, mutta se on ratkaisevan tärkeää. Ops-tiimi asentaa ja ylläpitää Artifactorya, mutta koska se ei ole erityisen houkutteleva, Dev-tiimit eivät ota sitä täysin omakseen.
Sofus Albertsen
Sofus is a Continuous Delivery Trainer and Consultant in Copenhagen. Before joining Eficode Praqma he was assistant professor on an Applied Science Bachelor program. He flies kites and in the summer he escapes the modern world by spending two weeks in a beach hut without electricity or network coverage.
Korjataan se.
Tässä artikkelissa saat käytännön vinkkejä Artifactoryn pitämiseen järjestyksessä ja siistinä, jotta siitä ei kasva paisunutta, hallitsematonta massaa.
Kaikki alkaa hyvin…
Onnittelut, olet asentanut Artifactoryn ja ottanut sen käyttöön. Se on uusi, kiiltävä ja kooltaan hallittava. Nyt on aika ottaa kaikki tiimit mukaan hyödyntämään työkalua täysimääräisesti.
Siirrytään vuosi tai pidemmälle ensimmäisestä asennuksesta: Artifactorysi koko kasvaa eksponentiaalisesti, koska kaikki tiimit tallentavat sinne kaikkien CI-buildien artifactit. Ja kuka siivoaa? Vastaus on: ei kukaan.
Ops-tiimi ei tiedä, mitä Artifactoryyn on tallennettu, ja koska Dev-tiimit eivät vastaa tallennustilan laajentamisesta, sotku ei vaikuta heihin.
Havainnollistetaan ongelman mittakaavaa yksinkertaisella laskelmalla:
Kolme kahdeksan hengen tiimiä tekee commitin kahdesti päivässä ja tuottaa 100 Mt artifacteja jokaista commitia kohden vuoden 200 työpäivän ajan. Tästä kertyy lähes teratavu artifacteja vuodessa, eikä suurinta osaa niistä koskaan julkaista asiakkaille.
Ja tämä koskee pientä tiimiä. Kuvittele mittakaava suuremmissa projekteissa.
Jos sääntöjen ja ohjeiden käyttöönottoa odottaa liian pitkään, tilanne muuttuu käytännössä hallitsemattomaksi. Ajan myötä Artifactory-palvelimesi paisuu, ja Ops-tiimin on vaikea hallita varmuuskopiointia ja ylläpitoa.
Mitä asialle voi tehdä? Seuraavissa osioissa kerron suositukseni, joiden avulla pääset tästä sotkusta eroon.
1. Määritä pipelineillesi ja repositorioillesi kypsyystasopolku
JFrogin parhaiden käytäntöjen mukaan artifactien kypsyystaso ilmaistaan siirtämällä ne repositoriosta toiseen.
Lähde: JFrog
Suosittelen noudattamaan tätä mallia. Se varmistaa, että käytät työkalua sen kehittäjien tarkoittamalla tavalla. Näin vältyt ikäviltä yllätyksiltä, jos JFrog muuttaa jotakin, jota käytät omalla tavallasi.
Kypsyystasojen määrä riippuu tarpeistasi. Selvitä kuitenkin, milloin artifacti siirtyy tiimiltä toiselle tai milloin sen julkaisusta yleisölle tehdään tärkeä päätös. Näin näet selkeämmin, mitä kypsyystasoja tarvitset.
Esimerkki voisi olla seuraava:
Repository maturity /type | Example name | Retention period* | Comment |
| sandbox | gradle-sandbox-local | 7 days | This is a catch-all repo where all, including individual, developers can upload artifacts. No guarantees are made here about quality. |
| dev | gradle-dev-local | 30 days | The landing place for when the CI system made the artifacts. Further testing is down the pipeline. |
| qa | gradle-qa-local | 60 days | Artifacts stay here when they undergo test. They are on a path to promotion to release, or to be dumped by a quality gate and replaced by a newer version. |
| release | gradle-release-local | never | This is what is released to the public, and should therefore never be deleted automatically. |
Repositorio
kypsyystaso
/tyyppi
* Säilytysajat tulisi laskea ominaisuuksien ”latausaika” ja ”viimeisin käyttöaika” perusteella. Artifactit poistetaan vasta, kun molemmat ajat ovat umpeutuneet.
Yksinkertaisempi vaihtoehto
Tuntuuko useiden repositorioiden käyttö liian raskaalta? Harkitse silloin yksinkertaista sääntöä, jossa toimintaa määrittävät ominaisuudet, kuten cleanup=skip tai released=true.
Huomaa kuitenkin, että tämän yksinkertaisen toteutuksen muuttaminen ajan myötä kypsempään malliin on hankalaa. Siksi suosittelen vahvasti kypsyystasorepositorioiden käyttöä. Aluksi voit ottaa käyttöön vain yhden tai kaksi.
Nämä ovat Artifactoryyn määritettävät perussäännöt, joiden avulla voit myöhemmin luoda artifactien siivoussääntöjä.
2. Etsi siivottavat artifactit
Tutustu ensin admin- ja monitorointi-välilehden tallennustilan yhteenvetoon. Näet siitä heti, mitkä repositoriot käyttävät eniten tallennustilaa.
Nyt sinulla on yleiskuva järjestelmän suurimmista tallennustilan käyttäjistä.
Sen avulla tiedät, mihin kannattaa keskittyä, jos käyt repositoriot läpi yksi kerrallaan.
Jos olet vasta ottamassa repositorioita käyttöön, hienoa – tee itsellesi palvelus ja ota nämä ”säännöt” käyttöön kaikissa repositorioissa kerralla.
Käytetään seuraavaksi Artifactory Query Languagea (AQL) niiden artifactien etsimiseen, jotka pitää poistaa. AQL on tehokas kieli, jolla voit löytää artifacteja ja buildeja kyselyjesi perusteella.
AQL:llä voit käytännössä löytää mitä tahansa. Sen malliin tottuminen vie hetken, mutta yleiskuva datamallista on nähtävissä alla:
Lähde: JFrog
Tässä on esimerkki siitä, miten löydät kaikki artifactit, jotka rikkovat sandbox-repositorioita koskevaa sääntöämme:
Lisää esimerkkejä löytyy Artifactory-koulutusrepositoriostamme.
Voit suorittaa AQL-kyselyitä monella eri tavalla, mutta helpointa on käyttää curlia niin, että autentikointi ja Artifactory-URL ovat ympäristömuuttujissa:
curl -i -X POST -H "${AUTH_HEADER}" -H "Content-Type:text/plain" "${ARTIFACTORY_URL}/api/search/aql" -T payload.aql
Vastaus näyttäisi tältä:
Voit rajata kustakin artifactista saatavan tiedon määrää käyttämällä AQL-kyselysi lopussa ”.include()”-metodia.
Myös CLI:llä voi suorittaa AQL-kyselyitä, mutta ne pitää kääriä filespec-muotoon, mikä on mielestäni vähintäänkin epäintuitiivista. CLI ei anna määrittää kyselyn ”include”-osaa, mikä rajoittaa haku- ja suodatusmahdollisuuksiasi.
Kun tämä on kunnossa, katsotaan seuraavaksi, miten juuri löytämämme artifactit poistetaan.
3. Käyttämättömien artifactien poistaminen
Saatavilla on runsaasti työkaluja, jotka auttavat siivoamaan artifacteja Artifactoryssa.
Se, että tähän on niin monta eri tapaa, kertoo minulle kaksi asiaa:
Tämän olisi pitänyt olla määriteltynä ydintuotteessa alusta alkaen, sillä kaikki käyttäjät tarvitsevat sitä tavalla tai toisella.
Artifactien poistaminen on herkkä asia, ja ihmisillä on erilaisia tarpeita sille, miten poistettavat ja säilytettävät artifactit valitaan.
En käy läpi kaikkia mahdollisia työkaluja, vaan nostan esiin kaksi lähestymistapaa:
Oma Python-skriptini
Halusin välttää XKCD-sarjakuvan kilpailevien standardien tilanteen, joten tarvitsin tavan luoda AQL-kysely ja käyttää sitä helposti sekä hakuun että poistamiseen. Koska kaikki saatavilla olevat työkalut käyttivät joko filespeciä tai jotakin itse tehtyä ja rajoitettua kyselytapaa, päätin kirjoittaa skriptin itse.
Tässä menetelmässä käytät samaa AQL-tiedostoa kuin haussa. Sen sijaan, että vain hakisit artifactit ja tulostaisit ne, voit myös poistaa ne.
Voit suorittaa sen joko erillisenä Python-skriptinä tai Docker-konttina.
Löydät repositorion sekä dokumentaation sisältävän Python-skriptin tältä sivulta.
Artifactoryn siivoussovellus
Toinen vaihtoehto yllä mainitsemalleni omalle skriptilleni, jonka haluan myös nostaa esiin, on crazy-maxin Artifactoryn siivoussovellus. (Vastuuvapauslauseke: en tunne tekijää, joten en voi taata lähdekoodin tietoturvan laatua.)
Etuna on, ettei sinun tarvitse osata AQL:ää, sillä yleisimmät asetukset ovat käytettävissä YAML-muotoisessa konfiguraatiossa.
Nyt sinun tarvitsee vain suorittaa tämä säännöllisesti joko build-työnä CI-järjestelmässäsi tai cron-työnä palvelimella (se voi olla jopa Artifactory-palvelin itse), jolloin Artifactorysi siivotaan automaattisesti ja säännöllisesti.
Anna viimeinen mahdollisuus palautukseen
Nyt kun kaikki artifactit on poistettu, Artifactoryasi odottaa huomattavasti kevyempi tulevaisuus. Mutta entä jos poistit jotain, joka olisi pitänyt säilyttää ikuisesti?
Käytännössä haluat varmistaa, että roskakori on otettu käyttöön (se on oletuksena käytössä) ja että säilytysaika on asetettu järkeväksi.
Voit määrittää tämän järjestelmänvalvojana ”Artifactory General Settings” -välilehdellä.
Näin artifactit voidaan palauttaa hitaalla ja manuaalisella prosessilla valitsemasi ajan kuluessa.
Jos roskakorin tyhjennysintosi riistäytyy käsistä, tästä tietämyskannan artikkelista voi olla apua artifactien palauttamiseen tietystä ajankohdasta sen sijaan, että palauttaisit ne yksi kerrallaan.
4. Jaa ja hallitse Projects-ominaisuuden avulla
Kun olet tehnyt kaiken edellä mainitun, jokin tiimi tai organisaatiosi osa saattaa silti tarvita enemmän levytilaa kuin muut. He toki poistavat asioita siivousprosessiin sovellettavan sääntökokonaisuuden mukaisesti, mutta entä jos heidän artifactinsa ovat gigatavujen eikä megatavujen kokoisia?
Kyse ei silloin ole pelkästään siivoamisesta. Heidän käyttöönsä varaama levytila saatetaan myös joutua rajaamaan kiinteään määrään.
Tähän voit käyttää Artifactoryn versiossa 7.31.10 käyttöön otettua suhteellisen uutta Projects-ominaisuutta. Projects-ominaisuuden avulla voit jakaa palvelimen ”osioihin”, jotka vastaavat projekti- tai tiimirakennettasi.
Olemme käyttäneet sitä joidenkin asiakkaiden kanssa vaihtelevin tuloksin. Kyseessä on melko uusi ominaisuus, jolta puuttuu vielä kypsyyttä, erityisesti jos yrität käyttää sitä permission targetien vaihtoehtona ja tiimit hallinnoivat itse itseään.
Tilannetta hankaloittaa se, että projektien enimmäismäärä riippuu vahvasti ostamastasi lisenssistä. Siksi ominaisuuteen ei välttämättä voi luottaa kaikkien tiimien ja projektien kohdalla.
Yhteenveto
Artifactien hallinta on tärkeää, ja sen on oltava tarkkaa, jotta se toimii kunnolla – mutta se on myös melko tylsää. Noudattamalla edellä olevia vinkkejä pääset tilanteeseen, jossa useimmat tehtävät ovat automatisoituja ja perustuvat sääntökokonaisuuksiin, jotka ovat riittävän yleisiä sopiakseen kaikille tiimeille niiden kypsyystasosta ja tarpeista riippumatta.
- DevOps
- CI/CD
- System of Work
Subscribe to our newsletter
Related blogs
