1---
  2title: Déploiement
  3theme: ./_themes/5ika.css
  4highlightTheme: github
  5verticalSeparator: <!--v-->
  6revealOptions:
  7  transition: 'fade'
  8---
  9
 10# Déploiement et automatisation
 11
 12---
 13
 14# Développer, ce n’est pas uniquement coder, mais aussi...
 15
 16- Vérifier que l’application passe les tests
 17- Linter le code
 18- Installer des dépendances
 19- Compiler les sources
 20- Compiler une image Docker
 21- Déployer vers un ou plusieurs environnements d’exécution
 22- Notifier d’autres personnes
 23- Packager une application
 24- Migrer une base de données
 25- Recharger la page après une modification du code dans l’IDE
 26- ...
 27
 28---
 29
 30# On automatise !
 31
 32L'humain est doué pour réflechir et créer, la machine est douée pour executer et reproduire.
 33L’humain fait des erreurs, oublie des choses, tandis qu’un ordinateur suit continuellement la recette qu’on lui fournit.
 34  
 35- Moins de temps sur les tâches redondantes = Plus de temps sur le code
 36- Plus de temps sur le code = Meilleure qualité de code
 37- Meilleure qualité de code = Meilleur produit
 38
 39L’objectif final de l’automatisation, c’est de rendre le travail efficace et intéressant.
 40
 41---
 42
 43# Quoi automatiser ?
 44
 45**Automatiser**:
 46- Ce qui est récurrent (ex: Lint)
 47- Ce qui est douloureux (ex: Test)
 48- Ce qui est long (ex: Déploiement)
 49
 50**Ne pas automatiser**:
 51- Ce qui relève de la création, de la réflexion
 52- Ce qui demande des compétences très particulières ou nouvelles
 53
 54---
 55
 56# Qu'est-ce qu'un pipeline ?
 57
 58Des outils permettent de définir un ensemble d’actions à effectuer à chaque fois qu’un développeur push des modifications dans un dépôt Git.
 59
 60Cet ensemble d’actions est appelé **Pipeline**.
 61
 62Un Pipeline est définie en différents stages qui correspondent à des groupes d’actions. Par exemple: Test, Compilation, Déploiement
 63
 64---
 65
 66![Pipeline](./img/pipeline.png)
 67
 68---
 69
 70# C'est quoi un job ?
 71
 72Un pipeline est constitué d’un ensemble de **jobs** (ou tâches).
 73
 74Concrètement, un job est **un script Bash** qui s’exécute sur une base de code (un dépôt Git) dans le but d’effectuer une action claire (tester, déployer, alerter, …).
 75
 76Dans un pipeline, certains jobs peuvent s’effectuer en parallèle tandis que d’autres peuvent s’effectuer séquentiellement.
 77
 78---
 79
 80# Le CI/CD
 81
 82![CI/CD](./img/CI-CD.png)
 83
 84---
 85
 86# Les types de test
 87
 88- Tests unitaires
 89- Tests fonctionnels
 90- Tests de régressions
 91- Tests visuels
 92- Tests de charge
 93- Tests de sécurité
 94- Code coverage
 95- Calcul de dette technique
 96
 97> [SonarQube](https://www.sonarsource.com/products/sonarqube/) est un outil
 98> qui analyse le code pour nous donner des informations précises sur sa qualité
 99
100---
101
102# Outils de CI/CD
103
104Plusieurs outils nous permettent de configurer et gérer des pipelines.
105Parmis les plus utilisés:
106
107- Gitlab CI: Référence dans le domaine, facile à prendre en main
108- Jenkins: Celui qui a inventé le concept, un peu vieillot mais puissant
109- GitHub Actions: Manière de faire GitHub
110
111… chaque semaine des nouveaux
112
113---
114
115# Exemple (GitLab)
116
117- Les _jobs_ sont réunis dans des _stages_
118- La configuration est faite dans un fichier _.gitlab-ci.yml_
119- Tous les scripts sont exécutés dans des containers Docker
120- Les pipelines sont effectués par des Runners
121
122![Pipeline Gitlab](img/pipeline-gitlab.png)
123
124---
125
126![Jobs dans le pipeline GitLab](img/pipeline-gitlab-jobs.png)
127
128---
129
130# Avec GitHub
131
132Pour s'aligner avec GitLab, GitHub a mis en place un système de CI/CD
133nommé **GitHub Actions**.
134
135C'est ce que nous allons utiliser pour mettre en place un pipeline sur
136notre dépôt.
137
138---
139
140## Avantage de GitHub Actions
141
142- Intégration transparente : Les actions sont intégrées directement à GitHub, ce qui facilite leur utilisation avec vos dépôts.
143- Large écosystème : GitHub Actions dispose d'un vaste écosystème d'actions prédéfinies créées par la communauté et les organisations.
144
145---
146
147## Comment créer un workflow (pipeline)
148
149Un workflow est un ensemble d'étapes (actions) qui sont déclenchées automatiquement en réponse à des événements spécifiques sur GitHub.
150
151> Les étapes suivantes ne sont pas à réaliser tout de suite.
152> Nous allons les faire ensemble pas à pas ensuite.
153
1541. Dans notre base de code, on crée un dossier `.github` puis un dossier `workflows` dans ce dossier.
1552. Dans le dossier `.github/workflows/`, on crée un fichier `deploy.yml`
1563. Dans ce fichier `deploy.yml`, on défini nos jobs
157
158Lorsque l'on va pusher ce fichier sur le dépôt Git, Github Actions va le lire automatiquement
159et effectuer les actions définies.
160
161---
162
163## Événements
164
165Généralement, le déclenchement d'un nouveau pipeline/workflow est fait à chaque *push* dans le dépôt Git.
166
167Mais on peut également déclencher des actions sur d'autres événements:
168
169- Création d'une Pull Request
170- Création d'un *tag*
171- Push uniquement sur la branche principale
172- Périodiquement
173- Création d'une issue
174
175[Liste des événements disponibles](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)
176
177---
178
179## Création du fichier `deploy.yml`
180
181La définition des jobs doit suivre la structure attendue par GitHub Actions.
182
183```yaml
184name: Déploiement           # Nom du workflow
185on: 
186    - push                  # Événement(s)
187jobs:
188    build-docker-image:     # Nom du job
189        runs-on: ubuntu-latest  # OS utilisé pour executé le job
190        steps:                  # Suite de commandes / tâches à effectuer
191            - name: Check out code  # Nécessaire, expliqué plus tard
192              uses: actions/checkout@v3
193            - run: docker login -u ... -p ...
194            - run: docker build -t 5ika/deer .
195            - run: docker push 5ika/deer
196```
197
198---
199
200## Chut 🤫
201
202Pour s'authentifier auprès de Docker Hub afin de pusher notre image,
203nous avons besoin de fournir nos identifiants et mots de passe dans le fichier `deploy.yml`.
204
205Cependant, ce fichier est public. Tout le monde peut le voir.
206On ne peut donc pas y mettre des informations _secrètes_.
207
208GitHub Actions permet de définir ailleurs ces _secrets_ et les utiliser dans
209notre workflow.
210
211---
212
213## Définir des secrets
214
2151. Sur votre dépôt GitHub, aller dans _Settings_, puis _Secrets and variables_ et _Actions_
2162. Cliquer sur _New repository secret_
2173. Créer un secret avec le nom `DOCKER_HUB_PASSWORD` et mettre vote mot de passe Docker Hub comme valeur
218
219Ce secret est maintenant utilisable dans le fichier `deploy.yml`.
220
221---
222
223## Utiliser des secrets dans le workflow
224
225On complète notre workflow dans `deploy.yml` pour utiliser notre secret et
226des variables d'environnement:
227
228```yaml
229name: Déploiement           # Nom du workflow
230on: 
231    push                    # Événement(s)
232env:
233    USERNAME: 5ika
234    IMAGE_NAME: deer
235jobs:
236    build-docker-image:     # Nom du job
237        runs-on: ubuntu-latest  # OS utilisé pour executé le job
238        steps:                  # Suite de commandes / tâches à effectuer
239            - name: Check out code
240              uses: actions/checkout@v3
241            - run: docker login -u $USERNAME -p $PASSWORD
242              env:
243                PASSWORD: ${{secrets.DOCKER_HUB_PASSWORD}}
244            - run: docker build -t $USERNAME/$IMAGE_NAME .
245            - run: docker push $USERNAME/$IMAGE_NAME
246```
247
248---
249
250# À vous !
251
2521. Forker le dépôt https://github.com/5ika/Deer (si ce n'est pas déjà fait)
2532. Cloner votre fork sur votre machine (si ce n'est pas déjà fait)
2543. Ajouter un Dockerfile (si ce n'est pas déjà fait)
2554. Ajouter un workflow grâce aux slides précédentes (ça c'est pas fait)
256
257---
258
259## Utiliser des actions tierces
260
261GitHub Actions permet d'utiliser des *steps* toutes prêtes
262faites par d'autres personnes directement dans vos workflows.
263
264Il met à disposition un [Marketplace](https://github.com/marketplace?type=actions)
265avec des actions toutes prêtes à être utilisées dans votre workflow.
266
267---
268
269### Exemple d'utilisation
270
271La GitHub Action [Publish Docker](https://github.com/marketplace/actions/publish-docker)
272permet de réaliser les étapes que nous avons fait précédemment.
273
274Pour l'utiliser dans une _step_, on utilise le mot-clé `uses` plutôt que `run`.
275
276---
277
278```yaml
279name: Déploiement
280on: 
281    push
282env:
283    USERNAME: 5ika
284    IMAGE_NAME: deer
285jobs:
286    build-docker-image:
287        runs-on: ubuntu-latest
288        steps:
289            - name: Check out code
290              uses: actions/checkout@v3
291            - name: Publish to Registry
292              uses: elgohr/Publish-Docker-Github-Action@v5
293              with:
294                name: ${{ env.USERNAME }}/${{ env.IMAGE_NAME }}
295                username: ${{ env.USERNAME }}
296                password: ${{ secrets.DOCKER_HUB_PASSWORD }}
297```
298
299---
300
301### actions/checkout
302
303L'action [action/checkout](https://github.com/marketplace/actions/checkout) que nous
304avons utilisé dans notre workflow dès le début appelle une fonction
305fournie par GitHub.
306
307Celle-ci permet de faire en sorte d'avoir le code du dépôt dans le dossier
308courant pour le job. Un peu comme si on faisait un `git clone` pour récupérer
309les fichiers avant de builder l'image Docker.
310
311---
312
313## Travail pratique
314
3151. Ajouter un fichier `README.md` à votre dépôt avec un peu de contenu
3162. Sur le GitHub Marketplace, trouver l'action qui vous permet de mettre à jour la description de votre image sur Docker Hub
3173. Créer une nouvelle _step_ dans votre workflow qui utilise l'action que vous avez trouvé
318
319> Une fois terminé, à chaque fois que vous modifiez le README sur votre dépôt Git,
320> la description de votre image sur Docker Hub doit se mettre à jour.
321
322---
323
324# Serveurs dans le Cloud
325
326Quand on veut mettre à disposition une application à des utilisateurs,
327il faut que l'on fasse tourner notre application sur un _serveur_.
328
329Nous devons donc acheter un serveur sur un hébergeur.
330
331---
332
333# Les types de serveur
334
335![Types de serveur](img/server_types.png)
336
337---
338
339## CAAS
340
341Les CAAS, pour _Container as a Service_, sont une forme de PAAS.
342Elles permettent de faire tourner des images Docker.
343
344Dans le cadre de cette formation, nous utiliserons [Jelastic](https://www.virtuozzo.com/application-platform/)
345(maintenant appelé Virtuozzo Application Platform) proposé par Infomaniak.
346
347---
348
349# Démo du fonctionnement de Jelastic sur Infomaniak
350
351---
352
353# Travail pratique - Déploiement manuel
354
355Déployer manuellement l'image Docker que vous avez sur Docker Hub dans un nouvel
356environnement sur Jelastic.
357
358Tim fourni les identifiants en cours.
359
360À la fin de cette étape, vous avez désormais chacun.e:
361
362- Un environnement avec un unique node qui tourne, utilisant votre image
363- Une URL pour accéder à votre environnement
364
365---
366
367Maintenant, nous allons faire en sorte que notre environnement sur Infomaniak
368soit **automatiquement** mis à jour dès qu'on **modifie le code** de notre
369application dans git (lorsqu'on push).
370
371---
372
373# Exemple de job de déploiement vers Jelastic
374
375```yaml
376...
377
378env:
379    ENVNAME: change-me
380    ...
381
382... 
383
384  deploy-to-jelastic:
385    runs-on: ubuntu-latest
386    container: mwienk/jelastic-cli  # Image Docker dans laquelle les steps seront exécutées
387    needs: build-docker-image       # Indique qu'il faut attendre le job de build
388    steps:
389        # Petit fixe nécessaire pour la suite
390      - run: ln -s /root/jelastic-cli.jar /github/home/jelastic-cli.jar
391        # Authentification auprès de l'API de Jelastic Infomaniak
392      - run: /root/jelastic/users/authentication/signin --login "$JELASTIC_USERNAME" --password "$JELASTIC_PASSWORD" --platformUrl app.jpc.infomaniak.com
393        env:
394          JELASTIC_USERNAME: ${{ secrets.JELASTIC_USERNAME }}
395          JELASTIC_PASSWORD: ${{ secrets.JELASTIC_PASSWORD }}
396        # Utilisation de l'API de Jelastic pour redéployer l'image Docker utilisé dans son environnement
397      - run: /root/jelastic/environment/control/redeploycontainersbygroup --envName $ENVNAME --nodeGroup cp --tag latest
398```
399
400---
401
402Une fois que tout fonctionne, vous avez un pipeline de CI/CD qui met à disposition
403une image Docker et qui met à jour votre serveur à chaque fois que vous faites
404une modification au niveau de votre code.
405
406Bravo ! 🎉
407
408---
409
410Nous avons fait cela dans un cas très simple avec deux fichiers statiques
411mais grâce à Docker, la même mécanique peut être utilisée pour tous les
412langages et tous les types d'application.
413
414Il suffit juste d'adapter le fichier Dockerfile pour s'adapter
415aux besoins de l'app.
416
417---
418
419# Travail pratique
420
421Mettre en place un workflow qui envoi votre code vers SonarCloud (SonarQube).
422
423Une action dans le Marketplace existe: https://github.com/marketplace/actions/sonarcloud-scan
424
425---
426
427Maintenant, nous pouvons regarder comment mettre en place cela
428dans un de vos projets.
429
430---
431
432# S'il reste beaucoup de temps
433
434- Effectuer des actions sur des environnements autres que le `push`
435- Aborder comment fonctionne les GitHub pages