spryker demoshop
1.0.0
docker-composeRequer: uma versão recente e estável do Docker e Docker-Comppose (com suporte Docker-compose.yml 3.4) no seu sistema Linux ou MacOS.
Como essa pilha é bastante complexa, incluindo um es falhado, requer pelo menos 4 GB de memória. Se você estiver executando o Docker no Windows/MacOS, ajuste as configurações de acordo.
Se os requisitos forem atendidos, a execução da loja é bastante fácil. Basta inserir estas etapas:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Isso puxa a imagem do Docker, crie uma rede, crie todos os contêineres, vincule seu código local no contêiner para permitir que você o edit de fora, conecte o contêiner um ao outro e finalmente expõe os serviços públicos. Como Yves, Zed, Jenkins-Master, PostgreSQL e Elasticsearch.
Seja paciente enquanto a pilha Spryker estiver sendo criada, porque a rotina de inicialização leva algum tempo para que todos os dados sejam importados para o banco de dados e depois exportados para Redis e Elasticsearch. Atualmente, isso leva cerca de 10 minutos.
Depois que a inicialização terminar, você poderá apontar o seu navegador para os seguintes URLs:
Esta é uma versão dockerizada da implementação oficial de referência do Spryker Demoshop. Ele está pronto para correr para fora da caixa, puxando automaticamente todas as dependências necessárias e criando uma pilha compreendendo PostgreSQL, Redis, Elasticsearch e Jenkins. Durante o tempo de execução, cada um dos serviços é inicializado.
Você pode usar esse repositório como uma demonstração para uma loja paradigmática baseada no SPRYKER COMMERCE SO ou como ponto de partida para o desenvolvimento de sua própria implementação, começando com um garfo do Demoshop.
O procedimento de construção e início, juntamente com mais ferramentas, é herdado da imagem Claranet/PHP. Lá você encontrará as idéias de design técnico por trás desta dockerização e respostas para outros pontos como:
docker/ estrutura do sistema de arquivosBenefícios da contêinerização:
Vários serviços estão sendo expostos pela pilha Docker-Compose. Para executar pilhas em paralelo e evitar colisões portuárias, precisamos alinhar a alocação da porta.
Portanto, o seguinte esquema foi implementado: o número da porta é codificado assim: ECCDD
Então Yves de é acessível via http: // localhost: 20100/e yves US via http: // localhost: 20102
Aviso: A diferenciação entre lojas/domínios por porta é aplicável apenas ao ambiente de desenvolvimento local. A pilha de grau de produção real fornecida pela Claranet está fazendo essa distinção com base no nome de domínio real.
Uma premissa central é - e esta é crucial para a sua compreensão dessa pilha - para construir uma imagem unificada em ambientes de desenvolvimento e produção. Isso afeta o uso do APPLICATION_ENV , que é avaliado pelo próprio aplicativo Spryker.
Esta variável tem o seguinte impacto:
A localização dos arquivos de configuração local e os recursos externos não é nada que precisa de consideração extra no ambiente de contêiner, pois todas essas pilhas são isoladas de qualquer maneira. Portanto, verifique se nenhuma instrução de configuração em ./config/Shared/ utilizará APPLICATION_ENV para identificar seus caminhos !!!
Consideramos apenas o ponto 1.1 que vale uma distinção. E como isso pode ser alcançado com a injeção de VARs adequados nos recipientes eficazes, não distinguimos entre os ambientes enquanto construímos as imagens. Como o ponto 1.1 exige que normalmente sejam resolvidos mais dependências, sempre construímos a imagem com APPLICATION_ENV definido para development . Mas em que modo o aplicativo realmente será executado é independente disso.
Isso significa que mesmo os contêineres de produção terão dependências de desenvolvimento incluídas. O motivo principal disso é o requisito de paridade de dev/teste/produto para garantir que os contêineres se comportem exatamente o mesmo em todos os estágios e em todos os ambientes. A troca para esta premissa é novamente imagens eficazes maiores.
Durante o tempo de execução, o comportamento do aplicativo Spryker pode ser controlado definindo APPLICATION_ENV , que aceita development ou production . Se você usar o script ./docker/run essas variáveis serão definidas automaticamente.
A idéia por trás do script de wrapper fornecida via ./docker/run é a distinção básica entre os ambientes devel e prod . A principal diferença entre esses ambientes em termos de docker-compose é o emprego de montagens de ligação no modo de desenvolvimento, o que permite ao desenvolvedor editar a base de código de fora enquanto executa o código em segundo plano dentro dos contêineres.
Como essa configuração se esforça para reduzir os esforços manuais, preparamos scripts de shell que tornam a lógica necessária e o apoiam com atalhos para as tarefas mais comuns, como criar a imagem ou criar ou derrubar a configuração do contêiner. Confira ./docker/run help
O ambiente prod destina-se a testar o resultado do seu trabalho em um ambiente de quase produção, o que significa que nenhum dados compartilhado entre o repositório local e o contêiner será estabelecido. Além disso, o aplicativo será executado com APPLICTION_ENV=production , que desativa as extensões específicas do desenvolvimento.
Como em um ambiente dockerizado Serviços externos são acessíveis em diferentes endereços, dependendo do ambiente em que o código está sendo executado, o contêiner/imagem precisa ser configurável a partir do exterior através de variáveis de ambiente. Estes precisam ser consumidos pelo aplicativo Spryker. Portanto, esta imagem espera variáveis de ambiente específicas injetadas como Docker Env vars e que estão sendo consomidas por meio de um config_local.php preparado.
Estamos alavancando o mecanismo nativo de Spryker de uma hierarquia de arquivos de configuração que define a ordem, precedência e o esquema de serem considerados arquivos de configuração. Esta imagem fornece seu próprio arquivo de configuração local do site, que pode ser encontrado neste repositório no docker/config_local.php e que pode ser encontrado na imagem do docker resultante em config/Shared/config_local.php . Como esse arquivo é o que substitui todos os outros.
A ordem de configuração é como a seguinte (Last Overidaide Prio Ones):
config_default.php - Configuração de baseconfig_default-development.php - Configuração relevante para o modo de desenvolvimento (consulte APPLICATION_ENV )config_local.php - Site Configuração local; Nesse caso, é a configuração do ambiente de contêiner.Este pedido permite que você use seu arquivo de configuração completamente independentemente do ambiente eficaz em que a loja será exibida. Você pode até controlar um comportamento diferente entre os ambientes. Acabamos de substituir as configurações locais do site, das quais essa idéia se originou.
Atualmente, ambos os ambientes devel e prod o uso de volumes sem nome, devido à suposição de um ambiente transitório. Isso significa que toda a pilha é criada com o único objetivo de verificar sua base de código. Não há nenhuma circunstância significava alguma configuração de grau de produção, onde os dados precisam persistir por recreações de contêineres !!!
O fluxo de trabalho assumido pode ser descrito como:
docker-compose(1) foi embrulhado através do script shell ./docker/run . Este script fornece atalhos para a maioria das tarefas comuns ao prestar atenção ao repositório local e sua configuração:
Apenas para construir o uso da imagem do docker: ./docker/run build
Isso se aplica a ambos os ambientes, pois ambos são baseados na mesma imagem. Ele construirá a imagem principal de Spryker-Demoshop, bem como um sabor especializado em Jenkins-Slave da imagem Spryker-Demoshop.
Na verdade, duas imagens estão sendo construídas, uma para a imagem real da loja que está sendo usada para o Nginx e os recipientes PHP no Yves e na camada Zed e um para o recipiente de escravos de Jenkins. Este último estende apenas a imagem da loja por todos os componentes Jenkins necessários para criar o Slave/Worker Jenkins. A razão para fazer isso no topo da imagem real da loja é que todos os trabalhos de back -end que estão sendo executados via Jenkins exigem a base completa do código Spryker.
O tempo de construção em uma estação de trabalho regular com SSDs construídos atualmente leva apropmatelamente 10 minutos para ambas as imagens.
Se você deseja iniciar seu próprio trabalho com base no Demoshop, poderá achar interessante o ambiente de desenvolvimento local. Essa configuração permite montar sua base de código local em um contêineres em execução e ver alterações na base de código entrarem em vigor imediatamente.
Basta correr ./docker/run devel up e lá está você.
Destrua a pilha de destaque, incluindo todos os volumes alocados sem nome: ./docker/run devel down -v
Os seguintes caminhos são montados no recipiente:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
Caso você precise reconstruir a imagem da loja e apenas recriar o Yves e/ou o recipiente Zed, mantendo todos os contêineres de dados (Redis, ES, PSQL) em execução: ./docker/run devel rebuild
Se você apenas deseja recriar esses contêineres sem reconstruí -los correndo: ./docker/run devel recreate
Enquanto a depuração pode ser útil em vez de deixar /entrypoint.sh inicializar o contêiner para pular essas etapas e verificar você mesmo. Você pode fazer isso alterando o command: run-zed do contêiner em relação ao command: sleep 1w no docker-compose-devel.yml e recriar o contêiner executando ./docker/run devel recreate zed .
docker-compose Como tudo isso é baseado na docker-compose(1) você pode precisar chamá-lo sozinho, por exemplo, para inserir um contêiner via shell: ./docker/run devel compose exec yves bash
Se a saída da construção não for tão reveladora e você precisar de uma sessão de depuração mais profunda, considere as etapas a seguir para ressuscitar o contêiner de construção intermediária morta:
./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
E aqui você vai investigar a causa da falha de construção.
Introduzimos o uso do instalador Spryker. Antes desta versão, renderizamos todo o processo de criação, instalação e provisionamento de Sprykwer em scripts de shell que residem na base e na imagem Spryker. Isso foi retirado a favor do novo instalador Spryker, que não representa nada mais que um contrato entre o aplicativo e a infraestrutura. Este contrato explicitamente Hilights todas as ações necessárias a serem tomadas para construir a loja. Preparamos esse contrato de uma rotina de instalação via config/installer/claranet.yml .
Abaixamos o apoio alpino em favor do Debian Stretch! Se você precisar de alpina, use versões anteriores 2.28.0, mas não apoiamos ainda mais o Alpine.
Observação também: a imagem pai mudou de claranet/spryker-base para claranet/php , que quebra a estrutura anterior docker/ FileSystem! Escolhemos esse caminho porque a imagem base anterior pode ser ainda mais generalizada para atender não apenas aos requisitos de Spryker, mas também a qualquer requisito de aplicativo baseado em PHP.
Se você encontrar um bug não listado aqui, denuncie -o!
Não enviaremos o DemosHop até https://bugs.php.net/bug.php?id=76029 ser corrigido e podemos ativar o Opcache. O Opcache é essencial em ambientes de produtos produtivos e não faz sentido usar 7.2 em dev e 7.1 na produção ...
Como parece Spryker Demoshop 2.32 , que há um bug que faz com que o Opcache lança exceções. Por isso, fomos forçados a desativar o Opcache.
