gwift-book/parts/deployment.tex

\part{Déploiement}

\begin{figure}[H]
    \centering
    \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/penguin-overflow.jpg}}
    \caption{"La Grande Vague" \url{https://www.peppercarrot.com/sr/viewer/framasoft-src__2020-11-06_la-grande-vague_by-David-Revoy.html} par David Revoy et Framasoft, CC-By}
\end{figure}


\begin{quote}
    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
\end{quote}

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
\cite{devops_handbook}.

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.

\begin{quote}
    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
\end{quote}

Le serveur que Django met à notre disposition \emph{via} la commande \texttt{runserver} est extrêmement pratique, mais il est uniquement prévu pour la phase développement.
En production:

\begin{itemize}
    \item Il est inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, \ldots
    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.
    \item 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.
\end{itemize}

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é 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é \emph{*What Is IaaS*} \footnote{\url{https://www.redhat.com/fr/topics/cloud-computing/what-is-iaas}}, qui présentait les principales différences entre types d'hébergement.

\begin{tabular}{r c c c c}
    & On-site & IaaS & PaaS & SaaS \\
    Applications & & & & \\
    Données & & & & \\
    Exécution & & & & \\
    Middleware & & & & \\
    Système d'exploitation & & & & \\
    Virtualisation & & & & \\
    Serveurs & & & & \\
    Stockage & & & & \\
    Réseau & & & & \\
\end{tabular}

\begin{figure}[H]
    \centering
    \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/deployment/iaas_focus-paas-saas-diagram.png}}
    \caption{L'infrastructure en tant que service, cc. \emph{RedHat Cloud Computing}}
\end{figure}

Ainsi, on trouve:

\begin{enumerate}
\item
    Le déploiment \emph{on-premises} ou \emph{on-site},
\item
    Les \emph{Infrastructures as a Service} ou \emph{IaaS}
\item
    Les \emph{Platforms as a Service} ou \emph{PaaS}
\item
    Les \emph{Softwares as a service} ou \emph{SaaS}, ce dernier point
    nous concernant moins, puisque c'est nous qui développons le logiciel.
\end{enumerate}

Dans cette partie, nous aborderons les points suivants:

\begin{enumerate}
    \item
        Définir l'infrastructure et les composants nécessaires à notre application
    \item
        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.
    \item
        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.
\end{enumerate}

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

\begin{itemize}
    \item
        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 \emph{load balancer}, de routeur plusieurs basées de données, mais ce sera le premier cas de figure.
    \item
        Dans des containers, avec Docker-Compose (et à nouveau sur un seul serveur)
    \item
        Sur une \textbf{Plateforme en tant que Service} (ou plus simplement, \textbf{PaaSPaaS}), pour faire abstraction de toute la couche de configuration du serveur.
\end{itemize}

Vous noterez que l'ensemble des composants utilisés sont \textit{Open source}:

\begin{quote}
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 [\ldots].

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
\end{quote}

Dans tous les cas, la disponibilité de logiciels et librairies \textit{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 \cite[p. 25]{roads_and_bridges} \footnote{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. \cite[p. 33]{roads_and_bridges}}.