โปรโฮสต์ > บล็อก > การบริหาร > Docker เป็นของเล่นหรือไม่? หรือยังจริงอยู่?

Docker เป็นของเล่นหรือไม่? หรือยังจริงอยู่?

Hello!

ฉันอยากจะตรงไปที่หัวข้อนี้จริงๆ แต่จะเป็นการถูกต้องมากกว่าถ้าเล่าเรื่องของฉันสักเล็กน้อย:

การเข้า

ฉันเป็นโปรแกรมเมอร์ที่มีประสบการณ์ในการพัฒนาแอปพลิเคชันหน้าเดียว, scala/java และ nodejs บนเซิร์ฟเวอร์

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

ระหว่างทาง ฉันได้พบกับผู้คนมากมายซึ่งมีทัศนคติต่อ Docker และระบบนิเวศที่แตกต่างกัน บางคนบอกว่านี่เป็นสิ่งที่สะดวกสบายที่รับประกันการทำงานข้ามแพลตฟอร์ม คนที่สองไม่เข้าใจว่าทำไมพวกเขาถึงวิ่งในคอนเทนเนอร์และจะได้กำไรอะไรจากมัน คนที่สามไม่สนใจเลยและไม่สนใจ (พวกเขาแค่เขียนโค้ดแล้วกลับบ้าน - ฉันอิจฉาพวกเขาโดย ทาง :)

เหตุผลในการใช้งาน

ทำไมฉันถึงใช้นักเทียบท่า? อาจเป็นเพราะสาเหตุดังต่อไปนี้:

  • เปิดตัวฐานข้อมูล 99% ของแอปพลิเคชันใช้งาน
  • เปิดตัว nginx สำหรับการกระจายส่วนหน้าและการพร็อกซีไปยังแบ็กเอนด์
  • คุณสามารถจัดแพคเกจแอปพลิเคชันเป็นอิมเมจนักเทียบท่าได้ ด้วยวิธีนี้แอปพลิเคชันของฉันจะทำงานได้ทุกที่ที่มีนักเทียบท่าอยู่ ปัญหาการกระจายจะได้รับการแก้ไขทันที
  • การค้นพบบริการนอกกรอบ คุณสามารถสร้าง microservices แต่ละคอนเทนเนอร์ (เชื่อมต่อกับเครือข่ายทั่วไป) สามารถเข้าถึงอีกคอนเทนเนอร์หนึ่งได้อย่างง่ายดายผ่านนามแฝง สะดวกมาก
  • การสร้างคอนเทนเนอร์และ "เล่น" ในนั้นเป็นเรื่องสนุก

