Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 32

Ansible это интересно.

Вопросы по теме:
Как там с гетерогенностью — насколько удобно создавать много разных серверов с похожими, но слегка отличающимися конфигами?
Как там с индемпотентностью — еcли я попрошу скачать фаил он будет его скачивать каждый раз или проверит что фаил уже есть?
Есть ли какие то решения кроме ssh — если я открою 10к ssh сессий одновременно моей системе поплохеет.
Комментарий пока не оценивали0
1) Гетерогенность
Можно выделить группу серверов 
[app_nodes]
app1.someapp.example.com
app3.someapp.example.com

Включить одну группу в другую
[all_apps:children]
app_nodes


И для каждой группы задать свои параметры (group_vars/app_nodes.yml)
Или для каждой конкретной машины подправить пару-тройку переменных (host_vars/app3.someapp.example.com.yml)
Всего голосов 1: ↑1 и ↓0+1
Ок. А как с зависимостями — обновили конфиг и надо передернуть демона?
Комментарий пока не оценивали0
notify: <нужный хэндлер>

- name: install nginx
  apt: >
    name={{ nginx_name }}
    state=installed
    force=yes

- name: write nginx.conf
  template: >
    src=nginx.conf.j2
    dest=/etc/nginx/nginx.conf
  notify: reload nginx

- name: nginx deny ip default host
  copy:
    dest: /etc/nginx/sites-enabled/deny_by_ip.conf
    src: deny_by_ip.conf
    force: no
  when: nginx_deny_by_ip
  notify: reload nginx


Handler запускается один раз если сработал хоть один notify. Описывается как-то так:
  - name: reload nginx
    sudo: yes
    service: name=nginx state={{ item }} pattern=nginx
    with_items:
      - reloaded
      - running
Всего голосов 1: ↑1 и ↓0+1
Всё верно. Добавлю, что все хэндлеры по умолчанию запускаются в конце прохода, но есть возможность и в конкретный момент времени запустить сработавшие.
Комментарий пока не оценивали0
Как раз нужно — подскажите как сделать?
Комментарий пока не оценивали0
В официальной документации пишут, что следом за задачей, которая могла заставить сработать хэндлер, нужно сбросить очередь хэндлеров:

tasks:
   - shell: some tasks go here
   - meta: flush_handlers
   - shell: some other tasks
Всего голосов 1: ↑1 и ↓0+1
Ещё стоит учитывать, что namespace хэндлеров общий, т. е. в двух ролях одинаковый handler использовать не стоит. Кроме того, в названиях хэндлеров нельзя использовать шаблонизацию, что печалит.
Комментарий пока не оценивали0
2) Идемпотентность:
В общем случае — проверит что файл (конфиг, например) есть и ничего делать не будет, задачу из playbook'а пометит как 'Ok'. Если конфига нет или его содержимое отличается — скажет 'Changed' и приведёт файл на машине в соответствие с исходным.

3) Работа по ssh — наиболее удобна и соответствует принципу «мы сами знаем когда нам что-то накатывать».
Однако возможна работа и по принципу Ceph'a, когда на каждой подконтрольной машине стоит ansible-pull, мониторящий какой-то репозиторий. Как только в нём появляются изменения — запускается локальный самодеплой (в теории, на живую не использовал)
Комментарий пока не оценивали0
3.1) Можно задать сколько хостов деплоить одновременно
Комментарий пока не оценивали0
2) В общем случае, ответственность за идемпотентность поведения лежит на авторах модулей к ansible. Те модули, которые делала команда проекта, в этом смысле очень хороши. А вот законтрибученые модули не особо сильно проверяют на это дело, по моему опыту. Но оно и понятно, почему.
Комментарий пока не оценивали0
Чтобы читающего не смутило обобщение, надо отметить, что есть много случаев, когда при работе даже с core-моудлями за идемпотентностью следит пользователь, например, это касается модуля replace, где пользователю требуется внести изменение так, чтобы при повторном проигрывании той же самой игры однажды изменённая строка вдруг опять не дала положительной реакции и не привела к очередному изменению.
Комментарий пока не оценивали0
3) Работа по ssh — наиболее удобна и соответствует принципу «мы сами знаем когда нам что-то накатывать».

