Comments 13
Присутствовал на первых двух. Общение про тренды было интересно послушать хотя бы для того, чтобы составить впечатление о разности взглядов сотрудников ведущих компаний на те или иные организации процессов.
Доклад про паппет оставил впечатление положительное, особенно интересным был момент про доступ к истории терминалов с любого сервера — на мой взгляд, в любой достаточно крупной компании очень даже полезная возможность.
Доклад про паппет оставил впечатление положительное, особенно интересным был момент про доступ к истории терминалов с любого сервера — на мой взгляд, в любой достаточно крупной компании очень даже полезная возможность.
Темы панели по высоким нагрузкам, к сожалению, не актуальные — это был драфт на момент сбора участников, а потом мы приехали в новосиб, выпили пива и сделали программу: www.slideshare.net/alexeyrybak/codefest2014-trends-32877703
С 1-14 в первом видео у организаторов, к сожалению, пошла проблема со звуком, поэтому вопросы из зала пропали
О. Наконец-то посмотрю про технопиар, а то на кодфесте не попал туда
Спасибо.
Смотрел доклад про паппет интересно — но хотелось бы больше подробностей. Особенно про инструменты создания и верификации модулей, ну и про тестирование.
Смотрел доклад про паппет интересно — но хотелось бы больше подробностей. Особенно про инструменты создания и верификации модулей, ну и про тестирование.
Добрый день,
Подробности всегда готов рассказать, если будут чуть более конкретные вопросы, например «как работает вот это?», «как делаете вот то?».
Модули создаем по двум путям:
1. пишем руками, проверяем также руками, далее с помощью «карты сервисов» привязываем «сервис-модуль».
2. когда понимаем, что модуль (кусок манифестов или целиком) можно(нужно) формировать автоматически – пишемкостыль скрипт, который как-раз и будет формировать модуль по заданному нами сценарию.
Что касается тестирования: разные окружения, puppet parser validate, оценка времени выполнения/применения тех или иных ресурс-типов, использование графов, которые puppet умеет формировать сам, использование визуальных инструментов, например, foreman, в котором удобно смотреть динамику применения манифестов.
external_node scripts не используем и/или используем минимум от этого функционала.
Подробности всегда готов рассказать, если будут чуть более конкретные вопросы, например «как работает вот это?», «как делаете вот то?».
Модули создаем по двум путям:
1. пишем руками, проверяем также руками, далее с помощью «карты сервисов» привязываем «сервис-модуль».
2. когда понимаем, что модуль (кусок манифестов или целиком) можно(нужно) формировать автоматически – пишем
Что касается тестирования: разные окружения, puppet parser validate, оценка времени выполнения/применения тех или иных ресурс-типов, использование графов, которые puppet умеет формировать сам, использование визуальных инструментов, например, foreman, в котором удобно смотреть динамику применения манифестов.
external_node scripts не используем и/или используем минимум от этого функционала.
external_node scripts — это имеется в виду External Node Classifier или что-то еще? Насколько я понял из презентации — у вас его роль выполняет foreman, не?
Интересен полный workflow создания модулей.
Попробую сформулировать идеальный workflow (как я его себе представляю) и в нём расставить вопросы, а вы уж не обессудьте поправить где что не так.
* вот разработчик начинает делать новый модуль, и вот сделал.
* сначала он проверяет его работу на локальной машине [предположение]?
* пишутся ли тесты? rspec, smoke, integration, ещё какие-то? всегда ли? в каких случаях не пишутся?
* ну предположим, что разработчик написал не только модуль, но и все тесты к нему и локально эти тесты для этого модуля проходят.
* Что дальше?
* Предположим, что дальше было бы здорово проверить что этот модуль не свалится в связке с другими модулями (интеграционный тест). Есть такое? Как проверяете?
* Предположим, что разработчик решил, что его код достаточно стабилен и отправляет его на сервер. Что там? Снова тесты прогоняются? На отдельно выделенном сервере? Создаются ли какие-то чистые виртуалки на которых проверяются разные конфигурации? Или выкатывается на какую-то часть production серверов?
Ну и еще:
При обновлении модулей, обновление сразу везде накатывается? Или по частям — сначала на 5 серверов, если всё ок, то еще на 5? А что будет если обновление вызвало бяку и надо его срочно откатить (довольно болезненный для меня вопрос в своё время).
Используете environment-ы в puppet-e? mcollective? hiera?
Интересен полный workflow создания модулей.
Попробую сформулировать идеальный workflow (как я его себе представляю) и в нём расставить вопросы, а вы уж не обессудьте поправить где что не так.
* вот разработчик начинает делать новый модуль, и вот сделал.
* сначала он проверяет его работу на локальной машине [предположение]?
* пишутся ли тесты? rspec, smoke, integration, ещё какие-то? всегда ли? в каких случаях не пишутся?
* ну предположим, что разработчик написал не только модуль, но и все тесты к нему и локально эти тесты для этого модуля проходят.
* Что дальше?
* Предположим, что дальше было бы здорово проверить что этот модуль не свалится в связке с другими модулями (интеграционный тест). Есть такое? Как проверяете?
* Предположим, что разработчик решил, что его код достаточно стабилен и отправляет его на сервер. Что там? Снова тесты прогоняются? На отдельно выделенном сервере? Создаются ли какие-то чистые виртуалки на которых проверяются разные конфигурации? Или выкатывается на какую-то часть production серверов?
Ну и еще:
При обновлении модулей, обновление сразу везде накатывается? Или по частям — сначала на 5 серверов, если всё ок, то еще на 5? А что будет если обновление вызвало бяку и надо его срочно откатить (довольно болезненный для меня вопрос в своё время).
Используете environment-ы в puppet-e? mcollective? hiera?
external_node scripts — это имеется в виду External Node Classifier или что-то еще? Насколько я понял из презентации — у вас его роль выполняет foreman, не?
именно External Node Classifier и именно его мы не используем.
Foreman используем для «посмотреть как там дела» + завязаны какие-то тригеры мониторинга, не особенно приоритетные, а так «чтобы в курсе быть».
По поводу модулей: у вас очень идеальное представление :) В нашем случае _несколько_отдаленно_ модуль – это описание того или иного сервиса, т.е. почти сервис == модуль в паппете.
Привязка модуля осуществляется по карте, по примеру должен быть модуль на сервере или нет. Забегая вперед, раз уж вы спрашивали про hiera – именно тут в том числе она у нас используется. Также отвечая на возможный вопрос «а что делать, если модуль на этом сервере больше не нужен? нужно же что-то удалить, остановить и прочее»: для нас «дешевле» в этом случае отправить машину на полный цикл ресетапа, нежели заниматься точечной чисткой. Готового и на 100% отработанного решения по подобной чистке паппетом у нас нет, есть только мысли.
Далее… Разработчики у нас не пишут модулей для паппета, да и чего бы то ни было для него они не пишут, всем этим занимается команда эксплуатации.
Проверка на локальной машины – только синтаксис, все остальное проверить невозможно в силу не одинаковой среды на localhost и боевой или условно боевой машине.
Т.е. отвечая на вопросы про тесты – тесты не пишутся, по крайней мере в том виде, в котором они могут быть знакомы разработчику.
Связка с другими модулями – это не частый кейс, т.к. чаще всего один модуль == один сервис. Один сервис – это не тоже самое, что одна служба, т.е. это вполне может быть некой связкой многих файлов, многих служб. Получается, что сервисы изолированы, а значит и модули в большинстве своем тоже. Однако проверка работы в связке с остальным осуществляется на неком devel-окружении, который представляет собой очень близкую копию production окружения, но работает на виртуальных машинах.
Дальше, если на devel все ОК, то осуществляется точечная проверка в production окружении. Условно увеличение применения в геометрической прогрессии. Часто получается так, что если 1-2 ноды применили изменения удачно – бояться нечего.
При обновлении модуля: этап проверки в devel окружении может быть опущен, но выкладка происходит постепенно в том случае, если модуль значимый, если нет — можно и везде обновить. Тому, кто занимается обновлением заранее известны последствия.
Для отката – откат в git до последнего стабильного состояния.
environments используем, нам очень нравится. Также используем stages, тоже удобно.
mcollective – да, для получения разных отчетов (мелких и быстрых, для себя, не бюрократических), а также для выполнения команд на серверах (быстро и удобно).
Про hiera я ответил чуть выше – да используем, чем дальше, тем больше.
Постарался ответить максимально подбробно, надеясь на то, что вопросы понял верно. Если интересно что-то еще – спрашивайте.
Спасибо за ответы.
Мне действительно интересно поговорить об этом =) Поэтому я позволю себе добавить несколько комментариев, и задать еще несколько вопросов.
> По поводу модулей: у вас очень идеальное представление :)
Есть такое. =) Понятно, что реальность полна компромиссов.
> для нас «дешевле» в этом случае отправить машину на полный цикл ресетапа, нежели заниматься точечной чисткой. Готового и на 100% отработанного решения по подобной чистке паппетом у нас нет, есть только мысли.
Вот я тоже не нашёл хорошего и простого способа откатывать изменения с паппетом. Теоретически, есть идеи — в духе писать для каждого изменения скрипт отката, но времени это потребует неприлично много. И если есть возможность пересоздать систему с нуля, то лучше так и сделать.
> Далее… Разработчики у нас не пишут модулей для паппета, да и чего бы то ни было для него они не пишут, всем этим занимается команда эксплуатации.
Моя логика: создание модуля для паппета — это разработка, так что человек создающий модуль в момент создания модуля вполне может быть назван разработчиком.
> Проверка на локальной машины – только синтаксис, все остальное проверить невозможно в силу не одинаковой среды на localhost и боевой или условно боевой машине.
1) Я вас здесь недопонимаю. Имхо — модули бывают разными. Могут быть линейным, а могут содержать какую-то простейшую логику (и в зависимости от параметров/фактов выполнять разные действия). И вот эту логику не так-то просто протестировать в реале, зато с этим отлично справляется rspec. Но rspec тесты ещё нужно написать. Впрочем, если тестов нет, то и тестировать нечего.
2) По поводу неодинаковой среды. Есть же виртуальные машины + vagrant. С ним можно довольно быстро поднять виртуалку + выполнить нужные скрипты. Всё в консоли. Неужели не используете?
У меня появилось подозрение, что говоря о модулях мы возможно о говорим о немного разных вещах. По крайней мере я.
Так вот, модуль в моём понимании может быть как
1) библиотечный модуль реализующий какой-либо функционал (скачивание и распаковка файла, установка и настройка какого-либо сервиса в зависимости от переданных параметров) — в общем, то что обычно выкладывают на puppet.forge.
2) конкретный модуль, делающий конкретное дело. Обычно такие модули либо используют другие модули (библиотечные) с конкретными параметрами, либо просто заточены на выполнение простейших действий. Эти, как мне кажется, почти всегда можно заменить парой библиотечных и внешним конфигуратором типа hiera.
> Т.е. отвечая на вопросы про тесты – тесты не пишутся, по крайней мере в том виде, в котором они могут быть знакомы разработчику.
А почему? Было ли это осознанным выбором? (или может просто никто не заморачивался изучением этого вопроса)
Про выкладку по частям — очень разумно. Я тоже так делал. А вот stages у себя не использовал — как-то не придумал применения.
Мне действительно интересно поговорить об этом =) Поэтому я позволю себе добавить несколько комментариев, и задать еще несколько вопросов.
> По поводу модулей: у вас очень идеальное представление :)
Есть такое. =) Понятно, что реальность полна компромиссов.
> для нас «дешевле» в этом случае отправить машину на полный цикл ресетапа, нежели заниматься точечной чисткой. Готового и на 100% отработанного решения по подобной чистке паппетом у нас нет, есть только мысли.
Вот я тоже не нашёл хорошего и простого способа откатывать изменения с паппетом. Теоретически, есть идеи — в духе писать для каждого изменения скрипт отката, но времени это потребует неприлично много. И если есть возможность пересоздать систему с нуля, то лучше так и сделать.
> Далее… Разработчики у нас не пишут модулей для паппета, да и чего бы то ни было для него они не пишут, всем этим занимается команда эксплуатации.
Моя логика: создание модуля для паппета — это разработка, так что человек создающий модуль в момент создания модуля вполне может быть назван разработчиком.
> Проверка на локальной машины – только синтаксис, все остальное проверить невозможно в силу не одинаковой среды на localhost и боевой или условно боевой машине.
1) Я вас здесь недопонимаю. Имхо — модули бывают разными. Могут быть линейным, а могут содержать какую-то простейшую логику (и в зависимости от параметров/фактов выполнять разные действия). И вот эту логику не так-то просто протестировать в реале, зато с этим отлично справляется rspec. Но rspec тесты ещё нужно написать. Впрочем, если тестов нет, то и тестировать нечего.
2) По поводу неодинаковой среды. Есть же виртуальные машины + vagrant. С ним можно довольно быстро поднять виртуалку + выполнить нужные скрипты. Всё в консоли. Неужели не используете?
У меня появилось подозрение, что говоря о модулях мы возможно о говорим о немного разных вещах. По крайней мере я.
Так вот, модуль в моём понимании может быть как
1) библиотечный модуль реализующий какой-либо функционал (скачивание и распаковка файла, установка и настройка какого-либо сервиса в зависимости от переданных параметров) — в общем, то что обычно выкладывают на puppet.forge.
2) конкретный модуль, делающий конкретное дело. Обычно такие модули либо используют другие модули (библиотечные) с конкретными параметрами, либо просто заточены на выполнение простейших действий. Эти, как мне кажется, почти всегда можно заменить парой библиотечных и внешним конфигуратором типа hiera.
> Т.е. отвечая на вопросы про тесты – тесты не пишутся, по крайней мере в том виде, в котором они могут быть знакомы разработчику.
А почему? Было ли это осознанным выбором? (или может просто никто не заморачивался изучением этого вопроса)
Про выкладку по частям — очень разумно. Я тоже так делал. А вот stages у себя не использовал — как-то не придумал применения.
Вот я тоже не нашёл хорошего и простого способа откатывать изменения с паппетом. Теоретически, есть идеи — в духе писать для каждого изменения скрипт отката, но времени это потребует неприлично много. И если есть возможность пересоздать систему с нуля, то лучше так и сделать.
Тут я с Вами полностью согласен. Есть еще вариант использовать:
ensure => ${some_if} ? {
'val1' => present,
'val2' => present,
default => absent; #for example
}
В данном случае, если говорить о нашей «карте», то читать это можно как: если сервис должен работать на этой ноде, то ресурсы там должны быть, иначе – это лишнее и нужно удалить. Но реалии таковы, что слишком уж много всего было написано до осознания того, что можно использовать нечто подобное. В данный момент применение подобной маски несет некоторые сложности, по большей части из-за того, что нужно переписывать «старое».
Моя логика: создание модуля для паппета — это разработка, так что человек создающий модуль в момент создания модуля вполне может быть назван разработчиком.
Я ни в коем случае не против, пусть так.
2) По поводу неодинаковой среды. Есть же виртуальные машины + vagrant. С ним можно довольно быстро поднять виртуалку + выполнить нужные скрипты. Всё в консоли. Неужели не используете?
Можно быстро, да, НО: для того, чтобы поднять/развернуть копию той среды, в которой на самом деле будет применяться окружение/модуль/манифест нам не достаточно просто поднять образ под Vagrant. Для этого уже есть готовое окружение с виртуалками, которое сильно ближе к реалиям. Т.е. зачем нам что-то гонять на машине «разработчика», если мы можем тестировать (безболезненно, в том числе и с --noop, на условно боевой инфраструктуре).
Про модули: прочитав ваше понимание, я не думаю, что мы говорим о разном. За исключением того, что мы не часто прибегаем к помощи открытых модулей с puppetforge.
Модуль – это описание чего-то законченного (это, конечно, относительно). Т.е. в нашем случае, если мы хотим описать тот или иной сервис модулем – это ни в коем случае не говорит о том, что модуль не модет использовать некоторые куски из других модулей. У нас есть условно оговоренная иерархия модулей, т.е. в момент написания мы можем на 100% быть уверенны в том, что использование каких-то структур, объектов, глобальных переменных нам разрешено и доступно, т.к. это применено к ноде на более раннем этапе.
А почему? Было ли это осознанным выбором? (или может просто никто не заморачивался изучением этого вопроса)
Да, это было осознанным выбором, потомучто никто не заморачивался :)
stages очень удобно использовать, например для того, чтобы обновить список репозиториев на target system, например:
условимся, что у нас есть 2 доп. стейджа, не считая main stage. Картинка будет выглядеть, например вот так.
1. stage «pre»
2. stage «main» #default
3. stage post
зачем нужен pre? ну например, нам нужно залочить версии определенных пакетов, чтобы на основном стейдже быть точно уверенным в том, что на системе уже стоит то, что нам нужно и нужных версий, некоторая подстраховка. Также, если мы хотим использовать те или иные пакеты в основном стейдже, то нам надо быть уверенными в том, что все нужные custom репозитории объявлены и работают – это мы тоже сделаем на подготовительном стейдже.
«stage main» – тут все понятно
«stage post» – тут мы можем подчистить за собой и/или выполнить какие-то завершающие процедуры.
Единственный минус стейджей или то о чем нужно помнить – у них своя область видимости, наследования классов и вот этого вот всего.
Спасибо за ответы!
> Тут я с Вами полностью согласен. Есть еще вариант использовать:
В принципе да. Но может возникнуть еще необходимость отката стороннего пакета, например. В общем и целом, автоматизированная переустановка узла с нуля — это наверно наиболее оптимальный способ.
А кстати, (может и было в какой статье, но я позабыл), а вы с помощью puppet-a только окружение настраиваете, или deployment тоже делаете?
И еще интересующий меня вопрос — не сталкивались вы с ситуацией, когда надо с помощью паппета управлять сенситивными данными (например конфигурационными файлами с паролями), но при этом сами данные спрятать даже от тех кто имеет доступ к исходникам модулей и может управлять паппетом — создавать/удалять ноды? И если да, то как решали? Или как решили бы, если б пришлось столкнуться? =)
> Тут я с Вами полностью согласен. Есть еще вариант использовать:
В принципе да. Но может возникнуть еще необходимость отката стороннего пакета, например. В общем и целом, автоматизированная переустановка узла с нуля — это наверно наиболее оптимальный способ.
А кстати, (может и было в какой статье, но я позабыл), а вы с помощью puppet-a только окружение настраиваете, или deployment тоже делаете?
И еще интересующий меня вопрос — не сталкивались вы с ситуацией, когда надо с помощью паппета управлять сенситивными данными (например конфигурационными файлами с паролями), но при этом сами данные спрятать даже от тех кто имеет доступ к исходникам модулей и может управлять паппетом — создавать/удалять ноды? И если да, то как решали? Или как решили бы, если б пришлось столкнуться? =)
deployment – xCAT, тут есть статья, а также запись выступления с #YaC2013.
По поводу второго вопроса: мы целиком и полностью доверяем тем, кто пишет манифесты всю ту информацию, что может быть там описана.
Если бы пришлось делать что-то подобное, то я думаю, что встал бы вопрос описания некоторого внешнего ресурса, который содержал бы в себе скрытые данные, т.е. в описании манифеста достаточно было бы указать какую-то маску в этом ресурсе(при первой прикидке: ментейнер действовал бы вслепую, полагаясь на валидные данные в источнике). Но это очень отдаленно и абстракнто, из серии – что в голову пришло.
По поводу второго вопроса: мы целиком и полностью доверяем тем, кто пишет манифесты всю ту информацию, что может быть там описана.
Если бы пришлось делать что-то подобное, то я думаю, что встал бы вопрос описания некоторого внешнего ресурса, который содержал бы в себе скрытые данные, т.е. в описании манифеста достаточно было бы указать какую-то маску в этом ресурсе(при первой прикидке: ментейнер действовал бы вслепую, полагаясь на валидные данные в источнике). Но это очень отдаленно и абстракнто, из серии – что в голову пришло.
Орги поправили звук в первом видео, теперь должно быть все слышно.
Sign up to leave a comment.
Видео докладов с конференции CodeFest 2014