PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Déploiement de Django + Python 3 + PostgreSQL sur AWS Elastic Beanstalk

Ce qui suit est une procédure pas à pas pour configurer et déployer une application Django, optimisée par Python 3, et PostgreSQL sur Amazon Web Services (AWS) tout en restant sain d'esprit.

Outils/technologies utilisées :

  1. Python v3.4.3
  2. Django v1.9
  3. Amazon Elastic Beanstalk, EC2, S3 et RDS
  4. EB CLI 3.x
  5. PostgreSQL

Bonus gratuit : Cliquez ici pour accéder à un guide gratuit des ressources d'apprentissage Django (PDF) qui vous montre des trucs et astuces ainsi que les pièges courants à éviter lors de la création d'applications Web Python + Django.

Découvrez Python 2 version de cet article ici.

Mise à jour le 21/08/2016 : Mise à jour des paramètres de configuration globale EB.


Haricot magique contre EC2

Elastic Beanstalk est une plate-forme en tant que service (PaaS) qui rationalise la configuration, le déploiement et la maintenance de votre application sur Amazon AWS. C'est un service géré, couplant le serveur (EC2), la base de données (RDS) et vos fichiers statiques (S3). Vous pouvez rapidement déployer et gérer votre application, qui s'adapte automatiquement à la croissance de votre site. Consultez la documentation officielle pour plus d'informations.



Mise en route

Nous utiliserons une simple application "Image du jour", que vous pouvez récupérer à partir de ce référentiel :

$ git clone https://github.com/realpython/image-of-the-day.git
$ cd image-of-the-day/
$ git checkout tags/start_here_py3

Après avoir téléchargé le code, créez un virtualenv et installez les exigences via pip :

$ pip install -r requirements.txt

Ensuite, avec PostgreSQL exécuté localement, configurez une nouvelle base de données nommée iotd . De plus, selon votre configuration Postgres locale, vous devrez peut-être mettre à jour les DATABASES configuration dans settings.py . Par exemple, j'ai mis à jour la configuration :

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'iotd',
        'USER': '',
        'PASSWORD': '',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

Vous pouvez maintenant configurer le schéma de la base de données, créer un superutilisateur et exécuter l'application :

$ python manage.py migrate
$ python manage.py createsuperuser
$ python manage.py runserver

Accédez à la page d'administration de votre navigateur à l'adresse http://localhost:8000/admin et ajoutez une nouvelle image, qui sera ensuite affichée sur la page principale.

L'application n'est pas censée être très excitante; nous l'utilisons uniquement à des fins de démonstration. Tout ce qu'il fait est de vous permettre de télécharger une image via l'interface d'administration et d'afficher cette image en plein écran sur la page principale. Cela dit, bien qu'il s'agisse d'une application relativement basique, elle nous permettra tout de même d'explorer un certain nombre de "pièges" qui existent lors du déploiement sur Amazon Beanstalk et RDS.

Maintenant que le site est opérationnel sur notre machine locale, commençons le processus de déploiement Amazon.



CLI pour AWS Elastic Beanstalk

Pour travailler avec un Amazon Elastic Beanstalk, nous pouvons utiliser un package appelé awsebcli. Au moment d'écrire ces lignes, la dernière version de est 3.7.4 et la méthode recommandée pour l'installer est avec pip :

$ pip install awsebcli

Testez maintenant l'installation pour vous assurer qu'elle fonctionne :

$ eb --version

Cela devrait vous donner un joli numéro de version 3.x :

EB CLI 3.7.4 (Python 3.4.3)

Pour commencer à utiliser Elastic Beanstalk, vous aurez besoin d'un compte avec AWS (surprise !). Inscrivez-vous (ou connectez-vous).



Configurer EB - Initialiser votre application

Avec le fonctionnement de l'interface de ligne de commande AWS Elastic Beanstalk, la première chose que nous voulons faire est de créer un environnement Beanstalk pour héberger l'application. Exécutez ceci depuis le répertoire du projet ("image-of-the-day") :

$ eb init

