Cómo instalar Drupal con Docker Compose

El autor seleccionó a la Fundación de las Naciones Unidas para recibir una donación como parte del programa Write for DOnations.

La versión original de WordPress de este tutorial fue escrita por Kathleen Juell.

Introducción

Drupal es un sistema de gestión de contenido (CMS) escrito en PHP y distribuido bajo la Licencia Pública General GNU de código abierto. Personas y organizaciones de todo el mundo utilizan Drupal para impulsar sitios gubernamentales, blogs personales, empresas y más. Lo que hace que Drupal sea único con respecto a otros marcos de CMS es su creciente comunidad y un conjunto de características que incluyen procesos seguros, rendimiento confiable, modularidad y flexibilidad para adaptarse.

Drupal requiere la instalación de la pila LAMP (Linux, Apache, MySQL y PHP) o LEMP (Linux, Nginx, MySQL y PHP), pero la instalación de componentes individuales es una tarea que lleva mucho tiempo. Podemos utilizar herramientas como Docker y Docker Compose para simplificar el proceso de instalación de Drupal. Este tutorial utilizará imágenes Docker para instalar componentes individuales dentro de los contenedores Docker. Al utilizar Docker Compose, podemos definir y gestionar varios contenedores para la base de datos, la aplicación y la red/comunicación entre ellos.

En este tutorial, instalaremos Drupal usando Docker Compose para que podamos aprovechar la contenedorización e implementar nuestro sitio web Drupal en servidores. Ejecutaremos contenedores para una base de datos MySQL, un servidor web Nginx y Drupal. También aseguraremos nuestra instalación obteniendo certificados TLS/SSL con Let's Encrypt para el dominio que queremos asociar con nuestro sitio. Finalmente, configuraremos un trabajo cron para renovar nuestros certificados para que nuestro dominio permanezca seguro.

Prerrequisitos

Para seguir este tutorial necesitaremos:

• Un servidor con Ubuntu 18.04, junto con un usuario no root con sudoprivilegios y un firewall activo. Para obtener instrucciones sobre cómo configurarlos, consulte esta guía de configuración inicial del servidor.
• Docker instalado en su servidor, siguiendo los pasos 1 y 2 de Cómo instalar y usar Docker en Ubuntu 18.04. Este tutorial ha sido probado en la versión 19.03.8.
• Docker Compose instalado en su servidor, siguiendo el paso 1 de Cómo instalar Docker Compose en Ubuntu 18.04. Este tutorial se ha probado en la versión 1.21.2.
• Un nombre de dominio registrado. Este tutorial lo utilizará your_domainen todo momento. Puede obtener uno gratis en Freenom o utilizar el registrador de dominios que prefiera.
• Los dos siguientes registros DNS están configurados para su servidor. Puede consultar esta introducción al DNS de DigitalOcean para obtener detalles sobre cómo agregarlos a una cuenta de DigitalOcean, si es la que está utilizando:
  • Un registro A que your_domainapunta a la dirección IP pública de su servidor.
  • Un registro A que apunta a la dirección IP pública de su servidor.www.your_domain

Paso 1: Definición de la configuración del servidor web

Antes de ejecutar cualquier contenedor, debemos definir la configuración de nuestro servidor web Nginx. Nuestro archivo de configuración incluirá algunos bloques de ubicación específicos de Drupal, junto con un bloque de ubicación para dirigir las solicitudes de verificación de Let's Encrypt al cliente Certbot para renovaciones de certificados automáticas.

Primero, creemos un directorio de proyecto para nuestra configuración de Drupal llamado drupal:

mkdir drupal 

Muévete al directorio recién creado:

cd drupal

Ahora podemos crear un directorio para nuestro archivo de configuración:

mkdir nginx-conf

Abra el archivo con nano o su editor de texto favorito:

nano nginx-conf/nginx.conf

En este archivo, agregaremos un bloque de servidor con directivas para el nombre de nuestro servidor y la raíz del documento, y bloques de ubicación para dirigir la solicitud de certificados, el procesamiento de PHP y las solicitudes de activos estáticos del cliente Certbot.

