spryker base
1.0.0
Catatan Penting: Proyek ini sudah usang! Harap gunakan claranet/spryker-demoshop sebagai referensi bootstrap atau cll claranet/php induk kami untuk kasus penggunaan php yang lebih generik! Kami tidak mempertahankan proyek ini lagi.
Gambar ini melayani tujuan menyediakan infrastruktur dasar untuk Yves dan Zed. Infrastruktur dalam hal skrip build/init dan perkakas lebih lanjut di sekitar toko itu sendiri. Gambar ini tidak menyediakan toko yang siap digunakan! Untuk menggunakan fitur yang diterapkan di sini, tulis Dockerfile Anda sendiri - yang menggunakan gambar dasar ini untuk diwariskan dari - di sepanjang implementasi Anda yang sebenarnya dari toko Spryker.
Proyek ini masih dalam beta dan akan mengalami kemungkinan perubahan!
Itulah mengapa kami ingin mendapatkan umpan balik dari Anda! Ini adalah upaya pekerjaan yang sedang berjalan yang berusaha untuk membuat berlabuh di toko Spryker semudah mungkin. Agar berhasil mencapai tujuan ini, kita perlu mengidentifikasi langkah -langkah umum yang layak untuk digeneralisasi dan dimasukkan ke dalam gambar dasar ini. Jadi beri tahu kami tentang kebutuhan dan pengalaman Anda.
Jika Anda ingin melihat gambar ini beraksi dan bagaimana itu akan digunakan, periksa demoshop Spryker yang dikemas. Demoshop ini berfungsi sebagai implementasi referensi untuk gambar dasar. Cara yang sama seperti Spryker memajukan bundel mereka dan membuat demoshop mencerminkan perubahan -perubahan itu, kami menggunakan demoshop dengan cara yang persis sama.
Ciri inti adalah:
ONBUILD Trigger Feature untuk mengaitkan dan mengontrol proses pembuatan gambar anakManfaat Kontainerisasi:
Premis pertama adalah, bahwa kami memutuskan untuk melayani wadah Yves dan Zed dari satu gambar. Manfaatnya adalah untuk selalu secara konsisten meningkatkan basis kode bersama di seluruh cluster. Tradeoff adalah gambar yang sedikit lebih besar, karena persyaratan kedua komponen perlu dimasukkan.
Premis lain 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 akan benar -benar dijalankan adalah independen dari build.
Ini berarti bahwa bahkan wadah produksi akan memiliki ketergantungan DEV. 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 yang disediakan dalam subfolder ./shop/docker ini mengikuti 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.
Konsep yang diperkenalkan oleh gambar dasar ini adalah untuk membagi gambar toko yang dihasilkan menjadi 3 lapisan yang berbeda (secara efektif ada lebih dari hanya 3 lapisan, karena setiap pernyataan di Dockerfile menghasilkan lapisan baru; tetapi gagasan 3 lapisan yang berbeda mengabstraksi logika pemicu OnBuild lebih mudah dan dimengerti). Ada beberapa alasan untuk ini:
Pertama, itu harus memanfaatkan cache Docker dan mempercepat pembangunan kembali iteratif dari citra toko. Karena lapisan -lapisan ini dipesan dari generik ke spesifik, kebutuhan untuk pembangunan kembali seluruh tumpukan sambil bekerja secara iteratif pada basis kode implementasi toko yang sebenarnya harus dikurangi.
Kedua, lapisan yang berbeda dapat diambil secara paralel sambil menarik gambar, yang mempercepat waktu pembuatan wadah yang relevan tidak hanya untuk pengembangan lokal, tetapi lebih untuk penyebaran pengaturan produksi. Selain itu, karena lapisan generik tidak sering berubah itu, kebutuhan tidak hanya untuk pembangunan kembali tetapi untuk mengulangi seluruh gambar harus dikurangi juga.
Sayangnya ini datang bukan tanpa biaya, ukuran gambar yang efektif akan sedikit lebih tinggi dari yang akan dibangun hanya dengan satu lapisan. Saat ini ini tampaknya menjadi tradeoff yang dapat diterima.
Apa tanggung jawab lapisan -lapisan itu dan di mana mereka berada dan kapan mereka akan dibangun?
claranet/spryker-base (gambar ini):claranet/spryker-demoshop (gambar toko hilir, misalnya demoshop):spryker-base (pikirkan variabel build $REBUILD_BASE_LAYER ) Jika dependensi PHP atau simpul Anda perlu ditarik dari repositori pribadi, Anda hanya perlu menyediakan ~/.netrc . File ini akan terdeteksi secara otomatis dan sementara sebagai Docker build yang disuntikkan ke dalam wadah build transient, yang digunakan oleh Git untuk mengkloning repositori yang sesuai, dan setelah itu menyeka lapisan resuilting tepat sebelum lapisan ditutup.
Format untuk $HOME/.netrc adalah sebagai berikut:
machine git.company.local
login my_user_name
password my_private_token
Agar berlaku, semua dependensi yang diberikan harus diberikan sebagai URL HTTP atau mereka diubah melalui git config --global "url.https://".insteadof "git://git@ yang telah disiapkan oleh gambar dasar.
Jika Anda ingin menambahkan aturan yang lebih spesifik, buat skrip build di lapisan ketergantungan yang dieksekusi sebelum proses resolusi ketergantungan:
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]"
Karena URL GIT dapat diberikan dalam kombinasi sewenang -wenang, ini dalam beberapa keadaan diperlukan.
Ini semua diperlukan karena Docker menolak untuk mengimplementasikan volume waktu pembuatan yang akan membuat proses ini jauh lebih mudah. Tetapi mereka memang mendapat alasan yang mencolok, karena fitur yang akan berisiko reproduktifitas, karena Dockerfile bukanlah satu -satunya sumber pembangunan. IS - seperti dalam argumen teknologi apa pun - tidak ada kebenaran absolut, hanya pengorbanan.
Karena di lingkungan yang berlapis pelihara, layanan eksternal dapat dijangkau pada alamat yang berbeda tergantung pada lingkungan kode berjalan di kita perlu beberapa konfigurasi untuk disesuaikan. Oleh karena itu kami menggunakan mekanisme asli Spryker dari prioritas file konfigurasi untuk menyuntikkan konfigurasi kami melalui situs konfigurasi konfigurasi Lokal Situs config/Shared/config_local.php . Karena file ini adalah yang mengesampingkan yang lainnya.
Pesanan konfigurasi adalah sebagai berikut:
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.
Untuk ini kami perlu menghapus config/Shared/config_local.php dari daftar .gitignore .
Saat ini kedua lingkungan devel dan prod menggunakan volume yang tidak disebutkan namanya yang disebabkan oleh asumsi lingkungan sementara. Ini berarti, seluruh tumpukan dapat 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:
Untuk menggunakan kembali fungsionalitas yang diterapkan di sini, aspek -aspek berikut perlu diselaraskan dengan gambar dasar:
./src/Pyz - implementasi toko Anda./config - Konfigurasi./public/{Yves,Zed} - Entrypoints to You Application (Document Root)composer.json dan composer.lockpackages.json , packages.lock and yarn.lock./docker/build.conf (ekstensi PHP, DEP Node, dll../docker/build.d/./docker/init.d/Lihatlah demoshop yang telah kami siapkan untuk menggunakan gambar ini di sini. Ini harus menjawab semua pertanyaan yang mungkin Anda miliki.
Karena implementasi referensi adalah demoshop yang dikelola oleh kami, ini adalah starter yang cukup bagus. Baik hanya dengan membayar repo ini atau dengan mulai dari awal.
Jika Anda ingin memulai dari awal, satu -satunya artefak yang menarik yang Anda butuhkan dari Demoshop adalah:
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.phpDengan ini, Anda siap mengisi repositori Anda dengan kode Anda dan menyesuaikannya dengan kebutuhan pribadi Anda.
Pikiran Dockerfile yang terlihat sebersih ini:
FROM claranet/spryker-base:latest
Baunya seperti reusability. :)
Kerangka toko dan demoshop juga mendapat skrip shell di bawah ./docker/run yang memberi Anda jalan pintas ke tugas yang paling umum. Lihatlah readme.md di sana untuk perincian lebih lanjut.
# 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
Variabel -variabel tersebut harus disediakan selama pembuatan wadah sebagai variabel lingkungan.
Sebagian besar variabel yang dikonsumsi oleh file 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"Dikonsumsi oleh inisialisasi kait:
ZED_ADMIN_PASSWORD - Jika atur kata sandi default dari pengguna [email protected] akan diatur ulangENABLE_XDEBUG - Modul PHP xdebug akan diaktifkan dan dikonfigurasi.ENABLE_OPCACHE - Modul PHP opcache akan diaktifkan dan dikonfigurasi. Variabel -variabel tersebut harus disediakan melalui proyek Anda spesifik ./docker/build.conf
PROJECT (Wajib)-Mengontrol Awalan Nama Layanan yang Dibuat dari docker-composeIMAGE (Wajib) - Apa nama gambar Docker yang dihasilkan?VERSION (wajib) - Versi gambar Docker mana yang sedang kami kerjakan?BUILD_DEPENDENCIES - Paket Distribusi (Debian) yang akan diinstal selama waktu pembangunanBASE_DEPENDENCIES - Distribusi (Debian) yang akan diinstal jugaPHP_EXTENSIONS - Daftar Ekstensi PHP yang terpisah ruang untuk diinstalNPM_DEPENDENCIES - Paket distribusi yang akan diintalasi sebelum penanganan NPM di lapisan DEPSKEEP_DEVEL_TOOLS (default: false) - Haruskah alat pengembangan dipasang dan disimpan di luar build?SKIP_CLEANUP (default: false) - Lewati Langkah Pembersihan di setiap tahap pembuatan lapisan. Ini membantu dalam masalah debugging. Ketahuilah, bahwa ini melewatkan penghapusan kredensial juga! Jadi jangan pernah merilis gambar seperti itu ke alam liar !!!CRONJOB_HANDLER - mendefinisikan di mana cronjobs harus didaftarkan. Saat ini Jenkins dan Crond didukung.REBUILD_BASE_LAYER - jika var build ini diberikan, lapisan dasar akan dibangun kembali selama build gambar toko hilir Untuk mengontrol perilaku Nginx, PHP-FPM atau PHP, Anda dapat menyuntikkan konfigurasi dari luar wadah saat mengikat dudukan atau melalui Dockerfile gambar toko anak.
Konfigurasi layanan disiapkan untuk memasukkan beberapa file yang merupakan konfigurasi yang efektif.
Semua konfigurasi diawasi untuk diharapkan di bawah direktori tertentu di mana semua file yang relevan akan
Lokasi yang diharapkan adalah:
/etc/nginx/spryker/yves.conf.d/*.conf/etc/nginx/spryker/zed.conf.d/*.conf/etc/php/fpm/yves.conf.d/*.conf/etc/php/fpm/zed.conf.d/*.conf/etc/php/ini/*.ini .Konfigurasi default dapat ditemukan di bawah:
/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
Di lingkungan di mana Anda hanya dapat memasang direktori lengkap ke dalam wadah, kami telah menyiapkan mekanisme yang mengharapkan hierarki direktori di bawah /mnt/configs dan pada pembuatan wadah itu symlink semua file di bawah lokasi ini ke lokasi yang sesuai di bawah /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
Karena sifat sistem file berlapis, gambar anak yang diwarisi dari gambar dasar ini dapat menimpa konfigurasi yang sederhana untuk mencapai perilaku yang diinginkan dari layanan tersebut.
Itu dapat dengan mudah disesuaikan dengan menyediakan file konfigurasi sendiri melalui Dockerfile :
FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf
Karena pemicu OnBuild akan menjadi arahan pertama anak Dockerfile yang dieksekusi, file -file yang ditimpa ini akan tersedia pertama kali selama runtime dari wadah.
Sebagian besar keputusan desain yang dibuat dalam gambar dasar diatur oleh gagasan penyesuaian dan ekstensibilitas. Gambar dasar yang hanya dapat digunakan sekali untuk citra toko individual tidak berguna dan jauh dari sesuatu yang disebut basis.
Proses build cukup banyak karena namanya menyarankan proses yang menghasilkan gambar yang dibagikan oleh semua wadah yang diturunkan selama runtime nanti.
Beberapa skrip build mempertimbangkan parameter yang dapat Anda atur di ./docker/build.conf
Lihat referensi di atas ..
Hook dir: ./docker/build.d/
Jika Anda ingin memperpanjang langkah -langkah build yang diwarisi dari gambar dasar atau untuk menonaktifkannya, Anda perlu menempatkan skrip build kustom Anda di bawah ./docker/build.d/ . Di sana Anda akan menemukan 3 direktori yang mencerminkan setiap tahap/lapisan:
./docker/build.d/base/ - instalasi level OS dasar./docker/build.d/deps/ - berurusan dengan dependensi php/simpul spesifik toko spesifik./docker/build.d/shop/ - menangani pembuatan kode basis kode toko yang sebenarnyaSkrip dari setiap subdir dapat diperintahkan secara leksikal dieksekusi (bersumber aktus).
Misalnya, jika Anda ingin mengubah cara cache navigasi dibangun oleh gambar dasar, Anda harus menyediakan skrip di lokasi yang sama disediakan oleh gambar dasar di bawah ./docker/build.d/shop/650_build_navigation_cache.sh . Karena gambar yang dihasilkan serta wadah akan memanfaatkan sistem file serikat, file yang disediakan oleh gambar toko didahulukan dari yang disediakan oleh gambar BAS. Dengan mekanisme ini Anda dapat menonaktifkan fungsionalitas hanya dengan menyediakan skrip yang tidak melakukan apa pun atau Anda dapat mengubah perilaku dengan menambahkan skrip yang melakukan sesuatu yang berbeda atau tambahan.
Mekanisme yang sama yang dijelaskan di atas dapat digunakan untuk mengubah cara inisialisasi wadah spryker dan seluruh pengaturan harus dieksekusi. Gambar dasar dilengkapi dengan default yang bermakna yang valid untuk lingkungan umum, tetapi dapat ditimpa dengan menempatkan skrip khusus di lokasi yang sesuai.
Gambar dasar memberikan kait untuk keduanya, inisialisasi masing -masing wadah, dan untuk inisialisasi seluruh pengaturan.
Hook dir: ./docker/entry.d/
Argumen runtime entrypoint ( run-yves , run-zed , run-yves-and-zed , run-cron ) yang mengatur peran mana yang dimiliki wadah aktual ini, semua sumber file yang tercantum dalam direktori hook ini. Variabel variabel, skrip memutuskan layanan mana yang akan diaktifkan dan untuk memulai selama runtime.
Tugas umum adalah mengaktifkan xdebug seperti yang diminta melalui Env var ENABLE_XDEBUG pada pembuatan kontainer.
Karena sifatnya semua kait akan dieksekusi pada setiap start wadah.
Hook dir: ./docker/init.d/
Umumnya setiap instance toko perlu melakukan langkah -langkah awal untuk menginisialisasi toko semacam itu. Selama pengaturan ini inisialisasi luas semua skrip shell di bawah Hook dir akan dieksekusi. Misalnya untuk menginisialisasi database dengan data dummy seperti demoshop tidak menempatkan skrip di bawah ./docker/init.d/500_import_demo_data.sh .
Ini tidak dilakukan secara implisit, wadah terpisah harus diteluskan dengan entri titik entri init .
Hook dir: ./docker/deploy.d/
Sama seperti prosedur init adalah prosedur penyebaran. Prosedur ini akan dilakukan selama penyebaran. Konsep siklus hidup terdiri dari 2 kait itu: init akan dipanggil pertama kali, dan penyebaran setiap kali versi baru dari gambar akan dilakukan.
Ini tidak dilakukan secara implisit, wadah terpisah harus diteluskan dengan deploy arg entrypoint.
Seperti yang telah disebutkan, Anda bebas menambahkan langkah -langkah build dan init khusus Anda. Skrip ./docker/common.inc.sh akan membantu Anda dengan beberapa fungsi yang berguna. Lihat sendiri.
Buat Langkah Build Anda dengan Menggunakan Fungsi Output yang Disiapkan:
errorText - Naikkan kesalahansuccessText - Kirim Back SuccesssectionHead - cetak judul untuk sekelompok tugassectionText - Cetak Informasi Langkah Bangunan Menengah Kami menyediakan fungsi install_packages untuk semua langkah build yang disertakan. Pastikan, bahwa Anda menggunakannya! Muncul dengan kemungkinan untuk menandai paket sebagai dependensi "membangun". Paket yang ditandai sebagai dependensi build akan dihapus setelah lapisan lapisan selesai. Untuk menandai paket sebagai dependensi build saja --build sebagai argumen pertama:
# remove "gcc" at the end of our image build
install_packages --build gcc
# keep "top" in the resulting image
install_packages top
Kami masih dalam tahap awal proyek ini, jadi dokumentasi mungkin tidak lengkap. Jika Anda ingin mempelajari lebih lanjut tentang fitur yang kami sediakan, silakan lihat Perpustakaan Shell.
Dalam contoh YVE/ZED Anda dapat menemukan Nginx, PHP-FPM dan log aplikasi di dalam /data/log/
Kami bergantung pada gambar PHP resmi: https://hub.docker.com/_/php/
Pertanyaan yang sangat bagus memang!
Kami telah memutuskan untuk pergi ke Alpine karena waktu pembangunan gambar yang lebih pendek - baik pembuatan sumber dan penginstalan paket. Ini kurang lebih merupakan bukti konsep yang harus menunjukkan, bahwa bahkan proyek pengangkat berat dapat di-host di Alpine. Manfaat yang diharapkan adalah ukuran gambar yang dikurangi dan waktu pembangunan yang lebih cepat serta waktu berjalan lebih cepat.
Sayangnya ternyata Musl Lib C memperkenalkan batasan yang tak tertahankan dalam konteks pelanggan - di mana keserbagunaan adalah kuncinya. Sejak 0.9.6 kami telah beralih ke gambar berbasis Debian.
Dua hal terlintas dalam pikiran:
Lebih banyak lagi akan datang. :)
Silakan lihat /masalah.
