#aws #пятница #terraform

Магия "у меня локально всё работает".

Пишет мне мой приятель, у которого я какое-то короткое время менторил(а такое слово вообще есть?)
"Алекс, Алекс, спасити памагити, у меня беда".
Сегодня он вносил небольшие правки в терраформ.
Запустил план на дев, на стейдж, на прод - все ок.
Аппрув, мерж в мастер и.. а терраформ план и апплай перенакатывает ему виртуалку с ec2🐒
Я помог ему восстановить сервис(вне этой заметки, отдельная стори и причина звонка), а затем мы начали разбираться, а как так вышло то, эй.

Шарит экран, говорит вот локально с мастера делаю план на дев, стейдж, проде, - всё ок.
Выдохнув, спрашиваю, а что ты знаешь про version constraints у терраформа?
Ну он, конечно же, ничего не знал.
Скидываю ему пример

= X.Y.Z - точная версия: version = "= 4.0.0" (только 4.0.0).
>= X.Y.Z - минимум и выше: version = ">= 4.0.0" (4.0.0 и выше).
<= X.Y.Z - максимум и ниже: version = "<= 4.0.0" (до 4.0.0 включительно).
> X.Y.Z - выше указанной: version = "> 4.0.0" (4.0.1 и выше).
< X.Y.Z - ниже указанной: version = "< 4.0.0" (до 4.0.0, не включая).
~> X.Y - в пределах мажорной: version = "~> 4.0" (4.0.x, но не 5.0).
>= X.Y.Z, < X.Y.Z - диапазон: version = ">= 4.0.0, < 5.0.0" (4.x.x, но не 5.x.x).

Смотрим его код, а там есть

...
version = ">= 5.0"
...

Лезем в
https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.0.0
охреневаем от брейкинг чейнджев
Приятель пилит сам у себя все версии в лок, проблема решена.

Он проверял локально и провайдер брался из кеша - проблемы не видел.
В CI/CD при каждом запуске запускался terrafrom init, что подтянул ему новую версию, которая триггернула пересоздание виртуалки.

Дальше была проверка всего кода tflint, checkov и другими утилитами, нашли ещё 4 места, где версии были плавающими, поправили и это.

Ну зато узнал что-то новое, чо.

#kubernetes #java

Считаю, что java великолепный язык, но он не подходит для работы в Kubernetes из коробки.

- Долгий холодный старт *
Да, есть современные фреймворки типа Quarkus или Micronaut, но у них есть и свои другие минусы по сравнению со спрингбут. Экосистема крайне малая.
- Большое жорево ресурсов при старте, но потом кушает совсем немного (при малом рпс).
Отсюда сложности расчётов "да сколько тебе ставить реквестов?".
Поставишь мало - как юсадж - ещё медленнее будет стартовать, поставишь много - оверкоммит ресурсов и кластер впустую простаивает.
В 2025 может решаться через новые альфа фичи https://kubernetes.io/docs/concepts/workloads/autoscaling/#in-place-pod-vertical-scaling , но я сам руками ещё не пробовал.
- размеры имаджей для джавы больше остальных рантаймов (аргумент высосан из практики 2-3 летней давности, когда крутил на базе OpenJDK, сейчас может ок). Просто мнение, его можно не считать.
- realtime/driven-event в связке HPA/KEDA это не про джаву (см. первый пункт *)
- исключительно на мой взгляд всратый GC, который, к тому же, может вызывать спонтанные OOMирания
Говорят, что переход на GraalVM может решить проблему, но не могу контр аргументировать, не было опыта.
- без опыта с джавой и кубером для первого старта это боль подстроить все десятки параметров, от метаспейс до размера кучи. Ты вынужден изучить все параметры, чтоб это хоть как-то стартовало в кубере.
Когда опыт есть конечно ок, поставил нужные параметры и полетело. Одно из самых сложных как по мне.
- логи, стактрейсы это стыд на 99999 строчек, нужен ультравайд монитор поставить вертикально, чтобы уместить весь аутпут. Обязательно вскроются проблемы с тем, что в системе логировании этот стактрейс будет разбит на отдельные строки, а не в одном сообщении и надо подстраивать. Ну почему бы не сделать сразу и нормально, ну камон?
- сложности с graceful shutdown
Честно говоря не помню почему, может есть специфика, может баг, а может мои кривые руки(скорее всего🐒), но спрингбут срать хотел на сигтерм от кублета.
POD висит 30 секунд, спрингбут закрывает контекст, а юзеры уже видят 503.
Когда с ним работал, решал эту проблему через терминейшн период 60 секунд, но это вообще неудобно при деплое, он очень долгий становится.
- отвратительно неудобное профилирование и снятие дампов в случае траблшутинга
Несколько раз надо было понять почему память течёт, как барышни на концерте Моя Мишель, вообще неудобно было. Может сейчас с этим проще.