Cela vous posera un certain nombre de questions pour vous aider à configurer votre environnement.

Région par défaut

Le choix de la région la plus proche de vos utilisateurs finaux fournira généralement les meilleures performances. Consultez cette carte si vous ne savez pas laquelle choisir.

Identifiants

Ensuite, il vous demandera vos informations d'identification AWS.

Ici, vous souhaiterez très probablement configurer un utilisateur IAM. Consultez ce guide pour savoir comment en configurer un. Si vous configurez un nouvel utilisateur, vous devrez vous assurer que l'utilisateur dispose des autorisations appropriées. La façon la plus simple de le faire est d'ajouter simplement « Accès administrateur » à l'utilisateur. (Ce n'est probablement pas un bon choix pour des raisons de sécurité, cependant.) Pour les stratégies/rôles spécifiques dont un utilisateur a besoin pour créer/gérer une application Elastic Beanstalk, consultez le lien ici.

Nom de l'application

Ce sera par défaut le nom du répertoire. Faites comme ça.

Version Python

Ensuite, la CLI devrait automatiquement détecter que vous utilisez Python et demander simplement une confirmation. Dis oui. Ensuite, vous devez sélectionner une version de plate-forme. Vous avez ici 2 options différentes pour Python 3 :

  • Python 3.4
  • Python 3.4 (préconfiguré - Docker)

Si vous êtes un hipster, choisissez le choix "Préconfiguré - Docker", sinon optez pour le "Python 3.4" normal. Non, seulement des taquineries ; la différence fondamentale est la suivante :


Python 3.4

Cela vous donne une image EC2 exécutant Amazon Linux 64 bits avec Python 3.4 préinstallé. Le serveur Web frontal est apache, avec mod_wsgi installé. C'est la manière "standard" ou "traditionnelle" du fonctionnement de Beanstalk. En d'autres termes, avec cette option Beanstalk créera des images EC2 pour vous, et vous pourrez utiliser l'ebextension fichiers dont nous parlerons plus tard pour personnaliser l'image EC2.



Python 3.4 (Préconfiguré – Docker)

