โปรโฮสต์ > บล็อก > การบริหาร > ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ

ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ

มาสายดีกว่าไม่มาเลย. หรือว่าเราเกือบจะทำผิดพลาดร้ายแรงโดยไม่รองรับ Dockerfiles ปกติในการสร้างอิมเมจแอปพลิเคชัน

ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ

เราจะพูดถึง เวร — ยูทิลิตี้ GitOps ที่ทำงานร่วมกับระบบ CI/CD และให้การจัดการวงจรการใช้งานแอปพลิเคชันทั้งหมด ช่วยให้:

  • รวบรวมและเผยแพร่ภาพ
  • ปรับใช้แอปพลิเคชันใน Kubernetes
  • ลบภาพที่ไม่ได้ใช้โดยใช้นโยบายพิเศษ


ปรัชญาของโครงการนี้คือการรวบรวมเครื่องมือระดับต่ำมาไว้ในระบบรวมศูนย์เดียวที่ช่วยให้วิศวกร DevOps ควบคุมแอปพลิเคชันต่างๆ ได้ หากเป็นไปได้ ควรใช้ยูทิลิตี้ที่มีอยู่ (เช่น Helm และ Docker) หากไม่มีวิธีแก้ไขปัญหา เราสามารถสร้างและสนับสนุนทุกสิ่งที่จำเป็นสำหรับสิ่งนี้

พื้นหลัง: นักสะสมภาพของคุณเอง

นี่คือสิ่งที่เกิดขึ้นกับตัวรวบรวมรูปภาพใน werf: Dockerfile ปกติไม่เพียงพอสำหรับเรา หากคุณดูประวัติของโครงการอย่างรวดเร็ว ปัญหานี้ปรากฏใน werf เวอร์ชันแรกแล้ว (จากนั้นยังคง รู้จักกันในชื่อ dapp).

ในขณะที่สร้างเครื่องมือสำหรับสร้างแอปพลิเคชันลงในอิมเมจ Docker เราก็รู้ได้อย่างรวดเร็วว่า Dockerfile ไม่เหมาะสำหรับเราสำหรับงานเฉพาะบางอย่าง:

  1. ความจำเป็นในการสร้างเว็บแอปพลิเคชันขนาดเล็กทั่วไปตามรูปแบบมาตรฐานต่อไปนี้:
    • ติดตั้งการพึ่งพาแอปพลิเคชันทั้งระบบ
    • ติดตั้งชุดไลบรารีการพึ่งพาแอปพลิเคชัน
    • รวบรวมทรัพย์สิน
    • และที่สำคัญคืออัพเดทโค้ดในภาพอย่างรวดเร็วและมีประสิทธิภาพ
  2. เมื่อมีการเปลี่ยนแปลงไฟล์โปรเจ็กต์ ตัวสร้างจะต้องสร้างเลเยอร์ใหม่อย่างรวดเร็วโดยใช้แพตช์กับไฟล์ที่เปลี่ยนแปลง
  3. หากไฟล์บางไฟล์มีการเปลี่ยนแปลง จำเป็นต้องสร้างสเตจที่ต้องพึ่งพาที่เกี่ยวข้องใหม่

ปัจจุบันนักสะสมของเรามีความเป็นไปได้อื่นๆ มากมาย แต่สิ่งเหล่านี้คือความปรารถนาและแรงกระตุ้นในช่วงแรกๆ

