Make. Build. Break. Reflect.

#DNS #cloudflare

Подстава, откуда не ждал.
Наверное все знали, и лишь я не знал.

Надо было для одной задачи проверить кое-что.
Я в своём личном аккаунте CloudFlare купил домен, арендовал VPS на linode, создал рутовую A запись, поднял Nginx на 80 порту - всё ок.
Задача усложнилась, мне надо было 443 порт, а это сертификаты.

Очевидно нужно сгенерить, на ум приходит cert-bot, acme.sh.
Сперва я промучался с одним, потом с вторым, эти падлы не хотели генерировать мне серты.
Просидев с логами я понял, что конфликт в TXT записи _acme-challenge.<domain>.
Всмыыысле, подумал я, какие TXT, у меня ничего нет в DNS записях, только A.
Иду в UI, в DNS там только A record.
Но логи говорят об обратном.

Ладно, идём в dig.

dig _acme-challenge.domain.com +answer TXT 8.8.8.8

А там, бл, я правда есть TXT записи.

;; ANSWER SECTION:
_acme-challenge.domain.com. 297 IN TXT "blabla"

Гугл, изучение админки CloudFlare приводят меня в и к документации.

❗️Дефолтное поведение Cloudflare при покупке домена включает Universal SSL/Edge Certificate.
Cloudflare автоматически выписывает вайлдкард сертификат на 3 месяца.
Для подтверждения владения Cloudflare сам автоматически создает собственные TXT-записи с префиксом _acme-challenge.*. Эти TXT записи не отображаются в стандартном интерфейсе DNS-записей Cloudflare.
Их наличие можно подтвердить только через внешний DNS-запрос, например dig.
Айдишник от Cloudflare не совпадает с айдишником другой утилиты, вываливается ошибка, конфликт, нет серта.

Решение очевидное: отключить Universal SSL/Edge Certificate Cloudflare:
Перейти в раздел SSL/TLS → Edge Certificates .
Найти блок Disable Universal SSL(в самом низу) и нажать кнопку Disable Universal SSL
Подождать около 15 минут. Он ревоукнет сертификат и уберёт все не редактируемые неявные TXT записи.

Теперь можно работать с любыми генераторами сертов, кто челленджит владение DNS зоной через создание _acme-challenge.domain.

Тех, кто челленджит DNS через HTTP-01 Challenge, это поведение не аффектит.

* а бектики я не поставил, потому как телеграм глючит и любой код в этой заметке превращает в мусор из спецсимволов и тайский алфавит. Как, например, превращает TXT в TXT. Fixed.

#delimiter #separator

Заметка для самых-самых маленьких.

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

Итак, Delimiter. Separators. Разделители.
Наверняка вы замечали, что в консоли/редакторе можно выделить по разному слова:
- выделив мышкой от начала слова до конца
- двойной клик (или хоткеи клавишами в редакторе)

Но при двойном клике в разных случаях и разных слов поведение разное.
Даже тут, в Telegram, с ПК, при двойном клике будет разное выделение.
Попробуйте!

asdf-qwer
asd—1234     (а вот тут уже выделяется всё)
asdf/fdsa
1234.4321
asdf_1234    (да, и тут будет выделено всё)
as 1234a
as␣2345      (и снова выделяется всё)

Всё зависит какой есть delimiter в том месте, где вы это выделяете.

Он имеет право быть разным везде:
- в editor VSCode
- в console VSCode
- в terminal Windows 11
- в WSL terminal
- в SQL console
Да где угодно на самом деле. И настройки у всех могут быть разными, не зависящими от других.

В случае, если ваc не устраивает то, что выделяется в вашем рабочем пространстве, можно просто поискать в гугле или документации про delimiter или separator.

Например в Terminal Windows 11 дефолтный делиметр

 /\-()"'.,:;<>~!@#$%^&*|+=[]{}~?│

и он находится в пункте
Windows Terminal → Settings → Interaction → Word delimiters
Можно поменять, удалив символ дефиса (-), на

 /\()"'.,:;<>~!@#$%^&*|+=[]{}~?│

И после этого в вашем терминале, например в WSL Ubuntu, будут выделяться слова типа

eks-cluster-one  # тут, в телеграм, конечно же, не сработает, это ж пример для WSL

В VSCode, если мне не изменяет память, два пункта.
- один для editor

`~!@#$%^&*()-=+[{]}\|;:'",.<>/?

- второй для terminal

 ()[]{}',"`─‘’“”|

Не стоит стесняться: кастомизируйте рабочее место так, как вам удобнее.
Значения по-умолчанию не всегда удобны.

Для чего важно знать, что такое delimiter?
Потому что это напрямую влияет на скорость и удобство редактирования текста и кода.
Если изменить границы слова через настройку разделителей, то двойной клик мышью или сочетания клавиш вроде Ctrl + Shift + ←/→ начинают работать именно так, как удобно вам.

#aws #opensearch #elasticsearch

Поехали к проду 🍷
Объявили время на апдейт, утвердили даты на выходные, ну а когда же.
Время апдейта? А время апдейта я написал, что "да за 6 часа управимся!"🐒🐒🐒
О, как же я ошибался в сроках.😭

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

Пристегните ремни, а теперь объявляем реальное время апгрейда😁:
- первый этап обновления до последней версии эластиксёрча - 12 часов.
- обновление до опенсёрча - 19 часов.
- обновление до последней на тот момент времени версии опенсёрча - 15 часов.
- включение SAML и авторизации - 18 часов.
- переиндексация (а потому что смотри первый пункт) - 49 часов.
На стейдже и деве не было конфликтов, а на проде не хватало полей и после апдейта просто рефреш не помогал, помогла только реиндексация всего. Поиндексно.

Подводим итоги:
вместо "да тут приключения на 20 минут", миграция заняла больше недели.
Я же не могу постоянно быть у ПК, а значит процесс запущенный днём, мог завершиться в 2 ночи, но я у ПК только в 10.00 утра, на этом тоже потеря времени.
Всю неделю логи были то доступны, то нет, во время обновления SAML вообще не было ничего доступно - доступ без пароля УЖЕ не работал, но доступ по SSO ЕЩЁ не работал.

