finish migration to adoc
This commit is contained in:
parent
3b60990c13
commit
8eb38628d0
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
364
source/conf.py
364
source/conf.py
|
|
@ -1,364 +0,0 @@
|
|||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# Gwift documentation build configuration file, created by
|
||||
# sphinx-quickstart on Wed Oct 28 18:48:30 2015.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
# containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import sys
|
||||
import os
|
||||
import shlex
|
||||
|
||||
import sphinx_rtd_theme
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'sphinx.ext.todo',
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
# source_suffix = ['.rst', '.md']
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The encoding of source files.
|
||||
#source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'Gwift'
|
||||
copyright = '2015, Fred & Céd\''
|
||||
author = 'Fred & Céd\''
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = '0.2'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '0.2'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = 'fr'
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
#today = ''
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
#today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = [x for x in os.listdir('.') if os.path.isdir(x)]
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all
|
||||
# documents.
|
||||
#default_role = None
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
#add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
#add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
#show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
#modindex_common_prefix = []
|
||||
|
||||
# If true, keep warnings as "system message" paragraphs in the built documents.
|
||||
#keep_warnings = False
|
||||
|
||||
# If true, `todo` and `todoList` produce output, else they produce nothing.
|
||||
todo_include_todos = True
|
||||
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
html_theme = "sphinx_rtd_theme"
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
#html_title = None
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
#html_short_title = None
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
#html_logo = None
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
#html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# Add any extra paths that contain custom files (such as robots.txt or
|
||||
# .htaccess) here, relative to this directory. These files are copied
|
||||
# directly to the root of the documentation.
|
||||
#html_extra_path = []
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
#html_last_updated_fmt = '%b %d, %Y'
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
#html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
#html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
#html_domain_indices = True
|
||||
|
||||
# If false, no index is generated.
|
||||
#html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
#html_split_index = False
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
#html_show_sourcelink = True
|
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||
#html_show_sphinx = True
|
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||
#html_show_copyright = True
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
#html_use_opensearch = ''
|
||||
|
||||
# This is the file name suffix for HTML files (e.g. ".xhtml").
|
||||
#html_file_suffix = None
|
||||
|
||||
# Language to be used for generating the HTML full-text search index.
|
||||
# Sphinx supports the following languages:
|
||||
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
|
||||
# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
|
||||
#html_search_language = 'en'
|
||||
|
||||
# A dictionary with options for the search language support, empty by default.
|
||||
# Now only 'ja' uses this config value
|
||||
#html_search_options = {'type': 'default'}
|
||||
|
||||
# The name of a javascript file (relative to the configuration directory) that
|
||||
# implements a search results scorer. If empty, the default will be used.
|
||||
#html_search_scorer = 'scorer.js'
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'Gwiftdoc'
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
#'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#'figure_align': 'htbp',
|
||||
'inputenc': '',
|
||||
'utf8extra': '',
|
||||
'preamble': '''
|
||||
\usepackage{fontspec}
|
||||
''',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'Gwift.tex', 'Gwift Documentation',
|
||||
'Fred \\& Céd\'', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
#latex_logo = None
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
#latex_use_parts = False
|
||||
|
||||
# If true, show page references after internal links.
|
||||
#latex_show_pagerefs = False
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
latex_show_urls = "True"
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#latex_domain_indices = True
|
||||
|
||||
|
||||
# -- Options for manual page output ---------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'gwift', 'Gwift Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#man_show_urls = False
|
||||
|
||||
|
||||
# -- Options for Texinfo output -------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'Gwift', 'Gwift Documentation',
|
||||
author, 'Gwift', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#texinfo_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#texinfo_domain_indices = True
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
#texinfo_show_urls = 'footnote'
|
||||
|
||||
# If true, do not generate a @detailmenu in the "Top" node's menu.
|
||||
#texinfo_no_detailmenu = False
|
||||
|
||||
|
||||
# -- Options for Epub output ----------------------------------------------
|
||||
|
||||
# Bibliographic Dublin Core info.
|
||||
epub_title = project
|
||||
epub_author = author
|
||||
epub_publisher = author
|
||||
epub_copyright = copyright
|
||||
|
||||
# The basename for the epub file. It defaults to the project name.
|
||||
#epub_basename = project
|
||||
|
||||
# The HTML theme for the epub output. Since the default themes are not optimized
|
||||
# for small screen space, using the same theme for HTML and epub output is
|
||||
# usually not wise. This defaults to 'epub', a theme designed to save visual
|
||||
# space.
|
||||
#epub_theme = 'epub'
|
||||
|
||||
# The language of the text. It defaults to the language option
|
||||
# or 'en' if the language is not set.
|
||||
#epub_language = ''
|
||||
|
||||
# The scheme of the identifier. Typical schemes are ISBN or URL.
|
||||
#epub_scheme = ''
|
||||
|
||||
# The unique identifier of the text. This can be a ISBN number
|
||||
# or the project homepage.
|
||||
#epub_identifier = ''
|
||||
|
||||
# A unique identification for the text.
|
||||
#epub_uid = ''
|
||||
|
||||
# A tuple containing the cover image and cover page html template filenames.
|
||||
#epub_cover = ()
|
||||
|
||||
# A sequence of (type, uri, title) tuples for the guide element of content.opf.
|
||||
#epub_guide = ()
|
||||
|
||||
# HTML files that should be inserted before the pages created by sphinx.
|
||||
# The format is a list of tuples containing the path and title.
|
||||
#epub_pre_files = []
|
||||
|
||||
# HTML files shat should be inserted after the pages created by sphinx.
|
||||
# The format is a list of tuples containing the path and title.
|
||||
#epub_post_files = []
|
||||
|
||||
# A list of files that should not be packed into the epub file.
|
||||
epub_exclude_files = ['search.html']
|
||||
|
||||
# The depth of the table of contents in toc.ncx.
|
||||
#epub_tocdepth = 3
|
||||
|
||||
# Allow duplicate toc entries.
|
||||
#epub_tocdup = True
|
||||
|
||||
# Choose between 'default' and 'includehidden'.
|
||||
#epub_tocscope = 'default'
|
||||
|
||||
# Fix unsupported image types using the Pillow.
|
||||
#epub_fix_images = False
|
||||
|
||||
# Scale large images.
|
||||
#epub_max_image_width = 0
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
#epub_show_urls = 'inline'
|
||||
|
||||
# If false, no index is generated.
|
||||
#epub_use_index = True
|
||||
|
Before Width: | Height: | Size: 6.4 KiB After Width: | Height: | Size: 6.4 KiB |
|
Before Width: | Height: | Size: 7.4 KiB After Width: | Height: | Size: 7.4 KiB |
|
|
@ -166,6 +166,28 @@ systemctl status supervisord.service
|
|||
ls /var/run/webapps/
|
||||
----
|
||||
|
||||
On peut aussi vérifier que l'application est en train de tourner, à l'aide de la commande `supervisorctl`:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
$$$ supervisorctl status gwift
|
||||
gwift RUNNING pid 31983, uptime 0:01:00
|
||||
----
|
||||
|
||||
Et pour gérer le démarrage ou l'arrêt, on peut passer par les commandes suivantes:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
$$$ supervisorctl stop gwift
|
||||
gwift: stopped
|
||||
root@ks3353535:/etc/supervisor/conf.d# supervisorctl start gwift
|
||||
gwift: started
|
||||
root@ks3353535:/etc/supervisor/conf.d# supervisorctl restart gwift
|
||||
gwift: stopped
|
||||
gwift: started
|
||||
----
|
||||
|
||||
|
||||
=== Ouverture des ports
|
||||
|
||||
[source,text]
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
On l'a déjà vu, Django se base sur un pattern type ActiveRecords pour l'ORM.
|
||||
|
||||
NOTE: à vérifier ;-)
|
||||
|
||||
et supporte les principaux moteurs de bases de données connus: MariaDB (en natif depuis Django 3.0), PostgreSQL au travers de psycopg2 (en natif aussi), Microsoft SQLServer grâce aux drivers [...à compléter] ou Oracle via https://oracle.github.io/python-cx_Oracle/[cx_Oracle].
|
||||
|
||||
WARNING: 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. De 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.
|
||||
|
||||
== PostgreSQL
|
||||
|
||||
On commence par installer PostgreSQL.
|
||||
|
||||
Par exemple, dans le cas de debian, on exécute la commande suivante:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
$$$ aptitude install postgresql postgresql-contrib
|
||||
----
|
||||
|
||||
Ensuite, on crée un utilisateur pour la DB:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
$$$ 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:~$
|
||||
----
|
||||
|
||||
Finalement, on peut créer la DB:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
postgres@gwift:~$ createdb --owner gwift_user gwift
|
||||
postgres@gwift:~$ exit
|
||||
logout
|
||||
$$$
|
||||
----
|
||||
|
||||
NOTE: penser à inclure un bidule pour les backups.
|
||||
|
||||
== MariaDB
|
||||
|
||||
Idem, installation, configuration, backup, tout ça.
|
||||
A copier de grimboite, je suis sûr d'avoir des notes là-dessus.
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
== Un peu de théorie... Les principales étapes
|
||||
|
||||
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.
|
||||
On va déjà parler de déploiement. Le serveur que django met à notre disposition est prévu uniquement pour le développement: inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...). De même, la base de donnée doit supporter plus qu'un seul utilisateur: SQLite fonctionne très bien dès lors qu'on se limite à un seul utilisateur... Sur une application Web, il est plus que probable que vous rencontriez rapidement des erreurs de base de données verrouillée pour écriture par un autre processus. Il est donc plus que bénéfique de passer sur quelque chose de plus solide.
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -17,6 +19,15 @@ Dans cette partie, on abordera les points suivants:
|
|||
|
||||
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, ...
|
||||
|
||||
Pour une mise ne production, le standard *de facto* est le suivant:
|
||||
|
||||
* Nginx comme serveur principal
|
||||
* Gunicorn comme serveur d'application
|
||||
* Supervisorctl pour le monitoring
|
||||
* PostgreSQL comme base de données.
|
||||
|
||||
C'est celle-ci que nous allons décrire ci-dessous.
|
||||
|
||||
=== Configuration et sécurisation de la machine hôte
|
||||
|
||||
Supervisor, nginx, gunicorn, utilisateurs, groupes, ...
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
== Mise à jour de l'application
|
||||
|
||||
Une application sans aucun bug et avec toutes les fonctionnalités présentes du premier coup, on n'a jamais vu (sauf peut-être Chuck Norris?).
|
||||
|
||||
Vous serez amenés (souvent?) à faire des mises à jour de votre application.
|
||||
|
||||
Les étapes à ne surtout pas oublier sont :
|
||||
|
||||
. La récupération des nouvelles sources
|
||||
. La mise à jour du schéma de la base de données
|
||||
. La récupération des (nouveaux) fichiers statiques
|
||||
. Le redémarrage de gunicorn, puisque les processus précédents devraient encore être en train de tourner - si ce n'est pas le cas, vous aurez sûrement mis une page d'erreur avec une licorne en place ;-)
|
||||
|
||||
=== Récupération des sources
|
||||
|
||||
Si vous avez suivi ce guide jusqu'ici, vos sources devraient se trouver dans le répertoire `/webapps/gwift` d'un utilisateur. Suivant la sécurité mise en place, vous aurez deux possibilités:
|
||||
|
||||
. Soit les sources sont toujours liées au dépôt Git/Mercurial/Whatever
|
||||
. Soit, vous devrez télécharger une archive contenant les fichiers.
|
||||
|
||||
Dans le premier cas :
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
cd ~/webapps/gwift
|
||||
git fetch
|
||||
git checkout <version_number>
|
||||
----
|
||||
|
||||
Dans le second cas :
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
wget -O ...
|
||||
unzip / tar xvfz / ...
|
||||
chown gwift:webapps ...
|
||||
----
|
||||
|
||||
Et dans les deux cas:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
source ~/.venvs/gwift/bin/activate
|
||||
python manage.py migrate
|
||||
python manage.py collectstatic
|
||||
supervisorctl reload
|
||||
----
|
||||
|
||||
|
||||
NOTE: j'avais bidouillé un truc avec la documentation de Fabric, mais je pense que je ne l'avais jamais essayé :-)
|
||||
|
||||
[source]
|
||||
----
|
||||
*****************************
|
||||
Automatisation du déploiement
|
||||
*****************************
|
||||
|
||||
Pour automatiser le déploiement, il existe `Fabric <http://www.fabfile.org/>`_.
|
||||
|
||||
* **Problème**: cette librairie n'existe que pour Python2.7.
|
||||
* **Avantage**: on peut écrire du code semblable à `ceci <https://github.com/UrLab/incubator/blob/master/fabfile.py>`_...
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from fabric.api import run, cd
|
||||
from fabric.context_managers import prefix
|
||||
|
||||
|
||||
def deploy():
|
||||
code_dir = '/home/www-data/incubator'
|
||||
with cd(code_dir), prefix('source ve/bin/activate'):
|
||||
run('sudo supervisorctl stop incubator')
|
||||
run("./save_db.sh")
|
||||
run("git pull")
|
||||
run("pip install -r requirements.txt --upgrade -q")
|
||||
run("./manage.py collectstatic --noinput -v 0")
|
||||
run("./manage.py makemigrations")
|
||||
run("./manage.py migrate")
|
||||
run('sudo supervisorctl start incubator')
|
||||
|
||||
En gros:
|
||||
|
||||
1. On se place dans le bon répertoire
|
||||
2. On arrête le superviseur
|
||||
3. On sauve les données de la base de données
|
||||
4. On charge la dernière version depuis le dépôt Git
|
||||
5. On met les dépendances à jour (en mode silencieux)
|
||||
6. On agrège les fichiers statiques
|
||||
7. On lance les migrations
|
||||
8. Et on relance le superviseur.
|
||||
|
||||
Avec un peu de chances, l'instance est à jour.
|
||||
----
|
||||
|
||||
IMPORTANT: y'a quand même un truc un peu foireux, c'est que l'utilisateur ci-dessus doit passer par root (ou sudo) pour redémarrer supervisorctl. C'est un peu moyen. Voir s'il n'y a pas un peu mieux comme méthode.
|
||||
|
|
@ -82,4 +82,4 @@ Une introduction à OAuth est `disponible ici <http://hueniverse.com/oauth/guide
|
|||
L'utilisation de jetons permet notamment de définir une durée d'utilisation et une portée d'utilisation. L'utilisateur d'un service A peut par exemple autoriser un service B à accéder à des ressources qu'il possède, sans pour autant révéler son nom d'utilisateur ou son mot de passe.
|
||||
|
||||
L'exemple repris au niveau du `workflow <http://hueniverse.com/oauth/guide/workflow/>`_ est le suivant : un utilisateur(trice), Jane, a uploadé des photos sur le site faji.com (A). Elle souhaite les imprimer au travers du site beppa.com (B).
|
||||
Au moment de la commande, le site beppa.com envoie une demande au site faji.com pour accéder aux ressources partagées par Jane. Pour cela, une nouvelle page s'ouvre pour l'utilisateur, et lui demande d'introduire sa "pièce d'identité". Le site A, ayant reçu une demande de B, mais certifiée par l'utilisateur, ouvre alors les ressources et lui permet d'y accéder.
|
||||
Au moment de la commande, le site beppa.com envoie une demande au site faji.com pour accéder aux ressources partagées par Jane. Pour cela, une nouvelle page s'ouvre pour l'utilisateur, et lui demande d'introduire sa "pièce d'identité". Le site A, ayant reçu une demande de B, mais certifiée par l'utilisateur, ouvre alors les ressources et lui permet d'y accéder.
|
||||
|
|
@ -1,6 +1,9 @@
|
|||
== Logging
|
||||
|
||||
Si on veut propager les logs entre applications, il faut bien spécifier l'attribut `propagate`, sans quoi on s'arrêtera au module sans prendre en considération les sous-modules.
|
||||
|
||||
```python
|
||||
[source,python]
|
||||
----
|
||||
LOGGING = {
|
||||
'version': 1,
|
||||
'disable_existing_loggers': False,
|
||||
|
|
@ -23,11 +26,12 @@ LOGGING = {
|
|||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
----
|
||||
|
||||
Par exemple:
|
||||
|
||||
```python
|
||||
[source,python]
|
||||
----
|
||||
'loggers': {
|
||||
'mv': { # Parent
|
||||
'handlers': ['file'],
|
||||
|
|
@ -39,14 +43,16 @@ Par exemple:
|
|||
'propagate': True,
|
||||
}
|
||||
},
|
||||
```
|
||||
----
|
||||
|
||||
Et dans le fichier `mv/models.py`, on a ceci:
|
||||
|
||||
```python
|
||||
[source,python]
|
||||
----
|
||||
logger = logging.getLogger(__name__)
|
||||
logger.debug('helloworld');
|
||||
```
|
||||
----
|
||||
|
||||
Le log sera écrit dans la console **ET** dans le fichier.
|
||||
Par contre, si on retire l'attribut `propagate: True` (ou qu'on le change en `propagate: False`), le même code ci-dessus n'écrit que dans la console. Simplement parce que le log associé à un package considère par défaut ses enfants, alors que le log associé à un module pas. [Par exemple](https://docs.djangoproject.com/en/2.1/topics/logging/#examples).
|
||||
|
||||
Par contre, si on retire l'attribut `propagate: True` (ou qu'on le change en `propagate: False`), le même code ci-dessus n'écrit que dans la console. Simplement parce que le log associé à un package considère par défaut ses enfants, alors que le log associé à un module pas. [Par exemple](https://docs.djangoproject.com/en/2.1/topics/logging/#examples).
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
===========
|
||||
Contrôleurs
|
||||
===========
|
||||
== Contrôleurs
|
||||
|
||||
Dans un *pattern* MVC classique, la traduction immédiate du **contrôleur** est une **vue**. Et comme on le verra par la suite, la **vue** est en fait le **template**.
|
||||
Les vues agrègent donc les informations à partir d'un des composants et les font transiter vers un autre. En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
|
||||
|
||||
.. include:: mvc/views.rst
|
||||
.. include:: mvc/templates.rst
|
||||
.. include:: mvc/layout.rst
|
||||
.. include:: mvc/urls.rst
|
||||
include::mvc/views.adoc[]
|
||||
include::mvc/views.templates.adoc[]
|
||||
include::mvc/layout.adoc[]
|
||||
include::mvc/urls.adoc[]
|
||||
|
||||
NOTE: Ne pas oublier de parler des sessions. Mais je ne sais pas si c'est le bon endroit.
|
||||
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
|
@ -1,27 +0,0 @@
|
|||
=====
|
||||
Gwift
|
||||
=====
|
||||
|
||||
Pour commencer, nous allons nous concentrer sur la création d'un site ne contenant qu'une seule application, même si en pratique le site contiendra déjà plusieurs applications fournies pas django, comme nous le verrons plus loin.
|
||||
|
||||
Pour prendre un exemple concret, nous allons créer un site permettant de gérer des listes de souhaits, que nous appellerons ``gwift`` (pour ``GiFTs and WIshlisTs`` :)).
|
||||
|
||||
La première chose à faire est de définir nos besoins du point de vue de l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur puisse faire avec l'application.
|
||||
|
||||
Ensuite, nous pourrons traduire ces besoins en fonctionnalités et finalement effectuer le développement
|
||||
|
||||
.. include:: gwift/00-specs.rst
|
||||
.. include:: gwift/01-models.rst
|
||||
.. include:: gwift/tests.rst
|
||||
|
||||
.. todo:: Ajouter pourquoi on hérite de ``models.Model``, etc.
|
||||
|
||||
.. include:: gwift/key-points.rst
|
||||
|
||||
.. include:: gwift/refactoring.rst
|
||||
|
||||
.. include:: gwift/user-management.rst
|
||||
|
||||
.. include:: gwift/console.rst
|
||||
|
||||
.. include:: gwift/metamodel.rst
|
||||
|
|
@ -52,6 +52,8 @@ include::toolchain/tools.adoc[]
|
|||
|
||||
include::toolchain/external_tools.adoc[]
|
||||
|
||||
include::toolchain/summary.adoc[]
|
||||
|
||||
|
||||
= Déploiement
|
||||
Et sécurisation du serveur.
|
||||
|
|
@ -60,26 +62,56 @@ include::deploy/index.adoc[]
|
|||
|
||||
include::deploy/centos.adoc[]
|
||||
|
||||
include::deploy/database.adoc[]
|
||||
|
||||
= Modélisation
|
||||
|
||||
Dans ce chapitre, on va parler de plusieurs concepts utiles au développement rapide d'une application. On parlera de modélisation, de migrations, d'administration auto-générée.
|
||||
|
||||
include::models/models.adoc[]
|
||||
include::django/models.adoc[]
|
||||
|
||||
include::models/querysets.adoc[]
|
||||
include::django/querysets.adoc[]
|
||||
|
||||
include::models/forms.adoc[]
|
||||
include::django/forms.adoc[]
|
||||
|
||||
include::models/migrations.adoc[]
|
||||
include::django/migrations.adoc[]
|
||||
|
||||
include::models/admin.adoc[]
|
||||
include::django/mvc.adoc[]
|
||||
|
||||
include::django/logging.adoc[]
|
||||
|
||||
include::django/admin.adoc[]
|
||||
|
||||
= Go Live !
|
||||
|
||||
Pour commencer, nous allons nous concentrer sur la création d'un site ne contenant qu'une seule application, même si en pratique le site contiendra déjà plusieurs applications fournies pas django, comme nous le verrons plus loin.
|
||||
|
||||
Pour prendre un exemple concret, nous allons créer un site permettant de gérer des listes de souhaits, que nous appellerons ``gwift`` (pour ``GiFTs and WIshlisTs`` :)).
|
||||
|
||||
La première chose à faire est de définir nos besoins du point de vue de l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur puisse faire avec l'application.
|
||||
|
||||
Ensuite, nous pourrons traduire ces besoins en fonctionnalités et finalement effectuer le développement
|
||||
|
||||
include::gwift/specs.adoc[]
|
||||
|
||||
include::gwift/models.adoc[]
|
||||
|
||||
include::gwift/tests.adoc[]
|
||||
|
||||
include::gwift/key-points.adoc[]
|
||||
|
||||
include::gwift/refactoring.adoc[]
|
||||
|
||||
include::gwift/user-management.adoc[]
|
||||
|
||||
include::gwift/console.adoc[]
|
||||
|
||||
include::gwift/metamodel.adoc[]
|
||||
|
||||
== Supervision des logs
|
||||
|
||||
== feedbacks utilisateurs
|
||||
|
||||
== feedbacks utilisateurs
|
||||
|
||||
|
||||
= En bonus
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,32 +0,0 @@
|
|||
******************
|
||||
Mise en production
|
||||
******************
|
||||
|
||||
Le serveur que django met à notre disposition est prévu uniquement pour le développement: inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...). De même, la base de donnée doit supporter plus qu'un seul utilisateur: SQLite fonctionne très bien dès lors qu'on se limite à un seul utilisateur... Sur une application Web, il est plus que probable que vous rencontriez rapidement des erreurs de base de données verrouillée pour écriture par un autre processus. Il est donc plus que bénéfique de passer sur quelque chose de plus solide.
|
||||
|
||||
Pour une mise ne production, le standard *de facto* est le suivant:
|
||||
|
||||
* Nginx comme serveur principal
|
||||
* Gunicorn comme serveur d'application
|
||||
* Supervisorctl pour le monitoring
|
||||
* PostgreSQL comme base de données.
|
||||
|
||||
C'est celle-ci que nous allons décrire ci-dessous.
|
||||
|
||||
Il est évidemment possible de configurer des connecteurs vers d'autres bases de données (Oracle, MSSQL ou MySQL), mais il ne nous est pas possible de décrire tous les cas d'utilisation. Nous allons nous limiter au
|
||||
|
||||
Les points suivants décrivent les étapes nécessaires à la mise en place de ces outils.
|
||||
|
||||
***Remarque***: dans ce qui suit, les commandes exécutées en root seront précédées de $$$.
|
||||
|
||||
Voir http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
|
||||
Et http://tutos.readthedocs.org/en/latest/source/ndg.html
|
||||
|
||||
Ne pas oublier la génération des fichiers statiques !
|
||||
|
||||
.. include:: production/postgresql.rst
|
||||
.. include:: production/environment.rst
|
||||
.. include:: production/gunicorn.rst
|
||||
.. include:: production/monitoring.rst
|
||||
.. include:: production/nginx.rst
|
||||
.. include:: production/fabric.rst
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
*****************************
|
||||
Automatisation du déploiement
|
||||
*****************************
|
||||
|
||||
Pour automatiser le déploiement, il existe `Fabric <http://www.fabfile.org/>`_.
|
||||
|
||||
* **Problème**: cette librairie n'existe que pour Python2.7.
|
||||
* **Avantage**: on peut écrire du code semblable à `ceci <https://github.com/UrLab/incubator/blob/master/fabfile.py>`_...
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from fabric.api import run, cd
|
||||
from fabric.context_managers import prefix
|
||||
|
||||
|
||||
def deploy():
|
||||
code_dir = '/home/www-data/incubator'
|
||||
with cd(code_dir), prefix('source ve/bin/activate'):
|
||||
run('sudo supervisorctl stop incubator')
|
||||
run("./save_db.sh")
|
||||
run("git pull")
|
||||
run("pip install -r requirements.txt --upgrade -q")
|
||||
run("./manage.py collectstatic --noinput -v 0")
|
||||
run("./manage.py makemigrations")
|
||||
run("./manage.py migrate")
|
||||
run('sudo supervisorctl start incubator')
|
||||
|
||||
En gros:
|
||||
|
||||
1. On se place dans le bon répertoire
|
||||
2. On arrête le superviseur
|
||||
3. On sauve les données de la base de données
|
||||
4. On charge la dernière version depuis le dépôt Git
|
||||
5. On met les dépendances à jour (en mode silencieux)
|
||||
6. On agrège les fichiers statiques
|
||||
7. On lance les migrations
|
||||
8. Et on relance le superviseur.
|
||||
|
||||
Avec un peu de chances, l'instance est à jour.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
**********
|
||||
Monitoring
|
||||
**********
|
||||
|
||||
Pour lancer et surveiller gunicorn, nous allons utiliser supervisord, qui est un démon sous lunix permettant de lancer d'autre programmes.
|
||||
|
||||
On commence par l'installer:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ aptitude install supervisor
|
||||
|
||||
On crée ensuite une fichier de configuration, ``/etc/supervisor/conf.d/gwift.conf``, qui sera lu au démarage de supervisord.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
[program:gwift]
|
||||
command = /webapps/gwift/gwift/bin/gunicorn_start ; Command to start
|
||||
user = gwift ; User to run as
|
||||
stdout_logfile = /webapps/gwift/gwift/logs/gunicorn_supervisor.log ; Where to write log messages
|
||||
environment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8 ; Set UTF-8 as default encoding
|
||||
autostart=true ; Start the program when supervisord is starting
|
||||
autorestart=unexpected ; Restart program if it exited anormaly
|
||||
redirect_stdout=true ; Redirect program output to the log file
|
||||
redirect_stderr=true ; Redirect program error to the log file
|
||||
|
||||
On peut alors démarer supervisord:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ service supervisor start
|
||||
|
||||
On peut vérifier que notre site est bien en train de tourner, à l'aide de la commande ``supervisorctl``:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ supervisorctl status gwift
|
||||
gwift RUNNING pid 31983, uptime 0:01:00
|
||||
|
||||
Pour gérer le démarage ou l'arrêt de notre application, nous pouvons effectuer les commandes suivantes:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ supervisorctl stop gwift
|
||||
gwift: stopped
|
||||
root@ks3353535:/etc/supervisor/conf.d# supervisorctl start gwift
|
||||
gwift: started
|
||||
root@ks3353535:/etc/supervisor/conf.d# supervisorctl restart gwift
|
||||
gwift: stopped
|
||||
gwift: started
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
|
||||
**********
|
||||
PostgreSQL
|
||||
**********
|
||||
|
||||
On commence par installer PostgreSQL.
|
||||
|
||||
Par exemple, dans le cas de debian, on exécute la commande suivante:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ aptitude install postgresql postgresql-contrib
|
||||
|
||||
Ensuite, on crée un utilisateur pour la DB:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$$$ 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:~$
|
||||
|
||||
Finalement, on peut créer la DB:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
postgres@gwift:~$ createdb --owner gwift_user gwift
|
||||
postgres@gwift:~$ exit
|
||||
logout
|
||||
$$$
|
||||
|
|
@ -1,6 +1,4 @@
|
|||
******
|
||||
Résumé
|
||||
******
|
||||
== En résumé
|
||||
|
||||
En résumé, la création d'un **nouveau** projet Django demande plus ou moins toujours les mêmes actions:
|
||||
|
||||
|
|
@ -9,9 +7,8 @@ En résumé, la création d'un **nouveau** projet Django demande plus ou moins t
|
|||
2. Configurer le fichier ``settings.py``
|
||||
|
||||
|
||||
Cookie-cutter
|
||||
=============
|
||||
. Cookie-cutter
|
||||
|
||||
C'est ici que le projet `Cookie-Cutter <http://cookiecutter.readthedocs.io/en/latest/readme.html>`_ va être intéressant: les X premières étapes peuvent être *bypassées* par une simple commande.
|
||||
|
||||
* `Cookiecutter-Django <http://cookiecutter-django.readthedocs.io/en/latest/project-generation-options.html>`_
|
||||
* `Cookiecutter-Django <http://cookiecutter-django.readthedocs.io/en/latest/project-generation-options.html>`_
|
||||
Loading…
Reference in New Issue