Tuesday, 19 April 2016

A Step By Step Guide For Deploying & Managing A PHP Application On Docker LAMP, LAPP, And LAOP Stacks


Um guia passo a passo para implantar e gerenciar um aplicativo PHP em Docker LAMP, LAPP, E LAOP Stacks

Para executar e gerenciar os 9 modelos de aplicações PHP (LAMP, LAPP, e LAOP Pilhas) neste projecto em 13 nuvens diferentes e plataformas de virtualização (incluindo vSphere, OpenStack, a AWS, Rackspace, Microsoft Azure, o Google Compute Engine, DigitalOcean, IBM SoftLayer, etc.), certifique-se que você quer:
fotografia
Customizar e executar qualquer um dos modelos publicados Docker PHP de aplicação (incluindo a lâmpada, LAPP, e LAOP Pilhas) e muitos outros modelos (incluindo multi-tier Java pilhas de aplicativos, Mongo Replica Set Cluster, Drupal, Wordpress, MEAN.JS, etc. )

fundo

Containerizing aplicações empresariais ainda é um desafio principalmente porque os quadros de composição de aplicação existentes não abordam dependências complexas, integrações externas ou auto-scaling fluxos de trabalho de pós-disposição. Além disso, o design efêmera de recipientes significa que os desenvolvedores tinham que girar novos contentores e recriar as complexas dependências e integrações externas com cada atualização de versão.
DCHQ, disponível nas versões hospedadas e no local, aborda todos esses desafios e simplifica a conteinerização de aplicações empresariais através de um quadro composição aplicação avançada que se estende Docker Compor com ligações de variáveis ​​de ambiente cross-imagem, script BASH plug-ins extensível que pode ser chamada no momento da solicitação ou pós-disposição, e clustering aplicativo para alta disponibilidade em vários hosts ou regiões com suporte para auto escala.
Uma vez que um aplicativo é provisionado, um usuário pode monitorar a CPU, memória, & I / O dos recipientes de funcionamento, receber notificações e alertas, e tenha acesso aos backups de aplicativos, a escala automática de entrada / saída de fluxos de trabalho, e plug-in fluxos de trabalho de execução para atualizar executando recipientes. Além disso, automatizado "App Run" permite aos usuários integrar seus fluxos de trabalho de integração contínua para programar a implantação de recipientes para o seu nightly builds ou sempre que as alterações são mescladas no GitHub.
Em blogs anteriores, demonstramos a automação de implementação end-to-end de várias aplicações Java (como Pizza Shop and Movie loja de aplicativos) em pilhas de aplicativos baseados em Docker multi-tier em 13 diferentes nuvens e plataformas de virtualização. Para a lista completa destes blogs, você pode visitar esta página: http://dchq.co/docker-java-applications.html
No entanto, muitos usuários ainda estavam confusos sobre alguns dos aspectos fundamentais da modelagem da aplicação. Estas questões incluem:
  • Onde é que estas variáveis ​​de ambiente vêm de no seu modelo de aplicativo baseado em YAML?
  • Como o banco de dados inicializado com os esquemas adequados necessários do meu aplicativo PHP?
Para responder a estas questões, criamos uma amostra "Names Directory" aplicação PHP neste projeto GitHub que pode ser implantado nessas pilhas de aplicação:

  • Docker LAMP Stack (Linux-Apache-MySQL-PHP)
  • Docker LAPP Stack (Linux-Apache-PostgreSQL-PHP)
  • Docker LAOP Stack (Linux-Apache-Oracle PHP)
Neste projecto, iremos fornecer um guia passo-a-passo para a configuração, implementação e gerenciamento de esta aplicação PHP usando pilhas diferentes aplicações e em diferentes nuvem de infra-estrutura / virtual.
Nós vamos cobrir:
  • Configurando o config.php da aplicação PHP
  • Inicializar o banco de dados para a aplicação PHP
  • Construção da imagem Docker usando PHP: 5,6-apache
  • Construir os modelos de aplicações baseadas em YAML que podem re-utilizados em qualquer host Linux rodando em qualquer lugar
  • Provisionamento e auto-dimensionamento da infra-estrutura subjacente em qualquer nuvem (com Rackspace sendo o exemplo neste blog)
  • Implantando a aplicação PHP multi-tier no cluster Rackspace
  • Monitoramento da CPU, memória e I / O dos recipientes de serviço
  • Possibilitando a integração contínua Usando Automated App Run
  • O dimensionamento da aplicação PHP

