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

หลังคำตอบของฉันสำหรับคำถาม: DevOps จะช่วยปรับปรุงขั้นตอนการทำสัญญาซอฟต์แวร์ได้อย่างไร Tensibai มีคำถาม:

อะไรที่ทำให้ Capistrano จำเป็นต้องใช้หุ่นเชิดหรือพ่อครัว?

คำตอบของฉันคือโพสต์ลิงก์ไปยังบทความของโนอาห์กิ๊บส์ "เราต้องการทั้ง Capistrano และ Chef หรือไม่?" . โดยส่วนตัวแล้วฉันยังสมัครรับข้อมูลมุมมองของโนอาห์ว่าเหมาะสมที่สุดที่จะ:

• ใช้เครื่องมือการปรับใช้ผู้เชี่ยวชาญเช่น Capistrano สำหรับการปรับใช้
• ใช้เครื่องมือการจัดการการกำหนดค่าผู้เชี่ยวชาญเช่น Chef สำหรับการจัดการการกำหนดค่า

วิธีการพื้นฐานที่เครื่องมือแต่ละประเภทใช้ในการทำงานให้เสร็จสมบูรณ์นั้นแตกต่างกันมาก:

• เครื่องมือการจัดการการกำหนดค่า - เป็นเรื่องเกี่ยวกับการสร้างและรักษาสถานะที่ต้องการของระบบ ตัวอย่างของเครื่องมือในการจัดการการกำหนดค่าเป็นเชฟ , หุ่นกระบอก , เบิ้ล , PowerShell DSC , เกลือสแต็ค

• เครื่องมือการปรับใช้ - เป็นเรื่องเกี่ยวกับการส่งมอบเวอร์ชั่นของซอฟต์แวร์ในสภาพแวดล้อมการโฮสต์ซึ่งมีฟังก์ชันการทำงานเพื่อรักษาซอฟต์แวร์หลายเวอร์ชันบนเครื่องหลายเครื่องและจัดการเวอร์ชันที่เป็น "ปัจจุบัน" ซึ่งมีความจำเป็นโดยธรรมชาติ ตัวอย่างของเครื่องมือการปรับใช้เป็นCapistrano , ปลาหมึก Deploy , DeployerและCommand.io

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

คำถาม:มีเครื่องมือการจัดการการกำหนดค่าเช่น Chef, Ansible และ Puppet ครบกำหนดจนถึงจุดที่พวกเขาสามารถตอบสนองทั้ง idempotent และแบบจำลองที่จำเป็นได้หรือไม่?

ในบริบทดังกล่าวควรใช้คำแนะนำทั่วไปทันที: ใช้เครื่องมือที่เหมาะสมสำหรับงาน

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

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

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

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

ทำให้คำถามนี้เป็นหลักตามความคิดเห็น;)

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

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

เครื่องมือจัดการการกำหนดค่ามีภาษาที่ประกาศซึ่งระบุสถานะของระบบ เครื่องมือการปรับใช้มีภาษาที่จำเป็นซึ่งบอกให้ระบบทำสิ่งต่าง ๆ คน DevOps จำเป็นต้องทำทั้งสองอย่าง

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

การใช้เครื่องมือจัดการการกำหนดค่า Ansible เป็นสิ่งที่งุ่มง่ามในการรีสตาร์ทเว็บเซิร์ฟเวอร์ ภาษาช่วยให้คุณบอกเว็บเซิร์ฟเวอร์ว่าเป็น "up" แต่หากคุณต้องการเริ่มต้นใหม่โดยเฉพาะคุณต้องตั้งค่าสถานะเป็น "เริ่มใหม่" แต่ไม่มีวิธีง่ายๆในการตรวจสอบว่าเว็บเซิร์ฟเวอร์ได้รับการรีสตาร์ทหรือไม่ นี่คือ kludge ใน Ansible เพื่อเปิดใช้งานการดำเนินการแบบครั้งเดียว

บางคนชอบทำงานทั้งสองประเภทด้วยเครื่องมือเดียวและทำงานที่ขอบขรุขระ คนอื่นชอบมีเครื่องมือสองอย่างที่ทำเกือบเหมือนกัน แต่ไม่มีขอบที่ขรุขระ เพื่อตอบคำถาม "ความเหมาะสม" เป็นเรื่องของรสนิยม คำตอบนี้อธิบายว่าทำไม

