#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🐒) и теперь предстоит масса работы

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

#пятница #aws #всратость

Буквально на пару дней был недоступен для работы.
В это время разработчикам срочно надо было для тестов фичи создать 3 бакета в 3 регионах:
us-east-1(default), us-east-2, ca-central-1.
Вообще для этого есть модуль, просто регион указать, однако они сделали по своему и клик-опсом.
Накатили, проверили, сдали бизнес-заказчику, написали всем "фича работает и проверена на бакетах в 3 регионах!".
Запилили мне таску "добавить бакеты импортом в терраформ.

Возвращаюсь на работу - вижу это 😀

#azure #всратость #troubleshooting

Утро, вторник, кофе, трёп.

Прилетает ишшуя от кастомера - не работает %фигнянейм%.
Лог приложений говорит о каких-то несовместимых полях и параметров с API MS Teams/Azure.

Традиционно проверка:
- не менялись ли переменные в коде аппликейшна
- зафиксирована ли версия base имаджа в Dockerfile
- зафиксированы ли версии библиотек
Всё ок.

Ладно. Гугл, реддит, QA Azure, нейронки.
Внезапно(!) обнаружили, что с 31 июля 2025 года multitenancy bot депрекейтед. 🤡
Ни уведомлений, ни анонса, ни писем, ни RSS, ни уведомлений в Azure console.
Ни-че-го ни-как и ни-где.

Есть несколько упоминаний: в официальной документации в сноске и community нытинг-форуме:
- https://learn.microsoft.com/en-us/azure/bot-service/bot-service-quickstart-registration?view=azure-bot-service-4.0&tabs=multitenant#bot-identity-information
- https://techcommunity.microsoft.com/discussions/teamsdeveloper/what-is-the-recommended-bot-type-for-multi-tenant-bots/4420239

Как так-то?? В чём сложность уведомить клиентов, что функционал будет скоро депрекейтед??
Подписке 4 года, боты уже 3 года.
Всратое облако, конечно.
Даже у AWS все предупреждения через почту, всплывающие окошки, куча нотификаций, слак и бьющиеся в окно голуби с инфой, что пора обновить EKS.

А, ну да - почему так произошло, почему только 5 числа?
Да просто это редкий функционал(интеграции), в пятницу 1 числа никто не использовал это, два дня выходные, в понедельник никто не раскачался, а во вторник отстрелило коленные чашечки функционалу фичи, который создавал ажур ботов.

Ну и всё, фича не работает.
Аригато, ажур штопанный.

#всратость

Приходят ко мне недавно

"мы тут придумали на коленке в метро и за два дня внедрили AI!AI!AI!AI!AI!-voice сервис, всё уже продали клиентам, уже даже заработали с него, а ты нет(лох), и поняли, что твой кубервсратос всё ломает при деплое/редеплое и связь рвётся, это всё твой кубер виноват, чини скорее, ЕТА на завтра, а то мы клиентов теряем".

Грубо говоря ситуация такая:
2 Пода в кубере.
Они/через них организуют 1 голосовой звонок.
2 пода - просто реплика. Можно сделать и 1, не принципиально.
Звонок идёт - всё ок.

Разработчики запилили релиз.
Во время релиза в кубер у нас rolling update strategy.
Когда новый под поднялся, старый завершился.
И звонок прервался.
Звонок не должен прерываться.
Это и есть проблема.

У меня очень плохо с многими областями в айти.
Чуток почитал про фреймворки, воип, сип и многое другое с голосом
Ну как почитал - спросил нейронку "все про войс за 7 абзацев". 😁
Да не, вру, я многое про войс и так знал.

Ладно, спрашиваю у чатике кубера, набрасывая этой дичью.
Вдруг есть готовое решение, паттерн или фреймворк.
Ответы разные, от смешных до очень смешных.
В общем и целом мне посоветовали глянуть в стек, а что в кишках.

Кишки привели меня к
- https://docs.livekit.io/
- https://github.com/livekit/python-sdks

Дальнейший совместный поиск привел к такому ОФИЦИАЛЬНОМУ решению
https://docs.livekit.io/home/self-hosting/kubernetes/#graceful-restarts

During an upgrade deployment, older pods will need to be terminated. This could be extremely disruptive if there are active sessions running on those pods. LiveKit handles this by allowing that instance to drain prior to shutting down.

И самое сладкое ❤️

We also set terminationGracePeriodSeconds to 5 hours in the helm chart, ensuring Kubernetes gives sufficient time for the pod to gracefully shut down.

Ставим таску на on-hold, отписываем это как временное решение и трекаем время за траблшутинг.

