Aki Sonatype Nexus-t használ a build szerverén, mint Maven repository, azzal a bosszantó problémával szembesül egy idő után, hogy a sonatype-work könyvtár egyre több helyet foglal el. Ennek alapvetően két oka van:

  • A saját termékünk kiadásait (releases) és munkapéldányait (snapshots) tartjuk itt a végtelenségig
  • A proxy repository helyi gyorstárként funkcionálva letölti a távoli szerverekről az igényelt Maven artifact fájlokat, s azok ott maradnak az idők végezetéig

Saját fájlok takarítása

Ha több verziót is életben tartunk a termékünkből, illetve ezt mások belefordítják a saját projektjeikbe (például mint az AndroidSOAP library), akkor alapvetően a kiadott artifact gyűjteményből nem töröljük ki a régi állományokat, mivel ezeket mások még használhatják. Természetesen a nagyon régi állományok akár törölhetőek is, ha kimondjuk, hogy ezeket a továbbiakban már nem támogatjuk. Ha pedig egyetlen éles rendszerre dolgozunk és a termék nem kerül ki a cégünk kapuján, akkor felesleges a régi kiadások őrizgetése, mert jó eséllyel nem lehet olyan környezetünk, ahol a régi csomag működőképes lenne. A releases repository tartalmát kézzel tudjuk megritkítani, erre ne is keressünk automatikus megoldást.

A munkapéldányaink között viszont célszerű néha automatikus irtást végezni, különben a régi – amúgy senki által nem használt – fájlok feleslegesen foglalják a szabad helyet a fájlrendszeren. Ehhez egyszerűen be kell állítani egy ütemezett feladatot:


Proxy repository takarítása

A proxy tároló alapvető funkciója az, hogy a fordításhoz, teszteléshez vagy futáshoz szükséges Maven artifact-halmaz gyorsan rendelkezésre álljon helyben, ne kelljen mindig – az esetleg lassú – hálózaton át letölteni ezeket a kisebb-nagyobb állományokat, másrészt a távoli repository szerverek terhelését hivatott csökkenteni azzal, hogy csak egyszer töltjük le az adott állományokat. Azonban az idő előrehaladtával az egyes artifact termékekből újabb és újabb verziók jönnek ki, illetve az is előfordulhat, hogy a fejlesztés során átmenetileg olyan függőségeket használunk, amelyekről kiderül, hogy nem alkalmasak az adott feladatra. Ezeket a fájlokat a proxy tárolja, de feleslegesen. Célszerű beállítani egy ésszerű határt a fájlok élettartamára, majd beállítani egy ütemezett feladatot a régen használt állományok törlésére:

Trash ürítése

A fenti két lépés után akár hátra is dőlhetnénk, ám a sonatype-work könyvtár mérete csak nem akar csökkenni, pedig látszólag futnak a fent definiált ütemezett feladatok. Ennek oka, hogy a Nexus nem törli a törölt állományokat, hanem beteszi... úgy van: a szemetesbe. Ha végleg meg szeretnénk szabadulni a felesleges cuccoktól, akkor futtatnunk kell időnként egy olyan ütemezett feladatot is, amely üríti a szemetest:

Az eredmény...

...egy sokkal kisebb helyet elfoglaló Nexus, amely nagyjából azonos funkcionalitással bír.

Comments  (7)

