Si vous vouslez accéder à votre console et que l’écran tourne en boucle, c’est que sans doute vous avez touché au FireWall. Vous avez touché au FireWall à l’occasion de l’installation de Nginx.
Pour recouvrer l’accès à votre console, il faut utiliser la Recovery Console, pour y accéder, aller dans Access dans la page principale du droplet.
Après le démarrage de la Recovery Console, il vous sera demandé de rentrer le mot de passe du user root, le problème est que vous n’avez pas de mot de passe root si vous avez choisi d’accéder pas clé SSH.
Il vous faudra donc resetter votre mot de passe root, en choisissant l’option juste après la Recovery Console, Reset Root Password.
Vous voila prêt à changer la configuration du Firewall une fois loggé
Une fois que vous avez créé votre droplet, il est conseillé de créer un utilisateur sudoable, sinon faites les opérations suivantes avec l’utilisateur root.
Nous allons mettre à jour vos paquets et installer Nginx
sudo apt update
sudo apt install nginx
Si vous êtes sous root pas la peine de mettre sudo. Sudo permet d’élever les privilèges d’un utilisateur non root.
Paramétrage du firewall ufw (uncomplicated Fire Wall)
sudo ufw app list // liste les applications connue par ufw
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
Si on n’a pas encore configuré un SSL pour le serveur, on va utiliser le profil Nginx HTTP.
>ufw allow 'Nginx HTTP'
Afficher le status du firewall
>ufw status
Status: inactive // si vous avez ça c'est que ufw n'est pas activé
faite la commande suivante:
>ufw enable
>ufw status
Status: active
To Action From
-- ------ ----
Nginx HTTP ALLOW Anywhere
Nginx HTTP (v6) ALLOW Anywhere (v6)
Vérifier que le serveur web tourne
A la fin de l’installation, Unbuntu démarre le serveur Nginx. Nous allons vérifier avec la commande
systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-07-27 21:06:47 UTC; 16min ago
Docs: man:nginx(8)
Process: 2697 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUC>
Process: 2699 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 2701 (nginx)
Tasks: 2 (limit: 509)
Memory: 2.2M (peak: 2.3M)
CPU: 16ms
CGroup: /system.slice/nginx.service
├─2701 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
└─2702 "nginx: worker process"
Jul 27 21:06:47 ubuntu-s-1vcpu-512mb-10gb-ams3-01 systemd[1]: Starting nginx.service - A high performance web se>
Jul 27 21:06:47 ubuntu-s-1vcpu-512mb-10gb-ams3-01 systemd[1]: Started nginx.service - A high performance web ser>
lines 1-16/16 (END)
troisième ligne indique active running.
Important ! autorisez le SSH, sinon vous risquez de ne plus avoir accès à la console, si c’est le cas voici une solution
ufw allow ssh
Nous allons visiter dans le navigateur une page pour vérifier que Nginx fonctionne. Faite la commande pour connaitre l’IP qui doit vous afficher une page:
ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'
165.232.90.185
10.18.0.5
fe80::28e7:4eff:fee5:b7fe
//commande alternative
curl -4 icanhazip.com
Je passe par l’IP V4, et j’obtiens bien une page web, la page d’accueil de Nginx.
Dans le contexte de GitHub Actions, une action est une application personnalisée pour la plateforme GitHub Actions qui automatise une tâche spécifique ou un ensemble de tâches au sein d’un workflow. Les actions sont les éléments de base des workflows et peuvent être réutilisées dans plusieurs workflows et dépôts.
Points Clés sur les Actions
Unités de Code Réutilisables : Les actions sont conçues pour être réutilisables. Vous pouvez les partager entre différents dépôts et avec la communauté GitHub.
Préconstruites ou Personnalisées : Vous pouvez utiliser des actions préconstruites disponibles sur le GitHub Marketplace ou créer vos propres actions personnalisées adaptées à vos besoins spécifiques.
Encapsulent des Tâches : Les actions encapsulent des tâches telles que le checkout du code, la configuration des environnements, l’exécution de tests et le déploiement des applications.
Configurables : Les actions acceptent souvent des entrées et produisent des sorties, ce qui permet de les personnaliser et de les composer ensemble pour créer des workflows complexes.
Types d’Actions
Actions JavaScript : Actions construites en utilisant Node.js qui peuvent exécuter du code JavaScript.
Actions de Conteneur Docker : Actions qui s’exécutent dans un conteneur Docker, ce qui vous permet de les empaqueter avec toutes leurs dépendances.
Actions Composites : Actions qui combinent plusieurs étapes en une seule action, définie en utilisant une série de commandes shell et d’autres actions.
Qu’est ce que actions/checkout@v3?
C’est une action prédéfinie de Github, qui clone un repository dans l’environnement du workflow.
Glossaire Github action:
logs
uses : est utlisé pour sélectionner une action déjà définie dans un docker, dans un repository.
name: le nom du workflow
on : écouteur d’événement
artifact
runs-on: spécifie le type de machine (ou « runner ») sur laquelle un job doit s’exécuter. Un runner est un serveur qui exécute les workflows définis dans vos fichiers YAML. Un runner peut être auto-hébergé.
Types de Runners Disponibles
GitHub Actions offre plusieurs types de runners hébergés (préconfigurés par GitHub) que vous pouvez utiliser :
ubuntu-latest : Une machine virtuelle exécutant la dernière version stable d’Ubuntu.
ubuntu-20.04 : Une machine virtuelle exécutant Ubuntu 20.04.
ubuntu-22.04 : Une machine virtuelle exécutant Ubuntu 22.04.
windows-latest : Une machine virtuelle exécutant la dernière version stable de Windows.
windows-2019 : Une machine virtuelle exécutant Windows Server 2019.
macos-latest : Une machine virtuelle exécutant la dernière version stable de macOS.
macos-11 : Une machine virtuelle exécutant macOS 11 (Big Sur).
Dans cet article on va voir comment déployer des container docker d’une application multicontainer dans un VPS à l’aide de Docker-compose. Sur DigitalOcean, la manipulation est plus facile que sur Azure ou AWS (le plus complexe)
Création du Droplet
Un droplet sur DigitalOcean (un prestataire Cloud abordable et pas trop compliqué à utiliser),
1/Créer un compte sur DigitalOcean
2/créer un droplet l’équivalent d’un VPS, choisir Ubuntu comme OS avec Docker préinstallé en vous aidant du Marketplace. Vous créerez par la même occasion un projet qui apparaitra dans la sidebar.
Ensuite vous choisissez le Datacenter le plus proche de chez vous, en France l’on choisira Amsterdam par exemple.
Dans la section « Choose an image« , cliquez sur l’onglet Marketplace, puis sur l’image Docker on Ubuntu, ici l’image représente une machine virtuelle bien sûr et pas une image Docker.
Ensuite choisissez les options les moins chères, dans Droplet Type, choisissez « Basic« , dans CPU options, choisissez « Regular« , et la formule au mois la moins chère.
Dans « Choose Authentication Method« , choisissez Password pour faire simple, et SSH Key pour faire pratique (pas de mémorisation de mot de passe et login nécessaire). Allez sur ce post pour générer et mettre votre clé sur le service. Enfin cliquez sur « Create Droplet ». Au bout d’un certain temps votre droplet sera créée avec Docker installé, cependant Docker-Compose ne sera pas encore installé. Il vous faudra faire via la console.
Si vous voulez installer à la main Docker, les instruction sont sur cette page :
Pour vous connecter en console dans votre Droplet dans la sidebar « Projects« , cliquez sur votre projet
Installer docker-compose
Une fois dedans cliquez sur « Console« , cela ouvrira un shell. Installez docker-compose
///sudo apt-get install docker-compose-plugin
ou tapez docker-compose, une erreur avec un message sur comment installer docker-compose s'affichera.
apt install docker-compose
Vous êtes en connecté en root, allez à /home et cloner le projet. Le projet consiste en un front end en ReactJS, un backend en Node/Express et de MongoDB. Ce dernier est directement tiré du hub de Docker. Alors que le front et le back vont être transformé en image via leurs Dockerfiles respectifs.
On clone soit en SSH car Github ne supporte plus l’authentification par login et mot de passe. ou alors il faut utiliser un PAT personal access token. L’ennui avec la clé SSH est qu’il faut en créer une sur le droplet et la mettre sur Github, cela fait beaucoup de manipulations. Le mieux est de créer le PAT sur Github. Il s’utilise comme un mot de passe.
Copie du fichier docker-compose-prod.yml depuis votre poste vers votre droplet
A ce stade il n’y a pas grand d’installé ni de configuré pour votre droplet (pas de FTP etc). Le moyen le plus simple d’envoyer un fichier vers le droplet est d’utiliser l’utilitaire rsync pour envoyer ce fichier. Mais le problème est que ce n’est pas simple d’avoir rsync sur Windows (pas un problème sur Linux). On va utiliser scp depuis le terminal DOS.
Si le fichier docker-compose-prod.yml est dans le git, pas besoin de faire cette manipulation finalement.
Démarrage du docker-compose avec le fichier de prod
Dans la racine du projet où il y a le fichier docker-compose-prod.yml
docker-compose -f docker-compose-prod.yml up -d
Cette unique ligne va créer ou importer les images, démarrer les containers et in fine votre application.
Accès à l’application sur DigitalOcean
Si tout s’est bien passé, vous allez pouvoir accéder à votre application sur le droplet à l’adresse IP que vous pouvez retrouver dans votre interface chez DigitalOcean, sur le port 3000.
Les problèmes rencontrés et leurs solutions
An accédant via l’adresse IP l’application, on rencontre une première erreur :
Problème de CORS
La preière fois que vous accédez à votre application, vous allez rencontrer ce message « Could not fetch movie »
Ceci est vraisemblablement dû à un problème de CORS (cross origin), si on ouvre les devtools, onglet Réseau, en inspectant la requête, vous aurez les indices. La requête est faite à http://localhost:3001/api alors que notre serveur possède une adresse IP (voir image)
En effet en phase de développement on a http://localhost:3001/api (voir le fichier src/services/api.js) , si la variable d’environnement REACT_APP_API_URL est settée, elle surchargera localhost.
A la racine du projet, il y a un fichier docker-compose-prod.yml. Dans le Dockerfile du front il vous faudra remplacer dans le fichier Dockerfile après COPY
Vérifiez aussi que dans le dossier backend, les fichiers docker-entrypoint.sh et wait-for soient exécutables en faisant la commande chmod +x <fichier>.
Une fois que la commande docker-compose est faite, vous avez la main dans le shell, Inspectez les containers
docker ps
//Voir les logs d'un container
docker logs <id-container>
//Par exemple si le container du backend ne fonctionne pas correctement, lisez les logs.
//Pour arrêter
docker-compose down
//Pour relancer avec un build d'images
docker-compose -f docker-compose-prod.yml up -d --build