จัดการพ่อครัวตำราในสภาพแวดล้อมแบบทีม


13

ฉันกำลังเรียนรู้พ่อครัวและมีปัญหาในการจัดโครงสร้างทุกอย่างเพื่อทำงานกับทีมของฉัน

สำหรับ starters ดูเหมือนว่าคุณควรสร้างโฟลเดอร์ Chef-repo ซึ่งคุณจะจัดเก็บและแก้ไขตำราที่ใช้ในการจัดการโหนดของคุณ

ฉันทำงานในโครงการต่าง ๆ และแต่ละคนอยู่ภายใต้การควบคุมแหล่ง git แล้ว จะเป็นการดีที่ฉันจะเก็บโฟลเดอร์ repo ของพ่อครัวหนึ่งโฟลเดอร์ในแต่ละโครงการของฉันด้วยโครงการตำราอาหารใช่ไหม

อย่างไรก็ตามในโฟลเดอร์ chef-repo ฉันต้องเพิ่มโฟลเดอร์การกำหนดค่า (.chef) ด้วยการกำหนดค่ามีดของฉันและการตรวจสอบความถูกต้องที่สำคัญของฉันและสิ่งเหล่านี้เฉพาะสำหรับฉัน เป็นเรื่องปกติหรือไม่ที่จะเพิ่มโฟลเดอร์. chef ไปยังไฟล์ gitignore

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

ขอบคุณสำหรับความช่วยเหลือ!


คุณสามารถตั้งค่า.chefโฟลเดอร์ให้ใช้ตัวแปรสภาพแวดล้อมหรืออะไรก็ได้
ceejayoz

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

มันช่างดีจริงๆที่หุ่นเชิดรองรับสภาพแวดล้อมเช่นนี้โดยกำเนิด
Tom O'Connor

คำตอบ:


15

ฉันทำงานกับหลายโครงการดังนั้นโซลูชันของ cjc จะไม่ทำงานสำหรับฉัน นอกจากนี้ยังมีปัญหาของการกำหนดค่าทั่วไป vs กำหนดเอง (ที่อยู่ ฯลฯ เป็นเรื่องปกติของ บริษัท และยังมีเวทมนตร์ในการกำหนดค่า) ในที่สุดแผนการที่ฉันใช้คือแฮ็ค แต่มันก็สะดวกในการใช้งาน

แทนที่จะใช้ทั่วโลก~/.chefฉันใช้ไดเรกทอรีย่อย '.chef' ภายใน chef-repo ซึ่งไม่ได้เก็บไว้ในคอมไพล์ (ถูกเพิ่มเข้าไป.gitignore) ฉันยังมีไฟล์config/knife.rbไฟล์ที่มีการตรวจสอบใน Git และมีการกำหนดค่าที่ใช้ร่วมกัน มันเริ่มต้นด้วยตัวอย่างนี้:

root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
  conf = File.join(root_dir, ".chef", conf_name)
  Kernel::load(conf) if File.exists? conf
end

ไฟล์นี้โหลดไฟล์.chef/knife-local.rbที่มีการกำหนดค่าแบบกำหนดเอง (ในเวอร์ชั่นพื้นฐานเป็นเพียงOPSCODE_USER='username'ค่าคงที่ที่ใช้ในภายหลัง แต่สามารถมีค่าคอนฟิกมีดใด ๆ ) และ.chef/knife-secrets.rbมีความลับที่ใช้ร่วมกัน (คีย์ AWS เป็นต้น)

ด้านล่างนั้นมีการกำหนดค่ามีดปกติที่ใช้ค่าคงที่ที่กำหนดในไฟล์เหล่านี้เช่น:

client_key               "#{root_dir}/.chef/#{OPSCODE_USER}.pem"

ด้วยวิธีนี้ฉันได้รับการตั้งค่ามีดแบบสแตนด์อโลนทั่วทั้ง บริษัท ซึ่งหมายความว่าข้อมูลโค้ดใด ๆ หรือการเรียกใช้มีดที่ใช้ร่วมกันในวิกินั้นจะใช้ได้กับทุกคน มีความสับสนและเวทย์มนตร์เพียงพอในตัวมีด - การกำหนดค่าต่าง ๆ จะทำให้แย่ลงเท่านั้น นอกจากนี้ทุกคนยังได้รับประโยชน์จากตัวอย่างมายากลขนาดเล็กเช่นนี้เพื่อknife sshใช้ในการกำหนดค่าการเข้าสู่ระบบในผู้ใช้~/.ssh/config