Configurando o config.php A aplicação PHP

Você pode clonar este exemplo "Names Directory" aplicação PHP do GitHub.
Este é o passo mais importante na sua aplicação PHP "Dockerizing". A fim de alavancar as variáveis ​​de ambiente você pode passar ao executar recipientes, você vai precisar para se certificar de que a sua candidatura está configurado de uma maneira que permitirá que você para alterar certas propriedades em tempo de pedido - como:
  • O motorista do banco de dados que você gostaria de usar
  • A URL do banco de dados
  • As credenciais de banco de dados
  • Todos os outros parâmetros que você gostaria de mudar em tempo de solicitação (por exemplo, o min / tamanho pool de conexão max, idle timeout, etc.)
Para conseguir isso, você primeiro precisa configurar config.php .
fotografia
Você vai notar que as propriedades de fonte de dados específico está fazendo referência as seguintes variáveis ​​de ambiente que serão repassados ​​na hora da solicitação:
  • DB_HOST
  • DB_USER
  • DB_PASS
  • DB_NAME
  • DB_PROVIDER
  • DB_PORT

Inicializar o banco de dados da aplicação PHP

Normalmente, recomendamos inicializar o esquema de banco de dados como parte da própria implantação de aplicativos PHP. Desta forma, você não precisa se preocupar com a manutenção de arquivos SQL separadas que precisam ser executadas no banco de dados separadamente.

No entanto, se você já tem esses arquivos SQL e você ainda preferem executá-los no banco de dados separadamente - então DCHQ podem ajudar a automatizar este processo através do seu quadro plug-in. Você pode se referir a esta seção para obter mais informações.
A fim de incluir os scripts SQL para criar as tabelas de banco de dados na aplicação PHP, você precisará configurar Persistence.php arquivo para preencher o banco de dados usando diferentes instruções SQL (dependendo do banco de dados utilizado). A função populateDatabase () funciona com o MySQL, PostgreSQL e Oracle.
fotografia

Construção da imagem Docker usando PHP: 5,6 Apache

Uma vez que a aplicação PHP é configurado, você simplesmente precisa para criar uma imagem Docker com o seu código PHP.
Uma vez conectado para DCHQ (seja o DCHQ.io hospedado ou on-premise versão), um usuário pode navegar para  construir a imagem e clique sobre o + botão para criar um novo Dockerfile (Git / GitHub / BitBucket) imagem construção.
Fornecer os valores requeridos como segue:
  • Git branch - este campo é opcional - mas um usuário pode especificar uma filial de um projeto GitHub. O ramo padrão é mestre.
  • Credenciais Git - um usuário pode armazenar as credenciais para um repositório GitHub privado firmemente no DCHQ. Isso pode ser feito ao navegar para provedores de nuvem  e clicando no + para selecionar Credenciais
  • Cluster - a construção de imagens Docker é orquestrado por meio do agente DCHQ. Como resultado, um utilizador necessita de seleccionar um conjunto em que um agente vai ser utilizado para executar a construção de imagens Docker. Se um cluster não foi criada ainda, consulte esta secção , quer registar anfitriões já em execução ou automatizar o provisionamento de nova infra-estrutura virtual.
  • Push to Registry - um utilizador pode empurrar a imagem recém-criada em cada um repositório público ou privado em Docker Hub ou Quay. Para registrar uma conta Docker Hub ou Quay, um usuário deve navegar para   Provedores e Repos nuvem e clicando no + para selecionar Docker Registos
  • Repositório - este é o nome do repositório no qual a imagem será empurrado. Por exemplo, a nossa imagem foi empurrado para dchq / php-exemplo: mais recente
  • Tag - este é o nome da marca que você gostaria de dar para a nova imagem. Os nomes de tags com suporte no DCHQ incluem:
    • {data {}} - data formatada
    • {{timestamp}} - o carimbo de tempo integral
  • Cron Expression - um usuário pode programar a construção de imagens Docker usando expressões cron out-of-box. Isso facilita diariamente e nightly builds para os usuários.
