Pull to refresh

Comments 21

UFO landed and left these words here

да, все верно, chef клиент можно запускать в таком режиме ( здесь правда уместнее говорить о команде knife ssh — но разница небольшая относительно вашего примера ).


возможно я не очень аккуратно выразился. вот что хотелось сказать — иногда мне хочется описать какую-либо конфигурацию ввиде сценария и тут же запустить все это на целевом сервере, в случае с шефом у вас всегда есть шаг связанный тем, что сценарий должен быть добавлен в виде кукбука на шеф сервер ( если это конечно не chef-solo но я здесь его не рассматриваю ) и только заетм шеф клиент ( когда вы его запускаете по ssh) запрашивает данный кукбук с шеф сервера (pull) — это определяет определенные накладные расходы на цикл разработки и тестирования кукбуков ( грубо говоря вы все время вынуждены делать knife upload каждый раз внося изменения в кукбук, плюс добавьте время когда шеф клиент скачает новую версию кукбука при запуске и т.д. ), в случае же с ansible или sparrowdo у вас нет этого лишнего шага, вы просто копируете ( в том или ином виде ) сценарий по ssh на целевой сервер и сразу же его выполняете…


В общем случае это не такая большая разница, но я считаю все же возможность быстро прогнать изменения очень важна при разработке. Так вот идея в том, что там где это уместно — писать сценарии на sparrowdo — это быстрее и проще, при этом это не отменяет основной цели — тестирования и разработки шеф кукбуков ( поэтому я и сказал в самом начале что использую эти два инструмента в связке ).

UFO landed and left these words here

Мне кажется мы начинаем уходить немного в сторону от того что я хотел сказать в статье, здесь акцент не на времени исполнения ( хотя опять таки же накладные расходы в случае с использованием chef как клиент сервер есть ) или там на сравнении pull с push архитекурой. А на том, что можно использовать шеф вместе со Sparrowdo, при отладке сценариев управления конфигурациями.


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

UFO landed and left these words here

Смотрите, в случае когда вы запускаете шеф как клиент серверное приложение что де факто основной способ использования шеф возникают те самые накладные расходы с тем что вы все время вынуждены "прокидывать" изменения в коде через шеф сервер ввиде кукбуков. Если сравнивать шеф сервер по этому параметру с тем же ansible или Sparrowdo, то последние imho выигрывают по причине отсутствия лишнего звена в цепочки ввиде шеф сервера.


Но давайте я скажу ещё раз — акцент этой статьи не на этом. Возможно я не очень аккуратно применил термин push based в данной статье, что увело нас в сторону.


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


Примеры? Мне кажется я как раз их и привёл достаточно. Ещё раз — тестирование системы после отработавшего шеф клиента, установка или настройка чего-либо что нужно по каким-то причинам прямо здесь и сейчас, но совершенно не требуется для успешной работы самих шеф кукбуков и самое главное не является целевой конфигурацией. А так же дополнительная настройка системы с целью воспроизведения граничных условий или багов. Как отработает мой шеф рецепт — если в системе уже будет установлен пакет такой-то версии или если не будет существовать такой-то пользователь? И так далее и тому подобное. Так вот — приведение трестируемого окружения к требуемому состоянию лучше из шефа выносить, так же как и сами тесты.
.


Пример с остановкой сервиса nginx перед запуском шеф кукбуков очень показателен, вам необходим выполнить остановку сервиса только ради тестирования кукбука? нет совершенно никакого смысла делать это через какой-то вспомогательный кукбуков или что ещё хуже вносить это в тестируемый кукбук. Гораздо проще это сделать "прямо и по месту" через Sparrowdo как я показал это в статье. Ведь по сути данная операция ( остановка сервиса ) вам нужна только на момент тестирования кукбука и все. Нет смысла вносить ее в шеф.


Здесь как раз хочется показать что использование только одного инструмента не всегда является best practice

