Implementación de Django + Python 3 + PostgreSQL en AWS Elastic Beanstalk

Si obtiene un error al crear el entorno, como - aws.auth.client.error.ARCInstanceIdentityProfileNotFoundException - verifique que las credenciales que está utilizando tengan los permisos apropiados para crear el entorno Beanstalk, como se mencionó anteriormente en esta publicación.

Además, puede mostrarle un mensaje sobre Platform requires a service role . Si es así, simplemente diga que sí y deje que cree el rol para usted.

Inmediatamente después de crear el entorno, eb intentará implementar su aplicación copiando todo el código en el directorio de su proyecto a la nueva instancia EC2, ejecutando pip install -r requirements.txt en proceso.

Debería ver un montón de información sobre el entorno que se está configurando en su pantalla, así como información sobre eb tratando de desplegar. También verá algunos errores. En particular, debería ver estas líneas ocultas en algún lugar de la salida:

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

No te preocupes, en realidad no es inválido. Consulte los registros para obtener más información:

$ eb logs

Esto tomará todos los archivos de registro recientes de la instancia EC2 y los enviará a su terminal. Es mucha información, por lo que es posible que desee redirigir la salida a un archivo (eb logs -z ). Mirando a través de los registros, verá un archivo de registro llamado eb-activity.log :

Error: pg_config executable not found.

El problema es que intentamos instalar psycopy2 (los enlaces de Python de Postgres), pero también necesitamos instalar los controladores de cliente de Postgres. Dado que no están instalados de forma predeterminada, debemos instalarlos primero. Arreglemos eso...

Personalización del proceso de implementación

eb leerá .config personalizado archivos de una carpeta llamada ".ebextensions" en el nivel raíz de su proyecto (directorio "image-of-the-day"). Estos .config Los archivos le permiten instalar paquetes, ejecutar comandos arbitrarios y/o establecer variables de entorno. Los archivos en el directorio ".ebextensions" deben cumplir con JSON o YAML sintaxis y se ejecutan en orden alfabético.

Instalación de paquetes

Lo primero que debemos hacer es instalar algunos paquetes para que nuestro pip install el comando se completará con éxito. Para hacer esto, primero creemos un archivo llamado .ebextensions/01_packages.config :

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

Las instancias EC2 ejecutan Amazon Linux, que es una variante de Redhat, por lo que podemos usar yum para instalar los paquetes que necesitamos. Por ahora, solo vamos a instalar tres paquetes:git, el cliente de Postgres y libjpeg para Pillow.

Después de crear ese archivo para volver a implementar la aplicación, debemos hacer lo siguiente:

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

Tenemos que confirmar los cambios porque el comando de implementación eb deploy funciona con la última confirmación y, por lo tanto, solo estará al tanto de los cambios de nuestro archivo después de que los confirmemos en git. (Sin embargo, tenga en cuenta que no tenemos que presionar; estamos trabajando desde nuestra copia local...)

Como probablemente hayas adivinado, el siguiente comando es:

$ eb deploy

Ahora debería ver solo un error:

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.

Averigüemos qué está pasando...

Configurando nuestro entorno Python

Las instancias EC2 en Beanstalk ejecutan Apache, y Apache encontrará nuestra aplicación de Python de acuerdo con el WSGIPATH que hemos establecido. Por defecto eb asume que nuestro archivo wsgi se llama application.py . Hay dos formas de corregir esto-

Opción 1:usar ajustes de configuración específicos del entorno

$ eb config

Este comando abrirá su editor predeterminado, editando un archivo de configuración llamado .elasticbeanstalk/iod-test.env.yml . Este archivo en realidad no existe localmente; eb lo sacó de los servidores de AWS y se lo presentó para que pueda cambiar la configuración en él. Si realiza algún cambio en este pseudoarchivo y luego lo guarda y sale, eb actualizará la configuración correspondiente en su entorno Beanstalk.

Si busca los términos "WSGI" en el archivo, debería encontrar una sección de configuración similar a esta:

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

Actualice WSGIPath:

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

Y luego tendrá su WSGIPath configurado correctamente. Si luego guarda el archivo y sale, eb actualizará la configuración del entorno automáticamente:

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.

