Оновлення та відкат

Оновлення

З Docker Compose вкажіть KEPT_IMAGE у .env на новий реліз і:

docker compose pull
docker compose up -d

Власна збірка з робочої копії: git pull, docker build -t kept:local ., потім docker compose up -d з KEPT_IMAGE=kept:local.

Реліз може змінювати й compose.yaml; його примітки так повідомляють. Завантажте файл релізу поверх свого (curl -fsSLO https://raw.githubusercontent.com/keptinventory/kept/v<version>/compose.yaml, або compose.full.yaml, якщо ви запускаєте саме його); .env залишається як є.

Налаштування, що потребують новий compose.yaml

compose.yaml передає Kept лише ті налаштування, що в ньому названі, і ніяких інших. Оновлення до 1.14.5, яке змінює лише KEPT_IMAGE, залишає файл 1.14.4, що не передає KEPT_HTTP_SIGN_IN_DAYS чи KEPT_EXTRA_ADDRESSES і сам встановлює KEPT_TRUSTED_PROXIES. Рядки в .env нічого не роблять, доки ви не завантажите compose.yaml (або compose.full.yaml) версії 1.14.5 і не виконаєте docker compose up -d.

Caddy та Ollama перенесено до compose.full.yaml

Починаючи з 1.14.5, compose.yaml запускає лише Kept і його базу даних. Caddy (профіль https), Ollama (профіль ollama) та закоментоване розгортання розділеним способом — у compose.full.yaml: той самий файл плюс ці компоненти. Якщо ви використовуєте Caddy або Ollama, завантажте натомість compose.full.yaml і задайте COMPOSE_FILE=compose.full.yaml у .env:

curl -fsSLO https://raw.githubusercontent.com/keptinventory/kept/v<version>/compose.full.yaml
echo COMPOSE_FILE=compose.full.yaml >> .env
docker compose --profile https up -d   # the profiles you use: https, ollama or both

Інакше наступне завантаження compose.yaml прибере Caddy: Compose називає його контейнер осиротілим, і після його видалення Kept залишиться на звичайному http. Сервіси Kept, мережа та томи (сертифікати Caddy у caddy-data, моделі в ollama) в обох файлах однакові, тож нічого не втратиться. Без Caddy та Ollama змін немає.

За власним проксі KEPT_TRUSTED_PROXIES у .env доходить до Kept починаючи з 1.14.5. Раніше compose.yaml встановлював власне значення, тож рядок у .env ігнорувався, а всі відвідувачі ділили обмеження входу проксі. Значення вже наявне в .env почне діяти, щойно ви завантажите compose.yaml версії 1.14.5 (вище); значення з compose.override.yaml можна перенести до .env. З Caddy із compose.full.yaml залиште його порожнім або залиште 172.29.72.200 у списку (зворотні проксі).

Посилання для входу (1.14.0)

1.14.0 переводить Kept на better-auth 1.7.13, що виправляє вразливість, за якої стан входу OAuth можна було використати як чарівне посилання для входу під іншим користувачем (GHSA-965c-763c-88jm). Чарівне посилання, надіслане поштою, або розпочатий вхід через Google чи OIDC до оновлення більше не працює: попросіть нове посилання або увійдіть знову.

Встановлення без клонування (1.13.0)

З 1.13.0 compose.yaml не потребує копії репозиторію і паролів бази даних: одноразовий сервіс bootstrap створює логіни при кожному запуску. Встановлення, зроблене раніше, працює як є: його п’ять рядків KEPT_DB_*_PASSWORD у .env використовуються як є (встановлення з версії до 1.13.0). Дві речі, які варто знати: порожній KEPT_IMAGE більше не будує робочу копію (він запускає реліз, який називає compose.yaml), а нічний резервний compose.override.yaml читає пароль власника з тому kept-owner, якщо .env більше не містить його (резервні копії).

Одноразовий сервіс migrate запускає kept migrate першим: міграції застосовуються один раз, під блокуванням бази даних, до того як нова версія обслуговує запит. Міграції Kept лише додають (стовпець чи таблиця видаляються або перейменовуються лише через два релізи), тож попередня версія все ще працює на новій схемі, і саме це робить можливим повернення.

Прочитайте примітки до релізу перед великою версією (1.x до 2.0).

Образ перемістився (1.8.0)

З 1.8.0 образ — ghcr.io/keptinventory/kept, а чарт — oci://ghcr.io/keptinventory/charts/kept. Релізи до 1.7.1 залишаються в ghcr.io/ibrahimroshdy/kept і не отримують нових версій. Для оновлення раз змініть назву образу:

Compose: KEPT_IMAGE=ghcr.io/keptinventory/kept:1.8.0.
Helm: image.repository: ghcr.io/keptinventory/kept, або встановіть чарт за новою адресою.

Ключ підпису той самий, тож cosign verify --key cosign.pub ghcr.io/keptinventory/kept:<version> працює як раніше (Перевірити реліз).

Дізнатися, що є нова версія

Kept може перевіряти наявність нових версій, і за замовчуванням це вимкнено. Якщо увімкнено, він раз на день запитує GitHub про останній реліз репозиторію, з якого зібрано його образ, надсилаючи лише запит (ні версії, ні ідентифікатора екземпляра). Нічого не завантажується і не встановлюється. KEPT_UPDATE_CHECK=true вмикає це і закріплює; false закріплює вимкнений стан.

Перемикач у Адмін → Реєстрація, під “Нові версії”. Адмін → Статус показує “Kept X доступна”, коли існує новіший реліз, а його Перевірити зараз запитує негайно.

Знімок перед кожним оновленням

Коли kept migrate знаходить незастосовані міграції в базі даних, що вже містить дані, і налаштовано ціль резервного копіювання, він спочатку робить знімок лише бази даних restic з тегом pre_upgrade. Якщо знімок не вдається, нічого не мігрується і команда зупиняється з причиною. Зберігаються останні 3 знімки перед оновленням.

Немає цілі резервного копіювання: Kept усе одно мігрує, голосно логує це, а Адмін → Статус показує, що було “оновлено без резервної копії”, доки не буде наступної успішної резервної копії.
KEPT_UPGRADE_SNAPSHOT=off (або kept migrate --skip-snapshot) спеціально пропускає його.
Додаток Home Assistant ніколи не робить знімка: резервна копія Home Assistant перед оновленням — це шлях назад.
Цілком нова база даних ніколи не робить знімка.

Щоб це працювало, сервіс migrate потребує ключів і налаштувань резервного копіювання, а також логіна власника. Файл Compose дає йому всі три; ціль-директорія також потребує свого монтування на migrate (резервні копії).

Повернення на одну версію

Щоб відкотитися, знову запустіть образ попереднього релізу: поверніть KEPT_IMAGE до старого тега, потім docker compose up -d. Зворотних міграцій немає; попередня версія працює на новішій схемі.

Kept записує міграції кожного релізу в базі даних і перевіряє при запуску:

база даних на один реліз попереду від образу: Kept запускається, а Адмін → Статус показує, що було відкочено з X;
на більше ніж один реліз попереду, або попереду міграціями, яких жоден записаний реліз не робив: Kept відмовляється запускатися (downgrade_refused) і називає обидві версії. Це момент, щоб відновити знімок перед оновленням. KEPT_ALLOW_DOWNGRADE=1 примусово запускає, і примус фіксується в аудиті.

Від 1.14.4 назад до 1.14.3: карта 1.14.3 має мінімум 1 м. Кімната зі стороною менше 1 м зберігає свій розмір, доки хтось не натисне Готово в Упорядкувати, що зберігає її за 1 м (або відмовляє, якщо це робить її перетин з наступною кімнатою). Щоб зберегти ці розміри, не упорядковуйте карту, доки не повернетесь на 1.14.4.

Великі оновлення Postgres

Файл Compose Kept закріплює Postgres 18 за дайджестом, і його оновлення залежностей ніколи не пропонують перехід на нову велику версію. Нова велика версія — це дамп і відновлення, аж ніяк не зміна тега на наявному томі (файли даних однієї великої версії не відкриваються в іншій):

Зробіть резервну копію і дайте їй завершитись: docker compose run --rm --no-deps --entrypoint kept kept admin backup.
Зупиніть Kept: docker compose stop kept.
Змініть образ db на нову велику версію на новому томі (перейменуйте kept-db у compose.yaml або відсуньте старий); тримайте старий том, доки не завершите.
docker compose up -d db: скрипт ініціалізації створює ролі та розширення в порожній базі даних.
Відновіть резервну копію в неї, потім docker compose up -d.

Образ Kept містить клієнтські інструменти великої версії Postgres, яку він підтримує, і процедура відновлення перевіряє їх відповідність серверу.