sql >> Database teknologi >  >> RDS >> PostgreSQL

Implementering af Django + Python 3 + PostgreSQL til AWS Elastic Beanstalk

Det følgende er en suppe-to-nød gennemgang af, hvordan man opsætter og implementerer en Django-applikation, drevet af Python 3 og PostgreSQL til Amazon Web Services (AWS), alt imens man forbliver sund.

Anvendte værktøjer/teknologier:

  1. Python v3.4.3
  2. Django v1.9
  3. Amazon Elastic Beanstalk, EC2, S3 og RDS
  4. EB CLI 3.x
  5. PostgreSQL

Gratis bonus: Klik her for at få adgang til en gratis Django Learning Resources Guide (PDF), der viser dig tips og tricks samt almindelige faldgruber, du skal undgå, når du bygger Python + Django-webapplikationer.

Tjek Python 2 version af denne artikel her.

Opdateret 21.08.2016: Opdaterede EB globale konfigurationsindstillinger.


Elastic Beanstalk vs EC2

Elastic Beanstalk er en platform som en tjeneste (PaaS), der strømliner opsætningen, implementeringen og vedligeholdelsen af ​​din app på Amazon AWS. Det er en administreret tjeneste, der kobler serveren (EC2), databasen (RDS) og dine statiske filer (S3). Du kan hurtigt implementere og administrere din applikation, som automatisk skaleres, efterhånden som dit websted vokser. Se den officielle dokumentation for mere information.



Kom godt i gang

Vi bruger en simpel app "Dagens billede", som du kan hente fra dette lager:

$ 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 downloadet koden, skal du oprette en virtualenv og installere kravene via pip:

$ pip install -r requirements.txt 

Dernæst, med PostgreSQL kørende lokalt, opsæt en ny database ved navn iotd . Afhængigt af din lokale Postgres-konfiguration skal du muligvis også opdatere DATABASERNE konfiguration i settings.py . For eksempel opdaterede jeg konfigurationen til:

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

Nu kan du opsætte databaseskemaet, oprette en superbruger og køre appen:

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

Naviger til admin-siden i din browser på http://localhost:8000/admin og tilføj et nyt billede, som derefter vil blive vist på hovedsiden.

Det er ikke meningen, at applikationen skal være særlig spændende; vi bruger det bare til demoformål. Det eneste, det gør, er at lade dig uploade et billede via admin-grænsefladen og vise billedet i fuld skærm på hovedsiden. Når det er sagt, selvom dette er en relativt grundlæggende app, vil den stadig give os mulighed for at udforske en række "gotchas", der eksisterer, når de implementeres til Amazon Beanstalk og RDS.

Nu hvor vi har webstedet oppe at køre på vores lokale maskine, lad os starte Amazon-implementeringsprocessen.



CLI til AWS Elastic Beanstalk

For at arbejde med en Amazon Elastic Beanstalk kan vi bruge en pakke kaldet awsebcli. I skrivende stund er den seneste version af 3.7.4, og den anbefalede måde at installere den på er med pip:

$ pip installer awsebcli 

Test nu installationen for at sikre, at den virker:

$ eb --version 

Dette skulle give dig et flot 3.x versionsnummer:

EB CLI 3.7.4 (Python 3.4.3) 

For rent faktisk at begynde at bruge Elastic Beanstalk skal du have en konto hos AWS (overraskelse!). Tilmeld dig (eller log ind).



Konfigurer EB – Initialiser din app

Når AWS Elastic Beanstalk CLI fungerer, er den første ting, vi ønsker at gøre, at skabe et Beanstalk-miljø til at hoste applikationen på. Kør dette fra projektbiblioteket ("image-of-the-day"):

$ eb init 

Dette vil bede dig om en række spørgsmål for at hjælpe dig med at konfigurere dit miljø.

Standardområde

At vælge den region, der er tættest på dine slutbrugere, vil generelt give den bedste ydeevne. Tjek dette kort, hvis du er i tvivl om, hvad du skal vælge.

legitimationsoplysninger

Dernæst vil den bede om dine AWS-legitimationsoplysninger.

