Установка WordPress с помощью Docker Compose: сервисы и SSL-сертификаты

WordPress – это свободная и открытая система управления контентом (CMS), построенная на базе данных MySQL с обработкой PHP. Благодаря своей расширяемой архитектуре на основе плагинов и шаблонов, а также возможности управлять через веб-интерфейс, WordPress является популярным выбором при создании различных веб-сайтов – от блогов до посадочных страниц и eCommerce сайтов.

Запуск WordPress обычно включает в себя установку стека LAMP (Linux, Apache, MySQL и PHP) или LEMP (Linux, Nginx, MySQL и PHP), что может занять много времени. Однако с помощью таких инструментов, как Docker и Docker Compose, вы можете упростить процесс настройки стека и установки WordPress. Вместо ручной установки отдельных компонентов вы можете использовать образы, которые многое стандартизируют (библиотеки, конфигурационные файлы и переменные среды), и запускать эти образы в изолированных контейнерах, которые выполняются в общей операционной системе. Кроме того, с помощью Compose вы можете координировать работу нескольких контейнеров – например, приложения и базы данных – и связать их друг с другом.

В этом мануале мы создадим мультиконтейнерную установку WordPress, где будет контейнер базы данных MySQL, веб-сервера Nginx и самого WordPress. Также мы защитим установку, получив для домена, который вы хотите связать с вашим сайтом, сертификаты TLS/SSL от Let’s Encrypt. Также мы настроим cron для обновления ваших сертификатов, чтобы домен оставался зашифрованным.

Требования

  • Сервер Ubuntu 18.04, настроенный по этому мануалу.
  • Установка Docker (смотрите разделы 1-2 мануала Установка и использование Docker в Ubuntu 18.04).
  • Установка Docker Compose (по разделу 1 мануала Установка Docker Compose в Ubuntu 18.04).
  • Зарегистрированное доменное имя. Этот мануал использует условный домен example.com, который вы должны заменить своим доменом.
  • DNS-записи А для доменов example.com и www.example.com, направленные на внешний IP-адрес сервера.

1: Определение конфигурации веб-сервера

Прежде чем запускать какие-либо контейнеры, нужно определить конфигурации веб-сервера Nginx. Его конфигурационный файл будет включать в себя специальные блоки location для WordPress, а также блок location для направления запросов верификации Let’s Encrypt на клиент Certbot (для автоматического обновления сертификатов).

Сначала создайте каталог проекта для вашей установки WordPress под названием wordpress и перейдите в него:

mkdir wordpress && cd wordpress

Затем создайте каталог для конфигурационного файла:

mkdir nginx-conf

Откройте файл с помощью nano или другого редактора:

nano nginx-conf/nginx.conf

В этот файл мы поместим блок server с директивами server name и document root, а также блоки location для направления запроса клиента Certbot, обработки PHP и запросов статических активов.

Вставьте следующий код в файл. Обязательно замените example.com собственным доменным именем:

server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
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;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass wordpress: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;
}
}

Давайте подробно разберем, какую информацию содержит блок server.

Директивы:

  • listen: указывает прослушиваемый порт 80, что позволяет нам использовать плагин Certbot webroot для запросов сертификатов. Обратите внимание, порт 443 ещ ене включен – мы обновим конфигурацию, чтобы включить SSL, когда получим сертификаты.
  • server_name: определяет имя вашего сервера и блок server, который должен использоваться для запросов к нему. Обязательно замените example.com в этой строке своим доменным именем.
  • index: определяет файлы, которые будут использоваться в качестве индексов при обработке запросов к вашему серверу. Здесь мы изменили приоритет по умолчанию, поставив index.php перед index.html, чтобы Nginx сначала использовал файлы с именем index.php, когда это возможно.
  • root: указывает корневой каталог для запросов к этому серверу. Этот каталог, /var/www/html, создается как точка монтирования во время сборки согласно инструкциям в WordPress Dockerfile. Также этот Dockerfile гарантирует, что файлы из релиза WordPress подключены к этому тому.

