diff --git a/.gitignore b/.gitignore index 75e2e36..82b703a 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,4 @@ _book/ build *.log *.vscode/ +*.asciidoctor/ diff --git a/adoc/main.html b/adoc/main.html deleted file mode 100644 index a8a1efb..0000000 --- a/adoc/main.html +++ /dev/null @@ -1,626 +0,0 @@ - - - - - - - - -Deep dive into Django - - - - - -
-
-
-
-

On ne va pas se mentir: il existe enormément de tutoriaux très bien réalisés sur "Comment réaliser une application Django" et autres "Déployer votre code en 2 minutes". On se disait juste que ces tutoriaux restaient relativement haut-niveau et se limitaient à un contexte donné.

-
-
-

L’idée du texte ci-dessous est de jeter les bases d’un bon développement, en survolant l’ensemble des outils permettant de suivre des lignes directrices reconnues, de maintenir une bonne qualité de code au travers des différentes étapes (du développement au déploiement) et de s’assurer du maintient correct de la base de code, en permettant à n’importe qui de reprendre le développement.

-
-
-

Ces idées ne s’appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python. Juste que ces deux bidules sont de bons candidats et que le cadre de travail est bien défini et suffisamment flexible.

-
-
-

Pour cela, on présentera différents outils (mypy, flake, black, …​), la rédaction de tests unitaires et d’intégration pour limiter les régressions, les règles de nomenclature et de contrôle du contenu, ainsi que les bonnes étapes pour arriver à un déploiement rapide et fonctionnel en peu d’étapes.

-
-
-

Dans tout à un seul et même endroit. Oui. :-)

-
-
-

Bonne lecture.

-
-
-
-
-

Configuration de l’environnement

-
-
-

Et configuration de l’espace de travail.

-
-
-

Environnements virtuels

-
-

On va commencer avec la partie la moins funky, mais la plus utile, dans la vie d’un développeur: la gestion et l’isolation des dépendances.

-
-
-

Il est tout à fait possible de s’en passer complètement dans le cadre de "petits" projets ou d’applications déployées sur des machines dédiées, et de fonctionner à grand renforts de "sudo" et d’installation globale des dépendances. Cette pratique est cependant fortement déconseillée pour plusieurs raisons:

-
-
-
    -
  1. -

    Pour la reproductibilité d’une

    -
  2. -
  3. -

    il est tout à fait envisagable que deux applications soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d’une même dépendance.

    -
  4. -
-
-
-
-

Flake8

- -
-
-

Black

- -
-
-

pytest

- -
-
-

mypy

- -
-
-
-
-

Déploiement

-
-
-

On va déjà parler de déploiement. Si vous avez suivi les étapes jusqu’ici, vous devriez à peine disposer d’un espace de travail proprement configuré, d’un modèle relativement basique et d’une configuration avec une base de données simpliste. En bref, vous avez quelque chose qui fonctionne, mais qui ressemble de très loin à ce que vous souhaitez au final.

-
-
-

Il y a une raison très simple à aborder le déploiement dès maintenant: à trop attendre et à peaufiner son développement en local, on en oublie que sa finalité sera de se retrouver exposé sur un serveur. On risque d’avoir oublié une partie des désidérata, d’avoir zappé une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu’elles fonctionnent sur un environnement en particulier.

-
-
-

Aborder le déploiement maintenant permet également de rédiger dès le début les procédures d’installation, de mise à jour et de sauvegardes. Déploier une nouvelle version sera aussi simple que de récupérer la dernière archive depuis le dépôt, la placer dans le bon répertoire, appliquer des actions spécifiques (et souvent identiques entre deux versions), puis redémarrer les services adéquats.

-
-
-

Dans cette partie, on abordera les points suivants:

-
-
-
    -
  • -

    La définition de l’infrastructure nécessaire à notre application

    -
  • -
  • -

    La configuration de l’hôte, qui hébergera l’application: dans une machine physique, virtuelle ou dans un container. On abordera aussi rapidement les déploiements via Ansible, Chef, Puppet ou Salt.

    -
  • -
  • -

    Les différentes méthodes de supervision de l’application: comment analyser les fichiers de logs et comment intercepter correctement une erreur si elle se présente et comment remonter l’information.

    -
  • -
  • -

    Une partie sur la sécurité et la sécurisation de l’hôte.

    -
  • -
-
-
-

Définition de l’infrastructure

-
-

Comme on l’a vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d’une application. On peut ainsi commencer petit, et suivre l’évolution des besoins en fonction de la charge estimée ou ressentie, ajouter un mécanisme de mise en cache, des logiciels de suivi, …​

-
-
-
-

Configuration et sécurisation de la machine hôte

-
-

Supervisor, nginx, gunicorn, utilisateurs, groupes, …​

-
-
-

Aussi : Docker, Heroku, Digital Ocean, Scaleway, OVH, …​ Bref, sur Debian et CentOS pour avoir un panel assez large. On oublie Windows.

-
-
-
-

Mise à jour

-
-

Script de mise à jour.

-
-
-
-

Supervision

-
-

Qu’est-ce qu’on fait des logs après ? :-)

-
-
-
-
-
-

Déploiement

-
-
-

Et sécurisation du serveur.

-
-
-
-
-

Modélisation

-
-
-

Et administration.

-
-
-
-
-

Go Live !

-
-
-

Et supervision.

-
-
-
-
- - - \ No newline at end of file