Что регулярно ломается в реальных сервисах, когда надо совместить YAML, .env, переменные окружения и вложенный Config.
Вот абсолютно бытовая ситуация. Есть config.yaml для локалки. Есть .env.example, который у каждого чуть свой. В проде значения прилетают через Docker/Kubernetes/systemd. В коде живет нормальный вложенный Config, а не плоская простыня.
И вот в этот момент становится ясно: в Go нет одного «очевидного» инструмента, который без плясок закрывает всю цепочку целиком.
JSON, YAML, TOML, HCL - за последние годы человечество успело изобрести десяток языков для конфигурации.
Каждый обещал быть "простым", "удобным" и "читаемым человеком".
Но по факту - все они страдают от одних и тех же проблем: шумный синтаксис, хрупкие отступы, бесконечные кавычки и отсутствие элементарных возможностей вроде модульности и слияния конфигов.
Пора перестать с этим мириться и сделать конфигурации наконец человеческими.
утомлять глаза, пытаясь разобраться в тонне бесполезных кавычек
утомлять глаза, пытаясь распознать в каком месте есть проблема с отступом
Когда-то я начинал свой путь как node.js разработчик и столкнулся с необходимостью конфигурировать приложение (кто бы мог подумать). Из простых решений, которые сразу приходят на ум, можно выделить:
файлы (json, .env, toml, yaml, xml, ini и прочие)
переменные окружения
аргументы процесса
В моём понимании это не совсем "конфигурация", а скорее способ передачи в неё данных. Так вот чтобы это всё заставить представлять из себя полноценную конфигурацию, с которой удобно работать, понадобилось поискать готовое решение. Среди прочих для себя выделил node-configЧитать полностью »
Есть счастливые люди, которые могут себе позволить просто перезаписывать YAML конфиги в продакшене. Мне же повезло меньше - инсталляции у меня специфичные и конфиги часто настраиваются "под себя". К каждому релизу приходилось готовить отдельную доку для ручного апдейта конфигурации.
Естественно, что руки сами тянутся автоматизировать такое безобразие, но гугл быстро дал понять что не я один мечтаю о хорошем, только вот заветного оазиса пока никто не нашел. Нет, смержить два YAML файлика задача не трудная, но только если готов пожертвовать комментами (что для многих, как и для меня, недопустимо).
Как то раз мне захотелось сделать "Contact us" виджет и возникла дилемма, как задать настройки кнопки?
Хотелось чтобы:
Всё было понятно для не(до)программистов
Легко было написать генератор
Всё работало сразу же
Всё работало сразу же
Иметься ввиду что нужно только подключить скрипт. Без создания экземпляра класса и вызова где-то там в коде. Мне разу же пришла в голову идея передавать параметры в GET параметрах URL.
Но также хотелось бы выложить код на github без использования серверной части... Я задал вопрос на Toster QNA Habr
Привет.
Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.
Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm.
Во время разработки часто возникает потребность для вынесения параметров в конфигурационные файлы. Да и вообще — хранить разные конфигурационный константы в коде является признаком дурного тона. Один из вариантов хранения настроек — использования конфигурационных файлов. .Net Core из коробки умеет работать с такими форматами как: json, ini, xml и другие. Так же есть возможность писать свои провайдеры конфигураций. (Кстати говоря за работу с конфигурациями отвечает сервис IConfiguration и IConfigurationProvider — для доступа к конфигурациям определенного формата и для написания своих провайдеров)
Но главная сложность, на мой взгляд, состоит в том, что у нас имеются аж 3 разные интерфейса для работы с конфигурациями. И не всегда понятно для чего они нужны и какой когда нужно использовать.
Состоялся публичный opensource-релиз системы конфигурирования уровня приложения OnlineConf, которая на протяжении последних восьми лет активно используется у нас в Mail.ru Group.
Исходный код сервиса, а также библиотеки для ряда используемых в компании языков программирования, опубликованы под лицензией MIT. Попробовать сервис можно при помощи Docker, в комплекте имеются конфигурационные файлы для быстрого запуска тестовой инсталляции.
Мне поступила задача по настройке CI. Было принято решение использовать трансформацию конфигурационных файлов и конфиденциальные данные хранить в зашифрованном виде.
Изучив документацию по шифрованию, вот что было сделано.
В каждой ОС Windows есть наборы сгенерированных ключей. Ключ генерируется либо на учетную запись, либо на машину. Ключи сгенерированные на машину можно посмотреть по этому пути C:ProgramDataMicrosoftCryptoRSAMachineKeys. Сюда и отправиться ключ который мы создадим далее.
Читать полностью »