Если у вас три с половиной VPS на Амазоне, то нет никакой разницы чем пользоваться — push, pull, Ansible, Chef, скрипт на баше или руками. Если у вас распределённая система с большим количеством серверов, виртуальных машин, софта, конфигураций и так далее, то наиболее скалируемый и безопасный вариант — это pull с добровольной кооперацией, когда не вы, а сервер «знает» когда ему обращаться к центральному хранилищу за новыми инструкциями и когда эти инструкции выполнять, с механизмом, позволяющим начать этот процесс по команде из центра. К сожалению Ansible в такой конфигурации не блещет совсем. С другой стороны, ниша, в которой может быть достаточно Ansible или скрипта, достаточно велика и большинство проектов не успевает настолько вырасти, чтобы увидеть эти проблемы хотя бы на горизонте.
Комментарий пока не оценивали0
Я в курсе, что можно, но это считается инвертированной архитектурой со всеми вытекающими последствиями. Вообще же исторически pull в Ansible был добавлен не без драм (с пассажами вроде «только идиот может хотеть pull», это почти дословная цитата) и с тех пор живёт там по остаточному принципу. И это вполне понятно, будь pull основным методом работы Ansible, было бы ещё хуже — это значит, что буквально на каждый хост нужно было бы ставить Python с набором библиотек, которые совершенно ни к чему на, скажем, публично доступном рекурсивном DNS-сервере, хотя там и SSH не нужен, если уж на то пошло. Но как я уже писал, большинство проектов проблем с архитектурой Ansible не увидит даже в перспективе, и потому нет причин волноваться. Однако, нужно быть морально готовым к тому, что в какой-то момент придётся мигрировать на более приспособленный для серьёзного использования софт.
Комментарий пока не оценивали0
Python на обслуживаемом ansible хосте всё равно нужен, т. к. ansible собирает python-скрипты, копирует на хост и выполняет локально.
Комментарий пока не оценивали0
Да? Спасибо за уточнение. Я почему-то был уверен, что Ansible «всё своё носит с собой», в том числе и интерпретатор, но видимо я что-то не так понял, когда тестировал его для своих нужд. Раз так, то стало быть для ещё большего круга задач Ansible абсолютно не подходит, что вообще печально, так как среди альтернатив выбора попросту нет, только CFEngine, прародитель Puppet, Chef и, в конечном итоге, Ansible. Но у него и порог входа сильно выше уровня эникеев, и баги есть досадные, которые очень тяжело исправлять, и, как следствие, меньше коммьюнити и меньше набор готовых решений.
Комментарий пока не оценивали0
On the managed nodes, you only need Python 2.4 or later, but if you are running less than Python 2.5 on the remotes, you will also need:
— python-simplejson
docs.ansible.com/intro_installation.html#managed-node-requirements

Кроме того если используется selinux необходимо ещё поставить libselinux-python до использования copy/file/template и аналогичный тасков.

Кроме того, есть модуль raw, который позволяет сделать бутстрап пайтона, если это необходимо. Не требует ничего, кроме ssh.

Сейчас python2.4+ нет только на очень сильно урезанных инсталляциях. На том же RHEL/CentOS он есть из коробки, т. к. yum на нем написан. Подозреваю, что в debian он тоже есть даже в более-менее компактных установках
Комментарий пока не оценивали0
В Debian на Python не завязано никаких ключевых компонентов системы и в базовой системе его нет. Другие дистрибутивы в проде, естественно, не используем.
Комментарий пока не оценивали0
Про идемпотентность:
Все зависит от вашего стиля написания плейбуков. Если вы использовали raw: wget foo.bla/file — то файл будет скачиваться каждый раз. Если же вы используете модуль get_url — то он будет проверять наличие и хэш файла перед скачиванием. Мы же в своей работе обычно пишем вначале стек проверок и заносим результаты в переменные. После чего в каждом шаге есть проверка вида «если nginx -v != заданной версии nginx — то берем собранный пакет и ставим. Если же nginx -v = заданной версии — то скипаем шаг. У нас, например, все роли обеспечивают идемпотентность.

Про кучу серверов единовременно:
У нас такой задачи не стоит обычно, но сами разработчики рапортуют об успешных инсталяциях на инфраструктурах в десятки тысяч машин. Можно запускать по очереди, по 10-20 хостов за раз. Можно отправить все задачи в кролика — и кем-то их разбирать. Архитектуры, которые решают подобные задачи уже изобретены.
Комментарий пока не оценивали0
1. А почему «рекомендуется Ubuntu или CentOS»? Вроде как ansible всё равно где работать, хоть на Plan9 — главное, чтобы там был python. Ну с Plan9 понятно — окружение может быть не то, но с *nix-like вообще разницы не вижу.
2. Вот сразу с ключей SSH. Сходу не помню есть ли готовое, но почему бы первым таском не сделать раскладку ключей и кстати подтягивание python на серверах?
Комментарий пока не оценивали0
Рекомендуется Ubuntu или CentOS для начала изучения, т.к. ставится не из Testing репозитория, быстро и просто. Для эксплуатации подходит практически любой дистрибутив. Про поднятие python не рассказано, т.к. нужные версии уже устанавливаются в указанных дистрибутивах. Как запустить на других — если нужно будет — есть в документации по Ansible. Не хотелось перегружать и так большое руководство, должно быть понятно и новичкам. Если не испугаются на первом этапе — хорошо.
Комментарий пока не оценивали0
А. Ну да, про тестинг репозитарий не подумал.
Всего голосов 1: ↑0 и ↓1-1
2. Кроме того ansible умеет подключаться не только по ключам, но и по паролю. Причем пароль умеет как запрашиваться в ходе выполнения, так и браться из файла настроек. Так что тем кто не знаком с работой по ключам или по какой-то причине нет возможности применить ключ — можно пользоваться вариантом с паролями и ключи раскладывать не придется.
Комментарий пока не оценивали0
И так тоже, кстати. Ещё он умеет как от юзера, так и через sudo. А ещё он, гад такой, не умел raw режим на FreeBSD до весны из-за очень неаккуратной работы с ключами внутри себя )
Комментарий пока не оценивали0
Так же указано, что необходимы права суперпользователя для обоих задач.