Написание плана и кода вообще - не сложно.
Адекватно оценить сроки апгрейда прода - сложно.
П - планирование. 🚬

- - - - - - -

"К чему эта заметка, Алекс?" - спросите вы.
А всё просто: календарь напомнил, что через месяц заканчивается стандартная поддержка - самое время обновляться.
Ссылка на детали тут: https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-announces-standard-and-extended-support-dates-for-elasticsearch-and-opensearch-versions/
Там расписано всё и по OpenSearch, и по Elasticsearch.

У меня тех старых кластеров уже нет, но если у вас ещё остались, то у вас примерно месяц, чтобы успеть с апдейтом и миграцией.

РЕБЯТА, У ВАС ОСТАЛСЯ ВСЕГО МЕСЯЦ НА ТО, ЧТОБЫ ЗАПРЫГНУТЬ В ЭТО УВЛЕКАТЕЛЬНОЕ ПУТЕШЕСТВИЕ МИГРАЦИИ ВСЕГО НА 6 ЧАСОВ! 😀

#aws #opensearch #elasticsearch

Однажды надо было обновить ElasticSearch в амазоне.
По историческим причинам была старая версия эластиксёрч.
Пришло какое-то уведомление "через какое-то время будет расширенная версия саппорта за деньги, обновляйся или плати", а это всегда страшно.
Никто не хочет платить за просранные сроки.

Было три классических окружений(dev, stage, prod), все одинаковые по конфигу терраформ модуля, но отличающиеся по размеру стораджа, типу инстансов, шардам и количеству инстансов, на деве вроде был всего один.

Ну задача-то не сложная:
- обновил поля в индекс паттерне если есть конфликты (опционально, будет не у всех).
Если есть конфликты, то обновление на какую-то из версий опенсёрч не пройдёт
- обновить руками в UI на последнюю версию (раньше не даёт сразу обновить на опенсёрч) эластиксерч
- обновить руками в UI с эластик на опенсёрч
- обновить руками в UI одну или две версии опенсёрча до последней
UI‑апгрейт AWS OpenSearch происходит пошагово, без возможности пропуска промежуточных версий.
- поменять ресурс терраформа с

resource "aws_elasticsearch_domain" "elasticsearch"

на

resource "aws_opensearch_domain" "opensearch"

- выполнить удаление старого ресурса

terraform state rm aws_elasticsearch_domain.elasticsearch

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

terraform import aws_opensearch_domain.opensearch %domainname%

- прогнать терраформ план и поправить, где чего упущено (ну там новые названия переменных для .tfvars файла и типа того, не помню уже).
- проверить все дашборды в графане(есть ли метрики и не поменялись ли они), поправить если надо
- проверить все метрики для алертов и алерты, поправить если надо
- коммит и отправить MR

Не сложно, не правда ли?
Пока без каких проблем.

Однако в процессе миграции кто-то решил "а давайте ещё и SSO включим! Ну всё равно же апдейт!" 🤩.
SSO так SSO, правила диктуют боссы и стейкхолдеры.
К текущему плану добавляем новый ресурс нечто типа (могут быть опечатки, пишу на память и примерам)

