spryker demoshop
1.0.0
docker-composeExige: une version récente et stable de Docker et Docker-Compose (avec prise en charge Docker-Compose.yml 3.4) sur votre système Linux ou MacOS.
Étant donné que cette pile est assez complexe, y compris un ES entièrement fière, il nécessite au moins 4 Go de mémoire. Si vous exécutez Docker sur Windows / MacOS, veuillez ajuster les paramètres en conséquence.
Si les conditions requises sont satisfaites, la gestion de la boutique est assez facile. Entrez simplement ces étapes:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Cela tire l'image Docker, créez un réseau, créez tous les conteneurs, Bind monte votre code local dans le conteneur afin de vous permettre de vivre de l'extérieur, connecte le conteneur les uns aux autres et expose enfin les services publics. Comme Yves, Zed, Jenkins-Master, Postgresql et Elasticsearch.
Veuillez être patient pendant la création de la pile Spryker, car la routine d'initialisation prend un certain temps pour que toutes les données soient importées dans la base de données, puis exportées vers Redis et Elasticsearch. Actuellement, cela prend environ 10 minutes.
Une fois l'initialisation terminée, vous pouvez pointer votre navigateur vers les URL suivantes:
Il s'agit d'une version dockée de l'implémentation officielle de référence du Spryker Demoshop. Il est prêt à s'exécuter hors de la boîte en tirant automatiquement toutes les dépendances requises et en créant une pile comprenant PostgreSQL, Redis, Elasticsearch et Jenkins. Pendant l'exécution, chacun des services est initialisé.
Vous pouvez utiliser ce référentiel soit comme démonstration pour une boutique paradigmatique basée sur Spryker Commerce OS, soit comme point de départ pour le développement de votre propre implémentation commençant par une fourche du Demoshop.
La procédure de construction et de démarrage ainsi que d'autres outils sont héritées de l'image Claranet / PHP. Vous y trouverez les idées de conception technique derrière ce docker et répond à d'autres points comme:
docker/ Système de fichiersAvantages de la conteneurisation:
Plusieurs services sont exposés par la pile Docker-Compose. Afin d'exécuter des piles en parallèle et d'empêcher les collisions de port, nous devons aligner l'allocation de port.
Par conséquent, le schéma suivant a été mis en œuvre: le numéro de port est codé comme ceci: ECCDD
Ainsi, yves de est accessible via http: // localhost: 20100 / et yves nous via http: // localhost: 20102
AVIS: La différenciation entre les magasins / domaines par port ne s'applique qu'à l'environnement de développement local. La pile de qualité de production réelle fournie par Claranet fait cette distinction en fonction du nom de domaine réel.
Une prémisse centrale est - et celle-ci est cruciale pour votre compréhension de cette pile - pour construire une image unifiée dans les environnements de développement et de production. Cela affecte l'utilisation de APPLICATION_ENV qui est évaluée par l'application Spryker elle-même.
Cette variable a l'impact suivant:
L'emplacement des fichiers de configuration locale et des ressources externes n'est rien qui nécessite une considération supplémentaire dans l'environnement conteneurisé, car toutes ces piles sont isolées de toute façon. Veuillez donc vous assurer qu'aucune instruction de configuration sous ./config/Shared/ n'utilisera APPLICATION_ENV pour identifier leurs pattes !!!
Nous considérons uniquement le point 1.1 d'une distinction. Et comme cela pourrait être réalisé en injectant des VAR appropriés dans les conteneurs efficaces, nous ne faisons pas de distinction entre les environnements lors de la construction des images. Étant donné que le point 1.1 nécessite généralement plus de dépendances pour être résolues, nous construisons toujours l'image avec APPLICATION_ENV définie au development . Mais dans quel mode l'application sera réellement exécutée est indépendante de cela.
Cela signifie que même les conteneurs de production auront des dépendances de développement incluses. La raison principale en est l'exigence de parité Dev / Test / Prod pour s'assurer que les conteneurs se comportent exactement les mêmes à toutes les étapes et dans tous les environnements. Le compromis pour cette prémisse est à nouveau des images efficaces plus grandes.
Pendant l'exécution, le comportement de l'application Spryker peut être contrôlé en définissant APPLICATION_ENV qui accepte development ou production . Si vous utilisez le script ./docker/run ces variables seront définies automatiquement.
L'idée derrière le script de wrapper fourni via ./docker/run est la distinction de base entre les environnements devel et prod . La principale différence entre ces environnements en termes de docker-compose est l'emploi des supports de liaison en mode de développement, ce qui permet au développeur de modifier la base de code de l'extérieur tout en exécutant le code en arrière-plan dans les conteneurs.
Étant donné que cette configuration s'efforce de réduire les efforts manuels, nous avons préparé des scripts de coquille qui rendent la logique nécessaire et vous soutiennent avec les raccourcis pour les tâches les plus courantes comme la construction de l'image ou la création ou la démolition de la configuration du conteneur. Découvrez ./docker/run help
L'environnement prod est destiné à tester le résultat de votre travail dans un environnement proche de produit, ce qui signifie qu'aucune donnée partagée entre votre référentiel local et le conteneur ne sera établi. De plus, l'application sera exécutée avec APPLICTION_ENV=production qui désactive les extensions spécifiques au développement.
Étant donné que dans un environnement dockerisé, les services externes sont accessibles sur différentes adresses en fonction de l'environnement dans lequel le code s'exécute, le conteneur / image doit être configurable à partir de l'extérieur via les variables d'environnement. Ceux-ci doivent être consommés par l'application Spryker. Par conséquent, cette image s'attend à des variables d'environnement spécifiques injectées sous forme de docker Env vars et qui sont consumées via une config_local.php préparée.
Nous tirons parti du mécanisme natif Spryker d'une hiérarchie de fichiers de configuration qui définit l'ordre, la priorité et le schéma de fichiers de configuration considérés. Cette image fournit son propre fichier de configuration local de site qui pourrait être trouvé dans ce référentiel sous docker/config_local.php et qui pourrait être trouvé dans l'image Docker résultante sous config/Shared/config_local.php . Puisque ce fichier est celui qui remplace tous les autres.
L'ordre de configuration est le suivant (les derniers OverrideS PRIO):
config_default.php - Configuration de baseconfig_default-development.php - Configuration pertinente pour le mode de développement (voir APPLICATION_ENV )config_local.php - Configuration locale du site; Dans ce cas, c'est la configuration de l'environnement conteneurisé.Cette commande vous permet d'utiliser votre fichier de configuration complètement indépendamment de l'environnement efficace dans lequel la boutique fonctionnera. Vous pouvez même contrôler un comportement différent entre les environnements. Nous prions simplement le SO pour dire les paramètres locaux du site, dont cette idée provient.
Actuellement, les deux environnements devel et prod en utilisant des volumes sans nom, ce qui est dû à l'hypothèse d'un environnement transitoire. Cela signifie que toute la pile est créée dans le seul but de vérifier votre base de code. Il n'est en aucun cas une certaine configuration de grade de production, où les données doivent persister sur les recréations de conteneurs !!!
Le flux de travail supposé pourrait être décrit comme:
docker-compose(1) a été enveloppé via le script shell ./docker/run . Ce script fournit des raccourcis pour la plupart des tâches courantes tout en faisant attention au référentiel local et à sa configuration:
Juste pour construire l'utilisation de l'image docker: ./docker/run build
Cela s'applique aux deux environnements car les deux sont basés sur la même image. Il construira l'image principale de Spryker-Demoshop ainsi qu'une saveur spécialisée Jenkins-Slave de l'image Spryker-Demoshop.
En fait, 2 images sont en cours de construction, une pour l'image réelle de la boutique qui est utilisée pour le Nginx et les conteneurs PHP dans les YVE et la couche Zed, et une pour le conteneur esclave Jenkins. Ce dernier ne fait que l'image de la boutique par tous les composants Jenkins requis afin de créer des esclaves / travailleurs Jenkins. La raison de cela en haut de l'image de la boutique réelle est que tous les travaux backend exécutés via Jenkins nécessitent la base complète de code spryker.
Le temps de construction sur un poste de travail régulier avec SSDS intégré est actuellement en avant 10 minutes pour les deux images.
Si vous souhaitez commencer votre propre travail en fonction du Demoshop, vous pourriez trouver l'environnement de développement local intéressant. Cette configuration vous permet de monter votre base de code locale dans des conteneurs en cours d'exécution et de voir les modifications de la base de code prennent effet immédiatement.
Il suffit de courir ./docker/run devel up et voilà.
Détruiser la pile de développement, y compris tous les volumes non nommés: ./docker/run devel down -v
Les chemins suivants sont liés au récipient:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
Dans le cas où vous devez reconstruire l'image de la boutique et simplement vouloir recréer le conteneur Yves et / ou Zed tout en gardant tous les conteneurs de données (Redis, ES, PSQL) en cours d'exécution: ./docker/run devel rebuild
Si vous voulez juste recréer ces conteneurs sans les reconstruire courir: ./docker/run devel recreate
Lors du débogage, il peut être utile au lieu de laisser /entrypoint.sh initialiser le conteneur pour sauter ces étapes et vérifier par vous-même. Vous pouvez le faire en modifiant la command: run-zed Directive of the Recerning Container to command: sleep 1w dans le docker-compose-devel.yml et recréez le conteneur en exécutant ./docker/run devel recreate zed .
docker-compose Étant donné que tout cela est basé sur docker-compose(1) vous devrez peut-être l'appeler par vous-même, par exemple pour entrer un conteneur via Shell: ./docker/run devel compose exec yves bash
Si la sortie de la construction n'est pas si révélatrice et que vous avez besoin d'une session de débogage plus profonde, considérez les étapes suivantes afin de ressusciter le conteneur de construction intermédiaire décédé:
./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
Et ici, vous allez enquêter sur la cause de l'échec de la construction.
Nous avons introduit l'utilisation du programme d'installation de Spryker. Avant cette version, nous avons rendu l'intégralité du processus de construction, d'installation et d'approvisionnement de Sprykwer dans des scripts shell résidant dans la base et l'image Spryker. Cela a été abandonné en faveur du nouveau programme d'installation de Spryker qui ne représente rien de plus qu'un contrat entre l'application et l'infrastructure. Ce contrat réalise explicitement toutes les mesures nécessaires à prendre pour construire la boutique. Nous avons préparé un tel contrat d'une routine d'installation via config/installer/claranet.yml .
Nous avons laissé tomber le soutien alpin en faveur de Debian Stretch! Si vous avez besoin d'Alpine, veuillez utiliser les versions avant 2.28.0, mais nous ne soutenons pas davantage Alpine.
Remarque également: L'image parent est passée de claranet/spryker-base à claranet/php , qui rompt la structure précédente docker/ FileSystem! Nous avons choisi ce chemin parce que l'ancienne image de base pourrait être encore généralisée pour répondre non seulement aux exigences de Spryker, mais plutôt à toutes les exigences d'application basées sur PHP.
Si vous trouvez un bug non répertorié ici, veuillez les signaler!
Nous n'expédierons pas le Demoshop tant que https://bugs.php.net/bug.php?id=76029 est fixe et nous pouvons activer Opcache. OPCACH est essentiel dans les environnements Prod, et il n'a pas de sens d'utiliser 7.2 en Dev et 7.1 en production ...
Depuis Spryker Demoshop 2.32 il semble qu'il y ait un bug qui fait que l'Opcache lance des exceptions. Nous avons donc été obligés de désactiver l'opcache.
