Bereitstellen einer Django-App für AWS Elastic Beanstalk

Wenn Sie beim Erstellen der Umgebung einen Fehler erhalten, z. B. - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - Überprüfen Sie, ob die von Ihnen verwendeten Anmeldeinformationen über die entsprechenden Berechtigungen zum Erstellen der Beanstalk-Umgebung verfügen, wie zuvor in diesem Beitrag besprochen.

Unmittelbar nachdem die Umgebung erstellt wurde, eb versucht, Ihre Anwendung bereitzustellen, indem es den gesamten Code in Ihrem Projektverzeichnis in die neue EC2-Instance kopiert und pip install -r requirements.txt ausführt dabei.

Sie sollten eine Reihe von Informationen über die eingerichtete Umgebung sowie Informationen über eb auf Ihrem Bildschirm sehen versuchen bereitzustellen. Sie werden auch einige Fehler sehen. Insbesondere sollten Sie diese Zeilen irgendwo in der Ausgabe vergraben sehen:

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

Keine Sorge – es ist nicht wirklich ungültig. Einzelheiten finden Sie in den Protokollen:

$ eb logs

Dadurch werden alle aktuellen Protokolldateien von der EC2-Instance abgerufen und an Ihr Terminal ausgegeben. Es sind viele Informationen, daher möchten Sie die Ausgabe möglicherweise in eine Datei umleiten (eb logs -z ). Beim Durchsehen der Protokolle sehen Sie eine Protokolldatei mit dem Namen eb-activity.log :

Error: pg_config executable not found.

Das Problem ist, dass wir versucht haben, psycopy2 zu installieren (die Postgres-Python-Bindungen), aber wir müssen auch die Postgres-Client-Treiber installieren. Da sie nicht standardmäßig installiert sind, müssen wir sie zuerst installieren. Lassen Sie uns das beheben …

Anpassen des Bereitstellungsprozesses

eb liest benutzerdefinierte .config Dateien aus einem Ordner namens „.ebextensions“ auf der Stammebene Ihres Projekts („Tagesbild“-Verzeichnis). Diese .config Dateien ermöglichen es Ihnen, Pakete zu installieren, beliebige Befehle auszuführen und/oder Umgebungsvariablen zu setzen. Dateien im Verzeichnis „.ebextensions“ sollten entweder JSON entsprechen oder YAML Syntax und werden in alphabetischer Reihenfolge ausgeführt.

Pakete installieren

Als erstes müssen wir einige Pakete installieren, damit unsere pip install Befehl wird erfolgreich abgeschlossen. Dazu erstellen wir zunächst eine Datei namens .ebextensions/01_packages.config :

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

EC2-Instances führen Amazon Linux aus, eine Redhat-Variante, sodass wir yum verwenden können, um die benötigten Pakete zu installieren. Im Moment werden wir nur zwei Pakete installieren – git und den Postgres-Client.

Nach dem Erstellen dieser Datei zum erneuten Bereitstellen der Anwendung müssen wir Folgendes tun:

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

Wir müssen die Änderungen festschreiben, da der Deployment-Befehl eb deploy arbeitet mit dem letzten Commit und wird sich daher unserer Dateiänderungen erst bewusst, nachdem wir sie an git übergeben haben. (Beachten Sie jedoch, dass wir nicht pushen müssen; wir arbeiten von unserer lokalen Kopie aus …)

Wie Sie wahrscheinlich erraten haben, lautet der nächste Befehl:

$ eb deploy

Sie sollten jetzt nur einen Fehler sehen:

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

Lassen Sie uns herausfinden, was passiert …

Konfigurieren unserer Python-Umgebung

EC2-Instances in Beanstalk führen Apache aus, und Apache findet unsere Python-App gemäß dem von uns festgelegten WSGIPATH. Standardmäßig eb geht davon aus, dass unsere wsgi-Datei application.py heißt . Es gibt zwei Möglichkeiten, dies zu korrigieren-

Option 1:Umgebungsspezifische Konfigurationseinstellungen verwenden

$ eb config

Dieser Befehl öffnet Ihren Standard-Editor und bearbeitet eine Konfigurationsdatei namens .elasticbeanstalk/iod-test.env.yml . Diese Datei existiert nicht wirklich lokal; eb hat es von den AWS-Servern heruntergezogen und Ihnen präsentiert, damit Sie die Einstellungen darin ändern können. Wenn Sie Änderungen an dieser Pseudodatei vornehmen und dann speichern und beenden, eb aktualisiert die entsprechenden Einstellungen in Ihrer Beanstalk-Umgebung.

Wenn Sie in der Datei nach den Begriffen „WSGI“ suchen, sollten Sie einen Konfigurationsabschnitt finden, der so aussieht:

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

Aktualisieren Sie den WSGIPath:

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

Und dann haben Sie Ihren WSGIPath korrekt eingerichtet. Wenn Sie die Datei dann speichern und beenden, wird eb wird die Umgebungskonfiguration automatisch aktualisieren:

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

Der Vorteil bei der Verwendung der eb config Methode zum Ändern von Einstellungen besteht darin, dass Sie unterschiedliche Einstellungen pro Umgebung angeben können. Aber Sie können die Einstellungen auch mit derselben .config aktualisieren Dateien, die wir zuvor verwendet haben. Dies verwendet die gleichen Einstellungen für jede Umgebung wie die .config Dateien werden beim Deployment angewendet (nach den Einstellungen von eb config angewendet wurden).

Option 2:Globale Konfigurationseinstellungen verwenden

Um die .config zu verwenden file Option erstellen wir eine neue Datei namens /.ebextensions/02_python.config :

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

Was ist los?

• DJANGO_SETTINGS_MODULE: "iotd.settings" - fügt den Pfad zum Einstellungsmodul hinzu.
• "PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH" - aktualisiert unseren PYTHONPATH damit Python die Module in unserer Anwendung finden kann. (Beachten Sie, dass die Verwendung des vollständigen Pfads erforderlich ist.)
• WSGIPath: iotd/iotd/wsgi.py legt unseren WSGI-Pfad fest.
• NumProcesses: 3 und NumThreads: 20 - aktualisiert die Anzahl der Prozesse und Threads, die zum Ausführen unserer WSGI-Anwendung verwendet werden.
• "/static/": "www/static/" setzt unseren statischen Dateipfad.

Auch hier können wir einen git commit durchführen dann ein eb deploy um diese Einstellungen zu aktualisieren.

Als nächstes fügen wir eine Datenbank hinzu.

Konfigurieren einer Datenbank

Versuchen Sie, die bereitgestellte Website anzuzeigen:

$ eb open

Dieser Befehl zeigt die bereitgestellte Anwendung in Ihrem Standardbrowser an. Sie sollten einen Verbindungsverweigerungsfehler sehen:

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

Dies liegt daran, dass wir noch keine Datenbank eingerichtet haben. An dieser Stelle eb richtet Ihre Beanstalk-Umgebung ein, aber nicht RDS (die Datenbankschicht). Wir müssen das manuell einrichten.

Datenbankeinrichtung

Verwenden Sie erneut die eb console um die Beanstalk-Konfigurationsseite zu öffnen.

Gehen Sie von dort aus wie folgt vor:

1. Klicken Sie auf den Link „Konfiguration“.
2. Scrollen Sie ganz nach unten auf der Seite und klicken Sie dann im Abschnitt „Datenebene“ auf den Link „Neue RDS-Datenbank erstellen“.
3. Ändern Sie auf der RDS-Setup-Seite die „DB Engine“ in „postgres“.
4. Fügen Sie einen „Master-Benutzernamen“ und ein „Master-Passwort“ hinzu.
5. Speichern Sie die Änderungen.