resource "aws_opensearch_domain" "opensearch"
...
  advanced_security_options {
    enabled                        = true
    internal_user_database_enabled = true
    master_user_options {
...
  }

и

resource "aws_opensearch_domain_saml_options" "saml"
...

- ну ещё там добавились всякие политики, роли и так далее. Я думаю это и так очевидно. Перечислять не буду.
- со стороны коллектора логов (Vector/VMlogs/fluentbit/Fluentd etc - выбор у каждого свой) добавилась ещё и авторизация - если УЖЕ включили SAML/SSO на OpenSearch, то для банальной отправки логов в хранилище будет авторизация.
- добавить 3 Azure enterprise application - на каждый из энвов, ведь Reply URL (Assertion Consumer Service URL) везде разный. Если был бы один опенсёрч на все энвы - был бы один аппликейшн.
- коммит и отправить MR, получить аппрув

Внесли в код, начали апплаить - а всё работает!
Коллектор логов шуршит, собирает логи, асьюмит роль, монтирует токен, цепляется к опенсёрчу, проходит авторизацию, аутентификацию и успешно делает PUT логов.
Пользователи отлично заходят на OpenSearch UI через SSO и всё работает.
На всё ушло около 4 часов чтения доков и вроде полутора-двух часов для апплая и отладки.

Ок, идём к Stage окружение, там повторяем примерно всё, что написано выше, правим мелкие недочёты если есть.
Почти не было кода, лишь просто выполнять команды в порядке, описанном в тикете.
На всё ушло вроде меньше 2 часов.
Всё так же работает.

#aws #azure #gcp #kubernetes

Допустим вы сменили место работы.
На новом месте GCP, Azure, AWS. Миллионы куберов.
Разные тенанты, разные сабскрипшны, разные профили, разные аккаунты, разные регионы.

Ваше железо с нуля, в нём пока нет ничего (а зачем старое со старых работ тащить?)
Надо установить утилиты, Надо обновить кубконфиг.
Чтобы видеть сразу всё и сразу (из доступного по правам).

Первым делом ставим asdf.
https://github.com/asdf-vm/asdf/releases
Затем добавляем тулзы.

cat ~/.tool-versions

kubelogin 0.1.4
helm 3.17.0
dive 0.12.0
sops 3.9.4
terragrunt 0.54.15
terraform 1.5.3
kubectl 1.29.0
awscli 2.31.6
aws-sso-cli 2.0.3
kubectx 0.9.5
eksctl 0.215.0
azure-cli 2.77.0
jq 1.8.1

Апплаим (у меня это алиас asdfu)

cut -d' ' -f1 ~/.tool-versions | xargs -I{} asdf plugin add {} && asdf install

Теперь у нас есть все необходимые утилиты

Затем конфигурируем один раз профили(если есть).

aws configure sso 
# или
aws configure sso --profile profilename
az login

Теперь нам надо один раз залогиниться в ажур и амазон.
Где-то достаточно
az login и aws sso login
где-то разово надо попрыгать по профилям

aws sso login --profile profilename

Мы залогинились во все тенанты, все подписки, все аккаунты.
Как теперь в автоматике собрать все кубконфиги?
На помощь нам приходит любимый bash ❤️.

AWS (пример)

account_id=$(aws sts get-caller-identity --query Account --output text)
eksctl get cluster --all-regions -o json | jq -r '.[] | [.Name, .Region] | @tsv' | while read -r name region; do
  aws eks update-kubeconfig \
    --name "$name" \
    --region "$region" \
    --alias "${account_id}_${name}-${region}"
done

Azure (пример)

origin_context=$(kubectl config current-context)
original_subscription_info=$(az account show --query '{id:id, name:name}' --output json)
original_subscription_id=$(echo "$original_subscription_info" | jq -r '.id')

subscriptions=$(az account list --query "[].id" --output tsv)
for subscription in $subscriptions; do
    az account set --subscription "$subscription"
    clusters=$(az aks list --query "[].{name:name, resourceGroup:resourceGroup}" --output json)
    for cluster in $(echo "$clusters" | jq -c '.[]'); do
        cluster_name=$(echo "$cluster" | jq -r '.name')
        resource_group=$(echo "$cluster" | jq -r '.resourceGroup')
        az aks get-credentials \
            --resource-group "$resource_group" \
            --name "$cluster_name" \
            --overwrite-existing \
            --context "${subscription}_${cluster_name}"
        kubelogin convert-kubeconfig -l azurecli
    done
done
kubectl config use-context "$origin_context"
az account set --subscription "$original_subscription_id"

Это пример логики скриптов.
Можно изменять под любые цели, мне в целом удобнее формат алиасов кластеров

# AWS
<account_id>_<cluster_name>-<region>
# Azure
<subscription_id>_<cluster_name>-<region>

Алиасы каждый пилит сам под себя - как кому удобнее.
Можно даже добавлять суффикс, что за кластера

# AWS
eks-<account_id>_<cluster_name>-<region>
# Azure
aks-<subscription_id>_<cluster_name>-<region>

Очевидно, что если аккаунт один, подписка одна и регион один - сложный нейминг не нужен.

Теперь наше рабочее место настроено и в любой момент времени можно обновить актуальные кластера всех провайдеров, всех тенантов, подписок, аккаунтов и даже всех регионов.

Вводим kubectx, видим огромный список всего.

> kubectx

aks-98765-98765-98765_stage-fake-centralus
aks-54321-54321-54321_dev-fake-eastus2
aks-12345-12345-12345_uat-fake-germanywestcentral
eks-123456789_dev-project1-us-east-1
eks-123456789_stage-project2-us-east-2
...

Cвичимся в нужное и поехали работать.

* в условиях разных SSO и корпоративных политик некоторые способы могут отличаться. Это лишь общий паттерн.

А доступ в GCP вам так и не дали 😀

If you upgraded to macOS Tahoe and it feels super slow, you can disable transparency by going to System Preferences > Accessibility > Display and checking "Reduce transparency"

My mac had been terrible since I upgraded, but after doing this it improved a lot.

Why did I even update the fckng OS?😭

#grafana

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

Где взять дашборды Grafana в 2025, как и с чего начать с нуля.

1) Скачать любой stack helm chart
aenix, victoria metrics, prometheus
- просто установить в миникуб/кубер, зайти в графану и откуда слить интересующие дашборды
- удалить stack

Если не хочется установить, то просто слить сразу директории и файлы. Пример:

helm pull oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack --untar

Все дашборды лежат в

kube-prometheus-stack/templates/grafana/dashboards-1.14
├── alertmanager-overview.yaml
├── apiserver.yaml
├── cluster-total.yaml
├── controller-manager.yaml
├── etcd.yaml
...

Внутри YAML лежит JSON.
Минус варианта:
надо будет ещё и records за собой утащить - большая часть дашбордов используют не стандартные метрики.

2) Официальные и community репозитории:
- https://grafana.com/grafana/dashboards
- https://play.grafana.org/dashboards (всякие demo, поиском искать по ключевым словам)
- https://grafana.com/orgs/victoriametrics/dashboards
- https://github.com/monitoring-mixins/website/tree/master/assets
- https://github.com/dotdc/grafana-dashboards-kubernetes
- https://github.com/voidquark/grafana-dashboards

3) Специфик репозитории. Само собой их больше, тут как пример.
- https://github.com/tarantool/grafana-dashboard
- https://github.com/cloudnative-pg/grafana-dashboards
- https://github.com/percona/grafana-dashboards
- https://github.com/temporalio/dashboards

4) Просто по тегам гитхаба (обычно по звёздам сортировать и брать нужное)
- https://github.com/topics/grafana-dashboards

5) GitHub поиск:
- Поиск по метрике (например, nginx_ingress_controller_requests, node_load5, trino_failuredetector_HeartbeatFailureDetector_ActiveCount etc.)
- Фильтрация по "dashboard" и "json"
- Сортировка по звёздам, дате, популярности
- Вытаскивать нужные .json и импорт к себе
Пример: https://github.com/search?q=rate%28nginx_ingress_controller_requests+language%3AJSON&type=code&l=JSON

6) Для новых/непопулярных проектов можно делать так.
Сделать port-forward на сервис, скопировать все метрики(обычно по пути /metrics), вставить в любую нейронку, попросить нечто типа "вот все метрики по %продуктнейм%, сделай мне общую графана борду, типовые сценарии использования, дальше поправлю сам".

Бонус-инфа:
7) Необычный проект для синка clickops/IaC по бордам
- https://github.com/grafana/grafana-git-sync-demo

