Comportament ciudat docker

Salut,
De vreo cateva ore ma confrunt cu o problema destul de ciudata cu Docker.
Am facut o aplicate simpla cu Nuxt3 si vreau sa o duc spre productie impachetata in docker.
Aplicatia pe local functioneaza cum ar trebui dar nu si in docker.
De exemplu in Docker cand accesez aplicatia prima pagina la care ma duce este /login … pe desktop este / (root) .
Imaginea docker este facuta cu imaginea oficiala de node care are aceasi versiune de node (18.17) .
Daca fac o alta imagine docker cu fisierele generare pe local, deci doar le copiez noua imagine functioneaza ca pe local si cum ar trebui sa functioneze.
Toate testele astea m-au dus cu gandul ca “npm run build” genereaza un rezultat diferit daca este rulat din docker.
Aveti experiente de genul asta? Cum le-ati rezolvat?

In primul rand, daca folosesti imaginea de node care e bazata pe alpine, incearc-o pe cea bazata pe debian/ubuntu.

E posibil ca lipsa glibc pe alpine sa cauzeze diverse incompatibilitati.

Buildul de productie se face in 2 pasi. In primul pas pornesc de la node:18.17-bullseye ca sa generez fisierele si in al 2lea de la node:18.17-alpine .
Cand am facut testul cu copierea fisierelor de pe local le-am copiat intr-o imagine de node:18-alpine .
Pe mine ma duce cu gandul ca ceva la step 1 este o problema.

Local tu o sa ai NODE_ENV=development, cand posibil faci build-ul pentru productie setezi NODE_ENV=production. Nu stiu daca conteaza sau nu la nuxt.

E foarte usor sa testezi ce face dupa build, iei fisierele si il rulezi local. Incearca sa setezi NODE_ENV=production local si vezi ce face.

Poate default route nu e /login ci te duce acolo fiindca / e o ruta protejata si ai mock-uit userul pe development.

1 Like

Am dat cu NODE_ENV=production si nu schimba nimic.
Nu am mockuiti useri de dev . Testele sunt pornite din browsere in incognito mode …

Daca rulezi ceva linkuit cu glibc pe musl nu o sa iti mearga exact la fel. Yeah sure, in majoritatea cazurilor sunt compatibile, dar nu e musai.

1 Like

Ce ai in loguri la browser ? Un default behavior comun e să te redirecteze la login dacă ai o eroare în cod.

Poate ai un .env pe local care nu se copiază în container sau ceva de genul asta și cumva duce la diferența asta de comportament a aplicației.

Poți rula un container cu imaginea dinainte să faci build-ul în docker, copiezi sursele din ea pe local și faci tu build-ul pe local să vezi cum merge.

docker run -d --rm <id imagine>

docker cp <id container>:<cale> <cale locala>

1 Like

Nu. Nu am de asta. Am pus inclusiv console/log alert pe pagina de index si login si se duce tina pe login desi nu ar trebui.
Nu sunt erori sau ceva care sa-mi sara in ochi.

O idee interesanta. Nu am facut pe baza de container cum ai zis tu dar am lasat containerul de la pasul 1 si am rulat aplicatia in 2 moduri. Dupa debug si cu npm run dev.
Am observat ca aici amandoua au acelasi comportament , adica se duc automat pe la pagina de login. Inca nu am o explicatie …
Fisierul .env este. cel care se afla la mine la masina locala…

Salut,
Am gasit problema mea.
Modulul @nuxtjs/supabase a pus “redirect” pe true ca default option (daca utilizatorul nu este autentificat se duce pe login). Asta inseamna ca te duce mereu pe pagina de login. Urata treaba si a fost greu sa ii fac debug ca efectiv nu se vedea prin codul meu.

Ce am invatat din asta este ca poti sa pornesti dockerul si sa te docnectezi din vscode la el cu extensia de docker si sa modifici direct fisiere.

Ce inca nu inteleg si problema exista este de ce codul la mine de pe local pus in docker merge altfel ca ala builduit…

Efectiv am pierdut 5-6 ore pe un kkt :slight_smile:

1 Like

Poti instala un pachet fara sa fie adaugat in package.json.

5-6 ore e puțin, am pierdut și o săptămână sau mai mult pe lucruri de genul. Încă n-ai ajuns la CORS cu mai multe servicii și proxy pe Azure/AWS ca să chiar înnebunești la probleme simple.

Frustrarea e maxima cand cauti solutia si nu o gasesti si nu ai nici o explicatie si ramai fara idei… si slava domnului am idei.

Multumesc tuturor pt ajutor.