วิธีการใช้ตัวแปรและ Vaults ของ Ansible

วิธีที่เราใช้ Ansible อย่างกว้างขวางที่ ExpressVPN

ทีมพัฒนาของเราทำงานอย่างอิสระกล่าวคือทีมเป็นเจ้าของผลิตภัณฑ์ของพวกเขาตลอดวงจรชีวิต การตั้งค่านี้หมายถึงความเข้าใจ Ansible ของเรามาจากการรวบรวมความรู้จากทีมต่าง ๆ ใน บริษัท มากกว่ากลุ่มส่วนกลางที่จัดการ Ansible.

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

เพื่อให้ง่ายต่อการแบ่งปันความรู้และใช้เครื่องมืออย่างถูกต้องเราตัดสินใจที่จะสร้างมาตรฐานวิธีที่เราใช้ Ansible สำหรับการจัดการการกำหนดค่าและการทำงานของเซิร์ฟเวอร์.

บล็อกนี้ครอบคลุมบทเรียนที่เราได้เรียนรู้การทำงานในระดับของเราการสะท้อนถึงวิธีการทำงานของเราและวิธีการจัดการ Ansible ในบริบทดังกล่าว.

เอกสารประกอบ

มาลงความเห็นกันเถอะ! เอกสารสำหรับ Ansible ทำให้บางสิ่งเป็นที่ต้องการโดยเฉพาะอย่างยิ่งเมื่อพูดถึงเอกสารแบบครบวงจร (เช่นคุณจะได้รับจากจุด A ถึงจุด Z ได้อย่างไร).

บางคำถามที่เราพบเป็นประจำคือ:“ ความสำคัญของตัวแปรทำงานอย่างไร” และ“ Ansible Vault นั้นเหมาะสมได้อย่างไร”

ปัญหาทั้งสองได้รับการบันทึกไว้เป็นอย่างดีมาก ๆ (ที่นี่และที่นี่) และหน้าตัวแปร Ansible มีส่วนที่ดีมากเกี่ยวกับลำดับความสำคัญอย่างชัดเจน แต่จุดตัดของทั้งสองได้รับการกล่าวถึงอย่างย่อ ๆ เท่านั้น ปัญหาคือไม่มีการเชื่อมโยงระหว่างเอกสารเกี่ยวกับตัวแปรและห้องใต้ดินทำให้เกิดความรู้สึกว่าผู้ใช้อยู่ในความต้องการของผู้ใช้ในการหาวิธีที่ทั้งสองตัดกัน.

ดังนั้นวันนี้เราจะลองครอบคลุมจุดตัดระหว่างตัวแปรและห้องใต้ดินกับแนวปฏิบัติที่ดีที่สุด.

สิ่งที่คุณสามารถใช้ไฟล์ Ansible Vault

โดยสรุป: เอกสารอธิบายห้องนิรภัยนั้น คุณสามารถเข้ารหัสทุกอย่างภายในโฟลเดอร์ Ansible ของคุณให้เป็นไฟล์ Vault, และ Ansible จะพยายาม “ถอดรหัส” อย่างชาญฉลาดเมื่อใดก็ตามที่การเล่นมีไฟล์เหล่านี้ ฮะ. เย็น!

เอกสารเกี่ยวกับตัวแปรไม่ได้พูดถึงไฟล์ Vault เลยซึ่งแปลกเพราะ Vault นั้นออกแบบมาสำหรับไฟล์ Variable ดังนั้นพวกเขาเข้ากันได้อย่างไร สิ่งสำคัญที่ควรทราบคือ ไฟล์ Vault นั้นไม่มีความหมายพิเศษสำหรับการประมวลผลตัวแปรหรือลำดับความสำคัญ, ดังนั้นจึงมีความยืดหยุ่นมาก แต่สิ่งนี้อาจไม่ทำให้คุณมีข้อมูลเพียงพอเกี่ยวกับวิธีการใช้อย่างถูกต้อง.

คุณทำผิด.

นำตัวอย่างของโฟลเดอร์ Ansible แบบง่าย ๆ นี้:

.
├── group_vars
├──├──ทั้งหมด
├──├──การผลิต
│└──การจัดเตรียม
s ansible.cfg
├──สินค้าคงคลัง
└── playbook.yml

เมื่อดูอย่างแรกการตั้งค่านี้ดูดี นี่จะเป็นโครงสร้างที่ค่อนข้างธรรมดาในการผลิตถ้าคุณอ่านเอกสาร ผู้สังเกตการณ์อาจสันนิษฐานว่าไฟล์ staging และ production ใน group_vars เป็น Vaults แต่ไม่จำเป็นต้องเป็นจริงซึ่งตัวมันเองเป็นปัญหา.

