Search for a command to run...
Bienvenue dans cet article où je vais détailler comment j'ai mis en place et configuré une collection d'applications auto-hébergées (self-hosted apps) en utilisant Docker, ainsi que des scripts utiles pour Proxmox et d'autres configurations dynamiques. Mon objectif est de créer un environnement sécurisé, accessible et facilement gérable pour mes applications préférées.
Avant de commencer, il est essentiel d'avoir les outils suivants installés sur votre machine :
Le repository comprend tous les fichiers utilisés pour la configuration de l'environnement.
Proxmox Virtual Environnement (abrégé Proxmox VE ou PVE) est une plateforme de virtualisation libre (licence AGPLv3) basée sur l'hyperviseur Linux KVM, et offre aussi des conteneurs avec LXC. Elle propose un support payant.
Elle est fournie avec un packaging par Proxmox Server Solutions GmbH. Source Wikipedia.
Cloner le Répertoire :
La première étape consiste à cloner mon dépôt Git contenant toutes les configurations nécessaires :
git clone https://github.com/kraaakilo/self-hosted.git
cd self-hosted
Configurer et Lancer les Conteneurs :
Ensuite, il suffit de naviguer dans le dossier de l'application désirée, de remplir les variables d'environnement, puis de démarrer les conteneurs :
docker-compose up -d
J'utilise Docker et Docker Compose pour gérer et déployer mes applications auto-hébergées. Chaque application dispose de son propre répertoire contenant un fichier compose.yml
et un fichier de variables d'environnement. Cette structure me permet de configurer et de démarrer facilement n'importe quelle application en naviguant dans son répertoire et en exécutant docker-compose up -d
.
J'ai acheté un domaine, m3a.site
, et pour obtenir un certificat SSL valide, j'ai utilisé le challenge DNS de Let's Encrypt. Ce challenge permet de valider la propriété du domaine sans avoir besoin de modifier les fichiers sur le serveur. J'ai configuré nginx proxy manager pour utiliser l'API de Cloudflare afin de modifier dynamiquement les entrées DNS nécessaires à la validation de ce challenge.
Une fois que Let's Encrypt a validé mon domaine via la modification des DNS, j'ai intégré cette configuration dans mon DNS local géré par Pi-hole. En configurant Pi-hole pour résoudre localement le domaine m3a.site
, j'ai pu pointer ce domaine vers les machines spécifiques de mon réseau local.
Cette approche permet de bénéficier d'un certificat SSL Let's Encrypt valide pour le domaine *.m3a.site
, tout en contrôlant entièrement la résolution DNS au sein de mon réseau local. Cela garantit la sécurité avec SSL et permet une gestion souple et centralisée de mon domaine, tout en facilitant l'accès aux services internes.
Pour garantir la sécurité de mes services, j'implémente des mesures telles que les règles de pare-feu UFW pour restreindre l'accès. J'utilise également des certificats SSL pour chiffrer le trafic entre mes clients et les applications, assurant ainsi une communication sécurisée.
Toutes mes applications ne sont pas directement accessibles depuis internet. Je n'ouvre que le port UDP 1194 pour OpenVPN afin de pouvoir accéder à mon réseau interne de n'importe où dans le monde. Cependant, un défi auquel j'ai dû faire face est de mettre à jour dynamiquement mon nom de domaine externe pour qu'il pointe vers l'adresse IP publique assignée par mon FAI, nécessaire pour correctement se connecter via VPN. Après quelques recherches, j'ai trouvé un script DDNS (Dynamic DNS) très utile, surtout lorsqu'il est utilisé avec des services comme Cloudflare.
Pour m'assurer que mon adresse IP est toujours à jour, j'utilise une machine Proxmox qui exécute une tâche cron. Cette tâche vérifie régulièrement l'adresse IP actuelle et, si elle a changé, met à jour mon enregistrement DNS chez Cloudflare. De cette manière, je peux toujours accéder à mon réseau interne via OpenVPN, même si mon FAI change mon adresse IP.
J'utilise Proxmox pour gérer mes environnements virtualisés, où j'exécute des conteneurs. Actuellement, j'utilise des conteneurs dans Proxmox avec des bind mounts pour connecter des volumes aux conteneurs Docker. Cela me permet de partager des données entre mes conteneurs et d'assurer une gestion centralisée des volumes de données. Cependant, un problème de permissions est apparu lorsque j'ai voulu garantir l'accès cohérent aux disques partagés.
Pour résoudre ce problème de permissions, j'ai créé un serveur NFS (Network File System) sur Proxmox. Cela me permet d'accéder aux disques et aux données partagées depuis d'autres machines sur mon réseau. Par exemple, d'autres applications ou serveurs peuvent utiliser NFS pour accéder aux mêmes volumes de données et les partager entre plusieurs services.
Dans les conteneurs Docker qui nécessitent l'écriture sur ces volumes partagés, j'ai appliqué une règle de UID/GID pour les utilisateurs exécutant les applications. En attribuant l'UID et le GID à 1000
, je m'assure que les permissions sont correctement maintenues à la fois dans les conteneurs et sur les disques eux-mêmes. Cela garantit la rétention des permissions, permettant à chaque conteneur d'accéder aux données de manière cohérente sans affecter les permissions globales sur le système.
Certains de mes conteneurs ne sont pas gérés par Nginx Proxy Manager (NPM), et donc ne bénéficient pas de la mise à jour automatique des certificats SSL fournie par NPM. Pour résoudre cela, j'utilise Ansible, un outil d'automatisation, pour garantir que mes services comme Gitea et Portainer disposent toujours de certificats SSL wildcard valides.
Ansible récupère périodiquement le contenu des certificats SSL gérés par NPM, qui sont automatiquement mis à jour pour refléter les derniers certificats valides. Ensuite, Ansible remplace les anciens certificats dans les conteneurs qui en ont besoin, afin de maintenir une infrastructure sécurisée avec des certificats à jour.
Voici un aperçu du contenu du playbook Ansible permettant de récupérer et de mettre à jour les certificats.
- name: Get Let's Encrypt Certificate
hosts: ssl_producer
tasks:
- name: get certificate fullchain
ansible.builtin.fetch:
src: /var/apps/nginx-proxy-manager/letsencrypt/live/npm-1/fullchain.pem
dest: ./ssl/
flat: yes
- name: get certificate privkey
ansible.builtin.fetch:
src: /var/apps/nginx-proxy-manager/letsencrypt/live/npm-1/privkey.pem
dest: ./ssl/
flat: yes
- name: Copy SSL files to Gitea server
hosts: gitea
tasks:
- name: Copy fullchain.pem to Gitea
ansible.builtin.copy:
src: ./ssl/fullchain.pem
dest: /etc/nginx/ssl/gitea/fullchain.pem
- name: Copy privkey.pem to Gitea
ansible.builtin.copy:
src: ./ssl/privkey.pem
dest: /etc/nginx/ssl/gitea/privkey.pem
- name: Copy SSL files to portainer server
hosts: portainer
tasks:
- name: Copy fullchain.pem to portainer
ansible.builtin.copy:
src: ./ssl/fullchain.pem
dest: /home/portainer/certs/fullchain.pem
- name: Copy privkey.pem to portainer
ansible.builtin.copy:
src: ./ssl/privkey.pem
dest: /home/portainer/certs/privkey.pem
Ce processus permet d'assurer que, même pour les services non gérés directement par Nginx Proxy Manager, les certificats SSL wildcard pour le domaine *.m3a.site
sont toujours valides et à jour, assurant ainsi une communication sécurisée sans interruption.
Pour suivre l'état de mes conteneurs et m'assurer que tout fonctionne correctement, j'ai mis en place un petit système de monitoring avec Grafana, Prometheus, et node_exporter. Ces outils me permettent de surveiller les conteneurs critiques et d'afficher des graphiques en temps réel sur leur utilisation des ressources (CPU, RAM).
Bien que cette solution soit fonctionnelle pour l'instant, je prévois de mettre en place une solution de monitoring plus robuste et globale à l'avenir. Mon objectif est de pouvoir suivre tous mes services et obtenir des alertes en cas de problème, afin de réagir rapidement si un service tombe en panne ou si une ressource atteint un seuil critique.
Pour prévenir la perte de données, je sauvegarde régulièrement mes volumes de données. Le dépôt inclut des scripts pour faciliter les processus de sauvegarde et de restauration, rendant plus simple la maintenance et la récupération de mes configurations.
NB: Ces scripts sont spécifiques à Proxmox uniquement
Voilà, j'espère que cette explication détaillée de mon environnement self-hosted vous sera utile ! Happy deployment !
Stay in the loop with my latest projects and insights! Follow me on Twitter to catch all the updates as they happen. Don't miss out on the journey – let's connect and explore the world of tech together. Click to follow now!