1660058040
Dans ce didacticiel, nous allons parcourir le processus de déploiement d'une application Django prête pour la production sur AWS Elastic Beanstalk.
À la fin de ce didacticiel, vous serez en mesure de :
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 :
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 .
Avant de plonger dans le didacticiel lui-même, examinons quelques concepts clés liés à Elastic Beanstalk :
Ces termes seront utilisés tout au long du didacticiel.
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 :
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 :
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 .
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.
Dans la racine du projet ("django-images"), exécutez :
$ eb init
Un certain nombre de questions vous seront posées.
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.
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".
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 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".
Pour nous connecter ultérieurement aux instances EC2, nous devons configurer SSH. Dites "oui" lorsque vous y êtes invité.
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
Ensuite, créons l'environnement Elastic Beanstalk et déployons l'application :
$ eb create
Encore une fois, vous serez invité à poser quelques questions.
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
└-env
ou└-dev
de suffixer à vos environnements afin de pouvoir différencier facilement les applications EB des environnements.
Votre application Web sera accessible à l'adresse %cname%.%region%.elasticbeanstalk.com
. Encore une fois, utilisez la valeur par défaut.
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 .
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é :
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
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.
$ 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
$ eb console
Cette commande ouvrira la console Elastic Beanstalk dans votre navigateur par défaut :
Encore une fois, vous pouvez voir que la santé de l'environnement est "sévère", ce que nous corrigerons à l'étape suivante.
À 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 :
PYTHONPATH
pour trouver des modules dans notre application.DJANGO_SETTINGS_MODULE
de 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:
PYTHONPATH
chemin Python sur notre instance EC2 ( docs ).DJANGO_SETTINGS_MODULE
vers nos paramètres Django ( docs ).WSGIPath
par notre application WSGI ( docs ).Comment fonctionnent les fichiers EB .config ?
- Vous pouvez en avoir autant que vous le souhaitez.
- Ils sont chargés dans l'ordre suivant : 01_x, 02_x, 03_x, etc.
- 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_HOSTS
in 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 open
pour 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.
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 .
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 DATABASE
configuration 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
DisallowedHost
erreur, ajoutezlocalhost
et127.0.0.1
à l'ALLOWED_HOSTS
intérieur de core/settings.py .
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":
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,
micro
assurez-vous de consulter la tarification AWS PostgreSQL .
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 os
package en haut de core/settings.py :
import os
Ensuite, nous devons dire à Elastic Beanstalk de s'exécuter makemigrations
et migrate
quand 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 :
commands
exé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.container_commands
exé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
createsu
commande consiste à se connecter en SSH à l'une des instances EC2 et à exécuter lacreatesuperuser
commande 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 open
pour ouvrir votre application dans un nouvel onglet du navigateur. Votre application devrait maintenant fonctionner. Assurez-vous que vous pouvez télécharger une image.
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 :
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".
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":
Ensuite, créez un nouvel utilisateur avec "Accès par programmation" et attribuez ce groupe à l'utilisateur :
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.
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.
Après avoir ajouté toutes les variables, cliquez sur "Appliquer".
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_APPS
dans 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 collectstatic
commande 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 mismatch
erreur, 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 .
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 :
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".
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".
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.
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 :
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.
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_settings
in .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é :
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.
Transformons Django SECRET_KEY
et les DEBUG
paramè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
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".
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']
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 :
Par expérience personnelle, j'ai pu résoudre tous les problèmes avec la première approche.
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 .
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.
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:
dev
et production
).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
1620177818
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.
#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
1619205540
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
1660058040
Dans ce didacticiel, nous allons parcourir le processus de déploiement d'une application Django prête pour la production sur AWS Elastic Beanstalk.
À la fin de ce didacticiel, vous serez en mesure de :
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 :
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 .
Avant de plonger dans le didacticiel lui-même, examinons quelques concepts clés liés à Elastic Beanstalk :
Ces termes seront utilisés tout au long du didacticiel.
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 :
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 :
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 .
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.
Dans la racine du projet ("django-images"), exécutez :
$ eb init
Un certain nombre de questions vous seront posées.
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.
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".
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 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".
Pour nous connecter ultérieurement aux instances EC2, nous devons configurer SSH. Dites "oui" lorsque vous y êtes invité.
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
Ensuite, créons l'environnement Elastic Beanstalk et déployons l'application :
$ eb create
Encore une fois, vous serez invité à poser quelques questions.
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
└-env
ou└-dev
de suffixer à vos environnements afin de pouvoir différencier facilement les applications EB des environnements.
Votre application Web sera accessible à l'adresse %cname%.%region%.elasticbeanstalk.com
. Encore une fois, utilisez la valeur par défaut.
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 .
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é :
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
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.
$ 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
$ eb console
Cette commande ouvrira la console Elastic Beanstalk dans votre navigateur par défaut :
Encore une fois, vous pouvez voir que la santé de l'environnement est "sévère", ce que nous corrigerons à l'étape suivante.
À 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 :
PYTHONPATH
pour trouver des modules dans notre application.DJANGO_SETTINGS_MODULE
de 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:
PYTHONPATH
chemin Python sur notre instance EC2 ( docs ).DJANGO_SETTINGS_MODULE
vers nos paramètres Django ( docs ).WSGIPath
par notre application WSGI ( docs ).Comment fonctionnent les fichiers EB .config ?
- Vous pouvez en avoir autant que vous le souhaitez.
- Ils sont chargés dans l'ordre suivant : 01_x, 02_x, 03_x, etc.
- 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_HOSTS
in 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 open
pour 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.
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 .
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 DATABASE
configuration 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
DisallowedHost
erreur, ajoutezlocalhost
et127.0.0.1
à l'ALLOWED_HOSTS
intérieur de core/settings.py .
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":
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,
micro
assurez-vous de consulter la tarification AWS PostgreSQL .
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 os
package en haut de core/settings.py :
import os
Ensuite, nous devons dire à Elastic Beanstalk de s'exécuter makemigrations
et migrate
quand 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 :
commands
exé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.container_commands
exé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
createsu
commande consiste à se connecter en SSH à l'une des instances EC2 et à exécuter lacreatesuperuser
commande 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 open
pour ouvrir votre application dans un nouvel onglet du navigateur. Votre application devrait maintenant fonctionner. Assurez-vous que vous pouvez télécharger une image.
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 :
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".
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":
Ensuite, créez un nouvel utilisateur avec "Accès par programmation" et attribuez ce groupe à l'utilisateur :
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.
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.
Après avoir ajouté toutes les variables, cliquez sur "Appliquer".
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_APPS
dans 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 collectstatic
commande 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 mismatch
erreur, 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 .
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 :
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".
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".
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.
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 :
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.
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_settings
in .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é :
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.
Transformons Django SECRET_KEY
et les DEBUG
paramè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
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".
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']
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 :
Par expérience personnelle, j'ai pu résoudre tous les problèmes avec la première approche.
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 .
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.
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:
dev
et production
).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
1593526920
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.
To successfully run GeoDjango on Elasticbeanstalk container using Python 3.6 you need to follow these steps:
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
1620185280
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:
Describe 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