Porównanie narzędzi DevOps: Artifactory vs. NXRM3

Devops

4 maja 2021 • 26 min czytania

    Na rynku dostępnych jest wiele narzędzi do zarządzania repozytoriami i trudno zdecydować się na najlepsze. Aby ułatwić ten wybór, przygotowaliśmy porównanie dwóch najpopularniejszych rozwiązań: JFrog Artifactory i NXRM3 (Nexus Repository Manager). Dla zachowania obiektywizmu, zdecydowaliśmy się na przyjęcie określonych kryteriów. Porównanie opiera się wyłącznie na oficjalnej dokumentacji i oficjalnych cennikach oraz dotyczy tylko najważniejszych parametrów obu narzędzi w wersji self-hosted.

    Architektura

    Pierwsza część porównania dotyczy architektury. W tej kwestii Artifactory od samego początku zyskuje przewagę. Architektura systemu przedstawiona została na poniższym schemacie, a pełny opis można łatwo znaleźć w dokumentacji.

    Kompletny JPD zawierający wszystkie usługi na platformie JFrog Enterprise+

    Tymczasem dokumentacja Nexusa nie uwzględnia wcale architektury systemu. Po wpisaniu frazy „architecture” w wyszukiwarce na stronie dokumentacji NXRM3 otrzymujemy następujący wynik:

    Architektura o wysokiej dostępności (HA)

    Oba produkty można zainstalować na jednym serwerze, jak również w architekturze o wysokiej dostępności. Jeśli chodzi o pojedynczą instancję, to mogą z niej skorzystać użytkownicy bezpłatnej wersji obu produktów. Zastosowanie architektury wysokiej dostępności, zarówno dla Artifactory, jak i NXRM3, jest możliwe tylko w wersji płatnej. W przypadku Nexusa jest to przynajmniej licencja Pro, a dla Artifactory – wersja Enterprise i wyższe.

    Jeśli chodzi o poziom złożoności architektury obu rozwiązań, to są na podobym poziomie. Artifactory ma jednak tę zaletę, że wystarczą 2 nody do uruchomienia HA, w porównaniu do wymaganych 3 nodów w NXRM3. Ponadto w Artifactory, współdzielonym zasobem między nodami jest (co najmniej) baza danych, która oficjalnie jest wspierana przez dużo popularnych typów: MySQLMS SQLPostgreSQL i Oracle (nie obsługuje Docker i Docker Compose). W odróżnieniu do ArtifactoryNexus Repository Manager  współdzieli przestrzeń dyskową między nodami i oficjalnie rekomendowane jest używanie tylko jej dwóch typów: NFS v4 lub AWS EFS.

    Architektura o wysokiej dostępności w Artifactory

    Architektura o wysokiej dostępności w Artifactory

    Usługi JFrog możemy skonfigurować pod kątem wysokiej dostępności z klastrem 2 lub większą liczbą nodów w tej samej sieci lokalnej (LAN). Konfiguracja wysokiej dostępności zapewnia ciągłą synchronizację, która obejmuje dane, konfigurację, obiekty w pamięci podręcznej i zaplanowane zmiany zadań we wszystkich nodach. Zarządzanie dużymi obciążeniami jest możliwe bez utraty wydajności, nawet jeśli projekt się rozrasta.

    Architektura o wysokiej dostępności w Artifactory jest zaimplementowana dzięki wykorzystaniu zewnętrznego Load Balancer (LB) i nodów aplikacji. Sam Artifactory nie ma wbudowanego modułu balansowania obciążenia. Aby zapewnić optymalną wydajność i czas pracy, LB dzieli ruch między nodami. JFrog Artifactory jest również interfejsem użytkownika dla innych produktów JFrogXray, Mission Control, Distribution, Pipelines.Ponieważ przedmiotem porównania jest tylko Artifactory, nie będziemy omawiać architektury wysoko dostępnej dla pozostałych produktów z rodziny JFrog w tym artykule.

    Zasoby współdzielone między nodami powinny być co najmniej bazą danych. Obsługiwane typy baz danych dla wysokiej dostępności to:

    • Oracle (nie dla Docker ani Docker Compose),
    • MySQL,
    • MS SQL,
    • PostgreSQL.

    Poszczególne nody muszą być również w stanie komunikować się ze sobą na dedykowanych portach w protokole TCP/IP.

    Architektura o wysokiej dostępności w NXRM3

    Architektura o wysokiej dostępności w NXRM3

    Klaster nodów i LB tworzy architekturę wysokiej dostępności i zabezpiecza czas pracy aplikacji bez przestojów. W ten sposób system pozostaje dostępny nawet w przypadku awarii któregoś z nodów. Podobnie jak w Artifactory, implementacja architektury o wysokiej dostępności dla NXRM3obejmuje konfigurację LB przez klienta (Nexus również nie ma wbudowanego LB) i implementację co najmniej 3 nodów (oficjalna, minimalna liczba nodów, wymagana do prawidłowego działania). Podobnie jak w przypadku Artifactory, w NXRM3 nody powinny mieć możliwość komunikacji na wybranych portach w protokole TCP/IP.

    Jednak NXRM3, w przeciwieństwie do Artifactory, nie współdzieli bazy danych (dla poszczególnych baz danych realizowana jest synchronizacja typu Active-Active), a repozytorium Blob. Zalecenie od Sonatype, jeśli chodzi o udostępnianie tego zasobu, dotyczy tylko NFS v4 lub AWS Elastic FilesystemSonatype zwraca również uwagę, że współdzielenie Blob Repo wykorzystuje mechanizm POSIX, dlatego nie działa dla systemu plików GlusterFS i FUSE.

    Wymagania systemowe

    Trudno jest porównać minimalną wymaganą ilość wolnej przestrzeni dyskowej w obu narzędziach, ponieważ producenci nie podali dokładnych wartości liczbowych. W Artifactory zalecenia są oparte na oczekiwanej objętości przechowywania artefaktów. Według źródła powinniśmy użyć szybkiego dysku z wolną przestrzenią, która jest co najmniej 3 razy większa od całkowitego rozmiaru przechowywanego artefaktu. W przypadku 100-200 użytkowników zdecydowanie zalecany jest backup SAN.

    Natomiast Nexus Repository Manager jest nieco bardziej złożonym systemem, ponieważ to narzędzie obsługuje kilka typów obiektów Blob. Decyzja, jakiego typu użyć, powinna zostać podjęta w oparciu o rozmiar repozytoriów, szybkość wzrostu i dostępność miejsca do magazynowania.

    Zarządzanie i konfiguracja

    Konfiguracja Artifactory odbywa się za pośrednictwem interfejsu użytkownika i pliku konfiguracyjnego yaml. Głównymi elementami konfiguracji w pliku yaml są elementy architektury, takie jak:

    • bazy danych,
    • repozytoria,
    • replikacja,
    • ustawienia ogólne (mail, url, LDAP, hasło, itd.),
    • bezpieczeństwo (ogólne bezpieczeństwo, polityka haseł, LDAP, SAML, OAuth, HTTP SSO, Crowd),
    • konfiguracja usług (Backups, Maven Indexer),
    • ustawienia zaawansowane.

    Z sekcji administracyjnej interfejsu użytkownika możemy zarządzać repozytoriami, dostępem i autoryzacją, bezpieczeństwem, licencjami, ustawieniami ogólnymi, serwerami proxy, monitorowaniem i artefaktami.

    W narzędziu NXRM3 konfiguracja i zarządzanie, poza kilkoma wyjątkami, odbywa się za pośrednictwem panelu administracyjnego w interfejsie użytkownika. Panel administracyjny podzielony jest na:

    • repozytoria,
    • serwer IQ,
    • bezpieczeństwo,
    • wsparcie,
    • system.

    W obu rozwiązaniach interfejs zarządzania jest przejrzysty i intuicyjny. Zaletą Artifactory jest jednak możliwość skonfigurowania produktu w dużej mierze w jednym pliku. To sprawia, że bardzo łatwo jest zarządzać taką konfiguracją i kontrolować ją (wersjonowanie, IaC). Porównanie nie obejmuje automatyzacji instalacji obu produktów, np. przy użyciu ansible.

    Autoryzacja i dostęp

    Mechanizmy monitorujące

    Artifactory posiada kilka wbudowanych mechanizmów monitorujących:

    • monitorowanie przestrzeni dyskowej (monitorowanie pamięci),
    • monitorowanie replikacji (w wersji Enterprise),
    • monitorowanie statusu usług (Artifactory, Access, Event, Frontend, Replicator, Metadata).

    Dodatkowo istnieje również API Health Check, które jest dostępne przez REST API po odpowiedniej autoryzacji.

    NXRM3 wypada nieco gorzej w porównaniu do Artifactory, jeśli chodzi o obszar mechanizmów monitorujących. NXRM3 ma funkcję Repository Health Check, ale oprócz tego mechanizmu i API Health Check, nie ma innych wbudowanych mechanizmów monitorowania. Wiele wbudowanych mechanizmów monitorowania w Artifactory daje narzędziu przewagę w tej kategorii.

    Polityka czyszczenia repozytorium

    Artifactorywedług dokumentacji, nie ma wbudowanych specjalnych mechanizmów usuwania artefaktów po określonych parametrach, np. ostatnim użyciu, ścieżce, tagu, itp. Jedynym wyjątkiem jest czyszczenie pamięci podręcznej w repozytoriach proxy i maksymalna liczba unikalnych snapshotów dla 6 typów repozytoriów: Maven, NuGet, Gradle, Ivy, Docker, SBT.

    Artifactory zaleca skorzystanie z jednej z dostępnych wtyczek artifactCleanup, dzięki której możemy usunąć artefakty w cronie lub przez REST Api na podstawie czasu ich ostatniego pobrania.

    Nexus Repository Manager ma wbudowany mechanizm wsparcia czyszczenia repozytoriów, który jest dobrze opisany, zawiera przykłady i sekcję FAQ. 

    Czyszczenie repozytorium odbywa się poprzez skonfigurowanie polityki czyszczenia repozytorium, która ma być uruchamiana z zadaną częstotliwością. Istnieje jedno zadanie (Administration → System → Tasks) typu „Admin Cleanup repositories using their associated policies”, które uruchamia politykę czyszczenia wszystkich repozytoriów. Podane zasady są dodawane do wybranego repozytorium na ekranie jego edycji (Administration → Repository → Repositories → selected repository).

    Jednak polityka czyszczenia repozytorium jest realizowana tylko przez tak zwane „soft delete”. Właściwe zwolnienie miejsca na dysku po „soft delete” odbywa się w zadaniu „Admin Compact Blob”, które należy skonfigurować do uruchamiania z dowolną częstotliwością w sekcji Administration → System → Tasks.

    Aby usunąć pozostałe obrazy, tj. te bez tagów, uruchamiamy zadanie „Docker Delete unused manifests and images” w Administration → System → Tasks. Zalecamy usuwanie takich obrazów przynajmniej raz w tygodniu. Oprócz zadania „Docker Delete unused manifests and images” zalecamy uruchamianie raz w tygodniu zadania „Docker Delete incomplete upload”, które, jak nazwa sugeruje, usuwa niedokończone publikacje obrazów Dockera.

    Parametry filtrowania dla obrazów Dockera, które mają zostać usunięte, to:

    • czas, jaki upłynął od opublikowania artefaktu,
    • czas, jaki upłynął od ostatniego pobrania artefaktu,
    • tag obrazu platformy Docker, pasujący do wyrażenia regularnego dla danych artefaktów.

    Ceny i licencje

    Nexus oferuje 2 pakiety: Nexus Repository OSS i Nexus Repository Pro. Pierwsza wersja jest bezpłatna i umożliwia nam centralizację i zarządzanie wszystkimi komponentami i plikami binarnymi oraz tworzenie artefaktów. Zgodnie z informacjami na stronie internetowej Nexusa, bezpłatny pakiet obejmuje:

    • nieograniczoną liczbę użytkowników, 
    • nieograniczoną liczbę repozytoriów proxy, hostów i grup, 
    • uniwersalne pokrycie formatów, 
    • możliwość integracji z innymi narzędziami CI/CD, 
    • rejestr kontenerów, 
    • formaty społecznościowe i wtyczki, 
    • możliwość przechowywania w chmurze: Amazon S3.

    Nexus Repository Pro kosztuje 120$ za użytkownika rocznie i pozwala nam zarządzanie artefaktami, przechowywanie multi-cloud i wysoką dostępność. Inne funkcje zawarte w pakiecie Pro to SSO SAML, zaawansowane tagowanie metadanych, grupy Blob, wdrażanie grupowe (Docker) i wsparcie klienta 24/7.

    Artifactory oferuje nam pakiet Pro dla nieograniczonej liczby użytkowników i repozytoriów. Podobnie jak Nexus, ta wersja zawiera rejestr kontenerów, replikację plików binarnych, SSO SAML i integrację z ekosystemami DevOps. Poza tym obejmuje również takie funkcje, jak REST API, Universal Artifact Support i bezpłatne aktualizacje. Koszty trudno porównać, ze względu na różnicę w sposobie rozliczania licencji. Cena pakietu Pro zależy od liczby serwerów i wynosi 3200 $ za jeden serwer rocznie.

    JFrog Artifactory vs. Nexus Repository Manager – podsumowanie

    Zarówno Nexus Repository Manager, jak i JFrog Artifactory to bardzo dobre narzędzia. Każde z nich ma swoje wady i zalety, a wybór powinien być podyktowany rzeczywistymi wymaganiami projektu i zespołu. JFrog Artifactory wygrywa przede wszystkim pod względem architektury, wymagań systemowych i mechanizmów monitorowania, natomiast Nexus Repository Manager jest zdecydowanie lepszy w obszarach takich jak polityka czyszczenia repozytorium czy ceny i licencje.

    Narzędzia DevOps nie ograniczają się tylko do zarządzania repozytoriami. Odkryj galaktykę narzędzi DevOps na naszej stronie internetowej i zobacz, jak jeszcze możemy zwiększyć efektywność procesów DevOps. Czytaj więcej:

    1. AutoDevOps z GitLab
    2. Plusy i minusy hostowania narzędzi CI/CD w chmurze
    3. Porównanie narzędzi DevOps: GitLab i Azure DevOps
    [contact-form-7 404 "Not Found"]