Pada artikel ini, kita akan melihat bagaimana cara memigrasi instalasi WordPress dari instalasi normal ke dalam container. Jika Anda melewatkannya, dalam artikel sebelumnya kami memberikan ikhtisar proses umum yang ingin kami gunakan.
Containerizing WordPress tampaknya sangat mudah. Ini adalah tumpukan LAMP standar, tetapi ada beberapa jebakan yang ingin kami hindari. Kontainer sebenarnya adalah dua hal:Gambar kontainer saat istirahat dan proses Linux saat runtime. Mari kita lihat kedua bagian—membangun dan menjalankan.
Catatan Editor:Untuk tujuan artikel ini, kami berasumsi Anda akan membuat container di Red Hat Enterprise Linux 8 menggunakan podman build. Anda mungkin dapat menggunakan petunjuk pada distribusi lain atau dengan rantai alat lain, namun, beberapa modifikasi mungkin diperlukan.
Bangun
WordPress membutuhkan PHP dan server web. Konfigurasi yang paling umum adalah menggunakan Apache (atau Nginx) dengan PHP FastCGI Process Manager (php-fpm) dan juru bahasa PHP. Faktanya, image container tujuan umum dapat dibuat untuk hampir semua aplikasi berbasis PHP, termasuk WordPress dan MediaWiki. Berikut ini contoh cara membuatnya dengan 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 gambar dikonfigurasi di luar kotak untuk menjalankan systemd di wadah saat dijalankan. Hal ini memudahkan untuk menjalankan beberapa perintah saat menginstal dan mengandalkan keahlian materi pelajaran yang tertanam dalam distribusi Linux. Seperti yang telah saya perdebatkan selama bertahun-tahun, kualitas gambar kontainer dan kebersihan rantai pasokan lebih penting daripada gambar individu terkecil mutlak yang dapat kami hasilkan (Intisari Kontainer:Bisakah Kebersihan Rantai Pasokan yang Baik Mengurangi Ukuran Gambar Dasar?). Kami perlu mempertimbangkan ukuran total rantai pasokan Anda, bukan gambar individual, jadi saya memilih ubi-init gambar.
Perhatikan betapa sederhananya Containerfile itu. Itu karena kami mengandalkan pembuat paket untuk memulai layanan dengan benar. Lihat juga:Apakah Distribusi Linux Masih Penting dengan Container?
Ini adalah build yang cukup sederhana, jadi mari beralih ke hal-hal rumit saat runtime.
[ Anda mungkin juga menyukai: Berpindah dari docker-compose ke Podman pod ]
Jalankan
Seperti layanan tradisional, pada server tradisional, menjalankan container kami dengan systemd memberi kita cara mudah untuk memulainya saat kita mem-boot host kontainer kita atau saat kontainer dimatikan (dapat dipulihkan pada tabel di atas). Mari membedah file unit systemd kita untuk lebih memahami keputusan desain dan beberapa keuntungan menjalankan layanan dalam 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
Pertama, perhatikan bahwa kami menjalankan seluruh wadah ini sebagai hanya-baca dan dengan –rm pilihan, membuatnya fana. Wadah dihapus setiap kali dihentikan. Ini memaksa kita untuk membagi kode, konfigurasi, dan data kita dan menyimpannya di mount eksternal, atau akan hilang. Ini juga memberi kita kemampuan untuk mematikan wadah untuk mengambil perubahan file konfigurasi seperti layanan normal (lebih lanjut tentang ini nanti). Apache, PHP FPM, dan MariaDB berjalan berdampingan dalam container, memungkinkan mereka berkomunikasi melalui soket pribadi dengan nyaman. Untuk layanan yang begitu sederhana, tidak perlu menskalakan MariaDB dan Apache secara terpisah, jadi tidak perlu memisahkannya.
Perhatikan bahwa kami membagi kode, konfigurasi, dan data ke dalam direktori terpisah dan mengikat mount. Binari Apache, PHP, dan PHP FPM utama berasal dari httpd-php container image dibangun di atas Red Hat Universal Base Image, sedangkan kode WordPress berasal dari kode/wordpress bind mount. Di banyak wadah, semua kode akan berasal dari gambar wadah (lihat Pelacak Permintaan nanti). Direktori code/wordpress hanya menampung kode WordPress PHP yang diunduh dari wordpress.org. Tidak ada data pribadi atau penyesuaian kami yang disimpan di direktori kode/wordpress. Namun, kami sengaja membuatnya menjadi pengikat yang terpisah dan dapat ditulis untuk memungkinkan WordPress memperbarui dirinya sendiri secara otomatis saat runtime. Ini bertentangan dengan praktik terbaik tipikal dengan container tetapi fitur yang sangat nyaman untuk layanan web populer yang menghadap publik yang terus-menerus diserang dan sering menerima pembaruan keamanan. Merancangnya dengan cara ini memberi kami pembaruan melalui udara tanpa harus membangun kembali gambar kontainer. Membuat layanan tanpa pengemudi mungkin sangat berguna.
Sekarang, lihat baris konfigurasi. Setiap file konfigurasi yang disesuaikan diikat ke dalam wadah hanya-baca. Ini adalah peningkatan keamanan yang solid dari server LAMP tradisional (mesin virtual atau bare metal). Ini mencegah penggunaan beberapa plugin WordPress yang mencoba mengubah wp-config.php, tetapi sebagian besar sysadmin tetap ingin menonaktifkannya. Ini bisa dibuat baca-tulis jika beberapa pengguna kami benar-benar membutuhkan plugin ini.
Selanjutnya, perhatikan direktori data. Kami mengikat mount tiga subdirektori yang berbeda. Semuanya dapat ditulis:
- data/wp-content – Direktori ini memiliki data pribadi dan penyesuaian di dalamnya. Ini termasuk hal-hal seperti tema WordPress, plugin, dan file yang diunggah (gambar, video, mp3, dll.). Perlu juga dicatat bahwa ini adalah situs WordPress Multi-User (MU), jadi banyak situs menyimpan datanya di sini. Administrator WordPress dapat masuk dan membuat situs baru jika perlu.
- data/log – Kami ingin log Apache kami berada di luar wadah sehingga kami dapat melacak akses/kesalahan atau melakukan analitik. Kami juga dapat menggunakan ini jika seseorang meretas, dan kami perlu merekonstruksi apa yang terjadi. Opsi pemasangan hanya-tulis mungkin berguna di sini.
- data/mariadb – Ini adalah direktori kami yang dapat ditulis untuk MariaDB. Sebagian besar rahasia kami disimpan dalam database, dan direktori ini memiliki izin yang ditetapkan dengan benar untuk pengguna/grup mysql. Ini memberi kami isolasi tingkat proses yang setara dalam wadah, mirip dengan server LAMP normal. Ada sedikit peningkatan keamanan karena instans MariaDB ini hanya memiliki data WordPress di dalamnya. Peretas tidak dapat membobol WordPress dan mengakses Wiki atau Pelacak Permintaan kami, yang memiliki instance MariaDB mereka sendiri.
Selanjutnya, mari kita lihat –tempfs tunggangan. Ini mengaktifkan systemd untuk berjalan dengan baik dalam wadah hanya-baca. Setiap data yang ditulis ke tunggangan ini akan dihapus secara otomatis saat penampung berhenti. Ini membuat segala sesuatu di luar pengikatan kami benar-benar fana. Modifikasi lain dapat dilakukan untuk menangkap /var/log/messages atau log lain jika diinginkan.
Untuk backup dalam WordPress, kami mengandalkan UpdraftPlus. UpdraftPlus menawarkan keuntungan mencadangkan semuanya dari situs WordPress MU, termasuk tema, plugin, file, dan database. Itu bahkan dapat mendorong cadangan ke penyimpanan jarak jauh seperti Dropbox atau pCloud (melalui WebDav). Ini adalah pola desain umum dengan aplikasi tingkat tinggi seperti WordPress. Seringkali, database, CRM, dll. Akan memiliki utilitas cadangan sendiri atau ekosistem perangkat lunak cadangan pihak ketiga. Mengandalkan perangkat lunak yang ada ini masih berguna dalam wadah.
[ Memulai container? Lihat kursus gratis ini. Menyebarkan aplikasi kemas:Tinjauan teknis. ]
Selesaikan
Butuh waktu yang sangat lama bagi saya untuk akhirnya mendapatkan aplikasi ini dalam wadah, tetapi upaya itu membuahkan hasil. Ada baiknya untuk memikirkan proyek semacam ini dalam hal peringkat mudah/sedang/sulit. Ini juga berguna setidaknya mempertimbangkan lift-and-shift, refactoring, dan menulis ulang. Seperti yang Anda lihat, migrasi ini membutuhkan banyak usaha. Itulah sebagian besar alasan mengapa perencanaan sangat penting.
Saya juga menekankan beberapa praktik keamanan dan kinerja yang baik. Saya juga berpegang pada prinsip modularitas Unix dengan pemisahan kode, konfigurasi, dan data.
Sekarang kita telah memindahkan WordPress, saatnya untuk menaikkan taruhan sedikit. Artikel berikutnya dalam seri ini membahas tentang penampung MediaWiki. Setelah Anda memiliki kesempatan untuk mencerna yang satu itu, kami akan mencoba Request Tracker.
Seri ini didasarkan pada "Panduan Peretas untuk Memindahkan Layanan Linux ke Wadah" di CrunchTools.com dan diterbitkan ulang dengan izin.