Dziś na tapecie temat aktualizacji serwera WWW. Mowa o aktualizacjach związaną z ostatnimi błędami znalezionymi w HTTP/2. A chodzi o serwer nie byle jaki, bo oczywiście o devopsiarz.pl, jest to instancja w infrastrukturze hetznera, która jest utrzymywana w nazwijmy to filozofii immutable infrastructure.

Jak czytaliście ostatnio moją stronę, to wiecie, że spłodziłem artykuł o dosyć istotnym błędach w implementacjach protokołu http/2 w najpopularniejszych serwerach www, które zostały niedawno opisane. Tak się składa, że jeden z tych webserverów - caddy, odpowiada za moją stronę devopsiarz.pl, tym samym też stanąłem przed koniecznością jego aktualizacji, oczywiście chcąc być przykładnym adminem.

 

 

To, w jaki sposób ja tworzę stroną swoją, jest nieco wyjaśnione w filmie Devopsiarz robi frontend po devopsowemu. Tam tematem odcinka była inna strona, natomiast sama filozofia i użyte oprogramowanie w stosunku do devopsiarz.pl są w zasadzie takie same, więc jeżeli jeszcze nie widzieliście tego filmu to zachęcam do jego obejrzenia zanim obejrzycie ten.

Na sam początek, warto sobie wyjaśnić, co znaczy w ogóle immutable infrastructure. Są dwa sposoby podejścia do infrastruktury: mutable i immutable. Czyli mówiąc najprościej zmienialne i niezmienialne.

Podejście tzw. mutable jest rzekłbym podejściem najbardziej klasycznym. Czyli posiadacie serwer, na którym dziala demon serwera www, i jeśli ten program trzeba zaktualizować, po prostu to robicie. Np. aktualizujecie poprzez paczki systemowe, albo wgrywacie na serwer nową wersję, albo coś w tym stylu. Jeśli potrzeba aktualizacji pliku konfiguracyjnego, też to od razu robicie. Możecie to robić ręcznie, jak jaskiniowiec, albo np. wspomagać się jakimś toolem do provisionignu typu ansible, puppet, chef czy salt. To co jest istotne w tym podejściu, to to, że operujecie na działającym serwerze, wprowadzacie w jakieś nim zmiany.

Z kolei podejście immutable infrastructure zakłada, że jak raz utworzyliście instancję serwera, to nic na niej już nie zmieniacie. Każda zmiana, choćby dodanie tymczasowego pliku, każda aktualizacja, czy to konfiguracji działającego na nim oprogramowania, czy samego oprogramowania lub jego bibliotek, jest tak jakby utworzeniem zupełnie nowego serwera. Tylko, że ten nowy serwer jest tworzony z obrazu, na którym już jest wszystko zainstalowane i skonfigurowane tak jak powinno, słowem: gotowe do działania.

Do tworzenia takich obrazów jest używany np. hashcorp packer - to program, który wciela się w nas można by powiedzieć, znaczy się wskazujemy mu zadania np. w postaci skryptów shell i kolejności ich wykonania, a on, tworzy tymczasowy serwer, loguje się na niego, wykonuje te wszystkie zadania po czym wylogowuje się, wyłącza ten tymczasowy serwer i automatycznie robi jego obraz. Jeżeli na jakimś etapie jego pracy wystąpi jakiś błąd, nawet nic nie znaczący z naszego punktu widzenia, to operacja jest przerywana i obraz nie zostanie utworzony. Wtedy musimy sprawdzić, co się wywaliło i zazwyczaj nanieść poprawki w naszym skrypcie. Trochę to wygląda podobnie do działania Ansible.

Generalnie, jak obraz jest gotowy, to w większości providerów cloudowych możemy na podstawie utworzonego tak obrazu, uruchomić serwer. I ten nowy serwer, będzie miał wszystko tak, jak packer zrobił według naszych instrukcji.

Tu nasuwa się pytanie, które podejście jest lepsze i dlaczego. Oczywiście, nie ma tutaj jednoznacznej odpowiedzi, jak zresztą zawsze w IT. Wszystko zależy. Podczas praktykowania mutable infrastrukture czasem może coś pójść źle, w sensie będzie błąd managiera pakietów, albo aktualizacja się nie powiedzie, albo coś tam, już nie mówiąc o tym, że mogliście w trakcie działania serwera, coś tam sprawdzać w konfiguracji i cudować. To może prowadzić do wielu problemów. W przypadku immutable infrastrukture nie bawimy w zmienianie niczego, jak mamy obraz, to tworzymy serwer i tyle. Jak chcemy coś zmienić, to generujemy nowy obraz i to jest bardziej dopierdliwie niż prosta zmiana na serwerze, ale dzięki temu unikamy tego typu problemów.

I właśnie w filozofii immutable infrastructure jest utrzymywana moja instancja na której działa strona devopsiarz.pl, czyli ja utworzyłem zupełnie nowy obraz z zaktualizowanym serwerem www i w ogóle pakietami systemowymi. Ponieważ nie używam (na razie) load balancera, podmianę serwerów zrobiłem w taki sposób, że utworzę nowy serwer, a na starym, jeszcze działającym, wyłączyłem jedynie usługę noip, która rozgłaszała jego aktualny adres IP na który nazwa devopsiarz.pl dotychczas wskazywała. Po paru minutach, gdy nowoutworzony serwer ściągnął dane z wszystkich repozytoriów i wygenerował moją stronę, mogłem spokojnie wyłączyć dotychczasowy serwer jak gdyby nigdy nic (uwaga na logi i inne rzeczy jak ich gdzieś nie wysyłacie)