หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

Docker Image Claranet/Spryker-base

หมายเหตุสำคัญ: โครงการนี้เลิกใช้แล้ว! โปรดใช้ claranet/spryker-demoshop เป็นข้อมูลอ้างอิง bootstrap หรือรูปภาพหลักของ claranet/php ของเราสำหรับการใช้ PHP ทั่วไปมากขึ้น! เราไม่รักษาโครงการนี้อีกต่อไป

  • อะไร
  • ทำไม
  • ออกแบบ
    • ภาพนักเทียบท่า
    • สร้างสภาพแวดล้อมเวลา
    • สภาพแวดล้อมรันไทม์
    • สร้างเลเยอร์
    • ที่เก็บส่วนตัว
    • การกำหนดค่า Spryker
    • ปริมาตรนักเทียบท่า
  • การประชุม
  • สร้างภาพที่กำหนดเองของคุณ
  • สร้างและเรียกใช้
  • การกำหนดค่า
    • ตัวแปรสภาพแวดล้อมรันไทม์ - การอ้างอิง
    • สร้างตัวแปรเวลา - การอ้างอิง
    • ฉีดการกำหนดค่าที่กำหนดเอง
      • ปริมาณภายนอก
      • ภาพเขียนทับ
  • การปรับแต่ง
    • build.conf
    • สร้างขั้นตอน
    • การเริ่มต้น
      • ระดับคอนเทนเนอร์
      • การตั้งค่ากว้าง
    • การปรับใช้
    • ขั้นตอนการสร้างที่กำหนดเอง
      • การตัดไม้
      • การติดตั้งแพ็คเกจเพิ่มเติม
  • ไม่ได้บันทึกไว้ที่นี่?
  • คำถามที่พบบ่อย
    • จะหาบันทึกได้ที่ไหน?
    • คุณใช้ภาพฐานใด
    • ทำไมไม่ใช้อัลไพน์อีกต่อไป?
    • จะเพิ่มความเร็วในการสร้างภาพเพิ่มเติมได้อย่างไร?
  • ปัญหา

อะไร

ภาพนี้มีวัตถุประสงค์เพื่อจัดหาโครงสร้างพื้นฐานพื้นฐานสำหรับ Yves และ Zed โครงสร้างพื้นฐานในแง่ของสคริปต์ Build/Init และเครื่องมือเพิ่มเติมรอบ ๆ ร้านค้า ภาพนี้ไม่ได้ให้ร้านค้าพร้อมใช้งาน! ในการใช้คุณสมบัติที่นำมาใช้ที่นี่เขียน Dockerfile ของคุณเอง - ซึ่งใช้ภาพพื้นฐานนี้เพื่อสืบทอดจาก - ตามการใช้งานจริงของร้านค้า Spryker

โครงการนี้ยังอยู่ในช่วงเบต้าและจะได้รับการเปลี่ยนแปลงที่อาจเกิดขึ้นได้!

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

หากคุณต้องการเห็นภาพนี้ดำเนินการและจะใช้วิธีการตรวจสอบ demoshop spryker containerized demoshop นี้ทำหน้าที่เป็นการนำไปใช้งานอ้างอิงสำหรับภาพพื้นฐาน เช่นเดียวกับที่ Spryker กำลังดำเนินการรวมกลุ่มของพวกเขาและทำให้ demoshop สะท้อนการเปลี่ยนแปลงเหล่านั้นที่เราใช้ demoshop ในลักษณะเดียวกัน

ลักษณะหลักคือ:

  • จัดเตรียมสภาพแวดล้อม PHP Runtime กับโมดูล PHP ที่พบบ่อยที่สุด
  • ใช้คุณสมบัติทริกเกอร์ ONBUILD Dockers เพื่อเชื่อมต่อและควบคุมกระบวนการสร้างภาพเด็ก
  • ให้การกำหนดค่า FPM/NGINX เริ่มต้นที่สมเหตุสมผล
  • เปิดสำหรับการปรับแต่งโดยการจัดทำขั้นตอนการสร้างเริ่มต้นและการกำหนดค่าที่เชื่อมต่อได้
  • คาดว่าโครงสร้างพื้นฐานเช่น spryker-demoshop
  • ไม่มีข้อ จำกัด เพิ่มเติมคุณมีอิสระที่จะออกแบบซื้อสินค้าในแบบที่คุณต้องการ