Cela vous donne une image EC2 exécutant Docker, avec une image Docker déjà configurée pour vous. L'image Docker exécute Debian Jessie 64 bits avec Python 3.4, nginx 1.8 et uWSGI 2.0.8. Étant donné que vous interagissez directement avec l'image Docker, si vous choisissez cette route, vous utiliserez des techniques de configuration Docker standard (c'est-à-dire un "Dockerfile"), et vous n'aurez pas à faire grand-chose qui est spécifique à AWS Beanstalk, comme Beanstalk sait comment gérer l'image Docker pour vous.

Pour cet article, nous nous concentrerons sur la manière "standard" ou "traditionnelle" d'utiliser une image EC2, alors choisissez l'option "Python 3.4" et passons à autre chose.

SSH

Dites oui à la configuration de SSH pour vos instances.

Paire de clés RSA

Ensuite, vous devez générer une paire de clés RSA, qui sera ajoutée à votre ~/.ssh dossier. Cette paire de clés sera également téléchargée sur la clé publique EC2 pour la région que vous avez spécifiée à la première étape. Cela vous permettra de vous connecter en SSH à votre instance EC2 plus tard dans ce didacticiel.



Qu'avons-nous accompli ?

Une fois eb init est terminé, vous verrez un nouveau dossier caché appelé .elasticbeanstalk dans votre répertoire de projet :

├── .elasticbeanstalk
│   └── config.yml
├── .gitignore
├── README.md
├── iotd
│   ├── images
│   │   ├── __init__.py
│   │   ├── admin.py
│   │   ├── migrations
│   │   │   ├── 0001_initial.py
│   │   │   └── __init__.py
│   │   ├── models.py
│   │   ├── tests.py
│   │   └── views.py
│   ├── iotd
│   │   ├── __init__.py
│   │   ├── settings.py
│   │   ├── urls.py
│   │   └── wsgi.py
│   ├── manage.py
│   ├── static
│   │   ├── css
│   │   │   └── bootstrap.min.css
│   │   └── js
│   │       ├── bootstrap.min.js
│   │       └── jquery-1.11.0.min.js
│   └── templates
│       ├── base.html
│       └── images
│           └── home.html
├── requirements.txt
└── www
    └── media
        └── sitelogo.png

Dans ce répertoire se trouve un config.yml file, qui est un fichier de configuration utilisé pour définir certains paramètres pour votre nouvelle application Beanstalk.

À ce stade, si vous tapez eb console il ouvrira votre navigateur par défaut et accédera à la console Elastic Beanstalk. Sur la page, vous devriez voir une application (appelée image-of-the-day si vous suivez exactement), mais pas d'environnements.

Une application représente votre application de code et est ce que eb init créé pour nous. Avec Elastic Beanstalk, une application peut avoir plusieurs environnements (c'est-à-dire développement, test, préproduction, production). C'est à vous de décider comment vous souhaitez configurer/gérer ces environnements. Pour les applications Django simples, j'aime avoir l'environnement de développement sur mon ordinateur portable, puis créer un environnement de test et de production sur Beanstalk.

Mettons en place un environnement de test…




Configurer EB – Créer un environnement

Revenons au terminal, dans le répertoire de votre projet, tapez :

$ eb create

Tout comme eb init , cette commande vous posera une série de questions.

Nom de l'environnement

Vous devez utiliser une convention de dénomination similaire à celle suggérée par Amazon - par exemple, application_name-env_name - en particulier lorsque/si vous commencez à héberger plusieurs applications avec AWS. J'ai utilisé - iod-test .

Préfixe DNS CNAME

Lorsque vous déployez une application sur Elastic Beanstalk, vous obtenez automatiquement un nom de domaine tel que xxx.elasticbeanstalk.com. DNS CNAME prefix est ce que vous voulez utiliser à la place de xxx . La valeur par défaut ne fonctionnera probablement pas si vous suivez parce que quelqu'un d'autre l'a déjà utilisée (les noms sont globaux pour AWS), alors choisissez quelque chose d'unique et continuez.


Que se passe-t-il maintenant ?

À ce stade eb créera réellement votre environnement pour vous. Soyez patient car cela peut prendre un certain temps.

Si vous obtenez une erreur lors de la création de l'environnement, comme - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - vérifiez que les informations d'identification que vous utilisez disposent des autorisations appropriées pour créer l'environnement Beanstalk, comme indiqué précédemment dans cet article.

En outre, il peut vous demander un message sur Platform requires a service role . Si c'est le cas, dites simplement oui et laissez-le créer le rôle pour vous.

Immédiatement après la création de l'environnement, eb tentera de déployer votre application, en copiant tout le code de votre répertoire de projet dans la nouvelle instance EC2, en exécutant pip install -r requirements.txt dans le processus.

Vous devriez voir un tas d'informations sur l'environnement en cours de configuration s'afficher sur votre écran, ainsi que des informations sur eb essayant de se déployer. Vous verrez également quelques erreurs. En particulier, vous devriez voir ces lignes enfouies quelque part dans la sortie :

ERROR: Your requirements.txt is invalid. Snapshot your logs for details.

Ne vous inquiétez pas - ce n'est pas vraiment invalide. Consultez les journaux pour plus de détails :

$ eb logs

Cela récupérera tous les fichiers journaux récents de l'instance EC2 et les sortira sur votre terminal. C'est beaucoup d'informations, vous pouvez donc rediriger la sortie vers un fichier (eb logs -z ). En parcourant les journaux, vous verrez un fichier journal nommé eb-activity.log :

Error: pg_config executable not found.

Le problème est que nous avons essayé d'installer psycopy2 (les liaisons Postgres Python), mais nous avons également besoin que les pilotes du client Postgres soient installés. Comme ils ne sont pas installés par défaut, nous devons d'abord les installer. Réparons ça…




Personnalisation du processus de déploiement

eb lira le .config personnalisé fichiers à partir d'un dossier appelé ".ebextensions" à la racine de votre projet (répertoire "image du jour"). Ces .config vous permettent d'installer des packages, d'exécuter des commandes arbitraires et/ou de définir des variables d'environnement. Les fichiers du répertoire ".ebextensions" doivent être conformes soit à JSON ou YAML syntaxe et sont exécutés dans l'ordre alphabétique.


Installer des packages

La première chose que nous devons faire est d'installer des packages afin que notre pip install commande se terminera avec succès. Pour ce faire, créons d'abord un fichier nommé .ebextensions/01_packages.config :

packages:
  yum:
    git: []
    postgresql93-devel: []
    libjpeg-turbo-devel: []

Les instances EC2 exécutent Amazon Linux, qui est une version Redhat, nous pouvons donc utiliser yum pour installer les packages dont nous avons besoin. Pour l'instant, nous allons simplement installer trois packages :git, le client Postgres, et libjpeg pour Pillow.

Après avoir créé ce fichier pour redéployer l'application, nous devons procéder comme suit :

$ git add .ebextensions/
$ git commit -m "added eb package configuration"

Nous devons valider les modifications car la commande de déploiement eb deploy fonctionne à partir du dernier commit, et ne sera donc au courant de nos modifications de fichiers qu'après les avoir validées sur git. (Notez cependant que nous n'avons pas à pousser ; nous travaillons à partir de notre copie locale...)

Comme vous l'avez probablement deviné, la commande suivante est :

$ eb deploy

Vous ne devriez plus voir qu'une seule erreur :

INFO: Environment update is starting.
INFO: Deploying new version to instance(s).
ERROR: Your WSGIPath refers to a file that does not exist.
INFO: New application version was deployed to running EC2 instances.
INFO: Environment update completed successfully.

Découvrons ce qui se passe…



Configuration de notre environnement Python

Les instances EC2 dans Beanstalk exécutent Apache, et Apache trouvera notre application Python en fonction du WSGIPATH que nous avons défini. Par défaut eb suppose que notre fichier wsgi s'appelle application.py . Il y a deux façons de corriger cela-

Option 1 :Utiliser des paramètres de configuration spécifiques à l'environnement 

$ eb config

Cette commande ouvrira votre éditeur par défaut, en modifiant un fichier de configuration appelé .elasticbeanstalk/iod-test.env.yml . Ce fichier n'existe pas réellement localement ; eb l'a retiré des serveurs AWS et vous l'a présenté afin que vous puissiez y modifier les paramètres. Si vous apportez des modifications à ce pseudo-fichier, puis enregistrez et quittez, eb mettra à jour les paramètres correspondants dans votre environnement Beanstalk.

Si vous recherchez les termes "WSGI" dans le fichier, vous devriez trouver une section de configuration qui ressemble à ceci :

aws:elasticbeanstalk:container:python:
  NumProcesses: '1'
  NumThreads: '15'
  StaticFiles: /static/=static/
  WSGIPath: application.py

Mettez à jour le WSGIPath :

 aws:elasticbeanstalk:container:python:
   NumProcesses: '1'
   NumThreads: '15'
   StaticFiles: /static/=static/
   WSGIPath: iotd/iotd/wsgi.py

Et ensuite, vous aurez correctement configuré WSGIPath. Si vous enregistrez ensuite le fichier et quittez, eb mettra automatiquement à jour la configuration de l'environnement :

Printing Status:
INFO: Environment update is starting.
INFO: Updating environment iod-test's configuration settings.
INFO: Successfully deployed new configuration to environment.
INFO: Environment update completed successfully.

L'avantage d'utiliser la eb config méthode pour modifier les paramètres est que vous pouvez spécifier différents paramètres par environnement. Mais vous pouvez également mettre à jour les paramètres en utilisant le même .config fichiers que nous utilisions auparavant. Cela utilisera les mêmes paramètres pour chaque environnement, comme le .config les fichiers seront appliqués lors du déploiement (après les paramètres de eb config ont été appliqués).

Option 2 :Utiliser les paramètres de configuration globaux

Pour utiliser le .config file, créons un nouveau fichier appelé /.ebextensions/02_python.config :

option_settings:
  "aws:elasticbeanstalk:application:environment":
    DJANGO_SETTINGS_MODULE: "iotd.settings"
    "PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH"
  "aws:elasticbeanstalk:container:python":
    WSGIPath: iotd/iotd/wsgi.py
    NumProcesses: 3
    NumThreads: 20
  "aws:elasticbeanstalk:container:python:staticfiles":
    "/static/": "www/static/"

Que se passe-t-il ?

  • DJANGO_SETTINGS_MODULE: "iotd.settings" - ajoute le chemin d'accès au module de paramètres.
  • "PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH" - met à jour notre PYTHONPATH afin que Python puisse trouver les modules dans notre application. Ce chemin peut varier en fonction de votre configuration ! Voir ce commentaire pour plus de détails. (Notez que l'utilisation du chemin complet est nécessaire.)
  • WSGIPath: iotd/iotd/wsgi.py définit notre chemin WSGI.
  • NumProcesses: 3 et NumThreads: 20 - met à jour le nombre de processus et de threads utilisés pour exécuter notre application WSGI.
  • "/static/": "www/static/" définit le chemin de nos fichiers statiques.

Encore une fois, nous pouvons faire un git commit puis un eb deploy pour mettre à jour ces paramètres.

Ajoutons ensuite une base de données.




Configuration d'une base de données

Essayez d'afficher le site Web déployé :

$ eb open

Cette commande affichera l'application déployée dans votre navigateur par défaut. Vous devriez voir une erreur de connexion refusée :

OperationalError at /
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

C'est parce que nous n'avons pas encore créé de base de données. À ce stade eb configurera votre environnement Beanstalk, mais il ne configurera pas RDS (le niveau base de données). Nous devons le configurer manuellement.


Configuration de la base de données

Encore une fois, utilisez eb console pour ouvrir la page de configuration de Beanstalk.

À partir de là, procédez comme suit :

  1. Cliquez sur le lien "Configuration".
  2. Faites défiler jusqu'en bas de la page, puis sous la section "Niveau de données", cliquez sur le lien "Créer une nouvelle base de données RDS".
  3. Sur la page de configuration RDS, remplacez "DB Engine" par "postgres".
  4. Ajoutez un "Nom d'utilisateur principal" et un "Mot de passe principal".
  5. Enregistrez les modifications.

Beanstalk créera le RDS pour vous. Maintenant, nous devons obtenir notre application Django pour se connecter au RDS. Beanstalk nous aidera ici en nous exposant un certain nombre de variables d'environnement sur les instances EC2 qui détaillent comment se connecter au serveur Postgres. Donc, tout ce que nous avons à faire est de mettre à jour notre settings.py fichier pour tirer parti de ces variables d'environnement. Confirmez que les DATABASES le paramètre de configuration reflète ce qui suit dans settings.py :

if 'RDS_DB_NAME' in os.environ:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.postgresql_psycopg2',
            'NAME': os.environ['RDS_DB_NAME'],
            'USER': os.environ['RDS_USERNAME'],
            'PASSWORD': os.environ['RDS_PASSWORD'],
            'HOST': os.environ['RDS_HOSTNAME'],
            'PORT': os.environ['RDS_PORT'],
        }
    }
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.postgresql_psycopg2',
            'NAME': 'iotd',
            'USER': 'iotd',
            'PASSWORD': 'iotd',
            'HOST': 'localhost',
            'PORT': '5432',
        }
    }