Agregue el siguiente código al archivo. Asegúrese de reemplazarlo your_domaincon su propio nombre de dominio:

~/drupal/nginx-conf/nginx.conf

server {    listen 80;    listen [::]:80;    server_name your_domain www.your_domain;    index index.php index.html index.htm;    root /var/www/html;    location ~ /.well-known/acme-challenge {        allow all;        root /var/www/html;    }    location / {        try_files $uri $uri/ /index.php$is_args$args;    }    rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;    location ~ .php$ {        try_files $uri =404;        fastcgi_split_path_info ^(.+.php)(/.+)$;        fastcgi_pass drupal:9000;        fastcgi_index index.php;        include fastcgi_params;        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;        fastcgi_param PATH_INFO $fastcgi_path_info;    }    location ~ /.ht {        deny all;    }    location = /favicon.ico {         log_not_found off; access_log off;     }    location = /robots.txt {         log_not_found off; access_log off; allow all;     }    location ~* .(css|gif|ico|jpeg|jpg|js|png)$ {        expires max;        log_not_found off;    }}

Nuestro bloque de servidor incluye la siguiente información:

Directivas:

• listen:Esto le indica a Nginx que escuche en el puerto 80, lo que nos permitirá usar el complemento webroot de Certbot para nuestras solicitudes de certificados. Tenga en cuenta que aún no incluimos el puerto 443; actualizaremos nuestra configuración para incluir SSL una vez que hayamos obtenido nuestros certificados correctamente.

• server_name: Esto define el nombre de nuestro servidor y el bloque de servidor que se debe utilizar para las solicitudes a nuestro servidor. Asegúrese de reemplazar your_domainesta línea con su propio nombre de dominio.

• index:La directiva index define los archivos que se usarán como índices al procesar solicitudes a nuestro servidor. Hemos modificado el orden de prioridad predeterminado aquí, moviéndolos index.phpal frente index.htmlpara que Nginx priorice los archivos llamados index.phpcuando sea posible.

• root:Nuestra directiva root nombra el directorio raíz para las solicitudes a nuestro servidor. Este directorio, /var/www/html, se crea como un punto de montaje en el momento de la compilación mediante instrucciones en nuestro Dockerfile de Drupal. Estas instrucciones de Dockerfile también garantizan que los archivos de la versión de Drupal se monten en este volumen.

• rewrite:Si la expresión regular especificada ( ^/core/authorize.php/core/authorize.php(.*)$) coincide con un URI de solicitud, el URI se cambia según lo especificado en la cadena de reemplazo ( /core/authorize.php$1).

Bloques de ubicación:

• location ~ /.well-known/acme-challenge:Este bloque de ubicación se encargará de las solicitudes al .well-knowndirectorio, donde Certbot colocará un archivo temporal para validar que el DNS de nuestro dominio se resuelva en nuestro servidor. Con esta configuración, podremos utilizar el complemento webroot de Certbot para obtener certificados para nuestro dominio.

• location /:En este bloque de ubicación, utilizaremos una try_filesdirectiva para comprobar si hay archivos que coincidan con las solicitudes de URI individuales. Sin embargo, en lugar de devolver un 404 Not Foundestado como predeterminado, pasaremos el control al index.phparchivo de Drupal con los argumentos de la solicitud.

• location ~ .php$:Este bloque de ubicación se encargará del procesamiento de PHP y enviará por proxy estas solicitudes a nuestro contenedor de Drupal . Debido a que nuestra imagen de Docker de Drupal se basará en la php:fpmimagen, también incluiremos opciones de configuración específicas del protocolo FastCGI en este bloque. Nginx requiere un procesador PHP independiente para las solicitudes PHP: en nuestro caso, estas solicitudes serán manejadas por el php-fpmprocesador que está incluido con la php:fpmimagen. Además, este bloque de ubicación incluye directivas, variables y opciones específicas de FastCGI que enviarán por proxy las solicitudes a la aplicación Drupal que se ejecuta en nuestro contenedor de Drupal, establecerán el índice preferido para la URI de solicitud analizada y analizarán las solicitudes de URI.

• location ~ /.ht:Este bloque se encargará .htaccessde los archivos, ya que Nginx no los entregará. La deny_alldirectiva garantiza que .htaccessnunca se entregarán archivos a los usuarios.

• location = /favicon.ico, location = /robots.txt:Estos bloques garantizan que las solicitudes de /favicon.icoy /robots.txtno se registrarán.

• location ~* .(css|gif|ico|jpeg|jpg|js|png)$:Este bloque desactiva el registro de solicitudes de activos estáticos y garantiza que estos activos sean altamente almacenables en caché, ya que su mantenimiento suele ser costoso.

Para obtener más información sobre el proxy FastCGI, consulte Descripción e implementación del proxy FastCGI en Nginx. Para obtener información sobre los bloques de ubicación y servidor, consulte Descripción de los algoritmos de selección de bloques de ubicación y servidor de Nginx.

Guarde y cierre el archivo cuando haya terminado de editarlo.

Una vez configurada Nginx, puede pasar a crear variables de entorno para pasarlas a sus contenedores de aplicaciones y bases de datos en tiempo de ejecución.

Paso 2: Definición de variables de entorno

Nuestra aplicación Drupal necesita una base de datos (MySQL, PostgresSQL, etc.) para guardar la información relacionada con el sitio. El contenedor Drupal necesitará acceso a ciertas variables de entorno en tiempo de ejecución para poder acceder al contenedor de la base de datos (MySQL). Estas variables contienen información confidencial, como las credenciales de la base de datos, por lo que no podemos exponerlas directamente en el archivo Docker Compose, el archivo principal que contiene información sobre cómo se ejecutarán nuestros contenedores.

Siempre se recomienda configurar los valores confidenciales en el .envarchivo y restringir su circulación. Esto evitará que estos valores se copien a los repositorios de nuestro proyecto y queden expuestos públicamente.

En el directorio principal del proyecto, ~/drupal, cree y abra un archivo llamado .env:

nano .env

Agregue las siguientes variables al .envarchivo, reemplazando las secciones resaltadas con las credenciales que desea utilizar:

~/drupal/.env

MYSQL_ROOT_PASSWORD=root_passwordMYSQL_DATABASE=drupalMYSQL_USER=drupal_database_userMYSQL_PASSWORD=drupal_database_password

Ahora hemos agregado la contraseña para la cuenta administrativa raíz de MySQL, así como nuestro nombre de usuario y contraseña preferidos para nuestra base de datos de aplicaciones.

Nuestro .envarchivo contiene información confidencial, por lo que siempre se recomienda incluirlo en los proyectos .gitignorey .dockerignorearchivos para que no se agregue a nuestros repositorios de Git ni a las imágenes de Docker.

Si planea trabajar con Git para el control de versiones, inicialice su directorio de trabajo actual como un repositorio con git init:

git init

Abrir .gitignorearchivo:

nano .gitignore

Añade lo siguiente:

~/drupal/.gitignore

.env

Guardar y salir del archivo.

De manera similar, abra el .dockerignorearchivo:

nano .dockerignore

Luego añade lo siguiente:

~/drupal/.dockerignore

.env.git

Guardar y salir del archivo.

Ahora que hemos tomado medidas para proteger nuestras credenciales como variables de entorno, pasemos al siguiente paso de definir nuestros servicios en un docker-compose.ymlarchivo.

Paso 3: Definición de servicios con Docker Compose

Docker Compose es una herramienta para definir y ejecutar aplicaciones Docker multicontenedor. Definimos un YAMLarchivo para configurar los servicios de nuestra aplicación. Un servicio en Docker Compose es un contenedor en ejecución y Compose nos permite vincular estos servicios con volúmenes y redes compartidas.