Beanstalk erstellt das RDS für Sie. Jetzt müssen wir unsere Django-App dazu bringen, sich mit dem RDS zu verbinden. Beanstalk wird uns hier helfen, indem es eine Reihe von Umgebungsvariablen auf den EC2-Instances für uns bereitstellt, die detailliert beschreiben, wie eine Verbindung zum Postgres-Server hergestellt wird. Wir müssen also nur unsere settings.py aktualisieren Datei, um diese Umgebungsvariablen zu nutzen. Bestätigen Sie, dass die DATABASES Konfigurationsparameter spiegelt Folgendes in settings.py wider :

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

Hier steht einfach:„Verwenden Sie die Einstellungen der Umgebungsvariablen, falls vorhanden, ansonsten verwenden Sie unsere Standardentwicklungseinstellungen“. Einfach.

Handhabung von Datenbankmigrationen

Bei unserem Datenbank-Setup müssen wir noch sicherstellen, dass Migrationen durchgeführt werden, damit die Datenbanktabellenstruktur korrekt ist. Wir können das tun, indem wir .ebextensions/02_python.config ändern und Hinzufügen der folgenden Zeilen am Anfang der Datei:

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

container_commands ermöglichen es Ihnen, beliebige Befehle auszuführen, nachdem die Anwendung auf der EC2-Instance bereitgestellt wurde. Da die EC2-Instance mithilfe einer virtuellen Umgebung eingerichtet wird, müssen wir diese virtuelle Umgebung zuerst aktivieren, bevor wir unseren Migrationsbefehl ausführen. Auch der leader_only: true Einstellung bedeutet:„Diesen Befehl nur auf der ersten Instanz ausführen, wenn auf mehreren Instanzen bereitgestellt wird“.

Vergessen Sie nicht, dass unsere Anwendung den Admin von Django verwendet, also brauchen wir einen Superuser …

Erstellen Sie den Admin-Benutzer

Leider createsuperuser erlaubt Ihnen nicht, ein Passwort anzugeben, wenn Sie --noinput verwenden Option, also müssen wir unseren eigenen Befehl schreiben. Glücklicherweise macht es Django sehr einfach, benutzerdefinierte Befehle zu erstellen.

Erstellen Sie die Datei iotd/images/management/commands/createsu.py :

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


class Command(BaseCommand):

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

Stellen Sie sicher, dass Sie die entsprechende __init__.py hinzufügen auch Dateien:

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

Mit dieser Datei können Sie python manage.py createsu ausführen , und es wird ein Superuser erstellt, ohne zur Eingabe eines Passworts aufzufordern. Fühlen Sie sich frei, den Befehl zu erweitern, um Umgebungsvariablen oder andere Mittel zu verwenden, mit denen Sie das Passwort ändern können.

Sobald Sie den Befehl erstellt haben, können wir einfach einen weiteren Befehl zu unseren container_commands hinzufügen Abschnitt in .ebextensions/02_python.config :

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

Bevor Sie dies testen, sollten wir sicherstellen, dass unsere statischen Dateien alle an der richtigen Stelle abgelegt sind …

Statische Dateien

Fügen Sie einen weiteren Befehl unter container_commands hinzu :

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

Die gesamte Datei sieht also so aus:

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

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

Wir müssen nun sicherstellen, dass die STATIC_ROOT in der settings.py korrekt eingestellt ist Datei:

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

Stellen Sie sicher, dass Sie www übergeben Verzeichnis nach git, damit das statische Verzeichnis erstellt werden kann. Führen Sie dann eb deploy aus wieder, und Sie sollten jetzt im Geschäft sein:

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

An diesem Punkt sollten Sie in der Lage sein, zu http://your_app_url/admin zu gehen, sich anzumelden, ein Bild hinzuzufügen und dieses Bild dann auf der Hauptseite Ihrer Anwendung anzuzeigen.

Erfolg!

S3 als Medienspeicher verwenden

