ก่อนอื่นมีทฤษฎีเล็กน้อย เกิดอะไรขึ้น ?
กล่าวง่ายๆ ก็คือ เอกสารนี้ได้รับการออกแบบมาเพื่อลดความซับซ้อนในการพัฒนาแอปพลิเคชัน SaaS โดยช่วยแจ้งนักพัฒนาและวิศวกร DevOps เกี่ยวกับปัญหาและแนวทางปฏิบัติที่พบบ่อยที่สุดในการพัฒนาแอปพลิเคชันสมัยใหม่
เอกสารนี้สร้างขึ้นโดยผู้พัฒนาแพลตฟอร์ม Heroku
แอป Twelve-Factor สามารถนำไปใช้กับแอปพลิเคชันที่เขียนด้วยภาษาการเขียนโปรแกรมใด ๆ และใช้บริการสำรองข้อมูลร่วมกัน (ฐานข้อมูล คิวข้อความ แคช ฯลฯ )
โดยสังเขปเกี่ยวกับปัจจัยที่ใช้วิธีนี้:
- รหัสเบส – หนึ่งโค้ดเบสที่ถูกติดตามในการควบคุมเวอร์ชัน – การปรับใช้หลายครั้ง
- การพึ่งพา – ประกาศอย่างชัดเจนและแยกการพึ่งพา
- องค์ประกอบ – บันทึกการกำหนดค่าในรันไทม์
- บริการสนับสนุน – พิจารณาบริการสำรองข้อมูลเป็นทรัพยากรปลั๊กอิน
- สร้าง ปล่อย วิ่ง – แยกขั้นตอนการประกอบและการดำเนินการออกจากกันอย่างเคร่งครัด
- กระบวนการต่างๆ – เรียกใช้แอปพลิเคชันเป็นกระบวนการไร้สัญชาติตั้งแต่หนึ่งกระบวนการขึ้นไป
- การผูกพอร์ต – บริการส่งออกโดยผูกท่าเรือ
- ความเท่าเทียม – ปรับขนาดแอปพลิเคชันของคุณโดยใช้กระบวนการ
- ความสามารถในการทิ้ง – เพิ่มความน่าเชื่อถือสูงสุดด้วยการเริ่มต้นระบบที่รวดเร็วและการปิดระบบใหม่ทั้งหมด
- การพัฒนาแอปพลิเคชัน/ความเท่าเทียมกันในการดำเนินงาน – รักษาสภาพแวดล้อมการพัฒนา การจัดเตรียม และการใช้งานจริงของคุณให้คล้ายกันมากที่สุด
- การบันทึก – ดูบันทึกเป็นกระแสของเหตุการณ์
- งานธุรการ – ดำเนินงานด้านการบริหาร/การจัดการโดยใช้กระบวนการเฉพาะกิจ
คุณสามารถรับข้อมูลเพิ่มเติมเกี่ยวกับปัจจัย 12 ประการได้จากแหล่งข้อมูลต่อไปนี้:
- - ต้องอ่าน
- — การแปลอย่างเป็นทางการ
- - มุมมองใหม่ของปัจจัย 12 ประการโดยมีเป้าหมายเพื่อปรับปรุงปัจจัยเหล่านั้น
การใช้งาน Blue-Green คืออะไร?
การปรับใช้สีน้ำเงิน-เขียวเป็นวิธีหนึ่งในการส่งแอปพลิเคชันไปให้ การผลิต ในลักษณะที่ลูกค้าไม่เห็นการเปลี่ยนแปลงใดๆ ในส่วนของเขา กล่าวอีกนัยหนึ่ง การปรับใช้แอปพลิเคชันด้วยศูนย์ หยุดทำงาน.
รูปแบบการปรับใช้ BG แบบคลาสสิกมีลักษณะเหมือนกับที่แสดงในภาพด้านล่าง
- ในช่วงเริ่มต้นจะมีเซิร์ฟเวอร์จริง 2 เครื่องที่มีโค้ด แอปพลิเคชัน โปรเจ็กต์เหมือนกันทุกประการ และมีเราเตอร์ (บาลานเซอร์)
- เราเตอร์เริ่มส่งคำขอทั้งหมดไปยังเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่ง (สีเขียว).
- ในช่วงเวลาที่คุณต้องการเผยแพร่อีกครั้ง โครงการทั้งหมดจะได้รับการอัปเดตบนเซิร์ฟเวอร์อื่น (สีน้ำเงิน) ซึ่งขณะนี้ไม่ได้ประมวลผลคำขอใดๆ
- หลังจากที่รหัสเปิดอยู่ สีน้ำเงิน เซิร์ฟเวอร์ได้รับการอัพเดตอย่างสมบูรณ์ เราเตอร์จะได้รับคำสั่งให้เปลี่ยนจาก สีเขียว บน สีน้ำเงิน เซิร์ฟเวอร์
- ตอนนี้ไคลเอนต์ทั้งหมดเห็นผลลัพธ์ของโค้ดที่ทำงานด้วย สีน้ำเงิน เซิร์ฟเวอร์
- บางครั้ง, สีเขียว เซิร์ฟเวอร์จะทำหน้าที่เป็นสำเนาสำรองในกรณีที่ปรับใช้ไม่สำเร็จ สีน้ำเงิน เซิร์ฟเวอร์ และในกรณีที่เกิดข้อผิดพลาดและข้อบกพร่อง เราเตอร์จะสลับโฟลว์ผู้ใช้กลับไป สีเขียว เซิร์ฟเวอร์เวอร์ชันเก่าที่เสถียร และส่งโค้ดใหม่ไปตรวจสอบและทดสอบ
- และเมื่อสิ้นสุดกระบวนการก็จะมีการอัพเดตในลักษณะเดียวกัน สีเขียว เซิร์ฟเวอร์ และหลังจากอัปเดตแล้ว เราเตอร์จะสลับโฟลว์คำขอกลับไปเป็น สีเขียว เซิร์ฟเวอร์
ทุกอย่างดูดีมากและเมื่อมองแวบแรกก็ไม่น่าจะมีปัญหาใด ๆ
แต่เนื่องจากเราอาศัยอยู่ในโลกสมัยใหม่ ตัวเลือกที่มีการสลับทางกายภาพตามที่ระบุไว้ในรูปแบบคลาสสิกจึงไม่เหมาะกับเรา บันทึกข้อมูลไว้ตอนนี้เราจะกลับมาข้อมูลในภายหลัง
คำแนะนำที่ไม่ดีและดี
ข้อจำกัดความรับผิดชอบ: ตัวอย่างด้านล่างแสดงยูทิลิตี้/วิธีการที่ฉันใช้ คุณสามารถใช้ทางเลือกอื่นที่มีฟังก์ชันคล้ายกันได้
ตัวอย่างส่วนใหญ่จะตัดกับการพัฒนาเว็บไม่ทางใดก็ทางหนึ่ง (ซึ่งเป็นเรื่องที่น่าประหลาดใจ) กับ PHP และ Docker
ย่อหน้าด้านล่างมีคำอธิบายเชิงปฏิบัติง่ายๆ เกี่ยวกับการใช้ปัจจัยโดยใช้ตัวอย่างที่เฉพาะเจาะจง หากคุณต้องการทราบทฤษฎีเพิ่มเติมในหัวข้อนี้ โปรดไปที่ลิงก์ด้านบนไปยังแหล่งข้อมูลต้นฉบับ
1. โค้ดเบส
ใช้ FTP และ FileZilla เพื่ออัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ทีละไฟล์ อย่าเก็บโค้ดไว้ที่อื่นนอกเหนือจากบนเซิร์ฟเวอร์ที่ใช้งานจริง
โปรเจ็กต์ควรมีฐานโค้ดเดียวเสมอ นั่นคือโค้ดทั้งหมดมาจากฐานเดียว ไป พื้นที่เก็บข้อมูล เซิร์ฟเวอร์ (การผลิต การจัดเตรียม การทดสอบ 1 การทดสอบ 2...) ใช้โค้ดจากสาขาของพื้นที่เก็บข้อมูลทั่วไปแห่งเดียว วิธีนี้ทำให้เราบรรลุความสอดคล้องของโค้ด
2. การพึ่งพาอาศัยกัน
ดาวน์โหลดไลบรารีทั้งหมดในโฟลเดอร์โดยตรงไปที่รูทของโปรเจ็กต์ อัปเดตได้ง่ายๆ โดยการโอนรหัสใหม่ไปยังโฟลเดอร์ที่มีไลบรารีเวอร์ชันปัจจุบัน ติดตั้งยูทิลิตี้ที่จำเป็นทั้งหมดโดยตรงบนโฮสต์เซิร์ฟเวอร์ซึ่งมีบริการอีก 20 รายการกำลังทำงานอยู่
โครงการควรมีรายการการขึ้นต่อกันที่เข้าใจได้ชัดเจนเสมอ (ตามการขึ้นต่อกันฉันหมายถึงสภาพแวดล้อมด้วย) การขึ้นต่อกันทั้งหมดจะต้องมีการกำหนดและแยกออกจากกันอย่างชัดเจน
ลองมาเป็นตัวอย่าง แต่ง и นักเทียบท่า.
แต่ง — ตัวจัดการแพ็คเกจที่ให้คุณติดตั้งไลบรารี่ใน PHP Composer อนุญาตให้คุณระบุเวอร์ชันอย่างเคร่งครัดหรือหลวมๆ และกำหนดเวอร์ชันเหล่านั้นอย่างชัดเจน บนเซิร์ฟเวอร์สามารถมีโปรเจ็กต์ที่แตกต่างกันได้ 20 โปรเจ็กต์ และแต่ละโปรเจ็กต์จะมีรายการแพ็คเกจและไลบรารีส่วนบุคคลที่ไม่ขึ้นกับโปรเจ็กต์อื่น
นักเทียบท่า — ยูทิลิตี้ที่ช่วยให้คุณกำหนดและแยกสภาพแวดล้อมที่แอปพลิเคชันจะทำงาน เช่นเดียวกับผู้แต่ง แต่เราสามารถระบุได้ว่าแอปพลิเคชันใช้งานได้กับอะไรอย่างละเอียดยิ่งขึ้น เลือกเวอร์ชันเฉพาะของ PHP ติดตั้งเฉพาะแพ็คเกจที่จำเป็นสำหรับโปรเจ็กต์ในการทำงาน โดยไม่ต้องเพิ่มอะไรเพิ่มเติม และที่สำคัญที่สุด โดยไม่รบกวนแพ็คเกจและสภาพแวดล้อมของเครื่องโฮสต์และโปรเจ็กต์อื่นๆ นั่นคือโครงการทั้งหมดบนเซิร์ฟเวอร์ที่ทำงานผ่าน Docker สามารถใช้ชุดแพ็คเกจใดก็ได้และสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
3. การกำหนดค่า
จัดเก็บการกำหนดค่าเป็นค่าคงที่โดยตรงในโค้ด แยกค่าคงที่สำหรับเซิร์ฟเวอร์ทดสอบ แยกสำหรับการใช้งานจริง เชื่อมโยงการทำงานของแอปพลิเคชันโดยขึ้นอยู่กับสภาพแวดล้อมโดยตรงในตรรกะทางธุรกิจของโปรเจ็กต์โดยใช้ if else build
การกำหนดค่า - นี่เป็นวิธีเดียวที่การปรับใช้โครงการจะแตกต่างกัน ตามหลักการแล้ว ควรส่งการกำหนดค่าผ่านตัวแปรสภาพแวดล้อม (env vars)
นั่นคือแม้ว่าคุณจะเก็บไฟล์การกำหนดค่าหลายไฟล์ .config.prod .config.local และเปลี่ยนชื่อในขณะที่ปรับใช้เป็น .config (การกำหนดค่าหลักที่แอปพลิเคชันอ่านข้อมูล) - นี่จะไม่ใช่แนวทางที่ถูกต้องเนื่องจาก ในกรณีนี้ ข้อมูลจากการกำหนดค่าจะเปิดเผยต่อสาธารณะสำหรับนักพัฒนาแอปพลิเคชันทั้งหมด และข้อมูลจากเซิร์ฟเวอร์ที่ใช้งานจริงจะถูกบุกรุก การกำหนดค่าทั้งหมดจะต้องจัดเก็บไว้ในระบบการปรับใช้โดยตรง (CI/CD) และสร้างขึ้นสำหรับสภาพแวดล้อมที่แตกต่างกันโดยมีค่าที่แตกต่างกันซึ่งจำเป็นสำหรับสภาพแวดล้อมเฉพาะ ณ เวลาที่ปรับใช้
4. บริการของบุคคลที่สาม
เชื่อมโยงกับสภาพแวดล้อมอย่างเคร่งครัด ใช้การเชื่อมต่อที่แตกต่างกันสำหรับบริการเดียวกันในบางสภาพแวดล้อม
ในความเป็นจริงจุดนี้ทับซ้อนอย่างมากกับประเด็นเกี่ยวกับการกำหนดค่าเนื่องจากหากไม่มีจุดนี้ข้อมูลการกำหนดค่าปกติจะไม่สามารถทำได้และโดยทั่วไปความสามารถในการกำหนดค่าจะลดลงจนเหลืออะไรเลย
การเชื่อมต่อกับบริการภายนอกทั้งหมด เช่น เซิร์ฟเวอร์คิว ฐานข้อมูล บริการแคช จะต้องเหมือนกันสำหรับทั้งสภาพแวดล้อมภายในเครื่องและสภาพแวดล้อมของบริษัทอื่น/สภาพแวดล้อมการใช้งานจริง กล่าวอีกนัยหนึ่ง เมื่อใดก็ได้ โดยการเปลี่ยนสตริงการเชื่อมต่อ ฉันสามารถแทนที่การเรียกไปยังฐาน #1 ด้วยฐาน #2 โดยไม่ต้องเปลี่ยนรหัสแอปพลิเคชัน หรือมองไปข้างหน้า เป็นตัวอย่าง เมื่อปรับขนาดบริการ คุณจะไม่จำเป็นต้องระบุการเชื่อมต่อด้วยวิธีพิเศษสำหรับเซิร์ฟเวอร์แคชเพิ่มเติม
5. สร้าง ปล่อย ดำเนินการ
มีเฉพาะโค้ดเวอร์ชันสุดท้ายบนเซิร์ฟเวอร์ โดยไม่มีโอกาสย้อนกลับการเผยแพร่ ไม่จำเป็นต้องเติมพื้นที่ดิสก์ ใครก็ตามที่คิดว่าสามารถปล่อยโค้ดเข้าสู่การผลิตโดยมีข้อผิดพลาดได้นั้นคือโปรแกรมเมอร์ที่แย่!
ทุกขั้นตอนของการปรับใช้จะต้องแยกออกจากกัน
มีโอกาสที่จะย้อนกลับ สร้างการเผยแพร่ด้วยสำเนาแอปพลิเคชันเก่า (ประกอบแล้วและพร้อมสำหรับการต่อสู้) ที่บันทึกไว้ในการเข้าถึงอย่างรวดเร็ว ดังนั้นในกรณีที่เกิดข้อผิดพลาด คุณสามารถกู้คืนเวอร์ชันเก่าได้ นั่นคือมีโฟลเดอร์ตามเงื่อนไข เผยแพร่ และโฟลเดอร์ ปัจจุบันและหลังจากการปรับใช้และประกอบโฟลเดอร์สำเร็จ ปัจจุบัน เชื่อมโยงกันด้วยลิงก์สัญลักษณ์ไปยังรุ่นใหม่ที่อยู่ภายใน เผยแพร่ ด้วยชื่อสามัญของหมายเลขรุ่น
นี่คือจุดที่เราจดจำการปรับใช้สีน้ำเงิน-เขียว ซึ่งช่วยให้คุณไม่เพียงแต่สลับระหว่างโค้ดเท่านั้น แต่ยังสลับระหว่างทรัพยากรทั้งหมดและแม้กระทั่งสภาพแวดล้อมที่มีความสามารถในการย้อนกลับทุกอย่าง
6. กระบวนการ
จัดเก็บข้อมูลสถานะแอปพลิเคชันภายในแอปพลิเคชันโดยตรง ใช้เซสชันใน RAM ของแอปพลิเคชันเอง ใช้การแบ่งปันระหว่างบริการของบุคคลที่สามให้มากที่สุด อาศัยความจริงที่ว่าแอปพลิเคชันสามารถมีได้เพียงกระบวนการเดียวและไม่อนุญาตให้ปรับขนาด
เกี่ยวกับเซสชัน ให้จัดเก็บข้อมูลไว้ในแคชที่ควบคุมโดยบริการของบุคคลที่สามเท่านั้น (memcached, redis) ดังนั้นแม้ว่าคุณจะมีกระบวนการแอปพลิเคชัน 20 กระบวนการทำงานอยู่ก็ตาม เมื่อเข้าถึงแคชแล้ว จะสามารถทำงานกับไคลเอนต์ต่อไปได้ สถานะเดียวกับที่ผู้ใช้ทำงานกับแอปพลิเคชันในกระบวนการอื่น ด้วยแนวทางนี้ ปรากฎว่าไม่ว่าคุณจะใช้บริการของบุคคลที่สามจำนวนเท่าใด ทุกอย่างก็ทำงานได้ตามปกติและไม่มีปัญหาในการเข้าถึงข้อมูล
7. การผูกพอร์ต
เฉพาะเว็บเซิร์ฟเวอร์เท่านั้นที่ควรทราบวิธีทำงานกับบริการของบุคคลที่สาม หรือดีกว่านั้น ติดตั้งบริการของบุคคลที่สามโดยตรงภายในเว็บเซิร์ฟเวอร์ ตัวอย่างเช่น เป็นโมดูล PHP ใน Apache
บริการทั้งหมดของคุณจะต้องเข้าถึงได้ผ่านการเข้าถึงที่อยู่และพอร์ตบางส่วน (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) นั่นคือจาก nginx ฉันสามารถเข้าถึงทั้ง php-fpm และ postgres และจาก php-fpm ไปจนถึง postgres และ nginx และจริงๆ แล้วจากแต่ละบริการ ฉันสามารถเข้าถึงบริการอื่นได้ ด้วยวิธีนี้ ความมีชีวิตของบริการจะไม่เชื่อมโยงกับความมีชีวิตของบริการอื่น
8. ความเท่าเทียม
ทำงานกับกระบวนการเดียวมิฉะนั้นหลายกระบวนการจะไม่สามารถทำงานร่วมกันได้!
เหลือพื้นที่ไว้สำหรับการปรับขนาด Docker swarm นั้นยอดเยี่ยมสำหรับสิ่งนี้
Docker Swarm เป็นเครื่องมือสำหรับสร้างและจัดการคลัสเตอร์ของคอนเทนเนอร์ทั้งระหว่างเครื่องที่แตกต่างกันและพวงของคอนเทนเนอร์บนเครื่องเดียวกัน
เมื่อใช้ Swarm ฉันสามารถกำหนดจำนวนทรัพยากรที่ฉันจะจัดสรรให้กับแต่ละกระบวนการ และจำนวนกระบวนการของบริการเดียวกันที่ฉันจะเปิดตัว และตัวปรับสมดุลภายในที่ได้รับข้อมูลบนพอร์ตที่กำหนด จะพร็อกซีไปยังกระบวนการโดยอัตโนมัติ ดังนั้น เมื่อเห็นว่าโหลดบนเซิร์ฟเวอร์เพิ่มขึ้น ฉันจึงสามารถเพิ่มกระบวนการได้มากขึ้น ซึ่งช่วยลดภาระของกระบวนการบางอย่างได้
9. การกำจัดทิ้ง
อย่าใช้คิวเพื่อทำงานกับกระบวนการและข้อมูล การฆ่ากระบวนการเดียวควรส่งผลต่อแอปพลิเคชันทั้งหมด หากบริการใดบริการหนึ่งล่ม ทุกอย่างก็ล่มหมด
แต่ละกระบวนการและบริการสามารถปิดได้ตลอดเวลา และสิ่งนี้ไม่ควรส่งผลกระทบต่อบริการอื่นๆ (แน่นอนว่านี่ไม่ได้หมายความว่าบริการจะไม่พร้อมใช้งานสำหรับบริการอื่น แต่บริการอื่นจะไม่ปิดหลังจากบริการนี้) กระบวนการทั้งหมดจะต้องยุติลงอย่างสวยงาม เพื่อว่าเมื่อสิ้นสุดกระบวนการแล้ว จะไม่มีข้อมูลเสียหาย และระบบจะทำงานได้อย่างถูกต้องในครั้งถัดไปที่คุณเปิดใช้งาน นั่นคือแม้ในกรณีที่มีการยุติฉุกเฉิน ข้อมูลไม่ควรได้รับความเสียหาย (กลไกการทำธุรกรรมเหมาะสมที่นี่ การสืบค้นในฐานข้อมูลจะทำงานเฉพาะในกลุ่มเท่านั้น และหากการสืบค้นอย่างน้อยหนึ่งรายการจากกลุ่มล้มเหลวหรือดำเนินการด้วย เกิดข้อผิดพลาด ดังนั้นจึงไม่มีการสืบค้นอื่นใดจากกลุ่มที่ล้มเหลวในที่สุด)
10. การพัฒนาแอปพลิเคชัน/ความเท่าเทียมกันในการดำเนินงาน
เวอร์ชันที่ใช้งานจริง การจัดเตรียม และเวอร์ชันในเครื่องของแอปพลิเคชันต้องแตกต่างกัน ในการผลิตเราใช้เฟรมเวิร์ก Yii Lite และ Yii ภายในเครื่อง เพื่อให้ทำงานได้เร็วขึ้นในการผลิต!
ในความเป็นจริง การปรับใช้และการทำงานกับโค้ดทั้งหมดควรอยู่ในสภาพแวดล้อมที่เกือบจะเหมือนกัน (เราไม่ได้หมายถึงฮาร์ดแวร์จริง) นอกจากนี้ พนักงานฝ่ายพัฒนาควรจะปรับใช้โค้ดกับการใช้งานจริงได้หากจำเป็น และไม่ใช่แผนก Devops ที่ได้รับการฝึกอบรมมาเป็นพิเศษ ซึ่งมีเพียงความแข็งแกร่งพิเศษเท่านั้นที่สามารถยกแอปพลิเคชันไปสู่การใช้งานจริงได้
นักเทียบท่ายังช่วยเราในเรื่องนี้ด้วย หากสังเกตจุดก่อนหน้าทั้งหมด การใช้นักเทียบท่าจะทำให้กระบวนการปรับใช้สภาพแวดล้อมทั้งในการผลิตและบนเครื่องท้องถิ่นเข้าสู่หนึ่งหรือสองคำสั่ง
11. บันทึก
เราเขียนบันทึกลงในไฟล์และฐานข้อมูล! เราไม่ล้างไฟล์และฐานข้อมูลจากบันทึก แค่ซื้อฮาร์ดไดรฟ์ที่มี 9000 Peta ไบต์ก็ไม่เป็นไร
บันทึกทั้งหมดควรถือเป็นกระแสของเหตุการณ์ แอปพลิเคชันไม่ควรเกี่ยวข้องกับการประมวลผลบันทึก บันทึกควรส่งออกไปที่ stdout หรือส่งผ่านโปรโตคอล เช่น udp เพื่อให้การทำงานกับบันทึกไม่สร้างปัญหาใดๆ สำหรับแอปพลิเคชัน greylog ดีสำหรับสิ่งนี้ Graylog การรับบันทึกทั้งหมดผ่าน udp (โปรโตคอลนี้ไม่จำเป็นต้องรอการตอบกลับเกี่ยวกับการรับแพ็กเก็ตที่สำเร็จ) จะไม่รบกวนแอปพลิเคชันในทางใดทางหนึ่ง และเกี่ยวข้องกับโครงสร้างและการประมวลผลบันทึกเท่านั้น ตรรกะของแอปพลิเคชันไม่เปลี่ยนแปลงเพื่อให้ทำงานกับแนวทางดังกล่าว
12. งานธุรการ
หากต้องการอัปเดตข้อมูล ฐานข้อมูล ฯลฯ ให้ใช้ตำแหน่งข้อมูลที่สร้างขึ้นแยกต่างหากใน API โดยการดำเนินการ 2 ครั้งติดต่อกันจะส่งผลให้ทุกอย่างถูกทำซ้ำ แต่คุณไม่ได้โง่ คุณจะไม่คลิกสองครั้ง และเราไม่ต้องการการโยกย้าย
งานการดูแลระบบทั้งหมดควรดำเนินการในสภาพแวดล้อมเดียวกันกับโค้ดทั้งหมด ในระดับรีลีส นั่นคือหากเราจำเป็นต้องเปลี่ยนโครงสร้างของฐานข้อมูล เราจะไม่ดำเนินการด้วยตนเองโดยการเปลี่ยนชื่อคอลัมน์และเพิ่มคอลัมน์ใหม่ผ่านเครื่องมือการจัดการฐานข้อมูลภาพบางอย่าง สำหรับสิ่งเหล่านี้ เราสร้างสคริปต์แยกต่างหาก - การย้ายข้อมูล ซึ่งดำเนินการทุกที่และในทุกสภาพแวดล้อมในลักษณะเดียวกันโดยให้ผลลัพธ์ที่เหมือนกันและเข้าใจได้ สำหรับงานอื่นๆ ทั้งหมด เช่น การกรอกข้อมูลในโครงการ ควรใช้วิธีการที่คล้ายกัน
ตัวอย่างการใช้งานใน PHP, Laravel, Laradock, Docker-Compose
ป.ล. ตัวอย่างทั้งหมดถูกสร้างขึ้นบน MacOS ส่วนใหญ่ยังเหมาะสำหรับ Linux ผู้ใช้ Windows ขออภัยด้วย แต่ฉันไม่ได้ทำงานกับ Windows มานานแล้ว
ลองจินตนาการถึงสถานการณ์ที่เราไม่มี PHP เวอร์ชันใดติดตั้งอยู่บนพีซีของเราและไม่มีอะไรเลย
ติดตั้ง docker และ docker-compose เวอร์ชันล่าสุด (สามารถพบได้บนอินเทอร์เน็ต)
docker -v &&
docker-compose -v
1. เราใส่
git clone https://github.com/Laradock/laradock.git &&
ls
เกี่ยวกับ Laradock ฉันจะบอกว่ามันเจ๋งมากซึ่งมีคอนเทนเนอร์และสิ่งเสริมมากมาย แต่ฉันจะไม่แนะนำให้ใช้ Laradock โดยไม่มีการแก้ไขในการผลิตเนื่องจากมีความซ้ำซ้อน จะดีกว่าถ้าสร้างคอนเทนเนอร์ของคุณเองตามตัวอย่างใน Laradock ซึ่งจะได้รับการปรับให้เหมาะสมมากขึ้น เนื่องจากไม่มีใครต้องการทุกสิ่งที่มีอยู่ในเวลาเดียวกัน
2. กำหนดค่า Laradock เพื่อเรียกใช้แอปพลิเคชันของเรา
cd laradock &&
cp env-example .env
2.1. เปิดไดเร็กทอรี habr (โฟลเดอร์หลักที่มีการโคลน laradock) ในโปรแกรมแก้ไขบางตัว (ในกรณี PHPStorm ของฉัน)
ในขั้นตอนนี้เราจะตั้งชื่อโครงการเท่านั้น
2.2. เปิดใช้งานอิมเมจพื้นที่ทำงาน (ในกรณีของคุณ รูปภาพจะใช้เวลาพอสมควรในการสร้าง)
Workspace เป็นอิมเมจที่เตรียมไว้เป็นพิเศษสำหรับการทำงานกับเฟรมเวิร์กในนามของนักพัฒนา
เราเข้าไปในภาชนะโดยใช้
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. การติดตั้ง Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. หลังการติดตั้ง เราจะตรวจสอบว่าไดเร็กทอรีที่มีโปรเจ็กต์ถูกสร้างขึ้นหรือไม่ และคิลเขียน
ls
exit
docker-compose down
2.5. กลับไปที่ PHPStorm และตั้งค่าเส้นทางที่ถูกต้องไปยังแอปพลิเคชัน laravel ของเราในไฟล์ .env
3. เพิ่มโค้ดทั้งหมดลงใน Git
ในการทำเช่นนี้ เราจะสร้างพื้นที่เก็บข้อมูลบน Github (หรือที่อื่น ๆ ) ไปที่ไดเร็กทอรี habr ในเทอร์มินัลแล้วรันโค้ดต่อไปนี้
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
ตรวจสอบว่าทุกอย่างเป็นไปตามลำดับหรือไม่
เพื่อความสะดวก ฉันแนะนำให้ใช้อินเทอร์เฟซแบบภาพสำหรับ Git ในกรณีของฉัน . (นี่คือลิงค์อ้างอิง)
4. เปิดตัวเลย!
ก่อนเริ่มต้น ตรวจสอบให้แน่ใจว่าไม่มีอะไรค้างอยู่บนพอร์ต 80 และ 443
docker-compose up -d nginx php-fpm
ดังนั้นโครงการของเราจึงประกอบด้วย 3 บริการแยกกัน:
- nginx - เว็บเซิร์ฟเวอร์
- php-fpm - php สำหรับรับคำขอจากเว็บเซิร์ฟเวอร์
- พื้นที่ทำงาน - PHP สำหรับนักพัฒนา
ในขณะนี้เราประสบความสำเร็จในการสร้างแอปพลิเคชันที่ตรงตาม 4 คะแนนจาก 12 คะแนน ได้แก่ :
1. รหัสเบส — โค้ดทั้งหมดอยู่ในที่เก็บข้อมูลเดียว (หมายเหตุเล็กๆ: การเพิ่มนักเทียบท่าในโปรเจ็กต์ laravel อาจถูกต้อง แต่นี่ไม่สำคัญ)
2. การพึ่งพา — การพึ่งพาของเราทั้งหมดเขียนไว้อย่างชัดเจนใน application/composer.json และในแต่ละ Dockerfile ของแต่ละคอนเทนเนอร์
3. บริการสนับสนุน — แต่ละบริการ (php-fom, nignx, พื้นที่ทำงาน) ใช้ชีวิตของตัวเองและเชื่อมต่อจากภายนอก และเมื่อทำงานกับบริการหนึ่ง อีกบริการหนึ่งจะไม่ได้รับผลกระทบ
4. กระบวนการต่างๆ — แต่ละบริการเป็นหนึ่งกระบวนการ แต่ละบริการไม่ได้รักษาสถานะภายใน
5. การผูกพอร์ต
docker ps
ดังที่เราเห็น แต่ละบริการทำงานบนพอร์ตของตัวเองและสามารถเข้าถึงบริการอื่น ๆ ทั้งหมดได้
6. ความเท่าเทียม
นักเทียบท่าช่วยให้เราสร้างกระบวนการต่างๆ ของบริการเดียวกันด้วยการปรับสมดุลโหลดอัตโนมัติระหว่างกระบวนการเหล่านั้น
มาหยุดคอนเทนเนอร์แล้ววิ่งผ่านแฟล็กกันเถอะ --มาตราส่วน
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
ดังที่เราเห็น มีการสร้างสำเนาของคอนเทนเนอร์ php-fpm เราไม่จำเป็นต้องเปลี่ยนแปลงอะไรในการทำงานกับคอนเทนเนอร์นี้ เรายังเข้าถึงมันต่อไปบนพอร์ต 9000 และ Docker จะควบคุมโหลดระหว่างคอนเทนเนอร์ให้เรา
7. ความสามารถในการทิ้ง - แต่ละคอนเทนเนอร์สามารถถูกฆ่าได้โดยไม่ทำร้ายอีกคอนเทนเนอร์ การหยุดหรือรีสตาร์ทคอนเทนเนอร์จะไม่ส่งผลต่อการทำงานของแอปพลิเคชันในระหว่างการเปิดตัวครั้งต่อไป แต่ละคอนเทนเนอร์สามารถยกได้ตลอดเวลา
8. การพัฒนาแอปพลิเคชัน/ความเท่าเทียมกันในการดำเนินงาน - สภาพแวดล้อมของเราทั้งหมดเหมือนกัน ด้วยการรันระบบบนเซิร์ฟเวอร์ในการผลิต คุณจะไม่ต้องเปลี่ยนแปลงอะไรในคำสั่งของคุณ ทุกอย่างจะขึ้นอยู่กับ Docker ในลักษณะเดียวกัน
9. การบันทึก — บันทึกทั้งหมดในคอนเทนเนอร์เหล่านี้จะถูกสตรีมและมองเห็นได้ในคอนโซล Docker (ในกรณีนี้กับภาชนะทำเองอื่นๆอาจจะไม่เป็นอย่างนั้นถ้าคุณไม่ดูแล)
docker-compose logs -f
แต่มีข้อเสียคือค่าเริ่มต้นใน PHP และ Nginx เขียนบันทึกลงในไฟล์ด้วย เพื่อให้บรรลุปัจจัย 12 ประการนั้นจำเป็น ปิด การเขียนบันทึกลงในไฟล์ในการกำหนดค่าของแต่ละคอนเทนเนอร์แยกกัน
นักเทียบท่ายังให้ความสามารถในการส่งบันทึกไม่เพียงแต่ไปยัง stdout แต่ยังรวมถึงสิ่งต่าง ๆ เช่น greylog ซึ่งฉันได้กล่าวไว้ข้างต้น และภายใน greylog เราสามารถดำเนินการบันทึกได้ตามต้องการ และแอปพลิเคชันของเราจะไม่สังเกตเห็นสิ่งนี้ในทางใดทางหนึ่ง
10. งานธุรการ — งานการดูแลระบบทั้งหมดได้รับการแก้ไขโดย laravel ด้วยเครื่องมือช่างที่ผู้สร้างแอปพลิเคชัน 12 ปัจจัยต้องการ
ตัวอย่างเช่น ฉันจะแสดงวิธีดำเนินการคำสั่งบางคำสั่ง
เราเข้าไปในภาชนะ
docker-compose exec workspace bash
php artisan list
ตอนนี้เราสามารถใช้คำสั่งใดก็ได้ (โปรดทราบว่าเราไม่ได้กำหนดค่าฐานข้อมูลและแคช ดังนั้นคำสั่งครึ่งหนึ่งจึงไม่สามารถดำเนินการได้อย่างถูกต้อง เนื่องจากได้รับการออกแบบมาให้ทำงานกับแคชและฐานข้อมูล)
11. การกำหนดค่า และ 12 สร้าง ปล่อย วิ่ง
ฉันต้องการอุทิศส่วนนี้ให้กับ Blue-Green Deployment แต่กลายเป็นว่าครอบคลุมเกินไปสำหรับบทความนี้ ฉันจะเขียนบทความแยกต่างหากเกี่ยวกับเรื่องนี้
โดยสรุป แนวคิดนี้อิงตามระบบ CI/CD เช่น เจนกิ้นส์ и Gitlab CI. ในทั้งสองอย่าง คุณสามารถตั้งค่าตัวแปรสภาพแวดล้อมที่เกี่ยวข้องกับสภาพแวดล้อมเฉพาะได้ ดังนั้น ในกรณีนี้ จะต้องปฏิบัติตามข้อ c การกำหนดค่า.
และประเด็นเกี่ยวกับ สร้าง ปล่อย วิ่ง ได้รับการแก้ไขโดยฟังก์ชันในตัวพร้อมชื่อ ท่อ.
ท่อ ช่วยให้คุณสามารถแบ่งกระบวนการปรับใช้ออกเป็นหลายขั้นตอน โดยเน้นขั้นตอนของการประกอบ การเปิดตัว และการดำเนินการ นอกจากนี้ใน Pipeline คุณสามารถสร้างการสำรองข้อมูลและอะไรก็ได้ นี่คือเครื่องมือที่มีศักยภาพอันไร้ขีดจำกัด
รหัสสมัครอยู่ที่ .
อย่าลืมเริ่มต้นโมดูลย่อยเมื่อทำการโคลนพื้นที่เก็บข้อมูลนี้
PS: วิธีการทั้งหมดนี้สามารถใช้ได้กับยูทิลิตี้และภาษาการเขียนโปรแกรมอื่น ๆ สิ่งสำคัญคือสาระสำคัญไม่แตกต่างกัน
ที่มา: will.com