UFO landed and left these words here

Мы можем даже убрать из статьи строчку про "который в отличие от chef является push based инструментом ..." и от этого ее суть не изменится. Предалагаю вам это сделать мысленно )) и перечитать…

UFO landed and left these words here

Смотрите вы тут много чего написали, но по-моему путаете понятия. Тестовое и продакшен окружения не имеют никакого отношения к тому что я писал. Ещё раз, хотя мне кажется я уже и так достаточно ясно до этого выразился. Иногда хочется протестировать поведение шеф рецептов в некоторых условиях. Эти условия можно назвать граничными в том смысле что они с вероятностью могут привести к нештатному поведению шеф рецептов. Или ещё более крайний случай — вы поймали баг и вам необходимо убедится что баг пофикшен после изменения кода кукбука, но опять таки же баг воспроизводился при определённых условиях. Цель ваших шеф рецептов — прведение ситсемы в правильное состояние, если вы будете вносить в эти же рецепты сценарии по воспоизведениею каких-то нецелевых конфигураций вы тем самым только все усложните. Смешивание кода для тестирования ( а воспроизведение системы в состояние когда баг проявляется — так же является тестированием ) с кодом трестируемого приложения — очевидный антипаттерн в разработке, причём не важно в какой.


Как раз таки разделение сценариев на Sparrowdo / chef позволяет разделять логически разный код на уровне разных инструментов.


Примеров я вам привёл уже достаточно, я если честно не вижу смысл ещё в какой-то более подробной детализации.

UFO landed and left these words here

Да и кстати написание wrapper кукбука это как раз imho костыль, который можно избежать с помощью Sparrowdo.


Во-первых вы создаете некоторую сущность которая вам нужна только для тестирования и заметьте загружаете ее в шеф сервер, как только вы закончите тестирование вам как придётся этот кукбук оттуда удалить, потому что он перестанет быть нужным. И заметьте у вас всегда будет как минимум один а то и несколько таких вспомогательных кукбуков или рецептов на каждый из тестируемых. Фактически вы плодите тем самым в шефе новые сущности, за которыми потом ещё надо следить и о которых очень легко потом забыть. В случае со sparrowdo — это просто один или несколько файлов положенных в SCM вместе с кодом кукбука и все. Шеф ничего о них не знает и вы никак не "загрязняете" его пространство кодом вспомогательных рецептов. Это кстати примерно то как работает тот же test- kitchen/serverspec например.


Во-вторых сам шеф плохо подходит для тестирования инфраструктуры, все более или менее популярные решения для этого как раз вынесены за рамки шеф рецептов ( кроме пожалуй chef minitest handler, который как написано на странице проекта — in low maintainance mode ) — можете сами посмотреть если интресно — serverspec, inspec, goss и так далее — ссылки я приводил в статье )

UFO landed and left these words here
Хотелось бы все же знать о величине этих накладных расходов

Вы почему-то все продолжаетесь цепляться за уже проговоренную нами тему ))) целью этой статьи было показать как разные виды задач относящиеся к разработке и отладке и тестированию рецептов шеф удобно решать с помощью разных инструментов, а не выбор инструмента которорй будет работать быстрее. И таки да, то что soarrowdo в своём цикле работы не требует промежуточного сервера я считаю плюсом по отношению к шефу запускаемым в режиме клиент-сервер. Но попытайтесь услышать меня ещё раз — это НЕ ТО почему я использую шеф в связке со Sparrowdo ( ну или наоборот, как вам угодно ) причины скорее идеологические ( разные виды задач и исходя из этого изоляция кода на уровне разных инструментов ) чем технические. Просто к слову пришлось я и сказал что вот дескать в soarrowdo такая архитектура запуска а у шеф такая-то, но в данном случае их не это главное, а главное то, что вы решаете разные задачи разными ( более подходящими ) инструментами и это хорошо. Надеюсь это поможет.