โดยทั่วไปแล้ว โดยไม่ต้องคิดซ้ำซาก เราก็เตรียมภาษาการเขียนโปรแกรมที่เราใช้ไว้ (ดูด้านล่าง) และเข้าสู่แนวทางการปฏิบัติ ดีเอสแอลของตัวเอง! ตามวัตถุประสงค์ มีวัตถุประสงค์เพื่ออธิบายกระบวนการประกอบเป็นขั้นตอนและพิจารณาการพึ่งพาของขั้นตอนเหล่านี้ในไฟล์ และเสริมด้วย นักสะสมของตัวเองซึ่งเปลี่ยน DSL ให้เป็นเป้าหมายสุดท้าย - ภาพที่ประกอบขึ้น ตอนแรก DSL อยู่ใน Ruby แต่เป็น เปลี่ยนไปใช้โกลัง — การกำหนดค่าของตัวรวบรวมของเราเริ่มอธิบายไว้ในไฟล์ YAML

ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ
การกำหนดค่าเก่าสำหรับ dapp ใน Ruby

ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ
การกำหนดค่าปัจจุบันสำหรับ werf บน YAML

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

NB: ในขณะนี้ Collector ของเราซึ่งทำงานร่วมกับการกำหนดค่าของตัวเอง (ใน YAML) และเรียกว่า Stapel Collector ได้พัฒนาเป็นเครื่องมือที่ทรงพลังพอสมควรแล้ว คำอธิบายโดยละเอียดสมควรได้รับบทความแยกต่างหาก และรายละเอียดพื้นฐานสามารถพบได้ใน เอกสาร.

ความตระหนักรู้ถึงปัญหา

แต่เราตระหนักและไม่ใช่ในทันทีว่าเราทำผิดพลาดครั้งหนึ่ง: เราไม่ได้เพิ่มความสามารถเข้าไป สร้างภาพผ่าน Dockerfile มาตรฐาน และรวมเข้ากับโครงสร้างพื้นฐานการจัดการแอปพลิเคชันแบบ end-to-end เดียวกัน (เช่น รวบรวมอิมเมจ ปรับใช้ และล้างข้อมูล) เป็นไปได้อย่างไรที่จะสร้างเครื่องมือสำหรับการปรับใช้ใน Kubernetes และไม่ใช้การสนับสนุน Dockerfile เช่น วิธีมาตรฐานในการอธิบายภาพสำหรับโปรเจ็กต์ส่วนใหญ่ใช่ไหม..

แทนที่จะตอบคำถามนี้ เราเสนอวิธีแก้ปัญหา จะเป็นอย่างไรถ้าคุณมี Dockerfile อยู่แล้ว (หรือชุดของ Dockerfiles) และต้องการใช้ wef?

NB: ว่าแต่ ทำไมคุณถึงอยากใช้ werf ล่ะ? คุณสมบัติหลักมีดังต่อไปนี้:

  • วงจรการจัดการแอปพลิเคชันเต็มรูปแบบ รวมถึงการทำความสะอาดรูปภาพ
  • ความสามารถในการจัดการการประกอบภาพหลายภาพพร้อมกันจากการกำหนดค่าเดียว
  • ปรับปรุงกระบวนการปรับใช้สำหรับแผนภูมิที่เข้ากันได้กับ Helm

สามารถดูรายการทั้งหมดเพิ่มเติมได้ที่ หน้าโครงการ.

ดังนั้น หากก่อนหน้านี้เราเสนอให้เขียน Dockerfile ใหม่ในการกำหนดค่าของเรา ตอนนี้เราจะพูดว่า: “ให้ werf สร้าง Dockerfiles ของคุณ!”

วิธีการใช้งาน?

การใช้งานฟีเจอร์นี้โดยสมบูรณ์ปรากฏในรุ่น เวิร์ฟ v1.0.3-beta.1. หลักการทั่วไปนั้นง่าย: ผู้ใช้ระบุเส้นทางไปยัง Dockerfile ที่มีอยู่ในการกำหนดค่า werf จากนั้นรันคำสั่ง werf build... เท่านี้ก็เรียบร้อย - werf จะประกอบภาพ ลองดูตัวอย่างที่เป็นนามธรรม

มาประกาศกันต่อไปครับ Dockerfile ในรูทโปรเจ็กต์:

FROM ubuntu:18.04
RUN echo Building ...

และเราจะประกาศ werf.yamlซึ่งใช้สิ่งนี้ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ทั้งหมด! ซ้าย วิ่ง werf build:

