Co to są niezmienne serwery?

Istnieją pytania dotyczące niezmiennych serwerów , takie jak:

• Jak wdrożyć niezmienny wzorzec serwera bez utraty możliwości wykonywania sekcji zwłok?
• Jaką rolę odgrywają narzędzia do zarządzania konfiguracją w niezmiennej infrastrukturze?

Wydaje się oczywiste, że ma to związek z serwerami (tę część otrzymuję). I po prostu trawiąc gramatykę niezmiennego , pomyślałbym, że ma to coś wspólnego z „niemożliwym do wyciszenia ”. Jeśli to przypuszczenie jest bliskie, nie miałbym pojęcia, czego dokładnie nie można wyciszyć (i wątpię, by miało to związek z kartami dźwiękowymi lub czymś ...).

Moje pytania :

• Co to właściwie są „niezmienne serwery” (w kontekście DevOps)?
• Dlaczego są używane?

Niezmienność to termin często używany w kręgach informatyki, który ogólnie sprowadza się do „niemożliwości zmiany po stworzeniu”. Jest zwykle używany w odniesieniu do równoległości, współbieżności i bezpieczeństwa wątków.

Dyskusja na ten temat jest fascynująca, ale ogólnie można ją znaleźć gdzie indziej w Stack Overflow . Opieram się chęci zanurzenia się tutaj. Kluczowej koncepcji nie można zmienić po utworzeniu.

Wyobraź sobie, że w Amazon wdrażasz usługę internetową, wypiekając ją do obrazu maszyny (AMI - wstępnie zbudowana instancja, którą możesz wielokrotnie ponownie rezerwować). Łączy się z bazą danych zaplecza za pomocą poświadczeń, które otrzymuje z rejestru podczas uruchamiania. Zrzuca dzienniki do narzędzia rejestrującego, takiego jak Splunk. Do normalnej codziennej pracy nie ma powodu, aby ssh w tym polu. Jeśli chcesz zwiększyć tę usługę, po prostu utwórz więcej instancji tego interfejsu AMI i dostosuj moduł równoważenia obciążenia. Obalenie go to po prostu zniszczenie instancji i modułów równoważenia obciążenia.

W codziennej pracy to pole nie ma powodu do zmiany . Możemy po prostu wystrzelić więcej z AMI.

Co się stanie, gdy konieczne będzie dostarczenie poprawki zabezpieczeń na poziomie systemu operacyjnego? Wtedy musisz podjąć decyzję ... czy upieczesz nowy AMI z zainstalowaną łatką i ponownie wdrożysz wszystkie działające instancje, czy też ssh do istniejących obrazów i zaktualizujesz łatkę? Jest wielu ludzi, którzy po prostu wślizgnęliby się do środka. Zwolennicy „niezmiennej architektury” krzyczeli na mnie, nawet sugerując, że coś takiego jest możliwe.

Immutabiliści (jeśli istnieje takie słowo) opowiadają się za pieczeniem nowego ami. Opowiadają się za usunięciem jakiegokolwiek powodu, aby ssh w maszynie kiedykolwiek. Opowiadają się za tym, aby każda konkretna konfiguracja komputera miała miejsce podczas uruchamiania tej maszyny poprzez wyciągnięcie szczegółów konfiguracji z repozytorium. Jest to ostateczny wyraz „bydła, a nie zwierząt domowych”.

Architektura niezmienna dotyczy w szczególności konfiguracji maszyn, które nie mają powodu zmieniać po utworzeniu obrazu maszyny . Jeśli coś wymaga zmiany, upiecz nowy obraz instancji, zamknij stary, przywołaj nowy.

Technologie w chmurze przesunęły granicę między sprzętem a oprogramowaniem, tak że wiele operacji technicznych, które wcześniej były wyłącznym obywatelem świata sprzętu komputerowego, również podlegają sferze oprogramowania. Współdzielone środowiska komputerowe mogą być tak stare jak same komputery ^1, ale technologie chmurowe mogą je spopularyzować, oferując wygodne i znane metafory do interakcji z nimi: użytkownicy chmury rezerwują instancję, kompletny komputer lub naśladownictwo, podczas gdy starsze udostępnione środowiska komputerowe mają wszystkie możliwe ustawienia nieporęcznych ograniczeń i „Twój program musi zostać załadowany na ten serwer FTP, będzie działał w środowisku X (zwykle z 10-letnią wersją dowolnego oprogramowania, którego chcesz używać), przez co najwyżej 60 minut” może brzmieć znajomo dla byłych lub rzeczywistych użytkowników centrów obliczeniowych.