#пятница #байки #troubleshooting

Ещё один случай, более банальный, но от того не менее занятный.
К нам обратились: "оборудование барахлит, раньше работало, потом стало похуже, а сейчас почти совсем не работает, сейчас стало совсем плохо".
Мы как обычно: отправили новый модем - не помогло, попросили заменить кабельную трассу - не помогло. Ясно: опять локальная херня, надо ехать, отправляют молодого.

Приезжаю. Место знакомое. Смотрю на антенну: стоит та же, что и пять лет назад. Только вот когда её ставили - перед ней было чистое поле. А теперь в нескольких метрах перед приёмником выросло почти дерево.
Сначала были слабые ростки, ветер шатал - появлялись помехи на канале, потом выросли кустики - помех стало чуть больше при ветре, а потом почти полноценный ствол с кроной. И он, как назло, при ветре и шатании кроны в самый азимут упирается. Догадаться, что спутниковая антенна должна видеть спутник напрямую, никто не удосужился. Стоит же железка - пусть работает сама по себе. Раньше же всегда работало. Они то сами ничего не меняли, да.

Я посмотрел на это, вздохнул, показал начальнику пальцем на дерево-куст и сказал: "вот ваш сбой, подпишите, пожалуйста, Акт выполненных работ".
Взгляд его не предвещал ничего хорошего его сотрудникам после моего уезда.
Ну, дальше по классике: спилили дерево, помехи ушли, сигнал вернулся, народ снова счастлив.
С тех пор мы при удалённой проверке просили сделать фото с телефона "а чего там сейчас перед тарелкой".

Иногда проблема не в людях, железках и кабелях, а в природе, которая растёт где хочет.
Без разрешения начальства и согласования с отделом связи.
Наверное, считает себя самым главным интегратором на объекте.

#troubleshooting #billing #CostOptimization #newrelic

Внезапно вырос ценник на newrelic.
Заметили не сразу, не было настроены алерты по биллингу.
Увидели лишь в начале месяца, при выставлении счёта.

Я не сильно тогда был знаком с newrelic, этой штукой обычно пользовались коллеги-разработчики, я больше по инфре и стеку с VM/Prometheus/Grafana, но деньги есть деньги, надо разбираться.

Поковырявшись в интерфейсе и немного документации, обнаружил, что деньги начали списываться в раздел логирования.
А ведь это странно, все логи у нас пишутся в ELK стек в самом кубе, зачем ещё и в newrelic писать, а там за каждый чих деньги просят.

Первым делом смотрю в ньюрелике кто именно пишет логи - ага, одно единственное приложение.
Иду в git, захожу в раздел PR, вижу там миллиард PR, закрываю, ибо даже с поиском ничего не найти.
Клонирую репозиторий, смотрю локально.
Ага, у нас агент newrelic ставится через Dockerfile

ENV NEWRELIC_VERSION 11.6.0.19
...
ADD https://download.newrelic.com/php_agent/archive/${NEWRELIC_VERSION}/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz /tmp/
RUN export NR_INSTALL_USE_CP_NOT_LN=1 NR_INSTALL_SILENT=1 \
    && tar -xf /tmp/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz -C /tmp \
    && /tmp/newrelic-php5-*/newrelic-install install \
    && rm -rf /tmp/*
...

Дальше ковыряюсь в конфигах самого приложения, но там ничего интересного.
Нет в явном виде "логирование енаблед тру" или подобного. Странно.
Ладно, ну поехали, смотрим через git кто когда вносил изменения в докерфайлэ, всё равно другой зацепки нет.

git log Dockerfile

И буквально через несколько коммитов вижу зацепку - коллега разработчик обновил версию newrelic.
Само собой нашёл и его PR и того, кто его аппрувил.
Но была обновлена только версия, больше ничего не менялось.
Херня какая.

Ладно, иду в POD, смотрю конфиг, а что внутри

cat /usr/local/etc/php/conf.d/newrelic.ini

и поиском вижу там нечто типа

newrelic.application_logging.enabled = true

Пилю себе ветку, в этой ветке делаю даунгрейд до старой версии newrelic, собираю имадж, смотрю в нём конфиг

newrelic.application_logging.enabled = false

Да бл.

Бегу в документацию и нахожу
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/

PHP agent version 10.1.0 lets you forward your PHP logs with APM logs in context. As of version 10.3.0, the logging metrics and agent log forwarding features are enabled by default. The value newrelic.application_logging.enabled controls whether or not the logs in context feature is active or inactive.

От суки, ладно, пилю быстрофикс (не удивлюсь, если он до сих пор там в докерфайле, лол).

RUN sed "s/^.*;newrelic.application_logging.enabled.*/newrelic.application_logging.enabled = false/" \
    -i /usr/local/etc/php/conf.d/newrelic.ini

Качу PR, аппрув, мерж, логи перестали идти в newrelic, прайс не растёт.

Ну а дальше как обычно: оповещение коллегам, ата-та так не делайте плиз, читайте доки перед апдейтом(да ладно, кому я вру, я бы тоже не читал), вот рут коз, вот фикс, вот ссылки, вот пруфы.
Все виновато покивали и сделали вид, что запомнили и не повторят ошибок. Да.

Потеря денег всего $460 за пару недель.
Идём работать дальше.

#troubleshooting #aws #ssh #retool #paranoia #linux

Ок, что же говорит ошибка. Текст типа

Test connection failed (120.327s):(SSH) Channel open failure: open failed
{query: "Connect Request", error: Object}
query: "Connect Request"
error: Object
message: "(SSH) Channel open failure: open failed"
data: Object
reason: 1
name: "Error"
message: "(SSH) Channel open failure: open failed"