Cela dit simplement, "utilisez les paramètres de variable d'environnement s'ils sont présents, sinon utilisez nos paramètres de développement par défaut". Simple.



Gestion des migrations de bases de données

Avec la configuration de notre base de données, nous devons toujours nous assurer que les migrations s'exécutent de manière à ce que la structure de la table de la base de données soit correcte. Nous pouvons le faire en modifiant .ebextensions/02_python.config et en ajoutant les lignes suivantes en haut du fichier :

container_commands:
  01_migrate:
    command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py migrate --noinput"
    leader_only: true

container_commands vous permettent d'exécuter des commandes arbitraires après le déploiement de l'application sur l'instance EC2. Étant donné que l'instance EC2 est configurée à l'aide d'un environnement virtuel, nous devons d'abord activer cet environnement virtuel avant d'exécuter notre commande migrate. Aussi le leader_only: true signifie "n'exécutez cette commande que sur la première instance lors du déploiement sur plusieurs instances".

N'oubliez pas que notre application utilise l'admin de Django, nous allons donc avoir besoin d'un super-utilisateur…



Créer l'utilisateur administrateur

Malheureusement createsuperuser ne vous permet pas de spécifier un mot de passe lorsque vous utilisez le --noinput option, nous devrons donc écrire notre propre commande. Heureusement, Django facilite la création de commandes personnalisées.

