การปรับใช้รหัสไปยังเซิร์ฟเวอร์ส่วนหน้าหลาย ๆ เครื่อง

เรามีสถานการณ์ที่เรามีเซิร์ฟเวอร์หลายตัวที่สมดุลโหลดซึ่งชี้ไปยังฐานข้อมูลทั่วไป

ในการทำงานปกติสิ่งนี้ใช้ได้ดีและให้ความซ้ำซ้อนความสามารถในการปรับขยายและอื่น ๆ

อย่างไรก็ตามเรากำลังค้นหาการปรับใช้ให้เป็นงานที่น่าเบื่อ

เรากำลังใช้คุณสมบัติอย่างกว้างขวางและกำลังพยายามปรับใช้โดยอัตโนมัติ การปรับใช้ในขณะนี้ไม่น่าเชื่อถือมาก

ในรูปแบบที่ง่ายสคริปต์การปรับใช้สำหรับแต่ละเซิร์ฟเวอร์มีสองขั้นตอน

1. อัปเดตไฟล์

2. เปลี่ยนกลับคุณสมบัติ (ซึ่งจะจัดการการพึ่งพาการเปลี่ยนแปลงการตั้งค่าและอื่น ๆ )

มีแนวทางปฏิบัติที่ดีที่สุดสำหรับการปรับใช้ข้ามเซิร์ฟเวอร์หลายเครื่องโดยไม่ทำให้พวกเขาอยู่ในสถานะไม่สอดคล้องหรือไม่?

เท่าที่ฉันสามารถดูได้ว่าคุณปรับใช้ขั้นตอนที่ 1 และ 2 ไปยังเซิร์ฟเวอร์ A หรือไม่ A จะทำให้เซิร์ฟเวอร์ B หยุดทำงานหากคุณลองขั้นตอนที่หนึ่งบนเซิร์ฟเวอร์ทั้งสองก่อนที่จะดำเนินการขั้นตอนที่ 2 พวกเขาทั้งสองจะพัง

คุณน่าจะพิจารณาAegirซึ่งเป็นระบบการจัดการ / ปรับใช้ไซต์ Drupal ที่ยืดหยุ่นและทรงพลังที่สุด สามารถจัดการ 'แพลตฟอร์ม' ที่ครอบคลุมพื้นที่หลายหัวเว็บหรือ 'กลุ่ม' รวมถึงโครงแบบอื่น ๆ ที่หลากหลาย

ผมขอแนะนำให้มีการอ่านผ่านพวกเขาเอกสารชุมชนซึ่งโดยทั่วไปสวยดีเช่นเดียวกับการอ่านผ่านmig5 ของภาพรวมที่ดีเยี่ยมและบทความแนะนำและบางส่วนของบทความอื่น ๆ ของเขาเหมือนคนนี้

คุณสามารถรับการสนับสนุนที่ดีในช่อง #aegir IRC

มันจะเป็นการเปลี่ยนแปลงเวิร์กโฟลว์ซึ่งอาจต้องใช้เวลาสักพักหนึ่งเพื่อให้ได้หัว แต่เมื่อคุณอยู่ที่นั่นคุณจะไม่หันหลังกลับ

ที่ บริษัท ของเราเราดูแลเว็บไซต์ Drupal จำนวนมากการตั้งค่าปัจจุบันของเรามีดังนี้:

• codebase ของทุกเว็บไซต์มี repo คอมไพล์เป็นของตัวเอง
• ฟีเจอร์ใหม่ที่ไม่น่าจะมีเสถียรภาพเพียงพอสำหรับการเปิดตัวครั้งต่อไปจะมีฟีเจอร์แบรนช์ของตัวเองในคอมไพล์

ข้างต้นฉันจะบอกว่าค่อนข้างธรรมดาสำหรับเว็บไซต์ Drupal ส่วนใหญ่

สิ่งที่เราทำพิเศษที่ บริษัท ของเราคือแพคเกจเดเบียนเว็บไซต์สำหรับการปรับใช้โดยใช้คำสั่งdrushแบบกำหนดเอง - ' Drush Debian Packaging '

Drush Debian Packaging ให้คำสั่ง Drush สำหรับการสร้างแพ็คเกจ Debian ของไซต์ Drupal เพื่อใช้งานเว็บไซต์ Drupal กับเซิร์ฟเวอร์ Debian หรือ Ubuntu

Drush Debian Packaging ใช้ระบบ Drupal hooks เพื่อสร้างแพ็คเกจ Debian ที่เหมาะกับเว็บไซต์ของคุณมากที่สุด คุณสมบัติรวมถึง:

