คำถามติดแท็ก databases

ฉันมีการสนทนากับเพื่อนเกี่ยวกับกรณีการใช้งานสำหรับนักเทียบท่า ผู้ชายคนหนึ่งในทีมต้องการใช้ Docker สำหรับทุกสิ่ง - เหมือนเสื้อคลุมกระบวนการยูนิกซ์ทั่วไป อีกคนคิดว่านักเทียบท่าควรใช้กับแอปพลิเคชั่นไร้สัญชาติเช่นMicroservicesและแอพสไตล์AWS Lambdaเท่านั้น เราได้รับการออกแบบทางวิศวกรรมเพื่อพิสูจน์แนวคิดสำหรับทั้งคู่ ในกลุ่มนักเทียบท่าของเราเรามีไดรฟ์ที่ใช้ร่วมกันซึ่งจะถูกเมาท์เมื่อโฮสต์ Docker ถูกเมาต์และถ้าฐานข้อมูลในคอนเทนเนอร์ถูกเมาท์ เพื่อนของฉันยังคงยึดติดกับตำแหน่งของเขาแม้จะแสดงหลักฐานที่ตรงกันข้าม (เขายังให้เหตุผลว่านักเทียบท่าเพิ่มความเสี่ยงที่ไม่จำเป็นโดยการเพิ่มความซับซ้อนให้กับสแต็ก) ฉันพยายามฟังและเข้าใจมุมมองของเขาทั้งในการแสดงความเห็นอกเห็นใจ แต่ก็ให้เหตุผลที่ดีกว่ากับเขาด้วย (เราทุกคนเข้ากันได้ดี - นี่เป็นการผสมผสานระหว่างการพูดคุยอย่างสนุกสนานและจริงจัง) คำถามที่อยู่เบื้องหลังคำถามคือ: เป็นฐานข้อมูลวัว ? ความคิดเห็นนี้แสดงให้เห็นว่าการสำรองข้อมูลอัตโนมัติและกลยุทธ์การดึงข้อมูลที่ดีสำหรับฐานข้อมูลของคุณนั้นแยกไม่ออกจากเซิร์ฟเวอร์วัว คำถามของฉันคืออะไรเหตุผลที่นักเทียบท่าไม่ควรใช้สำหรับฐานข้อมูลคืออะไร แก้ไข: มีคนขอให้ฉันชี้แจงคำศัพท์ของฉัน ฉันสมมติว่าแอ็พพลิเคชันฐานข้อมูลอยู่ในคอนเทนเนอร์และหน่วยเก็บนั้นอยู่ในไดรฟ์ข้อมูล สิ่งที่ฉันหมายถึงคือ RDBMS อยู่ในคอนเทนเนอร์และที่เก็บฐานข้อมูลอยู่ในโวลุ่ม นักวิจารณ์บางคนแนะนำว่าไดรฟ์ข้อมูลไดรฟ์ข้อมูลนักเทียบท่าจะไม่ทำงานกับฐานข้อมูลที่เขียนได้ดีมาก (หรือบางสิ่งบางอย่างเพื่อผลกระทบนั้น) คุณช่วยขยายที่ได้ไหม

25 containers  databases  cattle-vs-pet  risk 

การจัดส่งอย่างต่อเนื่องหรือการปรับใช้อย่างต่อเนื่องของโครงสร้างพื้นฐานและรหัสนั้นค่อนข้างง่ายเมื่อเปรียบเทียบกับการลองใช้วิธีการเดียวกันสำหรับฐานข้อมูลโดยเฉพาะ RDBMS รหัสและโครงสร้างพื้นฐานจะไม่เปลี่ยนแปลงหรือเปลี่ยนแปลงเมื่อการปรับใช้เสร็จสิ้น อย่างไรก็ตามฐานข้อมูลจะมีข้อมูลใหม่เพิ่มเข้ามาเพื่อสร้างข้อมูลหากไม่ใช่สคีมาที่ไม่แน่นอนขององค์ประกอบ ฉันทราบว่ามีวิธีปฏิบัติเช่นเพิ่มเฉพาะวัตถุฐานข้อมูลเช่นตารางและคอลัมน์ไม่เคยแก้ไขหรือลบออก - นี่เป็นวิธีการเพิ่มเติมอย่างหมดจดในการเข้าใกล้ schema ของฐานข้อมูล สกีมา อย่างเท่าเทียมกันมีผลิตภัณฑ์เช่นFlywayและReady Rollซึ่งช่วยในการเขียนการย้ายข้อมูลที่จะเขียนระหว่างสกีมาเวอร์ชันต่างๆ มีวิธีปฏิบัติและเครื่องมืออื่นใดอีกบ้างในปัจจุบันที่อนุญาตให้มีการปรับใช้สกีมาฐานข้อมูลอย่างต่อเนื่องในสภาพแวดล้อมการผลิตที่มีความสมบูรณ์ของข้อมูล

17 continuous-delivery  continuous-deployment  databases 

นี่เป็นคำถามที่กว้างขวางเกี่ยวกับวิธีการและคำแนะนำเกี่ยวกับตัวแปร / โครงสร้างสภาพแวดล้อม แต่ท้ายที่สุดฉันกำลังมองหาคำตอบสำหรับคำถามที่เฉพาะเจาะจงของ 'ฉันจะเก็บตัวแปรสภาพแวดล้อมของฉันได้อย่างไร' ประการแรกการชี้แจงบางอย่าง: สภาพแวดล้อมสำหรับฉันอาจมาจากเซิร์ฟเวอร์ 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 ข้างต้น เนื่องจากไฟล์ตัวแปรเปลี่ยนแปลงค่อนข้างบ่อยสิ่งนี้ทำให้เกิดปัญหากับการเปลี่ยนแปลงข้อมูลครั้งเดียวสองครั้งหรือแม้กระทั่งสามครั้งระหว่างกระทำการเปลี่ยนแปลงยากที่จะติดตามมากขึ้น …

11 ansible  configuration  databases  provisioning  environment-variables