Это пример из оригинальной статьи, Стивен в данном случае показывает, как из синхронного кода сделать асинхронный и что в данном случае генерируется компиллятором. В статье идут отсылки к предыдущим частям, поэтому я рекомендую начинать читать с первой части.
Это код из оригинальной статьи, сам Стивен говорит о том, что это просто примеры для понимания работы и реальный код конечно сложнее. Можете сами посмотреть реализацию в исходниках. Там как раз ссылка на таймер сохраняется в DelayPromise.
Тут нет, дублирования файлов конфигурации, файл конфигурации хранится в единственном экземпляре в configmap. У нас как это работает, в локальной разработке используется отдельный appsettings.Development.json, а в CI/СD используется конфигурация из helm (configmap.yaml), которая лежит в том же проекте. Разработчик после проведения тестирования локально, обновляет configmap и все это выливается в k8s.
Шаблон хранится в configmap, это стандартный способ хранения конфигурации для приложений в k8s. В него подставляются только секреты из vault, по тому же принципу, как работает helm, то есть это скорее не генератор, как таковой, а шаблонизатор.
Не очень понятно, как в данном случае можно пропустить эту фазу, было бы очень интересно посмотреть на вашу реализацию в связке с Vault.
Это пример из оригинальной статьи, Стивен в данном случае показывает, как из синхронного кода сделать асинхронный и что в данном случае генерируется компиллятором. В статье идут отсылки к предыдущим частям, поэтому я рекомендую начинать читать с первой части.
Это код из оригинальной статьи, сам Стивен говорит о том, что это просто примеры для понимания работы и реальный код конечно сложнее. Можете сами посмотреть реализацию в исходниках. Там как раз ссылка на таймер сохраняется в DelayPromise.
Большое спасибо!
Могу я вас попросить написать в личку по проблемам перевода и мы попробуем вместе сделать перевод лучше.
Большое спасибо! Исправлено.
Спасибо, исправил.
На этой неделе планирую закончить вторую часть.
Да согласен, в этом смысле вы правы, секция Logging в
/vault/secrets/appsettings.jsonизбыточна, поправлю код.Спасибо за потраченное время.
Тут нет, дублирования файлов конфигурации, файл конфигурации хранится в единственном экземпляре в configmap.
У нас как это работает, в локальной разработке используется отдельный appsettings.Development.json, а в CI/СD используется конфигурация из helm (configmap.yaml), которая лежит в том же проекте. Разработчик после проведения тестирования локально, обновляет configmap и все это выливается в k8s.
Шаблон хранится в configmap, это стандартный способ хранения конфигурации для приложений в k8s. В него подставляются только секреты из vault, по тому же принципу, как работает helm, то есть это скорее не генератор, как таковой, а шаблонизатор.
Не очень понятно, как в данном случае можно пропустить эту фазу, было бы очень интересно посмотреть на вашу реализацию в связке с Vault.
Поправил.
Есть хорошая статья, где есть сравнение https://www.hashicorp.com/blog/kubernetes-vault-integration-via-sidecar-agent-injector-vs-csi-provider.
В целом sidecar поддерживает больше фич, не требует инсталляции как demonset.
В Vault хранятся только секреты, сам конфиг, в данном случае
appsettings.jsonгенерируется на основе шаблона, который храниться в configmap.