Teil 1: Vom TYPO3 Container-Hosting zum TYPO3-Cluster mit erhöhtem Sicherheitsbedarf

Übersicht (nicht in Stein gemeißelt)

  • Teil 1: Container ready for Take-Off (dieser Post)
  • Teil 2: TYPO3 ready for Take-Off
  • Teil 3: Docker-Compose auf dem Produktiv-System
  • Teil 4: K8s und TYPO3 - Architektur
  • Teil 5: TYPO3 im K8s
  • Teil 6: K8s und TYPO3 - Fortgeschrittene Architektur
  • Teil 7: TYPO3-Cluster im K8s 1
  • Teil 8: TYPO3-Cluster im K8s 2
  • Teil 9: TYPO3-Cluster im K8s 3
  • Teil 10: K8s und TYPO3 - Architektur für erhöhten Sicherheitsbedarf
  • Teil 11: TYPO3-Cluster mit erhöhtem Sicherheitsbedarf

Container ready for Take-Off

Wir starten mit einem wichtigen Grundsatz: Sicherheit und Stabilität stehen im Fokus, sobald sich ein TYPO3-System von der Entwicklungsumgebung in die produktive Umgebung bewegt. Die Anforderungen an Container ändern sich erheblich, wenn der Übergang in die Produktivumgebung erfolgt, da hier maximale Sicherheit, hohe Performance und Stabilität entscheidend sind.

Für viele Entwickler*innen ist ddev die erste Wahl für ein effizientes TYPO3-Setup auf Basis von Containern. Doch das, was wir lokal für Testzwecke einsetzen, ist oft nicht ideal für den Produktiveinsatz. Ein Container-Image muss in der Produktion nach dem Build unveränderbar bleiben und den höchsten Sicherheitsanforderungen genügen. Im Folgenden beschreibe ich, wie wir eine sichere, minimalistische und produktionsreife TYPO3-Containerumgebung schaffen.

Wer Container für sein Hosting einsetzt, egal ob mit Docker- / Podman-Compose, -Swarm oder Kubernetes / OpenShift, sollte grundsätzlich eine abgewandelte Kopie seiner Images für die Entwicklung einsetzen. Nichts ist ärgerlicher und zeitraubender als Fehler, die erst später auftreten. Im besten Fall wird das gleiche Image in allen Stationen eingesetzt und nur, wenn notwendig, eine spezielle Version für das Debugging. Das ist für viele Entwickler*innen, aber auch Admins, die sich nun mehr und mehr im DevOps-Bereich bewegen, häufig eine deutliche Umstellung.

DevOps ist eine Methode, keine Job-Beschreibung! Jedes Entwicklungsteam sollte bis zum Launch der ersten Version nach dem MVP vollständig verantwortlich sein für die eigenen Services / Container und diese in einem vereinbarten Mindeststandard an Stabilität und Sicherheit bereitstellen, unterstützt durch einen SRE oder durch die allgemeine Anwendung von DevOps-Methoden. Im Weiteren gehe ich davon aus, dass du in einem Team unterwegs bist, das DevOps-Prinzipien anwendet.

Eine Kurze Definitionen von DevOps und SRE

DevOps

Eine Arbeitsmethode, die Entwicklung (Development) und Betrieb (Operations) verbindet. DevOps setzt auf enge Zusammenarbeit, Automatisierung und kontinuierliche Integration/Deployment (CI/CD). Ziel ist, Release-Zyklen zu verkürzen und die Qualität zu erhöhen.

SRE (Site Reliability Engineering)

Von Google entwickelter Ansatz, der Prinzipien der Softwareentwicklung auf IT-Operationen überträgt. SRE-Fachleute sind verantwortlich für die Verfügbarkeit, Leistung und Skalierbarkeit von Systemen und arbeiten mit Entwicklungsteams, um Betriebsprobleme proaktiv zu verhindern und die Systemzuverlässigkeit zu verbessern.

Minimalistische Systeme oder nicht?