Люблю ли я джаву? Да.
Готова ли она из коробки* к куберу? Нет.

* с популярным фреймворком спрингбут

Всё вышенаписанное не является истиной, лишь мнение одного инженера из 8 миллиардов человек на планете.

#troubleshooting #одинденьизжизни

Процесс мышления трабшутинга. Опять.
Часть 1 из 2.

Прилетает алёрт "рестарт пода с опенсёрч".
Потом 2 пода, тут же все 5 мастер подов".
Бегу смотреть.

Захожу в кластер, переключаюсь в неймспейс, где опенсёрч (он у нас в куберентисах).
Смотрю

kubectl get pods |grep opensearch

Да, есть рестарты.
Есть 5 подов master, 5 подов warm nodes, 5 cold nodes, 2 dashboards.
Рестарты у всех 5 мастеров, у остальных рестартов нет.
Ок, а какая причина? ООМ? Ошибка приложения? Конфигурация?

kubectl get pod PODNAME -o yaml | grep -A4 -i reason

Показывает, что exit code 1, то есть ошибка внутри приложения, не со стороны самого кубернетиса.
Смотрю логи одного из мастеров опенсёрча

kubectl logs PODNAMEMASTER

Внутри весёлые и любимые всем портянки java stacktrace.
Переворачиваю свой ультравайд монитор вертикально и читаю что же за причина.
Ага, ругается на какой-то сертификат TLS, который протух.

notBefore=J***l  8 06:58:13 2024 GMT
notAfter=***  8 06:58:13 2025 GMT

Переворачиваем монитор обратно в горизонтальное положение.
Смотрим какие есть сертификаты

kubectl get certificates | grep opensearch

Много сертров, часть с 365 дней(как бы намекает), часть 728, часть 180 дней.
Так, проблема в серте для опенсёрча, опенсерч мастер не стартует, сертификат надо обновить.
Не, ну а вдруг рестарт подов даст нам пересоздание сертов и секретов - делаем рестарт подов по лейблу.
Семь бед - один ресет.

kubectl get pod PODNAME -o yaml | grep -A8 -i labels
kubectl delete pod -l=opensearch.role=cluster_manager

После рестарта, снова рестарты пода есть. Ок, не помогло, ладно.

У меня очень слабый опыт с опенсёрч, а с опенсёрч в кубернетисах ещё меньше, да и ставил его не я.
Сперва разбираемся, как нам обновить серт:
- руками и чтобы быстро всё заработало
- что-то поправим в конфигах и оператор(если он есть) должен пересоздать серт
Смотрю все аннотации, название, даты и прочие атрибуты у сертификатов и secrets - нигде, ска, нет упоминания кто генерировал сертификат.
Пробовал даже нейронку спросить, он мне генерировал команды типа

kubectl get secret opensearch-cluster-http-cert -o jsonpath='{.data.tls\.crt}' -n service | base64 -d | openssl x509 -noout -issuer
issuer=CN = opensearch-cluster

