Jak zbudować domowy serwer deweloperski do obsługi Git, obrazów Dockera, baz danych i aplikacji podglądowych

Zbuduj stabilną warstwę usług, oddziel dane trwałe od artefaktów możliwych do ponownego utworzenia i zadbaj o to, by każdą usługę deweloperską można było odzyskać bez zachowywania samego hosta.

Dla jednego lub dwóch programistów pracujących w domu pojedynczy serwer z Linuksem może obsługiwać Git, rejestr obrazów, bazy danych i aplikacje podglądowe. Projekt pozostanie łatwy w zarządzaniu tylko wtedy, gdy tożsamość, role pamięci masowej, ekspozycja sieciowa, kopie zapasowe i przywracanie zostaną zaplanowane, zanim usługi zaczną od siebie zależeć.

Przypisz role usług przed wyborem sprzętu

Traktuj Git, rejestr obrazów, silniki baz danych i aplikacje podglądowe jako odrębne role usług, nawet jeśli korzystają z tego samego hosta. Git przechowuje historię kodu źródłowego; rejestr przechowuje artefakty możliwe do ponownego utworzenia; bazy danych zawierają zmienny stan aplikacji; aplikacje podglądowe to jednorazowe środowiska uruchomieniowe.

Oszacuj zapotrzebowanie na procesor i pamięć na podstawie równoległych kompilacji, zestawów roboczych baz danych i aktywnych podglądów. Oszacuj pojemność pamięci masowej na podstawie repozytoriów, okresu przechowywania w rejestrze, przyrostu baz danych, logów i miejsca na przygotowanie kopii zapasowych. Dzięki temu unikniesz zakupu dużego dysku, gdy pierwszym wąskim gardłem będzie pamięć.

Na początku używaj jednego węzła obliczeniowego, jeśli jego awaria jest akceptowalna w środowisku deweloperskim. Później wydziel węzły kompilacyjne, jeśli nagłe wzrosty obciążenia kompilacją zaczną spowalniać bazy danych lub interaktywne podglądy.

Oddziel dane trwałe, możliwe do ponownego utworzenia i służące do odzyskiwania

Nie twórz jednakowych kopii zapasowych każdego bajtu. Rejestr zwykle można odtworzyć na podstawie źródła i instrukcji kompilacji, ale bazy danych nie. Zapisuj zrzuty baz danych lub spójne migawki oddzielnie od woluminu działającej bazy danych.

Jeden praktyczny plan kopii zapasowych hostowanych samodzielnie pokazuje, dlaczego warto automatyzować obsługę Gita i kopie poza lokalizacją jako odrębne zadania, zamiast zakładać, że sam NAS jest kopią zapasową.

Utwórz jedną prywatną ścieżkę dostępu

Przypisz serwerowi stały adres w sieci LAN i lokalną nazwę DNS. Udostępniaj trasy do Git, rejestru, bazy danych i aplikacji podglądowych tylko sieciom, które ich potrzebują. Dostęp zdalny powinien odbywać się przez prywatną sieć VPN lub uwierzytelnioną ścieżkę przez odwrotny serwer proxy, a nie przez zestaw przekierowanych portów usług.

Używaj oddzielnych kont usług i kluczy wdrożeniowych. Programiści nie powinni współdzielić hasła administratora, a aplikacje podglądowe nie powinny dziedziczyć danych uwierzytelniających umożliwiających modyfikowanie repozytoriów Git lub rejestru.

Wybieraj SMB lub NFS tylko do obsługi plików, która rzeczywiście wymaga współdzielonego montowania. Poradnik doboru klientów SMB i NFS pomaga oddzielić wybór protokołu od dostępu do usług aplikacji.

Featured

ZimaBoard 2 - Miniaturowy serwer domowy dla wielkich pomysłów

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Dopasuj kolejność wdrażania do grafu zależności

Uruchamiaj kolejno: montowanie pamięci masowej, system tożsamości, bazy danych, rejestr, Git, a następnie aplikacje podglądowe. Kontrole stanu powinny sprawdzać rzeczywiste zależności, nie restartować powolnej bazy danych tylko dlatego, że aplikacja wciąż się uruchamia.

Przechowuj definicje wdrożeń, migracje schematu i trasy odwrotnego serwera proxy w systemie kontroli wersji. Dane poufne przechowuj poza repozytorium i jasno określ lokalizację ich kopii zapasowej. Zastępczy host powinien umożliwiać odtworzenie usług na podstawie definicji i zabezpieczonego stanu.

Sprawdź proces, odtwarzając jedną aplikację podglądową z czystej kopii repozytorium, pobierając jej obraz, przywracając testową bazę danych i uzyskując do niej dostęp z przewidzianej ścieżki klienta.

Twórz kopie zapasowe z myślą o przywracaniu, nie o kolekcjonowaniu

Twórz kopie zapasowe repozytoriów, zrzutów baz danych wykonanych za pomocą natywnych narzędzi, konfiguracji usług i zaszyfrowanych danych poufnych w lokalizacji, która nie jest zamontowana z prawem zapisu dla każdej usługi. Przechowuj co najmniej jedną kopię poza granicą zasilania serwera i uprawnień administratora.

Co kwartał przywracaj dane w odizolowanej przestrzeni nazw. Sprawdzaj użytkowników, rozszerzenia, zaplanowane zadania, uprawnienia do repozytoriów, uwierzytelnianie rejestru i trasy DNS, a nie tylko obecność plików.

Rozbuduj konfigurację, gdy kolejki kompilacji opóźniają interaktywną pracę, opóźnienia bazy danych rosną podczas przesyłania obrazów lub okna tworzenia kopii zapasowych pokrywają się z godzinami pracy. Przestań dodawać kolejne role do tego samego hosta, gdy jedna eksperymentalna usługa może wyczerpać zasoby lub przejąć dane uwierzytelniające potrzebne stabilnym usługom.

Ostateczna zasada konfiguracji

Konfiguracja jest gotowa, gdy każda usługa ma określoną rolę, zabezpieczony stan, kontrolowaną ścieżkę dostępu, przetestowane przywracanie oraz mierzalny warunek podziału lub rozbudowy topologii.