Uma vez que os campos obrigatórios estão concluídos, o usuário pode clicar em Salvar .

Um usuário pode, em seguida, clique no botão Reproduzir para construir a imagem Docker on-demand.
fotografia
Aqui está o Dockerfile real usado para construir esta imagem Docker deste repositório GitHub:
fotografia

Construir Os modelos de aplicativo baseado em YAML Isso pode re-utilizado em qualquer Linux host executando qualquer lugar

Uma vez conectado para DCHQ (seja o DCHQ.io hospedado ou versão on-premise), um usuário pode navegar para  App & Machine e clique sobre o + botão para criar um novo Docker Compose modelo.
Criamos 9 modelos de aplicativos usando as imagens oficiais de Docker Hub para a mesma aplicação PHP "Names Directory" - mas para diferentes servidores de aplicativos e bancos de dados.
Os modelos incluem exemplos das seguintes pilhas de aplicativos (para a mesma aplicação PHP):
  • Docker LAMP Stack (Linux-Apache-MySQL-PHP)
  • Docker LAPP Stack (Linux-Apache-PostgreSQL-PHP)
  • Docker LAOP Stack (Linux-Apache-Oracle XE-PHP)
  • Docker LAMP Stack (3-Tier Nginx-PHP-MySQL)
  • Docker LAPP Stack (3-Tier Nginx-PHP-PostgreSQL)
  • Docker LAOP Stack (3-Tier Nginx-PHP-Oracle XE)
  • Docker LAMP Stack (3-Tier Apache HTTP-PHP-MySQL)
  • Docker LAPP Stack (3-Tier Apache HTTP-PHP-PostgreSQL)
  • Docker LAOP Stack (3-Tier Apache HTTP-PHP-Oracle XE)

Ligações variável de ambiente entre as imagens

Além disso, um usuário pode criar cross-imagem ligações de variáveis ​​de ambiente, fazendo uma referência a variável de ambiente de outra imagem. Neste caso, temos feito várias ligações - incluindo DB_HOST = {{MySQL | container_private_ip}} - em que o IP contêiner banco de dados é resolvido dinamicamente em tempo de solicitação e é usado para garantir que o Apache-PHP Server pode estabelecer uma conexão com o banco de dados.
Aqui está uma lista de valores de variáveis ​​de ambiente suportadas:
  • {{alphanumeric | 8}} - cria um 8 caracteres seqüência alfanumérica aleatória. Isso é mais útil para criar senhas aleatórias.
  • {{Image Name | ip}} - permite que você digite o endereço IP do host de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação com o banco de dados.
  • {{Image Name | container_ip}} - permite que você insira o nome de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação segura com o banco de dados (sem expor a porta de base de dados).
  • {{Image Name | container_private_ip}} - permite que você insira o endereço IP interno de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação segura com o banco de dados (sem expor a porta de base de dados).
  • {{Image Name | port_Port Number}} - permite que você digite o número da porta de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação com o banco de dados. Neste caso, o número de porta especificado deve ser o número da porta interna - ou seja, não a porta externa que é atribuído ao recipiente. Por exemplo, {{PostgreSQL | port_5432}} irá ser traduzido para a porta externa real que vai permitir que a camada de middleware para estabelecer uma ligação com o banco de dados.
  • {{Image Name | Environment Variable Name}} - permite que você insira o valor variável de ambiente de uma imagem em variável de ambiente de outra imagem. Os casos de uso aqui são infinitas - como a maioria das aplicações multi-tier terá dependências cross-imagem.

LAMP Stack (Linux-Apache-MySQL-PHP)

fotografia
fotografia

LAPP Stack (Linux-Apache-PostgreSQL-PHP)

fotografia
fotografia

LAOP Stack (Linux-Apache-Oracle PHP)

fotografia
fotografia

LAMP Stack (3-Tier Nginx-PHP-MySQL)

