Debian -> Docker -> Debian & Apache & PHP

[Anoniem: 80910]

Mijn vraag
...

Hoi ik ben bezig met een server te testen.

Mijn server bestaat uit een Debian 11 installatie. daarop is Docker geinstalleerd.

Mijn docker compose file installereert Debian 11.8.
Omdat Debian 11 geen php 8.2 kent installeer ik de sury packages:

RUN wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
RUN sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

RUN apt-get update && apt-get install apache2 \
php8.2 \
php8.2-fpm \
php8.2-common \
php8.2-mysqli \
php8.2-pdo \
php8.2-gd \
php8.2-intl \
php8.2-imap \
php8.2-sockets \
php8.2-opcache \
php8.2-mbstring \
php8.2-readline \
php8.2-curl \
php8.2-zip \
php8.2-xml \
libapache2-mod-fcgid -y

Ik gebruik geen init.d (nog niet) maar mijn eigen php script om de server draaiende te houden.
Nu lijkt dit in eerste instantie te werken en aardig stabiel ook.

Echter heb ik een Youtube script die elke seconden controleerd of er een bepaald bestand is aangemaakt en daarmee gaat het mis. Dit is met een javascript interval en doet elke keer een server request.
Ik dacht dat kan mijn systeem wel aan, maar blijkbaar niet. nu crashed ie na een tijdje, en hij crashed niet alleen in de docker image, ssh toegang doet het ook niet meer.
Wat resulteerd in harde reboots.
Ik heb ook een status gehad dat de php code raar ging doen en ik een maximum execution tijd error kreeg op een willekeurige plaats in mijn code (bij inloggen). Dit had ik nog willen onderzoeken in autoload logs om te kijken of ik kan zien of die inderdaad in een oneindige loop terecht komt, o.i.d.
Met als de php code raar begint te doen, had ik nog wel ssh inlog maar waren de log files te groot geworden (11 GB) om nog te door gronden (wellicht tail -n 50) of even een speciale debug log hiervoor aanmaken.

De Apache2 error log in /var/log/apache2/error.log bevat geen foutmeldingen hierover.
De custom Apache2 error log bevat geen foutmeldingen hierover
De access log laat niets raars zien.

De apache2 configuratie is als volgt:

Dir::create('/run/php');
a2enmod proxy_fcgi setenvif
a2enconf php8.2-fpm
a2dismod php7.4
a2dismod mpm_prefork
a2enmod mpm_event
a2enmod http2
a2enmod rewrite
a2enmod ssl
'. /etc/apache2/envvars'


Oftewel na verloop van tijd, wordt het de server qua request al te veel als ie continue een request krijgt om af te handelen. ik denk omdat de php execution time error optreed de php-pipes dicht komt te zitten en hij er daarna helemaal de brei aan geeft.

Iemand een idee hoe ik dit kan verbeteren, wellicht zonder docker proberen en kijken of ie het daarna beter volhoudt, of kan ik beter de maximum execution time probleem eerst zien op te lossen, want als elke request 30 seconden rekenen inhoudt zal dat wel mis gaan ?

Ik had al een logger op mijn autoload zitten, alleen verwees die naar het verkeerde bestand.
Heb inmiddels een debug.log aangemaakt waar de autoloader alleen naar toe logt.
Ben er inmiddels ook achter, waarom de request zo langzaam gaan. (De logger) en het kan ook maar zo zijn, dat de logger de app omzeep helpt. als de log niets wordt zet ik hem ff uit en kijken of ie dan nog crashed...


...

[ Voor 6% gewijzigd door Anoniem: 80910 op 08-11-2023 07:16 . Reden: update ]

[DaFeliX]

Het is wat lastig zo te controleren wat er precies mis gaat, maar ik betwijfel of het ligt aan de execution time van php. Die zou juist eventuele problemen voorkomen door processen te stoppen die anders te lang duren. Het is niet zo dat php zelf uit gaat na die 30 seconden.
Verder lijkt het mij ook niet zo dat de docker-image je hostserver laat crashen, ik bedoel, het zou kunnen maar logischer lijkt het mij dat je het onderzoek vooral eerst moet richten op de host. Dus controleer de syslog e.d. van je host 'ns of je daar wat raars ziet.

Je zegt "crasht" de server en harde reboots, maar welke van deze twee is het nu?

En wat is "verloop van tijd", gaat dit om een vaste interval of is het willlekeurig? Verder, weet je zeker dat dit komt door het script? Wat als je de server een tijdje laat draaien zonder de container/script?

NB: Er is een PHP docker image beschikbaar, je hoeft dus niet in een container zelf PHP te installeren.

[Anoniem: 80910]

DaFeliX schreef op woensdag 8 november 2023 @ 07:19:
Het is wat lastig zo te controleren wat er precies mis gaat, maar ik betwijfel of het ligt aan de execution time van php. Die zou juist eventuele problemen voorkomen door processen te stoppen die anders te lang duren. Het is niet zo dat php zelf uit gaat na die 30 seconden.
Verder lijkt het mij ook niet zo dat de docker-image je hostserver laat crashen, ik bedoel, het zou kunnen maar logischer lijkt het mij dat je het onderzoek vooral eerst moet richten op de host. Dus controleer de syslog e.d. van je host 'ns of je daar wat raars ziet.

Je zegt "crasht" de server en harde reboots, maar welke van deze twee is het nu?

En wat is "verloop van tijd", gaat dit om een vaste interval of is het willlekeurig? Verder, weet je zeker dat dit komt door het script? Wat als je de server een tijdje laat draaien zonder de container/script?

NB: Er is een PHP docker image beschikbaar, je hoeft dus niet in een container zelf PHP te installeren.

ik heb die container een keer eerder getest en ben er van afgestapt en debian als basis gekozen. ik kan ook nog upgraden naar debian 12 en kijken of het dan goed gaat.

