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

จากเอกสารนักเทียบท่าอย่างเป็นทางการ:

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

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

ฉันอาจจะสาย แต่นี่คือ 10 เซ็นต์ของฉัน (คำตอบของ Ashishjain):

โดยทั่วไปชั้นหรือชั้นภาพคือการเปลี่ยนแปลงที่ภาพหรือภาพกลาง คำสั่งที่คุณระบุทุกคน ( FROM, RUN, COPYฯลฯ ) ใน Dockerfile ของท่านทำให้ภาพก่อนหน้านี้มีการเปลี่ยนแปลงดังนั้นการสร้างเลเยอร์ใหม่ คุณสามารถคิดว่ามันเป็นการแสดงละครการเปลี่ยนแปลงเมื่อคุณใช้คอมไพล์: คุณเพิ่มการเปลี่ยนแปลงของไฟล์จากนั้นอีกคนหนึ่งแล้วอีกคนหนึ่ง ...

พิจารณา Dockerfile ต่อไปนี้:

FROM rails:onbuild
ENV RAILS_ENV production
ENTRYPOINT ["bundle", "exec", "puma"]

ครั้งแรกที่เราเลือกภาพเริ่มต้น: rails:onbuildซึ่งจะมีหลายชั้น เราเพิ่มเลเยอร์อื่นที่ด้านบนของภาพเริ่มต้นของเราตั้งค่าตัวแปรสภาพแวดล้อมRAILS_ENVด้วยENVคำสั่ง จากนั้นเราบอกให้นักเทียบท่าทำงานbundle exec puma(ซึ่งบู๊ตเซิร์ฟเวอร์ rails) นั่นคืออีกชั้นหนึ่ง

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

คุณสามารถอ่านเพิ่มเติมได้ที่นี่

ภาพภาชนะนักเทียบท่าจะถูกสร้างขึ้นโดยใช้dockerfile ทุกบรรทัดในdockerfileจะสร้างเลเยอร์ ลองพิจารณาตัวอย่างตัวอย่างต่อไปนี้:

FROM ubuntu             #This has its own number of layers say "X"
MAINTAINER FOO          #This is one layer 
RUN mkdir /tmp/foo      #This is one layer 
RUN apt-get install vim #This is one layer 

สิ่งนี้จะสร้างภาพสุดท้ายที่จำนวนเลเยอร์ทั้งหมดจะเป็นX + 3

พวกเขามีเหตุผลมากที่สุดสำหรับฉันด้วยตัวอย่าง ...

ตรวจสอบเลเยอร์ของบิลด์ของคุณเองด้วย docker diff

ให้นำตัวอย่าง Dockerfile ที่วางแผนมา:

FROM busybox

RUN mkdir /data
# imagine this is downloading source code
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one 
RUN chmod -R 0777 /data
# imagine this is compiling the app
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two 
RUN chmod -R 0777 /data
# and now this cleans up that downloaded source code
RUN rm /data/one 

CMD ls -alh /data

แต่ละddคำสั่งเหล่านั้นส่งออกไฟล์ 1M ไปยังดิสก์ ให้สร้างรูปภาพด้วยการตั้งค่าสถานะพิเศษเพื่อบันทึกคอนเทนเนอร์ชั่วคราว:

docker image build --rm=false .

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

...
Step 2/7 : RUN mkdir /data
 ---> Running in 04c5fa1360b0
 ---> 9b4368667b8c
Step 3/7 : RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one
 ---> Running in f1b72db3bfaa
1024+0 records in
1024+0 records out
1048576 bytes (1.0MB) copied, 0.006002 seconds, 166.6MB/s
 ---> ea2506fc6e11

หากคุณรัน a docker diffบนแต่ละ ID คอนเทนเนอร์คุณจะเห็นไฟล์ที่สร้างในคอนเทนเนอร์เหล่านั้น:

$ docker diff 04c5fa1360b0  # mkdir /data
A /data
$ docker diff f1b72db3bfaa  # dd if=/dev/zero bs=1024 count=1024 of=/data/one
C /data
A /data/one
$ docker diff 81c607555a7d  # chmod -R 0777 /data
C /data
C /data/one
$ docker diff 1bd249e1a47b  # dd if=/dev/zero bs=1024 count=1024 of=/data/two
C /data
A /data/two
$ docker diff 038bd2bc5aea  # chmod -R 0777 /data
C /data/one
C /data/two
$ docker diff 504c6e9b6637  # rm /data/one
C /data
D /data/one

แต่ละบรรทัดนำหน้าด้วยการAเพิ่มไฟล์การCบ่งชี้การเปลี่ยนแปลงไปยังไฟล์ที่มีอยู่และDบ่งชี้การลบ

นี่คือส่วน TL; DR

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

ตรวจสอบภาพที่มีอยู่

คุณสามารถดูคำสั่งที่จะสร้างเลเยอร์ของภาพที่มีอยู่ด้วยdocker historyคำสั่ง คุณยังสามารถเรียกใช้docker image inspectบนรูปภาพและดูรายการของเลเยอร์ภายใต้ส่วน RootFS

นี่คือประวัติของภาพด้านบน:

IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
a81cfb93008c        4 seconds ago       /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "ls -…   0B
f36265598aef        5 seconds ago       /bin/sh -c rm /data/one                         0B
c79aff033b1c        7 seconds ago       /bin/sh -c chmod -R 0777 /data                  2.1MB
b821dfe9ea38        10 seconds ago      /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
a5602b8e8c69        13 seconds ago      /bin/sh -c chmod -R 0777 /data                  1.05MB
08ec3c707b11        15 seconds ago      /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
ed27832cb6c7        18 seconds ago      /bin/sh -c mkdir /data                          0B
22c2dd5ee85d        2 weeks ago         /bin/sh -c #(nop)  CMD ["sh"]                   0B
<missing>           2 weeks ago         /bin/sh -c #(nop) ADD file:2a4c44bdcb743a52f…   1.16MB

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

ทำไมต้องเลเยอร์

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

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

ลดชั้นป่อง

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

FROM busybox

RUN mkdir /data \
 && dd if=/dev/zero bs=1024 count=1024 of=/data/one \
 && chmod -R 0777 /data \
 && dd if=/dev/zero bs=1024 count=1024 of=/data/two \
 && chmod -R 0777 /data \
 && rm /data/one

CMD ls -alh /data

และถ้าคุณเปรียบเทียบภาพผลลัพธ์:

• busybox: ~ 1MB
• ภาพแรก: ~ 6MB
• ภาพที่สอง: ~ 2MB

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

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

ตัวอย่างเช่นในภาพที่สร้างขึ้นในประเทศจากภาพฐานสมมติว่าubuntu:14.04ในdocker historyคำสั่งผลตอบแทนถัวเฉลี่ยโซ่ภาพ แต่บางส่วนของรหัสภาพจะแสดงเป็น 'หายไป' เพราะสร้างประวัติศาสตร์ไม่ได้โหลด และเลเยอร์ที่สร้างภาพเหล่านี้สามารถพบได้ผ่าน

docker inspect <image_id> | jq -r '.[].RootFS'

เนื้อหาชั้นถูกเก็บไว้ที่ถ้าเลือกควบคุมที่เก็บข้อมูลคือ/var/lib/docker/aufs/diff aufsแต่เลเยอร์ถูกตั้งชื่อด้วยรหัสแคชที่สร้างแบบสุ่มดูเหมือนว่าการเชื่อมโยงระหว่างเลเยอร์และรหัสแคชนั้นเป็นที่ทราบกันดีว่า Docker Engine นั้นมีเหตุผลด้านความปลอดภัยเท่านั้น ฉันยังคงมองหาวิธีที่จะหา

1. ความสัมพันธ์ที่สอดคล้องกันระหว่างรูปภาพและเลเยอร์การเขียน
2. ตำแหน่งและขนาดที่แท้จริงของเลเยอร์บนดิสก์

บล็อกนี้ให้ข้อมูลเชิงลึกมาก

ข้อมูลจำเพาะภาพของ Docker ผ่านThe Moby Project :

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

โดยพื้นฐานแล้วเลเยอร์เป็นเพียงชุดของการเปลี่ยนแปลงที่เกิดขึ้นกับระบบไฟล์

ผมคิดว่าเอกสารอย่างเป็นทางการให้คำอธิบายรายละเอียดสวย: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/

_{(ที่มา: docker.com )}

ภาพประกอบด้วยหลายชั้นซึ่งมักจะเกิดจาก Dockerfile แต่ละบรรทัดใน Dockerfile จะสร้างเลเยอร์ใหม่และผลที่ได้คือภาพที่จะเขียนแทนด้วยรูปแบบเช่นrepo:tagubuntu:15.04

สำหรับข้อมูลเพิ่มเติมโปรดลองอ่านเอกสารอย่างเป็นทางการด้านบน

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

สำหรับข้อมูลเพิ่มเติมคุณสามารถดู "ประวัตินักเทียบท่า" ดังนี้:

ภาพนักเทียบท่า - ต้นไม้
คำเตือน: '--tree' เลิกใช้แล้วจะถูกลบในไม่ช้า ดูการใช้งาน
└─511136ea3c5aขนาดเสมือนจริง: 0 B แท็ก: scratch: latest
  Virtual59e359cb35ef ขนาดเสมือน: 85.18 MB
    └─e8d37d9e3476ขนาดเสมือน: 85.18 MB Tags: debian: wheezy
      └─c58b36b8f285ขนาดเสมือน: 85.18 MB
        Virtual90ea6e05b074 ขนาดเสมือน: 118.6 MB
          └─5dc74cffc471ขนาดเสมือน: 118.6 MB แท็ก: เป็นกลุ่ม: ล่าสุด

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

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

ให้ทั้งสอง Dockerfiles

FROM bash
RUN mkdir /data
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/three

และ

FROM bash
RUN mkdir /data
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/three
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one

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

$ docker history img_1
IMAGE               CREATED             CREATED BY                                      SIZE
30daa166a9c5        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
4467d16e79f5        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
c299561fd031        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
646feb178431        6 minutes ago       /bin/sh -c mkdir /data                          0B
78664daf24f4        2 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>           2 weeks ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B
<more missing...>

และ

$ docker history img_2
IMAGE               CREATED             CREATED BY                                      SIZE
f55c91305f8c        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
29b3b627c76f        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
18360be603aa        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
646feb178431        6 minutes ago       /bin/sh -c mkdir /data                          0B
78664daf24f4        2 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>           2 weeks ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B
<more missing...>

คุณสามารถดูได้ว่าถึงแม้ว่าการเปลี่ยนแปลงของระบบไฟล์จะเหมือนกันในทั้งสองกรณีลำดับนั้นมีความสำคัญ