Dlaczego deweloperzy przenoszą programy uruchamiające CI, rejestry i testowe bazy danych z laptopów na inne urządzenia?

Zespoły przenoszą te usługi z laptopów, aby zapewnić powtarzalność kompilacji, dostęp do współdzielonych zależności, możliwość usuwania stanu testowego i niezależność dostarczania oprogramowania od baterii lub środowiska pracy jednego dewelopera.

Serwer to nie większy laptop. Runner CI wykonuje niezaufane instrukcje projektu, rejestr przechowuje artefakty łańcucha dostaw, a baza testowa zawiera zmienny stan. Połączenie ich może być efektywne dla małego zespołu, ale 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ę albo potrzebuje lokalnego procesora i pamięci. Lokalny rejestr znika razem z tym komputerem, a baza testowa gromadzi stan, który rozumie tylko jeden deweloper.

Ciągła integracja opiera się na częstej, zautomatyzowanej weryfikacji, której wyniki są widoczne dla wszystkich. W praktykach ciągłej integracji Martina Fowlera nacisk kładzie się na zautomatyzowane kompilacje z samoczynnymi testami i widoczne wyniki — cechy, które trudno zagwarantować, gdy laptop jest dostępny tylko od czasu do czasu.

Przenoś rolę dopiero po określeniu, jaki problem rozwiązuje: opóźnienie kolejki, rozbieżność środowisk, dystrybucję obrazów, współdzielony stan integracji czy rywalizację o zasoby laptopa.

Oddziel granicę zaufania runnerów

Traktuj zadania CI jak 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 każdego repozytorium lub potoku.

Ograniczaj przestrzeń roboczą kompilacji i pamięci podręczne za pomocą 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.

Definiuj etykiety runnerów według poziomu zaufania i możliwości. Nie uruchamiaj kodu z pull requesta nieznanego kontrybutora na runnerze, który ma dostęp do sekretów produkcyjnych lub sieci domowej.

Nadaj rejestrowi rolę trwałej dystrybucji

Przechowuj dane rejestru i konfigurację na trwałej pamięci masowej, używaj uwierzytelniania, TLS w niezaufanych sieciach, reguł retencji i okien na odśmiecanie. Oddziel niezmienne tagi wydań od obrazów gałęzi przeznaczonych do usunięcia.

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

Monitoruj pojemność przed czyszczeniem. Usuwanie nieużywanych danych z rejestru może intensywnie obciążać operacje wejścia/wyjścia i — zależnie od wdrożenia — wymagać przejścia w tryb konserwacji.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Dbaj o to, by testowe bazy danych były jednorazowe, ale reprezentatywne

Przypisz każdemu potokowi lub gałęzi odizolowaną nazwę bazy danych, schemat, kontener lub maszynę wirtualną. Zasil ją danymi z wersjonowanych zestawów testowych lub zanonimizowanego zbioru danych, automatycznie uruchamiaj migracje, a następnie usuwaj ją po upływie okresu przechowywania.

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

Zachowuj tylko te logi i artefakty, które są potrzebne do diagnozowania nieudanych testów. Długotrwałe przechowywanie tajemniczych baz danych odtwarza problem z laptopem 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 pomoże zdecydować, czy izolację powinny zapewniać kontenery, czy maszyny wirtualne.

Umieść interfejs zarządzania w sieci z ograniczonym dostępem. Udostępniaj rejestr i interfejs CI tylko zespołowi lub za pośrednictwem uwierzytelnionej warstwy dostępu. Dla każdej usługi dokumentuj aktualizacje, zakres odpowiedzialności i procedurę przywracania poprzedniej wersji.

Przetestuj odtworzenie runnera, przywrócenie lub odbudowę rejestru, ponowne zapełnienie bazy danych, działanie przy pełnym dysku i ponowne uruchomienie serwera. Programiści powinni móc nadal pracować lokalnie podczas przywracania współdzielonych usług.

Końcowa kontrola konfiguracji

Przeniesienie zakończyło się sukcesem, gdy kompilacje działają bez konkretnego laptopa, środowiska można odtworzyć na podstawie wersjonowanych definicji, artefakty rejestru mają określony plan przechowywania i odzyskiwania, testowe bazy danych są odizolowane i jednorazowe, a żaden runner nie ma szerszego dostępu do sekretów, niż wymaga tego jego zadanie.