In questo articolo, diamo un'occhiata a come migrare un'installazione di WordPress da un'installazione normale a un container. Nel caso ve lo foste perso, in un precedente articolo abbiamo fornito una carrellata del processo generale che intendiamo utilizzare.
Containerizzare WordPress sembra così ingannevolmente facile. È uno stack LAMP standard, ma ci sono alcune insidie che vogliamo evitare. I container sono in realtà due cose:le immagini del container a riposo e i processi Linux in fase di esecuzione. Diamo un'occhiata a entrambe le parti:build ed esegui.
Nota dell'editore:ai fini di questo articolo, presumiamo che creerai i tuoi container su Red Hat Enterprise Linux 8 usando podman build. Potresti essere in grado di utilizzare le istruzioni su altre distribuzioni o con altre toolchain, tuttavia potrebbero essere necessarie alcune modifiche.
Costruisci
WordPress ha bisogno di PHP e di un server web. La configurazione più comune consiste nell'usare Apache (o Nginx) con PHP FastCGI Process Manager (php-fpm) e un interprete PHP. In effetti, è possibile creare un'immagine contenitore generica per quasi tutte le applicazioni basate su PHP, inclusi WordPress e MediaWiki. Ecco un esempio di come crearne uno con Red Hat Universal Base Image:
FROM registry.access.redhat.com/ubi8/ubi-init
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y mariadb-server mariadb php php-apcu php-intl php-mbstring php-xml php-json php-mysqlnd crontabs cronie iputils net-tools;yum clean all
RUN systemctl enable mariadb
RUN systemctl enable httpd
RUN systemctl disable systemd-update-utmp.service
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
ubi-init l'immagine è configurata immediatamente per eseguire systemd dentro il contenitore durante l'esecuzione. Ciò semplifica l'esecuzione di alcuni comandi durante l'installazione e fare affidamento sull'esperienza in materia incorporata nella distribuzione Linux. Come ho sostenuto per anni, la qualità dell'immagine del contenitore e l'igiene della catena di approvvigionamento sono più importanti delle singole immagini più piccole in assoluto che possiamo produrre (Bocconcini sui contenitori:una buona igiene della catena di approvvigionamento può mitigare le dimensioni dell'immagine di base?). Dobbiamo considerare la dimensione totale della tua catena di approvvigionamento, non le singole immagini, quindi ho scelto ubi-init immagine.
Nota quanto è semplice Containerfile. Questo perché ci affidiamo ai packager per avviare correttamente i servizi. Vedi anche:Le distribuzioni Linux contano ancora con i container?
È una build abbastanza semplice, quindi passiamo alle cose complicate in fase di esecuzione.
[ Potrebbe piacerti anche: Spostare da docker-compose a Podman pod ]
Corri
Come i servizi tradizionali, su server tradizionali, che eseguono i nostri container con systemd ci offre un modo conveniente per avviarli quando avviamo il nostro host del contenitore o quando il contenitore viene ucciso (recuperabilità nella tabella sopra). Analizziamo il nostro file di unità systemd per comprendere meglio le decisioni di progettazione e alcuni dei vantaggi dell'esecuzione di servizi nei container:
[Unit]
Description=Podman container - wordpress.crunchtools.com
[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --read-only --rm -p 80:80 --name wordpress.crunchtools.com \
-v /srv/wordpress.crunchtools.com/code/wordpress:/var/www/html/wordpress.crunchtools.com:Z \
-v /srv/wordpress.crunchtools.com/config/wp-config.php:/var/www/html/wordpress.crunchtools.com/wp-config.php:ro \
-v /srv/wordpress.crunchtools.com/config/wordpress.crunchtools.com.conf:/etc/httpd/conf.d/wordpress.crunchtools.com.conf:ro \
-v /srv/wordpress.crunchtools.com/data/wp-content:/var/www/html/wordpress.crunchtools.com/wp-content:Z \
-v /srv/wordpress.crunchtools.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/wordpress.crunchtools.com/data/mariadb/:/var/lib/mysql:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
localhost/httpd-php
ExecStop=/usr/bin/podman stop -t 3 wordpress.crunchtools.com
ExecStopAfter=/usr/bin/podman rm -f wordpress.crunchtools.com
Restart=always
[Install] WantedBy=multi-user.target
Innanzitutto, nota che stiamo eseguendo l'intero contenitore in sola lettura e con –rm opzione, rendendola effimera. Il contenitore viene eliminato ogni volta che viene arrestato. Questo ci costringe a dividere il nostro codice, configurazione e dati e salvarlo su supporti esterni, altrimenti andrà perso. Questo ci dà anche la possibilità di uccidere il contenitore per raccogliere le modifiche al file di configurazione come un normale servizio (ne parleremo più avanti). Apache, PHP FPM e MariaDB funzionano fianco a fianco nel container, consentendo loro di comunicare comodamente su socket privati. Per un servizio così semplice, non è necessario ridimensionare MariaDB e Apache separatamente, quindi non è necessario dividerli.
Si noti che dividiamo il codice, la configurazione e i dati in directory separate e associamo i mount. I principali binari FPM di Apache, PHP e PHP provengono da httpd-php immagine del contenitore costruita su Red Hat Universal Base Image, mentre il codice di WordPress deriva dal codice/wordpress bind mount. In molti contenitori, tutto il codice proverrà dall'immagine del contenitore (vedi Tracker delle richieste più avanti). La directory code/wordpress ospita solo il codice PHP di WordPress scaricato da wordpress.org. Nessuno dei nostri dati personali o personalizzazioni viene salvato nella directory code/wordpress. Tuttavia, l'abbiamo volutamente reso un montaggio di collegamento separato e scrivibile per consentire a WordPress di aggiornarsi automaticamente in fase di esecuzione. Ciò è contrario alle migliori pratiche tipiche con i container, ma è una funzionalità molto conveniente per un servizio Web popolare che è sotto attacco costante e riceve frequentemente aggiornamenti di sicurezza. Progettarlo in questo modo ci offre aggiornamenti via etere senza dover ricostruire l'immagine del contenitore. Rendere i servizi il più possibile senza conducente è sicuramente utile.
Ora, guarda le righe di configurazione. Ogni file di configurazione personalizzato è montato in binding nel contenitore di sola lettura. Questo è un solido aggiornamento della sicurezza dai tradizionali server LAMP (macchine virtuali o bare metal). Ciò impedisce l'utilizzo di alcuni plugin di WordPress che tentano di modificare wp-config.php, ma la maggior parte degli amministratori di sistema vorrebbe comunque disabilitarli. Questo potrebbe essere eseguito in lettura e scrittura se alcuni dei nostri utenti hanno davvero bisogno di questi plugin.
Quindi, nota la directory dei dati. Leghiamo mount a tre diverse sottodirectory. Sono tutti scrivibili:
- data/wp-content – Questa directory contiene i nostri dati personali e personalizzazioni. Ciò include cose come temi WordPress, plug-in e file caricati (immagini, video, mp3, ecc.). Va anche notato che questo è un sito WordPress Multi-User (MU), quindi più siti salvano i propri dati qui. Un amministratore di WordPress potrebbe accedere e creare nuovi siti, se necessario.
- dati/registri:vogliamo che i nostri registri Apache siano fuori dal contenitore in modo da poter rintracciare accessi/errori o eseguire analisi. Potremmo anche usarli se qualcuno si intromettesse e dobbiamo ricostruire cosa è successo. Un'opzione di montaggio di sola scrittura potrebbe essere utile qui.
- data/mariadb – Questa è la nostra directory scrivibile per MariaDB. La maggior parte dei nostri segreti sono archiviati nel database e questa directory ha i permessi impostati correttamente per l'utente/gruppo mysql. Questo ci fornisce un isolamento a livello di processo equivalente nel contenitore, simile a un normale server LAMP. C'è un po' di aggiornamento della sicurezza perché questa istanza MariaDB contiene solo dati di WordPress. Gli hacker non possono entrare in WordPress e accedere al nostro Wiki né al Tracker delle richieste, che hanno le proprie istanze MariaDB separate.
Quindi, diamo un'occhiata a –tempfs monti. Questi abilitano systemd per funzionare correttamente in un contenitore di sola lettura. Tutti i dati scritti su questi montaggi verranno automaticamente eliminati quando il contenitore si arresta. Questo rende tutto al di fuori delle nostre cavalcature vincolanti completamente effimero. Potrebbero essere apportate altre modifiche per acquisire /var/log/messages o altri registri se lo si desidera.
Per i backup all'interno di WordPress, ci affidiamo a UpdraftPlus. UpdraftPlus offre il vantaggio di eseguire il backup di tutto da un sito WordPress MU, inclusi temi, plug-in, file e database. Può anche inviare il backup a un archivio remoto come Dropbox o pCloud (tramite WebDav). Questo è un modello di progettazione comune con applicazioni di livello superiore come WordPress. Spesso i database, i CRM, ecc. avranno le proprie utilità di backup o ecosistemi di software di backup di terze parti. Affidarsi a questo software esistente è ancora utile nei container.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Mi ci è voluto molto tempo per ottenere finalmente queste applicazioni containerizzate, ma lo sforzo è stato ripagato. È bello pensare a questo tipo di progetto in termini di valutazioni facili/moderate/difficili. È anche utile almeno considerare lift-and-shift, refactoring e riscrittura. Come puoi vedere, queste migrazioni possono richiedere un grande sforzo. Questa è una parte importante del motivo per cui la pianificazione è così importante.
Ho anche sottolineato alcune buone pratiche di sicurezza e prestazioni. Mi sono anche attenuto ai principi Unix della modularità con la separazione di codice, configurazione e dati.
Ora che abbiamo spostato WordPress, è ora di alzare un po' la posta. Il prossimo articolo di questa serie esamina la containerizzazione di MediaWiki. Una volta che avrai avuto la possibilità di digerirlo, daremo un'occhiata a Request Tracker.
Questa serie è basata su "A Hacker's Guide to Moving Linux Services into Containers" su CrunchTools.com ed è stata ripubblicata con il permesso.