ตอนนี้ไฟล์“ all” ไม่สามารถเป็นไฟล์ Vault ได้เนื่องจากคุณ (หวังว่า) จะเข้ารหัสไฟล์ Staging และ Production Vault ด้วยรหัสผ่านที่แตกต่างกัน แต่ก็หมายความว่าไฟล์ group_vars ของคุณสำหรับสภาพแวดล้อมจำเป็นต้องมีการผสมผสานของความลับและไม่ใช่ความลับเนื่องจากคุณถูก จำกัด เพียงหนึ่งไฟล์ต่อหนึ่งสภาพแวดล้อม.

ด้วยเหตุนี้ – และหากคุณคาดการณ์เล็กน้อยหลังจากอ่านคำนำของ Vaults ในเอกสารประกอบ Ansible – คุณอาจสร้างหลุมฝังศพที่ใช้งานจริง / สร้างฉากโดยการคัดลอกเนื้อหาของ“ all” ในตอนแรกและจากนั้นดัดแปลงมัน.

นั่นหมายความว่าไฟล์“ all” ของคุณอาจมีลักษณะเช่นนี้:

ฐานข้อมูล:
ชื่อผู้ใช้: default_user
รหัสผ่าน: false

super_important_var_that_should_be_one: 1

และไฟล์ Vault ที่ใช้งานของคุณอาจมีลักษณะเช่นนี้:

ฐานข้อมูล:
ชื่อผู้ใช้: produser
รหัสผ่าน: supersecretpasswordnoonecansee

super_important_var_that_should_be_one: 1

(ไม่ต้องกังวลนี่ไม่ใช่รหัสผ่านการใช้งานจริงของเรา! เราตรวจสอบอีกครั้ง)

ด้านบนเป็นอันตรายสำหรับเหตุผลที่อาจไม่ชัดเจน ตัวอย่างเช่นคุณอาจพลาดการเปลี่ยนค่าเริ่มต้นสำหรับการผลิตและ / หรือไฟล์ “all” ของคุณอาจมีชื่อผิดและไม่ได้รวมอยู่ด้วย! (นี่คือสาเหตุของการหยุดทำงานเมื่อสัปดาห์ที่แล้ว)

แนวทางปฏิบัติที่ดี: วิธีใช้ไฟล์ Ansible Vault อย่างปลอดภัย

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

ดังนั้นให้ดูที่โครงสร้างที่จะทำให้ง่ายขึ้นที่จะไม่ยิงตัวเองในเท้า:

.
├── group_vars
├──├──ทั้งหมด
ars │└── vars.yml
├──├──การผลิต
ars │├── vars.yml
ault │└── vault.yml
│└──การจัดเตรียม
ault └── vault.yml
s ansible.cfg
├──สินค้าคงคลัง
└── playbook.yml

เอกสารแนวทางปฏิบัติที่ดีที่สุดยังแนะนำให้ใช้“ เลเยอร์ทางอ้อม” ซึ่งหมายความว่าคุณควรเทมเพลตในตัวแปรทั้งหมดในไฟล์ Vault ลงในตัวแปรที่อ้างอิงภายใน playbooks ของคุณ นอกจากนี้ยังแนะนำให้คุณเติมคำนำหน้าตัวแปรของคุณด้วย“ vault_” ซึ่งหมายความว่า / vars.yml ทั้งหมดของคุณอาจมีลักษณะดังนี้:

ฐานข้อมูล:
ชื่อผู้ใช้: default_user
รหัสผ่าน:“ {{vault_database_password}}”

super_important_var_that_should_be_one: 1

Production / vars.yml ของคุณมีลักษณะดังนี้:

ฐานข้อมูล:
ชื่อผู้ใช้: produser

และไฟล์ production / vault.yml ของคุณควรมีสิ่งนี้:

vault_database_password: supersecretpasswordnoonecansee

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

และที่สำคัญกว่านั้น Ansible จะล้มเหลวแม้กระทั่งการสร้าง vars หากไม่มี vault_database_password ตัวแปรภายในห้องนิรภัยซึ่งจะช่วยให้คุณประหยัดเวลาจากปัญหาอย่างน้อยคุณอาจประสบหากคุณไม่ได้ปิดแท็บที่ปิดไฟล์ Vault ของคุณ.

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

ตอนนี้เราหวังว่าจะเป็นประโยชน์สำหรับคุณ!