Mit diesem Setup gehen bei jeder erneuten Bereitstellung alle unsere hochgeladenen Bilder verloren. Wieso den? Nun, wenn Sie eb deploy ausführen , wird eine neue Instanz für Sie erstellt. Das wollen wir nicht, da wir dann zwar Einträge in der Datenbank für die Bilder haben, aber keine zugehörigen Bilder. Die Lösung besteht darin, die Mediendateien in Amazon Simple Storage Service (Amazon S3) statt auf der EC2-Instance selbst zu speichern.

Sie müssen:

1. Bucket erstellen
2. Suchen Sie den ARN (Amazon-Ressourcenname) Ihres Benutzers
3. Bucket-Berechtigungen hinzufügen
4. Konfigurieren Sie Ihre Django-App so, dass sie S3 verwendet, um Ihre statischen Dateien bereitzustellen

Da es bereits gute Berichte dazu gibt, zeige ich Sie nur auf meinen Favoriten:Amazon S3 zum Speichern Ihrer statischen Django- und Mediendateien verwenden

Apache-Konfiguration

Da wir Apache mit Beanstalk verwenden, möchten wir wahrscheinlich Apache so einrichten, dass (unter anderem) die gzip-Komprimierung aktiviert wird, damit Dateien von den Clients schneller heruntergeladen werden. Das geht mit container_commands . Erstellen Sie eine neue Datei .ebextensions/03_apache.config und fügen Sie Folgendes hinzu:

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

Dann müssen Sie die Datei .ebextensions/enable_mod_deflate.conf erstellen :

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

Dadurch wird die gzip-Komprimierung aktiviert, was bei der Größe der heruntergeladenen Dateien helfen sollte. Sie können dieselbe Strategie auch verwenden, um Ihr CSS/JS automatisch zu verkleinern und zu kombinieren und alle anderen erforderlichen Vorverarbeitungen durchzuführen.

Fehlerbehebung

Vergessen Sie nicht das sehr hilfreiche eb ssh Befehl, der Sie in die EC2-Instanz bringt, damit Sie herumstöbern und sehen können, was los ist. Bei der Fehlersuche sollten Sie einige Verzeichnisse beachten:

• /opt/python - Stammverzeichnis, in dem Ihre Anwendung landen wird.
• /opt/python/current/app - Die aktuelle Anwendung, die in der Umgebung gehostet wird.
• /opt/python/on-deck/app - Die App wird zunächst auf dem Deck installiert und dann, nachdem die Bereitstellung abgeschlossen ist, zu current verschoben . Wenn Sie Fehler in Ihren container_commands erhalten , sehen Sie sich on-deck an Ordner und nicht der current Ordner.
• /opt/python/current/env - Alle env-Variablen, die eb wird für Sie eingerichtet. Wenn Sie versuchen, einen Fehler zu reproduzieren, müssen Sie möglicherweise zuerst source /opt/python/current/env um die Dinge so einzurichten, wie sie wären, wenn eb deploy läuft.
• opt/python/run/venv - Die virtuelle Umgebung, die von Ihrer Anwendung verwendet wird; Sie müssen auch source /opt/python/run/venv/bin/activate ausführen wenn Sie versuchen, einen Fehler zu reproduzieren

Schlussfolgerung

Die Bereitstellung auf Elastic Beanstalk kann zunächst etwas entmutigend sein, aber sobald Sie verstanden haben, wo sich alle Teile befinden und wie die Dinge funktionieren, ist es eigentlich ziemlich einfach und äußerst flexibel. Es gibt Ihnen auch eine Umgebung, die automatisch skaliert wird, wenn Ihre Nutzung wächst. Hoffentlich hast du jetzt genug, um gefährlich zu sein! Viel Glück bei Ihrem nächsten Beanstalk-Einsatz.

Haben wir etwas verpasst? Haben Sie weitere Tipps oder Tricks? Bitte kommentieren Sie unten.