Простите, не заметил что перевод.
В целом с вами согласен. Но лично я понимаю SRE как среднее между "Тип 1" и "Тип 2".
Подробнее об описании зоны ответственности SRE написано здесь:
Позвольте узнать, а где вы откопали такое определение SRE?
Мне кажется идея Site Reliability Engineering дефакто соотвествует "Типу 2", описанному в статье.
И да, в терминологии DevOps явно забыли Qa. Видимо, название DevOpsQa не очень благозвучно.
Руками(через CM) обновлять достаточно время-затратно ;) Нужен постоянный напильник. Когда k8s не профильное направление, невольно хочется готовых production grade тулзов.
Как kops работает в aws весьма нравится, будем ждать ) Tectonic имел в виду как инсталлер для бареметал\квм.
Благодарю за ответ!
По моему опыту работать с базами локально значительно проще, чем в кубере (когда дело доходит до нестандартных случаев, рекавери и прочего), но не всегда хочется деплоить доп. сервера -)
Еще вопрос на счет flunetd-clickhouse. ClickHouse ведь любит хорошо определенные структуры. Но логи то далеки от этого. Вот лог нжинкс, вы целиком в столбец таблицы кладете или как-то распарсиваете (например, чтобы было можно сделать выборку по http response code, upstream_response_time)?
Вообще хотелось бы с nginx-ingress-controller слать логи в json. И класть их в clickhouse уже в структурированном виде. Насколько это просто\сложно сделать (в рамках loghouse)?
Интересует а как вы обновляете кластера кубернетес, особенно которые на квм\бареметал? А также существует ли регулярная процедура\полиси апдейта? используете ли tectonic ?
Спасибо больше за статью и проект! Очень нужный стек!
Поддержку вопрос hostmaster, не рассматривали fluentbit
как легковесный коллектор?
Также хотелось бы деталей по использованию clickhouse в кластере k8s. Какой тип волюмов используете? cephfs? есть ли проблемы с проседанием перфоманса? pod clickhouse привязан к какой-то конкретной ноде?
Я тоже делал похожие кастыли (packer+libvirt+python-script+dhpcd) ну и время старта квм-виртуалки на нормальном железе это секунды… но по хорошему cobbler решает большинство вопросов, а также его можно использовать как dynamic inventory для ansible.
Здесь речь шла о том, что при помощи ansible playbook можно приготовить такой же самый immutable контейнер, просто использовав ansible вместо шела. Это имеет смысл когда на ансибле уже написана автоматизация для сервиса. Ну или, например, для тестирования тех же плейбуков и ролей, но это уже совсем другая история.
В целом я с вами солидарен, преимущества от использования ansible-container для меня не очевидны, если не сказать спорны.
Также, никто не мешает запускать плейбук и в самом docker контейнере, предварительно установив там ansible или взяв уже готовый image c ansible.
RUN yum -y install epel-release \
&& yum -y install ansible \
&& echo -e "[local]\nlocalhost" > /etc/ansible/hosts
RUN ansible-galaxy install example-role
RUN ansible-playbook site.yml -c local
полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry. В то время как делать ansible-container run видится актуальным для каких-то тестов разве что...
Благодарю за развернутые детали. Тут наиболее интересно на мой взгляд это тесное взаимодействие с разработчиками, что они тоже применяют сальт и имеют к нему доступ. Однако, неясно как происходит повторное использование кода для другого проекта. Получается что стейты начинают жить в разных местах....
Касательно ролей, таргетинга и мульти-окружений, меня интересовало применительно к вашей структуре развертывания. Лично я же использую таргетинг по пиллар:
'I@roles:sphinx_server or I@sphinx_server_role:true':
- match: compound
- sphinx
и мульти окружения, которые просто напросто имеют разные пиллар данные, которые назначаются через систему рендеринга pillar/top.sls, впрочем как и роли:
А с этого момента можно поподробней )
Как вы решаете проблему защиты от отстрела ноги? А также проблему чувствительных данных? Девелоперы к ним тоже имеют доступ и могут вносить изменения?
Еще интересно, у вас получается и стейты и пиллар хранятся в одном репозитории + Saltfile?
Также, реализовано ли как-то reuse стейтов между разными проектами?
Используются ли мульти-окружения (dev\stg\etc\prod) и к ним девелоперы имеют доступ?
Со своей стороны могу сказать, что для деплоймента применяю дженкинс. Т.е. при коммите в гит или при запуске job в jenkins, эта самая джоба собирает пакет(rpm\deb) и\или идет на нужный сервер(а) и деплоит его.
Но как и любая другая схема, всё это тоже имеет свои ограничения.
Есть определенные нюансы. Что сальт, что ансибл очень специфически работают с sudo, предполагая что пользователь не имеет ограничений (ака NOPASSWD: ALL) и в audit\securе логе начинает происходить эдакая вахканалия.
Для деплоймент-задачь в jenkins еще можно придумать обходов, но на счет доступа команде(админов) — пришлось отказаться от судо и добавить ssh ключи к root.
Благо, ключи логируются. Да и вообще проблема не нова.
К чему я веду — как бы считаю не совсем правильным давать доступ к системе управления конфигурациями тем, кто не понимает как оно работает, иначе таки очень просто отстрелить себе ногу: salt-ssh host -r 'echo "rm -rf /"'
Про Saltfile — это, безусловно, удобно, но ведь всех проблем не решает. Есть же еще и пиллар данные… в которых чувствительную информацию хочется хранить безопасно.
И вы под командой кого имеете в виду? разработчиков в том числе?
Благодарствую, как-то пропустил его мимо и не пользовался! Пока мне хватло разных ростеров + разные pillar roots, file roots для разных проектов. Но Saltfile выглядит, действительно, удобнее.
Спасибо за статью. Еще один подход к разделению энвайроментов.
На счет тегов. Избыточные теги тоже зло. На мой взгляд (когда применяется бездумно) нарушает KISS и YAGNI.
По этому поводу можно подробней почитать здесь
У нас на порядок меньше хостов, но я с вами солидарен. Есть впечатление, что ребята из saltstack занимаются созданием фич, при этом обратная совместимость прихрамывает. Баги касательно salt-ssh у них также в очень низком приоритете.
Трудно сказать как дела обстоят с ansible, но есть предположение что получше. т.к. последний изначально проектировался под push метод работы и находится под крылом RedHat.
С python у меня лично не было проблем, кроме одного случая с багом в file.rescue, когда требовался python-msgpack. Но это довольно быстро починили.
Ansible в плейбуках использует свой собственный DSL (with\when\register\etc), а Jinja2 используется уже для templates.
Также, обработка циклов и условий осуществляется на уровне индивидуальных тасков.
Не сочтите за рекламу salt (в нем полно своих косяков), но эти различия довольно хорошо показаны по уже упомянутой ссылке.
SaltStack использует Jinja2 и для логики.
Причем, при желании там такого можно наворотить, что грустно становится....
Простите, не заметил что перевод.
В целом с вами согласен. Но лично я понимаю SRE как среднее между "Тип 1" и "Тип 2".
Подробнее об описании зоны ответственности SRE написано здесь:
https://landing.google.com/sre/interview/ben-treynor.html
https://landing.google.com/sre/book/chapters/introduction.html
https://landing.google.com/sre/book/chapters/evolving-sre-engagement-model.html
Позвольте узнать, а где вы откопали такое определение SRE?
Мне кажется идея Site Reliability Engineering дефакто соотвествует "Типу 2", описанному в статье.
И да, в терминологии DevOps явно забыли Qa. Видимо, название DevOpsQa не очень благозвучно.
Благодарю за ответ!
Руками(через CM) обновлять достаточно время-затратно ;) Нужен постоянный напильник. Когда k8s не профильное направление, невольно хочется готовых production grade тулзов.
Как kops работает в aws весьма нравится, будем ждать ) Tectonic имел в виду как инсталлер для бареметал\квм.
Благодарю за ответ!
По моему опыту работать с базами локально значительно проще, чем в кубере (когда дело доходит до нестандартных случаев, рекавери и прочего), но не всегда хочется деплоить доп. сервера -)
Еще вопрос на счет flunetd-clickhouse. ClickHouse ведь любит хорошо определенные структуры. Но логи то далеки от этого. Вот лог нжинкс, вы целиком в столбец таблицы кладете или как-то распарсиваете (например, чтобы было можно сделать выборку по http response code, upstream_response_time)?
Вообще хотелось бы с nginx-ingress-controller слать логи в json. И класть их в clickhouse уже в структурированном виде. Насколько это просто\сложно сделать (в рамках loghouse)?
Спасибо за статью!
Интересует а как вы обновляете кластера кубернетес, особенно которые на квм\бареметал? А также существует ли регулярная процедура\полиси апдейта? используете ли tectonic ?
Спасибо больше за статью и проект! Очень нужный стек!
Поддержку вопрос hostmaster, не рассматривали
fluentbit
как легковесный коллектор?
Также хотелось бы деталей по использованию clickhouse в кластере k8s. Какой тип волюмов используете? cephfs? есть ли проблемы с проседанием перфоманса? pod clickhouse привязан к какой-то конкретной ноде?
можно хранить, например, в ansible-vault
для амазона https://github.com/kubernetes/kops хорош
Ясно, благодарю!
Со своей стороны использую ansible + ansible-vault для раскатки yaml kubernetes. Но конфигурация сервисов отделена от кода проекта.
Спасибо за доклад!
как поступаете, когда yaml (конфигурация сервиса) содержит sensetive data ?
Я тоже делал похожие кастыли (packer+libvirt+python-script+dhpcd) ну и время старта квм-виртуалки на нормальном железе это секунды… но по хорошему cobbler решает большинство вопросов, а также его можно использовать как dynamic inventory для ansible.
Здесь речь шла о том, что при помощи ansible playbook можно приготовить такой же самый immutable контейнер, просто использовав ansible вместо шела. Это имеет смысл когда на ансибле уже написана автоматизация для сервиса. Ну или, например, для тестирования тех же плейбуков и ролей, но это уже совсем другая история.
В целом я с вами солидарен, преимущества от использования ansible-container для меня не очевидны, если не сказать спорны.
Также, никто не мешает запускать плейбук и в самом docker контейнере, предварительно установив там ansible или взяв уже готовый image c ansible.
полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry. В то время как делать
ansible-container runвидится актуальным для каких-то тестов разве что...Благодарю за развернутые детали. Тут наиболее интересно на мой взгляд это тесное взаимодействие с разработчиками, что они тоже применяют сальт и имеют к нему доступ. Однако, неясно как происходит повторное использование кода для другого проекта. Получается что стейты начинают жить в разных местах....
Касательно ролей, таргетинга и мульти-окружений, меня интересовало применительно к вашей структуре развертывания. Лично я же использую таргетинг по пиллар:
и мульти окружения, которые просто напросто имеют разные пиллар данные, которые назначаются через систему рендеринга pillar/top.sls, впрочем как и роли:
_roles/sphinx_server.sls:
Вообщемто по этому делу я собирался написать отдельную статью.
Сальт на мой взгляд вообще такой сумаcшедший конструктор, что я порой перестаю считать это достоинством. Функционала навернуто ооочень много.
А с этого момента можно поподробней )
Как вы решаете проблему защиты от отстрела ноги? А также проблему чувствительных данных? Девелоперы к ним тоже имеют доступ и могут вносить изменения?
Еще интересно, у вас получается и стейты и пиллар хранятся в одном репозитории + Saltfile?
Также, реализовано ли как-то reuse стейтов между разными проектами?
Используются ли мульти-окружения (dev\stg\etc\prod) и к ним девелоперы имеют доступ?
Со своей стороны могу сказать, что для деплоймента применяю дженкинс. Т.е. при коммите в гит или при запуске job в jenkins, эта самая джоба собирает пакет(rpm\deb) и\или идет на нужный сервер(а) и деплоит его.
Но как и любая другая схема, всё это тоже имеет свои ограничения.
Есть определенные нюансы. Что сальт, что ансибл очень специфически работают с sudo, предполагая что пользователь не имеет ограничений (ака NOPASSWD: ALL) и в audit\securе логе начинает происходить эдакая вахканалия.
Для деплоймент-задачь в jenkins еще можно придумать обходов, но на счет доступа команде(админов) — пришлось отказаться от судо и добавить ssh ключи к root.
Благо, ключи логируются. Да и вообще проблема не нова.
К чему я веду — как бы считаю не совсем правильным давать доступ к системе управления конфигурациями тем, кто не понимает как оно работает, иначе таки очень просто отстрелить себе ногу:
salt-ssh host -r 'echo "rm -rf /"'Про Saltfile — это, безусловно, удобно, но ведь всех проблем не решает. Есть же еще и пиллар данные… в которых чувствительную информацию хочется хранить безопасно.
И вы под командой кого имеете в виду? разработчиков в том числе?
Благодарствую, как-то пропустил его мимо и не пользовался! Пока мне хватло разных ростеров + разные pillar roots, file roots для разных проектов. Но Saltfile выглядит, действительно, удобнее.
Спасибо за статью.
Еще один подход к разделению энвайроментов.
На счет тегов. Избыточные теги тоже зло. На мой взгляд (когда применяется бездумно) нарушает KISS и YAGNI.
По этому поводу можно подробней почитать здесь
У нас на порядок меньше хостов, но я с вами солидарен. Есть впечатление, что ребята из saltstack занимаются созданием фич, при этом обратная совместимость прихрамывает. Баги касательно salt-ssh у них также в очень низком приоритете.
Трудно сказать как дела обстоят с ansible, но есть предположение что получше. т.к. последний изначально проектировался под push метод работы и находится под крылом RedHat.
С python у меня лично не было проблем, кроме одного случая с багом в file.rescue, когда требовался python-msgpack. Но это довольно быстро починили.
Ansible в плейбуках использует свой собственный DSL (with\when\register\etc), а Jinja2 используется уже для templates.
Также, обработка циклов и условий осуществляется на уровне индивидуальных тасков.
Не сочтите за рекламу salt (в нем полно своих косяков), но эти различия довольно хорошо показаны по уже упомянутой ссылке.
SaltStack использует Jinja2 и для логики.
Причем, при желании там такого можно наворотить, что грустно становится....