и дальше огромная простыня трейса.
А ничего она не говорит, и так понятно, ясно понятно, нет подключения.
Прохожу снова по инструкции - всё ок.
Проверяю не менялся ли паблик ключ? Не менялся.
Не менялся ли пул публичных адресов? Не менялся.
Блин, ну я же не дурак.
Добавляю руками свой IP на секьюрити группу, подключаюсь на бастион хост и оттуда делаю телнет и подключение через cli к PostgreSQL.
Сетевая связность есть, коннект.
Проверяю ещё раз все секьюрити группы, поиск по коммитам, всё отлично.
Так, стоп, а предыдущие то ресурсы работают?
Захожу в retool, в давно созданные ресурсы - тест проходит ок.

Чешу репу, гуглю решения, закидываю в 3 нейронки - решения нет.
Общие предположения, да и только.
В общем в траблшутинге и логах я просидел долго.
Чтобы не было стыдно, не буду говорить сколько, но много.

В итоге я просто начал смотреть все журналы, все конфиги и даже трейсы, мне было очень интересно.
Очевидно же, что у меня что-то не так, иначе бы ранее добавленные ресурсы не работали.

Спустя время дошёл до конца файла /etc/ssh/sshd_config перебирая по одному все включённые параметры, а там.... а там парам-пам-пам!
А там паранойя, ну прям рили паранойя.

# bastion host 1.2.3.4

cat /etc/ssh/sshd_config |grep -v "^#"
...
Match User retool
  PermitTTY no
  AllowTcpForwarding yes
  PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017
  ForceCommand /bin/echo "Shell disabled!"

Я даже сам забыл про эту паранойю!

В общем добавляю очевидное

...
PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017 postgresql.amazonaws.com:5432
...

Перезапускаю

sudo systemctl restart ssh

и Voilà! - коннект от retool есть.

Описываюсь ребятам, они подтверждают, закрываю задачу.

Какая же мораль? Как обычно:
- не думай, что остальные глупее тебя, если пишут ошибка есть - значит она есть!
- вспоминай о своих параноидальных привычках, прежде, чем тратить время
- держи конфиг sshd в IaC (ansible например), а не руками заполняй, баран. Поиском по iac я быстро увидел бы причину

* адреса endpoints к БД само собой должны быть полными и длинными, короткие URL лишь для примера

#troubleshooting #aws #ssh #retool #paranoia #linux

Есть такая штука, называется retool https://retool.com/
Какая-то платформа для менеджеров, я ей не пользовался никогда в бизнес уровне.
В UI интерфейсе мышкой подключаются resource и на их базе могут строятся какие-то таблички, панели и прочая не интересная мне информация для менеджеров и сейлзов(наверное).
Resources чаще всего это база данных. Например MySQL или PostgreSQL. У retool тысячи их для любых интеграций.
Это всё, что надо знать для начала, идём дальше.

В основном Retool из интернета подключается к вашим ресурсам либо напрямую по hostname, либо к AWS через IAM credentials, либо через SSH bastion host.
Первый случай я не знаю для кого, у меня пока не было опыта публичных БД, второй способ мне не нравится, да и не пройти с ним SOC2 аудит, так что у нас только третий вариант - через ssh tunnel.

У них есть вполне годный гайд https://docs.retool.com/data-sources/guides/connections/ssh-tunnels, который подойдёт для 99% случаев.
Создаётся пользователь на бастион хосте(например через ansible или руками), добавляется их ssh public key, раскидываются права - всё готово. В общем всё по инструкции.
При подключении ресурса вы в UI указываете ваш bastion хост, порт и прожимаете test connection.
Если всё ок- ошибки нет. Не ок - ошибка.
Ошибка чаще всего дурацкая, потому что открывается какой-то аналог developer tool и показывает длинный стактрейс.

С retool я уже работал, подключал на проект много лет назад.
В то время в качестве бастион хоста была убунту 18 вроде и мне пришлось промучить весь стакоферфлоу, чтобы найти решение для себя при ошибке, мне не хватало

PubkeyAcceptedKeyTypes +ssh-rsa

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

resource "aws_security_group" "bastion" {
...
  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"
    # https://docs.retool.com/data-sources/reference/ip-allowlist-cloud-orgs
    # retool ip ranges only
    # tfsec:ignore:aws-ec2-no-public-ingress-sgr
    cidr_blocks = [
      "35.90.103.132/30",
      "44.208.168.68/30",
      "3.77.79.248/30"
    ]
    description = "SSH access from allowed IP ranges"
  }
...

Потом добавились секюрити группы по MySQL/PostgreSQL типа

resource "aws_security_group_rule" "this" {
  type              = "ingress"
  from_port         = 5432
  to_port           = 5432
  protocol          = "tcp"
  cidr_blocks       = ["*********"]
  security_group_id = aws_security_group.rds.id
  description       = "Allow PostgreSQL access from ***** VPC"
}

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

Прошло много лет.

Ко мне приходят ребята инженеры, говорят хотят добавить новую БД для retool.
Уже подключена монга, mysql и всякое, а теперь надо и PostgreSQL.
Ок, говорю, ну там всё уже настроено - все ssh ключи, секьюрити группы и прочее - всё должно работать - другие то ресурсы(БД) работает до сих пор.
Берите креды и сами настраиваете, мы же договорились, что не должно быть боттлнека -девопса.
Они высылают скрин, что ошибка подключения. Я само собой не верю (бл, когда я научусь думать, что другие люди не глупее меня 🐒, баран самоуверенный).
Иду сам в retool, копирую все креды, создаю ресурс, но у меня тоже ошибка.
Извиняюсь перед ребятами, пилю тикет, начинаю разбираться.😭

#байки #troubleshooting #kubernetes #openshift

В далёком уже 2020-2021 я пилил обучающие онлайн видео для компании, где работал.
Ну типа внутренние онлайн видео встречи "что такое кубернетес/опеншифт" на минималках для ВНЕШНЕЙ компании-партнёра из другой страны. От моей компании передача знаний другой компании-партнёру.
Ничего интересного там не было, общий концепт куба, общие уровни абстракции и так далее.
Помимо этого были куски про CICD и так далее от коллег по компании.
В общем "DevOps онлайн уроки на минималках", галопам по европам skill-опам.