Ein idealer Produktionscontainer sollte die folgenden Prinzipien erfüllen:

  1. Reduktion auf das Wesentliche: Verwende nur die notwendigen Pakete. Wolfi OS ist ideal für minimalistische Builds, die Angriffsflächen reduzieren.
  2. Isolation und klare Verantwortlichkeiten: Ein Container sollte genau eine Aufgabe erfüllen. Mehrere Prozesse in einem Container erhöhen das Risiko und erschweren die Wartung.
  3. Vermeidung von Root-Rechten: Der Container sollte nicht als Root laufen, um Exploits zu verhindern.
  4. Multi-Stage Builds: Vermeide Entwicklungswerkzeuge im End-Image, um die Container-Größe zu minimieren.

Diese Best Practices bilden die Basis für ein wartbares und sicheres Container-Setup, das wir in den kommenden Teilen vertiefen.

Ich persönlich mag den Ansatz eines Distroless-Containers sehr, jedoch bringt der minimalistisch-puristische Ansatz eine große Herausforderung mit: Debugging mit z.B. Xdebug ist nicht möglich.

Für unser Ziel eignet sich der Ansatz jedoch hervorragend. Je weniger Pakete installiert werden, desto weniger müssen wir prüfen, updaten und zusätzlich absichern. Der Verzicht auf nicht absolut notwendige Pakete bringt also Sicherheit – Sicherheit, die wir später noch brauchen werden.

RHEL vs. Alpine Linux vs. Wolfi OS

RHEL

Kurz und schmerzlos. Zu langsam. Also die Updates, nicht das System.

Mir persönlich ist wichtig, dass Updates für Sicherheitslücken schnell verfügbar sind. Immer wenn ich bzw. das Team, in dem ich unterwegs war, RHEL validiert haben, haben wir CVEs gefunden, die in Ubuntu und Alpine schon gefixt waren.

Alpine

Wer Distroless sagt, denkt nicht direkt an Alpine. Alpine ist aber der Weg, den viele einschlagen, wenn sie generell kleine Images möchten. Der vorhandene Minimalansatz wirkt häufig besser als der radikalere Distroless-Einsatz. Doch wer an Alpine und PHP denkt, weiß um die Schwierigkeiten; wer nun auch noch Lokalisierung, z. B. für Deutsch, dazu nimmt, weiß, dass es mit dem Minimal-Prinzip schwierig wird.

Versteht mich nicht falsch, ich halte Alpine Linux für ein gutes, solides Linux, nur hat es Schwächen, die echte Herausforderungen sein können.

Wolfi OS

Wolfi OS von Chainguard bietet eine Lösung für diese Herausforderungen, indem es das Ziel verfolgt, 0 CVEs zu haben und auf glibc setzt, was eine bessere Kompatibilität mit PHP und Multi-Architekturen gewährleistet.

Durch die Nutzung von Wolfi OS minimieren wir bekannte Schwachstellen und setzen auf ein minimalistisches, sicheres System ohne überflüssige Pakete, das PHP-basierte Anwendungen wie TYPO3 effizient unterstützt. Ich liebe wirklich Wolfi OS; es hat für mich gleich mehrere Dinge gelöst, auf die ich in der Serie eingehen werde.

Meine Empfehlung ist, nutzt Wolfi OS, auch wenn nur die neueste PHP-Version kostenfrei verfügbar ist. Der Aufwand, die Images zu generieren, lohnt sich.

Immutability – Der Schlüssel zu stabilen und sicheren Containern

Ein weiterer zentraler Aspekt eines produktionsreifen Containers ist die Unveränderlichkeit (Immutability). Ein Container-Image, das einmal für die Produktion freigegeben wurde, darf nicht mehr verändert werden. Durch das Immutability-Prinzip bleibt das System stabil und sicher, da Änderungen nur über neue, geprüfte Builds vorgenommen werden. So lassen sich alle Anpassungen gezielt und kontrolliert über CI/CD-Pipelines und Rollouts implementieren.

Vorbereitung der Konfigurationsdateien

