Kiedyś to było…
Gdy zaczynałem swoją przygodę z programowaniem, to najczęściej spotykanym przeze mnie podejściem przy rozwijaniu aplikacji, nie tylko opartych na WordPressie, ale generalnie aplikacji zbudowanych na PHP był XAMPP (Apache + MariaDB + PHP + Perl). Niekiedy rekomendowano instalację PHP, MySQL/MariaDB i serwer WWW (zwykle Apache lub Nginx), bezpośrednio na lokalnych maszynach.
Uruchomienie aplikacji z wykorzystaniem XAMPP jest łatwe, szybkie i możliwe na każdym popularnym systemie operacyjnym. Wykorzystanie XAMPP nie wymaga dodatkowej konfiguracji i nie zdarzyło mi się mieć z nim większych problemów. Większy problem widzę w podejściu z bezpośrednią instalacją PHP, bazy danych i serwera WWW na maszynie. Szczególnie problematyczne będzie to, w przypadku chęci replikacji środowska na innej maszynie. Ręczna instalacja kilku komponentów jest bardziej czasochłonna niż instalacja XAMPP przy np. wdrażaniu nowej osoby do zespołu.
W tym wpisie przedstawię Ci trzeci sposób na lokalny development – WordPressa w kontenerach. Do przygotowania środowiska developerskiego wykorzystam gotowe obrazy dockerowe i narzędzie Docker Compose. Mimo niewątpliwych zalet XAMPP, jego możliwości są ograniczone. Przede wszystkim, XAMPP z góry definiuje wykorzystany serwer WWW (Apache). Po drugie, w przypadku potrzeby aktualizacji jednego z elementów XAMPP, konieczne jest oczekiwanie na nową wersję samego narzędzia. Kolejnym problemem jest deployment aplikacji. Dobrze przygotowane środowisko w kontenerach może być replikowalne na środowisku produkcyjnym. Dzięki temu, lokalny development odbywa się na środowisku maksymalnie zbliżonym do produkcyjnego.
Wykorzystane obrazy
Najważniejszym obrazem jest obraz zawierający WordPressa. Oczywiście nic nie stoi na przeszkodzie w ręcznym przygotowaniu obrazu. Można w tym celu pobrać paczkę WordPressa z oficjalnej strony i dodać do obrazu wykorzystując jako obraz bazowy obraz wybranej dystrybucji Linuxa. Dodatkowo konieczne będzie zainstalowanie PHP oraz konfiguracja wybranego serwera WWW. Jednak zasadnicze pytanie brzmi: „po co?”. WordPress jest dystrybuowany, między innymi, w postaci gotowego obrazu Dockerowego. Do dyspozycji mamy zarówno obrazy wykorzystujące serwer WWW Apache, jak i obrazy bazujące na NGINX. W tym wpisie wykorzystam oficjalny obraz WordPressa (Apache), ale nie widzę przeszkód, by dać szansę alternatywie od Bitnami (NGINX).
Do uruchomienia WordPressa konieczne będzie uruchomienie bazy danych. WordPress może działać z MySQL lub MariaDB. W zależności od preferencji, wybierz odpowiedni dla siebie system zarządzania bazą danych. W moim przypadku wybór padł na MySQL, ale decyzja ta nie jest podyktowana żadnym szczególnym czynnikiem.
Trzecim obrazem, który wykorzystałem do przygotowania środowiska developerskiego jest phpMyAdmin. Oczywiście nic nie stoi na przeszkodzie, aby wejść do kontenera z MySQL i bezpośrednio w nim wykonywać zapytania do bazy danych. Jednakże zdecydowanie wygodniej i szybciej jest skorzystać z dedykowanego UI.
Gdybyś jednak chciał/a skorzystać z phpMyAdmin na środowisku produkcyjnym, to upewnij się, że jest on dobrze zabezpieczony przed nieautoryzowanym dostępem! Pamiętaj również o ograniczeniu dostępu do danych do absolutnego minimum dla poszczególnych użytkowników. Otwarty dostęp do phpMyAdmin był furtką wykorzystaną do kradzieży danych z jednego z dużych serwisów e-commerce. Możesz również domyślnie wyłączyć phpMyAdmin i uruchamiać go tylko na chwilę, w razie potrzeby.
Docker Compose
Mając już listę potrzebnych obrazów, czas przejść do praktyki. Przeanalizuj fragment kodu poniżej, zapoznaj się z definicją skonteneryzowanego środowiska dla WordPressa:
version: '3.9'
services:
db:
image: mysql:8.0
command: --default-authentication-plugin=mysql_native_password
restart: always
env_file: .env
environment:
- MYSQL_DATABASE=$MYSQL_DATABASE
- MYSQL_USER=$MYSQL_USER
- MYSQL_PASSWORD=$MYSQL_PASSWORD
- MYSQL_ROOT_PASSWORD=$MYSQL_ROOT_PASSWORD
ports:
- 3306:3306
healthcheck:
test: mysqladmin ping -h localhost -P 3306 -u root -p$$MYSQL_ROOT_PASSWORD
interval: 5s
timeout: 10s
retries: 3
volumes:
- db_data:/var/lib/mysql
phpmyadmin:
image: phpmyadmin:5.2.1
restart: always
ports:
- 8080:80
environment:
- PMA_ARBITRARY=1
depends_on:
- db
wordpress:
image: wordpress:6.2.2
volumes:
- $PWD/wp_data:/var/www/html
ports:
- 80:80
restart: always
env_file: .env
environment:
- WORDPRESS_DB_HOST=db
- WORDPRESS_DB_USER=$MYSQL_USER
- WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
- WORDPRESS_DB_NAME=$MYSQL_DATABASE
depends_on:
- db
- phpmyadmin
volumes:
db_data:
wp_data:
Aby rozpocząć pracę z przedstawionym środowiskiem, skopiuj powyższy fragment kodu i zapisz go w pliku docker-compose.yml
. Alternatywnie, możesz pobrać powyższy kod z tego Gista. Dodatkowo, konieczne będzie utworzenie pliku .env
w miejscu, gdzie znajduje się plik docker-compose.yml
. Plik przechowuje wartości zmiennych środowiskowy wykorzystanych w definicjach kontenerów. W pliku .env
zdefiniuj wartości dla następujących zmiennych:
MYSQL_ROOT_PASSWORD=
MYSQL_DATABASE=
MYSQL_USER=
MYSQL_PASSWORD=
Po przygotowaniu plików, uruchom środowisko poleceniem docker-compose up -d
. Do zatrzymania środowiska możesz wykorzystać polecenie docker-compose down
.
Następnie, w przeglądarce udaj się pod adres http://localhost
i przeprowadź instalację WordPressa. Jeżeli potrzebujesz dostępu do phpMyAdmin, to jest on dostępny pod adresem http://localhost:8080
.
Zalety proponowanego środowiska
Omawiając zaproponowaną konfigurację chciałbym na chwilę zatrzymać się przy konfiguracji wolumenu dla obrazu WordPressa. Dzięki wskazaniu na $PWD/wp_data
, po uruchomieniu kontenerów, wszystkie pliki WordPressa będą dostępne w katalogu wp_data
w miejscu, gdzie znajduje się plik docker-compose.yml
. Dzięki temu, w łatwy sposób można rozwijać i modyfikować własne wtyczki oraz motywy. Zmiany wprowadzone w kodzie wtyczek i motywów widoczne są od razu po zapisaniu pliku i odświeżeniu strony. Nie ma konieczności restartu kontenera ani manualnego kopiowania czy przenoszenia plików.
Tak przygotowane środowisko może zostać dostosowane do pracy z Gitem. W tym celu konieczne będzie zdefiniowanie odpowiedniej konfiguracji .gitignore
. W repozytorium powinny znaleźć się tylko pliki przygotowanych przez ciebie wtyczek i motywów. Nie ma sensu przechowywać w repozytorium pozostałych plików WordPressa. Wyjątkiem jest sytuacja, gdzie w tych plikach wprowadzone zostały jakieś modyfikacje. Możesz dołączyć do repozytorium również takie pliki jak .htaccess
. Przykładowy plik .gitignore
, który uwzględnia tylko wskazane wtyczki i motywy wygląda następująco:
wp_data/wp-admin
wp_data/wp-includes
wp_data/*.*
wp_data/wp-content/uploads/
wp_data/wp-content/upgrade/
wp_data/wp-content/*.php
wp_data/wp-content/plugins/*
!wp_data/wp-content/plugins/[plugin_name]/
wp_data/wp-content/themes/*
!wp_data/wp-content/themes/[theme_name]/
W miejsce plugin_name
i theme_name
wstaw nazwę wtyczki lub motywu. Dla każdej wtyczki i motywu należy dodać osobny wyjątek.
Tak skonfigurowane środowisko, nie tylko pozwala komfortowo korzystać z Gita w projekcie, ale też powoduje że przy powrocie do pracy nad projektem jego uruchomienie trwa moment. Wykorzystanie zaproponowanej konfiguracji wolumenów powoduje, że restart środowiska developerskiego nie powoduje utraty danych. Po ponownym uruchomieniu środowiska, jego stan pozostanie niezmieniony.
Tak przygotowane środowisko pozwala też na szybkie testowanie aplikacji z danymi z innych środowisk. W tym celu udaj się pod adres http://localhost:8080
i uzupełnij pola username
i password
, a następnie zatwierdź formularz. Pole server
może pozostać puste. Po zalogowaniu się będziesz miał/a dostęp do bazy danych uprzednio zainstalowanej instancji WordPressa. W tym miejscu możesz zaimportować bazę danych z innego środowiska lub wprowadzić zmiany w bazie danych.
Podsumowanie
Mam nadzieję, że zaproponowane przeze mnie środowisko będzie dla Ciebie przydatne. Zachęcam do proponowania usprawnień i zmian w komentarzach. Nie zapomnij zajrzeć do materiałów dodatkowych i udostępnić artykułu w mediach społecznościowych 😁
Materiały dodatkowe i źródła
- WordPress with NGINX packaged by Bitnami
- Official WordPress Docker Image
- MariaDB vs. MySQL
- Docker dla WordPress – kompletny poradnik
- Czy z Morele.net dane wyciekły dwukrotnie? Jeden z atakujących się ujawnił
- WordPress samples
- Quickstart: Compose and WordPress
- How to Install WordPress on Docker (Windows, macOS, and Linux)
- Docker dla WordPress – kompletny poradnik
- Can Docker replace XAMPP?
- What is a LAMP stack?
Świetny poradnik!
Dla kogoś kto potrzebuje wystawić środowisko na szybko dobrym rozwiązaniem może też być LocalWP.
Dziękuję za miłe słowa!
LocalWP wygląda bardzo ciekawie, szczególnie że zakres możliwości jest naprawdę szeroki. Chętnie kiedyś przetestuję to narzędzie 🙂