fotografia
fotografia

LAPP Stack (3-Tier Nginx-PHP-PostgreSQL)

fotografia
fotografia

LAOP Stack (3-Tier Nginx-PHP-Oracle XE)

fotografia
fotografia

LAMP Stack (3-Tier ApacheHTTP-PHP-MySQL)

fotografia
fotografia

LAPP Stack (3-Tier ApacheHTTP-PHP-PostgreSQL)

fotografia
fotografia

LAOP Stack (3-Tier ApacheHTTP-PHP-Oracle XE)

fotografia
fotografia

Invocando um plug-in para inicializar o banco de dados separadamente em Docker LAMP Stack

Recomendamos inicializar o esquema de banco de dados como parte da própria implantação de aplicativos PHP. No entanto, se você ainda preferem executar os arquivos SQL no banco de dados separadamente - então DCHQ podem ajudar a automatizar este processo através do seu quadro plug-in.

Neste exemplo, o MySQL nesta pilha LAMP está invocando um plug-in script BASH para executar o arquivo populate.sql. O plug-in script BASH foi criado por navegando para  plug-ins e é algo como isto:
fotografia
Neste plug-in script BASH, $ MYSQL_USER , $ MYSQL_ROOT_PASSWORD e $ MYSQL_DATABASE são variáveis ​​de ambiente que são passadas no momento da solicitação.
$ FILE_URL é um argumento substituível que pode ser definido ao criar o plug-in ou ao solicitar a aplicação. Esta será a URL para o arquivo populate.sql.

Provisioning & Auto-dimensionamento da infra-estrutura subjacente On Any Nuvem

Depois que um aplicativo é salvo, um usuário pode registrar um provedor de nuvem para automatizar o provisionamento e auto-scaling de clusters em 12 pontos finais nuvem diferentes, incluindo VMware vSphere, OpenStack, CloudStack, a Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, IBM SoftLayer, o Google Compute Engine, e muitos outros.
Primeiro, um usuário pode registrar um provedor de nuvem para Rackspace (por exemplo), navegando para provedores de nuvem  e, em seguida, clicando no + botão para selecionar Rackspace . A API Key Rackspace precisa ser fornecido - que pode ser obtida a partir da seção Configurações da conta do painel de controle Rackspace Cloud.

Um usuário pode, então, criar um cluster com uma política de escala automática para girar automaticamente novas Cloud Servers. Isso pode ser feito ao navegar para Clusters de página e, em seguida, clicando no + botão. Você pode selecionar uma política de posicionamento por capacidade e, em seguida, Tecer como a camada de rede, a fim de facilitar a comunicação cross-recipiente seguro, protegido por senha em vários hosts dentro de um cluster. A Política de Auto-Scale por exemplo, pode definir o número máximo de VM (ou Cloud Servers) a 10.
Um usuário pode agora fornecer um número de Cloud Servers no cluster recém-criado, quer através do fluxo de trabalho baseado UI ou pela definição de um modelo de máquina de composição baseada em YAML simples que pode ser solicitada a partir da Biblioteca de autoatendimento.

Fluxo de trabalho baseado em UI - Um usuário pode solicitar Servidores Rackspace Nuvem navegando para Máquinas e depois clicar no + botão para selecionar Rackspace . Uma vez que o provedor de nuvem é selecionado, o usuário pode selecionar a região, tamanho e imagem necessários. Portas são abertas por padrão em servidores Rackspace Cloud acomodar alguns dos requisitos de porta (por exemplo, 32.000-59.000 para Docker, 6783 para Weave, e 5672 para RabbitMQ). Um cluster é selecionado e o número de Cloud Servers pode ser especificado.

