Pavel
просто между операцией записи в консул и и отработкой консул-темплейта может пройти n секунд, в конторыен делать ниче не надо
Alf 🙀
у них там тоже сокет есть. надо смотреть, но использовать нгинкс как лб вроде такое себе
Pavel
могу переформулировать так:
как записать чтонить в консул и подождать пока отработает консул темплейт :)
Pavel
на ум одна ересь лезет :)
Alf 🙀
можно привязать консул хелсчек на это, проверять стейт хелсчека и верить что оно отрендерено и работает
Alf 🙀
но вопрос хороший и это не звучит как кто то где то гарантировал доставку твоих изменений и их применение
Denis 災 nobody
а кто тут любит keepalived? )
Denis 災 nobody
одна хрень уже вынесла мозг
Denis 災 nobody
делаю ifdown eth1 - ничего не происходит, никаких переключений итд. Поднимаю - на нём больше нет шаред ип, notify молчит. Где косяк?
Alf 🙀
а ты уверен что тебе нужен keepalived?
Alf 🙀
может bgp anycast?
Denis 災 nobody
для начала, у нас нет bgp
Denis 災 nobody
и зачем anycast, рабочая нода должна быть ровно одна
Denis 災 nobody
по перекидыванию адреса - некоторые сервисы поднимаются
Alf 🙀
ну с эникастом получается как бы master-master. удобно.
Denis 災 nobody
мне нужен master-slave
Tadeusz
Tadeusz
Зачем велик строить
Tadeusz
А консул?
Pavel
ну я же там описал :)
Pavel
такое вообще накостылить можно?
- запиши в консул
- дождись пока отработает консул-темплейт <-----????
- продолжи работу
Pavel
citius
я делаю такое без консул темплейта. сервисы регаются в консуле, на них есть хелсчек. LB резолвит через консуловский днс. на каждом LB стоит consul agent + named который как кеш работает.
то что проходит хелсчек - выдается, что не проходит - нет. удобно.
citius
по сравнению с консул-темплейтом сильно проще, и надежнее.
Alf 🙀
citius
дык днс
citius
он знает что надо кидать на app.service.consul
citius
а консул динамически с TTL 0 выдает рабочие айпишники
Alf 🙀
citius
ну как откуда, из конфига ) адрес статический, для всех окружений приложения это всегда app.service.consul. что на стейдже, что на проде, что на тестах.
citius
это уже может темплейтится самим ансиблем есессно.
Alf 🙀
это не dns rr ли?
Alf 🙀
lb то здесь зачем?
citius
по сути да
citius
затем что 2-3 точки входа с мира могут раскидывать на нужное кол-во реальных беков.
citius
ну и это уже детали собсно
citius
основноая фишка - динамический дискавери, также точно сервисы и в базу например ходят.
Alf 🙀
dns as a service discovery. ок.
maniac
Aleksei
Есть вопрос по поводу хранения playbook'ов. У нас в компании достаточно много проектов, которые хранятся в виде отдельных ролей в едином репозитории. Всё бы хорошо, но со временем стало очень сложно в огромном количестве playbook'ов найти нужный, а так же сориентироваться, к какому проекту данный сервер относится.
Кто-то пытался организовать порядок среди playbook'ов? Поможет ли мне свой собственный Galaxy навести порядок в этом хаосе? Есть ли какие-нибудь best practices по этому вопросу?
Dmitry
Dmitry
Либо структурировать все в локальном репе получше.
Dmitry
разложить по папочками, дать структурные имена
Dmitry
роли типа class.project.role-name
Dmitry
и еще можно их положить в папочку class
Aleksei
и еще можно их положить в папочку class
В данный момент как раз используем структурированные имена, но большое количество Playbook'ов в корне всё равно напрягает.
Спасибо за совет с репозиториями, но хотелось бы, чтобы каждый Playbook знал какие зависимости у него, и оттуда их брать
Nklya
плейбуки держать в корне - плохая идея
Dmitry
Вообще, на мой взгляд, плейбуки вообще ничего не должны знать. Даже какую среду они обслуживают.
Dmitry
А на уровне инвентаря должен весь "раутинг" происходить
Nklya
согласен
Dmitry
Но это, конечно, спорный вопрос.... в разных ситуациях может смещаться
Dmitry
Но у меня плейбуки с названиями сервисов (глобальных, которые мы все поддерживаем). типа dima-api.yml
Dmitry
а роли типа того: infra.dima-api (пилит инстансы, конфиг амазона). Если бы деплоили код / конфиг черзе ансибл, то было бы еще app.dima-api
Dmitry
или кластер эластика, плейбук типа elasticsearch-strawberry.yml
Dmitry
а в него входят роли infra.elasticsearch-strawberry, elastic.elasticsearch, monitoring, logging, etc
Dmitry
Когда совсем 100% зависимость для всего, то пихаем. в base
Dmitry
Было бы круто послушать еще кого-нибудь про организацию и доводы.
Nklya
У нас принята строгая иерархия, в которой весь функционал в ролях, в плейбуках вызываются роли. Параметризуются роли через group_vars конкретного окружения
Пример https://github.com/cndies/ansible-repo-example
Nklya
Роли желательно версионировать. Для этого они выносятся в отдельные репы и подтягиваются через requirements.yml и ansible-galaxy
Pavel
о, делегация из "докера".... 😜
Sergey
о, делегация из "докера".... 😜
Странно, зачем докер-людям ансибл..... Контейнеры предполагают неизменяемость, насколько я понимаю, и внутри них провизионировать уже нечего. Прочие варианты - признак некорректного использования инструмента.
Pavel
Sergey
А, ну если так, то да, конечно, имеет место. Только это же редко где инструмент выбирается под задачу, а не наоборот 😊))
Sergey
То есть хосты, на которых сам докер-демон трудится?
Sergey
Чот мне потролить хочется, но тупо лень 😊
Так вот, наиболее часто слышанная мною отмазка во взаимоотношениях докероконтейнероводов и докерохостоводов - "это ваша проблема, разбирайтесь сами".
Sergey
Там, где я видел - да. Но это было давно и неправда.
Womchik
шизофрения?
Pavel
свет выключайте - они все лезет и лезут...
Nikolay
Какое гостеприимное сообщество :)
Pavel
какие, вы, докеры, нервные.....
даже щютак не понимаете
Nikolay
А кто тут докер и кто «щютак» не понимает :) таблички сарказм закончились..
Nikolay
У меня ansible и docker живут в мире и равноправии)
None
при создании vagrant машини, я же смогу на нее зайти по ssh или ток как vagrant ssh name
None
а то сыпит fatal: [10.0.77.14]: UNREACHABLE! => {
"changed": false,
"msg": "('Bad authentication type', [u'publickey']) (allowed_types=[u'publickey'])",
"unreachable": true
}
None
забыл знак вопроса поставить=) ??
Pavel
ключик от вагранта возьми и зайдешь
None
тоесть мне надо с authorized_keys тот что на вагранте к себе ssh-add сделать ?
Pavel
нет , надо ssh -i <путь к файлу private_key этой машинки> vagrant@<адрес>