Ansible w zarządzaniu flotą serwerów VPS - od konfiguracji po monitoring
Zarządzanie wieloma serwerami VPS to wyzwanie, które rośnie wraz z liczbą maszyn. Ręczna konfiguracja, aktualizacje przez SSH do każdego serwera z osobna, czy weryfikacja stanu zabezpieczeń na kilkunastu maszynach - to scenariusze, które pochłaniają czas i zwiększają ryzyko błędu ludzkiego. Ansible oferuje eleganckie rozwiązanie tych problemów poprzez automatyzację zarządzania infrastrukturą jako kod.
Dlaczego Ansible?
Ansible wyróżnia się prostotą - nie wymaga instalacji agentów na zarządzanych serwerach, działa przez SSH, a playbooki zapisane w YAML są czytelne nawet dla osób rozpoczynających przygodę z automatyzacją. Do najczęstszych zastosowań należą:
- Automatyczne wdrażanie nowych serwerów - od instalacji pakietów, przez konfigurację firewalla, po deployment aplikacji.
- Konsystentna konfiguracja - zapewnienie, że wszystkie serwery mają identyczne ustawienia bezpieczeństwa i środowiska.
- Masowe aktualizacje - równoczesna aktualizacja systemu na wszystkich maszynach jednym poleceniem.
- Audyt i compliance - weryfikacja czy serwery spełniają wymagane standardy bezpieczeństwa.
- Zarządzanie użytkownikami i kluczami SSH - centralna kontrola dostępu do infrastruktury.
Połączenie Ansible z narzędziami takimi jak Git (wersjonowanie konfiguracji), Ansible Vault (szyfrowanie haseł), oraz Prometheus/Grafana (monitoring) tworzy kompletny ekosystem zarządzania infrastrukturą.
Case Study 1: Przygotowanie VPS pod wydajne środowisko API
Scenariusz
Klient potrzebuje serwera API obsługującego wysoką liczbę requestów. Wymaga to optymalnej konfiguracji systemu operacyjnego, serwera aplikacji, bazy danych oraz reverse proxy.
Rozwiązanie z Ansible
Tworzymy rolę api-server zawierającą:
# roles/api-server/tasks/main.yml
---
- name: Optymalizacja parametrów jądra dla wydajności
sysctl:
name: ""
value: ""
state: present
reload: yes
loop:
- { key: 'net.core.somaxconn', value: '65535' }
- { key: 'net.ipv4.tcp_max_syn_backlog', value: '8192' }
- { key: 'net.ipv4.ip_local_port_range', value: '1024 65535' }
- name: Instalacja i konfiguracja Nginx jako reverse proxy
apt:
name: nginx
state: present
notify: restart nginx
- name: Konfiguracja rate limiting i cachowania
template:
src: nginx-api.conf.j2
dest: /etc/nginx/sites-available/api
notify: reload nginx
- name: Instalacja i optymalizacja PostgreSQL
include_tasks: postgresql.yml
- name: Deployment aplikacji API z PM2
include_tasks: deploy-api.yml
W pliku group_vars/api_servers.yml definiujemy zmienne specyficzne dla środowiska:
nginx_worker_processes: auto
nginx_worker_connections: 4096
postgresql_max_connections: 200
postgresql_shared_buffers: "256MB"
api_instances: 4
Dzięki takiemu podejściu możemy w kilka minut wdrożyć kolejny identyczny serwer API lub wprowadzić zmianę konfiguracji na wszystkich serwerach jednocześnie.
Case Study 2: Bezpieczna brama dostępowa (bastion host)
Scenariusz
Firma potrzebuje serwera bastion jako jedynego punktu wejścia do wewnętrznej infrastruktury z zaawansowanymi mechanizmami bezpieczeństwa: fail2ban, port knocking, MFA, oraz szczegółowym logowaniem połączeń.
Rozwiązanie z Ansible
Playbook bastion-hardening.yml:
---
- hosts: bastion
become: yes
roles:
- system-hardening
- fail2ban-advanced
- port-knocking
- audit-logging
tasks:
- name: Konfiguracja SSH z restrykcyjnymi zasadami
lineinfile:
path: /etc/ssh/sshd_config
regexp: ""
line: ""
loop:
- { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
- { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
- { regexp: '^PubkeyAuthentication', line: 'PubkeyAuthentication yes' }
- { regexp: '^AuthenticationMethods', line: 'AuthenticationMethods publickey,keyboard-interactive' }
notify: restart ssh
- name: Instalacja i konfiguracja Google Authenticator dla MFA
apt:
name: libpam-google-authenticator
state: present
- name: Konfiguracja fail2ban dla SSH
template:
src: fail2ban-ssh.j2
dest: /etc/fail2ban/jail.d/sshd.local
notify: restart fail2ban
- name: Setup port knocking z knockd
template:
src: knockd.conf.j2
dest: /etc/knockd.conf
- name: Auditd dla szczegółowego logowania
apt:
name: auditd
state: present
- name: Reguły auditd dla monitorowania dostępu
copy:
src: audit-rules-bastion.rules
dest: /etc/audit/rules.d/bastion.rules
W roles/port-knocking/templates/knockd.conf.j2:
[options]
logfile = /var/log/knockd.log
[openSSH]
sequence =
seq_timeout = 15
command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags = syn
cmd_timeout = 30
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
Wrażliwe dane jak knock_sequence przechowujemy zaszyfrowane w Ansible Vault:
ansible-vault encrypt_string '7000,8000,9000' --name 'knock_sequence'
Case Study 3: Zarządzanie farmą serwerów - monitoring i aktualizacje
Scenariusz
Zarządzanie 20+ serwerami VPS wymaga ciągłego monitorowania, regularnych aktualizacji oraz szybkiej reakcji na incydenty. Potrzebujemy rozwiązania do zbierania metryk, centralizacji logów i automatyzacji rutynowych zadań.
Rozwiązanie z Ansible + Prometheus + Grafana
Krok 1: Deployment stack’u monitorującego
Playbook monitoring-stack.yml:
---
- hosts: monitoring_server
roles:
- prometheus
- grafana
- alertmanager
- loki
- hosts: all_vps
roles:
- node-exporter
- promtail
Krok 2: Automatyczne aktualizacje z weryfikacją
Playbook update-and-verify.yml:
---
- hosts: all_vps
serial: 3 # aktualizuj 3 serwery naraz
max_fail_percentage: 10
tasks:
- name: Weryfikacja dostępności przed aktualizacją
wait_for:
port: ""
timeout: 5
loop: ""
- name: Aktualizacja pakietów
apt:
update_cache: yes
upgrade: dist
autoremove: yes
register: update_result
- name: Sprawdzenie czy wymagany restart
stat:
path: /var/run/reboot-required
register: reboot_required
- name: Reboot jeśli konieczny
reboot:
reboot_timeout: 300
when: reboot_required.stat.exists
- name: Weryfikacja usług po aktualizacji
systemd:
name: ""
state: started
loop: ""
- name: Raport z aktualizacji
debug:
msg: "Serwer : pakietów zaktualizowanych"
Krok 3: Analiza logów i wykrywanie anomalii
# playbook: analyze-logs.yml
---
- hosts: all_vps
tasks:
- name: Zbieranie błędów z journald (ostatnie 24h)
shell: "journalctl --since '24 hours ago' --priority=err --no-pager"
register: errors
changed_when: false
- name: Analiza nieudanych logowań SSH
shell: "grep 'Failed password' /var/log/auth.log | tail -20"
register: failed_logins
changed_when: false
- name: Sprawdzenie zużycia dysku
shell: "df -h / | awk 'NR==2 {print $5}'"
register: disk_usage
changed_when: false
- name: Alert przy wysokim zużyciu dysku
debug:
msg: "UWAGA: - dysk zapełniony w "
when: disk_usage.stdout | replace('%','') | int > 85
- name: Generowanie raportu
template:
src: health-report.j2
dest: "/tmp/health-.txt"
delegate_to: localhost
Integracja z Prometheus
W roles/node-exporter/tasks/main.yml automatycznie konfigurujemy eksporter metryk na każdym VPS:
- name: Instalacja node_exporter
get_url:
url: https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
dest: /tmp/
- name: Konfiguracja jako systemd service
template:
src: node-exporter.service.j2
dest: /etc/systemd/system/node-exporter.service
notify: restart node-exporter
Prometheus automatycznie dodaje nowe serwery do monitoringu dzięki template’owi konfiguracji:
# roles/prometheus/templates/prometheus.yml.j2
scrape_configs:
- job_name: 'vps-fleet'
static_configs:
Dobre praktyki i podsumowanie
- Wersjonowanie w Git - wszystkie playbooki i role trzymaj w repozytorium z jasną strukturą katalogów.
- Ansible Vault - nigdy nie commituj haseł w plain text, używaj
ansible-vaultdo szyfrowania wrażliwych danych. - Role i collections - dziel kod na reużywalne komponenty, korzystaj z Ansible Galaxy.
- Testowanie - używaj
--checki--diffprzed wykonaniem zmian na produkcji. - Idempotentność - playbooki powinny dawać ten sam rezultat przy wielokrotnym uruchomieniu.
- Dokumentacja - każda rola powinna mieć README z opisem zmiennych i przykładami użycia.
Ansible w połączeniu z ekosystemem narzędzi DevOps przekształca zarządzanie serwerami VPS z czasochłonnego obowiązku w zautomatyzowany, przewidywalny proces. Początkowa inwestycja czasu w przygotowanie playbooków zwraca się wielokrotnie przy każdej kolejnej operacji na infrastrukturze - czy to wdrożenie nowego serwera, które zamiast godziny zajmuje 5 minut, czy masowa aktualizacja wykonana z pewnością, że wszystko zostało zrobione konsystentnie i zgodnie z najlepszymi praktykami.
Kontakt z nami
Jeśli jesteś zainteresowany/-a automatyzacją zarządzania infrastrukturą serwerową, napisz do nas.