Template Compose máquina baseada em YAML - Um usuário pode criar primeiro um modelo de máquina de compor para Rackspace navegando para Máquinas e selecionando Máquina Compose .
Aqui está o modelo para solicitar um servidor de 4GB Cloud.
Os parâmetros suportados para o modelo de máquina Compose estão resumidos abaixo:
  • Descrição : Descrição do modelo / template
  • instanceType : Nuvem valor específico provedor (por exemplo general1-4)
  • região : Nuvem valor específico provedor (por exemplo IAD)
  • Imagem : Obrigatório - totalmente qualificado imagem ID / nome (por exemplo IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 ou vSphere VM Template nome)
  • nome de usuário : Opcional - apenas para VM Template vSphere nome de usuário

  • password : Opcional - apenas para VM Template vSphere senha criptografada. Você pode criptografar a senha utilizando o endpoint https://www.dchq.io/#/encrypt
  • rede : Opcional - Nuvem valor específico provedor (por exemplo padrão)
  • SecurityGroup : Nuvem valor específico provedor (por exemplo dchq-security-grupo)
  • keyPair : Nuvem valor específico provedor (chave por exemplo, privados)
  • OpenPorts : Opcional - valores de porta separados por vírgulas
  • contar : Nº total de VM, o padrão é 1.
Uma vez que o modelo de máquina Compose é salvo, um usuário pode solicitar esta máquina do Self-Service Biblioteca . Um usuário pode clicar em Personalizar e, em seguida, selecionar o provedor de nuvem e Cluster para usar para provisionar esses servidores Rackspace nuvem.

Implementação do aplicativo PHP multi-tier no cluster Rackspace

Uma vez que os Cloud Servers são provisionados, um usuário pode implantar um multi-tier, aplicações PHP baseadas em Docker sobre as novas Cloud Servers. Isso pode ser feito ao navegar para a biblioteca de Self-Service e em seguida, clicando em Personalizar para solicitar uma aplicação multi-tier.
Um usuário pode selecionar um Tag Ambiente (como DEV ou QE) eo Cluster Rackspace criado antes de clicar em Executar.

Acessando O In-Browser Terminal para os recipientes de corrida

Um ícone de prompt de comando deve estar disponível ao lado dos nomes dos recipientes na página ao vivo Apps. Isso permite aos usuários entrar no recipiente utilizando um protocolo de comunicação seguro através da fila de mensagens do agente. A lista branca de comandos podem ser definidos pelo inquilino de administração para garantir que os usuários não fazer quaisquer alterações prejudiciais sobre os recipientes de funcionamento.
Para a implantação PHP por exemplo, usamos a linha de comandos para se certificar de que o código PHP é realmente sob o / var / www / html / diretório.

fotografia

Acompanhamento A CPU, memória & S Utilização / dos recipientes de serviço

Uma vez que o aplicativo está instalado e funcionando, nossos desenvolvedores monitorar a CPU, memória, & I / O dos recipientes de funcionamento para receber alertas quando essas métricas exceder um limite pré-definido. Isto é especialmente útil quando nossos desenvolvedores estão realizando testes funcionais e de carga.
Um usuário pode executar a análise de monitoramento histórico e correlacionar questões a atualizações de contentores ou construir implementações. Isso pode ser feito clicando no ações de menu do aplicativo em execução e, em seguida, em Monitoring . Um intervalo de datas personalizado pode ser selecionado para ver CPU, memória e I / O historicamente.

Permitindo que a integração contínua Usando Automated App Run

Para os desenvolvedores que desejam seguir o modelo de contentores "imutáveis" por reconstruir imagens Docker contendo o código do aplicativo e girando-se novos recipientes com cada actualização da aplicação, DCHQ fornece uma compilação de imagem automatizada e recursos aplicativo executado automatizados que permitem aos desenvolvedores criar automaticamente imagens Docker de Dockerfiles ou projetos GitHub privadas contendo Dockerfiles, e depois girar pilhas LAMP completos utilizando as mais recentes imagens, programando a implantação de aplicativos e personalizar o arrendamento aplicação.
Como explicado na imagem compilação Docker seção , o usuário pode programar duas paralelas constrói para a imagem PHP (que é baseada em php: 5,6-apache ).
  • mais recente : uma construção constantemente substituir a última tag com as últimas alterações submetidas ao seu projeto GitHub
  • {{data}} ou {{}} timestamp : uma compilação paralela que vai fazer backup de todas as imagens criadas usando uma data formatado ou carimbo de tempo para o nome da marca