на один из сертификатов, но они не особо помогли понять ишшуера/эмитента.

Ладно, смотрим в IaC и самом кластере какие у нас сущности есть в кубере:
- есть опенсерч кластер (чарт хелма)
- есть опенсёрч оператор
Смотрим а вообще должен/умеет ли оператор в этой версии генерировать/перегенерировать при протухщести сертификат?
Читаем дефолт вэльюс + наши вэльюс файлы(из git репозитория)

helm show values opensearch-operator --version 2.7.0 --repo https://opensearch-project.github.io/opensearch-k8s-operator

Ни слова про cert, ни слова про tls. Поиском нет ничего.
Ок, а что у нас в самом чарте опенсёрч кластера?
Уже в самом гите опенсёрч кластера в гите вижу вэльюс файл с

security:
  tls:
    transport:
      generate: true
      perNode: true
    http:
      generate: true

Идём в гитхаб, читаем документацию по нашей версии - да, сертификат должен
- генерироваться
- перегенерироваться при протухшести
Но этого нет 👎
Смотрим issues на github - находим несколько про то, что сущности certificate/secrets НЕ удаляются при протухшести.
Воркэраунд солюшн - удаление и секретов и сертификатов.

#troubleshooting #одинденьизжизни

Часть 2 из 2.

Собираемся удалять сертификаты..

Так, стоп-стоп, а почему у нас был алёрт по рестартам пода, но не было по протухшести сертификата?
Значит мы почему-то это не мониторим.
Пока время есть давайте настроим хоть какой мониторинг/алертинг, а то через года снова траблы будут постфактум.
Гуглим, читаем про метрики, но по факту для быстроты я просто добавил 1 endpoint в blackbox exporter

---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMProbe
...
spec:
...
  targets:
    staticConfig:
      targets:
......
        - https://opensearch-cluster.NAMESPACE.svc:9200

Смотрим появился ли этот хост и проверяем в Grafana explore

probe_ssl_earliest_cert_expiry{} < time() + 30 * 24 * 60 * 60

Супер. Метрика пошла, мы видим за что зацепиться, пилим алёрт (а у нас его и не было, блллл 🐒)

- alert: SSLBlackBoxExporter
  expr: probe_ssl_earliest_cert_expiry{} < time() + 30 * 24 * 60 * 60
  ...
  annotations:
    summary: "SSL `{{ labels.instance }}` is expiring in {{ .Value | humanizeDuration }}"

Алерт прилетает, всё ок, возвращаемся к сертификатам.
Не глядя удаляем все сертификаты, на которые была ошибка.

kubectl delete certificate  CERTNAME1 CERTNAME2 

Видим новые пересоздались(оператором, которые прочитал про пересоздания наш конфиг кластера).
Делаем рестарт подов мастеров

kubectl delete pod -l=opensearch.role=cluster_manager

и.. и ничего - та же ошибка.
Ладно, удаляем все серты, которые TLS и которые для опенсёрча.
Удалили, рестарт подов мастера и.. и та же ошибка TLS.

Ладно, мы же уже опытные инженеры, смотрим а что у нас с secrets?

kubectl get secrets

и видим, что секрет не был пересоздан.
Ну, скорее всего баг - удаляем и secrets и certificates( естественно только те, что связаны с TLS, другие секреты мы не удаляем), серты пересоздаются, секреты пересоздаются, делаем рестарт подов мастера и..
и снова та же ошибка.
Смотрим внутри мастер пода

kubectl exec -it -- bash 

- да, серт новый монтируется.

Чего мы имеем:
- у нас НЕТ сертификатов со старым сертом
- у нас НЕТ секретов со старым сертификатом
- в под мастеров монтируется новый серт
- у нас уже есть алерт ❤️
- НО у нас есть ошибка TLS при старте мастеров

