Eladio  Rau

Eladio Rau

1660058040

Déploiement D'une Application Django Sur AWS Elastic Beanstalk

Dans ce didacticiel, nous allons parcourir le processus de déploiement d'une application Django prête pour la production sur AWS Elastic Beanstalk.

Objectifs

À la fin de ce didacticiel, vous serez en mesure de :

  1. Expliquer ce qu'est Elastic Beanstalk
  2. Initialiser et configurer Elastic Beanstalk
  3. Dépanner une application exécutée sur Elastic Beanstalk
  4. Intégrer Elastic Beanstalk à RDS
  5. Configurer S3 pour la prise en charge des fichiers statiques et multimédias
  6. Obtenir un certificat SSL via AWS Certificate Manager
  7. Utilisez un certificat SSL pour servir votre application sur HTTPS

Qu'est-ce qu'Elastic Beanstalk ?

AWS Elastic Beanstalk (EB) est un service facile à utiliser pour le déploiement et la mise à l'échelle des applications Web. Il connecte plusieurs services AWS, comme les instances de calcul ( EC2 ), les bases de données ( RDS ), les équilibreurs de charge ( Application Load Balancer ) et les systèmes de stockage de fichiers ( S3 ), pour n'en nommer que quelques-uns. EB vous permet de développer et de déployer rapidement votre application Web sans vous soucier de l'infrastructure sous-jacente. Il prend en charge les applications développées en Go, Java, .NET, Node.js, PHP, Python et Ruby. EB prend également en charge Docker si vous avez besoin de configurer votre propre pile logicielle ou de déployer une application développée dans un langage (ou une version) qu'EB ne prend pas actuellement en charge.

Configuration typique d'Elastic Beanstalk :

Architecture de haricot élastique

Il n'y a pas de frais supplémentaires pour AWS Elastic Beanstalk. Vous ne payez que les ressources consommées par votre application.

Pour en savoir plus sur Elastic Beanstalk, consultez Qu'est-ce qu'AWS Elastic Beanstalk ? à partir de la documentation officielle d'AWS Elastic Beanstalk .

Concepts de haricot élastique

Avant de plonger dans le didacticiel lui-même, examinons quelques concepts clés liés à Elastic Beanstalk :

  1. Une application est une collection logique de composants Elastic Beanstalk, y compris des environnements, des versions et des configurations d'environnement. Une application peut avoir plusieurs versions .
  2. Un environnement est un ensemble de ressources AWS exécutant une version d'application.
  3. Une plate -forme est une combinaison d'un système d'exploitation, d'un runtime de langage de programmation, d'un serveur Web, d'un serveur d'applications et de composants Elastic Beanstalk.

Ces termes seront utilisés tout au long du didacticiel.

Configuration du projet

Nous allons déployer une simple application d'hébergement d'images appelée django-images dans ce didacticiel.

Vérifiez votre compréhension en déployant votre propre application tout en suivant le didacticiel.

Tout d'abord, récupérez le code du référentiel sur GitHub :

$ git clone git@github.com:duplxey/django-images.git
$ cd django-images

Créez un nouvel environnement virtuel et activez-le :

$ python3 -m venv venv && source venv/bin/activate

Installez les exigences et migrez la base de données :

(venv)$ pip install -r requirements.txt
(venv)$ python manage.py migrate

Exécutez le serveur :

(venv)$ python manage.py runserver

Ouvrez votre navigateur Web préféré et accédez à http://localhost:8000 . Assurez-vous que tout fonctionne correctement en utilisant le formulaire à droite pour télécharger une image. Après avoir téléchargé une image, vous devriez la voir s'afficher dans le tableau :

Aperçu de l'application django-images

Interface de ligne de commande Elastic Beanstalk

Assurez-vous de créer un compte AWS avant de continuer. En créant un compte, vous pouvez également être éligible à l' offre gratuite d'AWS .

L' interface de ligne de commande Elastic Beanstalk (EB CLI) vous permet d'effectuer diverses opérations pour déployer et gérer vos applications et environnements Elastic Beanstalk.

Il existe deux manières d'installer l'interface de ligne de commande EB :

  1. Via le programme d'installation EB CLI
  2. Avec pip (awsebcli)

Il est recommandé d'installer l'interface de ligne de commande EB globalement (en dehors de tout environnement virtuel spécifique) à l'aide du programme d'installation (première option) pour éviter d'éventuels conflits de dépendance. Reportez-vous à cette explication pour plus de détails.

Après avoir installé l'interface de ligne de commande EB, vous pouvez vérifier la version en exécutant :

$ eb --version

EB CLI 3.20.3 (Python 3.10.)

Si la commande ne fonctionne pas, vous devrez peut-être ajouter l'interface de ligne de commande EB à $PATH.

Une liste des commandes EB CLI et leurs descriptions se trouvent dans la référence des commandes EB CLI .

Initialiser Elastic Beanstalk

Une fois que l'interface de ligne de commande EB est en cours d'exécution, nous pouvons commencer à interagir avec Elastic Beanstalk. Initialisons un nouveau projet avec un environnement EB.

Chaleur

Dans la racine du projet ("django-images"), exécutez :

$ eb init

Un certain nombre de questions vous seront posées.

Région par défaut

La région AWS de votre environnement (et ressources) Elastic Beanstalk. Si vous n'êtes pas familier avec les différentes régions AWS, consultez Régions et zones de disponibilité AWS . En règle générale, vous devez choisir la région la plus proche de vos clients. Gardez à l'esprit que les prix des ressources varient d'une région à l'autre.

Nom de l'application

Il s'agit du nom de votre application Elastic Beanstalk. Je recommande simplement d'appuyer sur Entrée et d'utiliser la valeur par défaut : "django-images".

Plate-forme et branche plate-forme

L'interface de ligne de commande EB détectera que vous utilisez un environnement Python. Après cela, il vous donnera différentes versions Python et versions Amazon Linux avec lesquelles vous pourrez travailler. Choisissez "Python 3.8 s'exécutant sur Amazon Linux 2 64 bits".

CodeCommit

CodeCommit est un service de contrôle de code source sécurisé, hautement évolutif et géré qui héberge des référentiels Git privés. Nous ne l'utiliserons pas car nous utilisons déjà GitHub pour le contrôle des sources. Alors dites "non".

SSH

Pour nous connecter ultérieurement aux instances EC2, nous devons configurer SSH. Dites "oui" lorsque vous y êtes invité.

Paire de clés

Pour se connecter aux instances EC2, nous aurons besoin d'une paire de clés RSA. Allez-y et générez-en un, qui sera ajouté à votre dossier "~/.ssh".

Après avoir répondu à toutes les questions, vous remarquerez un répertoire caché à l'intérieur de la racine de votre projet nommé ".elasticbeanstalk". Le répertoire doit contenir un fichier config.yml , avec toutes les données que vous venez de fournir.

.elasticbeanstalk
└── config.yml

Le fichier doit contenir quelque chose de similaire à :

branch-defaults:
  master:
    environment: null
    group_suffix: null
global:
  application_name: django-images
  branch: null
  default_ec2_keyname: aws-eb
  default_platform: Python 3.8 running on 64bit Amazon Linux 2
  default_region: us-west-2
  include_git_submodules: true
  instance_profile: null
  platform_name: null
  platform_version: null
  profile: eb-cli
  repository: null
  sc: git
  workspace_type: Application

Créer

Ensuite, créons l'environnement Elastic Beanstalk et déployons l'application :

$ eb create

Encore une fois, vous serez invité à poser quelques questions.

Nom de l'environnement

Ceci représente le nom de l'environnement EB. Je recommanderais de s'en tenir à la valeur par défaut : "django-images-env".

Il est recommandé d'ajouter └-envou └-devde suffixer à vos environnements afin de pouvoir différencier facilement les applications EB des environnements.

Préfixe DNS CNAME

Votre application Web sera accessible à l'adresse %cname%.%region%.elasticbeanstalk.com. Encore une fois, utilisez la valeur par défaut.

Équilibreur de charge

Un équilibreur de charge répartit le trafic entre les instances de votre environnement. Sélectionnez "candidature".

Si vous souhaitez en savoir plus sur les différents types d'équilibreur de charge, consultez Équilibreur de charge pour votre environnement Elastic Beanstalk .

Demandes de flotte Spot

Les requêtes Spot Fleet vous permettent de lancer des instances à la demande en fonction de vos critères. Nous ne les utiliserons pas dans ce didacticiel, alors dites "non".

--

Avec cela, l'environnement sera animé :

  1. Votre code sera compressé et téléchargé dans un nouveau compartiment S3.
  2. Après cela, les différentes ressources AWS seront créées, comme l'équilibreur de charge, les groupes de sécurité et de mise à l'échelle automatique et les instances EC2.

Une nouvelle application sera également déployée.

Cela prendra environ trois minutes, alors n'hésitez pas à prendre une tasse de café.

Une fois le déploiement terminé, l'interface de ligne de commande EB modifiera .elasticbeanstalk/config.yml .

La structure de votre projet devrait maintenant ressembler à ceci :

|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Statut

Une fois que vous avez déployé votre application, vous pouvez vérifier son état en exécutant :

$ eb status