นอกจากนี้ยังมีเรื่องของความลับที่แชร์: คีย์การตรวจสอบของเซิร์ฟเวอร์เชฟ, คีย์ AWS ที่เก็บไว้ในknife-secrets.rb, คีย์ส่วนตัว SSH ของ EC2, คีย์กระเป๋าข้อมูลที่เข้ารหัสและอื่น ๆ เราไม่ต้องการให้จัดเก็บไว้ในที่เก็บ - หรือที่ใดก็ตามที่พวกเขาไม่ได้เข้ารหัสอย่างปลอดภัย ดังนั้นเราจึงแจกจ่ายไฟล์เหล่านั้นเป็น.tar.gzไฟล์ซึ่งมีการเข้ารหัส GPG ให้กับทุกคนใน บริษัท และแชร์ผ่าน Dropbox

การกำหนดค่าทั้งหมดนี้มีความซับซ้อนและฉันต้องการให้ผู้คนในทีมใช้สิ่งนั้นจริง ๆ ดังนั้นจึงมีองค์ประกอบสุดท้าย: rake initงานที่สร้าง.chefไดเรกทอรีconfig/knife.rbเชื่อมโยงที่นั่นถอดรหัสและchef-secrets.tgzไฟล์untars ทำให้แน่ใจว่าผู้ใช้ Opscode แพลตฟอร์มส่วนตัวนั้น.chef/knife-local.rbอยู่ในตำแหน่งที่ถูกต้อง กำหนดค่า, symlink ดปลั๊กอินและกำหนดสิทธิ์ที่เหมาะสมในไดเรกทอรีและไฟล์ภายใน งานนี้ได้รับการตั้งค่าเพื่อให้สามารถเรียกใช้งานได้หลายครั้งในที่เก็บข้อมูลที่เริ่มต้นแล้ว (เช่นเพื่ออัปเดตความลับหรือมีดปลั๊กอิน)

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

เกี่ยวกับสภาพแวดล้อมหลาย: เชฟมีคุณสมบัติที่เรียกว่าสภาพแวดล้อม ฉันยังไม่ได้ใช้ แต่ควรทำในสิ่งที่คุณต้องการ นอกจากนี้คุณยังสามารถแยกสภาพแวดล้อมการผลิตอย่างเคร่งครัด (เพื่อหลีกเลี่ยงนักพัฒนาที่มีคีย์ใด ๆ ที่เกี่ยวข้องในทางใดทางหนึ่งในการผลิต env) โดยมีสององค์กร Hosted Chef แยกต่างหากหรือเซิร์ฟเวอร์ Chef ตัวอย่างเกร็ดความรู้ใบมีดนี้แสดงวิธีการตั้งค่ามีดในวิธีที่แตกต่างกันไปตามสาขาที่ตรวจสอบในปัจจุบัน - คุณสามารถใช้สิ่งนี้เพื่อตั้งค่าสภาพแวดล้อมเช่นเดียวกับ URL ของเซิร์ฟเวอร์พ่อครัว นอกจากนี้ยังมีปลั๊กอินมีดที่เรียกว่ามีดโฟลว์ ซึ่งให้เวิร์กโฟลว์สององค์กรที่สมบูรณ์ยิ่งขึ้น


ขอบคุณสำหรับคำตอบโดยละเอียด การดูงานที่เข้าสู่การตั้งค่าอย่างน้อยก็หมายความว่าฉันไม่พลาดสิ่งที่ชัดเจน ...
Alex Recarey

3

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

หรือคุณสามารถละทิ้งแนวคิดเซิร์ฟเวอร์ Chef และใช้ Chef-solo คุณสามารถรักษาตำราอาหารของคุณใน Git คุณสามารถแยกสาขาและรวม คุณสามารถเพิกเฉยปัญหากับหนังสือรับรองของมีดเพราะคุณจะไม่ใช้มันอีกต่อไป

คุณจะไม่สามารถใช้มีดค้นหาหรือถุงข้อมูล ** แต่บางคนไม่ต้องการคุณสมบัติเหล่านั้นอยู่ดี

** คุณสามารถจัดเรียงกระป๋องได้: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo


2

ฉันมีสองไดเรกทอรีในบ้านของฉัน. chef และ chef-repo Chef-repo อยู่ในคอมไพล์ . chef เป็นไดเรกทอรีส่วนตัวที่เป็นค่าเริ่มต้นสำหรับมีด คุณไม่จำเป็นต้องใส่ความลับของคุณจาก. chef เป็นคอมไพล์; มีดจะมองหา ~ / .chef


2

ไดเรกทอรี ~ / .chef ของคุณไม่ควรอยู่ใน git repo

ฉันมีไดเรกทอรี ~ / projects / ซึ่งฉันเก็บ repo พ่อครัวไว้ ในส่วนนี้จะเป็นการกำหนดค่าเซิร์ฟเวอร์ของฉัน

งานสุดท้ายของฉันคือเป็นวิศวกรระบบที่ร้าน Ruby-on-Rails nginx, varnish และ rails ของเรา (ในกลุ่มอื่น ๆ ) ไปที่ repo ของพ่อครัว แต่แอพ Rails นั้นถูกเก็บไว้ใน repos git แยกกันและถูกแยกออกจากกัน

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.