Exercice 03 : Lancer des services dans les jobs

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Déclarer un service postgres:16-alpine avec un alias dans un job
✅ Configurer les variables POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD
✅ Vous connecter au service via son alias depuis le script du job
✅ Appliquer le même pattern à d'autres services (Redis, MySQL)

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Module GitLab CI Intermédiaire - Exercice 02 complété
Notions SQL de base (psql)

📖 Contexte

Les services: dans GitLab CI sont des conteneurs Docker qui démarrent en même temps que le job et s'arrêtent à sa fin. Ils sont accessibles via un alias réseau (par défaut le nom de l'image). C'est la façon standard de tester une application avec une vraie base de données dans CI.

📋 Énoncé

Créez un pipeline qui lance une base de données PostgreSQL comme service, y crée une table, insère des données et vérifie leur présence. Ajoutez ensuite un service Redis pour tester la connectivité.

🧭 Déroulement de l'exercice

Tâche 1 : Déclarer le service PostgreSQL

Dans un job test-db, déclarez le service postgres:16-alpine avec l'alias db. Configurez les variables POSTGRES_DB, POSTGRES_USER et POSTGRES_PASSWORD.

Indice :
`yaml
test-db:
services:
- name: postgres:16-alpine
alias: db
variables:
POSTGRES_DB: testdb
POSTGRES_USER: testuser
POSTGRES_PASSWORD: testpass
`
L'alias db permet d'accéder au service via le hostname db dans vos scripts. Sans alias, le hostname par défaut serait postgres (nom de l'image).

Vérification : Le job démarre sans erreur "connection refused" au démarrage.

Tâche 2 : Attendre que PostgreSQL soit prêt

PostgreSQL met quelques secondes à démarrer. Ajoutez une boucle d'attente dans le script avant d'exécuter des requêtes.

Indice :
`bash
until pg_isready -h db -U $POSTGRES_USER; do
echo "En attente de PostgreSQL..."
sleep 2
done
`
pg_isready est disponible dans l'image postgres:16-alpine. Si votre image de job est différente, installez postgresql-client d'abord.

Vérification : Les logs affichent "accepting connections" avant la première requête SQL.

Tâche 3 : Exécuter des requêtes SQL

Depuis le job, connectez-vous à la base via psql et créez une table users, insérez un enregistrement, puis vérifiez avec un SELECT.

Indice :
`bash
PGPASSWORD=$POSTGRES_PASSWORD psql -h db -U $POSTGRES_USER -d $POSTGRES_DB -c "
CREATE TABLE users (id SERIAL, name TEXT);
INSERT INTO users (name) VALUES ('alice');
SELECT * FROM users;
"
`
La variable d'environnement PGPASSWORD évite l'invite de mot de passe interactive.

Vérification : Le SELECT retourne une ligne avec 1 | alice dans les logs.

Tâche 4 : Ajouter un service Redis

Créez un second job test-redis qui déclare redis:7-alpine comme service (alias cache) et vérifie la connectivité avec redis-cli ping.

Indice :
`yaml
test-redis:
image: redis:7-alpine
services:
- name: redis:7-alpine
alias: cache
script:
- redis-cli -h cache ping

> Redis ne nécessite pas de variables de configuration par défaut. La réponse `PONG` confirme que le service répond.

**Vérification :** Les logs du job `test-redis` affichent `PONG`.

---

### Tâche 5 : Comprendre la portée des services

Vérifiez que le service PostgreSQL du job `test-db` n'est pas accessible depuis le job `test-redis`. Chaque job a son propre réseau isolé.

> **Indice :** Essayez `pg_isready -h db` dans le job `test-redis` - vous devriez obtenir une erreur de connexion. C'est le comportement attendu : les services sont scoped au job qui les déclare.

**Vérification :** `pg_isready -h db` échoue dans `test-redis` (timeout ou connexion refusée).

---

## 🗂️ Mini-Projet : Pipeline avec services de base de données

**Checkpoints de validation :**

- [ ] Le service `postgres:16-alpine` démarre correctement avec les variables `POSTGRES_*`
- [ ] La boucle d'attente `pg_isready` fonctionne avant les requêtes
- [ ] Le `SELECT * FROM users` retourne les données insérées
- [ ] `redis-cli -h cache ping` retourne `PONG`
- [ ] Les services sont bien isolés entre les jobs

---

Exercice 03 : Lancer des services dans les jobs

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Déclarer un service postgres:16-alpine avec un alias dans un job
✅ Configurer les variables POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD
✅ Vous connecter au service via son alias depuis le script du job
✅ Appliquer le même pattern à d'autres services (Redis, MySQL)

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Module GitLab CI Intermédiaire - Exercice 02 complété
Notions SQL de base (psql)

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Déclarer le service PostgreSQL

Dans un job test-db, déclarez le service postgres:16-alpine avec l'alias db. Configurez les variables POSTGRES_DB, POSTGRES_USER et POSTGRES_PASSWORD.

Indice :
`yaml
test-db:
services:
- name: postgres:16-alpine
alias: db
variables:
POSTGRES_DB: testdb
POSTGRES_USER: testuser
POSTGRES_PASSWORD: testpass
`
L'alias db permet d'accéder au service via le hostname db dans vos scripts. Sans alias, le hostname par défaut serait postgres (nom de l'image).

Vérification : Le job démarre sans erreur "connection refused" au démarrage.

Tâche 2 : Attendre que PostgreSQL soit prêt

PostgreSQL met quelques secondes à démarrer. Ajoutez une boucle d'attente dans le script avant d'exécuter des requêtes.

Indice :
`bash
until pg_isready -h db -U $POSTGRES_USER; do
echo "En attente de PostgreSQL..."
sleep 2
done
`
pg_isready est disponible dans l'image postgres:16-alpine. Si votre image de job est différente, installez postgresql-client d'abord.

Vérification : Les logs affichent "accepting connections" avant la première requête SQL.

Tâche 3 : Exécuter des requêtes SQL

Depuis le job, connectez-vous à la base via psql et créez une table users, insérez un enregistrement, puis vérifiez avec un SELECT.

Indice :
`bash
PGPASSWORD=$POSTGRES_PASSWORD psql -h db -U $POSTGRES_USER -d $POSTGRES_DB -c "
CREATE TABLE users (id SERIAL, name TEXT);
INSERT INTO users (name) VALUES ('alice');
SELECT * FROM users;
"
`
La variable d'environnement PGPASSWORD évite l'invite de mot de passe interactive.

Vérification : Le SELECT retourne une ligne avec 1 | alice dans les logs.

Tâche 4 : Ajouter un service Redis

Créez un second job test-redis qui déclare redis:7-alpine comme service (alias cache) et vérifie la connectivité avec redis-cli ping.

Indice :
`yaml
test-redis:
image: redis:7-alpine
services:
- name: redis:7-alpine
alias: cache
script:
- redis-cli -h cache ping

> Redis ne nécessite pas de variables de configuration par défaut. La réponse `PONG` confirme que le service répond.

**Vérification :** Les logs du job `test-redis` affichent `PONG`.

---

### Tâche 5 : Comprendre la portée des services

Vérifiez que le service PostgreSQL du job `test-db` n'est pas accessible depuis le job `test-redis`. Chaque job a son propre réseau isolé.

> **Indice :** Essayez `pg_isready -h db` dans le job `test-redis` - vous devriez obtenir une erreur de connexion. C'est le comportement attendu : les services sont scoped au job qui les déclare.

**Vérification :** `pg_isready -h db` échoue dans `test-redis` (timeout ou connexion refusée).

---

## 🗂️ Mini-Projet : Pipeline avec services de base de données

**Checkpoints de validation :**

- [ ] Le service `postgres:16-alpine` démarre correctement avec les variables `POSTGRES_*`
- [ ] La boucle d'attente `pg_isready` fonctionne avant les requêtes
- [ ] Le `SELECT * FROM users` retourne les données insérées
- [ ] `redis-cli -h cache ping` retourne `PONG`
- [ ] Les services sont bien isolés entre les jobs

---