Bevor wir das Container-Image erstellen, konfigurieren wir die erforderlichen Dateien. Die folgenden Konfigurationen stellen sicher, dass der Container den Anforderungen an eine produktionsreife TYPO3-Umgebung gerecht wird. Alle Werte basieren auf Messungen und sind erprobt, wenn du oder ihr andere Werte habt, können diese für euch besser sein. Es kommt immer auch darauf an, welche TYPO3-Version und welche Extensions eingesetzt werden. In dieser Serie basieren alle Angaben auf TYPO3 12 und PHP 8.3 – ihr könnt euch vorstellen, solche Cluster sind nicht die ersten Systeme, die man auf eine neue Version anhebt.

1. PHP-Konfiguration: php.ini

Erstelle die Datei php.ini mit den folgenden Einstellungen, um Performance und Sicherheit für TYPO3 zu gewährleisten.

apc.shm_size = "128M"
apc.enable_cli=1
assert.active = Off
expose_php = Off
gd.jpeg_ignore_warning = 1
display_errors = Off
log_errors = On
max_execution_time = 240
max_input_vars = 1500
memory_limit = 256M
post_max_size = 80M
realpath_cache_size=4096K
realpath_cache_ttl = 3600
upload_max_filesize = 80M
redis.pconnect.pooling_enabled = 1

# opcache
opcache.enable = 1
opcache.enable_cli = 1
opcache.enable_file_override = 1
#opcache.validate_timestamps = 0
opcache.interned_strings_buffer = 64
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.max_wasted_percentage = 10

zend.assertions = -1
zend.detect_unicode = Off
session_gc_probability = 0
session.use_strict_mode = On
short_open_tag = Off

[Date]
date.timezone = Europe/Berlin

Was passiert hier?

Hier ist eine Erklärung der spezifischen Werte in der php.ini und deren Funktion:

  1. apc.shm_size = "128M": Gibt den gemeinsam genutzten Speicher für den APC-Cache an. Erhöht auf 128 MB für mehr Caching-Kapazität.
  2. apc.enable_cli=1: Erlaubt die Nutzung von APC im CLI-Modus, nützlich für Befehlszeilenskripte, die Zwischenspeicherung verwenden.
  3. assert.active = Off: Deaktiviert assert(), um den Overhead im Produktivbetrieb zu minimieren.
  4. expose_php = Off: Verhindert die PHP-Versionsanzeige in HTTP-Headern für zusätzliche Sicherheit.
  5. gd.jpeg_ignore_warning = 1: Ignoriert JPEG-Warnungen bei der Bildverarbeitung in GD, was den Betrieb stabiler macht.
  6. display_errors = Off: Fehlerausgaben werden im Produktionsbetrieb abgeschaltet, um Informationen über das System zu schützen.
  7. log_errors = On: Aktiviert das Fehlerlogging, was Fehlerdiagnose und Wartung erleichtert.
  8. max_execution_time = 240: Setzt das Skript-Timeout auf 240 Sekunden, was für lange, komplexe PHP-Skripte nützlich ist.
  9. max_input_vars = 1500: Erhöht die Anzahl erlaubter GET/POST-Variablen, was wichtig für Formulare mit vielen Feldern ist.
  10. memory_limit = 256M: Erhöht den maximalen Speicher für Skripte auf 256 MB, was Speichermangel in ressourcenintensiven Anwendungen verhindert.
  11. post_max_size = 80M und upload_max_filesize = 80M: Erlauben größere Dateien in POST-Anfragen und Uploads, was nützlich für Webanwendungen mit Medienuploads ist.
  12. realpath_cache_size=4096K und realpath_cache_ttl = 3600: Optimiert die Pfadauflösung, reduziert I/O-Operationen und verbessert so die Leistung bei Dateizugriffen.
  13. redis.pconnect.pooling_enabled = 1: Ermöglicht die Verwendung von persistenten Verbindungen in Redis, was die Effizienz bei hoher Last steigert.
  14. opcache-Einstellungen:
    1. enable = 1 und enable_cli = 1: Aktivieren OPCache im Web- und CLI-Modus.
    2. enable_file_override = 1: Erlaubt das Überschreiben von Datei-Existenzüberprüfungen für Performance-Optimierungen.
    3. interned_strings_buffer = 64, memory_consumption = 256, max_accelerated_files = 20000, max_wasted_percentage = 10: Stellen OPCache-Speichergrößen und Parameter ein, um Cache-Effizienz zu maximieren.
  15. zend.assertions = -1: Deaktiviert Assertions für Produktionsumgebungen und reduziert so den Overhead.
  16. zend.detect_unicode = Off: Verhindert Unicode-Erkennung in Zend, was Performance in bestimmten Setups verbessern kann.
  17. session.use_strict_mode = On: Aktiviert strikten Session-Modus, der Sessions absichert, indem nicht existierende Session-IDs zurückgewiesen werden.
  18. short_open_tag = Off: Deaktiviert Kurz-Tags (<?), um Konflikte mit XML und HTML zu vermeiden.
  19. date.timezone = Europe/Berlin: Setzt die Standard-Zeitzone auf Mitteleuropa, wichtig für korrektes Zeitmanagement in Skripten.