Одна из частей уроков была подготовка стенда во внутренней сети компании для студентов, чтобы они вживую всё это потыкали и сделали ДЗ.
Этим занимались системные администраторы(крутые ребята, между прочим!) внутри компании.
Установили GitLab, OpenShift, TeamCity, Nexus OSS etc.
Мы, "преподаватели", лишь дали указания, что нам надо, количество нод, версии и всё.
Когда админы всё подготовили, нам дали лишь эндпойнты и креды.
Нам лишь надо было подготовить домашки и всё проверить самостоятельно.

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

Сидим, оба "преподавателя" и хлопаем глазами*, как сельские дурачки🤡.
Признаться над своей некомпетентностью стыдно. Даже самому себе.

Потом, меня, внезапно, осеняет. Говорю:
- "а как ты проверял от себя локально? Какие команды вводил?"
- "ну докер билд, докер пуш, докер пулл для проверки"
- "а какой рантайм у опеншифта?"
- "ну cri-o вроде"
Ага, проверяли-то мы по-разному.

Иду к админам, тихонечко спрашиваю:
- "а случаем нет ли какого балансёра перед реджистри?
- "ну как нет, конечно же есть, у нас по регламенту должен быть балансёр"
Бегу в github, качаю нужные бинари крио, канико, докера, подмана и так далее.
Запускаю пулл с каждой из них, в фоне гоню tcpdump.
У всех разный user-agent 🐒. Сука.

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

Зачем нужен был балансёр перед реджистри внутри закрытой корпоративной сети, с фильтрацией по юзер агенту, я так и не узнал, сперва забыл спросить, а потом и вовсе тот админ покинул компанию, а спустя год и я ушёл.🤷🏽‍♂️

* да, вот такие "преподаватели" порой участвуют в преподавании.
Ради лишнего гроша участвуешь и не в такой активности компании😭.

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

Интервью где-то в параллельной вселенной.


- Переходим к следующему вопросу. Что происходит, когда вы вводите команду kubectl apply -f file.yaml?
- kubectl: command not found

- А, ладно, допустим установлен. Попробуем снова.
- error: the path "file.yaml" does not exist

- (Раздражённо) Нет-нет, файл точно есть.
- error: You must be logged in to the server (Unauthorized)

- (Устало) Так, у нас есть все бинари, ямл и контекст
- Unable to connect to the server: dial tcp 10.0.0.1:443: i/o timeout

- (обречённо) Да что же вы мне всё путаете, ок, есть файлы и контекст и доступ по сетке с VPN и с RBAC проблем нет
- Хорошо, kubectl apply по умолчанию использует Server-Side Apply, если не ошибаюсь с Kubernetes 1.23, где сервер разрешает конфликты полей через field managers. На клиенте YAML конвертируется в JSON для отправки на API-сервер. В случае client-side apply добавляется аннотация last-applied-configuration для 3-way merge. После получения запроса API-сервером объект проходит через mutating admission controllers и затем validating admission controllers, прежде чем сохраняется в etcd. В etcd данные хранятся в protobuf, а каждый write увеличивает resourceVersion - счётчик версий, который контроллеры используют для optimistic concurrency control, избегая race conditions.
Затем...

- (удивлённо прерывая) Стоп-стоп, эээ... я вообще думал про шедулер и поды с кублетом..
- До этого мы ещё даже не дошли. Могу предложить перейти сразу к продакшн-кейсам по вашей вакансии для ведущего инженера, а не к тесту на внимательность и глубокое ныряние в омут, в котором, порой, можно потонуть всем и сразу?
- Да-да, пожалуй вы правы, мне стоит пересмотреть точность и корректность вопросов практикующим инженерам..

#aws #eks #kubernetes #bottlerocket #troubleshooting

Case:
AWS EKS, Bottlerocket AMI. Случайно уронили коллектор логов, сбора не было несколько часов, но логи нужны прям сейчас. Если коллектор починить, то ждать долго(кстати какого фига долго я хз).
Нужных логов в поде нет, в ArgoCD их тоже нет(логично же).
Как быть?

Можно слить с EKS node(s), но этот путь не очевидный, ведь у нас Bottlerocket.

Для начала нужно быть уверен, что вы включали админ доступ в TOML конфиге.*

# Доступ к системным логам, получению root-оболочки (sheltie), запуску journalctl, logdog и пр.
[settings.host-containers.admin]
enabled = true

# Доступ к Bottlerocket API для настроек и диагностики, но без глубокого доступа к логам и файловой системе ноды.
[settings.host-containers.control]
enabled = true

Ок, админ доступ включён.
Смотрим на какой ноде запущен наш под.

kubectl get pods -o wide | grep podname
...  ip-10-1-114-226.ec2.internal ...

Узнаем айди инстанса.

kubectl get node -o yaml ip-10-1-114-226.ec2.internal | grep -A4 -i "nodeid"
... "i-09cd72826bee50209" ...

Подключаемся к инстансу через SSM

aws ssm start-session --target i-09cd72826bee50209

Сейчас нет никаких прав, переходим в админа.

enter-admin-container

Ок, мы стали админами(через контейнер), теперь нам нужен шелл - шелти.

[root@admin]# sudo sheltie

Дальше просто смотрим в /var/log/

ls /var/log/containers/
argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log
...

Ну и смотрим логи

cat argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log

"но Алекс, нам нужны все логи, как их слить к себе локально?"
Ок, запускаем сборку логов в шелти

bash-5.1# logdog

После коллекции у нас логи хранятся на ноде в

logs are at: /var/log/support/bottlerocket-logs.tar.gz

Теперь со своей локальной машины дёргаем их к себе через k8s API (да-да, я тоже не знал)

kubectl get --raw "/api/v1/nodes/ip-10-1-114-226.ec2.internal/proxy/logs/support/bottlerocket-logs.tar.gz" > ./bottlerocket-logs.tar.gz

