Intégrations
BunkerWeb Cloud
BunkerWeb Cloud est une solution gérée de Web Application Firewall (WAF) et de reverse proxy qui vous permet de sécuriser vos applications web sans installer BunkerWeb dans votre infrastructure. En souscrivant à BunkerWeb Cloud, vous bénéficiez d'une pile BunkerWeb complète hébergée dans le cloud avec des ressources dédiées (8 Go de RAM, 2 CPU par instance, répliqué sur 2 instances pour la haute disponibilité, offre Standard).
Avantages clés
Commandez votre instance BunkerWeb Cloud et accédez à :
- Déploiement instantané : Aucune installation requise dans votre infrastructure
- Haute disponibilité : Instances répliquées avec équilibrage de charge automatique
- Surveillance intégrée : Accès à Grafana pour la visualisation des journaux et des métriques
- Scalabilité : Ressources dédiées adaptées aux charges de travail importantes
- Sécurité renforcée : Protection WAF en temps réel contre les menaces web
Si vous êtes intéressé par l'offre BunkerWeb Cloud, n'hésitez pas à nous contacter afin que nous puissions discuter de vos besoins.
Vue d'ensemble de l'architecture
Architecture simple - Service unique
graph LR
A[Client] -->|HTTPS| B[exemple.com]
B -->|Résolution DNS| C[Load Balancer54984654.bunkerweb.cloud]
C -->|Trafic| D[BunkerWeb CloudWAF + Reverse Proxy]
D -->|HTTPS/HTTP| E[Serveur exemple.comInfrastructure Client]
style C fill:#e1f5fe,color:#222
style D fill:#f3e5f5,color:#222
style E fill:#e8f5e8,color:#222Architecture complexe - Multi-services
graph LR
A[Clients] -->|HTTPS| B[exemple.comautre-exemple.comun-autre-exemple.com]
B -->|Résolution DNS| C[Load Balancer54984654.bunkerweb.cloud]
C -->|Trafic| D[BunkerWeb CloudWAF + Reverse ProxySSL SNI Activé]
D -->|HTTPS avec SNI| E[Gateway ClientReverse Proxy/LB]
E -->|Routage interne| F[Service 1]
E -->|Routage interne| G[Service 2]
E -->|Routage interne| H[Service N]
style C fill:#e1f5fe,color:#222
style D fill:#f3e5f5,color:#222
style E fill:#fff3e0,color:#222
style F fill:#e8f5e8,color:#222
style G fill:#e8f5e8,color:#222
style H fill:#e8f5e8,color:#222Configuration initiale
1. Accès à l'interface de gestion
Après avoir souscrit à BunkerWeb Cloud, vous recevrez :
- URL d'accès à l'UI BunkerWeb : Interface pour configurer vos services
- Point de terminaison Load Balancer : URL unique au format
http://[ID].bunkerweb.cloud - Accès Grafana : Interface de surveillance et visualisation des métriques
- Ressources allouées : 2 instances avec 16 Go de RAM et 4 CPU chacune
2. Première connexion
- Connectez-vous à l'interface BunkerWeb Cloud
- Configurez vos services à protéger
- Accédez à Grafana pour visualiser vos journaux et métriques BunkerWeb
Configuration DNS
Redirection du trafic vers BunkerWeb Cloud
Pour que le trafic de votre domaine soit traité par BunkerWeb Cloud, vous devez configurer vos enregistrements DNS :
Configuration requise :
exemple.com. IN CNAME 54984654.bunkerweb.cloud.
www.exemple.com. IN CNAME 54984654.bunkerweb.cloud.
Important : Remplacez 54984654 par votre identifiant de load balancer fourni lors de la souscription.
Validation de la configuration
Vérifiez la résolution DNS :
dig exemple.com
nslookup exemple.com
Le résultat doit pointer vers votre point de terminaison BunkerWeb Cloud.
Configuration du service
Service unique
Pour un service simple hébergé sur votre infrastructure :
Configuration dans l'UI BunkerWeb :
- Server Name :
exemple.com - Use Reverse Proxy :
yes - Reverse Proxy Host :
185.87.1.100:443(IP de votre serveur)
Vous pouvez trouver toutes les options de configuration dans la Documentation Reverse Proxy
Multi-services avec SNI
Pourquoi activer le SNI ?
Le Server Name Indication (SNI) est essentiel lorsque :
- Plusieurs domaines pointent vers la même infrastructure backend
- Votre infrastructure héberge plusieurs services avec des certificats SSL distincts
- Vous utilisez un reverse proxy/gateway côté client
Configuration SNI
Dans l'UI BunkerWeb, pour chaque service :
# Service 1
SERVICE_NAME: exemple-com
SERVER_NAME: exemple.com
REVERSE_PROXY_HOST: https://gateway.interne.domaine.com
REVERSE_PROXY_PORT: 443
REVERSE_PROXY_SSL_SNI: yes
REVERSE_PROXY_SSL_SNI_NAME: exemple.com
# Service 2
SERVICE_NAME: autre-exemple-com
SERVER_NAME: autre-exemple.com
REVERSE_PROXY_HOST: https://gateway.interne.domaine.com
REVERSE_PROXY_PORT: 443
REVERSE_PROXY_SSL_SNI: yes
REVERSE_PROXY_SSL_SNI_NAME: autre-exemple.com
Vous pouvez trouver toutes les options de configuration dans la Documentation Reverse Proxy
Détails techniques SNI
Le SNI permet à BunkerWeb Cloud de :
- Identifier le service cible lors de la connexion TLS
- Transmettre le bon nom de domaine au backend
- Permettre au gateway client de sélectionner le bon certificat
- Router correctement vers le service approprié
Sans SNI activé :
graph LR
A[Client] --> B[BunkerWeb]
B --> C["Gateway (certificat par défaut)"]
C --> D[Erreur SSL]
style B fill:#f3e5f5,color:#222
style C fill:#fff3e0,color:#222
style D fill:#ff4d4d,color:#fff,stroke:#b30000,stroke-width:2pxAvec SNI activé :
graph LR
A[Client] --> B[BunkerWeb]
B --> C["Gateway (certificat spécifique exemple.com)"]
C --> D[Service Correct]
style B fill:#f3e5f5,color:#222
style C fill:#e8f5e8,color:#222
style D fill:#e8f5e8,color:#222Gestion SSL/TLS et SNI
Certificats SSL
Côté BunkerWeb Cloud
BunkerWeb Cloud gère automatiquement :
- Les certificats Let's Encrypt pour vos domaines
- Le renouvellement automatique
- La configuration TLS optimisée
Côté Infrastructure Client
Recommandations importantes :
- Utilisez HTTPS pour la communication entre BunkerWeb et vos services
- Gérez vos propres certificats sur votre infrastructure
- Configurez correctement le SNI sur votre gateway/reverse proxy
Configuration SNI détaillée
Cas d'usage : Infrastructure avec Gateway
Si votre architecture ressemble à :
graph LR
A[BunkerWeb Cloud] --> B[Gateway Client]
B --> C[Service 1]
B --> D[Service 2]
B --> E[Service 3]
style A fill:#f3e5f5,color:#222
style B fill:#fff3e0,color:#222
style C fill:#e8f5e8,color:#222
style D fill:#e8f5e8,color:#222
style E fill:#e8f5e8,color:#222Configuration requise côté BunkerWeb :
# Configuration pour exemple.com
REVERSE_PROXY_SSL_SNI: yes
REVERSE_PROXY_SSL_SNI_NAME: exemple.com
REVERSE_PROXY_SSL_VERIFY: no # Si certificat auto-signé côté client
REVERSE_PROXY_HEADERS: Host $host
# Configuration pour api.exemple.com
REVERSE_PROXY_SSL_SNI: yes
REVERSE_PROXY_SSL_SNI_NAME: api.exemple.com
REVERSE_PROXY_SSL_VERIFY: no
REVERSE_PROXY_HEADERS: Host $host
Configuration Gateway Client
Vue d'ensemble
Lorsque votre architecture utilise un gateway/reverse proxy côté client pour router le trafic vers plusieurs services, une configuration spécifique est nécessaire pour supporter le SNI et assurer une communication sécurisée avec BunkerWeb Cloud.
Configurations par technologie
Nginx
Configuration Nginx
# Configuration pour supporter SNI avec plusieurs services
server {
listen 443 ssl http2;
server_name exemple.com;
ssl_certificate /path/to/exemple.com.crt;
ssl_certificate_key /path/to/exemple.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
# En-têtes de sécurité
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
location / {
proxy_pass http://service1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
# Timeouts
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}
server {
listen 443 ssl http2;
server_name api.exemple.com;
ssl_certificate /path/to/api.exemple.com.crt;
ssl_certificate_key /path/to/api.exemple.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
location / {
proxy_pass http://api-service:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Configuration spécifique API
proxy_buffering off;
proxy_request_buffering off;
}
}
Traefik
Configuration Traefik
**Avec Docker Compose :**services:
traefik:
image: traefik:v3.0
command:
- --api.dashboard=true
- --providers.docker=true
- --providers.file.filename=/etc/traefik/dynamic.yml
- --entrypoints.websecure.address=:443
- --certificatesresolvers.myresolver.acme.tlschallenge=true
- --certificatesresolvers.myresolver.acme.email=admin@exemple.com
- --certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json
ports:
- "443:443"
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./letsencrypt:/letsencrypt
- ./dynamic.yml:/etc/traefik/dynamic.yml:ro
labels:
- "traefik.enable=true"
- "traefik.http.routers.dashboard.rule=Host(`traefik.exemple.com`)"
- "traefik.http.routers.dashboard.tls.certresolver=myresolver"
service1:
image: your-app:latest
labels:
- "traefik.enable=true"
- "traefik.http.routers.service1.rule=Host(`exemple.com`)"
- "traefik.http.routers.service1.entrypoints=websecure"
- "traefik.http.routers.service1.tls.certresolver=myresolver"
- "traefik.http.services.service1.loadbalancer.server.port=8080"
- "traefik.http.routers.service1.middlewares=security-headers"
api-service:
image: your-api:latest
labels:
- "traefik.enable=true"
- "traefik.http.routers.api.rule=Host(`api.exemple.com`)"
- "traefik.http.routers.api.entrypoints=websecure"
- "traefik.http.routers.api.tls.certresolver=myresolver"
- "traefik.http.services.api.loadbalancer.server.port=3000"
- "traefik.http.routers.api.middlewares=security-headers,rate-limit"
http:
middlewares:
security-headers:
headers:
frameDeny: true
contentTypeNosniff: true
browserXssFilter: true
forceSTSHeader: true
stsIncludeSubdomains: true
stsPreload: true
stsSeconds: 31536000
customRequestHeaders:
X-Forwarded-Proto: "https"
rate-limit:
rateLimit:
burst: 100
average: 50
routers:
service1:
rule: "Host(`exemple.com`)"
service: "service1"
tls:
certResolver: "myresolver"
middlewares:
- "security-headers"
api:
rule: "Host(`api.exemple.com`)"
service: "api-service"
tls:
certResolver: "myresolver"
middlewares:
- "security-headers"
- "rate-limit"
services:
service1:
loadBalancer:
servers:
- url: "http://service1:8080"
healthCheck:
path: "/health"
interval: "30s"
api-service:
loadBalancer:
servers:
- url: "http://api-service:3000"
healthCheck:
path: "/api/health"
interval: "30s"
Apache
Configuration Apache
# Configuration Apache avec SNI
<VirtualHost *:443>
ServerName exemple.com
DocumentRoot /var/www/html
# Configuration SSL
SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off
SSLCertificateFile /path/to/exemple.com.crt
SSLCertificateKeyFile /path/to/exemple.com.key
# En-têtes de sécurité
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
Header always set X-XSS-Protection "1; mode=block"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Configuration reverse proxy
ProxyPass / http://service1:8080/
ProxyPassReverse / http://service1:8080/
ProxyPreserveHost On
# En-têtes personnalisés
ProxyPassReverse / http://service1:8080/
ProxyPassReverseInterpolateEnv On
<Proxy *>
Require all granted
</Proxy>
# Logs
ErrorLog ${APACHE_LOG_DIR}/exemple.com_error.log
CustomLog ${APACHE_LOG_DIR}/exemple.com_access.log combined
</VirtualHost>
<VirtualHost *:443>
ServerName api.exemple.com
SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLCertificateFile /path/to/api.exemple.com.crt
SSLCertificateKeyFile /path/to/api.exemple.com.key
ProxyPass / http://api-service:3000/
ProxyPassReverse / http://api-service:3000/
ProxyPreserveHost On
# Configuration spécifique API
ProxyTimeout 300
ProxyBadHeader Ignore
ErrorLog ${APACHE_LOG_DIR}/api.exemple.com_error.log
CustomLog ${APACHE_LOG_DIR}/api.exemple.com_access.log combined
</VirtualHost>
# Configuration des modules requis
LoadModule ssl_module modules/mod_ssl.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module modules/mod_headers.so
HAProxy
Configuration HAProxy
global
maxconn 4096
log stdout local0
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Configuration SSL
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
option httplog
option dontlognull
option redispatch
retries 3
maxconn 2000
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/exemple.com.pem crt /etc/ssl/certs/api.exemple.com.pem
# En-têtes de sécurité
http-response set-header X-Frame-Options DENY
http-response set-header X-Content-Type-Options nosniff
http-response set-header X-XSS-Protection "1; mode=block"
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Routage basé sur SNI
acl is_exemple hdr(host) -i exemple.com
acl is_api hdr(host) -i api.exemple.com
use_backend service1_backend if is_exemple
use_backend api_backend if is_api
default_backend service1_backend
backend service1_backend
balance roundrobin
option httpchk GET /health
http-check expect status 200
server service1-1 service1:8080 check
server service1-2 service1-backup:8080 check backup
backend api_backend
balance roundrobin
option httpchk GET /api/health
http-check expect status 200
server api-1 api-service:3000 check
server api-2 api-service-backup:3000 check backup
# Interface de statistiques (optionnel)
listen stats
bind *:8404
stats enable
stats uri /stats
stats refresh 30s
stats admin if TRUE
Validation de la configuration SSL
Tester la configuration SSL :
# Test de connectivité SSL
openssl s_client -connect your-domain.com:443 -servername your-domain.com
# Vérification des en-têtes
curl -I https://your-domain.com
# Test SNI
curl -H "Host: exemple.com" https://54984654.bunkerweb.cloud
Bonnes pratiques Gateway
- Health Checks : Configurez des vérifications de santé pour vos services
- Load Balancing : Utilisez plusieurs instances pour la haute disponibilité
- Surveillance : Surveillez les métriques de votre gateway
- En-têtes de sécurité : Ajoutez les en-têtes de sécurité appropriés
- Timeouts : Configurez des timeouts appropriés pour éviter les blocages
Liste blanche d'IP BunkerWeb Cloud
Pourquoi configurer une liste blanche ?
Pour sécuriser davantage votre infrastructure, il est recommandé de configurer une liste blanche des adresses IP de BunkerWeb Cloud côté infrastructure client. Cela garantit que seul le trafic provenant de BunkerWeb Cloud peut atteindre vos services backend.
Nous recommandons de configurer la liste blanche au niveau du pare-feu (iptables ..etc).
Adresses IP BunkerWeb Cloud à autoriser
Liste des adresses IP à autoriser :
La liste mise à jour est disponible ici : https://repo.bunkerweb.io/cloud/ips
# Adresses IP BunkerWeb Cloud
4.233.128.18
20.19.161.132
Configuration de la liste blanche par technologie
Nginx
Configuration Nginx
# Dans votre configuration serveur
server {
listen 443 ssl;
server_name exemple.com;
# Liste blanche IP BunkerWeb Cloud
allow 192.168.1.0/24;
allow 10.0.0.0/16;
allow 172.16.0.0/12;
deny all;
ssl_certificate /path/to/exemple.com.crt;
ssl_certificate_key /path/to/exemple.com.key;
location / {
proxy_pass http://service1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
# Configuration avec module geo pour plus de flexibilité
geo $bunkerweb_ip {
default 0;
192.168.1.0/24 1;
10.0.0.0/16 1;
172.16.0.0/12 1;
}
server {
listen 443 ssl;
server_name exemple.com;
if ($bunkerweb_ip = 0) {
return 403;
}
# ... reste de la configuration
}
Traefik
Configuration Traefik
# Configuration dans dynamic.yml
http:
middlewares:
bunkerweb-whitelist:
ipWhiteList:
sourceRange:
- "192.168.1.0/24"
- "10.0.0.0/16"
- "172.16.0.0/12"
ipStrategy:
depth: 1
routers:
exemple-router:
rule: "Host(`exemple.com`)"
service: "exemple-service"
middlewares:
- "bunkerweb-whitelist"
- "security-headers"
tls:
certResolver: "myresolver"
api-router:
rule: "Host(`api.exemple.com`)"
service: "api-service"
middlewares:
- "bunkerweb-whitelist"
- "security-headers"
tls:
certResolver: "myresolver"
services:
service1:
image: your-app:latest
labels:
- "traefik.enable=true"
- "traefik.http.routers.service1.rule=Host(`exemple.com`)"
- "traefik.http.routers.service1.middlewares=bunkerweb-whitelist"
- "traefik.http.middlewares.bunkerweb-whitelist.ipwhitelist.sourcerange=192.168.1.0/24,10.0.0.0/16,172.16.0.0/12"
Apache
Configuration Apache
<VirtualHost *:443>
ServerName exemple.com
# Liste blanche IP BunkerWeb Cloud
<RequireAll>
Require ip 192.168.1.0/24
Require ip 10.0.0.0/16
Require ip 172.16.0.0/12
</RequireAll>
SSLEngine on
SSLCertificateFile /path/to/exemple.com.crt
SSLCertificateKeyFile /path/to/exemple.com.key
ProxyPass / http://service1:8080/
ProxyPassReverse / http://service1:8080/
ProxyPreserveHost On
# Configuration pour les logs d'accès refusés
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog logs/access.log combined
ErrorLog logs/error.log
</VirtualHost>
# Configuration alternative avec mod_authz_core
<VirtualHost *:443>
ServerName api.exemple.com
<Directory />
<RequireAny>
Require ip 192.168.1.0/24
Require ip 10.0.0.0/16
Require ip 172.16.0.0/12
</RequireAny>
</Directory>
# ... reste de la configuration
</VirtualHost>
HAProxy
Configuration HAProxy
# Configuration dans haproxy.cfg
frontend bunkerweb_frontend
bind *:443 ssl crt /path/to/certificates/
# ACL pour la liste blanche BunkerWeb Cloud
acl bunkerweb_ips src 192.168.1.0/24 10.0.0.0/16 172.16.0.0/12
# Bloquer tout sauf BunkerWeb Cloud
http-request deny unless bunkerweb_ips
# En-têtes de sécurité
http-response set-header X-Frame-Options DENY
http-response set-header X-Content-Type-Options nosniff
# Routage
acl is_exemple hdr(host) -i exemple.com
acl is_api hdr(host) -i api.exemple.com
use_backend app_servers if is_exemple
use_backend api_servers if is_api
default_backend app_servers
backend app_servers
balance roundrobin
server app1 service1:8080 check
server app2 service2:8080 check
backend api_servers
balance roundrobin
server api1 api-service:3000 check
server api2 api-service-backup:3000 check
Pare-feu Système (iptables)
Configuration iptables
#!/bin/bash
# Script de configuration iptables pour la liste blanche BunkerWeb Cloud
# Effacer les règles existantes
iptables -F
iptables -X
# Politiques par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Autoriser loopback
iptables -A INPUT -i lo -j ACCEPT
# Autoriser les connexions établies
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Liste blanche IPs BunkerWeb Cloud pour HTTPS
iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 10.0.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 172.16.0.0/12 -j ACCEPT
# Autoriser HTTP pour Let's Encrypt (optionnel)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Autoriser SSH (adapter selon vos besoins)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Logs pour débogage
iptables -A INPUT -j LOG --log-prefix "DROPPED: "
# Sauvegarder les règles
iptables-save > /etc/iptables/rules.v4
echo "Configuration iptables appliquée avec succès"
Bonnes pratiques Liste Blanche
- Surveiller les rejets : Surveillez les tentatives d'accès bloquées
- Mises à jour régulières : Gardez la liste des IP à jour
- Tests réguliers : Validez que la liste blanche fonctionne correctement
- Documentation : Documentez les changements d'IP
- Alertes : Configurez des alertes pour les changements d'IP BunkerWeb
- Sauvegarde : Gardez une configuration de sauvegarde en cas de problème
Configuration REAL_IP et Récupération de l'Adresse Client
Pourquoi configurer REAL_IP ?
Lorsque vous utilisez BunkerWeb Cloud comme reverse proxy, les adresses IP que vos applications backend voient sont celles de BunkerWeb Cloud, et non celles des clients réels. Pour récupérer les adresses IP réelles des clients, une configuration spécifique est requise.
Configuration Côté BunkerWeb Cloud
Dans l'UI BunkerWeb, configurez Real IP :
USE_REAL_IP: yes # Défaut est no
REAL_IP_FROM: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 # Défaut
REAL_IP_HEADER: X-Forwarded-For # Défaut
REAL_IP_RECURSIVE: yes # Défaut
# Exemple si vous utilisez aussi Cloudflare Proxy devant BunkerWeb
REAL_IP_FROM_URLS: https://www.cloudflare.com/ips-v4/ https://www.cloudflare.com/ips-v6/
Vous pouvez trouver toutes les options de configuration dans la Documentation Real Ip
Configuration Côté Infrastructure Client
Nginx
Configuration Nginx pour REAL_IP
# Configurer les adresses IP de confiance (BunkerWeb Cloud)
set_real_ip_from 4.233.128.18/32
set_real_ip_from 20.19.161.132/32
# En-tête à utiliser pour récupérer l'IP réelle
real_ip_header X-Real-IP;
# Alternative avec X-Forwarded-For
# real_ip_header X-Forwarded-For;
server {
listen 443 ssl http2;
server_name exemple.com;
# Configuration SSL
ssl_certificate /path/to/exemple.com.crt;
ssl_certificate_key /path/to/exemple.com.key;
location / {
proxy_pass http://service1:8080;
# Transmettre les en-têtes d'IP réelle au backend
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Log avec l'IP client réelle
access_log /var/log/nginx/access.log combined;
}
}
# Format de log personnalisé avec IP réelle
log_format real_ip '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'real_ip="$realip_remote_addr"';
Apache
Configuration Apache pour REAL_IP
# Charger le module mod_remoteip
LoadModule remoteip_module modules/mod_remoteip.so
<VirtualHost *:443>
ServerName exemple.com
# Configuration SSL
SSLEngine on
SSLCertificateFile /path/to/exemple.com.crt
SSLCertificateKeyFile /path/to/exemple.com.key
# Configurer les adresses IP de confiance
RemoteIPHeader X-Real-IP
RemoteIPTrustedProxy 4.233.128.18/32
RemoteIPTrustedProxy 20.19.161.132/32
# Alternative avec X-Forwarded-For
# RemoteIPHeader X-Forwarded-For
# Configuration reverse proxy
ProxyPass / http://service1:8080/
ProxyPassReverse / http://service1:8080/
ProxyPreserveHost On
# Transmettre les en-têtes IP
ProxyPassReverse / http://service1:8080/
ProxyPassReverseInterpolateEnv On
# Logs avec IP réelle
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined_real_ip
CustomLog logs/access.log combined_real_ip
ErrorLog logs/error.log
</VirtualHost>
HAProxy
Configuration HAProxy pour REAL_IP
global
maxconn 4096
log stdout local0
defaults
mode http
option httplog
option dontlognull
option forwardfor
# Format de log avec IP réelle
log-format "%ci:%cp [%t] %ft %b/%s %Tq/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/
# Liste blanche IP BunkerWeb Cloud
acl bunkerweb_ips src 4.233.128.18/32 20.19.161.132/32
http-request deny unless bunkerweb_ips
# Capturer l'IP réelle depuis les en-têtes
capture request header X-Real-IP len 15
capture request header X-Forwarded-For len 50
# Routage
acl is_exemple hdr(host) -i exemple.com
use_backend app_servers if is_exemple
default_backend app_servers
backend app_servers
balance roundrobin
# Ajouter/préserver les en-têtes d'IP réelle
http-request set-header X-Original-Forwarded-For %[req.hdr(X-Forwarded-For)]
http-request set-header X-Client-IP %[req.hdr(X-Real-IP)]
server app1 service1:8080 check
server app2 service2:8080 check backup
Traefik
Configuration Traefik pour REAL_IP
# Configuration dans dynamic.yml
http:
middlewares:
real-ip:
ipWhiteList:
sourceRange:
- "4.233.128.18/32"
- "20.19.161.132/32"
ipStrategy:
depth: 2 # Nombre de proxies de confiance
excludedIPs:
- "127.0.0.1/32"
routers:
exemple-router:
rule: "Host(`exemple.com`)"
service: "exemple-service"
middlewares:
- "real-ip"
tls:
certResolver: "myresolver"
services:
exemple-service:
loadBalancer:
servers:
- url: "http://service1:8080"
passHostHeader: true
entryPoints:
websecure:
address: ":443"
forwardedHeaders:
trustedIPs:
- "4.233.128.18/32"
- "20.19.161.132/32"
insecure: false
accessLog:
format: json
fields:
defaultMode: keep
names:
ClientUsername: drop
headers:
defaultMode: keep
names:
X-Real-IP: keep
X-Forwarded-For: keep
Tests et Validation
Vérification de la configuration
# Test 1: Vérifier les en-têtes reçus
curl -H "X-Real-IP: 203.0.113.1" \
-H "X-Forwarded-For: 203.0.113.1, 192.168.1.100" \
https://exemple.com/test-ip
# Test 2: Analyser les logs
tail -f /var/log/nginx/access.log | grep "203.0.113.1"
# Test 3: Test depuis différentes sources
curl -v https://exemple.com/whatismyip
Bonnes pratiques REAL_IP
- Sécurité : Ne faites confiance qu'aux en-têtes IP provenant de sources connues (BunkerWeb Cloud)
- Validation : Validez toujours les adresses IP reçues dans les en-têtes
- Journalisation : Loguez à la fois l'IP du proxy et l'IP réelle pour le débogage
- Fallback : Ayez toujours une valeur par défaut si les en-têtes sont manquants
- Tests : Testez régulièrement que la détection d'IP fonctionne correctement
- Surveillance : Surveillez les modèles d'IP pour détecter les anomalies
Dépannage REAL_IP
Problèmes courants
- L'IP affichée est toujours celle de BunkerWeb : Vérifiez la configuration des proxies de confiance
- En-têtes manquants : Vérifiez la configuration côté BunkerWeb Cloud
- IPs invalides : Implémentez une validation stricte des IPs
- Logs incorrects : Vérifiez le format des logs et la configuration du module real_ip
Commandes de diagnostic
Tester la détection d'IP
curl -H "X-Real-IP: 1.2.3.4" https://your-domain.com/debug-headers
Surveillance et Observabilité
Accès Grafana
Votre instance Grafana gérée vous donne accès à :
Métriques disponibles
-
Vue d'ensemble du trafic
-
Requêtes par seconde
- Codes de statut HTTP
- Géolocalisation des requêtes
-
Sécurité
-
Tentatives d'attaques bloquées
- Types de menaces détectés
- Règles WAF déclenchées
-
Métriques de performance
-
Latence des requêtes
- Temps de réponse backend
- Utilisation des ressources
Journaux disponibles
- Access Logs : Toutes les requêtes HTTP/HTTPS
- Security Logs : Événements de sécurité et blocages
- Error Logs : Erreurs système et d'application
Configuration des alertes
Configurez des alertes Grafana pour :
- Pics de trafic anormaux
- Augmentation des erreurs 5xx
- Détection d'attaques DDoS
- Échecs de santé backend
Bonnes pratiques
Sécurité
- Utilisez HTTPS pour toute communication backend
- Implémentez une liste blanche d'IP si possible
- Configurez des timeouts appropriés
- Activez la compression pour optimiser les performances
Performance
- Optimisez la configuration du cache
- Utilisez HTTP/2 côté client
- Configurez des health checks pour vos backends
- Surveillez les métriques régulièrement
Dépannage
Problèmes courants
1. Erreur SSL/TLS
Symptôme : Erreurs de certificat SSL
Solutions :
# Vérifier la configuration SNI
openssl s_client -connect backend.com:443 -servername exemple.com
# Vérifier les certificats backend
openssl x509 -in certificate.crt -text -noout
2. Timeout Backend
Symptôme : Erreurs 504 Gateway Timeout
Solutions :
- Augmenter
REVERSE_PROXY_CONNECT_TIMEOUT&REVERSE_PROXY_SEND_TIMEOUT - Vérifier la santé du backend
- Optimiser la performance de l'application
3. Problèmes de routage
Symptôme : Mauvais service servi
Solutions :
- Vérifier la configuration
SERVER_NAME - Valider la configuration SNI
- Vérifier les en-têtes
Host
Commandes de diagnostic
# Test de connectivité
curl -v https://your-domain.com
# Test avec en-têtes personnalisés
curl -H "Host: exemple.com" -v https://54984654.bunkerweb.cloud
# Vérification DNS
dig +trace exemple.com
# Test SSL
openssl s_client -connect exemple.com:443 -servername exemple.com
Support Technique
Pour toute assistance technique :
- Vérifiez les logs dans Grafana
- Vérifiez la configuration dans l'UI BunkerWeb
- Contactez le support avec les détails de configuration et les logs d'erreur
Image tout-en-un (AIO)
Déploiement
Pour déployer le conteneur tout-en-un, il vous suffit d'exécuter la commande suivante :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:testing
Par défaut, le conteneur expose :
- 8080/tcp pour HTTP
- 8443/tcp pour HTTPS
- 8443/udp pour QUIC
- 7000/tcp pour l'accès à l'interface utilisateur web sans BunkerWeb en façade (non recommandé pour la production)
Un volume nommé (ou un bind mount) est nécessaire pour conserver la base SQLite, le cache et les sauvegardes stockés sous /data dans le conteneur :
services:
bunkerweb-aio:
image: bunkerity/bunkerweb-all-in-one:testing
container_name: bunkerweb-aio
volumes:
- bw-storage:/data
...
volumes:
bw-storage:
Utilisation d'un dossier local pour les données persistantes
Le conteneur tout-en-un exécute ses services en tant qu'utilisateur non privilégié UID 101 / GID 101. Cela renforce la sécurité : même si une composante est compromise, elle n'obtient pas les privilèges root (UID/GID 0) sur l'hôte.
Si vous montez un dossier local, assurez-vous que les permissions permettent à cet utilisateur non privilégié d'écrire dedans :
mkdir bw-data && \
chown root:101 bw-data && \
chmod 770 bw-data
Ou, si le dossier existe déjà :
chown -R root:101 bw-data && \
chmod -R 770 bw-data
Lorsque vous utilisez Docker en mode rootless ou Podman, les UID/GID du conteneur sont remappés. Vérifiez d'abord vos plages subuid et subgid :
grep ^$(whoami): /etc/subuid && \
grep ^$(whoami): /etc/subgid
Par exemple, si la plage commence à 100000, l'UID/GID effectif sera 100100 (100000 + 100) :
mkdir bw-data && \
sudo chgrp 100100 bw-data && \
chmod 770 bw-data
Ou, si le dossier existe déjà :
sudo chgrp -R 100100 bw-data && \
sudo chmod -R 770 bw-data
L'image tout-en-un est livrée avec plusieurs services intégrés, qui peuvent être contrôlés à l'aide de variables d'environnement :
SERVICE_UI=yes(par défaut) - Active le service d'interface utilisateur WebSERVICE_SCHEDULER=yes(par défaut) - Active le service SchedulerSERVICE_API=no(par défaut) - Active le service API (plan de contrôle FastAPI)AUTOCONF_MODE=no(par défaut) - Active le service autoconfUSE_REDIS=yes(par défaut) : active l' instance Redis intégréeUSE_CROWDSEC=no(par défaut) - L'intégration CrowdSec est désactivée par défautHIDE_SERVICE_LOGS=(optionnel) - Liste de services séparés par des virgules à masquer dans les logs du conteneur. Valeurs acceptées :api,autoconf,bunkerweb,crowdsec,redis,scheduler,ui,nginx.access,nginx.error,modsec. Les fichiers sous/var/log/bunkerweb/<service>.logcontinuent d'être alimentés.
Intégration de l'API
L'image tout-en-un embarque l'API BunkerWeb. Elle est désactivée par défaut et peut être activée en définissant SERVICE_API=yes.
Sécurité
L'API constitue un plan de contrôle privilégié. Ne l'exposez pas directement à Internet. Conservez-la sur un réseau interne, restreignez les IP sources avec API_WHITELIST_IPS, imposez une authentification (API_TOKEN ou utilisateurs API + Biscuit) et, idéalement, passez par BunkerWeb en proxy inverse sur un chemin difficile à deviner.
Activation rapide (autonome) — publie le port de l'API ; à réserver aux tests :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e SERVICE_API=yes \
-e API_WHITELIST_IPS="127.0.0.0/8" \
-e API_USERNAME=changeme \
-e API_PASSWORD=StrongP@ssw0rd \
-p 80:8080/tcp -p 443:8443/tcp -p 443:8443/udp \
-p 8888:8888/tcp \
bunkerity/bunkerweb-all-in-one:testing
Configuration recommandée (derrière BunkerWeb) — ne publiez pas 8888 ; utilisez plutôt un proxy inverse :
services:
bunkerweb-aio:
image: bunkerity/bunkerweb-all-in-one:testing
container_name: bunkerweb-aio
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp"
environment:
SERVER_NAME: "api.example.com"
MULTISITE: "yes"
DISABLE_DEFAULT_SERVER: "yes"
api.example.com_USE_TEMPLATE: "bw-api"
api.example.com_USE_REVERSE_PROXY: "yes"
api.example.com_REVERSE_PROXY_URL: "/api-<unguessable>"
api.example.com_REVERSE_PROXY_HOST: "http://127.0.0.1:8888" # Point d'accès API interne
# Paramètres API
SERVICE_API: "yes"
# Définissez des identifiants robustes et autorisez uniquement des IP ou réseaux de confiance (plus de détails ci-dessous)
API_USERNAME: "changeme"
API_PASSWORD: "StrongP@ssw0rd"
API_ROOT_PATH: "/api-<unguessable>" # Doit correspondre à REVERSE_PROXY_URL
# Nous désactivons l'UI - passez à "yes" pour l'activer
SERVICE_UI: "no"
volumes:
- bw-storage:/data
networks:
- bw-universe
volumes:
bw-storage:
networks:
bw-universe:
name: bw-universe
Des informations détaillées concernant l'authentification, les permissions (ACL), la limitation de débit, le TLS et les options de configuration sont disponibles dans la documentation de l'API.
Accès à l'assistant d'installation
Par défaut, l'assistant d'installation est lancé automatiquement lorsque vous exécutez le conteneur AIO pour la première fois. Pour y accéder, procédez comme suit :
- Démarrez le conteneur AIO comme ci-dessus, en vous assurant que
SERVICE_UI=yes(valeur par défaut). - Accédez à l'interface utilisateur via votre point de terminaison BunkerWeb principal, par exemple
https://your-domain.
Suivez les étapes suivantes du guide de démarrage rapide pour configurer l'interface utilisateur Web.
Intégration Redis
L'image BunkerWeb All-In-One inclut Redis prêt à l'emploi pour la persistance des bannissements et des rapports. Gardez en tête :
- Le service Redis embarqué ne démarre que si
USE_REDIS=yeset siREDIS_HOSTreste sur sa valeur par défaut (127.0.0.1/localhost). - Il écoute sur l'interface loopback du conteneur ; il est donc accessible depuis les processus du conteneur, mais pas depuis d'autres conteneurs ni l'hôte.
- Ne redéfinissez
REDIS_HOSTque si vous disposez d'un point de terminaison Redis/Valkey externe, autrement l'instance embarquée ne sera pas lancée. - Pour désactiver Redis complètement, définissez
USE_REDIS=no. - Les journaux Redis apparaissent avec le préfixe
[REDIS]dans les journaux Docker et dans/var/log/bunkerweb/redis.log.
Intégration CrowdSec
L'image Docker tout-en-un de BunkerWeb est livrée avec CrowdSec entièrement intégré, sans conteneurs supplémentaires ni configuration manuelle requise. Suivez les étapes ci-dessous pour activer, configurer et étendre CrowdSec dans votre déploiement.
Par défaut, CrowdSec est désactivé. Pour l'activer, il suffit d'ajouter la USE_CROWDSEC variable d'environnement :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_CROWDSEC=yes \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:testing
-
Lorsque
USE_CROWDSEC=yes, le point d'entrée :- Inscrivez-vous et démarrez l'agent CrowdSec local (via
cscli). - Installez ou mettez à niveau les collections et les analyseurs par défaut.
- Configurez le
crowdsec-bunkerweb-bouncer/v1.6videur.
- Inscrivez-vous et démarrez l'agent CrowdSec local (via
Collections et analyseurs par défaut
Au premier démarrage (ou après la mise à niveau), les ressources suivantes sont automatiquement installées et maintenues à jour :
| Type | Nom | But |
|---|---|---|
| Collection | bunkerity/bunkerweb |
Protégez les serveurs Nginx contre un large éventail d'attaques basées sur HTTP, de la force brute aux tentatives d'injection. |
| Collection | crowdsecurity/appsec-virtual-patching |
Fournit un ensemble de règles de type WAF mis à jour dynamiquement ciblant les CVE connues, automatiquement corrigé quotidiennement pour protéger les applications Web contre les vulnérabilités nouvellement découvertes. |
| Collection | crowdsecurity/appsec-generic-rules |
Compléments crowdsecurity/appsec-virtual-patching avec des heuristiques pour les modèles d'attaque génériques de la couche application, tels que l'énumération, la traversée de chemin et les sondes automatisées, comblant les lacunes là où il n'existe pas encore de règles spécifiques à CVE. |
| Analyseur | crowdsecurity/geoip-enrich |
Enrichit les événements avec le contexte GeoIP |
Comment ça marche en interne
Le script entrypoint appelle :cscli hub update
cscli install collection bunkerity/bunkerweb
cscli install collection crowdsecurity/appsec-virtual-patching
cscli install collection crowdsecurity/appsec-generic-rules
cscli install parser crowdsecurity/geoip-enrich
Collection absente dans Docker ?
Si cscli collections list à l'intérieur du conteneur n'affiche toujours pas bunkerity/bunkerweb, exécutez docker exec -it bunkerweb-aio cscli hub update puis redémarrez le conteneur (docker restart bunkerweb-aio) pour rafraîchir le cache local du hub.
Ajouter des collections supplémentaires
Vous avez besoin d'une couverture supplémentaire ? Définissez CROWDSEC_EXTRA_COLLECTIONS à l'aide d'une liste de collections Hubb séparées par des espaces :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_CROWDSEC=yes \
-e CROWDSEC_EXTRA_COLLECTIONS="crowdsecurity/apache2 crowdsecurity/mysql" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:testing
Comment ça marche en interne
Le script parcourt chaque nom et installe ou met à jour si nécessaire — aucune intervention manuelle n'est requise.
Désactiver des analyseurs spécifiques
Si vous souhaitez conserver la configuration par défaut tout en désactivant explicitement un ou plusieurs analyseurs, fournissez une liste séparée par des espaces via CROWDSEC_DISABLED_PARSERS :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_CROWDSEC=yes \
-e CROWDSEC_DISABLED_PARSERS="crowdsecurity/geoip-enrich foo/bar-parser" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:testing
Notes :
- La liste est appliquée après l'installation/mise à jour des éléments requis ; seuls les analyseurs indiqués sont supprimés.
- Utilisez les slugs du hub tels qu'affichés par cscli parsers list (ex. : crowdsecurity/geoip-enrich).
Basculement AppSec
Les fonctionnalités CrowdSec AppSec, optimisées par les collections appsec-virtual-patching et appsec-generic-rules , sont activées par défaut.
Pour désactiver toutes les fonctionnalités AppSec (WAF/virtual-patching), définissez :
-e CROWDSEC_APPSEC_URL=""
Cela désactive effectivement le point de terminaison AppSec, de sorte qu'aucune règle n'est appliquée.
API CrowdSec externe
Si vous exploitez une instance CrowdSec distante, pointez le conteneur vers votre API :
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_CROWDSEC=yes \
-e CROWDSEC_API="https://crowdsec.example.com:8000" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:testing
- L'enregistrement local est ignoré lorsque n'
CROWDSEC_APIest pas127.0.0.1oulocalhost. - AppSec est désactivé par défaut lors de l'utilisation d'une API externe. Pour l'activer, définissez-le
CROWDSEC_APPSEC_URLsur le point de terminaison de votre choix. - L'inscription du videur se produit toujours sur l'API distante.
- Pour réutiliser une clé de videur existante, fournissez-la
CROWDSEC_API_KEYavec votre jeton pré-généré.
Plus d'options
Pour une couverture complète de toutes les options CrowdSec (scénarios personnalisés, journaux, dépannage, etc.), consultez la documentation du plugin BunkerWeb CrowdSec ou visitez le site officiel de CrowdSec.
Docker
L'utilisation de BunkerWeb en tant que conteneur Docker offre une approche pratique et simple pour tester et utiliser la solution, en particulier si vous êtes déjà familiarisé avec la technologie Docker.
Pour faciliter votre déploiement Docker, nous fournissons des images prédéfinies facilement disponibles sur Docker Hub, prenant en charge plusieurs architectures. Ces images prédéfinies sont optimisées et préparées pour être utilisées sur les architectures suivantes :
- x64 (64 bits)
- x86
- armv8 (ARM 64 bits)
- armv7 (ARM 32 bits)
En accédant à ces images prédéfinies à partir de Docker Hub, vous pouvez rapidement extraire et exécuter BunkerWeb dans votre environnement Docker, éliminant ainsi le besoin de processus de configuration ou d'installation étendus. Cette approche simplifiée vous permet de vous concentrer sur l'exploitation des capacités de BunkerWeb sans complexités inutiles.
Que vous effectuiez des tests, développiez des applications ou déployiez BunkerWeb en production, l'option de conteneurisation Docker offre flexibilité et facilité d'utilisation. L'adoption de cette méthode vous permet de tirer pleinement parti des fonctionnalités de BunkerWeb tout en tirant parti des avantages de la technologie Docker.
docker pull bunkerity/bunkerweb:testing
Les images Docker sont également disponibles sur les packages GitHub et peuvent être téléchargées à l'aide de l'adresse du ghcr.io dépôt :
docker pull ghcr.io/bunkerity/bunkerweb:testing
Les concepts clés de l'intégration Docker sont les suivants :
- Variables d'environnement: Configurez facilement BunkerWeb à l'aide de variables d'environnement. Ces variables vous permettent de personnaliser divers aspects du comportement de BunkerWeb, tels que les paramètres réseau, les options de sécurité et d'autres paramètres.
- Conteneur du Scheduler : gérez la configuration et exécutez les tâches à l'aide d'un conteneur dédié appelé Scheduler.
- Réseaux: Les réseaux Docker jouent un rôle essentiel dans l'intégration de BunkerWeb. Ces réseaux ont deux objectifs principaux : exposer les ports aux clients et se connecter aux services Web en amont. En exposant les ports, BunkerWeb peut accepter les demandes entrantes des clients, leur permettant d'accéder aux services Web protégés. De plus, en se connectant aux services Web en amont, BunkerWeb peut acheminer et gérer efficacement le trafic, offrant ainsi une sécurité et des performances améliorées.
Backend de base de données
Veuillez noter que nos instructions supposent que vous utilisez SQLite comme backend de base de données par défaut, tel que configuré par le DATABASE_URI paramètre. Cependant, d'autres backends de base de données sont également pris en charge. Pour plus d'informations, consultez les fichiers docker-compose dans le dossier misc/integrations du dépôt.
Variables d'environnement
Les paramètres sont transmis au Scheduler à l'aide de variables d'environnement Docker :
...
services:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
environment:
- MY_SETTING=value
- ANOTHER_SETTING=another value
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
...
Liste complète
Pour obtenir la liste complète des variables d'environnement, consultez la section des paramètres de la documentation.
Ignorer les conteneurs étiquetés
Lorsqu'un conteneur doit être ignoré par autoconf, définissez DOCKER_IGNORE_LABELS sur le contrôleur. Fournissez une liste de clés d'étiquettes séparées par des espaces ou des virgules (par exemple bunkerweb.SERVER_NAME) ou simplement le suffixe (SERVER_NAME). Tout conteneur ou source de configuration personnalisée portant une étiquette correspondante est ignoré lors de la découverte, et l'étiquette est ignorée lors de la traduction des paramètres.
Utilisation des secrets Docker
Au lieu de transmettre des paramètres sensibles via des variables d'environnement, vous pouvez les stocker en tant que secrets Docker. Pour chaque paramètre que vous souhaitez sécuriser, créez un secret Docker dont le nom correspond à la clé de paramètre (en majuscules). Les scripts d'entrée de BunkerWeb chargent automatiquement les secrets /run/secrets et les exportent en tant que variables d'environnement.
Exemple:
# Create a Docker secret for ADMIN_PASSWORD
echo "S3cr3tP@ssw0rd" | docker secret create ADMIN_PASSWORD -
Montez les secrets lors du déploiement :
services:
bw-ui:
secrets:
- ADMIN_PASSWORD
...
secrets:
ADMIN_PASSWORD:
external: true
Cela garantit que les paramètres sensibles sont tenus à l'écart de l'environnement et des journaux.
Programmateur
Le Scheduler s'exécute dans son propre conteneur, qui est également disponible sur Docker Hub :
docker pull bunkerity/bunkerweb-scheduler:testing
Paramètres BunkerWeb
Since version 1.6.0, the Scheduler container is where you define the settings for BunkerWeb. The Scheduler then pushes the configuration to the BunkerWeb container.
⚠ Important: Tous les paramètres liés à l'API (comme API_HTTP_PORT, API_LISTEN_IP, API_SERVER_NAME, API_WHITELIST_IP, et API_TOKEN si vous l'utilisez) doivent également être définis dans le conteneur BunkerWeb. Les paramètres doivent être répliqués dans les deux conteneurs, sinon le conteneur BunkerWeb n'acceptera pas les requêtes API du Scheduler.
x-bw-api-env: &bw-api-env
# We use an anchor to avoid repeating the same settings for both containers
API_HTTP_PORT: "5000" # Default value
API_LISTEN_IP: "0.0.0.0" # Default value
API_SERVER_NAME: "bwapi" # Default value
API_WHITELIST_IP: "127.0.0.0/24 10.20.30.0/24" # Set this according to your network settings
# Jeton optionnel ; si défini, le Scheduler enverra Authorization: Bearer <token>
API_TOKEN: ""
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
environment:
# This will set the API settings for the BunkerWeb container
<<: *bw-api-env
restart: "unless-stopped"
networks:
- bw-universe
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
environment:
# This will set the API settings for the Scheduler container
<<: *bw-api-env
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
restart: "unless-stopped"
networks:
- bw-universe
...
Un volume est nécessaire pour stocker la base de données SQLite et les sauvegardes utilisées par le Scheduler :
...
services:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
volumes:
- bw-storage:/data
...
volumes:
bw-storage:
Utilisation d'un dossier local pour les données persistantes
Le Scheduler s'exécute en tant qu' utilisateur non privilégié avec UID 101 et GID 101 à l'intérieur du conteneur. Cela renforce la sécurité : en cas d'exploitation d'une vulnérabilité, l'attaquant ne disposera pas des privilèges de root complet (UID/GID 0).
However, if you use a local folder for persistent data, you must set the correct permissions so the unprivileged user can write data to it. For example:
mkdir bw-data && \
chown root:101 bw-data && \
chmod 770 bw-data
Alternatively, if the folder already exists:
chown -R root:101 bw-data && \
chmod -R 770 bw-data
If you are using Docker in rootless mode or Podman, UIDs and GIDs in the container will be mapped to different ones on the host. You will first need to check your initial subuid and subgid:
grep ^$(whoami): /etc/subuid && \
grep ^$(whoami): /etc/subgid
For example, if you have a value of 100000, the mapped UID/GID will be 100100 (100000 + 100):
mkdir bw-data && \
sudo chgrp 100100 bw-data && \
chmod 770 bw-data
Or if the folder already exists:
sudo chgrp -R 100100 bw-data && \
sudo chmod -R 770 bw-data
Réseau
Par défaut, le conteneur BunkerWeb écoute (à l'intérieur du conteneur) les fichiers 8080/tcp pour HTTP, 8443/tcp pour HTTPS et 8443/udp pour QUIC.
!! avertissement "Ports privilégiés en mode rootless ou lors de l'utilisation de Podman" Si vous utilisez Docker en mode rootless et que vous souhaitez rediriger les ports privilégiés (< 1024) tels que 80 et 443 vers BunkerWeb, veuillez vous référer aux prérequis ici.
If you are using [Podman](https://podman.io/), you can lower the minimum number for unprivileged ports:
```shell
sudo sysctl net.ipv4.ip_unprivileged_port_start=1
```
La pile BunkerWeb typique lors de l'utilisation de l'intégration Docker contient les conteneurs suivants :
- BunkerWeb (en anglais)
- Programmateur
- Vos services
À des fins de défense en profondeur, nous vous recommandons vivement de créer au moins trois réseaux Docker différents :
bw-services: pour BunkerWeb et vos services webbw-universe: pour BunkerWeb et le Schedulerbw-db: pour la base de données (si vous en utilisez une)
Pour sécuriser la communication entre le Scheduler et l'API BunkerWeb, autorisez les appels d'API. Utilisez le paramètre API_WHITELIST_IP pour spécifier les adresses IP et sous-réseaux autorisés. Pour un niveau de protection supérieur, définissez API_TOKEN dans les deux conteneurs ; le Scheduler inclura automatiquement l'en-tête Authorization: Bearer <token>.
Il est fortement recommandé d'utiliser un sous-réseau statique pour le bw-universe réseau afin d'améliorer la sécurité. En mettant en œuvre ces mesures, vous pouvez vous assurer que seules les sources autorisées peuvent accéder à l'API BunkerWeb, réduisant ainsi le risque d'accès non autorisé ou d'activités malveillantes :
x-bw-api-env: &bw-api-env
# We use an anchor to avoid repeating the same settings for both containers
API_WHITELIST_IP: "127.0.0.0/24 10.20.30.0/24"
API_TOKEN: "" # Jeton API optionnel
# Jeton API optionnel pour l'accès authentifié à l'API
API_TOKEN: ""
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp" # QUIC
environment:
<<: *bw-api-env
restart: "unless-stopped"
networks:
- bw-services
- bw-universe
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
environment:
<<: *bw-api-env
BUNKERWEB_INSTANCES: "bunkerweb" # This setting is mandatory to specify the BunkerWeb instance
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
restart: "unless-stopped"
networks:
- bw-universe
...
volumes:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24 # Static subnet so only authorized sources can access the BunkerWeb API
bw-services:
name: bw-services
Fichier de composition complet
x-bw-api-env: &bw-api-env
# We use an anchor to avoid repeating the same settings for both containers
API_WHITELIST_IP: "127.0.0.0/24 10.20.30.0/24"
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp" # QUIC
environment:
<<: *bw-api-env
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
depends_on:
- bunkerweb
environment:
<<: *bw-api-env
BUNKERWEB_INSTANCES: "bunkerweb" # This setting is mandatory to specify the BunkerWeb instance
SERVER_NAME: "www.example.com"
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
restart: "unless-stopped"
networks:
- bw-universe
volumes:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24 # Static subnet so only authorized sources can access the BunkerWeb API
bw-services:
name: bw-services
Construire à partir de la source
Sinon, si vous préférez une approche plus pratique, vous avez la possibilité de créer l'image Docker directement à partir de la source. La création de l'image à partir de la source vous offre un meilleur contrôle et une meilleure personnalisation du processus de déploiement. Cependant, veuillez noter que cette méthode peut prendre un certain temps, en fonction de votre configuration matérielle (vous pouvez prendre un café ☕ si nécessaire).
git clone https://github.com/bunkerity/bunkerweb.git && \
cd bunkerweb && \
docker build -t bw -f src/bw/Dockerfile . && \
docker build -t bw-scheduler -f src/scheduler/Dockerfile . && \
docker build -t bw-autoconf -f src/autoconf/Dockerfile . && \
docker build -t bw-ui -f src/ui/Dockerfile .
Linux
Les distributions Linux prises en charge par BunkerWeb (architectures amd64/x86_64 et arm64/aarch64) comprennent :
- Debian 12 "Rat de bibliothèque"
- Debian 13 "Trixie"
- Ubuntu 22.04 "Jammy"
- Ubuntu 24.04 "Noble"
- Fedora 41 et 42
- Red Hat Enterprise Linux (RHEL) 8, 9 et 10
Script d'installation facile
Pour une expérience d'installation simplifiée, BunkerWeb fournit un script d'installation facile qui gère automatiquement l'ensemble du processus d'installation, y compris l'installation de NGINX, la configuration du référentiel et la configuration du service.
Démarrage rapide
Pour commencer, téléchargez le script d'installation et sa somme de contrôle, puis vérifiez l'intégrité du script avant de l'exécuter.
# Download the script and its checksum
curl -fsSL -O https://github.com/bunkerity/bunkerweb/releases/download/vtesting/install-bunkerweb.sh
curl -fsSL -O https://github.com/bunkerity/bunkerweb/releases/download/vtesting/install-bunkerweb.sh.sha256
# Verify the checksum
sha256sum -c install-bunkerweb.sh.sha256
# If the check is successful, run the script
chmod +x install-bunkerweb.sh
sudo ./install-bunkerweb.sh
Avis de sécurité
Vérifiez toujours l'intégrité du script d'installation avant de l'exécuter.
Téléchargez le fichier de somme de contrôle et utilisez un outil comme sha256sum pour confirmer que le script n'a pas été modifié ou altéré.
Si la vérification de la somme de contrôle échoue, n'exécutez pas le script — il pourrait être dangereux.
Comment ça marche
Le script d'installation facile est un outil puissant conçu pour rationaliser l'installation de BunkerWeb sur un nouveau système Linux. Il automatise les étapes clés suivantes :
- Analyse du système: détecte votre système d'exploitation et le compare à la liste des distributions prises en charge.
- Personnalisation de l'installation: en mode interactif, il vous invite à choisir un type d'installation (Tout en un, Manager, Worker, etc.) et à décider d'activer ou non l'assistant de configuration Web.
- Intégrations facultatives: propose d'installer et de configurer automatiquement le moteur de sécurité CrowdSec.
- Gestion des dépendances : Installe la version correcte de NGINX requise par BunkerWeb à partir de sources officielles et verrouille la version pour éviter les mises à niveau involontaires.
- Installation de BunkerWeb: Ajoute le référentiel de paquets BunkerWeb, installe les paquets nécessaires et verrouille la version.
- Configuration du service : Configure et active les
systemdservices correspondant au type d'installation que vous avez choisi. - Conseils post-installation: Fournit des étapes suivantes claires pour vous aider à démarrer avec votre nouvelle instance BunkerWeb.
Interactive Installation
Lorsqu'il est exécuté sans aucune option, le script passe en mode interactif qui vous guide tout au long du processus d'installation. Il vous sera demandé de faire les choix suivants :
- Type d'installation: sélectionnez les composants que vous souhaitez installer.
- Full Stack (par défaut): une installation tout-en-un comprenant BunkerWeb, le Scheduler et l'interface utilisateur Web.
- Manager: Installe le Scheduler et l'interface utilisateur Web, destinés à gérer un ou plusieurs travailleurs BunkerWeb distants.
- Worker: Installe uniquement l'instance BunkerWeb, qui peut être gérée par un gestionnaire distant.
- Planificateur uniquement : installe uniquement le composant Planificateur.
- Interface utilisateur Web uniquement : installe uniquement le composant Interface utilisateur Web.
- Assistant d'installation: choisissez d'activer ou non l'assistant de configuration Web. Ceci est fortement recommandé pour les nouveaux utilisateurs.
- Intégration CrowdSec: choisissez d'installer le moteur de sécurité CrowdSec pour une protection avancée et en temps réel contre les menaces.
- CrowdSec AppSec: si vous choisissez d'installer CrowdSec, vous pouvez également activer le composant Application Security (AppSec), qui ajoute des fonctionnalités WAF.
- Service API : choisissez d'activer le service API BunkerWeb optionnel. Il est désactivé par défaut sur les installations Linux.
Installations du gestionnaire et du Scheduler
Si vous choisissez le type d'installation Manager ou Scheduler Only, vous serez également invité à fournir les adresses IP ou les noms d'hôte de vos instances de travail BunkerWeb.
Options de ligne de commande
Pour les configurations non interactives ou automatisées, le script peut être contrôlé à l'aide d'indicateurs de ligne de commande :
Options générales :
| Option | Description |
|---|---|
-v, --version VERSION |
Spécifie la version de BunkerWeb à installer (par exemple, testing). |
-w, --enable-wizard |
Active l'assistant de configuration. |
-n, --no-wizard |
Désactive l'assistant d'installation. |
--api, --enable-api |
Active le service API (FastAPI) systemd (désactivé par défaut). |
--no-api |
Désactive explicitement le service API. |
-y, --yes |
S'exécute en mode non interactif en utilisant les réponses par défaut pour toutes les invites. |
-f, --force |
Force l'installation à se poursuivre même sur une version du système d'exploitation non prise en charge. |
-q, --quiet |
Installation silencieuse (suppression de la sortie). |
-h, --help |
Affiche le message d'aide avec toutes les options disponibles. |
--dry-run |
Montrez ce qui serait installé sans le faire. |
Types d'installation :
| Option | Description |
|---|---|
--full |
Installation complète de la pile (BunkerWeb, Scheduler, UI). Il s'agit de l'option par défaut. |
--manager |
Installe le Scheduler et l'interface utilisateur pour gérer les travailleurs à distance. |
--worker |
Installe uniquement l'instance BunkerWeb. |
--scheduler-only |
Installe uniquement le composant Scheduler. |
--ui-only |
Installe uniquement le composant Interface utilisateur Web. |
--api-only |
Installe uniquement le service API (port 8000). |
Intégrations de sécurité :
| Option | Description |
|---|---|
--crowdsec |
Installez et configurez le moteur de sécurité CrowdSec. |
--no-crowdsec |
Ignorez l'installation de CrowdSec. |
--crowdsec-appsec |
Installez CrowdSec avec le composant AppSec (inclut les fonctionnalités WAF). |
Options avancées :
| Option | Description |
|---|---|
--instances "IP1 IP2" |
Liste séparée par des espaces des instances BunkerWeb (requise pour les modes gestionnaire/Scheduler). |
--manager-ip IPs |
IPs du gestionnaire/Scheduler à mettre en liste blanche (requis pour worker en mode non-interactif). |
--dns-resolvers "IP1 IP2" |
IPs des résolveurs DNS personnalisés (pour les installations full, manager ou worker). |
--api-https |
Activer HTTPS pour la communication API interne (par défaut : HTTP uniquement). |
--backup-dir PATH |
Répertoire pour stocker la sauvegarde automatique avant la mise à jour. |
--no-auto-backup |
Ignorer la sauvegarde automatique (vous DEVEZ l'avoir fait manuellement). |
Exemple d'utilisation :
# Run in interactive mode (recommended for most users)
sudo ./install-bunkerweb.sh
# Non-interactive installation with defaults (full stack, wizard enabled)
sudo ./install-bunkerweb.sh --yes
# Install a Worker node without the setup wizard
sudo ./install-bunkerweb.sh --worker --no-wizard
# Install a specific version
sudo ./install-bunkerweb.sh --version testing
# Manager setup with remote worker instances (instances required)
sudo ./install-bunkerweb.sh --manager --instances "192.168.1.10 192.168.1.11"
# Manager avec communication API interne HTTPS
sudo ./install-bunkerweb.sh --manager --instances "192.168.1.10 192.168.1.11" --api-https
# Worker avec résolveurs DNS personnalisés et API interne HTTPS
sudo ./install-bunkerweb.sh --worker --dns-resolvers "1.1.1.1 1.0.0.1" --api-https
# Full installation with CrowdSec and AppSec
sudo ./install-bunkerweb.sh --crowdsec-appsec
# Silent non-interactive installation
sudo ./install-bunkerweb.sh --quiet --yes
# Preview installation without executing
sudo ./install-bunkerweb.sh --dry-run
# Error: CrowdSec cannot be used with worker installations
# sudo ./install-bunkerweb.sh --worker --crowdsec # This will fail
# Error: Instances required for manager in non-interactive mode
# sudo ./install-bunkerweb.sh --manager --yes # This will fail without --instances
Remarques importantes sur la compatibilité des options
CrowdSec Limitations:
- Les options CrowdSec (
--crowdsec,--crowdsec-appsec) ne sont compatibles qu'avec le type d'installation--full(par défaut) - Ils ne peuvent pas être utilisés avec les installations
--manager,--worker,--scheduler-only,--ui-onlyou--api-only
Disponibilité du service API :
- Le service API externe (port 8000) est disponible pour les types d'installation
--fullet--manager - Il n'est pas disponible pour les installations
--worker,--scheduler-onlyou--ui-only - Utilisez
--api-onlypour une installation dédiée du service API
Exigences relatives aux instances :
- L --instances 'option n'est valable qu'avec --manager les types d --scheduler-only 'installation et
- Lors de l'utilisation --manager ou --scheduler-only avec --yes (mode non interactif), l' --instances option est obligatoire
- Format: --instances "192.168.1.10 192.168.1.11 192.168.1.12"
Interactif vs non interactif :
- Le mode interactif (par défaut) vous demandera les valeurs requises manquantes
- Le mode non interactif (--yes) nécessite que toutes les options nécessaires soient fournies via la ligne de commande
Intégration de CrowdSec avec le script
Si vous choisissez d'installer CrowdSec lors de la configuration interactive, le script automatise entièrement son intégration avec BunkerWeb :
- Il ajoute le dépôt officiel CrowdSec et installe l'agent.
- Il crée un nouveau fichier d'acquisition pour que CrowdSec analyse les journaux de BunkerWeb (
access.log,error.log, etmodsec_audit.log). - Il installe les collections essentielles (
bunkerity/bunkerweb) et les analyseurs syntaxiques (crowdsecurity/geoip-enrich). - Il enregistre un videur pour BunkerWeb et configure automatiquement la clé API dans
/etc/bunkerweb/variables.env. - Si vous sélectionnez également le composant AppSec, il installe les
appsec-virtual-patchingcollections etappsec-generic-rulesconfigure le point de terminaison AppSec pour BunkerWeb.
Cela permet une intégration transparente et prête à l'emploi pour une prévention puissante des intrusions.
Considérations RHEL
Prise en charge des bases de données externes sur les systèmes basés sur RHEL
Si vous envisagez d'utiliser une base de données externe (recommandée pour la production), installez le paquet client approprié:
# Pour MariaDB
sudo dnf install mariadb
# Pour MySQL
sudo dnf install mysql
# Pour PostgreSQL
sudo dnf install postgresql
Ceci est nécessaire pour que le Scheduler de BunkerWeb puisse se connecter à votre base de données externe.
Après l'installation
En fonction de vos choix lors de l'installation :
Avec l'assistant d'installation activé :
- Accédez à l'assistant de configuration à l'adresse suivante :
https://your-server-ip/setup - Suivez la configuration guidée pour configurer votre premier service protégé
- Configurer les certificats SSL/TLS et d'autres paramètres de sécurité
Sans assistant d'installation :
- Modifier
/etc/bunkerweb/variables.envpour configurer BunkerWeb manuellement - Ajouter les paramètres de votre serveur et les services protégés
- Redémarrez le Scheduler :
sudo systemctl restart bunkerweb-scheduler
Installation à l'aide du gestionnaire de paquets
Veuillez vous assurer que NGINX 1.28.0 est installé avant d'installer BunkerWeb. Pour toutes les distributions, à l'exception de Fedora, il est obligatoire d'utiliser des paquets préconstruits à partir du dépôt officiel NGINX. La compilation de NGINX à partir des sources ou l'utilisation de paquets provenant de différents dépôts ne fonctionnera pas avec les paquets officiels préconstruits de BunkerWeb. Cependant, vous avez la possibilité de construire BunkerWeb à partir des sources.
La première étape consiste à ajouter le dépôt officiel NGINX :
sudo apt install -y curl gnupg2 ca-certificates lsb-release debian-archive-keyring && \
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null && \
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/debian `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list
Vous devriez maintenant pouvoir installer NGINX 1.28.0 :
sudo apt update && \
sudo apt install -y --allow-downgrades nginx=1.28.0-1~$(lsb_release -cs)
Version testing/dev
Si vous utilisez la version testing ou dev, vous devrez ajouter la directive force-bad-version à votre fichier /etc/dpkg/dpkg.cfg avant d'installer BunkerWeb.
echo "force-bad-version" | sudo tee -a /etc/dpkg/dpkg.cfg
Désactiver l'assistant d'installation
Si vous ne souhaitez pas utiliser l'assistant de configuration de l'interface Web lors de l'installation de BunkerWeb, exportez la variable suivante :
export UI_WIZARD=no
Et enfin, installez BunkerWeb testing :
curl -s https://repo.bunkerweb.io/install/script.deb.sh | sudo bash && \
sudo apt update && \
sudo -E apt install -y --allow-downgrades bunkerweb=testing
Pour empêcher la mise à jour des paquets NGINX et/ou BunkerWeb lors de l'exécution de apt upgrade, vous pouvez utiliser la commande suivante :
sudo apt-mark hold nginx bunkerweb
La première étape consiste à ajouter le dépôt officiel NGINX :
sudo apt install -y curl gnupg2 ca-certificates lsb-release ubuntu-keyring && \
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null && \
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list
Vous devriez maintenant pouvoir installer NGINX 1.28.0 :
sudo apt update && \
sudo apt install -y --allow-downgrades nginx=1.28.0-1~$(lsb_release -cs)
Version testing/dev
Si vous utilisez la version testing ou dev, vous devrez ajouter la directive force-bad-version à votre fichier /etc/dpkg/dpkg.cfg avant d'installer BunkerWeb.
echo "force-bad-version" | sudo tee -a /etc/dpkg/dpkg.cfg
Désactiver l'assistant d'installation
Si vous ne souhaitez pas utiliser l'assistant de configuration de l'interface Web lors de l'installation de BunkerWeb, exportez la variable suivante :
export UI_WIZARD=no
Et enfin, installez BunkerWeb testing :
curl -s https://repo.bunkerweb.io/install/script.deb.sh | sudo bash && \
sudo apt update && \
sudo -E apt install -y --allow-downgrades bunkerweb=testing
Pour empêcher la mise à jour des paquets NGINX et/ou BunkerWeb lors de l'exécution de apt upgrade, vous pouvez utiliser la commande suivante :
sudo apt-mark hold nginx bunkerweb
Fedora Update Testing
Si vous ne trouvez pas la version de NGINX répertoriée dans le dépôt stable, vous pouvez activer le dépôt updates-testing :
sudo dnf config-manager setopt updates-testing.enabled=1
Fedora fournit déjà NGINX 1.28.0, que nous prenons en charge :
sudo dnf install -y --allowerasing nginx-1.28.0
Désactiver l'assistant d'installation
Si vous ne souhaitez pas utiliser l'assistant de configuration de l'interface Web lors de l'installation de BunkerWeb, exportez la variable suivante :
export UI_WIZARD=no
Et enfin, installez BunkerWeb testing :
curl -s https://repo.bunkerweb.io/install/script.rpm.sh | sudo bash && \
sudo dnf makecache && \
sudo -E dnf install -y --allowerasing bunkerweb-testing
Pour empêcher la mise à jour des paquets NGINX et/ou BunkerWeb lors de l'exécution de dnf upgrade, vous pouvez utiliser la commande suivante :
sudo dnf versionlock add nginx && \
sudo dnf versionlock add bunkerweb
La première étape consiste à ajouter le dépôt officiel NGINX. Créez le fichier suivant dans /etc/yum.repos.d/nginx.repo :
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
Vous devriez maintenant pouvoir installer NGINX 1.28.0 :
sudo dnf install --allowerasing nginx-1.28.0
Désactiver l'assistant d'installation
Si vous ne souhaitez pas utiliser l'assistant de configuration de l'interface Web lors de l'installation de BunkerWeb, exportez la variable suivante :
export UI_WIZARD=no
Enfin, installez BunkerWeb testing :
curl -s https://repo.bunkerweb.io/install/script.rpm.sh | sudo bash && \
sudo dnf check-update && \
sudo -E dnf install -y --allowerasing bunkerweb-testing
Pour empêcher la mise à jour des paquets NGINX et/ou BunkerWeb lors de l'exécution de dnf upgrade, vous pouvez utiliser la commande suivante :
sudo dnf versionlock add nginx && \
sudo dnf versionlock add bunkerweb
Configuration et service
La configuration manuelle de BunkerWeb se fait en éditant le /etc/bunkerweb/variables.env fichier :
MY_SETTING_1=value1
MY_SETTING_2=value2
...
Une fois installé, BunkerWeb est livré avec trois services bunkerweb, bunkerweb-scheduler et bunkerweb-ui que vous pouvez gérer à l'aide systemctlde .
Si vous modifiez manuellement la configuration de BunkerWeb à l'aide /etc/bunkerweb/variables.env d'un redémarrage du bunkerweb-scheduler service, il suffira de générer et de recharger la configuration sans aucun temps d'arrêt. Mais selon le cas (par exemple, en changeant de port d'écoute), vous devrez peut-être redémarrer le bunkerweb service.
Haute disponibilité
Le Scheduler peut être détaché de l'instance BunkerWeb pour fournir une haute disponibilité. Dans ce cas, le Scheduler sera installé sur un serveur séparé et pourra gérer plusieurs instances BunkerWeb.
Manager
Pour installer uniquement le Scheduler sur un serveur, vous pouvez exporter les variables suivantes avant d'exécuter l'installation de BunkerWeb :
export MANAGER_MODE=yes
export UI_WIZARD=no
Vous pouvez également exporter les variables suivantes pour activer uniquement le Scheduler :
export SERVICE_SCHEDULER=yes
export SERVICE_BUNKERWEB=no
export SERVICE_UI=no
Worker
Sur un autre serveur, pour installer uniquement BunkerWeb, vous pouvez exporter les variables suivantes avant d'exécuter l'installation de BunkerWeb :
export WORKER_MODE=yes
Alternativement, vous pouvez également exporter les variables suivantes pour activer uniquement BunkerWeb :
export SERVICE_BUNKERWEB=yes
export SERVICE_SCHEDULER=no
export SERVICE_UI=no
Interface utilisateur Web
L'interface utilisateur Web peut être installée sur un serveur séparé pour fournir une interface dédiée à la gestion des instances BunkerWeb. Pour installer uniquement l'interface utilisateur Web, vous pouvez exporter les variables suivantes avant d'exécuter l'installation de BunkerWeb :
export SERVICE_BUNKERWEB=no
export SERVICE_SCHEDULER=no
export SERVICE_UI=yes
Docker autoconf
Intégration Docker
L'intégration de Docker autoconf est une "évolution" de celle de Docker. Veuillez d'abord lire la section sur l' intégration Docker si nécessaire.
Une autre approche est disponible pour résoudre l'inconvénient de recréer le conteneur chaque fois qu'il y a une mise à jour. En utilisant une autre image appelée autoconf, vous pouvez automatiser la reconfiguration en temps réel de BunkerWeb sans avoir besoin de recréer des conteneurs.
Pour tirer parti de cette fonctionnalité, au lieu de définir des variables d'environnement pour le conteneur BunkerWeb, vous pouvez ajouter des étiquettes à vos conteneurs d'application Web. L'image autoconf écoutera alors les événements Docker et gérera de manière transparente les mises à jour de configuration pour BunkerWeb.
Ce processus « automagique » simplifie la gestion des configurations BunkerWeb. En ajoutant des étiquettes à vos conteneurs d'applications web, vous pouvez déléguer les tâches de reconfiguration à autoconf sans l'intervention manuelle de la recréation de conteneurs. Cela simplifie le processus de mise à jour et améliore la commodité.
En adoptant cette approche, vous pouvez profiter d'une reconfiguration en temps réel de BunkerWeb sans avoir à vous soucier de la recréation de conteneurs, ce qui le rend plus efficace et plus convivial.
Mode multisite
L'intégration de Docker autoconf implique l'utilisation du mode multisite. Pour plus d'informations, reportez-vous à la section multisite de la documentation.
Backend de base de données
Veuillez noter que nos instructions supposent que vous utilisez MariaDB comme backend de base de données par défaut, tel que configuré par le DATABASE_URI paramètre. Cependant, nous comprenons que vous préférerez peut-être utiliser d'autres backends pour votre intégration Docker. Si c'est le cas, soyez assuré que d'autres backends de base de données sont toujours possibles. Pour plus d'informations, consultez les fichiers docker-compose dans le dossier misc/integrations du dépôt.
Pour activer les mises à jour automatiques de la configuration, incluez un conteneur supplémentaire appelé bw-autoconf dans la pile. Ce conteneur héberge le service autoconf, qui gère les modifications de configuration dynamiques pour BunkerWeb.
Pour prendre en charge cette fonctionnalité, utilisez un "vrai" backend de base de données dédié (par exemple, MariaDB, MySQL ou PostgreSQL) pour le stockage de configuration synchronisé. En intégrant bw-autoconf un backend de base de données approprié, vous établissez l'infrastructure pour une gestion automatisée de la configuration sans faille dans BunkerWeb.
x-bw-env: &bw-env
# We use an anchor to avoid repeating the same settings for both containers
AUTOCONF_MODE: "yes"
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24"
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp" # QUIC
labels:
- "bunkerweb.INSTANCE=yes" # Mandatory label for the autoconf service to identify the BunkerWeb instance
environment:
<<: *bw-env
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
environment:
<<: *bw-env
BUNKERWEB_INSTANCES: "" # We don't need to specify the BunkerWeb instance here as they are automatically detected by the autoconf service
SERVER_NAME: "" # The server name will be filled with services labels
MULTISITE: "yes" # Mandatory setting for autoconf
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Remember to set a stronger password for the database
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
restart: "unless-stopped"
networks:
- bw-universe
- bw-db
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:testing
depends_on:
- bunkerweb
- bw-docker
environment:
AUTOCONF_MODE: "yes"
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Remember to set a stronger password for the database
DOCKER_HOST: "tcp://bw-docker:2375" # The Docker socket
restart: "unless-stopped"
networks:
- bw-universe
- bw-docker
- bw-db
bw-docker:
image: tecnativa/docker-socket-proxy:nightly
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
CONTAINERS: "1"
LOG_LEVEL: "warning"
restart: "unless-stopped"
networks:
- bw-docker
bw-db:
image: mariadb:11
# We set the max allowed packet size to avoid issues with large queries
command: --max-allowed-packet=67108864
environment:
MYSQL_RANDOM_ROOT_PASSWORD: "yes"
MYSQL_DATABASE: "db"
MYSQL_USER: "bunkerweb"
MYSQL_PASSWORD: "changeme" # Remember to set a stronger password for the database
volumes:
- bw-data:/var/lib/mysql
restart: "unless-stopped"
networks:
- bw-db
volumes:
bw-data:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24
bw-services:
name: bw-services
bw-docker:
name: bw-docker
bw-db:
name: bw-db
Base de données dans le bw-db réseau
Le conteneur de base de données n'est intentionnellement pas inclus dans le bw-universe réseau. Il est utilisé par les bw-autoconf bw-scheduler conteneurs et plutôt que directement par BunkerWeb. Par conséquent, le conteneur de base de données fait partie du bw-db réseau, ce qui renforce la sécurité en rendant l'accès externe à la base de données plus difficile. Ce choix de conception délibéré permet de protéger la base de données et de renforcer la perspective de sécurité globale du système.
Utilisation de Docker en mode rootless
Si vous utilisez Docker en mode rootless, vous devrez remplacer le support du socket docker par la valeur suivante : $XDG_RUNTIME_DIR/docker.sock:/var/run/docker.sock:ro.
Les services d'Autoconf
Une fois la pile configurée, vous pourrez créer le conteneur de l'application web et ajouter les paramètres sous forme d'étiquettes à l'aide du préfixe "bunkerweb." afin de configurer automatiquement BunkerWeb :
services:
myapp:
image: mywebapp:4.2
networks:
- bw-services
labels:
- "bunkerweb.MY_SETTING_1=value1"
- "bunkerweb.MY_SETTING_2=value2"
networks:
bw-services:
external: true
name: bw-services
Espaces de noms
À partir de la version 1.6.0, les piles Autoconf de BunkerWeb supportent désormais les espaces de noms. Cette fonctionnalité vous permet de gérer plusieurs « clusters » d'instances et de services BunkerWeb sur le même hôte Docker. Pour tirer parti des espaces de noms, il vous suffit de définir l' NAMESPACE étiquette sur vos services. Voici un exemple :
services:
myapp:
image: mywebapp:4.2
networks:
- bw-services
labels:
- "bunkerweb.NAMESPACE=my-namespace" # Set the namespace for the service
- "bunkerweb.MY_SETTING_1=value1"
- "bunkerweb.MY_SETTING_2=value2"
networks:
bw-services:
external: true
name: bw-services
Comportement de l'espace de nommage
By default all Autoconf stacks listen to all namespaces. If you want to restrict a stack to specific namespaces, you can set the NAMESPACES environment variable in the bw-autoconf service:
...
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
labels:
- "bunkerweb.INSTANCE=yes"
- "bunkerweb.NAMESPACE=my-namespace" # Set the namespace for the BunkerWeb instance so the autoconf service can detect it
...
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:testing
environment:
...
NAMESPACES: "my-namespace my-other-namespace" # Only listen to these namespaces
...
Keep in mind that the NAMESPACES environment variable is a space-separated list of namespaces.
Spécifications de l'espace de nommage
There can only be one database and one Scheduler per namespace. If you try to create multiple databases or Schedulers in the same namespace, the configurations will end up conflicting with each other.
The Scheduler doesn't need the NAMESPACE label to work properly. It will only need the DATABASE_URI setting properly configured so that it can access the same database as the autoconf service.
Kubernetes
Pour automatiser la configuration des instances BunkerWeb dans un environnement Kubernetes, le service autoconf sert de contrôleur d'entrée. Il configure les instances BunkerWeb en fonction des ressources d'entrée et surveille également d'autres objets Kubernetes, tels que ConfigMap, pour des configurations personnalisées.
Synchronisation des ConfigMap
- Le contrôleur d'entrée ne gère que les ConfigMap portant l'annotation
bunkerweb.io/CONFIG_TYPE. - Ajoutez
bunkerweb.io/CONFIG_SITEpour restreindre la configuration à un service (le nom de serveur doit déjà exister); laissez l'annotation vide pour qu'elle s'applique globalement. - Supprimer l'annotation ou la ConfigMap retire la configuration personnalisée correspondante dans BunkerWeb.
Pour une configuration optimale, il est recommandé de définir BunkerWeb en tant que DaemonSet, ce qui garantit qu'un pod est créé sur tous les nœuds, tandis que l'autoconf et le scheduler sont définis comme un seul déploiement répliqué.
Compte tenu de la présence de plusieurs instances BunkerWeb, il est nécessaire d'établir un magasin de données partagé implémenté en tant que service Redis ou Valkey. Ce service sera utilisé par les instances pour mettre en cache et partager des données entre elles. Vous trouverez de plus amples informations sur les paramètres Redis/Valkey ici.
Backend de base de données
Veuillez noter que nos instructions supposent que vous utilisez MariaDB comme backend de base de données par défaut, tel que configuré par le DATABASE_URI paramètre. Cependant, nous comprenons que vous préférerez peut-être utiliser d'autres backends pour votre intégration Docker. Si c'est le cas, soyez assuré que d'autres backends de base de données sont toujours possibles. Pour plus d'informations, consultez les fichiers docker-compose dans le dossier misc/integrations du dépôt.
La configuration des backends de base de données en cluster est hors du périmètre de cette documentation.
Assurez-vous que les services autoconf ont accès à l'API Kubernetes. Il est recommandé d'utiliser l' autorisation RBAC à cette fin.
Autorité de certification personnalisée pour l'API Kubernetes
Si vous utilisez une autorité de certification personnalisée pour votre API Kubernetes, vous pouvez monter un fichier de bundle contenant vos certificats intermédiaires et racines sur le contrôleur d'entrée et définir la KUBERNETES_SSL_CA_CERT valeur de l'environnement sur le chemin d'accès du bundle à l'intérieur du conteneur. Sinon, même si cela n'est pas recommandé, vous pouvez désactiver la vérification du certificat en définissant la KUBERNETES_SSL_VERIFY variable d'environnement du contrôleur d'entrée sur no (la valeur par défaut yesest ).
De plus, il est crucial de définir la KUBERNETES_MODE variable d'environnement lors yes de l'utilisation de l'intégration Kubernetes. Cette variable est obligatoire pour un bon fonctionnement.
Méthodes d'installation
Utilisation de la charte Helm (recommandé)
La méthode recommandée pour installer Kubernetes est d'utiliser la charte Helm disponible à l'adresse https://github.com/bunkerity/bunkerweb-helm:
helm repo add bunkerweb https://repo.bunkerweb.io/charts
Vous pouvez ensuite utiliser le tableau de bord de bunkerweb à partir de ce dépôt :
helm install -f myvalues.yaml mybunkerweb bunkerweb/bunkerweb
La liste complète des valeurs est répertoriée dans le fichier charts/bunkerweb/values.yaml du dépôt bunkerity/bunkerweb-helm.
Conteneur Sidecar + Helm
Cette documentation explique comment déployer BunkerWeb en tant que sidecar pour protéger vos applications Kubernetes. Dans cette architecture, chaque application possède son propre conteneur BunkerWeb qui agit comme un reverse proxy de sécurité.
Architecture
flowchart TB
%% ---------- Styles ----------
classDef scheduler fill:#eef2ff,stroke:#4c1d95,stroke-width:1px,rx:6px,ry:6px;
classDef podContainer fill:none,stroke:#9ca3af,stroke-width:1px,stroke-dasharray:6 3,rx:6px,ry:6px;
classDef component fill:#f9fafb,stroke:#6b7280,stroke-width:1px,rx:4px,ry:4px;
classDef lb fill:#e0f2fe,stroke:#0369a1,stroke-width:1px,rx:6px,ry:6px;
%% ---------- Haut : Scheduler ----------
SCHED["Scheduler BunkerWeb (centralisé)<br/>+ UI + MariaDB + Redis"]:::scheduler
%% ---------- Groupe de Pods ----------
subgraph PODS["Pods"]
%% Pod d'application 1 ----------
subgraph POD1["Pod d'application"]
BW1["BunkerWeb"]:::component
APP1["Application<br/>(port 80)"]:::component
BW1 -->|requêtes légitimes| APP1
end
class POD1 podContainer
%% Pod d'application 2 ----------
subgraph POD2["Pod d'application"]
BW2["BunkerWeb"]:::component
APP2["Application<br/>(port XX)"]:::component
BW2 -->|requêtes légitimes| APP2
end
class POD2 podContainer
end
%% ---------- Équilibreur de charge (en bas) ----------
LB["Équilibreur de charge"]:::lb
%% ---------- Câblage (visible, sémantique) ----------
%% Le Scheduler contrôle les instances BunkerWeb (API)
SCHED -->|API 5000| BW1
SCHED -->|API 5000| BW2
%% L'équilibreur de charge envoie le trafic vers BunkerWeb
LB -->|HTTP/HTTPS| BW1
LB -->|HTTP/HTTPS| BW2
%% ---------- Aide à la mise en page (caché) ----------
%% Place l'équilibreur de charge sous tout le groupe PODS
PODS --> LB
linkStyle 6 stroke-width:0px,stroke:transparent;Prérequis
- Un cluster Kubernetes fonctionnel
- Helm 3.x installé
- Le chart Helm BunkerWeb déployé avec :
scheduleractivéuiactivéemariadbactivé (pour stocker les configurations)redisactivé (pour la synchronisation)controlleractivé (recommandé pour la découverte automatique des sidecars)bunkerweb.replicas: 0(pas de déploiement standalone)
Modes de Découverte des Sidecars
BunkerWeb propose deux modes de découverte des sidecars :
Mode 1 : Découverte Automatique (Controller - Recommandé)
Le controller BunkerWeb découvre automatiquement les pods avec sidecars BunkerWeb sans configuration manuelle.
Avantages :
- ✅ Découverte automatique des nouveaux sidecars
- ✅ Pas besoin de maintenir manuellement BUNKERWEB_INSTANCES
- ✅ Mise à l'échelle automatique
Configuration :
-
Activez le controller dans
values.yaml:controller: enabled: true tag: "1.6.5" -
Pour chaque sidecar, ajoutez :
- Annotation du pod :
bunkerweb.io/INSTANCE: "yes" - Variable d'environnement :
KUBERNETES_MODE: "yes"
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-bunkerweb
namespace: bunkerweb
spec:
replicas: 1
selector:
matchLabels:
app: nginx-bw
template:
metadata:
labels:
app: nginx-bw
annotations:
# Mandatory annotation for auto-discovery when using bunkerweb-controller
bunkerweb.io/INSTANCE: "yes"
spec:
containers:
# Random WebApp you want to protect
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
# Sidecar BunkerWeb
- name: bunkerweb
image: bunkerity/bunkerweb:latest
ports:
- containerPort: 8080
name: entrypoint
- containerPort: 5000
name: bwapi
- containerPort: 9113
name: metrics
env:
- name: API_WHITELIST_IP
value: "127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16"
- name: KUBERNETES_MODE
value: "yes"
---
apiVersion: v1
kind: Service
metadata:
name: nginx-bunkerweb
namespace: bunkerweb
spec:
type: ClusterIP
selector:
app: nginx-bw
ports:
- name: http
port: 80
targetPort: 8080 # BunkerWeb exposed port
-
Pas besoin de service headless - le controller communique directement avec les pods
-
Pas besoin de configurer le scheduler manuellement
BUNKERWEB_INSTANCES- le controller gère la découverte
Mode 2 : Configuration Manuelle (BUNKERWEB_INSTANCES)
Configuration explicite de chaque instance via la variable d'environnement BUNKERWEB_INSTANCES.
Avantages : - ✅ Contrôle précis des instances gérées - ✅ Utile pour des environnements multi-namespace complexes
Configuration :
Voir les sections suivantes pour les détails.
Étape 1 : Configuration du Scheduler
Le scheduler BunkerWeb est le composant central qui distribue les configurations à tous les sidecars.
Option A : Avec le Controller (Recommandé)
Si vous utilisez le controller pour la découverte automatique, aucune configuration spéciale n'est nécessaire pour le scheduler. Le controller détectera automatiquement les pods avec l'annotation bunkerweb.io/INSTANCE: "yes".
Option B : Configuration Manuelle avec BUNKERWEB_INSTANCES
Dans votre fichier values.yaml du chart BunkerWeb, configurez la variable d'environnement BUNKERWEB_INSTANCES avec les URLs de tous vos services headless :
scheduler:
tag: "testing-rc2"
extraEnvs:
- name: BUNKERWEB_INSTANCES
value: "http://app1-bunkerweb-workers.namespace.svc.cluster.local:5000 http://app2-bunkerweb-workers.namespace.svc.cluster.local:5000"
Important :
- Séparez les URLs par des espaces
- Utilisez le port 5000 (API interne de BunkerWeb)
- Format : http://<service-name>.<namespace>.svc.cluster.local:5000
Étape 2 : Création du Déploiement avec Sidecar
Structure du Déploiement
Créez un déploiement Kubernetes avec deux conteneurs :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mon-app-bunkerweb
namespace: votre-namespace
spec:
replicas: 1
selector:
matchLabels:
app: mon-app
template:
metadata:
labels:
app: mon-app
spec:
containers:
# Votre application
- name: mon-app
image: mon-image:latest
ports:
- containerPort: 80 # Port sur lequel écoute votre app
# Sidecar BunkerWeb
- name: bunkerweb
image: bunkerity/bunkerweb:testing-rc2
ports:
- containerPort: 8080 # Port HTTP exposé
- containerPort: 5000 # API interne (obligatoire)
name: bwapi
- containerPort: 9113 # Prometheus exporter
name: metrics
env:
- name: KUBERNETES_MODE # OBLIGATOIRE pour le mode controller
value: "yes"
- name: API_WHITELIST_IP
value: "127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16"
---
apiVersion: v1
kind: Service
metadata:
name: nginx-bunkerweb
namespace: bunkerweb
spec:
type: ClusterIP
selector:
app: nginx-bw
ports:
- name: http
port: 80
targetPort: 8080 # BunkerWeb exposed port
```
**Points clés :**
- **Annotation obligatoire** : `bunkerweb.io/INSTANCE: "yes"` doit être ajoutée dans `template.metadata.annotations` (au même niveau que `labels`)
- **Variable d'environnement obligatoire** : `KUBERNETES_MODE: "yes"` active le mode Kubernetes
- **Pas de service headless nécessaire** : le controller communique directement avec les pods
###### Variables d'environnement importantes
| Variable | Valeur | Description |
| ------------------ | ----------------------------------------------------- | ---------------------------------------------------------------- |
| `KUBERNETES_MODE` | `yes` | **Obligatoire** pour la découverte automatique via le controller |
| `API_WHITELIST_IP` | `127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16` | IPs autorisées à accéder à l'API |
##### Étape 3 : Création des Services
###### Service ClusterIP (exposition externe)
Service pour exposer votre application via BunkerWeb :
```yaml
apiVersion: v1
kind: Service
metadata:
name: mon-app-bunkerweb
namespace: votre-namespace
spec:
type: ClusterIP # ou LoadBalancer selon vos besoins
selector:
app: mon-app
ports:
- name: http
port: 80
targetPort: 8080 # Port BunkerWeb
Service Headless (API interne) - Conditionnel
Uniquement requis en mode manuel (sans controller) :
apiVersion: v1
kind: Service
metadata:
name: mon-app-bunkerweb-workers
namespace: votre-namespace
spec:
clusterIP: None # Service headless
selector:
app: mon-app
ports:
- name: bwapi
protocol: TCP
port: 5000
targetPort: 5000
Important :
- ⚠️ Non requis avec le controller - le controller communique directement avec les pods via l'API Kubernetes
- ✅ Obligatoire sans le controller - le nom de ce service doit être ajouté manuellement dans BUNKERWEB_INSTANCES
- Le selector doit correspondre aux labels de votre déploiement
Étape 4 : Configuration du Reverse Proxy
Vous avez deux options pour configurer le reverse proxy :
Option A : Via l'Interface Web (UI)
- Accédez à l'UI de BunkerWeb
- Allez dans la section "Services"
- Créez un nouveau service avec :
- Server name :
mon-app.example.com - Reverse proxy host :
http://127.0.0.1:80(ou le port de votre app) - Use reverse proxy :
yes - Sauvegardez
Le scheduler enverra automatiquement la configuration au sidecar via l'API (port 5000).
Option B : Via Variables d'Environnement
Ajoutez ces variables dans le conteneur bunkerweb :
env:
- name: MULTISITE
value: "yes"
- name: SERVER_NAME
value: "mon-app.example.com"
- name: mon-app.example.com_USE_REVERSE_PROXY
value: "yes"
- name: mon-app.example.com_REVERSE_PROXY_HOST
value: "http://127.0.0.1:80"
- name: mon-app.example.com_REVERSE_PROXY_URL
value: "/"
Note : L'option UI est recommandée pour une gestion centralisée et dynamique.
Étape 5 : Déploiement
Avec le Controller (Mode Automatique - Recommandé)
- Déployez votre application avec le sidecar :
kubectl apply -f mon-app-deployment.yaml
Assurez-vous que :
- L'annotation bunkerweb.io/INSTANCE: "yes" est présente dans template.metadata.annotations
- La variable KUBERNETES_MODE: "yes" est définie dans le conteneur bunkerweb
-
Vérifiez que le controller détecte le sidecar :
Vous devriez voir des logs indiquant la découverte du nouveau pod.kubectl logs -n bunkerweb deployment/bunkerweb-controller -f -
Créez la configuration du reverse proxy via l'UI de BunkerWeb
-
Testez votre application :
curl -H "Host: mon-app.example.com" http://<service-ip>
Sans Controller (Mode Manuel)
-
Déployez votre application avec le sidecar :
kubectl apply -f mon-app-deployment.yaml -
Ajoutez le service headless dans
BUNKERWEB_INSTANCES: Mettez à jour votrevalues.yamlet upgrader le chart Helm :helm upgrade bunkerweb bunkerity/bunkerweb -n bunkerweb -f values.yaml -
Vérifiez que le scheduler détecte le sidecar :
Vous devriez voir des logs indiquant la connexion au nouveau worker.kubectl logs -n bunkerweb deployment/bunkerweb-scheduler -f -
Créez la configuration du reverse proxy via l'UI de BunkerWeb
-
Testez votre application :
curl -H "Host: mon-app.example.com" http://<service-ip>
Problèmes courants
| Problème | Cause | Solution |
|---|---|---|
| Le scheduler ne trouve pas le sidecar | Service headless manquant ou mal configuré | Vérifier que le service existe et est dans BUNKERWEB_INSTANCES |
| Erreur 502 Bad Gateway | L'app n'est pas accessible depuis BunkerWeb | Vérifier que l'URL du reverse proxy est correcte (127.0.0.1:port) |
| Configuration non appliquée | Le sidecar n'a pas reçu la config | Vérifier les logs du scheduler et du sidecar |
| Port 5000 non accessible | Port non exposé dans le conteneur | Ajouter - containerPort: 5000 dans le conteneur bunkerweb |
Ajouter une Nouvelle Application
Avec le Controller (Mode Automatique)
Pour ajouter une nouvelle application protégée par BunkerWeb :
- Créez un nouveau déploiement avec le sidecar BunkerWeb avec :
- Annotation
bunkerweb.io/INSTANCE: "yes"danstemplate.metadata.annotations -
Variable d'environnement
KUBERNETES_MODE: "yes"dans le conteneur bunkerweb -
Créez uniquement le service ClusterIP (pas de service headless nécessaire !)
-
Appliquez le déploiement :
kubectl apply -f nouvelle-app-deployment.yaml -
Le controller détecte automatiquement le nouveau pod - pas besoin de redéployer le chart !
-
Configurez le reverse proxy dans l'UI
Sans le Controller (Mode Manuel)
Pour ajouter une nouvelle application protégée par BunkerWeb :
-
Créez un nouveau déploiement avec le sidecar BunkerWeb (comme décrit ci-dessus)
-
Créez les deux services (ClusterIP + Headless)
-
Ajoutez le nouveau service headless dans
BUNKERWEB_INSTANCES:extraEnvs: - name: BUNKERWEB_INSTANCES value: "http://app1-workers.ns.svc.cluster.local:5000 http://app2-workers.ns.svc.cluster.local:5000" -
Redéployez le chart :
helm upgrade bunkerweb bunkerity/bunkerweb -n bunkerweb -f values.yaml -
Configurez le reverse proxy dans l'UI
Bonnes Pratiques
✅ Utilisez le controller pour la découverte automatique des sidecars (plus simple, pas de service headless nécessaire)
✅ Utilisez un seul scheduler centralisé pour gérer tous les sidecars
✅ Ajoutez toujours l'annotation bunkerweb.io/INSTANCE: "yes" et la variable KUBERNETES_MODE: "yes" en mode controller
✅ Pas de service headless avec le controller - seul le service ClusterIP est nécessaire
✅ Utilisez l'UI pour gérer les configurations (plus flexible)
✅ Définissez des resource limits pour les conteneurs
✅ Utilisez des secrets Kubernetes pour les configurations sensibles
✅ Vérifiez les logs du scheduler et des sidecars régulièrement
Fichiers YAML complets
Au lieu d'utiliser la charte Helm, vous pouvez également utiliser les modèles YAML dans le dossier misc/integrations du référentiel GitHub. Veuillez noter que nous vous recommandons vivement d'utiliser le tableau de barre à la place.
Ressources d'entrée
Une fois que la pile Kubernetes de BunkerWeb est correctement configurée et opérationnelle (reportez-vous aux journaux autoconf pour plus d'informations), vous pouvez procéder au déploiement d'applications Web au sein du cluster et déclarer votre ressource d'entrée.
Il est important de noter que les paramètres BunkerWeb doivent être spécifiés en tant qu'annotations pour la ressource Ingress. Pour la partie domaine, veuillez utiliser la valeur spéciale bunkerweb.io. En incluant les annotations appropriées, vous pouvez configurer BunkerWeb en conséquence pour la ressource Ingress.
Ignorer les annotations bruyantes
Lorsque certaines annotations ne doivent pas impacter autoconf, définissez KUBERNETES_IGNORE_ANNOTATIONS sur le déploiement du contrôleur. Fournissez une liste de clés d'annotations séparées par des espaces ou des virgules (par exemple bunkerweb.io/EXTRA_FOO) ou simplement le suffixe (EXTRA_FOO). Les annotations correspondantes sont supprimées des paramètres dérivés de l'ingress, et les pods les portant sont entièrement ignorés lors de la découverte des instances.
Prise en charge TLS
Le contrôleur d'entrée BunkerWeb prend entièrement en charge les certificats HTTPS personnalisés à l'aide de la spécification tls, comme indiqué dans l'exemple. La configuration de solutions telles que cert-manager la génération automatique de secrets tls n'entre pas dans le cadre de cette documentation.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
# Will be applied to all host in this ingress
bunkerweb.io/MY_SETTING: "value"
# Will only be applied to the www.example.com host
bunkerweb.io/www.example.com_MY_SETTING: "value"
spec:
# TLS is optional, you can also use builtin Let's Encrypt for example
# tls:
# - hosts:
# - www.example.com
# secretName: secret-example-tls
rules:
- host: www.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: svc-my-app
port:
number: 8000
...
Espaces de noms
À partir de la version 1.6.0, les piles autoconf de BunkerWeb prennent désormais en charge les espaces de noms. Cette fonctionnalité vous permet de gérer plusieurs clusters d'instances et de services BunkerWeb sur le même cluster Kubernetes. Pour tirer parti des espaces de noms, il suffit de définir le namespace champ de métadonnées sur vos instances et services BunkerWeb. Voici un exemple :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: bunkerweb
namespace: my-namespace # Set the namespace for the BunkerWeb instance
...
Comportement de l'espace de nommage
Par défaut, toutes les piles Autoconf écoutent tous les namespaces. Si vous souhaitez restreindre une pile à des namespaces spécifiques, vous pouvez définir la variable d'environnement NAMESPACES dans le déploiement bunkerweb-controller :
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: bunkerweb-controller
namespace: my-namespace # Set the namespace for the Controller
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: bunkerweb-controller
template:
metadata:
labels:
app: bunkerweb-controller
spec:
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-controller
image: bunkerity/bunkerweb-autoconf:testing
imagePullPolicy: Always
env:
- name: NAMESPACES
value: "my-namespace my-other-namespace" # Only listen to these namespaces
...
...
Gardez à l'esprit que la variable d'environnement NAMESPACES est une liste de namespaces séparés par des espaces.
Spécifications de l'espace de nommage
Il ne peut y avoir qu'une seule base de données et qu'un seul Scheduler par namespace. Si plusieurs bases de données ou plusieurs Schedulers sont créés dans le même namespace, les configurations entreront en conflit.
Le Scheduler n'a pas besoin de l'annotation NAMESPACE pour fonctionner correctement. Il suffit que le paramètre DATABASE_URI soit correctement configuré afin qu'il puisse accéder à la même base de données que le service autoconf.
Classe d'entrée
Lorsqu'il est installé en utilisant les méthodes officielles de la documentation, BunkerWeb est livré avec la définition suivante IngressClass :
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: bunkerweb
spec:
controller: bunkerweb.io/ingress-controller
Afin de limiter les Ingress ressources surveillées par le contrôleur d'entrée, vous pouvez définir la KUBERNETES_INGRESS_CLASS variable d'environnement avec la valeur bunkerweb. Ensuite, vous pouvez utiliser la ingressClassName directive dans vos Ingress définitions :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
bunkerweb.io/MY_SETTING: "value"
bunkerweb.io/www.example.com_MY_SETTING: "value"
spec:
ingressClassName: bunkerweb
rules:
- host: www.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: svc-my-app
port:
number: 8000
Nom de domaine personnalisé
Si vous utilisez un nom de domaine personnalisé différent de celui par défaut pour votre cluster Kubernetes kubernetes.local , vous pouvez définir la valeur à l'aide de la KUBERNETES_DOMAIN_NAME variable d'environnement sur le conteneur du Scheduler.
Utilisation avec le contrôleur d'entrée existant
Conserver à la fois le contrôleur d'entrée existant et BunkerWeb
Il s'agit d'un cas d'utilisation où vous souhaitez conserver un contrôleur d'entrée existant, tel que nginx. Le flux de trafic typique sera : équilibreur de charge => contrôleur d'entrée => BunkerWeb => application.
Installation du contrôleur d'entrée nginx
Installez le dépôt helm nginx d'entrée :
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
Installez le contrôleur d'entrée nginx avec les valeurs par défaut (il se peut qu'il ne fonctionne pas sur votre propre cluster prêt à l'emploi, veuillez consulter la documentation) :
helm install --namespace nginx --create-namespace nginx ingress-nginx/ingress-nginx
Extraire l'adresse IP de LB :
kubectl get svc nginx-ingress-nginx-controller -n nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
Configurez les entrées DNS sur l'adresse IP de LB (par exemple, bunkerweb le sous-domaine pour l'interface utilisateur BW et myapp pour l'application) :
$ nslookup bunkerweb.example.com
Server: 172.26.112.1
Address: 172.26.112.1#53
Non-authoritative answer:
Name: bunkerweb.example.com
Address: 1.2.3.4
$ nslookup myapp.example.com
Server: 172.26.112.1
Address: 172.26.112.1#53
Non-authoritative answer:
Name: myapp.example.com
Address: 1.2.3.4
Installation de BunkerWeb
Installez le dépôt helm de BunkerWeb :
helm repo add bunkerweb https://repo.bunkerweb.io/charts
helm repo update
Créer un values.yaml fichier :
# Here we will setup the values needed to setup BunkerWeb behind an existing ingress controller
# Traffic flow with BW: LB => existing Ingress Controller => BunkerWeb => Service
# Traffic flow without BW: LB => existing Ingress Controller => Service
# Global settings
settings:
misc:
# Replace with your DNS resolver
# to get it: kubectl exec in a random pod then cat /etc/resolv.conf
# if you have an IP as nameserver then do a reverse DNS lookup: nslookup <IP>
# most of the time it's coredns.kube-system.svc.cluster.local or kube-dns.kube-system.svc.cluster.local
dnsResolvers: "kube-dns.kube-system.svc.cluster.local"
kubernetes:
# We only consider Ingress resources with ingressClass bunkerweb to avoid conflicts with existing ingress controller
ingressClass: "bunkerweb"
# Optional: you can choose namespace(s) where BunkerWeb will listen for Ingress/ConfigMap changes
# Default (blank value) is all namespaces
namespaces: ""
# Override the bunkerweb-external service type to ClusterIP
# Since we don't need to expose it to the outside world
# We will use the existing ingress controller to route traffic to BunkerWeb
service:
type: ClusterIP
# BunkerWeb settings
bunkerweb:
tag: testing
# Scheduler settings
scheduler:
tag: testing
extraEnvs:
# Enable real IP module to get real IP of clients
- name: USE_REAL_IP
value: "yes"
# Controller settings
controller:
tag: testing
# UI settings
ui:
tag: testing
Installez BunkerWeb avec des valeurs personnalisées :
helm install --namespace bunkerweb --create-namespace -f values.yaml bunkerweb bunkerweb/bunkerweb
Vérifiez les journaux et attendez que tout soit prêt.
Installation de l'interface utilisateur Web
Configurez l'entrée suivante (en supposant que le contrôleur nginx est installé) :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ui-bunkerweb
# Replace with your namespace of BW if needed
namespace: bunkerweb
annotations:
# HTTPS is mandatory for web UI even if traffic is internal
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
# We must set SNI so BW can serve the right vhost
# Replace with your domain
nginx.ingress.kubernetes.io/proxy-ssl-name: "bunkerweb.example.com"
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"
spec:
# Only served by nginx controller and not BW
ingressClassName: nginx
# Uncomment and edit if you want to use your own certificate
# tls:
# - hosts:
# - bunkerweb.example.com
# secretName: tls-secret
rules:
# Replace with your domain
- host: bunkerweb.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
# Created by Helm chart
name: bunkerweb-external
port:
# Using HTTPS port is mandatory for UI
number: 443
Et vous pouvez maintenant passer à l'assistant de configuration en accédant à https://bunkerweb.example.com/setup.
Protection de l'application existante
Tout d'abord, vous devrez vous rendre dans Global Config, sélectionner le plugin SSL, puis désactiver la redirection automatique HTTP vers HTTPS. Veuillez noter que vous n'avez besoin de le faire qu'une seule fois.
Supposons que vous ayez une application dans l'espace de myapp noms qui est accessible à l'aide du myapp-service service sur le port 5000.
Vous devrez ajouter un nouveau service sur l'interface utilisateur web et renseigner les informations requises :
- Nom du serveur : le domaine public de votre application (par ex.
myapp.example.com) - SSL/TLS : votre contrôleur d'entrée s'occupe de cette partie, donc ne l'activez pas sur BunkerWeb car le trafic est interne au sein du cluster
- Hôte proxy inverse : l'URL complète de votre application au sein du cluster (par exemple)
http://myapp-service.myapp.svc.cluster.local:5000
Une fois le nouveau service ajouté, vous pouvez maintenant déclarer une ressource Ingress pour ce service et l'acheminer vers le service BunkerWeb sur le port HTTP :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp
# Replace with your namespace of BW if needed
namespace: bunkerweb
spec:
# Only served by nginx controller and not BW
ingressClassName: nginx
# Uncomment and edit if you want to use your own certificate
# tls:
# - hosts:
# - myapp.example.com
# secretName: tls-secret
rules:
# Replace with your domain
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
# Created by Helm chart
name: bunkerweb-external
port:
number: 80
Vous pouvez visiter http(s)://myapp.example.com, qui est maintenant protégé par BunkerWeb ️
Swarm
Obsolète
L'intégration de Swarm est obsolète et sera supprimée dans une version ultérieure. Veuillez envisager d'utiliser l' intégration Kubernetes à la place.
Support PRO
Si vous avez besoin d'aide sur l'intégration Swarm, veuillez nous contacter au contact@bunkerity.com ou via le formulaire de contact.
Docker autoconf
L'intégration de Swarm est similaire à celle de Docker autoconf (mais avec des services au lieu de conteneurs). Veuillez d'abord lire la section sur l 'intégration de Docker autoconf si nécessaire.
Pour permettre la configuration automatique des instances BunkerWeb, le ** service autoconf nécessite l'accès à l'API Docker. Ce service est à l'écoute des événements Docker Swarm, tels que la création ou la suppression de services, et configure de manière transparente les instances BunkerWeb** en temps réel sans aucun temps d'arrêt. Il surveille également d'autres objets Swarm, tels que les configurations, pour les configurations personnalisées.
Semblable à l'intégration Docker autoconf, la configuration des services Web est définie à l'aide d'étiquettes qui commencent par le ** préfixe **bunkerweb.
Pour une configuration optimale, il est recommandé de planifier le service BunkerWeb en tant que service global sur tous les nœuds, tandis que les services autoconf, scheduler et proxy Docker API doivent être planifiés en tant que services répliqués uniques. Veuillez noter que le service proxy de l'API Docker doit être planifié sur un nœud de gestionnaire, sauf si vous le configurez pour utiliser une API distante (ce qui n'est pas couvert dans la documentation).
Étant donné que plusieurs instances de BunkerWeb sont en cours d'exécution, un magasin de données partagé implémenté en tant que service Redis ou Valkey doit être créé. Ces instances utiliseront le service Redis/Valkey pour mettre en cache et partager des données. Vous trouverez plus de détails sur les paramètres Redis/Valkey ici.
En ce qui concerne le volume de la base de données, la documentation ne spécifie pas d'approche spécifique. Le choix d'un dossier partagé ou d'un pilote spécifique pour le volume de base de données dépend de votre cas d'utilisation unique et est laissé à la disposition du lecteur.
Backend de base de données
Veuillez noter que nos instructions supposent que vous utilisez MariaDB comme backend de base de données par défaut, tel que configuré par le DATABASE_URI paramètre. Cependant, nous comprenons que vous préférerez peut-être utiliser d'autres backends pour votre intégration Docker. Si c'est le cas, soyez assuré que d'autres backends de base de données sont toujours possibles. Pour plus d'informations, consultez les fichiers docker-compose dans le dossier misc/integrations du dépôt.
La configuration des backends de base de données en cluster est hors du périmètre de cette documentation.
Voici le passe-partout de la pile que vous pouvez déployer à l'aide de docker stack deploy:
x-bw-env: &bw-env
# We use an anchor to avoid repeating the same settings for both services
SWARM_MODE: "yes"
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24"
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
ports:
- published: 80
target: 8080
mode: host
protocol: tcp
- published: 443
target: 8443
mode: host
protocol: tcp
- published: 443
target: 8443
mode: host
protocol: udp # QUIC
environment:
<<: *bw-env
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
deploy:
mode: global
placement:
constraints:
- "node.role == worker"
labels:
- "bunkerweb.INSTANCE=yes" # Mandatory label for the autoconf service to identify the BunkerWeb instance
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:testing
environment:
<<: *bw-env
BUNKERWEB_INSTANCES: "" # We don't need to specify the BunkerWeb instance here as they are automatically detected by the autoconf service
SERVER_NAME: "" # The server name will be filled with services labels
MULTISITE: "yes" # Mandatory setting for autoconf
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Remember to set a stronger password for the database
USE_REDIS: "yes"
REDIS_HOST: "bw-redis"
volumes:
- bw-storage:/data # This is used to persist the cache and other data like backups
restart: "unless-stopped"
networks:
- bw-universe
- bw-db
deploy:
placement:
constraints:
- "node.role == worker"
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:testing
environment:
SWARM_MODE: "yes"
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Remember to set a stronger password for the database
DOCKER_HOST: "tcp://bw-docker:2375" # The Docker socket
restart: "unless-stopped"
networks:
- bw-universe
- bw-docker
- bw-db
deploy:
placement:
constraints:
- "node.role == worker"
bw-docker:
image: tecnativa/docker-socket-proxy:nightly
environment:
CONFIGS: "1"
CONTAINERS: "1"
SERVICES: "1"
SWARM: "1"
TASKS: "1"
LOG_LEVEL: "warning"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: "unless-stopped"
networks:
- bw-docker
deploy:
placement:
constraints:
- "node.role == manager"
bw-db:
image: mariadb:11
# We set the max allowed packet size to avoid issues with large queries
command: --max-allowed-packet=67108864
environment:
MYSQL_RANDOM_ROOT_PASSWORD: "yes"
MYSQL_DATABASE: "db"
MYSQL_USER: "bunkerweb"
MYSQL_PASSWORD: "changeme" # Remember to set a stronger password for the database
volumes:
- bw-data:/var/lib/mysql
restart: "unless-stopped"
networks:
- bw-db
deploy:
placement:
constraints:
- "node.role == worker"
bw-redis:
image: redis:7-alpine
restart: "unless-stopped"
networks:
- bw-universe
deploy:
placement:
constraints:
- "node.role == worker"
volumes:
bw-data:
bw-storage:
networks:
bw-universe:
name: bw-universe
driver: overlay
attachable: true
ipam:
config:
- subnet: 10.20.30.0/24
bw-services:
name: bw-services
driver: overlay
attachable: true
bw-docker:
name: bw-docker
driver: overlay
attachable: true
bw-db:
name: bw-db
driver: overlay
attachable: true
Réglage obligatoire de l'swarm
Veuillez noter que la SWARM_MODE: "yes" variable d'environnement est obligatoire lors de l'utilisation de l'intégration Swarm.
Ignorer les services étiquetés
Besoin d'exclure un service Swarm d'autoconf ? Définissez SWARM_IGNORE_LABELS sur le contrôleur. Fournissez une liste de clés d'étiquettes séparées par des espaces ou des virgules (par exemple bunkerweb.SERVER_NAME) ou des suffixes (SERVER_NAME) et tout service portant ces étiquettes sera ignoré lors de la découverte.
Services Swarm
Une fois que la pile BunkerWeb Swarm est configurée et en cours d'exécution (voir les journaux autoconf et scheduler pour plus d'informations), vous pourrez déployer des applications Web dans le cluster et utiliser des étiquettes pour configurer dynamiquement BunkerWeb :
services:
myapp:
image: mywebapp:4.2
networks:
- bw-services
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.MY_SETTING_1=value1"
- "bunkerweb.MY_SETTING_2=value2"
networks:
bw-services:
external: true
name: bw-services
Espaces de noms
À partir de la version 1.6.0, les piles Autoconf de BunkerWeb supportent désormais les espaces de noms. Cette fonctionnalité vous permet de gérer plusieurs « clusters » d'instances et de services BunkerWeb sur le même hôte Docker. Pour tirer parti des espaces de noms, il vous suffit de définir l' NAMESPACE étiquette sur vos services. Voici un exemple :
services:
myapp:
image: mywebapp:4.2
networks:
- bw-services
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.NAMESPACE=my-namespace" # Set the namespace for the service
- "bunkerweb.MY_SETTING_1=value1"
- "bunkerweb.MY_SETTING_2=value2"
networks:
bw-services:
external: true
name: bw-services
Comportement de l'espace de nommage
Par défaut, toutes les piles Autoconf écoutent tous les espaces de noms. Si vous souhaitez restreindre une pile à des espaces de noms spécifiques, vous pouvez définir la variable d'environnement NAMESPACES dans le service bw-autoconf :
...
services:
bunkerweb:
image: bunkerity/bunkerweb:testing
...
deploy:
mode: global
placement:
constraints:
- "node.role == worker"
labels:
- "bunkerweb.INSTANCE=yes"
- "bunkerweb.NAMESPACE=my-namespace" # Set the namespace for the BunkerWeb instance
...
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:testing
environment:
NAMESPACES: "my-namespace my-other-namespace" # Only listen to these namespaces
...
deploy:
placement:
constraints:
- "node.role == worker"
...
Gardez à l'esprit que la variable d'environnement NAMESPACES est une liste d'espaces de noms séparés par des espaces.
Spécifications de l'espace de nommage
Il ne peut y avoir qu'une seule base de données et un seul Scheduler par espace de noms. Si vous tentez de créer plusieurs bases de données ou plusieurs Schedulers dans le même espace de noms, les configurations entreront en conflit.
Le Scheduler n'a pas besoin de l'étiquette NAMESPACE pour fonctionner correctement. Il a seulement besoin que le paramètre DATABASE_URI soit correctement configuré afin qu'il puisse accéder à la même base de données que le service autoconf.
Microsoft Azure
Taille de machine virtuelle recommandée
Soyez vigilant lorsque vous choisissez la référence SKU de la machine virtuelle. Vous devez sélectionner une référence SKU compatible avec la machine virtuelle Gen2 et nous vous recommandons de commencer par la série B2s ou Ds2 pour une utilisation optimale.
Vous pouvez facilement déployer BunkerWeb sur votre abonnement Azure de plusieurs manières :
- Azure CLI dans Cloud Shell
- Modèle Azure ARM
- Portail Azure via la Place de marché
Créez un groupe de ressources. Remplacez la valeur RG_NAME
az group create --name "RG_NAME" --location "LOCATION"
Créez une machine virtuelle avec la taille (SKU) Standard_B2s dans la même région que le groupe de ressources. Remplacez les valeurs RG_NAME, VM_NAME, VNET_NAME, SUBNET_NAME
az vm create --resource-group "RG_NAME" --name "VM_NAME" --image bunkerity:bunkerweb:bunkerweb:latest --accept-term --generate-ssh-keys --vnet-name "VNET_NAME" --size Standard_B2s --subnet "SUBNET_NAME"
Commande complète. Remplacez les valeurs RG_NAME, VM_NAME, LOCATION, HOSTNAME, USERNAME, PUBLIC_IP, VNET_NAME, SUBNET_NAME, NSG_NAME
az vm create --resource-group "RG_NAME" --name "VM_NAME" --location "LOCATION" --image bunkerity:bunkerweb:bunkerweb:latest --accept-term --generate-ssh-keys --computer-name "HOSTNAME" --admin-username "USERNAME" --public-ip-address "PUBLIC_IP" --public-ip-address-allocation Static --size Standard_B2s --public-ip-sku Standard --os-disk-delete-option Delete --nic-delete-option Delete --vnet-name "VNET_NAME" --subnet "SUBNET_NAME" --nsg "NSG_NAME"
Exigences en matière d'autorisations
Pour déployer un modèle ARM, vous devez disposer d'un accès en écriture sur les ressources que vous déployez ainsi que de l'accès à toutes les opérations sur le type de ressource Microsoft.Resources/deployments. Pour déployer une machine virtuelle, vous avez besoin des autorisations Microsoft.Compute/virtualMachines/write et Microsoft.Resources/deployments/*. L'opération what-if requiert les mêmes autorisations.
Déployer le modèle ARM :
Connectez-vous au portail Azure.
Obtenez BunkerWeb depuis le menu Créer une ressource.
Vous pouvez également passer par le Marketplace.
Vous pouvez accéder à l'assistant d'installation en parcourant l' https://your-ip-address/setup URI de votre machine virtuelle.