Ilya Lesikov @ilya-lesikov
DevOps/SRE and Software Development
Information
- Rating
- Does not participate
- Location
- Рязань, Рязанская обл., Россия
- Works in
- Date of birth
- Registered
- Activity
Specialization
DevOps, Application Developer
Senior
DevOps/SRE and Software Development
Приватности? В 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-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.