Um usuário pode, em seguida, navegue até Imagem Constrói e, em seguida, clique no + botão para criar uma nova política de "Automated App Run". Um usuário pode, em seguida, preencha os campos necessários - como:
  • Nome App : o nome que será dado ao aplicativo implantado
  • Lease : por padrão, uma concessão ilimitada é selecionado. No entanto, um prazo app automatizado é mais útil para ambientes / Teste DEV onde os usuários estão esperando uma aplicação já em execução com o último código de cada vez que entrar no escritório pela manhã. Para isso, os usuários podem fornecer um contrato de arrendamento de 1-dia ou 1 semana - dependendo de suas necessidades.
  • Blueprint : um usuário pode procurar um modelo já criado com base em YAML aplicativo (ou projeto) - semelhante ao dos exemplos apresentados neste projeto.
  • Cluster : este é o cluster no qual o aplicativo será implantado. Um usuário só verá uma lista de clusters ao qual ele / ela tenha sido dado acesso.
  • Expressão cron : a implantação do aplicativo pode ser agendado usando essas expressões cron simples. Por exemplo, 0 45 15? * MON-FRI vai disparar a implementação do aplicativo em tempo de UTC 15:45 de segunda a sexta-feira.
  • Quem pode gerenciar : um usuário pode fornecer direitos granulares aqui para ditar quem mais pode gerir esta política de "App Run".
fotografia

Dimensionando o aplicativo PHP

Se o aplicativo em execução torna-se recursos limitados, um usuário pode dimensionar o aplicativo para atender a crescente carga. Além disso, um usuário pode programar a escala para fora durante o horário comercial e da escala em nos fins de semana, por exemplo.

Para dimensionar o conjunto de recipientes PHP 1-2, um usuário pode clicar no ações de menu do aplicativo em execução e, em seguida, selecione Scale Out . Um usuário pode, em seguida, especifique o novo tamanho para o cluster e, em seguida, clique em Executar agora .

Em seguida, usamos o plug-in bash para atualizar o arquivo httpd.conf do Apache HTTP Server para que ele está ciente do novo servidor de aplicativos acrescentou. Os plug-ins bash script também pode ser programado para acomodar os casos de uso, como a limpeza de registros ou atualizar configurações em frequências definidas.
Para executar um plug-in em um recipiente de execução, um usuário pode clicar no ações de menu do aplicativo em execução e, em seguida, selecione Plug-ins . Um usuário pode então selecionar o balanceador de carga (Apache HTTP Server) contentor, procure o plug-in que precisa ser executado, permitir reiniciar recipiente utilizando o botão de alternância. O argumento padrão para este plug-in irá resolver dinamicamente todo o contêiner IP de um dos recipientes PHP em execução e adicioná-los como parte do arquivo httpd.conf.
Um pedido de tempo-line está disponível para acompanhar todas as mudanças feitas ao pedido de auditoria e diagnósticos. Isso pode ser acessado a partir do menu expansível na parte inferior da página de um aplicativo em execução.
Alertas e notificações estão disponíveis para quando recipientes ou anfitriões são para baixo ou quando a CPU & Memória Utilização de qualquer hosts ou recipientes exceder um limite definido.

Conclusão

Containerizing aplicações PHP a empresa ainda é um desafio principalmente porque os quadros de composição de aplicação existentes não abordam dependências complexas, integrações externas ou auto-scaling fluxos de trabalho de pós-disposição.
DCHQ, disponível nas versões hospedadas e no local, aborda todos esses desafios e simplifica a conteinerização de aplicativos corporativos PHP através de um quadro composição aplicação antecipada que facilita ligações de variáveis ​​de ambiente cross-imagem, plug-ins extensíveis script que podem ser invocados pelo solicitar tempo ou pós-disposição, e clustering aplicativo para alta disponibilidade em vários hosts ou regiões com suporte para auto escala.
Registe-se já na http://DCHQ.io ou baixar DCHQ On-Premise  
para ter acesso aos modelos de aplicações PHP multi-tier out-of-box juntamente com a funcionalidade de gerenciamento de ciclo de vida do aplicativo como o monitoramento, atualizações de contentores, a escala in / out e entrega contínua.



No comments:

Post a Comment