Créez le fichier iotd/images/management/commands/createsu.py :

from django.core.management.base import BaseCommand
from django.contrib.auth.models import User


class Command(BaseCommand):

    def handle(self, *args, **options):
        if not User.objects.filter(username="admin").exists():
            User.objects.create_superuser("admin", "[email protected]", "admin")

Assurez-vous d'ajouter le __init__.py approprié fichiers également :

└─ management
    ├── __init__.py
    └── commands
        ├── __init__.py
        └── createsu.py

Ce fichier vous permettra d'exécuter python manage.py createsu , et il créera un superutilisateur sans demander de mot de passe. N'hésitez pas à développer la commande pour utiliser des variables d'environnement ou un autre moyen vous permettant de changer le mot de passe.

Une fois que vous avez créé la commande, nous pouvons simplement ajouter une autre commande à nos container_commands section dans .ebextensions/02_python.config :

02_createsu:
  command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py createsu"
  leader_only: true

Avant de tester cela, assurons-nous que nos fichiers statiques sont tous placés au bon endroit…




Fichiers statiques

Ajoutez une autre commande sous container_commands :

03_collectstatic:
  command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py collectstatic --noinput"

Ainsi, le fichier entier ressemble à ceci :

container_commands:
  01_migrate:
    command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py migrate --noinput"
    leader_only: true
  02_createsu:
    command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py createsu"
    leader_only: true
  03_collectstatic:
    command: "source /opt/python/run/venv/bin/activate && python iotd/manage.py collectstatic --noinput"

