Implantar aplicativos Symfony + React na AWS por meio do IC

Boa tarde, neste artigo, mostrarei como implantar o aplicativo Symfony 4 na AWS. Há um exemplo desse processo na documentação oficial, mas minha versão não é tão trivial quanto o download de um arquivo zip com um aplicativo. No quintal de 2019, no modo docker, a arquitetura de microsserviços e as práticas de CI / CD estão finalmente começando a ser incluídas nas ferramentas não apenas dos engenheiros de DevOps, mas também dos desenvolvedores mortais comuns. Para tornar o artigo mais interessante, adicionei uma frente ao React.JS, para atender às necessidades de mais pessoas, se o seu aplicativo não usar o Encore - não importa, indicarei como alterar o arquivo do Docker para você, o suporte ao React.JS o afeta apenas . Quem estará interessado neste tutorial? Antes de tudo, ele é voltado para desenvolvedores de PHP que desejam mudar suas práticas de implantação - para se afastar dos cânones comuns e usar o docker para compactar seu aplicativo e exibir a imagem. Mas você pode se aprofundar um pouco mais, e a narração adicional terá como objetivo implantar automaticamente o aplicativo no Git por meio da plataforma CI / CD (o CircleCI será usado, mas se você estiver interessado na configuração do Gitlab, escreva nos comentários, anexarei). De fato, não é absolutamente importante para o React / PHP se você possui um aplicativo ou, por exemplo, o .NET Core, essa parte será interessante para os desenvolvedores obterem as habilidades de automação de implantação em geral. O código fonte está disponível no repositório do github, link no final do artigo. Bem, vamos lá!

Suponho que você tenha seu próprio aplicativo Symfony, mas para fins de demonstração, esboçamos “olá, mundo!” Contendo os seguintes pacotes:

`symfony/webpack-encore-bundle symfony/form symfony/orm-pack symfony/profiler-pack symfony/security-bundle symfony/twig-bundle symfony/validator symfony/phpunit-bridge` é um conjunto mínimo de cavalheiros. No momento, a estrutura da pasta deve ser a seguinte:



Agora você precisa configurar sua infraestrutura de nuvem. Não vou me concentrar em registrar e ativar o período de avaliação da AWS; neste estágio, precisamos criar 2 instâncias de banco de dados - usarei 2 tipos de ambiente: STG (teste) para testar a implementação de novos "recursos" e PROD (produção) como diretamente "combater" servidor Muitos artigos foram escritos sobre os benefícios do banco de dados de serviço gerenciado. Além disso, buscamos principalmente a conveniência do desenvolvedor neste guia, portanto, usamos o RDS, em vez de criar nosso próprio servidor de banco de dados separado. Como DBMS para este exemplo, eu usei o PostgreSQL, você é livre para escolher qualquer um que lhe convém, acessar o serviço RDS e criar 2 instâncias da capacidade e volume necessários. Como o arquivo .env está disponível para nós " .env para uso" no Symfony, nós o usaremos, por exemplo, para o PROD e para o STG criaremos uma cópia do .env.stg e APP_ENV=dev para APP_ENV=stg APP_ENV=dev em APP_ENV=stg em .env.stg e APP_ENV=dev em APP_ENV=prod em .env e também insira os parâmetros de conexão com o .env para cada uma das instâncias criadas.

Ótimo, um começo foi feito! Como você sabe, as dependências do symfony são instaladas através do compositer; para instalá-lo, use o arquivo composer.sh, que colocamos na raiz do projeto:


Este é um guia de instalação de software do compositor .

Agora, para cada um dos ambientes, crie seu próprio Dockerfile na raiz do projeto:


e


