тут барметал

consul

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

--limit ?

барметал можно грузить по PXE и навесить self-discovery и cloud scheduler (Nomad)

на dynamic inventory рисуется примерно столько ж

тоже надо бы вкурить..

ничем не будет отличаться от клауда

кроме постоянных сражений с железяками

барметал можно грузить по PXE и навесить self-discovery и cloud scheduler (Nomad)

систему можно ставить заранее, и вообще у нас есть свой ks.cfg ) А вопрос - в сносе ненужной ноды с других нод

систему можно ставить заранее, и вообще у нас есть свой ks.cfg ) А вопрос - в сносе ненужной ноды с других нод

consul-template

как только нода выпадет из healthy нод сервиса ее вычеркнут все консьюмеры

hashicorp сильно упрощает жизнь

сколько изучать.. =_=

нее. не стоит. это вход в кроличью нору

там дальше демоны и порталы

барметал можно грузить по PXE и навесить self-discovery и cloud scheduler (Nomad)

Есть же maas от каноникла

Ironic ещё

Но в глубине там всё одно

привет! никто не подскажет как сделать сделать так чтобы ansible работал с backup как человек? я пользуюсь стандартными модулями copy/template они поддерживают backup но очень криво, хочеться чтобы: ansible создавал backup для файлов по умолчанию и ложил их куда-то в /var/backup/ansible/path/to/original/file.timestamp с ротейтом

свои модули делать чо

свои модули делать чо

ок, а ансибл позволяет подключить через ansible.cfg?

его можно просто бросить в library

Интересно, а зачем вам рез. копии конфигов если вы используете систему управления конфигурациями? Да еще + история версий.

вот просто возьми модуль который в коробке лежит положи его рядом с ролью в library и будет использован он

Интересно, а зачем вам рез. копии конфигов если вы используете систему управления конфигурациями? Да еще + история версий.

потому что в реальной жизни есть факапы и исправления

Интересно, а зачем вам рез. копии конфигов если вы используете систему управления конфигурациями? Да еще + история версий.

на лицо конечно bad pattern да

и нет физической возможности наблюдать за всеми diff.

вот просто возьми модуль который в коробке лежит положи его рядом с ролью в library и будет использован он

для меня преимущество ansible только в том что я могу сделать git clone и запустить деплой. как я понимаю здесь речь идет про тауеры и прочее?

нет. речь про плохой паттерн. но решение я вам предложил

почему не хранить конфиги где-нибудь в гитлабе?

или я чего-то не понял?

так же почему нельзя использовать etckeeper

да там много вопросов на самом деле

те что должны быть - храняться в гите. но есть те что _по_факту_

и нет физической возможности наблюдать за всеми diff.

но есть возможность пойти и (наверное) ручками потом вытащить конфиг из бэкапа и вернуть его на место. А учитывая пожелание к истории версий, значит это произойдет видимо даже не сразу, а когда первый бэкап будет затерт.

под конфигами имел ввиду плейбуки и прочее барахло, сори

по факту и должны быть в гите)

те что должны быть - храняться в гите. но есть те что _по_факту_

который твой коллега накостылил в час ночи

а бекапить конфиги тем же duplicity

а бекапить конфиги тем же duplicity

бакапить - не нужно

у меня это реализовано duply+s3

нужно при обновлении через ansible

сделать бакап

не так как делает ansible, а по нормальному

а

по дефолту и не в туже директорию

бакапить - не нужно

Ну вот, мы видим что у человека свой особый подход.

Ну вот, мы видим что у человека свой особый подход.

конечно, бакапить то что сейчас есть нужно только при обновлении через систему конфигурации

по дефолту и не в туже директорию

Чем не подошёл etckeerper ?

Лучше возложить роль бэкапа на систему управления конфигами. Okay.

никогда не слышал об etckeerper. почитаю. спасибо за инфо

в проде можно использовать его?

я наверное плохо донес. надеюсь. вообщем всем спасибо.

конечно, бакапить то что сейчас есть нужно только при обновлении через систему конфигурации

Если вы обновляете через систему конфигураций - значит вы не ходите ручками. Ну как бы это подразумевается в любом случае.

по дефолту и не в туже директорию

у тебя есть конфиг на сервере, он должен совпадать с тем конфигом который у тебя в гите. когда ты выкатываешь изменения то коммитишь новый конфиг. нужен старый потом? - возьми из гита

в проде можно использовать его?

Конечно нет. Это середина 2000ых. Сейчас только иммутабл инфрастракча

а, я и думаю, почему я о нем не слышал)))

Мечты-мечты

а, я и думаю, почему я о нем не слышал)))

ну я использовал какое то время. вполне успешно. в тех местах где надо он вполне годен.

он просто был до широкого распространения упраления конфигурациями gitops и вот это всё.

у меня какое то время назад еще стоял плагин для vim который делал rcs

https://github.com/vim-scripts/rcs.vim

туже задачу решают.

... решали

2010, я с пацанами в линейдж шпилил в это время и даже не знал, что такое гит)))))

2010, я с пацанами в линейдж шпилил в это время и даже не знал, что такое гит)))))

тогда уже был свн, а он для конфигов тоже ок

Народ, я правильно понял, что создание local facts это ansible way. И всякие триггерные файлы по которым Ansible понимает, выполнять тот или иной таск лучшее заменить на local facts? Пример тасков, которые я думаю заменить на local facts: - name: Check updated state stat: path: /root/updated.state register: updatedState - name: Update all packages yum: name: '*' state: latest update_cache: yes when: updatedState.stat.exists == false - name: Create file /root/updated.state file: path: /root/updated.state state: touch when: updatedState.stat.exists == false

Поясни какую проблему ты решаешь?

Мне надо при создании машины, надо, чтобы ПО обновилось единожды. Т.е. при повторном запуске Playbook не запускал yum update *

А зачем latest? Чем present не угодил?

present == install, разве нет?

Напиши буку в которой будешь производить начальную конфигурацию машинок и гоняй ее отдельно от всего другого 1 раз при создании машины

Есть в планах разделить роли создания/удаления машинок от остальных ролей, но пока всё запускается последовательно и... И я ищу, какой костыль бы воткнуть, чтобы всё пока работало так =)

А зачем latest? Чем present не угодил?

latest это обновить систему

Есть в планах разделить роли создания/удаления машинок от остальных ролей, но пока всё запускается последовательно и... И я ищу, какой костыль бы воткнуть, чтобы всё пока работало так =)

ты ведь уже изобрел костыль) он не работает? или нужен еще 1 костыль для костыля?

ты ведь уже изобрел костыль) он не работает? или нужен еще 1 костыль для костыля?

Нет, я просто подумал, что юзать local facts было бы более православно. Вот и подумал, заменить одно другим

Что обычно, кстати, вы в local facts закидываете? И вообще, используете ли?

нет не использую. недостатоверный механизм

нет не использую. недостатоверный механизм

Почему недостоверный?

по тому с чем ты имеешь дело.

Эм... Что ты в неё поместишь - то и вернётся. Это как локальное хранилище значений. Не понимаю, в чём недостоверность... Скорее всего, я просто не шарю =)

Эм... Что ты в неё поместишь - то и вернётся. Это как локальное хранилище значений. Не понимаю, в чём недостоверность... Скорее всего, я просто не шарю =)

если тебе придет пустая ВМка с таким же именем, то быть беде

если тебе придет пустая ВМка с таким же именем, то быть беде

Не, я не про facts, а про local facts

Не, я не про facts, а про local facts

ааа. Ну я видел жуткие вещи - туда например кладут скрипт, и он возращает INI, которая парситься как факт - типа лайв статус получать

Я думаю Алексей имеет в виду хранить там лок файлы разные. Я тоже пришел недавно к этой идее, но пока не проверял

Я думаю Алексей имеет в виду хранить там лок файлы разные. Я тоже пришел недавно к этой идее, но пока не проверял

Ну типа. Скорее какие-то переменные, которые относятся только к этой машине

Для переменных машины есть hosrvars

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

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

поэтому у тебя сейчас хост обновлен а с точки зрения ноября у тя 4 уязвимости в ядре и 2 минимум в процессоре. так что хост снести нафиг и перестаивть только

Конкретные версии пакетов + present

Ну или метапакет с явно указанными зависимостями

Ага, суть понял. Если я хочу, чтобы у меня виртуалки выкатывались с самыми свежими версиями пакетов, то я раз в месяц (к примеру) создаю образ с виртуалкой на которой выполняю Full Update и просто его использую. А в основной роли, как максимум использую проверку, что (к примеру), версия ядра должна быть не ниже 4.4. Правильно?