Dlaczego deweloperzy przenoszą narzędzia CI, rejestry i testowe bazy danych poza swoje laptopy?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Are Developers Moving CI Runners, Registries, and Test Databases Off Their Laptops? - Zima Store Online

Zespoły przenoszą te usługi z laptopów, aby kompilacje były powtarzalne, współdzielone zależności dostępne, stan testów tymczasowy, a dostarczanie niezależne od baterii lub środowiska pracy jednego dewelopera.

Serwer nie jest większym laptopem. Runner CI wykonuje niezaufane instrukcje projektu, rejestr przechowuje artefakty łańcucha dostaw, a testowa baza danych zawiera zmienny stan. Połączenie tych ról może być wydajne dla małego zespołu tylko wtedy, gdy tożsamości, sieci, pamięć masowa, sekrety, limity i odzyskiwanie są rozdzielone według ról.

Zacznij od problemu z przepływem pracy

CI hostowane na laptopie zawodzi, gdy jego właściciel śpi, podróżuje, zmienia sieć, zamyka pokrywę lub potrzebuje lokalnego procesora i pamięci. Lokalny rejestr znika wraz z tym urządzeniem, a testowa baza danych gromadzi stan, który rozumie tylko jeden deweloper.

Ciągła integracja opiera się na częstej, automatycznej weryfikacji, którą każdy może zobaczyć. praktyki ciągłej integracji Martina Fowlera kładą nacisk na automatyczne kompilacje z samoczynnym testowaniem i widoczne wyniki - właściwości, które trudno zagwarantować na laptopie dostępnym tylko okazjonalnie.

Przenoś daną rolę dopiero po nazwaniu problemu, który ma zostać rozwiązany: opóźnienie w kolejce, rozbieżności środowiska, dystrybucja obrazów, współdzielony stan integracji lub rywalizacja o zasoby laptopa.

Rozdziel granicę zaufania runnera

Traktuj zadania CI jako wykonywanie kodu. W miarę możliwości używaj efemerycznych kontenerów lub maszyn wirtualnych, unikaj montowania gniazda Docker hosta w niezaufanych zadaniach i przypisuj poświadczenia o ściśle ograniczonym zakresie do poszczególnych repozytoriów lub potoków.

Umieść obszar roboczy kompilacji i pamięci podręczne w ramach limitów. Nieudane zadanie nie może zapełnić głównego systemu plików serwera ani odczytać poświadczeń rejestru niezwiązanych z jego projektem.

Zdefiniuj etykiety runnerów według poziomu zaufania i możliwości. Nie wysyłaj kodu żądania scalającego od nieznanego współtwórcy do runnera, który może uzyskać dostęp do sekretów produkcyjnych lub sieci domowej.

Uczyń rejestr trwałą rolą dystrybucyjną

Przechowuj dane i konfigurację rejestru na trwałej pamięci masowej, z uwierzytelnianiem, TLS na niezaufanych ścieżkach, zasadami retencji i oknami zbierania elementów bezużytecznych. Oddziel niezmienne tagi wydań od tymczasowych obrazów gałęzi.

Twórz kopie zapasowe konfiguracji, metadanych i artefaktów, których nie można odbudować. Jeśli obrazy można odtworzyć ze źródła, udokumentuj czas odbudowy i zachowaj źródło, definicje kompilacji oraz zewnętrzne zależności zamiast tworzyć kopię zapasową każdej warstwy pamięci podręcznej.

Monitoruj pojemność przed czyszczeniem. Zbieranie elementów bezużytecznych rejestru może intensywnie obciążać operacje wejścia-wyjścia, a zależnie od implementacji może wymagać trybu konserwacji.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zachowaj testowe bazy danych jako tymczasowe, ale reprezentatywne

Przydziel każdemu potokowi lub gałęzi odizolowaną nazwę bazy danych, schemat, kontener lub maszynę wirtualną. Inicjalizuj ją na podstawie wersjonowanych danych testowych lub zanonimizowanego zbioru danych, uruchamiaj migracje automatycznie i usuwaj ją po upływie okresu retencji.

Nigdy nie kopiuj do roli testowej sekretów produkcyjnych ani niezanonimizowanych danych osobowych. Ogranicz zasięg sieci, aby przejęte zadanie nie mogło przejść z testowej bazy danych do niezwiązanych usług.

Trwałe przechowuj tylko dzienniki i artefakty potrzebne do diagnozowania nieudanych testów. Długowieczne, tajemnicze bazy danych odtwarzają problem laptopa na większej maszynie.

Zbuduj topologię serwera dla małego zespołu

Używaj oddzielnych kont usług, sieci kontenerów, woluminów, limitów i zasad tworzenia kopii zapasowych dla ról runnera, rejestru i bazy danych. Ten przewodnik po platformach NAS i Docker pomaga zdecydować, czy kontenery, czy maszyny wirtualne powinny zapewniać izolację.

Umieść interfejs zarządzania w ograniczonej sieci. Udostępniaj rejestr i interfejs CI tylko zespołowi lub za pośrednictwem uwierzytelnionej warstwy dostępu. Rejestruj aktualizacje, własność i możliwość wycofania zmian dla każdej usługi.

Przetestuj odtworzenie runnera, przywrócenie lub odbudowę rejestru, ponowne zasilenie bazy danych, sytuację pełnego dysku oraz ponowne uruchomienie serwera. Deweloperzy powinni nadal móc pracować lokalnie podczas przywracania współdzielonych usług.

Końcowa kontrola konfiguracji

Przeniesienie jest udane, gdy kompilacje działają bez konkretnego laptopa, środowiska są odtwarzane na podstawie wersjonowanych definicji, artefakty rejestru mają plan retencji i odzyskiwania, testowe bazy danych są odizolowane i tymczasowe, a żaden runner nie przechowuje szerszego zakresu sekretów, niż wymaga tego jego zadanie.