ตอนนี้คุณสามารถสร้างอิมเมจ Docker ใน werf โดยใช้ Dockerfile ปกติ

นอกจากนี้ คุณสามารถประกาศสิ่งต่อไปนี้ได้ werf.yaml เพื่อสร้างภาพหลายภาพจาก Dockerfiles ที่แตกต่างกันในคราวเดียว:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

สุดท้ายนี้ ยังรองรับการส่งพารามิเตอร์บิลด์เพิ่มเติมด้วย เช่น --build-arg и --add-host - ผ่านการกำหนดค่า WRF คำอธิบายที่สมบูรณ์ของการกำหนดค่าอิมเมจ Dockerfile มีอยู่ที่ หน้าเอกสาร.

มันทำงานอย่างไร

ในระหว่างกระบวนการสร้าง แคชมาตรฐานของเลเยอร์ในเครื่องในฟังก์ชัน Docker อย่างไรก็ตาม สิ่งที่สำคัญก็คือเวิร์ฟนั้นด้วย รวมการกำหนดค่า Dockerfile เข้ากับโครงสร้างพื้นฐาน. สิ่งนี้หมายความว่า?

  1. แต่ละภาพที่สร้างจาก Dockerfile ประกอบด้วยหนึ่งขั้นตอนที่เรียกว่า dockerfile (คุณสามารถอ่านเพิ่มเติมเกี่ยวกับขั้นตอนที่อยู่ใน wef ได้ ที่นี่).
  2. สำหรับเวที dockerfile werf คำนวณลายเซ็นที่ขึ้นอยู่กับเนื้อหาของการกำหนดค่า Dockerfile เมื่อการกำหนดค่า Dockerfile เปลี่ยนแปลง ลายเซ็นของสเตจจะเปลี่ยนไป dockerfile และเวิร์ฟจะเริ่มสร้างสเตจนี้ใหม่ด้วยการกำหนดค่า Dockerfile ใหม่ หากลายเซ็นไม่เปลี่ยนแปลง werf จะนำรูปภาพจากแคช (รายละเอียดเพิ่มเติมเกี่ยวกับการใช้ลายเซ็นใน WRF ได้อธิบายไว้ใน รายงานนี้).
  3. ต่อไปสามารถเผยแพร่ภาพที่รวบรวมได้โดยใช้คำสั่ง werf publish (หรือ werf build-and-publish) และใช้เพื่อปรับใช้กับ Kubernetes อิมเมจที่เผยแพร่ไปยัง Docker Registry จะถูกล้างโดยใช้เครื่องมือล้างข้อมูล Werf มาตรฐาน เช่น รูปภาพเก่า (เก่ากว่า N วัน) รูปภาพที่เกี่ยวข้องกับสาขา Git ที่ไม่มีอยู่จริง และนโยบายอื่นๆ จะถูกล้างโดยอัตโนมัติ

รายละเอียดเพิ่มเติมเกี่ยวกับประเด็นต่างๆ ที่อธิบายไว้ที่นี่มีอยู่ในเอกสารประกอบ:

หมายเหตุและข้อควรระวัง

1. ADD ไม่รองรับ URL ภายนอก

ขณะนี้ยังไม่รองรับการใช้ URL ภายนอกในคำสั่ง ADD. Werf จะไม่เริ่มต้นการสร้างใหม่เมื่อทรัพยากรที่ URL ที่ระบุมีการเปลี่ยนแปลง เราวางแผนที่จะเพิ่มคุณสมบัตินี้เร็ว ๆ นี้

2. คุณไม่สามารถเพิ่ม .git ให้กับรูปภาพได้

