Sandbox rozwiązuje problem tymczasowy, nie organizacyjny
Najprostsza definicja sandboxu brzmi: odizolowane środowisko przeznaczone do pracy, której nie chcemy wykonywać na podstawowym komputerze ani w systemie współdzielonym z innymi zespołami. Może to być test nowej wersji bazy danych, uruchomienie nieznanego narzędzia, proof of concept usługi albo odtworzenie błędu zależnego od systemu operacyjnego.
Sandbox nie naprawi natomiast braku procesu deweloperskiego. Jeśli projekt potrzebuje stałego środowiska integracyjnego, automatycznych wdrożeń i trwałych danych, pojedyncza maszyna uruchomiona na kilka dni będzie tylko obejściem. Podobnie wygląda sytuacja, gdy kilka osób ma równolegle rozwijać wspólną usługę. Wtedy potrzebna jest uzgodniona topologia, kontrola zmian i reguły utrzymania, a nie luźny eksperyment.
Pięć sygnałów, że osobna VM jest rozsądnym wyborem
Decyzję można oprzeć na kilku praktycznych przesłankach. Sandbox VM zwykle ma sens, gdy występuje co najmniej jedna z nich:
- test wymaga uprawnień administratora lub zmian w usługach systemowych,
- narzędzie instaluje wiele zależności i może wejść w konflikt z codziennym toolchainem,
- potrzebna jest konkretna dystrybucja Linuxa, wersja kernela albo duża ilość RAM i miejsca na dysku,
- zespół chce udostępnić działający prototyp bez wystawiania portu z komputera pracownika,
- po eksperymencie całe środowisko powinno zostać usunięte razem z tymczasową konfiguracją.
Osobna maszyna bywa też dobrym wyjściem przy ograniczeniach firmowego laptopa. Nie trzeba wtedy uzyskiwać wyjątku dla każdej biblioteki czy demona. Nadal obowiązują zasady organizacji dotyczące danych, licencji i połączeń sieciowych, lecz sam eksperyment nie zmienia lokalnej stacji roboczej.
Przed uruchomieniem zapisz hipotezę i warunki testu
Nieprecyzyjny cel prowadzi do maszyny, na której instaluje się kolejne narzędzia bez odpowiedzi na pierwotne pytanie. Jedno zdanie często wystarcza, na przykład: „Sprawdzamy, czy biblioteka X obsłuży nasz format danych w czasie krótszym niż pięć minut i bez własnych rozszerzeń”. Do zdania należy dopisać wersję oprogramowania, próbkę danych, plan pomiaru i wynik, który zakończy test.
Tak przygotowany opis pozwala dobrać zasoby. Test kompilacji potrzebuje czegoś innego niż analiza dużego zbioru danych. Eksperyment z usługą sieciową wymaga jawnej listy portów i odbiorców, a ocena narzędzia korzystającego z API wymaga kontrolowanych danych dostępowych. Parametry maszyny powinny wynikać z zadania, nie z chęci uruchomienia największej możliwej konfiguracji.
Izolacja ma konkretne granice
Maszyna wirtualna oddziela system operacyjny eksperymentu od komputera użytkownika, ale nie usuwa wszystkich zagrożeń. Kod nadal może wysyłać ruch do internetu, pobierać pakiety z zewnętrznych repozytoriów albo łączyć się z usługami firmowymi. Przed testem trzeba więc ustalić reguły ruchu wychodzącego, sposób przechowywania sekretów i rodzaj danych, które wolno skopiować.
Do proof of concept najlepiej używać danych syntetycznych lub zanonimizowanych. Klucze API powinny mieć minimalny zakres i czas ważności krótszy niż życie maszyny. Jeżeli eksperyment dotyczy narzędzia o nieznanym zachowaniu, sensowne jest ograniczenie sieci do niezbędnych adresów oraz zapisanie logów połączeń. Dostęp root daje swobodę, ale zwiększa odpowiedzialność za to, co zostanie uruchomione.
Snapshot nie zastępuje opisu eksperymentu
Snapshot pozwala szybko wrócić do ustalonego stanu, na przykład przed instalacją kolejnej wersji. Jest przydatny, gdy test obejmuje kilka wariantów i każdy powinien startować z tego samego punktu. Nie jest jednak dokumentacją. Po usunięciu maszyny zniknie razem z jej kontekstem, jeśli zespół nie zapisze poleceń, wersji i wyników w trwałym miejscu.
Minimalny zapis powinien zawierać identyfikator obrazu lub systemu, listę kluczowych pakietów, konfigurację testu, dane wejściowe, wynik oraz decyzję. Dla prototypu aplikacji warto zachować kod w repozytorium, a dla testu wydajności także parametry obciążenia i pomiary. Zrzut ekranu bez wersji narzędzi rzadko pozwala później powtórzyć eksperyment.
Czas zakończenia jest częścią projektu
Dobry sandbox ma datę wygaśnięcia. Przed nią osoba odpowiedzialna sprawdza, czy wynik trafił do repozytorium lub dokumentacji, czy dane robocze trzeba wyeksportować i czy użyte poświadczenia zostały unieważnione. Następnie maszyna może zostać wyłączona bez utrzymywania przypadkowej usługi, której nikt już nie obserwuje.
Model czasowy ułatwia również ocenę kosztu. Zamiast finansować infrastrukturę „na wszelki wypadek”, rezerwuje się zasoby na okres potrzebny do uzyskania odpowiedzi. Jeśli wynik uzasadnia dalszą pracę, kolejny etap powinien już mieć własny projekt: repozytorium, właściciela, środowisko integracyjne i zasady utrzymania.
Kiedy wybrać sandbox, a kiedy inną formę środowiska
Pojedynczy Sandbox VM pasuje do krótkiej pracy jednej osoby lub małego eksperymentu z pełnymi uprawnieniami. Gdy ten sam scenariusz ma wykonać kilkanaście osób, lepszy jest zestaw identycznych stanowisk utworzonych z jednej konfiguracji bazowej. Jeśli zaś wynik ma działać stale i obsługiwać proces zespołu, trzeba zaprojektować środowisko utrzymywane, a nie przedłużać życie prototypu.
Najważniejsze pytanie brzmi więc nie „czy potrzebujemy VM?”, lecz „jakiej decyzji ma dostarczyć ten eksperyment?”. Gdy odpowiedź jest konkretna, sandbox przyspiesza pracę. Gdy celu nie da się nazwać, osobna maszyna jedynie przenosi nieporządek w inne miejsce.