Praktyczną konsekwencją tej zmiany jest to, że procedury wdrażania mogą być teraz reprezentowane przez artefakty oprogramowania. (Procedury wdrażania to instrukcje informujące o tym, jak skonfigurować infrastrukturę z bazami danych, serwerami internetowymi lub czymkolwiek należącym do tej infrastruktury, a także siecią, w której działają). W przypadku tych nowych soczewek ręczna konserwacja serwerów wygląda prawie jak ręczne łatanie kodu produkcyjnego - co w bardzo rzadkich przypadkach jest pożądane. Ręczna konserwacja jest podatna na wprowadzanie rozbieżności między systemami faktycznie działającymi w produkcji a kodem opisującym te systemy, co z kolei oznacza nieodwracalne zachowanie i niemożliwą analizę błędów, podwójne usuwanie błędów i inne nieszczęścia.

Niezmienny wzorzec serwer jest po prostu transpozycja do operacji chmura powyższym mantry, według których powinniśmy unikać konserwacji uruchomionych programów. Zamiast ręcznej konfiguracji serwerów, niezmienny wzorzec serwera zaleca zautomatyzowanie tej konfiguracji.

Smaki wdrożeniowe

Chociaż ogólna idea niezmiennego wzorca serwera jest dość jasna, istnieje wiele niuansów implementacyjnych. Na przykład niektóre podejścia sugerują, aby w ogóle nie aktualizować serwerów, ale zamiast tego systematycznie je zastępować . Jest tak, ponieważ aktualizacja powoduje sytuację, w której wdrożenie polega na tym, że serwery zostały uruchomione kilkakrotnie i przeszły przez kilka różnych procesów aktualizacji, co implikuje niejednorodny zestaw serwerów i może prowadzić do subtelnych różnic w sposobie obsługi zadań przez serwery. Drugim popularnym wariantem jest dyscyplina dotycząca zdalnego dostępu do serwerów. Niektórzy lubią całkowicie wyłączać zdalny dostęp administracyjny do serwerów, aby zagwarantować, że ręczna konserwacja nigdy nie nastąpi.

Notatka historyczna

Według mojej najlepszej wiedzy, „niezmienny serwer” został spopularyzowany przez Kief Morrisa, ale sam pomysł jest znacznie starszy. W 1999 roku więzienia FreeBSD spopularyzowały już ideę pełnej automatyzacji konfiguracji jednorazowych środowisk obliczeniowych. W ten sposób zacząłem wdrażać wzorzec „niezmiennego serwera” wiele lat, zanim usłyszałem tę nazwę, aby opisać tę technikę.

Niezmienność, w formie fizycznej niezmienności opartej na dyskach CD-ROM, jest również popularnym środkiem produkcji zaufanych systemów komputerowych. Nie należy tego mylić z niezmiennym wzorcem serwera.

Niezmienne serwery to serwery, na których nie można dokonywać żadnych zmian (najlepiej poza aktualizacjami i łatkami bezpieczeństwa). Zamiast zmieniać oprogramowanie na serwerze, buforujesz nowy serwer z pożądanym oprogramowaniem, a następnie zamykasz starszy.

Ta koncepcja pomaga upewnić się, że serwer testowy, programistyczny i QA są identyczne, co jest ważne z wielu powodów poza zakresem tego pytania. Kolejną zaletą niezmiennych serwerów jest możliwość przywrócenia aplikacji na starszy serwer. Na przykład muszę zmienić K na serwerze produkcyjnym 1, więc buforuję serwer 2 i zmieniam K. Teraz po 10 minutach zauważam, że K zepsuł się w mojej aplikacji, zamiast konieczności natychmiastowej naprawy, co może zająć godziny i potencjalnie może powodować przestoje u moich klientów, przekierowuję ruch z powrotem na serwer 1, podczas gdy zastanawiam się, co jest nie tak z 2.

Najlepsze wyjaśnienie można znaleźć (jak zawsze) w artykule Bliki Martina Fowlera na temat niezmiennych serwerów .

