Saya ingin berbagi beberapa kesan tentang perlu atau tidaknya panel kontrol untuk proyek web server tunggal komersial dengan seorang admin paruh waktu. Ceritanya bermula beberapa tahun yang lalu, ketika beberapa teman dari teman meminta saya untuk mengawasi pembelian sebuah bisnis—sebuah situs web berita—dari sudut pandang teknis. Saya perlu mendapatkan pemahaman dasar tentang apa yang berjalan di atas apa, memastikan semua detail yang diperlukan ditransfer dalam format dan cakupan yang tepat, dan secara strategis menilai apa yang dapat ditingkatkan.
Kesepakatan sudah tercapai, pemain biola tak lagi dibutuhkan. Tamat. Tidak juga.
Situs tersebut berjalan di VM dual-core 4GB di Linode, di suatu tempat yang berlumut. DebianServer 5 dengan waktu aktif 400 hari dan daftar panjang paket yang belum diperbarui. Komponen web menggunakan CMS kustom, nginx, PHP 5.3 FPM, dan MySQL Percona yang telah dioptimalkan. Pada dasarnya, semuanya berfungsi.
Saat berbincang dengan saya, pemilik baru sedang mencari programmer untuk menyempurnakan proyek ini. Ia menemukannya. Programmer tersebut menilai lalu lintas dan volume, lalu memutuskan bahwa ia ahli dalam optimasi dan manajemen biaya. Ia memigrasikan seluruh situs ke layanan hosting bersama seharga 700 rubel yang dikelola oleh IS****er-nya yang biasa. Beberapa hari kemudian, pemilik menelepon lagi: "Semuanya lambat dan sepertinya ada yang salah." Saya mencoba memperbaiki masalah ini melalui panel kontrol, tetapi setelah beberapa kali gagal mengubah versi PHP atau handler dari fcgi ke fpm, saya menyerah dan masuk ke shell. Di sana, saya menemukan debugging diaktifkan, yang menampilkan kata sandi untuk seluruh internet, 777 untuk beberapa folder, yang saat itu penuh dengan malware, dan hal-hal tak berguna lainnya. Pemiliknya menyadari dan memutuskan bahwa berhemat dalam hal hosting, programmer, dan admin yang akan mengawasi perkembangannya adalah tindakan yang salah.
Kami pindah ke RuVDS. Lokasinya sedikit lebih dekat daripada Linode di Inggris, dan jika kami tiba-tiba ingin menyimpan data pribadi dan sebagainya, kami tidak perlu pindah ke tempat lain. Karena proyek ini direncanakan untuk ekspansi, kami mendapatkan VM "untuk pertumbuhan": 4 inti, memori 8 GB, ruang disk 80 GB. Bukannya saya tidak tahu cara mengutak-atik konfigurasi Nginx secara manual, saya hanya tidak punya antusiasme untuk mengerjakan proyek ini secara mendalam (lihat di atas tentang paruh waktu). Jadi, saya menginstal Plesk (saya akan melewatkan detail instalasinya di sini, karena sebenarnya tidak ada: jalankan penginstalnya, atur kata sandi untuk admin, masukkan kuncinya, dan selesai). Saat itu, versinya adalah 17.0. Pengaturan dasarnya berjalan cukup baik; Plesk memiliki fail2ban dan versi PHP dan Nginx terbaru yang tersedia.
Mungkin saya harus berhenti sejenak dan menjelaskan alasannya. Karena saya jarang melakukan pekerjaan seperti ini dan tidak memiliki alat khusus atau preset untuk setiap situasi, jelas bahwa otomatisasi dasar diperlukan, pertama, agar prosesnya cepat, kedua, aman, dan ketiga, untuk memastikan semua praktik terbaik telah diterapkan.
Jadi, saya memasangnya. Saya menghemat cukup banyak waktu, dan situs tersebut langsung restart di server baru hampir seketika. Yang tersisa hanyalah mengubah konfigurasi otot, mengalokasikan setengah memori dan menambah jumlah buffer pool, serta menetapkan setengah inti untuk nginx (Splash tidak menyentuh konfigurasi global), lalu masuk ke shell selama beberapa hari untuk melihat statistik mysqltuner. Oh, dan saya membeli ImunifyAV berbayar dari katalog ekstensi untuk menghapus malware yang telah disuntikkan. Mereka menemukan sekitar 11000 berkas terinfeksi. Yang menyebalkan adalah potongan kode yang dikaburkan disuntikkan ke dalam berkas statis, dan membersihkannya secara manual pasti sangat merepotkan. Saya mencoba ClamAV terlebih dahulu, tetapi ternyata ClamAV tidak dapat menangani hal-hal seperti itu, sementara ImunifyAV bisa. Selain itu, berkas yang telah dibersihkan tetap berfungsi; potongan yang terinfeksi malware hanya dihapus.
Perhitungannya sederhana: $50 per bulan untuk VMware, $10 untuk Plesk (sebenarnya lebih murah, karena kami membeli langganan setahun penuh dengan diskon dua bulan), dan $3 untuk antivirus. Atau, jumlah yang sangat besar untuk waktu yang seharusnya saya habiskan di server pada awalnya, membersihkan kekacauan ini secara manual. Pemiliknya cukup senang dengan kesepakatan ini.
Sementara itu, kami menemukan programmer baru. Kami menyepakati pembagian tanggung jawab, membuat subdomain untuk versi uji coba, dan mulai bekerja. Dia sedang membangun versi baru situs di Laravel, dan saya mengawasi fail2ban.
Menariknya, arus orang-orang yang penasaran tak pernah berhenti, dan daftar yang diblokir selalu berisi sekitar seratus alamat. Efeknya menarik: khususnya, ketika saya biasanya masuk ke shell, layar selamat datang biasanya menampilkan sekitar 20000-30000 upaya masuk SSH yang gagal. Dengan fail2ban diaktifkan, jumlahnya sekitar 70. Upaya yang diinvestasikan: 0. Sayangnya, ada sedikit kendala. Secara default, WAF (modsecurity) "semi-aktif": dalam mode deteksi. Artinya, WAF mencatat aktivitas mencurigakan di log tetapi tidak mengambil tindakan apa pun. Dan fail2ban tanpa pandang bulu membaca semua log, menurut jail yang diaktifkan, dan menghapus semua yang bergerak. Karena itu, kami memblokir separuh staf editorial :D. Kami harus menonaktifkan jail ini dan memasukkan alamat IP yang diperlukan ke daftar putih demi keandalan. Upaya yang diinvestasikan hanyalah beberapa klik mouse dan melatih editor untuk memberikan alamat IP mereka.
Yang langsung disukai oleh programmer adalah kemampuan untuk mengunggah database langsung ke panel dan akses cepat ke phpMyAdmin
Yang saya sukai adalah log dan cadangannya. Log ditulis dan dirotasi secara otomatis; cadangan sangat mudah diatur. Saat kondisi paling lambat, cadangan penuh sekitar 10 GB dibuat, lalu cadangan inkremental sebesar 200 MB dibuat setiap hari selama seminggu. Pemulihannya sangat detail, hingga ke berkas atau basis data tertentu. Jika Anda perlu memulihkan dari cadangan inkremental, Anda tidak perlu repot-repot membuat cadangan penuh lalu memulihkan seluruh rantai—Plesk melakukannya secara otomatis. Anda dapat mengunggah cadangan di mana saja: ke FTP, Dropbox, S3 Bucket, Google Drive, dan sebagainya.
Hari G: Programmer akhirnya menyelesaikan mesin baru, kami memuatnya ke tahap produksi, mengimpor data lama, dan duduk untuk memilih warna Maserati masa depan kami. Kami masih memilih.
Masalah pertama dimulai. Situs baru ini memang lebih berat daripada yang lama, tetapi masalah sebenarnya adalah mereka menggunakan Yandex.Zen, antara lain, untuk meningkatkan lalu lintas, yang justru mendatangkan banyak pengunjung. Situs tersebut mengalami crash setelah 150 koneksi simultan (saya tidak berbicara tentang RPS, karena kami tidak mengukurnya). Mereka mulai menekan tombol dan mengubah kenop di area pengaturan php_fpm:
Ups, sudah ada 500 koneksi. Saat saya menggunakan kartu kredit untuk alat promosi, gelombang lalu lintas semakin besar. Tonggak berikutnya adalah 1000 koneksi bersamaan. Di sini, saya harus menyempurnakan kode dan memeriksa ototnya. Splash tidak membantu, tetapi bukan itu yang saya harapkan. Saya mengaktifkan log kueri yang lambat, menambahkan indeks ke basis data, menghapus kueri yang tidak perlu dari kode, dan mengubah konfigurasi MySQL lagi mengikuti saran mysqltuner.
Tantangan baru – 2000 koneksi. Plesk 17.8 baru saja dirilis, yang antara lain menambahkan caching nginx. Kami memperbaruinya (ternyata mudah). Kami mencobanya. Berhasil! Lalu kami menemui kendala: umpan Yandex.Zen berhenti berfungsi. Situsnya berfungsi, tetapi umpannya tidak berfungsi. Umpannya tidak berfungsi, tidak ada lalu lintas. Suasana memanas. Di bawah tekanan keadaan dan kurangnya imajinasi, saya langsung mencoba strace nginx dan menemukan apa yang saya cari. Ternyata pada suatu titik, nginx yang bodoh itu menyimpan cache kesalahan 500 sebagai respons terhadap getfeed.xml Yandex. Kami memperbaikinya dengan menambahkan pengecualian pada pengaturan cache:
Jelas pemiliknya membutuhkan LEBIH BANYAK, dan gelombangnya perlahan meningkat. Kami masih bisa mengatasinya untuk saat ini, tetapi kami mulai bereksperimen dengan memcached sejak awal, karena Laravel mendukungnya hampir secara langsung. Kami tidak ingin menginstal memcached secara manual hanya untuk bermain-main, jadi kami menginstal image Docker. Langsung dari dasbor.
Oke, saya bohong, saya harus masuk ke shell dan menginstal modul melalui pecl. Tepat sekali. Belum ada laporan tentang peningkatan throughput; belum ada lonjakan signifikan. Mesin situs terhubung ke localhost:11211, statistik menunjukkan hal ini, tetapi memori sedang terpakai. Jika kami menyukainya, kami akan melihat langkah selanjutnya. Kami akan membiarkannya apa adanya, atau menginstal versi "asli" langsung ke OS. Atau kami akan mencoba Redis dengan cara yang sama.
Lalu saya perlu menyiapkan buletin email. Tanpa relay, hanya autentikasi SMTP. Saya membuat alamat email, dan kami menggunakan detailnya untuk mengirim buletin melalui PHP.
Plesk Obsidian (18.0) baru saja dirilis, dan kami memperbaruinya tanpa rasa takut, berdasarkan pengalaman sebelumnya. Semuanya berjalan sangat lancar, tidak ada yang perlu dilaporkan. Sisi positifnya, antarmukanya telah ditingkatkan secara signifikan, dimodernisasi, dan kini lebih ramah pengguna di beberapa area. Pemantauan Lanjutan di Grafana adalah fitur yang keren.
Saya belum membahasnya secara detail, tapi Anda bisa, misalnya, mengatur notifikasi email untuk parameter apa pun. Buat pemiliknya, lol.
Ngomong-ngomong soal antarmukanya, aplikasi ini responsif dan berfungsi dengan sangat baik di ponsel. Pada tahap awal, saat kami mencoba menemukan pengaturan PHP yang optimal dan hal-hal lainnya, aplikasi ini sangat membantu. Terutama ketika programmer, yang sedang bersemangat bekerja, sedang mengerjakan sesuatu pada pukul 23, dan saya sedang bersemangat bekerja, minum vodka di sauna, dan saya perlu SEGERA mengubah sesuatu.
Oh, ngomong-ngomong. Anda bisa melihat dari gambar bahwa PHP Composer telah muncul. Kami belum mencobanya, tetapi misalnya, untuk Laravel, ini dapat menghemat beberapa login shell dan waktu instalasi dependensi. Sistem serupa juga tersedia untuk Node.JS dan Ruby.
SSL itu sederhana. Jika domain berhasil diselesaikan sesuai harapan, Let's Encrypt akan terinstal dengan satu klik dan otomatis diperbarui untuk domain itu sendiri, subdomain, dan bahkan layanan email.
Plesk sendiri saat ini cukup ramah pengguna dan stabil. Ia memperbarui dirinya sendiri dan OS secara diam-diam, menggunakan sedikit sumber daya, dan berjalan lancar. Saya bahkan tidak ingat ada masalah yang dianggap sebagai cacat nyata pada produk ini. Tentu saja ada beberapa masalah, tetapi itu mungkin disebabkan oleh konfigurasi yang tidak sempurna atau masalah di suatu tempat, jadi tidak ada yang perlu dikritik. Secara keseluruhan, pengalaman saya dengan Plesk menyenangkan. Yang tidak dimilikinya, dan penting untuk dipahami, adalah pengelompokan apa pun. Tidak ada LB, tidak ada HA. Anda bisa mencoba, tetapi upaya yang diperlukan akan sangat besar sehingga lebih baik melakukan sesuatu yang berbeda sejak awal.
Saya rasa kita bisa merangkumnya. Untuk situasi di mana tidak ada admin, atau hanya ada sedikit admin, ketika biaya hosting dan situs web yang berjalan di dalamnya melebihi, katakanlah, $100, di luar server bersama yang besar dengan 1500 situs, ketika pengambil keputusan dihadapkan pada pilihan untuk mempekerjakan admin paruh waktu, membeli perangkat lunak dan mempekerjakan admin "paruh waktu", atau tidak mempekerjakan admin sama sekali—hal ini tentu masuk akal. Dari perspektif admin jarak jauh, sama saja. $10 per bulan menghemat waktu dan menambah fleksibilitas untuk bekerja dalam skala yang sangat besar.оJumlah yang lebih besar. Jika, misalnya, saya diminta untuk mengelola proyek serupa, saya akan bersikeras untuk memindahkannya ke Plesk.
Sumber: www.habr.com