Her vil du højst sandsynligt ønsker at oprette en IAM-bruger. Se denne vejledning for, hvordan du konfigurerer en. Hvis du opretter en ny bruger, skal du sikre dig, at brugeren har de relevante tilladelser. Den nemmeste måde at gøre dette på er blot at tilføje "Administrator Access" til brugeren. (Dette er sandsynligvis ikke et godt valg af sikkerhedsmæssige årsager.) For de specifikke politikker/roller, som en bruger har brug for for at oprette/administrere en Elastic Beanstalk-applikation, se linket her.

Applikationsnavn

Dette vil som standard bruge biblioteksnavnet. Bare gå med det.

Python-version

Dernæst skal CLI automatisk registrere, at du bruger Python og bare bede om bekræftelse. Sig ja. Så skal du vælge en platformversion. Du har 2 forskellige muligheder her for Python 3:

  • Python 3.4
  • Python 3.4 (forudkonfigureret - Docker)

Hvis du er en hipster, skal du vælge 'Preconfigured - Docker'-valget, ellers gå med den normale 'Python 3.4'. Nej, kun drilleri; den grundlæggende forskel er denne:


Python 3.4

Dette giver dig et EC2-billede, der kører 64bit Amazon Linux med Python 3.4 forudinstalleret. Frontend-webserveren er apache, med mod_wsgi installeret. Dette er den "standard" eller "traditionelle" måde, hvorpå Beanstalk fungerer. Med andre ord, med denne mulighed vil Beanstalk oprette EC2-billeder for dig, og du kan bruge ebextension filer, vi vil tale om senere for at tilpasse EC2-billedet.



Python 3.4 (forudkonfigureret – Docker)

Dette giver dig et EC2-billede, der kører Docker, med et Docker-billede allerede opsat til dig. Docker-billedet kører 64bit Debian Jessie med Python 3.4, nginx 1.8 og uWSGI 2.0.8. Fordi du dybest set interagerer med Docker-billedet direkte, hvis du vælger denne rute, vil du bruge standard Docker-konfigurationsteknikker (dvs. en 'Dockerfile'), og så behøver du ikke gøre meget, der er AWS Beanstalk-specifikt, som Beanstalk ved, hvordan man administrerer Docker-billedet for dig.

Til denne artikel vil vi fokusere på den "standard" eller "traditionelle" måde at bruge et EC2-billede på, så vælg 'Python 3.4'-indstillingen og lad os gå videre.

SSH

Sig ja til at konfigurere SSH for dine forekomster.

RSA-nøglepar

Dernæst skal du generere et RSA-nøglepar, som vil blive tilføjet til din ~/.ssh folder. Dette nøglepar vil også blive uploadet til den offentlige EC2-nøgle for den region, du specificerede i trin et. Dette giver dig mulighed for at SSH ind i din EC2-instans senere i denne øvelse.



Hvad opnåede vi?

En gang eb init er færdig, vil du se en ny skjult mappe kaldet .elasticbeanstalk i din projektmappe:

├── .elasticbeanstalk│ └── config.yml├── .gitignore├── README.md├── iotd│ │ │ │____it ├││i billeder ├││it. ─ admin.py│ │ ├── migrations│ │ │ ├── 0001_initial.py│ │ │ └── __init__.py│ │s │s .py- static│ │ ├── css│ │ │ └── bootstrap.min.css│ │ └── js│ │ ├── bootstrap.min.js.1│└1 ── skabeloner│ ├── base.html│ └── billeder│ └── home.html├── krav.txt└── www └── media ───o.

Inde i den mappe er en config.yml fil, som er en konfigurationsfil, der bruges til at definere visse parametre for din nyligt prægede Beanstalk-applikation.

På dette tidspunkt, hvis du skriver eb console det vil åbne din standardbrowser og navigere til Elastic Beanstalk-konsollen. På siden bør du se én applikation (kaldet dagens billede hvis du følger nøjagtigt med), men ingen miljøer.

En applikation repræsenterer din kodeapplikation og er hvad eb init skabt til os. Med Elastic Beanstalk kan en applikation have flere miljøer (dvs. udvikling, test, iscenesættelse, produktion). Det er helt op til dig, hvordan du vil konfigurere/administrere disse miljøer. For simple Django-applikationer kan jeg godt lide at have udviklingsmiljøet på min bærbare computer, og derefter oprette en test- og et produktionsmiljø på Beanstalk.

Lad os få sat et testmiljø op...




Konfigurer EB – Opret et miljø

For at komme tilbage til terminalen, i din projektmappe skriv:

$ eb oprette 

Ligesom eb init , vil denne kommando stille dig en række spørgsmål.

Miljønavn

Du bør bruge en navnekonvention, der ligner den, Amazon foreslår - f.eks. application_name-env_name - især når/hvis du begynder at hoste flere applikationer med AWS. Jeg brugte - iod-test .

DNS CNAME-præfiks

Når du implementerer en app til Elastic Beanstalk, får du automatisk et domænenavn som xxx.elasticbeanstalk.com. DNS CNAME-præfiks er det, du vil bruge i stedet for xxx . Standarden fungerer sandsynligvis ikke, hvis du følger med, fordi en anden allerede har brugt den (navnene er globale for AWS), så vælg noget unikt og fortsæt.


Hvad sker der nu?

På dette tidspunkt eb vil faktisk skabe dit miljø for dig. Vær tålmodig, da dette kan tage noget tid.

Hvis du får en fejl ved oprettelse af miljøet, f.eks. - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - tjek, at de legitimationsoplysninger, du bruger, har passende tilladelser til at oprette Beanstalk-miljøet, som diskuteret tidligere i dette indlæg.

Det kan også bede dig om en besked om Platform kræver en servicerolle . Hvis det gør det, skal du bare sige ja og lade den skabe rollen for dig.

Umiddelbart efter at miljøet er oprettet, eb vil forsøge at implementere din applikation ved at kopiere al koden i dit projektbibliotek til den nye EC2-instans ved at køre pip install -r requirements.txt i processen.

Du bør se en masse information om det miljø, der konfigureres, vist på din skærm, samt information om eb forsøger at implementere. Du vil også se nogle fejl. Du bør især se disse linjer begravet et sted i outputtet:

FEJL:Din requirements.txt er ugyldig. Snapshot dine logfiler for detaljer. 

Bare rolig - den er ikke rigtig ugyldig. Tjek logfilerne for detaljer:

$ eb logs 

Dette vil gribe alle de seneste logfiler fra EC2-instansen og sende dem til din terminal. Det er en masse information, så du ønsker måske at omdirigere outputtet til en fil (eb logs -z ). Når du kigger gennem logfilerne, vil du se én logfil med navnet eb-activity.log :

Fejl:pg_config eksekverbar fil blev ikke fundet. 

Problemet er, at vi forsøgte at installere psycopy2 (Postgres Python-bindingerne), men vi skal også have Postgres-klientdriverne installeret. Da de ikke er installeret som standard, skal vi først installere dem. Lad os rette op på det...




Tilpasning af implementeringsprocessen

eb vil læse tilpasset .config filer fra en mappe kaldet ".ebextensions" på rodniveauet af dit projekt ("image-of-the-day"-mappen). Disse .config filer giver dig mulighed for at installere pakker, køre vilkårlige kommandoer og/eller indstille miljøvariabler. Filer i mappen ".ebextensions" skal være i overensstemmelse med enten JSON eller YAML syntaks og udføres i alfabetisk rækkefølge.


Installation af pakker

Den første ting vi skal gøre er at installere nogle pakker, så vores pip installerer kommandoen fuldføres med succes. For at gøre dette, lad os først oprette en fil kaldet .ebextensions/01_packages.config :

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

EC2-instanser kører Amazon Linux, som er en Redhat-smag, så vi kan bruge yum til at installere de pakker, vi har brug for. For nu skal vi bare installere tre pakker - git, Postgres-klienten og libjpeg til pillow.

Efter at have oprettet den fil for at geninstallere applikationen, skal vi gøre følgende:

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

Vi er nødt til at foretage ændringerne, fordi implementeringskommandoen eb deploy virker fra den seneste commit, og vil således først være opmærksom på vores filændringer, efter at vi har commit dem til git. (Bemærk dog, at vi ikke behøver at presse på; vi arbejder ud fra vores lokale kopi...)

Som du sikkert har gættet, er den næste kommando:

$ eb deploy 

Du skulle nu kun se én fejl:

INFO:Miljøopdatering starter.INFO:Implementering af ny version til instans(er). FEJL:Din WSGIPath henviser til en fil, der ikke eksisterer.INFO:Ny applikationsversion blev implementeret til at køre EC2-instanser.INFO :Miljøopdateringen er gennemført. 

Lad os finde ud af, hvad der sker...



Konfiguration af vores Python-miljø

EC2-forekomster i Beanstalk kører Apache, og Apache finder vores Python-app i henhold til den WSGIPATH, som vi har indstillet. Som standard eb antager, at vores wsgi-fil hedder application.py . Der er to måder at rette dette på-

Mulighed 1:Brug af miljøspecifikke konfigurationsindstillinger

$ eb config 

Denne kommando åbner din standardeditor og redigerer en konfigurationsfil kaldet .elasticbeanstalk/iod-test.env.yml . Denne fil eksisterer faktisk ikke lokalt; eb trak det ned fra AWS-serverne og præsenterede det for dig, så du kan ændre indstillinger i det. Hvis du foretager ændringer i denne pseudo-fil og derefter gemmer og afslutter, eb vil opdatere de tilsvarende indstillinger i dit Beanstalk-miljø.

Hvis du søger efter termerne 'WSGI' i filen, og du skulle finde en konfigurationssektion, der ser sådan ud:

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

Opdater WSGIPath:

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

Og så vil du have din WSGIPath opsat korrekt. Hvis du derefter gemmer filen og afslutter, eb vil automatisk opdatere miljøkonfigurationen:

Udskrivningsstatus:INFO:Miljøopdatering starter.INFO:Opdatering af miljø iod-tests konfigurationsindstillinger.INFO:Den nye konfiguration blev implementeret med succes til miljøet.INFO:Opdatering af miljøet er gennemført. 

Fordelen ved at bruge eb config metode til at ændre indstillinger er, at du kan angive forskellige indstillinger pr. miljø. Men du kan også opdatere indstillinger ved at bruge den samme .config filer, som vi brugte før. Dette vil bruge de samme indstillinger for hvert miljø, som .config filer vil blive anvendt ved implementering (efter indstillingerne fra eb config er blevet anvendt).

Mulighed 2:Brug af globale konfigurationsindstillinger

For at bruge .config filvalg, lad os oprette en ny fil kaldet /.ebextensions/02_python.config :

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

Hvad sker der?

  • DJANGO_SETTINGS_MODULE:"iotd.settings" - tilføjer stien til indstillingsmodulet.
  • "PYTHONPATH":"/opt/python/current/app/iotd:$PYTHONPATH" - opdaterer vores PYTHONPATH så Python kan finde modulerne i vores applikation. Denne sti kan variere afhængigt af din opsætning! Se denne kommentar for flere detaljer. (Bemærk, at brugen af ​​den fulde sti er nødvendig.)
  • WSGIPath:iotd/iotd/wsgi.py sætter vores WSGI-sti.
  • Antal processer:3 og NumThreads:20 - opdaterer antallet af processer og tråde, der bruges til at køre vores WSGI-applikation.
  • "/static/":"www/static/" angiver stien til vores statiske filer.

Igen kan vi lave en git commit derefter en eb deploy for at opdatere disse indstillinger.

Lad os derefter tilføje en database.




Konfiguration af en database

Prøv at se det installerede websted:

$ eb åben 

Denne kommando viser det installerede program i din standardbrowser. Du skulle se en fejlmeddelelse om afvist forbindelse:

OperationalError at /could not connect to server:Forbindelse nægtet Kører serveren på værten "localhost" (127.0.0.1) og accepterer TCP/IP-forbindelser på port 5432? 

Dette skyldes, at vi ikke har oprettet en database endnu. På dette tidspunkt eb opsætter dit Beanstalk-miljø, men det opsætter ikke RDS (databaselaget). Vi skal konfigurere det manuelt.


Databaseopsætning

Igen, brug eb-konsol for at åbne Beanstalk-konfigurationssiden.

Derfra skal du gøre følgende:

  1. Klik på linket "Konfiguration".
  2. Rul hele vejen til bunden af ​​siden, og klik derefter på linket "opret en ny RDS-database" under afsnittet "Data Tier".
  3. På RDS-opsætningssiden skal du ændre "DB Engine" til "postgres".
  4. Tilføj et "Hovedbrugernavn" og "Hovedadgangskode".
  5. Gem ændringerne.

