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.
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żą:
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ą.
Klient potrzebuje serwera API obsługującego wysoką liczbę requestów. Wymaga to optymalnej konfiguracji systemu operacyjnego, serwera aplikacji, bazy danych oraz reverse proxy.
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.
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ń.
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'
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ń.
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:
ansible-vault do szyfrowania wrażliwych danych.--check i --diff przed wykonaniem zmian na produkcji.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.
Jeśli jesteś zainteresowany/-a automatyzacją zarządzania infrastrukturą serwerową, napisz do nas.