Distribuera Django + Python 3 + PostgreSQL till AWS Elastic Beanstalk

Följande är en riktig genomgång av hur man ställer in och distribuerar en Django-applikation, som drivs av Python 3, och PostgreSQL till Amazon Web Services (AWS) samtidigt som man förblir sund.

Använda verktyg/tekniker:

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

Gratis bonus: Klicka här för att få tillgång till en gratis guide för Django Learning Resources (PDF) som visar dig tips och tricks samt vanliga fallgropar att undvika när du bygger Python + Django webbapplikationer.

Kolla in Python 2 version av denna artikel här.

Uppdaterad 2016-08-21: Uppdaterade EB globala konfigurationsinställningar.

Elastic Beanstalk vs EC2

Elastic Beanstalk är en plattform som en tjänst (PaaS) som effektiviserar installationen, driftsättningen och underhållet av din app på Amazon AWS. Det är en hanterad tjänst som kopplar ihop servern (EC2), databasen (RDS) och dina statiska filer (S3). Du kan snabbt distribuera och hantera din applikation, som automatiskt skalas när din webbplats växer. Kolla in den officiella dokumentationen för mer information.

Komma igång

Vi kommer att använda en enkel "Dagens bild"-app, som du kan hämta från det här arkivet:

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

När du har laddat ner koden skapar du en virtualenv och installerar kraven via pip:

$ pip install -r requirements.txt

Sedan, med PostgreSQL som körs lokalt, ställ in en ny databas med namnet iotd . Beroende på din lokala Postgres-konfiguration kan du också behöva uppdatera DATABASES konfiguration i settings.py . Till exempel uppdaterade jag konfigurationen till:

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

Nu kan du ställa in databasschemat, skapa en superanvändare och köra appen:

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

Navigera till administratörssidan i din webbläsare på http://localhost:8000/admin och lägg till en ny bild, som sedan kommer att visas på huvudsidan.

Applikationen är inte tänkt att vara särskilt spännande; vi använder det bara för demoändamål. Allt det gör är att låta dig ladda upp en bild via administratörsgränssnittet och visa bilden i helskärm på huvudsidan. Som sagt, även om det här är en relativt enkel app, kommer den fortfarande att tillåta oss att utforska ett antal "gotchas" som finns när vi distribuerar till Amazon Beanstalk och RDS.

Nu när vi har webbplatsen igång på vår lokala dator, låt oss starta Amazon-distributionsprocessen.

CLI för AWS Elastic Beanstalk

För att arbeta med en Amazon Elastic Beanstalk kan vi använda ett paket som heter awsebcli. När detta skrivs är den senaste versionen av 3.7.4 och det rekommenderade sättet att installera den är med pip:

$ pip install awsebcli

Testa nu installationen för att se till att den fungerar:

$ eb --version

Detta borde ge dig ett bra 3.x-versionsnummer:

EB CLI 3.7.4 (Python 3.4.3)

För att faktiskt börja använda Elastic Beanstalk behöver du ett konto hos AWS (överraskning!). Registrera dig (eller logga in).

Konfigurera EB – Initiera din app

När AWS Elastic Beanstalk CLI fungerar är det första vi vill göra att skapa en Beanstalk-miljö för applikationen. Kör detta från projektkatalogen ("image-of-the-day"):

$ eb init

Detta kommer att få dig att ställa ett antal frågor som hjälper dig att konfigurera din miljö.

Standardregion

Att välja den region som ligger närmast dina slutanvändare ger i allmänhet bäst prestanda. Kolla in den här kartan om du är osäker på vilken du ska välja.

Inloggningsuppgifter

Därefter kommer den att be om dina AWS-uppgifter.

Här kommer du troligen att vilja konfigurera en IAM-användare. Se den här guiden för hur du ställer in en. Om du skapar en ny användare måste du se till att användaren har lämpliga behörigheter. Det enklaste sättet att göra detta är att bara lägga till "Administratörsbehörighet" till användaren. (Detta är förmodligen inte ett bra val av säkerhetsskäl, dock.) För de specifika policyer/roller som en användare behöver för att skapa/hantera en Elastic Beanstalk-applikation, se länken här.

Appnamn

Detta kommer att ha katalognamnet som standard. Bara gå med det.

Python-version

Därefter bör CLI automatiskt upptäcka att du använder Python och bara be om bekräftelse. Säg ja. Sedan måste du välja en plattformsversion. Du har två olika alternativ här för Python 3:

Python 3.4
Python 3.4 (Förkonfigurerad - Docker)

Om du är en hipster, välj "Preconfigured - Docker" valet, annars gå med den vanliga "Python 3.4". Nej, bara retas; den grundläggande skillnaden är denna:

Python 3.4

Detta ger dig en EC2-bild som kör 64bit Amazon Linux med Python 3.4 förinstallerat. Frontend-webbservern är apache, med mod_wsgi installerad. Detta är det "standard" eller "traditionella" sättet som Beanstalk fungerar på. Med andra ord, med det här alternativet kommer Beanstalk att skapa EC2-bilder åt dig, och du kan använda ebextension filer vi kommer att prata om senare för att anpassa EC2-bilden.

Python 3.4 (Förkonfigurerad – Docker)

Detta ger dig en EC2-bild som kör Docker, med en Docker-bild redan inställd för dig. Docker-bilden kör 64-bitars Debian Jessie med Python 3.4, nginx 1.8 och uWSGI 2.0.8. Eftersom du i princip interagerar med Docker-bilden direkt, om du väljer den här vägen skulle du använda standard Docker-konfigurationstekniker (d.v.s. en 'Dockerfile'), och då behöver du inte göra mycket som är specifikt för AWS Beanstalk, eftersom Beanstalk vet hur man hanterar Docker-bilden åt dig.

För den här artikeln kommer vi att fokusera på det "standard" eller "traditionella" sättet att använda en EC2-bild, så välj alternativet "Python 3.4" och låt oss gå vidare.

SSH

Säg ja till att ställa in SSH för dina instanser.

RSA-nyckelpar

Därefter måste du skapa ett RSA-nyckelpar som kommer att läggas till din ~/.ssh mapp. Detta nyckelpar kommer också att laddas upp till den offentliga EC2-nyckeln för regionen du angav i steg ett. Detta gör att du kan SSH till din EC2-instans senare i denna handledning.

Vad har vi åstadkommit?

En gång eb init är klar kommer du att se en ny dold mapp som heter .elasticbeanstalk i din projektkatalog:

├── .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

Inuti den katalogen finns en config.yml fil, som är en konfigurationsfil som används för att definiera vissa parametrar för din nyligen präglade Beanstalk-applikation.

Vid det här laget, om du skriver eb console den öppnar din standardwebbläsare och navigerar till Elastic Beanstalk-konsolen. På sidan bör du se en applikation (kallad image-of-the-day om du följer exakt), men inga miljöer.

En applikation representerar din kodapplikation och är vad eb init skapat för oss. Med Elastic Beanstalk kan en applikation ha flera miljöer (d.v.s. utveckling, testning, iscensättning, produktion). Det är helt upp till dig hur du vill konfigurera/hantera dessa miljöer. För enkla Django-applikationer gillar jag att ha utvecklingsmiljön på min bärbara dator och sedan skapa en test- och en produktionsmiljö på Beanstalk.

Låt oss skapa en testmiljö...

Konfigurera EB – Skapa en miljö

När du kommer tillbaka till terminalen, i din projektkatalog skriv:

$ eb create

Precis som eb init , kommer det här kommandot att fråga dig med en rad frågor.

Miljönamn

Du bör använda en liknande namnkonvention som Amazon föreslår - t.ex. application_name-env_name - speciellt när/om du börjar vara värd för flera applikationer med AWS. Jag använde - iod-test .

DNS CNAME-prefix

När du distribuerar en app till Elastic Beanstalk får du automatiskt ett domännamn som xxx.elasticbeanstalk.com. DNS CNAME prefix är vad du vill ska användas i stället för xxx . Standarden fungerar förmodligen inte om du följer med eftersom någon annan redan har använt det (namnen är globala för AWS), så välj något unikt och fortsätt.

Vad händer nu?

Vid denna punkt eb kommer faktiskt att skapa din miljö åt dig. Ha tålamod eftersom det kan ta lite tid.

Om du får ett felmeddelande om att skapa miljön, som - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - kontrollera att de referenser du använder har lämpliga behörigheter för att skapa Beanstalk-miljön, som diskuterats tidigare i det här inlägget.

Du kan också få ett meddelande om Platform requires a service role . Om den gör det, säg bara ja och låt den skapa rollen åt dig.

Direkt efter att miljön har skapats, eb kommer att försöka distribuera din applikation genom att kopiera all kod i din projektkatalog till den nya EC2-instansen, köra pip install -r requirements.txt i processen.

Du bör se en massa information om miljön som ställs in på din skärm, samt information om eb försöker distribuera. Du kommer också att se några fel. I synnerhet bör du se dessa rader begravda någonstans i utgången:

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

Oroa dig inte - det är inte riktigt ogiltigt. Kontrollera loggarna för detaljer:

$ eb logs

Detta tar alla de senaste loggfilerna från EC2-instansen och matar ut dem till din terminal. Det är mycket information, så du kanske vill omdirigera utdata till en fil (eb logs -z ). När du tittar igenom loggarna ser du en loggfil med namnet eb-activity.log :

Error: pg_config executable not found.

Problemet är att vi försökte installera psycopy2 (Postgres Python-bindningarna), men vi behöver även Postgres-klientdrivrutinerna installeras. Eftersom de inte är installerade som standard måste vi installera dem först. Låt oss fixa det...

Anpassa distributionsprocessen

eb kommer att läsa anpassad .config filer från en mapp som heter ".ebextensions" på rotnivån för ditt projekt ("image-of-the-day"-katalogen). Dessa .config filer låter dig installera paket, köra godtyckliga kommandon och/eller ställa in miljövariabler. Filer i katalogen ".ebextensions" bör överensstämma med antingen JSON eller YAML syntax och exekveras i alfabetisk ordning.

Installera paket

Det första vi behöver göra är att installera några paket så att vår pip install kommandot kommer att slutföras framgångsrikt. För att göra detta, låt oss först skapa en fil som heter .ebextensions/01_packages.config :

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

EC2-instanser kör Amazon Linux, som är en Redhat-smak, så vi kan använda yum för att installera de paket vi behöver. För nu ska vi bara installera tre paket - git, Postgres-klienten och libjpeg för pillow.

Efter att ha skapat den filen för att distribuera om programmet måste vi göra följande:

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

Vi måste genomföra ändringarna eftersom distributionskommandot eb deploy fungerar av den senaste commit, och kommer därför bara att vara medveten om våra filändringar efter att vi commit dem till git. (Observera dock att vi inte behöver trycka på, vi arbetar utifrån vår lokala kopia...)

Som du säkert gissat är nästa kommando:

$ eb deploy

Du bör nu bara se ett fel:

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.

Låt oss ta reda på vad som händer...

Konfigurera vår Python-miljö

EC2-instanser i Beanstalk kör Apache, och Apache hittar vår Python-app enligt WSGIPATH som vi har ställt in. Som standard eb antar att vår wsgi-fil heter application.py . Det finns två sätt att korrigera detta-

Alternativ 1:Använda miljöspecifika konfigurationsinställningar

$ eb config

Detta kommando öppnar din standardredigerare och redigerar en konfigurationsfil som heter .elasticbeanstalk/iod-test.env.yml . Den här filen existerar faktiskt inte lokalt; eb drog ner den från AWS-servrarna och presenterade den för dig så att du kan ändra inställningarna i den. Om du gör några ändringar i den här pseudofilen och sedan sparar och avslutar, eb kommer att uppdatera motsvarande inställningar i din Beanstalk-miljö.

Om du söker efter termerna 'WSGI' i filen, och du bör hitta en konfigurationssektion som ser ut så här:

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

Uppdatera WSGIPath:

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

Och då kommer du att ha din WSGIPath korrekt inställd. Om du sedan sparar filen och avslutar, eb kommer att uppdatera miljökonfigurationen automatiskt:

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.

Fördelen med att använda eb config Metoden för att ändra inställningar är att du kan ange olika inställningar per miljö. Men du kan också uppdatera inställningarna med samma .config filer som vi använde tidigare. Detta kommer att använda samma inställningar för varje miljö, som .config filer kommer att tillämpas vid distribution (efter inställningarna från eb config har tillämpats).

Alternativ 2:Använda globala konfigurationsinställningar

För att använda .config filalternativ, låt oss skapa en ny fil som heter /.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/"

Vad händer?

DJANGO_SETTINGS_MODULE: "iotd.settings" - lägger till sökvägen till inställningsmodulen.
"PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH" - uppdaterar vår PYTHONPATH så att Python kan hitta modulerna i vår applikation. Den här sökvägen kan variera beroende på din inställning! Se den här kommentaren för mer information. (Observera att användningen av den fullständiga sökvägen är nödvändig.)
WSGIPath: iotd/iotd/wsgi.py anger vår WSGI-sökväg.
NumProcesses: 3 och NumThreads: 20 - uppdaterar antalet processer och trådar som används för att köra vår WSGI-applikation.
"/static/": "www/static/" anger sökvägen till vår statiska fil.

Återigen kan vi göra en git commit sedan en eb deploy för att uppdatera dessa inställningar.

Låt oss sedan lägga till en databas.

Konfigurera en databas

Försök att se den distribuerade webbplatsen:

$ eb open

Det här kommandot visar det installerade programmet i din standardwebbläsare. Du bör se ett felmeddelande om att anslutningen nekades:

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?

Det beror på att vi inte har skapat någon databas än. Vid denna punkt eb kommer att ställa in din Beanstalk-miljö, men den ställer inte in RDS (databasnivån). Vi måste ställa in det manuellt.

Databasinställningar

Återigen, använd eb console för att öppna Beanstalk-konfigurationssidan.

Därifrån gör du följande:

Klicka på länken "Konfiguration".
Bläddra hela vägen till botten av sidan och klicka sedan på länken "skapa en ny RDS-databas" under avsnittet "Datanivå".
Ändra "DB Engine" till "postgres" på RDS-inställningssidan.
Lägg till ett "Master Username" och "Master Password".
Spara ändringarna.

Beanstalk skapar RDS åt dig. Nu måste vi få vår Django-app för att ansluta till RDS. Beanstalk kommer att hjälpa oss här genom att exponera ett antal miljövariabler på EC2-instanserna för oss som beskriver hur man ansluter till Postgres-servern. Så allt vi behöver göra är att uppdatera våra settings.py fil för att dra fördel av dessa miljövariabler. Bekräfta att DATABASES konfigurationsparametern återspeglar följande i 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',
        }
    }

Detta säger helt enkelt "använd miljövariabelinställningarna om de finns, annars använd våra standardutvecklingsinställningar." Enkelt.

Hantera databasmigreringar

Med vår databasinstallation måste vi fortfarande se till att migreringarna körs så att databastabellstrukturen är korrekt. Vi kan göra det genom att ändra .ebextensions/02_python.config och lägga till följande rader överst i filen:

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

container_commands låter dig köra godtyckliga kommandon efter att applikationen har distribuerats på EC2-instansen. Eftersom EC2-instansen är inställd med en virtuell miljö måste vi först aktivera den virtuella miljön innan vi kör vårt migreringskommando. Även leader_only: true inställning betyder, "kör endast det här kommandot på den första instansen när du distribuerar till flera instanser."

Glöm inte att vår applikation använder sig av Djangos admin, så vi kommer att behöva en superanvändare...

Skapa administratörsanvändaren

Tyvärr createsuperuser tillåter dig inte att ange ett lösenord när du använder --noinput alternativet, så vi måste skriva vårt eget kommando. Lyckligtvis gör Django det väldigt enkelt att skapa anpassade kommandon.