TL; DR : เพียงใช้ Ansbile เป็นทั้งเครื่องมือกำหนดค่าและการปรับใช้ :)

การปรับใช้มีหลายประเภท:

• แอพลิเคชันที่ใช้ (ไฟล์แพคเกจเก็บถาวร)

• อิงคอนเทนเนอร์ (รวมถึง VM, Habitat, LXC, Docker)

• ตามฟังก์ชั่น (บริการไมโคร / Lambdas / ฟังก์ชั่น)

ฉันคิดว่าในกรณีนี้เราจะพูดเฉพาะเกี่ยวกับการอัปเดตแอปพลิเคชันบนเซิร์ฟเวอร์

สำหรับการปรับใช้คุณต้องมีสองสิ่งเกิดขึ้น:

1. ไฟล์หรือแพ็คเกจที่ถูกต้องจะต้องย้ายไปที่เซิร์ฟเวอร์
2. สถานะการกำหนดค่าและบริการจำเป็นต้องเปลี่ยน

ตอนนี้สำหรับ (1) คุณสามารถใช้หลายกลยุทธ์:

• ที่เก็บ / การประดิษฐ์สิ่งประดิษฐ์
• ที่เก็บแพ็กเกจ / ผู้จัดการแพ็คเกจ
• ระบบควบคุมเวอร์ชัน / การอัพเดท + การคอมไพล์ (เลือกได้)
• โปรโตคอลการถ่ายโอนไฟล์ (scp, rsync, ftp)
• เครื่องมือการปรับใช้

สำหรับ (2) คุณสามารถใช้:

• เครื่องมือจัดการการกำหนดค่า
• เครื่องมือการปรับใช้

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

จากประสบการณ์ส่วนตัวฉันได้ใช้ชุดค่าผสมทั้งหมด แต่ปัจจุบันเราใช้ Capistrano สำหรับการปรับใช้และการซิงค์แบบ Ansible สำหรับการจัดการการกำหนดค่าและ VCS และที่เก็บแพคเกจสำหรับการถ่ายโอนไฟล์ แต่มีปัญหากับ Capistrano และเราวางแผนที่จะย้ายออกจาก รวมกันบน Ansible สำหรับการจัดการการปรับใช้การบำรุงรักษาและการกำหนดค่า

การปรับใช้แอปพลิเคชันเป็นสิ่งที่ยากในการตรึงเนื่องจากมีปัญหาย่อยมากมาย ระบบการจัดการการกำหนดค่านั้นยอดเยี่ยมในการสร้างแบบจำลองซึ่งเป็นแบบรวมกันและทำงานกับ "อะไรคือสถานะที่ต้องการของระบบ" ในบริบทของการปรับใช้แอปสิ่งนี้ยอดเยี่ยมสำหรับสิ่งต่าง ๆ เช่นการปรับใช้บิตกับเครื่องการจัดการไฟล์กำหนดค่าและการตั้งค่าบริการระบบ สิ่งที่ไม่ดีอย่างยิ่งสำหรับสิ่งที่เป็นขั้นตอนโดยเนื้อแท้การโยกย้ายฐานข้อมูลและบริการรีสตาร์ท ฉันมักจะพยายามใส่ตรรกะการบรรจบกันใน Chef และให้เครื่องมือขั้นตอนภายนอก (โดยทั่วไปเป็น Fabric ในเคสของฉัน) จัดการบิตที่เหลือไม่กี่ตัว

ดังนั้นโดยพื้นฐานแล้วคุณควรใช้ทั้งสองอย่างกับชิ้นส่วนที่ดีที่สุด

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

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

สำหรับ Amazon Web Services นี่เป็นสิ่งที่จัดการได้ค่อนข้างสะดวกโดย API ส่วนใหญ่ แต่สำหรับพวกเราที่ต้องจัดการศูนย์ข้อมูลของเราเองนี่ไม่ใช่ตัวเลือก ด้วยเหตุนี้หัวหน้าโครงการ (และหมวกสีแดงอีกครั้งซึ่งแบรนด์นี้ ) ได้พบว่ามันจำเป็นที่จะกำKatello , Candlepinและผู้จัดการการกำหนดค่าเช่นเบิ้ล, Foreman หรือหุ่นกระบอกด้วยกันเมื่อปรับใช้Katello สถานการณ์

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