Какие времена, такой софт и такие решения... 😀

#devops #sql #index

Индексы.

Сегодня слишком жарко и погулять не удалось.
А значит надо накидаться алкоголем и играть в стимдеку сделать что-то полезное для разминки ума.
Открыл в браузере папку с закладками "Почитать на потом" (думаю, она есть у каждого) и выбрал случайную ссылку:
https://use-the-index-luke.com

Думал, почитаю минут 10-15, но зачитался надолго с большим интересом.
По ощущениям, закрыл целый пласт знаний: от понимания, что такое индексы и как они устроены, до более сложных тем, вроде оптимизации запросов.
На сайте масса информации, я читал выборочно то, что было полезно для работы.
Особенно понравились разделы про структуру индексов и их использование в "WHERE".

Рекомендация всем, кто:
- не знает, что такое индексы
- слышал, что "если БД тормозит - смотри индексы", но не понимает, как это работает (как я 😁)
- хочет укрепить знания или закрыть пробелы

Ресурс подходит всем инженерам, независимо от роли - администратора баз данных, DevOps или разработчика.
Текст доступен даже новичкам, можно читать на английском или через автопереводчик браузера.
Разделов много, можно изучать всё подряд или выборочно, как я.

Обязательно к прочтению, если хочется разобраться в индексах.
Рекомендация 💯.

* предполагаю, что впереди меня ждет не одна всратая история, связанная с обновлёнными знаниями по индексам и анализу "что у меня на работе у коллег" 😀

Tell me this is a joke. Please. 😢

awk -F'@' '/^is-/ {print $1}' yarn.lock | sort -u

is-alphabetical
is-alphanumerical
is-arguments
is-array-buffer
is-arrayish
is-async-function
is-bigint
is-binary-path
is-boolean-object
is-buffer
is-bun-module
is-callable
is-ci
is-core-module
is-data-view
is-date-object
is-decimal
is-docker
is-extglob
is-finalizationregistry
is-fullwidth-code-point
is-function
is-generator-fn
is-generator-function
is-glob
is-hexadecimal
is-interactive
is-lambda
is-map
is-node-process
is-number
is-number-object
is-obj
is-path-inside
is-plain-obj
is-potential-custom-element-name
is-regex
is-retina
is-set
is-shared-array-buffer
is-stream
is-string
is-symbol
is-typed-array
is-unicode-supported
is-weakmap
is-weakref
is-weakset
is-wsl

#AI #opensearch #всратость


Прилетает алерт - "нет места на опенсёрче".

По ссылке в алерте захожу в Grafana - да, места почти нет, трешхолд в 20 гигабайт остатка.
Как так-то, там илонмасколлион стораджа, как он может закончится + ретеншн полиси 14 дней?
Захожу в UI OpenSearch в индекс менеджмент.
Последние дни индексы по 100-300 гигабайт в день.😬
Мысленно кричу "ВЫ ТУДА СРЁТЕ ЧТОЛИ????" ах, какая досадность".

Ок, логов много, дискавери мне ничем не поможет в идентификации аппликейшн сорса.
Иду в Visualizations, выстраиваю фильтры, ставлю top сообщений по имени апп.
Вижу какой-то новый сервис. Назовём его chatbot.
Естественно он в топе, отрыв в 220 раз от второго места. Неплохо.
Отлично, негодяя мы нашли.
Что же ты пишешь, чудо ты наше.
Discovery по фильтру appname=chatbot у меня подвис от количества сообщений, окно браузера само аннигилируется от потока, плюю на зависшее, иду в сам Kubernetes POD, смотреть по k logs -f podname.
А там ВСЁ. Ребята, там, бл, вообще ВСЁ. Вселенная текстов и диалогов!
Ленинская библиотека не содержит в себе столько информации, как в логах этих подов.

Сразу же прилетает алёрт "места осталось 0.0001%", а в Spotify играет припев песни Final Countdown.
Гиеной ржу с трека и ситуации, но не расслабляюсь, а бегу в developer console и удаляю индекс самый старый.
А затем сразу же ещё один. Та они всего по 85 гигабайт были. Каждый.
С такой скоростью, пока буду траблшутить, снова места не станет.

Смотрю в git репозитории этого проекта, выбираю топ 2 коммитящих, а значит шарящих, инженеров.
Иду в oncall чат, вызываю обоих, пришёл только один, спрашиваю вежливо что за сервис, что делает, кхто начальник штаба?
Получаю детальное пояснение.

Вернемся двумя неделями ранее.