• กำหนดค่าโฮสต์เสมือนโดยอัตโนมัติสำหรับเว็บเซิร์ฟเวอร์ Apache2 และ Nginx
• Cron setup ใน /etc/cron.d
• การปรับใช้รหัสอัตโนมัติพร้อมด้วยการแบ่งพาร์ติชันสำหรับไซต์ / ค่าเริ่มต้น / ไฟล์
• การกำหนดค่าอัตโนมัติผ่านเครื่องมือการตั้งค่า dpkg debconf
• กระบวนการปรับใช้อัตโนมัติ
• ตัวจัดการ GS VCS ที่กำหนดเองสำหรับการสร้างแพ็คเกจจาก Git

สิ่งนี้หมายความว่า?

วิธีสร้างรุ่น:

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

ในการปรับใช้รุ่นแรกให้ SCP. .de กับเว็บเซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ จากนั้นในเว็บเซิร์ฟเวอร์ทั้งหมดจะทำงาน (คุณสามารถใช้แพคเกจ linux csshเพื่อพิมพ์คำสั่งไปยังเซิร์ฟเวอร์ทั้งหมดในฟาร์มในเวลาเดียวกัน):

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

ในการเรียกใช้เว็บเซิร์ฟเวอร์เดียว:

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

เสร็จสิ้น

แน่นอนว่าการย้อนกลับนี่เป็นเรื่องเล็กน้อยจากมุมมองของ codebase เพียงแค่ติดตั้ง. deb รุ่นก่อนหน้านี้ไปยังเว็บเซิร์ฟเวอร์ทั้งหมดและย้อนกลับฐานข้อมูล

ยินดีที่จะตอบคำถามใด ๆ เกี่ยวกับเรื่องนี้

ส่วนใดของกระบวนการปรับใช้เป็นงานที่ไม่น่าไว้วางใจ?

หากเป็นปัญหา "อัปเดตเซิร์ฟเวอร์ A ดังนั้น B / ความไม่สอดคล้องกัน" สิ่งที่เกี่ยวกับการวางหน้าการบำรุงรักษาสำหรับระยะเวลาของการผลักดันของคุณ? การบำรุงรักษาหน้าขึ้นอัปเดตรหัสบนหัวเว็บทั้งสองเรียกใช้ update.php หนึ่งในพวกเขาหน้าการบำรุงรักษาลง นั่นเป็นสคริปต์ที่ง่ายดาย

ตัวเลือกอื่น: ขึ้นอยู่กับประเภทของเว็บไซต์ที่คุณเปิดคุณสามารถสร้าง "โหมดอ่านอย่างเดียว" ซึ่งจะทำให้ผู้ใช้ทุกคนออฟไลน์และปิดใช้งานการเข้าสู่ระบบ / ลงทะเบียน โคลนฐานข้อมูลของคุณไปยังฐานข้อมูลที่สองบนกล่องฐานข้อมูลเดียวกันโคลนส่วนหน้าของคุณไปยัง docroot ใหม่ทำการอัปเดตของคุณที่นั่นจากนั้นเชื่อมโยง docroot ของ Apache กับ docroot ส่วนหน้าใหม่ เวิร์กโฟลว์คือ:

1. เปิดโหมดอ่านอย่างเดียว
2. เลือก current_db เข้าสู่ new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. อัปเดตรหัสเป็น new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. ปิดโหมดอ่านอย่างเดียว

มันจะขึ้นอยู่กับการเปลี่ยนแปลงที่คุณทำตามที่ Entendu แนะนำ สัดส่วนของการอัปเดตรหัสใดบ้างที่สามารถเรียกใช้โดยไม่ทำให้เกิดข้อผิดพลาดหากฐานข้อมูลยังไม่ได้อัปเดต สำหรับสิ่งที่ไม่ได้ขึ้นอยู่กับการอัพเดทฐานข้อมูล (และบางทีคุณสามารถเปลี่ยนกระบวนการพัฒนาเล็กน้อยเพื่อทำให้เป็นเรื่องธรรมดามากขึ้น) ไม่มีอะไรพิเศษที่ต้องทำ ฉันคิดว่าคุณต้องการทำการปรับใช้ด้วยการหยุดทำงานน้อยที่สุดมิฉะนั้นจะเป็นการดำเนินการซิงค์พื้นฐาน ในกรณีนี้จะมีบางช่วงเวลาที่มีเอฟเฟกต์ที่ไม่พึงประสงค์ (แม้ว่ามันจะเป็นเพียงแค่มีเว็บไซต์ในโหมดอ่านอย่างเดียว) แต่ฉันคิดว่ามันอาจจะเล็กไปหน่อย

คุณสามารถเพิ่มประสิทธิภาพพื้นฐานเช่นการตั้งค่าไดเรกทอรี "ใหม่" ในแต่ละเซิร์ฟเวอร์ล่วงหน้าแล้วสลับไปยังไดเรกทอรีใหม่ในเวลาเดียวกัน (อาจใช้ symlink เหมือนในคำตอบของ Entendu) เพื่อให้คุณได้รับทั้งหมด เซิร์ฟเวอร์เปลี่ยนเป็นไฟล์ใหม่ภายใน 5-10 วินาที

