docs: record strict cleanup to 6 verified functions
This commit is contained in:
Naeel
@@ -147,3 +147,224 @@ User → POST /console/api/functions/NAME/invoke
|
||||
|
||||
Причина: 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`
|
||||
|
||||
### Вывод
|
||||
|
||||
- Финальный набор теперь соответствует строгому критерию "однозначно работает и показывается".
|
||||
|
||||
Reference in New Issue
Block a user