Pull to refresh

Comments 14

Плюсанул. Тоже недавно это реализовал, сначала думал сделать не просто json файл конфигурации, а через user secrets (https://learn.microsoft.com/ru-ru/aspnet/core/security/app-secrets?view=aspnetcore-7.0&tabs=linux#secret-manager), но это рекомендуется только для локальной разработки, да и в дефолтном докер-образе нет вроде тулы по умолчанию.

Так что в целом как-то так и получилось, только не храню в vault весь appsettings.json, а только то, что относится к секретам.

Конечно можно сделать более секурно, но это уже детали.

В Vault хранятся только секреты, сам конфиг, в данном случае appsettings.json генерируется на основе шаблона, который храниться в configmap.

Никогда не понимал любителей генерировать конфиги из шаблонов, а уж при использовании ASP.NET Core — тем более. У вас есть key-value хранилище номер 1 (vault), вы из него делаете json, который будет считан и преобразован в key-value формат номер 2 (конфигурация asp.net core). Почему бы просто не пропустить шаг json?


А уж генерация неизменяемой секции Logging вместо помещения её куда-нибудь в appsettings.Production.json и вовсе выглядит как глупость

Шаблон хранится в configmap, это стандартный способ хранения конфигурации для приложений в k8s. В него подставляются только секреты из vault, по тому же принципу, как работает helm, то есть это скорее не генератор, как таковой, а шаблонизатор.

Не очень понятно, как в данном случае можно пропустить эту фазу, было бы очень интересно посмотреть на вашу реализацию в связке с Vault.

Сразу в ENV (но я не знаток Vault-а, просто предполагаю):

        # Environment variable export template
        vault.hashicorp.com/agent-inject-template-config: |
          {{ with secret "secret/data/web" -}}
            export api_key="{{ .Data.data.payments_api_key }}"
          {{- end }}

Вот в ENV как раз лучше ничего не складывать при наличии таковой возможности. ENV проще "угнать" чем файл: оно мало того что хранится в /proc/2/environ, так ещё и передаётся всем дочерним процессам

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


Однако, как минимум, стоит либо убрать секцию Logging из вашего configmap, либо убрать подключение файла /vault/secrets/appsettings.json и писать всё в обычный appsettings.json. Потому что эти два механизма (статическая секция в шаблоне и статический appsettings.json) дублируют друг друга. В процессе доработок ваши настройки неизбежно разрастутся между этими двумя местами, и концов вы там не найдёте.

Тут нет, дублирования файлов конфигурации, файл конфигурации хранится в единственном экземпляре в configmap.
У нас как это работает, в локальной разработке используется отдельный appsettings.Development.json, а в CI/СD используется конфигурация из helm (configmap.yaml), которая лежит в том же проекте. Разработчик после проведения тестирования локально, обновляет configmap и все это выливается в k8s.

Тут есть дублирование файлов конфигурации. Напоминаю код:


builder.Configuration
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
    .AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json", optional: true, reloadOnChange: true)
    .AddJsonFile("/vault/secrets/appsettings.json", optional: true, reloadOnChange: true);

Если бы основной appsettings.json генерировался из configmap — вам бы не понадобилось добавлять отдельный /vault/secrets/appsettings.json, да и вообще играться с конфигурацией. Следовательно, у вас активны как минимум два файла конфигурации — appsettings.json и /vault/secrets/appsettings.json. Причём наверняка в обоих есть секция Logging (просто потому что в первом она есть по умолчанию, и я не видел у вас инструкции её вырезать).

Да согласен, в этом смысле вы правы, секция Logging в /vault/secrets/appsettings.jsonизбыточна, поправлю код.
Спасибо за потраченное время.

Sign up to leave a comment.

Articles