Environment details for: django-images-env
  Application name: django-images
  Region: us-west-2
  Deployed Version: app-93ec-220218_095635133296
  Environment ID: e-z7dmesipvc
  Platform: arn:aws:elasticbeanstalk:us-west-2::platform/Python 3.8 running on 64bit Amazon Linux 2/3.3.10
  Tier: WebServer-Standard-1.0
  CNAME: django-images-env.us-west-2.elasticbeanstalk.com
  Updated: 2022-02-18 16:00:24.954000+00:00
  Status: Ready
  Health: Red

Vous pouvez voir que la santé actuelle de notre environnement est Red, ce qui signifie que quelque chose s'est mal passé. Ne vous en faites pas pour l'instant, nous y remédierons dans les prochaines étapes.

Vous pouvez également voir qu'AWS nous a attribué un CNAME qui est le nom de domaine de notre environnement EB. Nous pouvons accéder à l'application Web en ouvrant un navigateur et en naviguant vers le CNAME.

Ouvert

$ eb open

Cette commande ouvrira votre navigateur par défaut et naviguera vers le domaine CNAME. Vous verrez 502 Bad Gateway, que nous allons corriger ici sous peu

Console

$ eb console

Cette commande ouvrira la console Elastic Beanstalk dans votre navigateur par défaut :

Console Elastic Beanstalk

Encore une fois, vous pouvez voir que la santé de l'environnement est "sévère", ce que nous corrigerons à l'étape suivante.

Configurer un environnement

À l'étape précédente, nous avons essayé d'accéder à notre application et celle-ci a renvoyé 502 Bad Gateway. Il y a quelques raisons derrière cela :

  1. Python a besoin PYTHONPATHpour trouver des modules dans notre application.
  2. Par défaut, Elastic Beanstalk tente de lancer l'application WSGI à partir de application.py , qui n'existe pas.
  3. Django a besoin DJANGO_SETTINGS_MODULEde savoir quels paramètres utiliser.

Par défaut, Elastic Beanstalk sert les applications Python avec Gunicorn . EB installe automatiquement Gunicorn dans le processus de déploiement, nous n'avons donc pas à l'ajouter à requirements.txt . Si vous souhaitez échanger Gunicorn avec autre chose, jetez un œil à Configuration du serveur WSGI avec un Procfile .

Corrigeons ces erreurs.

Créez un nouveau dossier à la racine du projet appelé ".ebextensions". Dans le dossier nouvellement créé, créez un fichier nommé 01_django.config :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"

Remarques:

  1. Nous définissons le PYTHONPATHchemin Python sur notre instance EC2 ( docs ).
  2. Nous avons pointé DJANGO_SETTINGS_MODULEvers nos paramètres Django ( docs ).
  3. Nous avons remplacé le WSGIPathpar notre application WSGI ( docs ).

Comment fonctionnent les fichiers EB .config ?

  1. Vous pouvez en avoir autant que vous le souhaitez.
  2. Ils sont chargés dans l'ordre suivant : 01_x, 02_x, 03_x, etc.
  3. Vous n'avez pas besoin de mémoriser ces paramètres ; vous pouvez répertorier tous vos paramètres environnementaux en exécutant eb config.

Si vous souhaitez en savoir plus sur la personnalisation avancée de l'environnement, consultez Personnalisation avancée de l'environnement avec les fichiers de configuration .

À ce stade, la structure de votre projet devrait ressembler à ceci :

|-- .ebextensions
|   └-- 01_django.config
|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Une autre chose que nous devons faire avant de redéployer est d'ajouter notre CNAME au fichier ALLOWED_HOSTSin core/settings.py :

# core/settings.py

ALLOWED_HOSTS = [
    'xyz.elasticbeanstalk.com',  # make sure to replace it with your own EB CNAME
]

Alternativement, pour les tests, vous pouvez simplement utiliser un caractère générique : ALLOWED_HOSTS = ['*']. N'oubliez pas de changer cela après avoir terminé les tests !

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Vous remarquerez qu'Elastic Beanstalk ne détectera pas les modifications si vous ne vous engagez pas. En effet, EB s'intègre à git et ne détecte que les fichiers validés (modifiés).

Une fois le déploiement terminé, exécutez eb openpour voir si tout a fonctionné

Aie. Nous avons corrigé l'erreur précédente, mais il y en a une nouvelle maintenant :

NotSupportedError at /
deterministic=True requires SQLite 3.8.3 or higher

Ne vous inquiétez pas. C'est juste un problème avec SQLite, qui ne devrait de toute façon pas être utilisé en production. Nous allons l'échanger avec Postgres ici sous peu.

Configurer RDS

Django utilise une base de données SQLite par défaut . Bien que cela soit parfait pour le développement, vous souhaiterez généralement passer à une base de données plus robuste, comme Postgres ou MySQL, pour la production. De plus, la plate-forme EB actuelle ne fonctionne pas bien avec SQLite, en raison d'un conflit de dépendance de version. À cause de ces deux choses, nous allons remplacer SQlite par Postgres .

PostgreSQL local

Tout d'abord, lançons Postgres en local. Vous pouvez soit le télécharger à partir des téléchargements PostgreSQL , soit créer un conteneur Docker :

$ docker run --name django-images-postgres -p 5432:5432 \
    -e POSTGRES_USER=django-images -e POSTGRES_PASSWORD=complexpassword123 \
    -e POSTGRES_DB=django-images -d postgres

Vérifiez si le conteneur est en cours d'exécution :

$ docker ps -f name=django-images-postgres

CONTAINER ID   IMAGE      COMMAND                  CREATED              STATUS              PORTS                    NAMES
c05621dac852   postgres   "docker-entrypoint.s…"   About a minute ago   Up About a minute   0.0.0.0:5432->5432/tcp   django-images-postgres

Maintenant, essayons de nous y connecter avec notre application Django. Dans core/settings.py , modifiez la DATABASEconfiguration comme suit :

# core/settings.py

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

Ensuite, installez psycopg2-binary , qui est requis pour Postgres :

(venv)$ pip install psycopg2-binary==2.9.3

Ajoutez-le à requirements.txt :

Django==4.0.2
Pillow==9.0.1
django-tables2==2.4.1
django-crispy-forms==1.14.0
psycopg2-binary==2.9.3

Créez et appliquez les migrations :

(venv)$ python manage.py makemigrations
(venv)$ python manage.py migrate

Exécutez le serveur :

(venv)$ python manage.py runserver

Assurez-vous que vous pouvez toujours télécharger une image sur http://localhost:8000 .

Si vous obtenez une DisallowedHosterreur, ajoutez localhostet 127.0.0.1à l' ALLOWED_HOSTSintérieur de core/settings.py .

AWS RDS Postgres

Pour configurer Postgres pour la production, commencez par exécuter la commande suivante pour ouvrir la console AWS :

$ eb console

Cliquez sur "Configuration" dans la barre de gauche, faites défiler jusqu'à "Base de données", puis cliquez sur "Modifier".

Créez une BD avec les paramètres suivants et cliquez sur "Appliquer":

  • Moteur : postgres
  • Version du moteur : 12.9 (ancienne version de Postgres puisque db.t2.micro n'est pas disponible avec 13.1+)
  • Classe d'instance : db.t2.micro
  • Stockage : 5 Go (devrait être plus que suffisant)
  • Nom d'utilisateur : choisissez un nom d'utilisateur
  • Mot de passe : choisissez un mot de passe fort

Si vous souhaitez rester dans l' offre gratuite d'AWS, assurez-vous de choisir db.t2.micro. Les prix RDS augmentent de manière exponentielle en fonction de la classe d'instance que vous choisissez. Si vous ne souhaitez pas utiliser, microassurez-vous de consulter la tarification AWS PostgreSQL .

Paramètres RDS

Une fois la mise à jour de l'environnement terminée, EB transmettra automatiquement les informations d'identification DB suivantes à notre application Django :

RDS_DB_NAME
RDS_USERNAME
RDS_PASSWORD
RDS_HOSTNAME
RDS_PORT

Nous pouvons maintenant utiliser ces variables dans core/settings.py pour configurer DATABASE:

# core/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': 'django-images',
            'USER': 'django-images',
            'PASSWORD': 'complexpassword123',
            'HOST': 'localhost',
            'PORT': '5432',
        }
    }

N'oubliez pas d'importer le ospackage en haut de core/settings.py :

import os

Ensuite, nous devons dire à Elastic Beanstalk de s'exécuter makemigrationset migratequand une nouvelle version de l'application est déployée. Nous pouvons le faire en éditant le fichier .ebextensions/01_django.config . Ajoutez ce qui suit au bas du fichier :

# .ebextensions/01_django.config

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true

L'environnement EB exécutera désormais les commandes ci-dessus chaque fois que nous déployons une nouvelle version de l'application. Nous avons utilisé leader_only, donc seule la première instance EC2 les exécute (au cas où notre environnement EB exécute plusieurs instances EC2).

Les configurations Elastic Beanstalk prennent en charge deux sections de commande différentes, les commandes et les conteneur_commands . La principale différence entre eux réside dans le moment où ils sont exécutés dans le processus de déploiement :

  1. commandsexécuté avant que l'application et le serveur Web ne soient configurés et que le fichier de version de l'application ne soit extrait.
  2. container_commandsexécuté après la configuration de l'application et du serveur Web et l'extraction de l'archive de la version de l'application, mais avant le déploiement de la version de l'application (avant que les fichiers ne soient déplacés du dossier intermédiaire vers leur emplacement final).