option_settings:
  "aws:elasticbeanstalk:application:environment":
    DJANGO_SETTINGS_MODULE: "iotd.settings"
    "PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH"
    "ALLOWED_HOSTS": ".elasticbeanstalk.com"
  "aws:elasticbeanstalk:container:python":
    WSGIPath: iotd/iotd/wsgi.py
    NumProcesses: 3
    NumThreads: 20
  "aws:elasticbeanstalk:container:python:staticfiles":
    "/static/": "www/static/"

Nous devons maintenant nous assurer que le STATIC_ROOT est correctement défini dans settings.py fichier :

STATIC_ROOT = os.path.join(BASE_DIR, "..", "www", "static")
STATIC_URL = '/static/'

Assurez-vous de valider le www répertoire à git afin que le répertoire statique puisse être créé. Ensuite, exécutez eb deploy à nouveau, et vous devriez maintenant être en affaires :

INFO: Environment update is starting.
INFO: Deploying new version to instance(s).
INFO: New application version was deployed to running EC2 instances.
INFO: Environment update completed successfully.

À ce stade, vous devriez pouvoir accéder à http://your_app_url/admin, vous connecter, ajouter une image, puis voir cette image s'afficher sur la page principale de votre application.

Succès !



Utilisation de S3 pour le stockage multimédia

Avec cette configuration, chaque fois que nous déployons à nouveau, nous perdrons toutes nos images téléchargées. Pourquoi? Eh bien, lorsque vous exécutez eb deploy , une nouvelle instance est lancée pour vous. Ce n'est pas ce que nous voulons puisque nous aurons alors des entrées dans la base de données pour les images, mais pas d'images associées. La solution consiste à stocker les fichiers multimédias dans Amazon Simple Storage Service (Amazon S3) plutôt que sur l'instance EC2 elle-même.

