Devops

DigitalOcean recouvrez l’accès à votre console de droplet

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é

ufw allow ssh

Installer Nginx sur Ubuntu sur DigitalOcean

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.

f

Mémento sur les github actions

Concept essentiels de github actions

  • Workflow : un process fait d’un ou plusieur jobs. Le workflow est un fichier YAML
  • job : un ensemble de steps exécuté sur un même runner, tournent en parallèle en général et spécifie l’OS
  • step : une tâche dans un job, peut être une action ou une commande shell., share filesystem
  • runner : le serveur qui exécute le workflow

Qu’est ce qu’un action?

Une action est un ensemble de code au sein d’un workflow. En savoir plus sur les actions (EN)

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. Actions JavaScript : Actions construites en utilisant Node.js qui peuvent exécuter du code JavaScript.
  2. 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.
  3. 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).

steps:

Liens externes:

https://www.digitalocean.com/community/tech-talks/deploying-to-digitalocean-with-github-actions

Installer docker sur DigitalOcean Droplet avec Docker

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 :

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-22-04

Cloner votre projet depuis Github

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.

Clonage du projet depuis Github

/home# git clone git@github.com:refschool/vidly.git

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.

git clone https://<PAT>@github.com/refschool/vidly.git

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.

scp -i C:\Users\admin\.ssh\id_rsa E:\mosh\vidly\docker-compose-prod.yml root@188.166.87.69:/home/

Update :

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.

const baseUrl = process.env.REACT_APP_API_URL || "http://localhost:3001/api";

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

#Dockerfile
...
COPY . .
ENV REACT_APP_API_URL=http://adresse-ip-du-droplet:3001/api
...

Problème de droits de fichier

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
Retour en haut