ที่ทำให้ปัญหาของการปรับปรุงฐานข้อมูล หากเป็นประเภทที่ต้องทำจากเซิร์ฟเวอร์เดียวเท่านั้นคุณอาจต้องการให้ผู้อื่นอยู่ในโหมดการบำรุงรักษาหรือปรับ load balancer เพื่อไม่ให้ใช้ในขณะที่เกิดเหตุการณ์นี้ แน่นอนว่าหากพวกเขาไม่สามารถทำได้ในขณะที่ผู้ใช้งานอยู่บนไซต์คุณจะต้องมีทุกอย่างในโหมดการบำรุงรักษา แต่สำหรับการอัปเดตอย่างง่ายนี่อาจเป็นสิ่งที่คุณสามารถทำได้ในเวลาประมาณ 30 วินาทีหรือน้อยกว่า

อาจมีความคุ้มค่าที่จะมีสคริปต์การปรับใช้ที่แตกต่างกันสำหรับการเปลี่ยนแปลงประเภทต่างๆดังนั้นคุณสามารถเรียกใช้กระบวนการที่จำเป็นน้อยที่สุดไม่ว่าจะเป็นเพียงการคัดลอกไฟล์การรันการอัพเดทฐานข้อมูลขนาดเล็กหรือทำการเปลี่ยนแปลงฐานข้อมูลหลัก

หากคุณสามารถปรับปรุงไฟล์และฐานข้อมูลของคุณให้ดีที่สุดและดูว่ามีการเปลี่ยนแปลงอย่างง่าย ๆ ที่คุณสามารถทำได้กับวิธีที่สิ่งต่าง ๆ ได้รับการพัฒนาหรือไม่นั้นอาจนำคุณเข้ามาใกล้ แต่ฉันไม่รู้ว่าสิ่งนี้เป็นสิ่งใหม่สำหรับคุณ :)

Aegir มีประโยชน์ในการจัดการเครือข่ายเว็บไซต์ ฉันใช้มันในการปรับใช้และจัดการไซต์มากกว่า 2000 แห่งสำหรับไคลเอนต์เดียว

คำถามของคุณแนะนำว่าคุณต้องการจัดการเว็บไซต์เดียวที่มีหลาย webheads หากเป็นกรณี Aegir อาจมีประโยชน์น้อยกว่าสำหรับคุณ แต่ฉันขอแนะนำให้คุณดูที่การใช้ระบบไฟล์ที่รองรับเครือข่าย ไม่เพียงแค่นี้จะทำให้แน่ใจได้ว่ารหัสของคุณถูกเก็บไว้ในซิงค์หมายความว่าการอัปโหลดของคุณนั้นมีอยู่ในโหนดทั้งหมด

ผู้คนในอดีตเคยใช้ NFS ซึ่งอนุญาตให้ระบบไฟล์ของเซิร์ฟเวอร์หนึ่งแชร์กับโหนดอื่น น่าเสียดายที่นี่มีจุดล้มเหลวเพียงจุดเดียวเพราะหากเซิร์ฟเวอร์ NFS ล็อคหรือทำให้ไซต์ของคุณไม่สามารถให้บริการได้

หากคุณมีความยินดีที่จะประนีประนอมเล็ก ๆ น้อย ๆ เกี่ยวกับประสิทธิภาพ io ในความโปรดปรานของเซิร์ฟเวอร์ที่มีความน่าเชื่อถือมากขึ้นแล้วฉันจะแนะนำGlusterFS ฉันใช้ในสภาพแวดล้อมการผลิตไม่กี่ครั้ง มันไม่สมบูรณ์แบบ แต่ดีกว่า NFS Gluster อนุญาตให้ webhead อ่านแบบโลคัลเสมอและการเขียนจะถูกเรพลิเคทไปยังโหนดอื่น

ในแง่ของกลยุทธ์การปรับใช้ของคุณคุณควรจะมีdrushเป็นเครื่องมือแรกในรายการของคุณ ด้วย drush คุณควรจะสามารถทำตามขั้นตอนการปรับใช้ของคุณโดยอัตโนมัติ คุณควรพิจารณาเพิ่มเจนกินส์ลงในมิกซ์เพื่อให้คุณสามารถติดตามงานการปรับใช้ของคุณและระบุรูปแบบหากสิ่งต่างๆ Capistrano สามารถเป็นประโยชน์สำหรับการทำขั้นตอนที่เกี่ยวข้องโดยอัตโนมัติในการปรับใช้ หากคุณทำสิ่งต่าง ๆ อย่างถูกต้องคุณสามารถทำได้เพื่อให้ผู้ใช้ของคุณไม่เคยรู้เลยว่าคุณได้ทำการปรับใช้