Os arquivos podem ser usados ​​"como estão", nenhuma macro é usada para alterações. Vamos percorrer o conteúdo do Dockerfile para dissipar o toque "mágico". Como "base", usamos a imagem oficial do PHP 7.2.19 com o servidor da Web Apache integrado (você pode usar qualquer um de sua escolha, configurar um pacote com o Nginx e assim por diante. Neste exemplo, eu uso o acima como o mais, na minha opinião, conveniente). A linha de exposição não é importante para nós no momento, por si só não faz nada, mas no futuro será usada pelo ElasticBeanstalk, que precisa ser implantado corretamente. As construções a seguir usam as configurações de produção otimizadas para PHP recomendadas pelo fabricante, ativam o mod_rewrite para Apache e aumentam o tamanho máximo da memória para um script PHP de 128 para 256 mb, o que é necessário para o compositor funcionar corretamente. Em seguida, instalamos os aplicativos necessários, dependências e extensões PHP e os configuramos imediatamente. Atribuímos a pasta / var / www ao diretório de trabalho do nosso aplicativo - o código fonte do nosso aplicativo será copiado para ele. Como o apache, por padrão, usa / var / www como um ponto de entrada para seu host, e o arquivo de índice symfony está localizado em / var / www / public, alteramos a raiz do documento apache com a seguinte construção. Em seguida, instalamos o compositor, nodejs e yarn sequencialmente (se você não usar encore / react.js em seu aplicativo, não precisará dos dois últimos pontos). Por fim, copiamos nosso código fonte e iniciamos a instalação de dependências através do composer for symfony e yarn for react.js. O significado de um Dockerfile para STG separado está na penúltima instrução para docker - copiar .env.stg para .env, portanto, o arquivo .env na imagem STG conterá os parâmetros relevantes para esse ambiente. Você pode coletar localmente (é claro, com o docker instalado) a imagem, executá-la e garantir que o aplicativo esteja funcionando e que não precise de mais nada para este trabalho:

 docker build -t tmp:stg -f Dockerfile.stg . docker run -p 80:80 tmp:stg 

para STG e

 docker build -t tmp:prod . docker run -p 80:80 tmp:prod 

para PROD.
Podemos usar o EC2, configurar o ELB / ASG etc., ou usar o ElasticBeanstalk, que é apenas um presente para nós em termos de conveniência. Vá para a seção ElasticBeanstalk e crie um novo aplicativo com seu nome e descrição. Em seguida, crie 2 ambientes mencionados anteriormente: STG e PROD, crie ambos os ambientes como um ambiente de servidor da Web, especifique “Docker” como plataforma e deixe o aplicativo de Amostra como o código do aplicativo. A implantação no ElasticBeanstalk é feita através do upload de arquivos ou instruções do projeto, geralmente em um arquivo zip. No nosso caso, o fluxo será assim: coletamos a imagem do docker do nosso aplicativo, carregamos no repositório e carregamos a instrução em vez do arquivo de origem ou da imagem do docker, o que instrui o ElasticBeanstalk a tirar a imagem do servidor remoto e implantá-la. E tudo isso é automático.

Vamos começar criando um repositório para armazenar imagens do docker. Existem 2 opções:

1 - seu projeto é privado, seu código é fechado e o repositório, respectivamente, também deve ser fechado. Nesse caso, você mantém seu próprio registro de imagens em algum lugar ou usa uma nuvem privada. A AWS possui ECR para esses fins, você pode criar um repositório lá, mas ninguém o obriga a fazer isso.

2 - você tem um projeto de código aberto e pode usar o dockerhub.

No nosso exemplo, o código está aberto, mas mostrarei como usar repositórios fechados, depois de entender esse processo, conectar uma imagem do dockerhub não será difícil. A primeira coisa que precisamos é criar o próprio repositório, depois disso você obterá seu URI exclusivo. A narração adicional será para terceiros (não os repositórios da AWS ECR e sua integração), pois a ECR escreverei depois disso.

Após criar o repositório, precisamos fazer logon neste serviço e há um pequeno truque ... Vá para as configurações da janela de encaixe instalada localmente e verifique se você tem a opção de salvar as senhas no armazenamento externo removido (para usuários do macOS: “Armazene com segurança os logins da janela de encaixe no macOS Keychain "), caso contrário, o arquivo de configuração de que precisamos estará vazio. E assim, autorizamos no serviço selecionado a armazenar os registros de suas imagens:

 docker login -u LOGIN -p PASSWORD REGISTRY 

após a autenticação bem-sucedida, a seguinte construção aparecerá no arquivo de configuração ~ / .docker / config.json:

 "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" } 

