gwift-reborn/deployment.asc

= Déploiement

____
To be effective, a software system must be deployable.
The higher the cost of deployements, the less useful the system is.
A goal of a software architecture, then, should be to make a system that can be
easily deployed with a single action. Unfortunately, deployment strategy is seldom considered during initial development.
This leads to architectures that may be make the system easy to develop, but leave it
very difficult to deploy.

— Robert C. Martin, Clean Architecture
____

Il y a une raison très simple à aborder le déploiement dès maintenant : à trop attendre et à peaufiner son développement pour soi-même, on en oublie que sa finalité sera de se retrouver exposé et accessible depuis un serveur.
Il est probable d’oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu’elles puissent être mises à disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé.

Un bon déploiement ne doit pas dépendre de dizaines de petits scripts éparpillés sur le disque : l’objectif est que celui-ci soit rapide et fiable.
Cet objectif peut être atteint au travers d’un partitionnement correct, incluant le fait que le composant principal s’assure que chaque sous-composant est correctement démarré intégré et supervisé.

Aborder le déploiement dès le début du développement permet également de rédiger les procédures d’installation, de mises à jour et de sauvegardes adaptées.
A la fin de chaque intervalle de développement, les fonctionnalités auront dû avoir été intégrées, testées, fonctionnelles et un code propre, démontrable dans un environnement similaire à un environnement de production, et créées à partir d’un tronc commun au développement.

Déploier une nouvelle version doit être le plus simple possible, et doit se résumer, dans le pire des cas, à quelques lignes d’un script Bash.

____
Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and disruptions such as service outages, service impairments, or security or compliance failures.

— DevOps Handbook Introduction
____

Le serveur que Django met à notre disposition _via_ la commande `runserver` est extrêmement pratique, mais il est uniquement prévu pour la phase développement. En production :

* Il est inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ... De même, Django propose par défaut une base de données SQLite, qui fonctionne parfaitement dès lors que l’on connait ses limites et que l’on se limite à un utilisateur à la fois.
* Il est légitime que la base de donnée soit capable de supporter plusieurs utilisateurs et connexions simultanés. En restant avec les paramètres par défaut, il est plus que probable que vous rencontriez rapidement des erreurs de verrou parce qu’un autre processus a déjà pris la main pour écrire ses données. En bref, vous avez quelque chose qui fonctionne, qui répond à un besoin, mais qui va attirer la grogne de ses utilisateurs pour des problèmes de latences, pour des erreurs de verrou
ou simplement parce que le serveur répondra trop lentement.

L’objectif de cette partie est de parcourir les différentes possibilités qui s’offrent à nous en termes de déploiement, tout en faisant en sorte que le code soit le moins couplé possible à sa destination de production.
L’objectif est donc de faire en sorte qu’une même application puisse être hébergées par plusieurs hôtes sans avoir à subir de modifications.
Nous vous renvoyons vers les 12-facteurs dont nous avons déjà parlé <<Fiabilité, évolutivité et maintenabilité>> et qui vous énormément nous aider, puisque ce sont des variables d’environnement qui vont réellement piloter le câblage entre l’application, ses composants et son hébergement.

RedHat proposait récemment un article intitulé https://www.redhat.com/fr/topics/cloud-computing/what-is-iaas[_*What Is IaaS*_], qui présentait les principales différences entre types d’hébergement.

[cols=">,^,^,^,^",]
|===
| |On-site |IaaS |PaaS |SaaS
|Applications | | | |
|Données | | | |
|Exécution | | | |
|Middleware | | | |
|Système d’exploitation | | | |
|Virtualisation | | | |
|Serveurs | | | |
|Stockage | | | |
|Réseau | | | |
|===

Ainsi, on trouve :

. Le déploiment _on-premises_ ou _on-site_,
. Les _Infrastructures as a Service_ ou _IaaS_
. Les _Platforms as a Service_ ou _PaaS_
. Les _Softwares as a service_ ou _SaaS_, ce dernier point nous
concernant moins, puisque c’est nous qui développons le logiciel.

Dans cette partie, nous aborderons les points suivants :

. Définir l’infrastructure et les composants nécessaires à notre application
. Configurer l’hôte qui hébergera l’application et y déployer notre application: dans une machine physique, virtuelle ou dans un container. Nous aborderons aussi les déploiements via Ansible et Salt. A ce stade, nous aurons déjà une application disponible.
. Configurer les outils nécessaires à la bonne exécution de ce code et de ses fonctionnalités: les différentes méthodes de supervision de l’application, comment analyser les fichiers de logs, comment intercepter correctement une erreur si elle se présente et comment remonter correctement l’information.

Nous allons détailler ci-dessous trois méthodes de déploiement :

* Sur une machine hôte, en embarquant tous les composants sur un même serveur. Ce ne sera pas idéal, puisqu’il ne sera pas possible de configurer un _load balancer_, de routeur plusieurs basées de données, mais ce sera le premier cas de figure.
* Dans des containers, avec Docker-Compose (et à nouveau sur un seul serveur)
* Sur une *Plateforme en tant que Service* (ou plus simplement, *PaaSPaaS*), pour faire abstraction de toute la couche de configuration du serveur.

Vous noterez que l’ensemble des composants utilisés sont _Open source_ :

____
When I built my first company starting in 1999, it cost $2.5 million in
infrastructure just to get started and another $2.5 million in team
costs to code, launch, manage, market and sell our software [...].

The first major change in our industry was imperceptible to us as an
industry. It was driven by the introduction of open-source software,
most notably what was called the LAMP stack. Linux (instead of UNIX),
Apache (web server software), MySQL (instead of Oracle) and PHP. Of
course there were variants - we preferred PostGres to MySQL and many
people used other programming languages than PHP.

Open source became a movement - a mentality: Suddenly infrastructure
software was nearly free. We paid 10% of the normal costs for the
software and that money was software support. A 90% disruption in cost
spawns innovation - belive me.

– Mark Suster
____

Dans tous les cas, la disponibilité de logiciels et librairies _open source_, ainsi que des plateformes d’hébergements (comme Amazon Web Services ou Heroku) plus accessibles signifient qu’une startup n’a plus besoin d’investir des millions pour démarrer.

[NOTE]
====
Avant que les logiciels libres n’existent, les entreprises technologiques traitaient les logiciels comme n’importe quel produit payant: une équipe d’employés construisait les nouveaux logiciels en interne, puis les vendait au public.
Le développement logiciel avait donc un business-model très clair, mais ceci venait en contrepartie avec des coûts énormes.
Les logiciels propriétaires demandaient des équipes complètes pour supporter le développement, tandis qu’il fallait également des vendeurs, une équipe marketing et un troupeau d’avocats.
====


include::book/deployment/infrastructure-components.adoc[]

include::book/deployment/processes.adoc[]

include::book/deployment/logs.adoc[]

include::book/deployment/native.adoc[]

include::book/deployment/files-storage.adoc[]

include::book/deployment/paas.adoc[]

include::book/deployment/cloud-native.adoc[]

include::book/deployment/kubernetes.adoc[]