[DevOps, Kubernetes] Автогенерация секретов в Helm (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Auto-Generated Helm Secrets
Команда Kubernetes aaS от Mail.ru перевела короткую заметку о том, как автоматически генерировать секреты Helm при обновлении. Далее текст от автора статьи — технического директора Intoware, компании-разработчика SaaS-решений.
Контейнеры — это круто. Сначала я был противником контейнеров (стыдно признаться), но теперь я полностью поддерживаю использование этой технологии.
Если вы читаете это, то, надеюсь, успешно плавали по морям Docker, осознали преимущества Kubernetes и сделали свою жизнь намного проще с Helm.
Тем не менее некоторые вещи явно сложнее, чем должны быть.
Как автоматически генерировать секреты при обновлении?
Секрет Kubernetes — ресурс, который содержит пары ключ/значение, которые вы хотите использовать в своем коде. Это могут быть строки подключения к базе данных, пароли электронной почты и так далее. Используя секреты, вы создаете четкое разделение между кодом и настройками, что позволяет легко настраивать различные развертывания без изменения кодовой базы.
Часто встречающаяся ситуация, когда два модуля должны взаимодействовать при помощи общего ключа. Никто за пределами кластера не должен знать этот ключ, так как он предназначен для связи «от одного к другому» внутри кластера.
Создание секретов
Обычно, чтобы создать секрет в Helm, нужно:
- описать секрет в файле значений;
- переопределить его в процессе деплоя;
- сослаться на него внутри деплоя/пода;
- … профит !
Обычно это выглядит примерно так:
apiVersion: v1
kind: Secret
metadata:
name: my-super-awesome-api-key
type: Opaque
stringData:
apiKey: {{ .Values.MyApiKeySecret | quote }}
Простой секрет Kubernetes, использующий значения из values.yml
Но, допустим, вы не хотите указывать свой секрет в файле значений.
Существует много вариантов, когда для развертывания требуется общий ключ, который должен быть сгенерирован во время установки.
В приведенном выше примере со связью между модулями нежелательно делиться секретом за пределами развертывания. Поэтому очень желательно, чтобы Helm имел механизмы для автоматического создания секрета без необходимости его непосредственного указания.
Хуки
Хуки позволяют запускать код в определенных местах в процессе установки. Возможно, есть задание по настройке, которое необходимо запустить после первой установки, или, возможно, необходимо выполнить очистку перед выполнением любого обновления.
Для решения нашей проблемы добавления ключа, генерируемого при установке, идеально подходят предустановочные хуки. Но есть одна загвоздка: вы не можете автоматически сгенерировать секрет один раз при обновлении. Хуки будут работать при каждом обновлении.
Если вы сгенерировали свой секрет, и ваша первая установка еще не произошла, тогда прекратите чтение, предустановочный хук отлично подойдет для вас.
Но если секрет является частью обновления (возможно, новой функции, которой не было во время установки), то досадно, что невозможно создать предустановочный хук, который бы сработал всего один раз.
Функции
Функции Helm позволяют добавлять различные элементы скриптов в сценарии развертывания.
apiVersion: v1
kind: Secret
metadata:
name: my-super-awesome-api-key
type: Opaque
stringData:
apiKey: {{ uuidv4 | quote }} #Generate a new UUID and quote it
В этом примере показано, что значением секрета apiKey будет новый UUID, сгенерированный во время установки.
Helm включает в себя действительно обширную библиотеку функций, которая использует потрясающие функции шаблонов GO и библиотеку функций Sprig для создания настраиваемых развертываний.
Функция Lookup
В Helm 3.1 добавлена функция Lookup, которая позволяет запросить существующий деплой и:
- проверить существование ресурсов;
- вернуть значение существующего ресурса для последующего использования.
Используя обе эти возможности, мы можем создать одноразовый динамически сгенерированный секрет!
# 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}}
apiVersion: v1
kind: Secret
metadata:
name: some-awesome-secret
type: Opaque
# 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data")
{{ if $secret -}}
data:
apiKey: {{ $secret.data.apiKey }}
# 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)!
{{ else -}}
stringData:
apiKey: {{ uuidv4 | quote }}
{{ end }}
Всякий раз, когда новое обновление применяется к серверу, Helm будет либо генерировать новое значение секрета (если секрета еще нет), либо повторно использовать существующее значение.
Успехов!
Что еще почитать по теме:
- Три уровня автомасштабирования в Kubernetes и как их эффективно использовать.
- Kubernetes в духе пиратства с шаблоном по внедрению.
- Наш канал Вокруг Kubernetes в Телеграме.
===========
Источник:
habr.com
===========
===========
Автор оригинала: James Woodall
===========Похожие новости:
- [DevOps, Python, Анализ и проектирование систем, Искусственный интеллект, Машинное обучение] Общий обзор архитектуры сервиса для оценки внешности на основе нейронных сетей
- [Agile, DevOps, Управление персоналом, Читальный зал] DevOps или как мы теряем заработную плату и будущее IT-отрасли
- [DevOps, Kubernetes, Серверное администрирование, Системное администрирование] Логирование в Kubernetes: EFK против PLG (перевод)
- [Настройка Linux, Системное администрирование, Облачные вычисления, Серверное администрирование, DevOps] Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2
- [DevOps, Настройка Linux] Используем nftables в Red Hat Enterprise Linux 8 (перевод)
- [DevOps, Kubernetes, Системное администрирование] Валидация Kubernetes YAML на соответствие лучшим практикам и политикам (перевод)
- [DevOps, Open source, Карьера в IT-индустрии, Учебный процесс в IT] Какой совет оказал наибольшее влияние на вашу карьеру в DevOps (перевод)
- [Go, Алгоритмы, Программирование, Процессоры] Go и кэши CPU (перевод)
- [DevOps, Системное администрирование] Новые подходы автоматизации Wildfly
- [DevOps, Open source, Управление разработкой, Учебный процесс в IT] 10 контринтуитивных выводов после 10 лет проведения DevOpsDays (перевод)
Теги для поиска: #_devops, #_kubernetes, #_kubernetes, #_devops, #_helm, #_deploy, #_blog_kompanii_mail.ru_group (
Блог компании Mail.ru Group
), #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:26
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Auto-Generated Helm Secrets Команда Kubernetes aaS от Mail.ru перевела короткую заметку о том, как автоматически генерировать секреты Helm при обновлении. Далее текст от автора статьи — технического директора Intoware, компании-разработчика SaaS-решений. Контейнеры — это круто. Сначала я был противником контейнеров (стыдно признаться), но теперь я полностью поддерживаю использование этой технологии. Если вы читаете это, то, надеюсь, успешно плавали по морям Docker, осознали преимущества Kubernetes и сделали свою жизнь намного проще с Helm. Тем не менее некоторые вещи явно сложнее, чем должны быть. Как автоматически генерировать секреты при обновлении? Секрет Kubernetes — ресурс, который содержит пары ключ/значение, которые вы хотите использовать в своем коде. Это могут быть строки подключения к базе данных, пароли электронной почты и так далее. Используя секреты, вы создаете четкое разделение между кодом и настройками, что позволяет легко настраивать различные развертывания без изменения кодовой базы. Часто встречающаяся ситуация, когда два модуля должны взаимодействовать при помощи общего ключа. Никто за пределами кластера не должен знать этот ключ, так как он предназначен для связи «от одного к другому» внутри кластера. Создание секретов Обычно, чтобы создать секрет в Helm, нужно:
Обычно это выглядит примерно так: apiVersion: v1
kind: Secret metadata: name: my-super-awesome-api-key type: Opaque stringData: apiKey: {{ .Values.MyApiKeySecret | quote }} Простой секрет Kubernetes, использующий значения из values.yml Но, допустим, вы не хотите указывать свой секрет в файле значений. Существует много вариантов, когда для развертывания требуется общий ключ, который должен быть сгенерирован во время установки. В приведенном выше примере со связью между модулями нежелательно делиться секретом за пределами развертывания. Поэтому очень желательно, чтобы Helm имел механизмы для автоматического создания секрета без необходимости его непосредственного указания. Хуки Хуки позволяют запускать код в определенных местах в процессе установки. Возможно, есть задание по настройке, которое необходимо запустить после первой установки, или, возможно, необходимо выполнить очистку перед выполнением любого обновления. Для решения нашей проблемы добавления ключа, генерируемого при установке, идеально подходят предустановочные хуки. Но есть одна загвоздка: вы не можете автоматически сгенерировать секрет один раз при обновлении. Хуки будут работать при каждом обновлении. Если вы сгенерировали свой секрет, и ваша первая установка еще не произошла, тогда прекратите чтение, предустановочный хук отлично подойдет для вас. Но если секрет является частью обновления (возможно, новой функции, которой не было во время установки), то досадно, что невозможно создать предустановочный хук, который бы сработал всего один раз. Функции Функции Helm позволяют добавлять различные элементы скриптов в сценарии развертывания. apiVersion: v1
kind: Secret metadata: name: my-super-awesome-api-key type: Opaque stringData: apiKey: {{ uuidv4 | quote }} #Generate a new UUID and quote it В этом примере показано, что значением секрета apiKey будет новый UUID, сгенерированный во время установки. Helm включает в себя действительно обширную библиотеку функций, которая использует потрясающие функции шаблонов GO и библиотеку функций Sprig для создания настраиваемых развертываний. Функция Lookup В Helm 3.1 добавлена функция Lookup, которая позволяет запросить существующий деплой и:
Используя обе эти возможности, мы можем создать одноразовый динамически сгенерированный секрет! # 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}} apiVersion: v1 kind: Secret metadata: name: some-awesome-secret type: Opaque # 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data") {{ if $secret -}} data: apiKey: {{ $secret.data.apiKey }} # 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)! {{ else -}} stringData: apiKey: {{ uuidv4 | quote }} {{ end }} Всякий раз, когда новое обновление применяется к серверу, Helm будет либо генерировать новое значение секрета (если секрета еще нет), либо повторно использовать существующее значение. Успехов! Что еще почитать по теме:
=========== Источник: habr.com =========== =========== Автор оригинала: James Woodall ===========Похожие новости:
Блог компании Mail.ru Group ), #_devops, #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:26
Часовой пояс: UTC + 5