Crearemos diferentes contenedores para nuestra aplicación Drupal, base de datos y servidor web. Junto con estos, también crearemos un contenedor para ejecutar Certbot con el fin de obtener certificados para nuestro servidor web.

Crear un docker-compose.ymlarchivo:

nano docker-compose.yml

Agregue el siguiente código para definir la versión del archivo Compose y mysqlel servicio de base de datos:

~/drupal/docker-compose.yml

version: "3"services:  mysql:    image: mysql:8.0    container_name: mysql    command: --default-authentication-plugin=mysql_native_password    restart: unless-stopped    env_file: .env    volumes:      - db-data:/var/lib/mysql    networks:      - internal

Repasemos una por una todas las opciones de configuración del mysqlservicio:

• image: Esto especifica la imagen que se usará o se extraerá para crear el contenedor. Siempre se recomienda usar la imagen con la etiqueta de versión adecuada, excluyendo la latestetiqueta, para evitar conflictos futuros. Obtenga más información sobre las mejores prácticas de Dockerfile en la documentación de Docker.

• container_name:Para definir el nombre del contenedor.

• command:Esto se utiliza para anular el comando predeterminado (instrucción CMD) en la imagen. MySQL admite diferentes complementos de autenticación, pero mysql_native_passwordes el método tradicional de autenticación. Dado que PHP, y por lo tanto Drupal, no admiten la autenticación más reciente de MySQL, debemos configurarlo --default-authentication-plugin=mysql_native_passwordcomo el mecanismo de autenticación predeterminado.

• restart: Se utiliza para definir la política de reinicio del contenedor. La unless-stoppedpolítica reinicia un contenedor a menos que se detenga manualmente.

• env_file:Esto agrega las variables de entorno desde un archivo. En nuestro caso, leerá las variables de entorno desde el .envarchivo definido en el paso anterior.

• volumes:Esto monta rutas de host o volúmenes con nombre, especificados como subopciones de un servicio. Estamos montando un volumen con nombre llamado db-dataal /var/lib/mysqldirectorio del contenedor, donde MySQL escribirá sus archivos de datos de manera predeterminada.

• networks: Esto define la internalred a la que se unirá nuestro servicio de aplicación. Definiremos las redes al final del archivo.

Hemos definido nuestra mysqldefinición de servicio, así que ahora agreguemos la definición del drupalservicio de aplicación al final del archivo:

~/drupal/docker-compose.yml

...  drupal:    image: drupal:8.7.8-fpm-alpine    container_name: drupal    depends_on:      - mysql    restart: unless-stopped    networks:      - internal      - external    volumes:      - drupal-data:/var/www/html

En esta definición de servicio, le damos un nombre a nuestro contenedor y definimos una política de reinicio, como hicimos con el mysqlservicio. También agregamos algunas opciones específicas para este contenedor:

• image:Aquí, estamos usando la 8.7.8-fpm-alpineimagen de Drupal. Esta imagen tiene el php-fpmprocesador que nuestro servidor web Nginx requiere para manejar el procesamiento de PHP. Además, estamos usando la alpineimagen, derivada del proyecto Alpine Linux, que reducirá el tamaño de la imagen general y se recomienda en las mejores prácticas de Dockerfile. Drupal tiene más versiones de imágenes, así que consúltelas en Dockerhub.

• depends_on: Esto se utiliza para expresar dependencia entre servicios. Definir el mysqlservicio como dependencia de nuestro drupalcontenedor garantizará que drupaleste se creará después del mysqlcontenedor y permitirá que nuestra aplicación se inicie sin problemas.

• networks:Aquí, hemos agregado este contenedor a la externalred junto con la internalred. Esto garantizará que nuestro mysqlservicio sea accesible solo desde el drupalcontenedor a través de la internalred, mientras que este contenedor seguirá siendo accesible para otros contenedores a través de la externalred.

