DevOps — всё

Автор оригинала: Michael DeHaan
  • Перевод
[Этот материал представляет собой перевод серии твитов Майкла ДеХана, одного из создателей популярного движка автоматизации Ansible — прим.перев.]

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

Тем, кто скажет, что это было непопадание продукта в рынок, или что мне следовало подождать подольше — при всём уважении, вы неправы. Я знаю об этой сфере намного больше любого, кроме пяти людей в мире :-) Причины этого интересны…

По сути (1) agile-график означает, что на работе ни у кого нет времени, (2) DevOps не смог сработать так, как задумывалось. И тому, и тому понадобилось время для постепенного проявления, и причинения вреда. Честно говоря, около 12 лет.

DevOps [-подход — прим.перев.] должен был стать похожим на гибрид разработки и администрирования [development/operations — прим.перев.], но вместо этого люди делают обыденные инструменты, а разработчики делают массу того, к чему привычны администраторы. А администраторы становятся *ещё более* системными администраторами, чем были хотя бы в середине этого срока [в 12 лет — прим.перев.]

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

В нашем же случае множество обсуждений указывает на то, что все заняты, ни у кого нет времени, а ещё… вcё больше и больше заинтересованы в решениях типа «мало кода/нет кода». Это не касается открытых исходников в целом, а только сегмента IT-администрирования.

Оглядываясь назад, на обсуждения лицензирования (Mongo, Redis, Confluent) — они были правы, защищаясь от «облачных» злоупотреблений, но это говорит и ещё о чём-то: чтобы начать это делать, им пришлось встретиться с уменьшающейся ценностью взаимодействия с сообществом.

Верно, не все предлагаемые улучшения всегда хороши, но взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде. Вы бы, наверное, подумали, что если кто-то написал одну из тех штук на GitHub, что получают наибольшее количество запросов на улучшение, то люди захотели бы попробовать его новые штуки и поделиться идеями, но на моём форуме — только 60 участников, и только 10 из них заходили за последнюю неделю. Каждый проект клонируется всего лишь дважды в день, и то, скорее всего — автоматически.

Я вижу сильное движение в других областях, типа экосистемы JavaScript. У меня масса энтузиазма касательно открытых исходников и обмена идеями. Я много говорил с людьми, у которых серьёзные проблемы с управлением конфигурацией. Но, в конце концов, взаимодействия не получается.

Программы с открытыми исходниками подпитывают взаимодействие. И, в основном, вот мой диагноз — широкомасштабное выгорание. Оно наступало медленно, и мы его не заметили. Agile и DevOps — выгорание. На мой взгляд, в некоторых областях мы технологически беднее, чем были шесть лет назад. Почему?

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

Мы в основном позволили нашему управляющему софту стать шуткой. Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.

Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу. Вот я и оказался той самой канарейкой — в большей или меньшей степени.

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

Я надеюсь, здесь вовлечённость будет выражаться большими числами. Ну а если нет — его всё равно можно использовать, чтобы напилить клёвые мелодии. Возможно, я погружусь в некоторые интересные штуки по анализу данных, потому что они также интересуют меня.

Как же мы можем починить открытые исходники для IT в общем и в целом? Взгляните, кем должен быть DevOps… он должен быть настолько же разработчиком, настолько же и администратором. Боритесь с agile'ом, который пожирает ваше расписание. Пробуйте новые штуки, придумывайте, изучайте варианты и не пытайтесь быть кем-то ещё.

Блокируйте в Твиттере «адвокатов разработчиков». Мы любим говорить о представленности, но подумайте о том, что для технологий может означать «покупай местное». Поддерживайте мелкие проекты и ISV [независимые производители ПО — прим.перев.]. Взаимодействуйте. Большинство нас питается взаимодействием более, чем всем остальным.

Будущее, в которым мы просто потребляем софт, выпущенный одним из четырёх брендов, кажется мне довольно унылым, особенно если в этом будущем мало кода. Чтобы пережить это объединение, нам нужно разнообразие. И, чтобы к нему прийти, мы должны отвергнуть окостенение практик.

Очень немногие вещи мы делаем наилучшим способом, в основном же — тем способом, которым делают все. Большинство софта, который все хотят использовать — отстой. Ну и какой в этом прикол, ну серьёзно? Откажитесь от посредственности и делайте так, как сочтёте нужным.

Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше. Возможно, мало-помалу мы сможем это изменить.

Но в следующий раз, когда разговор зайдёт о смене парадигмы типа «agile» или «devops», начатый кем-то, кто ни написал, ни построил ничего значительного, будьте вежливыми, но не ведитесь на то, что они пытаются вам впарить.

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

