spryker demoshop
1.0.0
docker-composeMembutuhkan: Versi terbaru dan stabil dari Docker dan Docker-Compose (dengan dukungan Docker-compose.yml 3.4) pada sistem Linux atau MacOS Anda.
Karena tumpukan ini cukup kompleks termasuk ES yang sepenuhnya melayang, itu membutuhkan setidaknya 4GB memori. Jika Anda menjalankan Docker di Windows/MacOS, harap sesuaikan pengaturan yang sesuai.
Jika syarat terpenuhi, menjalankan toko cukup mudah. Cukup masukkan langkah -langkah ini:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Ini menarik gambar Docker, membuat jaringan, membuat semua wadah, mengikat memasang kode lokal Anda ke dalam wadah untuk memungkinkan Anda untuk hidup-di luar dari luar, menghubungkan wadah satu sama lain dan akhirnya memaparkan layanan publik. Seperti Yves, Zed, Jenkins-Master, PostgreSQL dan Elasticsearch.
Harap bersabar saat tumpukan Spryker sedang dibuat, karena rutinitas inisialisasi membutuhkan waktu cukup untuk semua data yang diimpor ke dalam database dan kemudian diekspor ke Redis dan Elasticsearch. Saat ini ini memakan waktu sekitar 10 menit.
Setelah inisialisasi selesai, Anda dapat mengarahkan browser Anda ke URL berikut:
Ini adalah versi berlabuh dari implementasi referensi resmi dari Spryker Demoshop. Siap berjalan di luar kotak dengan secara otomatis menarik semua dependensi yang diperlukan dan membuat tumpukan yang terdiri dari PostgreSQL, Redis, Elasticsearch dan Jenkins. Selama runtime, masing -masing layanan diinisialisasi.
Anda dapat menggunakan repositori ini baik sebagai demonstrasi untuk toko paradigmatik berdasarkan Spryker Commerce OS atau sebagai titik awal untuk pengembangan implementasi Anda sendiri yang dimulai dengan garpu demoshop.
Prosedur Build and Start bersama dengan perkakas lebih lanjut diwarisi dari gambar clariet/php. Di sana Anda akan menemukan ide desain teknis di balik dockerisasi ini dan jawaban untuk poin lebih lanjut seperti:
docker/ FilesystemManfaat Kontainerisasi:
Beberapa layanan sedang diekspos oleh tumpukan komposisi Docker. Untuk menjalankan tumpukan secara paralel dan mencegah tabrakan pelabuhan, kita perlu menyelaraskan alokasi pelabuhan.
Oleh karena itu skema berikut telah diimplementasikan: Nomor port dikodekan seperti ini: ECCDD
Jadi Yves de dapat dijangkau melalui http: // localhost: 20100/dan yves kami melalui http: // localhost: 20102
PEMBERITAHUAN: Diferensiasi antara toko/domain berdasarkan port hanya berlaku untuk lingkungan Devel lokal. Tumpukan tingkat produksi aktual yang disediakan oleh Clariset melakukan perbedaan ini berdasarkan nama domain yang sebenarnya.
Premis pusat adalah - dan yang ini sangat penting untuk pemahaman Anda tentang tumpukan ini - untuk membangun satu gambar terpadu di seluruh lingkungan pengembangan dan produksi. Ini mempengaruhi penggunaan APPLICATION_ENV yang dievaluasi oleh aplikasi Spryker itu sendiri.
Variabel ini memiliki dampak berikut:
Lokasi file konfigurasi lokal dan sumber daya eksternal tidak ada yang perlu dipertimbangkan ekstra dalam lingkungan yang dikemas, karena semua tumpukan itu terisolasi. Jadi harap pastikan bahwa tidak ada pernyataan konfigurasi di bawah ./config/Shared/ akan menggunakan APPLICATION_ENV untuk mengidentifikasi jalur mereka !!!
Kami menganggap hanya poin 1.1 yang layak menjadi perbedaan. Dan karena ini dapat dicapai dengan menyuntikkan VAR yang tepat ke dalam wadah yang efektif, kami tidak membedakan antara lingkungan sambil membangun gambar. Karena poin 1.1 biasanya membutuhkan lebih banyak dependensi untuk diselesaikan, kami selalu membangun gambar dengan APPLICATION_ENV yang diatur ke development . Tetapi dalam mode mana aplikasi sebenarnya akan dijalankan adalah independen dari itu.
Ini berarti bahwa bahkan wadah produksi akan memiliki ketergantungan pengembangan. Alasan utama untuk ini adalah persyaratan untuk paritas dev/test/prod untuk memastikan wadah berperilaku persis sama di semua tahap dan di semua lingkungan. Tradeoff untuk premis ini lagi adalah gambar efektif yang lebih besar.
Selama runtime perilaku aplikasi Spryker dapat dikontrol dengan mengatur APPLICATION_ENV yang menerima development atau production . Jika Anda menggunakan skrip ./docker/run variabel ini akan diatur secara otomatis.
Gagasan di balik skrip pembungkus yang disediakan melalui ./docker/run adalah perbedaan dasar antara lingkungan devel dan prod . Perbedaan utama antara lingkungan tersebut dalam hal docker-compose adalah pekerjaan Bind Mounts dalam mode Devel, yang memungkinkan pengembang untuk mengedit basis kode dari luar sambil menjalankan kode di latar belakang di dalam wadah.
Karena pengaturan ini berusaha untuk mengurangi upaya manual, kami menyiapkan skrip shell yang membuat logika yang diperlukan dan mendukung Anda dengan jalan pintas untuk tugas -tugas paling umum seperti membangun gambar atau membuat atau menghancurkan pengaturan wadah. Lihat ./docker/run help
Lingkungan prod dimaksudkan untuk menguji hasil pekerjaan Anda di lingkungan yang hampir ke produk, yang berarti bahwa tidak ada data bersama antara repositori lokal Anda dan wadah akan ditetapkan. Selanjutnya aplikasi akan dijalankan dengan APPLICTION_ENV=production yang menonaktifkan ekstensi spesifik pengembangan.
Karena dalam lingkungan yang berlapis pelihara, layanan eksternal dapat dicapai pada alamat yang berbeda tergantung pada lingkungan kode berjalan, wadah/gambar perlu dikonfigurasi dari luar melalui variabel lingkungan. Ini perlu dikonsumsi oleh aplikasi Spryker. Oleh karena itu gambar ini mengharapkan variabel lingkungan spesifik yang disuntikkan sebagai Docker Env Vars dan yang sedang disusun melalui config_local.php yang disiapkan.
Kami memanfaatkan mekanisme asli Spryker dari hierarki file konfigurasi yang mendefinisikan urutan, prioritas dan skema untuk dianggap sebagai file konfigurasi. Gambar ini menyediakan file konfigurasi lokal situsnya sendiri yang dapat ditemukan di repositori ini di bawah docker/config_local.php dan yang dapat ditemukan di gambar Docker yang dihasilkan di bawah config/Shared/config_local.php . Karena file ini adalah yang mengesampingkan yang lainnya.
Urutan konfigurasi adalah sebagai yang berikut (terakhir diveide prio):
config_default.php - konfigurasi dasarconfig_default-development.php - konfigurasi yang relevan untuk mode pengembangan (lihat APPLICATION_ENV )config_local.php - Konfigurasi Lokal Situs; Dalam hal ini konfigurasi untuk lingkungan yang dimasukkan.Pesanan ini memungkinkan Anda untuk menggunakan file konfigurasi Anda sepenuhnya secara independen dari lingkungan yang efektif yang akan dijalankan oleh toko. Anda bahkan dapat mengontrol perilaku yang berbeda antar lingkungan. Kami hanya mengesampingkan pengaturan lokal SO SITE, yang berasal dari ide ini.
Saat ini kedua lingkungan devel dan prod menggunakan volume yang tidak disebutkan namanya yang disebabkan oleh asumsi lingkungan sementara. Ini berarti, seluruh tumpukan dibuat untuk tujuan satu -satunya untuk memeriksa basis kode Anda karena itu. Ini tidak ada keadaan yang tidak dimaksudkan sebagai beberapa pengaturan nilai produksi, di mana data perlu bertahan selama rekreasi kontainer !!!
Alur kerja yang diasumsikan dapat digambarkan sebagai:
docker-compose(1) telah dibungkus melalui skrip shell ./docker/run . Script ini menyediakan jalan pintas untuk sebagian besar tugas umum sambil memperhatikan repositori lokal dan konfigurasinya:
Hanya untuk membangun gambar docker: ./docker/run build
Ini berlaku untuk kedua lingkungan karena keduanya didasarkan pada gambar yang sama. Ini akan membangun gambar spryker-demoshop utama serta rasa jenkins-slave khusus dari gambar spryker-demoshop.
Sebenarnya 2 gambar sedang dibangun, satu untuk gambar toko yang sebenarnya yang sedang digunakan untuk nginx dan wadah PHP di kedua Yves dan lapisan zed, dan satu untuk wadah budak Jenkins. Yang terakhir hanya memperluas gambar toko dengan semua komponen Jenkins yang diperlukan untuk membuat budak/pekerja Jenkins. Alasan untuk melakukan ini di atas citra toko yang sebenarnya adalah bahwa semua pekerjaan backend dijalankan melalui Jenkins membutuhkan basis kode spryker penuh.
Waktu pembangunan pada workstation reguler dengan SSD yang dibangun saat ini membutuhkan waktu sekitar 10 menit untuk kedua gambar.
Jika Anda ingin memulai pekerjaan Anda sendiri berdasarkan demoshop, Anda mungkin menganggap lingkungan pengembangan lokal menarik. Pengaturan ini memungkinkan Anda untuk memasang basis kode lokal Anda ke dalam wadah yang berjalan dan melihat perubahan pada basis kode berlaku segera.
Jalankan saja ./docker/run devel up dan di sana Anda pergi.
Hancurkan tumpukan Devel termasuk semua volume yang tidak disebutkan namanya: ./docker/run devel down -v
Jalur berikut diikat dipasang ke dalam wadah:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
Jika Anda perlu membangun kembali citra toko dan hanya ingin menciptakan kembali Yves dan/atau wadah zed sambil menjaga semua wadah data (Redis, ES, PSQL) berjalan: ./docker/run devel rebuild
Jika Anda hanya ingin menciptakan kembali wadah -wadah itu tanpa membangunnya kembali ./docker/run devel recreate
Meskipun debugging mungkin berguna alih -alih membiarkan /entrypoint.sh menginisialisasi wadah untuk melewatkan langkah -langkah ini dan memeriksa sendiri. Anda dapat melakukan ini dengan mengubah command: run-zed dari wadah yang memprihatinkan untuk command: sleep 1w di docker-compose-devel.yml dan buat ulang wadah dengan menjalankan ./docker/run devel recreate zed .
docker-compose Karena semua ini didasarkan pada docker-compose(1) Anda mungkin perlu menyebutnya sendiri, misalnya untuk memasukkan wadah melalui shell: ./docker/run devel compose exec yves bash
Jika output dari build tidak terlalu memberi tahu dan Anda membutuhkan sesi debug yang lebih dalam, pertimbangkan langkah -langkah berikut untuk membangkitkan kembali wadah pembangunan perantara yang mati:
./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
Dan di sini Anda menyelidiki penyebab kegagalan pembangunan.
Kami memperkenalkan penggunaan pemasang Spryker. Sebelum versi ini, kami telah memberikan seluruh proses sprykwer, instal, dan penyediaan dalam skrip shell yang berada di pangkalan dan gambar Spryker. Ini telah dijatuhkan mendukung pemasang Spryker baru yang tidak lebih dari kontrak antara aplikasi dan infrastruktur. Kontrak ini secara eksplisit mengawasi semua tindakan yang diperlukan untuk diambil untuk membangun toko. Kami telah menyiapkan kontrak rutin instalasi seperti itu melalui config/installer/claranet.yml .
Kami menjatuhkan dukungan Alpine untuk Debian Stretch! Jika Anda memerlukan Alpine, silakan gunakan versi sebelumnya 2.28.0, tetapi kami tidak mendukung alpine lebih lanjut.
Catatan juga: Gambar induk beralih dari claranet/spryker-base ke claranet/php , yang merusak struktur docker/ Filesystem sebelumnya! Kami telah memilih jalur ini karena gambar dasar sebelumnya dapat lebih digeneralisasi lebih lanjut untuk mencocokkan tidak hanya persyaratan spryker, tetapi juga persyaratan aplikasi berbasis PHP.
Jika Anda menemukan bug yang tidak terdaftar di sini, silakan laporkan!
Kami tidak akan mengirimkan demoshop sampai https://bugs.php.net/bug.php?id=76029 diperbaiki dan kami dapat mengaktifkan opcache. Opcache sangat penting dalam lingkungan prod, dan tidak masuk akal untuk menggunakan 7.2 di dev dan 7.1 dalam produksi ...
Karena Spryker Demoshop 2.32 tampaknya, bahwa ada bug yang menyebabkan opcache melempar pengecualian. Jadi kami terpaksa menonaktifkan Opcache.
