Ansible dla serwerów Linux: konfiguracja jako kod w repozytorium

Opisujemy konfigurację Państwa serwerów Linux w Ansible, w repozytorium Git lub SVN z osobnymi inwentarzami dla produkcji i testów. Każdy szczegół konfiguracji jest wtedy udokumentowany, a każdy serwer da się odtworzyć w kilka minut, bez pamiętania, co ktoś kiedyś zmienił ręcznie.

  • Ansible z osobnymi inwentarzami dla produkcji i testów
  • Full stack i DevOps od 2012 r.
  • Repozytorium z reguły zostaje u Państwa

Gdzie stosujemy Ansible

Ansible opisuje konfigurację serwerów Linux w plikach tekstowych: pakiety, usługi, użytkowników i klucze SSH, pliki konfiguracyjne i reguły zapory. Pliki leżą w repozytorium Git lub SVN. Ansible łączy się z serwerami przez SSH i doprowadza je do opisanego stanu, bez osobnego agenta działającego na serwerach.

Ansible stosujemy przy serwerach, które dotąd utrzymywano ręcznie, i wszędzie tam, gdzie kilka serwerów ma być skonfigurowanych tak samo. Nasi inżynierowie pracują z Ansible i osobnymi inwentarzami dla produkcji i testów. Bieżące utrzymanie serwerów opisuje strona Linux & DevOps. Za pomocą Ansible jednolicie konfigurujemy też hosty dla Dockera i maszyny wirtualne na Proxmoksie, na przykład po przeniesieniu z hostingu do kontenera.

U góry kartka z pomarańczowym obrysem i trzema liniami; jedna linia rozgałęzia się do trzech jednakowych skrzynek, w każdej trzy poziome paski

Gdy serwery latami utrzymywano ręcznie

Ansible opłaca się przede wszystkim w takich sytuacjach:

  • Serwery skonfigurowano ręcznie, a ich konfiguracja istnieje tylko na samych serwerach.
  • Nikt nie wie dokładnie, co ostatnio zmieniono i dlaczego.
  • Środowisko testowe różni się od produkcji, a błędy wychodzą dopiero na produkcji.
  • Nowy administrator długo poznaje serwery, zanim może samodzielnie pracować.

Ręcznych zmian w praktyce nikt nie zapisuje, więc po kilku miesiącach nikt nie wie, co i na którym serwerze zmieniono, a wiedza o konfiguracji zanika. Z Ansible każda zmiana przechodzi przez repozytorium i zostaje tam zapisana jako commit z datą, autorem i opisem, a każdy szczegół konfiguracji jest udokumentowany i odtwarzalny. Przy pojedynczym serwerze, który rzadko się zmienia, nakład często się nie opłaca. Wtedy wystarczą dobra dokumentacja i runbook.

Pięć prostokątów w małej sieci: dwa narysowane ciągłą linią, trzy przerywaną, jakby nieznane; na jednym świeci pomarańczowa kropka

Typowe zadania z Ansible

  • Inwentaryzacja istniejących serwerów: pakiety, usługi, pliki konfiguracyjne, użytkownicy, zadania cron i reguły zapory.
  • Repozytorium Git lub SVN z rolami dla powtarzalnych elementów, takich jak serwer WWW, PHP lub Lucee, baza danych, wysyłka poczty, użytkownicy i dostęp SSH.
  • Osobne inwentarze dla produkcji i testów. Różnice, takie jak nazwy serwerów i adresy, są zapisane jako zmienne w danym inwentarzu.
  • Hasła i klucze zaszyfrowane w repozytorium zamiast zapisanych otwartym tekstem.
  • Wdrażanie aktualizacji i ustawień bezpieczeństwa, takich jak utwardzenie SSH i reguły zapory, na wielu serwerach, najpierw na serwerach testowych.
  • Przygotowanie serwerów pod Dockera i jednolita konfiguracja maszyn wirtualnych na Proxmoksie.
  • Dokumentacja w repozytorium i runbook dla Państwa zespołu.
Trzy różnie ukształtowane obudowy serwerów na jednej linii, nad nimi pomarańczowa kropka połączona z każdą z nich

Serwer, który da się odbudować z repozytorium

Przebieg Ansible zmienia tylko to, co odbiega od opisanego stanu, a drugi przebieg zaraz po nim nie zgłasza już zmian. Jeśli ktoś ręcznie zmienił opisane ustawienie, następny przebieg pokaże różnicę i przywróci opisany stan. Nowe role i zmiany sprawdzamy najpierw na serwerach testowych, a produkcja przychodzi potem, w oknie uzgodnionym z Państwem.

Gdy serwer ulegnie awarii albo przechodzi na nowy sprzęt lub do maszyny wirtualnej, jego konfigurację odtwarza się z repozytorium. Bazy danych i przesłane pliki nie należą do opisu, pochodzą z kopii zapasowej. Dlatego częścią całości są kopie zapasowe z testem odtworzenia. Repozytorium z reguły znajduje się u Państwa, więc nowy administrator lub inny dostawca sprawdzi w nim, jak skonfigurowano serwery.

Dwie szafy serwerowe z poziomymi slotami obok siebie, lewa narysowana przerywaną linią, prawa z pomarańczowym obrysem; strzałka w prawo i przerywana strzałka z powrotem w lewo; obie stoją na jednej linii z małym kółkiem

Jak wprowadzamy Ansible na istniejących serwerach

  1. Inwentaryzacja

    Spisujemy, co jest skonfigurowane na serwerach, i porównujemy test z produkcją. Listę różnic otrzymują Państwo na piśmie.

  2. Repozytorium i role

    Zakładamy repozytorium, z reguły po Państwa stronie, i opisujemy serwery w rolach oraz w osobnych inwentarzach dla produkcji i testów.

  3. Uzgodnienie na teście

    Stawiamy serwer testowy z opisu i porównujemy go z produkcją, aż każda różnica zostanie wyjaśniona.

  4. Pierwszy przebieg na produkcji

    Plan, termin i drogę powrotu uzgadniamy z Państwem wcześniej. Przed przebiegiem sprawdzamy kopię zapasową, a po nim usługi i aplikację.

  5. Dokumentacja i przekazanie

    W repozytorium opisujemy, jak uruchomić przebieg, jakie są inwentarze i gdzie leżą zaszyfrowane hasła. Do tego dochodzi runbook dla Państwa zespołu.

Powiązane sytuacje wyjściowe z serwerami

  • Wsparcie Debiana 11 zakończyło się 31.08.2026, a CentOS 7 już 30.06.2024 (stan: 2026-10). Zaktualizujemy Państwa serwer albo zaplanujemy i wykonamy przejście na Debiana. Pracujemy również z Proxmox VE 8 i z serwerami fizycznymi, które przenosimy na Proxmox.

  • Przenosimy Państwa aplikację w Lucee, ColdFusion lub PHP z klasycznego hostingu do kontenerów. Środowisko można wtedy odtworzyć, zaktualizować i przenieść na inny serwer. Część dostawców hostingu pobiera dopłaty za stare wersje PHP, a dla PHP 8.2 poprawki bezpieczeństwa kończą się 31.12.2026 (stan: 2026-10).

  • Państwa system działa, ale nikt nie zna go dokładnie. Spisujemy aplikację, bazę danych, serwer i pocztę, oceniamy ryzyka, na piśmie rekomendujemy dalszą drogę, a na życzenie przejmujemy utrzymanie systemu.

Pierwszy krok: przegląd serwera z pisemnym wynikiem

Przegląd serwera

