Czy wiedziałeś, że po użyciu klasycznej składni w dockerze “:latest”, chcąc zainstalować najnowszą wersję, to w przypadku Authentika kończy się instalacją wersji praktycznie sprzed roku? Ja też nie, boleśnie się o tym przekonałem gdy konfigurowałem to narzędzie na swoim labie.

Po co w ogóle mi Authentik?

Odpowiedź jest prozaiczna, po prostu perspektywa zintegrowanego środowiska do logowania jawiła mi się jako coś かっこいい i jako coś, co sprawi, że mój lab będzie wyglądał bardziej profesjonalnie. I to tyle, nie ma w tym żadnej głębi.

Jaki jest problem?

Po instalacji dosyć szybko uzmysłowiłem sobie, że używanie wersji sprzed ponad roku w perspektywie czasu może przysporzyć mi problemów i nie jest najlepszym pomysłem, więc zacząłem interesować się aktualizacją.

Po podejrzeniu oficjalnego pliku docker-compose.yml podmieniłem linijkę “image” na taką, która instaluje konkretną wersję

image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.2.2}

Nawiasem mówiąc, pierwszy raz spotkałem się z takim rozwiązaniem, że dopisek :latest nie instaluje najnowszej wersji. Może jest to podyktowane bezpieczeństwem i zmuszeniem użytkowników do bardziej świadomych aktualizacji…?

Uruchomiłem docker compose pull, w celu zaktualizowania obrazu i…. tutaj zaczęły się problemy. Popełniłem dwa karygodne błędy:

  1. Nie zrobiłem backupu przed puszczeniem aktualizacji (rookie mistakes…)
  2. Nie zajrzałem do oficjalnej dokumentacji, żeby zorientować się, czy nie ma jakiś specjalnych zaleceń odnośnie aktualizacji… a tutaj były. Authentik w swojej oficjalnej dokumentacji jasno wskazuje, żeby najpierw aktualizować do najnowszej wersji danej wersji major.minor i iść wersjami po kolei.

Upgrade sequence: Upgrades must follow the sequence of major releases; do not skip directly from an older major version to the most recent version.

Always upgrade to the latest minor version (.x) within each major.minor version before upgrading to the next major version. For example, if you’re currently running 2025.2.1, upgrade in the following order:

  1. Upgrade to the latest 2025.2.x.
  2. Then to the latest 2025.4.x.
  3. Finally to the latest 2025.6.x.

Jak już możecie się domyślić, aktualizacja z 2025.2 do 2026.2 od razu, bez aktualizacji pośrednich nie mogła skończyć się inaczej jak klęską.

Jaki był efekt?

Z uwagi na to, że migracje w najnowszej wersji potrzebowały / opierały się na tabelach, które zostały dodane w wersjach pośrednich, postgresql zaczął sypać mi masę błędów — oczywiście sama aplikacja nie wstała.

Oto fragment logu, który pokazuje dokładnie o co chodziło — migracja authentik_core.0056_user_roles z nowszej wersji próbuje odwołać się do pola group_id na modelu Role, którego w moim schemacie bazy nie było:

authentik-server  | === Starting migration
authentik-server  | Operations to perform:
authentik-server  |   Apply all migrations: auth, authentik_blueprints, authentik_brands,
authentik-server  |   authentik_core, authentik_crypto, authentik_endpoints, [...]
authentik-server  | Running migrations:
authentik-server  |   Applying authentik_core.0056_user_roles...
authentik-server  |
authentik-server  | Traceback (most recent call last):
authentik-server  |   File "/authentik/core/migrations/0056_user_roles.py", line 76,
authentik-server  |     in migrate_object_permissions
authentik-server  |     role = get_role_for_group_id(group_id)
authentik-server  |   File "/authentik/core/migrations/0056_user_roles.py", line 30,
authentik-server  |     in get_role_for_group_id
authentik-server  |     role = Role.objects.using(db_alias).filter(group_id=group_id).first()
authentik-server  |   [... Django ORM stack ...]
authentik-server  | django.core.exceptions.FieldError: Cannot resolve keyword 'group_id'
authentik-server  |   into field. Choices are: ak_groups, initialpermissions, managed,
authentik-server  |   name, rolemodelpermission, roleobjectpermission, users, uuid
authentik-server  | {"error":"exit status 1","event":"gunicorn process died, restarting",
authentik-server  |   "level":"warning","logger":"authentik.router"}
authentik-server  | {"error":"exit status 1","event":"gunicorn failed to start, restarting",
authentik-server  |   "level":"error","logger":"authentik.router"}

Gdy zrozumiałem, co się stało, cofnąłem wersję do 2025.2 i chciałem zrobić to po bożemu, czyli aktualizować wedle zaleceń Authentika — niestety było na to za późno. Z każdą aktualizacją postgres komunikował masę niezgodności / brakujących tabel w bazie danych. Próbowałem naprawiać problemy na bieżąco, tzn. odpowiadać na dane komunikaty, które aktualnie pojawiały się na ekranie, ale nawet gdy udało mi się przejść o jedną wersję do przodu, to z każdą kolejną było tylko gorzej. Baza danych była już tak zdewastowana, że nie pozostało mi nic innego jak uderzyć się w pierś i postawić całego Authentika na nowo. Na moje szczęście, miałem na tamtym etapie skonfigurowane dosłownie kilka proxy auth oraz maksymalnie 2 oAuth. Cofnąłem się do wersji początkowej, jakoś udało mi się na “trytytkach” spiąć tę bazę danych i zalogować do panelu. Zrobiłem zrzuty ekranu tego, co miałem skonfigurowane, a następnie wysadziłem cały folder z danymi w powietrze.

Co robić i jak żyć?

Czytaj zawsze dokumentację. Jeżeli wydaje Ci się, że coś wiesz, to poświęć te 3 minuty, żeby się upewnić co do kroków, jakie chcesz podjąć. W tym przypadku problem nie był makabryczny, na szczęście wszystko działo się w zasadzie niedługo po tym jak po raz pierwszy skonfigurowałem Authentika, ale wyobraź sobie, gdyby to był serwis krytyczny w jakiejś firmie… Aż ciary przechodzą. No i backupy!!! Teraz już wersjonuję swoje pliki docker-compose w repozytorium, oraz wszystkie pliki konfiguracyjne codziennie lecą rclonem do chmury, ale serio — nie zaniedbujcie tego, bo mogą być z tego problemy.

Smacznej kawusi, Kuba