La ventaja de usar eb config El método para cambiar la configuración es que puede especificar diferentes configuraciones por entorno. Pero también puede actualizar la configuración usando el mismo .config archivos que estábamos usando antes. Esto usará la misma configuración para cada entorno, como el .config los archivos se aplicarán en la implementación (después de la configuración de eb config han sido aplicados).

Opción 2:Usar ajustes de configuración global

Para usar el .config opción de archivo, creemos un nuevo archivo llamado /.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/"

¿Qué está pasando?

• DJANGO_SETTINGS_MODULE: "iotd.settings" - agrega la ruta al módulo de configuración.
• "PYTHONPATH": "/opt/python/current/app/iotd:$PYTHONPATH" - actualiza nuestro PYTHONPATH para que Python pueda encontrar los módulos en nuestra aplicación. ¡Esta ruta puede variar según su configuración! Consulte este comentario para obtener más detalles. (Tenga en cuenta que el uso de la ruta completa es necesario).
• WSGIPath: iotd/iotd/wsgi.py establece nuestra ruta WSGI.
• NumProcesses: 3 y NumThreads: 20 - actualiza la cantidad de procesos y subprocesos utilizados para ejecutar nuestra aplicación WSGI.
• "/static/": "www/static/" establece la ruta de nuestros archivos estáticos.

De nuevo, podemos hacer un git commit luego un eb deploy para actualizar esta configuración.

A continuación, agreguemos una base de datos.

Configuración de una base de datos

Intente ver el sitio web implementado:

$ eb open

Este comando mostrará la aplicación implementada en su navegador predeterminado. Debería ver un error de conexión rechazada:

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?

Esto se debe a que aún no hemos configurado una base de datos. En este punto eb configurará su entorno Beanstalk, pero no configurará RDS (el nivel de la base de datos). Tenemos que configurarlo manualmente.

Configuración de la base de datos

De nuevo, usa eb console para abrir la página de configuración de Beanstalk.

A partir de ahí, haz lo siguiente:

1. Haga clic en el enlace "Configuración".
2. Desplácese hasta el final de la página y luego, en la sección "Nivel de datos", haga clic en el enlace "crear una nueva base de datos RDS".
3. En la página de configuración de RDS, cambie el "Motor DB" a "postgres".
4. Agregue un "Nombre de usuario maestro" y una "Contraseña maestra".
5. Guarde los cambios.

Beanstalk creará el RDS por ti. Ahora necesitamos que nuestra aplicación Django se conecte al RDS. Beanstalk nos ayudará aquí exponiendo una serie de variables de entorno en las instancias EC2 para nosotros que detallan cómo conectarse al servidor de Postgres. Así que todo lo que tenemos que hacer es actualizar nuestro settings.py archivo para aprovechar esas variables de entorno. Confirme que las DATABASES El parámetro de configuración refleja lo siguiente en 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',
        }
    }

Esto simplemente dice:"use la configuración de la variable de entorno si está presente; de ​​lo contrario, use nuestra configuración de desarrollo predeterminada". Sencillo.

Manejo de migraciones de bases de datos

Con la configuración de nuestra base de datos, aún debemos asegurarnos de que las migraciones se ejecuten para que la estructura de la tabla de la base de datos sea correcta. Podemos hacerlo modificando .ebextensions/02_python.config y agregando las siguientes líneas en la parte superior del archivo:

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

container_commands le permite ejecutar comandos arbitrarios después de que la aplicación se haya implementado en la instancia EC2. Debido a que la instancia EC2 se configura mediante un entorno virtual, primero debemos activar ese entorno virtual antes de ejecutar nuestro comando de migración. También el leader_only: true la configuración significa "ejecutar este comando solo en la primera instancia cuando se implemente en varias instancias".

No olvide que nuestra aplicación utiliza el administrador de Django, por lo que necesitaremos un superusuario...

Crear el usuario administrador

Desafortunadamente createsuperuser no le permite especificar una contraseña cuando usa --noinput opción, por lo que tendremos que escribir nuestro propio comando. Afortunadamente, Django hace que sea muy fácil crear comandos personalizados.

Cree el archivo 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")

Asegúrese de agregar el __init__.py apropiado archivos también:

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

