ฉันควรเก็บตัวแปรสภาพแวดล้อมของฉันอย่างไร

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

ประการแรกการชี้แจงบางอย่าง:

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

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

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

ตอนนี้การกำหนดค่าจะเริ่มต้นเป็น submodule ในที่เก็บ git ข้างต้น เนื่องจากไฟล์ตัวแปรเปลี่ยนแปลงค่อนข้างบ่อยสิ่งนี้ทำให้เกิดปัญหากับการเปลี่ยนแปลงข้อมูลครั้งเดียวสองครั้งหรือแม้กระทั่งสามครั้งระหว่างกระทำการเปลี่ยนแปลงยากที่จะติดตามมากขึ้น

ในฐานะที่ผมเองเห็นมันก้าวไปข้างหน้าเราควรจะมองในการจัดเก็บตัวแปรลูกค้าของเราทั้งหมดในศูนย์กลางทาง / ปรับขนาดได้และแล้วเบ็ดลงไปกับสินค้าคงคลังแบบไดนามิกที่มีเบิ้ล

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

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

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

ข้อเสนอแนะใด ๆ

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

ปัจจัยทั่วไป

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

ใช้กงสุล KV Pairs

ตัวแปรสภาพแวดล้อมถูกโหลดจากที่เก็บข้อมูลสิ่งประดิษฐ์ (ไม่เคยเป็น repit git ดั้งเดิม) และโหลดลงในแผนผังคู่ของ KV เนมสเปซ

/env/dev1/my/application/v1.1.1

โดยที่ dev1 ก่อนหน้านี้เป็นชื่อของสภาพแวดล้อม my / application คือ namespace ของแอปพลิเคชันและ v1.1.1 เป็นรุ่นของตัวแปรสภาพแวดล้อมที่จะใช้

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

ปัญหาเกี่ยวกับวิธีการนี้ นักพัฒนาเสมอและฉันหมายถึงทุกครั้งพบวิธีการจัดส่งการเปลี่ยนแปลงการกำหนดค่าในสภาพแวดล้อมที่มีผลกระทบสำคัญกับวิธีการทำงานของโปรแกรมประยุกต์ เพราะมันง่ายกว่าเสมอที่จะได้รับการอนุมัติการเปลี่ยนแปลงการกำหนดค่ามากกว่าการเปลี่ยนแปลงรหัส

การจัดเก็บสิ่งประดิษฐ์ "การปรับใช้" ที่มีตัวแปรฝังอยู่

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

ส่วนการปรับใช้นั้นเป็นไฟล์ yaml ซึ่งมี URL ไปยังไบนารีที่ releasable และการกำหนดค่าทั้งหมดที่แนบมา

แพลตฟอร์มนี้มีส่วนประกอบในการอ่านตัวแปรแล้วนำไปไว้ในแผนผังกระบวนการของแอปพลิเคชันเมื่อเริ่มต้นขึ้น

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

สิ่งนี้ทำให้ยากขึ้นเล็กน้อยสำหรับนักพัฒนาที่จะลองและสร้างตรรกะในแอปพลิเคชันของพวกเขาซึ่งจะเปลี่ยนพฤติกรรมของมันตามตัวแปรเพื่อให้พวกเขาสามารถเปลี่ยนแปลงได้โดยไม่ต้องผ่านวัฏจักรการทดสอบที่เหมาะสม

คะแนนโบนัส

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

การจัดการความลับที่เป็นที่ยอมรับคือเวิร์มของตนเอง แต่มันก็คุ้มค่าที่จะพิจารณา

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

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

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

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