Skapa filen 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")

Se till att du lägger till lämplig __init__.py filer också:

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

Den här filen låter dig köra python manage.py createsu , och det kommer att skapa en superanvändare utan att be om ett lösenord. Expandera gärna kommandot för att använda miljövariabler eller andra sätt att tillåta dig att ändra lösenordet.

När du har skapat kommandot kan vi bara lägga till ytterligare ett kommando till våra container_commands avsnitt i .ebextensions/02_python.config :

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

Innan du testar detta, låt oss se till att alla våra statiska filer är placerade på rätt plats...

Statiska filer

Lägg till ytterligare ett kommando under container_commands :

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

Så hela filen ser ut så här:

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

Vi måste nu se till att STATIC_ROOT är korrekt inställd i settings.py fil:

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

Se till att du använder www katalogen till git så att den statiska katalogen kan skapas. Kör sedan eb deploy igen, och du bör nu vara igång:

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.

Vid det här laget bör du kunna gå till http://din_app_url/admin, logga in, lägga till en bild och sedan se bilden visas på huvudsidan i din applikation.

Framgång!

Använda S3 för medielagring

Med den här inställningen kommer vi att förlora alla våra uppladdade bilder varje gång vi distribuerar igen. Varför? Tja, när du kör eb deploy , en ny instans skapas åt dig. Det är inte vad vi vill eftersom vi då kommer att ha poster i databasen för bilderna, men inga associerade bilder. Lösningen är att lagra mediefilerna i Amazon Simple Storage Service (Amazon S3) istället för på själva EC2-instansen.

Du måste:

Skapa en hink
Ta tag i din användares ARN (Amazon Resource Name)
Lägg till hinkbehörigheter
Konfigurera din Django-app för att använda S3 för att visa dina statiska filer

Eftersom det redan finns bra skrivningar om detta, ska jag bara peka på min favorit:Använda Amazon S3 för att lagra Django Static och Media Files

Apache-konfiguration

Eftersom vi använder Apache med Beanstalk vill vi förmodligen ställa in Apache för att (bland annat) aktivera gzip-komprimering så att filer laddas ner snabbare av klienterna. Det kan göras med container_commands . Skapa en ny fil .ebextensions/03_apache.config och lägg till följande:

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

Sedan måste du skapa filen .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>

Om du gör detta aktiverar du gzip-komprimering, vilket borde hjälpa till med storleken på filerna du laddar ner. Du kan också använda samma strategi för att automatiskt förminska och kombinera din CSS/JS och göra någon annan förbearbetning du behöver göra.

Felsökning

Glöm inte den mycket hjälpsamma eb ssh kommando, som tar dig in i EC2-instansen så att du kan leta runt och se vad som händer. Vid felsökning finns det några kataloger du bör vara medveten om:

/opt/python :Roten till var din ansökan kommer att hamna.
/opt/python/current/app :Den aktuella applikationen som finns i miljön.
/opt/python/on-deck/app :Appen placeras initialt på däck och sedan, efter att all distribution är klar, flyttas den till current . Om du får fel i dina container_commands , kolla in on-deck mapp och inte den current mapp.
/opt/python/current/env :Alla env-variabler som eb kommer att ställa in åt dig. Om du försöker återskapa ett fel kan du först behöva source /opt/python/current/env för att få saker inställda som de skulle vara när eb deploy körs.
opt/python/run/venv :Den virtuella env som används av din applikation; du måste också köra source /opt/python/run/venv/bin/activate om du försöker återskapa ett fel.

Slutsats

Att distribuera till Elastic Beanstalk kan vara lite skrämmande i början, men när du väl förstår var alla delar finns och hur saker fungerar är det faktiskt ganska enkelt och extremt flexibelt. Det ger dig också en miljö som skalas automatiskt när din användning växer. Förhoppningsvis har du vid det här laget tillräckligt för att vara farlig! Lycka till med din nästa Beanstalk-distribution.

Har vi missat något? Har du några andra tips eller tricks? Vänligen kommentera nedan.