Distribuzione di Django + Python 3 + PostgreSQL su AWS Elastic Beanstalk

Quello che segue è una panoramica su come configurare e distribuire un'applicazione Django, basata su Python 3, e PostgreSQL su Amazon Web Services (AWS), il tutto rimanendo sano di mente.

Strumenti/tecnologie utilizzate:

Python v3.4.3
Django v1.9
Amazon Elastic Beanstalk, EC2, S3 e RDS
EB CLI 3.x
PostgreSQL

Bonus gratuito: Fai clic qui per accedere a una guida gratuita alle risorse di apprendimento di Django (PDF) che mostra suggerimenti e trucchi, nonché le insidie comuni da evitare durante la creazione di applicazioni Web Python + Django.

Dai un'occhiata a Python 2 versione di questo articolo qui.

Aggiornato il 21/08/2016: Aggiornate le impostazioni di configurazione globale di EB.

Elastic Beanstalk vs EC2

Elastic Beanstalk è una piattaforma come servizio (PaaS) che semplifica la configurazione, la distribuzione e la manutenzione della tua app su Amazon AWS. È un servizio gestito, che accoppia il server (EC2), il database (RDS) e i tuoi file statici (S3). Puoi distribuire e gestire rapidamente la tua applicazione, che si ridimensiona automaticamente man mano che il tuo sito cresce. Consulta la documentazione ufficiale per ulteriori informazioni.

Per iniziare

Utilizzeremo una semplice app "Immagine del giorno", che puoi prendere da questo repository:

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

Dopo aver scaricato il codice, crea un virtualenv e installa i requisiti tramite pip:

$ pip install -r requirements.txt

Quindi, con PostgreSQL in esecuzione localmente, imposta un nuovo database chiamato iotd . Inoltre, a seconda della configurazione locale di Postgres, potrebbe essere necessario aggiornare i DATABASES configurazione in settings.py . Ad esempio, ho aggiornato la configurazione a:

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

Ora puoi configurare lo schema del database, creare un superutente ed eseguire l'app:

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

Passa alla pagina di amministrazione del tuo browser all'indirizzo http://localhost:8000/admin e aggiungi una nuova immagine, che verrà quindi visualizzata nella pagina principale.

L'applicazione non è pensata per essere molto eccitante; lo stiamo solo usando a scopo dimostrativo. Tutto ciò che fa è caricare un'immagine tramite l'interfaccia di amministrazione e visualizzare l'immagine a schermo intero nella pagina principale. Detto questo, sebbene si tratti di un'app relativamente semplice, ci consentirà comunque di esplorare una serie di "problemi" che esistono durante la distribuzione su Amazon Beanstalk e RDS.

Ora che il sito è attivo e funzionante sulla nostra macchina locale, iniziamo il processo di distribuzione di Amazon.

CLI per AWS Elastic Beanstalk

Per lavorare con Amazon Elastic Beanstalk, possiamo utilizzare un pacchetto chiamato awsebcli. Al momento della stesura di questo articolo, l'ultima versione di è 3.7.4 e il modo consigliato per installarlo è con pip:

$ pip install awsebcli

Ora prova l'installazione per assicurarti che funzioni:

$ eb --version

Questo dovrebbe darti un bel numero di versione 3.x:

EB CLI 3.7.4 (Python 3.4.3)

Per iniziare effettivamente a utilizzare Elastic Beanstalk avrai bisogno di un account con AWS (sorpresa!). Iscriviti (o accedi).

Configura EB – Inizializza la tua app

Con l'AWS Elastic Beanstalk CLI funzionante, la prima cosa che vogliamo fare è creare un ambiente Beanstalk su cui ospitare l'applicazione. Eseguilo dalla directory del progetto ("immagine-del-giorno"):

$ eb init

Questo ti chiederà una serie di domande per aiutarti a configurare il tuo ambiente.

Regione predefinita

La scelta della regione più vicina ai tuoi utenti finali generalmente fornirà le migliori prestazioni. Dai un'occhiata a questa mappa se non sei sicuro di quale scegliere.

Credenziali

Successivamente, chiederà le tue credenziali AWS.

