"Вернись обратно"
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
Переключиться на предыдущий контекст Kubernetes
Переключиться на предыдущий namespace в Kubernetes
Переключиться на предыдущую ветку в git
Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
cd - Переключиться на предыдущий контекст Kubernetes
kubectx - Переключиться на предыдущий namespace в Kubernetes
kubens -Переключиться на предыдущую ветку в git
git checkout -Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
👍10❤2
#devops
Когда есть частая задача быстро смотреть содержимое секретов кубера, например пароли:
Пример использования:
Особенности:
- для тех, кто не любит тяжёлые плагины с kubectl или k9s
- эта функция-пример не учитывает неймспейс, но я всегда юзаю
*kvs - kube view secret
Когда есть частая задача быстро смотреть содержимое секретов кубера, например пароли:
~/.bashrc (или любой другой шелл)function kvs() {
kubectl get secret "$1" -o json | jq '.data | map_values(@base64d)'
}Пример использования:
> kvs grafana-monitoring
{
"admin-password": "pupupu",
"admin-user": "pupupu@pupupu.ded",
"ldap-toml": ""
}
Особенности:
- для тех, кто не любит тяжёлые плагины с kubectl или k9s
- эта функция-пример не учитывает неймспейс, но я всегда юзаю
kubens и свичусь всегда, так что для меня ок*kvs - kube view secret
👍10
#devops
Дотфайлы в репозитории: что, сколько?
В 2025 репо без дотфайлов - как микросервис без контейнера: не взлетает.
Они решают всё: от фильтра мусора до CI/CD и AI IDE.
Сколько их сейчас нужно для стандартного проекта?
5-10 - стандарт для микросервисов.
Меньше - тухло, больше 15 - безусловно перегиб.
Пробежимся по категориям.
1. Игнорирование: убираем мусор
2. Окружение: переменные
3. Инструменты: линтеры, форматтеры, хуки
5. CI/CD: автоматизация
6. Тесты и сборка
7. IDE/AI IDE: редакторы
Так сколько же? Для бизнес аппликейшн среднее значение 6-8:
.gitignore, .dockerignore, .CICD.yaml, .editorconfig, .pre-commit-config.yaml, .IDE.yaml + для стека
Для helm chart 3+:
.gitignore, .helmignore, .pre-commit-config.yaml, .yamllint.yaml
Для terra*/инфры 5+:
.gitignore, .editorconfig, .pre-commit-config.yaml, .IDE.yaml, .tflint, yamllint.yaml
Бежать и пилить все недостающие файлы? Не, конечно не стоит.
Каждый сам должен для себя решить когда и что ему нужно в проектах и постепенно добавлять то, чего не хватает команде и бизнесу. Взросление не происходит мгновенно.
Если не знаете с чего начать, то спросите любую нейронку какие дотфайлы нужны вам для вашего проекта и какой пример содержимого.
В конце концов есть даже генераторы и готовые сборки, например:
https://github.com/PatrickJS/awesome-cursorrules
https://github.com/sanjeed5/awesome-cursor-rules-mdc/
https://github.com/github/gitignore
https://github.com/toptal/gitignore
(искать через "awesome .DOTFILENAME")
У нас уже почти стандарт 7 файлов по минималке везде, кроме хелм чарта.
В монолит монорепе аж 14 дотфайлов. Все в работе.
* Безусловно я мог пропустить часть дотфайлов, либо забыл, либо не работал с ними.
** .CICD.yaml = ямл для того CICD, который на проекте, от трависа до гитхаба/гитлаба.
Update: конечно я забыл про один из главных файлов
Подробно писал про asdf тут https://xn--r1a.website/makebreakreflect/69
Дотфайлы в репозитории: что, сколько?
В 2025 репо без дотфайлов - как микросервис без контейнера: не взлетает.
Они решают всё: от фильтра мусора до CI/CD и AI IDE.
Сколько их сейчас нужно для стандартного проекта?
5-10 - стандарт для микросервисов.
Меньше - тухло, больше 15 - безусловно перегиб.
Пробежимся по категориям.
1. Игнорирование: убираем мусор
.gitignore - Очевидно, без вопросов. Чистит node_modules, логи, .env. Все знают, что тут..dockerignore - Почти все проекты - контейнеры. Фильтрует контекст Docker, чтобы не тащить лишнего. Писал тут https://xn--r1a.website/makebreakreflect/84 .helmignore - Как .dockerignore, но для Helm-чартов. Нужен для репо с чартами или гетерогенных пайплайнов..npmignore - Чистит лишнее при публикации npm-пакетов. Только для пакетов.2. Окружение: переменные
.env - Хранит DATABASE_URL, порты. В .gitignore, без вариантов..env.example/development/production - Шаблон(ы) .env для разных окружений.3. Инструменты: линтеры, форматтеры, хуки
.eslintrc - Линтинг JS/TS. Без него в JS/TS никуда..yamllint - Линтинг YAML - K8s, CI/CD. Если YAML много, надо..tflint - Линтинг Terraform. Для Terraform-проектов..prettierrc - Форматирует код. Почти везде..nvmrc - Фиксирует версию Node.js. Для Node..huskyrc - Преккоммит-хуки. Автопроверки перед коммитом..lintstagedrc - Линтинг только изменённых файлов. Работает с Husky..pre-commit-config.yaml - Конфиг для pre-commit. Например запускает линтеры (tflint, ESLint, chehov) перед коммитом. Для автопроверок. Must have как по мне для всех.5. CI/CD: автоматизация
.github/workflows/*.yml - Пайплайны GitHub Actions. Для GitHub CI/CD..gitlab-ci.yml - Пайплайны GitLab. Для GitLab.6. Тесты и сборка
.jest.config.js - Конфиг Jest для тестов JS/TS..tsconfig.json - Конфиг TypeScript. Для TS..vite.config.js - Сборка фронта/бэка. Для сложных сборок.7. IDE/AI IDE: редакторы
.editorconfig - Единые настройки редакторов. Для команд..cursorignore - Исключает файлы для AI в Cursor. Для Cursor. Например с локальным .env и паролями..cursorrules - правила Cursor IDE.cursor/rules/*.mdc - Правила для AI Cursor - стиль кода, ограничения. Для Cursor..windsurfrules - Правила Windsurf, стиль, ограничения..idea/ - Конфиги IntelliJ. Для JetBrainsТак сколько же? Для бизнес аппликейшн среднее значение 6-8:
.gitignore, .dockerignore, .CICD.yaml, .editorconfig, .pre-commit-config.yaml, .IDE.yaml + для стека
Для helm chart 3+:
.gitignore, .helmignore, .pre-commit-config.yaml, .yamllint.yaml
Для terra*/инфры 5+:
.gitignore, .editorconfig, .pre-commit-config.yaml, .IDE.yaml, .tflint, yamllint.yaml
Бежать и пилить все недостающие файлы? Не, конечно не стоит.
Каждый сам должен для себя решить когда и что ему нужно в проектах и постепенно добавлять то, чего не хватает команде и бизнесу. Взросление не происходит мгновенно.
Если не знаете с чего начать, то спросите любую нейронку какие дотфайлы нужны вам для вашего проекта и какой пример содержимого.
В конце концов есть даже генераторы и готовые сборки, например:
https://github.com/PatrickJS/awesome-cursorrules
https://github.com/sanjeed5/awesome-cursor-rules-mdc/
https://github.com/github/gitignore
https://github.com/toptal/gitignore
(искать через "awesome .DOTFILENAME")
У нас уже почти стандарт 7 файлов по минималке везде, кроме хелм чарта.
В монолит монорепе аж 14 дотфайлов. Все в работе.
* Безусловно я мог пропустить часть дотфайлов, либо забыл, либо не работал с ними.
** .CICD.yaml = ямл для того CICD, который на проекте, от трависа до гитхаба/гитлаба.
Update: конечно я забыл про один из главных файлов
.tool-versions - просто мастхэв.Подробно писал про asdf тут https://xn--r1a.website/makebreakreflect/69
👍10❤1😢1🤡1
#docker #devsecops #paranoia #devops
Что у нас есть в пайплайнах?
Линтер питон скриптов, валидация YAML, tflint для терраформа, checkov для безопасности, git-leaks, sonarqube, скоринг кода, sast, dast и многое другое. Миллионы всего.
Всем и всё это знакомо.
А что по
Есть великолепный проект для простых проверок:
https://github.com/hadolint/hadolint
Его можно добавить в pre-commit hook
https://github.com/hadolint/hadolint/blob/master/.pre-commit-hooks.yaml
Можно добавить в pipeline.
Что он умеет?
- проверка и анализ Docker на соответствие лучшим практикам
- интеграция с ShellCheck (моя любовь ❤️), но нужно не для всех
- гибкий конфиг через .hadolint.yaml
- поддержка игнора
- интеграция с CICD
Всё-всё, хватит пустых слов, что он умеет можно почитать и в документации, давайте к практике и примеру.
Добавляем его в наш основной канико(да когда ж ты умрёшь?!) имадж, используемый для сборок:
Ок, базовый имадж есть.
Теперь добавляем его в основной общий пайплайн.
Например запускать можно так на этапе сборки имаджа.
Что тут проверяем?
- чтобы всегда стоял тег бейз имаджа
https://github.com/hadolint/hadolint/wiki/DL3006
- чтобы тег бейз имаджа был НЕ latest
https://github.com/hadolint/hadolint/wiki/DL3007
Выше пример лишь для двух проверок(полный список есть на гитхабе).
Можно использовать всё и игнорировать что-то(в комментах докерфайла например).
Как вам надо, так и делайте. Конкретно для себя мне нравятся лишь эти две проверки.
Ещё один инструмент в нашем бесконечном списке бесконечных инструментов.
Что у нас есть в пайплайнах?
Линтер питон скриптов, валидация YAML, tflint для терраформа, checkov для безопасности, git-leaks, sonarqube, скоринг кода, sast, dast и многое другое. Миллионы всего.
Всем и всё это знакомо.
А что по
Dockerfile?Есть великолепный проект для простых проверок:
https://github.com/hadolint/hadolint
Его можно добавить в pre-commit hook
https://github.com/hadolint/hadolint/blob/master/.pre-commit-hooks.yaml
Можно добавить в pipeline.
Что он умеет?
- проверка и анализ Docker на соответствие лучшим практикам
- интеграция с ShellCheck (моя любовь ❤️), но нужно не для всех
- гибкий конфиг через .hadolint.yaml
- поддержка игнора
- интеграция с CICD
Всё-всё, хватит пустых слов, что он умеет можно почитать и в документации, давайте к практике и примеру.
Добавляем его в наш основной канико(да когда ж ты умрёшь?!) имадж, используемый для сборок:
FROM gcr.io/kaniko-project/executor:v1.23.1-debug
ENV TRIVY_VERSION=0.61.0 \
CRANE_VERSION=0.19.0 \
HADOLINT=v2.12.0
RUN wget --no-verbose https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz && \
tar -zxvf trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz -C /kaniko && \
rm -f trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz
RUN wget --no-verbose https://github.com/google/go-containerregistry/releases/download/v${CRANE_VERSION}/go-containerregistry_Linux_x86_64.tar.gz && \
tar -zxvf go-containerregistry_Linux_x86_64.tar.gz -C /kaniko && \
rm -f go-containerregistry_Linux_x86_64.tar.gz && \
rm -f /kaniko/LICENSE /kaniko/README.md
RUN wget --no-verbose https://github.com/hadolint/hadolint/releases/download/${HADOLINT}/hadolint-Linux-x86_64 && \
mv hadolint-Linux-x86_64 /kaniko/hadolint && \
chmod +x /kaniko/hadolint
Ок, базовый имадж есть.
Теперь добавляем его в основной общий пайплайн.
Например запускать можно так на этапе сборки имаджа.
# Lint the Dockerfile
echo "Executing hadolint check on $dockerfilePath"
/kaniko/hadolint $dockerfilePath --error DL3006 --error DL3007 --failure-threshold error
Что тут проверяем?
- чтобы всегда стоял тег бейз имаджа
https://github.com/hadolint/hadolint/wiki/DL3006
- чтобы тег бейз имаджа был НЕ latest
https://github.com/hadolint/hadolint/wiki/DL3007
Выше пример лишь для двух проверок(полный список есть на гитхабе).
Можно использовать всё и игнорировать что-то(в комментах докерфайла например).
Как вам надо, так и делайте. Конкретно для себя мне нравятся лишь эти две проверки.
Ещё один инструмент в нашем бесконечном списке бесконечных инструментов.
👍17
#security #git #devops
Часть 1 из 2.
Рано или поздно все инженеры начинают расти профессионально.
Мы узнаем лучшие практики, оптимизируем существующий стек или инфру, внедряем новые технологии.
В какой-то момент мы даже следуем бест практис по security.
Добавление сканеров, проверки на бесящие всех CVE, пайплайны, pre-commit hooks и selinux/securitycontext.
Перечислять всё не буду, это невероятно огромная область.
Ноинтернет git всё помнит.
Git is the source of truth, как говорит мой коллега.
Это сейчас мы внедрили все практики и больше нет утечек паролей и токенов в гит, а храним всё в vault/aws sm/azure sa.
А что же в истории git?
В гите у нас могут остаться:
- токены
- private keys
- пароли
Давайте проверим и почистим за собой в репозитории.
Экспериментировать мы будем на публичных репах, чтобы вы сперва потренировались, ДО того, как будете ломать свои реальные репозитории🤣 .
Предварительная подготовка
- установить
Эта штука позволяет найти секреты во всех ветках всех файлах всей гит истории.
Описание есть в ридми.
- устанавливаем
- устанавливаем
я просто сделал так
Эта штука помогает удалить лишнее найденное из гита.
- устанавливаем
эта штука нам нужна для разового парсинга
- ну и
Приступаем к поиску и очистке.
- форкаем себе рандом популярный проект, а почему бы и да
Ищём тут https://github.com/trending?since=monthly
есть какой-то
- клонируем себе форкнутый проект (у вас путь другой будет само собой)
- запускаем сканер утечки чувствительных данных не меняя директорию
Результатом будет джейсон файл с детальным описанием кто, когда, что и за тип секретов.
Можете открыть и посмотреть, что там утек 1 токен от разработчика(он может быть и реальным и фейком).
- Для удобства очищаем его от всего лишнего
Для чего мы это делаем?
Чтобы сгенерить и проверить содержимое файла passwords.txt и ЕСЛИ в нём есть то, чего НЕ НАДО удалять из гита и оно бы осталось в гите, надо убрать из этого файла.
В этом файле то, что будет в последствии удалено из гита.
- заходим в гит репозиторий
- запускам
Видим длинную простыню текста, типа
- ещё раз смотрим чего же мы там меняем(если есть хоть любые сомнения, прерывайте процесс! операция без бекапов не поддаётся восстановлению!!!)
Часть 1 из 2.
Рано или поздно все инженеры начинают расти профессионально.
Мы узнаем лучшие практики, оптимизируем существующий стек или инфру, внедряем новые технологии.
В какой-то момент мы даже следуем бест практис по security.
Добавление сканеров, проверки на бесящие всех CVE, пайплайны, pre-commit hooks и selinux/securitycontext.
Перечислять всё не буду, это невероятно огромная область.
Но
Git is the source of truth, как говорит мой коллега.
Это сейчас мы внедрили все практики и больше нет утечек паролей и токенов в гит, а храним всё в vault/aws sm/azure sa.
А что же в истории git?
В гите у нас могут остаться:
- токены
- private keys
- пароли
Давайте проверим и почистим за собой в репозитории.
Экспериментировать мы будем на публичных репах, чтобы вы сперва потренировались, ДО того, как будете ломать свои реальные репозитории
Предварительная подготовка
- установить
gitleaks https://github.com/gitleaks/gitleaksЭта штука позволяет найти секреты во всех ветках всех файлах всей гит истории.
Описание есть в ридми.
- устанавливаем
java- устанавливаем
bfg https://rtyley.github.io/bfg-repo-cleaner/я просто сделал так
wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar
Эта штука помогает удалить лишнее найденное из гита.
- устанавливаем
jq https://github.com/jqlang/jqэта штука нам нужна для разового парсинга
- ну и
gitПриступаем к поиску и очистке.
- форкаем себе рандом популярный проект, а почему бы и да
Ищём тут https://github.com/trending?since=monthly
есть какой-то
microsoft/qlib- клонируем себе форкнутый проект (у вас путь другой будет само собой)
git clone git@github.com:kruchkov-alexandr/qlib.git
- запускаем сканер утечки чувствительных данных не меняя директорию
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json
○
│╲
│ ○
○ ░
░ gitleaks
12:23PM INF 1790 commits scanned.
12:23PM INF scan completed in 696ms
12:23PM WRN leaks found: 1
Результатом будет джейсон файл с детальным описанием кто, когда, что и за тип секретов.
Можете открыть и посмотреть, что там утек 1 токен от разработчика(он может быть и реальным и фейком).
- Для удобства очищаем его от всего лишнего
cat findings.json | jq -r '.[].Secret' > passwords.txt
Для чего мы это делаем?
Чтобы сгенерить и проверить содержимое файла passwords.txt и ЕСЛИ в нём есть то, чего НЕ НАДО удалять из гита и оно бы осталось в гите, надо убрать из этого файла.
В этом файле то, что будет в последствии удалено из гита.
- заходим в гит репозиторий
cd qlib
- запускам
bfg>java -jar ../bfg-1.14.0.jar --replace-text ../passwords.txt
Видим длинную простыню текста, типа
Commit Tree-Dirt History
------------------------
Earliest Latest
| |
.........................................................DDm
D = dirty commits (file tree fixed)
m = modified commits (commit message or parents changed)
. = clean commits (no changes to file tree)
Before After
-------------------------------------------
First modified commit | 21f0b394 | b3d34764
Last dirty commit | 63021018 | abf5a1bf
Changed files
-------------
Filename Before & After
---------------------------------------------------
data.py | 8de32f3f ⇒ 82298fe3, f6bd7809 ⇒ 8bd16038
In total, 159 object ids were changed. Full details are logged here:
/home/***/GIT/INTERNET/qlib.bfg-report/2025-06-12/12-24-52
- ещё раз смотрим чего же мы там меняем(если есть хоть любые сомнения, прерывайте процесс! операция без бекапов не поддаётся восстановлению!!!)
cat /home/***/GIT/INTERNET/qlib.bfg-report/202*-0*-**/12-24-52/changed-files.txt
8de32f3f6c0373ca1b41fe6d3f4dbd4c23685d71 82298fe3811f0c36aa982a1ff23ee92289cc9346 data.py
f6bd780905649d8d004c13bd98a91044958b9573 8bd160386147b2007172e618dbe049b02cd4bcc3 data.py
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😨2
#security #git #devops
Часть 2 из 2.
- теперь мы выдыхаем, принимаем решение и чистим
Это мы почистили ЛОКАЛЬНО гит, пока на ремоут сервер не заливали.
- проверяем, что локально всё чисто
То есть проверка показала, что все токены и пароли были удалены.
- крестимся и пушим в ремоут
Всё, история в нашем форке почищена.
Можно ещё раз проверить всё
- удаляем локальный репозиторий
- клонируем с ремоута
- проверяем на утечки
- радуемся, что даже в истории гита нет утечек
Инструкция написана максимально подробно, чтобы те, кто подобного раньше никогда не делали, не допустили бы глупых ошибок. Сперва потренируйтесь на паблик репозиториях, отточите все действия до полного понимания и только потом надо чистить реальные репозитории на работе.
На реальных боевых репозиториях в идеале сделать бекап, прям gzip файлом, до всех изменений, если опыта мало и только потом приступать.
Инструкция длинная, кажется сложно, но на самом деле это лишь 5 команд и всё.
Не бойтесь. Вы - инженер.
Часть 2 из 2.
- теперь мы выдыхаем, принимаем решение и чистим
git reflog expire --expire=now --all && git gc --prune=now --aggressive
Это мы почистили ЛОКАЛЬНО гит, пока на ремоут сервер не заливали.
- проверяем, что локально всё чисто
cd ..
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json
○
│╲
│ ○
○ ░
░ gitleaks
12:29PM INF 1790 commits scanned.
12:29PM INF scan completed in 722ms
12:29PM INF no leaks found
То есть проверка показала, что все токены и пароли были удалены.
- крестимся и пушим в ремоут
cd qlib
git push origin --force
Всё, история в нашем форке почищена.
Можно ещё раз проверить всё
- удаляем локальный репозиторий
cd ..
sudo rm -r qlib
- клонируем с ремоута
git clone git@github.com:kruchkov-alexandr/qlib.git
- проверяем на утечки
gitleaks detect --source qlib --log-opts="--all" --report-path findings.json
○
│╲
│ ○
○ ░
░ gitleaks
12:33PM INF 1790 commits scanned.
12:33PM INF scan completed in 731ms
12:33PM INF no leaks found
- радуемся, что даже в истории гита нет утечек
Инструкция написана максимально подробно, чтобы те, кто подобного раньше никогда не делали, не допустили бы глупых ошибок. Сперва потренируйтесь на паблик репозиториях, отточите все действия до полного понимания и только потом надо чистить реальные репозитории на работе.
На реальных боевых репозиториях в идеале сделать бекап, прям gzip файлом, до всех изменений, если опыта мало и только потом приступать.
Инструкция длинная, кажется сложно, но на самом деле это лишь 5 команд и всё.
Не бойтесь. Вы - инженер.
👍16
#helm #devops
Валидации, проверки, линтеры.
Как много мы о них говорим, но и как это иногда важно.
У меня есть helm chart.
После изменения любых параметров или темплейтов я его проверяю.
- unit tests (ооооооочень редко и не всем нужно)
- linter
Дальше публикация и куда-то релиз.
Чарт готов, чарт проверен в пайплайне и пре-коммит хуками.
А что с values файлами на стороне приложений?
У меня же есть прекрасные коллеги с ровными руками.
Они могут в values файлах своих репозиториев при использовании нашего общего чарта допустить ошибку.
Ну так бывает, все ошибаются.
Могут написать "true" вместо true, могут не там сделать indent или вообще половину indent(1/3).
Которые при любых проблемах обвиняют девопсов😮 🫵 😮 .
Как быть тут?
На помощь мне приходит
То есть на базе template мы генерируем schema.yaml файл, по которому будет идти сравнение values.yaml файлов у коллег.
Для начала я потренируюсь на кошках и возьму классный чарт отличного продукта
https://github.com/cloudnative-pg/charts
Клонирую его себе
Затем мне надо написать схему.
Буду ли я просить нейронки?
👎 Да пошли они в хер, с ними голова вообще перестала работать.🐒
Буду ли я сам писать схему?
Да щас🤣 .
Иду в awesome helm репу, ищу есть ли чего у нас там для скима валидейшн.
https://github.com/cdwv/awesome-helm
Нахожу поиском там генератор (второй депрекейтед)
https://github.com/dadav/helm-schema
Читаю - всё ок, отлично подходит под мою задачу.
Качаю, распаковываю и так далее
Теперь иду в свой склонированный cnpg репозиторий
и просто запускаю бинарь
Результатом будет json файл(ы) в каждом чарте.
Один из файлов выглядит так
https://gist.github.com/kruchkov-alexandr/dc4cf3e4ac9af5719fb435d42e1873e6
Чарт есть, генератор схема валидейшн есть, схема есть.
Осталось научиться проверять.
У меня есть три основных варианта использования схемы:
- подсунуть комментарии-аннотации в values.yaml
- в VSCode мышкой клацнуть на схему и сам vscode будет подсвечивать ошибки
- команда в терминале в CICD
Мне больше нравится последний вариант автоматизации.
Немного душноты:
- команда
- если есть файл
Валидации, проверки, линтеры.
Как много мы о них говорим, но и как это иногда важно.
У меня есть helm chart.
После изменения любых параметров или темплейтов я его проверяю.
- unit tests (ооооооочень редко и не всем нужно)
helm unittest ./helm-chart
- linter
helm lint helm-chart
Дальше публикация и куда-то релиз.
helm package helm-chart
Чарт готов, чарт проверен в пайплайне и пре-коммит хуками.
А что с values файлами на стороне приложений?
У меня же есть прекрасные коллеги с ровными руками.
Они могут в values файлах своих репозиториев при использовании нашего общего чарта допустить ошибку.
Ну так бывает, все ошибаются.
Могут написать "true" вместо true, могут не там сделать indent или вообще половину indent(1/3).
Которые при любых проблемах обвиняют девопсов
Как быть тут?
На помощь мне приходит
schema validation.То есть на базе template мы генерируем schema.yaml файл, по которому будет идти сравнение values.yaml файлов у коллег.
Для начала я потренируюсь на кошках и возьму классный чарт отличного продукта
https://github.com/cloudnative-pg/charts
Клонирую его себе
git clone git@github.com:cloudnative-pg/charts.git
Затем мне надо написать схему.
Буду ли я просить нейронки?
Буду ли я сам писать схему?
Да щас
Иду в awesome helm репу, ищу есть ли чего у нас там для скима валидейшн.
https://github.com/cdwv/awesome-helm
Нахожу поиском там генератор (второй депрекейтед)
https://github.com/dadav/helm-schema
Читаю - всё ок, отлично подходит под мою задачу.
Качаю, распаковываю и так далее
wget https://github.com/dadav/helm-schema/releases/download/0.18.1/helm-schema_0.18.1_Linux_x86_64.tar.gz
tar -xvf helm-schema_0.18.1_Linux_x86_64.tar.gz
chmod +x helm-schema
sudo cp helm-schema /usr/local/bin/
Теперь иду в свой склонированный cnpg репозиторий
cd ~/GIT/INTERNET/cnpg/ #(у вас путь другой будет само собой)
и просто запускаю бинарь
helm-schema
Результатом будет json файл(ы) в каждом чарте.
Один из файлов выглядит так
https://gist.github.com/kruchkov-alexandr/dc4cf3e4ac9af5719fb435d42e1873e6
Чарт есть, генератор схема валидейшн есть, схема есть.
Осталось научиться проверять.
У меня есть три основных варианта использования схемы:
- подсунуть комментарии-аннотации в values.yaml
- в VSCode мышкой клацнуть на схему и сам vscode будет подсвечивать ошибки
- команда в терминале в CICD
Мне больше нравится последний вариант автоматизации.
Немного душноты:
- команда
helm template генерирует(рендерит) YAML манифесты.- если есть файл
JSON со схемой, то helm template проверяет ещё и схему!Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
#helm #devops
Поехали проверять.
Всё ок, нет проблем, куча манифестов срендерилось.
Теперь иду в файл
и меняю
на
Снова запускаю и получаю ошибку
Отлично, у меня есть
- мой чарт/чарты
- автоматическая генерация схемы путем
То есть когда мы что-либо меняем в своём чарте, то у нас и автоматическая проверка идёт и автоматически генерируется и в гите обновляется схема.
Дальше я свой общий
Так, а что у нас с GitOps ArgoCD подходом?
Ведь мы там не используем helm в чистом виде и нет понятия релиза.
Читаю документацию
https://argo-cd.readthedocs.io/en/stable/user-guide/helm/
Ура, под капотом ArgoCD использует как раз helm template, а значит мы при syncing увидим не просто ошибку, а ошибку в каком конкретно месте у нас ошибка.
Итог:
- в самом чарте появилась схема, к тому же она автоматически обновляется при каждом изменении чарта
- при использовании helm для релизов в моём pipeline я добавляю
- в случае работы с ArgoCD у меня так же проверяется схема, снижая количество человеческих ошибок
- и со стороны чарта и со стороны репозиториев разработчиков есть🐒 )
Поздравляю - мы снова добавили какую-то очереднуюхероту автоматизацию и валидацию 🤣
Поехали проверять.
helm template alexk-test charts/cluster/
Всё ок, нет проблем, куча манифестов срендерилось.
Теперь иду в файл
charts/cluster/values.yamlи меняю
endpointCA:
create: false
на
endpointCA:
create: "false"
Снова запускаю и получаю ошибку
helm template alexk-test charts/cluster/
Error: values don't meet the specifications of the schema(s) in the following chart(s):
cluster:
- recovery.endpointCA.create: Invalid type. Expected: boolean, given: string
Отлично, у меня есть
- мой чарт/чарты
- автоматическая генерация схемы путем
pre-commit и/или CICD команды схемы для чарта до релиза чартаТо есть когда мы что-либо меняем в своём чарте, то у нас и автоматическая проверка идёт и автоматически генерируется и в гите обновляется схема.
Дальше я свой общий
pipeline для приложений коллег добавляю шаг helm template и он до релиза проверяет values.yaml файлы пользователей и коллег.Так, а что у нас с GitOps ArgoCD подходом?
Ведь мы там не используем helm в чистом виде и нет понятия релиза.
Читаю документацию
https://argo-cd.readthedocs.io/en/stable/user-guide/helm/
Ура, под капотом ArgoCD использует как раз helm template, а значит мы при syncing увидим не просто ошибку, а ошибку в каком конкретно месте у нас ошибка.
Итог:
- в самом чарте появилась схема, к тому же она автоматически обновляется при каждом изменении чарта
- при использовании helm для релизов в моём pipeline я добавляю
helm template для проверки корректности values.yaml файлов разработчиков- в случае работы с ArgoCD у меня так же проверяется схема, снижая количество человеческих ошибок
- и со стороны чарта и со стороны репозиториев разработчиков есть
pre-commit hooks (если на них забиваютПоздравляю - мы снова добавили какую-то очередную
Please open Telegram to view this post
VIEW IN TELEGRAM
✍9🔥6❤1
#aws #devops #EKS #IRSA
На одном проекте пришла задача избавиться от IAM-кредов в подах и перейти на роли.
Есть три давно созданных EKS-кластера. Я написал Terraform-код: полиси, роль, policy attachment, service account, OIDC и всё остальное. Поправил Helm-чарт, добавив service account. Прокатил изменения по всем кластерам - всё ок.
На DEV я убрал IAM-креды из секретов, чтобы CDK перешёл на роль - всё ок. Сто раз всё проверил: секреты почистил, аппликейшены передеплоил, в AWS-консоли видно, что роль используется, IAM-креды - нет. Удалил IAM для DEV - всё работает. Повторил на STAGE - тоже всё ок.
И тут прод. Удалил креды - и всё рухнуло к чертям. Поды начали использовать роль ноды 🤡, у которой, естественно, нет доступа ко всем ресурсам AWS. Вернул креды, откатил, прод поднял, получил по щщам и начал дебажить.
Сто раз перепроверил Terraform-код - всё идентично. Проверил OIDC, IRSA, роли - всё совпадает, проблем нет. Но почему-то на проде поды не берут нужную роль.
Нырнул в документацию и пошёл шаг за шагом. Это был скучный этап, просто читал, как всё это работает в кишках. Через пару часов упёрся в мутейшн хуки.
Проверил
dev
stage
prod
Кто-то (или что-то) когда-то как-то удалил pod-identity-webhook на проде. Как так вышло - история умалчивает, это останется тайной. Жаль только часов дебага, когда я матчил код, роли, OIDC и IRSA, не подозревая, что мутейшн хука просто нет.🚶♀
Что делает этот вебхук? (текст украден из чата кубера):
- Добавляет переменные среды:
Добавляет в волумы:
И всё. Дальше куб сам выписывает SA-токен с aud: sts.amazonaws.com.
Принял быстрый фикс:
Установил cert-manager (если его не было):
Склонировал и развернул:
Проверил логи:
Запустил тест:
Получил:
Ура, теперь поды используют новую роль. Убил тестовый под. Удалил IAM-креды, накатил снова - всё ок.
Задача решена.🎉
.....
Прошло пару дней.
.....
Сижу, значит, пишу этот текст-заметку, пока не забыл, и задумался: неужели такое возможно в 2025? Зачем? Зачем, мистер Андерсон, вообще руками что-то ставить в кластер,
Читаю за утренним кофе документацию, пока жена не видит:
- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
- https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html
Дошёл до:
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_pod_identity_association
.
..
...
Прочитал, промолчал, набычился, посмотрел на пол, закатил глаза, наделkubectl apply -f клоунский нос 🤡 и отправил пост в телеграм.
На одном проекте пришла задача избавиться от IAM-кредов в подах и перейти на роли.
Есть три давно созданных EKS-кластера. Я написал Terraform-код: полиси, роль, policy attachment, service account, OIDC и всё остальное. Поправил Helm-чарт, добавив service account. Прокатил изменения по всем кластерам - всё ок.
На DEV я убрал IAM-креды из секретов, чтобы CDK перешёл на роль - всё ок. Сто раз всё проверил: секреты почистил, аппликейшены передеплоил, в AWS-консоли видно, что роль используется, IAM-креды - нет. Удалил IAM для DEV - всё работает. Повторил на STAGE - тоже всё ок.
И тут прод. Удалил креды - и всё рухнуло к чертям. Поды начали использовать роль ноды 🤡, у которой, естественно, нет доступа ко всем ресурсам AWS. Вернул креды, откатил, прод поднял, получил по щщам и начал дебажить.
Сто раз перепроверил Terraform-код - всё идентично. Проверил OIDC, IRSA, роли - всё совпадает, проблем нет. Но почему-то на проде поды не берут нужную роль.
Нырнул в документацию и пошёл шаг за шагом. Это был скучный этап, просто читал, как всё это работает в кишках. Через пару часов упёрся в мутейшн хуки.
Проверил
mutatingwebhookconfigurations:dev
kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook
stage
kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook
prod
kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
hui
Кто-то (или что-то) когда-то как-то удалил pod-identity-webhook на проде. Как так вышло - история умалчивает, это останется тайной. Жаль только часов дебага, когда я матчил код, роли, OIDC и IRSA, не подозревая, что мутейшн хука просто нет.
Что делает этот вебхук? (текст украден из чата кубера):
- Добавляет переменные среды:
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount
AWS_ROLE_ARN (значение берётся из аннотации к SA)
Добавляет в волумы:
- name: aws-iam-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: sts.amazonaws.com
expirationSeconds: 86400
path: token
...
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
name: aws-iam-token
readOnly: true
И всё. Дальше куб сам выписывает SA-токен с aud: sts.amazonaws.com.
Принял быстрый фикс:
Установил cert-manager (если его не было):
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml
Склонировал и развернул:
git clone https://github.com/aws/amazon-eks-pod-identity-webhook
cd amazon-eks-pod-identity-webhook
make cluster-up IMAGE=amazon/amazon-eks-pod-identity-webhook:latest
Проверил логи:
kubectl logs -n default -l app=pod-identity-webhook
Запустил тест:
kubectl run irsa-test --image=amazon/aws-cli -n production --overrides='{"spec":{"serviceAccountName":"new-sa"}}' --command -- sh -c "aws sts get-caller-identity && sleep 3600"Получил:
{
"UserId": "54252523:botocore-session-2345452354",
"Account": "2345452345",
"Arn": "arn:aws:sts::234534524:assumed-role/expected-new-role/botocore-session-345235"
}Ура, теперь поды используют новую роль. Убил тестовый под. Удалил IAM-креды, накатил снова - всё ок.
Задача решена.🎉
.....
Прошло пару дней.
.....
Сижу, значит, пишу этот текст-заметку, пока не забыл, и задумался: неужели такое возможно в 2025? Зачем? Зачем, мистер Андерсон, вообще руками что-то ставить в кластер,
kubectl apply -f??Читаю за утренним кофе документацию, пока жена не видит:
- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
- https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html
Дошёл до:
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_pod_identity_association
.
..
...
Прочитал, промолчал, набычился, посмотрел на пол, закатил глаза, надел
Please open Telegram to view this post
VIEW IN TELEGRAM
😁16👍2😨2
#github #devops
Заметка капитана очевидности.
Когда мне надо что-то найти для задачи/работы, но "я пока не знаю что", то я начинаю запрос с
Иногда ищу в Google, иногда сразу на GitHub.
99.9% результата поиска в Google всё равно ведёт в GitHub.
Это может быть что угодно:
- алёрты alertmanager
https://samber.github.io/awesome-prometheus-alerts/
- хуки гита
https://github.com/compscilauren/awesome-git-hooks#readme
- cheat sheets гита
https://github.com/arslanbilal/git-cheat-sheet#readme
- утилиты Kubernetes
https://github.com/vilaca/awesome-k8s-tools
https://github.com/ksoclabs/awesome-kubernetes-security
https://github.com/magnologan/awesome-k8s-security
https://github.com/calvin-puram/awesome-kubernetes-operator-resources
- системные утилиты
https://github.com/luong-komorebi/Awesome-Linux-Software
https://github.com/cuongndc9/awesome-linux-apps
- чего-то для баша
https://github.com/awesome-lists/awesome-bash
- фреймворки go
https://github.com/avelino/awesome-go
- правила для Cursor IDE
https://github.com/PatrickJS/awesome-cursorrules
- либы питона
https://github.com/uhub/awesome-python
- платные и бесплатные статуспейджи, селдфхостед и менеджед
https://github.com/ivbeg/awesome-status-pages
- MSP
https://github.com/guardzcom/awesome-msp
- для Helm
https://github.com/cdwv/awesome-helm
- MCP сервера
https://github.com/punkpeye/awesome-mcp-servers
Список почти бесконечный.
Утилиты, книги, плагины, tips&tricks, темплейты.
Заметка капитана очевидности.
Когда мне надо что-то найти для задачи/работы, но "я пока не знаю что", то я начинаю запрос с
awesome.Иногда ищу в Google, иногда сразу на GitHub.
99.9% результата поиска в Google всё равно ведёт в GitHub.
Это может быть что угодно:
- алёрты alertmanager
https://samber.github.io/awesome-prometheus-alerts/
- хуки гита
https://github.com/compscilauren/awesome-git-hooks#readme
- cheat sheets гита
https://github.com/arslanbilal/git-cheat-sheet#readme
- утилиты Kubernetes
https://github.com/vilaca/awesome-k8s-tools
https://github.com/ksoclabs/awesome-kubernetes-security
https://github.com/magnologan/awesome-k8s-security
https://github.com/calvin-puram/awesome-kubernetes-operator-resources
- системные утилиты
https://github.com/luong-komorebi/Awesome-Linux-Software
https://github.com/cuongndc9/awesome-linux-apps
- чего-то для баша
https://github.com/awesome-lists/awesome-bash
- фреймворки go
https://github.com/avelino/awesome-go
- правила для Cursor IDE
https://github.com/PatrickJS/awesome-cursorrules
- либы питона
https://github.com/uhub/awesome-python
- платные и бесплатные статуспейджи, селдфхостед и менеджед
https://github.com/ivbeg/awesome-status-pages
- MSP
https://github.com/guardzcom/awesome-msp
- для Helm
https://github.com/cdwv/awesome-helm
- MCP сервера
https://github.com/punkpeye/awesome-mcp-servers
Список почти бесконечный.
Утилиты, книги, плагины, tips&tricks, темплейты.
🔥19❤3