🥇Docker Compose: จากการพัฒนาสู่การผลิต

การแปลการถอดเสียงพอดแคสต์ที่เตรียมไว้เพื่อรอการเริ่มต้นหลักสูตร "ผู้ดูแลระบบลินุกซ์"

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

ด้วยการถือกำเนิดของ นักเทียบท่าเขียน v3 ไฟล์ YAML เหล่านี้สามารถใช้ได้โดยตรงในสภาพแวดล้อมการใช้งานจริงเมื่อทำงานด้วย
กลุ่ม ฝูงนักเทียบท่า.

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

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

ความแตกต่างระหว่างไฟล์การพัฒนาและไฟล์ที่ใช้งานจริง

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

ในการใช้งานจริง คุณมีคลัสเตอร์ที่มีโหนดจำนวนมาก และวอลุ่มอยู่ในเครื่อง
สัมพันธ์กับโหนดที่คอนเทนเนอร์ (หรือบริการ) ของคุณทำงานอยู่ ดังนั้นคุณจึงไม่ทำเช่นนั้น
คุณสามารถเมานต์ซอร์สโค้ดได้โดยไม่ต้องดำเนินการที่ซับซ้อนซึ่งรวมถึง
การซิงโครไนซ์รหัส สัญญาณ ฯลฯ

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

แทนที่การกำหนดค่า

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

Docker compose รองรับการรวมไฟล์เขียนที่แตกต่างกันเข้าด้วยกัน
รับการกำหนดค่าขั้นสุดท้าย วิธีการทำงานสามารถดูได้จากตัวอย่าง:

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

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

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

ไวยากรณ์นี้ไม่สะดวกมากในระหว่างการพัฒนาเมื่อมีคำสั่ง
จะต้องทำหลายครั้ง

โชคดีที่นักเทียบท่าเขียนจะค้นหาไฟล์พิเศษที่เรียกว่าโดยอัตโนมัติ
นักเทียบท่า-compose.override.yml เพื่อแทนที่ค่า นักเทียบท่า-compose.yml. ถ้า
เปลี่ยนชื่อไฟล์ที่สอง คุณจะได้ผลลัพธ์เดียวกัน โดยใช้คำสั่งดั้งเดิมเท่านั้น:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

โอเค จำง่ายกว่า

การประมาณค่าของตัวแปร

รองรับไฟล์การกำหนดค่า การแก้ไข
ตัวแปร และค่าเริ่มต้น นั่นคือคุณสามารถทำสิ่งต่อไปนี้:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

และถ้าคุณทำ บิลด์นักเทียบท่าเขียน (หรือพุช) โดยไม่มีตัวแปรสภาพแวดล้อม
$MY_SERVICE_VERSIONจะใช้ค่านี้ ล่าสุดแต่ถ้าคุณตั้งค่า
ค่าของตัวแปรสภาพแวดล้อมก่อนการ build จะถูกใช้เมื่อสร้างหรือผลัก
ไปที่ทะเบียน private.registry.mine.

หลักการของฉัน

แนวทางที่ใช้ได้ผลสำหรับฉันอาจใช้ได้ผลสำหรับคุณเช่นกัน ฉันติดตามสิ่งเหล่านี้
กฎง่ายๆ:

สแต็กทั้งหมดของฉันสำหรับการผลิต การพัฒนา (หรือสภาพแวดล้อมอื่นๆ) ได้รับการกำหนดผ่าน
ไฟล์นักเทียบท่าเขียน
ไฟล์การกำหนดค่าที่จำเป็นเพื่อให้ครอบคลุมสภาพแวดล้อมทั้งหมดของฉันให้มากที่สุด
หลีกเลี่ยงการทำซ้ำ
ฉันต้องการคำสั่งง่ายๆ หนึ่งคำสั่งเพื่อทำงานในแต่ละสภาพแวดล้อม
การกำหนดค่าหลักถูกกำหนดไว้ในไฟล์ นักเทียบท่า-compose.yml.
ตัวแปรสภาพแวดล้อมใช้เพื่อกำหนดแท็กรูปภาพหรืออื่นๆ
ตัวแปรที่อาจแตกต่างกันไปตามสภาพแวดล้อม (การจัดเตรียม การบูรณาการ
การผลิต).
ค่าของตัวแปรการผลิตจะถูกใช้เป็นค่าสำหรับ
โดยค่าเริ่มต้น สิ่งนี้จะช่วยลดความเสี่ยงหากสแต็กถูกเปิดใช้งานในการใช้งานจริงโดยไม่มี
ตั้งค่าตัวแปรสภาพแวดล้อม
หากต้องการเริ่มบริการในสภาพแวดล้อมการใช้งานจริง ให้ใช้คำสั่ง การปรับใช้ docker stack - เขียนไฟล์ docker-compose.yml -with-registry-auth my-stack-name.
สภาพแวดล้อมการทำงานเริ่มต้นโดยใช้คำสั่ง docker-compose ขึ้น -d.

ลองดูตัวอย่างง่ายๆ

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

ฉันสามารถใช้ นักเทียบท่าเขียน (นักเทียบท่าเขียน)เพื่อรันสแต็กเข้าไป
โหมดการพัฒนาพร้อมซอร์สโค้ดที่ติดตั้งอยู่ /โครงการ/src.

ฉันสามารถใช้ไฟล์เดียวกันนี้ในการผลิตได้! และฉันก็ใช้ได้แน่นอน
ไฟล์เดียวกัน นักเทียบท่า-compose.yml สำหรับการแสดงละคร เพื่อขยายเรื่องนี้ไปสู่
การผลิต ฉันแค่ต้องสร้างและส่งภาพด้วยแท็กที่กำหนดไว้ล่วงหน้า
ในระยะ CI:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

ในการผลิต สามารถรันได้โดยใช้คำสั่งต่อไปนี้:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

และถ้าคุณต้องการทำแบบเดียวกันบนเวที คุณก็แค่ต้องกำหนด
ตัวแปรสภาพแวดล้อมที่จำเป็นสำหรับการทำงานในสภาพแวดล้อมการแสดงละคร:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

ด้วยเหตุนี้ เราจึงใช้ไฟล์ docker-compose สองไฟล์ที่แตกต่างกัน ซึ่งไม่มี
การกำหนดค่าที่ซ้ำกันสามารถใช้ได้กับทุกสภาพแวดล้อมที่คุณมี!

เรียนรู้เพิ่มเติมเกี่ยวกับหลักสูตร "ผู้ดูแลระบบลินุกซ์"

ที่มา: will.com

Docker Compose: จากการพัฒนาสู่การผลิต

ความแตกต่างระหว่างไฟล์การพัฒนาและไฟล์ที่ใช้งานจริง

แทนที่การกำหนดค่า

การประมาณค่าของตัวแปร

หลักการของฉัน

เพิ่มความคิดเห็น ยกเลิกการตอบ