Qui, molto probabilmente vorrai configurare un utente IAM. Consulta questa guida per come configurarne uno. Se imposti un nuovo utente, dovrai assicurarti che l'utente disponga delle autorizzazioni appropriate. Il modo più semplice per farlo è aggiungere semplicemente "Accesso amministratore" all'utente. (Questa probabilmente non è un'ottima scelta per motivi di sicurezza, tuttavia.) Per le politiche/ruoli specifici di cui un utente ha bisogno per creare/gestire un'applicazione Elastic Beanstalk, vedere il collegamento qui.

Nome dell'applicazione

Questo verrà impostato automaticamente sul nome della directory. Vai con quello.

Versione Python

Successivamente, la CLI dovrebbe rilevare automaticamente che stai utilizzando Python e chiedere semplicemente conferma. Dì di si. Quindi è necessario selezionare una versione della piattaforma. Hai 2 diverse opzioni qui per Python 3:

Python 3.4
Python 3.4 (preconfigurato - Docker)

Se sei un hipster, scegli l'opzione "Preconfigurato - Docker", altrimenti vai con il normale "Python 3.4". No, solo prendere in giro; la differenza fondamentale è questa:

Python 3.4

Questo ti dà un'immagine EC2 che esegue Amazon Linux a 64 bit con Python 3.4 preinstallato. Il server web front-end è apache, con mod_wsgi installato. Questo è il modo "standard" o "tradizionale" in cui funziona Beanstalk. In altre parole, con questa opzione Beanstalk creerà per te immagini EC2 e potrai usare ebextension file di cui parleremo più avanti per personalizzare l'immagine EC2.

Python 3.4 (preconfigurato – Docker)

Questo ti dà un'immagine EC2 che esegue Docker, con un'immagine Docker già configurata per te. L'immagine Docker esegue Debian Jessie a 64 bit con Python 3.4, nginx 1.8 e uWSGI 2.0.8. Poiché fondamentalmente stai interagendo direttamente con l'immagine Docker, se scegli questo percorso utilizzerai le tecniche di configurazione Docker standard (ad esempio, un 'Dockerfile'), e quindi non devi fare molto che sia AWS Beanstalk specifico, poiché Beanstalk sa come gestire l'immagine Docker per te.

Per questo articolo ci concentreremo sul modo "standard" o "tradizionale" di utilizzare un'immagine EC2, quindi scegli l'opzione "Python 3.4" e andiamo avanti.

SSH

Dì di sì alla configurazione di SSH per le tue istanze.

Coppia di chiavi RSA

Successivamente, devi generare una coppia di chiavi RSA, che verrà aggiunta al tuo ~/.ssh cartella. Questa coppia di chiavi verrà anche caricata nella chiave pubblica EC2 per la regione specificata nel passaggio uno. Ciò ti consentirà di accedere a SSH nella tua istanza EC2 più avanti in questo tutorial.

Cosa abbiamo realizzato?

Una volta eb init è terminato, vedrai una nuova cartella nascosta chiamata .elasticbeanstalk nella directory del tuo progetto:

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

All'interno di quella directory c'è un config.yml file, che è un file di configurazione utilizzato per definire determinati parametri per la tua applicazione Beanstalk appena coniata.

A questo punto, se digiti eb console aprirà il tuo browser predefinito e passerà alla console Elastic Beanstalk. Nella pagina dovresti vedere un'applicazione (chiamata image-of-the-day se stai seguendo esattamente), ma nessun ambiente.

Un'applicazione rappresenta la tua applicazione di codice ed è ciò che eb init creato per noi. Con Elastic Beanstalk, un'applicazione può avere più ambienti (ad esempio, sviluppo, test, staging, produzione). Sta a te decidere come configurare/gestire questi ambienti. Per le semplici applicazioni Django mi piace avere l'ambiente di sviluppo sul mio laptop, quindi creare un ambiente di test e di produzione su Beanstalk.

Prepariamo un ambiente di test...

Configura EB – Crea un ambiente

Tornando al terminale, nella directory del tuo progetto digita:

$ eb create

Proprio come eb init , questo comando ti chiederà una serie di domande.

Nome ambiente

Dovresti utilizzare una convenzione di denominazione simile a quella suggerita da Amazon, ad esempio application_name-env_name, specialmente quando/se inizi a ospitare più applicazioni con AWS. Ho usato - iod-test .

Prefisso CNAME DNS

Quando distribuisci un'app su Elastic Beanstalk, otterrai automaticamente un nome di dominio come xxx.elasticbeanstalk.com. DNS CNAME prefix è quello che vuoi usare al posto di xxx . L'impostazione predefinita probabilmente non funzionerà se stai seguendo perché qualcun altro l'ha già utilizzata (i nomi sono globali per AWS), quindi scegli qualcosa di unico e continua.

Cosa succede adesso?

A questo punto eb creerà effettivamente il tuo ambiente per te. Sii paziente perché potrebbe volerci del tempo.

Se viene visualizzato un errore durante la creazione dell'ambiente, ad esempio - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - verifica che le credenziali che stai utilizzando dispongano delle autorizzazioni appropriate per creare l'ambiente Beanstalk, come discusso in precedenza in questo post.

Inoltre, potrebbe richiedere un messaggio su Platform requires a service role . In tal caso, dì semplicemente di sì e lascia che crei il ruolo per te.

Subito dopo la creazione dell'ambiente, eb tenterà di distribuire la tua applicazione, copiando tutto il codice nella directory del tuo progetto nella nuova istanza EC2, eseguendo pip install -r requirements.txt nel processo.

Dovresti vedere una serie di informazioni sull'ambiente in fase di configurazione visualizzate sullo schermo, oltre a informazioni su eb cercando di schierare. Vedrai anche alcuni errori. In particolare dovresti vedere queste righe sepolte da qualche parte nell'output:

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

Non preoccuparti:non è davvero valido. Controlla i log per i dettagli:

$ eb logs

Questo acquisirà tutti i file di registro recenti dall'istanza EC2 e li emetterà sul tuo terminale. Sono molte informazioni, quindi potresti voler reindirizzare l'output a un file (eb logs -z ). Esaminando i registri, vedrai un file di registro denominato eb-activity.log :

Error: pg_config executable not found.

Il problema è che abbiamo provato ad installare psycopy2 (i collegamenti Python di Postgres), ma abbiamo bisogno che anche i driver client di Postgres siano installati. Poiché non sono installati per impostazione predefinita, è necessario installarli prima. Risolviamolo...

Personalizzazione del processo di distribuzione

eb leggerà .config personalizzato file da una cartella chiamata ".ebextensions" al livello principale del tuo progetto (directory "immagine-del-giorno"). Questi .config i file consentono di installare pacchetti, eseguire comandi arbitrari e/o impostare variabili di ambiente. I file nella directory ".ebextensions" devono essere conformi a JSON o YAML sintassi e vengono eseguiti in ordine alfabetico.

Installazione dei pacchetti

La prima cosa che dobbiamo fare è installare alcuni pacchetti in modo che il nostro pip install il comando verrà completato correttamente. Per fare ciò, creiamo prima un file chiamato .ebextensions/01_packages.config :

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

Le istanze EC2 eseguono Amazon Linux, che è una versione di Redhat, quindi possiamo utilizzare yum per installare i pacchetti di cui abbiamo bisogno. Per ora, installeremo solo tre pacchetti:git, il client Postgres e libjpeg per Pillow.

Dopo aver creato quel file per ridistribuire l'applicazione, dobbiamo fare quanto segue:

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

Dobbiamo eseguire il commit delle modifiche perché il comando di distribuzione eb deploy funziona con l'ultimo commit e quindi sarà a conoscenza delle modifiche ai nostri file solo dopo che le avremo impegnate in git. (Nota però che non dobbiamo spingere; stiamo lavorando dalla nostra copia locale...)

Come probabilmente avrai intuito, il comando successivo è:

$ eb deploy

Ora dovresti vedere solo un errore:

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.

Scopriamo cosa sta succedendo...

Configurazione del nostro ambiente Python

Le istanze EC2 in Beanstalk eseguono Apache e Apache troverà la nostra app Python in base al WSGIPATH che abbiamo impostato. Per impostazione predefinita eb presuppone che il nostro file wsgi si chiami application.py . Ci sono due modi per correggere questo:

Opzione 1:utilizzo delle impostazioni di configurazione specifiche dell'ambiente

$ eb config

Questo comando aprirà il tuo editor predefinito, modificando un file di configurazione chiamato .elasticbeanstalk/iod-test.env.yml . Questo file in realtà non esiste localmente; eb l'ha tirato giù dai server AWS e te lo ha presentato in modo che tu possa modificarne le impostazioni. Se apporti modifiche a questo pseudo-file e poi salvi ed esci, eb aggiornerà le impostazioni corrispondenti nel tuo ambiente Beanstalk.

Se cerchi i termini "WSGI" nel file e dovresti trovare una sezione di configurazione simile a questa:

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

Aggiorna il WSGIPath:

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

E poi avrai il tuo WSGIPath impostato correttamente. Se poi salvi il file ed esci, eb aggiornerà automaticamente la configurazione dell'ambiente:

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.

Il vantaggio di usare eb config il metodo per modificare le impostazioni è che puoi specificare impostazioni diverse per ambiente. Ma puoi anche aggiornare le impostazioni usando lo stesso .config file che stavamo utilizzando prima. Questo utilizzerà le stesse impostazioni per ogni ambiente, come .config i file verranno applicati al momento della distribuzione (dopo le impostazioni da eb config sono stati applicati).

Opzione 2:utilizzo delle impostazioni di configurazione globali

Per utilizzare il .config opzione file, creiamo un nuovo file chiamato /.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/"

Cosa sta succedendo?

DJANGO_SETTINGS_MODULE: "iotd.settings" - aggiunge il percorso al modulo delle impostazioni.
"PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH" - aggiorna il nostro PYTHONPATH così Python può trovare i moduli nella nostra applicazione. Questo percorso può variare a seconda della tua configurazione! Vedi questo commento per maggiori dettagli. (Nota che è necessario l'uso del percorso completo.)
WSGIPath: iotd/iotd/wsgi.py imposta il nostro percorso WSGI.
NumProcesses: 3 e NumThreads: 20 - aggiorna il numero di processi e thread utilizzati per eseguire la nostra applicazione WSGI.
"/static/": "www/static/" imposta il nostro percorso dei file statici.

Ancora una volta, possiamo eseguire un git commit quindi un eb deploy per aggiornare queste impostazioni.

Quindi aggiungiamo un database.

Configurazione di un database

Prova a visualizzare il sito Web distribuito:

$ eb open

Questo comando mostrerà l'applicazione distribuita nel browser predefinito. Dovresti vedere un errore di connessione rifiutata:

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?

Questo perché non abbiamo ancora impostato un database. A questo punto eb imposterà il tuo ambiente Beanstalk, ma non configurerà RDS (il livello di database). Dobbiamo configurarlo manualmente.

Configurazione del database

Ancora una volta, usa eb console per aprire la pagina di configurazione di Beanstalk.

Da lì, procedi come segue:

Fai clic sul link "Configurazione".
Scorri fino in fondo alla pagina, quindi nella sezione "Livello dati", fai clic sul link "crea un nuovo database RDS".
Nella pagina di configurazione di RDS cambia "DB Engine" in "postgres".
Aggiungi un "Nome utente principale" e una "Password principale".
Salva le modifiche.

Beanstalk creerà l'RDS per te. Ora dobbiamo ottenere la nostra app Django per connettersi all'RDS. Beanstalk ci aiuterà qui esponendo una serie di variabili di ambiente sulle istanze EC2 che descrivono in dettaglio come connettersi al server Postgres. Quindi tutto ciò che dobbiamo fare è aggiornare il nostro settings.py file per sfruttare queste variabili di ambiente. Conferma che il DATABASES parametro di configurazione riflette quanto segue in settings.py :

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

Questo dice semplicemente "usa le impostazioni delle variabili di ambiente se presenti, altrimenti usa le nostre impostazioni di sviluppo predefinite". Semplice.

Gestione delle migrazioni del database

Con la nostra configurazione del database, dobbiamo comunque assicurarci che le migrazioni vengano eseguite in modo che la struttura della tabella del database sia corretta. Possiamo farlo modificando .ebextensions/02_python.config e aggiungendo le seguenti righe nella parte superiore del file:

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

container_commands consentono di eseguire comandi arbitrari dopo che l'applicazione è stata distribuita nell'istanza EC2. Poiché l'istanza EC2 è configurata utilizzando un ambiente virtuale, dobbiamo prima attivare tale ambiente virtuale prima di eseguire il comando di migrazione. Anche il leader_only: true impostazione significa "esegui questo comando solo sulla prima istanza durante la distribuzione su più istanze".

Non dimenticare che la nostra applicazione utilizza l'amministratore di Django, quindi avremo bisogno di un superutente...

Crea l'utente amministratore

Sfortunatamente createsuperuser non ti consente di specificare una password quando usi il --noinput opzione, quindi dovremo scrivere il nostro comando. Fortunatamente, Django rende molto facile creare comandi personalizzati.

Crea il file 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")

Assicurati di aggiungere il __init__.py appropriato anche i file:

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

Questo file ti permetterà di eseguire python manage.py createsu e creerà un superutente senza richiedere una password. Sentiti libero di espandere il comando per utilizzare le variabili di ambiente o un altro mezzo per consentirti di modificare la password.

Una volta creato il comando, possiamo semplicemente aggiungere un altro comando al nostro container_commands sezione in .ebextensions/02_python.config :

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

Prima di testarlo, assicuriamoci che i nostri file statici siano tutti inseriti nella posizione corretta...

File statici

Aggiungi un altro comando in container_commands :

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

Quindi l'intero file ha questo aspetto:

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/"

Ora dobbiamo assicurarci che STATIC_ROOT è impostato correttamente in settings.py file:

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

Assicurati di eseguire il commit di www directory su git in modo da poter creare la directory statica. Quindi esegui eb deploy di nuovo, e ora dovresti essere in attività:

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.

A questo punto dovresti essere in grado di andare su http://your_app_url/admin, accedere, aggiungere un'immagine e quindi vedere quell'immagine visualizzata nella pagina principale della tua applicazione.

Successo!

Utilizzo di S3 per l'archiviazione multimediale

Con questa configurazione, ogni volta che distribuiamo nuovamente, perderemo tutte le nostre immagini caricate. Come mai? Bene, quando esegui eb deploy , viene creata una nuova istanza per te. Questo non è ciò che vogliamo poiché avremo quindi voci nel database per le immagini, ma nessuna immagine associata. La soluzione è archiviare i file multimediali in Amazon Simple Storage Service (Amazon S3) anziché nell'istanza EC2 stessa.

Dovrai:

Crea un bucket
Prendi l'ARN (Amazon Resource Name) del tuo utente
Aggiungi autorizzazioni per il bucket
Configura la tua app Django per utilizzare S3 per servire i tuoi file statici

Dal momento che ci sono già buone recensioni su questo, ti indicherò solo il mio preferito:utilizzo di Amazon S3 per archiviare file Django statici e multimediali

Configurazione di Apache

Dato che stiamo usando Apache con Beanstalk, probabilmente vorremmo configurare Apache per (tra le altre cose) abilitare la compressione gzip in modo che i file vengano scaricati più velocemente dai client. Questo può essere fatto con container_commands . Crea un nuovo file .ebextensions/03_apache.config e aggiungi quanto segue:

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

Quindi devi creare il file .ebextensions/enable_mod_deflate.conf :

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

In questo modo abiliterai la compressione gzip, che dovrebbe aiutare con le dimensioni dei file che stai scaricando. Puoi anche utilizzare la stessa strategia per minimizzare e combinare automaticamente i tuoi CSS/JS ed eseguire qualsiasi altra preelaborazione che devi eseguire.

Risoluzione dei problemi

Non dimenticare l'utilissimo eb ssh comando, che ti porterà nell'istanza EC2 in modo da poter dare un'occhiata e vedere cosa sta succedendo. Durante la risoluzione dei problemi, ci sono alcune directory di cui dovresti essere a conoscenza:

/opt/python :radice di dove finirà l'applicazione.
/opt/python/current/app :l'applicazione corrente ospitata nell'ambiente.
/opt/python/on-deck/app :L'app viene inizialmente inserita nel deck e quindi, al termine di tutta la distribuzione, verrà spostata in current . Se riscontri errori nei tuoi container_commands , dai un'occhiata al on-deck cartella e non il current cartella.
/opt/python/current/env :Tutte le variabili env che eb si preparerà per te. Se stai cercando di riprodurre un errore, potresti prima aver bisogno di source /opt/python/current/env per impostare le cose come sarebbero quando eb deploy è in esecuzione.
opt/python/run/venv :l'ambiente virtuale utilizzato dalla tua applicazione; dovrai anche eseguire source /opt/python/run/venv/bin/activate se stai cercando di riprodurre un errore.

Conclusione

La distribuzione su Elastic Beanstalk può essere un po' scoraggiante all'inizio, ma una volta capito dove sono tutte le parti e come funzionano, in realtà è abbastanza facile ed estremamente flessibile. Ti offre anche un ambiente che si ridimensionerà automaticamente all'aumentare del tuo utilizzo. Spero che ormai tu abbia abbastanza per essere pericoloso! Buona fortuna per la tua prossima distribuzione di Beanstalk.

Ci siamo persi qualcosa? Hai altri suggerimenti o trucchi? Si prega di commentare di seguito.