Да, значительная часть этих настроек это "фичи" вроде safe browsing, которые подразумевают риски для приватности. Есть и немало настроек у которых прямо в названии имеется telemetry (открою секрет, если вы нажмете ctrl-f вы сможете найти их на той странице). Остальная часть это настройки, влияющие на fingerprinting (упрощают/усложняют ваше отслеживание со стороны сервисов), и секурити. Часть настроек непосредственно связанных с телеметрией не отключается через GUI, только через user.js.
Scoop по сути получается альтернативой chocolatey или msi-установщикам. У нас в планах разобраться с тем, как лучше устанавливать werf на Windows. Для Linux/macOS недавно сделали установщик (Bash-скрипт), который под капотом устанавливает trdl, и через trdl устанавливает werf, ну и делает ещё некоторые вспомогательные штуки. Что-то подобное хочется иметь и под Windows, как это будет реализовано (скрипты, пакеты, установщики) будем смотреть ближе к делу.
И всё же сам werf будет устанавливаться только через trdl. Основные причины: высокая безопасность (судя по вики scoop у них на это такого большого фокуса нет), эффективные автообновления (что самого trdl, что ПО, которое им устанавливается), кроссплатформенность. Подробнее можно почитать тут: https://ru.trdl.dev/ Хотя мы обязательно подумаем, сможем ли мы как-то подвязать trdl+werf к пакетным системам вроде snoop.
Docker сейчас является зависимостью для запуска werf, так что если хотите запускать werf на хосте, то Docker Desktop на Windows таки надо будет поставить.
С другой стороны, теоретически, вы можете поставить werf на одну из нод minikube и попробовать запускать его там, но этот сценарий не проверялся, и часть инструкций по подготовке окружения изменится (как минимум то, что связано с доступом через ингресс).
Всё это интересно и мы подумаем, что из этого мы можем захватить, хотя возможно уже в рамках других статей. Тут хотелось ограничить охват того, что описываем, а то как видите, даже несмотря на то, что опустили шаблонизацию и опустили какие-то слишком уж очевидные (на мой взгляд) вещи, вроде пина тегов, а итак вышло довольно объёмно. Ну и вторая часть статьи сейчас в работе.
Действительно, можно реализовать проверку внутри приложения. Инит-контейнеры не использовать. Стартап-проба только в таком случае по-хорошему не должна проверять внешние зависимости, иначе проба начнет падать и Pod может войти в CrashLoopBackOff, что приведет к лишнему простою.
При этом само приложение не должно падать, когда внешняя зависимость становится недоступной, иначе опять же Pod может войти в CrashLoopBackOff. Вместо этого надо ретраить внешнюю зависимость, пока она не поднимется.
Если всё это получается реализовать, то соглашусь, такой подход предпочтительнее инит-контейнеров. Это у меня профдеформация видимо уже малехонькая, в нашем случае «ребят, ваше приложение надо переписать» нечасто работает :)
Идея скачать и запустить целый постгрес
Там образ весит всего 50Мб, на практике это ничего особо не аффектит. Сам postgresql-сервер в данном случае конечно не запускается. Если всё же образ беспокоит, то можно либо самому собрать минимальный образ только с pg_isready, либо засунуть pg_isready в контейнер с приложением и поэкспериментировать с чем-то вроде
И всё же, ваш вариант мне видится самым предпочтительным. Остается только вопрос, стоит ли в вашем варианте вынести проверку внешних зависимостей на какой-нибудь /readiness, где проверять этот эндпоинт в readinessProbe.
А это боль, да. И проблема в том, что вот это {{ if .Values.key1.key2.key3 }} особо то никак и не обернешь в include. Единственный вариант который в голову приходил — это сделать define, в который аргументом пробрасывается строка типа ".Values.key1.key2.key3", а внутри это как-то разбивать (по точкам?) на массив и по очереди проверять каждый ключ на существование.
Но всё это довольно чудно и, вероятно, требует прилично логики чтобы все исключения обработать, так что реализовывать не стал.
Всё так, у всех свои практики складываются, стандартизации нет. При этом подводных в helm-шаблонах полно, поэтому пока выработаешь какие-то действительно работающие лучшие практики, шишек набьешь кучу.
Думал может в отдельной статье поделиться практиками по структуре чартов/values, которые показали себя рабочими по крайней мере у нас, может кому полезно будет.
На практике если логика продублирована — в большинстве случаев это значит что она изначально была реализована по-разному (и вероятно разными людьми), а потом ещё и правилась, и тоже по-разному, в разноё время и разными людьми. В итоге начинается дрифт этой логики/конфигурации, и простым sed'ом уже не пройдешься.
Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Действительно, если к чартам особых требований нет, то лучше держать всё максимально простым. Но если однотипных чартов становится много + сложность каждого отдельного чарта растёт, то в любом случае у тебя получится куча шаблонизации. Просто эта сложность не будет вынесена в include/define'ы, а будет в каждом чарте повторяться снова и снова. Каждый раз реализована по-новому, каждый раз с новыми багами/фичами, и без возможности всё это централизованно править.
Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.
В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.
Тут ещё инфа, хотя уже подпротухла и сейчас наверное хуже: https://spyware.neocities.org/articles/firefox.html
Да, значительная часть этих настроек это "фичи" вроде safe browsing, которые подразумевают риски для приватности. Есть и немало настроек у которых прямо в названии имеется telemetry (открою секрет, если вы нажмете ctrl-f вы сможете найти их на той странице). Остальная часть это настройки, влияющие на fingerprinting (упрощают/усложняют ваше отслеживание со стороны сервисов), и секурити. Часть настроек непосредственно связанных с телеметрией не отключается через GUI, только через user.js.
Тут можно подробнее про телеметрию в Firefox почитать, для тех кто в танке: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf
Да-да, все дураки кроме вас.
Вы конечно можете поудалять ненужное из того файла, но вы подустанете разбираться что там к чему.
Приватности? В Firefox телеметрии сегодня больше, чем, наверное, в хроме и edge вместе взятых.
Чтобы хотя бы частично отключить телеметрию надо иметь вот ЭТО на 400 строк настроек: https://github.com/arkenfox/user.js/blob/master/user.js
Спасибо за фидбек.
Scoop по сути получается альтернативой chocolatey или msi-установщикам. У нас в планах разобраться с тем, как лучше устанавливать werf на Windows. Для Linux/macOS недавно сделали установщик (Bash-скрипт), который под капотом устанавливает trdl, и через trdl устанавливает werf, ну и делает ещё некоторые вспомогательные штуки. Что-то подобное хочется иметь и под Windows, как это будет реализовано (скрипты, пакеты, установщики) будем смотреть ближе к делу.
И всё же сам werf будет устанавливаться только через trdl. Основные причины: высокая безопасность (судя по вики scoop у них на это такого большого фокуса нет), эффективные автообновления (что самого trdl, что ПО, которое им устанавливается), кроссплатформенность. Подробнее можно почитать тут: https://ru.trdl.dev/ Хотя мы обязательно подумаем, сможем ли мы как-то подвязать trdl+werf к пакетным системам вроде snoop.
Можно попробовать ещё такой вариант:
Docker сейчас является зависимостью для запуска werf, так что если хотите запускать werf на хосте, то Docker Desktop на Windows таки надо будет поставить.
С другой стороны, теоретически, вы можете поставить werf на одну из нод minikube и попробовать запускать его там, но этот сценарий не проверялся, и часть инструкций по подготовке окружения изменится (как минимум то, что связано с доступом через ингресс).
А почему не хочется Docker на хост ставить?
При этом само приложение не должно падать, когда внешняя зависимость становится недоступной, иначе опять же Pod может войти в CrashLoopBackOff. Вместо этого надо ретраить внешнюю зависимость, пока она не поднимется.
Если всё это получается реализовать, то соглашусь, такой подход предпочтительнее инит-контейнеров. Это у меня профдеформация видимо уже малехонькая, в нашем случае «ребят, ваше приложение надо переписать» нечасто работает :)
Там образ весит всего 50Мб, на практике это ничего особо не аффектит. Сам postgresql-сервер в данном случае конечно не запускается. Если всё же образ беспокоит, то можно либо самому собрать минимальный образ только с pg_isready, либо засунуть pg_isready в контейнер с приложением и поэкспериментировать с чем-то вроде
И всё же, ваш вариант мне видится самым предпочтительным. Остается только вопрос, стоит ли в вашем варианте вынести проверку внешних зависимостей на какой-нибудь /readiness, где проверять этот эндпоинт в readinessProbe.
{{ if .Values.key1.key2.key3 }}особо то никак и не обернешь в include. Единственный вариант который в голову приходил — это сделать define, в который аргументом пробрасывается строка типа ".Values.key1.key2.key3", а внутри это как-то разбивать (по точкам?) на массив и по очереди проверять каждый ключ на существование.Но всё это довольно чудно и, вероятно, требует прилично логики чтобы все исключения обработать, так что реализовывать не стал.
Думал может в отдельной статье поделиться практиками по структуре чартов/values, которые показали себя рабочими по крайней мере у нас, может кому полезно будет.
Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.
В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.