Dla firm z serwerami Linux, których nikt już dokładnie nie zna: przed aktualizacją, po odejściu administratora albo gdy klient pyta o kopie zapasowe.

  • Wersja i stan wsparcia systemu operacyjnego i usług
  • Zabezpieczenie: dostęp SSH, zapora sieciowa, otwarte usługi i certyfikaty TLS
  • Aktualizacje: czego brakuje i jak były dotąd wdrażane
  • Kopie zapasowe: co jest zabezpieczane i czy test odtworzenia jest udokumentowany
  • Monitoring i logi: co jest monitorowane, a czego brakuje
  • Lista ustaleń według priorytetu

Na tym etapie niczego na serwerze nie zmieniamy. Aplikacja i kod nie należą do przeglądu, od tego jest Przegląd systemu legacy. Zakres i cenę ustalamy w rozmowie wstępnej i potwierdzamy na piśmie przed rozpoczęciem pracy. Na życzenie otrzymają Państwo potem ofertę stałej opieki.

Co zawiera wynik

Pisemna lista ustaleń według priorytetu z zaleceniami dotyczącymi zabezpieczenia, aktualizacji, kopii zapasowych i monitoringu oraz plan aktualizacji z oknami serwisowymi. Oba dokumenty należą do Państwa.

O co klienci często pytają przed startem

Co zrobić, jeśli brakuje nam danych dostępowych?

Zwykle da się to rozwiązać. Zaczynamy od tego, czym Państwo dysponują: umową i kontem u dostawcy hostingu, dostępem do domeny oraz, jeśli istnieją, repozytorium i kopiami zapasowymi. Dostęp do serwera często można zresetować przez dostawcę hostingu, jeśli występują Państwo jako strona umowy. Dostęp do systemu uzyskujemy wyłącznie za Państwa wyraźną zgodą.

Czy pracują Państwo z Jirą, Gitem i SVN?

Tak, z Gitem i z SVN. Zadania prowadzimy w Jirze lub w narzędziu, z którego Państwo już korzystają. Kod znajduje się w Państwa własnym repozytorium i pozostaje w Państwa rękach.

Co się stanie, gdy u Państwa ktoś będzie niedostępny?

Zastępstwo zapewniamy na życzenie. Dokumentację również przygotowujemy na życzenie, a repozytorium z reguły znajduje się u Państwa, dzięki czemu kod pozostaje w Państwa rękach. Jak współpracujemy, opisuje strona Współpraca.

Czy znają się Państwo na Linuksie i na Windows Server?

Linux jest naszą główną platformą: Debian i Ubuntu, serwery WWW, klastry baz danych i wirtualizacja na KVM i Proxmox. Windows Server z IIS obsługujemy na produkcji od 2015 r. Zalecamy przejście na Linuksa, chyba że Państwo wolą zostać przy Windows.

Kiedy mogą Państwo zacząć?

Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.

Jaka jest Państwa stawka godzinowa?

To zależy od zakresu, modelu współpracy i pilności. Prosimy krótko opisać Państwa sytuację, a po rozmowie otrzymają Państwo ofertę. Nie trzeba przy tym podawać budżetu. Stałe ceny podajemy przy produktach wejściowych.

Prosimy opisać serwery w trzech zdaniach

Wystarczy podać liczbę serwerów i system operacyjny, miejsce, w którym stoją (u Państwa lub u dostawcy hostingu), oraz to, czy istnieje już środowisko testowe.

Pola oznaczone jako „opcjonalnie” można zostawić puste.

Kontakt e-mailowy

Do kontaktu telefonicznego wystarczy numer: awarie całą dobę, w pozostałych sprawach w ciągu jednego dnia roboczego.

Jaki system, jaka technologia, co chcą Państwo osiągnąć? Prosimy nie przesyłać haseł ani poufnych dokumentów.

Odpowiedź w ciągu jednego dnia roboczego · bez zobowiązań

Wykorzystujemy Państwa dane wyłącznie do odpowiedzi na zapytanie. Prownex IT Services Sp. z o. o. jest administratorem danych. Okres przechowywania i Państwa prawa opisano w polityce prywatności.