Ajoutons également une commande pour créer un superutilisateur. Nous pouvons utiliser le cadre de commande personnalisé intuitif de Django pour ajouter une nouvelle commande. Dans l'application "images", créez les fichiers et dossiers suivants :

└-- images
    └-- management
        |-- __init__.py
        └-- commands
            |-- __init__.py
            └-- createsu.py

createsu.py :

# images/management/commands/createsu.py

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


class Command(BaseCommand):
    help = 'Creates a superuser.'

    def handle(self, *args, **options):
        if not User.objects.filter(username='admin').exists():
            User.objects.create_superuser(
                username='admin',
                password='complexpassword123'
            )
        print('Superuser has been created.')

Ensuite, ajoutez la troisième commande de conteneur à .ebextensions/01_django.config :

# .ebextensions/01_django.config

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  # ------------------------------------- new -------------------------------------
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  # --------------------------------- end of new  ---------------------------------

Une alternative à la création d'une createsucommande consiste à se connecter en SSH à l'une des instances EC2 et à exécuter la createsuperusercommande par défaut de Django.

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Attendez que le déploiement se termine. Une fois cela fait, exécutez eb openpour ouvrir votre application dans un nouvel onglet du navigateur. Votre application devrait maintenant fonctionner. Assurez-vous que vous pouvez télécharger une image.

S3 pour le stockage de fichiers

Découvrez la version déployée de votre tableau de bord d'administration. Les fichiers statiques ne sont pas servis correctement. De plus, nous ne voulons pas que les fichiers statiques ou multimédias soient stockés localement sur une instance EC2, car les applications EB doivent être aussi sans état, ce qui facilite grandement la mise à l' échelle de vos applications sur plusieurs instances EC2.

Alors qu'AWS fournit un certain nombre de services de stockage persistant , S3 est sans doute le plus populaire et le plus facile à utiliser.

Pour configurer S3, nous devrons :

  1. Créer un compartiment S3
  2. Créer un groupe et un utilisateur IAM pour la gestion du compartiment S3
  3. Définir les variables d'environnement Elastic Beanstalk S3
  4. Configurer les paramètres statiques et multimédias de Django

Créer un compartiment S3

Pour commencer, créons un nouveau compartiment S3. Accédez à la console AWS S3 et cliquez sur "Créer un compartiment". Donnez au compartiment un nom unique et définissez la région AWS. Utilisez la configuration par défaut pour tout le reste. Appuyez sur "Créer".

Groupe et utilisateur IAM

Accédez à la console IAM . Sur le côté gauche de l'écran, sélectionnez "Groupes d'utilisateurs". Créez un nouveau groupe avec la permission "AmazonS3FullAccess":

Groupe AWS IAM

Ensuite, créez un nouvel utilisateur avec "Accès par programmation" et attribuez ce groupe à l'utilisateur :

Utilisateur AWS IAM

AWS générera des identifiants d'authentification pour vous. Téléchargez le fichier .csv fourni . Nous devrons les transmettre à notre environnement Elastic Beanstalk à l'étape suivante.

Définir les variables d'environnement EB

Ensuite, nous devons définir les variables d'environnement suivantes :

AWS_ACCESS_KEY_ID                - your ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY            - your SECRET_ACCESS_KEY
AWS_S3_REGION_NAME               - your selected S3 region
AWS_STORAGE_BUCKET_NAME          - your bucket name

Accédez à votre console Elastic Beanstalk. Cliquez sur "Configurer". Ensuite, dans la catégorie "Logiciel", cliquez sur "Modifier" et faites défiler jusqu'à la section "Propriétés de l'environnement". Additionnez les quatre variables.

Variables d'environnement AWS Elastic Beanstalk

Après avoir ajouté toutes les variables, cliquez sur "Appliquer".

Configurer les paramètres statiques et multimédias de Django

Ensuite, pour que Django puisse communiquer avec notre compartiment S3, nous devons installer les packages django- storages et boto3 .

Ajoutez-les au fichier requirements.txt :

Django==4.0.2
Pillow==9.0.1
django-tables2==2.4.1
django-crispy-forms==1.14.0
psycopg2-binary==2.9.3
boto3==1.21.3
django-storages==1.12.3

Ensuite, ajoutez l'application nouvellement installée INSTALLED_APPSdans core/settings.py :

# core/settings.py

INSTALLED_APPS = [
    # ...
    'storages',
]

Configurez django-storages pour utiliser les variables d'environnement transmises par Elastic Beanstalk :

if 'AWS_STORAGE_BUCKET_NAME' in os.environ:
    STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
    DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

    AWS_STORAGE_BUCKET_NAME = os.environ['AWS_STORAGE_BUCKET_NAME']
    AWS_S3_REGION_NAME = os.environ['AWS_S3_REGION_NAME']

    AWS_S3_ACCESS_KEY_ID = os.environ['AWS_ACCESS_KEY_ID']
    AWS_S3_SECRET_ACCESS_KEY = os.environ['AWS_SECRET_ACCESS_KEY']

Enfin, nous devons exécuter la collectstaticcommande une fois le déploiement terminé, ajoutez donc ce qui suit au bas de 01_django.config :

# .ebextensions/01_django.config
# ...

container_commands:
  # ...
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Le fichier complet devrait maintenant ressembler à ceci :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Confirmez que les fichiers statiques et multimédias sont maintenant stockés sur S3.

Si vous obtenez une Signature mismatcherreur, vous pouvez ajouter le paramètre suivant à core/settings.py : AWS_S3_ADDRESSING_STYLE = "virtual". Pour plus de détails, reportez-vous à ce problème GitHub .

Pour en savoir plus sur le stockage de fichiers statiques et multimédias sur AWS S3, consultez l' article Stockage de fichiers statiques et multimédias Django sur Amazon S3 .

HTTPS avec le gestionnaire de certificats

Cette partie du tutoriel nécessite que vous disposiez d'un nom de domaine.

Besoin d'un domaine pas cher pour vous entraîner ? Plusieurs bureaux d'enregistrement de domaine ont des promotions sur les domaines '.xyz'. Alternativement, vous pouvez créer un domaine gratuit chez Freenom . Si vous ne possédez pas de nom de domaine, mais souhaitez tout de même utiliser HTTPS, vous pouvez créer et signer avec un certificat X509 .

Pour servir votre application via HTTPS, nous devrons :

  1. Demander et valider un certificat SSL/TLS
  2. Faites pointer votre nom de domaine vers votre EB CNAME
  3. Modifier l'équilibreur de charge pour servir HTTPS
  4. Modifier les paramètres de votre application

Demander et valider un certificat SSL/TLS

Accédez à la console AWS Certificate Manager . Cliquez sur "Demander un certificat". Définissez le type de certificat sur "Public" et cliquez sur "Suivant". Entrez votre nom de domaine complet dans la saisie du formulaire, définissez la "Méthode de validation" sur "Validation DNS", puis cliquez sur "Demander".

AWS demande un certificat public

Vous serez alors redirigé vers une page où vous pourrez voir tous vos certificats. Le certificat que vous venez de créer doit avoir le statut "En attente de validation".

Pour qu'AWS délivre un certificat, vous devez d'abord prouver que vous êtes le propriétaire du domaine. Dans le tableau, cliquez sur le certificat pour afficher les "Détails du certificat". Notez le "nom CNAME" et la "valeur CNAME". Pour valider la propriété du domaine, vous devrez créer un "enregistrement CNAME" dans les paramètres DNS de votre domaine. Utilisez le "nom CNAME" et la "valeur CNAME" pour cela. Une fois cela fait, il faudra quelques minutes à Amazon pour récupérez les modifications de domaine et émettez le certificat. Le statut doit passer de "En attente de validation" à "Émis".

Faites pointer le nom de domaine vers l'EB CNAME

Ensuite, vous devez faire pointer votre domaine (ou sous-domaine) vers votre environnement EB CNAME. De retour dans les paramètres DNS de votre domaine, ajoutez un autre enregistrement CNAME avec la valeur correspondant à votre EB CNAME -- par exemple, django-images-dev.us-west-2.elasticbeanstalk.com.

Attendez quelques minutes que votre DNS se rafraîchisse avant de tester les choses à partir de la http://saveur de votre nom de domaine dans votre navigateur.

Modifier l'équilibreur de charge pour servir HTTPS

De retour dans la console Elastic Beanstalk, cliquez sur « Configuration ». Ensuite, dans la catégorie "Load balancer", cliquez sur "Edit". Cliquez sur "Ajouter un écouteur" et créez un écouteur avec les détails suivants :

  1. Port - 443
  2. Protocole - HTTPS
  3. Certificat SSL - sélectionnez le certificat que vous venez de créer

Cliquez sur "Ajouter". Ensuite, faites défiler vers le bas de la page et cliquez sur "Appliquer". La mise à jour de l'environnement prendra quelques minutes.

Modifier vos paramètres d'application

Ensuite, nous devons apporter quelques modifications à notre application Django.

Tout d'abord, ajoutez votre domaine pleinement qualifié àALLOWED_HOSTS :

# core/settings.py

ALLOWED_HOSTS = [
    # ...
    'yourdomain.com',
]

