การกำหนดค่าด้วยตัวแปรสภาพแวดล้อม

สารบัญ:

• สรุป
  • ประเด็น
  • การตัดสินใจ
  • สถานะ
• รายละเอียด
  • สมมติฐาน
  • ข้อจำกัด
  • จุดยืน
  • ข้อโต้แย้ง
  • นัยยะ
• ที่เกี่ยวข้อง
  • การตัดสินใจที่เกี่ยวข้อง
  • ข้อกำหนดที่เกี่ยวข้อง
  • ผลงานที่เกี่ยวข้อง
  • หลักการที่เกี่ยวข้อง
• หมายเหตุ

สรุป

ประเด็น

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

• เพื่อบรรลุสิ่งนี้ เราต้องการใช้การกำหนดค่าด้วยตัวแปรสภาพแวดล้อม

• เราต้องการจัดการการกำหนดค่าโดยใช้ไฟล์ที่เราควบคุมเวอร์ชันได้

• เราต้องการให้ความสะดวกด้านประสบการณ์นักพัฒนาบางอย่าง เช่น การรู้ว่ากำหนดค่าอะไรได้และค่าเริ่มต้นที่เกี่ยวข้อง

การตัดสินใจ

ตัดสินใจเลือกไฟล์ .env พร้อมไฟล์ค่าเริ่มต้นและไฟล์สคีมาที่เกี่ยวข้อง

สถานะ

ตัดสินใจแล้ว เปิดรับการพิจารณาความสามารถใหม่เมื่อมีขึ้น

รายละเอียด

สมมติฐาน

เราชอบแยกโค้ดแอปพลิเคชันและโค้ดสภาพแวดล้อม เราสันนิษฐานว่าแอปต้องทำงานต่างกันในสภาพแวดล้อมต่าง ๆ เช่น สภาพแวดล้อมการพัฒนา สภาพแวดล้อมการทดสอบ สภาพแวดล้อมสาธิต สภาพแวดล้อมการผลิต ฯลฯ

เราชอบแนวปฏิบัติของอุตสาหกรรม "12 factor app" และยิ่งกว่านั้นคือแนวปฏิบัติที่เกี่ยวข้อง "15 factor app"

โครงการก่อนหน้าของเราหลายโครงการใช้ข้อตกลงของไฟล์ .env หรือไดเรกทอรี .env ที่คล้ายกัน เป็นแนวปฏิบัติทั่วไปที่จะเก็บไฟล์เหล่านี้ไว้นอกการควบคุมเวอร์ชัน และใช้วิธีอื่นในการติดตั้งใช้งาน กำหนดเวอร์ชัน และจัดการแทน

ข้อจำกัด

เราต้องการเก็บความลับไว้นอกระบบควบคุมเวอร์ชัน (VCS) สำหรับการจัดการซอร์สโค้ด (SCM) ของเรา

เรามุ่งหวังความเข้ากันได้กับเฟรมเวิร์กและไลบรารีซอฟต์แวร์ยอดนิยม เช่น Node มีโมดูล "dotenv" สำหรับอ่านการกำหนดค่าด้วยตัวแปรสภาพแวดล้อม

จุดยืน

เราพิจารณาแนวทางบางอย่าง:

• จัดเก็บการกำหนดค่าในแอป เช่น ในไฟล์ config.js

• จัดเก็บการกำหนดค่าในสภาพแวดล้อม เช่น ในไฟล์ .env

• ดึงการกำหนดค่าจากตำแหน่งที่ทราบ เช่น เซิร์ฟเวอร์ใบอนุญาต

ข้อโต้แย้ง

เราเลือกแนวทางไฟล์ .env เพราะ:

• เป็นที่นิยม รวมถึงในหมู่ผู้เชี่ยวชาญ

• เป็นไปตามรูปแบบของไฟล์ .env ที่ทีมของเราใช้สำเร็จหลายครั้งในหลายโครงการ

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

นัยยะ

เราต้องหาวิธีแยกการกำหนดค่าด้วยตัวแปรสภาพแวดล้อมที่เป็นสาธารณะออกจากการจัดการความลับ

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

เราคาดว่าแอปพลิเคชันทั้งหมดของเราจะใช้แนวทางนี้

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

เราจะคงแอปพลิเคชันของเราที่ใช้แนวทางที่มีความสามารถมากกว่า เช่น เซิร์ฟเวอร์ใบอนุญาต ไว้ตามเดิม

ข้อกำหนดที่เกี่ยวข้อง

เราจะเพิ่มความสามารถด้าน devops สำหรับไฟล์ รวมถึง hook การทดสอบ และการรวมระบบอย่างต่อเนื่อง

เราต้องฝึกอบรมเพื่อนร่วมทีมนักพัฒนาทั้งหมดเกี่ยวกับการตัดสินใจนี้

ผลงานที่เกี่ยวข้อง

แต่ละพื้นที่ที่เราติดตั้งใช้งานจะต้องมีไฟล์ .env และไฟล์ที่เกี่ยวข้องของตนเอง

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย

หมายเหตุ

ไฟล์ตัวอย่าง .env:

NAME=Alice Anderson
EMAIL=alice@example.com

ไฟล์ตัวอย่าง .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

ไฟล์ตัวอย่าง .env.schema ที่มีเฉพาะคีย์:

NAME
EMAIL