У нас локально теперь все логи в bottlerocket-logs.tar.gz
Задача решена.**


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

** При необходимости повторить для других нод, если исторически старый под был запущен на других нодах.

#victoriametrics #traces

Я ждал-ждал и наконец-то дождался.
Helm чарт трейсов в VM и саппорт в операторе.
Скорее всего с багами, ибо первый релиз, но всё равно в dev домой накачу вечером.

- https://github.com/VictoriaMetrics/helm-charts/pull/2400
- https://github.com/VictoriaMetrics/operator/pull/1499

#kubernetes #secrets #api

(заметка не несёт никакой ценности, лишь мысли)

Иногда, для самого себя, я провожу теоретические, вперемешку с практическими, изыскания.
Выбираю узкопрофильную тему и ковыряю, пока не дохожу до кишков.

Это может быть знания зачем EXPOSE в докер файле и на что это влияет, какая разница между cgroup v1 и cgroup v2 или различия хранилищ для больших данных и миллиардов мелких файлов по 6 KB.
Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".

Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько VERBs.
https://kubernetes.io/docs/reference/using-api/api-concepts/

Знания и поиск по документации привел к тому, что есть WATCH запрос, который идёт каждый раз от kubelet, когда стартует под или скейлится или происходит редеплой через любую из стратегий, при использовании секрета кубернетиса.
То есть каждый раз при этих действиях идёт WATCH.
Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.

sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

Затем мои поиски вывели на отличную опцию immutable в секретах (вру, я слышал и знал о ней раньше, но прям в проде не использовал).
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.

"если секрет иммутабл, то кублет(с каждой ноды) не делает WATCH запрос в апишку".

"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде 😀
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки

В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)