Este archivo le permitirá ejecutar python manage.py createsu , y creará un superusuario sin solicitar una contraseña. Siéntase libre de expandir el comando para usar variables de entorno u otros medios que le permitan cambiar la contraseña.

Una vez que haya creado el comando, podemos simplemente agregar otro comando a nuestro container_commands sección en .ebextensions/02_python.config :

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

Antes de probar esto, asegurémonos de que todos nuestros archivos estáticos estén en el lugar correcto...

Archivos estáticos

Agregue un comando más en container_commands :

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

Entonces todo el archivo se ve así:

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

Ahora debemos asegurarnos de que STATIC_ROOT está configurado correctamente en settings.py archivo:

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

Asegúrate de confirmar el www directorio a git para que se pueda crear el directorio estático. Luego ejecute eb deploy de nuevo, y ahora debería estar en el negocio:

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.

En este punto, debería poder ir a http://your_app_url/admin, iniciar sesión, agregar una imagen y luego ver esa imagen en la página principal de su aplicación.

¡Éxito!

Uso de S3 para almacenamiento multimedia

Con esta configuración, cada vez que implementemos nuevamente, perderemos todas nuestras imágenes cargadas. ¿Por qué? Bueno, cuando ejecutas eb deploy , se crea una nueva instancia para usted. Esto no es lo que queremos ya que entonces tendremos entradas en la base de datos para las imágenes, pero no imágenes asociadas. La solución es almacenar los archivos multimedia en Amazon Simple Storage Service (Amazon S3) en lugar de en la propia instancia EC2.

Necesitarás:

1. Crear un cubo
2. Obtenga el ARN de su usuario (Nombre de recurso de Amazon)
3. Agregar permisos de depósito
4. Configure su aplicación Django para usar S3 para servir sus archivos estáticos

Dado que ya hay buenos comentarios sobre esto, solo le indicaré mi favorito:usar Amazon S3 para almacenar sus archivos multimedia y estáticos de Django

Configuración de Apache

Dado que estamos usando Apache con Beanstalk, probablemente queramos configurar Apache para (entre otras cosas) habilitar la compresión gzip para que los clientes descarguen los archivos más rápido. Eso se puede hacer con container_commands . Cree un nuevo archivo .ebextensions/03_apache.config y agrega lo siguiente:

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

Luego necesita crear el archivo .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>

Hacer esto habilitará la compresión gzip, lo que debería ayudar con el tamaño de los archivos que está descargando. También puede usar la misma estrategia para minimizar y combinar automáticamente su CSS/JS y hacer cualquier otro preprocesamiento que necesite hacer.

Resolución de problemas

No olvides el muy útil eb ssh comando, que lo llevará a la instancia de EC2 para que pueda hurgar y ver qué está pasando. Al solucionar problemas, hay algunos directorios que debe tener en cuenta:

• /opt/python :Raíz de donde terminará su aplicación.
• /opt/python/current/app :La aplicación actual que está alojada en el entorno.
• /opt/python/on-deck/app :la aplicación se pone inicialmente en la cubierta y luego, después de que se complete toda la implementación, se moverá a current . Si obtiene fallas en su container_commands , mira el on-deck carpeta y no el current carpeta.
• /opt/python/current/env :Todas las variables env que eb configurará para usted. Si está intentando reproducir un error, es posible que primero deba source /opt/python/current/env para configurar las cosas como lo harían cuando se ejecuta eb deployment.
• opt/python/run/venv :El entorno virtual utilizado por su aplicación; también deberá ejecutar source /opt/python/run/venv/bin/activate si está intentando reproducir un error.

Conclusión

La implementación en Elastic Beanstalk puede ser un poco abrumadora al principio, pero una vez que comprenda dónde están todas las partes y cómo funcionan las cosas, en realidad es bastante fácil y extremadamente flexible. También le brinda un entorno que escalará automáticamente a medida que crezca su uso. ¡Ojalá ya tengas suficiente para ser peligroso! Buena suerte en tu próxima implementación de Beanstalk.

Bono gratis: Haga clic aquí para obtener acceso a una Guía de recursos de aprendizaje de Django (PDF) gratuita que le muestra consejos y trucos, así como las trampas comunes que debe evitar al crear aplicaciones web de Python + Django.

¿Nos perdimos algo? ¿Tienes otros consejos o trucos? Comente a continuación.