Ansible и reverse-proxy сервера

Примерно полгода назад, пришлось разработать схему обратного проксирования сайтов, с многих нод (n>20) на несколько (n<=3) боевых серверов. Недавно столкнулся в аналогичным запросом от коллеги. Поэтому решил поделиться, и все собрать в статью.
Уровень статьи — для начинающих.

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

Поиск информации по теме reverse-proxy, часто сводится к статьям по настройке “nginx to apache” (на локальный apache или на удаленный upstream-сервер), CDN-прокси сервисов (cloudflare, *cdn, cloudfront, etc.). В данном случае это не совсем подходило.
Особенность заключается в необходимости предоставлять множество разных IP (из различных географических локаций) для доменов одного-двух серверов.

Для решения задачи были куплены несколько VPS в необходимых различных локациях (дешевые, спасибо lowendbox.com & lowendstock.com, но с необходимым бендвичем).
VPS пока использовались на Centos-6-x32, но как только epel выкатит пакеты для Centos-7 32-bit, будем обновляться.
Все остальные манипуляции с серверам выполняются удаленно, при помощи ansible.

Структура проекта Ansible

В соответствии с принятой практикой, имеем такую файловую структуру:

$ find -type f ./roles/update_os/tasks/main.yml ./roles/update_nginx_configs/tasks/main.yml ./roles/update_nginx_configs/files/proxy.conf ./roles/update_nginx_configs/templates/domain.conf.j2 ./roles/update_nginx_configs/handlers/main.yml ./roles/update_hostname/tasks/main.yml ./ansible.cfg ./hosts ./proxy-nodes.yml 

Пройдемся по всем файлам.

[test] localhost ansible_connection=local  [centos:children] proxy-nodes  [proxy-nodes] xxx.xxx.xxx.xxx  ansible_connection=ssh ansible_ssh_user=root  ansible_ssh_pass=xxxxxx node_hostname=proxy-node-001.www.co yyy.yyy.yyy.yyy  ansible_connection=ssh ansible_ssh_user=root  ansible_ssh_pass=yyyyyy node_hostname=proxy-node-010.www.co zzz.zzz.zzz.zzz  ansible_connection=ssh ansible_ssh_user=root  ansible_ssh_pass=zzzzzz node_hostname=proxy-node-029.www.co 

Тут отображена мета-группа [centos] и отдельно указана группа [proxy-nodes] как дочерня группа к [centos].
Структура с расчетом на расширение ролей и задач.

[defaults] pipelining                = True hostfile                  = hosts [ssh_connection] ssh_args                  = -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s control_path              = ~/.ansible/cp/ansible-ssh-%%h-%%p-%%r 

Тут тоже ничего особенного.
Настройка сервера идет отпользователя root, поэтому можно смело включить pipelining.
hostfile — для умешения входных параметров при работе в консоли,
ssh_args — для уменьшения говорливости при релоадах хостов, и настройки persistent connection, среди них самый важный — ControlPath.

Это позволяет работать быстрее, чем с опцией «accelerate: true». Несмотря на документацию, Centos 6 уже почти год корректно работает с ControlPersist, и не требует такого преинсталла, как делалось ранее:

--- - hosts: centos    tasks:    - name: install EPEL     yum: name=epel-release    - name: install keyczar     yum: name=python-keyczar

Далее, стандартный плейбук, при работе с ролями, и таск update_os:

--- - hosts: proxy-nodes   roles:     - update_hostname     - update_os     - update_nginx_configs 

---  - name: repo install EPEL   yum: name=epel-release  - name: repo install nginx-release-centos-6   yum: state=present name=http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm  - name: packages install some   yum: name={{ item }}   with_items:     - nginx     - yum-update  - name: packages upgrade all   yum: name=* state=latest 

Считаю, что данные файлы не нуждаются в комментировании.

Роль update_hostname

Так уж повелось, что ноды как-то именуются. Как можно было видеть, в файле hosts указан, говорящий за себя, параметр node_hostname. К сожалению, ansible еще не может изменить хостнейм в соответствии с FQDN, поэтому приходится помогать:

---  - name: set hostname   hostname: name={{ node_hostname }}  - name: add hostname to /etc/hosts   lineinfile: dest=/etc/hosts regexp='.*{{ node_hostname }}$' line="{{ ansible_default_ipv4.address }} {{ node_hostname }}" state=present create=yes   when: ansible_default_ipv4.address is defined 

Теперь hostname -f не ругается, а именно такая проверка существует в некоторых панелях управления.

Роль update_nginx_configs

Последняя роль — update_nginx_configs.
Тут мы описываем обработчик, для релода nginx:

--- - name: reload nginx   service: name=nginx state=reloaded

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

proxy_cache_path  /tmp  levels=1:2    keys_zone=PROXY:10m inactive=24h  max_size=4g use_temp_path=off; include /etc/nginx/conf.d/proxy/*.conf;

Шаблон для доменов примерно такой:

server {         listen {{  ansible_default_ipv4.address  }}:80;         server_name {{  item.domain  }} www.{{  item.domain  }};         access_log  /var/log/nginx/{{  item.domain  }}.access.log main ;         error_log   /var/log/nginx/{{  item.domain  }}.error.log;          location / {                 proxy_pass http://{{  item.remoteip  }}:80/;                 proxy_redirect off;                 proxy_set_header Host $host;                 proxy_set_header X-Real-IP $remote_addr;                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                 client_max_body_size 10m;                 proxy_connect_timeout 90;                  proxy_cache             PROXY;                 proxy_cache_valid       200 302 1d;                 proxy_cache_valid       404    30m;                 proxy_cache_valid       any     1m;                 proxy_cache_use_stale   error timeout invalid_header updating http_500 http_502 http_503 http_504;         } } 

Тут в целом ничего особенного, параметры проксирования и кеша подбираются под проект. Среди динамически параметров видим всего три: ansible_default_ipv4.address, item.domain и item.remoteip. Откуда берутся последние два, видно из следующего файла:

---  - name: create non existing dir /etc/nginx/conf.d/proxy/   file: path=/etc/nginx/conf.d/proxy/ state=directory mode=0755  - copy: src=proxy.conf dest=/etc/nginx/conf.d/ owner=nginx group=nginx  backup=yes  - name: re-create domain templates   template: src=domain.conf.j2 dest=/etc/nginx/conf.d/proxy/{{ item.domain }}.conf owner=nginx group=nginx  backup=yes   with_items:     - { domain: 'nginx.org'       , remoteip: '206.251.255.63' }     - { domain: 'docs.ansible.com', remoteip: '104.25.170.30'  }   notify: reload nginx  - name: validate nginx conf   command: nginx -t   changed_when: false

Вот и завершающие этапы: проверили, что директория для доменов существует, обновили конфиг с настройками зоны кеширования, в цикле с with_items прошлись по всем парам domain-remoteip и пересоздали конфиги.
Последним этапом идет валидация конфига, и при успешном результате запустится обработчик reload nginx.
К сожалению, эту валидацию не получается использовать при генерации template или копировании конфига proxy.conf.
Опции validate=«nginx -t -c %s», или даже validate=«nginx -t -c /etc/nginx/nginx.conf -p %s» не так хороши, как в случае генерации конфига httpd.conf.

Поехали!

В случае обновления или изменения списка доменов в задаче «re-create domain templates», выполняем:

ansible-playbook proxy-nodes.yml

без каких-либо дополнительных параметров.
После добавления новой ноды необходимо выполнить команду:

ansible-playbook proxy-nodes.yml —limit=bbb.bbb.bbb.bbb

где указать IP новой ноды.

Заключение

Спросив google, я не получил ответ о подобных сервисах от хостинг-провайдеров.
А ведь целевая аудитория может быть очень разная, от CEO до различных adult web-мастеров.
Поэтому ниже опрос.

ссылка на оригинал статьи https://habrahabr.ru/post/269123/