V tomto článku se podíváme na to, jak migrovat instalaci WordPressu z běžné instalace do kontejneru. Pokud jste to přehlédli, v předchozím článku jsme uvedli souhrn obecného procesu, který hodláme použít.
Kontejnerování WordPressu se zdá být zdánlivě snadné. Je to standardní zásobník LAMP, ale existuje několik úskalí, kterým se chceme vyhnout. Kontejnery jsou ve skutečnosti dvě věci:obrazy kontejnerů v klidu a procesy Linuxu za běhu. Pojďme se podívat na obě části – sestavení a spuštění.
Poznámka editora:Pro účely tohoto článku předpokládáme, že své kontejnery budete stavět na Red Hat Enterprise Linux 8 pomocí sestavení podman. Pokyny můžete použít v jiných distribucích nebo s jinými nástroji, mohou však být nutné určité úpravy.
Sestavit
WordPress potřebuje PHP a webový server. Nejběžnější konfigurací je použití Apache (nebo Nginx) s PHP FastCGI Process Manager (php-fpm) a PHP interpretem. Ve skutečnosti lze obraz kontejneru pro obecné účely vytvořit pro téměř jakoukoli aplikaci založenou na PHP, včetně WordPress a MediaWiki. Zde je příklad toho, jak jej vytvořit pomocí 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 image je po vybalení nakonfigurován pro spuštění systemd v kontejner při spuštění. Díky tomu je snadné spustit několik příkazů při instalaci a spolehnout se na odborné znalosti obsažené v distribuci Linuxu. Jak jsem léta tvrdil, kvalita obrazu kontejneru a hygiena dodavatelského řetězce jsou důležitější než absolutně nejmenší jednotlivé obrazy, které dokážeme vyrobit (Tidbits kontejnerů:Může dobrá hygiena dodavatelského řetězce zmírnit základní velikosti obrazu?). Musíme vzít v úvahu celkovou velikost vašeho dodavatelského řetězce, nikoli jednotlivé obrázky, proto jsem zvolil ubi-init obrázek.
Všimněte si, jak jednoduchý je Containerfile. Je to proto, že spoléháme na balírny, že služby spustí správně. Viz také:Záleží na linuxových distribucích stále na kontejnerech?
Je to poměrně jednoduché sestavení, takže přejděme ke složitějším věcem za běhu.
[ Také by se vám mohlo líbit: Přechod z docker-compose na Podman pody ]
Spustit
Stejně jako tradiční služby na tradičních serverech běží naše kontejnery s systemd nám poskytuje pohodlný způsob, jak je spustit, když spouštíme hostitele kontejneru nebo když je kontejner zabit (obnovitelnost v tabulce výše). Pojďme si rozebrat náš soubor systemd unit, abychom lépe porozuměli návrhovým rozhodnutím a některým výhodám spouštění služeb v kontejnerech:
[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
Nejprve si všimněte, že celý tento kontejner spouštíme pouze pro čtení a s –rm možnost, takže je pomíjivá. Kontejner je odstraněn pokaždé, když je zastaven. To nás nutí rozdělit náš kód, konfiguraci a data a uložit je na externí připojení, jinak se ztratí. To nám také dává možnost zabít kontejner, aby se změny konfiguračního souboru nabraly jako normální služba (více o tom později). Apache, PHP FPM a MariaDB běží v kontejneru vedle sebe, což jim pohodlně umožňuje komunikovat přes privátní sokety. U tak jednoduché služby není potřeba škálovat MariaDB a Apache samostatně, takže je není potřeba rozdělovat.
Všimněte si, že jsme rozdělili kód, konfiguraci a data do samostatných adresářů a připojení. Hlavní binární soubory Apache, PHP a PHP FPM pocházejí z httpd-php kontejner image postavený na Red Hat Universal Base Image, zatímco kód WordPress pochází z připojení kódu/wordpressu. V mnoha kontejnerech bude veškerý kód pocházet z obrázku kontejneru (viz Sledování požadavků později). Adresář code/wordpress obsahuje pouze WordPress PHP kód stažený z wordpress.org. Žádné z našich osobních údajů nebo přizpůsobení nejsou uloženy v adresáři code/wordpress. Přesto jsme z něj záměrně udělali samostatný, zapisovatelný svazek, který umožňuje WordPressu, aby se automaticky aktualizoval za běhu. To je v rozporu s typickými osvědčenými postupy pro kontejnery, ale je to velmi pohodlná funkce pro oblíbenou veřejnou webovou službu, která je pod neustálým útokem a často dostává aktualizace zabezpečení. Architektura tímto způsobem nám poskytuje bezdrátové aktualizace, aniž bychom museli znovu vytvářet obrázek kontejneru. Udělat ze služeb co nejméně řidičů je rozhodně užitečné.
Nyní se podívejte na konfigurační řádky. Každý přizpůsobený konfigurační soubor je připojen do kontejneru pouze pro čtení. Jedná se o solidní bezpečnostní upgrade z tradičních LAMP serverů (virtuálních strojů nebo holého kovu). To brání použití některých pluginů WordPress, které se snaží změnit wp-config.php, ale většina systémových administrátorů by je stejně chtěla deaktivovat. To mohlo být proveden pro čtení a zápis, pokud někteří naši uživatelé tyto pluginy skutečně potřebují.
Dále si všimněte datového adresáře. Připojíme tři různé podadresáře. Všechny jsou zapisovatelné:
- data/wp-content – Tento adresář obsahuje naše osobní údaje a přizpůsobení. To zahrnuje věci, jako jsou témata WordPress, pluginy a nahrané soubory (obrázky, videa, mp3 atd.). Je třeba také poznamenat, že se jedná o web WordPress pro více uživatelů (MU), takže zde svá data ukládá více webů. Administrátor WordPress se může přihlásit a v případě potřeby vytvořit nové stránky.
- data/protokoly – Chceme, aby naše protokoly Apache byly mimo kontejner, abychom mohli sledovat přístup/chyby nebo provádět analýzy. Mohli bychom je také použít, kdyby se někdo naboural, a potřebujeme zrekonstruovat, co se stalo. Zde může být užitečná možnost připojení pouze pro zápis.
- data/mariadb – Toto je náš zapisovatelný adresář pro MariaDB. Většina našich tajemství je uložena v databázi a tento adresář má správně nastavena oprávnění pro uživatele/skupinu mysql. To nám poskytuje ekvivalentní izolaci na úrovni procesu v kontejneru, podobnou běžnému serveru LAMP. Došlo k mírnému upgradu zabezpečení, protože tato instance MariaDB obsahuje pouze data WordPress. Hackeři se nemohou nabourat do WordPressu a dostat se na naši Wiki ani Request Tracker, které mají své vlastní samostatné instance MariaDB.
Dále se podívejme na –tempfs montuje. Ty umožňují systemd správně fungovat v kontejneru pouze pro čtení. Všechna data zapsaná do těchto připojení budou automaticky smazána, když se kontejner zastaví. Díky tomu je vše mimo naše poutače zcela pomíjivé. Pro zachycení /var/log/messages lze provést další úpravy nebo v případě potřeby jiné protokoly.
Pro zálohování v rámci WordPress se spoléháme na UpdraftPlus. UpdraftPlus nabízí výhodu zálohování všeho z webu WordPress MU, včetně témat, pluginů, souborů a databáze. Může dokonce poslat zálohu do vzdáleného úložiště, jako je Dropbox nebo pCloud (prostřednictvím WebDav). Toto je běžný návrhový vzor u aplikací vyšší úrovně, jako je WordPress. Databáze, CRM atd. budou mít často své vlastní zálohovací nástroje nebo ekosystémy zálohovacího softwaru třetích stran. Spoléhat se na tento existující software je v kontejnerech stále užitečné.
[ Začínáte s kontejnery? Podívejte se na tento bezplatný kurz. Nasazení kontejnerových aplikací:technický přehled. ]
Zabalit
Trvalo mi velmi dlouho, než jsem tyto aplikace konečně dostal do kontejneru, ale úsilí se vyplatilo. Je dobré přemýšlet o tomto druhu projektu z hlediska hodnocení snadné/střední/obtížné. Je také užitečné alespoň zvážit zvednutí a posunutí, refaktorování a přepisování. Jak vidíte, tyto migrace mohou vyžadovat velké úsilí. To je velká část toho, proč je plánování tak důležité.
Zdůraznil jsem také některé dobré bezpečnostní a výkonnostní postupy. Držel jsem se také unixových zásad modularity s oddělením kódu, konfigurace a dat.
Nyní, když jsme přesunuli WordPress, je čas trochu zvýšit ante. Další článek této série se zabývá kontejnerizací MediaWiki. Jakmile budete mít příležitost to strávit, dáme si švih na Request Tracker.
Tato série je založena na „Hacker's Guide to Moveing Linux Services into Containers“ na CrunchTools.com a je znovu publikována se svolením.