Télémétrie et composants
continuous-integration/drone/push Build is failing
Details
continuous-integration/drone/push Build is failing
Details
This commit is contained in:
parent
9e0ef60e44
commit
bc7c7f74d4
|
|
@ -68,7 +68,7 @@ C'est donc une bonne idée de faire en sorte que des erreurs d'indisponibilité
|
|||
\hline
|
||||
Reverse Proxy & & Nginx \\
|
||||
\hline
|
||||
Load balancers & Distribue la charge sur plusieurs serveurs, en fonction du nombre d'utilisateurs, du nombre de requêtes à gérer et du temps que prennent chacune d'entre elles & HAProxy \\
|
||||
Load balancers & Distribution de la charge sur plusieurs serveurs, en fonction du nombre d'utilisateurs, du nombre de requêtes à gérer et du temps que prennent chacune d'entre elles & HAProxy \\
|
||||
\hline
|
||||
Serveurs d'application & & Gunicorn, Uvicorn \\
|
||||
\hline
|
||||
|
|
@ -108,15 +108,29 @@ Le principe du \textbf{proxy inverse} est de pouvoir rediriger du trafic entrant
|
|||
|
||||
\subsubsection{Répartiteur de charge (\textit{Load balancer})}
|
||||
|
||||
Les répartiteurs de charges sont super utiles pour donner du mou à l'infrastructure:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Maintenance et application de patches,
|
||||
\item Répartition des utilisateurs connectés,
|
||||
\item \ldots
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{Serveurs d'application (\textit{Workers})}
|
||||
|
||||
\subsubsection{Télémétrie}
|
||||
Processus et threads.
|
||||
|
||||
Au niveau logiciel (la partie mise en subrillance ci-dessus), la requête arrive dans les mains du processus Python, qui doit encore
|
||||
|
||||
\begin{enumerate}
|
||||
\item effectuer le routage des données,
|
||||
\item trouver la bonne fonction à exécuter,
|
||||
\item récupérer les données depuis la base de données,
|
||||
\item effectuer le rendu ou la conversion des données,
|
||||
\item et renvoyer une réponse à l'utilisateur.
|
||||
\end{enumerate}
|
||||
|
||||
\begin{quote}
|
||||
Once a rocket has left the ground, telemetry is essential for tracking what's happening and for understanding failures \cite[p. 10]{data_design}
|
||||
\end{quote}
|
||||
|
||||
Le
|
||||
|
||||
\subsection{Composants de supervision}
|
||||
|
||||
|
|
@ -205,7 +219,7 @@ La configuration des \emph{loggers} est relativement simple, un peu plus complex
|
|||
Il est ainsi possible de définir des formattages, différents gestionnaires (\emph{handlers}) et loggers distincts, en fonction de nos applications.
|
||||
|
||||
Sauf que comme nous l'avons vu avec les 12 facteurs, nous devons traiter les informations de notre application comme un flux d'évènements.
|
||||
Il n'est donc pas réellement nécessaire de chipoter la configuration, puisque la seule classe qui va réellement nous intéresser concerne les \texttt{StreamHandler}.
|
||||
Il n'est donc pas réellement nécessaire de chipoter la configuration, puisque la seule classe qui va réellement nous intéresser concerne les \texttt{StreamHandler}, qui seront pris en charge par gunicorn \index{Gunicorn}.
|
||||
La configuration que nous allons utiliser est celle-ci:
|
||||
|
||||
\begin{enumerate}
|
||||
|
|
@ -253,20 +267,3 @@ Il existe également \href{https://munin-monitoring.org}{Munin}, \href{https://w
|
|||
\subsubsection{Sentry}
|
||||
|
||||
\subsubsection{Greylog}
|
||||
|
||||
|
||||
\section{Niveau application}
|
||||
Au niveau logiciel (la partie mise en subrillance ci-dessus), la requête arrive dans les mains du processus Python, qui doit encore
|
||||
|
||||
\begin{enumerate}
|
||||
\item effectuer le routage des données,
|
||||
\item trouver la bonne fonction à exécuter,
|
||||
\item récupérer les données depuis la base de données,
|
||||
\item effectuer le rendu ou la conversion des données,
|
||||
\item et renvoyer une réponse à l'utilisateur.
|
||||
\end{enumerate}
|
||||
|
||||
Comme nous l'avons 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.
|
||||
Il est possible de démarrer petit, et de suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, d'ajouter un mécanisme de mise en cache, des logiciels de suivi, \ldots
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -690,3 +690,8 @@ En continuant de cette manière (ie. Ecriture du code et des tests, vérificatio
|
|||
|
||||
A noter que tester le modèle en lui-même (ses attributs ou champs) ou des composants internes à Django n'a pas de sens: cela reviendrait à mettre en doute son fonctionnement interne.
|
||||
Selon le principe du SRP \ref{SRP}, c'est le framework lui-même qui doit en assurer la maintenance et le bon fonctionnement.
|
||||
|
||||
\section{Conclusions}
|
||||
|
||||
Comme nous l'avons 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.
|
||||
Il est possible de démarrer petit, et de suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, d'ajouter un mécanisme de mise en cache, des logiciels de suivi, \ldots
|
||||
|
|
|
|||
|
|
@ -0,0 +1,2 @@
|
|||
\chapter{Svelte}
|
||||
|
||||
|
|
@ -65,6 +65,8 @@ Si vous n'en utilisez pas déjà un, partez sur \href{https://keepassxc.org/}{Ke
|
|||
|
||||
\includegraphics{images/environment/keepass.png}
|
||||
|
||||
La finalité de cette application va être de centraliser la gestion de vos phrases de passe, pour les accès aux bases de données, services en ligne, etc.
|
||||
|
||||
\subsection{Un système de gestion de versions}
|
||||
|
||||
Il existe plusieurs systèmes de gestion de versions.
|
||||
|
|
@ -78,12 +80,20 @@ Ses deux plus gros défauts concernent sa courbe d'apprentissage pour les nouvea
|
|||
\caption{\url{https://xkcd.com/1597/}}
|
||||
\end{figure}
|
||||
|
||||
Même pour un développeur solitaire, un système de gestion de versions (quel qu'il soit) reste indispensable.
|
||||
|
||||
Chaque "\textbf{branche}" correspond à une tâche à réaliser: un bogue à corriger (\emph{Hotfix A}), une nouvelle fonctionnalité à ajouter ou un "\emph{truc à essayer}" \footnote{Oui, comme dans "Attends, j'essaie vite un truc, si ça marche, c'est beau."} (\emph{Feature A} et \emph{Feature B}).
|
||||
|
||||
Chaque "\textbf{commit}" correspond à une sauvegarde atomique d'un état ou d'un ensemble de modifications cohérentes entre elles.\footnote{Il convient donc de s'abstenir de modifier le CSS d'une application et la couche d'accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up.}
|
||||
De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Même pour un développeur solitaire, un système de gestion de versions (quel qu'il soit) reste indispensable, car il permet d'isoler un ensemble de modifications dans une \textit{unité de travail}, jusqu'à ce que celles-ci forment un tout cohérent:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Chaque "\textbf{branche}" correspond à une tâche à réaliser: un bogue à corriger (\emph{Hotfix A}), une nouvelle fonctionnalité à ajouter ou un "\emph{truc à essayer}" \footnote{Oui, comme dans "Attends, j'essaie vite un truc, si ça marche, c'est beau."} (\emph{Feature A} et \emph{Feature B}).
|
||||
\item
|
||||
Chaque "\textbf{commit}" correspond à une sauvegarde atomique d'un état ou d'un ensemble de modifications cohérentes entre elles.\footnote{Il convient donc de s'abstenir de modifier le CSS d'une application et la couche d'accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up.}
|
||||
De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.
|
||||
\end{enumerate}
|
||||
\item
|
||||
L'historique d'un module est ainsi disponible, sauvé et traçable: qui a réalisé quelle modification à quel moment.
|
||||
Ceci permet notamment de dessiner l'évolution du code et de mettre un surbrillance que certains modules distincts évoluent un peu trop main dans la main (et devraient donc être refactoriser, selon les principes de développement énumérés plus tôt).
|
||||
\end{enumerate}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
|
|
@ -91,7 +101,7 @@ De cette manière, il est beaucoup plus facile pour le développeur de se concen
|
|||
\caption{Git en action}
|
||||
\end{figure}
|
||||
|
||||
Cas pratique: vous développez cette nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
|
||||
Cas pratique: vous développez une nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
|
||||
Il suffit alors de:
|
||||
|
||||
\begin{enumerate}
|
||||
|
|
@ -111,15 +121,17 @@ Il suffit alors de:
|
|||
Et revenir tranquillou sur votre branche de développement pour fignoler ce générateur de noms de dinosaures rigolos que l'univers vous réclame à cor et à a cri (\texttt{git\ checkout\ features/dinolol})
|
||||
\end{enumerate}
|
||||
|
||||
Finalement, sachez qu'il existe plusieurs manières de gérer ces flux d'informations.
|
||||
Les plus connus sont \href{https://www.gitflow.com/}{Gitflow} et \href{https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/}{Threeflow}.
|
||||
Il existe plusieurs méthodes pour gérer ces flux d'informations.
|
||||
Les plus connues sont \href{https://www.gitflow.com/}{Gitflow} et \href{https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/}{Threeflow}.
|
||||
|
||||
La gestion de versions de fichiers permet de conserver un historique de toutes les modifications enregistrées, associées à un horodatage et une description.
|
||||
|
||||
|
||||
\subsection{Décrire ses changements}
|
||||
|
||||
La description d'un changement se fait \emph{via} la commande \texttt{git\ commit}.
|
||||
Il est possible de lui passer directement le message associé à ce changement grâce à l'attribut \texttt{-m}, mais c'est une pratique relativement déconseillée: un \emph{commit} ne doit effectivement pas obligatoirement être décrit sur une seule ligne.
|
||||
Une description plus complète, accompagnée des éventuels tickets ou références, sera plus complète, plus agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.
|
||||
Une description plus complète, accompagnée des éventuels tickets ou références de tâches, sera plus complète, plus agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.
|
||||
|
||||
De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique. Par exemple:
|
||||
|
||||
|
|
@ -131,6 +143,9 @@ De plus, la plupart des plateformes de dépôts présenteront ces informations d
|
|||
|
||||
La première ligne est reprise comme titre (normalement, sur 50 caractères maximum); le reste est repris comme de la description.
|
||||
|
||||
\subsection{Nommer ses branches}
|
||||
|
||||
|
||||
\section{Bases de données}
|
||||
|
||||
\begin{quote}
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 272 KiB |
Loading…
Reference in New Issue