Make Docker logging to stderr the default

[pablothedude]

This will make logging to stderr the default.
Also documentation is added on how to add syslog config.
This will allow debugging in dev env (devonf) out-of-the-box.

[baszoetekouw]

Ziet er ok uit, maar lijkt me goed dat @quartje even er een blik op werpt. Ik zal iig voor onze deploy de handler terugzetten op syslog (zie OpenConext/OpenConext-deploy@443ea2f)

[baszoetekouw]

Lijkt me prima, zolang we in OpenConext-deploy de handler maar weer terugzetten op syslog (toch, @quartje ?)

[baszoetekouw]

Overigens (vraag voor @quartje denk ik): klopt het dat we in de dockers syslog gebuiken dan?

[quartje]

nee, daar wordt stdout gebruikt. Ik snap het probleem ook nog niet helemaal, want in de docker file wordt een logging.yml geplaatst:
https://github.com/OpenConext/OpenConext-engineblock/blob/main/docker/Dockerfile.prod#L16
Dat is deze:
https://github.com/OpenConext/OpenConext-engineblock/blob/main/docker/conf/logging.yml

Volgens mij was het probeem al opgelost dus

[pablothedude]

In de regel gebeuren configuratie verschillen met Symfony alleen met een afwijkende parameters.yml per omgeving. Ik had dus niet verwacht dat er nog een losse config overschreven zou worden (in dit geval de logging,yaml).
De aanpassing had ik gedaan omdat er in dev modus in devconf geprobeerd om naar syslog te loggen, dat leek dus nog een pre devconf oplossing. Dat werkte in development niet lekker en ook de console commando's loggen in devconf dan te veel naar stderr.

Vandaar dat ik een aanpassing had gedaan om of naar 'syslog' of naar 'docker' (stderr) te loggen. De vraag is nu even hoe er in productie wordt gelogd en of syslog dan nog wordt gebruikt. Want is die aparte logging.yaml dan nog nodig en zou dit dan niet gelost kunnen worden met alleen een afwijking in de parameters.yaml. Alleen als syslog dan nog nodig is tenminste.

Beter is het denk ik als ik die copy uit die prod dockerfile haal en de juiste config gewoon in de logging.yml aanpas zodat dezelfde in dev en prod worden gebruikt. Dus dat zal dan de versie worden zonder syslog maar met het uistluiten van sommige channels. Want ik denk dat daar dan geen verschil meer in zouden moeten zitten, m.u.v. het log level.

Dit zullen Symfony developers ook eerder verwachten en dus ook testen, wat bugs in de toekomst ook zal voorkomen.

[baszoetekouw]

Is er een reden om hier niet alle logging mee te nemen (zoals syslog ook doet)?

[baszoetekouw]

Oh, ik zie nu pas wat er gebeurt; de authentication logs gaan al direct naar syslog. Zou je die ook niet via de docker handler willen laten lopen dan?

[quartje]

Alles moet naar stdout zodat het opgepakt en doorgestuurd kan worden

[quartje]

I've left the default untouched, and I've included a seperate logging.yml in docker/conf/logging.yml which is copied to the container.
I assume you want the default also to work immediately when using a container. If that is the case this should work and not interfer with the prod container (as it is overwritten there)

[baszoetekouw]

If that is the case this should work and not interfer with the prod container (as it is overwritten there)

Ahh, I was looking for that, but the logging.yml is overwritten during container build, and not in the deploy. I'll revert my deploy-commit, as that is not necessary at all.

[pablothedude]

Thanks @quartje. It seems that I can also use the production configuration in development because only the log level will be different. The log level is already configurable in parameters.yml so we could use the same. I therefore removed the COPY from the prod docker image and I used that logging configuration as default configuration for logging and added some minor optimizations.

I discussed this also IRL with @baszoetekouw and we decided to use the logging to stderr as default and drop the syslog support. I however did add documentation for users of Engineblock on howto log to syslog.