Проверяйте nginx.conf во время развертываемого развертывания


11

У меня есть один предоставленный Ansible сервер, на котором работает несколько сайтов.

Мои Ansible задачи выглядят примерно так:

- name: site nginx config
  template: src="nginx-site.conf.j2" dest=/etc/nginx/conf.d/{{item.name}}.conf
            owner=root group=root mode=0444
  with_items: sites
  notify: restart nginx

- name: nginx conf
  template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf 
            owner=root group=root mode=0444
  notify: restart nginx

Я бы хотел использовать validateпараметр модуля шаблона Ansible для вызова nginx -tи проверки того, что мои новые конфигурации синтаксически допустимы. Это работает для основного nginx.conf:

  template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf 
            owner=root group=root mode=0444
            validate="/usr/sbin/nginx -c %s -t"

Но, похоже, он не подхватывает изменения в конфигурационных файлах для конкретного сайта. Размещение validateна сайте шаблонов не работает, так как они должны быть включены в httpдирективу, чтобы быть действительными.

Что я могу сделать, чтобы проверить правильность этих файлов, специфичных для сайта?

Ответы:


9

Вы можете сделать некоторые трюки и проверить размещенный файл, как (идея заимствована из https://gist.github.com/psd/5042334 ): validate: bash -c 'nginx -t -c /dev/stdin <<< "events {worker_connections 1;} http { include %s; }"'


это на самом деле работает, upvote!
13dimitar

4

Нет смысла напрямую вызывать validateфайл, включенный в основной файл конфигурации nginx, потому что действительность директив в конкретном файле конфигурации может зависеть от остальных файлов конфигурации (например, у вас есть два файла конфигурации, которые объявляют один и тот же блок сервера). так далее).

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


1
Хорошо. Так что, я думаю, мне нужно убедить ANSIBLE в том, чтобы объединить все для проверки за один раз?
Эрин Позвони

@ErinCall В идеале ваша конфигурация nginx должна оставаться полностью действительной, даже если ваша игровая книга была прервана на полпути.
Майкл Хэмптон

3

Я использовал подход, аналогичный принятому ответу, принимая во внимание проблемы другого ответа.

Я создал этот смысл для этой цели.

Идея состоит в том, чтобы скопировать весь /etc/nginxкаталог во временный каталог, изменить один файл из %sпараметра и проверить основной конфиг nginx на наличие проблем. Если вы предполагаете, что изначально конфигурация nginx является допустимой, и все задачи, которые изменяют конфигурацию nginx, используют ее для проверки, тогда, я думаю, проблем не будет.

Как один лайнер это будет выглядеть так:

validate: bash -c 'NGINX_CONF_DIR=`mktemp -d`; cp -rTp /etc/nginx/ "$NGINX_CONF_DIR" && cp -Tp %s "$NGINX_CONF_DIR"/sites-enabled/new-site.conf && nginx -t -c "$NGINX_CONF_DIR"/nginx.conf'


1
Мне нужно было это решение вместо принятого ответа, потому что мой конф nginx включал fastcgi_params.
Yep_It's_Me

3

Вот более простой способ, который работает по крайней мере с Ansible 2.5:

- name: Verify Nginx config
  become: yes
  command: nginx -t
  changed_when: false

Он запускает эквивалент sudo nginx -tи проверяет свой вывод. Если в конфиге nginx есть ошибка, он возвращает ненулевое значение, и задача Ansible выдаст ошибку ( changed_when).

Если вы установили Nginx как пользователь, просто удалите его become, хотя я думаю, что он все равно будет работать даже с ним.


1
Это плохой пример, когда при использовании templateмодуля и опции проверки в Ansible у вас есть гарантия на действительность конфигурации, но если вы развернете шаблон, а затем выполните ручную проверку и потерпите неудачу, то у вас все еще будет проблема, что недопустимый Шаблон был развернут, и его не нужно возвращать.
Рабин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.