W poprzednim wpisie omówiłem pokrótce proces konfiguracji podstawowych narzędzi. Wspomniałem też, że Artifactory zostało zamienione na Nexusa, ale nie powiedziałem dlaczego. Dziś dwa błędy, które kosztowały mnie czas i dużo nerwów.

Artifactory

W chwili, gdy mamy dockera, to instalacja artifactory wydaje się bajecznie prosta. Tworzymy bazę danych, podajemy namiary na nią w konfiguracji docker compose i gotowe. Nie do końca. Artifactory działa z własnym UID i GUID ( 1030:1030). To oznacza, że jeżeli chcemy przechowywać wolumen artifactory poza domyślnym (lub skonfigurowanym odgórnie) katalogiem dockera, to trzeba pobawić się z odpowiednimi dostępami.

Tu mamy dwie opcje. Najpierw możemy uruchomić całość z użytkownikiem root tak jak zrobiłem to z nexusem, pozwolić się temu skonfigurować i potem zrobić chown. To zadziała, ale jest duża szansa, że po restarcie już z właściwym użytkownikiem nie wstanie. Dlaczego? Problem leży gdzieś między / a katalogiem docelowym. Gdzieś nie ma odpowiednich uprawnień, czegoś brakuje itd. Po dwóch wieczorach walki z tym rozwiązaniem stwierdziłem, że jebać to zrobię konfigurację domyślną. I ta, druga opcja zadziałała. Co prawda, oznacza to, że późniejszy backup całości będzie upierdliwy, ale jakoś przeżyję. Przynajmniej miałem takie założenie.

To, co jednak nie chciało działać, to sklejenie ze sobą proxy nginx i artifactory działającego w ścieżce /artifactory. Tutaj poległem po całości, ponieważ nie udało mi się tak skonfigurować tego wszystkiego, żeby chciało działać. Nie wiem, może głupi jestem. Artifactory wystawia dwa porty 8081 i 8082. Oba powinny być mapowane na localhost/artifactory, a w konfiguracji samego artifactory wystarczy dodać odpowiednią ścieżkę i powinno działać… no nie. Po prostu nie chciało to tak zadziałać. Albo wywalało zwykłe 404, albo doklejało do URL-a dodatkową ścieżkę budując localhost/artifactory/artifactory. Żeby jednak nie było, to da się to zrobić, ale trzeba mieć większą kontrolę nad własną siecią (i wiedzieć, jak nią zarządzać), ponieważ „sztuczka” polega na użyciu odpowiednich domen. Jak nie masz DNS, to nawet nie podchodź.

Poddałem się i pierdolnąłem to w kąt. Zainstalowałem Nexusa…

npm

… i na tym Nexusie skonfigurowałem sobie lokalne proxy repozytorium npm. Pomysł jest niezły, bo przy moim talencie do JS, wielokrotnie usuwam node_modules i wykonuję npm install. Zatem oszczędzanie transferu jest całkiem niezłym pomysłem. Jednak nie do końca.

Skonfigurowałem zatem sobie proxy na nexusie, a następnie w /etc/hosts dodałem:

Listing 1. Konfiguracja hosts


127.0.0.1 view-localhost localhost koziolek koziolek.home

Pierwsza instalacja za pomocą npm trwała wieki, ale kolejne poszły już bardzo szybko i zgrabnie. Mogłem odtrąbić sukces. Do czasu…

Github action i dziwny błąd

„Dla jednego z moich klientów, lidera na rynku…” w każdym razie potrzebuję czasami coś zbudować za pomocą Github Actions (GHA). Wypchnąłem kod, poszedłem na kawusię, wracam, a tam niespodzianka. Build wyłożył się na etapie npm install. Jednak sam komunikat był mocno enigmatyczny. Npm nie mógł znaleźć pakietu. Sprawdziłem lokalnie i działa. Dodałem pakiet bezpośrednio, ale GHA mówi, że nie może znaleźć. Nosz kurwa mać, twoja krzemowa. Termin goni, klient pyta, co się stało, że się zesrało, a ja nie mam pojęcia. Dżepetto podsuwa rozwiązania, które powodują jeszcze większe fakapy (nie działa lokalnie), a jeszcze człowiek chce skończyć pracę na dziś. Koniec końców usunąłem node_modules, lockfile npm i yarn wypchnąłem i po kolejnej nieudanej próbie zacząłem analizować, czego tak naprawdę npm szuka.

Okazało się, że w package-lock.json mam wskazane moje domowe domeny. Po prostu npm działa inaczej niż maven i zaszywa informację o pochodzeniu pakietu w pliku. Czy to ma sens? Moim zdaniem nie do końca, bo utrudnia pracę z wieloma repozytoriami pakietów. Jednocześnie rozumiem motywacje twórców, którzy wyszli z założenia, że bezpieczeństwo pakietów JS i powtarzalność procesu jest ważniejsza niż wygoda użycia.

Dlaczego działa to w twojej firmie?

Ponieważ cały proces zarówno lokalnego budowania, jak i CI/CD masz ogarnięty w ramach sieci wewnętrznej. Twój Jenkins, TeamCity, czy inne narzędzie widzi wszystkie potrzebne adresy. Względnie twoje firmowe repozytorium jest wystawione na świat i można się do niego dobić z zewnątrz.

Podsumowanie

Domowe środowisko pozwala na samodzielne przejście przez pewne procesy, których nie widzimy w codziennej pracy. Nie oznacza to jednak, że będziemy mieli łatwo. Odkręcenie błędu z npm zajęło mi dłuższą chwilę, ale udało się to ogarnąć. Pomysł na użycie Artifactory zarzuciłem, ale kiedyś wrócę do niego w ramach ćwiczeń z dockera. Na razie jednak czas na hardware.