Ну ведь магии не бывает, может быть эээммммээ может соседние поды - warm + cold +dashboards имеют проблемы с сертом?
Смотрим на рестарты - рестартов у них нет.
Смотрим в логи, блл, стактрейс, java и снова переворачиваем монитор вертикально 🐒 - та же ошибка с сертом, но рестартов уже нет.
Странная фигня, но ладно, публикуем в slack канале ЩА ЛОГИ БУДУТ НЕДОСТУПНЫ ПАДАЖИТЕ
и рестартим ВСЕ поды всего опенсёрча по общему лейблу

kubectl delete pod -l opster.io/opensearch-cluster=opensearch-cluster

Происходит рестарт всех 17 POD-ов и.. и проблема ушла.

Итог:
- у нас появился алерт по протухшести на будущее (есть другие, на nginx контроллеры, но тут, внутренний ресурс по 9200 не было 🤡)
- опенсёрч сволочь такая на java, у него под капотом какая-то магия, с протухшим сертом мастера делают рестарт, а остальные нет и серт нужен всем (я хз для чего, да мне и не интересно) и рестарт всем для перемонтирования
- мы разобрались чуток и можно списать время в трекер джиры
- научились мастерски крутить монитором как рулём авто

#helm #devops

Валидации, проверки, линтеры.
Как много мы о них говорим, но и как это иногда важно.

У меня есть 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 проверяет ещё и схему!

#helm #devops

Поехали проверять.

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 (если на них забивают🐒)

Поздравляю - мы снова добавили какую-то очередную хероту автоматизацию и валидацию 🤣

#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, роли - всё совпадает, проблем нет. Но почему-то на проде поды не берут нужную роль.

Нырнул в документацию и пошёл шаг за шагом. Это был скучный этап, просто читал, как всё это работает в кишках. Через пару часов упёрся в мутейшн хуки.

Проверил 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
.
..
...
Прочитал, промолчал, набычился, посмотрел на пол, закатил глаза, надел kubectl apply -f клоунский нос 🤡 и отправил пост в телеграм.

#azure #docker #opersource

OpenSource. Latest. Apache.
Да, пусть заметка называется Apache.

Прихожу на работу, а там десяток алёртов жалоб пользователей и всё UI нерабочий.
Просто не работает, и никаких алёртов.
Ладно.

На этом проекте уже не первый день, знаю, что в кишках там внутри проекты с Apache SuperSet.
https://superset.apache.org/
Иду в UI - да, какая-то ошибка (неизвестная мне). Ошибка говорит проблемы с подключением к каталогу Trino
https://trino.io
По ссылкам можно зайти, только если это интересно, в целом хватает триггера - Apache.

Ошибка говорит о том, что невозможно подключится к trino по http(а его и нет), везде написано https(только он и есть).
Явно баг.

Иду в кубернетис, там у нас и трино и суперсет.
Методом тыка и быстрого анализа узнаю, что проблема не везде - не на всех инстансах SuperSet.
Там, где утром был автоматический апдейт AKS кластер(спасибо за неотключаемый секьюрити патч, мистар Ажур), есть проблема. Где апдейта не было - всё ок работает.
Смотрю как устанавливается суперсет - везде хелм чарт и точное указание версии чарта.
Ну пусть будет версия 3.0.0.
Но проблема есть и не стоит закрывать глаза на интуицию, что это пока Apache.
Смотрю откуда тащится чарт и приходим к GitHub, на то и опенсорс.
https://github.com/apache/superset/blob/3.0.0/helm/superset/values.yaml#L178
Сук, as is это приведёт к latest тегу.

Бегу сравнивать SHA имаджей на SuperSet где работает и где не работает.
Всё так, имаджи разные. 🤡 Хотя чарт одинаковый, как и values.yaml
Быстро пушу имадж работающий в внутренний реджистри, чтобы не проетерять в суете.

