docs: add server and CI/CD guides
This commit is contained in:
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: Bien démarrer un serveur
|
||||
description: Sécuriser les accès et poser une base saine avant le premier déploiement.
|
||||
---
|
||||
|
||||
Un serveur de production doit être préparé **avant** d'héberger l'application. L'objectif du premier jour est simple : réduire la surface d'attaque, conserver un accès de secours et automatiser les mises à jour de sécurité.
|
||||
|
||||
<Callout title="Ne te verrouille pas dehors" type="warn">
|
||||
Garde ta première session SSH ouverte pendant les changements. Valide la configuration, puis ouvre une deuxième session avec la clé avant de désactiver les mots de passe.
|
||||
</Callout>
|
||||
|
||||
## 1. Mettre le système à jour
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt full-upgrade -y
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
Après le redémarrage, reconnecte-toi et vérifie que les services essentiels sont revenus.
|
||||
|
||||
## 2. Créer un compte d'administration
|
||||
|
||||
Le compte `root` ne doit pas être utilisé pour les connexions quotidiennes :
|
||||
|
||||
```bash
|
||||
sudo adduser deploy
|
||||
sudo usermod -aG sudo deploy
|
||||
```
|
||||
|
||||
Ce compte servira à administrer et déployer l'application. Pour une équipe, préfère un compte nominatif par personne et un compte technique distinct pour l'automatisation.
|
||||
|
||||
## 3. Utiliser une clé SSH
|
||||
|
||||
Génère la clé sur ta machine, jamais sur le serveur :
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/serveur_production
|
||||
ssh-copy-id -i ~/.ssh/serveur_production.pub deploy@ADRESSE_IP
|
||||
```
|
||||
|
||||
Teste ensuite la connexion dans un nouveau terminal :
|
||||
|
||||
```bash
|
||||
ssh -i ~/.ssh/serveur_production deploy@ADRESSE_IP
|
||||
```
|
||||
|
||||
Quand cet accès fonctionne, ajoute un fichier `/etc/ssh/sshd_config.d/99-hardening.conf` :
|
||||
|
||||
```text
|
||||
PermitRootLogin no
|
||||
PasswordAuthentication no
|
||||
PubkeyAuthentication yes
|
||||
```
|
||||
|
||||
Valide **avant** de recharger SSH :
|
||||
|
||||
```bash
|
||||
sudo sshd -t
|
||||
sudo systemctl reload ssh
|
||||
```
|
||||
|
||||
## 4. Fermer les ports inutiles
|
||||
|
||||
Pour un serveur web classique, seuls SSH, HTTP et HTTPS sont nécessaires :
|
||||
|
||||
```bash
|
||||
sudo ufw allow OpenSSH
|
||||
sudo ufw allow 80/tcp
|
||||
sudo ufw allow 443/tcp
|
||||
sudo ufw enable
|
||||
sudo ufw status verbose
|
||||
```
|
||||
|
||||
Applique les mêmes restrictions dans le pare-feu du fournisseur cloud.
|
||||
|
||||
<Callout title="Docker et UFW" type="warn">
|
||||
Un port publié par Docker peut contourner les règles UFW. Ne publie vers l'hôte que les ports du reverse proxy, vérifie aussi le pare-feu du fournisseur et utilise la chaîne Docker <code>DOCKER-USER</code> si tu dois filtrer le trafic des conteneurs.
|
||||
</Callout>
|
||||
|
||||
## 5. Automatiser les correctifs de sécurité
|
||||
|
||||
```bash
|
||||
sudo apt install unattended-upgrades
|
||||
sudo dpkg-reconfigure -plow unattended-upgrades
|
||||
```
|
||||
|
||||
`fail2ban` peut compléter cette base si le service SSH est exposé à Internet :
|
||||
|
||||
```bash
|
||||
sudo apt install fail2ban
|
||||
sudo systemctl enable --now fail2ban
|
||||
```
|
||||
|
||||
## Checklist du premier jour
|
||||
|
||||
- [ ] système entièrement mis à jour et redémarré ;
|
||||
- [ ] connexion avec un compte non-root ;
|
||||
- [ ] clé Ed25519 testée dans une seconde session ;
|
||||
- [ ] connexion root et mot de passe SSH désactivés ;
|
||||
- [ ] configuration validée avec `sshd -t` ;
|
||||
- [ ] seuls les ports 22, 80 et 443 sont ouverts ;
|
||||
- [ ] mises à jour de sécurité automatiques activées ;
|
||||
- [ ] accès de secours du fournisseur testé ou documenté.
|
||||
|
||||
## Documentation officielle
|
||||
|
||||
- [OpenSSH sur Ubuntu](https://documentation.ubuntu.com/server/how-to/security/openssh-server/)
|
||||
- [Pare-feu Ubuntu](https://documentation.ubuntu.com/server/how-to/security/firewalls/)
|
||||
- [Mises à jour automatiques](https://documentation.ubuntu.com/server/how-to/software/automatic-updates/)
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"title": "Serveur",
|
||||
"description": "Préparer un hôte de production fiable",
|
||||
"pages": ["bien-demarrer", "preparer-docker"]
|
||||
}
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: Préparer l'hôte Docker
|
||||
description: Installer Docker proprement et organiser le serveur pour les déploiements.
|
||||
---
|
||||
|
||||
Une fois le système sécurisé, prépare un hôte minimal. Le serveur doit exécuter des images déjà construites : il n'a pas besoin du code source, de Node.js ni des outils de compilation.
|
||||
|
||||
## Installer Docker depuis le dépôt officiel
|
||||
|
||||
Utilise le [dépôt APT officiel de Docker](https://docs.docker.com/engine/install/ubuntu/) plutôt qu'un script d'installation téléchargé à la volée. Installe Docker Engine, le plugin Buildx et Docker Compose, puis vérifie l'installation :
|
||||
|
||||
```bash
|
||||
sudo systemctl enable --now docker
|
||||
sudo docker run --rm hello-world
|
||||
sudo docker compose version
|
||||
```
|
||||
|
||||
## Choisir le bon niveau d'accès
|
||||
|
||||
Ajouter un utilisateur au groupe `docker` permet d'éviter `sudo`, mais ce groupe donne des privilèges équivalents à `root`. Trois options existent :
|
||||
|
||||
| Option | Usage |
|
||||
| --- | --- |
|
||||
| `sudo docker ...` | simple pour l'administration manuelle |
|
||||
| Docker rootless | bon isolement lorsque la stack le permet |
|
||||
| script de déploiement restreint | adapté à une CI qui doit lancer une seule opération |
|
||||
|
||||
Évite de donner un accès Docker complet à tous les comptes. La [documentation post-installation de Docker](https://docs.docker.com/engine/install/linux-postinstall/) détaille le risque du groupe `docker` et le mode rootless.
|
||||
|
||||
## Organiser les fichiers de production
|
||||
|
||||
```text
|
||||
/srv/mon-app/
|
||||
├── docker-compose.prod.yml
|
||||
├── .env.prod
|
||||
├── .env.release
|
||||
└── backups/
|
||||
```
|
||||
|
||||
- `docker-compose.prod.yml` décrit les services ;
|
||||
- `.env.prod` contient la configuration et les secrets du serveur ;
|
||||
- `.env.release` contient uniquement le tag d'image déployé ;
|
||||
- `backups/` reçoit les sauvegardes chiffrées avant leur copie hors du serveur.
|
||||
|
||||
Protège les fichiers sensibles :
|
||||
|
||||
```bash
|
||||
sudo install -d -o root -g deploy -m 0750 /srv/mon-app
|
||||
sudo install -o root -g deploy -m 0640 .env.prod /srv/mon-app/.env.prod
|
||||
```
|
||||
|
||||
Les secrets ne doivent apparaître ni dans l'image, ni dans Git, ni dans les journaux de la CI.
|
||||
|
||||
## Préparer le réseau et le TLS
|
||||
|
||||
1. fais pointer le DNS vers l'adresse publique du serveur ;
|
||||
2. expose uniquement le reverse proxy en `80` et `443` ;
|
||||
3. garde la base de données et les services internes sur le réseau Docker ;
|
||||
4. configure un certificat TLS avec renouvellement automatique ;
|
||||
5. vérifie l'URL de santé depuis l'extérieur.
|
||||
|
||||
## Prévoir l'exploitation
|
||||
|
||||
Avant le premier déploiement, décide :
|
||||
|
||||
- où sont stockés les volumes persistants ;
|
||||
- à quelle fréquence ils sont sauvegardés ;
|
||||
- comment restaurer une sauvegarde sur une machine vierge ;
|
||||
- combien de temps conserver les journaux Docker ;
|
||||
- qui reçoit les alertes de disponibilité et d'espace disque ;
|
||||
- comment accéder au serveur si SSH ne répond plus.
|
||||
|
||||
<Callout title="Une sauvegarde n'existe qu'après un test de restauration" type="info">
|
||||
Copie les sauvegardes hors du serveur et vérifie régulièrement qu'une restauration complète fonctionne. Un volume Docker persistant ne remplace pas une sauvegarde.
|
||||
</Callout>
|
||||
|
||||
## Prêt pour le déploiement ?
|
||||
|
||||
- [ ] Docker et Compose proviennent du dépôt officiel ;
|
||||
- [ ] l'accès Docker est limité et documenté ;
|
||||
- [ ] le répertoire `/srv/mon-app` est protégé ;
|
||||
- [ ] les secrets sont présents uniquement sur le serveur ou dans un coffre ;
|
||||
- [ ] DNS et TLS fonctionnent ;
|
||||
- [ ] les volumes, sauvegardes et journaux ont une politique claire ;
|
||||
- [ ] une URL de santé est disponible.
|
||||
|
||||
Reference in New Issue
Block a user