Поиск по сайту:

Как установить WordPress с помощью Docker Compose

Введение

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

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

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

Предпосылки

Чтобы следовать этому руководству, вам понадобятся:

  • Сервер под управлением Ubuntu 20.04, пользователь без полномочий root с привилегиями sudo и активным брандмауэром. Чтобы узнать, как их настроить, ознакомьтесь с нашим руководством по начальной настройке сервера.
  • Docker установлен на вашем сервере в соответствии с шагами 1 и 2 инструкции «Установка и использование Docker в Ubuntu 20.04».
  • Docker Compose установлен на вашем сервере, выполнив шаг 1 инструкции по установке Docker Compose в Ubuntu 20.04.
  • Зарегистрированное доменное имя. В этом руководстве будет использоваться your_domain. Вы можете получить его бесплатно на Freenom или воспользоваться услугами регистратора домена по вашему выбору.
  • Обе следующие записи DNS настроены для вашего сервера. Вы можете следовать этому введению в DNS DigitalOcean, чтобы узнать, как добавить их в учетную запись DigitalOcean:
    • Запись A с your_domain, указывающая на общедоступный IP-адрес вашего сервера.
    • Запись A с www.your_domain, указывающая на общедоступный IP-адрес вашего сервера.

    После того, как вы все настроили, вы готовы начать первый шаг.

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

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

    Сначала создайте каталог проекта для вашей установки WordPress. В этом примере он называется wordpress. Вы можете назвать этот каталог по-другому, если хотите:

    1. mkdir wordpress

    Затем перейдите в каталог:

    1. cd wordpress

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

    1. mkdir nginx-conf

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

    1. nano nginx-conf/nginx.conf

    В этом файле добавьте блок сервера с директивами для вашего имени сервера и корня документа, а также блоки местоположения, чтобы направить запрос клиента Certbot на сертификаты, обработку PHP и запросы статических ресурсов.

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

    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;
        }

        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;
        }
}

    Наш серверный блок включает в себя следующую информацию:

    Директивы:

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

    Блоки локации:

    • location ~ /.well-known/acme-challenge: этот блок location будет обрабатывать запросы к каталогу .well-known, куда Certbot поместит временный файл. чтобы убедиться, что DNS для вашего домена разрешается на ваш сервер. С этой конфигурацией вы сможете использовать подключаемый модуль webroot Certbot для получения сертификатов для своего домена.
    • location /: в этом блоке location директива try_files используется для проверки файлов, соответствующих отдельным запросам URI. Однако вместо возврата статуса 404 Not Found по умолчанию вы передадите управление файлу index.php WordPress с аргументами запроса.
    • location ~ \.php$: этот блок location будет обрабатывать PHP и передавать эти запросы в ваш контейнер wordpress. Потому что в этом блоке ваш образ WordPress Docker будет основан на протоколе FastCGI. Nginx требует независимый PHP-процессор для PHP-запросов. В этом случае эти запросы будут обрабатываться процессором php-fpm, включенным в образ php:fpm. Кроме того, этот блок местоположения включает специфичные для FastCGI директивы, переменные и параметры, которые будут проксировать запросы к приложению WordPress, работающему в вашем контейнере 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)$: этот блок отключает ведение журнала для запросов статических ресурсов и обеспечивает высокую кешируемость этих ресурсов, поскольку они обычно дороги в обслуживании.

    Дополнительные сведения о прокси-сервере FastCGI см. в статье Общие сведения об алгоритмах выбора Nginx Server и Location Block.

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

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

    Шаг 2 — Определение переменных среды

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

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

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

    1. 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 init:

    1. git init

    Затем создайте и откройте файл .gitignore:

    1. nano .gitignore

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

    .env

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

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

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

    1. 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:

    1. 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, какое изображение необходимо извлечь для создания контейнера. Вы закрепляете лучшие практики Dockerfile.
    • container_name: указывает имя контейнера.
    • restart: определяет политику перезапуска контейнера. По умолчанию используется нет, но вы настроили перезапуск контейнера, если он не будет остановлен вручную.
    • env_file: этот параметр сообщает Compose, что вы хотите добавить переменные среды из файла с именем .env, расположенного в контексте сборки. В этом случае контекстом сборки является ваш текущий каталог.
    • environment: этот параметр позволяет добавлять дополнительные переменные среды помимо тех, которые определены в вашем файле .env. Вы установите переменную MYSQL_DATABASE равной wordpress, чтобы указать имя для базы данных вашего приложения. Поскольку это неконфиденциальная информация, вы можете включить ее непосредственно в файл docker-compose.yml.
    • volumes: здесь вы монтируете именованный том с именем dbdata в каталог /var/lib/mysql в контейнере. Это стандартный каталог данных для MySQL в большинстве дистрибутивов.
    • command: этот параметр указывает команду для переопределения более новой аутентификации 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: для этой настройки вы используете страницу изображений Docker Hub WordPress.
    • 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. Использование именованного тома таким образом позволит вам совместно использовать код вашего приложения с другими контейнерами.
    • сети: вы также добавляете контейнер wordpress в сеть app-network.

    Затем под определением службы приложения wordpress добавьте следующее определение для службы webserver 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 Nginx.

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

    • ports: открывает доступ к порту 80 для включения параметров конфигурации, которые вы определили в файле nginx.conf на шаге 1.
    • тома: здесь вы определяете комбинацию именованных томов и привязок монтирования:
      • wordpress:/var/www/html: это смонтирует код вашего приложения WordPress в каталог /var/www/html, который вы указали как root в вашем блоке сервера Nginx.
      • ./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 sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

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

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

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

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

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

      ...
volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

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

      Определяемая пользователем мостовая сеть 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 sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

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

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

      Шаг 4 — Получение SSL-сертификатов и учетных данных

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

      1. docker-compose up -d

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

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

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

      1. docker-compose ps

      После завершения ваши службы db, wordpress и webserver будут Up и certbot завершится с сообщением о состоянии 0:

      Output
        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

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

      1. docker-compose logs service_name

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

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

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

      Output
      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 your_domain

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

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

      1. 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 sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
...

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

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

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

      Output
      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 your_domain
certbot      | http-01 challenge for www.your_domain
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/your_domain/fullchain.pem
certbot      |    Your key file has been saved at:
certbot      |    /etc/letsencrypt/live/your_domain/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.

      Шаг 5 — Изменение конфигурации веб-сервера и определения службы

      Включение SSL в вашей конфигурации Nginx будет включать в себя добавление перенаправления HTTP на HTTPS, указание сертификата SSL и расположения ключей, а также добавление параметров безопасности и заголовков.

      Поскольку вы собираетесь воссоздать службу webserver, чтобы включить эти дополнения, вы можете остановить ее сейчас:

      1. docker-compose stop webserver

      Перед изменением файла конфигурации получите рекомендуемый параметр безопасности Nginx от Certbot с помощью curl:

      1. curl -sSLo nginx-conf/options-ssl-nginx.conf https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf

      Эта команда сохранит эти параметры в файле с именем options-ssl-nginx.conf, расположенном в каталоге nginx-conf.

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

      1. rm nginx-conf/nginx.conf

      Создайте и откройте другую версию файла:

      1. nano nginx-conf/nginx.conf

      Добавьте в файл следующий код, чтобы перенаправить HTTP на HTTPS и добавить учетные данные SSL, протоколы и заголовки безопасности. Не забудьте заменить your_domain своим собственным доменом:

      server {
        listen 80;
        listen [::]:80;

        server_name your_domain www.your_domain;

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

        location / {
                rewrite ^ https://$host$request_uri? permanent;
        }
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name your_domain www.your_domain;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

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

        include /etc/nginx/conf.d/options-ssl-nginx.conf;

        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "no-referrer-when-downgrade" always;
        add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
        # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        # enable strict transport security only if you understand the implications

        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;
        }
}

      Блок HTTP-сервера указывает веб-корневой каталог для запросов на обновление Certbot в каталог .well-known/acme-challenge. Он также включает директиву перезаписи, которая направляет HTTP-запросы к корневому каталогу на HTTPS.

      Блок сервера HTTPS включает ssl и http2. Чтобы узнать больше о том, как HTTP/2 повторяет протоколы HTTP, и о преимуществах, которые он может иметь для производительности веб-сайта, прочитайте введение в Как настроить Nginx с поддержкой HTTP/2 в Ubuntu 18.04.

      Этот блок также включает ваш SSL-сертификат и расположение ключей, а также рекомендуемые параметры безопасности Certbot, которые вы сохранили в nginx-conf/options-ssl-nginx.conf.

      Кроме того, включены некоторые заголовки безопасности, которые позволят вам получить рейтинг A по таким вещам, как функция «предварительной загрузки».

      Ваши директивы root и index также расположены в этом блоке, как и остальные блоки расположения, специфичные для WordPress, которые обсуждались на шаге 1.

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

      Перед повторным созданием службы webserver вам необходимо добавить сопоставление портов 443 в определение службы webserver.

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

      1. nano docker-compose.yml

      В определение службы webserver добавьте следующее сопоставление портов:

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

      Вот полный файл 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"
      - "443:443"
    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 sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

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

      Воссоздайте службу webserver:

      1. docker-compose up -d --force-recreate --no-deps webserver

      Проверьте свои сервисы с помощью docker-compose ps:

      1. docker-compose ps

      В выводе должно быть указано, что ваши службы db, wordpress и webserver запущены:

      Output
        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:443->443/tcp, 0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

      Когда ваши контейнеры запущены, вы можете завершить установку WordPress через веб-интерфейс.

      Шаг 6 — Завершение установки через веб-интерфейс

      Запустив контейнеры, завершите установку через веб-интерфейс WordPress.

      В веб-браузере перейдите к домену вашего сервера. Не забудьте заменить your_domain своим собственным доменным именем:

      https://your_domain

      Выберите язык, который вы хотите использовать:

      После нажатия «Продолжить» вы попадете на главную страницу настройки, где вам нужно будет выбрать имя для своего сайта и имя пользователя. Здесь рекомендуется выбрать запоминающееся имя пользователя (а не «admin») и надежный пароль. Вы можете использовать пароль, который WordPress генерирует автоматически, или создать свой собственный.

      Наконец, вам нужно будет ввести свой адрес электронной почты и решить, хотите ли вы запретить поисковым системам индексировать ваш сайт:

      Нажав «Установить WordPress» внизу страницы, вы получите приглашение для входа в систему:

      После входа в систему вы получите доступ к панели администрирования WordPress:

      Завершив установку WordPress, вы можете предпринять шаги, чтобы убедиться, что ваши SSL-сертификаты будут обновляться автоматически.

      Шаг 7 — Обновление сертификатов

      Сертификаты Let’s Encrypt действительны в течение 90 дней. Вы можете настроить автоматический процесс продления, чтобы гарантировать, что они не истечет. Один из способов сделать это — создать задание с помощью утилиты планирования cron. В следующем примере вы создадите задание cron для периодического запуска сценария, который будет обновлять ваши сертификаты и перезагружать конфигурацию Nginx.

      Сначала откройте скрипт с именем ssl_renew.sh:

      1. nano ssl_renew.sh

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

      #!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew --dry-run && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

      Этот сценарий сначала присваивает двоичный файл docker-compose переменной с именем COMPOSE и указывает параметр --no-ansi, который будет запускать docker-compose команды без управляющих символов ANSI. Затем он делает то же самое с двоичным файлом docker. Наконец, он переходит в каталог проекта ~/wordpress и выполняет следующие команды docker-compose:

      • docker-compose run. Это запустит контейнер certbot и переопределит команду, указанную в вашем certbot. определение услуги. Вместо использования подкоманды certonly используется подкоманда renew, которая обновляет сертификаты, срок действия которых истекает. Также включена опция --dry-run для проверки вашего скрипта.
        • Сигнал
      • SIGHUP контейнеру webserver для перезагрузки конфигурации Nginx.

      Затем он запускает docker system prune, чтобы удалить все неиспользуемые контейнеры и образы.

      Закройте файл, когда закончите редактирование. Сделайте его исполняемым с помощью следующей команды:

      1. chmod +x ssl_renew.sh

      Затем откройте корневой файл crontab, чтобы запускать скрипт обновления с заданным интервалом:

      sudo crontab -e

      Если вы впервые редактируете этот файл, вам будет предложено выбрать редактор:

      Output
      no crontab for root - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:
...

      В самом низу этого файла добавьте следующую строку:

      ...
*/5 * * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

      Это установит интервал задания каждые пять минут, чтобы вы могли проверить, сработал ли ваш запрос на продление, как предполагалось. Файл журнала cron.log создается для записи соответствующих выходных данных задания.

      Через пять минут проверьте cron.log, чтобы убедиться, что запрос на продление выполнен успешно:

      1. tail -f /var/log/cron.log

      Следующий вывод подтверждает успешное обновление:

      Output
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** 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/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Выйдите, введя CTRL+C в своем терминале.

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

      ...
0 12 * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

      Вы также можете удалить параметр --dry-run из сценария ssl_renew.sh:

      #!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

      Ваше задание cron гарантирует, что ваши сертификаты Let’s Encrypt не истечет, обновляя их, когда они соответствуют требованиям. Вы также можете настроить ротацию журналов с помощью утилиты Logrotate для ротации и сжатия файлов журналов.

      Заключение

      В этом руководстве вы использовали Docker Compose для создания установки WordPress с веб-сервером Nginx. В рамках этого рабочего процесса вы получили сертификаты TLS/SSL для домена, который вы хотите связать со своим сайтом WordPress. Кроме того, вы создали задание cron для обновления этих сертификатов при необходимости.

      В качестве дополнительных шагов для повышения производительности и резервирования сайта вы можете ознакомиться со следующими статьями о доставке и резервном копировании ресурсов WordPress:

      • Как ускорить доставку ресурсов WordPress с помощью CDN DigitalOcean Spaces.
      • Как создать резервную копию сайта WordPress в Spaces.
      • Как хранить ресурсы WordPress в пространстве DigitalOcean.

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

      • Как настроить WordPress с MySQL в Kubernetes с помощью Helm.