UFO landed and left these words here

Давайте так, я дискуссию продолжать смысла не вижу, мне кажется, я уже достаточно обосновал свою позицию. Предлагаю обсуждение закрыть, не потому что мне нечего сказать на все ваши ремарки, а просто я чувствую ( может конечно субъективно ) что мы попросту впустую тратим время и разговор уходит в деструктивное русло. Вы, кстати начали с того что вы шефе не спец — ну дак возьмите и попробуйте его поиспользовать, потом soarrowdo с ним или без него и сравните, и тогда уже из вашего практического опыта можем поговорить… а сейчас что-то вам доказывать я если честно говоря устал ))) тут как бы дело добровольное. — нравится инструмент — используйте, не нравится — не используйте, никто как бы не заставляет ))) просто иногда что бы реально понять нужно оно вам или нет — необходимо хотя несколько практических примеров реализовать… по крайней мере я так всегда делаю… удачи! )))

UFO landed and left these words here

Я чего-то не понимаю или почему пост в хабе Rust?

Я извиняюсь, добавил этот хаб по ошибке, убрал.

Давайте по порядку отвечу на ваши последние комментарии


  • писать тесты на одном языке есть смысл если вы пишите юнит тесты, когда же речь идёт об интеграционном тестировании, что примерно наш случай, язык написания интеграционных тестов и приведения окружения в требуемое состояние совершенно не обязан быть тем же что и язык на котором написано трестируемое приложение ( в нашем случае кукбуки шеф ). В этом случае, как я уже много раз говорил, выбираем язык, исходя из удобства
  • вся ваша идея с использованием кукбуков для тестирования или кукбуков обёрток мне была ясна с самого начала, я сам так когда-то делал, основной минус этого подхода — сложность поддержания связанная с тем что шеф не предназначен для таких вещей и прямое подтверждение тому, что просто потому что вам нужно что-то поверить в вашей системе ( шеф сервер ) — появляется куча сущностей, которые являются для неё чужеродными. Еще раз — chef — инструмент управления конфигурациями, не надо запихивать в него ( читайте буквально — создавать кукбуки для тестирования ) сценарии тестирования — они должны быть в другом месте. Читайте внимательно мои предыдущие комментарии, я там объяснил почему.
  • в случае со Sparrowdo у вас код для тестирования как раз лежит рядом с тестируемых кодом, и ещё ближе чем в варианте когда у вас есть некие кукбуки обертки которыми вы тестируете ваши другие кукбуки, как я вам уже сказал вы просто кладёте Sparrowdo сценарии рядом с кодом кукбука, куда уж ближе ...
  • основной выйгрыш, который вы получаете со Sparrowdo — это отделение трестируемого от самих тестов ( у вас нет никаких тестовых кукбуков, сосушесвующиз совместно с трестируемыми кукбуками. ) и более короткий цикл запуска сценариев, так как у вас нет необходимости загружать из как кукбука в шеф сервер и вы просто запускаете их напряму по ssh, ваши варианты с копировннием шеф рецептов по scp и использованием шеф соло — ещё одно докозательство того, что в некоторых случаях шеф неудобен для быстрой разработки и отладки
  • так же Sparrowdo отвязывает разработчика пишущего интеграционный или тестируемый код от необходимости даде знать chef dsl а использовать напрямую нативные команды того дистрибутива OC для которого идёт тестирование. Что делает код сценария лаконичней и эффективнее. Шеф хорош когда вы хотите абстрагироваться от "деталей реализации" целевого сервера, но но когда вам нужно чтото подебажить на более низком уровне все приимущества шеф исчезают и он становится неуклюжим. Примеры? Попробуй написать абстрактный код на bash, и запустил его через шеф — у вас возникнет несколько неприятных моментов с этим — но это тема для отдельного поста, может быть когда нибудь об этом напишу. Только не говорите мне про ресурсы execute и bash...
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.