Beanstalk vil oprette RDS for dig. Nu skal vi have vores Django-app til at oprette forbindelse til RDS. Beanstalk vil hjælpe os her ved at afsløre en række miljøvariabler på EC2-instanserne for os, der beskriver, hvordan man forbinder til Postgres-serveren. Så alt, hvad vi skal gøre, er at opdatere vores settings.py fil for at drage fordel af disse miljøvariabler. Bekræft, at DATABASER konfigurationsparameter afspejler følgende i settings.py :

hvis 'RDS_DB_NAME' i 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', } } 

Dette siger blot, "brug indstillingerne for miljøvariablen, hvis de er til stede, ellers brug vores standardudviklingsindstillinger." Simpelt.



Håndtering af databasemigreringer

Med vores databaseopsætning skal vi stadig sikre os, at migreringer kører, så databasetabelstrukturen er korrekt. Det kan vi gøre ved at ændre .ebextensions/02_python.config og tilføje følgende linjer øverst i filen:

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

container_commands giver dig mulighed for at køre vilkårlige kommandoer, efter at applikationen er blevet installeret på EC2-instansen. Fordi EC2-instansen er sat op ved hjælp af et virtuelt miljø, skal vi først aktivere det virtuelle miljø, før vi kører vores migreringskommando. Også leader_only:true indstilling betyder, "kør kun denne kommando på den første instans, når du installerer til flere instanser."

Glem ikke, at vores applikation gør brug af Djangos admin, så vi får brug for en superbruger...



Opret administratorbrugeren

Desværre createsuperuser tillader dig ikke at angive en adgangskode, når du bruger --noinput mulighed, så vi bliver nødt til at skrive vores egen kommando. Heldigvis gør Django det meget nemt at oprette brugerdefinerede kommandoer.

Opret filen iotd/images/management/commands/createsu.py :

fra django.core.management.base import BaseCommandfrom django.contrib.auth.models import Userclass Command(BaseCommand):def handle(self, *args, **options):hvis ikke User.objects.filter (brugernavn="admin").exists():User.objects.create_superuser("admin", "[email protected]", "admin") 

Sørg for at tilføje den relevante __init__.py filer også:

└─ administration ├── __init__.py └── kommandoer ├── __init__.py └── createsu.py 

Denne fil giver dig mulighed for at køre python manage.py createsu , og det vil oprette en superbruger uden at bede om en adgangskode. Du er velkommen til at udvide kommandoen til at bruge miljøvariabler eller en anden måde at tillade dig at ændre adgangskoden.

Når du har oprettet kommandoen, kan vi bare tilføje endnu en kommando til vores container_commands sektion i .ebextensions/02_python.config :

02_createsu:kommando:"kilde /opt/python/run/venv/bin/activate &&python iotd/manage.py createsu" leader_only:sand 

Før du tester dette, lad os sørge for, at vores statiske filer alle er placeret det rigtige sted...




Statiske filer

Tilføj en kommando mere under container_commands :

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

Så hele filen ser sådan ud:

container_commands:01_migrate:kommando:"source /opt/python/run/venv/bin/activate &&python iotd/manage.py migrate --noinput" leader_only:true 02_createsu:kommando:"source /opt/ python/run/venv/bin/activate &&python iotd/manage.py createsu" leader_only:true 03_collectstatic:kommando:"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":".elasticbeanstalkbean aws:elasticbeanstalk:container:python":WSGIPath:iotd/iotd/wsgi.py AntalProcesser:3 NumThreads:20 "aws:elasticbeanstalk:container:python:staticfiles":"/static/":"www/static/" 

Vi skal nu sikre, at STATIC_ROOT er indstillet korrekt i settings.py fil:

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

Sørg for at bruge www mappe til git, så den statiske dir kan oprettes. Kør derefter eb deploy igen, og du skulle nu være i gang:

INFO:Miljøopdatering starter.INFO:Implementering af ny version til instans(er).INFO:Ny applikationsversion blev implementeret til at køre EC2-instanser.INFO:Miljøopdatering gennemført. 

På dette tidspunkt skulle du være i stand til at gå til http://your_app_url/admin, logge ind, tilføje et billede og derefter se billedet vist på hovedsiden af ​​din applikation.

