One place for hosting & domains

      Cómo escalar y proteger una aplicación de Django con Docker, Nginx y Let’s Encrypt


      Introducción

      En los entornos basados en la nube, hay diversas maneras de escalar y proteger aplicaciones de Django. Al escalar horizontalmente y ejecutar varias copias de su aplicación, puede crear un sistema más tolerante a fallos y de alta disponibilidad, a la vez que aumenta su rendimiento para que se puedan procesar solicitudes de forma simultánea. Una manera de escalar horizontalmente una aplicación de Django es proporcionar servidores de aplicaciones adicionales que ejecuten su aplicación de Django y su servidor HTTP WSGI (como Gunicorn o uWSGI). Para dirigir y distribuir las solicitudes entrantes a través de este conjunto de servidores de aplicaciones, puede usar un equilibrador de carga y un proxy inverso como Nginx. Nginx también puede almacenar en caché contenido estático y detener las conexiones de Seguridad de la capa de transporte (TLS), que se utilizan para proporcionar conexiones HTTPS y seguras a su aplicación.

      Ejecutar su aplicación de Django y el proxy Nginx dentro de contenedores de Docker garantiza que estos componentes se comporten de la misma manera independientemente del entorno en el que se implementen. Además, los contenedores proporcionan muchas características que facilitan la creación de paquetes y la configuración de su aplicación.

      En este tutorial, escalará horizontalmente una aplicación Polls de Django y Gunicorn en un contenedor proporcionando dos servidores de aplicaciones que ejecutarán una copia de un contenedor de una aplicación de Django y Gunicorn.

      También habilitará HTTPS al proporcionar y configurar un tercer servidor proxy que ejecutará un contenedor de un proxy inverso Nginx y otro de un cliente Certbot. Certbot proporcionará certificados TLS para Nginx de la entidad de certificación Let’s Encrypt. Esto garantizará que su sitio reciba una calificación de seguridad alta de SSL Labs. Este servidor proxy recibirá todas las solicitudes externas de su aplicación y se ubicará frente a los dos servidores de aplicaciones de Django que preceden en la cadena. Por último, reforzará este sistema distribuido al restringir el acceso externo solo al servidor proxy.

      Requisitos previos

      Para seguir este tutorial, necesitará lo siguiente:

      • Tres servidores con Ubuntu 18.04:

        • Dos se utilizarán como servidores de aplicaciones y se utilizarán para ejecutar su aplicación de Django y Gunicorn.
        • Uno se usará como servidor proxy y se utilizará para ejecutar Nginx y Certbot.
        • Todos los usuarios deben tener un usuario no root con privilegios sudo y firewall activo. Para obtener información sobre cómo configurarlos, consulte esta guía de configuración inicial para servidores.
      • Docker instalado en los tres servidores. Para obtener orientación sobre la instalación de Docker, siga los pasos 1 y 2 de Cómo instalar y usar Docker en Ubuntu 18.04.

      • Un nombre de dominio registrado. En este tutorial, utilizaremos your_domain en todo momento. Puede obtener un ejemplar gratis en Freenom o utilizar el registrador de dominios que desee.

      • Un registro DNS A con your_domain.com orientado a la dirección IP pública de su servidor proxy. Puede seguir esta introducción al DNS de DigitalOcean para obtener información sobre cómo agregarlo a una cuenta de DigitalOcean, si usa una:

      • Un depósito de almacenamiento de objetos S3, como un Space de DigitalOcean, para almacenar los archivos estáticos de su proyecto de Django y un conjunto de claves de acceso para ese espacio. Para obtener información sobre cómo crear Spaces, consulte la documentación de Cómo crear Spaces. Para obtener información sobre cómo crear claves de acceso para Spaces, consulte Compartir el acceso a Spaces con claves de acceso. Con cambios menores, puede usar cualquier servicio de almacenamiento de objetos que admita el complemento django-storages

      • Una instancia de un servidor de PostgreSQL, una base de datos y un usuario para su aplicación de Django. Con cambios menores, puede usar cualquier base de datos que admita Django.

      Paso 1: Configurar el primer servidor de aplicaciones de Django

      Para comenzar, vamos a clonar el repositorio de aplicaciones de Django en el primer servidor de aplicaciones. A continuación, configuraremos y compilaremos la imagen de Docker de la aplicación y probaremos la aplicación ejecutando el contenedor de Django.

      Nota: Si continúa desde Cómo crear una aplicación de Django y Gunicorn con Docker, ya habrá completado el Paso 1, por lo que puede pasar directamente al Paso 2 para configurar el segundo servidor de aplicaciones.

      Comience iniciando sesión en el primero de los dos servidores de aplicaciones de Django. Utilice git para clonar la rama polls-docker del repositorio de GitHub de la aplicación Polls del tutorial de Django. Este repositorio contiene código para la aplicación Polls de muestra de la documentación de Django. La rama polls-docker contiene una versión con Docker de la aplicación Polls. Para obtener información sobre cómo se modificó la aplicación Polls para que funcione de forma eficaz en un entorno con contenedor, consulte Cómo crear una aplicación de Django y Gunicorn con Docker.

      • git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

      Diríjase al directorio django-polls:

      cd django-polls
      

      Este directorio contiene el código de Python de la aplicación de Django, un Dockerfile que Docker utilizará para crear la imagen del contenedor, y un archivo env que contiene una lista de las variables de entorno que se van a pasar al entorno en ejecución del contenedor. Inspeccione el Dockerfile con cat:

      cat Dockerfile
      

      Output

      FROM python:3.7.4-alpine3.10 ADD django-polls/requirements.txt /app/requirements.txt RUN set -ex && apk add --no-cache --virtual .build-deps postgresql-dev build-base && python -m venv /env && /env/bin/pip install --upgrade pip && /env/bin/pip install --no-cache-dir -r /app/requirements.txt && runDeps="$(scanelf --needed --nobanner --recursive /env | awk '{ gsub(/,/, "nso:", $2); print "so:" $2 }' | sort -u | xargs -r apk info --installed | sort -u)" && apk add --virtual rundeps $runDeps && apk del .build-deps ADD django-polls /app WORKDIR /app ENV VIRTUAL_ENV /env ENV PATH /env/bin:$PATH EXPOSE 8000 CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi"]

      Este Dockerfile utiliza la imagen de Docker oficial de Python 3.7.4 como base e instala los requisitos del paquete de Python de Django y Gunicorn, tal como se define en el archivo django-polls/requirements.txt. A continuación, elimina algunos archivos de compilación innecesarios, copia el código de la aplicación en la imagen y establece el PATH de ejecución. Por último, declara que el puerto 8000 se utilizará para aceptar conexiones de contenedores entrantes y ejecuta gunicorn con 3 trabajadores, escuchando en el puerto 8000.

      Para obtener más información sobre cada uno de los pasos de este Dockerfile, consulte el Paso 6 de Cómo crear una aplicación de Django y Gunicorn con Docker.

      Ahora, compile la imagen con docker build:

      Nombramos la imagen polls con el indicador -t y pasamos el directorio actual como contexto de compilación, el conjunto de archivos a los que se debe hacer referencia al construir la imagen.

      Una vez que Docker haya compilado y etiquetado la imagen, enumere las imágenes disponibles utilizando docker images:

      docker images
      

      Debería ver la imagen polls enumerada:

      Output

      REPOSITORY TAG IMAGE ID CREATED SIZE polls latest 80ec4f33aae1 2 weeks ago 197MB python 3.7.4-alpine3.10 f309434dea3a 8 months ago 98.7MB

      Antes de ejecutar el contenedor de Django, debemos configurar su entorno de ejecución utilizando el archivo env presente en el directorio actual. Este archivo se pasará al comando docker run que se utiliza para ejecutar el contenedor y Docker insertará las variables de entorno configuradas en el entorno en ejecución del contenedor.

      Abra el archivo env con nano o su editor favorito:

      nano env
      

      Configuraremos el archivo de esta manera y deberá agregar algunos valores adicionales como se indica a continuación.

      django-polls/env

      DJANGO_SECRET_KEY=
      DEBUG=True
      DJANGO_ALLOWED_HOSTS=
      DATABASE_ENGINE=postgresql_psycopg2
      DATABASE_NAME=polls
      DATABASE_USERNAME=
      DATABASE_PASSWORD=
      DATABASE_HOST=
      DATABASE_PORT=
      STATIC_ACCESS_KEY_ID=
      STATIC_SECRET_KEY=
      STATIC_BUCKET_NAME=
      STATIC_ENDPOINT_URL=
      DJANGO_LOGLEVEL=info
      

      Complete los valores que faltan para las siguientes claves:

      • DJANGO_SECRET_KEY: establézcala en un valor único e impredecible, como se detalla en la documentación de Django. Se proporciona un método para generar esta clave en la sección Ajustar la configuración de la aplicación del tutorial Aplicaciones escalables de Django.
      • DJANGO_ALLOWED_HOSTS: esta variable asegura la aplicación y evita ataques a través del encabezado de host HTTP. Para propósitos de prueba, establézcala en *, un comodín que coincidirá con todos los hosts. En producción, debe establecerlo en your_domain.com. Para obtener más información sobre esta configuración de Django, consulte la sección Configuración principal en la documentación de Django.
      • DATABASE_USERNAME: establézcalo en el usuario de la base de datos de PostgreSQL creado en los pasos de requisitos previos.
      • DATABASE_NAME: establézcalo en polls o el nombre de la base de datos de PostgreSQL creado en los pasos de requisitos previos.
      • DATABASE_PASSWORD: establézcala en la contraseña de la base de datos de PostgreSQL creada en los pasos de requisitos previos.
      • DATABASE_HOST: establézcalo en el nombre de host de su base de datos.
      • DATABASE_PORT: Set establézcalo en el puerto de su base de datos.
      • STATIC_ACCESS_KEY_ID: establézcala en la clave de acceso de su cubo S3 o su Space.
      • STATIC_SECRET_KEY: establézcala en el secreto de la clave de acceso de su cubo S3 o su Space.
      • STATIC_BUCKET_NAME: establézcalo en el nombre de su cubo S3 o su Space.
      • STATIC_ENDPOINT_URL: establézcala en la URL de extremo correspondiente de su cubo S3 o su Space, por ejemplo, https://space-name.nyc3.digitaloceanspaces.com, si su Space está ubicado en la región nyc3.

      Una vez que haya finalizado la edición, guarde y cierre el archivo.

      Ahora, utilizaremos docker run para anular el CMD establecido en Dockerfile y crear el esquema de la base de datos utilizando los comandos manage.py makemigrations y manage.py migrate:

      docker run --env-file env polls sh -c "python manage.py makemigrations && python manage.py migrate"
      

      Ejecutamos la imagen del contenedor polls:latest, pasamos el archivo de variables de entorno que acabamos de modificar y anulamos el comando de Dockerfile con sh -c "python manage.py makemigrations && python manage.py migrate", lo que creará el esquema de la base de datos definido mediante el código de la aplicación. Si lo ejecuta por primera vez, debería ver lo siguiente:

      Output

      No changes detected Operations to perform: Apply all migrations: admin, auth, contenttypes, polls, sessions Running migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying polls.0001_initial... OK Applying sessions.0001_initial... OK

      Esto indica que el esquema de la base de datos se ha creado correctamente.

      Si no está ejecutando migrate por primera vez, Django realizará un no-op a menos que el esquema de la base de datos haya cambiado.

      A continuación, ejecutaremos otra instancia del contenedor de la aplicación y utilizaremos una shell interactiva en su interior para crear un usuario administrativo para el proyecto de Django.

      docker run -i -t --env-file env polls sh
      

      Esto le proporcionará una línea de comandos de shell dentro del contenedor en ejecución que puede usar para crear el usuario de Django:

      python manage.py createsuperuser
      

      Ingrese un nombre de usuario, una dirección de correo electrónico y una contraseña para su usuario y, una vez que haya creado el usuario, presione CTRL+D para salir del contenedor y cerrarlo.

      Por último, generaremos los archivos estáticos de la aplicación y los subiremos al Space de DigitalOcean utilizando collectstatic. Tenga en cuenta que esta operación puede tardar un poco en completarse.

      docker run --env-file env polls sh -c "python manage.py collectstatic --noinput"
      

      Una vez que estos archivos se hayan generado y cargado, obtendrá el siguiente resultado.

      Output

      121 static files copied.

      Ahora, podemos ejecutar la aplicación:

      docker run --env-file env -p 80:8000 polls
      

      Output

      [2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0 [2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1) [2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync [2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7 [2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8 [2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

      Aquí, ejecutamos el comando predeterminado definido en el Dockerfile, gunicorn --bind :8000 --workers 3 mysite.wsgi:application y exponemos el puerto del contenedor 8000 para que el puerto 80 del servidor de Ubuntu se asigne al puerto 8000 del contenedor polls.

      Ahora, debería poder navegar a la aplicación polls desde su navegador web al escribir http://APP_SERVER_1_IP en la barra de direcciones URL. Dado que no hay una ruta definida para la ruta / , es probable que reciba un error de 404 Page Not Found (Página no encontrada), lo que es de esperar.

      Advertencia: Al usar el firewall UFW con Docker, Docker omite cualquier regla de firewall configurada, tal como se documenta en este número de GitHub. Esto explica por qué tiene acceso al puerto 80 de su servidor, a pesar de no haber creado explícitamente una regla de acceso de UFW en ningún paso de los requisitos previos. Abordaremos este problema de seguridad en el Paso 5, al corregir la configuración de UFW. Si no usa UFW y está utilizando firewalls de DigitalOcean para la nube, puede ignorar de forma segura esta advertencia.

      Diríjase a http://APP_SERVER_1_IP/polls para ver la interfaz de la aplicación Polls:

      Interfaz de la aplicación Polls

      Para ver la interfaz administrativa, visite http://APP_SERVER_1_IP/admin. Debería ver la ventana de autenticación de administración de la aplicación Polls:

      Página de autenticación de administración de Polls

      Ingrese el nombre de usuario administrativo y la contraseña que creó con el comando createsuperuser.

      Después de la autenticación, podrá acceder a la interfaz administrativa de la aplicación Polls:

      Interfaz principal de administración de Polls

      Tenga en cuenta que los que los recursos estáticos de las aplicaciones admin y polls se entregan directamente desde el almacenamiento de objetos. Para confirmar esto, consulte Prueba de la entrega de archivos estáticos de Spaces.

      Cuando haya terminado de explorar, presione CTRL+C en la ventana de terminal que está ejecutando el contenedor de Docker para cerrar el contenedor.

      Ahora que ha confirmado que el contenedor de la aplicación se ejecuta de la manera prevista, puede ejecutarlo en modo separado, lo que lo ejecutará en segundo plano y le permitirá salir de su sesión SSH:

      docker run -d --rm --name polls --env-file env -p 80:8000 polls
      

      El indicador -d le indica a Docker que ejecute el contenedor en modo separado y el indicador -rm limpia el sistema de archivos del contenedor una vez que se sale de él. Denominamos polls al contenedor.

      Desconéctese del primer servidor de aplicaciones de Django y diríjase a http://APP_SERVER_1_IP/polls para confirmar que el contenedor se está ejecutando de la manera prevista.

      Ahora que su primer servidor de aplicaciones de Django está en ejecución, puede configurar el segundo.

      Paso 2: Configurar el segundo servidor de aplicaciones de Django

      Como muchos de los comandos que se utilizan para configurar este servidor serán los mismos que los que utilizamos en el paso anterior, se presentarán aquí de forma abreviada. Revise el Paso 1 para obtener más información sobre los comandos que se utilizan en este paso.

      Comience por iniciar sesión en el segundo servidor de aplicaciones de Django.

      Clone la rama polls-docker del repositorio de GitHub django-polls:

      • git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

      Diríjase al directorio django-polls:

      cd django-polls
      

      Compile la imagen con docker build:

      Abra el archivo env con nano o su editor favorito:

      nano env
      

      django-polls/env

      DJANGO_SECRET_KEY=
      DEBUG=True
      DJANGO_ALLOWED_HOSTS=
      DATABASE_ENGINE=postgresql_psycopg2
      DATABASE_NAME=polls
      DATABASE_USERNAME=
      DATABASE_PASSWORD=
      DATABASE_HOST=
      DATABASE_PORT=
      STATIC_ACCESS_KEY_ID=
      STATIC_SECRET_KEY=
      STATIC_BUCKET_NAME=
      STATIC_ENDPOINT_URL=
      DJANGO_LOGLEVEL=info
      

      Complete los valores que faltan como se indica en el Paso 1. Cuando haya terminado de editar, guarde y cierre el archivo.

      Por último, ejecute el contenedor de la aplicación en modo separado:

      docker run -d --rm --name polls --env-file env -p 80:8000 polls
      

      Diríjase a http://APP_SERVER_2_IP/polls para confirmar que el contenedor se está ejecutando de la manera prevista. Puede iniciar sesión de forma segura en el segundo servidor de aplicaciones sin cerrar el contenedor en ejecución.

      Con los dos contenedores de aplicaciones de Django en ejecución, puede configurar el contenedor del proxy inverso Nginx.

      Paso 3: Configurar el contenedor de Docker de Nginx

      Nginx es un servidor web versátil que ofrece varias características, como proxy inverso, equilibrio de carga y almacenamiento en caché. En este tutorial, hemos descargado los recursos estáticos de Django al almacenamiento de objetos, por lo que no utilizaremos las capacidades de almacenamiento en caché de Nginx. Sin embargo, utilizaremos Nginx como proxy inverso para nuestros dos servidores de aplicaciones de Django de backend y distribuiremos las solicitudes entrantes entre ellos. Además, Nginx realizará la terminación de TLS y el redireccionamiento utilizando un certificado TLS proporcionado por Certbot. Esto significa que obligará a los clientes a usar HTTPS, redireccionando las solicitudes HTTP entrantes al puerto 443. Luego, descifrará las solicitudes HTTPS y las redirigirá, a través del proxy, a los servidores de Django que preceden en la cadena.

      En este tutorial, hemos tomado la decisión de desacoplar los contenedores de Nginx de los servidores de backend. Dependiendo de su caso de uso, puede optar por ejecutar el contenedor de Nginx en cualquiera de los dos servidores de aplicaciones de Django, redirigiendo las solicitudes, a través del proxy, de forma local. Otra posible arquitectura sería ejecutar dos contenedores de Nginx, uno en cada servidor de backend, con un equilibrador de carga en la nube al frente. Cada arquitectura presenta diferentes ventajas de seguridad y desempeño; debe realizar una prueba de carga de su sistema para descubrir los posibles cuellos de botella. La arquitectura flexible que se describe en este tutorial le permite escalar tanto la capa de la aplicación de Django de backend como la capa del proxy de Nginx. Cuando el contenedor único de Nginx se convierta en un cuello de botella, puede escalar varios proxy de Nginx y agregar un equilibrador de carga en la nube o uno L4 rápido, como HAProxy.

      Con los dos servidores de aplicaciones de Django en ejecución, podemos comenzar a configurar el servidor proxy de Nginx. Inicie sesión en su servidor proxy y cree un directorio llamado conf:

      mkdir conf
      

      Cree un archivo de configuración denominado nginx.conf con nano o su editor favorito:

      nano conf/nginx.conf
      

      Pegue la siguiente configuración de Nginx:

      conf/nginx.conf

      
      upstream django {
          server APP_SERVER_1_IP;
          server APP_SERVER_2_IP;
      }
      
      server {
          listen 80 default_server;
          return 444;
      }
      
      server {
          listen 80;
          listen [::]:80;
          server_name your_domain.com;
          return 301 https://$server_name$request_uri;
      }
      
      server {
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          server_name your_domain.com;
      
          # SSL
          ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
      
          ssl_session_cache shared:le_nginx_SSL:10m;
          ssl_session_timeout 1440m;
          ssl_session_tickets off;
      
          ssl_protocols TLSv1.2 TLSv1.3;
          ssl_prefer_server_ciphers off;
      
          ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
      
          client_max_body_size 4G;
          keepalive_timeout 5;
      
              location / {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_pass http://django;
              }
      
          location ^~ /.well-known/acme-challenge/ {
              root /var/www/html;
          }
      
      }
      

      Los bloques upstream, server y location configuran Nginx para que redirija las solicitudes HTTP a HTTPS y equilibre su carga entre los dos servidores de aplicaciones de Django configurados en los pasos 1 y 2. Para obtener más información sobre la estructura de los archivos de configuración de Nginx, consulte el artículo Información sobre la estructura de los archivos y los contextos de configuración de Nginx. El artículo Información sobre algoritmos de selección de bloques de servidores y ubicación de Nginx también puede resultarle útil.

      Esta configuración se realizó a partir de archivos de configuración de muestra proporcionados por Gunicorn, Cerbot y Nginx y representa una configuración mínima de Nginx para poner en marcha esta arquitectura. Los ajustes de esta configuración de Nginx están fuera del alcance de este artículo, pero puede usar una herramienta como NGINXConfig para generar archivos de configuración de Nginx seguros y de buen rendimiento para su arquitectura.

      El bloque upstream define el grupo de servidores que se utiliza para redirigir las solicitudes mediante el proxy utilizando la directiva proxy_pass:

      conf/nginx.conf

      upstream django {
          server APP_SERVER_1_IP;
          server APP_SERVER_2_IP;
      }
      . . .
      

      En este bloque, lo denominamos django e incluimos las direcciones IP de los dos servidores de aplicaciones de Django. Si los servidores de aplicaciones se ejecutan en DigitalOcean y tienen habilitadas redes VPC, debe usar sus direcciones IP privadas aquí. Para obtener información sobre cómo habilitar las redes VPC en DigitalOcean, consulte Cómo habilitar redes VPC en Droplets existentes.

      El primer bloque server captura las solicitudes que no coinciden con su dominio y termina la conexión. Por ejemplo, este bloque manejaría una solicitud HTTP directa a la dirección IP de su servidor:

      conf/nginx.conf

      . . .
      server {
          listen 80 default_server;
          return 444;
      }
      . . .
      

      El siguiente bloque server redirige las solicitudes HTTP a su dominio a HTTPS utilizando un redireccionamiento HTTP 301. Luego, el bloque server final se encarga de manejar estas solicitudes:

      conf/nginx.conf

      . . .
      server {
          listen 80;
          listen [::]:80;
          server_name your_domain.com;
          return 301 https://$server_name$request_uri;
      }
      . . .
      

      Estas dos directivas definen las rutas al certificado TLS y la clave secreta. Se proporcionarán utilizando Certbot y se instalarán en el contenedor de Nginx en el siguiente paso.

      conf/nginx.conf

      . . .
      ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
      . . .
      

      Estos parámetros son los valores predeterminados de seguridad SSL recomendados por Certbot. Para obtener más información sobre ellos, consulte el Módulo ngx_http_ssl_module en la documentación de Nginx. La guía Seguridad/TLS del lado del servidor de Mozilla es otro recurso útil que puede usar para ajustar su configuración de SSL.

      conf/nginx.conf

      . . .
          ssl_session_cache shared:le_nginx_SSL:10m;
          ssl_session_timeout 1440m;
          ssl_session_tickets off;
      
          ssl_protocols TLSv1.2 TLSv1.3;
          ssl_prefer_server_ciphers off;
      
          ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
      . . .
      

      Estas dos directivas de la configuración de muestra de Nginx de Gunicorn establecen el tamaño máximo permitido del cuerpo de la solicitud del cliente y asignan el tiempo de espera para las conexiones persistentes con el cliente. Nginx cerrará las conexiones con el cliente una vez transcurridos los segundos de keepalive_timeout.

      conf/nginx.conf

      . . .
      client_max_body_size 4G;
      keepalive_timeout 5;
      . . .
      

      El primer bloque location le indica a Nginx que redirija, a través del proxy, las solicitudes a los servidores upstream django mediante HTTP. También preserva los encabezados HTTP del cliente que capturan la dirección IP de origen, el protocolo utilizado para la conexión y el host de destino:

      conf/nginx.conf

      . . .
      location / {
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_pass http://django;
      }
      . . .
      

      Para obtener más información sobre estas directivas, consulte Implementación de Gunicorn y Module ngx_http_proxy_module en la documentación de Nginx.

      El bloque location final captura las solicitudes a la ruta /well-known/acme-challenge/ que utiliza Certbot en los desafíos de HTTP-01 para verificar su dominio con Let’s Encrypt y suministrar o renovar los certificados TLS.  Para obtener más información sobre el desafío HTTP-01 que utiliza Certbot, consulte Tipos de desafíos en la documentación de Let’s Encrypt.

      conf/nginx.conf

      . . .
      location ^~ /.well-known/acme-challenge/ {
              root /var/www/html;
      }
      

      Una vez que haya finalizado la edición, guarde y cierre el archivo.

      Ahora, puede usar este archivo de configuración para ejecutar un contenedor de Docker de Nginx. En este tutorial, utilizaremos la imagen nginx:1.19.0, versión 1.19.0, de la imagen de Docker oficial que mantiene Nginx.

      Cuando ejecutemos el contenedor por primera vez, Nginx arrojará un error y fallará, dado que aún no hemos proporcionado los certificados definidos en el archivo de configuración. De todos modos, ejecutaremos el comando para descargar la imagen de Nginx de forma local y probar que todo lo demás funcione correctamente:

      docker run --rm --name nginx -p 80:80 -p 443:443 
          -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro 
          -v /var/www/html:/var/www/html 
          nginx:1.19.0
      

      Aquí, denominamos nginx al contenedor y asignamos los puertos del host 80 y 443 a los puertos de los contenedores respectivos. El indicador -v ubica el archivo config en el contenedor de Nginx en /etc/nginx/conf.d/nginx.conf, que la imagen de Nginx está preconfigurada para cargar. Se coloca en modo ro o de “solo lectura”, por lo que el contenedor no puede modificar el archivo. El directorio web root /var/www/html también se instala en el contenedor. Por último, nginx:1.19.0 le indica a Docker que extraiga y ejecute la imagen nginx:1.19.0 de Dockerhub.

      Docker extraerá y ejecutará la imagen y, luego, Nginx arrojará un error cuando no encuentre el certificado TLS configurado y la clave secreta. Los suministraremos en el siguiente paso utilizando un cliente de Cerbot con Docker y la entidad de certificación Let’s Encrypt.

      Paso 4: Configurar la renovación de certificados de Let’s Encrypt y Certbot

      Certbot es un cliente Let’s Encrypt desarrollado por Electronic Frontier Foundation. Proporciona certificados TLS gratuitos de la entidad de certificación Let’s Encrypt que permiten a los navegadores verificar la identidad de sus servidores web. Como tenemos Docker instalado en nuestro servidor proxy de Nginx, utilizaremos la imagen de Docker de Certbot para suministrar y renovar los certificados TLS.

      Comience por asegurarse de tener un registro DNS A asignado a la dirección IP pública del servidor proxy. A continuación, en su servidor proxy, proporcione una versión provisional de los certificados utilizando la imagen de Docker certbot:

      docker run -it --rm -p 80:80 --name certbot 
               -v "/etc/letsencrypt:/etc/letsencrypt" 
               -v "/var/lib/letsencrypt:/var/lib/letsencrypt" 
               certbot/certbot certonly --standalone --staging -d your_domain.com
      

      Este comando ejecuta la imagen de Docker certbot en modo interactivo y reenvía el puerto 80 del host al puerto 80 del contenedor. Crea y monta dos directorios de host en el contenedor: /etc/letsencrypt/ y /var/lib/letsencrypt/. certbot se ejecuta en modo standalone, sin Nginx, y utilizará los servidores staging de Let’s Encrypt para realizar la validación del dominio.

      Cuando se le solicite, ingrese su dirección de correo electrónico y acepte las Condiciones del servicio. Si la validación del dominio es correcta, debería ver el siguiente resultado:

      Output

      Obtaining a new certificate Performing the following challenges: http-01 challenge for stubb.dev Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain.com/privkey.pem Your cert will expire on 2020-09-15. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.

      Puede inspeccionar el certificado utilizando cat:

      sudo cat /etc/letsencrypt/live/your_domain.com/fullchain.pem
      

      Con el certificado TLS suministrado, podemos probar la configuración de Nginx que establecimos en el paso anterior:

      docker run --rm --name nginx -p 80:80 -p 443:443 
          -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro 
          -v /etc/letsencrypt:/etc/letsencrypt 
          -v /var/lib/letsencrypt:/var/lib/letsencrypt 
          -v /var/www/html:/var/www/html 
          nginx:1.19.0
      

      Este es el mismo comando que ejecutamos en el Paso 3, con la adición de los dos directorios de Let’s Encrypt que acabamos de crear.

      Una vez que Nginx esté en ejecución, diríjase a http://your_domain.com. Puede recibir una advertencia en su navegador indicando que la entidad de certificación no es válida. Esto es de esperar dado que suministramos certificados provisionales, no certificados de producción de Let’s Encrypt. Compruebe la barra de direcciones URL de su navegador para confirmar que su solicitud HTTP se haya redireccionado a HTTPS.

      Presione CTRL+C en su terminal para salir de Nginx y volver a ejecutar el cliente certbot, omitiendo el indicador --staging:

      docker run -it --rm -p 80:80 --name certbot 
               -v "/etc/letsencrypt:/etc/letsencrypt" 
               -v "/var/lib/letsencrypt:/var/lib/letsencrypt" 
               certbot/certbot certonly --standalone -d your_domain.com
      

      Cuando se le solicite mantener el certificado existente o renovarlo y sustituirlo, presione 2 para renovarlo y, luego, presione ENTER para confirmar su elección.

      Con el certificado TLS de producción suministrado, vuelva a ejecutar el servidor Nginx:

      docker run --rm --name nginx -p 80:80 -p 443:443 
          -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro 
          -v /etc/letsencrypt:/etc/letsencrypt 
          -v /var/lib/letsencrypt:/var/lib/letsencrypt 
          -v /var/www/html:/var/www/html 
          nginx:1.19.0
      

      En su navegador, diríjase a http://your_domain.com. En la barra de direcciones URL, confirme que la solicitud HTTP se haya redireccionado a HTTPS. Dado que la aplicación Polls no tiene una ruta predeterminada configurada, debería ver un error de Django de *Página no encontrada *. Diríjase a https://your_domain.com/polls para ver la interfaz estándar de la aplicación Polls:

      Interfaz de la aplicación Polls

      En este punto, ha suministrado un certificado TLS de producción utilizando el cliente de Docker Certbot y está redirigiendo las solicitudes externas a través del proxy inverso y equilibrando la carga entre los dos servidores de aplicaciones de Django.

      Los certificados de Let’s Encrypt caducan cada 90 días. Para asegurarse de que su certificado permanezca válido, debe renovarlo regularmente antes de su vencimiento programado. Con Nginx en ejecución, debe usar el cliente de Certbot en modo webroot en vez de standalone. Esto significa que Certbot realizará la validación creando un archivo en el directorio /var/www/html/.well-known/acme-challenge/ y la regla location definida en la configuración de Nginx realizada en el Paso 3 capturará las solicitudes de validación de Let’s Encrypt a esta ruta. A continuación, Certbot rotará los certificados, y usted podrá volver a cargar Nginx para que utilice este certificado recién suministrado.

      Hay varias formas de automatizar este procedimiento, pero la renovación automática de certificados TLS está fuera del alcance de este tutorial. Para obtener un proceso similar usando la utilidad de programación cron, consulte el paso 6 de Cómo proteger una aplicación de Node.js en un contenedor con Nginx, Let’s Encrypt y Docker Compose.

      En su terminal, presione CTRL+C para cerrar el contenedor de Nginx. Vuelva a ejecutarlo en modo separado al agregar el indicador -d:

      docker run --rm --name nginx -d -p 80:80 -p 443:443 
          -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro 
          -v /etc/letsencrypt:/etc/letsencrypt 
          -v /var/lib/letsencrypt:/var/lib/letsencrypt 
        -v /var/www/html:/var/www/html 
          nginx:1.19.0
      

      Con Nginx ejecutándose en segundo plano, utilice el siguiente comando para realizar una ejecución de prueba del procedimiento de renovación de certificados:

      docker run -it --rm --name certbot 
          -v "/etc/letsencrypt:/etc/letsencrypt" 
        -v "/var/lib/letsencrypt:/var/lib/letsencrypt" 
        -v "/var/www/html:/var/www/html" 
        certbot/certbot renew --webroot -w /var/www/html --dry-run
      

      Utilizamos el complemento --webroot, especificamos la ruta web root y utilizamos el indicador --dry-run para verificar que todo funciona correctamente sin realizar la renovación de certificados real.

      Si la simulación de la renovación se realiza correctamente, debería ver el siguiente resultado:

      Output

      Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for your_domain.com Using the webroot path /var/www/html for all unmatched domains. Waiting for verification... Cleaning up challenges - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - new certificate deployed without reload, fullchain is /etc/letsencrypt/live/your_domain.com/fullchain.pem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/your_domain.com/fullchain.pem (success) ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      En un entorno de producción, después de renovar los certificados, debe volver a cargar Nginx para que los cambios surtan efecto. Para volver a cargar Nginx, ejecute el siguiente comando:

      docker kill -s HUP nginx
      

      Este comando enviará una señal HUP Unix al proceso de Nginx que se está ejecutando en el contenedor de Docker nginx. Al recibir esta señal, Nginx volverá a cargar su configuración y sus certificados renovados.

      Con HTTPS habilitado y todos los componentes de esta arquitectura en ejecución, el paso final es bloquear la configuración al evitar el acceso externo a los dos servidores de aplicaciones backend; todas las solicitudes HTTP deben pasar por el proxy de Nginx.

      Paso 5: Prevención de acceso externo a servidores de aplicaciones de Django

      En la arquitectura que se describe en este tutorial, la terminación de SSL se produce en el proxy de Nginx. Esto significa que Nginx descifra la conexión SSL y los paquetes se redirigen, a través del proxy, a los servidores de aplicaciones de Django no cifrados. Para muchos casos de uso, este nivel de seguridad es suficiente. Para las aplicaciones que incluyen datos financieros o de salud, es conveniente implementar cifrado de extremo a extremo. Puede hacerlo al reenviar paquetes cifrados a través del equilibrador de carga y descifrarlos en los servidores de aplicaciones o volver a cifrarlos en el proxy y descifrarlos nuevamente en los servidores de aplicaciones de Django. Estas técnicas están fuera del alcance de este artículo, pero puede consultar el documento Cifrado de extremo a extremo para obtener más información.

      El proxy de Nginx actúa como una puerta de enlace entre el tráfico externo y la red interna. En teoría, ningún cliente externo debería tener acceso directo a los servidores de aplicaciones internos y todas las solicitudes deberían pasar a través del servidor de Nginx. La nota del Paso 1 describe brevemente un problema abierto con Docker en el que Docker omite la configuración de firewall ufw de manera predeterminada y abre los puertos de forma externa, lo que puede ser peligroso. Para solucionar este problema de seguridad, se recomienda usar firewalls para la nube al trabajar con servidores con Docker. Para obtener más información sobre la creación de firewalls para la nube con DigitalOcean, consulte Cómo crear firewalls. También puede manipular iptables directamente en lugar de usar ufw. Para obtener más información sobre el uso de iptables con Docker, consulte Docker e iptables.

      En este paso, modificaremos la configuración de UFW para bloquear el acceso externo a los puertos del host que abre Docker. Al ejecutar Django en los servidores de aplicaciones, pasamos el indicador -p 80:8000 a docker, que reenvía el puerto 80 del host al puerto 8000 del contenedor. Esto también abrió el puerto 80 a clientes externos, lo que puede verificar al dirigirse a http://your_app_server_1_IP. Para evitar el acceso directo, modificaremos la configuración de UFW utilizando el método que se describe en el repositorio de GitHub ufw-docker.

      Comience por iniciar sesión en el primer servidor de aplicaciones de Django. A continuación, abra el archivo /etc/ufw/after.rules con privilegios de superusuario, utilizando nano o su editor favorito:

      sudo nano /etc/ufw/after.rules
      

      Cuando se le solicite, ingrese su contraseña y, luego, presione ENTER para confirmar.

      Debería ver las siguientes reglas ufw:

      /etc/ufw/after.rules

      #
      # rules.input-after
      #
      # Rules that should be run after the ufw command line added rules. Custom
      # rules should be added to one of these chains:
      #   ufw-after-input
      #   ufw-after-output
      #   ufw-after-forward
      #
      
      # Don't delete these required lines, otherwise there will be errors
      *filter
      :ufw-after-input - [0:0]
      :ufw-after-output - [0:0]
      :ufw-after-forward - [0:0]
      # End required lines
      
      # don't log noisy services by default
      -A ufw-after-input -p udp --dport 137 -j ufw-skip-to-policy-input
      -A ufw-after-input -p udp --dport 138 -j ufw-skip-to-policy-input
      -A ufw-after-input -p tcp --dport 139 -j ufw-skip-to-policy-input
      -A ufw-after-input -p tcp --dport 445 -j ufw-skip-to-policy-input
      -A ufw-after-input -p udp --dport 67 -j ufw-skip-to-policy-input
      -A ufw-after-input -p udp --dport 68 -j ufw-skip-to-policy-input
      
      # don't log noisy broadcast
      -A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
      
      # don't delete the 'COMMIT' line or these rules won't be processed
      COMMIT
      

      Pegue el siguiente bloque de reglas de configuración de UFW en la parte inferior:

      /etc/ufw/after.rules

      . . .
      
      # BEGIN UFW AND DOCKER
      *filter
      :ufw-user-forward - [0:0]
      :DOCKER-USER - [0:0]
      -A DOCKER-USER -j RETURN -s 10.0.0.0/8
      -A DOCKER-USER -j RETURN -s 172.16.0.0/12
      -A DOCKER-USER -j RETURN -s 192.168.0.0/16
      
      -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
      
      -A DOCKER-USER -j ufw-user-forward
      
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
      
      -A DOCKER-USER -j RETURN
      COMMIT
      # END UFW AND DOCKER
      

      Estas reglas restringen el acceso público a los puertos que abre Docker y permiten el acceso a los intervalos de IP privadas 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Si usa VPC con DigitalOcean, entonces, las Droplets de su red VPC tendrán acceso al puerto abierto a través de la interfaz de red privada, pero los clientes externos no lo tendrán. Para obtener más información sobre las VPC, consulte la documentación oficial de las VPC. Para obtener más información sobre las reglas implementadas en este fragmento de código, consulte ¿Cómo funciona? en el archivo README de ufw-docker.

      Si no está utilizando VPC con DigitalOcean y ha introducido las direcciones IP públicas de los servidores de aplicaciones en el bloque upstream de su configuración de Nginx, deberá modificar explícitamente el firewall UFW para que permita tráfico del servidor de Nginx a través del puerto 80 de los servidores de aplicaciones de Django. Para obtener información sobre la creación de reglas allow con el firewall de UFW, consulte Aspectos básicos de UFW: reglas y comandos comunes de firewall.

      Una vez que haya finalizado la edición, guarde y cierre el archivo.

      Reinicie ufw para que tome la nueva configuración:

      sudo systemctl restart ufw
      

      Diríjase a http://APP_SERVER_1_IP en su navegador web para confirmar que ya no pueda acceder al servidor de aplicaciones a través del puerto 80.

      Repita este proceso en el segundo servidor de aplicaciones de Django.

      Cierre sesión en el primer servidor de aplicaciones o abra otra ventana de terminal, e inicie sesión en el segundo servidor de aplicaciones de Django. A continuación, abra el archivo /etc/ufw/after.rules con privilegios de superusuario, utilizando nano o su editor favorito:

      sudo nano /etc/ufw/after.rules
      

      Cuando se le solicite, ingrese su contraseña y, luego, presione ENTER para confirmar.

      Pegue el siguiente bloque de reglas de configuración de UFW en la parte inferior:

      /etc/ufw/after.rules

      . . .
      
      # BEGIN UFW AND DOCKER
      *filter
      :ufw-user-forward - [0:0]
      :DOCKER-USER - [0:0]
      -A DOCKER-USER -j RETURN -s 10.0.0.0/8
      -A DOCKER-USER -j RETURN -s 172.16.0.0/12
      -A DOCKER-USER -j RETURN -s 192.168.0.0/16
      
      -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
      
      -A DOCKER-USER -j ufw-user-forward
      
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
      -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
      -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
      
      -A DOCKER-USER -j RETURN
      COMMIT
      # END UFW AND DOCKER
      

      Una vez que haya finalizado la edición, guarde y cierre el archivo.

      Reinicie ufw para que tome la nueva configuración:

      sudo systemctl restart ufw
      

      Diríjase a http://APP_SERVER_2_IP en su navegador web para confirmar que ya no pueda acceder al servidor de aplicaciones a través del puerto 80.

      Por último, diríjase a https://your_domain_here/polls para confirmar que el proxy de Nginx siga teniendo acceso a los servidores de Django que preceden en la cadena. Debería ver la interfaz predeterminada de la aplicación de Polls.

      Conclusión

      En este tutorial, configuró una aplicación Polls de Django escalable utilizando contenedores de Docker. A medida que su tráfico y la carga en el sistema aumenten, puede escalar cada capa de forma separada: la capa de redireccionamiento mediante proxy de Nginx, la capa de aplicaciones de backend de Django y la capa de la base de datos de PostgreSQL.

      Crear un sistema distribuido suele implicar tener que tomar varias decisiones de diseño, y encontrará varias arquitecturas disponibles para satisfacer su caso de uso. La arquitectura que se describe en este tutorial se presenta como un plan flexible para diseñar aplicaciones escalables con Django y Docker.

      Probablemente desee controlar el comportamiento de sus contenedores cuando detecten errores o ejecutar contenedores de forma automática al iniciar su sistema. Para hacerlo, puede usar un administrador de procesos como Systemd o implementar directivas de reinicio. Para obtener más información al respecto, consulte Iniciar contenedores de forma automática en la documentación de Docker.

      Al trabajar a gran escala con varios hosts ejecutando la misma imagen de Docker, puede resultar más eficaz automatizar los pasos utilizando una herramienta de administración de configuración como Ansible o Chef. Para obtener más información sobre la administración de configuración, consulte Introducción a la administración de configuración y Configuración de la automatización con Ansible: Un kit del taller de DigitalOcean.

      En lugar de compilar la misma imagen en cada host, también puede simplificar la implementación utilizando un registro de imágenes como Docker Hub, que compila, almacena y distribuye imágenes de Docker en varios servidores. Además de un registro de imágenes, una canalización de integración e implementación continua puede ayudarlo a compilar, probar e implementar imágenes en sus servidores de aplicaciones. Para obtener más información sobre CI/CD, consulte Introducción a las prácticas recomendadas de CI/CD.



      Source link

      Cómo instalar una pila ERPNext en Ubuntu 20.04


      El autor seleccionó a Software in the Public Interest para recibir una donación como parte del programa Write for DOnations.

      Introducción

      ERPNext es un conjunto de programas de Planeación de recursos empresariales (ERP) que aprovecha la potencia y la flexibilidad de las tecnologías de código abierto. Se destaca en la gestión de los principales procesos empresariales, como los de finanzas, ventas, recursos humanos, fabricación, compras, servicios, necesidades de asistencia y más. Estos son algunos de los beneficios de implementar un sistema como ERPNext:

      • Mejor productividad mediante la automatización de procesos comerciales repetitivos
      • Mejora de la eficacia de TI al permitir que todos los departamentos de la empresa compartan una misma base de datos
      • Mejora la toma de decisiones al proporcionar una visión integral de cómo se relacionan las unidades de negocio entre sí

      ERPNext está basado en Frappe, un marco de aplicaciones web de pila completa escrito en Python que aprovecha al máximo el entorno de ejecución de Node/JavaScript y utiliza MariaDB como su backend de base de datos. Una de las diversas ventajas de las aplicaciones basadas en Frappe, como ERPNext, es la utilidad de línea de comandos bench. La CLI de banco les ahorra tiempo a los administradores mediante la automatización de tareas como la instalación, la actualización, la configuración y la administración de varios sitios de Frappe/ERPNext.

      En este tutorial, instalará y configurará una pila ERPNext en un servidor con Ubuntu 20.04. Esto le permitirá configurar su pila para diversos entornos de desarrollo o producción de acuerdo con sus necesidades y lo preparará para crear una arquitectura más compleja y tolerante a errores.

      Requisitos previos

      Nota: Al seleccionar las especificaciones de su servidor, tenga en cuenta que los sistemas ERP realizan un uso intensivo de recursos. Esta guía indica que se requiere un servidor con 4 GB de RAM, lo suficiente para casos de uso básico, pero los requisitos de hardware específicos pueden variar dependiendo de la cantidad de usuarios y el tamaño de su empresa.

      Paso 1: Configurar el firewall

      Si bien la configuración del firewall para entornos de desarrollo es opcional, es una práctica de seguridad obligatoria para los entornos de producción.

      Deberá abrir los siguientes puertos en su servidor ERPNext:

      • 80/tcp y 443/tcp para HTTP y HTTPS respectivamente
      • 3306/tcp para la conexión con MariaDB (se recomienda solo si necesita acceso remoto a la base de datos)
      • 143/tcp y 25/tcp para IMAP y STMP respectivamente
      • 22/tcp para SSH (si todavía no ha habilitado OpenSSH en los ajustes de UFW)
      • 8000/tcp para probar su plataforma antes de implementarla en producción

      Para abrir varios puertos de vez, puede usar el siguiente comando:

      • sudo ufw allow 22,25,143,80,443,3306,8000/tcp

      De forma alternativa, puede permitir conexiones de direcciones IP específicas en puertos determinados utilizando este comando:

      • sudo ufw allow from server_IP to any port port_number

      Después de abrir todos los puertos necesarios, habilite el firewall:

      Ahora, confirme el estado de su firewall:

      UFW mostrará una lista de sus reglas habilitadas. Asegúrese de que los puertos necesarios de ERPNext estén abiertos:

      Output

      Status: active To Action From -- ------ ---- 22,25,80,143,443,3306,8000/tcp ALLOW Anywhere 22,25,80,143,443,3306,8000/tcp (v6) ALLOW Anywhere (v6)

      Para obtener más información sobre la configuración de UFW, consulte nuestra guía sobre cómo configurar un firewall con UFW en Ubuntu 20.04.

      La configuración de un firewall adecuado es el primero de dos pasos preliminares. Ahora, configurará la asignación de teclado y la codificación de caracteres en su servidor.

      Paso 2: Establecer las configuraciones regionales

      Es sumamente recomendable configurar la asignación de teclado para la consola, así como el idioma y la codificación de caracteres de su host. Esto es necesario para evitar posibles problemas durante el proceso de instalación de ERPNext 12. Tenga en cuenta que estos ajustes afectan únicamente la configuración regional del sistema y no están relacionados con el idioma de la IU de su plataforma de ERPNext.

      Primero, actualice su servidor:

      Ahora, configure la asignación de teclado, el idioma y la codificación de caracteres:

      • sudo localectl set-keymap us && sudo localectl set-locale LANG=en_US.utf8

      Ubuntu 20.04 y otras distribuciones Linux usan la utilidad localectl para controlar y modificar los ajustes de configuración regional y distribución del teclado de todo el sistema antes de que el usuario inicie sesión, que es exactamente lo que requiere ERPNext 12.

      También deberá agregar las siguientes líneas a su archivo /etc/environment. Utilice nano o su editor de texto preferido para abrir el archivo:

      • sudo nano /etc/environment

      Ahora, agregue el siguiente contenido:

      /etc/environment

      LC_ALL=en_US.UTF-8
      LC_CTYPE=en_US.UTF-8
      LANG=en_US.UTF-8
      

      Guarde y cierre el archivo.

      Reinicie su servidor para aplicar todos los cambios:

      Espere unos minutos hasta que el servidor se reinicie y, luego, utilice ssh para volver a ingresar su instancia. Ya está listo para instalar su base de datos.

      Paso 3: Instalar MariaDB

      Ahora, añadirá MariaDB a su pila de servidores. ERPNext 12 requiere MariaDB 10.2, o una versión posterior, para funcionar correctamente. Como Ubuntu 20.04 incluye MariaDB 10.3 en sus repositorios oficiales, puede instalar esta versión usando el comando apt:

      • sudo apt install mariadb-server

      De forma alternativa, si prefiere instalar una versión de MariaDB más reciente, puede seguir el paso 3 de nuestra guía sobre cómo instalar una pila ERPNext en Ubuntu 18.04. Este paso lo guiará a través del asistente del repositorio en línea de MariaDB, lo que lo ayudará a instalar la versión más reciente: MariaDB 10.5.

      Después de instalar mariadb-server, instale los siguientes paquetes:

      • sudo apt install python3-mysqldb libmysqlclient-dev

      ERPNext 12 es una aplicación de Python y, por lo tanto, requiere la biblioteca python3-mysqldb para la administración de la base de datos. Se requiere libmysqlclient-dev para acceder a ciertas características de desarrollo de MariaDB.

      A continuación, añada una capa de seguridad adicional al servidor de MariaDB ejecutando la secuencia de comandos mysql_secure_installation:

      • sudo mysql_secure_installation

      La secuencia de comandos mysql_secure_installation le realizará varias preguntas:

      • Primero, le solicitará la contraseña root, pero como todavía no hay ninguna contraseña configurada, presione ENTER.
      • A continuación, cuando se le pregunte si desea cambiar la contraseña root de MariaDB, responda N. Se recomienda usar la contraseña predeterminada junto con la autenticación de Unix en los sistemas basados en Ubuntu, dado que la cuenta root está estrechamente relacionada con tareas automatizadas de mantenimiento del sistema.
      • Las preguntas restantes están relacionadas con la eliminación de usuarios anónimos de la base de datos, la restricción de inicio de sesión remoto de la cuenta root en el host local, la eliminación de la base de datos de prueba y la recarga de las tablas de privilegios. Puede responder Y a todas estas preguntas.

      Después de completar la secuencia de comandos mysql_secure_installation, MariaDB comenzará a ejecutarse utilizando su configuración predeterminada. En la instalación estándar de ERPNext, se utiliza el usuario root de MariaDB para todas las operaciones de la base de datos. Si bien este enfoque puede ser conveniente en las configuraciones de servidores individuales, no se considera una buena práctica de seguridad. Por tanto, en la siguiente sección, aprenderá a evitar este problema al crear un nuevo usuario con privilegios especiales.

      Crear un usuario superadministrador de MariaDB

      ERPNext espera utilizar el usuario root de MariaDB, para administrar las conexiones con la base de datos, pero esto no siempre es ideal. Para solucionar esta limitación y permitir administrar MariaDB a un usuario non-root, ahora, creará una base de datos con el nombre del usuario de forma manual. Luego, podrá asignarle privilegios especiales al usuario nuevo para que pueda realizar operaciones en la base de datos de ERPNext.

      Abra la línea de comandos de MariaDB:

      Ahora, cree una nueva base de datos nueva con el nombre del usuario al que desea asignar las conexiones de MariaDB. En este tutorial, se utilizará sammy, pero puede seleccionar un nombre diferente:

      Confirme que la base de datos se haya creado utilizando esta instrucción SQL:

      Verá un resultado similar a este:

      Output

      +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sammy | +--------------------+

      Ahora, cree el usuario de MariaDB, sammy, con privilegios similares al del usuario root y asígnele la contraseña segura que desee. Conserve la contraseña en un lugar seguro; la necesitará más adelante:

      • GRANT ALL PRIVILEGES ON *.* TO 'sammy'@'%' IDENTIFIED BY 'mariadb_password' WITH GRANT OPTION;

      Ahora, confirme tanto la creación del usuario como los privilegios del usuario nuevo:

      • SELECT host, user, Super_priv FROM mysql.user;

      Verá un resultado similar a este:

      Output

      +-----------+-------+------------+ | Host | User | Super_priv | +-----------+-------+------------+ | localhost | root | Y | | localhost | mysql | Y | | % | sammy| Y | +-----------+-------+------------+ 3 rows in set (0.001 sec)

      A continuación, ejecute la operación flush privileges para aplicar todos los cambios:

      Cuando termine, salga de la sesión:

      Ahora que ha creado un usuario de la base de datos, solo deberá ajustar MariaDB para garantizar el funcionamiento correcto de ERPNext 12. Afortunadamente, el equipo de ERPNext proporciona una excelente plantilla de configuración que utilizará como punto de partida para su implementación. En la siguiente sección, aprenderá a configurar correctamente la base de datos de MariaDB utilizando esa plantilla.

      Paso 4: Configurar MariaDB para ERPNext

      Ahora que instaló y aseguró MariaDB, es momento de configurarlo para las conexiones con ERPNext.

      Primero, detenga mariadb.service:

      • sudo systemctl stop mariadb

      Ahora, utilice nano o el editor de texto que prefiera para crear un archivo de configuración de MariaDB, denominado mariadb.cnf:

      • sudo nano /etc/mysql/mariadb.conf.d/mariadb.cnf

      A continuación, añada la plantilla de configuración oficial de ERPNext:

      /etc/mysql/mariadb.conf.d/mariadb.cnf

      [mysqld]
      
      # GENERAL #
      user                           = mysql
      default-storage-engine         = InnoDB
      socket                         = /var/lib/mysql/mysql.sock
      pid-file                       = /var/lib/mysql/mysql.pid
      
      # MyISAM #
      key-buffer-size                = 32M
      myisam-recover                 = FORCE,BACKUP
      
      # SAFETY #
      max-allowed-packet             = 256M
      max-connect-errors             = 1000000
      innodb                         = FORCE
      
      # DATA STORAGE #
      datadir                        = /var/lib/mysql/
      
      # BINARY LOGGING #
      log-bin                        = /var/lib/mysql/mysql-bin
      expire-logs-days               = 14
      sync-binlog                    = 1
      
      # REPLICATION #
      server-id                      = 1
      
      # CACHES AND LIMITS #
      tmp-table-size                 = 32M
      max-heap-table-size            = 32M
      query-cache-type               = 0
      query-cache-size               = 0
      max-connections                = 500
      thread-cache-size              = 50
      open-files-limit               = 65535
      table-definition-cache         = 4096
      table-open-cache               = 10240
      
      # INNODB #
      innodb-flush-method            = O_DIRECT
      innodb-log-files-in-group      = 2
      innodb-log-file-size           = 512M
      innodb-flush-log-at-trx-commit = 1
      innodb-file-per-table          = 1
      innodb-buffer-pool-size        = 5462M
      innodb-file-format             = barracuda
      innodb-large-prefix            = 1
      collation-server               = utf8mb4_unicode_ci
      character-set-server           = utf8mb4
      character-set-client-handshake = FALSE
      max_allowed_packet             = 256M
      
      # LOGGING #
      log-error                      = /var/lib/mysql/mysql-error.log
      log-queries-not-using-indexes  = 0
      slow-query-log                 = 1
      slow-query-log-file            = /var/lib/mysql/mysql-slow.log
      
      # CONNECTIONS #
      
      pid-file        = /var/run/mysqld/mysqld.pid
      socket          = /var/run/mysqld/mysqld.sock
      bind-address    = 0.0.0.0
      
      [mysql]
      default-character-set = utf8mb4
      
      [mysqldump]
      max_allowed_packet=256M
      

      Guarde y cierre el archivo. Para obtener información más detallada sobre estas configuraciones, consulte este archivo de plantilla en el repositorio de Github de ERPNext. Es un punto de partida útil para explorar estas opciones.

      El archivo de configuración, /etc/mysql/mariadb.conf.d/mariadb.cnf, complementa y también anula algunos de los valores incluidos en la configuración predeterminada de MariaDB, ubicada en /etc/mysql/my.cnf. Este archivo le proporciona una plantilla específica que mejora en gran medida el desempeño de la base de datos de ERPNext. Sin embargo, tenga en cuenta que, si bien esta plantilla es un excelente punto de partida, puede mejorar aún más el desempeño de MariaDB al ajustar estos parámetros para adaptarlos a sus necesidades.

      Probar la conexión con MariaDB

      Como ERPNext utiliza la conexión con la base de datos prácticamente para todas sus operaciones internas, es conveniente probar la conexión antes de continuar.

      Inicie mariadb.service:

      • sudo systemctl start mariadb

      Para probar la conexión, puede usar el siguiente comando. Recuerde sustituir sammy y mariadb_password con sus credenciales:

      • mysql --user sammy --password mariadb_password --host=localhost --protocol=tcp --port=3306 test

      Verá un resultado que muestra el contenido de ayuda básico de MariaDB y varios parámetros. Esto significa que su conexión se estableció correctamente:

      Output

      mysql Ver 15.1 Distrib 10.4.13-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Usage: mysql [OPTIONS] [database] Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf ... --ssl-verify-server-cert Verify server's "Common Name" in its cert against hostname used when connecting. This option is disabled by default. -t, --table Output in table format. --tee=name Append everything into outfile. See interactive help (h) also. Does not work in batch mode. Disable with --disable-tee. This option is disabled by default. -u, --user=name User for login if not current user. -U, --safe-updates Only allow UPDATE and DELETE that uses keys. -U, --i-am-a-dummy Synonym for option --safe-updates, -U. -v, --verbose Write more. (-v -v -v gives the table output format). ... max-join-size 1000000 secure-auth FALSE show-warnings FALSE plugin-dir (No default value) default-auth (No default value) binary-mode FALSE connect-expired-password FALSE

      Si necesita modificar los ajustes de MariaDB o corregir errores, recuerde volver a cargar el servicio utilizando el siguiente comando:

      • sudo systemctl restart mariadb

      Cuando haya terminado, habilite MariaDB:

      • sudo systemctl enable mariadb

      Ahora que ha probado la conexión con la base de datos, puede proceder con la instalación de su aplicación ERPNext.

      Paso 5: Configurar ERPNext 12

      Ahora que el backend de su base de datos está listo, puede seguir configurando su aplicación web ERPNext. En esta sección, aprenderá a instalar y configurar todos los componentes que requiere ERPNext 12 e instalará la aplicación.

      Comience por preparar el servidor con todos los paquetes del sistema que requiere ERPNext 12. Instale las dependencias de todo el sistema utilizando el siguiente comando:

      • sudo DEBIAN_FRONTEND=noninteractive apt install -y curl build-essential python3-testresources python3-setuptools python3-dev libffi-dev python3-pip libcurl4 dnsmasq fontconfig git htop libcrypto++-dev libfreetype6-dev liblcms2-dev libwebp-dev libxext6 libxrender1 libxslt1-dev libxslt1.1 libffi-dev ntpdate postfix python3-dev python-tk screen vim xfonts-75dpi xfonts-base zlib1g-dev apt-transport-https libsasl2-dev libldap2-dev libcups2-dev pv libjpeg8-dev libtiff5-dev tcl8.6-dev tk8.6-dev libdate-manip-perl logwatch

      La variable DEBIAN_FRONTEND=noninteractive se ha trasladado al comando de instalación para evitar los mensajes de Postfix. Para obtener información detallada sobre la configuración de Postfix, consulte nuestra guía Cómo instalar y configurar Postfix en Ubuntu 20.04.

      A continuación, actualice pip3, el administrador de paquetes estándar de Python, e instale las versiones más recientes de tres módulos de Python adicionales:

      • sudo -H python3 -m pip install --upgrade setuptools cryptography psutil

      setuptools facilita la instalación y la actualización de los paquetes de Python, cryptography añade capacidades de cifrado a su pila y psutil ayuda a supervisar el sistema. Ahora que ha instalado todas las dependencias globales necesarias, instalará todos los servicios y las bibliotecas que requiere ERPNext 12.

      Configurar Node.js y Yarn

      ERPNext 12 funciona con la versión 8, o una más reciente, del entorno de servidor de Node.js. De hecho, a la fecha de redacción de este artículo, la secuencia de comandos oficial de ERPNext easy_install utiliza Node 8. Sin embargo, desde una perspectiva de seguridad, es conveniente instalar una versión más reciente, dado que Node 8 llegó al final de su vida útil (EOL) en 2020 y, por lo tanto, no se lanzarán más parches de seguridad. A la fecha de redacción de este artículo, Ubuntu 20.04 contiene la versión 10.19 de Node.js. Si bien esta versión se sigue manteniendo, por motivos similares (su vida útil finaliza en menos de un año) es sumamente recomendable evitar usarla. En esta guía, se instalará la versión 12 LTS de Node.js junto con los administradores de paquetes correspondientes npm y yarn. Tenga en cuenta que el marco de trabajo de Frappe utiliza yarn para la instalación de dependencias. Si decide utilizar un método de instalación alternativo, asegúrese de que la versión 1.12+ de yarn quede instalada en su sistema.

      Añada el repositorio de NodeSource a su sistema:

      • curl -sL https://deb.nodesource.com/setup_12.x -o nodesource_setup.sh

      Ahora, puede revisar el contenido de la secuencia de comandos descargada:

      • sudo nano nodesurce_setup.sh

      Cuando esté satisfecho con el contenido de la secuencia de comandos, proceda a ejecutarla:

      • sudo bash nodesource_setup.sh

      Esta secuencia de comandos actualizará automáticamente la lista apt. Ahora, puede instalar nodejs en su servidor:

      A continuación, instale yarn de forma global utilizando el administrador de paquetes npm:

      Ahora que tiene Node instalado, puede proceder con la configuración de wkhtmltopdf para su plataforma.

      ERPNext utiliza la herramienta de código abierto wkhtmltopdf para convertir contenido de HTML a PDF utilizando el motor de representación Qt WebKit. Esta característica se utiliza principalmente para imprimir facturas, cotizaciones y otros informes. ERPNext 12 requiere una versión específica de wkhtmltopdf: 0.12.5 con Qt corregido.

      Para instalar wkhtmltopdf, comience por cambiar a un directorio adecuado para descargar el paquete, en este caso /tmp:

      Descargue la versión adecuada de wkhtmltopdf y el paquete correspondiente para Ubuntu 20.04 de la página del proyecto:

      • wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox_0.12.5-1.bionic_amd64.deb

      Ahora, instale el paquete utilizando la herramienta dpkg:

      • sudo dpkg -i wkhtmltox_0.12.5-1.bionic_amd64.deb

      A continuación, copie todos los ejecutables pertinentes a su directorio /usr/bin/:

      • sudo cp /usr/local/bin/wkhtmlto* /usr/bin/

      Cuando los archivos estén en su lugar, cambie sus permisos para que se puedan ejecutar:

      • sudo chmod a+x /usr/bin/wk*

      Ahora que wkhtmltopdf está instalado correctamente, añada Redis a la pila de su base de datos.

      Instalar Redis

      ERPNext 12 utiliza Redis para mejorar el desempeño de MariaDB. Específicamente, Redis ayuda con el almacenamiento en caché.

      Primero, instale Redis desde el repositorio oficial de Ubuntu 20.04:

      • sudo apt install redis-server

      A continuación, habilite Redis en el inicio:

      • sudo systemctl enable redis-server

      Ahora que ha añadido Redis a su pila, vamos a tomarnos un momento para resumir lo que ha logrado hasta ahora. Hasta este punto, ha instalado todos los componentes principales que requiere ERPNext 12, que son los siguientes:

      • Un backend de base de datos de MariaDB
      • El entorno de servidor Node.js de JavaScript
      • El administrador de paquetes Yarn
      • Una caché de base de datos Redis
      • El generador de documentos PDF wkhtmltopdf

      Ya sea que esté instalando el sistema ERP para un entorno de desarrollo o de producción, está listo para continuar con el siguiente paso: instalar el marco de pila completa de Frappe y la aplicación web ERPNext 12.

      Paso 6: Instalar la CLI Frappe Bench

      Ahora que ha instalado todos los requisitos de pila de ERPNext, puede aprovechar la flexibilidad de la utilidad de línea de comandos bench de Frappe. La CLI bench se diseñó con el objetivo de ayudar a los usuarios en el proceso de instalación, configuración y administración de aplicaciones basadas en el marco de trabajo Frappe, como ERPNext. En las siguientes secciones, instalará la CLI bench y, luego, la utilizará para completar el proceso de configuración de ERPNext 12.

      Asegúrese de que el usuario de Frappe (en este caso, sammy) tenga los derechos apropiados en su directorio home:

      • sudo chown sammy -R /home/sammy

      Ahora, clone el repositorio frappe/bench y colóquelo su directorio de inicio. Recuerde sustituir sammy con su nombre de usuario del sistema:

      • git clone https://github.com/frappe/bench /home/sammy/.bench --depth 1 --branch master

      Instale la CLI bench:

      • sudo pip3 install -e /home/sammy/.bench

      En esta guía, se asume que está instalando ERPNext 12 para escenarios de prueba o producción y, por lo tanto, está utilizando la rama master. Pero si tiene la intención de desarrollar aplicaciones o módulos de ERPNext personalizados, la rama develop podría ser una mejor opción. En cualquier caso, está listo para instalar el marco de trabajo Frappe. Este será su último paso antes de instalar ERPNext.

      Configurar el entorno del marco de trabajo Frappe

      En esta sección, creará un entorno de Frappe utilizando la CLI bench.

      Durante la instalación de Frappe, puede exceder el límite del monitor de archivos de Ubuntu, que está establecido en 8192 por defecto. Para evitar este problema, establezca un límite superior utilizando el siguiente comando:

      • echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

      El comando tee adjuntará el contenido de su comando echo al archivo invocado y también imprimirá el resultado en su consola.

      A continuación, inicie Frappe Framework 12. Sustituya a Sammy por su nombre de usuario del sistema:

      • bench init /home/sammy/frappe-bench --frappe-path https://github.com/frappe/frappe --frappe-branch version-12 --python python3

      Durante la ejecución, puede ver un error sobre su ruta y varias advertencias. Deje que el proceso continúe hasta el final. Cuando haya terminado, verá un resultado similar al siguiente, lo que indica que su entorno se creó correctamente:

      Output

      ... Done in 82.23s. INFO:bench.utils:setting up backups no crontab for sammy SUCCESS: Bench /home/sammy/frappe-bench initialized

      Nota: el proceso bench init puede detenerse si se encuentra un error spawn ENOMEM. Este error se provoca cuando su sistema se queda sin memoria. Para continuar, debe solucionarlo instalando más memoria física o asignando espacio SWAP.

      Analicemos con mayor detalle el comando utilizado para crear el entorno:

      • /home/sammy/frappe-bench es la ruta donde se instalarán Frappe Framework, los sitios web y las aplicaciones relacionadas. En este ejemplo, se creará un nuevo directorio, denominado frappe-bench, para alojar todos los archivos necesarios.
      • -frappe-path apunta al repositorio de Frappe, que, en este caso, es el repositorio oficial de Github.
      • --frappe-branch es la versión de Frappe que se instalará. Como desea instalar ERPNext 12, la versión seleccionada es Frappe 12.
      • --python es la versión de Python que se utilizará. ERPNext 12 requiere Python 3.6 o superior. Sin embargo, las versiones anteriores siguen utilizando Python 2.7.

      Para obtener más información sobre los comandos de la CLI bench, consulte la Hoja de trucos de comandos de Bench.

      La flexibilidad que ofrece el marco de trabajo de Frappe va mucho más allá del uso de entornos aislados. También puede crear distintos sitios web e instalar aplicaciones en ellos.

      Paso 7: Instalar la aplicación web ERPNext 12

      En esta sección, configurará un sitio basado en Frappe e instalará la aplicación ERPNext 12 en él.

      Posiciónese en el directorio donde se inició Frappe.

      • cd /home/sammy/frappe-bench

      Antes de continuar, deberá instalar versiones específicas de las bibliotecas de Python numpy y pandas en el entorno virtual de Frappe. Instalar estos paquetes utilizando el siguiente comando:

      • ./env/bin/pip install numpy==1.18.5 && ./env/bin/pip install pandas==0.24.2

      En este punto, es posible que la instalación se detenga por unos 10 a 20 minutos y vea este mensaje:

      Output

      ... Building wheel for pandas (setup.py) ... -

      Esto tiene que ver con un error relacionado con pandas y Ubuntu 20.04, que, a la fecha de redacción de este artículo, es bastante nuevo. De todos modos, los paquetes se crearán y, una vez que se completen, verá un resultado similar a este:

      Output

      ... Successfully built pandas Installing collected packages: pandas Successfully installed pandas-0.24.2

      Ahora, puede continuar con la instalación. Descargue ERPNext 12 desde su repositorio utilizando la CLI bench:

      • bench get-app erpnext https://github.com/frappe/erpnext --branch version-12

      A continuación, cree el sitio nuevo, sustituyendo your_domain por el dominio que haya asociado con la IP de este servidor:

      • bench new-site your_domain --admin-password 'erpnext_admin_password' --mariadb-root-username sammy --mariadb-root-password 'mariadb_password'

      Tomémonos un momento para revisar las opciones utilizadas en el comando anterior:

      • bench new-site crea un sitio nuevo basado en Frappe Framework.
      • your_domain es el nombre del sitio nuevo. Asegúrese de que el DNS de su dominio tenga un registro A apuntado a la IP de su servidor.
      • <^>erpnext_admin_password<^>** es la contraseña deseada para el usuario **administrador de ERPNext. Conserve esta contraseña en un lugar seguro; la necesitará en breve.
      • mariadb_password es la contraseña que creó al principio de la guía para el usuario de MariaDB sammy.

      A continuación, instale la aplicación ERPNext en el sitio:

      • bench --site your_domain install-app erpnext

      Cuando la instalación se haya completado, tendrá una aplicación ERPNext 12 en funcionamiento. Ahora, vamos a probarla utilizando un comando bench:

      El comando anterior iniciará una consola de monitoreo en tiempo real que le mostrará varios mensajes relacionados con el servidor web y otros servicios. Abra un navegador web y diríjase a localhost:8000 (para instalaciones locales) o your_domain:8000 (si está utilizando un servidor remoto). Verá la pantalla de inicio de sesión de ERPNext (procederemos con el inicio de sesión y la configuración en un paso posterior, una vez que el sitio esté listo para producción).

      Después de consultar su implementación de prueba, regrese a su terminal y presione CTRL+C. De esta manera, detendrá ERPNext y saldrá de la consola de monitoreo.

      Si su objetivo principal es crear módulos o modificar ERPNext 12, puede detenerse en este punto. No se requieren más componentes para fines de desarrollo. Sin embargo, si necesita un sistema listo para producción que no requiera inicialización manual, deberá instalar y configurar algunos componentes adicionales. Este será su siguiente paso.

      Paso 8: Configurar ERPNext 12 para producción

      Si bien su aplicación ERPNext 12 está lista, el sistema en su conjunto todavía no está preparado para producción. Para garantizar la fiabilidad y la seguridad de ERPNext, deberá habilitar algunos servicios adicionales:

      • Fail2ban proporciona una capa de protección adicional contra los intentos de fuerza bruta de usuarios y bots maliciosos.
      • Nginx funciona principalmente como proxy web, redireccionando todo el tráfico del puerto 8000 al puerto 80 (HTTP) o 443 (HTTPS).
      • Supervisor garantiza que los procesos clave de ERPNext se ejecuten constantemente y los reinicia según sea necesario.

      Hasta este punto, ha instalado y configurado ERPNext 12 de forma manual, lo que le ha permitido personalizar el proceso para adaptarlo cualquier caso de uso en particular. Sin embargo, durante el resto de la configuración de producción, puede aprovechar la conveniencia de la CLI bench y dejar que automatice la instalación y la configuración de estos servicios restantes.

      Asegúrese de estar posicionado en el directorio de trabajo de Frappe:

      • cd /home/sammy/frappe-bench

      Ahora, utilice el siguiente comando para finalizar la configuración de ERPNext 12 para producción:

      • sudo bench setup production sammy --yes

      El comando anterior instala y configura Nginx, Supervisor y Fail2Ban y establece a sammy como propietario del entorno de producción.

      Estos son los archivos de configuración que crea el comando bench:

      • Dos archivos de configuración de Nginx ubicados en /etc/nginx/nginx.conf y /etc/nginx/conf.d/frappe-bench.conf
      • Una proxy jail de Fail2Ban ubicada en /etc/fail2ban/jail.d/nginx-proxy.conf y un filtro situado en /etc/fail2ban/filter.d/nginx-proxy.conf

      Estas configuraciones predeterminadas bastarán para este tutorial, pero siéntase en libertad de explorar y ajustar estos archivos para adaptarlos a sus requisitos. Puede detener todos los servicios con el siguiente comando:

      • sudo supervisorctl stop all

      Y, luego, cuando esté listo, puede reiniciar sus servicios:

      • sudo supervisorctl start all

      Ahora, está listo para probar su instalación.

      Probar la instalación de ERPNext 12

      Primero, verifique que se estén ejecutando los servicios de producción esenciales. Utilice el siguiente comando systemctl y, luego, canalícelo a grep:

      • systemctl list-unit-files | grep 'fail2ban|nginx|supervisor'

      Verá un resultado similar a este:

      Output

      fail2ban.service enabled nginx.service enabled supervisor.service enabled

      Una vez que haya confirmado que todo funciona adecuadamente, puede probar ERPNext 12 en su servidor activo. Abra el navegador que prefiera y navegue a your_domain o a la ubicación en la que esté alojada su aplicación ERPNext 12.

      Después de unos segundos, debería ver la pantalla de inicio de sesión de ERPNext 12. Utilice el nombre de usuario (correo electrónico) Administrator y la contraseña erpnext_admin_password que creó anteriormente.

      Pantalla de inicio de sesión de ERPNext

      En la siguiente pantalla, verá un menú desplegable en el que puede seleccionar el idioma de la IU para la aplicación:

      Selección de idioma

      Tras la selección de idiomas, ERPNext le solicitará que indique su país, zona horaria y moneda:

      Seleccione su región

      Una vez que haya completado la información de su región, podrá crear su primer usuario de ERPNext. La información que proporcione se utilizará en las credenciales de inicio de sesión del usuario.

      Primer usuario de ERPNext

      En la siguiente pantalla, se le preguntará sobre lo que ERPNext denomina Dominios. Si no está seguro de cuál es su dominio, seleccione Distribution y haga clic en el botón Next.

      Seleccione sus dominios

      A continuación, deberá proporcionar el nombre de la empresa y una abreviatura.

      Nombre de la empresa

      En la última pantalla, ERPNext le pedirá que indique la actividad de su empresa, el nombre de su banco, el tipo de plan de cuentas y el período del año fiscal. Podrá ingresar a bancos adicionales más adelante. Por ahora, complete todos los campos que desee y, luego, haga clic en el botón Complete Setup.

      Información financiera

      A continuación, verá una barra de progreso.

      Configurar ERPNext

      Una vez que se haya completado el proceso de configuración, verá el panel de control principal de ERPNext 12.

      Panel de control de ERPNext 12

      Ha instalado y configurado por completo una aplicación ERPNext 12.

      Conclusión

      Ahora que ha instalado correctamente su aplicación ERPNext 12, es posible que desee comenzar a implementar el sistema para las necesidades de su empresa. Una buena manera de comenzar a hacerlo es hacer clic en el botón Getting Started del panel de control de ERPNext. ERPNext lo ayudará a configurar la plataforma para todas sus necesidades empresariales y de comercio electrónico.

      Primeros pasos

      Es posible que también desee aumentar la velocidad de ERPNext. Si es así, puede consultar información sobre los ajustes de desempeño de ERPNext, que lo orientará sobre las mejores prácticas y cómo depurar problemas relacionados con el desempeño.



      Source link

      Cómo instalar WordPress en Ubuntu 20.04 con una pila LAMP


      Introducción

      WordPress es una tecnología de código abierto extremadamente popular para crear sitios web en el Internet actual. Usado por el 63 % de los sitios web que utilizan un sistema de gestión de contenidos (GMS), los sitios de WordPress representan el 36 % de todos los sitios web que están en línea actualmente.

      Existen muchos enfoques diferentes para obtener acceso a WordPress y algunos procesos de configuración son más complejos que otros. Este tutorial está destinado para aquellos que desean instalar y administrar una instancia WordPress en un servidor en la nube no gestionado a través de la línea de comandos. Aunque este enfoque requiere más pasos que una instalación WordPress ya hecha, ofrece a los administradores mayor control sobre su entorno de WordPress.

      Si lo que desea es acceder a una instalación de WordPress ya lista, DigitalOcean Markeplace ofrece una aplicación con solo un clic para comenzar con WordPress a través de la instalación cuando prepara su servidor.

      Dependiendo de sus necesidades y objetivos, puede encontrar otras opciones que son más adecuadas. Como software de código abierto, WordPress puede descargarse e instalarse de forma gratuita, pero para que esté disponible en la web, probablemente necesite una infraestructura en la nube y un nombre de dominio. Siga esta guía si está interesado en trabajar a través de la instalación del lado del servidor y configurar un sitio WordPress.

      Este tutorial usará una pila LAMP (Linux, Apache, MySQL y PHP), que es una opción para una arquitectura de servidor compatible con WordPress proporcionando el sistema operativo Linux, el servidor web Apache, la base de datos MySQL y el lenguaje de programación PHP. Instalaremos y configuraremos WordPress a través de LAMP en un servidor Linux Ubuntu 20.04.

      Requisitos previos

      Para completar este tutorial, necesitará acceso a un servidor Ubuntu 20.04 y necesitará completar estos pasos antes de comenzar esta guía:

      • Configure su servidor siguiendo nuestra Guía de configuración inicial del servidor Ubuntu 20.04, y asegúrese de tener un usuario sudo no root.
      • Instale una pila LAMP siguiendo nuestra Guía sobre LAMP para instalar y configurar este software.
      • Proteja su sitio: WordPress asume la entrada del usuario y almacena datos del usuario, de forma que es importante tener una capa de seguridad. TLS/SSL es la tecnología que le permite cifrar el tráfico de su sitio para que su conexión y la de sus usuarios sea segura. Aquí tiene dos opciones disponibles para cumplir con este requisito:
        • Si tiene nombre de dominio, puede proteger su sitio con Let´s Encrypt, que proporciona certificados de confianza gratuitos. Para la configuración, siga nuestra guía de Let’s Encrypt para Apache.
        • Si no cuenta con un dominio y solo utiliza esta configuración para pruebas o cuestiones personales, puede emplear en su lugar un certificado autofirmado. Le proporciona el mismo tipo de cifrado, pero sin la validación del dominio. Para la configuración, siga nuestra guía de SSL autofirmados para Apache.

      Cuando complete los pasos de configuración, inicie sesión en su servidor como usuario sudo y continúe.

      Paso 1: Creación de una base de datos de MySQL y un usuario para WordPress

      El primer paso que daremos es preparatorio. WordPress utiliza MySQL para administrar y almacenar el sitio y la información del usuario. Ya instalamos MySQL, pero debemos crear una base de datos y un usuario para que use WordPress.

      Para comenzar, inicie sesión en la cuenta root de MySQL (administrativa) emitiendo este comando (tenga en cuenta que este no es el usuario root de su servidor):

      Una vez instalado el software le solicitará la contraseña que configuró para la cuenta root de MySQL.

      Nota: Si no puede acceder a su base de datos MySQL a través de root, como usuario sudo puede actualizar la contraseña de su usuario root iniciando sesión en la base de datos de esta forma:

      Una vez que reciba la instrucción de MySQL, puede actualizar la contraseña del usuario root. Aquí, sustituya new_password por una contraseña segura de su elección.

      • ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'new_password';

      Ahora puede escribir EXIT; y puede volver a iniciar sesión en la base de datos a través de la contraseña con el siguiente comando:

      En la base de datos, puede crear una base de datos exclusiva para que WordPress la controle. Puede ponerle el nombre que quiera, pero usaremos el nombre wordpress en esta guía. Cree la base de datos para WordPress escribiendo lo siguiente:

      • CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

      Nota: Cada instrucción de MySQL debe terminar en punto y coma (;). Asegúrese de que esto no falte si experimenta problemas.

      A continuación, crearemos una cuenta de usuario separada de MySQL que usaremos exclusivamente para realizar operaciones en nuestra nueva base de datos. Crear bases de datos y cuentas específicas puede ayudarnos desde el punto de vista de administración y seguridad. Usaremos el nombre wordpressuser en esta guía, pero puede usar el nombre que sea más relevante para usted.

      Crearemos esta cuenta, configuraremos una contraseña y concederemos acceso a la base de datos que hemos creado. Podemos hacerlo escribiendo el siguiente comando. Recuerde elegir una contraseña segura aquí para su usuario de base de datos donde tenemos password:

      • CREATE USER 'wordpressuser'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

      A continuación, deje saber a la base de datos que nuestro wordpressuser debería tener acceso completo a la base de datos que configuramos:

      • GRANT ALL ON wordpress.* TO 'wordpressuser'@'%';

      Ahora tiene una base de datos y una cuenta de usuario, creadas específicamente para WordPress. Debemos eliminar los privilegios de modo que la instancia actual de MySQL sepa sobre los cambios recientes que hemos realizado:

      Cierre MySQL escribiendo lo siguiente:

      En el siguiente paso, crearemos la base para los complementos de WordPress descargando extensiones PHP para nuestro servidor.

      Paso 2: Instalación de extensiones de PHP adicionales

      Cuando configuramos nuestra pila LAMP, solo necesitamos un conjunto de extensiones muy reducido para que PHP se comunicara con MySQL. WordPress y muchos de sus complementos aprovechan las extensiones de PHP adicionales.

      Podemos descargar e instalar algunas de las extensiones de PHP más populares para usarlas con WordPress escribiendo lo siguiente:

      • sudo apt update
      • sudo apt install php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip

      Esto sentará las bases para instalar complementos adicionales en nuestro sitio WordPress.

      Nota: Cada complemento de WordPress tiene su propio conjunto de requisitos. Para algunos, posiblemente sea necesario instalar paquetes de PHP adicionales. Compruebe la documentación de sus complementos para ver sus requisitos de PHP. Si están disponibles, pueden instalarse con apt como ya se ha mostrado.

      Necesitaremos reiniciar Apache para cargar estas nuevas extensiones; realizaremos más configuraciones en Apache en la próxima sección, así que puede esperar hasta entonces o reiniciar ahora para completar el proceso de extensión de PHP.

      • sudo systemctl restart apache2

      Paso 3: Ajuste de la configuración de Apache para permitir reemplazos y reescrituras .htaccess

      A continuación, realizaremos algunos ajustes de menor importancia en nuestra configuración de Apache. Conforme a los tutoriales de los requisitos previos, debe tener un archivo de configuración para su sitio en el directorio /etc/apache2/sites-available/.

      En esta guía, utilizaremos /etc/apache2/sites-available/wordpress.conf, pero debe sustituir la ruta a su archivo de configuración cuando proceda. Además, emplearemos /var/www/wordpresscomo el directorio root de nuestra instalación de WordPress. Debería usar el root web especificada en su propia configuración. Si siguió nuestro tutorial LAMP, puede ser su nombre de dominio en vez de wordpress en ambas instancias.

      Nota: Es posible que utilice la configuración predeterminada 000-default.conf (con /var/www/html como su root web). Se puede usar si solo va a alojar un sitio web en este servidor. En caso negativo, resulta mejor dividir la configuración necesaria en chunks lógicos, un archivo por sitio.

      Con nuestras rutas identificadas, podemos pasar a trabajar con .htaccess de forma que Apache pueda manejar los cambios en la configuración directorio por directorio.

      Habilitar reemplazos .htaccess

      Actualmente, el uso de archivos .htaccess está desactivado. WordPress y muchos de sus complementos utilizan estos archivos de forma amplia para realizar ajustes de comportamiento del servidor web dentro del directorio.

      Abra el archivo de configuración de Apache para su sitio web con un editor de texto como nano.

      • sudo nano /etc/apache2/sites-available/wordpress.conf

      Para permitir archivos .htaccess, debemos configurar la directiva AllowOverride dentro de un bloque Directory orientado a nuestro root de documentos. Agregue el siguiente bloque de texto dentro del bloque VirtualHost en su archivo de configuración. Asegúrese de utilizar el directorio root web correcto:

      /etc/apache2/sites-available/wordpress.conf

      <Directory /var/www/wordpress/>
          AllowOverride All
      </Directory>
      

      Cuando termine, guarde y cierre el archivo. En nano, puede hacer esto pulsando CTRL y X juntos, luego Y, y luego ENTER.

      Habilitar el módulo de reescritura

      A continuación, podemos habilitar mod_rewrite para usar la característica de permalink de WordPress:

      Esto le permite tener permalinks a sus publicaciones más legibles por el ser humano, como en los siguientes dos ejemplos:

      http://example.com/2012/post-name/
      http://example.com/2012/12/30/post-name
      

      El comando a2enmod invoca una secuencia de comandos que habilita el módulo especificado en la configuración Apache.

      Habilitar los cambios

      Antes de implementar los cambios realizados, compruebe que no hay errores de sintaxis ejecutando la siguiente prueba.

      • sudo apache2ctl configtest

      Puede recibir un resultado como el siguiente:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      Si desea eliminar la línea superior, simplemente agregue una directiva ServerName a su archivo de configuración principal (global) de Apache en /etc/apache2/apache2.conf. ServerName puede ser el dominio o la dirección IP de su servidor. Este es solo un mensaje, sin embargo, y no afecta a la funcionalidad de su sitio. En tanto el resultado contenga Sintaxis OK, podrá continuar.

      Reinicie Apache para implementar los cambios: Asegúrese de reiniciar ahora, incluso si ha reiniciado anteriormente en este tutorial.

      • sudo systemctl restart apache2

      A continuación, descargaremos y configuraremos el propio WordPress.

      Paso 4: Descargar WordPress

      Ahora que el software de nuestro servidor está configurado, podemos descargar y configurar WordPress. Preferentemente por motivos de seguridad, siempre se recomienda obtener la versión más reciente de WordPress del sitio del producto.

      Cambie a un directorio que permita la escritura (recomendamos uno temporal como /tmp) y descargue la versión comprimida.

      • cd /tmp
      • curl -O https://wordpress.org/latest.tar.gz

      Extraiga el archivo comprimido para crear la estructura de directorios de WordPress:

      Moveremos estos archivos a nuestro root de documentos por ahora. Antes de hacerlo, podemos añadir un archivo ficticio .htaccess de modo que esté disponible para que WordPress lo use más adelante.

      Cree el archivo escribiendo lo siguiente:

      • touch /tmp/wordpress/.htaccess

      También copiaremos sobre el archivo de configuración de muestra al nombre de archivo que lee WordPress:

      • cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php

      También podemos crear el directorio de actualización, de modo que WordPress no tenga problemas de permisos al intentar hacerlo por su cuenta siguiendo una actualización a su software:

      • mkdir /tmp/wordpress/wp-content/upgrade

      Ahora podemos copiar todo el contenido del directorio en nuestro root de documentos. Usaremos un punto al final de nuestro directorio de origen para indicar que todo lo que está dentro del directorio debe copiarse, incluyendo archivos ocultos (como el archivo .htaccess que hemos creado):

      • sudo cp -a /tmp/wordpress/. /var/www/wordpress

      Asegúrese de sustituir el directorio /var/www/wordpress por el directorio que haya configurado en su servidor.

      Paso 5: Configurar el directorio de WordPress

      Antes de realizar la configuración basada en web de WordPress, debemos ajustar algunos elementos en nuestro directorio de WordPress.

      Realizar ajustes de propiedad y permisos

      Un paso importante que debemos lograr es configurar permisos de archivo razonables y la propiedad.

      Empezaremos por dar la propiedad de todos los archivos al usuario y al grupo www-data. Este es el usuario como el que se ejecuta el servidor web Apache, y este último deberá poder leer y escribir archivos de WordPress para presentar el sitio web y realizar actualizaciones automáticas.

      Actualice la propiedad con el comando chown que le permite modificar la propiedad del archivo. Asegúrese de apuntar al directorio relevante de su servidor.

      • sudo chown -R www-data:www-data /var/www/wordpress

      A continuación, ejecutaremos dos comandos find para establecer los permisos correctos de los directorios y archivos de WordPress:

      • sudo find /var/www/wordpress/ -type d -exec chmod 750 {} ;
      • sudo find /var/www/wordpress/ -type f -exec chmod 640 {} ;

      Estos permisos deberían hacer que pueda trabajar de forma efectiva con WordPress, pero tenga en cuenta que algunos complementos y procedimientos pueden requerir ajustes adicionales.

      Configurar el archivo de configuración de WordPress

      Ahora, debemos realizar algunos cambios en el archivo de configuración principal de WordPress.

      Cuando abramos el archivo, nuestra primera tarea será ajustar algunas claves secretas para proporcionar un nivel de seguridad a nuestra instalación. WordPress proporciona un generador seguro para estos valores, para que no tenga que crear valores correctos por su cuenta. Solo se utilizan internamente, de modo que no dañará la usabilidad el tener valores complejos y seguros aquí.

      Para obtener valores seguros del generador de claves secretas de WordPress, escriba lo siguiente:

      • curl -s https://api.wordpress.org/secret-key/1.1/salt/

      Obtendrá valores únicos que se parecen al resultado del bloque siguiente.

      Advertencia: Debe solicitar valores únicos cada vez. NO copie los siguientes valores.

      Output

      define('AUTH_KEY', '1jl/vqfs<XhdXoAPz9 DO NOT COPY THESE VALUES c_j{iwqD^<+c9.k<J@4H'); define('SECURE_AUTH_KEY', 'E2N-h2]Dcvp+aS/p7X DO NOT COPY THESE VALUES {Ka(f;rv?Pxf})CgLi-3'); define('LOGGED_IN_KEY', 'W(50,{W^,OPB%PB<JF DO NOT COPY THESE VALUES 2;y&,2m%3]R6DUth[;88'); define('NONCE_KEY', 'll,4UC)7ua+8<!4VM+ DO NOT COPY THESE VALUES #`DXF+[$atzM7 o^-C7g'); define('AUTH_SALT', 'koMrurzOA+|L_lG}kf DO NOT COPY THESE VALUES 07VC*Lj*lD&?3w!BT#-'); define('SECURE_AUTH_SALT', 'p32*p,]z%LZ+pAu:VY DO NOT COPY THESE VALUES C-?y+K0DK_+F|0h{!_xY'); define('LOGGED_IN_SALT', 'i^/G2W7!-1H2OQ+t$3 DO NOT COPY THESE VALUES t6**bRVFSD[Hi])-qS`|'); define('NONCE_SALT', 'Q6]U:K?j4L%Z]}h^q7 DO NOT COPY THESE VALUES 1% ^qUswWgn+6&xqHN&%');

      Son líneas de configuración que podemos pegar directamente en nuestro archivo de configuración para establecer claves seguras. Copie el resultado que obtuvo ahora.

      A continuación, abra el archivo de configuración de WordPress:

      • sudo nano /var/www/wordpress/wp-config.php

      Busque la sección que contiene los valores de ejemplo para esos ajustes.

      /var/www/wordpress/wp-config.php

      . . .
      
      define('AUTH_KEY',         'put your unique phrase here');
      define('SECURE_AUTH_KEY',  'put your unique phrase here');
      define('LOGGED_IN_KEY',    'put your unique phrase here');
      define('NONCE_KEY',        'put your unique phrase here');
      define('AUTH_SALT',        'put your unique phrase here');
      define('SECURE_AUTH_SALT', 'put your unique phrase here');
      define('LOGGED_IN_SALT',   'put your unique phrase here');
      define('NONCE_SALT',       'put your unique phrase here');
      
      . . .
      

      Elimine esas líneas y pegue los valores que copió de la línea de comandos:

      /var/www/wordpress/wp-config.php

      . . .
      
      define('AUTH_KEY',         'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_KEY',  'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_KEY',    'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_KEY',        'VALUES COPIED FROM THE COMMAND LINE');
      define('AUTH_SALT',        'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_SALT', 'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_SALT',   'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_SALT',       'VALUES COPIED FROM THE COMMAND LINE');
      
      . . .
      

      A continuación, vamos a modificar algunos de los ajustes de conexión de la base de datos al principio del archivo. Debe ajustar el nombre de la base de datos, su usuario y la contraseña asociada que configuramos dentro de MySQL.

      El otro cambio que debemos realizar es configurar el método que debe emplear WordPress para escribir el sistema de archivos. Debido a que hemos dado permiso al servidor web para escribir donde debe hacerlo, podemos fijar de forma explícita el método del sistema de archivos a “direct”. Si no lo configuramos con nuestros ajustes actuales, WordPress solicitaría las credenciales de FTP cuando realicemos algunas acciones.

      Este ajuste se puede agregar debajo de los ajustes de conexión de la base de datos o en cualquier otra parte del archivo:

      /var/www/wordpress/wp-config.php

      . . .
      
      // ** MySQL settings - You can get this info from your web host ** //
      /** The name of the database for WordPress */
      define( 'DB_NAME', 'wordpress' );
      
      /** MySQL database username */
      define( 'DB_USER', 'wordpressuser' );
      
      /** MySQL database password */
      define( 'DB_PASSWORD', 'password' );
      
      /** MySQL hostname */
      define( 'DB_HOST', 'localhost' );
      
      /** Database Charset to use in creating database tables. */
      define( 'DB_CHARSET', 'utf8' );
      
      /** The Database Collate type. Don't change this if in doubt. */
      define( 'DB_COLLATE', '' );
      
      
      . . .
      
      define('FS_METHOD', 'direct');
      

      Guarde y cierre el archivo cuando termine.

      Paso 6: Completar la instalación a través de la interfaz web

      Ahora que la configuración del servidor está completa, podemos finalizar la instalación a través de la interfaz web.

      En su navegador web, vaya al nombre de dominio o a la dirección IP pública de su servidor:

      https://server_domain_or_IP
      

      Seleccione el idioma que desee usar:

      Selección de idioma de WordPress

      A continuación, accederá a la página principal de configuración.

      Seleccione un nombre para su sitio WordPress y seleccione un nombre de usuario. Se recomienda elegir algo único y evitar nombres de usuario comunes como “admin” por motivos de seguridad. De forma automática, se generará una contraseña segura. Guárdela o seleccione una contraseña segura alternativa.

      Introduzca su dirección de correo electrónico y defina si quiere que los motores de búsqueda no indexen su sitio:

      Instalación de la configuración de WordPress

      Cuando haga clic para seguir, irá a una página que le pide que inicie sesión:

      Solicitud de inicio de sesión de WordPress

      Tras iniciar sesión, accederá al panel de administración de WordPress:

      Solicitud de inicio de sesión de WordPress

      En este momento, puede comenzar a diseñar su sitio web WordPress. Si es la primera vez que utiliza WordPress, explore la interfaz un poco para conocer su nuevo CMS.

      Conclusión

      Enhorabuena, WordPress está ahora instalado y listo para usarse.

      En este momento, quizá quiera hacer lo siguiente:

      • Seleccionar los ajustes de sus permalinks para las publicaciones de WordPress, que encontrará en Ajustes > Permalinks.
      • Seleccionar un nuevo tema en Apariencia > Temas.
      • Instalar nuevos complementos para aumentar la funcionalidad de su sitio bajo Complementos > Añadir nuevo.
      • Si va a colaborar con otros, puede también desear agregar usuarios adicionales en este momento bajo Usuarios > Añadir Nuevo.

      Puede encontrar recursos adicionales para formas alternativas de instalar WordPress, aprender a instalar WordPress en diferentes distribuciones de servidores, automatizar sus instalaciones de WordPress y escalar sus sitios de WordPress consultando nuestra etiqueta WordPress Community.



      Source link