โดยทั่วไปแล้ว การเพิ่มไดเร็กทอรี .git ในภาพ - การปฏิบัติที่ไม่ดีและนี่คือเหตุผล:

  1. ถ้า .git ค้างอยู่ในภาพสุดท้ายซึ่งผิดหลักการ แอพ 12 ปัจจัย: เนื่องจากอิมเมจสุดท้ายจะต้องเชื่อมโยงกับการคอมมิตเดียว จึงไม่สามารถทำได้ git checkout กระทำโดยพลการ
  2. .git เพิ่มขนาดของรูปภาพ (พื้นที่เก็บข้อมูลอาจมีขนาดใหญ่เนื่องจากไฟล์ขนาดใหญ่ถูกเพิ่มเข้าไปแล้วลบออก) ขนาดของแผนผังการทำงานที่เกี่ยวข้องกับการคอมมิตเฉพาะจะไม่ขึ้นอยู่กับประวัติการดำเนินการใน Git ในกรณีนี้จะมีการเพิ่มเติมและการลบออกในภายหลัง .git จากภาพสุดท้ายจะไม่ทำงาน: รูปภาพจะยังคงได้รับเลเยอร์พิเศษ - นี่คือวิธีการทำงานของ Docker
  3. นักเทียบท่าสามารถเริ่มต้นการสร้างใหม่ที่ไม่จำเป็นได้ แม้ว่าจะมีการสร้างการคอมมิตเดียวกัน แต่จากแผนผังการทำงานที่แตกต่างกัน ตัวอย่างเช่น GitLab จะสร้างไดเร็กทอรีโคลนแยกต่างหากใน /home/gitlab-runner/builds/HASH/[0-N]/yourproject เมื่อเปิดใช้งานการประกอบแบบขนาน การประกอบซ้ำเพิ่มเติมจะเกิดจากการที่ไดเร็กทอรี .git จะแตกต่างกันในเวอร์ชันโคลนที่แตกต่างกันของพื้นที่เก็บข้อมูลเดียวกัน แม้ว่าจะมีการสร้างการคอมมิตเดียวกันก็ตาม

จุดสุดท้ายยังมีผลที่ตามมาเมื่อใช้ wef Werf ต้องการให้แคชที่สร้างขึ้นปรากฏเมื่อรันคำสั่งบางคำสั่ง (เช่น werf deploy). เมื่อคำสั่งเหล่านี้ทำงาน werf จะคำนวณลายเซ็นขั้นตอนสำหรับรูปภาพที่ระบุ werf.yamlและจะต้องอยู่ในแคชแอสเซมบลี - มิฉะนั้นคำสั่งจะไม่สามารถทำงานต่อไปได้ หากลายเซ็นบนเวทีขึ้นอยู่กับเนื้อหา .gitจากนั้นเราจะได้รับแคชที่ไม่เสถียรต่อการเปลี่ยนแปลงในไฟล์ที่ไม่เกี่ยวข้อง และ Werf จะไม่สามารถให้อภัยการกำกับดูแลดังกล่าวได้ (สำหรับรายละเอียดเพิ่มเติม โปรดดู เอกสาร).

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

ทั้งหมด

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

อย่างไรก็ตาม ในกระบวนการเขียนตัวสร้างของเราเอง เรามองข้ามการสนับสนุน Dockerfiles ที่มีอยู่ไป ข้อบกพร่องนี้ได้รับการแก้ไขแล้ว และในอนาคตเราวางแผนที่จะพัฒนาการสนับสนุน Dockerfile พร้อมกับ Stapel builder แบบกำหนดเองของเราสำหรับการประกอบแบบกระจายและสำหรับการประกอบโดยใช้ Kubernetes (เช่น การประกอบบนรันเนอร์ภายใน Kubernetes เช่นเดียวกับที่ทำใน kaniko)

ดังนั้น หากคุณมี Dockerfiles อยู่สองสามไฟล์อยู่รอบๆ... ความพยายาม เวร!

ป.ล. รายการเอกสารในหัวข้อ

อ่านเพิ่มเติมในบล็อกของเรา: “werf - เครื่องมือของเราสำหรับ CI / CD ใน Kubernetes (รายงานภาพรวมและวิดีโอ)'

ที่มา: will.com

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