Мы допустили движения, сделавшие это с нами, и допускаем до сих пор. Принятие окостенения [практик — прим.перев.] и наплевательство на качество софта, которые мы все поддерживаем, просто должны прекратиться. IT — инженерное дело, так что относитесь к ним соответственно.

Если это сложно для меня — представьте, каково оно кому-либо без платформы. Для меня OSS было отличным способом познакомиться с массой людей, и кучей радости, и… если я не могу сделать это сегодня — ой…

Все виды крутой помощи, касавшиеся движения OSS, которыми мы наслаждались в RedHat в 2006 — то, во что я уже просто не верю сегодня. Движение не было ошибочным, просто что-то сдвинулось в культуре, и убило его.

Я не могу удержаться от мысли о том, что не потому ли Red Hat была продана не ради дистрибутива, но (согласно объявлению IBM) ради дистрибутива Kubernetes и OpenStack. Они тоже столкнулись с этим? Что каждая большая компания с OSS-проектом думает о вовлечённости, но не может сказать?

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

(всем, кто поставит «плюс» за это, хм… спасибо?)

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Насколько глубоко вы изучаете используемые инструменты?

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 76

    +1

    DevOps и эджайл сделали с индустрией ПО то, что происходило годами и десятилетиями в других сферах. Слава Богу профессионализм ещё в почете. И крутые специалисты найдут себе работу… Но как побочный эффект — опенсурц умер.

      +4
      Боюсь, да: open-source умер в контексте «почитать-код-подумать-внести-свой-вклад-чтобы-стало-лучше». Средней руки спец возьмёт то, что есть, и будет долго ныть в issues, не читая документацию, вместо того, чтобы создать PR/MR.
        +3
        можно подумать кому-то этот PR/MR нужен. Там с той стороны сидят ребята на поддуве у facebook, microsoft или какой-другой компании и у них свой план. А на MR скорее ответят, что его как-то не так оформили или ещё как-то докопаются до мелочей.
          +3

          И соглашусь, и нет. С одной стороны, есть многие проекты, которые с радостью примут правильный PR/MR, т.к. разработчиков всегда не хватает.
          С другой стороны, опен сурс это тоже способ коммерции. И подсадить сообщество на свой продукт и потом продавать его коммерческую версию. И собирать хорошие идеи у сообщества, ничего не давая взамен. И ещё много чего.

            +2
            Здесь бы великолепно смотрелась ссылка на пример такого MR.
              +2

              Да легко:
              https://github.com/async-rs/async-std/pull/122
              https://github.com/withoutboats/romio/pull/106


              Первый ультимативно закрыли из-за смены политики в отношении зависимостей, без предложения отребейзить или поправить код. После чего открыли свой ишью и втроем думают, как же решить проблему, решенную в моем PR. До сих пор не придумали.


              Второй хотят закрыть с аргументом "это троллинг, это спам", потому что это мешает им пиарить свой собственный проект.


              Ребята сидят на поддуве у Ferrous Systems, если что. Вчитываемся в PR, делаем выводы, голосуем/отписываемся.

                0

                Как-то звучит как обида с вашей стороны.

                  +4
                  Когда не принимают PR это всегда обидно.
                  Особенно, когда у твоего PR есть «пальцы вверх».
                  0
                  Второй выглядит конечно странно, но у меня, как человека со стороны, нет ниодной причины подозревать в чем-то кого-то. С чего вдруг дело в пиаре? Неадекватность — это тут видно вполне.

                  По первому, выглядит как типичная ситуация, когда PR сделан без согласования с ментейнерами. Вместо того, чтобы копошиться в нем, править коммиты, можно закрыть его, открыть баг для обсуждения, а уже потом писать решение в новом PR. Никакого криминала. Вам обидно — это другой вопрос. Участвуйте в обсуждении, может придете к компромиссу.
                    +1

                    Первый PR был открыт за полмесяца до смены парадигмы.

                      0
                      И? Это ничего не меняет.
              +4

              Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.


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


              Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.

              Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.

                +2

                Есть разные проекты: в некоторых огородились и туда нереально что-то пропихнуть, даже компаниям, не только индивидуальным разработчикам.
                А некоторые с радостью примут вашу помощь.
                По моим наблюдениям чем старше, больше и сложнее проект, тем меньше шансов на принятие сторонних PR.

                  +1
                  > Средней руки спец возьмёт то, что есть, и будет долго ныть в issues,
                  А что делать… Правда тут есть момент в том, имеет ли место проблема или это «не чтение документации». Если второе то такое быстро закрывается, а первое часто висит годами.

                  > вместо того, чтобы создать PR/MR.
                  Чтобы сделать PR, нужно разобраться в коде, сделать фикс который ничего не сломает, вероятно написать/дописать автотесты, причём в стиле фирмы и ещё много работы. А потом ещё передать права на свою работу, часто без этого не берут PR, типа левый программер, надо поменять лицензию например — обходи потом по всем, собирай разрешения, удаляй их код если они не одобрили.
                  И если не провёл много сотен часов в коде этой утилиты, то часто сделать этот PR это работа даже не на неделю а может быть и больше, тогда как сотруднику — пол дня на всё. С другой стороны, я бы воздержался использовать софт, у которого нужно ориентироваться как в своём чтобы всё работало.

                  Ещё позиция многих людей — это опенсорц, тут никто ничего никому не обязан. И я сам с этим столкнулся, когда видел проблемы, но авторы вместо того чтобы их править, слали пачками письма «купите подписку всего за 3 килобакса в месяц и мы будем решать ваши issue». А сообщество такое «ну и что, имеют право». То есть находишь баг, репортишь, а в ответ «гони бабла». Именно такая позиция и убивает опенсорс. И вызывает желание критические ошибки не разработчикам сдавать, а продавать куда-то как 0day. Или и то и другое сразу.
                  Я конечно понимаю, что работы может быть и так много, а ещё семья-друзья ждут, а ещё — что гораздо приятнее пилить новые фишки чем ловить баги и править старый код, но это противоречие убийственно для опенсорса.
                  Хотя тема вообще-то про devops.
                    +1

                    На самом деле опенсурс и девопс идут рука об руку.
                    Потому что бизнес требует результат вчера, денег на покупку коробочного решения не дает (попробуй обоснуй! к тому же, у "коробок" своих болячек полно), приходится выкручиваться как можешь.

                0
                Хотелось бы в опросе вариант ответа
                «Пишу исходники, и свободно в них ориентируюсь» :)
                  +1
                  А мне бы был полезен другой опрос, про вовлеченность и как ее починить, коллега (:)
                    +1
                    Лично я вполне согласен с рецептами починки от Майкла — собственно, поэтому и сделал перевод, ибо зацепило.
                      +1
                      А какие это рецепты?
                        +2
                        Так вот же:
                        Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше.
                          0
                          Как я понял, автор не знает что делать с повсеместным падением уровня вовлеченности в open source проектах
                          взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде.
                          Симптомом которого было внедрение Agile практик и DevOps. И он не знает, что с этим делать.
                          Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу.
                            +1
                            Всё же, на мой взгляд, внедрение agile и DevOps — пара причин, которые привели к текущей ситуации.
                            Говоря прямо, инструменты, требующие определённого уровня квалификации, пошли в широкие массы. Результат печален: если условный спец умеет/успевает только использовать инструмент, но никак не разбираться в нём детально, то, конечно, никакой вовлечённости этот инструмент в нём не разожжёт, и никаких MR/PR никто от этого спеца не увидит. В лучшем случае — те самые унылые issues, потому что «доку не читай @ в чаты пиши».
                              0

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

                                +1
                                Вот прям повеяло простыми нажатиями кнопки «сделать хорошо» :-)
                                К сожалению, одинаково универсальных инструментов нет, и те, кто это не понимает, всегда будут огорчены тем, что «X не умеет Y, а Z — умеет, но при этом стоит денег». Остаётся только пожимать плечами и вчитываться в исходники очередного инструмента :-)
                        +5
                        Действительно, где тут рецепты? Что в переводе, что в оригинале — мало связный поток сознания непонятно о чем.
                    +6
                    Я думаю проблема ещё заключается в том, что спецы, работающие в компаниях, берут исходники из открытого проекта, дорабатывают его под себя или исправляют ошибки, но обратно в открытый доступ этот код уже не попадает
                      +1
                      Ну это часто нарушает лицензию, да и трудно представить причину не выкладывать фикс если он уже готов. Неужели так трудно оформить PR?
                        +2
                        если используется только внутри компании где было сделано то вообще-то не нарушает, распространять закрытый код без выкладки кода при этом запрещено.
                        Выложить по ошибкам PR проще, чтобы меньше патчить код на новых версиях, но зачастую реализовано то что большинству не нужно, оформлено не как нужно, код надо рефакторить, иногда ломает например работу на arm итд.
                          +1
                          Есть разные ситуации. В некоторых проектах PR висят сотнями, на которые разработчи не обращают внимания. Где-то автор давно забил на поддержку. Где-то с другой стороны сидят люди за зарплату, у которых есть свой взгляд на вещи и более приоритетные таски.

                          Ревью это на самом деле затратно. Нередко в PR предлагают кастыли, решающие чьи-то сиюминутные проблемы. Без тестов, без документации. Превращать интервью в менторинг или найти время, чтобы переписать самому? Снизить издержки можно. Для этого надо знакомить потенциальных контрибьютеров с принятыми правилами, архитектурой, вкладываться в документацию. На это опять же нужно время и набор самостоятельных скиллов.
                        +4

                        Автор ансибла недоволен софтом с багами? Удивительно.

                          0
                          Вот прям с языка снял. Настолько слабодокументированной и баг-на-баге-багом-погоняет системы — еще поискать! Настолько, что под свои задачи хочется сесть и написать свой ансибл…
                            +3
                            А кто же мешает? Напишите! Возможно, ваши задачи окажутся близки кому-то ещё, и мы станем свидетелями рождения нового замечательного инструмента управления конфигурацией — проявится то самое взаимодействие, о котором пишет Майкл.
                              +1
                              Репутация это конечно то, что легко потерять и трудно набрать, но должен сказать что последние версии ансибла гораздо лучше чем все было раньше.
                              С последней 2.9 вообще ничего не сломалось, что никогда не бывало раньше :) А с 2.8 совсем немного проблем было. Наверное к 3.0 будет уже нормальным зрелым продуктом.
                              +1
                              Часто issue создают люди, которые не понимают, как работает та или иная часть/функция/модуль, да ещё и с комментариями — «хочу, чтобы работало вот так».
                                +2

                                Любой ишью имеет ценность. Даже если он именно в ключе "хочу, чтобы работало вот так", но был реджекнут — это уже информация для будущих поколений, что так работать не будет.
                                Другой вопрос, что очень многие ишью дублируют другие (трекер не читай @ ишью создавай) или описаны очень… поверхностно (HELP! HELP! волки!). Или ответ на них есть в доке. И с помощью Ишью легко сделать DOS атаку на представителей разработки конкретного софта. Заведи 100 ненужных ишью — пускай разработчики их разгребают ((((((

                                  +1

                                  Вся катастрофа ансибла — в том, что НИКТО не знает, как оно работает. Как написано — так и работает. Отношения между переменными, import'ами и include'ами — мистика совершеннейшая. Я недавно описывал совершеннейший WTF с import_role, который переопределяет переменные для таски, в которой import, но только вне scope остальных import'ов. Попытка разобраться с этим — это изучение карты минного поля.


                                  А главная проблема ansible — глобальный массив переменных, который иногда притворяется локальными переменными.

                                    +1
                                    В контексте статьи хочу заметить, что исходники Ансибла при этом открыты, то есть всегда есть возможность прочитать и понять, _как именно_ работает. Ну и, конечно же, обсудить с сообществом.

                                    А если этого не хочется по каким-то причинам — всегда можно взять и написать свою систему, которая будет:
                                    • легковесной,
                                    • простой в использовании,
                                    • не будет содержать багов,
                                    • и будет абсолютно бесплатной в использовании.

                                    P.S. Лично я проблем с глобальными переменными не встречаю вовсе — и так уже пять лет!.. По моим ощущениям, чаще источники подобных проблем кроются в непонимании объектной модели Ansible (как говорится, «не о присутствующих», сугубо по опыту чата @pro_ansible).
                                      0

                                      Можно сколько угодно читать исходники Ансибла, если они неконсистенты с заявленной моделью в голове, то "переписать" единственный вариант. Потому что это архитектурная проблема, которая не решается патчкой патчей.


                                      У нас на работе множество людей, которые ни разу не сталкивались с неконсистеностью модели Асибла. Например, все бухгалтеры ни разу не сталкивались с проблемами при написании плейбук ансибла. Повар тоже не сталкивался. А вот операторы и программисты сталкиваются постоянно.


                                      Если вы так уверены в консистености ансибла, то объясните вот это:
                                      https://habr.com/en/company/southbridge/blog/471896/#comment_20769540

                                        0
                                        Что-то я не вижу, чтобы где-то озвучивал подобную уверенность:
                                        Если вы так уверены в консистености ансибла
                                        Во-вторых, если посмотреть на плейбук по ссылке, то вы изменяете глобальные переменные внутри отдельных вызовов ролей и удивляетесь результату. С чем именно консистентен подход с изменением глобальных переменных в отдельных вызовах?
                                          0

                                          Мой вопрос о том, что если import_role меняет переменные на этапе загрузки (как обычно это делает import), то почему последующий импорт не затирает значения предыдущего import'а? Т.е. почему каждая роль получает "своё" значение перменной, но таска, которая "не при делах" получает значение последней роли? Где тут консистентность?


                                          Я вам даже задам другой вопрос. Как вы думаете, что будет, если я эту "глобальную переменную" задам в блоке vars для play? Попробуйте ответить, опираясь на знание в голове, а не на эксперимент.

                                            0
                                            Да не хочу я делать странное, про которое в доке написано «не надо так». Вот есть ссылка, по ней вторым абзацем лежит фраза:
                                            Avoid defining the variable “x” in 47 places and then ask the question “which x gets used”. Why? Because that’s not Ansible’s Zen philosophy of doing things.
                                            В переводе означает «Избегайте определения переменной в 47 местах, чтобы потом не спрашивать, какое значение используется».
                                            Именно так я и делаю.
                                              +1

                                              Как интересно. И каким образом этот дзен консистентен с идеей переиспользуемых ролей?


                                              Допустим, вам надо на сервере x настроить 20 почти одинаковых копий приложения, отличающихся конфигурационным файлом и параметром в template'е systemd.


                                              Есть роль, которая может настроить приложение.


                                              Ваши действия? Желательно, с учётом reusable roles.

                                                +1
                                                А здесь уже вижу запрос на конструктив — респект.

                                                Подобные случаи выглядят достаточно просто: роль, у неё есть набор параметров. Для того, чтобы роль не падала при запуске без параметров, параметры устанавливаются в некие безопасные умолчания через defaults/main.yml.

                                                А сам управляющий плейбук может выглядеть вот так:
                                                ---
                                                - hosts: <hostgroup1>
                                                  roles:
                                                    - role: role1
                                                      param1: value1
                                                - hosts: <hostgroup2>
                                                  roles:
                                                    - role: role1
                                                      param1: value2
                                                


                                                Вполне себе reusable.
                                                  +1

                                                  А в пределах одной play? Я понимаю, что на тривиальных примерах "распилите на два" работает хорошо, но в середине сложного кода "распил" на play может быть неконструктивным. Хорошим примером может быть ситуация, когда долго собираются set_facts до запуска роли.

                                                    0
                                                    Занятно, что в вашем вопросе содержится ответ :-) Сбор фактов часто является самой долго исполняющейся частью плейбука, соответственно, его принято отключать.
                                                    Вариант отключения сбора фактов
                                                    У меня обычно в плейбуках встречается что-то похожее:
                                                    ---
                                                    - hosts: <hostgroup1>:<hostgroup2>
                                                      gather_facts: yes
                                                      tasks: []
                                                    - hosts: <hostgroup1>
                                                      gather_facts: no
                                                      roles:
                                                        - role: role1
                                                          param1: value1
                                                    - hosts: <hostgroup2>
                                                      gather_facts: no
                                                      roles:
                                                        - role: role1
                                                          param1: value2
                                                    


                                                    Ну или если хочется красоты:
                                                    Красота
                                                    ---
                                                    - hosts: <hostgroup1>:<hostgroup2>
                                                      gather_facts: yes
                                                      tasks: []
                                                    - hosts: <hostgroup1>
                                                      gather_facts: no
                                                      roles:
                                                        - role: role1
                                                          param1: "{{ bar  }}"
                                                    - hosts: <hostgroup2>
                                                      gather_facts: no
                                                      roles:
                                                        - role: role1
                                                          param1: "{{ bar  }}"
                                                    

                                                    А переменная bar, соответственно, определена для каждой группы.

                                                    Если прямо совсем нет возможности делать несколько play (плеев? драм?), то вот ссылочка на официальную документацию. Можно заставить роль исполняться несколько раз.
                                                      0

                                                      Т.е. вы предлагаете import_role не использовать. Вполне вариант. Ещё можно не использовать любой произвольный набор модулей, в которых пост-фактум нашлись баги.


                                                      Я не понимаю, почему


                                                         - debug: var=foo
                                                           vars:
                                                             foo: 1

                                                      имеет scope (в пределах task), а


                                                         - import_role: name=foobar
                                                           vars:
                                                             foo: 1

                                                      имеет scope… глобальный, кроме ролей, которым передан vars, который влияет на глобальный scope и в пределах роли.


                                                      Вот моё понимание консистентности не укладывается в эту реальность.


                                                      Хотите ещё смешного?


                                                      - hosts: localhost
                                                        tasks:
                                                         - debug: var=[a,b]
                                                        vars:
                                                          a: '{% if True %}{"x": 1}{% endif %}'
                                                          b: '{% if True %} {"x":1}{% endif %}'

                                                      Расскажите мне, почему a — это словарь, а b — строка. (Я-то знаю, вы мне с точки зрения разумного дизайна объясните).

                                                        0
                                                        Про первое. Я не использую import_role просто потому, что не получу каких-то реальных преимуществ от его использования. А про особенности — см. доку, плюс здесь.
                                                        Исходя из двух указанных мест, лично мне понятно, что я получу определённые проблемы вместе с import_role, не получив абсолютно ничего конструктивного взамен. Тащить в проект что-то новое только потому, что могу — не-а, не моё. Продакшн ведь.

                                                        Про второе. Достаточно спеку YaML'а почитать. По спеке символ пробела разделяет токены YaML. Во втором случае нет пробела — значит, фигурная скобка является просто первым символом в строке, и не образует токен.

                                                        Предлагаю на этом прекратить коллективное чтение документации вслух, т.к. я не уверен, что обсуждение содержит что-то конструктивное/интересное для других читающих. Частные, узкоспециализированные вопросы можете задать в ЛС, на почту, либо в телегу (на выступлениях я указываю контакты в презентациях).
                                                          0

                                                          То есть ваша позиция — "в нём баг, его не надо использовать, а в остальном всё хорошо". Эта позиция применима при любом количестве багов в любом наборе модулей.


                                                          Я import_role использую для интеграции одних ролей в другие. Если роль ставит приложение, вешает алиас IP и конфигурирует nginx для приложения, то если мы делаем таски в include_tasks (потому что у нас список приложений), то без import_role никак. Точнее, я решил проблему с помощью include_role, но это обход индивидуального WTF.


                                                          Насчёт второго — вы не вчитались в пример. И a и b в кавычках, т.е. с точки зрения yaml это одно и то же, а смешное наступает на этапе парсинга вывода jinja.

                                                            +1
                                                            Если у вас задача тестировать ансибл, то я уверен что вы неплохо справляетесь — делать странное и обнаруживать различные непоследовательности это прекрасно.
                                                            Если у вас задача использовать ансибл, то наверное стоит делать по good practices, а не воротить import_role там где не нужно, и жаловаться что работает не так как хотелось бы. Стоит начать с документации и научиться пользоваться ансиблом, он довольно неплохо делает свою работу.

                                                            Насчёт второго — вы не вчитались в пример. И a и b в кавычках, т.е. с точки зрения yaml это одно и то же, а смешное наступает на этапе парсинга вывода jinja.
                                                            Еще один пример настоящего тестировщика, давайте наделаем ошибок и наворотим чего-то, а потом посмотрим как эта тулза с этим справится. ОК, надеюсь вам платят за тестирование.
                                                              0

                                                              Моя задача — сопровождать проекты.


                                                              С ходу:
                                                              Проект 1 (целиком мой):


                                                              find . |grep -v .git |wc -l
                                                              896
                                                              find . -type f |grep -v .git |xargs wc -l
                                                              16412

                                                              Проект 2 (коллективный):
                                                              files: 10225
                                                              lines: 738985


                                                              Проект 3 (общий):
                                                              files: 7821
                                                              lines: 1329654


                                                              Я все эти проблемы находил не "из принципа", а в процессе отладки. Фигня с import_role, например, случилась при переходе с 2.7 на 2.8 (или 2.6 на 2.7? Не помню.), причём была настолько подлой, что проблему поймали уже operations team в продакшене — все тесты проходили на "ура", просто была "небольшая путаница в ip".


                                                              Когда вы говорите "воротить import_role там, где не нужно", у меня к вам вопрос: а где нужно? Вот, вы, например, где используете?

                                                                +1

                                                                Я согласен с коллегой, что ансибл местами непоследователен. В моем идеальном мире тоже все программы без багов и розовых коней по углам. К сожалению, реальный мир не такой. И приходится приспосабливаться к ограничениям инструмента и к тому, что в каждой следующей версии ломают поведение предыдущей. И это не проблема ансибла как такового. А, в целом, всей индустрии.


                                                                все тесты проходили на "ура", просто была "небольшая путаница в ip".

                                                                Во-первых, нужен канареечный релиз, чтобы такое отлаживать. Да, отладка на продакшене. А что делать!?
                                                                Во-вторых, это может приводить к факапам, как, например, у яндекса, с мисконфигурацией сетевых устройств. ЛЕГКО.

                                                                  0

                                                                  Я рад бы делать канареечный релиз в продакшене, но продакшен держит bgp-сессии с роутерами tier1 провайдеров, и сделать a/b-тестирование на tier1 не получается в силу нехватки оных.


                                                                  На самом деле даже a/b ничего не нашло бы, потому что просто перепутались сесии — у всех там full view, так что проблему заметили много позже.

                                                                    +1

                                                                    Вот оно — вот она причина, почему BGP кладется вместе с половиной энторнетов… Это просто админы (недо)освоили ансибл…


                                                                    /я без конкретики, а просто нытье в общем/

                                                                      –1

                                                                      А он кладётся? Обычно страдают только пользователи одного аплинка, либо AS, которым неповезло и чьи префиксы зааносил очередной пакистанский ютубодав.


                                                                      Для того, чтобы это сделать, не нужен ансибл, достаточно чуть-чуть кривых рук.

                                                                  +2
                                                                  Вот, вы, например, где используете?
                                                                  Вряд ли я где-то их использую, у меня везде include_role
                                                                    0

                                                                    include_role обладает своими чудными свойствами. Вот, например (следите за руками):


                                                                    roles/role1/tasks/main.yaml:


                                                                    - set_fact:
                                                                       foo: role
                                                                    - debug: var=foo

                                                                    play.yaml


                                                                    - hosts: localhost
                                                                      tasks:
                                                                        - include_role: name=role1
                                                                          vars:
                                                                           - foo: vars
                                                                        - debug: var=foo

                                                                    Как вы думаете, что будет выведено на экран? Вот я сейчас пример делал, и мне самому страшно стало.

                                                                      +2
                                                                      Ну мне тоже страшно стало от вашего примера, вы же понимаете что это ненормально так делать?
                                                                      Вывелось все по variables precedence.
                                                                      Но больше пожалуйста не ставьте set_fact в роли, если вы собираетесь передать туда данные из внешнего scope. Используйте defaults для этого.
                                                                        0

                                                                        А как же reusable role? Роль делает set_fact, а увидеть не может. У меня, например, очень часто есть такой паттерн:


                                                                        - uri:
                                                                            url ...
                                                                          register: foo_res
                                                                        
                                                                        - set_fact:
                                                                             foobar: foo_res.json.some.field.inside

                                                                        И вот это поломано, например, если роль в одном месте была вызвана напрямую, а в другом была include_role.


                                                                        Выше оратор сказал, что не использует import_role. Теперь, мне, расскажут, что использовать include_role тоже неправильно?


                                                                        PS Пример я писал заново и сам восхитился эффектом. Я такого не ожидал, я думал, будет просто overshadow внутри роли. Что при этом set_fact за пределы роли уедет (а самой роли не достанется) — это для меня новое.


                                                                        Каждый день новость и всё болит (с) анекдот.

                                                                          +2
                                                                          Я не понимаю что тут мешает reusability. Проблема не в том, что роль «не видит» параметер, а в том что вы его грубо перезаписываете :) Я вам дам еще идею, добавьте "-e foo=test" в запуск ансибла, и увидите везде «test». Да, потому что external variable нагибает всех.
                                                                          Сделайте нормальный дизайн, где вы не определяете ту же переменную в 47 местах и не перезаписываете ее десять раз.

                                                                          П.С. Я вообще в курсе проблем ансибла и его багов, как я сказал выше 2.9 была первой версией на моей памяти которая ничего не сломала :) Но роли и их reusability это никак не проблема уже давно, проблема в вашем дизайне.
                                                                            –1

                                                                            Стоп. Если бы оно просто "перезаписало" (как вы предлагаете с -e) — уменя бы не было вопросов. Перезаписало и перезаписало.


                                                                            Но почему, перезаписав, оно использует другое значение? Если я перезаписал значение foo в role, почему в выводе vars? Если я перезаписал значение в vars, то почему в выводе role?

                                                                              +1
                                                                              Потому что когда вы посылаете vars в роль/таск/еще куда-то, то это действует только для этой роли/таска/еще чего-то.

                                                                              Смотрите на примере тасков, будет легче понять:

                                                                              - debug: var=testvar
                                                                              - include_tasks: debug_var.yml
                                                                                  vars:
                                                                                    testvar: nook
                                                                              - debug: var=testvar

                                                                              когда в хостс у вас: testvar=ok

                                                                              Передаваемый testvar: nook действует только в пределах таска. То же самое и с ролями, блоками и т.д. Никакой магии, все по докам.
                                                                              А когда вы выходите из scope роли, то переменная будет равна тому, чему должна по приоритетам, то есть set_fact. Странно? Да, есть немного, но зато все по докам.
                                                                              Но еще страннее передавать значение в роль, которая определяет это значение, и потом после этой роли опять его использовать. Это что-то за гранью.
                                                                                0

                                                                                Странно? Да, есть, много.


                                                                                Это и есть моя главная претензия к ансиблу. Чем больше его используешь, тем страннее.


                                                                                Вот, например, сегодняшнее открытие:


                                                                                ansible_interfaces содержит интерфейсы в нормальном виде (например, br-42), а параметры интерфейса можно посмотреть в ansible_br_42. Просто вздохнуть, дописать в список бесконечного wtf'а, который находишь каждый день, и продолжать.

                                                                                  +1

                                                                                  Сделай свой форк — будь мужчиной )))))

                                                                                    0

                                                                                    Форк делать бесполезно. Ансибл можно брать как inspiration, но не более.


                                                                                    Что ансибл сделал: нашёл правильную модель, нафигачил миллион модулей, решил проблему бутстрапа.
                                                                                    Что ансибл сделал неправильно: катастрофическая модель переменных, wtf-конвертация типов jinja2-питон

                                                                                    +2

                                                                                    Так перестаньте использовать его странными способами, не будете получать странные результаты :)

                                                                                      +1

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

                                                                                        +2
                                                                                        Знаете, вы не первый кто использует ансибл и include_role в нем. Далеко не первый и не единственный. Может все таки проблема не в зеркале?
                                                                                          0

                                                                                          И я единственный, кто жалуется на нелогичность ансибла? Может, проблема всё-таки в системе типизации jinja-python и странной системе переменнных?

                                                                                            +2
                                                                                            Ну, на вкус и цвет… Мне лично система переменных странной не кажется, хотя возможно она и далека от идеала. Но я делаю как мне советуют делать в ансибле, и у меня все прекрасно работает. Я не делаю странных вещей, а потом удивляюсь странным результатам.
                                                                                            Думаю в любом языке программирования можно напортачить с глобальными и местными переменными, путая scope где только возможно и потом жаловаться какие это плохие языки. Но зачем?
                                                                                            А если я вижу реальный баг в ансибл и путь его решения, я делаю патч в ансибл. В основном в модули, конечно, в коре сам черт ногу сломит. Немного попинать на #ansible-devel и патч замержат, еще одной проблемой меньше.
                                                                                              +1

                                                                                              Я думаю, что это честно, что нет local scope variables в ансибле. Вспомните сколько гемора в языках типа С/C++ с этими областями видимости. Нужно реально помнить в каждый конкретный момент времени с какой из одноименных переменных Вы работаете.
                                                                                              Конечно, это работает только в случае, если Вы сами изобретаете эмулируете область видимости путем жесткого применения некоей конвенции о наименовании переменных.


                                                                                              P.S. именно поэтому в классических языках и не рекомендуют делать глобальные переменные, суть — глобальное состояние, т.к. код превращается в лапшу.

                                    +1
                                    У JBoss'a всегда была модель бизнеса: в open source максимум бета, остальное — за деньги. Как говорится: «Не сотвори себе кумира». Кто сказал, что OS — это бесплатно? За все бесплатное кто-то обязательно платит. Это относится в равной степени ко всем модным штучкам, т.к. их чаще всего и делают для привлечения денег. Создали Аджайл — получили целую индустрию коучеров и последователей, назвали одмина DevOps'ом, нет кодить он как не умел, так и не умеет, как плел жгуты так и плетет, но теперь за него можно взять полтийник в час, а не четвертной.
                                      0
                                      Ну допустим, я — девопс. Начинал кодить еще с ассемблера.
                                      Но у девопса минимальная магнитуда влияния на разработчиков и методологию.
                                      Всем заправляют ПМы.
                                        0
                                        Всем заправляют ПМы.

                                        Даже если они есть, то они не обязательно всем заправляют. А ведь иногда их и нет вообще :)

                                          +2
                                          Всем заправляют ПМы.

                                          Это — та реальность, в которой живёте вы, но у кого-то другого ситуация может отличаться: его мнение имеет значение. И только вы можете либо соглашаться со своей ситуацией, либо как-то её менять.
                                          0

                                          спасибо, отличная статья, хороший перевод

                                            +1
                                            Благодарю!
                                            Исходная ссылка где-то в профильных чатах мелькнула, увидел автора — решил прочитать. Понял, что это — «ОГО!», потому что симптомы, описанные в статье, действительно ощущаются: на конференциях и митапах в лучшем случае — делимся своими удачными практиками, а в худшем — просто перенимаем чужие.
                                            При этом есть несколько решений, которые в своих… ну не областях, наверное, а нишах сегмента администрирования стали именно что неписанным стандартом, и ничего принципиально нового не появляется пару-тройку лет точно. Ну правда, а что свежего в сегменте можно вспомнить хотя бы за последний год? Разве ту же VictoriaMetrics, но и всё, пожалуй… Ну а если я ошибаюсь — что ж, с удовольствием не только прочту названия новых продуктов в комментариях, но и попробую хотя бы их потестировать.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое