One place for hosting & domains

      качестве

      Настройка BIND в качестве DNS-сервера частной сети на базе Ubuntu 18.04


      Введение

      Важным элементом управления конфигурацией и инфраструктурой сервера является поддержание удобного способа просмотра сетевых интерфейсов и IP-адресов по имени с помощью настройки корректной системы доменных имен (DNS). Использование полных доменных имен (FQDN), а не IP-адреса, для указания сетевых адресов облегчает настройку служб и приложений и повышает поддерживаемость файлов конфигурации. Настройка собственной DNS для вашей частной сети — это отличный способ совершенствования методов управления серверами.

      Из этого руководства вы узнаете, как выполнить настройку внутреннего DNS-сервера с помощью программного обеспечения сервера имен BIND (BIND9) на Ubuntu 18.04, которое может быть использовано вашими серверами для предоставления частных имен хостов и частных IP-адресов. Это служит центральным средством для управления внутренними именами хостов и частными IP-адресами, что необходимо при расширении вашей среды до более чем нескольких хостов.

      Версию CentOS, используемую в данном руководстве, можно найти здесь.

      Предварительные требования

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

      • Свежий сервер Ubuntu 18.04, который будет использоваться в качестве основного DNS-сервера, ns1.
      • (Рекомендуется) Второй сервер Ubuntu 18.04, который используется в качестве дополнительного DNS-сервера, ns2.
      • Дополнительные серверы в одном центре обработки данных, которые будут использовать ваши DNS-серверы.

      На каждом из этих серверов необходимо настроить административный доступ с помощью пользователя sudo и брандмауэра согласно инструкциям нашего руководства по начальной настройке сервера Ubuntu 18.04.

      Если вы не знакомы с концепцией DNS, рекомендуем ознакомиться минимум с первыми тремя частями нашего руководства Введение в управление DNS.

      Пример инфраструктуры и целей

      В рамках данной статьи мы предполагаем следующее:

      • У нас есть два сервера, которые будут назначены в качестве наших серверов имен DNS. В этом руководстве мы будем использовать наименования ns1 и ns2.
      • У нас есть два дополнительных клиентских сервера, которые будут использовать созданную нами инфраструктуру DNS. В этом руководстве мы будем использовать наименования host1 и host2. Вы можете добавить любое количество, которое захотите, для вашей инфраструктуры.
      • Все эти серверы существуют в одном центре обработки данных. Мы полагаем, что это центр обработки данных nyc3.
      • Для всех этих серверов активирована опция частной сети (и в подсети 10.128.0.0/16; вам, возможно, нужно будет отредактировать эти параметры для ваших серверов).
      • Все серверы подключены к проекту, который запущен на example.com. Поскольку наша система DNS будет полностью внутренней и частной, вам не нужно будет приобретать доменное имя. Однако использование собственного домена может помочь избежать конфликтов с доменами с публичной маршрутизацией.

      С учетом этих предположений мы решили, что будет полезно использовать схему именования, которая использует nyc3.example.com для обращения к нашей частной подсети или зоне. Таким образом, частным полным доменным именем (FQDN) для host1 будет host1.nyc3.example.com. Соответствующую информацию см. в следующей таблице:

      Хост Роль Частное FQDN Частный IP-адрес
      ns1 Основной DNS-сервер ns1.nyc3.example.com 10.128.10.11
      ns2 Дополнительный DNS-сервер ns2.nyc3.example.com 10.128.20.12
      host1 Стандартный хост 1 host1.nyc3.example.com 10.128.100.101
      host2 Стандартный хост 2 host2.nyc3.example.com 10.128.200.102

      Примечание: существующая настройка будет отличаться, примеры имен и IP-адресов будут использоваться для демонстрации того, как выполнить настройку DNS-сервера для получения работающей внутренней DNS. У вас должна быть возможность легко адаптировать данную настройку для вашей среды, заменив имена хостов и частные IP-адреса на собственные. Нет необходимости использовать имя региона центра обработки данных в схеме присвоения имен, но мы используем его для обозначения хостов, принадлежащих к частной сети конкретного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутреннюю DNS внутри каждого отдельного центра обработки данных.

      К концу данного руководства мы получим основной DNS-сервер, ns1, и, в качестве опции, дополнительный DNS-сервер, ns2, который будет служит в качестве резервного сервера.

      Давайте начнем с установки нашего основного DNS-сервера, ns1.

      Установка BIND на DNS-серверах

      Примечание: красным цветом выделяется важная информация! Он часто будет использоваться для чего-то, что необходимо заменить на собственные настройки или того, что нужно изменить или добавить в файл конфигурации. Например, если вы увидите что-то вроде host1.nyc3.example.com, замените эти данные на FQDN вашего сервера. Аналогичным образом, если вы увидите host1_private_IP, замените эти данные на частный IP-адрес вашего сервера.

      На обоих DNS-серверах, ns1 и ns2, обновите кэш пакета apt с помощью следующей команды:

      Теперь можно переходить к установке BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Настройка режима IPv4 для Bind

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

      • sudo nano /etc/default/bind9

      Добавьте “-4” в конец параметра OPTIONS. Результат будет выглядеть следующим образом:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Сохраните файл и закройте его после завершения.

      Перезапустите BIND для вступления изменений в силу:

      • sudo systemctl restart bind9

      Теперь, после установки BIND, давайте настроим основной DNS-сервер.

      Настройка основного DNS-сервера

      Конфигурация BIND состоит из множества файлов, которые включены в основной файл конфигурации, named.conf. Эти имена файлов начинаются с named, потому что это имя процесса, который запускает BIND (сокращение от “domain name daemon”). Мы начнем с настройки файла параметров.

      Настройка файла параметров

      На сервере ns1 откройте файл named.conf.options для редактирования:

      • sudo nano /etc/bind/named.conf.options

      Над существующим блоком options создайте новый блок ACL (список контроля доступа) под названием “trusted”. Именно здесь мы создадим список клиентов, для которых мы будем разрешать рекурсивные DNS-запросы (т. е. запросы от ваших серверов, находящихся в том же центре обработки данных, что и ns1). С помощью нашего примера частных IP-адресов мы добавим ns1, ns2, host1 и host2 в наш список надежных клиентов:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Теперь, когда у нас есть список доверенных DNS-клиентов, нам нужно отредактировать блок options. В настоящее время начало блока выглядит следующим образом:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Под директивой directory добавьте выделенные цветом строки конфигурации (и замените в соответствующем IP-адресе ns1), чтобы результат выглядел примерно следующим образом:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      После завершения редактирования сохраните и закройте файл named.conf.options. Согласно конфигурация выше, только ваши собственные серверы (т. е. доверенные) смогут запрашивать у вашего DNS-сервера внешние домены.

      Далее мы настроим локальный файл, чтобы задать ваши DNS-зоны.

      Настройка локального файла

      На сервере ns1 откройте файл named.conf.local для редактирования:

      • sudo nano /etc/bind/named.conf.local

      Файл должен содержать только несколько комментариев. Здесь мы зададим наши зоны. DNS-зоны определяют конкретную область для управления и определения записей DNS. Поскольку наши домены будут находиться в субдомене nyc3.example.com, мы будем использовать его в качестве зоны прямого просмотра. Поскольку частные IP-адреса нашего сервера находятся в пространстве IP-адресов 10.128.0.0/16, мы создадим зону обратного просмотра, чтобы мы могли определять обратный просмотр в этом диапазоне.

      Добавьте зону прямого просмотра со следующими строками, заменив имя зоны на собственное, и закрытый IP-адрес дополнительного DNS сервера в директиве allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Если, согласно нашему предположению, нашей частной подсетью является 10.128.0.0/16, добавьте зону обратного просмотра с помощью следующих строк (обратите внимание, что имя зоны обратного просмотра начинается с “128.10”, что представляет собой битное преобразование “10.128"​):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Если ваши серверы охватывают несколько частных подсетей, но находятся в одном центре обработки данных, обязательно указывайте дополнительную зону и файл зоны для каждой отдельной подсети. После добавления всех необходимых зон сохраните и закройте файл named.conf.local.

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

      Создание файла для зоны прямого просмотра

      Файл зоны прямого просмотра — это место, где мы будем определять DNS-записи для прямого просмотра DNS. Т. е., когда DNS получает запрос имени, например, "host1.nyc3.example.com”, будет выполняться поиск в файле зоны прямого просмотра для получения соответствующего частного IP-адреса для host1.

      Давайте создадим директорию, в которой будут находиться наши файлы зоны. Согласно конфигурации named.conf.local, это должна быть директория /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      При создании нашего файла зоны для прямого просмотра мы будем опираться в качестве примера на файл зоны db.local. Скопируйте его в надлежащее место с помощью следующих команд:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

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

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Первоначально он будет выглядеть примерно следующим образом:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Во-первых, вам необходимо отредактировать запись SOA. Замените первую запись “localhost” на полное доменное имя (FQDN) ns1, а затем замените “root.localhost” на “admin.nyc3.example.com”. При каждом изменении файла зоны вам нужно будет увеличивать значение serial, прежде чем перезапускать процесс named. Мы увеличим значение до “3”. Теперь файл должен выглядеть примерно следующим образом:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Далее удалите три записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

      В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Теперь добавьте записи A для ваших хостов, которые принадлежат к этой зоне. Это может быть любой сервер, имя которого будет заканчиваться на “.nyc3.example.com” (замените имена и частные IP-адреса). Используя приведенные в качестве примера имена и частные IP-адреса, мы добавим записи A для ns1, ns2, host1 и host2 примерно таким образом:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Сохраните и закройте файл db.nyc3.example.com.

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

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Теперь пришло время перейти к файлу (файлам) зоны для обратного просмотра.

      Создание файла (файлов) зоны для обратного просмотра

      Файлы зоны для обратного просмотра служат местом, где мы будем определять PTR записей DNS для обратного просмотра DNS. Т. е., когда DNS получает запрос для IP-адреса, например, “10.128.100.101”, она будет выполнять поиск по файлу (файлам) зоны для обратного просмотра, чтобы получить соответствующее полное доменное имя, в нашем случае это “host1.nyc3.example.com”.

      В ns1 для каждой зоны обратного просмотра, заданной в файле named.conf.local, необходимо создать файл зоны для обратного просмотра. При создании нашего файла (или файлов) зоны для обратного просмотра мы будем опираться в качестве примера на файл зоны db.local. Скопируйте его в надлежащее место с помощью следующих команд (замените имя файла назначения, чтобы оно соответствовало определению вашей зоны для обратного просмотра):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Отредактируйте файл зоны для обратного просмотра, который соответствует зоне(-ам), определенной(-ым) в named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Первоначально он будет выглядеть примерно следующим образом:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      Как и в случае с файлом зоны для прямого просмотра, вам нужно изменить запись SOA и увеличить значение serial. Он должен выглядеть следующим образом:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Теперь удалите две записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

      В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Затем добавьте записи PTR для всех ваших серверов, чей IP-адрес соответствует подсети файла зоны, который вы редактируете. В нашем примере это будут все наши хосты, поскольку все они находятся в подсети 10.128.0.0/16. Обратите внимание, что первый столбец включает два последних байта частных IP-адресов ваших серверов в обратном порядке. Обязательно замените имена и частные IP-адреса согласно данным ваших серверов:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

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

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

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Мы завершили редактирование наших файлов, и теперь мы можем проверить наши файлы на ошибки.

      Проверка синтаксиса конфигурации BIND

      Запустите следующую команду для проверки синтаксиса файлов named.conf*:

      Если в ваших именованных файлах конфигурации нет ошибок в синтаксисе, вы должны будете вернуться в командную строку без каких-либо сообщений об ошибках. При обнаружении проблем с файлами конфигурации вы должны будете просмотреть сообщение об ошибке и раздел «Настройка основного DNS сервера», а затем снова воспользоваться командой named-checkconf.

      Команда named-checkzone может использоваться для проверки корректности ваших файлов зоны. Первый аргумент команды указывает имя зоны, а второй аргумент определяет соответствующий файл зоны, оба из которых определены в named.conf.local​​​.

      Например, чтобы проверить конфигурацию зоны для прямого просмотра “nyc3.example.com”, запустите следующую команду (измените на ваши имена зоны для прямого просмотра и файла):

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      А чтобы проверить конфигурацию зоны для обратного просмотра “128.10.in-addr.arpa”, запустите следующую команду (замените на данные, соответствующие вашей зоне для обратного просмотра и файлу):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

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

      Перезапуск BIND

      Перезапустите BIND:

      • sudo systemctl restart bind9

      Если у вас есть настроенный брандмауэр UFW, откройте доступ к BIND с помощью следующей команды:

      Теперь ваш основной DNS-сервер настроен и может отвечать на запросы DNS. Давайте перейдем к созданию дополнительного DNS-сервера.

      Настройка дополнительного DNS-сервера

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

      На сервере ns2 отредактируйте файл named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      В верхней части файла добавьте ACL с частными IP-адресами всех ваших доверенных серверов:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Под директивой directory добавьте следующие строки:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Сохраните и закройте файл named.conf.options. Этот файл должен выглядеть так же, как файл named.conf.options сервера ns1, за исключением того, что его необходимо настроить на прослушивание частного IP-адреса ns2.

      Теперь необходимо отредактировать файл named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Определите slave-зоны, соответствующие master-зонам основного DNS-сервера. Обратите внимание, что в качестве типа используется slave, в файле отсутствует путь, и существует директива masters, которая должна быть настроена на частный IP-адрес основного DNS-сервера. Если вы определили несколько зон для обратного просмотра на основном DNS-сервере, обязательно проверьте, что все они были добавлены на этом этапе:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

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

      Запустите следующую команду для проверки валидности ваших файлов конфигурации:

      После выполнения проверки перезапустите BIND:

      • sudo systemctl restart bind9

      Разрешите подключение DNS к серверу, внеся изменения в правила брандмауэра UFW:

      Теперь у вас есть основной и дополнительный DNS-серверы для имени частной сети и преобразования IP-адреса. Теперь вам нужно настроить ваши клиентские серверы, чтобы они могли использовать ваши частные DNS-серверы.

      Настройка DNS-клиентов

      Прежде чем все ваши серверы в доверенном ACL смогут отправлять запросы на ваши DNS-серверы, вы должны настроить для каждого из них использование ns1 и ns2 в качестве сервера имен. Этот процесс варьируется в зависимости от операционной системы, но для большинства дистрибутивов Linux он подразумевает добавление ваших серверов доменных имен в файл /etc/resolv.conf.

      Клиенты Ubuntu 18.04

      На Ubuntu 18.04 настройка сетевого взаимодействия выполняется с помощью Netplan, абстракции, которая позволяет вам записывать стандартную конфигурацию сети и применять ее к несовместимому сетевому ПО, отвечающему за бекэнд. Для настройки DNS нам потребуется записать файл конфигурации Netplan.

      Во-первых, найдите устройство, связанное с вашей частной сетью, отправив частной подсети команду ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      В этом примере используется частный интерфейс eth1.

      Далее необходимо создать новый файл в /etc/netplan с именем 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Вставьте в файл следующее содержимое. Вам потребуется изменить интерфейс частной сети, адреса ваших DNS-серверов ns1 и ns2, а также зону DNS:

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

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Сохраните файл и закройте его после завершения.

      Затем вы должны сообщить Netplan о необходимости использования нового файла конфигурации с помощью команды netplan try. При наличии проблем, которые приводят к потере подключения к сети, Netplan будет автоматически перезапускать изменения по истечении определенного периода времени:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Если счетчик в нижней части обновляется корректно, это значит, что новой конфигурации удалось по крайней мере не повредить ваше соединение SSH. Нажмите ENTER, чтобы принять изменения в конфигурации.

      Теперь проверьте DNS-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:

      • sudo systemd-resolve --status

      Прокрутите вниз, пока не увидите раздел для вашего интерфейса частной сети. Вы должны увидеть частные IP-адреса ваших DNS-серверов, которые будут перечислены в первую очередь, а за ними идут резервные значения. Ваш домен должен находиться в строке DNS Domain:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Ваш клиент должен быть настроен на использование ваших внутренних DNS-серверов.

      Клиенты Ubuntu 16.04 и Debian

      В серверах Ubuntu 16.04 и Debian вы можете изменить файл /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      Внутри найдите строку dns-nameservers и добавьте ваши серверы доменных имен в начало списка, который уже добавлен в файл. Под этой строкой добавьте опцию dns-search, указывающую на базовый домен вашей инфраструктуры. В нашем случае это будет “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Сохраните файл и закройте его после завершения.

      Перезапустите ваши сетевые службы, применив изменения с помощью следующих команд. Убедитесь, что вы заменили eth0 на имя вашего сетевого интерфейса:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

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

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

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

      Вы должны увидеть ваши серверы доменных имен в файле /etc/resolv.conf, а также ваш домен поиска:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Ваш клиент настроен для использования ваших DNS-серверов.

      Клиенты CentOS

      В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg-eth0. Возможно, вам придется заменить eth0 на имя вашего основного сетевого интерфейса:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Найдите опции DNS1 и DNS2 и задайте для них частные IP-адреса ваших основного и дополнительного серверов доменных имен. Добавьте параметр DOMAIN, используя базовый домен вашей инфраструктуры. В этом руководстве это будет “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Сохраните файл и закройте его после завершения.

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

      • sudo systemctl restart network

      Команда может зависнуть на несколько секунд, но через короткое время вы должны вернуться в командную строку.

      Убедитесь, что изменения вступили в силу, введя следующую команду:

      Вы должны увидеть ваши серверы доменных имен и домена поиска в списке:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Ваш клиент теперь может подключиться и использовать ваши DNS-серверы.

      Тестирование клиентов

      Используйте nslookup для проверки того, могут ли ваши клиенты отправлять запросы вашим серверам доменных имен. У вас должна быть возможность сделать это для всех клиентов, которые были настроены и находятся в доверенном ACL.

      Для клиентов CentOS вам может потребоваться установка утилиты с помощью следующей команды:

      • sudo yum install bind-utils

      Мы можем начать выполнять прямой просмотр.

      Прямой просмотр

      Например, мы можем выполнить прямой просмотр для получения IP-адреса host1.nyc3.example.com с помощью следующей команды:

      Запрос “host1” расширяется до “host1.nyc3.example.com”, потому что опция search задана для вашего частного субдомена, а запросы DNS будут пытаться просмотреть этот субдомен перед поиском по всему хосту. Результат описанной выше команды будет выглядеть следующим образом:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      Теперь мы можем проверить обратный просмотр.

      Обратный просмотр

      Чтобы протестировать обратный просмотр, отправьте DNS-серверу запрос на частный IP-адрес host1:

      Результат будет выглядеть следующим образом:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Если все имена и IP-адреса будут передавать правильные значения, это означает, что ваши файлы зоны настроены надлежащим образом. Если вы получите неожиданные значения, обязательно проверьте файлы зоны на вашем основном DNS-сервере (например, db.nyc3.example.com и db.10.128).

      Поздравляем! Ваши внутренние DNS-серверы настроены надлежащим образом! Теперь мы перейдем к сохранению записей зоны.

      Сохранение DNS-записей

      Теперь, когда у вас есть работающий внутренний DNS-сервер, вам нужно хранить ваши записи DNS, чтобы они точно отражали среду сервера.

      Добавление хоста в DNS

      При добавлении хоста в вашу среду (в одном центре обработки данных) вам нужно добавить его в DNS. Здесь представлен список шагов, которые вам нужно предпринять:

      Основной сервер доменных имен

      • Файл зоны для прямого просмотра: добавьте запись A для нового хоста, увеличив значение “Serial”
      • Файл зоны для обратного просмотра: добавьте запись PTR для нового хоста, увеличив значение “Serial”
      • Добавьте частный IP-адрес вашего нового хоста в доверенный ACL (named.conf.options)

      Протестируйте ваши файлы конфигурации:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Затем перезагрузите BIND:

      • sudo systemctl reload bind9

      Ваш основной сервер должен быть настроен для использования нового хоста.

      Дополнительный сервер доменных имен

      • Добавьте частный IP-адрес вашего нового хоста в доверенный ACL (named.conf.options)

      Проверьте синтаксис конфигурации:

      Затем перезагрузите BIND:

      • sudo systemctl reload bind9

      Ваш вторичный сервер теперь будет принимать подключения с нового хоста.

      Настройка нового хоста для использования вашей DNS

      • Настройте /etc/resolv.conf для использования ваших DNS-серверов
      • Выполните проверку с помощью nslookup

      Удаление хоста из DNS

      Если вы удалите хост из вашей среды или захотите просто убрать его из DNS, просто удалите все данные, которые были добавлены при добавлении сервера в DNS (т. е. выполните описанные выше шаги в обратно порядке).

      Заключение

      Теперь вы можете обращаться к интерфейсам серверов вашей частной сети по имени, а не по IP-адресу. Это упрощает настройку служб и приложений, поскольку вам больше не нужно запоминать частные IP-адреса, а файлы будет легче читать и понимать. Кроме того, теперь вы можете изменять свои конфигурации для работы с новыми серверами в одном месте, на вашем основном DNS-сервере, вместо того чтобы редактировать целых набор самых разных файлов.

      Когда ваш внутренний DNS-сервер был настроен, а файлы конфигурации используют частные FQDN для указания сетевых подключений, *критически *важно, чтобы ваши DNS-сервера обслуживались надлежащим образом. Если оба сервера окажутся недоступны, ваши службы и приложения, которые опираются на них при работе, не смогут нормально функционировать. Именно поэтому рекомендуется настроить для вашей DNS минимум один дополнительный сервер и сохранять рабочиие резервные копии всех серверов.



      Source link

      Настройка Nginx для использования в качестве веб-сервера и обратного прокси-сервера для Apache в One Ubuntu 18.04 Server


      Автор выбрал фонд Electronic Frontier Foundation для получения пожертвований в рамках программы Write for DOnations.

      Введение

      Apache и Nginx — два популярных веб-сервера с открытым исходным кодом, часто используемые с PHP. Одновременный запуск обоих серверов на одной виртуальной машине может быть полезным в ситуации с хостингом нескольких сайтов с разными требованиями. Обычно для запуска двух веб-серверов на одной системе используются разные IP-адреса или разные номера портов.

      Серверы, имеющие адреса IPv4 и IPv6, можно настроить для обслуживания сайтов Apache через один протокол и сайтов Nginx через другой протокол, однако это не самый практичный вариант, поскольку еще не все провайдеры поддерживают протокол IPv6. Другое решение заключается в использовании разных номеров портов (напрмер, 81 или 8080) для второго веб-серверна, однако публикация URL-адресов с номерами портов (в формате http://example.com:81) не всегда является разумным или идеальным решением.

      В этом руководстве вы настроите Nginx как веб-сервер и обратный прокси-сервер для Apache — все на одном сервере.

      В зависимости от веб-приложения для обеспечения осведомленности Apache о присутствии обратного прокси-сервера могут потребоваться изменения кода, особенно если настроены сайты SSL. Чтобы избежать этого, нужно установить модуль Apache под названием mod_rpaf, который перезаписывает определенные переменные среды так, что все выглядит, как если бы Apache напрямую обрабатывал запросы веб-клиентов.

      Мы разместим четыре доменных имени на одном сервере. Два из них будут обслуживаться Nginx: example.com (виртуальный хост по умолчанию) и sample.org. Остальные два, foobar.net и test.io, будут обслуживаться Apache. Также мы настроим Apache для обслуживания приложений PHP с использованием PHP-FPM, что обеспечивает более высокую производительность по сравнению с mod_php.

      Предварительные требования

      Для прохождения данного обучающего руководства вам потребуется следующее:

      • Новый сервер Ubuntu 18.04, настроенный в соответствии с указаниями документа «Начальная настройка сервера с Ubuntu 18.04», с пользователем sudo non-root и брандмауэром.
      • Четыре полностью квалифицированных доменных имени, настроенных на указание на IP-адрес вашего сервера. В разделе «Шаг 3. Настройка имени хоста с DigitalOcean» показано, как можно это сделать. Если вы размещаете DNS ваших доменов в других местах, нужно создать соответствующие записи уровня A именно там.

      Шаг 1 — Установка Apache и PHP-FPM

      Начнем с установки Apache и PHP-FPM.

      Помимо Apache и PHP-FPM мы также установим модуль PHP FastCGI Apache, libapache2-mod-fastcgi, для поддержки веб-приложений FastCGI.

      Вначале обновите свой список пакетов и убедитесь, что у вас установлены последние версии пакетов.

      Затем выполните установку пакетов Apache и PHP-FPM:

      • sudo apt install apache2 php-fpm

      Модуль FastCGI Apache недоступен в хранилище Ubuntu, и поэтому вам следует загрузить его с kernel.org и установить с помощью команды dpkg.

      • wget https://mirrors.edge.kernel.org/ubuntu/pool/multiverse/liba/libapache-mod-fastcgi/libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb
      • sudo dpkg -i libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb

      Далее изменим конфигурацию Apache по умолчанию для использования PHP-FPM.

      Шаг 2 — Настройка Apache и PHP-FPM

      На этом шаге мы изменим номер порта Apache на 8080 и настроим его для работы с PHP-FPM с использованием модуля mod_fastcgi. Переименуйте файл конфигурации Apache ports.conf:

      • sudo mv /etc/apache2/ports.conf /etc/apache2/ports.conf.default

      Создайте новый файл ports.conf и установите в нем порт 8080:

      • echo "Listen 8080" | sudo tee /etc/apache2/ports.conf

      Примечание. Веб-серверы обычно настраиваются на прослушивание адреса 127.0.0.1:8080 при настройке в качестве обратного прокси-сервера, однако при этом для переменной среды PHP SERVER_ADDR будет установлено значение циклического IP-адреса, а не публичного IP-адреса сервера. Наша цель — настроить сервер Apache так, чтобы сайты не видели обратный прокси-сервер перед ним. Поэтому мы настроим его для прослушивания порта 8080 на всех IP-адресах.

      Далее мы создадим файл виртуального хоста для Apache. Директива <VirtualHost> этого файла будет установлена для обслуживания только сайтов на порту 8080.

      Отключите виртуальный хост по умолчанию:

      • sudo a2dissite 000-default

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

      • sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/001-default.conf

      Откройте новый файл конфигурации:

      • sudo nano /etc/apache2/sites-available/001-default.conf

      Измените порт прослушивания на 8080:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:8080>
          ServerAdmin webmaster@localhost
          DocumentRoot /var/www/html
          ErrorLog ${APACHE_LOG_DIR}/error.log
          CustomLog ${APACHE_LOG_DIR}/access.log combined
      </VirtualHost>
      

      Сохраните файл и активируйте новый файл конфигурации:

      • sudo a2ensite 001-default

      Затем перезагрузите Apache:

      • sudo systemctl reload apache2

      Убедитесь, что Apache прослушивает порт 8080:

      Результат должен выглядеть как в следующем примере, где apache2 прослушивает порт 8080:

      Output

      Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1086/sshd tcp6 0 0 :::8080 :::* LISTEN 4678/apache2 tcp6 0 0 :::22 :::* LISTEN 1086/sshd

      Убедившись, что Apache прослушивает правильный порт, вы можете настроить поддержку PHP и FastCGI.

      Шаг 3 — Настройка Apache для использования mod_fastcgi

      По умолчанию Apache обслуживает страницы PHP с помощью модуля mod_php, однако для работы с PHP-FPM ему требуется дополнительная настройка.

      Примечание. Если вы пытаетесь использовать это обучающее руководство в существующей системе LAMP с mod_php, вначале выполните отключение с помощью команды sudo a2dismod php7.2.

      Мы добавим блок конфигурации для mod_fastcgi, зависящий от mod_action. По умолчанию mod_action отключен, и предварительно его нужно включить:

      Переименуйте существующий файл конфигурации FastCGI:

      • sudo mv /etc/apache2/mods-enabled/fastcgi.conf /etc/apache2/mods-enabled/fastcgi.conf.default

      Создайте новый файл конфигурации:

      • sudo nano /etc/apache2/mods-enabled/fastcgi.conf

      Добавьте в файл следующие директивы для передачи запросов файлов .php в сокет PHP-FPM UNIX:

      /etc/apache2/mods-enabled/fastcgi.conf

      <IfModule mod_fastcgi.c>
        AddHandler fastcgi-script .fcgi
        FastCgiIpcDir /var/lib/apache2/fastcgi
        AddType application/x-httpd-fastphp .php
        Action application/x-httpd-fastphp /php-fcgi
        Alias /php-fcgi /usr/lib/cgi-bin/php-fcgi
        FastCgiExternalServer /usr/lib/cgi-bin/php-fcgi -socket /run/php/php7.2-fpm.sock -pass-header Authorization
        <Directory /usr/lib/cgi-bin>
          Require all granted
        </Directory>
      </IfModule>
      

      Сохраните изменения и проведите тест конфигурации:

      Если отображается Syntax OK, перезагрузите Apache:

      • sudo systemctl reload apache2

      Если отображается предупреждение Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message., его можно игнорировать. Мы настроим имена серверов позднее.

      Теперь убедимся, что мы можем обслуживать PHP из Apache.

      Шаг 4 — Проверка функционала PHP

      Чтобы убедиться, что PHP работает, мы создадим файл phpinfo() и получим к нему доступ к через браузер.

      Создайте файл /var/www/html/info.php, содержащий вызов функции phpinfo:

      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php

      Чтобы просмотреть файл в браузере, откройте адрес http://your_server_ip:8080/info.php. На странице появится перечень параметров конфигурации, используемых PHP. Результат будет выглядеть примерно так:

      phpinfo Server API

      phpinfo PHP Variables

      Убедитесь, что в Server API вверху страницы указано значение FPM/FastCGI. Раздел «Переменные PHP» в нижней трети страницы покажет, что параметр SERVER_SOFTWARE имеет значение Apache на Ubuntu. Это подтверждает, что модуль mod_fastcgi активен, и что Apache использует PHP-FPM для обработки файлов PHP.

      Шаг 5 — Создание виртуальных хостов для Apache

      Давайте создадим файлы виртуальных хостов Apache для доменов foobar.net и test.io. Для этого мы вначале создадим корневые каталоги документов document root для обоих сайтов и разместим в эти каталоги файлы, чтобы можно было легко протестировать нашу конфигурацию.

      Вначале создайте корневые каталоги документа:

      • sudo mkdir -v /var/www/foobar.net /var/www/test.io

      Затем создайте файл index для каждого сайта:

      • echo "<h1 style='color: green;'>Foo Bar</h1>" | sudo tee /var/www/foobar.net/index.html
      • echo "<h1 style='color: red;'>Test IO</h1>" | sudo tee /var/www/test.io/index.html

      Далее создайте файл phpinfo() для каждого сайта, чтобы мы могли протестировать правильность конфигурации PHP.

      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/foobar.net/info.php
      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/test.io/info.php

      Теперь создайте файл виртуального хоста для домена foobar.net:

      • sudo nano /etc/apache2/sites-available/foobar.net.conf

      Добавьте в файл следующий код для определения хоста:

      /etc/apache2/sites-available/foobar.net.conf

          <VirtualHost *:8080>
              ServerName foobar.net
              ServerAlias www.foobar.net
              DocumentRoot /var/www/foobar.net
              <Directory /var/www/foobar.net>
                  AllowOverride All
              </Directory>
          </VirtualHost>
      

      Строка AllowOverride All активирует поддержку .htaccess.

      Это только базовые указания. Полное руководство по по настройке виртуальных хостов в Apache можно найти в документе «Настройка виртуальных хостов Apache в Ubuntu 16.04».

      Сохраните и закройте файл. Затем создайте аналогичную конфигурацию для test.io. Сначала создайте файл:

      • sudo nano /etc/apache2/sites-available/test.io.conf

      Затем добавьте в файл конфигурацию:

      /etc/apache2/sites-available/test.io.conf

          <VirtualHost *:8080>
              ServerName test.io
              ServerAlias www.test.io
              DocumentRoot /var/www/test.io
              <Directory /var/www/test.io>
                  AllowOverride All
              </Directory>
          </VirtualHost>
      

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

      Теперь, когда вы создали оба виртуальных хоста Apache, разрешите сайтам использовать команду a2ensite. Это создаст символическую связь с файлом виртуального хоста в каталоге sites-enabled:

      • sudo a2ensite foobar.net
      • sudo a2ensite test.io

      Снова проверьте Apache на наличие ошибок конфигурации:

      При отсутствии ошибок появится сообщение Syntax OK. Если появится любое другое сообщение, проверьте конфигурацию и повторите попытку.

      Когда в конфигурации не останется ошибок, перезагрузите Apache, чтобы применить изменения:

      • sudo systemctl reload apache2

      Чтобы подтвердить работу сайтов, откройте в браузере адреса http://foobar.net:8080 и http://test.io:8080 и убедитесь, что для каждого из сайтов отображается файл index.html.

      Вы увидите следующие результаты:

      страница индекса foobar.net

      страница индекса test.io

      Также попробуйте получить доступ к файлам info.php files каждого сайта, чтобы убедиться в работе PHP. Откройте адреса http://foobar.net:8080/info.php и http://test.io:8080/info.php в браузере.

      Для каждого сайта вы увидите такой же перечень настроек PHP, что и на шаге 4.

      Мы разместили два сайта на сервере Apache на порту 8080. Теперь давайте настроим Nginx.

      Шаг 6 — Установка и настройка Nginx

      На этом шаге мы выполним установку Nginx и настроим домены example.com и sample.org как виртуальные хосты Nginx. Полное руководство по настройке виртуальных хостов в Nginx можно найти в документе «Настройка блоков сервера Nginx (виртуальных хостов) в Ubuntu 18.04».

      Установите Nginx с помощью диспетчера пакетов:

      Затем удалите соединение symlink по умолчанию виртуального хоста, поскольку мы больше не будем его использовать:

      • sudo rm /etc/nginx/sites-enabled/default

      Позднее мы создадим собственный сайт по умолчанию (example.com).

      Теперь мы создадим виртуальные хосты для Nginx, используя ту же процедуру, что использовалась для Apache. Вначале необходимо создать корневые каталоги документов для обоих сайтов:

      • sudo mkdir -v /usr/share/nginx/example.com /usr/share/nginx/sample.org

      Мы будем хранить сайты Nginx в каталоге /usr/share/nginx, где Nginx требуется хранить их по умолчанию. Вы можете поместить их в каталог /var/www/html с сайтами Apache, но разделение поможет привязать сайты к Nginx.

      Как и в случае с виртуальными хостами Apache, после завершения настройки следует создать файлы index и phpinfo() для тестирования:

      • echo "<h1 style='color: green;'>Example.com</h1>" | sudo tee /usr/share/nginx/example.com/index.html
      • echo "<h1 style='color: red;'>Sample.org</h1>" | sudo tee /usr/share/nginx/sample.org/index.html
      • echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/example.com/info.php
      • echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/sample.org/info.php

      Теперь создайте файл виртуального хоста для домена example.com:

      • sudo nano /etc/nginx/sites-available/example.com

      Nginx вызывает области серверных блоков файла конфигурации server {. . .}. Создайте серверный блок для главного виртуального хоста, example.com. Директива default_server configuration делает его виртуальным хостом по умолчанию для обработки запросов HTTP, не соответствующих никакому другому виртуальному хосту.

      /etc/nginx/sites-available/example.com

      server {
          listen 80 default_server;
      
          root /usr/share/nginx/example.com;
          index index.php index.html index.htm;
      
          server_name example.com www.example.com;
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              fastcgi_pass unix:/run/php/php7.2-fpm.sock;
              include snippets/fastcgi-php.conf;
          }
      }
      

      Сохраните и закройте файл. Создайте файл виртуального хоста для второго домена Nginx, sample.org:

      • sudo nano etc/nginx/sites-available/sample.org

      Добавьте в файл следующее:

      /etc/nginx/sites-available/sample.org

      server {
          root /usr/share/nginx/sample.org;
          index index.php index.html index.htm;
      
          server_name sample.org www.sample.org;
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              fastcgi_pass unix:/run/php/php7.2-fpm.sock;
              include snippets/fastcgi-php.conf;
          }
      }
      

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

      Затем активируйте оба сайта, создав символические ссылки на каталог sites-enabled:

      • sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
      • sudo ln -s /etc/nginx/sites-available/sample.org /etc/nginx/sites-enabled/sample.org

      Протестируйте конфигурацию Nginx и убедитесь в отсутствии проблем с конфигурацией:

      При обнаружении ошибок перезагрузите Nginx:

      • sudo systemctl reload nginx

      Получите доступ к файлу phpinfo() виртуальных хостов Nginx через браузер по адресам http://example.com/info.php и http://sample.org/info.php. Снова изучите разделы PHP Variables.

      Переменные Nginx PHP Variables

      [SERVER_SOFTWARE] должен иметь значение nginx, указывая, что файлы обслуживались Nginx напрямую. [DOCUMENT_ROOT] должен указывать на каталог, ранее созданный на этом шаге для каждого из сайтов Nginx.

      К настоящему моменту мы установили Nginx и создали два виртуальных хоста. Далее мы настроим Nginx на запросы прокси-сервера, предназначенные для доменов Apache.

      Шаг 7 — Настройка Nginx для виртуальных хостов Apache

      Создадим дополнительный виртуальный хост Nginx с несколькими именами доменов в директивах server_name. Запросы этих доменных имен будут перенаправляться через прокси-сервер в Apache.

      Создайте новый файл виртуального хоста Nginx для перенаправления запросов в Apache:

      • sudo nano /etc/nginx/sites-available/apache

      Добавьте следующий блок кода, указывающий имена доменов виртуального хоста Apache и перенаправляющий их запросы в Apache. Обязательно используйте публичный IP-адрес в proxy_pass:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name foobar.net www.foobar.net test.io www.test.io;
      
          location / {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      }
      

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

      • sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache

      Протестируйте конфигурацию и убедитесь в отсутствии ошибок:

      Если ошибок нет, перезагрузите Nginx:

      • sudo systemctl reload nginx

      Откройте в браузере URL-адрес http://foobar.net/info.php. Перейдите в раздел PHP Variables и проверьте отображаемые значения.

      phpinfo для Apache через Nginx

      Переменные SERVER_SOFTWARE и DOCUMENT_ROOT подтверждают, что запрос был обработан Apache. Переменные HTTP_X_REAL_IP и HTTP_X_FORWARDED_FOR были добавлены Nginx и должны показывать публичный IP-адрес компьютера, используемого для доступа к URL-адресу.

      Мы успешно настроили Nginx для перенаправления запросов определенных доменов в Apache через прокси-сервер. Теперь настроим Apache для установки переменной REMOTE_ADDR, как если бы эти запросы обрабатывались напрямую.

      Шаг 8 — Установка и настройка mod_rpaf

      На этом шаге вы установите модуль Apache под названием mod_rpaf, который перезаписывает значения REMOTE_ADDR, HTTPS и HTTP_PORT на базе значений, предоставленных обратным прокси-сервером. Без этого модуля для некоторых приложений PHP потребуется изменение кода для бесшовной работы из-за прокси-сервера. Этот модуль представлен в хранилище Ubuntu как libapache2-mod-rpaf, однако он устарел и не поддерживает некоторые директивы конфигурации. Поэтому мы установим его из источника.

      Установите пакеты, необходимые для построения модуля:

      • sudo apt install unzip build-essential apache2-dev

      Загрузите последний стабильный выпуск из GitHub:

      • wget https://github.com/gnif/mod_rpaf/archive/stable.zip

      Выполните извлечение загруженного файла:

      Перейдите в новый каталог, содержащий файлы:

      Скомпилируйте и установите модуль:

      Затем создайте в каталоге mods-available файл, который будет загружать модуль rpaf,

      • sudo nano /etc/apache2/mods-available/rpaf.load

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

      /etc/apache2/mods-available/rpaf.load

      LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so
      

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

      Создайте в этом каталоге другой файл с именем rpaf.conf, который будет содержать директивы конфигурации для mod_rpaf:

      • sudo nano /etc/apache2/mods-available/rpaf.conf

      Добавьте следующий блок кода для настройки mod_rpaf и обязательно укажите IP-адрес своего сервера:

      /etc/apache2/mods-available/rpaf.conf

          <IfModule mod_rpaf.c>
              RPAF_Enable             On
              RPAF_Header             X-Real-Ip
              RPAF_ProxyIPs           your_server_ip
              RPAF_SetHostName        On
              RPAF_SetHTTPS           On
              RPAF_SetPort            On
          </IfModule>
      

      Здесь приведено краткое описание каждой директивы. Дополнительную информацию можно найти в файле README по модулю mod_rpaf.

      • RPAF_Header — заголовок, используемый для реального IP-адреса клиента.
      • RPAF_ProxyIPs — IP-адрес прокси-сервера для корректировки запросов HTTP.
      • RPAF_SetHostName — обновляет имя vhost так, чтобы работали параметры ServerName и ServerAlias.
      • RPAF_SetHTTPS — задает переменную среды HTTPS на основе значения, содержащегося в X-Forwarded-Proto.
      • RPAF_SetPort — задает переменную среды SERVER_PORT. Полезна для использования, когда сервер Apache находится за прокси-сервером SSL.

      Сохраните rpaf.conf и активируйте модуль:

      При этом создаются символические ссылки файлов rpaf.load и rpaf.conf в каталоге mods-enabled. Теперь протестируем конфигурацию:

      Если ошибок нет, перезагрузите Apache:

      • sudo systemctl reload apache2

      Откройте в браузере страницы phpinfo() по адресам http://foobar.net/info.php и http://test.io/info.php и проверьте раздел PHP Variables. Переменная REMOTE_ADDR также будет использоваться для публичного IP-адрса вашего локального компьютера.

      Теперь настроим шифрование TLS/SSL для каждого сайта.

      Шаг 9 — Настройка сайтов HTTPS с Let’s Encrypt (опционально)

      На этом шаге мы настроим сертификаты TLS/SSL для обоих доменов, размещенных в Apache. Мы получим сертификаты посредством Let’s Encrypt. Nginx поддерживает конечные узлы SSL, и поэтому мы можем настроить SSL без изменения файлов конфигурации Apache. Модуль mod_rpaf обеспечивает установку в Apache переменных среды, необходимых для бесшовной работы приложений за обратным прокси-сервером SSL.

      Вначале мы разделим блоки server {...} обоих доменов так, что у каждого из них будет собственный сертификат SSL. Откройте в своем редакторе файл /etc/nginx/sites-available/apache:

      • sudo nano /etc/nginx/sites-available/apache

      Измените файл, чтобы он выглядел следующим образом, сайты foobar.net и test.io должны находиться в собственных server блоках:

      /etc/nginx/sites-available/apache

          server {
              listen 80;
              server_name foobar.net www.foobar.net;
      
              location / {
                  proxy_pass http://your_server_ip:8080;
                  proxy_set_header Host $host;
                  proxy_set_header X-Real-IP $remote_addr;
                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                  proxy_set_header X-Forwarded-Proto $scheme;
              }
          }
          server {
              listen 80;
              server_name test.io www.test.io;
      
              location / {
                  proxy_pass http://your_server_ip:8080;
                  proxy_set_header Host $host;
                  proxy_set_header X-Real-IP $remote_addr;
                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                  proxy_set_header X-Forwarded-Proto $scheme;
              }
          }
      

      Мы используем Certbot для генерирования сертификатов TLS/SSL. Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется.

      Прежде всего, добавьте официальное хранилище Certbot:

      • sudo add-apt-repository ppa:certbot/certbot

      Нажмите ENTER в диалоге, чтобы подтвердить добавление нового хранилища. Обновите список пакетов, чтобы получить данные пакета нового хранилища:

      Установите пакет Certbot’s Nginx с apt:

      • sudo apt install python-certbot-nginx

      После установки используйте команду certbot для генерирования сертификатов для foobar.net и www.foobar.net:

      • sudo certbot --nginx -d foobar.net -d www.foobar.net

      Эта команда указывает Certbot, что нужно использовать плагин nginx, а параметр -d задает имена, для которых должен действовать сертификат.

      Если это первый запуск certbot, вам будет предложено указать адрес эл. почты и принять условия обслуживания. После этого certbot свяжется с сервером Let’s Encrypt и отправит запрос с целью подтвердить, что вы контролируете домен, для которого запрашиваете сертификат.

      Далее Certbot запросит желаемый вариант настройки HTTPS:

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

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

      Теперь выполните команду для второго домена:

      • sudo certbot --nginx -d test.io -d www.test.io

      Откройте один из доменов Apache в браузере с помощью префикса https://; откройте https://foobar.net/info.php, и вы увидите следующее:

      phpinfo ssl

      Посмотрите раздел PHP Variables. Для переменной SERVER_PORT задано значение 443 и протокол HTTPS включен, как если бы осуществлялся прямой доступ к Apache через HTTPS. При такой настройке переменных не нужно специально настраивать приложения PHP для работы за обратным прокси-сервером.

      Теперь отключим прямой доступ к Apache.

      Шаг 10 — Блокировка прямого доступа к Apache (опционально)

      Поскольку Apache прослушивает порт 8080 на публичном IP-адресе, он доступен кому угодно. Его можно заблокировать с помощью следующей команды IPtables в наборе правил брандмауэра.

      • sudo iptables -I INPUT -p tcp --dport 8080 ! -s your_server_ip -j REJECT --reject-with tcp-reset

      Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт 8080, убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт 8080. Например: http://example.com:8080

      Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables tcp-reset, сторонний наблюдатель не увидит разницы между портом 8080 и портом, где отсутствует какое-либо обслуживание.

      Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр iptables-persistent в хранилище Ubuntu. Прочитайте эту статью, чтобы узнать больше о настройке IPTables.

      Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.

      Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)

      Когда Nginx перенаправляет запросы доменов Apache через прокси-сервер, каждый запрос файла этого домена отправляется в Apache. Nginx обслуживает статические файлы, такие как изображения, JavaScript и таблицы стилей, быстрее Apache. Поэтому мы настроим файл виртуального хоста Nginx apache для прямого обслуживания статических файлов и перенаправления запросов PHP в Apache.

      Откройте в своем редакторе файл /etc/nginx/sites-available/apache:

      • sudo nano /etc/nginx/sites-available/apache

      Вам потребуется добавить два дополнительных блока location в каждый блок server, а также изменить существующие разделы location. Кроме того, вам нужно будет указать Nginx, где можно найти статические файлы для каждого сайта.

      Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name test.io www.test.io;
          root /var/www/test.io;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      }
      
      server {
          listen 80;
          server_name foobar.net www.foobar.net;
          root /var/www/foobar.net;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_ip_address:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      }
      

      Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name test.io www.test.io;
          root /var/www/test.io;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          listen 443 ssl;
          ssl_certificate /etc/letsencrypt/live/test.io/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/test.io/privkey.pem;
          include /etc/letsencrypt/options-ssl-nginx.conf;
          ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
      }
      
      server {
          listen 80;
          server_name foobar.net www.foobar.net;
          root /var/www/foobar.net;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_ip_address:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          listen 443 ssl;
          ssl_certificate /etc/letsencrypt/live/foobar.net/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/foobar.net/privkey.pem;
          include /etc/letsencrypt/options-ssl-nginx.conf;
          ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
      }
      

      Директива try_files указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение .php, запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.

      Предупреждение. Директива location ~ /.ht очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как .htaccess и .htpasswd.

      Сохраните файл и проведите тест конфигурации:

      Если тест завершается успешно, перезагрузите Nginx:

      • sudo service nginx reload

      Чтобы убедиться, что все работает, вы можете просмотреть файлы журнала Apache в каталоге /var/log/apache2 и посмотреть запросы GET для файлов info.php сайтов test.io и foobar.net. Используйте команду tail для просмотра последних нескольких строк файла и параметр -f для просмотра изменений файла:

      • sudo tail -f /var/log/apache2/other_vhosts_access.log

      Теперь откройте в браузере http://test.io/info.php и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:

      Output

      test.io:80 your_server_ip - - [01/Jul/2016:18:18:34 -0400] "GET /info.php HTTP/1.0" 200 20414 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"

      Затем откройте страницы index.html каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.

      Завершив изучение файла журнала, нажмите CTRL+C, чтобы остановить отслеживание.

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

      Заключение

      Вы настроили один сервер Ubuntu, где Nginx обслуживает сайты example.com и sample.org, а Apache обслуживает сайты foobar.net и test.io. Хотя Nginx выступает в качестве обратного прокси-сервера Apache, прокси-служба Nginx невидима, и подключение к доменам Apache выглядит так, как если бы оно напрямую обслуживалось Apache. Вы можете использовать этот метод для вывода защищенных и статичных сайтов.



      Source link

      Использование Traefik в качестве обратного прокси для контейнеров Docker в Ubuntu 18.04


      Автор выбрал Girls Who Code для получения пожертвования в рамках программы Write for DOnations.

      Введение

      Docker может эффективно запускать веб-приложения в производственном среде, но бывает так, что вам нужно запустить несколько приложений на одном хосте Docker. В этой ситуации вам нужно настроить обратный прокси, поскольку вы хотите открывать для мира только порты 80 и 443.

      Traefik — это обратный прокси с поддержкой Docker, имеющий собственную панель мониторинга. В этом обучающем модуле вы используете Traefik для перенаправления запросов двух разных контейнеров веб-приложений: контейнера WordPress и контейнера Adminer, каждый из которых взаимодействует с базой данных MySQL. Вы настроите Traefik для обслуживания соединений через HTTPS с помощью Let’s Encrypt.

      Предварительные требования

      Для выполнения этого обучающего модуля вам потребуется следующее:

      Шаг 1 — Настройка и запуск Traefik

      Проект Traefik имеет официальный образ Docker, так что мы будем использовать его для запуска Traefik в контейнере Docker.

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

      Для создания шифрованного пароля мы используем утилиту htpasswd. Вначале следует установить эту утилиту, которая входит в пакет apache2-utils:

      • sudo apt-get install apache2-utils

      Затем нужно сгенерировать пароль с помощью htpasswd. Замените secure_password паролем, который вы хотите использовать для административного пользователя Traefik:

      • htpasswd -nb admin secure_password

      Программа выдаст следующий результат:

      Output

      admin:$apr1$ruca84Hq$mbjdMZBAG.KWn7vfN/SNK/

      Используйте этот результат в файле конфигурации Traefik для настройки базовой аутентификации HTTP для проверки состояния Traefik и информационной панели мониторинга. Скопируйте всю строку результатов, чтобы ее можно было вставить.

      Для настройки сервера Traefik мы создадим новый файл конфигурации с именем traefik.toml в формате TOML. TOML — это язык конфигурации, похожий на используемый в файлах INI, но при этом стандартизированный. Этот файл позволит нам настроить сервер Traefik и различные интеграции или провайдеров, которых мы хотим использовать. В этом обучающем модуле мы будем использовать три из числа доступных провайдеров Traefik: api, docker и acme, который используется для поддержки TLS при использовании Let’s Encrypt.

      Откройте новый файл в nano или в другом предпочитаемом текстовом редакторе:

      Добавьте две точки входа с именами http и https, которые будут по умолчанию доступны всем серверным компонентам:

      traefik.toml

      defaultEntryPoints = ["http", "https"]
      

      Мы настроим точки входа http и https в следующих шагах.

      Затем настройте провайдер api, который дает доступ к интерфейсу информационной панели. Здесь вам нужно вставить результат выполнения команды htpasswd:

      traefik.toml

      ...
      [entryPoints]
        [entryPoints.dashboard]
          address = ":8080"
          [entryPoints.dashboard.auth]
            [entryPoints.dashboard.auth.basic]
              users = ["admin:your_encrypted_password"]
      
      [api]
      entrypoint="dashboard"
      

      Информационная панель — это отдельное веб-приложение, работающее в контейнере Traefik. Мы настроим информационную панель для запуска на порту 8080.

      Раздел entrypoints.dashboard настраивает способ подключения с помощью провайдера api, а раздел entrypoints.dashboard.auth.basic настраивает базовую аутентификацию HTTP для информационной панели. Используйте результат выполнения команды htpasswd для получения значения записи users. Вы можете указать дополнительные имена пользователей, отделяя их с помощью запятых.

      Мы определили первую точку входа entryPoint, но теперь нам нужно определить другие точки входа для стандартных коммуникаций HTTP и HTTPS, которые не направлены на провайдер api. В разделе entryPoints настраиваются адреса, которые могут прослушивать Traefik и контейнеры, подключенные через прокси. Добавьте в файл следующие строки под заголовком entryPoints:

      traefik.toml

      ...
        [entryPoints.http]
          address = ":80"
            [entryPoints.http.redirect]
              entryPoint = "https"
        [entryPoints.https]
          address = ":443"
            [entryPoints.https.tls]
      ...
      

      Точка входа http использует порт 80, а точка входа https использует порт 443 для TLS/SSL. Мы автоматически перенаправляем весь трафик порта 80 на точку входа https, чтобы принудительно использовать защищенные соединения для всех запросов.

      Затем добавьте этот раздел для настройки поддержки сертификата Let’s Encrypt для Traefik:

      traefik.toml

      ...
      [acme]
      email = "your_email@your_domain"
      storage = "acme.json"
      entryPoint = "https"
      onHostRule = true
        [acme.httpChallenge]
        entryPoint = "http"
      

      Этот раздел называется acme, потому что ACME — это имя протокола, используемое для связи с Let’s Encrypt для управления сертификатами. Служба Let’s Encrypt требует для регистрации действующий адрес электронной почты, и чтобы дать Traefik возможность генерировать сертификаты для наших хостов, установите для ключа email свой адрес электронной почты. Затем мы укажем, что будем сохранять получаемую от Let’s Encrypt информацию в файле JSON с именем acme.json. Ключ entryPoint должен указывать на точку входа, использующую порт 443, и в нашем случае это будет точка входа https.

      Ключ onHostRule указывает, как Traefik следует генерировать сертификаты. Мы хотим получать сертификаты сразу же после создания контейнеров с заданными именами хостов, и для этого мы используем параметр onHostRule.

      Раздел acme.httpChallenge позволяет указать, как Let’s Encrypt сможет проверять необходимость генерирования сертификата. Мы настроим его для обслуживания файла в рамках запроса через точку входа http.

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

      traefik.toml

      ...
      [docker]
      domain = "your_domain"
      watch = true
      network = "web"
      

      Провайдер docker позволяет Traefik выступать в качестве прокси для контейнеров Docker. Мы настроили провайдер на отслеживание новых контейнеров в сети web (которую мы вскоре создадим) и для предоставления доступа к ним как к субдоменам домена your_domain.

      На данный момент файл traefik.toml должен иметь следующее содержание:

      traefik.toml

      defaultEntryPoints = ["http", "https"]
      
      [entryPoints]
        [entryPoints.dashboard]
          address = ":8080"
          [entryPoints.dashboard.auth]
            [entryPoints.dashboard.auth.basic]
              users = ["admin:your_encrypted_password"]
        [entryPoints.http]
          address = ":80"
            [entryPoints.http.redirect]
              entryPoint = "https"
        [entryPoints.https]
          address = ":443"
            [entryPoints.https.tls]
      
      [api]
      entrypoint="dashboard"
      
      [acme]
      email = "your_email@your_domain"
      storage = "acme.json"
      entryPoint = "https"
      onHostRule = true
        [acme.httpChallenge]
        entryPoint = "http"
      
      [docker]
      domain = "your_domain"
      watch = true
      network = "web"
      

      Сохраните файл и выйдите из редактора. Настроив эти параметры конфигурации, мы можем запускать Traefik.

      Шаг 2 — Запуск контейнера Traefik

      Затем создайте сеть Docker, которую прокси будет использовать для связи с контейнерами. Сеть Docker необходима, чтобы мы могли использовать ее для приложений, запущенных с помощью Docker Compose. Присвоим этой сети имя web.

      • docker network create web

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

      Создайте пустой файл, где будет храниться информация Let’s Encrypt. Мы передадим ее в контейнер, чтобы Traefik мог ее использовать:

      Traefik сможет использовать этот файл, только если пользователь root внутри контейнера будет иметь уникальный доступ к этому файлу для чтения и записи. Для этого нам нужно будет заблокировать разрешения файла acme.json, чтобы права записи и чтения были только у владельца файла.

      После передачи файла в Docker владелец автоматически сменяется на пользователя root внутри контейнера.

      Затем создайте контейнер Traefik с помощью следующей команды:

      • docker run -d
      • -v /var/run/docker.sock:/var/run/docker.sock
      • -v $PWD/traefik.toml:/traefik.toml
      • -v $PWD/acme.json:/acme.json
      • -p 80:80
      • -p 443:443
      • -l traefik.frontend.rule=Host:monitor.your_domain
      • -l traefik.port=8080
      • --network web
      • --name traefik
      • traefik:1.7.2-alpine

      Это команда немного длинная, так что попробуем ее разбить.

      Мы используем флаг -d для запуска контейнера в фоновом режиме как демона. Затем мы передадим файл docker.sock в контейнер, чтобы процесс Traefik могу отслеживать изменения в контейнерах. Также мы передадим в контейнер созданные нами файл конфигурации traefik.toml и файл acme.json.

      Затем мы сопоставим порты :80 и :443 нашего хоста Docker с аналогичными портами контейнера Traefik, чтобы Traefik принимал весь трафик HTTP и HTTPS, поступающий на сервер.

      Затем мы создадим два ярлыка Docker, которые будут предписывать Traefik направлять трафик хоста monitor.your_domain на порт :8080 в контейнере Traefik, открывая доступ к информационной панели мониторинга.

      Мы зададим для контейнера сеть web и присвоим ему имя traefik.

      В заключение мы используем образ traefik:1.7.2-alpine для этого контейнера, поскольку он имеет небольшой размер.

      Команда ENTRYPOINT всегда запускается при создании контейнера из образа Docker. В данном случае команда представялет собой двоичный файл traefik в контейнере. При запуске контейнера вы можете передать для команды дополнительные аргументы, но мы настроили все параметры в файле traefik.toml.

      После запуска контейнера вы получили информационную панель, которую можете использовать для просмотра состояния ваших контейнеров. Также вы можете использовать эту информационную панель для визуализации клиентских и серверных ресурсов, зарегистрированных Traefik. Откройте панель мониторинга, введя в браузер адрес https://monitor.your_domain. Вам будет предложено ввести имя пользователя и пароль. Используйте имя пользователя admin и пароль, заданный на шаге 1.

      После входа вы увидите интерфейс, который будет выглядеть примерно так:

      Пустая информационная панель Traefik

      Сейчас на панели почти ничего нет, но вам следует это окно открытым, и вы увидите, как будет меняться его содержание при добавлении в Traefik контейнеров.

      Мы запустили прокси Traefik, настроили его для работы с Docker и подготовились к отслеживанию других контейнеров Docker. Теперь запустим контейнеры, для которых Traefik будет выступать в качестве прокси.

      Шаг 3 — Регистрация контейнеров в Traefik

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

      1. Блог, использующий официальный образ WordPress.
      2. Сервер управления базами данных, использующий официальный образ Adminer.

      Для управления этими приложениями мы будем использовать Docker Compose с файлом docker-compose.yml. Откройте файл docker-compose.yml в редакторе:

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

      docker-compose.yml

      version: "3"
      
      networks:
        web:
          external: true
        internal:
          external: false
      

      Мы будем использовать Docker Compose версии 3, потому что это последняя крупная версия формата файлов Compose.

      Чтобы у Traefik была возможность распознавать наши приложения, они должны входить в ту же сеть. Поскольку мы создали сеть вручную, мы подключим ее, указав имя сети web и задав для параметра external значение true. Затем мы определим другую сеть, чтобы мы могли подключать наши открытые контейнеры к контейнеру базы данных, доступ к которому мы не будем предоставлять через Traefik. Мы присвоим этой сети имя internal.

      Теперь мы определим наши службы, по одной за раз. Начнем с контейнера blog, который будет основан на официальном образе WordPress. Добавьте эту конфигурацию в файл:

      docker-compose.yml

      version: "3"
      ...
      
      services:
        blog:
          image: wordpress:4.9.8-apache
          environment:
            WORDPRESS_DB_PASSWORD:
          labels:
            - traefik.backend=blog
            - traefik.frontend.rule=Host:blog.your_domain
            - traefik.docker.network=web
            - traefik.port=80
          networks:
            - internal
            - web
          depends_on:
            - mysql
      

      Ключ environment позволяет задать переменные среды, которые будут заданы внутри контейнера. Мы не задаем значение паарметра WORDPRESS_DB_PASSWORD и тем самым предписываем Docker Compose использовать значение из нашей оболочки и передавать его при создании контейнера. Мы определим эту переменную в нашей оболочке перед запуском контейнеров. Так нам не придется напрямую программировать пароли в файле конфигурации.

      Раздел labels позволяет задать значения конфигурации для Traefik. Ярлыки Docker сами по себе ничего не делают, но Traefik их считывает, и поэтому ему известно, как следует обрабатывать контейнеры. Вот что делает каждый из этих ярлыков:

      • traefik.backend задает имя серверной службы в Traefik (которая указывает на фактический контейнер blog).
      • traefik.frontend.rule=Host:blog.your_domain предписывает Traefik проверить запрошенный хост, и если он соответствует шаблону blog.your_domain, перенаправить трафик в контейнер blog.
      • traefik.docker.network=web указывает, в какой сети Traefik следует искать внутренний IP-адрес для этого контейнера. Поскольку у нашего контейнера Traefik есть доступ ко всей информации Docker, он может взять IP-адрес сети internal, если мы не указали этого.
      • traefik.port задает открытый порт, который Traefik следует использовать для перенаправления трафика в этот контейнер.

      При такой конфигурации весь трафик, отправляемый на порт 80 нашего хоста Docker, будет перенаправляться в контейнер blog.

      Мы назначим для этого контейнера две отдельных сети, чтобы Traefik мог находить его через сеть web и чтобы он мог связываться с контейнером базы данных через сеть internal.

      Наконец, ключ depends_on сообщает Docker Compose, что этот контейнер должен запускаться после того, как будут запущены его зависимости. Поскольку для запуска WordPress требуется база данных, мы должны запустить наш контейнер mysql до того, как запустим контейнер blog.

      Теперь настройте службу MySQL, добавив в файл следующую конфигурацию:

      docker-compose.yml

      services:
      ...
        mysql:
          image: mysql:5.7
          environment:
            MYSQL_ROOT_PASSWORD:
          networks:
            - internal
          labels:
            - traefik.enable=false
      

      Для этого контейнера мы используем официальный образ MySQL 5.7. Возможно вы заметили, что мы снова используем элемент environment без значения. Для переменных MYSQL_ROOT_PASSWORD и WORDPRESS_DB_PASSWORD нужно задать одинаковое значение, чтобы наш контейнер WordPress мог связываться с MySQL. Мы не хотим открывать контейнер mysql для Traefik или внешнего мира, и поэтому мы назначим его только в сеть internal. Поскольку у Traefik имеется доступ к сокету Docker, данный процесс по умолчанию открывает клиентскую часть для контейнера mysql. Поэтому мы добавим ярлык traefik.enable=false, указывая, что Traefik не следует открывать доступ к этому контейнеру.

      В заключение добавим следующую конфигурацию для определения контейнера Adminer:

      docker-compose.yml

      services:
      ...
        adminer:
          image: adminer:4.6.3-standalone
          labels:
            - traefik.backend=adminer
            - traefik.frontend.rule=Host:db-admin.your_domain
            - traefik.docker.network=web
            - traefik.port=8080
          networks:
            - internal
            - web
          depends_on:
            - mysql
      

      Этот контейнер основан на официальном образе Adminer. Конфигурации network и depends_on для этого контейнера точно совпадают с использованными нами для контейнера blog.

      Однако поскольку мы направляем весь трафик порта 80 нашего хоста Docker непосредственно в контейнер blog, нам нужно настроить этот контейнер по другому, чтобы трафик отправлялся в контейнер adminer. Строка traefik.frontend.rule=Host:db-admin.your_domain предписывает Traefik изучить запрошенный хост. Если он совпадает с шаблоном db-admin.your_domain, Traefik будет перенаправлять трафик в контейнер adminer.

      На данный момент файл docker-compose.yml должен иметь следующее содержание:

      docker-compose.yml

      version: "3"
      
      networks:
        web:
          external: true
        internal:
          external: false
      
      services:
        blog:
          image: wordpress:4.9.8-apache
          environment:
            WORDPRESS_DB_PASSWORD:
          labels:
            - traefik.backend=blog
            - traefik.frontend.rule=Host:blog.your_domain
            - traefik.docker.network=web
            - traefik.port=80
          networks:
            - internal
            - web
          depends_on:
            - mysql
        mysql:
          image: mysql:5.7
          environment:
            MYSQL_ROOT_PASSWORD:
          networks:
            - internal
          labels:
            - traefik.enable=false
        adminer:
          image: adminer:4.6.3-standalone
          labels:
            - traefik.backend=adminer
            - traefik.frontend.rule=Host:db-admin.your_domain
            - traefik.docker.network=web
            - traefik.port=8080
          networks:
            - internal
            - web
          depends_on:
            - mysql
      

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

      Теперь задайте в оболочке значения переменных WORDPRESS_DB_PASSWORD и MYSQL_ROOT_PASSWORD, прежде чем запускать контейнеры:

      • export WORDPRESS_DB_PASSWORD=secure_database_password
      • export MYSQL_ROOT_PASSWORD=secure_database_password

      Замените secure_database_password желаемым паролем для базы данных. Не забудьте использовать один и тот же пароль для WORDPRESS_DB_PASSWORD и MYSQL_ROOT_PASSWORD.

      Установив эти переменные, запустите контейнеры с помощью docker-compose:

      Еще раз посмотрите на информационную панель администратора Traefik. Вы увидите, что теперь для двух открытых серверов отображаются серверная часть и клиентская часть:

      Заполненная информационная панель Traefik

      Перейдите на адрес blog.your_domain, заменив your_domain на имя вашего домена. Вы будете перенаправлены на соединение TLS и сможете завершить настройку WordPress:

      Экран настройки WordPress

      Откройте Adminer. Для этого введите адрес db-admin.your_domain в адресную строку браузера, заменив your_domain на имя вашего домена. Контейнер mysql не открыт для окружающего мира, но контейнер adminer имеет доступ к нему через внутреннюю сеть internal в Docker, которую они совместно используют, используя имя контейнера mysql как имя хоста.

      На экране входа в систему Adminer используйте имя пользователя root, mysql в качестве сервера и заданное значение пароля MYSQL_ROOT_PASSWORD. После входа в систему вы увидите пользовательский интерфейс Adminer:

      Adminer подключен к базе данных MySQL

      Оба сайта уже работают, и вы можете использовать информационную панель monitor.your_domain для наблюдения за приложениями.

      Заключение

      В этом обучающем руководстве вы настроили Traefik для перенаправления запросов в другие приложения в контейнерах Docker.

      Декларативная конфигурация Traefik на уровне контейнера приложения позволяет легко настраивать дополнительные услуги. При этом контейнер traefik не требуется перезапускать при добавлении новых приложений для переадресации трафика, поскольку Traefik моментально определяет изменения через отслеживаемый файл сокета Docker.

      Чтобы узнать больше о том, что можно сделать с помощью Traefik, ознакомьтесь с официальной документацией по Traefik.



      Source link