Diese Werte optimieren PHP für Sicherheit, Leistung und Stabilität, besonders in produktiven Webanwendungen.

2. PHP-FPM-Konfiguration: www.conf

Erstelle die Datei www.conf für PHP-FPM, um Server-Resourcen optimal zu nutzen und die Sicherheit zu erhöhen.

; Start a new pool named 'www'.
; the variable $pool can be used in any directive and will be replaced by the
; pool name ('www' here)
[www]

; Per pool prefix
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'
; When not set, the global prefix (or NONE) applies instead.
; Note: This directive can also be relative to the global prefix.
; Default Value: none
;prefix = /path/to/pools/$pool

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = www-data
group = www-data

; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific IPv4 address on
;                            a specific port;
;   '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses
;                            (IPv6 and IPv4-mapped) on a specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = 127.0.0.1:9000

; Set listen(2) backlog.
; Default Value: 511 (-1 on FreeBSD and OpenBSD)
;listen.backlog = 511

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions.
; Default Values: user and group are set as the running user
;                 mode is set to 0660
;listen.owner = www-data
;listen.group = www-data
;listen.mode = 0660
; When POSIX Access Control Lists are supported you can set them using
; these options, value is a comma separated list of user/group names.
; When set, listen.owner and listen.group are ignored
;listen.acl_users =
;listen.acl_groups =

; List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect.
; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original
; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address
; must be separated by a comma. If this value is left blank, connections will be
; accepted from any ip address.
; Default Value: any
;listen.allowed_clients = 127.0.0.1

; Specify the nice(2) priority to apply to the pool processes (only if set)
; The value can vary from -19 (highest priority) to 20 (lower priority)
; Note: - It will only work if the FPM master process is launched as root
;       - The pool processes will inherit the master process priority
;         unless it specified otherwise
; Default Value: no set
; process.priority = -19

; Set the process dumpable flag (PR_SET_DUMPABLE prctl) even if the process user
; or group is differrent than the master process user. It allows to create process
; core dump and ptrace the process for the pool user.
; Default Value: no
; process.dumpable = yes

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
pm = dynamic

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 15

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
pm.start_servers = 2

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 1

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 3

; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
;pm.process_idle_timeout = 10s;

; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in 3rd party libraries. For
; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
; Default Value: 0
pm.max_requests = 500

