Использование шаблонов веб-сервера

Использование шаблонов веб-сервера

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

Самый простой вариант – сделать все стандартно, то есть скопировать файлы и настроить в веб-сервере новый сайт, но для этого потребуются соответствующие права, плюс затраты по времени будут больше. Поэтому выкладку на веб-сервер желательно максимально автоматизировать. Для небольших проектов необязательно использовать CI, можно выполнить несколько простых настроек. Простейший процесс деплоя при помощи штатных возможностей Git в BitBucket рассмотрен в [1]. С веб-сервером тоже можно создать готовую настройку, при которой он будет сам забирать файлы с подкаталога /var/www/имя_поддомена при обращении поддомен.example.org.

server {

    listen 80;

    server_name *.example.org;

    set $subdomain "";

    if ($host ~* ^([a-z0-9-\.]+)\.example.org$) {

        set $subdomain $1;

    }

        location / {

        root /var/www/$subdomain;

        index index.html index.php;

            location ~ \.php$ {

                include snippets/fastcgi-php.conf;

                fastcgi_pass unix:/run/php/php7.0-fpm.sock;

        }

    }

}

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

Но если приложение требует разных сред, то лучшим вариантом будет использование контейнеров. Здесь можно самостоятельно настроить шаблон для proxy_pass nginx, но есть более удобный вариант, требующий меньше затрат [2] ипозволяющий все сделать буквально парой команд.

Перестраиваем DNS, чтобы имя *.example.org смотрело на нужный IP. Запускаем контейнер jwilder/nginx-proxy:

$ docker run -d -p 80:80 -v /var/run/docker.sock: /tmp/docker.sock:ro jwilder/nginx-proxy

И при запуске контейнера указываем в параметре VIRTUAL_HOST нужный домен:

$ docker run -e VIRTUAL_HOST=foo.example.com nginx

Теперь к контейнеру можем обратиться по DNS. nginx-proxy поддерживает wild-домены, SSL, несколько портов, разные параметры проксирования и многое другое, с его помощью можно реализовать любой сценарий. Только смотреть логи при массовом применении Docker не очень удобно, так как они разбросаны по каталогам, путь к которым у каждого контейнера свой. По умолчанию используется --log-driver=json-file, который складывает данные в JSON-формате вподкаталоги /var/lib/docker/containers, и так просто их в ELK (Elasticsearch + Logstash + Kibana) не подашь. Можно перенастроить Docker в --log-driver=syslog, но разбирать информацию из одного файла не очень удобно. Разработчик nginx-proxy предложил свой вариант решения этой задачи – docker-gen [3], который самостоятельно генерирует нужные пути. Настраивается он просто.

Устанавливаем filebeat [4], который используется для отправки логов в Logstash:

$ wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

$ sudo apt install apt-transport-https

$ sudo apt update

$ sudo apt install filebeat

Добавляем в автостарт:

$ sudo systemctl daemon-reload

$ sudo systemctl enable filebeat

Скачиваем архив:

$ wget -c https://github.com/jwilder/docker-gen/releases/download/0.7.3/docker-gen-linux-amd64-0.7.3.tar.gz

Копипуем файл docker-gen в /opt/docker-gen. Для удобства создаем конфигурацию для systemd:

$ sudo vi /etc/systemd/system/docker-gen.service

[Unit]

Description=A file generator that renders templates using

Docker Container meta-data.

Documentation=https://github.com/jwilder/docker-gen

After=network.target docker.socket

Requires=docker.socket=

[Service]

ExecStart=/opt/docker-gen/docker-gen -notify "/etc/init.d

/filebeat restart > /dev/null 2>&1 &" -notify-output -watch

/etc/docker-gen/filebeat.tmpl /etc/filebeat/filebeat.yml

Restart=always

[Install]

WantedBy=multi-user.target

Alias=docker-gen.service

Принцип простой. При запуске и работе docker-gen проверяет текущие контейнеры и создает на основе шаблона конфигурацию для filebeat (файл /etc/filebeat/filebeat.yml). Параметры могут быть разные. В примере отбираем контейнеры изопределенного репозитория, для удобства последующего отбора используем в качестве поля информацию из VIRTUAL_HOST:

$ sudo vi /etc/docker-gen/filebeat.tmpl

filebeat.prospectors:

 {{ range $key, $value := . }}

  - paths:

     - /var/lib/docker/containers/{{ $value.ID }}/{{ $value.ID }}-json.log

     - /var/log/plugins/{{ $value.Name }}/*.log

    tags: ["{{ $value.Image.Repository }}"]

    fields:

       {{ if eq $value.Image.Repository "testsite" }}

       virtual_host: "{{ $value.Env.VIRTUAL_HOST }}"

       {{ end }}

 {{ end }}

output:

  logstash:

    hosts: ['logstash.expamle.org:5044']

    tls:

      certificate_authorities: ['/etc/ssl/logstash/logstash.crt']

    ssl:

      enabled: true

      verification_mode: none

      supported_protocols: [SSLv3, TLSv1.0, TLSv1.1, TLSv1.2]

logging:

  files:

    rotateeverybytes: 10485760

Запускаем:

$ sudo systemctl start filebeat

Проверяем изменения в /etc/filebeat/filebeat.yml. Все готово к работе.

1. Яремчук С. Работаем с BitBucket. // «Системный администратор», №10, 2016 г. – С. 70-73 (http://samag.ru/archive/article/3298).
2. Проект nginx-proxy – https://github.com/jwilder/nginx-proxy.
3. Проект docker-gen – https://github.com/jwilder/docker-gen.
4. Страница filebeat – https://www.elastic.co/products/beats/filebeat.

Подготовил Сергей Яремчук

Комментарии могут оставлять только зарегистрированные пользователи