Serwer, czy to sprzętowy, czy wirtualny serwer w chmurze, zazwyczaj ma system operacyjny i działającą na nim aplikację.

Często aplikacja i komponenty systemu operacyjnego wymagają konfiguracji i wymagają wprowadzenia zmian. Na przykład łatki bezpieczeństwa, wdrażanie nowych wersji aplikacji i zmiany konfiguracji.

Kiedy weźmiesz pod uwagę, że jakakolwiek zmiana jest mutacją stanu serwera, termin ten immutablezaczyna mieć sens. Oznacza to, że na takim serwerze nie są dozwolone żadne mutacje .

Często dzieje się tak, gdy ludzie są zaangażowani w zmianę stanu serwera - może to być wdrożenie wersji, zmiana konfiguracji lub ścieżka bezpieczeństwa. W rezultacie serwer przestaje działać zgodnie z oczekiwaniami. Na przykład aplikacja może nie działać teraz z powodu błędnej konfiguracji itp.

Dlatego ustanowiono praktykę tworzenia niezmiennych serwerów. W przypadku niezmiennych serwerów tworzony jest obraz serwera wraz ze wszystkimi konfiguracjami, łatami i wersjami aplikacji. Następnie ten obraz serwera można wykorzystać do tworzenia serwerów w różnych środowiskach.

Pierwszym środowiskiem, w którym taki obraz jest używany, byłoby środowisko, w którym obraz można przetestować pod kątem działania. Wszelkie nieprawidłowości są wykrywane, a dopiero potem taki obraz może być promowana w środowisku produkcyjnym zastąpić serwery tam z nowej wersji (która jest znana do pracy dobrze).

Po zautomatyzowaniu procesu tworzenia obrazów i promowania obrazów otrzymujesz proces bardzo odporny na awarie, który wymaga niewielkiego wysiłku ludzkiego i bardzo małej szansy na wprowadzenie awarii do usługi.

Często niezmienne serwery nie zawierają nawet żadnego sposobu „wejścia” na nie, na przykład brakuje serwera ssh. W takim przypadku często zdarza się, że cała metrologia serwera (metryki, logi) jest wysyłana do systemów zewnętrznych, takich jak baza danych metryk lub usługa agregacji logów.

W przypadku kontenerów (patrz: Docker ) istnieje również proces tworzenia obrazów, a następnie odradzania ich do działających kontenerów. Są one często zastępowane nowymi kontenerami opartymi na zaktualizowanych obrazach i nigdy nie są mutowane. Oznacza to, że żaden człowiek nie wchodzi do pojemnika, aby „coś naprawić”, wprowadzając zmianę.

Zacznijmy od odwrotności, czym jest zmienny serwer?

Tradycyjnie, zmienna infrastruktura serwerowa to taka, która jest ciągle modyfikowana i aktualizowana. Możesz zabezpieczyć w nim powłokę, uaktualnić pakiety, skonfigurować ją, zainstalować usługi i wdrożyć do niej nowy kod. To sprawia, że ​​można go modyfikować, możesz go mutować lub modyfikować.

Niezmienna infrastruktura to kolejny paradygmat infrastruktury, w którym serwery nigdy nie są modyfikowane po ich wdrożeniu. Jeśli coś wymaga aktualizacji, naprawy lub modyfikacji w jakikolwiek sposób, nowe serwery zbudowane ze wspólnego obrazu z odpowiednimi zmianami są zastępowane starymi. Po zatwierdzeniu są one wykorzystywane, a stare są wycofywane z eksploatacji.

Dlaczego są używane? Korzyści z niezmiennej infrastruktury to większa spójność i niezawodność infrastruktury oraz prostszy, bardziej przewidywalny proces wdrażania i łagodzący typowe problemy z serwerami w modyfikowalnej infrastrukturze, takie jak przestoje z powodu awarii serwera lub cokolwiek innego.

Ale musisz wiedzieć, jak efektywnie zapewnić to za pomocą kompleksowej automatyzacji wdrażania i szybkiego udostępniania serwera.

Wyobraź sobie, że wydobywasz bitcoiny, nie chciałbyś mieć żadnych przestojów, gdyby twój serwer się zawiesił, potrzebujesz kopii zapasowej tak szybko, jak to możliwe, więc niezmienna infrastruktura powinna być rozwiązaniem.