; The URI to view the FPM status page. If this value is not set, no URI will be
; recognized as a status page. It shows the following informations:
;   pool                 - the name of the pool;
;   process manager      - static, dynamic or ondemand;
;   start time           - the date and time FPM has started;
;   start since          - number of seconds since FPM has started;
;   accepted conn        - the number of request accepted by the pool;
;   listen queue         - the number of request in the queue of pending
;                          connections (see backlog in listen(2));
;   max listen queue     - the maximum number of requests in the queue
;                          of pending connections since FPM has started;
;   listen queue len     - the size of the socket queue of pending connections;
;   idle processes       - the number of idle processes;
;   active processes     - the number of active processes;
;   total processes      - the number of idle + active processes;
;   max active processes - the maximum number of active processes since FPM
;                          has started;
;   max children reached - number of times, the process limit has been reached,
;                          when pm tries to start more children (works only for
;                          pm 'dynamic' and 'ondemand');
; Value are updated in real time.
; Example output:
;   pool:                 www
;   process manager:      static
;   start time:           01/Jul/2011:17:53:49 +0200
;   start since:          62636
;   accepted conn:        190460
;   listen queue:         0
;   max listen queue:     1
;   listen queue len:     42
;   idle processes:       4
;   active processes:     11
;   total processes:      15
;   max active processes: 12
;   max children reached: 0
;
; By default the status page output is formatted as text/plain. Passing either
; 'html', 'xml' or 'json' in the query string will return the corresponding
; output syntax. Example:
;   http://www.foo.bar/status
;   http://www.foo.bar/status?json
;   http://www.foo.bar/status?html
;   http://www.foo.bar/status?xml
;
; By default the status page only outputs short status. Passing 'full' in the
; query string will also return status for each pool process.
; Example:
;   http://www.foo.bar/status?full
;   http://www.foo.bar/status?json&full
;   http://www.foo.bar/status?html&full
;   http://www.foo.bar/status?xml&full
; The Full status returns for each process:
;   pid                  - the PID of the process;
;   state                - the state of the process (Idle, Running, ...);
;   start time           - the date and time the process has started;
;   start since          - the number of seconds since the process has started;
;   requests             - the number of requests the process has served;
;   request duration     - the duration in µs of the requests;
;   request method       - the request method (GET, POST, ...);
;   request URI          - the request URI with the query string;
;   content length       - the content length of the request (only with POST);
;   user                 - the user (PHP_AUTH_USER) (or '-' if not set);
;   script               - the main script called (or '-' if not set);
;   last request cpu     - the %cpu the last request consumed
;                          it's always 0 if the process is not in Idle state
;                          because CPU calculation is done when the request
;                          processing has terminated;
;   last request memory  - the max amount of memory the last request consumed
;                          it's always 0 if the process is not in Idle state
;                          because memory calculation is done when the request
;                          processing has terminated;
; If the process is in Idle state, then informations are related to the
; last request the process has served. Otherwise informations are related to
; the current request being served.
; Example output:
;   ************************
;   pid:                  31330
;   state:                Running
;   start time:           01/Jul/2011:17:53:49 +0200
;   start since:          63087
;   requests:             12808
;   request duration:     1250261
;   request method:       GET
;   request URI:          /test_mem.php?N=10000
;   content length:       0
;   user:                 -
;   script:               /home/fat/web/docs/php/test_mem.php
;   last request cpu:     0.00
;   last request memory:  0
;
; Note: There is a real-time FPM status monitoring sample web page available
;       It's available in: /usr/local/share/php/fpm/status.html
;
; Note: The value must start with a leading slash (/). The value can be
;       anything, but it may not be a good idea to use the .php extension or it
;       may conflict with a real PHP file.
; Default Value: not set
;pm.status_path = /internal-php/status

; The ping URI to call the monitoring page of FPM. If this value is not set, no
; URI will be recognized as a ping page. This could be used to test from outside
; that FPM is alive and responding, or to
; - create a graph of FPM availability (rrd or such);
; - remove a server from a group if it is not responding (load balancing);
; - trigger alerts for the operating team (24/7).
; Note: The value must start with a leading slash (/). The value can be
;       anything, but it may not be a good idea to use the .php extension or it
;       may conflict with a real PHP file.
; Default Value: not set
;ping.path = /health

; This directive may be used to customize the response of a ping request. The
; response is formatted as text/plain with a 200 response code.
; Default Value: pong
;ping.response = OK

; The access log file
; Default: not set
;access.log = log/$pool.access.log

; The access log format.
; The following syntax is allowed
;  %%: the '%' character
;  %C: %CPU used by the request
;      it can accept the following format:
;      - %{user}C for user CPU only
;      - %{system}C for system CPU only
;      - %{total}C  for user + system CPU (default)
;  %d: time taken to serve the request
;      it can accept the following format:
;      - %{seconds}d (default)
;      - %{milliseconds}d
;      - %{milli}d
;      - %{microseconds}d
;      - %{micro}d
;  %e: an environment variable (same as $_ENV or $_SERVER)
;      it must be associated with embraces to specify the name of the env
;      variable. Some examples:
;      - server specifics like: %{REQUEST_METHOD}e or %{SERVER_PROTOCOL}e
;      - HTTP headers like: %{HTTP_HOST}e or %{HTTP_USER_AGENT}e
;  %f: script filename
;  %l: content-length of the request (for POST request only)
;  %m: request method
;  %M: peak of memory allocated by PHP
;      it can accept the following format:
;      - %{bytes}M (default)
;      - %{kilobytes}M
;      - %{kilo}M
;      - %{megabytes}M
;      - %{mega}M
;  %n: pool name
;  %o: output header
;      it must be associated with embraces to specify the name of the header:
;      - %{Content-Type}o
;      - %{X-Powered-By}o
;      - %{Transfert-Encoding}o
;      - ....
;  %p: PID of the child that serviced the request
;  %P: PID of the parent of the child that serviced the request
;  %q: the query string
;  %Q: the '?' character if query string exists
;  %r: the request URI (without the query string, see %q and %Q)
;  %R: remote IP address
;  %s: status (response code)
;  %t: server time the request was received
;      it can accept a strftime(3) format:
;      %d/%b/%Y:%H:%M:%S %z (default)
;      The strftime(3) format must be encapsulated in a %{<strftime_format>}t tag
;      e.g. for a ISO8601 formatted timestring, use: %{%Y-%m-%dT%H:%M:%S%z}t
;  %T: time the log has been written (the request has finished)
;      it can accept a strftime(3) format:
;      %d/%b/%Y:%H:%M:%S %z (default)
;      The strftime(3) format must be encapsulated in a %{<strftime_format>}t tag
;      e.g. for a ISO8601 formatted timestring, use: %{%Y-%m-%dT%H:%M:%S%z}t
;  %u: remote user
;
; Default: "%R - %u %t \"%m %r\" %s"
;access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"
access.format='{"time":"%{%Y-%m-%dT%H:%M:%S%z}T","client_ip":"%{HTTP_X_FORWARDED_FOR}e","remote_addr":"%R","remote_user":"%u","request":"%m %{REQUEST_URI}e %{SERVER_PROTOCOL}e","response_status":%s,"body_bytes_sent":"%l","request_time":%d,"http_referrer":"%{HTTP_REFERER}e","http_user_agent":"%{HTTP_USER_AGENT}e","http_request_id":"%{TOOM_REQUEST_ID}e","market_id":"%{TOOM_MARKET_ID}e","correlation_id":"%{K_CORRELATION_ID}e", "user_correlation_id":"%{K_USER_CORRELATION_ID}e", "cpu_percent": %C, "memory_consumption": %M }'
; The log file for slow requests
; Default Value: not set
; Note: slowlog is mandatory if request_slowlog_timeout is set
;slowlog = log/$pool.log.slow

; The timeout for serving a single request after which a PHP backtrace will be
; dumped to the 'slowlog' file. A value of '0s' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
;request_slowlog_timeout = 0

; Depth of slow log stack trace.
; Default Value: 20
;request_slowlog_trace_depth = 20

; The timeout for serving a single request after which the worker process will
; be killed. This option should be used when the 'max_execution_time' ini option
; does not stop script execution for some reason. A value of '0' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
request_terminate_timeout = 240s

; Set open file descriptor rlimit.
; Default Value: system defined value
;rlimit_files = 1024

; Set max core size rlimit.
; Possible Values: 'unlimited' or an integer greater or equal to 0
; Default Value: system defined value
;rlimit_core = 0

; Chroot to this directory at the start. This value must be defined as an
; absolute path. When this value is not set, chroot is not used.
; Note: you can prefix with '$prefix' to chroot to the pool prefix or one
; of its subdirectories. If the pool prefix is not set, the global prefix
; will be used instead.
; Note: chrooting is a great security feature and should be used whenever
;       possible. However, all PHP paths will be relative to the chroot
;       (error_log, sessions.save_path, ...).
; Default Value: not set
;chroot =

; Chdir to this directory at the start.
; Note: relative path can be used.
; Default Value: current directory or / when chroot
;chdir = /var/www

; Redirect worker stdout and stderr into main error log. If not set, stdout and
; stderr will be redirected to /dev/null according to FastCGI specs.
; Note: on highloaded environment, this can cause some delay in the page
; process time (several ms).
; Default Value: no
catch_workers_output = yes

; Decorate worker output with prefix and suffix containing information about
; the child that writes to the log and if stdout or stderr is used as well as
; log level and time. This options is used only if catch_workers_output is yes.
; Settings to "no" will output data as written to the stdout or stderr.
; Default value: yes
;decorate_workers_output = no

; Clear environment in FPM workers
; Prevents arbitrary environment variables from reaching FPM worker processes
; by clearing the environment in workers before env vars specified in this
; pool configuration are added.
; Setting to "no" will make all environment variables available to PHP code
; via getenv(), $_ENV and $_SERVER.
; Default Value: yes
clear_env = no

; Limits the extensions of the main script FPM will allow to parse. This can
; prevent configuration mistakes on the web server side. You should only limit
; FPM to .php extensions to prevent malicious users to use other extensions to
; execute php code.
; Note: set an empty value to allow all extensions.
; Default Value: .php
;security.limit_extensions = .php .php3 .php4 .php5 .php7

; Pass environment variables like LD_LIBRARY_PATH. All $VARIABLEs are taken from
; the current environment.
; Default Value: clean env
;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp

; Additional php.ini defines, specific to this pool of workers. These settings
; overwrite the values previously defined in the php.ini. The directives are the
; same as the PHP SAPI:
;   php_value/php_flag             - you can set classic ini defines which can
;                                    be overwritten from PHP call 'ini_set'.
;   php_admin_value/php_admin_flag - these directives won't be overwritten by
;                                     PHP call 'ini_set'
; For php_*flag, valid values are on, off, 1, 0, true, false, yes or no.

; Defining 'extension' will load the corresponding shared extension from
; extension_dir. Defining 'disable_functions' or 'disable_classes' will not
; overwrite previously defined php.ini values, but will append the new value
; instead.

; Note: path INI options can be relative and will be expanded with the prefix
; (pool, global or /usr/local)

; Default Value: nothing is defined by default except the values in php.ini and
;                specified at startup with the -d argument
;php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f www@my.domain.com
;php_flag[display_errors] = off
;php_admin_value[error_log] = /var/log/fpm-php.www.log
;php_admin_flag[log_errors] = on
;php_admin_value[memory_limit] = 32M

Was passiert hier?

Hier sind die Parameter und ihre Bedeutungen, die im Vergleich zu den Standardwerten angepasst wurden:

  1. user und group = www-data: Setzt den Benutzer und die Gruppe, unter der PHP-FPM ausgeführt wird. Standardmäßig verwendet PHP-FPM dieselben Standardbenutzer wie den Webserver.
  2. listen = 127.0.0.1:9000: Gibt die Adresse für die Annahme von FastCGI-Anfragen an. Der Standardwert ist ein UNIX-Socket, hier wurde jedoch eine TCP-Verbindung konfiguriert, die sich für verteilte Setups eignet.
  3. pm = dynamic: Wechselt die Prozessverwaltung zu dynamic. Die Standardeinstellung ist dynamic, jedoch sind nachfolgende pm-Parameter angepasst, um das Verhalten für Startprozesse zu steuern.
  4. pm.max_children = 15: Setzt das Limit für gleichzeitige Anfragen auf 15 Prozesse. Dies beeinflusst die maximale Anzahl an Verbindungen, die gleichzeitig verarbeitet werden können.
  5. pm.start_servers = 2: Legt fest, dass zu Beginn zwei Serverprozesse starten, was die Reaktionsfähigkeit beim Start verbessert.
  6. pm.min_spare_servers = 1 und pm.max_spare_servers = 3: Gibt an, dass zwischen einem und drei Prozesse im Leerlauf gehalten werden sollen, um eine schnelle Bearbeitung zu ermöglichen, ohne Ressourcen zu vergeuden.
  7. pm.max_requests = 500: Definiert, dass jeder Kindprozess nach 500 Anfragen neu startet, um Speicherlecks und Überlastungen zu verhindern. Der Standardwert ist 0, was eine unbegrenzte Verarbeitung erlaubt.
  8. request_terminate_timeout = 240s: Begrenzung der Ausführungszeit eines einzelnen Requests auf 240 Sekunden. Der Standardwert ist 0, was keine Zeitbegrenzung vorsieht.
  9. catch_workers_output = yes: Erlaubt die Protokollierung von stdout und stderr für Worker-Prozesse, was Debugging erleichtert. Standardmäßig werden diese Ausgaben ignoriert.
  10. clear_env = no: Lässt die Worker-Umgebungsvariablen unverändert, während der Standardwert alle Umgebungsvariablen leert, um eine sicherere Umgebung zu gewährleisten.
  11. `access.format: Der Log-Formatstring wurde für strukturierte JSON-Logs angepasst. Das Standardformat ist einfacher, hier aber für umfassendere Protokollierung optimiert.

Diese Einstellungen optimieren die PHP-FPM-Poolkonfiguration für Leistung, Resilienz und Debugging in einer Produktionsumgebung, die sowohl auf Sicherheit als auch auf Effizienz ausgelegt ist.

3. PHP-FPM Hauptkonfiguration: php-fpm.conf

Erstelle die Datei php-fpm.conf für weitere Feinabstimmungen, definiere dort abweichend vom Standard ein hohes log_limit damit die Fehlermeldungen vollständig ausgegeben werden.

; Set log_limit to very high number in order for log messages not be truncated
log_limit = 1000000

Diese Dateien platzieren wir im Build-Verzeichnis, damit sie später in das Image kopiert werden können.

Aufbau des Dockerfiles

Das folgende Dockerfile erstellt ein TYPO3-Image auf Basis von Wolfi OS und kopiert die vorbereiteten Konfigurationsdateien in das Container-Setup.

# Start with Wolfi OS base image for a secure and minimal setup
FROM ghcr.io/shyim/wolfi-php/fpm:8.3

# Install PHP dependencies
RUN apk add --no-cache php-8.3-redis php-8.3-gd

# Copy your files
COPY . /var/www/html

# Copy configuration files into the image
COPY php.ini /etc/php/php.ini
COPY www.conf /etc/php/php-fpm.d/www.conf
COPY php-fpm.conf /etc/php/php-fpm.conf

# running as non-root
USER www-data

Der Verzicht auf einen Root-User zur Ausführung ist eine empfohlene Vorgehensweise, die euch erlaubt, die vergebenen Berechtigungen zu minimieren.

Erstellen des Images

Um das Image zu bauen, führe folgenden Befehl im Verzeichnis des Dockerfiles aus:

docker build .

Hier können auch Multi-Arch-Images gebaut werden; wenn ihr auf dem Mac entwickelt, lohnt sich der Build eines ARM64-Images. Wir haben jetzt ein PHP-FPM-Image. Im nächsten Teil schauen wir uns an, welche Änderungen wir für den Betrieb von TYPO3 in einem Container anpassen müssen. Im endgültigen Setup werden wir RepoDigests für den Tag nutzen.

Mit diesen Konfigurationen und dem Immutability-Prinzip bleibt das TYPO3-Setup stabil und sicher. In den folgenden Teilen gehen wir detaillierter auf CI/CD-Pipelines, Cluster-Architekturen und Monitoring ein, um das Setup weiter zu optimieren.

aktualisiert_am 26-10-2024