Использование шаблонов веб-сервера::Журнал СА 7-8.2017
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 10470
Комментарии: 11
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 10904
Комментарии: 13
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 17794
Комментарии: 2
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 16344
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 17140
Комментарии: 7
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2017 / Выпуск №7-8 (176-177) / Использование шаблонов веб-сервера

Рубрика: Администрирование /  How To

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

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

Самый простой вариант – сделать все стандартно, то есть скопировать файлы и настроить в веб-сервере новый сайт, но для этого потребуются соответствующие права, плюс затраты по времени будут больше. Поэтому выкладку на веб-сервер желательно максимально автоматизировать. Для небольших проектов необязательно использовать 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.

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


Комментарии отсутствуют

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

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru