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.
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.
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.
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.
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.
Jak wprowadzamy Ansible na istniejących serwerach
-
Inwentaryzacja
Spisujemy, co jest skonfigurowane na serwerach, i porównujemy test z produkcją. Listę różnic otrzymują Państwo na piśmie.
-
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.
-
Uzgodnienie na teście
Stawiamy serwer testowy z opisu i porównujemy go z produkcją, aż każda różnica zostanie wyjaśniona.
-
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ę.
-
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
-
-
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.