лейблов • Разработчик может править спецификации и видеть результат • Кастомизация per-environment • При генерации итоговых спецификаций можем выполнять внешние команды 14
изменения откатить • Нет менеджера зависимостей • Нет инструмента для работы с секретами • У разработки свои процессы • Много Shell-скриптов • Никто не разбирается, как это работает • Если что-то не работает, все равно идут к тебе • 40+ репозиториев 17
момент • Иметь прозрачную историю изменений • Иметь возможность править спецификации множества приложений • Избавиться от необходимости подстраиваться под workflow разработки • Работа с версиями секретов • Простой способ работы с зависимостями • Отдать разработке пайплайн сборки артефактов • Минимизировать проблемы при публикации приложений 22
и деплоить если появился новый тег • Релиз на несуществующий образ невозможен • Можно лочить релиз на определенной версии тега деплой и соответственно снимать лос • Не нужно выделять отдельного доступа до CI, flux генерирует ssh ключ через который работает с git’ом • Имеет функционал патча спек приложения • Через .flux.yml можно использовать хоть Kustomize, хоть ksonnet • Поддерживает приватные репозитории • Есть хуки 26
только в Weave Cloud • Изменение спецификаций идет по прямой • Релиз и роллбэк релиза в этой идеологии – публикация того или иного образа • Пока fluxctl или fluxapi не отработают flux ничего не запишет в Git • Используется memcached, но только как кеш для реквестов до Docker Registry • Удаление отслеживаемой сущности (workload) из репозитория со спецификациями переводит запущенные сервисы в статус read-only, их нельзя обновлять через flux и они не будут удалены автоматически • На каждый репозиторий (а так же комбинацию бранчей в репозитории) запускается 1 копия flux-демона 27
(kustomize, ksonnet, helm) • Можно писать плагины • Есть пользовательский интерфейс • В составе идет dex, поэтому можно использовать ldap • Доступ к кластеру не нужен, только к API • Одна инсталляция может обслуживать несколько кластеров • Свои CRDs для описания инсталляции • Приватные репозитории • Есть хуки
map to a Kubernetes cluster. It’s merely a collection of Server Groups, irrespective of any Kubernetes clusters that might be included in your underlying architecture" • Поддержка федерации Kubernetes • Есть пользовательский интерфейс • Работает из коробки с Istio • Авто rollback • Есть поддержка LDAP и ему подобных • В pipelin’ах можно ставить триггер на тег образа
CD платформа, а платформа для управления приложениями Kubernetes • Тяжеловесная инсталляция • Ему нужна CI система • Публикация происходит с помощью Helm’а
с тем, что мы не хотим хранить секреты в открытом виде 2. Секреты уже описаны в HashiCorp Vault, раньше мы их забирали при вызове kustomize 3. Структура данных не представляет возможным передать сразу все секреты приложению, которые ему нужны
с тем, что мы не хотим хранить секреты в открытом виде 2. Секреты уже описаны в HashiCorp Vault, раньше мы их забирали при вызове kustomize 3. Структура данных не представляет возможным передать сразу все секреты приложению, которые ему нужны 4. Есть доклад “Управление секретами с помощью HashiCorp Vault” от Сергея Носкова (Avito)
с тем, что мы не хотим хранить секреты в открытом виде 2. Секреты уже описаны в HashiCorp Vault, раньше мы их забирали при вызове kustomize 3. Структура данных не представляет возможным передать сразу все секреты приложению, которые ему нужны 4. Есть доклад “Управление секретами с помощью HashiCorp Vault” от Сергея Носкова (Avito) 5. Есть рекомендации от HashiCorp (нужно учить приложения ходить в Vault)
с тем, что мы не хотим хранить секреты в открытом виде 2. Секреты уже описаны в HashiCorp Vault, раньше мы их забирали при вызове kustomize 3. Структура данных не представляет возможным передать сразу все секреты приложению, которые ему нужны 4. Есть доклад “Управление секретами с помощью HashiCorp Vault” от Сергея Носкова (Avito) 5. Есть рекомендации от HashiCorp (нужно учить приложения ходить в Vault) 6. Есть множество реализации admission webhook’ов
с тем, что мы не хотим хранить секреты в открытом виде 2. Секреты уже описаны в HashiCorp Vault, раньше мы их забирали при вызове kustomize 3. Структура данных не представляет возможным передать сразу все секреты приложению, которые ему нужны 4. Есть доклад “Управление секретами с помощью HashiCorp Vault” от Сергея Носкова (Avito) 5. Есть рекомендации от HashiCorp (нужно учить приложения ходить в Vault) 6. Есть множество реализации admission webhook’ов Оказалось, что не очень много :(
что нам нужно) • Sync – например, в случае какого-то сложного развертывания • PostSync – например, провести какие-то тесты, подергать какие-то ручки • SyncFail – когда все плохо 70
ссылку на текущий репозиторий • У Job должна быть аннотация PreSync, а SyncWave, если задан, то быть больше или равен 0 • У ConfigMap и Secret должна быть аннотация PreSync и SyncWave, у SyncWave должно быть значение -1 79
окружения должны быть свои vault-path и vault-role аннотации • Нельзя использовать тег latest • Использовать можно только внутренний Docker Registry • У Deployment должны быть определенные лейблы 80
должны быть указаны • Ресурсы должны быть указаны • Контейнер должен запускаться с capabilities.Drop = All • Контейнер не может запускаться с capabilities.Add = SYS_ADMIN
root • Контейнер не может запускаться с runAsUser > 10000 • Контейнер может запускаться только с readOnlyFileSystem • Контейнер не может запускаться с privileged = true • В контейнер не должен быть проброшен Docker-сокет 83
sysadminkadesk
otanet
yoyoyopg
handy
you
bobtani
oracle4engineer
kommy339
joelq
satoshirobatofujimoto
yu4u
r74tech
9wick
chriscoyier
colly
sachag
sonatard
jponch
gr2m
cassininazir
eileencodes
holman
lemiorhan
tmm1
![Вопросы • https://github.com/leominov • https://t.me/leominov • [email protected] 93](https://files.speakerdeck.com/presentations/d05691466f1b4021a74072b9d04a865e/slide_92.jpg){kind=link}