С 3 и 4 переходить на 5+ смысл есть, потому что там новая хиера - глобальный слой появился (если мне не изменяет память), много интересных бэкэндов; паппетсервер более просто масштабируется, на те же compile-мастера за счёт SRV-записей в DNS нагрузка легче выносится; фактер новый (какие-то новые фичи там точно появлялись, сейчас не назову, какие конкретно); и в целом он уже не похож на говно мамонта. Уязвимости - разумеется, валидно, но, если честно, я не припомню актуальных CVE, которые нас могли бы затронуть. С обновлением ОС всё очень просто на самом деле: так как puppet-agent поставляется со всем необходимым, и никаких внешних зависимостей не тащит - с большой долей вероятности можно ставить пакет для старого дистрибутива на новом дистрибутиве.
Спасибо за информацию, изучим Choria, выглядит интересно. На текущий момент у нас есть внутреннее решение, связанное и с ENC, и с PuppetDB, которое позволяет как запускать некоторые задания через агентов (включая прогон паппета), так и искать хосты, отчёты и факты в pdb.
Тут просто важно понимать, зачем нужно это обновление. Обновление ради обновления - увольте. Если заметно увеличится скорость работы паппетсервера/агента, уменьшится количество зависаний сервера (сейчас регулярно раз в день, а то и чаще, некоторые паппетсервера рестартуются, иначе подвисают по непонятным причинам) - смысл есть. Если просто чтобы циферку больше увидеть - оно не стоит трудозатрат.
автоматическа канареечная выкатка пока ещё на стадии реализации, алгоритм следующий:
пользователь запушил изменения в ветку, в Ci/CD запускаются все локальные проверки (линтеры, unit- и acceptance-тесты)
если локальные проверки прошли успешно, определяем, какие роли затрагиваются изменениями в этой ветке (пока что определение роли делаем ручное, для каждой роли указываем, какие файлы в репозитории на неё влияют; в будущем это можно будет автоматизировать, например, путём анализа каталогов хостов с данной ролью)
для каждой такой роли выбираем канареечные хосты (рандомом; опять же, возможна разметка хостов для того, чтобы всегда использовать или никогда не использовать какой-то хост для канарейки), переводим их в окружение, соответствующее данной ветке, принудительно прогоняем там паппет
запускаем проверки на этих хостах (проверки сделали на основе acceptance-тестов - на каждом хосте стоит inspec, который локально прогоняет acceptance-тесты, в которых подставлены актуальные боевые параметры вместо тестовых)
в зависимости от статуса проверок либо помечаем билд успешным, либо делаем откат изменений (самая сложная часть, потому что универсального рецепта для отката конфигурации без потери данных нет)
мы только что закончили семилетний (!) процесс перехода с Puppet 3.7 на Puppet 7. Процесс был очень долгий из-за того, что хостов много, конфигурации много, тестов ноль - всё это приходилось переписывать и дописывать, концептуально изменения с 3 до 4 и с 4 до 5 версии очень большие, а вот начиная с 5 версии всё более или менее минорное (я не читал подробный changelog 8 и последующих версий, но точно знаю, что в 8 версии есть ломающие наши манифесты изменения - точно что-то придётся переписывать). Соответственно, до свежих версий Puppet или OpenVox мы обязательно когда-нибудь обновимся (если к тому времени не уйдём с Puppet на какую-то другую систему управления конфигурацией, конечно).
с чистого листа - нужно смотреть, какие сейчас задачи в плане управления конфигурацией стоят перед нами и перед другими командами в компании. Когда есть куча написанного кода - всегда переход на другую систему подразумевает большой объём работ как по переписыванию существующего кода, так и по переписыванию инструментов, переделке процессов.
А про это я как раз расписал в описании ресурса типа file: https://habr.com/ru/company/avito/blog/507346/#file, конкретно в параметре source.
Если указывать схему file:, то исходные файлы будут браться с той ноды, на которой запускается паппет-агент. Чтобы брать файлы с паппетсервера, нужно использовать схему puppet:, и использовать правильные пути на самом паппетсервере.
Директория /etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certs не прокатит — нужна поддиректория files внутри какого-нибудь модуля. Например, назовём модуль certs, путь на паппетсервере будет /etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/certs/files/certs; чтобы брать файлы по этому пути — используйте source => 'puppet:///modules/certs/certs' (при условии, что окружение ноды — ubuntu_vdi_test).
Если хотя бы один из модулей под вашим управлением — поменяйте название конфликтующего ресурса, добавьте туда название модулей, например (см. мой пример с разными провайдерами для пакета).
Про отслеживание зависимостей — так как в терминологии паппета нет понятия "подмодуль", тут нужно уточнить, речь идёт об отдельных модулях-зависимостях (тогда надо смотреть в metadata.json/Puppetfile/Modulefile), или о ресурсах внутри одного модуля, от которых зависят другие ресурсы внутри этого модуля (вообще паппет показывает, в каком именно месте используется необъявленный ресурс)?
Foreman это такой комбайн, который, насколько мне известно, умеет работать не только с Puppet в качестве бэкэнда.
В случае с Puppet Foreman выступает в роли ENC, про это, как раз, я расскажу в следующей части.
Я вам таки больше скажу — у этих инструментов немного разная область применения, поэтому можно использовать и то, и другое. Мы используем puppet для поддержания конфигурации серверов в нужном состоянии, а ansible используем для разовых заданий (например, поднимаем кластера Ceph именно с помощью ansible).
В нашем случае ситуация достаточно тяжёлая, потому что написано много кода посредственного качества под третий паппет, а в новый (изначально пятый, но к моменту запуска уже шестой) паппет мы хотели не просто перенести старые манифесты, а применять подходы Infrastructure as Code и писать качественный код, покрывая его тестами. Между третьим и шестым паппетом большая разница: как минимум, отличаются парсеры (https://puppet.com/docs/puppet/3.8/experiments_future.html), разные версии hiera (hiera 1 в третьем паппете и hiera 5 в шестом), поэтому мы потихоньку переписываем старые манифесты с нуля и переводим сервера со старого паппета на новый поштучно (ну, или скорее по группам).
Кроме огромного объёма манифестов, которые нам нужно переписать, встала ещё одна проблема: для бэкапов мы используем экспортируемые ресурсы, а для работы экспортируемых ресурсов нужна одна общая PuppetDB. Разные версии паппета совместимы с разными версиями PuppetDB, обратной совместимости нет (во всяком случае, не при такой разнице версий, как у нас), поэтому мы написали прокси для старого паппета, который реализует интерфейс старой PuppetDB и кладёт данные в новую PuppetDB. Ну и плюс были небольшие приседания с сертификатами для того, чтобы в одну и ту же PuppetDB ходили несколько новых паппетсерверов (засада кроется в двусторонней проверке TLS-сертификатов, каждый паппетсервер хочет, чтобы у PuppetDB был сертификат, выпущенный этим же паппетсервером).
Третий момент — сетевая конфигурация, которая хранится в Hiera и должна быть одинакова для сервера вне зависимости от того, под какой версией паппета этот сервер. Здесь просто — вынесли эту Hiera в отдельный репозиторий и подключаем его ко всем паппетсерверам.
В вашем случае проблем, скорее всего, будет меньше: если я правильно понимаю, то парсер четвёртой и шестой версии паппета если и отличается, то не так сильно, во всяком случае, лямбды туда уже завезли, да и окружения используются по умолчанию.
Раз у вас настроен CI/CD — попробуйте залить существующий код под шестой паппет, прогоните тесты, поймёте масштаб бедствий. Если тесты не покажут проблем, то переключайте агенты под новый паппет, прогоняйте в режиме noop, смотрите, бомбанёт что-нибудь или нет.
Повторюсь: hCaptcha работает не на нашей стороне, а на стороне Cloudflare. Мы html-страницу отдаём без всяких блокировок, блокировка происходит в момент обращения к статике (js, css), которая лежит на Cloudflare.
Для отдачи статики мы в Авито используем CDN Cloudflare. Cloudflare работает не только как CDN — у них полноценный стек сервисов от L3 до L7. В том числе у них есть WAF, который на подозрительные запросы отдаёт страницу с капчей (как раз с hCaptcha).
Страница с капчей отдаётся к кодом ответа 403, и фаерволу в приниципе без разницы, какой тип ресурса вы запросили — HTML, JS, CSS или что-то ещё, в случае подозрительного запроса вам в любом случае прилетит HTML.
Почему ваш запрос посчитали подозрительным — всё просто, IP выходных нод TOR'а очень часто помечаются как подозрительные.
Подобные проблемы могут возникнуть на любом сайте, где статический контент отдаётся через CDN, а динамический — нет.
Нашего умысла защищать javascript от ботов и показывать им капчу тут нет, это чисто общая логика Cloudflare.
По поводу актуальности отдачи HTML на запрос JS и прочих ресурсов веб-страницы мы Cloudflare обратную связь передали.
С 3 и 4 переходить на 5+ смысл есть, потому что там новая хиера - глобальный слой появился (если мне не изменяет память), много интересных бэкэндов; паппетсервер более просто масштабируется, на те же compile-мастера за счёт SRV-записей в DNS нагрузка легче выносится; фактер новый (какие-то новые фичи там точно появлялись, сейчас не назову, какие конкретно); и в целом он уже не похож на говно мамонта.
Уязвимости - разумеется, валидно, но, если честно, я не припомню актуальных CVE, которые нас могли бы затронуть.
С обновлением ОС всё очень просто на самом деле: так как puppet-agent поставляется со всем необходимым, и никаких внешних зависимостей не тащит - с большой долей вероятности можно ставить пакет для старого дистрибутива на новом дистрибутиве.
Спасибо за информацию, изучим Choria, выглядит интересно.
На текущий момент у нас есть внутреннее решение, связанное и с ENC, и с PuppetDB, которое позволяет как запускать некоторые задания через агентов (включая прогон паппета), так и искать хосты, отчёты и факты в pdb.
Тут просто важно понимать, зачем нужно это обновление. Обновление ради обновления - увольте.
Если заметно увеличится скорость работы паппетсервера/агента, уменьшится количество зависаний сервера (сейчас регулярно раз в день, а то и чаще, некоторые паппетсервера рестартуются, иначе подвисают по непонятным причинам) - смысл есть. Если просто чтобы циферку больше увидеть - оно не стоит трудозатрат.
Head Avito Puppetmaster here.
автоматическа канареечная выкатка пока ещё на стадии реализации, алгоритм следующий:
пользователь запушил изменения в ветку, в Ci/CD запускаются все локальные проверки (линтеры, unit- и acceptance-тесты)
если локальные проверки прошли успешно, определяем, какие роли затрагиваются изменениями в этой ветке (пока что определение роли делаем ручное, для каждой роли указываем, какие файлы в репозитории на неё влияют; в будущем это можно будет автоматизировать, например, путём анализа каталогов хостов с данной ролью)
для каждой такой роли выбираем канареечные хосты (рандомом; опять же, возможна разметка хостов для того, чтобы всегда использовать или никогда не использовать какой-то хост для канарейки), переводим их в окружение, соответствующее данной ветке, принудительно прогоняем там паппет
запускаем проверки на этих хостах (проверки сделали на основе acceptance-тестов - на каждом хосте стоит inspec, который локально прогоняет acceptance-тесты, в которых подставлены актуальные боевые параметры вместо тестовых)
в зависимости от статуса проверок либо помечаем билд успешным, либо делаем откат изменений (самая сложная часть, потому что универсального рецепта для отката конфигурации без потери данных нет)
мы только что закончили семилетний (!) процесс перехода с Puppet 3.7 на Puppet 7. Процесс был очень долгий из-за того, что хостов много, конфигурации много, тестов ноль - всё это приходилось переписывать и дописывать, концептуально изменения с 3 до 4 и с 4 до 5 версии очень большие, а вот начиная с 5 версии всё более или менее минорное (я не читал подробный changelog 8 и последующих версий, но точно знаю, что в 8 версии есть ломающие наши манифесты изменения - точно что-то придётся переписывать). Соответственно, до свежих версий Puppet или OpenVox мы обязательно когда-нибудь обновимся (если к тому времени не уйдём с Puppet на какую-то другую систему управления конфигурацией, конечно).
с чистого листа - нужно смотреть, какие сейчас задачи в плане управления конфигурацией стоят перед нами и перед другими командами в компании. Когда есть куча написанного кода - всегда переход на другую систему подразумевает большой объём работ как по переписыванию существующего кода, так и по переписыванию инструментов, переделке процессов.
Напомните, какой закон нивелирует пункт EULA о том, что дизассемблирование запрещено?
А про это я как раз расписал в описании ресурса типа file: https://habr.com/ru/company/avito/blog/507346/#file, конкретно в параметре source.
Если указывать схему
file:, то исходные файлы будут браться с той ноды, на которой запускается паппет-агент. Чтобы брать файлы с паппетсервера, нужно использовать схемуpuppet:, и использовать правильные пути на самом паппетсервере.Директория
/etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certsне прокатит — нужна поддиректорияfilesвнутри какого-нибудь модуля. Например, назовём модульcerts, путь на паппетсервере будет/etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/certs/files/certs; чтобы брать файлы по этому пути — используйтеsource => 'puppet:///modules/certs/certs'(при условии, что окружение ноды —ubuntu_vdi_test).Если я правильно понимаю, то ошибка именно из-за дублирования ресурса
user { 'deploy': }в старом и новом модуле. Решается эта проблема так:Если хотя бы один из модулей под вашим управлением — поменяйте название конфликтующего ресурса, добавьте туда название модулей, например (см. мой пример с разными провайдерами для пакета).
Про отслеживание зависимостей — так как в терминологии паппета нет понятия "подмодуль", тут нужно уточнить, речь идёт об отдельных модулях-зависимостях (тогда надо смотреть в
metadata.json/Puppetfile/Modulefile), или о ресурсах внутри одного модуля, от которых зависят другие ресурсы внутри этого модуля (вообще паппет показывает, в каком именно месте используется необъявленный ресурс)?Foreman это такой комбайн, который, насколько мне известно, умеет работать не только с Puppet в качестве бэкэнда.
В случае с Puppet Foreman выступает в роли ENC, про это, как раз, я расскажу в следующей части.
Есть на форже.
https://forge.puppet.com/puppet/puppetserver
https://forge.puppet.com/puppetlabs/puppetdb
Я вам таки больше скажу — у этих инструментов немного разная область применения, поэтому можно использовать и то, и другое. Мы используем puppet для поддержания конфигурации серверов в нужном состоянии, а ansible используем для разовых заданий (например, поднимаем кластера Ceph именно с помощью ansible).
В нашем случае ситуация достаточно тяжёлая, потому что написано много кода посредственного качества под третий паппет, а в новый (изначально пятый, но к моменту запуска уже шестой) паппет мы хотели не просто перенести старые манифесты, а применять подходы Infrastructure as Code и писать качественный код, покрывая его тестами. Между третьим и шестым паппетом большая разница: как минимум, отличаются парсеры (https://puppet.com/docs/puppet/3.8/experiments_future.html), разные версии hiera (hiera 1 в третьем паппете и hiera 5 в шестом), поэтому мы потихоньку переписываем старые манифесты с нуля и переводим сервера со старого паппета на новый поштучно (ну, или скорее по группам).
Кроме огромного объёма манифестов, которые нам нужно переписать, встала ещё одна проблема: для бэкапов мы используем экспортируемые ресурсы, а для работы экспортируемых ресурсов нужна одна общая PuppetDB. Разные версии паппета совместимы с разными версиями PuppetDB, обратной совместимости нет (во всяком случае, не при такой разнице версий, как у нас), поэтому мы написали прокси для старого паппета, который реализует интерфейс старой PuppetDB и кладёт данные в новую PuppetDB. Ну и плюс были небольшие приседания с сертификатами для того, чтобы в одну и ту же PuppetDB ходили несколько новых паппетсерверов (засада кроется в двусторонней проверке TLS-сертификатов, каждый паппетсервер хочет, чтобы у PuppetDB был сертификат, выпущенный этим же паппетсервером).
Третий момент — сетевая конфигурация, которая хранится в Hiera и должна быть одинакова для сервера вне зависимости от того, под какой версией паппета этот сервер. Здесь просто — вынесли эту Hiera в отдельный репозиторий и подключаем его ко всем паппетсерверам.
В вашем случае проблем, скорее всего, будет меньше: если я правильно понимаю, то парсер четвёртой и шестой версии паппета если и отличается, то не так сильно, во всяком случае, лямбды туда уже завезли, да и окружения используются по умолчанию.
Раз у вас настроен CI/CD — попробуйте залить существующий код под шестой паппет, прогоните тесты, поймёте масштаб бедствий. Если тесты не покажут проблем, то переключайте агенты под новый паппет, прогоняйте в режиме noop, смотрите, бомбанёт что-нибудь или нет.
Спасибо за вопрос, дописал в статью параграф про запуск и дебаг.
ssh <host> 'sudo puppet agent -t --noop'Страница с капчей отдаётся к кодом ответа 403, и фаерволу в приниципе без разницы, какой тип ресурса вы запросили — HTML, JS, CSS или что-то ещё, в случае подозрительного запроса вам в любом случае прилетит HTML.
Почему ваш запрос посчитали подозрительным — всё просто, IP выходных нод TOR'а очень часто помечаются как подозрительные.
Подобные проблемы могут возникнуть на любом сайте, где статический контент отдаётся через CDN, а динамический — нет.
Нашего умысла защищать javascript от ботов и показывать им капчу тут нет, это чисто общая логика Cloudflare.
По поводу актуальности отдачи HTML на запрос JS и прочих ресурсов веб-страницы мы Cloudflare обратную связь передали.