ทำไม

ประโยชน์ของการบรรจุ:

  • ความสม่ำเสมอ
  • การทำซ้ำได้
  • ความพอประมาณ
  • แบบฟอร์มการปรับใช้ที่ราบรื่น

ออกแบบ

ภาพนักเทียบท่า

สถานที่แรกคือเราตัดสินใจที่จะให้บริการ Yves และ Zed Container จากภาพเดียว ผลประโยชน์คือการอัพเกรดฐานรหัสที่ใช้ร่วมกันอย่างสม่ำเสมอตลอดทั้งคลัสเตอร์ การแลกเปลี่ยนเป็นภาพที่ใหญ่กว่าเล็กน้อยเนื่องจากจำเป็นต้องรวมความต้องการของทั้งสองส่วนประกอบ

สร้างสภาพแวดล้อมเวลา

หลักฐานอีกประการหนึ่งคือ - และอันนี้มีความสำคัญต่อความเข้าใจของคุณเกี่ยวกับสแต็กนี้ - เพื่อสร้างภาพรวมหนึ่งภาพในสภาพแวดล้อมการพัฒนาและการผลิต สิ่งนี้มีผลต่อการใช้งานของ APPLICATION_ENV ซึ่งได้รับการประเมินโดยแอพ Spryker เอง

ตัวแปรนี้มีผลกระทบต่อไปนี้:

  1. ในช่วงเวลาสร้าง:
    1. แพ็คเกจใดที่จะติดตั้งผ่านความละเอียดการพึ่งพา (Composer, NPM)
    2. โหมดที่แตกต่างกันในการสร้างสินทรัพย์
  2. ในช่วงเวลาทำงาน:
    1. แอปพลิเคชันกำลังจะค้นหาไฟล์การกำหนดค่า (Propel Config) ที่ไหน
    2. แหล่งข้อมูลภายนอกอยู่ที่ไหน
    3. แอพจะเปิดใช้งานการดีบัก symfony/devel หรือไม่?

ตำแหน่งของไฟล์การกำหนดค่าท้องถิ่นและทรัพยากรภายนอกไม่มีสิ่งใดที่ต้องพิจารณาเป็นพิเศษในสภาพแวดล้อมที่มีการบรรจุเนื่องจากสแต็กทั้งหมดนั้นแยกได้อย่างไรก็ตาม ดังนั้นโปรดตรวจสอบให้แน่ใจว่าไม่มีคำสั่งการกำหนดค่าภายใต้ ./config/Shared/ shared/ จะใช้ APPLICATION_ENV สำหรับการระบุเส้นทางของพวกเขา !!!

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

ซึ่งหมายความว่าแม้แต่คอนเทนเนอร์การผลิตก็ยังมีการพึ่งพาอาศัยกัน เหตุผลหลักสำหรับเรื่องนี้คือข้อกำหนดสำหรับ dev/test/prod parity เพื่อให้แน่ใจว่าคอนเทนเนอร์ทำงานเหมือนกันในทุกขั้นตอนและในทุกสภาพแวดล้อม การแลกเปลี่ยนสำหรับสถานที่นี้เป็นภาพที่มีประสิทธิภาพมากขึ้นอีกครั้ง ในระหว่างการรันไทม์พฤติกรรมของแอปพลิเคชัน Spryker สามารถควบคุมได้โดยการตั้ง APPLICATION_ENV ซึ่งยอมรับ development หรือ production หากคุณใช้สคริปต์ ./docker/run run ตัวแปรนี้จะถูกตั้งค่าโดยอัตโนมัติ

สภาพแวดล้อมรันไทม์

แนวคิดที่อยู่เบื้องหลังสคริปต์ที่มีให้ในโฟลเดอร์ ./shop/docker docker นี้ติดตามความแตกต่างพื้นฐานระหว่างสภาพแวดล้อม devel และ prod ความแตกต่างที่สำคัญระหว่างสภาพแวดล้อมเหล่านั้นในแง่ของ docker-compose คือการจ้างงานของการติดตั้ง BIND ในโหมด Devel ซึ่งช่วยให้นักพัฒนาสามารถแก้ไขฐานรหัสจากภายนอกในขณะที่ใช้รหัสในพื้นหลังภายในคอนเทนเนอร์

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

สภาพแวดล้อม prod มีไว้สำหรับการทดสอบผลการทำงานของคุณในสภาพแวดล้อมที่อยู่ใกล้กับ Prod ซึ่งหมายความว่าจะไม่มีข้อมูลที่ใช้ร่วมกันระหว่างที่เก็บในพื้นที่ของคุณและคอนเทนเนอร์จะถูกสร้างขึ้น นอกจากนี้แอปพลิเคชันจะทำงานด้วย APPLICTION_ENV=production ซึ่งปิดใช้งานส่วนขยายเฉพาะการพัฒนา

สร้างเลเยอร์

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

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

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

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

ความรับผิดชอบของเลเยอร์เหล่านั้นคืออะไรและพวกเขาจะอยู่ที่ไหนและพวกเขาจะถูกสร้างขึ้นเมื่อใด

  • claranet/spryker-base (ภาพนี้):
    • ชั้นฐาน - ติดตั้งโครงสร้างพื้นฐานฐานระดับ OS ทั้งหมด PHP และโมดูลที่พบมากที่สุด
  • claranet/spryker-demoshop (ภาพร้านค้าดาวน์สตรีมเช่น demoshop):
    • เลเยอร์ฐาน - ติดตั้งโมดูล PHP เพิ่มเติมและ/หรือแทนที่ชั้นฐานจากอิมเมจ spryker-base (โปรดทราบตัวแปรสร้าง $REBUILD_BASE_LAYER )
    • เลเยอร์การพึ่งพา - แก้ไขการพึ่งพา PHP/โหนดเฉพาะของร้านค้าทั้งหมด
    • Code Layer - สร้างรหัสเฉพาะของร้านค้าเช่น ORM, Tranfer Objects

ที่เก็บส่วนตัว

ในกรณีที่ต้องดึง PHP หรือโหนดของคุณจากที่เก็บข้อมูลส่วนตัวคุณเพียงแค่ต้องให้ ~/.netrc ไฟล์นี้จะถูกตรวจพบโดยอัตโนมัติและชั่วคราวเป็น Docker Build Arg ที่ฉีดเข้าไปในคอนเทนเนอร์บิลด์ชั่วคราวซึ่งใช้โดย Git สำหรับการโคลนที่เก็บที่เหมาะสมและหลังจากนั้นเช็ดชั้น resuilting ทันทีก่อนที่เลเยอร์จะถูกปิด

รูปแบบสำหรับ $HOME/.netrc มีดังนี้: 

 machine git.company.local
login my_user_name
password my_private_token

เพื่อให้มีผลต่อการพึ่งพาทั้งหมดที่กำหนดจะต้องได้รับเป็น URL HTTP หรือพวกเขาได้รับการแปลงผ่าน git config --global "url.https://".insteadof "git://git@ ซึ่งจัดทำขึ้นแล้วโดยภาพพื้นฐาน

หากคุณต้องการเพิ่มกฎเฉพาะเพิ่มเติมให้สร้างสคริปต์บิลด์ในเลเยอร์การพึ่งพาซึ่งได้รับการดำเนินการก่อนกระบวนการแก้ไขการพึ่งพา: 

 vi docker/build.d/deps/300_private_repo_override.sh
#!/bin/sh
sectionText "Diverting git transport from SSH to HTTPS: https://git.company.local"
git config --global "url.https://git.company.local/".insteadof "[email protected]:"
git config --global "url.https://git.company.local".insteadof "ssh://[email protected]"

เนื่องจาก GIT URL สามารถให้ในการผสมผสานโดยพลการนี่เป็นในบางสถานการณ์ที่จำเป็น

ทั้งหมดนี้มีความจำเป็นเนื่องจาก Docker ปฏิเสธที่จะใช้ปริมาณการสร้างเวลาซึ่งจะทำให้กระบวนการนี้ง่ายขึ้น แต่พวกเขามีเหตุผลที่โดดเด่นอย่างแท้จริงเนื่องจากคุณลักษณะดังกล่าวจะเสี่ยงต่อการทำซ้ำเพราะ Dockerfile ไม่ใช่แหล่งกำเนิดของการสร้าง แต่เพียงผู้เดียว IS - เช่นเดียวกับในการโต้แย้งทางเทคโนโลยี - ไม่มีความจริงสัมบูรณ์มีเพียงการแลกเปลี่ยนเท่านั้น