Se não aparecer, verifique a configuração da janela de encaixe descrita acima novamente.

Agora tudo está pronto para preparar o arquivo de instruções para ElasticBeanstalk - Dockerrun.aws.json, seu código será assim:


Em geral, a instrução é semelhante a esta: após o login usando a chave localizada por KEY_PATH no armazenamento S3 BUCKET_ID, carregue a imagem IMAGE_URL substituindo a salva, inicie-a encaminhando a porta 80 para a mesma porta no contêiner. Agora, sobre as constantes usadas:

BUCKET_ID é a "mochila" criada automaticamente para você no serviço S3, com a forma elasticbeanstalk-REGION-HASH, é onde o sistema localiza arquivos de serviço para o ElasticBeanstalk, incluindo arquivos de aplicativos que você baixa usando o botão "Upload and deploy".

KEY_PATH - caminho do arquivo de autorização para o repositório de imagens, eu uso o formato APP_NAME / cr.json, ou seja, na pasta BUCKET_ID sob o nome do meu aplicativo (eu crio, se ainda não o tiver), coloquei o arquivo cr.json que contém o código recebido após a autorização no registro Imagens localmente:


IMAGE_URL é o URI exclusivo do seu registro de imagem + tag da própria imagem; tudo deve ficar claro aqui.

É isso, agora podemos fazer o download desse arquivo como uma versão do nosso aplicativo no ElasticBeanstalk, e ele abrirá a imagem especificada e a implantará.

Resta automatizar esse processo. E, para ser absolutamente interessante, implementarei a sequência de etapas para o próximo fluxo: para todos os commit NÃO no ramo principal, a imagem será coletada e implantada no ambiente STG e, se formos empurrados para o mestre, ou melhor, fechá-lo e preenchê-lo com solicitação de mesclagem , o código será implantado no PROD. Assim, obtemos no PROD um assistente atualizado, no qual tudo deve ficar bem, e ramificações para o desenvolvimento e teste de novo código no STG. Para esta implementação, precisamos de instruções para o upload de imagens não recentes, copie Dockerrun.aws.json para Dockerrun.aws.stg.json e renomeie Dockerrun.aws.json para Dockerrun.aws.prod.json (apenas por conveniência).

A única coisa que diferencia o Dockerrun.aws.stg.json do Dockerrun.aws.prod.json é IMAGE_URL:


Como eu disse no começo do artigo, usarei o CircleCI como um CI / CD, que, de acordo com meus sentimentos pessoais, é mais rápido que o GitlabCI se eu usar a versão SaaS gratuita. O Travis gratuito funcionaria, mas como ele não funciona com repositórios privados do git, não conduzi uma demonstração específica para que não houvesse desapontamento quando essa oportunidade fosse necessária. Deixarei as configurações do projeto no CircleCI para que os leitores estudem por si mesmas, darei as instruções necessárias para a implantação - na raiz do nosso projeto, criaremos a pasta .circleci, nela config.yml, com o seguinte conteúdo:


Eu pintei o fluxo em si um pouco antes, aqui ele é traduzido em instruções yaml para CircleCI, vamos seguir a implementação de etapas específicas. É importante observar a presença de variáveis ​​de ambiente definidas para o IC que serão usadas por ele durante o trabalho:

CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD são necessários para acessar o armazenamento de imagens do docker - a mesma coisa que colocamos no cr.json, apenas sem base64

CI_REGISTRY / CI_REGISTRY_ID compõem um URL de imagem exclusivo, sem uma tag

AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY - os nomes falam por si, são créditos da AWS para o usuário em cujo nome o CircleCI implantará. Acesse o AWS IAM e crie um usuário, adicione-o ao grupo de administradores e forneça apenas acesso programático. Lembre-se de que o AWS_SECRET_ACCESS_KEY está disponível para visualização / cópia apenas uma vez; depois de clicar no link de exibição, você não o verá novamente.

