fission-console/doc/thinking/2026-04-15.md

2026-04-15 — Thinking Log

Агент: GitHub Copilot (Claude Opus 4.6)

---

Сессия: Fixup invoke auth в fission-console

Контекст на начало сессии

Console (fission-console) — веб-UI для управления Fission serverless functions. Был полностью реализован: CRUD (create/get/update/delete), UI с модалами, unit-тесты, Docker-образ, k8s deployment, ingress. Всё работало через https://fission.kube5s.ru/console/.

Единственная нерешённая проблема: invoke функции через console API возвращал 401 unauthorized: malformed token — роутер Fission требует авторизацию.

Анализ проблемы

Invoke flow: console → POST к роутеру Fission → роутер вызывает функцию.

Роутер Fission (router.fission.svc.cluster.local) сконфигурирован с auth:

• AUTH_USERNAME / AUTH_PASSWORD — из секрета router
• JWT_SIGNING_KEY — из секрета router
• ConfigMap feature-config содержит: auth.enabled: true, auth.authUriPath: "/auth/login", auth.jwtExpiryTime: 120

Значит роутер использует собственный JWT, а не K8s ServiceAccount tokens.

Первая попытка: SA token (неудачная)

Изначально решил использовать ServiceAccount token из пода:

• Файл /var/run/secrets/kubernetes.io/serviceaccount/token автоматически монтируется в любой под
• Добавил saTokenPath в server struct, метод readSAToken()
• При invoke читал токен и ставил Authorization: Bearer <token>

Результат: 401 unauthorized: key is of invalid type — роутер пытался валидировать K8s JWT своим signing key (HS256), а K8s SA token — RS256. Не совместимы.

Исследование auth-механизма роутера

Прочитал секрет router:

• username: admin
• password: 7XG1lSg0EFqPLE4pf3He
• jwtSigningKey: FWT3rdVUwfUn08tkC3lt

Проверил endpoint /auth/login:

POST http://router.fission.svc.cluster.local/auth/login
Body: {"username":"admin","password":"..."}
Response 201: {"accesstoken":"eyJ...","tokentype":"Bearer"}

Проверил invoke с полученным JWT:

GET http://router.fission.svc.cluster.local/auth-test2
Header: Authorization: Bearer eyJ...
Response 200: hello

Работает! Роутер принимает свой JWT.

Вторая попытка: JWT login (успешная)

Решение: console при invoke делает POST /auth/login к роутеру, получает JWT, кеширует, использует для вызова функции.

Изменения в main.go:

1. Добавил поля в server struct: authUser, authPass, tokenMu sync.Mutex, cachedJWT, tokenExpAt
2. Новый метод getRouterToken():
   • Если authUser/authPass заданы → делает POST /auth/login
   • Кеширует JWT на 100 сек (JWT expiry = 120 сек, берём с запасом)
   • Fallback на SA token если login не удался
3. В handleInvokeFunction вызывает getRouterToken() и ставит Authorization: Bearer <token>
4. Env переменные FISSION_AUTH_USERNAME / FISSION_AUTH_PASSWORD берутся из секрета router

Изменения в deploy/console.yaml:

• Добавил env FISSION_AUTH_USERNAME и FISSION_AUTH_PASSWORD с secretKeyRef из секрета router

Баг: 201 vs 200

Первый деплой с JWT login не работал: в логах видно что login возвращает 201 Created (не 200 OK), а мой код проверял строго resp.StatusCode != http.StatusOK. JWT получался, но отбрасывался.

Фикс: if resp.StatusCode != http.StatusOK && resp.StatusCode != http.StatusCreated {

Баг: кешированный Docker-образ

После первого docker push naeel/fission-console:v0.2.0 без JWT, потом пересобрал с JWT и запушил тот же тег v0.2.0. Но нод кластера использовал старый образ (imagePullPolicy по умолчанию = IfNotPresent). SHA не совпадали.

Решение: начал использовать инкрементальные теги (v0.2.1, v0.2.2).

Финальный результат

E2E тест через ingress:

=== create ===
{"httptrigger":"final-test-route","name":"final-test","package":"final-test-pkg","route":"/final-test"}

=== invoke ===
{"invoke_url":"http://router.fission.svc.cluster.local/final-test","latency_ms":138,"response_raw":"invoke works!","status":200}

=== delete ===
{"deleted":true,"name":"final-test","package":"final-test-pkg"}

Все 5 тестов пройдены. Commit 8920ba1 → feat/console.

Обновление unit-тестов

Тест TestInvokeFunctionWithJWTAuth:

• Поднимает mock HTTP server, который на /auth/login возвращает {"accesstoken":"fake-jwt-token-xyz"}
• На другие пути проверяет Authorization header
• Создаёт функцию через CRUD, вызывает invoke
• Проверяет что JWT был получен и отправлен

Итоговая архитектура auth flow

User → POST /console/api/functions/NAME/invoke
            ↓
    Console backend:
    1. GET trigger для NAME → route, methods
    2. getRouterToken():
       - cached JWT есть и не expired? → используем
       - иначе POST /auth/login → получаем JWT, кешируем на 100s
    3. GET/POST router_url + route
       Header: Authorization: Bearer <JWT>
            ↓
    Fission Router (валидирует JWT)
            ↓
    Function pod → response
            ↓
    Console → User (JSON: status, latency_ms, invoke_url, response_raw)

---

Сессия: Обновление правил репозиториев

Добавлены правила работы с файловой системой и SSH:

• sless: обновлён .github/copilot-instructions.md — добавлена секция про маппинг путей, разрешение редактировать локально, обязательность SSH для команд
• fission: создан .github/copilot-instructions.md с аналогичными правилами

Причина: VPN может быть активен локально, вызывая сбои при прямом выполнении команд. Монтирование sshfs делает локальное редактирование файлов эквивалентным редактированию на ВМ.

---

Сессия: JS invoke timeouts в UI (root cause + fix)

Симптом

• Все JS invoke через UI (/console/api/functions/{name}/invoke) падали по timeout.
• В router логах: roundtripper timeout (60s)/error sending request to function.
• В executor логах specialization для node окружения могла проходить, но ответ функции не возвращался.

Ключевые находки

1. Node runtime работал через POST /v2/specialize.
2. При functionName=main runtime строил путь загрузки как: - /userfunc/deployarchive/main
3. В реальном поде /userfunc/deployarchive был файлом (literal payload), а не директорией.
4. После перевода на пустой entrypoint (functionName="") specialization стала успешной (202, user code loaded), но запросы всё равно зависали.
5. Прямая проверка контейнера показала второй контрактный нюанс node runtime: - пользовательская функция должна возвращать объект формата { status, body, headers? } - возврат простой строки приводил к зависанию ответа (callback не отправлял HTTP response).

Принятые изменения

• nodejs-acc закреплен на ghcr.io/fission/node-env:1.32.5.
• Для JS функций (fn-js-acc, fn-js-direct, тестовые jsm1..jsm4): - выставлен пустой entrypoint (functionName="") - код приведен к контракту Node runtime: - module.exports = async function(context) { return { status: 200, body: "..." }; }
• Для основных JS trigger включены методы GET и POST.

Проверка

• UI invoke: - fn-js-acc -> status=200, response_raw=hello-js-ok - fn-js-direct -> status=200, response_raw=hello-js-ok
• Прямые GET через роутер: - /js-acc -> 200 - /js-direct -> 200
• Тестовые jsm1..jsm4 после унификации кода -> 200 через UI invoke.

Вывод

Проблема была не в UI-рендеринге и не в одном конкретном trigger, а в несовпадении контракта Node runtime:

• entrypoint/path specialization
• shape возвращаемого значения функции.

---

Сессия: Финальный fix fn-go-acc (Go runtime specialization)

Симптом

• fn-go-acc выдавал timeout на invoke через console/router.

Диагностика

1. На исходной конфигурации в executor логах: - plugin.Open("/userfunc/deployarchive/main.go"): invalid ELF header.
2. Это означало, что runtime ожидал plugin-артефакт, но в package deployment лежал исходник main.go.
3. После первой попытки собрать plugin локальным go1.26.1 ошибка invalid ELF ушла, но появился новый фейл specialization: - Post "http://127.0.0.1:8888/v2/specialize": EOF.
4. Вывод: plugin собран несовместимой версией Go относительно runtime.

Решение

• Сборка plugin выполнена в ghcr.io/fission/go-builder (Go 1.25.6), то есть тем же toolchain, что у Fission environment builder: - GO111MODULE=off /usr/local/go/bin/go build -buildmode=plugin -o main.so ./main.go - упаковка main.so в deploy.zip.
• Обновление функции через CLI: - fission function update -n default --name fn-go-acc --env go-acc --entrypoint Handler --deployarchive /tmp/fn-go-acc-fix2/deploy.zip -f

Проверка

• /go-acc через router с JWT: hello-go-ok, HTTP 200.
• В executor логах specialization успешен: - specialized pod - added function service - без invalid ELF и без EOF.

Контрольная матрица маршрутов

• /auto/ok -> 200
• /js-acc -> 200
• /js-direct -> 200
• /go-acc -> 200

Практический вывод

Для go-env в этом кластере критично соблюдать контракт runtime:

1. deploy-пакет должен содержать именно plugin (.so), а не исходник.
2. plugin должен быть собран совместимой версией Go (через ghcr.io/fission/go-builder).

---

Сессия: Edit Code для fn-go-acc пустой

Симптом

• В UI (GET /console/api/functions/fn-go-acc) поле code было пустым.

Почему так произошло

• После фикса runtime функция была переведена на deploy-архив plugin (main.so).
• Package имел вид: - spec.deployment.type=url - spec.deployment.url=... - без spec.deployment.literal
• Backend в handleGetFunction извлекал код только из spec.deployment.literal, поэтому для URL-пакета отдавал пустую строку.

Что изменено

• В backend добавлен extractPackageSourceCode(...) с fallback-приоритетом: 1. spec.source.literal 2. spec.deployment.literal 3. spec.source.url 4. spec.deployment.url
• Добавлена загрузка URL-архива через fetchPackageArchive(...) и декодирование через decodeArchiveBytesToSource(...).
• Обновлен unit-тестами сценарий, где deployment.literal отсутствует, но есть source.literal.

Операционные шаги

• Собран и задеплоен naeel/fission-console:v0.2.6.
• Для текущей fn-go-acc дополнительно обновлен sourcearchive (main.go), чтобы исходник гарантированно отображался в Edit Code.

Результат

• GET /console/api/functions/fn-go-acc теперь возвращает непустой Go source в code.
• Вызов /go-acc остается рабочим (hello-go-ok, HTTP 200).

---

Сессия: Проверка TLS + branding NUBES + верификация tf-neg-syntax-fn

TLS

• Проверен доступ к console: - http://.../console/ -> 308 redirect на HTTPS - https://.../console/ -> 200
• Ingress конфиг содержит корректный TLS блок и принудительный SSL redirect.
• Вывод: endpoint защищен TLS, «незащищенного HTTP-доступа» нет.

Брендинг NUBES

• В console/ui/index.html добавлены: - <title>NUBES Fission Console</title> - favicon (inline SVG) - navbar brand block с NUBES / FISSION CONSOLE.
• Обновлен образ до naeel/fission-console:v0.2.9.

tf-neg-syntax-fn — почему timeout вместо прямого SyntaxError

• Функция содержит заведомо битый Python (def main(:), confirmed через GET /console/api/functions/tf-neg-syntax-fn.
• На runtime это роняет specialization (500), после чего executor ретраит.
• Поэтому router/console не получает «чистый traceback» сразу из runtime API и видит timeout/ошибку specialization.
• Для UX введен fail-fast и явная ошибка в console invoke: - timeout after 20s: function specialization likely failed (for example, syntax error).

---

Сессия: "Не защищено красным" — экстренное лечение

Наблюдение

• Сертификат endpoint сам по себе валидный (Let's Encrypt, CN/SAN = fission.kube5s.ru).
• Но на том же host были два ingress с разной TLS-конфигурацией: - fission-console с TLS - fission-router без TLS

Действие

• Патч fission-router: - добавлен spec.tls с secretName: fission-tls - добавлен force-ssl-redirect=true

Результат

• HTTP на роутер-пути дает 308 -> HTTPS
• HTTPS на console стабильно 200
• Конфигурация host выровнена: теперь и console, и router на одном сертификате.

---

Сессия: Строгая чистка до "только точно рабочие и видимые"

Запрос

• Оставить только функции, которые в UI/Console: - показывают исходник (code не пустой) - реально вызываются (invoke.status == 200)

Что произошло

• Выполнен массовый cleanup с keep-list.
• По логу cleanup выявилась ошибка jsonpath в пост-обработке orphan-пакетов: - использовалось {n} вместо {"\\n"} - это ломало шаг удаления orphan-объектов после основного удаления.
• Основное удаление функций при этом сработало корректно.

Проверка после cleanup

• Текущее состояние: - functions: 6 - httptriggers: 6 - packages: 6
• Остались только: - auth-test2 - fn-js-direct - fn-js-acc - hello - tf-auto-ok-fn - tf-stress-fast-fn
• Для каждой функции через Console API подтверждено: - code=OK - invoke=OK

Вывод

• Финальный набор теперь соответствует строгому критерию "однозначно работает и показывается".

---

Сессия: Возврат к 15 функциям + проверка ожиданий + live favicon

Наблюдение в начале

• После строгой чистки в кластере оставалось 6 функций.
• В live UI favicon оставался старым, хотя в репозитории правка уже была.
• Проверка deployment показала: работал старый image naeel/fission-console:v0.3.0.

Расширение набора до 15

• Добавлены функции из примеров: - tf-hello-fn, tf-deep-recursion-fn, tf-destroy-test-fn, tf-freq-update-fn, tf-orphan-fn - tf-multi-env-1-fn, tf-multi-env-2-fn, tf-multi-env-3-fn
• Добавлен негативный кейс: - tf-neg-syntax-fn + route /neg/syntax
• Итоговый размер: - functions = 15 - httptriggers = 15

Что сломалось и как починено

1. multi-env-1/2/3 не применялись: - ошибка Terraform: Invalid escape sequence из-за "$\{path.module\}/code". - фикс: заменено на "${path.module}/code" во всех трех main.tf.

2. После применения multi-env-1/2/3 маршруты таймаутили (rc=28): - причина: image env ghcr.io/fission/python-env:v1.20.0. - фикс: переключено на ghcr.io/fission/python-env, re-apply всех трех модулей. - результат: /multi-env-1, /multi-env-2, /multi-env-3 -> HTTP 200.

Финальная тест-матрица

• Router tests с JWT: PASS=15, FAIL=0.
• Успешные 200: базовые + multi-env + tf-hello + stress-fast.
• Ожидаемые ошибки: - /deep-recursion -> timeout (HTTP 000, rc=28) - /neg/syntax -> timeout (HTTP 000, rc=28)
• Console invoke подтверждает: - positive функции -> status=200 - negative функции -> fail-fast timeout error.

Favicon в live

• Собран и выкачен naeel/fission-console:v0.3.1.
• deployment/fission-console обновлен и rollout успешен.
• Проверка https://fission.kube5s.ru/console/ показывает нужный favicon URL: - https://nubes.ru/themes/custom/nubes_2025/favicon.png.