Блоки location:

  • location ~ /.well-known/acme-challenge: этот блок будет обрабатывать запросы в каталоге .well-known, где Certbot разместит временный файл для проверки того, разрешается ли DNS вашего домена на ваш сервер. С этой конфигурацией можно использовать плагин webroot для получения сертификатов.
  • location /: в этом блоке используется директиву try_files для проверки файлов, которые соответствуют отдельным запросам URI. Однако вместо статуса 404 Not Found по умолчанию сервер передаст управление в файл index.php WordPress с аргументами запроса.
  • location ~ \.php$: этот блок настраивает обработку PHP и передает запросы в контейнер WordPress. Поскольку Docker образ WordPress будет основан на образе php: fpm, мы также включим в этот блок специальные параметры конфигурации для протокола FastCGI. Nginx нужен независимый PHP процессор для запросов PHP: в данном случае эти запросы будут обрабатываться процессором php-fpm, включенным в образ php: fpm. Кроме того, этот блок включает в себя специальные директивы, переменные и параметры FastCGI, которые будут проксировать запросы приложению WordPress в контейнере, устанавливать индекс для обработанного URI запроса и парсить запросы URI.
  • location ~ /\.ht: этот блок будет обрабатывать файлы .htaccess, так как Nginx их не обслуживает. Директива deny_all гарантирует, что файлы .htaccess никогда не будут предоставляться пользователям.
  • location = /favicon.ico, location = /robots.txt: эти блоки гарантируют, что запросы к /favicon.ico и /robots.txt не будут регистрироваться.
  • location ~* \.(css|gif|ico|jpeg|jpg|js|png)$: этот блок отключает логирование для запросов статических активов и обеспечивает их высокую кэшируемость, поскольку их обслуживание обычно дорого обходится.

Читайте также: Алгоритмы выбора блоков server и location в Nginx

Сохраните и закройте файл, когда закончите редактирование. Если вы использовали nano, нажмите Ctrl+X, Y, а затем Enter.

После конфигурации Nginx вы можете перейти к созданию переменных среды, которые будут передаваться в приложение и контейнеры базы данных во время выполнения.

2: Определение переменных среды

Ваша БД и контейнеры приложений WordPress нуждаются в доступе к определенным переменным среды во время выполнения, чтобы данные приложения сохранялись и были доступны. Эти переменные должны содержать имя базы данных приложения и хоста. Они в том числе включают в себя конфиденциальную информацию: root пароль MySQL, пароль пользователя и базы данных приложения.

Вместо того чтобы указывать все эти значения в файле Docker Compose – главном файле, который содержит информацию о том, как будут работать контейнеры, – мы можем установить конфиденциальные значения в файле .env и ограничить его использование. Таким образом можно предотвратить копирование конфиденциальных данных в репозитории проектов и, следовательно, их раскрытие.

В основном каталоге проекта ~/wordpress откройте файл .env:

nano .env

Конфиденциальные значения, которые нужно указать в этом файле, включают пароль root пользователя MySQL, а также имя и пароль, которые WordPress будет использовать для доступа к базе данных.

Добавьте следующие имена переменных и значения в файл. Не забудьте указать свои собственные значения для каждой переменной:

MYSQL_ROOT_PASSWORD=your_root_password
MYSQL_USER=your_wordpress_database_user
MYSQL_PASSWORD=your_wordpress_database_password

Итак, вы указали пароль учетной записи администратора root, а также имя пользователя и пароль для БД приложения.

Сохраните и закройте файл, когда закончите редактирование.

Поскольку файл .env содержит конфиденциальную информацию, нужно обязательно включить его в файлы .gitignore и .dockerignore этого проекта (они сообщают Git и Docker, какие файлы не следует копировать в репозитории Git и образы Docker соответственно).

Читайте также: Краткий справочник по Git

Если вам нужен контроль версий Git, инициализируйте текущий рабочий каталог как репозиторий:

git init

Откройте файл .gitignore:

nano .gitignore

Добавьте в него файл .env:

.env

Сохраните и закройте файл.

Еще одна хорошая мера предосторожности – добавить .env в файл .dockerignore, чтобы он не попадал в контейнеры, когда вы используете этот каталог в качестве контекста сборки.