การกำหนดค่า Spryker

เนื่องจากในสภาพแวดล้อมที่มีสภาพแวดล้อมการบริการภายนอกสามารถเข้าถึงได้ตามที่อยู่ที่แตกต่างกันขึ้นอยู่กับสภาพแวดล้อมที่รหัสกำลังทำงานอยู่ในเราจำเป็นต้องมีการกำหนดค่าบางอย่างที่จะปรับ ดังนั้นเราจึงใช้กลไกเนทีฟของ Spryker ของความสำคัญของไฟล์การกำหนดค่าเพื่อที่จะฉีดการกำหนดค่าของเราผ่านทางไซต์การกำหนดค่าไฟล์ local config/Shared/config_local.php เนื่องจากไฟล์นี้เป็นไฟล์ที่แทนที่ไฟล์อื่นทั้งหมด

ลำดับการกำหนดค่ามีดังต่อไปนี้:

  • config_default.php - การกำหนดค่าพื้นฐาน
  • config_default-development.php - การกำหนดค่าที่เกี่ยวข้องกับโหมดการพัฒนา (ดู APPLICATION_ENV )
  • config_local.php - การกำหนดค่าโลคัลไซต์; ในกรณีนี้การกำหนดค่าสำหรับสภาพแวดล้อมแบบคอนเทนเนอร์

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

สำหรับสิ่งนี้เราจำเป็นต้องลบ config/Shared/config_local.php ออกจากรายการ. .gitignore

ปริมาตรนักเทียบท่า

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

เวิร์กโฟลว์ที่สันนิษฐานสามารถอธิบายได้ว่า:

  1. สร้างสภาพแวดล้อม
  2. เริ่มต้นด้วยข้อมูลจำลอง
  3. Evolve Code Base
  4. iterate: rebuild -> run -> init -> Evolve
  5. ทำลายสภาพแวดล้อม

การประชุม

เพื่อที่จะนำฟังก์ชั่นการใช้งานมาใช้ใหม่ที่นี่ด้านต่อไปนี้จะต้องสอดคล้องกับภาพพื้นฐาน:

  • ติดตามลำดับชั้นของไดเรกทอรีอ้างอิง Spryker
    • ./src/Pyz - การใช้งานร้านค้าของคุณ
    • ./config - การกำหนดค่า
    • ./public/{Yves,Zed} - จุดเข้ากับแอปพลิเคชันของคุณ (รูทเอกสาร)
  • การพึ่งพาอาศัยกัน
    • PHP: composer.json และ composer.lock
    • โหนด: packages.json , packages.lock และ yarn.lock
  • ทำให้การกำหนดค่า spryker พิจารณา env vars เช็คเอาต์ shop_skel/config/chared/config_local.php ซึ่งเป็นตัวอย่างของความหมายในจุดนี้
  • ควบคุมการพึ่งพาที่คุณต้องการติดตั้ง (ส่วนขยาย php, deps โหนด, ฯลฯ pp.) ผ่าน ./docker/build.conf
  • ควบคุมกระบวนการสร้างภาพโดยวางสคริปต์บิลด์ที่กำหนดเองของคุณไว้ใต้ ./docker/build.d/
  • ควบคุมกระบวนการเริ่มต้นของการตั้งค่าโดยวางสคริปต์ของคุณภายใต้ ./docker/init.d/

ตรวจสอบ demoshop ที่เราเตรียมไว้สำหรับการใช้ภาพนี้ที่นี่ สิ่งนี้ควรตอบคำถามทั้งหมดที่คุณอาจมี

สร้างภาพที่กำหนดเองของคุณ

เนื่องจากการใช้งานอ้างอิงเป็น demoshop ที่เราดูแลรักษาอยู่นี่เป็นผู้เริ่มต้นที่ดีทีเดียว ไม่ว่าจะโดยเพียงแค่ฟอร์ก repo นี้หรือเริ่มจากศูนย์

หากคุณต้องการเริ่มต้นจากศูนย์สิ่งประดิษฐ์ที่น่าสนใจเพียงอย่างเดียวที่คุณต้องการจาก demoshop คือ:

  • ./docker/*
  • ./Dockerfile
  • ./.dockerignore
  • ./config/Shared/config_local.php

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

โปรดทราบ Dockerfile ที่ดูสะอาดเหมือนนี้: 

 FROM claranet/spryker-base:latest

มีกลิ่นเหมือนการใช้ซ้ำ -

สร้างและเรียกใช้

Skeleton ร้านค้าและ demoshop รวมถึงเชลล์สคริปต์ภายใต้ ./docker/run ซึ่งให้ทางลัดแก่คุณในงานที่พบบ่อยที่สุด ชำระเงิน readme.md ที่นั่นเพื่อดูรายละเอียดเพิ่มเติม 

 # Build the image
./docker/run build

# Run the demoshop in development mode
./docker/run devel up

# Stop all the containers of the demoshop including their artifacts
./docker/run devel down -v

การกำหนดค่า

ตัวแปรสภาพแวดล้อมรันไทม์ - การอ้างอิง

ตัวแปรเหล่านั้นจะมีให้ในระหว่างการสร้างคอนเทนเนอร์เป็นตัวแปรสภาพแวดล้อม

ตัวแปรส่วนใหญ่ได้รับการใช้งานโดยไฟล์ config/Shared/config_local.php :

  • APPLICATION_ENV="production"
  • SPRYKER_SHOP_CC="DE"
  • ZED_HOST="zed"
  • YVES_HOST="yves"
  • ES_HOST="elasticsearch"
  • ES_PROTOCOL="http"
  • ES_PORT="9200"
  • REDIS_STORAGE_PROTOCOL="tcp"
  • REDIS_STORAGE_HOST="redis"
  • REDIS_STORAGE_PORT="6379"
  • REDIS_STORAGE_PASSWORD=""
  • REDIS_SESSION_PROTOCOL="tcp"
  • REDIS_SESSION_HOST="redis"
  • REDIS_SESSION_PORT="6379"
  • REDIS_SESSION_PASSWORD=""
  • ZED_DB_USERNAME="postgres"
  • ZED_DB_PASSWORD=""
  • ZED_DB_DATABASE="spryker"
  • ZED_DB_HOST="database"
  • ZED_DB_PORT="5432"
  • JENKINS_URL="http://jenkins:8080/"
  • RABBITMQ_HOST="rabbitmq"
  • RABBITMQ_PORT="5672"
  • RABBITMQ_USER="spryker"
  • RABBITMQ_PASSWORD=""
  • YVES_SSL_ENABLED="false"
  • YVES_COMPLETE_SSL_ENABLED="false"
  • ZED_SSL_ENABLED="false"
  • ZED_API_SSL_ENABLED="false"

บริโภคโดยการเริ่มต้นตะขอ:

  • ZED_ADMIN_PASSWORD - หากตั้งรหัสผ่านเริ่มต้นของผู้ใช้ [email protected] จะถูกรีเซ็ต
  • ENABLE_XDEBUG - โมดูล php xdebug จะเปิดใช้งานและกำหนดค่า
  • ENABLE_OPCACHE - โมดูล php opcache จะเปิดใช้งานและกำหนดค่า

สร้างตัวแปรเวลา - การอ้างอิง

ตัวแปรเหล่านั้นจะต้องจัดทำผ่านโครงการเฉพาะของคุณ ./docker/build.conf

  • PROJECT (บังคับ)-ควบคุมคำนำหน้าชื่อของบริการที่สร้างขึ้น docker-compose
  • IMAGE (บังคับ) - ชื่อของ Docker Image คือชื่ออะไร?
  • VERSION (บังคับ) - เรากำลังทำงานอิมเมจเวอร์ชันใด
  • BUILD_DEPENDENCIES - แพ็คเกจการแจกจ่าย (Debian) ที่จะติดตั้งในช่วงเวลาสร้าง
  • BASE_DEPENDENCIES - แพ็คเกจการแจกจ่าย (Debian) ที่จะติดตั้งเพิ่มเติม
  • PHP_EXTENSIONS - รายการ Space Seperated ของส่วนขยาย PHP ที่จะติดตั้ง
  • NPM_DEPENDENCIES - แพ็คเกจการแจกจ่ายซึ่งจะถูกรวมเข้าด้วยกันก่อนการจัดการ NPM ในชั้น deps
  • KEEP_DEVEL_TOOLS (ค่าเริ่มต้น: เท็จ) - จะติดตั้งเครื่องมือพัฒนาและเก็บไว้นอกเหนือจากการสร้างหรือไม่?
  • SKIP_CLEANUP (ค่าเริ่มต้น: เท็จ) - ข้ามขั้นตอนการล้างข้อมูลในแต่ละชั้นสร้างเลเยอร์ สิ่งนี้ช่วยในการแก้ไขปัญหา โปรดทราบว่าการข้ามสิ่งนี้เช็ดข้อมูลรับรองเช่นกัน! ดังนั้นไม่เคยปล่อยภาพเช่นนี้ลงไปในป่า !!!
  • CRONJOB_HANDLER - กำหนดตำแหน่งที่ควรลงทะเบียน Cronjobs ปัจจุบันรองรับเจนกินส์และครอนด์
  • REBUILD_BASE_LAYER - หากได้รับ build var นี้เลเยอร์ฐานจะถูกสร้างใหม่ในระหว่างการสร้างภาพร้านค้าดาวน์สตรีม

ฉีดการกำหนดค่าที่กำหนดเอง

ในการควบคุมพฤติกรรมของ Nginx, PHP-FPM หรือ PHP คุณสามารถฉีดการกำหนดค่าจากด้านนอกของคอนเทนเนอร์เป็น BIND Mounts หรือผ่าน Dockerfile ของภาพร้านค้าเด็ก

ปริมาณภายนอก

การกำหนดค่าบริการพร้อมที่จะรวมไฟล์หลายไฟล์ซึ่งประกอบด้วยการกำหนดค่าที่มีประสิทธิภาพ

การกำหนดค่าทั้งหมดได้รับการเตรียมล่วงหน้าให้คาดหวังภายใต้ไดเรกทอรีเฉพาะที่ไฟล์ที่เกี่ยวข้องทั้งหมดจะ

สถานที่ที่คาดหวังคือ:

  • nginx
    • /etc/nginx/spryker/yves.conf.d/*.conf
    • /etc/nginx/spryker/zed.conf.d/*.conf
  • PHP FPM
    • /etc/php/fpm/yves.conf.d/*.conf
    • /etc/php/fpm/zed.conf.d/*.conf
  • php ini
    • /etc/php/ini/*.ini

การกำหนดค่าเริ่มต้นจะพบได้ภายใต้: 

 /etc/php/fpm/zed.conf.d/100_base.conf
/etc/php/fpm/zed.conf.d/200_pm.conf
/etc/php/fpm/zed.conf.d/300_php.conf
/etc/php/fpm/yves.conf.d/100_base.conf
/etc/php/fpm/yves.conf.d/200_pm.conf
/etc/php/fpm/yves.conf.d/300_php.conf
/etc/php/ini/xdebug.ini
/etc/php/ini/opcache.ini
/etc/nginx/spryker/zed.conf.d/500-default.conf
/etc/nginx/spryker/yves.conf.d/500_default.conf

ในสภาพแวดล้อมที่คุณสามารถติดตั้งไดเรกทอรีที่สมบูรณ์ลงในคอนเทนเนอร์เท่านั้นเราได้เตรียมกลไกที่คาดว่าจะมีลำดับชั้นของไดเรกทอรีภายใต้ /mnt/configs และในการสร้างคอนเทนเนอร์มัน symlinks ไฟล์ทั้งหมดภายใต้ตำแหน่งนี้ไปยังตำแหน่งที่สอดคล้องกันภายใต้ /etc/ 

 # For example: 
/mnt/configs/nginx/zed.conf.d/600-custom-headers.conf      -->  /etc/nginx/zed.conf.d/600-custom-headers.conf
/mnt/configs/php/fpm/yves.conf.d/500-raise-processes.conf  -->  /etc/php/fpm/yves.conf.d/500-raise-processes.conf

ภาพเขียนทับ

เนื่องจากลักษณะของระบบไฟล์เลเยอร์ภาพเด็กที่สืบทอดมาจากภาพพื้นฐานนี้สามารถเขียนทับการกำหนดค่าได้อย่างง่ายเพื่อให้ได้พฤติกรรมที่ต้องการของบริการเหล่านั้น

สิ่งเหล่านั้นสามารถปรับแต่งได้อย่างง่ายดายโดยการจัดหาไฟล์การกำหนดค่าด้วยตัวเองผ่าน Dockerfile : 

 FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf

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

การปรับแต่ง

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

build.conf

กระบวนการสร้างค่อนข้างมากตามชื่อแนะนำกระบวนการที่สร้างภาพที่ได้รับการแชร์โดยคอนเทนเนอร์ที่ได้รับทั้งหมดในระหว่างการรันไทม์ในภายหลัง

สคริปต์บิลด์บางตัวพิจารณาพารามิเตอร์ที่คุณสามารถตั้งค่าได้ใน ./docker/build.conf

ดูการอ้างอิงด้านบน ..

สร้างขั้นตอน

Hook Dir: ./docker/build.d/

หากคุณต้องการขยายขั้นตอนการสร้างที่สืบทอดมาจากภาพพื้นฐานหรือเพื่อปิดการใช้งานคุณจะต้องวางสคริปต์บิลด์ที่กำหนดเองของคุณภายใต้ . ./docker/build.d/ ที่นั่นคุณจะพบไดเรกทอรี 3 ตัวที่สะท้อนแต่ละขั้นตอน/เลเยอร์:

  • ./docker/build.d/base/ - การติดตั้งระดับระบบปฏิบัติการฐาน
  • ./docker/build.d/deps/ - จัดการกับการพึ่งพา PHP/โหนดเฉพาะร้านค้าเฉพาะร้านค้า
  • ./docker/build.d/shop/ - จัดการกับการสร้างรหัสของฐานรหัสร้านค้าจริง

สคริปต์ของแต่ละ subdir ได้รับการสั่งซื้อ lexically (actuall sourced)

ตัวอย่างเช่นหากคุณต้องการเปลี่ยนวิธีการสร้างแคชการนำทางโดยอิมเมจพื้นฐานคุณต้องจัดหาสคริปต์ในตำแหน่งเดียวกันกับที่จัดทำโดยอิมเมจพื้นฐานภายใต้ . ./docker/build.d/shop/650_build_navigation_cache.sh เนื่องจากภาพที่เกิดขึ้นรวมถึงคอนเทนเนอร์จะใช้ระบบไฟล์ยูเนี่ยนไฟล์ที่จัดทำโดยภาพร้านค้าจะมีความสำคัญเหนือกว่าภาพที่จัดทำโดยอิมเมจ BAS ด้วยกลไกนี้คุณสามารถปิดใช้งานฟังก์ชั่นได้ง่ายๆโดยการจัดหาสคริปต์ที่ไม่ได้ทำอะไรหรือคุณสามารถเปลี่ยนพฤติกรรมได้โดยการเพิ่มสคริปต์ซึ่งทำสิ่งที่แตกต่างหรือเพิ่มเติม

การเริ่มต้น

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

ภาพพื้นฐานให้ตะขอสำหรับทั้งสองการเริ่มต้นของแต่ละคอนเทนเนอร์และสำหรับการเริ่มต้นของการตั้งค่าทั้งหมด

ระดับคอนเทนเนอร์

Hook Dir: ./docker/entry.d/

อาร์กิวเมนต์ entrypoint Runtime ( run-yves , run-zed , run-yves-and-zed , run-cron ) การปกครองที่มีบทบาทที่คอนเทนเนอร์จริงนี้มีแหล่งที่มาทั้งหมดของไฟล์ที่แสดงในไดเรกทอรี hook นี้ ผ่านตัวแปรสคริปต์ตัดสินใจว่าจะเปิดใช้บริการใดและเริ่มต้นในระหว่างการรันไทม์

งานทั่วไปคือการเปิดใช้งาน xdebug ตามที่ร้องขอผ่าน Env Var ENABLE_XDEBUG ในการสร้างคอนเทนเนอร์

เนื่องจากธรรมชาติตะขอทั้งหมดจะถูกดำเนินการในแต่ละคอนเทนเนอร์เริ่มต้น

การตั้งค่ากว้าง

Hook Dir: ./docker/init.d/

โดยทั่วไปแต่ละอินสแตนซ์ของร้านค้าจะต้องดำเนินการขั้นตอนเริ่มต้นเพื่อเริ่มต้นร้านค้าดังกล่าว ในระหว่างการตั้งค่าการเริ่มต้นอย่างกว้างขวางนี้สคริปต์เชลล์ทั้งหมดภายใต้ hook dir ได้รับการดำเนินการ ตัวอย่างเช่นการเริ่มต้นฐานข้อมูลด้วยข้อมูลจำลองเช่น demoshop วางสคริปต์ภายใต้ ./docker/init.d/500_import_demo_data.sh

สิ่งนี้ไม่ได้ดำเนินการอย่างชัดเจนภาชนะแยกต่างหากจะต้องวางไข่ด้วย ententpoint arg init

การปรับใช้

Hook Dir: ./docker/deploy.d/

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

สิ่งนี้ไม่ได้ดำเนินการโดยนัยคอนเทนเนอร์แยกต้องวางไข่ด้วย deploy ententpoint arg

ขั้นตอนการสร้างที่กำหนดเอง

ดังที่ได้กล่าวไปแล้วคุณมีอิสระที่จะเพิ่มขั้นตอนการสร้างที่กำหนดเองและขั้นตอนเริ่มต้น สคริปต์ ./docker/common.inc.sh จะช่วยคุณในการทำงานที่มีประโยชน์ ตรวจสอบด้วยตัวเอง

การตัดไม้

ทำให้ขั้นตอนการสร้างของคุณบอกโดยใช้ฟังก์ชั่นเอาต์พุตที่เตรียมไว้:

  • errorText - เพิ่มข้อผิดพลาด
  • successText - ส่งคืนความสำเร็จ
  • sectionHead - พาดหัวพิมพ์สำหรับกลุ่มงาน
  • sectionText - พิมพ์ข้อมูลขั้นตอนการสร้างระดับกลาง

การติดตั้งแพ็คเกจเพิ่มเติม

เรามีฟังก์ชั่น install_packages สำหรับขั้นตอนการสร้างที่รวมอยู่ทั้งหมด โปรดตรวจสอบให้แน่ใจว่าคุณใช้มัน! มันมาพร้อมกับความเป็นไปได้ที่จะตั้งค่าสถานะแพ็คเกจเป็น "สร้าง" การพึ่งพา แพ็คเกจที่ถูกตั้งค่าสถานะเป็น Buildencies จะถูกลบออกหลังจากการสร้างเลเยอร์เสร็จสิ้น การตั้งค่าสถานะแพ็คเกจเป็น Build Dependencies เพิ่งตั้งค่า --build สร้างเป็นอาร์กิวเมนต์แรก: 

 # remove "gcc" at the end of our image build
install_packages --build gcc
 
# keep "top" in the resulting image
install_packages top

ไม่ได้บันทึกไว้ที่นี่?

เรายังอยู่ในช่วงเริ่มต้นของโครงการนี้ดังนั้นเอกสารอาจไม่สมบูรณ์ หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับคุณสมบัติที่เราให้ไว้โปรดดูที่ห้องสมุดเชลล์

คำถามที่พบบ่อย

จะหาบันทึกได้ที่ไหน?

ในอินสแตนซ์ YVES/ZED คุณสามารถค้นหา NGINX, PHP-FPM และบันทึกแอปพลิเคชันภายใน /data/logs/

คุณใช้ภาพฐานใด

เราขึ้นอยู่กับภาพ PHP อย่างเป็นทางการ: https://hub.docker.com/_/php/

ทำไมไม่ใช้อัลไพน์อีกต่อไป?

คำถามที่ดีมาก!

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

น่าเสียดายที่ปรากฎว่า Musl lib C แนะนำข้อ จำกัด ซึ่งทนไม่ได้ในบริบทของลูกค้า - ที่ความสามารถรอบตัวเป็นกุญแจสำคัญ ตั้งแต่ 0.9.6 เราได้เปลี่ยนเป็นภาพที่ใช้ Debian

จะเพิ่มความเร็วในการสร้างภาพเพิ่มเติมได้อย่างไร?

สองสิ่งที่นึกถึง:

  • ใช้พร็อกซีท้องถิ่นซึ่งแคชคำขอ HTTP
  • การใช้งานสร้าง Multistage Docker ที่เสนอ

จะมาเร็ว ๆ นี้ -

ปัญหา

โปรดดู /ปัญหา

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