ฉันควรจะกำหนดค่าแอพพลิเคชั่นของฉันที่ไหน?


17

ฉันได้อ่านเมื่อเร็ว ๆ นี้การอภิปรายเกี่ยวกับ " คุณสมบัติที่ควรขึ้นอยู่กับสภาพแวดล้อมที่ถูกเก็บไว้? "

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

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

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


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

คำตอบ:


6

ใครบอกว่าไฟล์คุณสมบัติและตัวแปรสภาพแวดล้อมที่ไม่เกิดร่วมกัน?

มีความแตกต่างระหว่าง "ฉันจะจัดเก็บการกำหนดค่าแอพของฉันอยู่ที่ไหน" และ " แหล่งที่มาแอพของฉันตั้งค่าอยู่ที่ไหน"

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

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

ซึ่งหมายความว่าคุณต้องมีกระบวนการปรับใช้สองขั้นตอน -

  1. ฉันปรับใช้แอปพลิเคชันอาจเข้าสู่สภาพแวดล้อมโดยผ่านกระบวนการควบคุมการเปลี่ยนแปลง X และทำการตรวจสอบ Y ด้วยเครื่องมือ Z ไม่ว่าอะไรก็ตาม
  2. ฉันปรับใช้การกำหนดค่าสภาพแวดล้อมของฉันลงในสภาพแวดล้อมโดยผ่านกระบวนการควบคุมการเปลี่ยนแปลงและการตรวจสอบ B ด้วยเครื่องมือ C กระบวนการเดียวกันผลลัพธ์ที่แตกต่าง

ในการใช้ตัวอย่างของการจัดการตัวแปรสภาพแวดล้อมเป็นคู่ของ Key Value ในเครื่องมือเช่นกงสุลหากคุณกำลังจัดเก็บไฟล์การกำหนดค่าใน git แล้วเครื่องมือเช่น git2consul ที่มีการจัดการรับการกำหนดค่านั้นเข้าสู่สภาพแวดล้อมเมื่อมีการปรับปรุง

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


0

 วิธีที่เราทำคือเรามี 3 ชิ้น (หรือสิ่งประดิษฐ์) สำหรับแอปพลิเคชันที่ทำงานทุกครั้ง

  1. แอปพลิเคชั่นที่เรากำลังพัฒนา นี่คือสิ่งเดียวกันโดยไม่คำนึงถึงสภาพแวดล้อม เพื่อให้ตรงกับตัวอย่างของคุณนั่นจะเป็นแอปพลิเคชัน Spring เป็น jar / war
  2. คอนเทนเนอร์ที่จะเรียกใช้แอปพลิเคชัน นี่คือสิ่งเดียวกันโดยไม่คำนึงถึงสภาพแวดล้อม หากใช้ Spring Boot คุณไม่จำเป็นต้องใช้ Tomcat อีกต่อไปและเพียงแค่รันไทม์ Java ดังนั้นใช้ openjdk Docker container
  3. การกำหนดค่าที่แอปพลิเคชันต้องการ นี่เป็นสิ่งเดียวที่แตกต่างกันในสภาพแวดล้อม ในแอพ Spring คุณน่าจะใช้ไฟล์คุณสมบัติ

ไฟล์การกำหนดค่าอยู่ในการควบคุมแหล่งที่แยกต่างหาก นี้เคยเป็น Git แต่ตอนนี้เรากำลังใช้ SaaS ที่เราสร้างขึ้นเรียกว่าการกำหนดค่าอย่างhttp://www.configapp.com คุณสมบัติหลักของ Config คือการจัดการการกำหนดค่าเฉพาะสภาพแวดล้อมได้ง่าย ในการเรียกใช้แอปพลิเคชันของเราบนเซิร์ฟเวอร์ใหม่เราจะดึงคอนเทนเนอร์ Docker สิ่งประดิษฐ์ของแอปพลิเคชันและไฟล์การกำหนดค่าสำหรับสภาพแวดล้อมนั้น ในคอนเทนเนอร์เราติดตั้งไดเรกทอรีที่เก็บแอปพลิเคชันและไฟล์กำหนดค่าซึ่งเป็นส่วนหนึ่งของการเรียกใช้คอนเทนเนอร์ แอปพลิเคชันของเราเหมือนกัน คอนเทนเนอร์ / รูปภาพของเราเหมือนกัน ไฟล์การกำหนดค่าเท่านั้นจะแตกต่างกัน

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

เพื่อสรุปเราดึง app.jar, app.properties, openjdk Docker จากนั้นเราเรียกใช้ openjdk Docker เพื่อติดตั้งตำแหน่งของ app.jar และ app.properties สภาวะแวดล้อมเฉพาะสิ่งเดียวคือ app.properties เพื่อจัดการ app.properties ได้อย่างง่ายดายไม่ว่าเราจะใช้คีย์คุณสมบัติ, สภาพแวดล้อม, อินสแตนซ์ของคลัสเตอร์ / ภูมิภาคกี่ครั้งก็ตาม

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