ssh inlog naar het hoofdsysteem werkt dan niet meer en moet ik middels de power knop het systeem rebooten.
ik zal zo de syslog bekijken (ik kan het reproduceren en naar verloop van tijd (kan een paar uur duren) weet de tijd niet exact.
Als ik de Youtube actie niet uitvoer (geen javascript interval met server request initieer) blijft het systeem stabiel. als ik de interval op tijd stop is er ook geen server crash...

[Rensjuh]

Als je het script handmatig aftrapt, werkt het dan wel?
En is het script ook echt binnen die 1 seconde klaar?
Kan me voorstellen dat als dat script niet klaar is binnen, die 1 seconde, maar wel weer afgetrapt word de server het op een gegeven moment ook begeeft...

Misschien moet je het script eens wat minder vaak laten draaien?
Probeer het eens met iedere 10 of 30 seconden een keer?

[Anoniem: 80910]

Rensjuh schreef op woensdag 8 november 2023 @ 07:25:
Als je het script handmatig aftrapt, werkt het dan wel?
En is het script ook echt binnen die 1 seconde klaar?
Kan me voorstellen dat als dat script niet klaar is binnen, die 1 seconde, maar wel weer afgetrapt word de server het op een gegeven moment ook begeeft...

Misschien moet je het script eens wat minder vaak laten draaien?
Probeer het eens met iedere 10 of 30 seconden een keer?

[DaFeliX]

Anoniem: 80910 schreef op woensdag 8 november 2023 @ 07:25:
[...]

Als ik de Youtube actie niet uitvoer (geen javascript interval met server request initieer) blijft het systeem stabiel. als ik de interval op tijd stop is er ook geen server crash...

Je hebt dus fysieke toegang tot de server? Log dan 'ns in op de TTY console ipv via SSH in te loggen; krijg je daar niet de output te zien wat er mis is met de server?

[Anoniem: 80910]

DaFeliX schreef op woensdag 8 november 2023 @ 07:30:
[...]


Je hebt dus fysieke toegang tot de server? Log dan 'ns in op de TTY console ipv via SSH in te loggen; krijg je daar niet de output te zien wat er mis is met de server?

Goeie nog niet aan gedacht, wacht ik daar ff op...

[luukvr]

Kan het misschien zijn dat je memory overloopt?=

Debian heeft harddisk caching en Docker heeft standaard variabel gebruik van memory. Dat is vaak een slechte combinatie omdat de Docker omgeving eindeloos memory slurpt van de server waardoor hij uiteindelijk alles inneemt en de server zijn eigen services niet meer fatsoenlijk kan draaien. Heb zelf vaker dat soort problemen gehad en opgelost door een limiet te zetten op hoeveel memory de Docker-omgeving mag gebruiken dan gaat hij binnen die omgeving eerst z'n hd caching gebruiken i.p.v. steeds maar meer memory vragen.

[Anoniem: 80910]

Anoniem: 80910 schreef op woensdag 8 november 2023 @ 07:37:
[...]

Goeie nog niet aan gedacht, wacht ik daar ff op...

@DaFeliX helaas scherm blijft zwart (wel aan, tv gaat niet naar standby)

ssh geeft:
ssh: connect to host 10.0.0.10 port 22: No route to host

ctrl-alt 2 - 3 - 4 geeft geen nieuwe tty

Memory geloof ik niet in: 96 GB available, 1x zo'n script aanroepen kost geloof ik tussen de 10 en 20 MB / request, maar als ie achter gaat lopen doet een interval heel naar, en blijft alles op pending staan.

Daarnaast heb ik php nog default staan met workers, dat is 1x hoofd process en 2x workers uit mijn hoofd. het staat nog ff na te pruttelen in de hoop het een ddos is momenteel, maar ik vind het vreemd dat het systeem met 16 threads down gaat op 2 processen.


welke logs van het systeem zijn interessant om in te zien in zo'n geval, het is debian 12
@ 2 uur later...
Heb net ff in mijn router gekeken naar attached devices, staat er niet meer tussen.
lekker scriptje gemaakt dus om de systeembeheerders een knopje te laten indrukken.
het deed dus 2 requests per seconde slechts om dit uit te voeren met een interval...

Heb de log files bekeken en na 1 uur vanmiddag deed ie het niet meer, iets meer dan 7 uur dus. logt niets, valt uit het netwerk, echt harde reset nodig.

Is er een manier van memory loggen beschikbaar of moet ik zelf wat schrijven en in een cron wegschrijven naar disk om te kijken of toch de memory vol loopt ?

[ Voor 62% gewijzigd door Anoniem: 80910 op 08-11-2023 18:33 . Reden: mention ]

[Hero of Time]

Syslog server. Dat is waar je naar op zoek bent.

Maar is het echt wel verstandig om een site elke seconde aan te tikken? Dat riekt namelijk enorm naar DoS praktijken. En als je een script zo hebt gemaakt dat er niet eens gekeken wordt of er nog iet draait en stopt als dat zo is, is het ook niet echt een goed script. De boel in een queue dumpen is compleet kansloos, want als het niet zou hoeven wachten heb je ook geen queue nodig. Een file gaat nooit opgelost worden als er 10 auto's bij komen en maar 3 weg kunnen.

[Anoniem: 80910]

Hero of Time schreef op woensdag 8 november 2023 @ 19:23:
Syslog server. Dat is waar je naar op zoek bent.

Maar is het echt wel verstandig om een site elke seconde aan te tikken? Dat riekt namelijk enorm naar DoS praktijken. En als je een script zo hebt gemaakt dat er niet eens gekeken wordt of er nog iet draait en stopt als dat zo is, is het ook niet echt een goed script. De boel in een queue dumpen is compleet kansloos, want als het niet zou hoeven wachten heb je ook geen queue nodig. Een file gaat nooit opgelost worden als er 10 auto's bij komen en maar 3 weg kunnen.

@Hero of Time maar een syslog server zit toch standaard ingebakken in linux ? zijn die syslog servers niet een webschil om de log file heen, of loggen die ook meer informatie ?

ik heb alle logs bekeken en kwam wel tegen dat er iets wordt geblokkeert in de firewall
[UFW BLOCK] IN=enp2s0 OUT= MAC=[redacted] SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

maar dat is het multicast adres volgens google.

syslog met tail -n 1750 tot het einde gekomen van de vorige sessie en het houdt gewoon op te loggen zonder specifieke melding. het hele systeem crashed gewoon zonder foutmelding.

Bash:

2023-11-08T13:17:01.378275+00:00 vps2 CRON[3547073]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2023-11-08T13:17:59.278619+00:00 vps2 kernel: [29202.829579] [UFW BLOCK] IN=enp2s0 OUT= MAC=01:00:5e:00:00:01:b0:39:56:e3:2b:98:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
2023-11-08T13:20:04.720922+00:00 vps2 kernel: [29328.272386] [UFW BLOCK] IN=enp2s0 OUT= MAC=01:00:5e:00:00:01:b0:39:56:e3:2b:98:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
2023-11-08T15:50:14.687440+00:00 vps2 systemd-pstore[406]: PStore dmesg-efi-169944968531001 moved to /var/lib/systemd/pstore/169944968/dmesg-efi-169944968531001
2023-11-08T15:50:14.687502+00:00 vps2 systemd-pstore[406]: PStore dmesg-efi-169944968530001 moved to /var/lib/systemd/pstore/169944968/dmesg-efi-169944968530001
2023-11-08T15:50:14.687515+00:00 vps2 kernel: [    0.000000] Linux version 6.1.0-13-amd64 ([e-mail]) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
2023-11-08T15:50:14.687520+00:00 vps2 systemd-pstore[406]: PStore dmesg-efi-169944968529001 moved to /var/lib/systemd/pstore/169944968/dmesg-efi-169944968529001

ik wil de systematiek wel ff toelichten op dit moment:

youtube is een admin/root task geworden in mijn systeem. zo'n admintask maakt dan een bepaald aantal bestanden aan. 1 daarvan is een ".end" bestand als ie klaar is met de task.
Wat het script doet op het moment is pollen met een interval of zo'n ".end" bestand bestaat met jwt (json web token techniek) en hierdoor moet het script eerst door authenticatie heen. dit duurt samen even en duurt gemiddeld zo'n 500 msec per request.

Nu weet ik niet of php-fpm er standaard meer workers bij maakt als ie het druk krijgt, als dat niet het geval is, kan ik mij voorstellen dat wanneer het langer dan 1 seconden duurt en je 2 workers hebt, dat dit mis kan gaan. wat er daarnaast mis gaat heb ik gezien is dat requests eerst naar een andere status gaan: er treed een maximum execution time error op en het lijkt erop dat dit gebeurt bij het inlezen van de configuratie. dit wilde ik met een Logger meten in de autoload.
Echter duurt het script laden dan langer omdat ie voor het loggen mijn app opnieuw instantieert momenteel en lijkt het zo'n 6 uur goed te gaan en daarna crashed.

Wat ik had verwacht is dan dat mijn, apache2, php8.2-fpm opnieuw moet opstarten en dan opgelost. Nu crashed via docker (met standaard rechten) de hele pc. Nu kan ik ff een vm starten en kijken of ie daar ook op crashed.

De server is een I7 8 core 16 thread 96 GB ram systeem. Waar ik op z'n minst wel 2 request per seconde verwacht te kunnen verwerken. het draait op een ssd.

De interval verhogen kan natuurlijk altijd, nu kom ik maar tot de 50.000 requests en het hangt, hieronder een screeenshot van zo'n interval test van 1 seconden

Bash:

 490117 www-data  20   0  251596  38444  29116 S   6.6   0.0  12:18.89 php-fpm8.2
 757559 www-data  20   0  251600  38396  29108 S   6.6   0.0  10:36.17 php-fpm8.2
2248234 www-data  20   0  251600  35200  25976 S   4.0   0.0   1:16.44 php-fpm8.2

[ Voor 27% gewijzigd door Anoniem: 80910 op 08-11-2023 21:49 ]

[Hero of Time]

Je verwart hier de logger syslog (dat tegenwoordig is vervangen door systemd-journald) met de functie van een syslog server.

Vind het nog steeds bijzonder dat je zo enorm vaak Youtube moet aanraken. En als je elke keer weer moet authenticeren ipv dat je een auth token gebruikt is ook niet handig programmeren.

Niet negatief bedoeld, maar je begrip van hoe php werkt als service en hoe het workers spawned zegt mij ook al wat dat je maar wat doet met de hoop dat het werkt.

[Shivs]

Is er iets te vinden in je journalctl? Eventueel even zorgen dat die persistent is voor als je moet rebooten.

[Anoniem: 80910]

Hero of Time schreef op woensdag 8 november 2023 @ 22:06:
Je verwart hier de logger syslog (dat tegenwoordig is vervangen door systemd-journald) met de functie van een syslog server.

Vind het nog steeds bijzonder dat je zo enorm vaak Youtube moet aanraken. En als je elke keer weer moet authenticeren ipv dat je een auth token gebruikt is ook niet handig programmeren.

Niet negatief bedoeld, maar je begrip van hoe php werkt als service en hoe het workers spawned zegt mij ook al wat dat je maar wat doet met de hoop dat het werkt.

Wel ik ben momenteel een test aan het uitvoeren die de server laat crashen. Dat wil ik uiteindelijk voorkomen. Hoe ik dat oplos zie ik, als ik een foutmelding krijg.

De reden dat er bij de header een bearer token wordt meegestuurd leek me logisch. Dat ik in het script dan moet verifiëren of het de juiste user met rollen en permissies is, zou wellicht anders kunnen/ simpeler.

Ik had verwacht dat ie dit met gemak aan kan, blijkbaar niet. Waarom ik momenteel elke seconden uitvoer ipv 1x per 5/10seconden is test.

De test was ook een instance initiëren van mijn app en dan loggen. Hierdoor deed de autoloader er iets langer over, maar was mijn gedachte daar gaat het mis.

500.000 inlogpogingen per dag testen kan dus niet, duurt te lang. Maar hoe ik mijn server test onder gezonde load.

Ik ga nu kijken of ik een vastloper krijg met meerdere threads. Dat is nieuw voor mij en wellicht het probleem geweest.

Hij heeft vanacht volstaan door de logger uit te zetten en heeft wel doorgepruteld en niet vast gelopen.

Toch bijzonder om de host machine anno 2023 te zien freezen onder slechts 50.000 requests

[deHakkelaar]

De berichten in het /var/log/syslog bestandje zijn rechtstreeks afkomstig van systemd (systemd-journald.service):

$ systemd-analyze cat-config systemd/journald.conf
[..]
#ForwardToSyslog=yes

Boven is de default voor mijn Debian 12 distro.
Waar je dus zeker wilt zoeken is in de systemd journals.

Alles sinds laatste --boot weergeven:

code:

sudo journalctl --full --no-pager --boot

Of twee boots terug:

code:

sudo journalctl --full --no-pager --boot=-2

Warnings, errors etc:

code:

sudo journalctl --full --no-pager --boot --priority=4

Zelfde maar met extra info:

code:

sudo journalctl --full --no-pager --boot --priority=4 --catalog

Of voor een bepaalde namespace/unit (bv apache2):

code:

sudo journalctl --full --no-pager --boot --priority=4 --catalog --unit=apache2.service

Of de journals live volgen:

code:

sudo journalctl --full --catalog --follow

Of alleen een bepaalde unit (of meerderen) live volgen:

code:

sudo journalctl --full --catalog --follow --unit=apache2.service --unit=cron.service

Alle units weergeven:

code:

systemctl --full --no-pager list-unit-files

En ik zou ook kijken in de kernel ring buffer/logs (is in RAM dus volgende boot weg):

code:

sudo dmesg --ctime

Of alleen errors & warnings etc:

code:

sudo dmesg --ctime --level=warn,emerg,alert,crit,err

Of live volgen:

code:

sudo dmesg --ctime --follow-new

Als je de man pages vd desbetreffende commandos raadpleegt zie je veel meer opties waaronder de shortcuts voor de argumenten zoals bv -b ipv --boot.
Ook handige zijn:

$ man journalctl
[..]
       -k, --dmesg
           Show only kernel messages. This implies -b and adds the match
           "_TRANSPORT=kernel".
[..]
       -S, --since=, -U, --until=
           Start showing entries on or newer than the specified date, or on or
           older than the specified date, respectively. Date specifications
           should be of the format "2012-10-30 18:17:16".
[..]
       -g, --grep=
           Filter output to entries where the MESSAGE= field matches the
           specified regular expression.

Ik dacht ik type dit zo ff in elkaar maar ...

EDIT: Ter info, mijn minbase Debian heeft zelfs helemaal geen syslog en de andere logs die je gewend bent daar te vinden:

$ ls -1 /var/log/
README
alternatives.log
alternatives.log.1
apt
bootstrap.log
btmp
btmp.1
dpkg.log
dpkg.log.1
faillog
journal
lastlog
private
runit
wtmp

$ cat /var/log/README
You are looking for the traditional text log files in /var/log, and they are
gone?

Here's an explanation on what's going on:

You are running a systemd-based OS where traditional syslog has been replaced
with the Journal. The journal stores the same (and more) information as classic
syslog. To make use of the journal and access the collected log data simply
invoke "journalctl", which will output the logs in the identical text-based
format the syslog files in /var/log used to be. For further details, please
refer to journalctl(1).

Alternatively, consider installing one of the traditional syslog
implementations available for your distribution, which will generate the
classic log files for you. Syslog implementations such as syslog-ng or rsyslog
may be installed side-by-side with the journal and will continue to function
the way they always did.

Thank you!

Further reading:
        man:journalctl(1)
        man:systemd-journald.service(8)
        man:journald.conf(5)
        https://0pointer.de/blog/projects/the-journal.html

[ Voor 26% gewijzigd door deHakkelaar op 11-11-2023 01:26 . Reden: kleine correcties voor logica ]

[gbspeel]

Een externe website of API moet je het liefst nooit willen aanraken via een webserver. Je webserver kan zelf al een timeout geven omdat de externe server niet meewerkt en in jouw geval begeeft je server het wellicht door de stress. Met een POST/PUT/DELETE loop je daarbij extra risico. Apache, Nginx of de PHP-config kan de boel terminaten.

Het beste maak je hier een achtergrondproces van. Op CLI-processen zit standaard geen timeout. Dat proces kan het resultaat naar een cache of database wegschrijven. Je webserver kan daar vervolgens weer gebruik van maken, zonder de vertraging van externe diensten.

Frameworks zoals Laravel hebben alle tools in huis om dat te bereiken (een worker met jobs die kunnen falen en opnieuw kunnen worden gestart). Ook hoef je met `docker-compose` geen complete container met OS te builden, maar kun je het met Alpine-containers lichter houden, plus makkelijker onderhoudbaar omdat je b.v. alleen een php-container een upgrade geeft.

Voorbeeldje van een docker-compose file van een Laravel-project waar ik net mee ben begonnen:

YAML:

version: "3"

networks:
  homelab:
    driver: bridge

services:
  composer:
    build:
      context: ./
      dockerfile: docker/dev/composer.dockerfile
    env_file:
      - .env
    user: "${DEV_UID}:${DEV_UID}"
    volumes:
      - .:/app

  artisan:
    build:
      context: ./
      dockerfile: docker/dev/artisan.dockerfile
    networks:
      - homelab
    user: "${DEV_UID}:${DEV_UID}"
    volumes:
      - ./:/var/www

  php-fpm:
    build:
      context: ./
      dockerfile: docker/dev/php-fpm.dockerfile
    env_file:
      - .env
    networks:
      - homelab
    user: "${DEV_UID}:${DEV_UID}"
    volumes:
      - ./:/var/www

  redis:
    image: redis:7.0-alpine
    networks:
      - homelab
    ports:
      - "6379:6379"

  web:
    image: nginx:1.25-alpine
    depends_on:
      - php-fpm
      - redis
    links:
      - php-fpm
    networks:
      - homelab
    ports:
      - "80:80"
    restart: unless-stopped
    volumes:
      - ./docker/dev/nginx/homelab.conf:/etc/nginx/conf.d/homelab.conf
      - .:/var/www

  worker:
    build:
      context: ./
      dockerfile: docker/dev/artisan.dockerfile
    command: queue:work
    depends_on:
      - redis
    networks:
      - homelab
    restart: unless-stopped
    user: "${DEV_UID}:${DEV_UID}"
    volumes:
      - ./:/var/www

Met een klein beetje verdiepen in het installeren van PHP-extensies, kun je ook nuances aanbrengen in je FPM- en CLI-containers.

[Anoniem: 80910]

gbspeel schreef op maandag 13 november 2023 @ 16:51:
Een externe website of API moet je het liefst nooit willen aanraken via een webserver. Je webserver kan zelf al een timeout geven omdat de externe server niet meewerkt en in jouw geval begeeft je server het wellicht door de stress. Met een POST/PUT/DELETE loop je daarbij extra risico. Apache, Nginx of de PHP-config kan de boel terminaten.

Het beste maak je hier een achtergrondproces van. Op CLI-processen zit standaard geen timeout. Dat proces kan het resultaat naar een cache of database wegschrijven. Je webserver kan daar vervolgens weer gebruik van maken, zonder de vertraging van externe diensten.

Frameworks zoals Laravel hebben alle tools in huis om dat te bereiken (een worker met jobs die kunnen falen en opnieuw kunnen worden gestart). Ook hoef je met `docker-compose` geen complete container met OS te builden, maar kun je het met Alpine-containers lichter houden, plus makkelijker onderhoudbaar omdat je b.v. alleen een php-container een upgrade geeft.
[/code]

Met een klein beetje verdiepen in het installeren van PHP-extensies, kun je ook nuances aanbrengen in je FPM- en CLI-containers.

Wel, ik gebruik een debian based docker image in combinatie met docker compose.
Ik heb mijn eigen framework geschreven gebaseerd op debian en ben er nu zo'n 5 jaar mee bezig (gemiddeld 1 avond in de week).
Laravel is leuk voor kleine projecten, maar als het grotere projecten wordt, vind ik het een zooitje worden in de hierarchy.

Mijn situatie:

Ik heb een desktop environment in de browser geschreven, met daarin momenteel enkele apps.
1 daarvan is Youtube (deze kan downloaden van Youtube en Soundcloud bijvoorbeeld).
Deze App heeft een adres nodig als input en stuurt het dan door naar de backend.
Die maakt een zogenaamde task aan voor een root process. Er wordt apart een token opgeslagen. (JWT).
De taskmanager (door root gestart via een cronjob, en deze start elke minuut opnieuw voor een minuut lang) laadt de task en indien de JWT nog geldig is en de user in de claim de juiste rollen en rechten, mag deze de youtube app uitvoeren. Deze voert zich volledig uit in de achtergrond.

Nu start de Youtube app een javascript interval die gaat pollen of er een bestand is aangemaakt (Een zogenaamde .end file). De taskmanager maakt een .begin file, een .end file en een voortgang bestand geloof ik (De .end wordt aangemaakt als de task is afgerond).

Nu was ik mijn code aan het testen en kwam ik erachter dat als ik een lange poll doe op het bestand (de .end) (dus ongeacht of het bestaat of niet) de server ging crashen na ongeveer 50.000 requests (Die alle een JWT meekrijgen / valideren en via Mysql de rollen ophaalt en controlleerd). Dit duurde gemiddeld zo'n 600 msec per request.

De autoloader was verzwaard met een statische functie naar mijn logger. Die functie initieerde de "App" opnieuw / leest configuratie en weet zo de logger te initieeren en naar de juiste locatie weg te schrijven.

Hierdoor ontstond er een rare situatie in de autoloader (tijdens autoloaden, autoloaden van de app / logger bijvoorbeeld) en met php-fpm op default werdt er in de loop van de tijd (in de 50.000 requests) een error gegenereerd (Nog onbekend). Deze error zorgde ervoor dat de max_execution_time werdt overschreven. Waarschijnlijk in mijn config / parser wordt deze error gegenereerd, lijkt op een oneindige loop die toevallig optreed op de een of andere manier.

Echter wat er daarna dus gebeurde loopt eerst php-fpm vast, daarna docker, en daarna het systeem. Wat dus een harde reboot vereist (knopje indrukken).

Ik zie het niet terug in de logs, wat er fout gaat.


Nu wil ik die Youtube app toch al anders maken, dat is het probleem niet. Het is meer als test bedoeld. elke seconden een request afvuren op mijn server die de server (een I7 met 96 GB geheugen en ssd's) makkelijk aanmoeten.

Die logger daar in de autoload was om de laatste staat van de machine te bepalen zodat gekeken kan worden naar die max_execution_time error