Kata "penyebaran" dapat memiliki dua arti tergantung pada konteksnya. Anda juga membingungkan peran Apache / Nginx dengan peran komponen lainnya.
Catatan bersejarah: Artikel ini awalnya ditulis pada 6 November 2010, ketika ekosistem server aplikasi Ruby terbatas. Saya telah memperbarui artikel ini pada 15 Maret 2013 dengan semua pembaruan terbaru di ekosistem.
Penafian : Saya adalah salah satu penulis Phusion Passenger, salah satu server aplikasi.
Apache vs Nginx
Keduanya adalah server web. Mereka dapat menyajikan file statis tetapi - dengan modul yang tepat - juga dapat melayani aplikasi web yang dinamis misalnya yang ditulis dalam PHP. Apache lebih populer dan memiliki lebih banyak fitur, Nginx lebih kecil dan lebih cepat dan memiliki lebih sedikit fitur.
Baik Apache maupun Nginx tidak dapat menyajikan aplikasi web Ruby di luar kotak, untuk melakukan itu Anda perlu menggunakan Apache / Nginx dalam kombinasi dengan beberapa jenis add-on, dijelaskan nanti.
Apache dan Nginx juga dapat bertindak sebagai proksi terbalik, artinya mereka dapat mengambil permintaan HTTP yang masuk dan meneruskannya ke server lain, yang juga berbicara HTTP. Ketika server itu merespons dengan respons HTTP, Apache / Nginx akan meneruskan respons kembali ke klien; Anda akan belajar nanti mengapa ini relevan.
Mongrel dan server aplikasi produksi lainnya vs WEBrick
Mongrel adalah "server aplikasi" Ruby: Secara konkret ini berarti bahwa Mongrel adalah aplikasi yang:
- Memuat aplikasi Ruby Anda di dalam ruang prosesnya sendiri.
- Mengatur soket TCP, memungkinkannya untuk berkomunikasi dengan dunia luar (mis. Internet). Mongrel mendengarkan permintaan HTTP pada soket ini dan meneruskan data permintaan ke aplikasi web Ruby.
- Aplikasi web Ruby kemudian mengembalikan objek, yang menggambarkan seperti apa respons HTTP seharusnya, dan Mongrel mengurungnya untuk mengubahnya menjadi respons HTTP aktual (byte aktual) dan mengirimkannya kembali ke soket.
Namun Mongrel cukup tanggal, saat ini tidak lagi dipertahankan. Server aplikasi alternatif yang lebih baru adalah:
- Penumpang Phusion
- Unicorn
- Tipis
- Puma
- Trinidad (hanya JRuby)
- TorqueBox (hanya JRuby)
Saya akan membahasnya nanti dan menjelaskan bagaimana mereka berbeda satu sama lain dan dari Mongrel.
WEBrick melakukan hal yang sama dengan Mongrel, tetapi perbedaannya adalah:
- WEBrick tidak cocok untuk produksi, tidak seperti semua yang saya sebutkan sebelumnya. WEBrick sepenuhnya ditulis dalam Ruby. Mongrel (dan sebagian besar server aplikasi Ruby lainnya) adalah bagian Ruby dan bagian C (Sebagian besar Ruby), tetapi parser HTTP-nya ditulis dalam C untuk kinerja.
- WEBrick lebih lambat dan kurang kuat. Ini memiliki beberapa kebocoran memori yang diketahui dan beberapa masalah penguraian HTTP yang diketahui.
- WEBrick biasanya hanya digunakan sebagai server default selama pengembangan karena WEBrick dimasukkan dalam Ruby secara default. Mongrel dan server aplikasi lain harus diinstal secara terpisah. Tidak disarankan untuk menggunakan WEBrick di lingkungan produksi, meskipun untuk beberapa alasan Heroku memilih WEBrick sebagai server default. Mereka menggunakan Thin sebelumnya, jadi saya tidak tahu mengapa mereka beralih ke WEBrick.
Server aplikasi dan dunia
Semua server aplikasi Ruby saat ini berbicara HTTP, namun beberapa server aplikasi mungkin langsung terpapar ke Internet pada port 80, sementara yang lain mungkin tidak.
- Server aplikasi yang dapat langsung terpapar ke Internet: Penumpang Phusion, Rainbows
- Server aplikasi yang mungkin tidak terpapar langsung ke Internet: Mongrel, Unicorn, Thin, Puma. Server aplikasi ini harus diletakkan di belakang server web proxy terbalik seperti Apache dan Nginx.
- Saya tidak cukup tahu tentang Trinidad dan TorqueBox, jadi saya telah menghilangkannya.
Mengapa beberapa server aplikasi harus diletakkan di belakang proxy terbalik?
- Beberapa server aplikasi hanya dapat menangani 1 permintaan secara bersamaan, per proses. Jika Anda ingin menangani 2 permintaan secara bersamaan, Anda perlu menjalankan beberapa instance server aplikasi, masing-masing melayani aplikasi Ruby yang sama. Rangkaian proses server aplikasi ini disebut cluster server aplikasi (karenanya disebut Mongrel Cluster, Thin Cluster, dll). Anda kemudian harus mengatur Apache atau Nginx untuk membalikkan proxy ke kluster ini. Apache / Nginx akan mengurus pendistribusian permintaan di antara instance dalam cluster (Lebih lanjut tentang ini di bagian "model konkurensi I / O").
- Server web dapat menyangga permintaan dan tanggapan, melindungi server aplikasi dari "klien lambat" - klien HTTP yang tidak mengirim atau menerima data dengan sangat cepat. Anda tidak ingin server aplikasi Anda tidak melakukan apa-apa sambil menunggu klien mengirim permintaan penuh atau menerima respons penuh, karena selama waktu itu server aplikasi mungkin tidak dapat melakukan hal lain. Apache dan Nginx sangat pandai melakukan banyak hal pada saat yang sama karena mereka multithreaded atau evented.
- Sebagian besar server aplikasi dapat menyajikan file statis, tetapi tidak terlalu bagus. Apache dan Nginx dapat melakukannya lebih cepat.
- Orang-orang biasanya mengatur Apache / Nginx untuk menyajikan file statis secara langsung, tetapi meneruskan permintaan yang tidak sesuai dengan file statis ke server aplikasi, ini adalah praktik keamanan yang baik. Apache dan Nginx sangat matang dan dapat melindungi server aplikasi dari (mungkin berbahaya) permintaan yang rusak.
Mengapa beberapa server aplikasi dapat langsung terpapar ke Internet?
- Penumpang Phusion adalah binatang yang sangat berbeda dari semua server aplikasi lainnya. Salah satu fitur uniknya adalah terintegrasi ke dalam server web.
- Penulis Rainbows secara terbuka menyatakan bahwa aman untuk langsung mengeksposnya ke Internet. Penulis cukup yakin bahwa tidak ada kerentanan dalam HTTP parser (dan sejenisnya). Namun, penulis tidak memberikan jaminan dan mengatakan bahwa penggunaan merupakan risiko sendiri.
Server aplikasi dibandingkan
Di bagian ini saya akan membandingkan sebagian besar server aplikasi yang saya sebutkan, tetapi bukan Penumpang Phusion. Penumpang Phusion adalah binatang yang sangat berbeda dari yang lain sehingga saya telah memberikannya bagian khusus. Saya juga telah menghapus Trinidad dan TorqueBox karena saya tidak mengenal mereka dengan cukup baik, tetapi mereka tetap relevan jika Anda menggunakan JRuby.
- Mongrel adalah tulang yang sangat sederhana. Seperti disebutkan sebelumnya, Mongrel adalah murni multi-proses multi-threaded, jadi itu hanya berguna dalam sebuah cluster Tidak ada pemantauan proses: jika suatu proses dalam gugus macet (misalnya karena bug dalam aplikasi) maka perlu restart secara manual. Orang cenderung menggunakan alat pemantauan proses eksternal seperti Monit dan Tuhan.
- Unicorn adalah cabang dari Mongrel. Ini mendukung pemantauan proses terbatas: jika suatu proses crash itu secara otomatis restart oleh proses master. Itu dapat membuat semua proses mendengarkan pada satu soket bersama, alih-alih soket terpisah untuk setiap proses. Ini menyederhanakan konfigurasi proxy terbalik. Seperti Mongrel, itu murni multi-proses multi-threaded.
- Thin menggunakan model I / O yang terjadi dengan memanfaatkan perpustakaan EventMachine. Selain menggunakan parser HTTP Mongrel, itu tidak didasarkan pada Mongrel dengan cara apa pun. Mode cluster-nya tidak memiliki proses pemantauan sehingga Anda perlu memonitor crash dll. Tidak ada soket bersama Unicorn, sehingga setiap proses mendengarkan pada soketnya sendiri. Secara teori, model I / O Thin memungkinkan konkurensi tinggi, tetapi dalam sebagian besar situasi praktis yang digunakan untuk Thin, satu proses Thin hanya dapat menangani 1 permintaan bersamaan, jadi Anda masih memerlukan sebuah cluster. Lebih lanjut tentang properti khusus ini di bagian "model konkurensi I / O".
- Puma juga bercabang dari Mongrel, tetapi tidak seperti Unicorn, Puma dirancang untuk murni multi-threaded. Oleh karena itu saat ini tidak ada dukungan cluster builtin. Anda perlu berhati-hati untuk memastikan bahwa Anda dapat memanfaatkan beberapa inti (Lebih lanjut tentang ini di bagian "model konkurensi I / O").
- Rainbows mendukung beberapa model konkurensi melalui penggunaan perpustakaan yang berbeda.
Penumpang Phusion
Penumpang Phusion bekerja sangat berbeda dari yang lainnya. Penumpang Phusion terintegrasi langsung ke Apache atau Nginx, dan dengan demikian dapat dibandingkan dengan mod_php untuk Apache. Sama seperti mod_php memungkinkan Apache untuk melayani aplikasi PHP, hampir secara ajaib, Penumpang Phusion memungkinkan Apache (dan juga Nginx!) Untuk melayani aplikasi Ruby, hampir secara ajaib. Tujuan Penumpang Phusion adalah untuk menjadikan semuanya Just Work (tm) dengan sesedikit mungkin kesulitan.
Alih-alih memulai proses atau cluster untuk aplikasi Anda, dan mengonfigurasi Apache / Nginx untuk menyajikan file statis dan / atau membalikkan permintaan proxy ke proses / cluster dengan Phusion Passenger, Anda hanya perlu:
- Anda mengedit file konfigurasi server web dan menentukan lokasi direktori 'publik' aplikasi Ruby Anda.
- Tidak ada langkah 2.
Semua konfigurasi dilakukan dalam file konfigurasi server web. Phusion Passenger mengotomatiskan segalanya. Tidak perlu memulai cluster dan mengelola proses. Memulai / menghentikan proses, memulai kembali ketika mereka crash, dll - semua otomatis. Dibandingkan dengan server aplikasi lain, Penumpang Phusion memiliki bagian bergerak yang jauh lebih sedikit. Kemudahan penggunaan ini adalah salah satu alasan utama mengapa orang menggunakan Penumpang Phusion.
Juga tidak seperti server aplikasi lain, Penumpang Phusion terutama ditulis dalam C ++, membuatnya sangat cepat.
Ada juga varian Enterprise dari Phusion Passenger dengan lebih banyak fitur, seperti rolling restart otomatis, dukungan multithreading, resistansi penyebaran kesalahan, dll.
Untuk alasan di atas, Phusion Passenger saat ini adalah server aplikasi Ruby paling populer, memberi daya lebih dari 150.000 situs web, termasuk yang besar seperti New York Times, Pixar, Airbnb, dll.
Penumpang Phusion vs server aplikasi lain
Phusion Passenger menyediakan lebih banyak fitur dan memberikan banyak keunggulan dibandingkan server aplikasi lain, seperti:
- Menyesuaikan jumlah proses secara dinamis berdasarkan lalu lintas. Kami menjalankan banyak aplikasi Rails di server kami yang terbatas sumber daya yang tidak menghadap publik, dan bahwa orang-orang di organisasi kami hanya menggunakan paling banyak beberapa kali sehari. Hal-hal seperti Gitlab, Redmine, dll. Penumpang Phusion dapat menurunkan proses-proses tersebut ketika tidak digunakan, dan memutarnya ketika digunakan, memungkinkan lebih banyak sumber daya tersedia untuk aplikasi yang lebih penting. Dengan server aplikasi lain, semua proses Anda dihidupkan sepanjang waktu.
- Beberapa server aplikasi tidak bagus dalam beban kerja tertentu, berdasarkan desain. Misalnya Unicorn dirancang hanya untuk permintaan yang berjalan cepat: Lihat bagian situs web Unicorn "Just Worse in Some Cases".
Beban kerja yang tidak bagus di Unicorn adalah:
- Mengalirkan beban kerja (misalnya streaming langsung Rails 4 atau streaming template Rails 4).
- Beban kerja tempat aplikasi melakukan panggilan HTTP API.
Model I / O hybrid di Phusion Passenger Enterprise 4 atau lebih baru membuatnya menjadi pilihan yang sangat baik untuk jenis beban kerja ini.
- Server aplikasi lain mengharuskan pengguna untuk menjalankan setidaknya satu instance per aplikasi. Sebaliknya, Penumpang Phusion mendukung banyak aplikasi dalam satu contoh. Ini sangat mengurangi biaya administrasi.
- Peralihan pengguna otomatis, fitur keamanan yang nyaman.
- Penumpang Phusion mendukung banyak MRI Ruby, JRuby dan Rubinius. Mongrel, Unicorn dan Thin hanya mendukung MRI. Puma juga mendukung semua 3.
- Penumpang Phusion sebenarnya mendukung lebih dari sekadar Ruby! Ini juga mendukung Python WSGI, jadi misalnya bisa juga menjalankan aplikasi Django dan Flask. Bahkan Penumpang Phusion bergerak ke arah menjadi server polyglot. Dukungan Node.js pada daftar todo.
- Pengumpulan sampah di luar band. Penumpang Phusion dapat menjalankan pengumpul sampah Ruby di luar siklus permintaan / respons normal, berpotensi mengurangi waktu permintaan hingga ratusan milidetik. Unicorn juga memiliki fitur serupa, tetapi versi Phusion Passenger lebih fleksibel karena 1) tidak terbatas pada GC dan dapat digunakan untuk pekerjaan sewenang-wenang. 2) Versi Phusion Passenger berfungsi baik dengan aplikasi multithreaded, sedangkan Unicorn tidak.
- Restart bergulir otomatis. Rolling restart pada Unicorn dan server lain memerlukan beberapa pekerjaan scripting. Phusion Passenger Enterprise mengotomatisasi sepenuhnya cara ini untuk Anda.
Ada lebih banyak fitur dan kelebihan, tetapi daftarnya sangat panjang. Anda harus merujuk ke manual Penumpang Phusion yang komprehensif ( versi Apache , versi Nginx ) atau situs web Penumpang Phusion untuk informasi.
Model konkurensi I / O
- Proses tunggal berulir tunggal. Ini adalah model I / O yang paling populer untuk server aplikasi Ruby, sebagian karena dukungan multithreading di ekosistem Ruby sangat buruk. Setiap proses dapat menangani tepat 1 permintaan sekaligus. Server web memuat saldo antar proses. Model ini sangat kuat dan ada sedikit kesempatan bagi programmer untuk memperkenalkan bug konkurensi. Namun, konkurensi I / O-nya sangat terbatas (dibatasi oleh jumlah proses). Model ini sangat cocok untuk beban kerja cepat dan pendek. Sangat tidak cocok untuk memperlambat, I-O blocking yang berjalan lama, misalnya beban kerja yang melibatkan pemanggilan API HTTP.
- Murni multi-utas. Saat ini ekosistem Ruby memiliki dukungan multithreading yang sangat baik, sehingga model I / O ini menjadi sangat layak. Multithreading memungkinkan konkurensi I / O yang tinggi, sehingga cocok untuk beban kerja I / O blocking jangka pendek dan jangka panjang. Programmer lebih cenderung memperkenalkan bug konkurensi, tetapi untungnya sebagian besar kerangka kerja web dirancang sedemikian rupa sehingga ini masih sangat tidak mungkin. Namun satu hal yang perlu diperhatikan adalah bahwa interpreter MRI Ruby tidak dapat memanfaatkan beberapa core CPU bahkan ketika ada banyak utas, karena penggunaan Global Interpreter Lock (GIL). Anda dapat mengatasi ini dengan menggunakan beberapa proses multi-utas, karena setiap proses dapat memanfaatkan inti CPU. JRuby dan Rubinius tidak memiliki GIL, sehingga mereka dapat sepenuhnya memanfaatkan banyak core dalam satu proses tunggal.
- Hibrida multi-utas multi-proses. Terutama diterapkan oleh Phusion Passenger Enterprise 4 dan yang lebih baru. Anda dapat dengan mudah beralih di antara multi-proses single-threaded, murni multithreaded, atau bahkan beberapa proses masing-masing dengan beberapa utas. Model ini memberikan yang terbaik dari kedua dunia.
- Terjadi Model ini sangat berbeda dari model yang disebutkan sebelumnya. Ini memungkinkan konkurensi I / O yang sangat tinggi dan karenanya sangat bagus untuk memblok beban kerja I / O yang sudah berjalan lama. Untuk memanfaatkannya, dukungan eksplisit dari aplikasi dan kerangka kerja diperlukan. Namun semua kerangka kerja utama seperti Rails dan Sinatra tidak mendukung kode yang terjadi. Inilah sebabnya mengapa dalam praktiknya proses Thin masih tidak dapat menangani lebih dari 1 permintaan pada satu waktu, membuatnya secara efektif berperilaku sama dengan model multi-proses single-threaded. Ada kerangka kerja khusus yang dapat mengambil keuntungan dari I / O yang terjadi, seperti Cramp.
Sebuah artikel baru-baru ini diposting di blog Phusion tentang penyetelan jumlah proses dan utas secara optimal karena beban kerja Anda. Lihat pengaturan konkurensi Penumpang Phusion Penumpang .
Capistrano
Capistrano adalah sesuatu yang sangat berbeda. Di semua bagian sebelumnya, "penyebaran" mengacu pada tindakan memulai aplikasi Ruby Anda di server aplikasi, sehingga aplikasi itu dapat diakses oleh pengunjung, tetapi sebelum itu bisa terjadi, biasanya seseorang perlu melakukan beberapa pekerjaan persiapan, seperti:
- Mengunggah kode dan file aplikasi Ruby ke mesin server.
- Memasang pustaka tempat aplikasi Anda bergantung.
- Menyiapkan atau memigrasi basis data.
- Memulai dan menghentikan dasmon apa pun yang bergantung pada aplikasi Anda, seperti pekerja Sidekiq / Resque atau apa pun.
- Semua hal lain yang perlu dilakukan saat Anda mengatur aplikasi Anda.
Dalam konteks Capistrano, "penyebaran" mengacu pada melakukan semua pekerjaan persiapan ini. Capistrano bukan server aplikasi. Sebaliknya, ini adalah alat untuk mengotomatiskan semua pekerjaan persiapan itu. Anda memberi tahu Capistrano di mana server Anda berada dan perintah mana yang harus dijalankan setiap kali Anda menggunakan versi baru aplikasi Anda, dan Capistrano akan mengunggah mengunggah aplikasi Rails ke server untuk Anda dan menjalankan perintah yang Anda tentukan.
Capistrano selalu digunakan dalam kombinasi dengan server aplikasi. Itu tidak menggantikan server aplikasi. Demikian pula sebaliknya, server aplikasi tidak menggantikan Capistrano, mereka dapat digunakan dalam kombinasi dengan Capistrano.
Tentu saja Anda tidak harus menggunakan Capistrano. Jika Anda lebih suka mengunggah aplikasi Ruby Anda dengan FTP dan secara manual menjalankan langkah-langkah perintah yang sama setiap kali, maka Anda bisa melakukannya. Orang lain sudah bosan, jadi mereka mengotomatiskan langkah-langkah itu di Capistrano.