120 lines
4.4 KiB
TeX
120 lines
4.4 KiB
TeX
\chapter{Debian}
|
||
|
||
La première étape pour la configuration de notre hôte consiste à définir les utilisateurs et groupes de droits. Il est faut absolument éviter de faire tourner une application en tant qu'utilisateur \textbf{root}, car la moindre faille pourrait avoir des conséquences catastrophiques.
|
||
|
||
Une fois que ces utilisateurs seront configurés, nous pourrons passer à l'étape de configuration, qui consistera à:
|
||
|
||
\begin{enumerate}
|
||
\item
|
||
Déployer les sources
|
||
\item
|
||
Démarrer un serveur implémentant une interface WSGI (\textbf{Web Server Gateway Interface}), qui sera chargé de créer autant de petits lutins travailleurs que nous le désirerons.
|
||
\item
|
||
Démarrer un superviseur, qui se chargera de veiller à la bonne santé de nos petits travailleurs, et en créer de nouveaux s'il le juge nécessaire
|
||
\item
|
||
Configurer un proxy inverse, qui s'occupera d'envoyer les requêtes d'un utilisateur externe à la machine hôte vers notre serveur applicatif, qui la communiquera à l'un des travailleurs.
|
||
\end{enumerate}
|
||
|
||
La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, ... Il existe des dizaines d'hébergements typés VPS (\textbf{Virtual Private Server}). A vous de choisir celui qui vous convient \footnote{Personnellement, j'ai un petit faible pour Hetzner Cloud}.
|
||
|
||
\section{Dépendances systèmes}
|
||
|
||
\section{Base de données}
|
||
|
||
|
||
On l'a déjà vu, Django se base sur un pattern type
|
||
\href{https://www.martinfowler.com/eaaCatalog/activeRecord.html}{ActiveRecords}
|
||
pour la gestion de la persistance des données et supporte les principaux
|
||
moteurs de bases de données connus:
|
||
|
||
\begin{itemize}
|
||
\item
|
||
SQLite (en natif, mais Django 3.0 exige une version du moteur
|
||
supérieure ou égale à la 3.8)
|
||
\item
|
||
MariaDB (en natif depuis Django 3.0),
|
||
\item
|
||
PostgreSQL au travers de psycopg2 (en natif aussi),
|
||
\item
|
||
Microsoft SQLServer grâce aux drivers {[}\ldots\hspace{0pt}à
|
||
compléter{]}
|
||
\item
|
||
Oracle via
|
||
\href{https://oracle.github.io/python-cx_Oracle/}{cx\_Oracle}.
|
||
\end{itemize}
|
||
|
||
Chaque pilote doit être utilisé précautionneusement ! Chaque version de Django n'est pas toujours compatible avec chacune des versions des pilotes, et chaque moteur de base de données nécessite parfois une
|
||
version spécifique du pilote. Par ce fait, vous serez parfois bloqué sur une version de Django, simplement parce que votre serveur de base de données se trouvera dans une version spécifique (eg. Django 2.3 à cause
|
||
d'un Oracle 12.1).
|
||
|
||
Ci-dessous, quelques procédures d'installation pour mettre un serveur à disposition. Les deux plus simples seront MariaDB et PostgreSQL, qu'on couvrira ci-dessous. Oracle et Microsoft SQLServer se trouveront en
|
||
annexes.
|
||
|
||
\subsection{PostgreSQL}
|
||
|
||
On commence par installer PostgreSQL.
|
||
|
||
Dans le cas de debian, on exécute la commande suivante:
|
||
|
||
\begin{verbatim}
|
||
# aptitude install postgresql postgresql-contrib
|
||
\end{verbatim}
|
||
|
||
Ensuite, on crée un utilisateur pour la DB:
|
||
|
||
\begin{verbatim}
|
||
# su - postgres
|
||
postgres@gwift:~$ createuser --interactive -P
|
||
Enter name of role to add: gwift_user
|
||
Enter password for new role:
|
||
Enter it again:
|
||
Shall the new role be a superuser? (y/n) n
|
||
Shall the new role be allowed to create databases? (y/n) n
|
||
Shall the new role be allowed to create more new roles? (y/n) n
|
||
postgres@gwift:~$
|
||
\end{verbatim}
|
||
|
||
Finalement, on peut créer la DB:
|
||
|
||
\begin{verbatim}
|
||
postgres@gwift:~$ createdb --owner gwift_user gwift
|
||
postgres@gwift:~$ exit
|
||
logout
|
||
\end{verbatim}
|
||
|
||
\subsection{MariaDB}
|
||
|
||
Idem, installation, configuration, backup, tout ça. A copier de grimboite, je suis sûr d’avoir
|
||
des notes là-dessus.
|
||
|
||
\section{Environment utilisateur}
|
||
|
||
\begin{verbatim}
|
||
su - gwift
|
||
cp /etc/skel/.bashrc .
|
||
cp /etc/skel/.bash_profile .
|
||
ssh-keygen
|
||
mkdir bin
|
||
mkdir .venvs
|
||
mkdir webapps
|
||
python3.6 -m venv .venvs/gwift
|
||
source .venvs/gwift/bin/activate
|
||
cd /home/gwift/webapps
|
||
git clone ...
|
||
\end{verbatim}
|
||
|
||
La clé SSH doit ensuite être renseignée au niveau du dépôt, afin de pouvoir y accéder.
|
||
A ce stade, on devrait déjà avoir quelque chose de fonctionnel en démarrant les commandes
|
||
suivantes:
|
||
|
||
\begin{verbatim}
|
||
# en tant qu'utilisateur 'gwift'
|
||
source .venvs/gwift/bin/activate
|
||
pip install -U pip
|
||
pip install -r requirements/base.txt
|
||
pip install gunicorn
|
||
cd webapps/gwift
|
||
gunicorn config.wsgi:application --bind localhost:3000 --settings
|
||
=config.settings_production
|
||
\end{verbatim}
|