[Symfony4 / Docker] Class 'App\Kernel' not found

[egonolieux]

Ik ben een Symfony 4 app aan het migreren naar Docker, maar dit verloopt helaas niet zonder problemen. Ik maak gebruik van de php:7.2-fpm image waarin ik Nodejs en nog een aantal PHP extensions installeer.

code:

USER tcgcollector

WORKDIR /var/www/tcgcollector

# Run NPM.
COPY --chown=tcgcollector:tcgcollector ./package* ./
RUN npm install && npm cache clean --force

# Run Composer.
COPY --chown=tcgcollector:tcgcollector ./composer* ./symfony.lock ./
RUN composer install --prefer-dist --optimize-autoloader --classmap-authoritative --no-dev --no-scripts \
    && composer clear-cache

COPY --chown=tcgcollector:tcgcollector . .

# Install assets.
ENV APP_ENV=prod
RUN php ./bin/console fos:js-routing:dump --format=json --target=./assets/routes.json \
    && npm run gulp -- dist \
    && php ./bin/console assets:install

In dit bovenstaande deel van de Dockerfile, kopieer ik de source naar de image en installeer ik alle nodige dependencies. Het loopt echter fout bij het laatste stuk waar ik een aantal Symfony console commands wil uitvoeren om assets te installeren.

Bij het uitvoeren van de Symfony console (bin/console), krijg ik volgende foutmelding:

code:

Step 16/24 : RUN php ./bin/console fos:js-routing:dump --format=json --target=./assets/routes.json     && npm run gulp -- dist     && php ./bin/console assets:install
 ---> Running in 447a8150e290

Fatal error: Uncaught Error: Class 'App\Kernel' not found in /var/www/tcgcollector/bin/console:37
Stack trace:
#0 {main}
  thrown in /var/www/tcgcollector/bin/console on line 37

Dit is raar, want na inspectie in de container is te zien dat de App namespace aanwezig is in vendor/composer/autoload_psr4.php, zoals geconfigureerd in composer.json:

code:

    "autoload": {
        "psr-4": {
            "App\\": "./src/"
        }
    }

Het bin/console bestand is onaagepast en is exact hetzelfde als deze: https://github.com/symfon...y/console/3.3/bin/console. Ook al wordt op regel 12 het autoload bestand geimporteerd, kan de App\Kernel class niet gevonden worden.

[Voor 6% gewijzigd door egonolieux op 24-10-2018 07:53]

[DynaSpan]

Heb je ook gekeken of Kernel bestaat in de map ./src/?

[ACM]

De hele App-map is vervallen in Symfony 4, zie hun upgrade-documentatie:
https://github.com/symfon...lob/master/UPGRADE-4.0.md

egonolieux schreef op woensdag 24 oktober 2018 @ 07:48:
Het bin/console bestand is onaagepast en is exact hetzelfde als deze: https://github.com/symfon...y/console/3.3/bin/console. Ook al wordt op regel 12 het autoload bestand geimporteerd, kan de App\Kernel class niet gevonden worden.

Je verwijst hier naar een 3.3-versie... niet handig met 4

[Voor 62% gewijzigd door ACM op 24-10-2018 08:36]

[egonolieux]

ACM schreef op woensdag 24 oktober 2018 @ 08:35:
De hele App-map is vervallen in Symfony 4, zie hun upgrade-documentatie:
https://github.com/symfon...lob/master/UPGRADE-4.0.md


[...]

Je verwijst hier naar een 3.3-versie... niet handig met 4

Symfony 3.3 is eigenlijk praktisch exact hetzelfde als Symfony 4 under the hood, alleen is Symfony 4 met het nieuwe flex systeem. Symfony 4 gebruikt wel degelijk dit bestand, het werd geinstalleerd via skeleton/flex op een nieuwe 4 installatie.

Waar jij het over hebt is de app map, die bestaat inderdaad niet meer. Maar als je goed kijkt, gaat het hier om de App namespace, welke in eerdere Symfony 3 versies AppBundle was trouwens .

In de link die je me geeft, zeggen ze ook dat je bin/console moet vervangen door de nieuwe console.
De link die dan naar het nieuwe console bestand verwijst, is exact dezelfde als de link die ik hier poste.

DynaSpan schreef op woensdag 24 oktober 2018 @ 08:20:
Heb je ook gekeken of Kernel bestaat in de map ./src/?

Kernel.php is aanwezig in ./src/

[Voor 10% gewijzigd door egonolieux op 24-10-2018 09:06]

[ACM]

En werkt dat relatieve pad wel? Kan zijn dat daar wat gedoe mee ontstaat of dat ie 'expanded' wordt in de autoload-files voor jij e.e.a. naar docker kopieert en het daar dan niet meer werkt.

[Cartman!]

Waarom heb je "src" aangepast naar "./src" ? Wat heeft composer daar precies van gemaakt in je vendor/composer/autoload_psr4.php file ?

[egonolieux]

Ik had zelf manueel de autoload bestanden al eens overlopen, en de gegenereerde paden zijn correct.
Ik heb persoonlijk de conventie mijn relatieve paden altijd met de huidige directory te beginnen, en heb de paden onder autoload aangepast om ze consistent te houden met een aantal paden die bij scripts staan. Zou niets mogen uitmaken.

Ik heb wat verder geëxperimenteerd en nu blijkt dat als ik `dump-autoload` doe in hetzelfde `RUN` statement als de scripts, dat het werkt zonder problemen:

code:

USER tcgcollector

WORKDIR /var/www/tcgcollector

# Run NPM.
COPY --chown=tcgcollector:tcgcollector ./package* ./
RUN npm install && npm cache clean --force

# Run Composer.
COPY --chown=tcgcollector:tcgcollector ./composer* ./symfony.lock ./
RUN composer install --prefer-dist --no-dev --no-scripts && composer clear-cache

COPY --chown=tcgcollector:tcgcollector . .

# Install assets.
ENV APP_ENV=prod
RUN composer dump-autoload --optimize --classmap-authoritative --no-dev --no-scripts \
    && php ./bin/console fos:js-routing:dump --format=json --target=./assets/routes.json \
    && npm run gulp -- dist \
    && php ./bin/console assets:install

Het rare is dat het uitvoeren van de composer scripts in de draaiende container dan weer hetzelfde probleem geeft? Het is net alsof het dumpen van de autoload op geen enkele manier persisted wordt tijdens build-time. Hoewel als ik binnen de container met `docker exec` kijk, dan zijn de autoload bestanden aanwezig. Als ik vervolgens binnen de draaiende container de autoload dump, werkt het zonder problemen.

Ik heb ondertussen in ieder geval de `dump-autoload` naar een runtime `docker-entrypoint.sh` verhuisd omdat ik problemen had met een aantal composer scripts die environment variables nodig hadden die enkel tijdens runtime beschikbaar zijn. Met deze noodzakelijke verandering heb ik dus eigenlijk rond het probleem gewerkt.

Maar wat kan de reden van dit probleem zijn? Misschien dat een diff tussen de build- en runtime autoload bestanden iets zegt?

[Voor 10% gewijzigd door egonolieux op 30-10-2018 20:23]