Menyebarkan kode ke beberapa server ujung depan

Kami memiliki situasi di mana kami memiliki beberapa server yang seimbang yang menunjuk ke database umum.

Dalam menjalankan hal-hal normal ini berfungsi dengan baik dan memberikan redundansi, skalabilitas dll.

Namun kami menemukan penyebaran menjadi sedikit tugas.

Kami menggunakan fitur secara luas dan mencoba mengotomatiskan penerapan. Penempatan saat ini tidak terlalu bisa diandalkan.

Dalam bentuk yang disederhanakan, skrip penyebaran untuk setiap server memiliki dua tahap

1. Perbarui File

2. Kembalikan Fitur (yang akan mengelola dependensi, perubahan pengaturan dll)

Apakah ada praktik terbaik untuk digunakan di beberapa server tanpa menyebabkannya tidak konsisten?

Sejauh yang saya bisa lihat jika Anda menggunakan langkah 1 dan 2 ke server A itu akan menyebabkan server B rusak, jika Anda mencoba langkah satu di kedua server sebelum melanjutkan ke langkah 2 keduanya akan rusak untuk sementara waktu.

Anda mungkin harus melihat ke dalam Aegir , yang sejauh ini merupakan sistem manajemen / penyebaran situs Drupal yang paling fleksibel dan kuat. Ia mampu mengelola 'platform' yang menjangkau beberapa kepala web, atau 'cluster', serta berbagai konfigurasi lainnya.

Saya sarankan membaca dokumentasi komunitas mereka yang umumnya cukup baik, serta membaca ikhtisar mig5 yang sangat baik dan artikel pengantar dan beberapa artikel lainnya seperti ini .

Anda juga bisa mendapatkan dukungan yang baik di saluran IRC #aegir.

Ini akan menjadi sedikit perubahan alur kerja, yang pasti bisa memakan waktu untuk menggerakkan kepala Anda, tetapi begitu Anda di sana, Anda tidak akan melihat ke belakang.

Di perusahaan kami, kami mengelola BANYAK situs Drupal, pengaturan kami saat ini berjalan seperti ini:

• Setiap basis kode situs memiliki git repo sendiri
• Fitur-fitur baru yang sepertinya tidak cukup stabil untuk rilis berikutnya mendapatkan cabang fitur mereka sendiri di git

Di atas saya katakan cukup umum untuk sebagian besar situs Drupal.

Apa yang kami lakukan khusus di perusahaan kami adalah paket debian situs untuk penyebaran menggunakan perintah drush khusus - ' Drush Debian Packaging '.

Drush Debian Packaging menyediakan perintah Drush untuk membangun paket Debian dari situs Drupal sebagai sarana untuk menyebarkan situs Drupal ke server Debian atau Ubuntu.

Drush Debian Packaging menggunakan sistem kait Drupal untuk membangun paket Debian yang paling sesuai dengan kebutuhan situs Anda. Fitur termasuk:

• Konfigurasi host virtual otomatis untuk server web Apache2 dan Nginx
• Pengaturan cron di /etc/cron.d
• Penyebaran kode otomatis dengan pemisahan partisi untuk situs / default / file
• Konfigurasi otomatis melalui alat pengaturan dpkg debconf
• Proses penyebaran otomatis
• handler kustom Git VCS untuk membangun paket dari Git

Apa artinya ini?

Untuk membuat rilis:

cd /path/to/drupal-root
drush dh-make

Untuk menyebarkan rilis, pertama SCP. Deb ke semua server web di kluster. Kemudian pada semua server web jalankan (Anda dapat menggunakan paket linux cssh untuk mengetik perintah ke semua server di peternakan pada saat yang sama):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Di satu server web dijalankan:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Selesai

Tentu saja untuk mengembalikan ini sekarang sepele dari sudut pandang basis kode, cukup instal versi .deb sebelumnya ke semua server web dan kembalikan database.

Senang menjawab pertanyaan tentang ini

Bagian mana dari proses penyebaran yang merupakan tugas / tidak dapat diandalkan?

Jika itu masalah "perbarui server A maka B / inkonsistensi", bagaimana dengan memasang halaman pemeliharaan selama durasi dorongan Anda? Halaman pemeliharaan naik, perbarui kode pada kedua kepala web, jalankan update.php di salah satu dari mereka, halaman pemeliharaan turun. Itu cukup mudah skrip.

Pilihan lain: tergantung pada jenis situs yang Anda jalankan, Anda dapat membuat "mode baca-saja" yang menendang semua pengguna offline dan menonaktifkan login / register. Mengkloning DB Anda ke DB kedua pada kotak db yang sama, mengkloning ujung depan Anda ke dokumen baru, lakukan pembaruan Anda di sana, kemudian symlink dokumen Apache ke dokumen depan ujung baru. Alur kerja adalah seperti:

1. Mode hanya baca aktif
2. SELECT current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.domainanda.com ==> / new_docroot
5. perbarui kode menjadi new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Mode hanya baca mati.

Itu akan tergantung pada perubahan yang Anda buat, seperti yang disarankan Entendu. Berapa proporsi pembaruan kode yang dapat dijalankan tanpa menyebabkan kesalahan jika database belum diperbarui? Untuk apa pun yang tidak bergantung pada pembaruan basis data (dan mungkin Anda dapat mengubah sedikit proses pengembangan untuk menjadikan ini lebih umum), tidak ada yang benar-benar istimewa untuk dilakukan. Saya berasumsi Anda ingin melakukan penyebaran dengan downtime minimal, jika tidak, ini hanya akan mengambil beberapa operasi sinkronisasi dasar. Dalam hal ini akan selalu ada beberapa jendela waktu dengan efek yang tidak diinginkan (bahkan jika itu hanya memiliki situs dalam mode read-only) tetapi saya akan berpikir itu bisa sangat kecil sebagian besar waktu.

Anda dapat melakukan optimasi dasar seperti mengatur direktori "baru" di setiap server sebelumnya dan kemudian beralih semuanya untuk menunjuk ke direktori baru pada saat yang sama (mungkin menggunakan symlink seperti dalam jawaban Entendu) sehingga Anda bisa mendapatkan semua server beralih ke file baru dalam 5-10 detik.

Itu meninggalkan masalah pembaruan basis data. Jika mereka jenis yang harus dilakukan dari satu server saja, Anda mungkin ingin menempatkan yang lain dalam mode pemeliharaan atau menyesuaikan penyeimbang beban untuk tidak menggunakannya saat ini terjadi. Tentu saja jika mereka tidak dapat dilakukan ketika pengguna aktif di situs Anda hanya perlu memiliki semuanya dalam mode pemeliharaan tetapi untuk pembaruan sederhana ini mungkin sesuatu yang dapat Anda lakukan dalam waktu sekitar 30 detik atau kurang.

Mungkin patut memiliki skrip penerapan yang berbeda untuk berbagai jenis perubahan, sehingga Anda dapat menjalankan proses minimal yang diperlukan, baik itu hanya menyalin file, menjalankan pembaruan basis data kecil, atau melakukan perubahan basis data besar.

Jika Anda dapat mengoptimalkan pembaruan file dan database Anda dan melihat apakah ada perubahan sederhana yang dapat Anda lakukan dengan cara hal-hal dikembangkan, itu bisa membawa Anda lebih dekat, tetapi saya tidak tahu apakah semua ini baru bagi Anda :)

Aegir berguna mengelola jaringan situs. Saya menggunakannya untuk menyebarkan dan mengelola lebih dari 2000 situs untuk satu klien.

Pertanyaan Anda menunjukkan bahwa Anda ingin mengelola satu situs dengan banyak webhead. Jika itu yang terjadi, Aegir mungkin kurang bermanfaat bagi Anda. Alih-alih saya sarankan Anda melihat menggunakan sistem file yang mendukung jaringan. Ini tidak hanya memastikan kode Anda tetap sinkron, itu berarti unggahan Anda tersedia di semua node.

Secara historis orang telah menggunakan NFS yang memungkinkan sistem file dari satu server untuk dibagikan dengan node lain. Sayangnya ini memperkenalkan satu titik kegagalan, karena jika server NFS mengunci atau mati situs Anda tidak dapat dilayani.

Jika Anda mau berkompromi sedikit pada kinerja io dalam mendukung server yang lebih andal, maka saya akan merekomendasikan GlusterFS . Saya telah menggunakan beberapa lingkungan produksi. Itu tidak sempurna tetapi lebih baik dari NFS. Gluster memungkinkan webhead untuk selalu membaca secara lokal dan menulis kemudian direplikasi ke node lain.

Dalam hal strategi penyebaran Anda, Anda harus menggunakan drush sebagai alat pertama dalam daftar Anda. Dengan drush Anda harus dapat mengotomatiskan langkah-langkah penyebaran Anda. Anda harus mempertimbangkan untuk menambahkan Jenkins ke dalam campuran sehingga Anda dapat melacak pekerjaan penempatan Anda dan mengidentifikasi pola jika semuanya gagal. Capistrano dapat berguna untuk mengotomatiskan langkah-langkah yang terlibat dalam penyebaran. Jika Anda melakukan hal-hal dengan benar, Anda dapat membuatnya sehingga pengguna Anda bahkan tidak pernah tahu bahwa Anda melakukan penempatan.