Нужно отметить, что если права суперпользователя нужны для выполнения всех задач в игре, то можно просто указать ключ sudo на уровне игры:

- hosts: webservers
  remote_user: yourname
  sudo: yes

Или в файле ansible.cfg. Или в качестве ключа в командной строке.
Всего голосов 1: ↑1 и ↓0+1
Отличная статья. Год назад начал внедрять Ansible у себя — порядка 700 хостов ею держим на данный момент, не все автоматизированно, но некоторый пул задач безусловно ею решается.
В процессе эксплуатации конечно вылезают велосипеды, но куда же без них.
В будущем будет книжка целая — shop.oreilly.com/product/0636920035626.do
Всего голосов 1: ↑1 и ↓0+1
У нас порядка 400. А какие велосипеды писали, для чего, поделитесь? Нас ansible полностью устроил, основная проблема была в утрясании workflow, много итераций прошли в этом процессе.
Комментарий пока не оценивали0
Сейчас все и не упомнишь, мы еще свой workflow утрясаем)
Из того, что вспомнил — пляски с генерацией ИД уникального по последним трем октетам адреса:

server-id={{ ansible_default_ipv4.address |replace(".","")|reverse|truncate(9,True,"")|reverse }}


Из-за большого кол-ва проектов (порядка 10), пришлось в каждый подключать свой собственный файл с некими константами.
А потом решать проблему с доступом пользователей и их заведением на разные группы хостов…
Раз
В итоге родилось вот такое вот:

- name: Add ssh user
  user: 
    name={{ item.user }} 
    groups={{ item.group }} 
    comment={{ item.comment }} uid={{ item.uid }}
    password={{ item.password }}
    shell={{ user_shell | default("/bin/bash") }} 
    state={{ item.state | default("present") }}
  with_items: "ssh_users"
  when: item.user is defined


А группа ssh_users для каждой группы хостов определяет список пользователей, данные о которых берутся из общего файла group_vars/all. Фильм Начало тут отдыхает :)
пользователь определялся видом
dtest:
    - { user: 'd.test', group: 'ssh_access', comment: "Test_User", uid: '10403', password: 'MEGAHASH', state: 'absent' }

имя перменной не может содержать точку, ансибл воспринимает ее как переменную, а экранировать не получилось. И пробел в комменте тоже)

Из последнего скорее не велосипед, а просто особенность — настроил автоматическое добавление хоста в мониторинг заббикса при его первоначальной настройке. Использую для этого API заббикса и модуль ансибла uri, так он заставляет писать json как будто я сотону вызываю.
Два
- name: register host in zabbix database
  uri: url=http://"{{zabbix_server}}"/api_jsonrpc.php HEADER_Content-Type="application/json" method=POST
       body="{\"jsonrpc\":\"2.0\",\"method\":\"host.create\", \"params\":{\"host\":\"{{ ansible_fqdn }}\",\"interfaces\":[{\"type\":1,\"main\":1,\"useip\":1,\"ip\":\"{{ ansible_ssh_host | default (ansible_default_ipv4.address) }}\", \"dns\":\"{{ ansible_fqdn }}\", \"port\":\"10050\"}], \"groups\":[{\"groupid\":\"{{zabbix_group_id.json.result[0].groupid}}\"}]}, \"auth\":\"{{zabbix_auth_code.json.result}}\",\"id\":4}"
  delegate_to: localhost
  when: zabbix_host_exist.json.result == False


В основном велосипеды делались для переменных, которые ансибл страсть как любит. Переменные для переменных в переменных. В итоге через месяц ты уже не понимаешь, как оно работает :)
А вообще с ним весело )
Комментарий пока не оценивали0
Да, Ansible — мощная штука!

Я заморочался и создал несколько ролей, которые можно повторно использовать, в основном, это касается веб-разработки и LAMP-стека: github.com/andyceo/ansible-roles Еще несколько ролей можно найти на Ansible Galaxy, сервисе, куда можно закачивать свои роли, чтобы все ими могли пользоваться.

Еще долго думал, в каком виде хранить все свои настройки для всех хостов в виде одного репозитория, и вот пока пришел к этому: github.com/andyceo/ansible-example

Об использовании Ansible для разработке под Друпал я рассказывал на последнем Drupal-кемпе в Москве, вот доклад, кому интересно: 2014.drupalcampmsk.ru/program/sessions/ispolzovanie-ansible-dlya-upravleniya-serverami-i-drupal
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr