Et voici la seconde partie des débuts sur Docker

Suite à mon premier article, j’étais donc capable de faire tourner un environnement de développement pour créer des projets Symfony.

OK, c’était bien beau tout ça, mais pour le moment ça ne faisait que tourner en local sur mon MacBook et ce n’est pas comme ça qu’on héberge un site. 

Les serveurs mutualisés étant déjà un certain enfer à configurer pour un simple site, je n’osais même pas imaginer faire tourner Docker dessus. J’ai donc opté pour un serveur dédié chez Scaleway et une fois la commande passée j’y ai installé Docker sur Ubuntu 20.04.

J’organise un peu les dossiers sur le serveur, j’installe les outils dont j’aurais besoin (Git entre autres) et je peux cloner mon dépôt de la partie 1 qui fait tourner Symfony sous Docker.

Je lance : « docker-compose up -d » et ça y est, mon site de dév se retrouve en prod !

Et oui ! Souvenez-vous, la configuration qui fonctionne chez vous en local sera fonctionnelle aussi en prod grâce à Docker !

Bon c’est bien beau tout ça, mais maintenant que mon site est en ligne il reste deux petites choses à régler :

• Je n’ai pas de nom de domaine et pour accéder à mon serveur il faut son IP
• Il n’y a aucune sauvegarde qui n’est faite ni du site ni de la base de données

Nom de domaine

Alors c’est parti, réglons tout ça. Tout d’abord il faut se rendre sur le service qui gère notre nom de domaine afin d’en modifier le DNS (Domain Name Service). Ici on trouvera le nom de domaine avec une catégorie A et une adresse IP. Cela représente l’adresse IP du serveur sur lequel pointe notre nom de domaine.

Vous l’aurez compris, on va aller remplacer cette IP par celle de notre nouveau serveur dédié pour que le domaine pointe vers celui-ci.

Un certain délai peut être nécessaire pour que le changement soit effectué, cela dépend des prestataires, mais une fois fait on peut rapidement vérifier que, ça y est, notre site est bien associé au nom de domaine.

Sauvegarde

Super notre site fonctionne et est accessible au bon endroit. Manque plus qu’à faire des sauvegardes pour être sûr de ne pas le perdre et on sera bon !

L’idée ici est de faire un dump de notre base de données MySQL chaque nuit, pour l’avoir dans notre ensemble de fichiers (la config Docker + les fichiers du site) et ensuite faire une sauvegarde globale de tout ça.

On crée donc un cron sur notre container MySQL qui va quotidiennement faire un dump de la base de données :

On créer ensuite un volume pour que ce fichier .sql soit parmi les fichiers du site et de la configuration Docker et voilà.

Maintenant il nous reste à sauvegarder l’ensemble et pour cela on va utiliser la commande duplicity qui permet de faire des sauvegardes incrémentielles de fichiers.

Cela va nous créer une archive Tar chiffrée avec GnuPG. Archive que l’on va ensuite uploader sur un serveur FTP prévu pour cela. Scaleway offre d’ailleurs 100Go de stockage pour les sauvegardes dans son offre de base.

Cette commande duplicity on va la placer sur notre serveur dédié et elle va s’occuper de créer les fichiers et les uploader directement toutes les nuits elle aussi.

On crée donc un petit script sur le serveur et un nouveau cron qui l’exécutera toutes les nuits.

duplicity /var/www/blog ftp://truc.com

C’est tout bon ! Vous avez un environnement qui tourne sur un serveur dédié où vous pouvez déployer des containers Docker et assurer la sauvegarde de tous vos projets.

Aller plus loin

L’étape supplémentaire dont vous pourriez avoir besoin est celle de gérer plusieurs sites sur un même serveur. Dans ce cas il faudra dispatcher les différents noms de domaine qui pointeront pourtant tous sur la même IP de serveur.

Pour cela on utilise un proxy qui va servir de porte d’entrée à votre serveur et s’occuper automatiquement d’envoyer les visiteurs vers le bon site qui correspond au nom de domaine.

Dans mon cas j’ai utilisé "nginx-proxy" couplé à "nginx-redirect" pour gérer les  « virtual host ».

Verdict

Maintenant que je commence à maîtriser Docker et à en voir toutes les subtilités, je comprends l’engouement qu’il peut y avoir autour de cette techno.

C’est un peu compliqué à cerner au départ, surtout les interactions entre chaque service et surtout quand on est un pur développeur comme moi à la base n’ayant jamais trop touché au côté serveur.

Mais on s’y fait vite après quelques cafés et ça en vaut vraiment la peine, car le temps gagné à la fin sur chaque projet est assez dingue, sans compter la facilité de configurer à peu près tout et n’importe quoi.