• volumes:Estamos montando un volumen con nombre que se llama drupal-dataal /var/www/htmlpunto de montaje creado por la imagen de Drupal. El uso de un volumen con nombre de esta manera nos permitirá compartir nuestro código de aplicación con otros contenedores.

A continuación, agreguemos la definición del servicio Nginx después de la drupaldefinición del servicio:

~/drupal/docker-compose.yml

...  webserver:    image: nginx:1.17.4-alpine    container_name: webserver    depends_on:      - drupal    restart: unless-stopped    ports:      - 80:80    volumes:      - drupal-data:/var/www/html      - ./nginx-conf:/etc/nginx/conf.d      - certbot-etc:/etc/letsencrypt    networks:      - external

Nuevamente, le asignamos un nombre a nuestro contenedor y lo hacemos dependiente del contenedor de Drupal en orden de inicio. También usamos una imagen alpina: la 1.17.4-alpineimagen de Nginx.

Esta definición de servicio también incluye las siguientes opciones:

• ports:Esto expone el puerto 80para habilitar las opciones de configuración que definimos en nuestro nginx.confarchivo en el Paso 1.

• volumes:Aquí, definimos tanto el volumen nombrado como la ruta del host:

  • drupal-data:/var/www/html:Esto montará nuestro código de aplicación Drupal en el /var/www/htmldirectorio que configuramos como raíz en nuestro bloque de servidor Nginx.

  • ./nginx-conf:/etc/nginx/conf.d:Esto montará el directorio de configuración de Nginx en el host en el directorio correspondiente en el contenedor, lo que garantiza que cualquier cambio que hagamos en los archivos del host se reflejará en el contenedor.

  • certbot-etc:/etc/letsencrypt:Esto montará los certificados y claves Let's Encrypt relevantes para nuestro dominio en el directorio apropiado en el contenedor.

  • networks:Hemos definido la externalred únicamente para permitir que este contenedor se comunique con el drupalcontenedor y no con el mysqlcontenedor.

Por último, agregaremos nuestra última definición de servicio para el certbotservicio. Asegúrese de reemplazar sammy@your_domainy your_domainpor su propio correo electrónico y nombre de dominio:

~/drupal/docker-compose.yml

...  certbot:    depends_on:      - webserver    image: certbot/certbot    container_name: certbot    volumes:      - certbot-etc:/etc/letsencrypt      - drupal-data:/var/www/html    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

Esta definición le indica a Compose que extraiga la certbot/certbotimagen de Docker Hub. También utiliza volúmenes con nombre para compartir recursos con el contenedor Nginx, incluidos los certificados de dominio y la clave certbot-etcy el código de la aplicación en drupal-data.

También lo hemos utilizado depends_onpara asegurarnos de que el certbotcontenedor se iniciará después de que webserverse ejecute el servicio.

No hemos especificado ninguno networksaquí porque este contenedor no se comunicará con ningún servicio a través de la red. Solo agrega los certificados y la clave del dominio que hemos montado utilizando los volúmenes nombrados.

También hemos incluido la commandopción que especifica un subcomando para ejecutar con el certbotcomando predeterminado del contenedor. El cliente de Certbot admite complementos para obtener e instalar certificados. Estamos usando el webrootcomplemento para obtener un certificado al incluir certonlyy --webrooten la línea de comandos. Obtenga más información sobre el complemento y los comandos adicionales en la documentación oficial de Certbot.

Después de la certbotdefinición del servicio, agregue las definiciones de red y volumen:

~/drupal/docker-compose.yml

...networks:  external:    driver: bridge  internal:    driver: bridgevolumes:  drupal-data:  db-data:  certbot-etc:

La clave de nivel superior networksnos permite especificar las redes que se crearán. networkspermite la comunicación entre los servicios/contenedores en todos los puertos, ya que están en el mismo host de demonio de Docker. Hemos definido dos redes, internaly external, para proteger la comunicación de los servicios webserver, drupaly .mysql