Для того, чтобы не аффектило юзеров просто меняем image путь вместо дефолтного - на внутренний registry с некрасивым tag в виде sha.
Работа сервиса восстановилась, ошибок нет, пользователи больше не кидают кизяки в нас/меня.

Есть время потраблшутить: а ну и чего у нас в докерфайле
https://github.com/apache/superset/blob/3.0.0/Dockerfile
Сук, красота с pip install но вроде не в этом дело.
Не понимаю, отупел с облаками🐒, натравливаю нейронку на репу, она говорит мне про
https://github.com/apache/superset/blob/3.0.0/setup.py
Ага, значит у нас где-то есть прикрученная к забору версия, а где-то нет. Красиво.
Предполагаю в этом причина
https://github.com/apache/superset/blob/3.0.0/setup.py#L177

Начинаю гуглить по всем связанным репозиториям(чтобы сократить вероятность, что копну не туда), хотя я мог бы это сделать с самого начала и не ковыряться в докерах шмокерах.🤡
https://github.com/trinodb/trino-python-client/issues/557

То есть проблема не в самом суперсете, а сторонней библиотеке, которая ставится через trino>=0.324.0 и тянет за собой ещё и клиента само собой. И при каждом обновлении докеримаджа для трино каждый раз пере собирается новый, сук, имадж, который по latest идет к ЛЮБОЙ версии чарта.

Варианта у нас два(нет, больше, но пусть будет проще так):
- ждать исправление бага и нового чарта хелма от суперсет
- перетащить всё к себе и впоследствии менеджить самому

Ещё раз с коллегами оценили опенсорс, риски и решили перетащить докерфайл к себе.
Создаю новый репозиторий, пихаю туда докерфайл, пайплайн для CICD со сборкой имаджа и публикация по тегам во внутреннем реджистри, requriments.txt

Докерфайл простой (тут уже версия выше, но это другая история)

FROM apachesuperset.docker.scarf.sh/apache/superset:4.1.2
USER root
COPY requirements.txt /app/requirements.txt
RUN pip install -r /app/requirements.txt
USER superset 

Открываю тот самый рабочий supserset имадж, и командами docker run ... смотрю версии библиотек (вроде команда pip list).

Копирую всё оттуда, хардкорю версии в requirements.txt ровно то, что было в рабочем образе.
Локальная сборка, тест, коммит, пуш, тегируем 0.0.1.

Сперва dev, потом stage/uat/prod - меняю путь до локального реджистри и тега.
Проблема решена и ура, теперь у нас + новый форк имаджа.

#azure #docker #opersource

В последствии оказалось, что это было на 100% верное решение, потому что у библиотек выходило ещё пару багов и были проблемы другие, а так менеджить свой докерфайл это удобнее, потому что можно добавлять свои библиотеки.
Например штатно ни в одной из версий SuperSet не хватает psycopg2 🐒
Да, это можно добавить в bootstrap, но потом мы захотели включить алертинг, а это подтянуло ещё и selenium webdriver и многое многое другое.
https://superset.apache.org/docs/configuration/alerts-reports/
Удобнее в форке держать и это ок.


Итог:
а как обычно, мог бы поиском в гугле выйти сразу на репу с кривой либой, но нет, мамкин инженер хочет во всём разобраться пошагово и это просто трата времени.
Ну главное жалоб больше нет, как и рисков latest.

Как узнать есть ли у тебя новая таска?

- прочитать в новостях https://github.com/bitnami/charts/issues/35164

- похихикать над картиночками https://xn--r1a.website/devops_untraveled/1879

- нахмурить брови и проверить у себя на проде

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep bitnami | wc -l

36

ну или точнее таргеты

kubectl get deployment,statefulset,daemonset,job,cronjob --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.kind}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep bitnami

- осознать, что часть напрямую чарты, а часть просто депенденси (Redis🐒) и теперь предстоит масса работы

- сказать "штош" и пойти дальше это перепиливать, ну а чё делать ещё