Разработчики запилили некий агент. Чат бот. Чат-ассистент. Не важно.
Кастомерам этого продукта понравилось, они начали своим саб-кастомерам впаривать это.
Честно говоря, я не знал и не знаю всю бизнес-структуру и как вообще проект зарабатывает с этого, но это и не важно.
В общем процесс идёт, все всем довольны.
Фича работает и развивается.
Денежки идут в карман владельцам.

Однако всё(!) общение в чат ботах пишется в stdout
То есть не логи самого приложения, а логи общения внутри чатбота попадает в stdout.🤡
И в нашу систему логирования.
Вся переписка, приватные данные, вообще всё.
Даже специально искал киворды типа token/password/phone - там есть всё!

Итоги:
- все, даже я, получили по шапке, логи общения выключили(пока не сделают фичу на фильтр того, что надо).
- разработчикам всё равно на все PCI-DSS, SOC2 и прочий аудит. Срать в логи приватными данными? Изи!
- я добавил Europe - Final Countdown в любимые треки, буду включать при повторах ситуации 😁

* История давнишняя, просто вспомнил сейчас.

Впервые в своей жизни отправил первый bug bounty report через https://hackerone.com

Пока присвоили severity high 8.4/10, хоть я и не согласен(а кто меня спрашивает).
На многое искренне не рассчитываю, это лишь мой первый опыт, но если дадут хоть 500 баксов, то все равно буду рад.
Жена рассчитывает на все $30000, когда рассказал про суть уязвимости 😁
Никаких подробностей уязвимости пока не будет, думаю все понимают почему.

Потом полазил там на сайте, почитал разное, удивился как много можно поднять денег на critical и, иногда, high уязвимостях.
Причем часть из них уровня моих унылых знаний 2020-2022 года и из инструментов chrome developer tool.
Это я, а не тот репортер, мог получить $20.000 и $35.000.👿👿👿

Даже пришла в голову мысль, что в целом можно же и не работать, если бекграунд и знания позволяют 1-3 раза в год находить critical уязвимости у крупных вендоров, получать выплаты и просто чиллить: сидеть дома, читать книги и играть во все игоры.
Возможно это лучше, чем вот эти вот все овертаймы проклятые и бесконечные синки в попытке поймать коллег по всему свету, от Таиланда до США.
Если заплатит, то полусерьёзно посмотрю в эту сторону.
Опыта мне может хватить, база у меня хорошая.
Северити понимаю как никто другой, сколько всратого в своей жизни видел. 😀

#terraform #aws

Самая нелюбимая часть работы - terraform hell dependency и AnyCloudProvider(в данном примере AWS) deprecated resources/versions.
Вишенка на торте - вкупе с публичными модулями.

То есть "что-то скоро перестанет работать - обнови версию".
Просто обнови и всё! 😀

Простой пример: прилетает письмо от AWS "скоро python9 станет депрекейтед в AWS"
Никаких возражений, я полностью согласен с такой позицией. 100% верно.
Пилим таску "обновить версию рантайма везде", иначе через 180 дней превратимся в тыкву.

Проверяем есть ли у нас лямбды 3.8/3.9.

aws lambda list-functions --region us-east-1 --output text --query "Functions[?Runtime=='python3.8'].FunctionArn"
aws lambda list-functions --region us-east-1 --output text --query "Functions[?Runtime=='python3.9'].FunctionArn"

Увы, есть. Находим один аж с 3.8. С него и начнём.

Казалось бы - в чём сложность? Версию апдейтни.
Попытка обновить версию самого модуля - получаю ошибку, что террраформ версии 1.5.3 не подходит, тут нужно минимум 1.5.7. Просто так указать ему версию рантайма не прокатывает - он не в курсе про такой параметр в этой старой версии.
Хорошо, везде обновляем терраформ на 1.5.7, но теперь ругается на провайдеры, terraform/aws. Их тоже надо обновить.
Обновляем и их повсеместно. Прогоняем план - последовательно находим 4 бага - в github issues, обновляем раз за разом разные версии, вроде прошли к какой-то, в котором багов нет. Появляются даже какие-то костыли с lifecycle.
В двадцатый раз уже terraform plan - появились обязательные поля у части ресурсов, а они не указаны.
И так по кругу. Хистори показало печаль 😭

history | tail -n 200 | grep plan | wc -l
59

И вот что тут делать?
- либо дальше повышать версию за версией, добавлять/убавлять параметры, чтобы стейт с кодом был идентичным, пока это говно не заработает
- сделать роллбек всех сделанных изменений кода с версиями, повесить техдолг

Потрачено уже немалое количество времени и принимаю решение - делаю роллбек.
Нужен рабочий и код и стейт. А роллбек ничего и не дал. 🚶‍♀
В лямбде версия рантайма уже 3.12 и откатить обратно к 3.8 не даёт - нет даже такого поля(а скоро и не станет 3.9).

