deskryptor wdrożenia artykuł
Deskryptor wdrożenia w aplikacjach webowych
27 kwietnia 2017
String cache StringBuilder artykuł
String cache i StringBuilder w praktyce
6 maja 2017
Konfiguracja Puppet artykuł

We wpisie tym podsumowuję postęp prac nad projektem Pogodynka. W tym tygodniu wyłącznie devops. Pokrótce opiszę Ci moje przygody z konfiguracją VPS przy pomocy Puppet’a.

Konfiguracja maszyny produkcyjnej

Chociaż do konfiguracji produkcyjnej daleko, będę tutaj pisał o “serwerze produkcyjnym”. Mam tu na myśli VPS (ang. Virtual Private Server), na którym uruchomiona będzie baza danych oraz Tomcat. To właśnie do tej maszyny Malinka wysyłała będzie informacje o odczytach temperatury. Ta sama maszyna posłuży do uruchomienia aplikacji webowej pokazującej interfejs użytkownika.

Namiastka produkcji

Konfiguracja ta nijak nie przypomina “produkcji z prawdziwego zdarzenia”. Nie ma tu mowy o sensownym monitorowaniu czy zapewnieniu niezawodności. Mam świadomość tych niedociągnięć :). Jak na hobbystyczny projekt konfiguracja tego typu powinna być wystarczająco dobra. Oczywiście przy takiej konfiguracji nie zapewnię dostępności na poziomie pięciu dziewiątek (nawet, chyba dwóch nie dałbym rady ;)).

Aby poprawić tę konfigurację musiałbym poświęcić na nią więcej czasu i zapłacić więcej za utrzymanie finalnego środowiska. “Budżetu” na Pogodynkę, nie chciałbym powiększać, więc zostanę przy aktualnych ustawieniach. Akceptuję te niedociągnięcia z racji tego, że projekt ten nie jest krytyczny.

Zarządzanie konfiguracją

Mógłbym skonfigurować maszynę ręcznie. Na pewno byłoby to szybsze niż zabawa, którą zaraz opiszę. Jednak tego typu podejście prowadzi do sytuacji, w której odtworzenie konfiguracji jest ciężkie. Chciałbym tego uniknąć.

Konfiguracja maszyny produkcyjnej zarządzana jest przy pomocy Puppet’a. Całość trzymana jest w repozytorium razem z kodem. Dzięki takiemu podejściu wiem dokładnie co, jak i kiedy zostało zmienione. A co najważniejsze mogę tę konfigurację szybko odtworzyć.

Czym jest Puppet

Puppet to narzędzie, które pomaga zarządzać konfiguracją maszyn. Puppet używa tak zwanych manifestów, które określają konfigurację danej maszyny. Wewnątrz manifestów używany jest DSL (ang. Domain Specific Language), który ułatwia tę konfigurację.

Przy pomocy tego narzędzia i odpowiednich manifestów możemy na przykład zainstalować bazę danych, odpowiednią wersję Javy czy Tomcat’a.

Manifesty z konfiguracją pakowane są w tak zwane moduły. W moim przypadku używam na przykład modułów do instalacji Tomcat’a czy zarządzania regułami firewalla. Mogę śmiało powiedzieć, że konfiguracja większości standardowych rzeczy dostępna jest w odpowiednim module.

Kod odpowiedzialny za konfigurację

Aby niepotrzebnie nie komplikować sprawy uruchamiam Puppeta w trybie “samodzielnym”. Nie ma tutaj standardowej maszyny, z której pobierana jest konfiguracja („puppet mastera”). Jest to uproszczenie, które w tym przypadku jest akceptowalne.

Cały katalog modułów trzymam w repozytorium git. Zewnętrzne moduły puppeta dodałem do repozytorium jako submoduły git’a.

Dzięki takiemu podejściu zawsze (jak tylko github i repozytoria modułów są dostępne ;)) mam dostęp do całości konfiguracji.

Konfiguracja przy pomocy Puppet’a

Wykupiłem VPS w jednej z firm. Zainstalowałem tam obraz z Debianem Jessie. W tym miejscu zaczyna się zabawa ;).

Instalacja Javy

Zacznijmy od Javy. Instalacja Javy 8 na Debianie 8 nie jest trywialna :). Chodzi mi tu o Javę od Oracle. OpenJDK można zainstalować z “backports”. Po zabawie z kluczami do apt udało mi się Javę zainstalować:

Tomcat

Podobnie jak w przypadku firewalla użyłem istniejącego modułu.

Cała konfiguracja sprowadza się do kilku linijek:

Sam Tomcat uruchamiany jest z poziomu użytkownika tomcat. Z tego powodu nie mogę uruchomić go tak aby nasłuchiwał na domyślnym porcie HTTP. Tomcat słucha na 8080.

Firewall

Podobnie jak w przypadku Tomcat’a użyłem istniejącego modułu. Oczywiście nie chcę otwierać na świat serwera produkcyjnego. Sytuacja, w której na przykład baza danych była dostępna z zewnątrz jest zła. Domyślnie chcę mieć otwarty mały podzbiór portów. Oczywiście standardowy port 80 dla HTTP i 22 dla SSH potrzebuję, resztę trzeba wyciąć.

To się musiało stać, w trakcie zabawy z konfiguracją firewall odciąłem sobie dostęp po SSH. Skończyło się to reinstalacją Debiana na nowo. Całe szczęście cała konfiguracja trzymana jest w repozytorium więc odtworzenie poprzedniego stanu sprowadziło się do kilku komend:

Poza wycięciem portów za pomocą konfiguracji firewalla będę musiał zrobić przekierowanie ruchu z portu 80 na 8080. Ta część jeszcze przede mną ;).

Podsumowanie

Konfiguracja jeszcze nie jest gotowa. Jeśli chcesz zobaczyć jej aktualną wersję możesz rzucić okiem na samouczkowego githuba. Jeszcze męczę się z dopięciem niektórych elementów. W każdym razie postęp, mały bo mały, jest. Do końca projektu zostały jeszcze trzy tygodnie. Trzymaj za mnie kciuki ;). Do następnego razu!

Newsletter

  Jeśli chcesz otrzymywać informacje o nowych artykułach na blogu prosto na Twój email, zapisz się 🙂

Zdjęcie dzięki uprzejmości https://www.flickr.com/photos/joseywales/316407052/sizes/o/