spryker demoshop
1.0.0
docker-composeต้องใช้: Docker และ Docker-compose เวอร์ชันล่าสุดที่เสถียร (พร้อมการสนับสนุน Docker-compose.yml 3.4) บนระบบ Linux หรือ MacOS ของคุณ
เนื่องจากสแต็กนี้ค่อนข้างซับซ้อนรวมถึง ES ที่หายไปอย่างเต็มที่จึงต้องใช้หน่วยความจำอย่างน้อย 4GB หากคุณใช้ Docker บน Windows/MacOS โปรดปรับการตั้งค่าให้เหมาะสม
หากเป็นไปตามความจำเป็นการทำงานร้านค้านั้นค่อนข้างง่าย เพียงป้อนขั้นตอนเหล่านี้:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
สิ่งนี้จะดึงอิมเมจนักเทียบท่าสร้างเครือข่ายสร้างคอนเทนเนอร์ทั้งหมดผูกติดตั้งรหัสท้องถิ่นของคุณลงในคอนเทนเนอร์เพื่อให้คุณสามารถใช้งาน Edit จากภายนอกเชื่อมต่อคอนเทนเนอร์เข้าหากันและในที่สุดก็เปิดเผยบริการสาธารณะ เช่นเดียวกับ Yves, Zed, Jenkins-Master, PostgreSQL และ Elasticsearch
โปรดอดทนในขณะที่สแต็ก Spryker กำลังถูกสร้างขึ้นเนื่องจากรูทีนการเริ่มต้นใช้เวลาค่อนข้างนานสำหรับข้อมูลทั้งหมดที่จะนำเข้าสู่ฐานข้อมูลจากนั้นส่งออกไปยัง Redis และ Elasticsearch ปัจจุบันใช้เวลาประมาณ 10 นาที
หลังจากการเริ่มต้นเสร็จสิ้นคุณจะสามารถชี้เบราว์เซอร์ไปยัง URL ต่อไปนี้:
นี่เป็นเวอร์ชันที่เกี่ยวข้องกับการดำเนินการอ้างอิงอย่างเป็นทางการของ Spryker Demoshop พร้อมที่จะหมดกล่องโดยดึงการพึ่งพาที่ต้องการทั้งหมดโดยอัตโนมัติและสร้างสแต็กประกอบด้วย postgreSQL, Redis, Elasticsearch และ Jenkins ในระหว่างการรันไทม์แต่ละบริการจะเริ่มต้น
คุณสามารถใช้ที่เก็บนี้ได้ทั้งเป็นการสาธิตสำหรับร้านค้ากระบวนทัศน์ตามระบบปฏิบัติการของ Spryker Commerce หรือเป็นจุดเริ่มต้นสำหรับการพัฒนาการนำไปปฏิบัติของคุณเองเริ่มต้นด้วยส้อมของ Demoshop
ขั้นตอนการสร้างและเริ่มต้นพร้อมกับเครื่องมือเพิ่มเติมนั้นสืบทอดมาจากภาพ Claranet/PHP ที่นั่นคุณจะพบแนวคิดการออกแบบทางเทคนิคที่อยู่เบื้องหลังการเชื่อมต่อนี้และคำตอบสำหรับคะแนนเพิ่มเติมเช่น:
docker/ ไฟล์ประโยชน์ของการบรรจุ:
มีบริการหลายอย่างที่ได้รับการเปิดเผยโดยสแต็กนักเทียบท่า ในการเรียกใช้สแต็คแบบขนานและป้องกันการชนพอร์ตเราจำเป็นต้องจัดตำแหน่งการจัดสรรพอร์ต
ดังนั้นรูปแบบต่อไปนี้ได้ถูกนำไปใช้: หมายเลขพอร์ตถูกเข้ารหัสเช่นนี้: ECCDD
ดังนั้น Yves de สามารถเข้าถึงได้ผ่าน http: // localhost: 20100/และ yves เราผ่าน http: // localhost: 20102
ข้อสังเกต: ความแตกต่างระหว่างร้านค้า/โดเมนโดยพอร์ตนั้นใช้ได้เฉพาะกับสภาพแวดล้อมการพัฒนาท้องถิ่นเท่านั้น สแต็กเกรดการผลิตจริงที่จัดทำโดย Claranet กำลังทำสิ่งที่แตกต่างนี้ตามชื่อโดเมนจริง
หลักฐานหลักคือ - และอันนี้มีความสำคัญต่อความเข้าใจของคุณเกี่ยวกับสแต็กนี้ - เพื่อสร้างภาพรวมหนึ่งภาพในสภาพแวดล้อมการพัฒนาและการผลิต สิ่งนี้มีผลต่อการใช้งานของ APPLICATION_ENV ซึ่งได้รับการประเมินโดยแอพ Spryker เอง
ตัวแปรนี้มีผลกระทบต่อไปนี้:
ตำแหน่งของไฟล์การกำหนดค่าท้องถิ่นและทรัพยากรภายนอกไม่มีสิ่งใดที่ต้องพิจารณาเป็นพิเศษในสภาพแวดล้อมที่มีการบรรจุเนื่องจากสแต็กทั้งหมดนั้นแยกได้อย่างไรก็ตาม ดังนั้นโปรดตรวจสอบให้แน่ใจว่าไม่มีคำสั่งการกำหนดค่าภายใต้ ./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 ตัวแปรนี้จะถูกตั้งค่าโดยอัตโนมัติ
แนวคิดเบื้องหลังสคริปต์ wrapper ที่ให้ผ่าน ./docker/run run เป็นความแตกต่างพื้นฐานระหว่างสภาพแวดล้อม devel และ prod ความแตกต่างที่สำคัญระหว่างสภาพแวดล้อมเหล่านั้นในแง่ของ docker-compose คือการจ้างงานของการติดตั้ง BIND ในโหมด Devel ซึ่งช่วยให้นักพัฒนาสามารถแก้ไขฐานรหัสจากภายนอกในขณะที่ใช้รหัสในพื้นหลังภายในคอนเทนเนอร์
เนื่องจากการตั้งค่านี้มุ่งมั่นที่จะลดความพยายามด้วยตนเองเราจึงเตรียมสคริปต์เชลล์ซึ่งทำให้ตรรกะที่จำเป็นและสนับสนุนคุณด้วยทางลัดสำหรับงานที่พบบ่อยที่สุดเช่นการสร้างภาพหรือสร้างหรือฉีกขาดการตั้งค่าคอนเทนเนอร์ ตรวจสอบ ./docker/run help
สภาพแวดล้อม prod มีไว้สำหรับการทดสอบผลการทำงานของคุณในสภาพแวดล้อมที่อยู่ใกล้กับ Prod ซึ่งหมายความว่าจะไม่มีข้อมูลที่ใช้ร่วมกันระหว่างที่เก็บในพื้นที่ของคุณและคอนเทนเนอร์จะถูกสร้างขึ้น นอกจากนี้แอปพลิเคชันจะทำงานด้วย APPLICTION_ENV=production ซึ่งปิดใช้งานส่วนขยายเฉพาะการพัฒนา
เนื่องจากในสภาพแวดล้อมที่มีสภาพแวดล้อมการบริการภายนอกสามารถเข้าถึงได้ตามที่อยู่ต่างกันขึ้นอยู่กับสภาพแวดล้อมที่รหัสกำลังทำงานอยู่คอนเทนเนอร์/รูปภาพจะต้องกำหนดค่าจากภายนอกผ่านตัวแปรสภาพแวดล้อม แอพ Spryker จำเป็นต้องบริโภค ดังนั้นภาพนี้จึงคาดหวังว่าตัวแปรสภาพแวดล้อมที่เฉพาะเจาะจงจะถูกฉีดเป็น Docker Env Vars และที่ได้รับการพิจารณาผ่าน config_local.php ที่เตรียมไว้
เราใช้ประโยชน์จากกลไกดั้งเดิมของ Spryker ของลำดับชั้นไฟล์การกำหนดค่าซึ่งกำหนดลำดับความสำคัญและรูปแบบของการพิจารณาไฟล์การกำหนดค่า ภาพนี้มีไฟล์การกำหนดค่าโลคัลไซต์ของตัวเองซึ่งสามารถพบได้ในที่เก็บนี้ภายใต้ docker/config_local.php และสามารถพบได้ในภาพ Docker ที่ได้ภายใต้ config/Shared/config_local.php เนื่องจากไฟล์นี้เป็นไฟล์ที่แทนที่ไฟล์อื่นทั้งหมด
คำสั่งการกำหนดค่าเป็นสิ่งต่อไปนี้ (overides สุดท้าย prio):
config_default.php - การกำหนดค่าพื้นฐานconfig_default-development.php - การกำหนดค่าที่เกี่ยวข้องกับโหมดการพัฒนา (ดู APPLICATION_ENV )config_local.php - การกำหนดค่าโลคัลไซต์; ในกรณีนี้การกำหนดค่าสำหรับสภาพแวดล้อมแบบคอนเทนเนอร์คำสั่งซื้อนี้ช่วยให้คุณสามารถใช้ไฟล์กำหนดค่าของคุณได้อย่างสมบูรณ์โดยไม่ขึ้นกับสภาพแวดล้อมที่มีประสิทธิภาพร้านค้าจะทำงานคุณสามารถควบคุมพฤติกรรมที่แตกต่างระหว่างสภาพแวดล้อมได้ เราเพิ่งแทนที่การตั้งค่าท้องถิ่นของไซต์ซึ่งความคิดนี้มีต้นกำเนิดมาจาก
ปัจจุบันสภาพแวดล้อมทั้งสอง devel และ prod โดยใช้ปริมาณที่ไม่มีชื่อซึ่งเกิดจากการสันนิษฐานของสภาพแวดล้อมชั่วคราว ซึ่งหมายความว่าสแต็กทั้งหมดได้รับการสร้างขึ้นเพื่อจุดประสงค์เดียวในการตรวจสอบรหัสฐานรหัสของคุณ มันไม่ได้หมายถึงการตั้งค่าเกรดการผลิตบางอย่างซึ่งข้อมูลจำเป็นต้องคงอยู่กับการพักผ่อนหย่อนใจของคอนเทนเนอร์ !!!
เวิร์กโฟลว์ที่สันนิษฐานสามารถอธิบายได้ว่า:
docker-compose(1) ถูกห่อผ่าน shell script ./docker/run สคริปต์นี้ให้ทางลัดสำหรับงานทั่วไปส่วนใหญ่ในขณะที่ให้ความสนใจกับที่เก็บในท้องถิ่นและการกำหนดค่า:
เพียงเพื่อสร้างการใช้อิมเมจนักเทียบท่า: ./docker/run build
สิ่งนี้ใช้กับสภาพแวดล้อมทั้งสองเนื่องจากทั้งคู่ขึ้นอยู่กับภาพเดียวกัน มันจะสร้างภาพสปอร์เคอร์-เดโมโกปหลักรวมถึงรสชาติของเจนกินส์-สลาวด์พิเศษจากภาพ Spryker-Demoshop
ที่จริงแล้วมีการสร้างภาพ 2 ภาพหนึ่งภาพสำหรับภาพร้านค้าจริงซึ่งใช้สำหรับ Nginx และภาชนะบรรจุ PHP ทั้งใน Yves และชั้น Zed และอีกอันหนึ่งสำหรับภาชนะทาสเจนกินส์ หลังขยายภาพร้านค้าโดยส่วนประกอบของเจนกินส์ที่ต้องการทั้งหมดเพื่อสร้างทาส/คนงานเจนกินส์ เหตุผลในการทำสิ่งนี้ในด้านบนของภาพร้านค้าจริงคืองานแบ็กเอนด์ทั้งหมดที่วิ่งผ่านเจนกินส์ต้องใช้ฐานรหัสสปอร์เกอร์เต็ม
เวลาในการสร้างบนเวิร์กสเตชันปกติพร้อม SSD ในปัจจุบันใช้เวลา Aprpoximely 10 นาทีสำหรับภาพทั้งสอง
หากคุณต้องการเริ่มงานของคุณเองตาม demoshop คุณอาจพบว่าสภาพแวดล้อมการพัฒนาในท้องถิ่นน่าสนใจ การตั้งค่านี้ช่วยให้คุณสามารถติดตั้งรหัสฐานในเครื่องของคุณลงในคอนเทนเนอร์ที่กำลังทำงานอยู่และดูการเปลี่ยนแปลงฐานรหัสจะมีผลทันที
เพียงแค่เรียกใช้ ./docker/run devel up และไปที่นั่น
./docker/run devel down -v สแต็ค Dele
เส้นทางต่อไปนี้จะถูกผูกไว้ในคอนเทนเนอร์:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
ในกรณีที่คุณต้องการสร้างภาพร้านค้าใหม่และต้องการสร้าง YVES และ/หรือ ZED คอนเทนเนอร์ใหม่ในขณะที่เก็บข้อมูลทั้งหมด (REDIS, ES, PSQL) ทำงาน: ./docker/run devel rebuild
หากคุณเพียงต้องการสร้างตู้คอนเทนเนอร์เหล่านั้นใหม่โดยไม่ต้องสร้างใหม่อีกครั้ง: ./docker/run devel recreate
ในขณะที่การดีบักมันอาจจะมีประโยชน์แทนที่จะปล่อยให้ /entrypoint.sh เริ่มต้นคอนเทนเนอร์เพื่อข้ามขั้นตอนนี้และตรวจสอบด้วยตัวคุณเอง คุณสามารถทำได้โดยการเปลี่ยน command: run-zed ของคอนเทนเนอร์ที่เกี่ยวข้องกับ command: sleep 1w ใน docker-compose-devel.yml และสร้างคอนเทนเนอร์ ./docker/run devel recreate zed
docker-compose เนื่องจากทั้งหมดนี้ขึ้นอยู่กับ docker-compose(1) คุณอาจต้องเรียกมันด้วยตัวเองเช่นเพื่อป้อนคอนเทนเนอร์ผ่านเชลล์: ./docker/run devel compose exec yves bash
หากผลลัพธ์ของบิลด์ไม่ได้บอกและคุณต้องการเซสชันการดีบักที่ลึกกว่าให้พิจารณาขั้นตอนต่อไปนี้เพื่อคืนชีพคอนเทนเนอร์บิลด์ระดับกลางที่ตายแล้ว:
./docker/run build
# assumed that the last created container is the failed intermediate build container
docker commit $(docker ps -lq) debug
docker run --rm --it debug /bin/sh
และที่นี่คุณไปตรวจสอบสาเหตุของความล้มเหลวในการสร้าง
เราแนะนำการใช้งานของตัวติดตั้ง Spryker ก่อนรุ่นนี้เราได้แสดงกระบวนการสร้างการติดตั้งและการจัดเตรียมทั้งหมดในสคริปต์เชลล์ที่อาศัยอยู่ในฐานและภาพ Spryker สิ่งนี้ได้รับการลดลงในความโปรดปรานของตัวติดตั้ง Spryker ใหม่ซึ่งแสดงถึงอะไรมากไปกว่าสัญญาระหว่างแอปพลิเคชันและโครงสร้างพื้นฐาน สัญญานี้อย่างชัดเจน hilights การกระทำที่จำเป็นทั้งหมดที่จะดำเนินการเพื่อสร้างร้านค้า เราได้จัดทำสัญญาการติดตั้งผ่าน config/installer/claranet.yml
เราลดการสนับสนุนอัลไพน์ในความโปรดปรานของ Debian Stretch! หากคุณต้องการอัลไพน์โปรดใช้รุ่นก่อน 2.28.0 แต่เราไม่สนับสนุนอัลไพน์เพิ่มเติม
หมายเหตุ: ภาพแม่เปลี่ยนจาก claranet/spryker-base เป็น claranet/php ซึ่งทำลายโครงสร้างของระบบ docker/ Filesystem ก่อนหน้า! เราได้เลือกเส้นทางนี้เนื่องจากภาพพื้นฐานในอดีตอาจเป็นเรื่องทั่วไปที่จะจับคู่ไม่เพียง แต่ข้อกำหนดของ Spryker เท่านั้น แต่ยังเป็นข้อกำหนดแอปพลิเคชันที่ใช้ PHP ใด ๆ
หากคุณพบข้อผิดพลาดที่ไม่ได้ระบุไว้ที่นี่โปรดรายงาน!
เราจะไม่จัดส่ง demoshop จนกว่า https://bugs.php.net/bug.php?id=76029 ได้รับการแก้ไขและเราสามารถเปิดใช้งาน opcache Opcache เป็นสิ่งจำเป็นในสภาพแวดล้อม Prod และไม่สมเหตุสมผลที่จะใช้ 7.2 ใน dev และ 7.1 ในการผลิต ...
เนื่องจาก Spryker Demoshop 2.32 ดูเหมือนว่ามีข้อผิดพลาดซึ่งทำให้ opcache โยนข้อยกเว้น ดังนั้นเราจึงถูกบังคับให้ปิดการใช้งาน opcache