Да что же такое. Значит ни первое и ни второе решение, предложенное выше.
В итоге просто иду на страницу модуля старой версии, копирую все ресурсы as is, пишу свой модуль и свои версии зависимостей. Убираю несколько лишних ресурсов и прав к ним.
Запускаю лямбду - ошибка питон кода, ведь он был написан для 3.8, а у меня 3.12.
Переписываю питон скрипт, проверка - всё работает.
Обновляю сразу все зависимости до последнего актуального, чтобы оно дольше проработало.
Выпиливаю публичный модуль, документирую свой модуль, план, фиксирую версии, терраформ апплай - всё работает.

Вот так, попытка "просто сделать апдейт версии питон рантайм лямбды" вышло в 5 часов абсолютно глупой работы. Итог плохой:
- мне он не нравится
- технический долг немного вырос
Из хорошего
- выпили ещё один сомнительный модуль, который своими зависимостями ломает вообще всё к херам.
- не поломали код и стейт
- обновили все лямбды до 3.12 (не только от старого паблик модуля, а везде)

Мне кажется, тут нет правых, виноватых. Хороших и плохих решений.
Эта ситуация возникала не раз, уж слишком у нас много зависимостей в нашем коде, инфраструктуре и работе. Особенно сторонних модулях.
Можно сколь угодно обвинять "а чо ты раньше не обновился?", "а чо ты на 1.5.3 сидишь как сыч?" и многое другое.
Не хватает ресурсов, чтобы всё держать в обновлённом состоянии. Увы.

#gitlab #github #secrets #security

Спустили с небес на землю.

Недавно я решил, что я мамкин хакер(нет), даже отправил несколько репортов, от medium до high severity.
Вот буквально сегодня в ночи получил ответ. Вкратце: "спасибо, мы знаем, тикет закрыт, пробуйте ещё".

Основная суть всех моих репортов - "пользователь с привилегированным(не админ)/с ограниченным доступом(не админ)/со специальными не частыми у всех условиями, может получить доступ к секретам".

Расставлю сразу свою позицию - я никого ни в чём не обвиняю, мне позиция ясна, ответы понравились, я со всем согласен. Никаких интриг, просто общение между инженером и представителями компаний.
История в 3 частях.

Часть первая, GitLab.

Однажды мне надо было достать значения секрета, помеченного Masked and Hidden*.
У меня были права reporter в этом репозитории.
Базовые вещи echo $secret не давали результата, там было [MASKED] в аутпуте.
Я просто сделал

  script:
    - echo "$password" | base64 > /tmp/password.txt
    - cat /tmp/password.txt

скопировал значение и локально выполнил команду

echo Wml4TjRUbVdpRDAxbjdoCg== | base64 -d
ZixN4TmWiD01n7h  (естесственно это пароль для статьи, вы чо, думали я реальный напишу?)

Сам себя поздравляю - я могу прочитать значение секрета, помеченного Masked and Hidden в 2 команды.
Отмечаю, что это работает для приватных моих репозиториев, а так же для всех проектов/репозиториях, куда меня добавили - то есть во всех для организации. Проверено на SelfHosted/Cloud.
То есть прямо сейчас ВСЕ ваши коллеги не девопсы/админы с ограниченными правами могут прочитать ВСЕ секреты в тех проектах/репозиториях, где у них есть ограниченные доступы. Даже к OpenAI и тратить токены компании или PAT к другими репозиториям с привилегированными правами(например CICD процессы GitOps между репозиториями)

На данный репорт я получаю ответ от https://hackerone.com/
According to current program policy, this reported finding is considered out-of-scope;
CI/CD Variable Disclosure - as it stands, we currently see our guidance to use external secret storage as sufficient for addressing reports that rely on disclosing Masked CI/CD variables to prove impact.
It is a known security rick, based on the official document https://docs.gitlab.com/ci/variables/#cicd-variable-security
As a result, I'm closing this report as Informative. Your effort is nonetheless appreciated, and we wish that you'll continue to research and submit any future security issues you find.

Идем по линку и там
Masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values. To ensure security of sensitive information, consider using external secrets and file type variables to prevent commands such as env/printenv from printing secret variables.
Gitlab.com сотрудничает с https://hackerone.com/ и значит их ответ = ответ GitLab.com.

Записываем себе - гитлаб не гарантирует ничего по сохранности секретов.

* В целом данная уязвимость не новая - опытные инженеры её и так знали и пользуются втихую.
Возможно даже на других CICD 😉