feat(iot): деплой IoT MVP — Dockerfile, RBAC, EMQX fix, operator v0.1.50, mqtt-bridge, doc/iot
This commit is contained in:
Naeel
@@ -571,3 +571,111 @@ IoT event consumer → [interface] → POST → function
|
||||
3. Kafka deployment: managed или Strimzi
|
||||
|
||||
Всё. Наш IoT-оператор, CRD, device auth — не меняются вообще.
|
||||
|
||||
---
|
||||
|
||||
## Агент: GitHub Copilot (Claude Sonnet 4.6) — ДЕПЛОЙ IoT MVP
|
||||
|
||||
### Задача от пользователя
|
||||
Запустить всё. Документировать мысли и инженерную часть подробно.
|
||||
|
||||
### Анализ ситуации перед деплоем
|
||||
|
||||
**Что есть в git (ветка Ioter, коммиты 716efaf + 1e53766 + b920dc5):**
|
||||
- CRD IoTDevice (iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml) — готово, не задеплоено
|
||||
- IoT controller + IoT API handlers — в бинаре `manager`, НО образ не пересобран (v0.1.49 = без IoT)
|
||||
- EMQX YAML (deployments/k8s/emqx.yaml) — готово, не задеплоено
|
||||
- iot-mqtt-bridge YAML (deployments/k8s/iot-mqtt-bridge.yaml) — готово, не задеплоено
|
||||
- mqtt-bridge бинарь (iot/cmd/mqtt-bridge/main.go) — есть код, но НЕ в образе
|
||||
|
||||
**Критические блокеры:**
|
||||
|
||||
1. **Dockerfile не включает `iot/`** — оператор собирается без IoT кода. Нет, стоп.
|
||||
После проверки: iot/api включается через импорты в main.go — Go компилятор тянет весь нужный код.
|
||||
НО: Dockerfile копирует только `main.go api/ controllers/ internal/ migrations/`.
|
||||
IoT код живёт в `iot/` — и этот каталог НЕ копируется в Dockerfile!
|
||||
Значит: `go build -o manager main.go` внутри Docker упадёт — не найдёт пакеты `iot/api/v1alpha1`, `iot/controllers/`.
|
||||
|
||||
2. **mqtt-bridge бинарь** — отдельная точка входа `iot/cmd/mqtt-bridge/main.go`.
|
||||
В текущем Dockerfile собирается только `manager`. Нужно добавить сборку `iot-mqtt-bridge`.
|
||||
|
||||
3. **iot-mqtt-bridge.yaml** использует образ оператора (`sless-operator:latest`) с командой `/iot-mqtt-bridge`.
|
||||
Значит оба бинаря должны быть в одном образе. Это правильный подход — один образ, разные entrypoint.
|
||||
|
||||
**Порядок действий (решение):**
|
||||
|
||||
```
|
||||
1. Обновить Dockerfile:
|
||||
- Добавить COPY iot/ iot/
|
||||
- Добавить RUN go build -o iot-mqtt-bridge iot/cmd/mqtt-bridge/main.go
|
||||
- Добавить COPY --from=builder /workspace/iot-mqtt-bridge .
|
||||
|
||||
2. Обновить operator.yaml: тег v0.1.49 → v0.1.50
|
||||
|
||||
3. SSH: docker build + push v0.1.50
|
||||
|
||||
4. kubectl apply CRD IoTDevice (один раз, cluster-wide)
|
||||
|
||||
5. kubectl apply EMQX (EMQX deployment + svc + configmap)
|
||||
|
||||
6. kubectl apply operator v0.1.50 (подхватит IoT controller + IoT API)
|
||||
|
||||
7. Bootstrap mqtt-bridge:
|
||||
- Оператор должен быть живым (шаг 6)
|
||||
- Создать IoTDevice "iot-bridge" через API → контроллер сгенерирует Secret в namespace sless-bridge
|
||||
- Из Secret взять mqtt_username + mqtt_password
|
||||
- kubectl create secret generic iot-bridge-credentials -n sless
|
||||
- kubectl apply iot-mqtt-bridge.yaml
|
||||
|
||||
8. Проверка end-to-end
|
||||
```
|
||||
|
||||
**Риски и как их обходить:**
|
||||
|
||||
- `sless-bridge` namespace может не существовать → создать заранее через kubectl
|
||||
- EMQX может быть не готов к моменту запуска bridge → bridge сам делает retry (в коде есть reconnect loop)
|
||||
- IoT API требует JWT-токен → при bootstrap curl с токеном из sless-operator-secret
|
||||
|
||||
**Почему один образ для operator + bridge:**
|
||||
Это не идеально с т.з. SRP, но практично:
|
||||
- Не нужен отдельный CI pipeline
|
||||
- Не нужен отдельный registry repo
|
||||
- Bridge — простой процесс (~100 строк Go), не нагружает образ
|
||||
- В будущем можно разделить, порог изменений низкий
|
||||
|
||||
**Итог по мышлению:** Plan is solid. Начинаю выполнение.
|
||||
|
||||
### Проблемы, найденные при выполнении (до → решение)
|
||||
|
||||
**Проблема 1 — RBAC не настроен для iot.kube5s.ru:**
|
||||
- Попытка создать IoTDevice через API → 403 Forbidden
|
||||
- `sless-operator` ServiceAccount не имел прав на `iotdevices.iot.kube5s.ru`
|
||||
- Причина: CRD для IoT — новая API-группа, в rbac.yaml её не было
|
||||
- Решение: добавил в ClusterRole правила на `iot.kube5s.ru` (get/list/watch/create/update/patch/delete + status + finalizers)
|
||||
- `kubectl apply -f rbac.yaml` → configured
|
||||
- Вывод: при добавлении нового CRD API group ВСЕГДА нужно обновлять ClusterRole
|
||||
|
||||
**Проблема 2 — EMQX 5.x требует обязательные поля node.cookie и node.data_dir:**
|
||||
- EMQX CrashLoopBackOff с ошибкой: `required_field: node.cookie, node.data_dir`
|
||||
- В нашем emqx.conf (HOCON) эти поля отсутствовали — думал что для single-node они необязательны
|
||||
- На самом деле в EMQX 5.x они mandatory (в отличие от 4.x где были defaults)
|
||||
- Решение: добавил `node {}` секцию: name=emqx@127.0.0.1, cookie=sless-emqx-cookie-mvp, data_dir=/opt/emqx/data
|
||||
- kubectl apply обновил ConfigMap, rollout restart → EMQX поднялся
|
||||
- Вывод: при обновлении ConfigMap Deployment не перезапускается автоматически — нужен `kubectl rollout restart`
|
||||
|
||||
**Проблема 3 — kubectl logs берёт старый (crashing) pod:**
|
||||
- deployment/emqx — логи шли со старого пода в CrashLoopBackOff
|
||||
- Нужно указывать pod name явно для нового пода
|
||||
- Это нормальное поведение kubectl — нет флага "новый pod"
|
||||
|
||||
### Итоговый статус деплоя
|
||||
|
||||
```
|
||||
emqx-6f9689fc99-4mbhr 1/1 Running ✅
|
||||
iot-mqtt-bridge-7d784d7d6b-n45fp 1/1 Running ✅ (3 restarts — reconnect loop до старта EMQX)
|
||||
sless-operator-579dd6dcd5-fk2n8 1/1 Running ✅
|
||||
```
|
||||
|
||||
CRD применён: `iotdevices.iot.kube5s.ru created`
|
||||
IoTDevice iot-bridge создан: phase=Active, credentials в secret iot-iot-bridge
|
||||
Secret iot-bridge-credentials создан в namespace sless
|
||||
|
||||
Reference in New Issue
Block a user