#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, копирую все креды, создаю ресурс, но у меня тоже ошибка.
Извиняюсь перед ребятами, пилю тикет, начинаю разбираться.😭

#linux

Самое сложное это переступить свои привычки и стереотипы.

Начал карьеру с VSCode/vim/IDEA - привыкаешь с хоткеям, интерфейсу, удобству.
С браузером так же. Пересесть на другое - неудобно, непривычно, неохота.

По Linux утилитам тоже самое, одни плюсы: часть уже есть в операционной системе по умолчанию, часть ты знаешь так, что даже без нейронки и хелпа на память помнишь синтаксис.
cat, sed, ping, du, df, grep, awk

Зачем переходить на другое?
- Его надо отдельно ставить. Фу.
- Снова учить синтаксис. Больно, да.

Однако причины перейти всё же есть.
Скорость работы, удобство и новые фичи.
Конкретно для меня это user/human-friendly.

Для себя я нашёл эти и даже успел к ним привыкнуть:

cat ~/.tool-versions
...
jq 1.8.1
direnv 2.37.1
duf 0.9.1
dust 1.2.3
bat 0.25.0
yq 4.48.1
delta 0.18.2
...

Остальное тоже пробовал, но не прижилось.
Фигня для rustаманов-зумеров 😁.
Шучу, просто не зашло по задачам🤡.

Ниже список репозиториев, где есть несколько современных утилит - замена/альтернатива привычных всем:
- https://github.com/ibraheemdev/modern-unix
- https://github.com/johnalanwoods/maintained-modern-unix

Как бонус (не замена, а просто общий список):
- https://github.com/agarrharr/awesome-cli-apps
- https://terminaltrove.com/list/

#kubernetes #linux #база

Существует достаточно частая проблема: ошибки категории "misleading".
Когда копаешь в одно, а проблема в другом.

Инженеры Kubernetes иногда сталкиваются с крайне сбивающей с толку ошибкой при запуске пода:

MountVolume.SetUp failed... no space left on device.

Не зная причины этой ошибки, мы сперва тратим время на:
- просмотр что за PVC используются у деплоймента/пода.
- что за нода сейчас запустила этот под, нет ли нехватки места на самой ноде
- лезут в графану, в метрики и графики по нодам, подам, PV
- как разбиты разделы диска на нодах, что и сколько отдаётся эфемеркам
- чего там по айнодам (ну наконец-то пригодились эти знания! 🕺)
- и так далее
И это правильные мысли и план, это так же может быть причиной ошибки, но наш случай про другое.

Попытка найти строку "no space left on device" в исходном коде Kubelet на GitHub также не дает результатов, потому что Kubelet не генерирует этот текст - он просто ретранслирует низкоуровневую ошибку, полученную от ядра Linux(или от рантайма, тут могу наврунькать).

Истинная причина кроется в тонком различии между единицами измерения CPU и памяти в спецификации ресурсов. Это особенно критично для Проецируемых томов (Projected Volumes), таких как Service Account Token (kube-api-access-*), которые монтируются как tmpfs (файловая система в RAM).
https://kubernetes.io/docs/concepts/storage/projected-volumes/

Когда инженер по ошибке использует суффикс CPU (m) для лимита памяти, например:

resources:
  limits:
    memory: "512m"  # Ошибка, должно быть "512Mi"!

- Kubelet парсит "512m" для памяти как метрический милли, что равно 0.512 байта. Поскольку размер тома (tmpfs) должен быть целым числом, это значение округляется до 0 байт (или ничтожно малого значения). Kubelet использует этот 0 байт для установки максимального размера тома tmpfs.
- Kubelet использует этот лимит памяти для установки максимального размера тома tmpfs для Service Account токена
- Ядро Linux получает запрос на монтирование tmpfs с нулевым или ничтожно малым размером. Системный вызов mount завершается неудачей (из-за попытки выделить даже минимальный объём, обычно 1 страница = 4 KiB). и возвращает низкоуровневую ошибку ENOSPC ("No space left on device"), поскольку невозможно создать файловую систему (даже в RAM) с таким малым выделением ресурсов.

То есть в нашем случае ошибка "no space left on device" на самом деле означает: "Не удалось создать RAM-диск (tmpfs) требуемого объема, потому что выделенный размер (0 байт) некорректен".

❕Стоит понимать, что Kubernetes API сервер не считает "512m" для памяти ошибкой валидации.
Он принимает это как легальное значение (0.512 байта), что позволяет поду быть созданным, но приводит к сбою выполнения (runtime failure) при монтировании на ноде.

Решение очевидное:
всегда используйте бинарные единицы (IEC) для ресурсов памяти: Mi (мебибайты), Gi (гибибайты).
Может есть и другие, я только эти использовал всегда.

Чтобы превентивно избавляться от такой проблемы, используйте дополнительно:
- pre-commit hooks
- валидаторы cli в CI/CD процессе

Какие-то конкретные утилиты советовать не буду, оставлю ссылки для примера:
- https://github.com/instrumenta/kubeval (давно не обновлялся, но он работает ок)
- https://github.com/yannh/kubeconform
- https://github.com/kubernetes-sigs/kubectl-validate

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