Enfin, nous devons rediriger tout le trafic de HTTP vers HTTPS. Il existe plusieurs façons de procéder, mais la plus simple consiste à configurer Apache en tant qu'hôte proxy. Nous pouvons y parvenir par programmation en ajoutant ce qui suit à la fin de option_settingsin .ebextensions/01_django.config :

# .ebextensions/01_django.config

option_settings:
  # ...
  aws:elasticbeanstalk:environment:proxy:  # new
    ProxyServer: apache                    # new

Votre fichier final 01_django.config devrait maintenant ressembler à ceci :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: apache

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Créez ensuite un dossier ".platform" à la racine du projet et ajoutez les fichiers et dossiers suivants :

└-- .platform
    └-- httpd
        └-- conf.d
            └-- ssl_rewrite.conf

ssl_rewrite.conf :

# .platform/httpd/conf.d/ssl_rewrite.conf

RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>

La structure de votre projet devrait maintenant ressembler à ceci :

|-- .ebextensions
|   └-- 01_django.config
|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- .platform
|   └-- httpd
|       └-- conf.d
|           └-- ssl_rewrite.conf
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
│   ├── management
│   │   ├── __init__.py
│   │   └── commands
│   │       ├── __init__.py
│   │       └── createsu.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Maintenant, dans votre navigateur, la https://saveur de votre application devrait fonctionner. Essayez d'aller à la http://saveur. Vous devriez être redirigé vers la https://saveur. Assurez-vous également que le certificat est correctement chargé :

application sécurisée

Variables d'environnement

En production, il est préférable de stocker la configuration spécifique à l'environnement dans des variables d'environnement . Avec Elastic Beanstalk, vous pouvez définir des variables d'environnement personnalisées de deux manières différentes.

Variables d'environnement via EB CLI

Transformons Django SECRET_KEYet les DEBUGparamètres en variables d'environnement.

Commencez par exécuter :

$ eb setenv DJANGO_SECRET_KEY='<replace me with your own secret key>' \
            DJANGO_DEBUG='1'

Vous pouvez définir plusieurs variables d'environnement avec une seule commande en les séparant par des espaces. Il s'agit de l'approche recommandée car elle n'entraîne qu'une seule mise à jour de l'environnement EB.

Modifiez core/settings.py en conséquence :

# core/settings.py

SECRET_KEY = os.environ.get(
    'DJANGO_SECRET_KEY',
    '<replace me with your own fallback secret key>'
)

DEBUG = os.environ.get('DJANGO_DEBUG', '1').lower() in ['true', 't', '1']

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Variables d'environnement via la console EB

Accédez à la console Elastic Beanstalk via eb open. Accédez à "Configuration" > "Logiciel" > "Modifier". Ensuite, faites défiler jusqu'aux "Propriétés de l'environnement".

Variables d'environnement AWS Elastic Beanstalk

Une fois que vous avez terminé, cliquez sur "Appliquer" et votre environnement sera mis à jour.

Vous pouvez ensuite accéder à ces variables dans votre environnement Python via os.environ.

Par exemple:

VARIABLE_NAME = os.environ['VARIABLE_NAME']

Débogage d'Elastic Beanstalk

Lorsque vous travaillez avec Elastic Beanstalk, il peut être assez frustrant de comprendre ce qui ne va pas si vous ne savez pas comment accéder aux fichiers journaux. Dans cette section, nous examinerons exactement cela.

Il existe deux façons d'accéder aux journaux :

  1. CLI ou console Elastic Beanstalk
  2. SSH dans l'instance EC2

Par expérience personnelle, j'ai pu résoudre tous les problèmes avec la première approche.

CLI ou console Elastic Beanstalk

CLI :

$ eb logs

This command will fetch the last 100 lines from the following files:

/var/log/web.stdout.log
/var/log/eb-hooks.log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/eb-engine.log

L'exécution eb logséquivaut à se connecter à la console EB et à naviguer vers "Journaux".

Je recommande de diriger les journaux vers CloudWatch . Exécutez la commande suivante pour l'activer :

$ eb logs --cloudwatch-logs enable

Vous trouverez généralement des erreurs Django dans /var/log/web.stdout.log ou /var/log/eb-engine.log .

Pour en savoir plus sur les journaux Elastic Beanstalk, consultez Affichage des journaux des instances Amazon EC2 .

SSH dans l'instance EC2

Pour vous connecter à une instance EC2 sur laquelle votre application Django est en cours d'exécution, exécutez :

$ eb ssh

Vous serez invité à ajouter l'hôte à vos hôtes connus la première fois. Dis oui. Avec cela, vous aurez désormais un accès complet à votre instance EC2. N'hésitez pas à expérimenter avec les commandes de gestion de Django et à vérifier certains des fichiers journaux mentionnés dans la section précédente.

Gardez à l'esprit qu'Elastic Beanstalk met automatiquement à l'échelle et déploie de nouvelles instances EC2. Les modifications que vous apportez à cette instance EC2 spécifique ne seront pas répercutées sur les instances EC2 nouvellement lancées. Une fois cette instance EC2 spécifique remplacée, vos modifications seront effacées.

Conclusion

Dans ce didacticiel, nous avons parcouru le processus de déploiement d'une application Django sur AWS Elastic Beanstalk. Vous devriez maintenant avoir une bonne compréhension du fonctionnement d'Elastic Beanstalk. Effectuez une auto-vérification rapide en passant en revue les objectifs au début du didacticiel.

Prochaines étapes:

  1. Vous devriez envisager de créer deux environnements EB distincts ( devet production).
  2. Consultez le groupe Auto Scaling pour votre environnement Elastic Beanstalk pour savoir comment configurer des déclencheurs pour la mise à l'échelle automatique de votre application.

Pour supprimer toutes les ressources AWS que nous avons créées tout au long du didacticiel, arrêtez d'abord l'environnement Elastic Beanstalk :

$ eb terminate

Vous devrez supprimer manuellement le compartiment S3, le certificat SSL, ainsi que le groupe et l'utilisateur IAM.

Enfin, vous pouvez trouver la version finale du code dans le référentiel django-elastic-beanstalk sur GitHub.

Source :  https://testdrive.io

#django #aws 

What is GEEK

Buddha Community

Déploiement D'une Application Django Sur AWS Elastic Beanstalk
Ahebwe  Oscar

Ahebwe Oscar

1620177818

Django admin full Customization step by step

Welcome to my blog , hey everyone in this article you learn how to customize the Django app and view in the article you will know how to register  and unregister  models from the admin view how to add filtering how to add a custom input field, and a button that triggers an action on all objects and even how to change the look of your app and page using the Django suit package let’s get started.

Database

Custom Titles of Django Admin

Exclude in Django Admin

Fields in Django Admin

#django #create super user django #customize django admin dashboard #django admin #django admin custom field display #django admin customization #django admin full customization #django admin interface #django admin register all models #django customization

How to Use AWS Elastic Beanstalk to Reduce Risk of Deployment Downtime

You can use AWS Elastic Beanstalk to create and deploy an updated or upgrated application version with blue-green deployment using cloned configs.

In this piece, I’ll be demonstrating how AWS Elastic Beanstalk can simplify deployments by doing all the hard work for you – and with no risk of downtime – by employing a Blue/Green deployment strategy.

Using AWS means combining a large number of tools to complete projects. Personally, I choose to streamline this process by using Elastic Beanstalk, as it enables me and the rest of the dev team to control the AWS resources which power the applications we support and gives us full access to the underlying resources at any time.

#cloud #aws #elastic beanstalk #aws tools #aws elastic beanstalk

Eladio  Rau

Eladio Rau

1660058040

Déploiement D'une Application Django Sur AWS Elastic Beanstalk

Dans ce didacticiel, nous allons parcourir le processus de déploiement d'une application Django prête pour la production sur AWS Elastic Beanstalk.

Objectifs

À la fin de ce didacticiel, vous serez en mesure de :

  1. Expliquer ce qu'est Elastic Beanstalk
  2. Initialiser et configurer Elastic Beanstalk
  3. Dépanner une application exécutée sur Elastic Beanstalk
  4. Intégrer Elastic Beanstalk à RDS
  5. Configurer S3 pour la prise en charge des fichiers statiques et multimédias
  6. Obtenir un certificat SSL via AWS Certificate Manager
  7. Utilisez un certificat SSL pour servir votre application sur HTTPS

Qu'est-ce qu'Elastic Beanstalk ?

AWS Elastic Beanstalk (EB) est un service facile à utiliser pour le déploiement et la mise à l'échelle des applications Web. Il connecte plusieurs services AWS, comme les instances de calcul ( EC2 ), les bases de données ( RDS ), les équilibreurs de charge ( Application Load Balancer ) et les systèmes de stockage de fichiers ( S3 ), pour n'en nommer que quelques-uns. EB vous permet de développer et de déployer rapidement votre application Web sans vous soucier de l'infrastructure sous-jacente. Il prend en charge les applications développées en Go, Java, .NET, Node.js, PHP, Python et Ruby. EB prend également en charge Docker si vous avez besoin de configurer votre propre pile logicielle ou de déployer une application développée dans un langage (ou une version) qu'EB ne prend pas actuellement en charge.

Configuration typique d'Elastic Beanstalk :

Architecture de haricot élastique

Il n'y a pas de frais supplémentaires pour AWS Elastic Beanstalk. Vous ne payez que les ressources consommées par votre application.

Pour en savoir plus sur Elastic Beanstalk, consultez Qu'est-ce qu'AWS Elastic Beanstalk ? à partir de la documentation officielle d'AWS Elastic Beanstalk .

Concepts de haricot élastique

Avant de plonger dans le didacticiel lui-même, examinons quelques concepts clés liés à Elastic Beanstalk :

  1. Une application est une collection logique de composants Elastic Beanstalk, y compris des environnements, des versions et des configurations d'environnement. Une application peut avoir plusieurs versions .
  2. Un environnement est un ensemble de ressources AWS exécutant une version d'application.
  3. Une plate -forme est une combinaison d'un système d'exploitation, d'un runtime de langage de programmation, d'un serveur Web, d'un serveur d'applications et de composants Elastic Beanstalk.

Ces termes seront utilisés tout au long du didacticiel.

Configuration du projet

Nous allons déployer une simple application d'hébergement d'images appelée django-images dans ce didacticiel.

Vérifiez votre compréhension en déployant votre propre application tout en suivant le didacticiel.

Tout d'abord, récupérez le code du référentiel sur GitHub :

$ git clone git@github.com:duplxey/django-images.git
$ cd django-images

Créez un nouvel environnement virtuel et activez-le :

$ python3 -m venv venv && source venv/bin/activate

Installez les exigences et migrez la base de données :

(venv)$ pip install -r requirements.txt
(venv)$ python manage.py migrate

Exécutez le serveur :

(venv)$ python manage.py runserver

Ouvrez votre navigateur Web préféré et accédez à http://localhost:8000 . Assurez-vous que tout fonctionne correctement en utilisant le formulaire à droite pour télécharger une image. Après avoir téléchargé une image, vous devriez la voir s'afficher dans le tableau :

Aperçu de l'application django-images

Interface de ligne de commande Elastic Beanstalk

Assurez-vous de créer un compte AWS avant de continuer. En créant un compte, vous pouvez également être éligible à l' offre gratuite d'AWS .

L' interface de ligne de commande Elastic Beanstalk (EB CLI) vous permet d'effectuer diverses opérations pour déployer et gérer vos applications et environnements Elastic Beanstalk.

Il existe deux manières d'installer l'interface de ligne de commande EB :

  1. Via le programme d'installation EB CLI
  2. Avec pip (awsebcli)

Il est recommandé d'installer l'interface de ligne de commande EB globalement (en dehors de tout environnement virtuel spécifique) à l'aide du programme d'installation (première option) pour éviter d'éventuels conflits de dépendance. Reportez-vous à cette explication pour plus de détails.

Après avoir installé l'interface de ligne de commande EB, vous pouvez vérifier la version en exécutant :

$ eb --version

EB CLI 3.20.3 (Python 3.10.)

Si la commande ne fonctionne pas, vous devrez peut-être ajouter l'interface de ligne de commande EB à $PATH.

Une liste des commandes EB CLI et leurs descriptions se trouvent dans la référence des commandes EB CLI .

Initialiser Elastic Beanstalk

Une fois que l'interface de ligne de commande EB est en cours d'exécution, nous pouvons commencer à interagir avec Elastic Beanstalk. Initialisons un nouveau projet avec un environnement EB.

Chaleur

Dans la racine du projet ("django-images"), exécutez :

$ eb init

Un certain nombre de questions vous seront posées.

Région par défaut

La région AWS de votre environnement (et ressources) Elastic Beanstalk. Si vous n'êtes pas familier avec les différentes régions AWS, consultez Régions et zones de disponibilité AWS . En règle générale, vous devez choisir la région la plus proche de vos clients. Gardez à l'esprit que les prix des ressources varient d'une région à l'autre.

Nom de l'application

Il s'agit du nom de votre application Elastic Beanstalk. Je recommande simplement d'appuyer sur Entrée et d'utiliser la valeur par défaut : "django-images".

Plate-forme et branche plate-forme

L'interface de ligne de commande EB détectera que vous utilisez un environnement Python. Après cela, il vous donnera différentes versions Python et versions Amazon Linux avec lesquelles vous pourrez travailler. Choisissez "Python 3.8 s'exécutant sur Amazon Linux 2 64 bits".

CodeCommit

CodeCommit est un service de contrôle de code source sécurisé, hautement évolutif et géré qui héberge des référentiels Git privés. Nous ne l'utiliserons pas car nous utilisons déjà GitHub pour le contrôle des sources. Alors dites "non".

SSH

Pour nous connecter ultérieurement aux instances EC2, nous devons configurer SSH. Dites "oui" lorsque vous y êtes invité.

Paire de clés

Pour se connecter aux instances EC2, nous aurons besoin d'une paire de clés RSA. Allez-y et générez-en un, qui sera ajouté à votre dossier "~/.ssh".

Après avoir répondu à toutes les questions, vous remarquerez un répertoire caché à l'intérieur de la racine de votre projet nommé ".elasticbeanstalk". Le répertoire doit contenir un fichier config.yml , avec toutes les données que vous venez de fournir.

.elasticbeanstalk
└── config.yml

Le fichier doit contenir quelque chose de similaire à :

branch-defaults:
  master:
    environment: null
    group_suffix: null
global:
  application_name: django-images
  branch: null
  default_ec2_keyname: aws-eb
  default_platform: Python 3.8 running on 64bit Amazon Linux 2
  default_region: us-west-2
  include_git_submodules: true
  instance_profile: null
  platform_name: null
  platform_version: null
  profile: eb-cli
  repository: null
  sc: git
  workspace_type: Application

Créer

Ensuite, créons l'environnement Elastic Beanstalk et déployons l'application :

$ eb create

Encore une fois, vous serez invité à poser quelques questions.

Nom de l'environnement

Ceci représente le nom de l'environnement EB. Je recommanderais de s'en tenir à la valeur par défaut : "django-images-env".

Il est recommandé d'ajouter └-envou └-devde suffixer à vos environnements afin de pouvoir différencier facilement les applications EB des environnements.

Préfixe DNS CNAME

Votre application Web sera accessible à l'adresse %cname%.%region%.elasticbeanstalk.com. Encore une fois, utilisez la valeur par défaut.

Équilibreur de charge

Un équilibreur de charge répartit le trafic entre les instances de votre environnement. Sélectionnez "candidature".

Si vous souhaitez en savoir plus sur les différents types d'équilibreur de charge, consultez Équilibreur de charge pour votre environnement Elastic Beanstalk .

Demandes de flotte Spot

Les requêtes Spot Fleet vous permettent de lancer des instances à la demande en fonction de vos critères. Nous ne les utiliserons pas dans ce didacticiel, alors dites "non".

--

Avec cela, l'environnement sera animé :

  1. Votre code sera compressé et téléchargé dans un nouveau compartiment S3.
  2. Après cela, les différentes ressources AWS seront créées, comme l'équilibreur de charge, les groupes de sécurité et de mise à l'échelle automatique et les instances EC2.

Une nouvelle application sera également déployée.

Cela prendra environ trois minutes, alors n'hésitez pas à prendre une tasse de café.

Une fois le déploiement terminé, l'interface de ligne de commande EB modifiera .elasticbeanstalk/config.yml .

La structure de votre projet devrait maintenant ressembler à ceci :

|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Statut

Une fois que vous avez déployé votre application, vous pouvez vérifier son état en exécutant :

$ eb status

Environment details for: django-images-env
  Application name: django-images
  Region: us-west-2
  Deployed Version: app-93ec-220218_095635133296
  Environment ID: e-z7dmesipvc
  Platform: arn:aws:elasticbeanstalk:us-west-2::platform/Python 3.8 running on 64bit Amazon Linux 2/3.3.10
  Tier: WebServer-Standard-1.0
  CNAME: django-images-env.us-west-2.elasticbeanstalk.com
  Updated: 2022-02-18 16:00:24.954000+00:00
  Status: Ready
  Health: Red

Vous pouvez voir que la santé actuelle de notre environnement est Red, ce qui signifie que quelque chose s'est mal passé. Ne vous en faites pas pour l'instant, nous y remédierons dans les prochaines étapes.

Vous pouvez également voir qu'AWS nous a attribué un CNAME qui est le nom de domaine de notre environnement EB. Nous pouvons accéder à l'application Web en ouvrant un navigateur et en naviguant vers le CNAME.

Ouvert

$ eb open

Cette commande ouvrira votre navigateur par défaut et naviguera vers le domaine CNAME. Vous verrez 502 Bad Gateway, que nous allons corriger ici sous peu

Console

$ eb console

Cette commande ouvrira la console Elastic Beanstalk dans votre navigateur par défaut :

Console Elastic Beanstalk

Encore une fois, vous pouvez voir que la santé de l'environnement est "sévère", ce que nous corrigerons à l'étape suivante.

Configurer un environnement

À l'étape précédente, nous avons essayé d'accéder à notre application et celle-ci a renvoyé 502 Bad Gateway. Il y a quelques raisons derrière cela :

  1. Python a besoin PYTHONPATHpour trouver des modules dans notre application.
  2. Par défaut, Elastic Beanstalk tente de lancer l'application WSGI à partir de application.py , qui n'existe pas.
  3. Django a besoin DJANGO_SETTINGS_MODULEde savoir quels paramètres utiliser.

Par défaut, Elastic Beanstalk sert les applications Python avec Gunicorn . EB installe automatiquement Gunicorn dans le processus de déploiement, nous n'avons donc pas à l'ajouter à requirements.txt . Si vous souhaitez échanger Gunicorn avec autre chose, jetez un œil à Configuration du serveur WSGI avec un Procfile .

Corrigeons ces erreurs.

Créez un nouveau dossier à la racine du projet appelé ".ebextensions". Dans le dossier nouvellement créé, créez un fichier nommé 01_django.config :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"

Remarques:

  1. Nous définissons le PYTHONPATHchemin Python sur notre instance EC2 ( docs ).
  2. Nous avons pointé DJANGO_SETTINGS_MODULEvers nos paramètres Django ( docs ).
  3. Nous avons remplacé le WSGIPathpar notre application WSGI ( docs ).

Comment fonctionnent les fichiers EB .config ?

  1. Vous pouvez en avoir autant que vous le souhaitez.
  2. Ils sont chargés dans l'ordre suivant : 01_x, 02_x, 03_x, etc.
  3. Vous n'avez pas besoin de mémoriser ces paramètres ; vous pouvez répertorier tous vos paramètres environnementaux en exécutant eb config.

Si vous souhaitez en savoir plus sur la personnalisation avancée de l'environnement, consultez Personnalisation avancée de l'environnement avec les fichiers de configuration .

À ce stade, la structure de votre projet devrait ressembler à ceci :

|-- .ebextensions
|   └-- 01_django.config
|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Une autre chose que nous devons faire avant de redéployer est d'ajouter notre CNAME au fichier ALLOWED_HOSTSin core/settings.py :

# core/settings.py

ALLOWED_HOSTS = [
    'xyz.elasticbeanstalk.com',  # make sure to replace it with your own EB CNAME
]

Alternativement, pour les tests, vous pouvez simplement utiliser un caractère générique : ALLOWED_HOSTS = ['*']. N'oubliez pas de changer cela après avoir terminé les tests !

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Vous remarquerez qu'Elastic Beanstalk ne détectera pas les modifications si vous ne vous engagez pas. En effet, EB s'intègre à git et ne détecte que les fichiers validés (modifiés).

Une fois le déploiement terminé, exécutez eb openpour voir si tout a fonctionné

Aie. Nous avons corrigé l'erreur précédente, mais il y en a une nouvelle maintenant :

NotSupportedError at /
deterministic=True requires SQLite 3.8.3 or higher

Ne vous inquiétez pas. C'est juste un problème avec SQLite, qui ne devrait de toute façon pas être utilisé en production. Nous allons l'échanger avec Postgres ici sous peu.

Configurer RDS

Django utilise une base de données SQLite par défaut . Bien que cela soit parfait pour le développement, vous souhaiterez généralement passer à une base de données plus robuste, comme Postgres ou MySQL, pour la production. De plus, la plate-forme EB actuelle ne fonctionne pas bien avec SQLite, en raison d'un conflit de dépendance de version. À cause de ces deux choses, nous allons remplacer SQlite par Postgres .

PostgreSQL local

Tout d'abord, lançons Postgres en local. Vous pouvez soit le télécharger à partir des téléchargements PostgreSQL , soit créer un conteneur Docker :

$ docker run --name django-images-postgres -p 5432:5432 \
    -e POSTGRES_USER=django-images -e POSTGRES_PASSWORD=complexpassword123 \
    -e POSTGRES_DB=django-images -d postgres

Vérifiez si le conteneur est en cours d'exécution :

$ docker ps -f name=django-images-postgres

CONTAINER ID   IMAGE      COMMAND                  CREATED              STATUS              PORTS                    NAMES
c05621dac852   postgres   "docker-entrypoint.s…"   About a minute ago   Up About a minute   0.0.0.0:5432->5432/tcp   django-images-postgres

Maintenant, essayons de nous y connecter avec notre application Django. Dans core/settings.py , modifiez la DATABASEconfiguration comme suit :

# core/settings.py

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

Ensuite, installez psycopg2-binary , qui est requis pour Postgres :

(venv)$ pip install psycopg2-binary==2.9.3

Ajoutez-le à requirements.txt :

Django==4.0.2
Pillow==9.0.1
django-tables2==2.4.1
django-crispy-forms==1.14.0
psycopg2-binary==2.9.3

Créez et appliquez les migrations :

(venv)$ python manage.py makemigrations
(venv)$ python manage.py migrate

Exécutez le serveur :

(venv)$ python manage.py runserver

Assurez-vous que vous pouvez toujours télécharger une image sur http://localhost:8000 .

Si vous obtenez une DisallowedHosterreur, ajoutez localhostet 127.0.0.1à l' ALLOWED_HOSTSintérieur de core/settings.py .

AWS RDS Postgres

Pour configurer Postgres pour la production, commencez par exécuter la commande suivante pour ouvrir la console AWS :

$ eb console

Cliquez sur "Configuration" dans la barre de gauche, faites défiler jusqu'à "Base de données", puis cliquez sur "Modifier".

Créez une BD avec les paramètres suivants et cliquez sur "Appliquer":

  • Moteur : postgres
  • Version du moteur : 12.9 (ancienne version de Postgres puisque db.t2.micro n'est pas disponible avec 13.1+)
  • Classe d'instance : db.t2.micro
  • Stockage : 5 Go (devrait être plus que suffisant)
  • Nom d'utilisateur : choisissez un nom d'utilisateur
  • Mot de passe : choisissez un mot de passe fort

Si vous souhaitez rester dans l' offre gratuite d'AWS, assurez-vous de choisir db.t2.micro. Les prix RDS augmentent de manière exponentielle en fonction de la classe d'instance que vous choisissez. Si vous ne souhaitez pas utiliser, microassurez-vous de consulter la tarification AWS PostgreSQL .

Paramètres RDS

Une fois la mise à jour de l'environnement terminée, EB transmettra automatiquement les informations d'identification DB suivantes à notre application Django :

RDS_DB_NAME
RDS_USERNAME
RDS_PASSWORD
RDS_HOSTNAME
RDS_PORT

Nous pouvons maintenant utiliser ces variables dans core/settings.py pour configurer DATABASE:

# core/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': 'django-images',
            'USER': 'django-images',
            'PASSWORD': 'complexpassword123',
            'HOST': 'localhost',
            'PORT': '5432',
        }
    }

N'oubliez pas d'importer le ospackage en haut de core/settings.py :

import os

Ensuite, nous devons dire à Elastic Beanstalk de s'exécuter makemigrationset migratequand une nouvelle version de l'application est déployée. Nous pouvons le faire en éditant le fichier .ebextensions/01_django.config . Ajoutez ce qui suit au bas du fichier :

# .ebextensions/01_django.config

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true

L'environnement EB exécutera désormais les commandes ci-dessus chaque fois que nous déployons une nouvelle version de l'application. Nous avons utilisé leader_only, donc seule la première instance EC2 les exécute (au cas où notre environnement EB exécute plusieurs instances EC2).

Les configurations Elastic Beanstalk prennent en charge deux sections de commande différentes, les commandes et les conteneur_commands . La principale différence entre eux réside dans le moment où ils sont exécutés dans le processus de déploiement :

  1. commandsexécuté avant que l'application et le serveur Web ne soient configurés et que le fichier de version de l'application ne soit extrait.
  2. container_commandsexécuté après la configuration de l'application et du serveur Web et l'extraction de l'archive de la version de l'application, mais avant le déploiement de la version de l'application (avant que les fichiers ne soient déplacés du dossier intermédiaire vers leur emplacement final).

Ajoutons également une commande pour créer un superutilisateur. Nous pouvons utiliser le cadre de commande personnalisé intuitif de Django pour ajouter une nouvelle commande. Dans l'application "images", créez les fichiers et dossiers suivants :

└-- images
    └-- management
        |-- __init__.py
        └-- commands
            |-- __init__.py
            └-- createsu.py

createsu.py :

# images/management/commands/createsu.py

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


class Command(BaseCommand):
    help = 'Creates a superuser.'

    def handle(self, *args, **options):
        if not User.objects.filter(username='admin').exists():
            User.objects.create_superuser(
                username='admin',
                password='complexpassword123'
            )
        print('Superuser has been created.')

Ensuite, ajoutez la troisième commande de conteneur à .ebextensions/01_django.config :

# .ebextensions/01_django.config

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  # ------------------------------------- new -------------------------------------
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  # --------------------------------- end of new  ---------------------------------

Une alternative à la création d'une createsucommande consiste à se connecter en SSH à l'une des instances EC2 et à exécuter la createsuperusercommande par défaut de Django.

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Attendez que le déploiement se termine. Une fois cela fait, exécutez eb openpour ouvrir votre application dans un nouvel onglet du navigateur. Votre application devrait maintenant fonctionner. Assurez-vous que vous pouvez télécharger une image.

S3 pour le stockage de fichiers

Découvrez la version déployée de votre tableau de bord d'administration. Les fichiers statiques ne sont pas servis correctement. De plus, nous ne voulons pas que les fichiers statiques ou multimédias soient stockés localement sur une instance EC2, car les applications EB doivent être aussi sans état, ce qui facilite grandement la mise à l' échelle de vos applications sur plusieurs instances EC2.

Alors qu'AWS fournit un certain nombre de services de stockage persistant , S3 est sans doute le plus populaire et le plus facile à utiliser.

Pour configurer S3, nous devrons :

  1. Créer un compartiment S3
  2. Créer un groupe et un utilisateur IAM pour la gestion du compartiment S3
  3. Définir les variables d'environnement Elastic Beanstalk S3
  4. Configurer les paramètres statiques et multimédias de Django

Créer un compartiment S3

Pour commencer, créons un nouveau compartiment S3. Accédez à la console AWS S3 et cliquez sur "Créer un compartiment". Donnez au compartiment un nom unique et définissez la région AWS. Utilisez la configuration par défaut pour tout le reste. Appuyez sur "Créer".

Groupe et utilisateur IAM

Accédez à la console IAM . Sur le côté gauche de l'écran, sélectionnez "Groupes d'utilisateurs". Créez un nouveau groupe avec la permission "AmazonS3FullAccess":

Groupe AWS IAM

Ensuite, créez un nouvel utilisateur avec "Accès par programmation" et attribuez ce groupe à l'utilisateur :

Utilisateur AWS IAM

AWS générera des identifiants d'authentification pour vous. Téléchargez le fichier .csv fourni . Nous devrons les transmettre à notre environnement Elastic Beanstalk à l'étape suivante.

Définir les variables d'environnement EB

Ensuite, nous devons définir les variables d'environnement suivantes :

AWS_ACCESS_KEY_ID                - your ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY            - your SECRET_ACCESS_KEY
AWS_S3_REGION_NAME               - your selected S3 region
AWS_STORAGE_BUCKET_NAME          - your bucket name

Accédez à votre console Elastic Beanstalk. Cliquez sur "Configurer". Ensuite, dans la catégorie "Logiciel", cliquez sur "Modifier" et faites défiler jusqu'à la section "Propriétés de l'environnement". Additionnez les quatre variables.

Variables d'environnement AWS Elastic Beanstalk

Après avoir ajouté toutes les variables, cliquez sur "Appliquer".

Configurer les paramètres statiques et multimédias de Django

Ensuite, pour que Django puisse communiquer avec notre compartiment S3, nous devons installer les packages django- storages et boto3 .

Ajoutez-les au fichier requirements.txt :

Django==4.0.2
Pillow==9.0.1
django-tables2==2.4.1
django-crispy-forms==1.14.0
psycopg2-binary==2.9.3
boto3==1.21.3
django-storages==1.12.3

Ensuite, ajoutez l'application nouvellement installée INSTALLED_APPSdans core/settings.py :

# core/settings.py

INSTALLED_APPS = [
    # ...
    'storages',
]

Configurez django-storages pour utiliser les variables d'environnement transmises par Elastic Beanstalk :

if 'AWS_STORAGE_BUCKET_NAME' in os.environ:
    STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
    DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

    AWS_STORAGE_BUCKET_NAME = os.environ['AWS_STORAGE_BUCKET_NAME']
    AWS_S3_REGION_NAME = os.environ['AWS_S3_REGION_NAME']

    AWS_S3_ACCESS_KEY_ID = os.environ['AWS_ACCESS_KEY_ID']
    AWS_S3_SECRET_ACCESS_KEY = os.environ['AWS_SECRET_ACCESS_KEY']

Enfin, nous devons exécuter la collectstaticcommande une fois le déploiement terminé, ajoutez donc ce qui suit au bas de 01_django.config :

# .ebextensions/01_django.config
# ...

container_commands:
  # ...
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Le fichier complet devrait maintenant ressembler à ceci :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Confirmez que les fichiers statiques et multimédias sont maintenant stockés sur S3.

Si vous obtenez une Signature mismatcherreur, vous pouvez ajouter le paramètre suivant à core/settings.py : AWS_S3_ADDRESSING_STYLE = "virtual". Pour plus de détails, reportez-vous à ce problème GitHub .

Pour en savoir plus sur le stockage de fichiers statiques et multimédias sur AWS S3, consultez l' article Stockage de fichiers statiques et multimédias Django sur Amazon S3 .

HTTPS avec le gestionnaire de certificats

Cette partie du tutoriel nécessite que vous disposiez d'un nom de domaine.

Besoin d'un domaine pas cher pour vous entraîner ? Plusieurs bureaux d'enregistrement de domaine ont des promotions sur les domaines '.xyz'. Alternativement, vous pouvez créer un domaine gratuit chez Freenom . Si vous ne possédez pas de nom de domaine, mais souhaitez tout de même utiliser HTTPS, vous pouvez créer et signer avec un certificat X509 .

Pour servir votre application via HTTPS, nous devrons :

  1. Demander et valider un certificat SSL/TLS
  2. Faites pointer votre nom de domaine vers votre EB CNAME
  3. Modifier l'équilibreur de charge pour servir HTTPS
  4. Modifier les paramètres de votre application

Demander et valider un certificat SSL/TLS

Accédez à la console AWS Certificate Manager . Cliquez sur "Demander un certificat". Définissez le type de certificat sur "Public" et cliquez sur "Suivant". Entrez votre nom de domaine complet dans la saisie du formulaire, définissez la "Méthode de validation" sur "Validation DNS", puis cliquez sur "Demander".

AWS demande un certificat public

Vous serez alors redirigé vers une page où vous pourrez voir tous vos certificats. Le certificat que vous venez de créer doit avoir le statut "En attente de validation".

Pour qu'AWS délivre un certificat, vous devez d'abord prouver que vous êtes le propriétaire du domaine. Dans le tableau, cliquez sur le certificat pour afficher les "Détails du certificat". Notez le "nom CNAME" et la "valeur CNAME". Pour valider la propriété du domaine, vous devrez créer un "enregistrement CNAME" dans les paramètres DNS de votre domaine. Utilisez le "nom CNAME" et la "valeur CNAME" pour cela. Une fois cela fait, il faudra quelques minutes à Amazon pour récupérez les modifications de domaine et émettez le certificat. Le statut doit passer de "En attente de validation" à "Émis".

Faites pointer le nom de domaine vers l'EB CNAME

Ensuite, vous devez faire pointer votre domaine (ou sous-domaine) vers votre environnement EB CNAME. De retour dans les paramètres DNS de votre domaine, ajoutez un autre enregistrement CNAME avec la valeur correspondant à votre EB CNAME -- par exemple, django-images-dev.us-west-2.elasticbeanstalk.com.

Attendez quelques minutes que votre DNS se rafraîchisse avant de tester les choses à partir de la http://saveur de votre nom de domaine dans votre navigateur.

Modifier l'équilibreur de charge pour servir HTTPS

De retour dans la console Elastic Beanstalk, cliquez sur « Configuration ». Ensuite, dans la catégorie "Load balancer", cliquez sur "Edit". Cliquez sur "Ajouter un écouteur" et créez un écouteur avec les détails suivants :

  1. Port - 443
  2. Protocole - HTTPS
  3. Certificat SSL - sélectionnez le certificat que vous venez de créer

Cliquez sur "Ajouter". Ensuite, faites défiler vers le bas de la page et cliquez sur "Appliquer". La mise à jour de l'environnement prendra quelques minutes.

Modifier vos paramètres d'application

Ensuite, nous devons apporter quelques modifications à notre application Django.

Tout d'abord, ajoutez votre domaine pleinement qualifié àALLOWED_HOSTS :

# core/settings.py

ALLOWED_HOSTS = [
    # ...
    'yourdomain.com',
]

Enfin, nous devons rediriger tout le trafic de HTTP vers HTTPS. Il existe plusieurs façons de procéder, mais la plus simple consiste à configurer Apache en tant qu'hôte proxy. Nous pouvons y parvenir par programmation en ajoutant ce qui suit à la fin de option_settingsin .ebextensions/01_django.config :

# .ebextensions/01_django.config

option_settings:
  # ...
  aws:elasticbeanstalk:environment:proxy:  # new
    ProxyServer: apache                    # new

Votre fichier final 01_django.config devrait maintenant ressembler à ceci :

# .ebextensions/01_django.config

option_settings:
  aws:elasticbeanstalk:application:environment:
    DJANGO_SETTINGS_MODULE: "core.settings"
    PYTHONPATH: "/var/app/current:$PYTHONPATH"
  aws:elasticbeanstalk:container:python:
    WSGIPath: "core.wsgi:application"
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: apache

container_commands:
  01_makemigrations:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py makemigrations --noinput"
    leader_only: true
  02_migrate:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py migrate --noinput"
    leader_only: true
  03_superuser:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py createsu"
    leader_only: true
  04_collectstatic:
    command: "source /var/app/venv/*/bin/activate && python3 manage.py collectstatic --noinput"
    leader_only: true

Créez ensuite un dossier ".platform" à la racine du projet et ajoutez les fichiers et dossiers suivants :

└-- .platform
    └-- httpd
        └-- conf.d
            └-- ssl_rewrite.conf

ssl_rewrite.conf :

# .platform/httpd/conf.d/ssl_rewrite.conf

RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>

La structure de votre projet devrait maintenant ressembler à ceci :