Voltar para as etapas de configuração do CircleCI. Qual é a magia? O checkout carrega o código-fonte da ramificação git no diretório de trabalho atual; esse processo é repetido em todos os trabalhos. No processo de compilação, efetuamos logon sequencialmente no repositório, coletamos o código com base no Dockerfile.stg sob a tag XXX: dev e o enviamos ao repositório. O build-master faz a mesma coisa, usa o Dockerfile “regular” sob a tag XXX: latest for assembly.

deploy-stg instala o AWS EB CLI e cria um perfil de autorização no arquivo ~ / .aws / config, necessário para que o CLI funcione corretamente e inicializa as variáveis ​​para o CLI - você precisará especificar a região que escolher, a plataforma - sempre Docker e o nome do seu aplicativo. Em seguida, copiamos o conteúdo de Dockerrun.aws.stg.json para o novo arquivo Dockerrun.aws.json e, usando o ambiente e a região específicos, fornecemos o comando para implantar nosso aplicativo usando o perfil de autorização criado. Por padrão, como resultado desse comando, todo o código da ramificação monitorada terminará em um arquivo zip, que será baixado no ElasticBeanstalk e descompactado lá, mas essa operação é relativamente cara, por isso criamos um novo arquivo Dockerrun.aws.json, que é suficiente para implantar o criado por nós imagem remota, e só precisamos carregá-la, de fato. Para isso, crie um arquivo .ebignore na raiz do projeto:


Esse arquivo usa a sintaxe .gitignore e é .gitignore, mas não para a Git CLI, mas para a AWS EB CLI. Neste arquivo, digo à CLI para ignorar todos os arquivos, exceto o Dockerrun.aws.json. Agora, quando você executa o trabalho deploy-stg no ElasticBeanstalk, apenas o arquivo que criamos será enviado. deploy-prod faz o mesmo, apenas copia o conteúdo do arquivo Dockerrun.aws.prod.json para Dockerrun.aws.json, e o último é uma indicação da sequência de trabalho no formato CircleCI (deploy-stg após build e deploy-prod após build -master) e em quais ramificações os dados estão procurando (ignore: - master e somente: - master).

Um pouco diferente é sobre o AWS ECR, como prometi, voltaremos a ele. Você não precisa fazer login remotamente no ECR e criar um arquivo cr.json, pois o ElasticBeanstalk “conhece um irmão pessoalmente”. Assim, o Dockerrun.aws.json terá uma aparência diferente - simplesmente não haverá bloqueio de autenticação:


Mas como então a autenticação acontecerá? O fato é que o serviço que acessa o ECR possui um certo conjunto de direitos, que por sua vez se baseiam em certas políticas de segurança. No nosso caso, quando a implantação é iniciada via AWS CLI a partir de um servidor de terceiros (do IC), a função "aws-elasticbeanstalk-ec2-role" é usada, encontre-a no AWS IAM na seção de funções e anexe a política adicional "AmazonEC2ContainerRegistryReadOnly" a ela. Agora, o download de um repositório privado para seu "vizinho" será bem-sucedido sem erros.

Mas isso é exatamente o carregamento da mesma VPC, por meio da CLI, o comando docker login também não é "sem truques": você precisa obter (apenas obter) créditos para o login do docker por meio da CLI da AWS, para isso existe um comando

aws ecr get-login --region REGION --no-include-email

Este comando retornará uma linha do logon do docker de formulários ...

eval $(aws ecr get-login --region EB_REGION --no-include-email)

O comando primeiro receberá uma cadeia de caracteres para autenticação e, em seguida, inicia o processo correspondente. Em vista dessas regras para o AWS ECR, o arquivo de instruções para o CircleCI terá a seguinte aparência:


docker-in-docker setup_remote_docker , . , :



, , () . «» . ( - ) , , , .

GitHub: tutorial-aws-symfony-ci