La volumesclave se utiliza para definir los volúmenes nombrados drupal-data, db-data, y certbot-etc. Cuando Docker crea volúmenes, el contenido del volumen se almacena en un directorio en el sistema de archivos del host, /var/lib/docker/volumes/, que es administrado por Docker. El contenido de cada volumen se monta luego desde este directorio a cualquier contenedor que use el volumen. De esta manera, es posible compartir código y datos entre contenedores.

El docker-compose.ymlarchivo terminado se verá así:

~/drupal/docker-compose.yml

version: "3"services:  mysql:    image: mysql:8.0    container_name: mysql    command: --default-authentication-plugin=mysql_native_password    restart: unless-stopped    env_file: .env    volumes:      - db-data:/var/lib/mysql    networks:      - internal    drupal:    image: drupal:8.7.8-fpm-alpine    container_name: drupal    depends_on:      - mysql    restart: unless-stopped    networks:      - internal      - external    volumes:      - drupal-data:/var/www/html    webserver:    image: nginx:1.17.4-alpine    container_name: webserver    depends_on:      - drupal    restart: unless-stopped    ports:      - 80:80    volumes:      - drupal-data:/var/www/html      - ./nginx-conf:/etc/nginx/conf.d      - certbot-etc:/etc/letsencrypt    networks:      - external    certbot:    depends_on:      - webserver    image: certbot/certbot    container_name: certbot    volumes:      - certbot-etc:/etc/letsencrypt      - drupal-data:/var/www/html    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domainnetworks:  external:    driver: bridge  internal:    driver: bridgevolumes:  drupal-data:  db-data:  certbot-etc:

Hemos terminado de definir nuestros servicios. A continuación, iniciemos el contenedor y probemos nuestras solicitudes de certificados.

Paso 4: obtención de certificados y credenciales SSL

Podemos iniciar nuestros contenedores con el docker-compose upcomando, que creará y ejecutará nuestros contenedores en el orden que hayamos especificado. Si nuestras solicitudes de dominio son exitosas, veremos el estado de salida correcto en nuestra salida y los certificados correctos montados en la /etc/letsencrypt/livecarpeta del contenedor del servidor web.

Para ejecutar los contenedores en segundo plano, utilice el docker-compose upcomando con el -dindicador:

docker-compose up -d

Verá un resultado similar que confirma que se han creado sus servicios:

Output...Creating mysql     ... doneCreating drupal    ... doneCreating webserver ... doneCreating certbot   ... done

Verifique el estado de los servicios mediante el docker-compose pscomando:

docker-compose ps

Veremos los servicios mysql, drupal, y webservercon un Statede Up, mientras que certbotsaldrán con un 0mensaje de estado:

Output  Name                 Command               State           Ports--------------------------------------------------------------------------certbot     certbot certonly --webroot ...   Exit 0drupal      docker-php-entrypoint php-fpm    Up       9000/tcpmysql       docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcpwebserver   nginx -g daemon off;             Up       0.0.0.0:80-80/tcp

Si ve algo distinto a lo que aparece Upen la Statecolumna para los servicios mysql, drupalo webserver, o un estado de salida distinto al 0del certbotcontenedor, asegúrese de verificar los registros de servicio con el docker-compose logscomando:

docker-compose logs service_name

Ahora podemos comprobar que nuestros certificados están montados en el webservercontenedor usando el docker-compose execcomando:

docker-compose exec webserver ls -la /etc/letsencrypt/live

Esto dará el siguiente resultado:

Outputtotal 16drwx------    3 root     root          4096 Oct  5 09:15 .drwxr-xr-x    9 root     root          4096 Oct  5 09:15 ..-rw-r--r--    1 root     root           740 Oct  5 09:15 READMEdrwxr-xr-x    2 root     root          4096 Oct  5 09:15 your_domain

Ahora que todo funciona correctamente, podemos editar nuestra certbotdefinición de servicio para eliminar la --stagingbandera.

Abra el docker-compose.ymlarchivo, vaya a la certbotdefinición del servicio y reemplace el --stagingindicador en la opción de comando con el --force-renewalindicador, que le indicará a Certbot que desea solicitar un nuevo certificado con los mismos dominios que un certificado existente. La certbotdefinición actualizada se verá así:

~/drupal/docker-compose.yml

...  certbot:    depends_on:      - webserver    image: certbot/certbot    container_name: certbot    volumes:      - certbot-etc:/etc/letsencrypt      - drupal-data:/var/www/html    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain...

Necesitamos ejecutarlo docker-compose upnuevamente para recrear el certbotcontenedor. También incluiremos la --no-depsopción para indicarle a Compose que puede omitir el inicio del webserverservicio, ya que ya se está ejecutando:

docker-compose up --force-recreate --no-deps certbot

Veremos un resultado que indica que nuestra solicitud de certificado fue exitosa:

OutputRecreating certbot ... doneAttaching to certbotcertbot      | Saving debug log to /var/log/letsencrypt/letsencrypt.logcertbot      | Plugins selected: Authenticator webroot, Installer Nonecertbot      | Renewing an existing certificatecertbot      | Performing the following challenges:certbot      | http-01 challenge for your_domaincertbot      | http-01 challenge for www.your_domaincertbot      | Using the webroot path /var/www/html for all unmatched domains.certbot      | Waiting for verification...certbot      | Cleaning up challengescertbot      | IMPORTANT NOTES:certbot      |  - Congratulations! Your certificate and chain have been saved at:certbot      |    /etc/letsencrypt/live/your_domain/fullchain.pemcertbot      |    Your key file has been saved at:certbot      |    /etc/letsencrypt/live/your_domain/privkey.pemcertbot      |    Your cert will expire on 2020-01-03. To obtain a new or tweakedcertbot      |    version of this certificate in the future, simply run certbotcertbot      |    again. To non-interactively renew *all* of your certificates, runcertbot      |    "certbot renew"certbot      |  - Your account credentials have been saved in your Certbotcertbot      |    configuration directory at /etc/letsencrypt. You should make acertbot      |    secure backup of this folder now. This configuration directory willcertbot      |    also contain certificates and private keys obtained by Certbot socertbot      |    making regular backups of this folder is ideal.certbot      |  - If you like Certbot, please consider supporting our work by:certbot      |certbot      |    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donatecertbot      |    Donating to EFF:                    https://eff.org/donate-lecertbot      |certbot exited with code 0

Ahora que hemos generado exitosamente nuestros certificados, podemos actualizar nuestra configuración de Nginx para incluir SSL.

Paso 5: Modificación de la configuración del servidor web y la definición del servicio

Después de instalar los certificados SSL en Nginx, necesitaremos redirigir todas las solicitudes HTTP a HTTPS. También tendremos que especificar las ubicaciones de nuestro certificado SSL y de nuestras claves, y agregar parámetros de seguridad y encabezados.

Dado que va a recrear el webserverservicio para incluir estas adiciones, puede detenerlo ahora:

docker-compose stop webserver

Esto dará el siguiente resultado:

OutputStopping webserver ... done

A continuación, eliminemos el archivo de configuración de Nginx que creamos anteriormente:

rm nginx-conf/nginx.conf

Abra otra versión del archivo:

nano ng

					

												


							
															

									SUSCRÍBETE A NUESTRO BOLETÍN 								
							
															

									No te pierdas de nuestro contenido ni de ninguna de nuestras guías para que puedas avanzar en los juegos que más te gustan.								
							
						
						
						
					
				
			

		

			Correo Electronico
			

		
			

		
			

		
							

					Al suscribirte, aceptas nuestra política de privacidad y nuestros términos de servicio.				
						

			
			


Tal vez te puede interesar:

Cómo agregar efectos de sonido a tus aplicaciones React
Cómo utilizar el modo independiente de Certbot para recuperar certificados SSL de Let's Encrypt en Debian 10
Cómo instalar el servidor web Apache en Debian 10
Obtención de datos de ubicación con Ionic 4 y Capacitor