Succes!



Brug af S3 til medieopbevaring

Med denne opsætning mister vi alle vores uploadede billeder, hver gang vi implementerer igen. Hvorfor? Nå, når du kører eb deploy , er en ny instans spundet op til dig. Det er ikke det, vi ønsker, da vi så vil have poster i databasen for billederne, men ingen tilknyttede billeder. Løsningen er at gemme mediefilerne i Amazon Simple Storage Service (Amazon S3) i stedet for på selve EC2-instansen.

Du skal:

  1. Opret en bøtte
  2. Få fat i din brugers ARN (Amazon Resource Name)
  3. Tilføj bucket-tilladelser
  4. Konfigurer din Django-app til at bruge S3 til at betjene dine statiske filer

Da der allerede er gode skrive-ups om dette, vil jeg bare henvise dig til min favorit:Brug af Amazon S3 til at gemme dig Django Static og Media Files



Apache-konfiguration

Da vi bruger Apache med Beanstalk, vil vi sandsynligvis konfigurere Apache til (blandt andet) at aktivere gzip-komprimering, så filerne downloades hurtigere af klienterne. Det kan gøres med container_commands . Opret en ny fil .ebextensions/03_apache.config og tilføje følgende:

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

Derefter skal du oprette filen .ebextensions/enable_mod_deflate.conf :

# mod_deflate-konfiguration # Begræns komprimering til disse MIME-typer AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddOutputFilterByType AddBOuthtml+xml DEFLATE application/xml+rss AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE text/css # Niveau af komprimering (Højeste 9 - Laveste 1) DeflateCompressionLevel.x har nogle problemer. BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 har nogle flere problemer BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE udgiver sig som Netscape, men det er fint BrowserMatch \bMSI[E ] !no-gzip !gzip-only-text/html # Sørg for, at proxyer ikke leverer det forkerte indhold Header tilføj Vary User-Agent env=!dont-vary

Hvis du gør dette, aktiveres gzip-komprimering, hvilket burde hjælpe med størrelsen på de filer, du downloader. Du kan også bruge den samme strategi til automatisk at minificere og kombinere din CSS/JS og udføre enhver anden forbehandling, du skal udføre.



Fejlfinding

Glem ikke den meget nyttige eb ssh kommando, som får dig ind i EC2-instansen, så du kan søge rundt og se, hvad der foregår. Ved fejlfinding er der et par mapper, du skal være opmærksom på:

  • /opt/python :Roden til, hvor din ansøgning ender.
  • /opt/python/current/app :Den aktuelle applikation, der er hostet i miljøet.
  • /opt/python/on-deck/app :Appen sættes i første omgang på dækket og derefter, når al implementeringen er fuldført, flyttes den til aktuel . Hvis du får fejl i dine container_commands , tjek på dækket mappe og ikke den nuværende mappe.
  • /opt/python/current/env :Alle env-variabler, der eb vil sætte op for dig. Hvis du forsøger at genskabe en fejl, skal du muligvis først kilde /opt/python/current/env for at få tingene sat op, som de ville være, når eb deploy kører.
  • opt/python/run/venv :Den virtuelle env, der bruges af din applikation; du skal også køre source /opt/python/run/venv/bin/activate hvis du forsøger at genskabe en fejl.


Konklusion

Installation til Elastic Beanstalk kan være lidt skræmmende i starten, men når du først forstår, hvor alle delene er, og hvordan tingene fungerer, er det faktisk ret nemt og ekstremt fleksibelt. Det giver dig også et miljø, der automatisk skaleres, efterhånden som dit forbrug vokser. Forhåbentlig har du nu nok til at være farlig! Held og lykke med din næste Beanstalk-installation.

Gratis bonus: Klik her for at få adgang til en gratis Django Learning Resources Guide (PDF), der viser dig tips og tricks samt almindelige faldgruber, du skal undgå, når du bygger Python + Django-webapplikationer.

Gik vi glip af noget? Har du andre tips eller tricks? Kommenter venligst nedenfor.



  1. Pandaer skriver dataramme til andre postgresql-skemaer

  2. MySQL #1140 - Blanding af GROUP-kolonner

  3. Hvad er de 10 bedste funktioner i Microsoft Access?

  4. Dynamisk (kolonnebaseret) interval