Vous devrez :

  1. Créer un compartiment
  2. Récupérer l'ARN (Amazon Resource Name) de votre utilisateur
  3. Ajouter des autorisations de compartiment
  4. Configurez votre application Django pour utiliser S3 pour servir vos fichiers statiques

Puisqu'il existe déjà de bons articles à ce sujet, je vais simplement vous indiquer mon préféré :Utiliser Amazon S3 pour stocker vos fichiers Django statiques et multimédia



Configuration Apache

Puisque nous utilisons Apache avec Beanstalk, nous souhaitons probablement configurer Apache pour (entre autres) activer la compression gzip afin que les fichiers soient téléchargés plus rapidement par les clients. Cela peut être fait avec container_commands . Créez un nouveau fichier .ebextensions/03_apache.config et ajoutez ce qui suit :

container_commands:
  01_setup_apache:
    command: "cp .ebextensions/enable_mod_deflate.conf /etc/httpd/conf.d/enable_mod_deflate.conf"

Ensuite, vous devez créer le fichier .ebextensions/enable_mod_deflate.conf :

# mod_deflate configuration
<IfModule mod_deflate.c>
  # Restrict compression to these MIME types
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE text/xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE application/xml+rss
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/css
  # Level of compression (Highest 9 - Lowest 1)
  DeflateCompressionLevel 9
  # Netscape 4.x has some problems.
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  # Netscape 4.06-4.08 have some more problems
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  # MSIE masquerades as Netscape, but it is fine
  BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
<IfModule mod_headers.c>
  # Make sure proxies don't deliver the wrong content
  Header append Vary User-Agent env=!dont-vary
</IfModule>
</IfModule>

Cela activera la compression gzip, ce qui devrait aider avec la taille des fichiers que vous téléchargez. Vous pouvez également utiliser la même stratégie pour minifier et combiner automatiquement votre CSS/JS et effectuer tout autre prétraitement dont vous avez besoin.



Dépannage

N'oubliez pas le très utile eb ssh commande, qui vous amènera dans l'instance EC2 afin que vous puissiez fouiller et voir ce qui se passe. Lors du dépannage, vous devez connaître quelques répertoires :

  • /opt/python  :Racine de l'endroit où votre application se retrouvera.
  • /opt/python/current/app  :L'application actuelle qui est hébergée dans l'environnement.
  • /opt/python/on-deck/app  :L'application est initialement placée sur le pont, puis, une fois le déploiement terminé, elle sera déplacée vers current . Si vous obtenez des échecs dans vos container_commands , consultez le on-deck dossier et non le current dossier.
  • /opt/python/current/env :Toutes les variables d'environnement que eb mettra en place pour vous. Si vous essayez de reproduire une erreur, vous devrez peut-être d'abord source /opt/python/current/env pour que les choses soient configurées comme elles le seraient lorsque eb deploy est en cours d'exécution.
  • opt/python/run/venv :L'environnement virtuel utilisé par votre application ; vous devrez également exécuter source /opt/python/run/venv/bin/activate si vous essayez de reproduire une erreur.


Conclusion

Le déploiement sur Elastic Beanstalk peut être un peu intimidant au début, mais une fois que vous comprenez où se trouvent toutes les parties et comment les choses fonctionnent, c'est en fait assez facile et extrêmement flexible. Il vous offre également un environnement qui évolue automatiquement à mesure que votre utilisation augmente. J'espère que maintenant vous en avez assez pour être dangereux ! Bonne chance pour votre prochain déploiement de Beanstalk.

Bonus gratuit : Cliquez ici pour accéder à un guide gratuit des ressources d'apprentissage Django (PDF) qui vous montre des trucs et astuces ainsi que les pièges courants à éviter lors de la création d'applications Web Python + Django.

Avons-nous raté quelque chose ? Avez-vous d'autres trucs ou astuces? Veuillez commenter ci-dessous.