Compare commits
No commits in common. 'a0a9dc41744775d80a495978e738718d1eb23ffc' and '01edbc92c0fff5a8ae77436b8da1904c7d4a6665' have entirely different histories.
a0a9dc4174
...
01edbc92c0
@ -1,2 +0,0 @@
|
||||
.venv
|
||||
build/*
|
||||
@ -1,83 +0,0 @@
|
||||
Déploiement
|
||||
=============
|
||||
|
||||
Le dossier `deployment/roles` contient des *roles*, c'est-à-dire des élément d'installation exécutés par ansible sur le serveur. Le fichier `playbook.yml` définit l'ordre dans lequel ansible lance les roles.
|
||||
|
||||
- `common` installe le paquet debian.
|
||||
|
||||
- `nginx` installe le reverse proxy.
|
||||
|
||||
- `certbot` ajoute le certificat https.
|
||||
|
||||
- `archive` :
|
||||
|
||||
- lance la commande git archive qui crée un tar.gz à partir du dossier de la webapp ;
|
||||
|
||||
- met cette archive dans `deployment/roles/archive/files` ;
|
||||
|
||||
- copie l'archive dans le dossier `opt` du serveur ;
|
||||
|
||||
- extraie l'archive dans le serveur : le code de la webapp est donc copiée dans le serveur.
|
||||
|
||||
- `pip` installe les librairies Python nécessaires sur le serveur.
|
||||
|
||||
- `run` lance l'application Flask.
|
||||
|
||||
- `mongodb` installe mongodb sur le serveur.
|
||||
|
||||
L'activation de l'ensemble des roles est automatisée avec le script `run_playbook.sh`.
|
||||
|
||||
Procédure d'installation
|
||||
------------------------
|
||||
|
||||
1. Dans `princevault`, *activer le venv* :
|
||||
|
||||
- faire le decrypt : `./vault decrypt` ;
|
||||
|
||||
- ajouter la clef ssh : `ssh-keygen -f "<PATH>/.ssh/known_hosts" -R "<SITE>"`, `ssh-copy-id -i <PATH>/.ssh/id_ed25519.pub debian@<SITE>`.
|
||||
|
||||
2. Dans `webapp` :
|
||||
|
||||
- copier/coller le param.yaml de `princevault` et le renommer.
|
||||
|
||||
- pour livrer une version de la webapp il faut créer un tag : `git checkout main`, `git merge develop`, `git tag -a <nom du tag> -m "<message>"`.
|
||||
|
||||
3. Dans `deployment`, *activer le venv* :
|
||||
|
||||
- copier/coller le main.yml de `princevault/deployment` dans `deployment/group_vars/all`, le renommer et vérifier que le bon tag est renseigner dans `application_release_tag`.
|
||||
|
||||
- lancer le playbook (`./install.sh`), qui lance les rôles :
|
||||
|
||||
- Rôle common. `deployment/roles/common/tasks/main.yml` : installation et mise à jour du système et des outils. (cron renouvelle le certificat https)
|
||||
|
||||
- Rôle ngnx. `deployment/roles/nginx/tasks/main.yml` : compléter les fichiers de `/etc/nginx/sites-enabled/`. Pour ajouter une autre appli, faire une variable `domain2`.
|
||||
|
||||
- Rôle certbot.
|
||||
|
||||
- Rôle archive.
|
||||
|
||||
- Rôle pip.
|
||||
|
||||
- Rôle mongodb.
|
||||
|
||||
4. Dans `datascience`, *activer le venv* :
|
||||
|
||||
- copier/coller le param.yml de `princevault/datascience` dans `datascience/actes-princiers/conf/local`
|
||||
|
||||
- installer les librairies : `pip install -r ./actes-princiers/src/requirements.txt`
|
||||
|
||||
- récupéer les dernières données : `./data_registry_update.sh`
|
||||
|
||||
- effacer le contenu de 02_intermediate`./clean_intermediate_data.sh`
|
||||
|
||||
- dans `datascience/actes-princiers` : `kedro run --tags="etl_transform"`
|
||||
|
||||
- (scp -r datascience/ <user>@<domain>:~/)
|
||||
|
||||
- `kedro run --tags="populate_database"`
|
||||
|
||||
5. Dans `deployment`, *activer le venv* :
|
||||
|
||||
- Lancement de l'application (`launch_playbook.yml`) avec `./launch_application.sh`
|
||||
|
||||
7. Publier l'application en cas de mise à jour : `deployment/publish.sh`
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
@ -1,32 +0,0 @@
|
||||
Gestion des informations d'identification
|
||||
=============================================
|
||||
|
||||
:keywords: credentials, secrets, vault
|
||||
|
||||
En anglais : les *credentials*, ou d'une manière plus générale, les *secrets*.
|
||||
|
||||
Deux méthodes sont utilisées dans le projet, suivant que les informations
|
||||
sensibles sont contenues dans un (ou des) fichier(s) centralisés ou bien que
|
||||
les informations sensibles sont, de par la nature du projet, réparties dans tout le projet.
|
||||
|
||||
- Le fichier non inclus dans le dépôt. C'est la méthode la plus simple,
|
||||
on utilise le fichier `.gitignore` du projet ;
|
||||
- Dans les cas où les variables sont disséminées, on utilise un :term:`coffre`
|
||||
pour chifrer et déchiffrer (encrypt and decrpyt) les fichiers sensibles.
|
||||
|
||||
Typiquement dans un projet de déploiement basé sur ansible, les variables de configuration et les variables sensibles sont réparties dans les différents :term:`rôles`, dans ce cas la méthode de chiffrement est préférable.
|
||||
|
||||
.. note:: cette méthode est à utiliser de préférence aussi
|
||||
si on utilise des conteneurs (ex: docker), c'est la méthode utilisée
|
||||
par les différents orchestrateurs de conteneur (ex: kubernetes).
|
||||
|
||||
.. glossary::
|
||||
|
||||
coffre
|
||||
|
||||
Un coffre fort virtuel est un endroit où sont placé les fichiers sensibles, ou bien simplement une manière de chiffrer ces fichiers sensibles.
|
||||
|
||||
rôles
|
||||
|
||||
Les rôles ansibles sont des morceaux cohérents de configuration, par exemple si on installe un serveur web sur une machine cible, l'étape de configuration du https avec let's encrypt est une étape autonome qui peut être isolée.
|
||||
L'intérêt est de pouvoir mieux lire les différentes étapes de l'installation de la machine cible.
|
||||
Loading…
Reference in New Issue