สิ่งที่ฉันไม่ชอบเกี่ยวกับนักเทียบท่าเสมอ:

  • เพื่อให้แอปพลิเคชันของฉันทำงานได้ ฉันจำเป็นต้องมี Docker บนเซิร์ฟเวอร์ เหตุใดฉันจึงต้องการสิ่งนี้หากแอปพลิเคชันของฉันทำงานบน jre หรือ nodejs และสภาพแวดล้อมสำหรับแอปพลิเคชันเหล่านั้นอยู่บนเซิร์ฟเวอร์อยู่แล้ว
  • หากฉันต้องการเรียกใช้อิมเมจที่สร้างขึ้นในเครื่อง (ส่วนตัว) บนเซิร์ฟเวอร์ระยะไกล ฉันก็จำเป็นต้องมีพื้นที่เก็บข้อมูลนักเทียบท่าของตัวเอง ฉันต้องการให้รีจิสทรีทำงานที่ไหนสักแห่ง และฉันต้องกำหนดค่า https ด้วย เนื่องจาก docker cli ทำงานบน https เท่านั้น โอ้พระเจ้า... แน่นอนว่ามีตัวเลือกในการบันทึกภาพในเครื่องผ่าน docker save แล้วส่งภาพมาทาง scp... แต่นั่นเป็นการเคลื่อนไหวของร่างกายเยอะมาก นอกจากนี้ มันดูเหมือนเป็นวิธีแก้ปัญหาแบบ "ไม้ยันรักแร้" จนกว่าพื้นที่เก็บข้อมูลของคุณจะปรากฏขึ้น
  • docker-compose. จำเป็นสำหรับการรันคอนเทนเนอร์เท่านั้น นั่นคือทั้งหมดที่ เขาไม่สามารถทำอะไรได้อีก Docker-compose มีไฟล์หลายเวอร์ชัน มีไวยากรณ์เป็นของตัวเอง ไม่ว่าจะเปิดเผยแค่ไหน ฉันก็ไม่อยากอ่านเอกสารของพวกเขา ฉันจะไม่ต้องการมันที่อื่น
  • เมื่อทำงานเป็นทีมคนส่วนใหญ่เขียน Dockerfile ผิดมาก ไม่เข้าใจว่ามันแคชยังไง เพิ่มทุกอย่างที่ต้องการและไม่ต้องการลงในอิมเมจ สืบทอดจากอิมเมจที่ไม่ได้อยู่ใน Dockerhub หรือ Private Repository สร้างบางส่วน docker-compose ไฟล์ที่มีฐานข้อมูลและไม่มีสิ่งใดคงอยู่ ในเวลาเดียวกัน นักพัฒนาประกาศอย่างภาคภูมิใจว่า Docker นั้นเจ๋ง ทุกอย่างใช้งานได้ในท้องถิ่นสำหรับพวกเขา และที่สำคัญฝ่าย HR เขียนในตำแหน่งที่ว่างว่า: “เราใช้ Docker และเราต้องการผู้สมัครที่มีประสบการณ์การทำงานเช่นนั้น”
  • ฉันถูกหลอกหลอนด้วยความคิดเกี่ยวกับการยกทุกอย่างใน Docker: postgresql, kafka, redis น่าเสียดายที่ไม่ใช่ทุกสิ่งที่จะทำงานในคอนเทนเนอร์ได้ ไม่ใช่ทุกสิ่งที่จะกำหนดค่าและเรียกใช้ได้ง่าย สิ่งนี้ได้รับการสนับสนุนจากนักพัฒนาบุคคลที่สาม ไม่ใช่จากผู้จำหน่ายเอง และอย่างไรก็ตาม คำถามก็เกิดขึ้นทันที: ผู้ขายไม่ต้องกังวลกับการบำรุงรักษาผลิตภัณฑ์ของตนใน Docker เหตุใดจึงเป็นเช่นนี้ บางทีพวกเขาอาจรู้อะไรบางอย่าง?
  • คำถามนี้มักเกิดขึ้นเกี่ยวกับการคงอยู่ของข้อมูลคอนเทนเนอร์เสมอ แล้วคุณคิดว่า ฉันควรเมานต์ไดเร็กทอรีโฮสต์หรือสร้างโวลุ่มนักเทียบท่าหรือสร้างที่เก็บข้อมูลซึ่งตอนนี้เป็นอยู่ deprecated? หากฉันเมานต์ไดเร็กทอรี ฉันต้องตรวจสอบให้แน่ใจว่า uid และ gid ของผู้ใช้ในคอนเทนเนอร์ตรงกับ id ของผู้ใช้ที่เปิดใช้คอนเทนเนอร์ ไม่เช่นนั้นไฟล์ที่สร้างโดยคอนเทนเนอร์จะถูกสร้างขึ้นด้วยสิทธิ์รูท ถ้าฉันใช้ volume จากนั้นข้อมูลก็จะถูกสร้างขึ้นในบางส่วน /usr/* และก็จะมีเรื่องเดียวกันกับ uid และ gid เหมือนอย่างกรณีแรก หากคุณกำลังเปิดตัวส่วนประกอบของบริษัทอื่น คุณต้องอ่านเอกสารประกอบและค้นหาคำตอบสำหรับคำถาม: “ส่วนประกอบเขียนไฟล์ในไดเร็กทอรีคอนเทนเนอร์ใด”

ฉันไม่ชอบความจริงที่ว่าฉันต้องยุ่งกับ Docker นานเกินไป ในระยะเริ่มแรก: ฉันรู้วิธีเปิดคอนเทนเนอร์, อิมเมจใดที่จะเรียกใช้, สร้าง Makefiles ที่มีนามแฝงเป็นคำสั่ง Docker แบบยาว ฉันเกลียดการเขียนนักเทียบท่าเพราะฉันไม่ต้องการเรียนรู้เครื่องมืออื่นในระบบนิเวศของนักเทียบท่า และ docker-compose up มันทำให้ฉันรำคาญ โดยเฉพาะถ้าพวกเขายังพบกันที่นั่น build การก่อสร้างมากกว่าภาพที่ประกอบแล้ว สิ่งเดียวที่ฉันต้องการจริงๆ คือสร้างผลิตภัณฑ์อย่างมีประสิทธิภาพและรวดเร็ว แต่ฉันไม่รู้ว่าจะใช้นักเทียบท่าอย่างไร

แนะนำ Ansible

เมื่อเร็วๆ นี้ (สามเดือนที่แล้ว) ฉันทำงานร่วมกับทีม DevOps ซึ่งสมาชิกเกือบทุกคนมีทัศนคติเชิงลบต่อ Docker ด้วยเหตุผล:

  • นักเทียบท่ากฎ iptables (แม้ว่าคุณจะสามารถปิดการใช้งานได้ใน daemon.json)
  • นักเทียบท่าเป็นรถบั๊กกี้และเราจะไม่ใช้งานจริง
  • หาก docker daemon ขัดข้อง แสดงว่าคอนเทนเนอร์ทั้งหมดที่มีโครงสร้างพื้นฐานพังตามนั้น
  • ไม่จำเป็นต้องมีนักเทียบท่า
  • ทำไมต้องนักเทียบท่าหากมี Ansible และเครื่องเสมือน

ในงานเดียวกัน ฉันคุ้นเคยกับเครื่องมืออื่น - Ansible ฉันได้ยินเรื่องนี้ครั้งหนึ่ง แต่ฉันไม่ได้พยายามเขียน playbook ของตัวเอง และตอนนี้ฉันเริ่มเขียนงานแล้ววิสัยทัศน์ของฉันก็เปลี่ยนไปอย่างสิ้นเชิง! เพราะฉันรู้ว่า Ansible มีโมดูลสำหรับการรันคอนเทนเนอร์นักเทียบท่า การสร้างอิมเมจ เครือข่าย ฯลฯ และคอนเทนเนอร์สามารถทำงานได้ไม่เพียงแต่ในเครื่องเท่านั้น แต่ยังบนเซิร์ฟเวอร์ระยะไกลด้วย! ความสุขของฉันไม่มีขอบเขต - ฉันพบเครื่องมือ NORMAL และโยนไฟล์ Makefile และไฟล์นักเทียบท่าของฉันทิ้งไป พวกมันถูกแทนที่ด้วยงาน yaml รหัสลดลงโดยใช้โครงสร้างเช่น loop, whenฯลฯ

นักเทียบท่าสำหรับการรันส่วนประกอบของบุคคลที่สาม เช่น ฐานข้อมูล

ฉันเพิ่งเริ่มคุ้นเคยกับ ssh tunnels ปรากฎว่าการ "ส่งต่อ" พอร์ตของเซิร์ฟเวอร์ระยะไกลไปยังพอร์ตในเครื่องนั้นง่ายมาก เซิร์ฟเวอร์ระยะไกลอาจเป็นเครื่องในระบบคลาวด์หรือเครื่องเสมือนที่ทำงานใน VirtualBox หากเพื่อนร่วมงานของฉันหรือฉันต้องการฐานข้อมูล (หรือส่วนประกอบของบุคคลที่สามอื่นๆ) เราก็สามารถเริ่มต้นเซิร์ฟเวอร์ด้วยส่วนประกอบนี้และปิดการทำงานเมื่อไม่จำเป็นต้องใช้เซิร์ฟเวอร์ การส่งต่อพอร์ตให้ผลเช่นเดียวกับฐานข้อมูลที่ทำงานในคอนเทนเนอร์นักเทียบท่า

คำสั่งนี้ส่งต่อพอร์ตในเครื่องของฉันไปยังเซิร์ฟเวอร์ระยะไกลที่ทำงาน postgresql:

ssh -L 9000:โลคัลโฮสต์:5432 [ป้องกันอีเมล]

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

ฉันเพิ่งอ่านเจอว่าอุโมงค์ SSH มีฟังก์ชันการทำงานที่จำกัดของ VPN ทั่วไป! คุณสามารถติดตั้ง OpenVPN หรือการใช้งาน VPN อื่นๆ ตั้งค่าโครงสร้างพื้นฐานและมอบให้นักพัฒนาใช้งานได้ นี่มันเจ๋งมาก!

โชคดีที่ AWS, GoogleCloud และอื่นๆ ให้คุณใช้งานได้ฟรีหนึ่งปี ดังนั้นจงใช้มันเลย! พวกมันราคาถูกถ้าคุณปิดมันเมื่อไม่ได้ใช้งาน ฉันสงสัยอยู่เสมอว่าทำไมฉันถึงต้องการเซิร์ฟเวอร์ระยะไกลเช่น gcloud ดูเหมือนว่าฉันจะพบมันแล้ว

ในฐานะเครื่องเสมือนในเครื่อง คุณสามารถใช้ Alpine เดียวกันซึ่งใช้งานอยู่ในคอนเทนเนอร์นักเทียบท่าได้ หรือการกระจายน้ำหนักเบาอื่น ๆ เพื่อให้เครื่องบูตเร็วขึ้น

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

เล็กน้อยเกี่ยวกับอิมเมจนักเทียบท่าและการกระจาย

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

คุณเคยเห็นที่ใดที่นักพัฒนาซอฟต์แวร์พอร์ตผลิตภัณฑ์ของตนในรูปแบบนักเทียบท่าเท่านั้น?
ผลลัพธ์ของผลิตภัณฑ์ส่วนใหญ่คือไฟล์ไบนารีสำหรับแพลตฟอร์มเฉพาะ ซึ่งจะถูกเพิ่มลงในอิมเมจนักเทียบท่าซึ่งสืบทอดมาจากแพลตฟอร์มที่ต้องการ คุณเคยสงสัยบ้างไหมว่าทำไมถึงมีรูปภาพที่คล้ายกันมากมายบน dockerhub? ตัวอย่างเช่น ป้อน nginx คุณจะเห็นรูปภาพ 100500 รูปจากบุคคลอื่น คนเหล่านี้ไม่ได้พัฒนา nginx เอง พวกเขาเพียงเพิ่ม nginx อย่างเป็นทางการให้กับอิมเมจนักเทียบท่าและปรุงรสด้วยการกำหนดค่าของตนเองเพื่อความสะดวกในการเปิดตัวคอนเทนเนอร์

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

สรุป: ฉันไม่ต้องการรีจิสทรีนักเทียบท่า ฉันจะใช้ S3 บางประเภทหรือเพียงแค่พื้นที่จัดเก็บไฟล์เช่น Google Drive/Dropbox

นักเทียบท่าใน CI

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

บริษัทเหล่านี้ใช้นักเทียบท่าบนเซิร์ฟเวอร์ที่กระบวนการ CI ทำงาน คำถาม: เหตุใดคุณจึงต้องสร้างโปรเจ็กต์ในคอนเทนเนอร์นักเทียบท่าบนเซิร์ฟเวอร์ของคุณ ทำไมไม่เพียงแค่เตรียมสภาพแวดล้อมสำหรับบิลด์ เช่น เขียน Playbook Ansible ที่จะติดตั้งเวอร์ชันที่จำเป็นของ nodejs, php, jdk, คัดลอกคีย์ ssh ฯลฯ ไปยังเซิร์ฟเวอร์ที่บิลด์จะเกิดขึ้น

ตอนนี้ฉันเข้าใจแล้วว่านี่เป็นการตอกย้ำตัวเองเพราะนักเทียบท่าไม่ได้สร้างผลกำไรใด ๆ ด้วยความโดดเดี่ยว ปัญหาที่ฉันพบกับ CI ในนักเทียบท่า:

  • คุณต้องมีอิมเมจนักเทียบท่าเพื่อสร้างอีกครั้ง คุณต้องค้นหารูปภาพหรือเขียน dockerfile ของคุณเอง
  • 90% ที่คุณต้องส่งต่อคีย์ ssh ซึ่งเป็นข้อมูลลับที่คุณไม่ต้องการเขียนไปยังอิมเมจนักเทียบท่า
  • คอนเทนเนอร์ถูกสร้างขึ้นและตาย แคชทั้งหมดจะหายไปพร้อมกับมัน รุ่นถัดไปจะดาวน์โหลดการขึ้นต่อกันของโปรเจ็กต์ทั้งหมดอีกครั้ง ซึ่งใช้เวลานานและไม่มีประสิทธิภาพ และเวลาคือเงิน

Developer ไม่ได้สร้างโปรเจ็กต์ใน Docker Container (ฉันเคยเป็นแฟนตัวยงมาก่อน จริงๆ ฉันรู้สึกเสียใจกับตัวเองในอดีต xD) ใน Java คุณสามารถมีหลายเวอร์ชันและเปลี่ยนเวอร์ชันเหล่านั้นด้วยคำสั่งเดียวให้เป็นเวอร์ชันที่คุณต้องการตอนนี้ มันเหมือนกันใน nodejs นั่นคือ nvm

เอาท์พุต

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

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

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

หากคุณยังคงตัดสินใจใช้นักเทียบท่า ให้ทำดังนี้:

  • ระมัดระวังเป็นอย่างยิ่ง
  • อย่าบังคับให้นักพัฒนาใช้นักเทียบท่า
  • จำกัดการใช้งานในที่เดียว อย่ากระจายไปยังที่เก็บ Dockefile และ Docker-compose ทั้งหมด

PS:

ขอบคุณสำหรับการอ่าน ฉันขอให้คุณตัดสินใจอย่างโปร่งใสในเรื่องของคุณและวันทำงานที่มีประสิทธิผล!

ที่มา: will.com

เพิ่มความคิดเห็น