Откройте файл:

nano .dockerignore

Добавьте .env:

.env

Ниже можно при желании добавить файлы и каталоги, связанные с разработкой вашего приложения:

.env
.git
docker-compose.yml
.dockerignore

Сохраните и закройте файл.

После этого вы можете перейти к определению своих сервисов в файле docker-compose.yml.

3: Определение сервисов с помощью Docker Compose

Ваш файл docker-compose.yml будет содержать определения сервисов вашей установки. В Compose сервис – это работающий контейнер, а определения сервисов указывают информацию о том, как будет работать каждый контейнер.

Используя Compose, вы можете определить различные сервисы для запуска мультиконтейнерных приложений, поскольку Compose позволяет связывать эти сервисы вместе с помощью общих сетей и томов. Это полезно для нашей текущей настройки, так как мы собираемся создать отдельные контейнеры для БД, приложения WordPress и веб-сервера. Мы также создадим контейнер для запуска клиента Certbot, чтобы получить сертификаты для веб-сервера.

Для начала откройте файл docker-compose.yml:

nano docker-compose.yml

Добавьте следующий код, чтобы определить версию файла Compose и сервис базы данных db:

version: '3'
services:
db:
image: mysql:8.0
container_name: db
restart: unless-stopped
env_file: .env
environment:
- MYSQL_DATABASE=wordpress
volumes:
- dbdata:/var/lib/mysql
command: '--default-authentication-plugin=mysql_native_password'
networks:
- app-network

Определение сервиса db содержит следующие параметры:

  • image: сообщает Compose, какой образ загрузить для создания контейнера. Мы закрепляем здесь mysql:8.0, чтобы избежать возможных конфликтов, так как образ mysql: latest постоянно обновляется. Для получения дополнительной информации о закреплении версий и обхода конфликтов зависимостей см. документацию Docker.
  • container_name: указывает имя контейнера.
  • restart: определяет политику перезапуска контейнера. По умолчанию здесь no, но мы установили перезапуск контейнера, если он не был остановлен вручную.
  • env_file: добавляет переменные среды из файла.env, расположенного в контексте сборки. В этом случае контекст сборки является нашим текущим каталогом.
  • environment: эта опция позволяет указывать дополнительные переменные окружения, помимо тех, которые определены в файле .env. Мы установим в переменной MYSQL_DATABASE значение wordpress, чтобы предоставить имя базы данных приложения. Поскольку это не конфиденциальная информация, ее можно включить непосредственно в файл docker-compose.yml.
  • volumes: здесь монтируется именованный том dbdata в каталоге /var/lib/mysql контейнера. Это стандартный каталог данных для MySQL в большинстве дистрибутивов.
  • command: эта опция указывает команду для переопределения инструкции CMD по умолчанию для  образа. В нашем случае нужно добавить параметр в стандартную команду mysqld образа Docker, которая запускает сервер MySQL в контейнере. Эта опция, –default-authentication-plugin=mysql_native_password, устанавливает для системной переменной –default-authentication-plugin значение mysql_native_password, указывая, какой механизм аутентификации должен управлять новыми запросами входа. Эту настройку нужно добавить для аутентификации пользователя БД, поскольку PHP и, следовательно, образ WordPress не поддерживают более новую аутентификацию MySQL по умолчанию.
  • networks: указывает, что сервис приложений присоединится к сети app-network, которую мы определим в конце файла.

Под сервисом db укажите определение сервиса приложения wordpress.

...
wordpress:
depends_on:
- db
image: wordpress:5.1.1-fpm-alpine
container_name: wordpress
restart: unless-stopped
env_file: .env
environment:
- WORDPRESS_DB_HOST=db:3306
- WORDPRESS_DB_USER=$MYSQL_USER
- WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
- WORDPRESS_DB_NAME=wordpress
volumes:
- wordpress:/var/www/html
networks:
- app-network