7 Comments

  1. Az Evict Unused Proxied Items From Repository Caches jobhoz hasznos lehet egy olyan CI job (meg amúgy is), ami rendszeresen fut és úgy build-eli a projektet, hogy build előtt törli a helyi Maven repository cache-t. Így kiderül, ha esetleg eltűnik az eredeti repository-ból valamilyen, a projekt számára szükséges függőség.

    Emiatt az Empty Trash-nél  a Purge older items-nek több napot állítanék be, mint ami az Evict older items-nek van beállítva, hogy ha eltűnik egy szükséges függőség, akkor a trash-ből még vissza tudjuk állítani.

    1. Auth Gábor AUTHOR

      hasznos lehet egy olyan CI job (meg amúgy is), ami rendszeresen fut és úgy build-eli a projektet, hogy build előtt törli a helyi Maven repository cache-t

      Ezt majd a CI takarítás témakör alatt írom meg... (smile)

      Emiatt az Empty Trash-nél  a Purge older items-nek több napot állítanék be, mint ami az Evict older items-nek van beállítva, hogy ha eltűnik egy szükséges függőség, akkor a trash-ből még vissza tudjuk állítani

      Mindenki beállítja magának a megfelelő időt... a számomra ez így ebben a formában tökéletesnek tűnik, de jogos az észrevétel... (smile)

  2. Én azt gondolom, hogy a proxy repository fontos feladata a megismételhető build szempontjából, hogy amelyik lib egyszer elérhető volt az minden buildelés során elérhető legyen és pont ugyanaz legyen a tartalma mint az első buildnél, függetlenül bármely harmadik fél ténykedésétől. Ha kitörlöd a repo-ból akkor vagy elérhető lesz a harmadik félnél vagy sem. A régi jó cvs/svn lib könyvtáras jarhell elérésnél sosem volt ilyen probléma, így nem kéne visszafelé fejlődni csak azért mert rendet raktunk.

    1. Auth Gábor AUTHOR

      Ezt így ebben a formában projektje válogatja... (smile)

      Ha olyan modellben dolgozunk, hogy nem támogatunk több verziót egyszerre, mivel mindig a legutolsó release van éles üzemben, akkor nem szükséges az, hogy egy sok évvel ezelőtti kiadást reprodukálhatóan újra akarunk fordítani. Ha viszont ez feltétel, akkor rendszeresen fordítsuk újra és teszteljük is a régi (és támogatandó) csomagokat, hogy biztosak legyünk abban, hogy pont ugyanaz a tartalma, mint amire szükségünk lehet adott esetben.

      Tapasztalatom szerint az nem működik, hogy például három éven át nem fordítunk le egy csomagot, aztán hirtelen kell és le is fordul, majd megfelelően fut is... és nem csak a függőségek miatt nem fordul vagy nem fut, hanem a build és run környezet változott annyit, hogy már nem képes fordulni vagy futni. (smile)

      1. Azt én értem, hogy van olyan projekt ahol nem kell a régebbi verziót buildelni. Ugyanakkor ott sem hiszem, hogy jó ötlet magunk alatt vágni a fát. Ha például valamiért nem megy a CI akkor meg kell állítani ezt a job-t is nehogy letörölje a harmadik feles függőségeket a company repository-ból, ahelyett, hogy a CI javításával foglalkoznánk? Kinek fog eszébe jutni? Vagy ezt is leszabályozzuk? Ennél szerintem olcsóbb a diszk.

        Az pedig, hogy egyéb okokból nem fordul nem indokolja, hogy további problémákat gödítsünk a build elé.

        Egyébként mekkora repo méretekről beszélgetünk? 

        1. Auth Gábor AUTHOR

          Ha például valamiért nem megy a CI akkor meg kell állítani ezt a job-t is nehogy letörölje a harmadik feles függőségeket a company repository-ból, ahelyett, hogy a CI javításával foglalkoznánk?

          Mondjuk több mint két hétig nem megy a CI? Akkor nem az lesz a legnagyobb problémánk, hogy honnan szerzünk meg egy olyan függőséget, amely már annyira régi, hogy a maven.org központi repository-ból is kitörölték... (smile)

          ...szóval továbbra is tartom azt a mondást, hogy fejlesztési modell függő az általad jelzett probléma... ha a termék verzióiból mindig van hetente legalább egy build, akkor esélytelen, hogy ebből bármi baj legyen. Ha pedig ezek nem igazak egy projektre, akkor törekedni kell arra, hogy teljesüljenek ezek feltételek... sokkal nagyobb kockázat van egy sok évvel ezelőtt lefordított és azóta potenciálisan nem forduló projektben, mint abban, hogy mindig mindent legalább hetente egyszer lefordítunk (ez már garantálja azt, hogy a szükséges függőségek maradnak csak a helyi repository-ban és minden más két hét után törlődik).

          A másik megközelítés pedig ugye az, hogy ha véletlenül vagy szándékosan baj történik a céges repository-val, akkor se lehet többé előállítani a terméket, pluszban nem vesszük észre, hogy egy szükséges függőség már teljesen megszűnt a külvilágban (!!!)... ez nem kockázat?

          1. Igen, csak tudod itt befigyel a "ki fizeti ki?" kerdeskore is. Szep dolog az, hogy torekedni kell egy normalis fejlesztesi modellre, de van amikor a kornyezet (az ugyfel hozzaallasa, a technikai feltetelek, barmi) olyan, hogy nem lehet, akkor bizony bele kell menni abba is, hogy hogyan lehet a dolgokat nem szepen megoldani - es nem baj, ha az is elhangzik. En csak szimpla egyszeru PHP projektekkel dolgoztam, de meg igy is elojott neha az, hogy hirtelen szukseg lett volna hetekkel/honapokkal ezelotti verziora valamibol. PHP projektnel ez persze egyszeru, mert eloveszem a szukseges fajlokat az SVN-bol, berakom, putty, kesz, de egy Java projektnel ebbol bizony oriasi kavarodas lehet. En azt mondom, hogy meg kell szabni az esszeruseg hatarait, es ugy torolgetni, hogy azon belul maradjunk - de csak azert torolni, hogy az a szam ne 670 MB hanem csak 56 legyen, mikozben van 30 GB teruletunk - dumbness. Es annyir azert szerintem meg a nexus mukodesen se lassit az artifactok mennyisege, hogy megerne.

Attachments  (3)

Add Attachment
  File Modified
PNG File empty_trash.png Nov 16, 2013 by Auth Gábor
PNG File evict_repositories.png Nov 16, 2013 by Auth Gábor
PNG File remove_snapshots.png Nov 16, 2013 by Auth Gábor