sum(rate(apiserver_request_duration_seconds_sum{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)
/
sum(rate(apiserver_request_duration_seconds_count{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)

- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)

sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.

Всё выглядит как сказка, а что на деле?

Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.

Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой immutable секрет замонитирован на ноде более, чем в один под(разные деплойменты) то такой секрет не подтянется при изменим даже при рестарте.
Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.

Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭

#пятница #байки #troubleshooting

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

Мы разрабатывали спутниковое оборудование - модем.
Ну, типа коробочка: в один конец втыкается ethernet, в другой - кабель для спутниковой антенны. Если объяснять совсем упрощённо.

Однажды поступил сигнал, что в одном месте, куда мы поставляли железо, периодически перестаёт работать связь. Там уже меняли всё: и внешнее оборудование (LNB, передатчик), и кабели, и внутреннее - модемы и блоки питания. Не помогало.
Основная гипотеза была: враги, конкуренты или радиолюбители мешают на спутнике.
Короче, время от времени канал тупил.
Худшая гипотеза - наше оборудование овно, а это тревожный звонок для бизнеса.

Сначала я пытался разобраться удалённо.
Соорудил наспех snmp-monitoring-схему, даже просил людей записывать на бумажке время, когда "глючит". Получилось, что срывы происходят утром, днём и вечером - плюс-минус в одно и то же время.
Но удалённо разобраться не вышло.
А это клиенты, так что надо было срочно решать проблему.
В итоге меня отправили в командировку на три дня.

Меня поселили в гостинице рядом, но на саму территорию связи просто так не пускали.
Утром провели внутрь для диагностики.
Я весь день таскался со своим измерительным оборудованием (два ящика, кстати!), слонялся туда‑сюда, выглядел, наверное, как идиот-“следящий”. Но одного дня мне хватило.

К концу первого дня я понял, в чём дело.
За стеной пункта связи оказалось другое помещение - кухня.
Там сотрудники по утрам грели еду, потому что дома не успевали.
Включали самую паршивую китайскую микроволновку, которая фонит во всех, бл… диапазонах - даже в L band!
Излучение пробивало стену и било прямо по стойке с оборудованием.
Влиял не только наш модем, но и соседнее железо, просто про это никто даже не догадывался.
Днём они грели обед, вечером - кофе.

Я поставил анализаторы, показал сотрудникам и начальнику графики и реальные замеры.
Для чистоты эксперимента включал микроволновку и демонстрировал, как ровно в этот момент садится спутниковый сигнал.
После этого микроволновку перестали включать - и все проблемы исчезли.

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

Оставшееся время командировки я гулял по местному лесу и думал о том, сколько таких дешевых микроволновок по всему миру, и как редко рядом оказывается человек с анализатором.

#azure #finops #devops

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

Была подзадача "перетащить часть проекта с Azure stack на Bare metal".
С платформой и стеком выбор был уже почти сделан, надо было лишь развернуть инфру и перетащить данные.
Инфру развернули за 0.0001мс - мы же все гитопсы теперь.
С данными вышла засада - их было 330+ терабайт. И это лишь в одном блобе. Блобов много.
Мы были не готовы к таким цифрам в bare metal и это пахло проблемами.
И капасити и скорость передачи данных в бар метал - это сколько недель ждать?
Решили вообще узнать - а все ли данные нужны?
Зашли к девелоперам по datawarehouse стеку, они сказали нечто типа "ну мы, конечно же, компания, специализирующая на данных, данных у нас ОЧЕНЬ много, но цифра не похожа на настоящую".
Это отличный пойнт, а значит время для анализа.
Базово ажур ничего не даёт по аналитике, либо за деньги, а потому надо всё включать.
Первым делом включили Inventory - специальный инструмент, позволяющий получать отчёт о всех данных внутри блоба. Запустили, сутки ждали, он сформировался в CSV файле, вроде около 150 мегабайт.

Ок, у нас есть миллионы строчек, но сами же мы не будем глазами считать.
Создаём локально базу данных PostgreSQL.
Затем создаём табличку типа (тут есть ошибки, но это не влияет на саму задачу)
https://gist.github.com/kruchkov-alexandr/9f1210db954c92b059113835e950562e
Запускаем DBeaver и импортируем CSV файл в это локальную базу данных PostgreSQL.

Данные по объектам в блобе, а значит пора мучать любимый AI ассистент SQL запросами, нечто типа
https://gist.github.com/kruchkov-alexandr/73096e1a8a78274944dcb3c02c45f090
Оба запроса собирают статистику по контейнерам blob, считая количество файлов и их суммарный размер в GiB, также выводят общий итог по всем контейнерам.

Возвращаемся к девелоперам, показываем статистику, анализ, все в шоке, срочный колл, разбор полётов.
Не буду опускаться в суть бизнес процессов, почему и где была логическая проблема, но в общем у нас был сбой
и данные дублировались. Трижды всё проверили, расписали план и двинулись дальше:
- удалили часть данных
- включили лайфсайкл полиси на 1 день
- выключили safe delete или как это называется
- что-то ещё, но я уже не помню

В общем на момент истории блоб весит 44 терабайта, удалено больше 280 терабайт.

Какие же потери мы понесли с момента бага с дублированием?
- чтение/перечтение данных каждый день
- операции
- хранение
Итого $3500+ в месяц. За один только блоб.
Просто три с половиной шутки за мусорную дату каждый месяц....

Дальше создали задачи по всем энвайронментам пройтись, по всем стораджам, сделать такой же анализ и сходить по командам за уточнением процессинга и хранения даты, чтобы везде снизить косты, раз уж у нас был один инцидент.

Да, компания специализируется на дате, её очень много, и само собой никто уже с огромными объемами не мониторил банальный сбой и дублирование / версионирование / сейфделиты / редубликацию трафика на ингрессе и так далее. Когда данных петабайты, особо не следишь где чего и сколько. Всем кажется, что это нормально.

Итоги:
- коллега я, крутой и мощщный синёр помидор, показал всем, как делать аналитику сотен миллионов объектов в блобе
- узнали о величайшем(нет) провале по мониторингу биллинга и размера даты
- на момент стори снизили косты на $3500+ в месяц 😭 Точная сумма будет известно потом, когда завершаться все работы по всем стораджам, а их не мало.
- отчасти сняли блокер по переносу даты в барметал (нет, но это другая история)

#argocd #gitops

В рамках самостоятельной профессиональной регулярной переподготовки поработал пару ночей над ArgoCD https://argo-cd.readthedocs.io/

Вообще я с ним давно работаю, всё умею, вношу правки, добавляю новые аппликейшны/аппликейшнсеты, траблшутю и вообще всё понятно.

Но что, если всё поднять с нуля и не подглядывать за ранее написанным кодом?
Насколько сильно обделаюсь в свои портки за 40 грошей?

Задача простая: есть тестовая организация в GitHub, внутри 3 тестовых репозитория с 3 микросервисами, 1 репозиторий с универсальным helm chart, который подходит всем 3 тестовым микросервисам, 1 репозиторий argocd с манифестами Application + Application Set. Всё сделать сперва на мастер ветке, потом по тегам докер имиджа.
Мы стильные молодёжные, так что сразу с SSO авторизацией.
Есть тестовый(студенческий) аккаунт MS Azure + MS Entra.
Финишем добавить пару общий хелмчартов, ну не знаю, допустим прометиус стек, так же через арго.

Признаюсь, первые часа два я дичайше тупил.🚬
Сперва долго тупил с SSO. Потом орнул с разделения админ центра/enterprise applications/app service.
Ок, авторизацию прикрутил и это хорошо.
Потом долго пытался понять а как вообще цеплять репозитории к арго серверу.
Все валуес файлы делать в каждом репозитории? Или все валуес файлы хранить в репах с аппликейшнсетами?
Аппликейшн или аппликейшнсеты пилить? С учётом на рост(теории).
Если валуес хранить в репозиториях микросервисах, получается мне надо каждый из них внести по отдельности вместе с кредами? А как лучше - через https или git? А как проходит авторизация с гитом?
В итоге сделал через PAT GitHub и логин git (внезапно).
Ладно, репы подключил, но что если я всё ещё хочу валуес файлы хранить в репе с сервисам, а не в арго репе - мне все репы отдельно подключать надо?? Это же бред. Потом прочитал(и спросил у коллеги) про креденшл темплейт, что облегчило мою задачу, ведь всё в одной организации гитхаба. Не надо каждый подключать, очень удобно.
С репами вроде закончил.
Затем я перечитал десятки страниц документации, всякие how to/get started etc.
А у меня ничего не получалось.
Просто не было понимания как стартовать с нуля.
Вроде вот всё понятно: вот репы, вот чарт, вот аппликейшнсет, сейчас будет ????? и ???? и всё заработает.
Не хватало какого-то краеугольного куска гранита для понимания что не так.
В общем просто "изначальный" аппликешйн, который должен играть роль init/controller/bootstrap/App-of-Apps/mainapp (назвать как удобно), который и указывает аргохе куда смотреть на основные аппликейшнсеты...надо создавать руками через kubectl apply -f init.yaml
Я не нашёл иных способов, как изначальную инициацию сделать без разового ввода команды.
Ок, это заработало, засинкалось. Появились аппликейшн сеты, пробовал добавить ещё, новые репы и так далее. Всё заработало.
Потом я ковырялся в реконселейшн арго, так как k8s кластер тестовый, free tier и его апишку просто ломало полностью от 8 приложений(+5 от чартов).
Вернулся к ролевой модели, поковырялся кто может видеть логи, кто может делать рестарт подов и удалять ресурсы, тоже потратил время.
В общем и целом задача закрыта - поднял всё с нуля. Не удивлюсь, что где-то сделал глупо, но идеально и не стояло задачи.

Увлекательное время.
Закрыл несколько пробелов в знаниях, освежил старые знаний.
Всё же одно дело работать с инструментом, который я либо настроил давно, либо вообще делали без меня, другое дело поднять всё с нуля.

#aws #smallindiecompany #ui #🐒

ALRIGHT AWS, ALRIGHT, I GET IT