Meskipun butuh waktu lama untuk mendapatkan motivasi, saya akhirnya mengemas beberapa layanan Linux pribadi. Saya telah mendokumentasikan proyek dalam seri ini. Dalam artikel ini, kami akan membawa Anda melalui contoh terakhir, Request Tracker.
Untuk memulai, kami melihat beberapa prinsip umum untuk memigrasikan aplikasi ke container. Kemudian kami melihat penampung WordPress, dan selanjutnya, kami membahas pemindahan MediaWiki ke dalam penampung. Proyek itu sedikit lebih terlibat daripada yang pertama, dengan penambahan penjadwalan tugas. Dalam artikel terakhir ini, kita akan mempertimbangkan migrasi yang jauh lebih kompleks. Secara khusus, kita akan melihat Request Tracker. Layanan ini mungkin yang paling rumit karena build dan run keduanya cukup canggih.
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.
Memindahkan Pelacak Permintaan
Bangun
Tidak seperti WordPress dan MediaWiki, yang berjalan pada gambar satu lapis di atas gambar dasar, Request Tracker menggunakan dua lapisan di atas gambar dasar. Mari kita lihat setiap lapisan dan lihat mengapa kita melakukannya dengan cara ini.
Lapisan pertama dibangun sangat mirip dengan httpd-php gambar. Gambar ini menambahkan layanan yang diperlukan untuk aplikasi web berbasis Perl. Kami menyertakan Apache, modul FastCGI, Perl, MariaDB, cron, dan beberapa utilitas dasar untuk pemecahan masalah:
DARI registry.access.redhat.com/ubi8/ubi-initMAINTAINER fatherlinux <[email protected]>Jalankan yum install -y httpd mod_fcgid perl mariadb-server mariadb crontabs cronie iputils net-tools; yum clean allRUN systemctl aktifkan mariadbRUN systemctl aktifkan httpdRUN systemctl aktifkan postfixRUN systemctl nonaktifkan systemd-update-utmp.serviceENTRYPOINT ["/sbin/init"]CMD ["/sbin/init"]
Lapisan kedua adalah di mana segala sesuatunya menjadi sangat canggih. Request Tracker menggunakan banyak modul Perl dari CPAN. Banyak dari modul ini dikompilasi dengan gcc dan membutuhkan waktu lama untuk menginstal. Butuh banyak pekerjaan untuk menyelesaikan semua dependensi ini agar Request Tracker berhasil diinstal. Secara historis, kami akan menangkap ini dalam skrip di suatu tempat, tetapi dengan wadah, kami dapat memiliki semuanya dalam satu Containerfile. Sangat nyaman.
[ Anda mungkin juga menikmati: 6 panduan untuk membuat container aman ]
Hal berikutnya yang harus Anda perhatikan tentang file ini adalah bahwa ini adalah build multi-tahap. Podman dan Buildah benar-benar dapat melakukan build multi-tahap, dan mereka bisa sangat berguna untuk aplikasi seperti Request Tracker. Kami bisa saja mengikat-mount di direktori, seperti yang kami lakukan dengan WordPress dan MediaWiki, tetapi kami memilih build multi-tahap sebagai gantinya. Ini akan memberi kita portabilitas dan kecepatan jika kita perlu membangun kembali aplikasi di tempat lain.
Build multi-tahap dapat dianggap sebagai menangkap server pengembangan dan server produksi dalam satu file build. Secara historis, server pengembangan sebenarnya yang paling sulit untuk diotomatisasi. Sejak awal CFEngine pada pertengahan 1990-an, pengembang menolak untuk menggunakan kontrol versi dan menambahkan apa pun yang mereka inginkan ke server pengembangan untuk membuatnya berfungsi. Seringkali, mereka bahkan tidak tahu apa yang mereka tambahkan untuk membuat sebuah bangunan selesai. Ini sebenarnya rasional ketika Anda memiliki server berumur panjang yang didukung dengan baik, tetapi selalu menyebabkan rasa sakit ketika administrator sistem harus "mengupgrade server dev." Merupakan mimpi buruk untuk membuat build berfungsi di server baru dengan sistem operasi baru.
Dengan build multi-tahap, kami menangkap semua instruksi build dan bahkan lapisan cache yang dibuat. Kami dapat membangun kembali server virtual pengembangan ini di mana saja kami suka.
DARI registry.access.redhat.com/ubi8/ubi-initFROM localhost/httpd-perl AS localhost/rt4-buildMAINTAINER fatherlinux <[email protected]>Jalankan yum install -y expat-devel gcc; yum clean allRUN cpan -i CPANRUN cpan -i -f GnuPG::InterfaceRUN cpan -i DBIx::SearchBuilder \ExtUtils::Command::MM \Text::WikiFormat \Devel::StackTrace \Apache::Session \Module::Segarkan \HTML::TreeBuilder \HTML::FormatText::WithLinks \HTML::FormatText::WithLinks::AndTables \Data::GUID \CGI::Cookie \DateTime::Format::Natural \Text::Password::Dapat diucapkan \UNIVERSAL::require \JSON \DateTime \Net::CIDR \CSS::Minifier::XS \CGI \Devel::GlobalDestruction \Text::Wrapper \Net::IP \HTML::RewriteAttributes \Log::Dispatch \Plack \Regexp::Common::net::CIDR \Scope::Upper \CGI::Emulate::PSGI \HTML::Mason::PSGIHandler \HTML::Scrubber \HTML::Entities \HTML::Mason \ File::ShareDir \Mail::Header \XML::RSS \List::MoreUtils \Plack::Handler::Starlet \IPC::Run3 \Email::Address \Role::Basic \MIME::Entity \Regexp::IPv6 \Convert::Color \Business::Hours \Symbol::Global::Name \MIME::Types \Locale::Maketext::Fuzzy \Tree::Simple \Clone \HTML::Dikutip \Data::Page ::Pageset \Text::Dikutip \DateTime::Locale \HTTP::Messa ge \Crypt::Eksblowfish \Data::ICal \Locale::Maketext::Lexicon \Time::ParseDate \Mail::Mailer \Email::Address::List \Date::Extract \CSS::Squish \Class::Accessor::Fast \LWP::Simple \Module::Versions::Report \Regexp::Common \Date::Manip \CGI::PSGI \JavaScript::Minifier::XS \FCGI \PerlIO::eol \GnuPG ::Interface \LWP::UserAgent >=6.02 \LWP::Protocol::https \String::ShellQuote \Crypt::X509RUN cd /root/rt-4.4.4;make testdeps;make install# DeployFROM localhost/httpd -perl AS localhost/rt:4.4.4RUN yum install -y postfix mailx;yum clean allCOPY --from=localhost/rt4-build /opt/rt4 /opt/rt4COPY --from=localhost/rt4-build /usr/lib64 /perl5 /usr/lib64/perl5COPY --from=localhost/rt4-build /usr/share/perl5 /usr/share/perl5COPY --from=localhost/rt4-build /usr/local/share/perl5 /usr/local /share/perl5COPY --from=localhost/rt4-build /usr/local/lib64/perl5/ /usr/local/lib64/perl5/RUN chown -R root.bin /opt/rt4/lib;chown -R root. apache /opt/rt4/etcENTRYPOINT ["/sbin/init"]CMD ["/sbin/init"]
Tahap kedua dalam pembangunan multi-tahap ini membangun server produksi virtual. Dengan membaginya menjadi tahap kedua, kita tidak perlu menginstal alat pengembangan seperti gcc atau ekspat-devel dalam gambar produksi akhir. Ini mengurangi ukuran gambar kami dan mengurangi ukuran rantai pasokan perangkat lunak dalam layanan yang terpapar jaringan. Ini juga berpotensi mengurangi kemungkinan seseorang melakukan sesuatu yang buruk dengan penampung kami, jika mereka meretasnya.
Kami hanya menginstal utilitas email pada tahap kedua ini, yang mendefinisikan lapisan kedua dari gambar produksi kami untuk Request Tracker. Kita dapat menginstal utilitas ini di httpd-perl lapisan, tetapi banyak aplikasi Perl lainnya tidak memerlukan utilitas email.
Kenyamanan lain dari pembangunan multi-tahap adalah kita tidak perlu membangun kembali semua modul Perl tersebut setiap kali kita ingin memperbarui juru bahasa Perl, Apache, atau MariaDB untuk patch keamanan.
Jalankan
Sekarang, seperti WordPress dan MediaWiki, mari kita lihat beberapa trik yang kita gunakan saat runtime:
[Unit]Description=Podman container – rt.fatherlinux.comDocumentation=man:podman-generate-systemd(1)[Service]Type=simpleExecStart=/usr/bin/podman run -i --rm - -read-only -p 8081:8081 --nama rt.fatherlinux.com \-v /srv/rt.fatherlinux.com/code/reminders:/root/reminders:ro \-v /srv/rt.fatherlinux.com /config/rt.fatherlinux.com.conf:/etc/httpd/conf.d/rt.fatherlinux.com.conf:ro \-v /srv/rt.fatherlinux.com/config/MyConfig.pm:/root/ .cpan/CPAN/MyConfig.pm:ro \-v /srv/rt.fatherlinux.com/config/RT_SiteConfig.pm:/opt/rt4/etc/RT_SiteConfig.pm:ro \-v /srv/rt.fatherlinux. com/config/root-crontab:/var/spool/cron/root:ro \-v /srv/rt.fatherlinux.com/config/aliases:/etc/aliases:ro \-v /srv/rt.fatherlinux. com/config/main.cf:/etc/postfix/main.cf:ro \-v /srv/rt.fatherlinux.com/data/mariadb:/var/lib/mysql:Z \-v /srv/rt. fatherlinux.com/data/logs/httpd:/var/log/httpd:Z \-v /srv/rt.fatherlinux.com/data/logs/rt4:/opt/rt4/var:Z \-v /srv/ rt.fatherlinux.com/data/backups:/root/.backups:Z \--tmpfs /etc \--tm pfs /var/log/ \--tmpfs /var/tmp \--tmpfs /var/spool \--tmpfs /var/lib \localhost/rt:latestExecStop=/usr/bin/podman stop -t 3 rt.fatherlinux .comExecStopAfter=/usr/bin/podman rm -f rt.fatherlinux.comRestart=always[Install]WantedBy=multi-user.target Seperti MediaWiki, semua file konfigurasi di-bind-mount dalam read-only, memberi kami peningkatan keamanan yang solid. Terakhir, direktori data bersifat baca-tulis, sama seperti wadah kami yang lain. Satu pengamatan sederhana:Kami masih mengikat mount beberapa kode ke dalam gambar untuk Pengingat , yang merupakan kumpulan skrip kecil yang dibuat sendiri yang mengirim email dan menghasilkan tiket untuk entri mingguan, bulanan, dan tahunan.
Analisis lebih lanjut
Mari kita bahas beberapa topik terakhir yang tidak spesifik untuk salah satu layanan Linux kemas kami.
Dapat dipulihkan
Recoverability adalah sesuatu yang harus kita pertimbangkan dengan hati-hati. Dengan menggunakan systemd , kami mendapatkan pemulihan yang solid, setara dengan layanan Linux biasa. Perhatikan systemd memulai ulang layanan saya tanpa mengedipkan mata:
podman membunuh -a55299bdfebea23db81f0277d45ccd967e891ab939ae3530dde155f550c18bda987a34fb86f854ccb86d9be46b5fe94f6e0e15322f5301e5e66c396195480047aC8092d
Lihat itu! Layanan yang dimulai ulang:
podman pscontainer ID commage perintah dibuat port status nama33a8f9286cee localhost/httpd-php:terbaru/sbin/init 1 detik yang lalu kurang dari satu detik 0.0.0.0:80->80/tcp wordpress.runchTools. com37dd6d4393af localhost/rt:4.4.4 /sbin/init 1 detik yang lalu Naik Kurang dari satu detik yang lalu 0.0.0.0:8081->8081/tcp rt.fatherlinux.come4cc410680b1 localhost/httpd- php lalu Naik Kurang dari sedetik yang lalu 0.0.0.0:8080->80/tcp learn.fatherlinux.com Tips dan trik
Ini cukup berguna untuk membuat perubahan file konfigurasi. Kita cukup mengedit file konfigurasi pada host container atau menggunakan sesuatu seperti Ansible dan mematikan semua container dengan podman kill -a memerintah. Karena kami menggunakan systemd , itu akan menangani restart layanan dengan anggun. Ini sangat nyaman.
Mungkin sulit untuk menjalankan perangkat lunak di dalam wadah, terutama jika Anda ingin menjalankannya hanya-baca. Anda membatasi proses dengan cara yang belum tentu dirancang. Oleh karena itu, berikut beberapa tips dan triknya.
Pertama, ini berguna untuk menginstal beberapa utilitas standar di wadah Anda. Dalam panduan ini, kami menginstal ip-utils dan net-tools sehingga kami dapat memecahkan masalah kontainer kami. Misalnya, dengan Request Tracker, saya harus memecahkan masalah entri berikut di /etc/aliases , yang menghasilkan tiket dari email:
profesional: "|/opt/rt4/bin/rt-mailgate --queue 'Profesional' --action sesuai --url http://localhost:8081/"
Alat curl , ping , dan netstat semuanya sangat berguna karena kami juga menggunakan DNS eksternal dan Cloudflare.
Selanjutnya adalah podman diff , yang saya gunakan secara ekstensif untuk menjalankan container sebagai read-only. Anda dapat menjalankan wadah dalam mode baca-tulis dan terus-menerus memeriksa podman diff untuk melihat file apa yang telah berubah. Ini contohnya:
podman diff learn.fatherlinux.comC /varC /var/spoolC /var/spool/cronA /var/spool/cron/rootC /var/wwwC /var/www/htmlA /var/www/html/ belajar.fatherlinux.comC /rootA /root/.backups
Pindah ke Kubernetes
Perhatikan bahwa Podman akan memberi tahu kita file mana yang telah berubah sejak container dimulai. Dalam hal ini, setiap file yang kami pedulikan ada di tmpfs atau bind mount. Ini memungkinkan kami menjalankan penampung ini sebagai hanya-baca.
Melihat Kubernetes dengan seksama adalah langkah alami berikutnya. Menggunakan perintah seperti podman generate kube akan membuat kita menjadi bagian dari jalan ke sana, tetapi kita masih perlu mencari cara untuk mengelola volume persisten dan cadangan pada volume persisten tersebut. Untuk saat ini, kami telah memutuskan bahwa Podman + systemd memberikan dasar yang bagus. Semua pekerjaan yang telah kami lakukan dengan memisahkan kode, konfigurasi, dan data diperlukan untuk membawa kami ke Kubernetes.
Catatan tentang lingkungan
Lingkungan saya adalah mesin virtual tunggal yang berjalan di Linode.com dengan RAM 4GB, dua CPU, dan penyimpanan 80GB. Saya dapat mengunggah gambar kustom saya sendiri dari RHEL 8 untuk dijadikan sebagai wadah host. Selain mengatur nama host dan mengarahkan DNS melalui Cloudflare, saya benar-benar tidak perlu membuat perubahan lain pada host. Semua data penting ada di /srv , yang akan membuatnya sangat mudah untuk diganti jika gagal. Terakhir, /srv direktori pada host penampung telah dicadangkan sepenuhnya.
Jika Anda tertarik untuk melihat file konfigurasi dan struktur direktori /srv , saya telah menyimpan kode di sini di GitHub saya.
Bias
Seperti semua orang, saya memiliki bias, dan saya pikir adil untuk mengungkapkannya. Saya menjabat sebagai Administrator Sistem Linux untuk sebagian besar karir saya sebelum datang ke Red Hat. Saya memiliki bias terhadap Linux, dan khususnya terhadap Red Hat Enterprise Linux. Saya juga cenderung ke arah otomatisasi dan psikologi tentang cara membuat robot itu dapat diakses oleh kontributor reguler.
Salah satu frustrasi saya yang paling awal sebagai sysadmin adalah bekerja di tim dengan 1000 server web Linux (melakukan eCard di web 1.0) di mana dokumentasi tentang bagaimana berkontribusi pada otomatisasi benar-benar buram dan tidak ada alasan yang didokumentasikan mengapa segala sesuatunya seperti itu. . Kami memiliki otomatisasi yang hebat, tetapi tidak ada yang mempertimbangkan psikologi tentang cara memperkenalkan orang baru ke dalamnya. Itu tenggelam-atau-berenang.
Blog ini bertujuan untuk membantu orang mengatasi masalah itu, sementara pada saat yang sama, membuatnya hampir mendokumentasikan diri sendiri. Saya pikir sangat penting untuk mempertimbangkan input manusia dan output robot dari otomatisasi. Lihat juga:Dokumentasi Bootstrapping Dan Rooting:Bagian 1
[ Lembar contekan gratis:Glosarium Kubernetes ]
Kesimpulan
Tampaknya sangat mudah untuk memindahkan layanan umum seperti WordPress ke dalam wadah, tetapi sebenarnya tidak. Arsitektur fleksibel dan aman yang diuraikan dalam artikel ini mengatur keterampilan Administrator atau Arsitek Linux senior untuk berpindah dari server LAMP biasa ke wadah yang sesuai dengan OCI. Panduan ini memanfaatkan mesin kontainer yang disebut Podman sekaligus menyiapkan layanan Anda untuk Kubernetes. Memisahkan kode, konfigurasi, dan data Anda adalah langkah yang diperlukan untuk beralih ke Kubernetes. Semuanya dimulai dengan keterampilan Linux dasar yang solid.
Beberapa keputusan yang disorot dalam artikel ini dengan sengaja menantang berbagai kesalahpahaman dalam komunitas wadah—hal-hal seperti menggunakan systemd dalam wadah atau hanya berfokus pada gambar dasar terkecil yang dapat Anda temukan tanpa memperhatikan seluruh rantai pasokan perangkat lunak. Namun, produk akhir mudah digunakan. Ini menyediakan alur kerja yang sangat mirip dengan server LAMP tradisional, yang membutuhkan beban kognitif minimal untuk administrator sistem Linux tradisional.
Beberapa keputusan desain yang dibuat dalam artikel ini adalah kompromi dan tidak sempurna. Namun, saya membuatnya karena saya memahami tekanan dari budaya DevOps modern dan psikologi tim operasi dan pengembangan. Saya ingin memberikan fleksibilitas untuk mendapatkan nilai lebih dari container. Kumpulan layanan ini akan berguna sebagai model untuk memigrasikan banyak layanan Anda sendiri ke dalam container. Ini akan menyederhanakan pengelolaan, peningkatan, dan pemulihan mereka. Ini tidak hanya membantu admin Linux yang ada, tetapi juga kohort masa depan yang akan mewarisi layanan ini, termasuk versi saya yang akan datang yang akan melupakan semua detailnya. Layanan kemas ini pada dasarnya mendokumentasikan diri dengan gaya yang kondusif bagi budaya DevOps yang sukses.
Seri ini didasarkan pada "Panduan Peretas untuk Memindahkan Layanan Linux ke Wadah" di CrunchTools.com dan diterbitkan ulang dengan izin.
Linux