spryker base
1.0.0
NOTA IMPORTANTE: Este projeto está depreciado! Use o claranet/spryker-demoshop como uma referência de bootstrap ou nossa imagem parental claranet/php para um caso de uso mais genérico de PHP! Não mantemos mais este projeto.
Esta imagem serve ao objetivo de fornecer a infraestrutura base para Yves e Zed. Infraestrutura em termos de scripts de construção/init e ferramentas adicionais em torno da própria loja. Esta imagem não fornece uma loja pronta para uso! Para usar os recursos implementados aqui, escreva seu próprio Dockerfile - que usa essa imagem base para herdar - ao longo da implementação real de uma loja Spryker.
Este projeto ainda está na versão beta e passará por possíveis mudanças de quebra!
É por isso que estamos ansiosos para obter feedback de você! Este é um trabalho de trabalho em andamento que se esforça para tornar a Dockerizer uma loja Spryker o mais fácil possível. Para atingir com sucesso esse objetivo, precisamos identificar etapas comuns que valem a pena ser generalizadas e colocar nessa imagem base. Então conte -nos sobre suas necessidades e suas experiências.
Se você quiser ver esta imagem em ação e como será usado, confira o Spryker Demoshop em contêiner. Este Demoshop serve como implementação de referência para a imagem base. Da mesma maneira que Spryker está progredindo em seus feixes e fazendo com que o Demoshop reflita as mudanças que usamos o Demoshop exatamente da mesma maneira.
Os principais traços são:
ONBUILD para conectar e controlar o processo de criação de imagem infantilBenefícios da contêinerização:
A primeira premissa é que decidimos servir o Yves e o recipiente ZED de uma imagem. O benefício é sempre atualizar consistentemente a base de código compartilhada em um cluster inteiro. A troca é de imagens um pouco maiores, uma vez que os requisitos de ambos os componentes precisam ser incluídos.
Outra premissa é - 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 será executado é independente da construção.
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 dos scripts fornecidos nesta subpasta ./shop/docker segue 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.
O conceito introduzido por essa imagem base é dividir a imagem da loja resultante em três camadas distintas (efetivamente, existem mais de apenas 3 camadas, uma vez que cada declaração no Dockerfile resulta em uma nova camada; mas a idéia de 3 camadas distintas abstrairá a lógica do acionador de Onbuild mais fácil e compreensível). Há alguns motivos para isso:
Primeiro, ele deve aproveitar o cache do Docker e acelerar reconstruções iterativas da imagem da loja. Como essas camadas são ordenadas de genérico a específico, a necessidade de reconstruções de toda a pilha enquanto trabalha iterativamente na base de código da implementação real da loja deve ser reduzida.
Segundo, camadas diferentes podem ser recuperadas em paralelo ao puxar a imagem, que acelera o tempo de criação de contêineres, que é relevante não apenas para o desenvolvimento local, mas também para implantações da configuração de produção. Além disso, como as camadas genéricas não mudam com tanta frequência, a necessidade não apenas para reconstruções, mas também para renovar a imagem inteira também deve ser reduzida.
Infelizmente, isso não ocorre sem custo, o tamanho efetivo da imagem será um pouco maior que o que é acumulado em apenas uma camada. No momento, isso parece ser uma troca aceitável.
Quais são as responsabilidades dessas camadas e onde elas estão localizadas e quando elas serão construídas?
claranet/spryker-base (esta imagem):claranet/spryker-demoshop (a imagem da loja a jusante, por exemplo, o Demoshop):spryker-base (Mind the $REBUILD_BASE_LAYER Build Variable) Caso suas dependências de php ou nó precisem ser retiradas de um repositório privado, você só precisa fornecer um ~/.netrc . Este arquivo será detectado automaticamente e temporariamente, pois o Docker Build Arg injetado no contêiner de construção transitória, usado pelo Git para clonar os repositórios apropriados e depois limpar a camada de reajuste antes que a camada seja fechada.
O formato para o $HOME/.netrc é o seguinte:
machine git.company.local
login my_user_name
password my_private_token
Para entrar em vigor, todas as dependências especificadas devem ser dadas como URL HTTP ou se transformam via git config --global "url.https://".insteadof "git://git@ que já foi preparado pela imagem base.
Se você deseja adicionar regras mais específicas, crie um script de construção na camada de dependência que é executada antes do processo de resolução de dependência:
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]"
Como os URLs do Git podem ser dados em uma combinação arbitrária, isso é necessário em algumas circunstâncias.
Tudo isso é necessário porque o Docker se recusa a implementar volumes de tempo de construção, o que tornaria esse processo muito mais fácil. Mas eles tiveram realmente motivos impressionantes, uma vez que um recurso arriscaria a reprodutibilidade, porque Dockerfile não é a única fonte de induções de construção. O IS - como em qualquer argumento tecnológico - sem verdade absoluta, apenas compensações.
Como em um ambiente dockerizado Serviços externos são acessíveis em um endereço diferente, dependendo do ambiente em que o código está em execução, precisamos de alguma configuração para ser ajustada. Portanto, usamos o mecanismo nativo de Spryker da precedência do arquivo de configuração para injetar nossa configuração através do site de configuração local config/Shared/config_local.php . Como esse arquivo é o que substitui todos os outros.
O pedido de configuração é o seguinte:
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.
Para isso, precisávamos remover config/Shared/config_local.php da lista .gitignore .
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:
Para reutilizar as funcionalidades implementadas aqui, os seguintes aspectos precisam ser alinhados com a imagem base:
./src/Pyz - sua implementação da sua loja./config - Configuração./public/{Yves,Zed} - Ponto de entrada para você aplicativo (documento root)composer.json e composer.lockpackages.json , packages.lock e yarn.lock./docker/build.conf./docker/build.d/./docker/init.d/Confira o Demoshop que preparamos para usar esta imagem aqui. Isso deve responder a todas as perguntas que você pode ter.
Como a implementação de referência é o Demoshop que é mantido por nós, este é um bom iniciante. Apenas bifurcando esse repositório ou começando do zero.
Se você deseja começar do zero, os únicos artefatos de interesse que você precisa do DemosHop são:
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.phpCom isso, você está pronto para preencher seu repositório com seu código e personalizá -lo para suas necessidades individuais.
Lembre -se do Dockerfile , que parece tão limpo quanto este:
FROM claranet/spryker-base:latest
Isso cheira a reutilização. :)
O esqueleto da loja e o Demoshop também receberam um script de shell em ./docker/run que fornece atalhos para as tarefas mais comuns. Confira o readme.md para mais detalhes.
# 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
Essas variáveis devem ser fornecidas durante a criação de contêineres como variáveis de ambiente.
A maioria das variáveis é consumida pelo arquivo 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"Consumido por ganchos de inicialização:
ZED_ADMIN_PASSWORD - se definir a senha padrão do usuário [email protected] será redefinidoENABLE_XDEBUG - O módulo PHP xdebug será ativado e configurado.ENABLE_OPCACHE - O módulo PHP opcache será ativado e configurado. Essas variáveis devem ser fornecidas através do seu projeto específico ./docker/build.conf
PROJECT (obrigatório)-Controla o prefixo do nome dos serviços criados docker-composeIMAGE (obrigatória) - Qual é o nome da imagem do docker resultante?VERSION (obrigatória) - Em qual versão da imagem do Docker estamos trabalhando?BUILD_DEPENDENCIES - Pacotes de distribuição (Debian) a serem instalados durante o tempo de construçãoBASE_DEPENDENCIES - PACAGES DE DISTRIBUIÇÃO (Debian) a serem instalados adicionalmentePHP_EXTENSIONS - Lista espacial separada da extensão PHP a ser instaladaNPM_DEPENDENCIES - pacotes de distribuição que serão intalhados antes do manuseio da NPM na camada de DEPSKEEP_DEVEL_TOOLS (padrão: false) - As ferramentas de desenvolvimento serão instaladas e mantidas além da construção?SKIP_CLEANUP (padrão: false) - Pule a etapa de limpeza em cada estágio de construção da camada. Isso ajuda a depurar problemas. Esteja ciente de que isso pula também limpando as credenciais! Então nunca solte uma imagem tão selvagem !!!CRONJOB_HANDLER - Define onde os cronjobs devem ser registrados. Atualmente, Jenkins e Crond são apoiados.REBUILD_BASE_LAYER - Se essa compilação Var for fornecida, a camada base será reconstruída durante a construção de imagem da loja a jusante Para controlar o comportamento do NGINX, PHP-FPM ou PHP, você pode injetar a configuração da parte externa do contêiner como montagens de ligação ou via Dockerfile da imagem da loja infantil.
A configuração dos serviços está preparada para incluir vários arquivos que constituíam a configuração efetiva.
Todas as configurações são preferidas de se esperar em um diretório específico, onde todos
Os locais esperados são:
/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 .A configuração padrão pode ser encontrada em:
/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
Em ambientes em que você só pode montar diretórios completos no contêiner, preparamos um mecanismo que espera uma hierarquia de diretório sob /mnt/configs e na criação de contêineres, ele simplifica todos os arquivos neste local para o local correspondente em /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
Devido à natureza dos sistemas de arquivos em camadas, a imagem infantil herdadora desta imagem base pode simples substituir configurações para alcançar o comportamento desejado desses serviços.
Eles podem ser facilmente personalizados fornecendo arquivos de configuração por si mesmo através do Dockerfile :
FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf
Como o gatilho OnBuild serão as primeiras diretivas do Child Dockerfile a serem executadas, esses arquivos substituídos estarão disponíveis pela primeira vez durante o tempo de execução do contêiner.
A maioria das decisões de design tomada na imagem base é governada pela idéia de personalização e extensibilidade. Uma imagem base que poderia ser usada apenas uma vez para uma imagem individual da loja é bastante inútil e longe de algo chamado base.
O processo de construção é praticamente o nome sugere o processo que produz a imagem que é compartilhada por todos os contêineres derivados durante o tempo de execução posteriormente.
Alguns scripts de construção consideram parâmetros que você pode definir ./docker/build.conf
Veja referência acima ..
Dir do gancho: ./docker/build.d/
Se você deseja estender as etapas de construção herdadas da imagem base ou desativá -las, você precisa colocar seu script de construção personalizado em ./docker/build.d/ . Lá você encontrará 3 diretórios refletindo cada estágio/camada:
./docker/build.d/base/ - instalações de nível de sistema operacional base./docker/build.d/deps/ - lide com dependências específicas de php/nó da loja./docker/build.d/shop/ - lide com a geração de código da base de código de loja realScripts de cada subdir são executados lexicamente (atuais).
Por exemplo, se você deseja alterar a maneira como o cache de navegação é construído pela imagem base, você deve fornecer um script no mesmo local que é fornecido pela imagem base em ./docker/build.d/shop/650_build_navigation_cache.sh . Como a imagem resultante e o contêiner utilizarão os sistemas de arquivos da União, os arquivos fornecidos pela imagem da loja recebem precedência sobre os fornecidos pela imagem BAS. Por esse mecanismo, você pode desativar uma funcionalidade simplesmente fornecendo um script que não faz nada ou pode alterar o comportamento adicionando um script que faz algo de maneira diferente ou adicionalmente.
O mesmo mecanismo descrito acima pode ser empregado para alterar a maneira como a inicialização do contêiner Spryker e toda a configuração deve ser executada. A imagem base vem com padrões significativos válidos para ambientes comuns, mas podem ser substituídos colocando scripts personalizados em locais apropriados.
A imagem base fornece ganchos para ambos, inicialização de cada um dos contêineres e para a inicialização de toda a configuração.
Dir do gancho: ./docker/entry.d/
Os argumentos de ponto de entretenimento de tempo de execução ( run-yves , run-zed , run-yves-and-zed , run-cron ) governando qual papel esse contêiner está tendo, todos fonte dos arquivos listados neste diretório de gancho. Via variáveis, os scripts decidem quais serviços ativar e começar durante o tempo de execução.
Uma tarefa comum seria ativar xdebug , conforme solicitado via ENV VAR ENABLE_XDEBUG na criação de contêineres.
Devido à natureza, todos os ganchos serão executados em cada contêiner.
Dir do gancho: ./docker/init.d/
Geralmente, cada instância da loja precisa executar etapas iniciais para inicializar essa loja. Durante esta configuração, a ampla inicialização todos os scripts do shell sob o diretor do gancho são executados. Por exemplo, para inicializar o banco de dados com dados fictícios como o Demoshop, coloca o script em ./docker/init.d/500_import_demo_data.sh .
Isso não é feito implícito, um recipiente separado deve ser gerado com o init ARG ENTRADE.
Dir do gancho: ./docker/deploy.d/
O mesmo que o procedimento init é o procedimento de implantação. Este procedimento será realizado durante as implantações. O conceito de ciclo de vida consiste nesses 2 ganchos: o init será chamado pela primeira vez e a implantação sempre que uma nova versão da imagem será realizada.
Isso não é feito implicitamente, um recipiente separado deve ser gerado com a deploy do Arg.
Como já mencionado, você está livre para adicionar suas etapas de construção e init muito personalizadas. O script ./docker/common.inc.sh o ajudará com algumas funções úteis. Confira sozinho.
Faça a sua etapa de construção dizendo usando funções de saída preparadas:
errorText - Levante um errosuccessText - Envie de volta o sucessosectionHead - Impressão manchete para um grupo de tarefassectionText - Imprimir informações intermediárias de etapa de construção Fornecemos uma função install_packages para todas as etapas de construção incluídas. Certifique -se de que você esteja usando! Ele vem com a possibilidade de sinalizar pacotes como dependências "construir". Os pacotes sinalizados como dependências de compilação serão removidos após o acabamento da construção da camada. Para sinalizar os pacotes como dependências de construção, basta definir --build como o primeiro argumento:
# remove "gcc" at the end of our image build
install_packages --build gcc
# keep "top" in the resulting image
install_packages top
Ainda estamos nos estágios iniciais deste projeto, portanto a documentação pode estar incompleta. Se você quiser saber mais sobre os recursos que estamos fornecendo, dê uma olhada na biblioteca da Shell.
Nas instâncias Yves/Zed, você pode encontrar NGINX, PHP-FPM e logs de aplicativos dentro /data/logs/
Dependemos das imagens oficiais do PHP: https://hub.docker.com/_/php/
Muito boa pergunta!
Decidimos ir para o Alpine devido a tempos de construção de imagem mais curtos - a compilação de origem e a instalação do pacote. Foi mais ou menos uma prova de conceito que deve demonstrar, que mesmo projetos de levantamento pesado podem ser hospedados no Alpine. Os benefícios esperados são tamanhos de imagem reduzidos e tempo de construção mais rápido, além de tempos de execução mais rápidos.
Infelizmente, o Musl Lib C introduz a limitação que são insuportáveis no contexto do cliente - onde a versatilidade é a chave. Desde 0.9.6, mudamos para imagens baseadas no Debian.
Duas coisas vem à mente:
Mais por vir em breve. :)
Por favor, dê uma olhada em /problemas.