|-- .ebextensions
|   └-- 01_django.config
|-- .elasticbeanstalk
|   └-- config.yml
|-- .gitignore
|-- .platform
|   └-- httpd
|       └-- conf.d
|           └-- ssl_rewrite.conf
|-- README.md
|-- core
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- urls.py
|   └-- wsgi.py
|-- db.sqlite3
|-- images
|   |-- __init__.py
|   |-- admin.py
|   |-- apps.py
|   |-- forms.py
│   ├── management
│   │   ├── __init__.py
│   │   └── commands
│   │       ├── __init__.py
│   │       └── createsu.py
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   └-- __init__.py
|   |-- models.py
|   |-- tables.py
|   |-- templates
|   |   └-- images
|   |       └-- index.html
|   |-- tests.py
|   |-- urls.py
|   └-- views.py
|-- manage.py
└-- requirements.txt

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Maintenant, dans votre navigateur, la https://saveur de votre application devrait fonctionner. Essayez d'aller à la http://saveur. Vous devriez être redirigé vers la https://saveur. Assurez-vous également que le certificat est correctement chargé :

application sécurisée

Variables d'environnement

En production, il est préférable de stocker la configuration spécifique à l'environnement dans des variables d'environnement . Avec Elastic Beanstalk, vous pouvez définir des variables d'environnement personnalisées de deux manières différentes.

Variables d'environnement via EB CLI

Transformons Django SECRET_KEYet les DEBUGparamètres en variables d'environnement.

Commencez par exécuter :

$ eb setenv DJANGO_SECRET_KEY='<replace me with your own secret key>' \
            DJANGO_DEBUG='1'

Vous pouvez définir plusieurs variables d'environnement avec une seule commande en les séparant par des espaces. Il s'agit de l'approche recommandée car elle n'entraîne qu'une seule mise à jour de l'environnement EB.

Modifiez core/settings.py en conséquence :

# core/settings.py

SECRET_KEY = os.environ.get(
    'DJANGO_SECRET_KEY',
    '<replace me with your own fallback secret key>'
)

DEBUG = os.environ.get('DJANGO_DEBUG', '1').lower() in ['true', 't', '1']

Validez les modifications sur git et déployez :

$ git add .
$ git commit -m "updates for eb"

$ eb deploy

Variables d'environnement via la console EB

Accédez à la console Elastic Beanstalk via eb open. Accédez à "Configuration" > "Logiciel" > "Modifier". Ensuite, faites défiler jusqu'aux "Propriétés de l'environnement".

Variables d'environnement AWS Elastic Beanstalk

Une fois que vous avez terminé, cliquez sur "Appliquer" et votre environnement sera mis à jour.

Vous pouvez ensuite accéder à ces variables dans votre environnement Python via os.environ.

Par exemple:

VARIABLE_NAME = os.environ['VARIABLE_NAME']

Débogage d'Elastic Beanstalk

Lorsque vous travaillez avec Elastic Beanstalk, il peut être assez frustrant de comprendre ce qui ne va pas si vous ne savez pas comment accéder aux fichiers journaux. Dans cette section, nous examinerons exactement cela.

Il existe deux façons d'accéder aux journaux :

  1. CLI ou console Elastic Beanstalk
  2. SSH dans l'instance EC2

Par expérience personnelle, j'ai pu résoudre tous les problèmes avec la première approche.

CLI ou console Elastic Beanstalk

CLI :

$ eb logs

This command will fetch the last 100 lines from the following files:

/var/log/web.stdout.log
/var/log/eb-hooks.log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/eb-engine.log

L'exécution eb logséquivaut à se connecter à la console EB et à naviguer vers "Journaux".

Je recommande de diriger les journaux vers CloudWatch . Exécutez la commande suivante pour l'activer :

$ eb logs --cloudwatch-logs enable

Vous trouverez généralement des erreurs Django dans /var/log/web.stdout.log ou /var/log/eb-engine.log .

Pour en savoir plus sur les journaux Elastic Beanstalk, consultez Affichage des journaux des instances Amazon EC2 .

SSH dans l'instance EC2

Pour vous connecter à une instance EC2 sur laquelle votre application Django est en cours d'exécution, exécutez :

$ eb ssh

Vous serez invité à ajouter l'hôte à vos hôtes connus la première fois. Dis oui. Avec cela, vous aurez désormais un accès complet à votre instance EC2. N'hésitez pas à expérimenter avec les commandes de gestion de Django et à vérifier certains des fichiers journaux mentionnés dans la section précédente.

Gardez à l'esprit qu'Elastic Beanstalk met automatiquement à l'échelle et déploie de nouvelles instances EC2. Les modifications que vous apportez à cette instance EC2 spécifique ne seront pas répercutées sur les instances EC2 nouvellement lancées. Une fois cette instance EC2 spécifique remplacée, vos modifications seront effacées.

Conclusion

Dans ce didacticiel, nous avons parcouru le processus de déploiement d'une application Django sur AWS Elastic Beanstalk. Vous devriez maintenant avoir une bonne compréhension du fonctionnement d'Elastic Beanstalk. Effectuez une auto-vérification rapide en passant en revue les objectifs au début du didacticiel.

Prochaines étapes:

  1. Vous devriez envisager de créer deux environnements EB distincts ( devet production).
  2. Consultez le groupe Auto Scaling pour votre environnement Elastic Beanstalk pour savoir comment configurer des déclencheurs pour la mise à l'échelle automatique de votre application.

Pour supprimer toutes les ressources AWS que nous avons créées tout au long du didacticiel, arrêtez d'abord l'environnement Elastic Beanstalk :

$ eb terminate

Vous devrez supprimer manuellement le compartiment S3, le certificat SSL, ainsi que le groupe et l'utilisateur IAM.

Enfin, vous pouvez trouver la version finale du code dans le référentiel django-elastic-beanstalk sur GitHub.

Source :  https://testdrive.io

#django #aws 

Running Geo Django on ElasticBeanstalk

I want to tell you this story because I wasted about 14 hours to realize how to achieve it correctly.

NB!: Sometimes working with Elastic Beanstalk can be like this.

Long story short

To successfully run GeoDjango on Elasticbeanstalk container using Python 3.6 you need to follow these steps:

  1. Launch EC2 instance from ElasticBeanstalk image ami-0a2fbeb2675c47493. NB! Do not use EC2 instances under the control of ElasticBeanstalk for that purpose. Launch an instance from the source image used by Beanstalk;
  2. Install GDAL 2;
  3. Create a custom AMI;
  4. Run your Django app using this AMI.

The road so far

We have been using ElasticBeanstalk for 2 years to deploy our Django application in one of our projects. However, we weren’t using Geocoding features for our Django app. In one of our services, we decided to use Geo features of Django and enable PostGIS support for the project.

The problem was with missing GDAL 2 library, required for Django. There is GDAL 1 in Amazon Linux’s repositories, but it’s outdated dependency to make Django enable its GeoSpatial features.

I tried to build it from sources, installed on running instance and deployed code. Everything was fine, but I wanted to make it more reliable and be sure that it would work constantly because my changes would be deleted by autoscaling. Hence, I wanted to build a custom** AMI image **with required libraries (I needed two more, that didn’t exist in repositories).

Okay. I ran a clean configuration of the Elastic Beanstalk environment, installed everything, and created a custom AMI from EC2 instance I created using ElasticBeanstalk.

Seems pretty easy, I thought. I tried to create a new environment using this image and I found a problem with environment variables. For an unknown reason, Python container didn’t see the variables I set in the web interface.

I tried to set them using eb command and tried to set them using .ebextensions. Finally, I set them manually and had luck running the Django app, but it was unable to deploy it using eb deploy command.

In the next step I tried to use an updated image with Python 3.7 and Amazon Linux 2, but there were a lot of differences between Amazon Linux and Amazon Linux 2 that required a lot of changes in my deployment configuration.

I started thinking about what’s wrong with my configuration and why it didn’t work. I made a suggestion, that I built custom AMI wrong way and I started from the beginning.

#elastic-beanstalk #aws-elastic-beanstalk #django #python #coding #amazon #aws #ec2

Ahebwe  Oscar

Ahebwe Oscar

1620185280

How model queries work in Django

How model queries work in Django

Welcome to my blog, hey everyone in this article we are going to be working with queries in Django so for any web app that you build your going to want to write a query so you can retrieve information from your database so in this article I’ll be showing you all the different ways that you can write queries and it should cover about 90% of the cases that you’ll have when you’re writing your code the other 10% depend on your specific use case you may have to get more complicated but for the most part what I cover in this article should be able to help you so let’s start with the model that I have I’ve already created it.

**Read More : **How to make Chatbot in Python.

Read More : Django Admin Full Customization step by step

let’s just get into this diagram that I made so in here:

django queries aboutDescribe each parameter in Django querset

we’re making a simple query for the myModel table so we want to pull out all the information in the database so we have this variable which is gonna hold a return value and we have our myModel models so this is simply the myModel model name so whatever you named your model just make sure you specify that and we’re gonna access the objects attribute once we get that object’s attribute we can simply use the all method and this will return all the information in the database so we’re gonna start with all and then we will go into getting single items filtering that data and go to our command prompt.

Here and we’ll actually start making our queries from here to do this let’s just go ahead and run** Python manage.py shell** and I am in my project file so make sure you’re in there when you start and what this does is it gives us an interactive shell to actually start working with our data so this is a lot like the Python shell but because we did manage.py it allows us to do things a Django way and actually query our database now open up the command prompt and let’s go ahead and start making our first queries.

#django #django model queries #django orm #django queries #django query #model django query #model query #query with django