IV. Blob Storage

Le terme blob storage vous le retrouverez dans pas mal de plateformes Cloud et pas que.

Un blob c'est genre un fichier quoi, un bout de données.

Le blob storage c'est une feature où on peut créer/récupérer des fichiers, sur le réseau.

Azure met ça à disposition. Autrement dit :

• on crée un Blob Storage dans Azure
• on donne à une VM les droits pour y accéder
• cette VM peut écrire/lire des fichiers dans le Blob Storage

Là où c'est stylé :

• ça marche peu importe l'OS qui va l'utiliser (ça passe par HTTP)
• tu peux partager un Blob Storage entre plusieurs machines (même à l'autre bout du monde)
• les fichiers que tu mets dans le Blob Storage ils font leur life, donc si ta VM décède, les data dans le Blob Storage ne bougent pas, tu recrées une VM et ça repart
• etccccccccccc.

⚠️⚠️⚠️ Dans cette partie, on bosse que avec azure2.tp2

1. Un premier ptit blobz

➜ Créer un Storage Account

• comme d'hab : WebUI, ou CLI az
• Azure fonctionne fonctionne comme ça : un Storage Account pour ensuite créer des Blobs

• le nom que vous choisissez doit être unique à travers tout Azure (pas juste votre compte)

  • vous aurez une erreur si le nom est déjà choisi ;)

➜ Créer un Blob Container

• c'est un machin dans lequel on peut écrire des Blobs, les récupérer plus tard si on veut
• il est associé à un Storage Account

➜ Activer la "Managed Identity" pour votre VM azure2.tp2

➜ Donner le rôle "Storage Blob Data Contributor" à azure2.tp2

🌞 Upload un fichier dans le Blob Container depuis azure2.tp2

• vous vous connectez en SSH à azure2.tp2
• téléchargez le CLI az
• puis :

# on se log automatiquement avec la Managed Identity
az login --identity

# on crée un fichier de test bidon
echo "meow" > /tmp/meow.txt

# upload du fichier dans le Blob Container
az storage blob upload \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <BLOB_CONTAINER_NAME> \
  --name meow.txt \
  --file /tmp/hello.txt \
  --auth-mode login

🌞 Download un fichier du Blob Container

• depuis VOTRE PC
• commande az qui récupère le fichier meow.txt

Note

Vous pouvez aussi passer par la WebUI pour consulter le contenu du Blob Container.

2. Haïssez-moi

A. Intro

Je veux un script bash, quelle surprise.

Tu le vois pas venir ? azure2 ? Database ? Blob Storage ? I SAY BACKUP !

On va mettre en place une sauvegarde la base de données du site web (parce que c'est tout de même hyper important de conserver ces posts).

L'idée c'est :

• on a un script

  • capable d'effectuer une backup MySQL
  • upload la backup dans le Blob Container
  • en un mot : c'est l'frérot

• on le lance à intervalles réguliers

  • on met le script dans .service
  • on crée un .timer qui vient déclencher le script à intervalles réguliers

• pour que ça marche

  • le script doit se connecter à la base de données et récupérer le contenu
  • une commande est faite pour ça : mysqldump
  • il faudra créer un utilisateur dans la base SQL, que notre script utilisera pour se connecter

Je dis "on" mais évidemment c'est vous, et c'est en bash.

B. Utilisateur MySQL

🌞 Créer un ptit user SQL pour notre script

• connectez-vous à la base de données (commande mysql)
• créez un utilisateur backup (CREATE USER)

• donnez lui tous les droits sur la base meow_database (un GRANT puis FLUSH PRIVILEGES)

  • si t'es big girl/big boi tu vas lire de la doc pour voir comment on lui donne que les droits de lecture

Note

Tu peux juste copy/paste les commandes SQL du TP1, et tu remplaces le user par backup.

🌞 Tester que vous pouvez vous connecter avec cet utilisateur

• depuis la VM toujours : mysql -u backup -h localhost -p

-u t'indiques un user, -h l'adresse IP ou le nom de la machine où tu veux te co et -p pour saisir un password après.

C. Script db_backup.sh

🌞 Ecrire le script db_backup.sh

• il utilise une commande mysqldump pour récupérer le contenu de la base de données
• une commande tar pour archiver et compresser en .tar.gz
• une commande az pour uploader la backup sur notre ptit Blob Container
• un clean : le fichier .tar.gz doit être supprimé de la machine

🌞 Environnement du script db_backup.sh

• il est stocké dans /usr/local/bin/
• créez un utilisateur backup (commande useradd)
• il appartient à l'utilisateur backup (TU COCO LA COMMANDE NON (ok c'est chown))
• il n'est lisible et exécutable que par cet utilisateur (chmod)

🌞 Récupérer le blob

• récupérer le blob sur TON PC avec une commande az

📁 Dans le dépôt git : votre db_backup.sh

D. Service

🌞 Ecrire un fichier /etc/systemd/system/db_backup.service

• il doit lancer le script /usr/local/bin/db_backup.sh
• en tant que l'utilisateur backup

• il faudra indiquer Type=oneshot dans la section [Service]

  • par défaut, un service, c'est un truc qui tourne en permanence
  • donc un script de backup qui s'exécute puis se termine, ça affichera le service en Failed une fois terminé
  • on indique explicitement avec Type=oneshot que c'est un programme qui va se terminer et c'est normal

Note

Tu peux juste prendre mon webapp.service du TP1, sur la machine azure1.tp2 et l'adapter un peu.

📁 Dans le dépôt git : votre db_backup.service

---

🌞 Tester

• sudo systemctl daemon-reload après une modif de service, tu coco
• sudo systemctl start backup
• sudo systemctl status backup

Va check que t'as bien un nouveau fichier dans ton Blob Container.

E. Timer

🌞 Ecrire un fichier /etc/systemd/system/db_backup.timer

• paf je vous le file :

[Unit]
Description=Sauvegarde de la DB toutes les 1 min

[Timer]
# Premier lancement 1 minutes après le boot
OnBootSec=1min

# Et ensuite, ça retrigger 1 minutes après que ça soit stopped
OnUnitActiveSec=1min
Unit=db_backup.service

[Install]
WantedBy=timers.target

J'ai mis 1 min pour des tests faciles, on fait ça moins souvent évidemment.

🌞 Activer le Timer

• avec un sudo systemctl start db_backup.timer
• activation au boot sudo systemctl enable db_backup.timer

🌞 Attendre et observer

• sudo systemctl list-timers pour voir la prochaine exécution
• prouver que ça trigger bien votre service et donc votre script et donc un upload sur Blob Storage