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

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

так же почему нельзя использовать 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. Правильно?

Эталонный образ виртуалки можно через packer удобно создавать. Там из коробки поддерживается провижинер ансибла

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

Звучит разумно

Если добавить темтирование этих виртуалок через testkitchen/molecula/testinfra/inspec то можно будет спать спокойней

Эталонный образ виртуалки можно через packer удобно создавать. Там из коробки поддерживается провижинер ансибла

Я слышал о нём. Правильно ли я понимаю, что ты ему скармливаешь либо ISO с каким-нибудь kickstart'ом, либо образ эталонной VM и он сам тебе делает из него то, что надо по итогу?

Тип того

Под капотом все банально 1 пакер стартует хттп сервер 2 стартует виртуалку 3 виртуалку бутит, что бы стянула кикстарт файл 4 отрабатывает кикстарт, подымает сеть, делает что надо 5 вм в ребуте, пришла сеть - допровижинивает как надо 6 экспортим и пакуем виртуалку

Вариантов настроек километр. Это порождает опасность ошибиться. Настойчиво рекомендую задуматься о тестирование для этого счастья

Понял. Спасибо всем за дискуссию! ^^

Пошёл думать, как привести всё это в тот вид, в котором оно и должно быть =)

1 ci - jenkins/gitlab/teamcity 2 vm builds - packer ( можно nested virtualization) под каждую платформу 3 артифакторий - nexus/artifactory/s3 4 vm tests - testkitchen / molecula / testinfra 5 infrastructure provision - terraform/ nomad/ cloudfront Ну и на каждом уровне никто не отменял своих костылей и велосипедов

Артифакторий))

Чем слово не угодило Оо

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

А как правильно перевести? Хранилище артефактов?

Например

профилакторий