В этом определении мы называем контейнер и определяем политику перезапуска, как делали это в сервисе db. Мы также добавляем некоторые индивидуальные параметры для этого контейнера:

  • depends_on: эта опция запускает контейнеры в порядке зависимости, то есть контейнер wordpress будет запускаться после контейнера db. Приложение WordPress зависит от  базы данных и пользователя, поэтому выражение этого порядка позволит ему правильно запускаться.
  • image: здесь мы используем образ WordPress 5.1.1-fpm-alpine. Как обсуждалось в разделе 1, благодаря этому образу приложение будет иметь процессор php-fpm, необходимый Nginx для обработки PHP. Это также образ alpine, полученный из проекта Alpine Linux, а это поможет уменьшить общий размер образа. За дополнительной информацией о преимуществах и недостатках использования образов alpine обращайтесь к обсуждению Image Variants на странице образов WordPress в Docker Hub.
  • env_file: позволяет извлечь значения из файла .env, поскольку именно здесь мы определили пользователя и пароль базы данных приложения.
  • environment: здесь мы используем значения, которые определили в файле .env, но присваиваем их переменным, которые нужны образу WordPress: WORDPRESS_DB_USER и WORDPRESS_DB_PASSWORD. Мы также определяем WORDPRESS_DB_HOST, это сервер MySQL, работающий в контейнере db, который доступен по порту MySQL по умолчанию, 3306. Значение WORDPRESS_DB_NAME должно совпадать со значением, которое вы указали в определении сервиса MySQL для MYSQL_DATABASE: wordpress.
  • volumes: монтирует именованный том под названием wordpress в точку /var/www/html, созданную образом WordPress. Использование именованного тома позволит нам делиться кодом приложения с другими контейнерами.
  • networks: мы также добавляем контейнер WordPress в сеть app-network.

Далее, под определением сервиса wordpress добавьте следующее определение для сервиса веб-сервера Nginx:

...
webserver:
depends_on:
- wordpress
image: nginx:1.15.12-alpine
container_name: webserver
restart: unless-stopped
ports:
- "80:80"
volumes:
- wordpress:/var/www/html
- ./nginx-conf:/etc/nginx/conf.d
- certbot-etc:/etc/letsencrypt
networks:
- app-network

Опять же, здесь мы называем контейнер и делаем его зависимым от контейнера WordPress в порядке запуска. Мы также используем образ alpine – 1.15.12-alpine.

Это определение сервиса также включает следующие опции:

  • ports: открывает порт 80 для включения параметров конфигурации, которые мы определили в файле nginx.conf в разделе 1.
  • volumes: здесь мы определяем комбинацию именованных томов и привязок:
    • wordpress:/var/www/html: это смонтирует код приложения WordPress в каталог /var/www/html, каталог, который мы установили в качестве root в блоке server.
    • ./nginx-conf:/etc/nginx/conf.d: свяжет монтирование каталога конфигурации Nginx на хосте с соответствующим каталогом в контейнере, благодаря чему любые изменения в файлах на хосте будут отражены в контейнере.
    • certbot-etc:/etc/letsencrypt: смонтирует соответствующие сертификаты и ключи Let’s Encrypt для нашего домена в соответствующий каталог на контейнере.

Снова этот контейнер добавляется в сеть app-network.

Под определением webserver  добавьте последнее определение сервиса для certbot. Обязательно замените адрес электронной почты и указанные здесь доменные имена своей собственной информацией:

certbot:
depends_on:
- webserver
image: certbot/certbot
container_name: certbot
volumes:
- certbot-etc:/etc/letsencrypt
- wordpress:/var/www/html
command: certonly --webroot --webroot-path=/var/www/html --email 8host@example.com --agree-tos --no-eff-email --staging -d example.com -d www.example.com

Это определение извлекает образ certbot/certbot из Docker Hub. Оно также привлекает именованные тома для совместного использования ресурсов с контейнером Nginx (сертификаты домена и ключ в certbot-etc и код приложения в wordpress).

Опять же, мы использовали depends_on, чтобы указать, что контейнер certbot должен запускаться только после запуска сервиса webserver.

Мы также включили параметр command, он задает подкоманду, которую нужно запустить с помощью команды certbot контейнера по умолчанию. Подкоманда certonly получит сертификат со следующими параметрами:

  • –webroot: использует плагин webroot для размещения файлов в папке webroot. Этот плагин зависит от метода проверки HTTP-01. Он использует HTTP-запрос, чтобы подтвердить, что Certbot может получить доступ к ресурсам с сервера, который отвечает на данное доменное имя.
  • –webroot-path: указывает путь к каталогу webroot.
  • –email: адрес электронной почты для регистрации и восстановления.
  • –agree-tos: означает, что вы принимаете Соглашение подписчика ACME.
  • –no-eff-email: не позволяет Certbot делиться вашей электронной почтой с Electronic Frontier Foundation (EFF). Этот параметр можно удалить, если он вам не нужен.
  • –staging: использует промежуточную среду Let’s Encrypt для получения тестовых сертификатов. Использование этого параметра позволяет протестировать параметры конфигурации и избежать возможных ограничений на количество запросов домена. Для получения дополнительной информации об этих ограничениях см. документацию по ограничениям Let’s Encrypt.
  • -d: позволяет указать доменные имена, которые вы хотите прикрепить к вашему запросу сертификата. В данном случае мы включили example.com и www.example.com. Обязательно замените их своим собственным доменом.

После сервиса certbot добавьте определение сети и тома:

...
volumes:
certbot-etc:
wordpress:
dbdata:
networks:
app-network:
driver: bridge

Ключ верхнего уровня volumes определяет тома certbot-etc, wordpress и dbdata. Когда Docker создает тома, содержимое тома сохраняется в каталоге в файловой системе хоста Docker, /var/lib/docker/volumes/. Содержимое каждого тома затем монтируется из этого каталога в любой контейнер, использующий соответствующий том. Таким образом можно обмениваться кодом и данными между контейнерами.

Пользовательская мостовая сеть app-network обеспечивает связь между контейнерами, поскольку они находятся на одном хосте Docker. Это оптимизирует трафик и обмен данными внутри приложения, поскольку оно открывает все порты между контейнерами в одной и той же мостовой сети, при этом не открывая никаких портов для внешнего мира. Контейнеры db, wordpress и webserver могут взаимодействовать друг с другом, нужно только предоставить порт 80 для внешнего доступа к приложению.

Готовый файл docker-compose.yml будет выглядеть так:

version: '3'
services:
db:
image: mysql:8.0
container_name: db
restart: unless-stopped
env_file: .env
environment:
- MYSQL_DATABASE=wordpress
volumes:
- dbdata:/var/lib/mysql
command: '--default-authentication-plugin=mysql_native_password'
networks:
- app-network
wordpress:
depends_on:
- db
image: wordpress:5.1.1-fpm-alpine
container_name: wordpress
restart: unless-stopped
env_file: .env
environment:
- WORDPRESS_DB_HOST=db:3306
- WORDPRESS_DB_USER=$MYSQL_USER
- WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
- WORDPRESS_DB_NAME=wordpress
volumes:
- wordpress:/var/www/html
networks:
- app-network
webserver:
depends_on:
- wordpress
image: nginx:1.15.12-alpine
container_name: webserver
restart: unless-stopped
ports:
- "80:80"
volumes:
- wordpress:/var/www/html
- ./nginx-conf:/etc/nginx/conf.d
- certbot-etc:/etc/letsencrypt
networks:
- app-network
certbot:
depends_on:
- webserver
image: certbot/certbot
container_name: certbot
volumes:
- certbot-etc:/etc/letsencrypt
- wordpress:/var/www/html
command: certonly --webroot --webroot-path=/var/www/html --email 8host@example.com --agree-tos --no-eff-email --staging -d example.com -d www.example.com
volumes:
certbot-etc:
wordpress:
dbdata:
networks:
app-network:
driver: bridge

Сохраните и закройте файл.

4: Получение сертификатов SSL

Мы можем запустить контейнеры с помощью команды docker-compose up, которая создаст и запустит их в указанном нами порядке. Если запросы сертификата для домена будут выполнены успешно, мы увидим соответствующий статус в выходных данных и сами сертификаты, смонтированные в /etc/letsencrypt/live контейнера webserver.

Создайте контейнеры с помощью docker-compose up и флага -d, который запустит контейнеры db, wordpress и webserver в фоновом режиме:

docker-compose up -d

Вы увидите вывод, подтверждающий, что сервисы были созданы:

Creating db ... done
Creating wordpress ... done
Creating webserver ... done
Creating certbot   ... done

Используя docker-compose ps, проверьте статус сервисов:

docker-compose ps

Если все прошло успешно, сервисы db, wordpress и webserver будут активированы, и контейнер certbot завершит работу и выведет сообщение о статусе 0:

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

Если в столбце State сервисов db, wordpress или webserver вы видите не Up, а другое значение, или статус выхода контейнера certbot отличается от 0, обязательно проверьте логи сервисов с помощью команды docker-compose logs:

docker-compose logs service_name

Теперь можно убедиться, что сертификаты в контейнере webserver были смонтированы, с помощью docker-compose exec:

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

Если ваши запросы на сертификат были обработаны успешно, вы увидите подобный вывод:

total 16
drwx------    3 root     root          4096 May 10 15:45 .
drwxr-xr-x    9 root     root          4096 May 10 15:45 ..
-rw-r--r--    1 root     root           740 May 10 15:45 README
drwxr-xr-x    2 root     root          4096 May 10 15:45 example.com

Теперь, когда вы знаете, что ваш запрос на сертификаты был принят, вы можете отредактировать определение сервиса certbot и убрать флаг –staging.

Откройте docker-compose.yml:

nano docker-compose.yml

Найдите раздел с определением сервиса certbot и замените флаг –staging в опции command на флаг –force-renewal. С его помощью Certbot сможет запросить новый сертификат для тех же доменов, что и действующий сертификат. Определение certbot теперь будет выглядеть так:

...
certbot:
depends_on:
- webserver
image: certbot/certbot
container_name: certbot
volumes:
- certbot-etc:/etc/letsencrypt
- certbot-var:/var/lib/letsencrypt
- wordpress:/var/www/html
command: certonly --webroot --webroot-path=/var/www/html --email 8host@example.com --agree-tos --no-eff-email --force-renewal -d example.com -d www.example.com
...

Теперь вы можете запустить docker-compose для воссоздания контейнера certbot. Мы также включим параметр –no-deps, чтобы Compose мог пропустить запуск сервиса webserver, поскольку он уже запущен:

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

Вы увидите вывод, указывающий, что ваш запрос сертификата был успешно обработан:

Recreating certbot ... done
Attaching to certbot
certbot      | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot      | Plugins selected: Authenticator webroot, Installer None
certbot      | Renewing an existing certificate
certbot      | Performing the following challenges:
certbot      | http-01 challenge for example.com
certbot      | http-01 challenge for www.example.com
certbot      | Using the webroot path /var/www/html for all unmatched domains.
certbot      | Waiting for verification...
certbot      | Cleaning up challenges
certbot      | IMPORTANT NOTES:
certbot      |  - Congratulations! Your certificate and chain have been saved at:
certbot      |    /etc/letsencrypt/live/example.com/fullchain.pem
certbot      |    Your key file has been saved at:
certbot      |    /etc/letsencrypt/live/example.com/privkey.pem
certbot      |    Your cert will expire on 2019-08-08. To obtain a new or tweaked
certbot      |    version of this certificate in the future, simply run certbot
certbot      |    again. To non-interactively renew *all* of your certificates, run
certbot      |    "certbot renew"
certbot      |  - Your account credentials have been saved in your Certbot
certbot      |    configuration directory at /etc/letsencrypt. You should make a
certbot      |    secure backup of this folder now. This configuration directory will
certbot      |    also contain certificates and private keys obtained by Certbot so
certbot      |    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/donate
certbot      |    Donating to EFF:                    https://eff.org/donate-le
certbot      |
certbot exited with code 0

Получив необходимые сертификаты, вы можете перейти к отладке конфигурации Nginx для поддержки SSL. Об этом мы поговорим в следующей части этой серии мануалов.

Tags: , , , ,

Добавить комментарий