One place for hosting & domains

      Conteinerizando

      Conteinerizando um aplicativo Ruby on Rails para desenvolvimento com o Docker Compose


      Introdução

      Se você estiver desenvolvendo ativamente um aplicativo, usar o Docker pode simplificar seu fluxo de trabalho e o processo de implantação do seu aplicativo para produção. Trabalhar com contêineres no desenvolvimento oferece os seguintes benefícios:

      • Os ambientes são consistentes, o que significa que você pode escolher as linguagens e dependências que quiser para seu projeto sem se preocupar com conflitos de sistema.
      • Os ambientes são isolados, tornando mais fácil a resolução de problemas e a adição de novos membros de equipe.
      • Os ambientes são portáteis, permitindo que você empacote e compartilhe seu código com outros.

      Este tutorial mostrará como configurar um ambiente de desenvolvimento para um aplicativo Ruby on Rails usando o Docker. Você criará vários contêineres – para o aplicativo em si, o banco de dados PostgreSQL, o Redis e um serviço Sidekiq — com o Docker Compose. A configuração fará o seguinte:

      • Sincronize o código do aplicativo no host com o código no contêiner para facilitar as alterações durante o desenvolvimento.
      • Mantenha os dados do aplicativo entre as reinicializações do contêiner.
      • Configure os threads de trabalho do Sidekiq para processar os trabalhos, conforme o esperado.

      No final deste tutorial, você terá um aplicativo funcional de informações sobre tubarões sendo executado em contêineres do Docker:

      Página inicial do App Sidekiq

      Pré-requisitos

      Para seguir este tutorial, será necessário:

      Passo 1 — Clonando o projeto e adicionando dependências

      Nosso primeiro passo será clonar o repositório rails-sidekiq da conta da Comunidade DigitalOcean no GitHub. Esse repositório inclui o código da configuração descrita em Como adicionar o Sidekiq e o Redis em um aplicativo Ruby on Rails, que explica como adicionar o Sidekiq a um projeto Rails 5 existente.

      Clone o repositório em um diretório chamado rails-docker:

      • git clone https://github.com/do-community/rails-sidekiq.git rails-docker

      Navegue até o diretório rails-docker:

      Nesse tutorial, usaremos o PostgreSQL como um banco de dados. Para trabalhar com o PostgreSQL, em vez do SQLite 3, será necessário adicionar a gem pgàs dependências do projeto, que estão listadas em seu respectivo Gemfile. Abra aquele arquivo para edição usando o nano ou seu editor favorito:

      Adicione a gem em qualquer lugar das dependências principais do projeto (acima das dependências de desenvolvimento):

      ~/rails-docker/Gemfile

      . . .
      # Reduces boot times through caching; required in config/boot.rb
      gem 'bootsnap', '>= 1.1.0', require: false
      gem 'sidekiq', '~>6.0.0'
      gem 'pg', '~>1.1.3'
      
      group :development, :test do
      . . .
      

      Também podemos comentar a gem sqlite, uma vez que não a iremos usar mais:

      ~/rails-docker/Gemfile

      . . .
      # Use sqlite3 as the database for Active Record
      # gem 'sqlite3'
      . . .
      

      Por fim, comente a gem spring-watcher-listen em development:

      ~/rails-docker/Gemfile

      . . .
      gem 'spring'
      # gem 'spring-watcher-listen', '~> 2.0.0'
      . . .
      

      Se não desativarmos essa gema, veremos mensagens de erro persistentes ao acessar o console do Rails. Essas mensagens de erro resultam do fato de que essa gem permite que o Rails listen para monitorar as alterações em desenvolvimento, em vez de sondar o sistema de arquivos quanto a mudanças. Como essa gem monitora a raiz do projeto, incluindo o diretório node_modules, ela irá gerar mensagens de erro sobre quais diretórios estão sendo monitorados, sobrecarregando o console. No entanto, se estiver preocupado em preservar recursos da CPU, desativar essa gem pode não funcionar para você. Neste caso, pode ser uma boa ideia fazer o upgrade do seu aplicativo Rails para o Rails 6.

      Salve e feche o arquivo quando você terminar a edição.

      Com seu repositório de projeto em vigor, a gem pg adicionada ao seu Gemfile e a gem spring-watcher-listen comentada, você estará pronto para configurar seu aplicativo para trabalhar com o PostgreSQL.

      Passo 2 — Configurando o aplicativo para trabalhar com o PostgreSQL e o Redis

      Para trabalhar com o PostgreSQL e o Redis em desenvolvimento, precisamos fazer o seguinte:

      • Configurar o aplicativo para funcionar com o PostgreSQL como o adaptador padrão.
      • Adicionar um arquivo .env ao projeto com nosso nome de usuário do banco de dados e senha, além do host do Redis.
      • Criar um script init.sql para criar um usuário sammy para o banco de dados.
      • Adicionar um inicializador ao Sidekiq, de modo que ele possa funcionar com nosso serviço redis em contêiner.
      • Adicionar o arquivo .env e outros arquivos relevantes aos arquivos gitignore e dockerignore do projeto.
      • Criar operações de propagação do banco de dados, de modo que o nosso aplicativo tenha alguns registros com os quais poderemos trabalhar quando o inicializarmos.

      Primeiro, abra seu arquivo de configuração do banco de dados, localizado em config/database.yml:

      Atualmente, o arquivo inclui as seguintes configurações default [padrão], que serão aplicadas na ausência de outras configurações:

      ~/rails-docker/config/database.yml

      default: &default
        adapter: sqlite3
        pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
        timeout: 5000
      

      Precisamos alterar essas configurações para refletir o fato de que usaremos o adaptador postgresql, já que vamos criar um serviço do PostgreSQL com o Docker Compose para manter os dados do nosso aplicativo.

      Exclua o código que define o SQLite como o adaptador e substitua-o pelas seguintes configurações, que irão configurar o adaptador de maneira apropriada e as outras variáveis necessárias para a conexão:

      ~/rails-docker/config/database.yml

      default: &default
        adapter: postgresql
        encoding: unicode
        database: <%= ENV['DATABASE_NAME'] %>
        username: <%= ENV['DATABASE_USER'] %>
        password: <%= ENV['DATABASE_PASSWORD'] %>
        port: <%= ENV['DATABASE_PORT'] || '5432' %>
        host: <%= ENV['DATABASE_HOST'] %>
        pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
        timeout: 5000
      . . .
      

      Em seguida, vamos modificar a configuração do ambiente development, já que este é o ambiente que estamos usando nesta configuração.

      Exclua a configuração existente do banco de dados SQLite para que a seção fique parecida com esta:

      ~/rails-docker/config/database.yml

      . . .
      development:
        <<: *default
      . . .
      

      Por fim, exclua também as configurações do database para os ambientes production e test:

      ~/rails-docker/config/database.yml

      . . .
      test:
        <<: *default
      
      production:
        <<: *default
      . . .
      

      Essas modificações nas configurações padrão do banco de dados nos permitirão definir as informações do nosso banco de dados dinamicamente usando variáveis de ambiente definidas nos arquivos .env, as quais não serão aplicadas no controle de versão.

      Salve e feche o arquivo quando você terminar a edição.

      Note que, se você estiver criando um projeto Rails a partir do zero, você poderá definir o adaptador com o comando rails new, como descrito no Passo 3 do artigo sobre Como usar o PostgreSQL com seu aplicativo Ruby on Rails no Ubuntu 18.04. Isso irá definir seu adaptador em config/database.yml e adicionará automaticamente a gem pg ao projeto.

      Agora que referenciamos nossas variáveis de ambiente, podemos criar um arquivo para elas com nossas configurações preferidas. Extrair definições de configuração dessa maneira faz parte da Abordagem de 12 fatores para o desenvolvimento de aplicativos, a qual define as melhores práticas para obtenção de resiliência dos aplicativos em ambientes distribuídos. Agora, quando estivermos definindo nossos ambientes de produção e teste no futuro, configurar nossas definições de banco de dados envolverá a criação de arquivos .env adicionais e o referenciamento do arquivo apropriado nos nossos arquivos do Docker Compose.

      Abra um arquivo .env:

      Adicione os valores a seguir ao arquivo:

      ~/rails-docker/.env

      DATABASE_NAME=rails_development
      DATABASE_USER=sammy
      DATABASE_PASSWORD=shark
      DATABASE_HOST=database
      REDIS_HOST=redis
      

      Além de definir nosso nome de banco de dados, usuário e senha, também definimos um valor para o DATABASE_HOST. O valor, database, refere-se ao serviço de database do PostgreSQL que vamos criar usando o Docker Compose. Também definimos um REDIS_HOST para especificar nosso serviço redis.

      Salve e feche o arquivo quando você terminar a edição.

      Para criar o usuário de banco de dados sammy, podemos escrever um script init.sql o qual poderemos, então, montar no contêiner do banco de dados quando ele for iniciado.

      Abra o arquivo de script:

      Adicione o código a seguir para criar um usuário sammy com privilégios administrativos:

      ~/rails-docker/init.sql

      CREATE USER sammy;
      ALTER USER sammy WITH SUPERUSER;
      

      Esse script criará o usuário apropriado no banco de dados e concederá privilégios administrativos a esse usuário.

      Defina permissões apropriadas no script:

      Em seguida, vamos configurar o Sidekiq para que trabalhe com nosso serviço redis em contêiner. Podemos adicionar um inicializador ao diretório config/initializers, onde o Rails procura as definições de configuração assim que os frameworks e plug-ins estiverem carregados, que define um valor para um host do Redis.

      Abra um arquivo sidekiq.rb para especificar essas configurações:

      • nano config/initializers/sidekiq.rb

      Adicione o código a seguir ao arquivo para especificar valores para um REDIS_HOST e REDIS_PORT:

      ~/rails-docker/config/initializers/sidekiq.rb

      Sidekiq.configure_server do |config|
        config.redis = {
          host: ENV['REDIS_HOST'],
          port: ENV['REDIS_PORT'] || '6379'
        }
      end
      
      Sidekiq.configure_client do |config|
        config.redis = {
          host: ENV['REDIS_HOST'],
          port: ENV['REDIS_PORT'] || '6379'
        }
      end
      

      Assim como acontece com as definições da configuração do nosso banco de dados, tais definições nos dão a capacidade de definir dinamicamente os parâmetros de nosso host e porta. Isso, por sua vez, nos permite substituir os valores apropriados em tempo de execução sem ter que modificar o código do aplicativo propriamente dito. Além de um REDIS_HOST, temos um valor padrão definido para o REDIS_PORT, caso não seja definido em outro lugar.

      Salve e feche o arquivo quando você terminar a edição.

      Em seguida, para garantir que os dados sensíveis do nosso aplicativo não sejam copiados para o controle de versão, podemos adicionar .env ao arquivo .gitignore do nosso projeto, que diz ao Git quais arquivos ignorar no nosso projeto. Abra o arquivo para edição:

      Ao final do arquivo, adicione uma entrada para .env:

      ~/rails-docker/.gitignore

      yarn-debug.log*
      .yarn-integrity
      .env
      

      Salve e feche o arquivo quando você terminar a edição.

      Em seguida, vamos criar um arquivo .dockerignore para definir o que não deve ser copiado para nossos contêineres. Abra o arquivo para edição:

      Adicione o código a seguir ao arquivo, que diz ao Docker para ignorar algumas das coisas que não precisamos que sejam copiadas para nossos contêineres:

      ~/rails-docker/.dockerignore

      .DS_Store
      .bin
      .git
      .gitignore
      .bundleignore
      .bundle
      .byebug_history
      .rspec
      tmp
      log
      test
      config/deploy
      public/packs
      public/packs-test
      node_modules
      yarn-error.log
      coverage/
      

      Adicione também .env ao final deste arquivo:

      ~/rails-docker/.dockerignore

      . . .
      yarn-error.log
      coverage/
      .env
      

      Salve e feche o arquivo quando você terminar a edição.

      Como passo final, criaremos alguns dados de propagação, de modo que o nosso aplicativo tenha alguns registros quando o inicializarmos.

      Abra um arquivo para os dados de propagação no diretório db:

      Adicione o código a seguir ao arquivo para criar quatro tubarões de demonstração e um post de exemplo:

      ~/rails-docker/db/seeds.rb

      # Adding demo sharks
      sharks = Shark.create([{ name: 'Great White', facts: 'Scary' }, { name: 'Megalodon', facts: 'Ancient' }, { name: 'Hammerhead', facts: 'Hammer-like' }, { name: 'Speartooth', facts: 'Endangered' }])
      Post.create(body: 'These sharks are misunderstood', shark: sharks.first)
      

      Esses dados de propagação criarão quatro tubarões e um post que será associado ao primeiro tubarão.

      Salve e feche o arquivo quando você terminar a edição.

      Com seu aplicativo configurado para funcionar com o PostgreSQL e suas variáveis de ambiente criadas, você está pronto para escrever seu aplicativo Dockerfile.

      Passo 3 — Escrevendo os scripts do Dockerfile e de ponto de entrada

      Seu Dockerfile especifica o que será incluído no contêiner do seu aplicativo quando ele estiver criado. Usar um Dockerfile permite que você defina seu ambiente de contêiner e evite discrepâncias com as dependências ou versões de tempo de execução.

      Ao seguir essas diretrizes para criação de contêineres otimizados, tornaremos nossa imagem o mais eficiente possível usando uma base Alpine e tentando minimizar nossas camadas de imagem no geral.

      Abra um Dockerfile em seu diretório atual:

      As imagens do Docker são criadas com uma sucessão de imagens em camadas que são baseadas umas nas outras. Nosso primeiro passo será adicionar a imagem base para nosso aplicativo, que formará o ponto inicial da compilação do aplicativo.

      Adicione o código a seguir ao arquivo para adicionar a imagem alpine do Ruby como uma base:

      ~/rails-docker/Dockerfile

      FROM ruby:2.5.1-alpine
      

      A imagem alpine é derivada do projeto Alpine Linux e nos ajudará a manter nossa imagem com tamanho reduzido. Para obter mais informações sobre se a imagem alpine é a escolha certa para seu projeto, consulte a discussão completa na seção de Variantes de imagem da página de imagens do Docker Hub Ruby.

      Alguns fatores a serem levados em consideração ao se usar o alpine no desenvolvimento:

      • Manter a imagem com tamanho reduzido irá diminuir os tempos de carregamento da página e de recursos, especialmente se você também mantiver os volumes a um mínimo. Isso tornará a experiência do seu usuário – durante o desenvolvimento – rápida e mais próxima da experiência de se trabalhar localmente, em um ambiente não conteinerizado.
      • A paridade entre as imagens de desenvolvimento e de produção facilita implantações bem-sucedidas. Como as equipes optam frequentemente por usar imagens do Alpine na produção – pelos benefícios em termos de velocidade, o desenvolvimento com uma base de Alpine ajuda a compensar os problemas na transição para a produção.

      Em seguida, defina uma variável de ambiente para especificar a versão Bundler:

      ~/rails-docker/Dockerfile

      . . .
      ENV BUNDLER_VERSION=2.0.2
      

      Esse é um dos passos que vamos adotar para evitar conflitos de versão entre a versão bundler padrão, disponível no nosso ambiente e nosso código de aplicativo, que exige o Bundler 2.0.2.

      Em seguida, adicione ao Dockerfile os pacotes necessários para trabalhar com o aplicativo:

      ~/rails-docker/Dockerfile

      . . .
      RUN apk add --update --no-cache 
            binutils-gold 
            build-base 
            curl 
            file 
            g++ 
            gcc 
            git 
            less 
            libstdc++ 
            libffi-dev 
            libc-dev 
            linux-headers 
            libxml2-dev 
            libxslt-dev 
            libgcrypt-dev 
            make 
            netcat-openbsd 
            nodejs 
            openssl 
            pkgconfig 
            postgresql-dev 
            python 
            tzdata 
            yarn
      

      Esses pacotes incluem o nodejs e yarn, entre outros. Como nosso aplicativo atende os ativos com o webpack, precisamos incluir o Node.js e o Yarn para que o aplicativo funcione conforme o esperado.

      Lembre-se de que a imagem alpine tem tamanho diminuto: a lista apresentada aqui não esgota os pacotes que você talvez queira ou precise no desenvolvimento, quando estiver conteinerizando o seu próprio aplicativo.

      Em seguida, instale a versão do bundler apropriada:

      ~/rails-docker/Dockerfile

      . . .
      RUN gem install bundler -v 2.0.2
      

      Esse passo irá garantir a paridade entre o nosso ambiente conteinerizado e as especificações no arquivo Gemfile.lock desse projeto.

      Agora, defina o diretório de trabalho para o aplicativo no contêiner:

      ~/rails-docker/Dockerfile

      . . .
      WORKDIR /app
      

      Copie para lá o seu Gemfile e o Gemfile.lock:

      ~/rails-docker/Dockerfile

      . . .
      COPY Gemfile Gemfile.lock ./
      

      Copiar esses arquivos como um passo independente, seguido de bundle install, significa que as gems do projeto não precisam ser recompiladas toda vez que você fizer alterações no código do seu aplicativo. Isso funcionará em conjunto com o volume da gem que vamos incluir no nosso arquivo Compose, o qual irá montar as gems para o seu contêiner de aplicativo, nos casos em que o serviço for recriado.As gems do projeto, porém, permanecerão as mesmas.

      Em seguida, defina as opções de configuração para a compilação da gem nokogiri:

      ~/rails-docker/Dockerfile

      . . .
      RUN bundle config build.nokogiri --use-system-libraries
      . . .
      

      Esse passo compila a nokigiri com as versões de biblioteca libxml2 e libxslt que adicionamos ao contêiner do aplicativo no passo RUN apk add... acima.

      Em seguida, instale as gems do projeto:

      ~/rails-docker/Dockerfile

      . . .
      RUN bundle check || bundle install
      

      Antes de instalar as gems, essa instrução verifica se elas já estão instaladas.

      Em seguida, vamos repetir o mesmo procedimento que usamos com as gems em relação aos nossos pacotes e dependências do JavaScript. Primeiro, vamos copiar os metadados do pacote; em seguida, vamos instalar as dependências e, por fim, vamos copiar o código do aplicativo na imagem do contêiner.

      Para começar com a seção Javascript do nosso Dockerfile, copie os arquivos package.json e yarn.lock do diretório de seu projeto atual, no host, para o contêiner:

      ~/rails-docker/Dockerfile

      . . .
      COPY package.json yarn.lock ./
      

      Depois, instale os pacotes necessários com yarn install:

      ~/rails-docker/Dockerfile

      . . .
      RUN yarn install --check-files
      

      Essa instrução inclui um sinalizador --check-files com o comando yarn, um recurso que garante que nenhum arquivo instalado anteriormente tenha sido removido. Como no caso das nossas gems, vamos gerenciar a permanência dos pacotes no diretório node_modules com um volume, quando escrevermos nosso arquivo Compose.

      Por fim, copie o resto do código do aplicativo e inicie o aplicativo com um script de ponto de entrada:

      ~/rails-docker/Dockerfile

      . . .
      COPY . ./
      
      ENTRYPOINT ["./entrypoints/docker-entrypoint.sh"]
      

      Usar um script de ponto de entrada nos permite executar o contêiner como um executável.

      O Dockerfile final ficará parecido com este:

      ~/rails-docker/Dockerfile

      FROM ruby:2.5.1-alpine
      
      ENV BUNDLER_VERSION=2.0.2
      
      RUN apk add --update --no-cache 
            binutils-gold 
            build-base 
            curl 
            file 
            g++ 
            gcc 
            git 
            less 
            libstdc++ 
            libffi-dev 
            libc-dev 
            linux-headers 
            libxml2-dev 
            libxslt-dev 
            libgcrypt-dev 
            make 
            netcat-openbsd 
            nodejs 
            openssl 
            pkgconfig 
            postgresql-dev 
            python 
            tzdata 
            yarn
      
      RUN gem install bundler -v 2.0.2
      
      WORKDIR /app
      
      COPY Gemfile Gemfile.lock ./
      
      RUN bundle config build.nokogiri --use-system-libraries
      
      RUN bundle check || bundle install
      
      COPY package.json yarn.lock ./
      
      RUN yarn install --check-files
      
      COPY . ./
      
      ENTRYPOINT ["./entrypoints/docker-entrypoint.sh"]
      

      Salve e feche o arquivo quando você terminar a edição.

      Em seguida, crie um diretório chamado entrypoints para os scripts de ponto de entrada:

      Esse diretório incluirá nosso script de ponto de entrada principal e um script para o nosso serviço Sidekiq.

      Abra o arquivo para o script de ponto de entrada do aplicativo:

      • nano entrypoints/docker-entrypoint.sh

      Adicione o código a seguir ao arquivo:

      rails-docker/entrypoints/docker-entrypoint.sh

      #!/bin/sh
      
      set -e
      
      if [ -f tmp/pids/server.pid ]; then
        rm tmp/pids/server.pid
      fi
      
      bundle exec rails s -b 0.0.0.0
      

      A primeira linha importante é set -e, que diz ao shell /bin/sh – que executa o script – para falhar rapidamente se houver problemas mais tarde no script. Em seguida, o script verifica se o tmp/pids/server.pid não está presente, a fim de garantir que não haverá conflitos de servidor quando iniciarmos o aplicativo. Por fim, o script inicia o servidor Rails com o comando bundle exec rails s. Usamos a opção -b com esse comando para vincular o servidor a todos os endereços IP e não para o localhost padrão. Essa invocação faz com que o servidor Rails encaminhe os pedidos de entrada para o IP do contêiner e não para o localhost padrão.

      Salve e feche o arquivo quando você terminar a edição.

      Crie o executável do script:

      • chmod +x entrypoints/docker-entrypoint.sh

      Em seguida, vamos criar um script para iniciar nosso serviço sidekiq, que irá processar nossas tarefas do Sidekiq. Para obter mais informações sobre como esse aplicativo usa o Sidekiq, consulte o artigo sobre Como adicionar o Sidekiq e o Redis a um aplicativo Ruby on Rails.

      Abra um arquivo para o script de ponto de entrada do Sidekiq:

      • nano entrypoints/sidekiq-entrypoint.sh

      Adicione o código a seguir ao arquivo para iniciar o Sidekiq:

      ~/rails-docker/entrypoints/sidekiq-entrypoint.sh

      #!/bin/sh
      
      set -e
      
      if [ -f tmp/pids/server.pid ]; then
        rm tmp/pids/server.pid
      fi
      
      bundle exec sidekiq
      

      Esse script inicia o Sidekiq no contexto do nosso pacote de aplicativo.

      Salve e feche o arquivo quando você terminar a edição. Torne-o executável:

      • chmod +x entrypoints/sidekiq-entrypoint.sh

      Com seus scripts de ponto de entrada e o Dockerfile instalados, você está pronto para definir seus serviços no seu arquivo Compose.

      Usando o Docker Compose, conseguiremos executar vários contêineres necessários para nossa configuração. Vamos definir nossos serviços do Compose no nosso arquivo principal docker-compose.yml. Um serviço no Compose é um contêiner em execução e as definições de serviço — que você incluirá no seu arquivo docker-compose.yml — contém informações sobre como cada imagem de contêiner será executada. A ferramenta Compose permite que você defina vários serviços para construir aplicativos multi-contêiner.

      Nossa configuração do aplicativo incluirá os seguintes serviços:

      • O aplicativo em si
      • O banco de dados PostgreSQL
      • Redis
      • Sidekiq

      Também vamos incluir uma montagem bind como parte da nossa preparação, de modo que qualquer alteração de código que fizermos durante o desenvolvimento será imediatamente sincronizada com os contêineres que precisam de acesso a esse código.

      Note que não estamos definindo um serviço de test, uma vez que testar está fora do âmbito deste tutorial e desta série. Porém, você pode fazer esse teste, seguindo o anterior que estamos usando aqui para o serviço do sidekiq.

      Abra o arquivo docker-compose.yml:

      Primeiro, adicione a definição de serviço do aplicativo:

      ~/rails-docker/docker-compose.yml

      version: '3.4'
      
      services:
        app:
          build:
            context: .
            dockerfile: Dockerfile
          depends_on:
            - database
            - redis
          ports:
            - "3000:3000"
          volumes:
            - .:/app
            - gem_cache:/usr/local/bundle/gems
            - node_modules:/app/node_modules
          env_file: .env
          environment:
            RAILS_ENV: development
      

      A definição de serviço do app inclui as seguintes opções:

      • build: define as opções de configuração, incluindo o context e dockerfile, que serão aplicadas quando o Compose construir a imagem do aplicativo. Se quisesse usar uma imagem existente de um registro como o Docker Hub, você poderia usar como alternativa a instrução image, com informações sobre seu nome de usuário, repositório e tag da imagem.
      • context: define o contexto de construção para a construção da imagem — neste caso, o diretório atual do projeto.
      • dockerfile: especifica o Dockerfile no diretório atual do seu projeto como o arquivo que o Compose usará para construir a imagem do aplicativo.
      • depends_on: esta opção define primeiro os contêineres database e redis, de modo que eles estejam em funcionamento antes do app.
      • ports: esta opção mapeia a porta 3000 no host até a porta 3000 no contêiner.
      • volumes: estamos incluindo dois tipos de montagens aqui:
        • A primeira é uma montagem bind que monta o código do nosso aplicativo no host para o diretório /app no contêiner. Isso facilitará o desenvolvimento rápido, uma vez que quaisquer alterações que você faça no código do seu host serão povoadas imediatamente no contêiner.
        • A segunda é um volume nomeado, o gem_cache. Quando a instrução bundle install executa no contêiner, ela instala as gems do projeto. Adicionar esse volume significa que, caso você recriar o contêiner, as gems serão montadas no novo contêiner. Essa montagem pressupõe que não houve nenhuma alteração no projeto. Assim, caso você de fato faça alterações nas gems do seu projeto no desenvolvimento, você precisará lembrar de excluir esse volume antes de recriar o serviço do seu aplicativo.
        • O terceiro volume é um volume nomeado para o diretório node_modules. Em vez de ter o node_modules montado no host, o qual pode levar a discrepâncias de pacotes e conflitos de permissões no desenvolvimento, esse volume irá garantir que os pacotes neste diretório sejam mantidos e reflitam o estado atual do projeto. Novamente, se você modificar as dependências do Node do projeto, precisará remover e recriar esse volume.
      • env_file: esta opção diz ao Compose que gostaríamos de adicionar variáveis de ambiente de um arquivo chamado .env, localizado no contexto da compilação.
      • environment: usar esta opção nos permite definir uma variável de ambiente não confidencial, enviando informações sobre o ambiente do Rails para o contêiner.

      Em seguida, abaixo da definição de serviço do app, adicione o código a seguir para definir seu serviço de database:

      ~/rails-docker/docker-compose.yml

      . . .
        database:
          image: postgres:12.1
          volumes:
            - db_data:/var/lib/postgresql/data
            - ./init.sql:/docker-entrypoint-initdb.d/init.sql
      

      Ao contrário do serviço app, o serviço database extrai uma imagem postgres diretamente do Docker Hub. Note que estamos também fixando a versão aqui, em vez de defini-la como latest [mais recente] ou sem especificá-la (que, por padrão, é definida como latest). Dessa forma, podemos garantir que essa configuração funcione com as versões especificadas aqui e evitar surpresas inesperadas com as alterações de falha do código na imagem.

      Também estamos incluindo aqui um volume db_data, o qual manterá os dados do nosso aplicativo entre as inicializações do contêiner. Além disso, montamos nosso script de inicialização init.sql no diretório apropriado, docker-entrypoint-initdb.d/ no contêiner, para criar nosso usuário de banco de dados sammy. Depois que o ponto de entrada da imagem criar o usuário e banco de dados padrão postgres, ele executará quaisquer scripts encontrados no diretório docker-entrypoint-initdb.d/, que você poderá usar para as tarefas de inicialização necessárias. Para obter mais detalhes, examine a seção Inicialização de scripts da documentação da imagem do PostgreSQL.

      Em seguida, adicione a definição de serviço redis:

      ~/rails-docker/docker-compose.yml

      . . .
        redis:
          image: redis:5.0.7
      

      Assim como o serviço de database, o serviço de redis usa uma imagem do Docker Hub. Neste caso, não vamos manter o cache do trabalho do Sidekiq.

      Por fim, adicione a definição de serviço do sidekiq:

      ~/rails-docker/docker-compose.yml

      . . .
        sidekiq:
          build:
            context: .
            dockerfile: Dockerfile
          depends_on:
            - app      
            - database
            - redis
          volumes:
            - .:/app
            - gem_cache:/usr/local/bundle/gems
            - node_modules:/app/node_modules
          env_file: .env
          environment:
            RAILS_ENV: development
          entrypoint: ./entrypoints/sidekiq-entrypoint.sh
      

      Nosso serviço sidekiq se assemelha ao serviço app em alguns aspectos: ele usa o mesmo contexto e imagem de compilação, variáveis de ambiente e volumes. No entanto, ele é depende dos serviços app, redis e database e, portanto, será o último a ser iniciado. Além disso, ele usa um entrypoint que irá substituir o ponto de entrada definido no Dockerfile. Essa configuração do entrypoint aponta para entrypoints/sidekiq-entrypoint.sh, que inclui o comando apropriado para iniciar o serviço sidekiq.

      Como passo final, adicione as definições de volume abaixo da definição de serviço sidekiq:

      ~/rails-docker/docker-compose.yml

      . . .
      volumes:
        gem_cache:
        db_data:
        node_modules:
      

      Nossa chave de nível superior de volumes define os volumes gem_cache, db_data e node_modules. Quando o Docker cria volumes, o conteúdo do volume é armazenado em uma parte do sistema de arquivos do host, /var/lib/docker/volumes/, que é gerenciado pelo Docker. O conteúdo de cada volume é armazenado em um diretório em /var/lib/docker/volumes/ e é montado em qualquer contêiner que utilize o volume. Dessa forma, os dados de informações sobre tubarões – a serem criados por nossos usuários – irão permanecer no volume db_data, mesmo se removermos e recriarmos o serviço de database.

      O arquivo final se parecerá com este:

      ~/rails-docker/docker-compose.yml

      version: '3.4'
      
      services:
        app:
          build:
            context: .
            dockerfile: Dockerfile
          depends_on:     
            - database
            - redis
          ports:
            - "3000:3000"
          volumes:
            - .:/app
            - gem_cache:/usr/local/bundle/gems
            - node_modules:/app/node_modules
          env_file: .env
          environment:
            RAILS_ENV: development
      
        database:
          image: postgres:12.1
          volumes:
            - db_data:/var/lib/postgresql/data
            - ./init.sql:/docker-entrypoint-initdb.d/init.sql
      
        redis:
          image: redis:5.0.7
      
        sidekiq:
          build:
            context: .
            dockerfile: Dockerfile
          depends_on:
            - app      
            - database
            - redis
          volumes:
            - .:/app
            - gem_cache:/usr/local/bundle/gems
            - node_modules:/app/node_modules
          env_file: .env
          environment:
            RAILS_ENV: development
          entrypoint: ./entrypoints/sidekiq-entrypoint.sh
      
      volumes:
        gem_cache:
        db_data:
        node_modules:     
      

      Salve e feche o arquivo quando você terminar a edição.

      Com as definições do seu serviço gravadas, você estará pronto para iniciar o aplicativo.

      Passo 5 — Testando o aplicativo

      Com seu arquivo docker-compose.yml funcionando, você pode criar seus serviços com o comando docker-compose up e propagar o seu banco de dados. Você também pode testar se seus dados serão mantidos, interrompendo e removendo seus contêineres com o docker-compose down e recriando-os.

      Primeiro, compile as imagens de contêiner e crie os serviços, executando o docker-compose up com o sinalizador -d, o qual executará os contêineres em segundo plano:

      Você verá um resultado, confirmando que seus serviços foram criados:

      Output

      Creating rails-docker_database_1 ... done Creating rails-docker_redis_1 ... done Creating rails-docker_app_1 ... done Creating rails-docker_sidekiq_1 ... done

      Você também pode obter informações mais detalhadas sobre os processos de inicialização exibindo o resultado do registro dos serviços:

      Você verá algo simelhante a isso caso tudo tenha iniciado corretamente:

      Output

      sidekiq_1 | 2019-12-19T15:05:26.365Z pid=6 tid=grk7r6xly INFO: Booting Sidekiq 6.0.3 with redis options {:host=>"redis", :port=>"6379", :id=>"Sidekiq-server-PID-6", :url=>nil} sidekiq_1 | 2019-12-19T15:05:31.097Z pid=6 tid=grk7r6xly INFO: Running in ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-musl] sidekiq_1 | 2019-12-19T15:05:31.097Z pid=6 tid=grk7r6xly INFO: See LICENSE and the LGPL-3.0 for licensing details. sidekiq_1 | 2019-12-19T15:05:31.097Z pid=6 tid=grk7r6xly INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org app_1 | => Booting Puma app_1 | => Rails 5.2.3 application starting in development app_1 | => Run `rails server -h` for more startup options app_1 | Puma starting in single mode... app_1 | * Version 3.12.1 (ruby 2.5.1-p57), codename: Llamas in Pajamas app_1 | * Min threads: 5, max threads: 5 app_1 | * Environment: development app_1 | * Listening on tcp://0.0.0.0:3000 app_1 | Use Ctrl-C to stop . . . database_1 | PostgreSQL init process complete; ready for start up. database_1 | database_1 | 2019-12-19 15:05:20.160 UTC [1] LOG: starting PostgreSQL 12.1 (Debian 12.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit database_1 | 2019-12-19 15:05:20.160 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 database_1 | 2019-12-19 15:05:20.160 UTC [1] LOG: listening on IPv6 address "::", port 5432 database_1 | 2019-12-19 15:05:20.163 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" database_1 | 2019-12-19 15:05:20.182 UTC [63] LOG: database system was shut down at 2019-12-19 15:05:20 UTC database_1 | 2019-12-19 15:05:20.187 UTC [1] LOG: database system is ready to accept connections . . . redis_1 | 1:M 19 Dec 2019 15:05:18.822 * Ready to accept connections

      Você também pode verificar o status dos seus contêineres com o docker-compose ps:

      Você verá um resultado indicando que seus contêineres estão funcionando:

      Output

      Name Command State Ports ----------------------------------------------------------------------------------------- rails-docker_app_1 ./entrypoints/docker-resta ... Up 0.0.0.0:3000->3000/tcp rails-docker_database_1 docker-entrypoint.sh postgres Up 5432/tcp rails-docker_redis_1 docker-entrypoint.sh redis ... Up 6379/tcp rails-docker_sidekiq_1 ./entrypoints/sidekiq-entr ... Up

      Em seguida, crie e propague seu banco de dados e execute migrações nele com o comando docker-compose exec a seguir:

      • docker-compose exec app bundle exec rake db:setup db:migrate

      O comando docker-compose exec permite que você execute comandos nos seus serviços. Aqui, nós o estamos usando para executar rake db:setup e db:migrate, no contexto do pacote do nosso aplicativo, com o objetivo de criar e propagar o banco de dados e executar as migrações. Como você trabalha com desenvolvimento, o docker-compose exec se mostrará útil quando quiser executar migrações em relação ao seu banco de dados de desenvolvimento.

      Você verá o seguinte resultado após executar este comando:

      Output

      Created database 'rails_development' Database 'rails_development' already exists -- enable_extension("plpgsql") -> 0.0140s -- create_table("endangereds", {:force=>:cascade}) -> 0.0097s -- create_table("posts", {:force=>:cascade}) -> 0.0108s -- create_table("sharks", {:force=>:cascade}) -> 0.0050s -- enable_extension("plpgsql") -> 0.0173s -- create_table("endangereds", {:force=>:cascade}) -> 0.0088s -- create_table("posts", {:force=>:cascade}) -> 0.0128s -- create_table("sharks", {:force=>:cascade}) -> 0.0072s

      Com seus serviços em execução, você pode acessar o localhost:3000 ou o http://your_server_ip:3000 no navegador. Você verá uma página de destino que se parece com esta:

      Página inicial do App Sidekiq

      Agora, podemos testar a permanência dos dados. Crie um novo tubarão, clicando no botão** Get Shark Info**, que levará você até a rota shark/index:

      Página do índice de tubarões com os dados propagados

      Para verificar se o aplicativo está funcionando, podemos adicionar algumas informações de demonstração a ele. Clique em New Shark. Será solicitado que coloque um nome de usuário (sammy) e senha (shark), graças às configurações de autenticação do projeto.

      Na página New Shark, digite “Mako” no campo Name e “Fast” no campo Facts.

      Clique no botão Create Shark para criar o tubarão. Assim que tiver criado o tubarão, clique em Home, na barra de navegação do site para voltar à página de destino principal do aplicativo. Agora, podemos testar se o Sidekiq está funcionando.

      Clique no botão Which Sharks Are in Danger? [Quais tubarões estão em perigo?] . Como não fez upload de nenhum tubarão em perigo, isso levará você até a visualização de index endangered [em perigo]:

      Exibição do índice Endangered [Em perigo]

      Clique em Import Endangered Sharks para importar os tubarões. Você verá uma mensagem de status informando que os tubarões foram importados:

      Iniciar importação

      Você verá também o início da importação. Atualize sua página para ver a tabela inteira:

      Atualizar tabela

      Graças ao Sidekiq, o upload de nosso lote grande de tubarões em perigo foi bem-sucedido, sem bloquear o navegador ou interferir com outras funcionalidades do aplicativo.

      Clique no botão Home, no final da página, para voltar à página principal do aplicativo:

      Página inicial do App Sidekiq

      A partir daqui, clique em Which Sharks Are in Danger? novamente. Você verá os tubarões que foram carregados novamente.

      Agora que sabemos que nosso aplicativo está funcionando corretamente, podemos testar a permanência dos nossos dados.

      De volta ao seu terminal, digite o seguinte comando para interromper e remover seus contêineres:

      Note que não estamos incluindo a opção --volumes; desta forma, nosso volume db_data não foi removido.

      O resultado a seguir confirma que seus contêineres e rede foram removidos:

      Output

      Stopping rails-docker_sidekiq_1 ... done Stopping rails-docker_app_1 ... done Stopping rails-docker_database_1 ... done Stopping rails-docker_redis_1 ... done Removing rails-docker_sidekiq_1 ... done Removing rails-docker_app_1 ... done Removing rails-docker_database_1 ... done Removing rails-docker_redis_1 ... done Removing network rails-docker_default

      Recrie os contêineres:

      Abra o console do Rails no contêiner do app com o docker-compose exec e bundle exec rails console:

      • docker-compose exec app bundle exec rails console

      No prompt, inspecione o registro do last [último] do Tubarão no banco de dados:

      Você verá o registro que acabou de criar:

      IRB session

      Shark Load (1.0ms) SELECT "sharks".* FROM "sharks" ORDER BY "sharks"."id" DESC LIMIT $1 [["LIMIT", 1]] => "#<Shark id: 5, name: "Mako", facts: "Fast", created_at: "2019-12-20 14:03:28", updated_at: "2019-12-20 14:03:28">"

      Depois, você poderá verificar se os seus tubarões Endangered permaneceram, usando o seguinte comando:

      IRB session

      (0.8ms) SELECT COUNT(*) FROM "endangereds" => 73

      Seu volume db_data foi montado com sucesso no serviço database recriado, possibilitando que seu serviço app acesse os dados salvos. Se navegar diretamente até a página index shark – visitando o localhost:3000/sharks ou http://your_server_ip:3000/sharks, você também verá aquele registro sendo exibido:

      Página de índice de tubarões com o Mako

      Seus tubarões em perigo também estarão em exibição em localhost:3000/endangered/data ou http://your_server_ip:3000/endangered/data:

      Atualizar tabela

      Seu aplicativo agora está funcionando em contêineres do Docker com persistência de dados e sincronização de código habilitados. Você pode seguir em frente e testar as alterações do código local no seu host, as quais serão sincronizadas com o seu contêiner, graças à montagem bind que definimos como parte do serviço do app.

      Conclusão

      Ao seguir este tutorial, você criou uma configuração de desenvolvimento para o seu aplicativo Rails, usando os contêineres do Docker. Você tornou seu projeto mais modular e portátil, extraindo informações confidenciais e desassociando o estado do seu aplicativo do seu código. Você também configurou um arquivo clichê docker-compose.yml que pode revisar conforme suas necessidades de desenvolvimento e exigências mudem.

      Conforme for desenvolvendo, você pode se interessar em aprender mais sobre a concepção de aplicativos para fluxos de trabalho em contêiner e Cloud Native. Consulte o artigo Arquitetando aplicativos para o Kubernetes e Modernizando aplicativos para o Kubernetes para obter mais informações sobre esses tópicos. Ou, caso queira investir em uma sequência de aprendizagem do Kubernetes, veja o artigo sobre o Kubernetes para obter o currículo dos desenvolvedores de pilha completa.

      Para aprender mais sobre o código do aplicativo em si, consulte os outros tutoriais nesta série:



      Source link

      Conteinerizando um aplicativo Laravel 6 para o desenvolvimento com o Docker Compose no Ubuntu 18.04


      Introdução

      Conteinerizar um aplicativo se refere ao processo de adaptar um aplicativo e seus componentes com a finalidade de conseguir executá-lo em ambientes leves, conhecidos como contêineres. Esses ambientes são isolados e descartáveis e podem ser aproveitados para o desenvolver, testar e implantar aplicativos para a produção.

      Neste guia, usaremos o Docker Compose para conteinerizar um aplicativo Laravel 6 para o desenvolvimento. Quando você tiver terminado, terá um aplicativo de demonstração Laravel funcionando em três contêineres de serviço separados:

      • Um serviço de app executando o PHP7.4-FPM;
      • Um serviço de db executando o MySQL 5.7;
      • Um serviço de nginx que usa o serviço app para analisar o código PHP antes de entregar o aplicativo Laravel para o usuário final.

      Para permitir um processo de desenvolvimento simplificado e facilitar a depuração do aplicativo, manteremos os arquivos do aplicativo em sincronia, usando volumes compartilhados. Também veremos como usar os comandos docker-compose exec para executar o Composer e o Artisan no contêiner do app.

      Pré-requisitos

      Passo 1 — Obtendo o aplicativo Demo

      Para começar, vamos buscar o aplicativo demo do Laravel do seu repositório do Github. Estamos interessados na ramificação do tutorial-01, que contém o aplicativo básico do Laravel que criamos no primeiro guia desta série.

      Para obter o código do aplicativo compatível com este tutorial, baixe a versão tutorial-1.0.1 para seu diretório home com:

      • cd ~
      • curl -L https://github.com/do-community/travellist-laravel-demo/archive/tutorial-1.0.1.zip -o travellist.zip

      Vamos precisar do comando unzip para descompactar o código do aplicativo. Caso não tenha instalado esse pacote antes, faça isso agora com:

      • sudo apt update
      • sudo apt install unzip

      Agora, descompacte os conteúdos do aplicativo e renomeie o diretório desempacotado para ter um acesso mais fácil:

      • unzip travellist.zip
      • mv travellist-laravel-demo-tutorial-1.0.1 travellist-demo

      Navegue até o diretório travellist-demo:

      No próximo passo, vamos criar um arquivo de configuração .env para configurar o aplicativo.

      Passo 2 — Configurando o arquivo .env do aplicativo

      Os arquivos de configuração do Laravel estão localizados em um diretório chamado config, dentro do diretório raiz do aplicativo. Além disso, um arquivo .env é usado para preparar a configuração dependente do ambiente, como credenciais e quaisquer informações que possam variar entre as implantações. Esse arquivo não está incluído no controle de revisão.

      Aviso: o arquivo de configuração de ambiente contém informações confidenciais sobre o seu servidor, incluindo credenciais para o banco de dados e chaves de segurança. Por esse motivo, nunca compartilhe esse arquivo publicamente.

      Os valores contidos no arquivo .env terão precedência sobre os valores definidos nos arquivos de configuração regulares, localizados no diretório config. Cada instalação em novo ambiente exige um arquivo de ambiente personalizado para definir coisas como as configurações da conexão com o banco de dados, as opções de depuração, a URL do aplicativo, entre outros itens que possam variar, dependendo do ambiente em que o aplicativo esteja funcionando.

      Agora, vamos criar um novo arquivo .env para personalizar as opções de configuração do ambiente de desenvolvimento que estamos preparando. O Laravel vem com um exemplo de arquivo do .env que podemos copiar para criar o nosso:

      Abra este arquivo usando o nano ou outro editor de texto de sua escolha:

      O arquivo .env atual do aplicativo demo travellist contém as configurações para usar um banco de dados local do MySQL, com o 127.0.0.1 como o host do banco de dados. Precisamos atualizar a variável DB_HOST para que ela aponte para o serviço de banco de dados que vamos criar em nosso ambiente do Docker. Neste guia, vamos chamar nosso serviço de banco de dados de db. Vá em frente e substitua o valor listado de DB_HOST pelo nome do serviço de banco de dados:

      .env

      APP_NAME=Travellist
      APP_ENV=dev
      APP_KEY=
      APP_DEBUG=true
      APP_URL=http://localhost:8000
      
      LOG_CHANNEL=stack
      
      DB_CONNECTION=mysql
      DB_HOST=db
      DB_PORT=3306
      DB_DATABASE=travellist
      DB_USERNAME=travellist_user
      DB_PASSWORD=password
      ...
      

      Caso queira, sinta-se à vontade para alterar o nome do bando de dados, nome de usuário e senha. Essas variáveis serão aproveitadas em um próximo passo, onde iremos definir o arquivo docker-compose.yml para configurar nossos serviços.

      Salve o arquivo quando terminar de editar. Se você usou o nano, você pode fazer isso pressionando Ctrl+x, depois Y e Enter para confirmar.

      Passo 3 — Configurando o Dockerfile do aplicativo

      Embora ambos os nossos serviços do MySQL e do Nginx se baseiem em imagens padronizadas, obtidas a partir do Docker Hub,ainda precisaremos compilar uma imagem personalizada para o contêiner do aplicativo. Criaremos um novo Dockerfile para isso.

      Nossa imagem do travellist irá basear-se na imagem oficial do PHP, php:7.4-fpm​​​ do Docker Hub. Além desse ambiente básico do PHP-FPM, instalaremos alguns módulos adicionais do PHP e a ferramenta de gerenciamento de dependência do Composer.

      Também iremos criar um novo usuário do sistema; isso é necessário para executar comandos do artisan e do composer durante o desenvolvimento do aplicativo. A configuração do uid garante que o usuário dentro do contêiner tenha o mesmo uid que o usuário do sistema no seu computador host, onde você estiver executando o Docker. Dessa forma, quaisquer arquivos criados por esses comandos são replicados no host com as permissões corretas. Isso também significa que você poderá usar o editor de códigos de sua escolha no computador host para desenvolver o aplicativo que está executando dentro dos contêineres.

      Crie um novo Dockerfile com:

      Copie o seguinte conteúdo para o seu Dockerfile:

      Dockerfile

      FROM php:7.4-fpm
      
      # Arguments defined in docker-compose.yml
      ARG user
      ARG uid
      
      # Install system dependencies
      RUN apt-get update && apt-get install -y 
          git 
          curl 
          libpng-dev 
          libonig-dev 
          libxml2-dev 
          zip 
          unzip
      
      # Clear cache
      RUN apt-get clean && rm -rf /var/lib/apt/lists/*
      
      # Install PHP extensions
      RUN docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd
      
      # Get latest Composer
      COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
      
      # Create system user to run Composer and Artisan Commands
      RUN useradd -G www-data,root -u $uid -d /home/$user $user
      RUN mkdir -p /home/$user/.composer && 
          chown -R $user:$user /home/$user
      
      # Set working directory
      WORKDIR /var/www
      
      USER $user
      
      

      Não se esqueça de salvar o arquivo quando terminar.

      Nosso Dockerfile começa pela definição da imagem base que estamos usando: php:7.4-fpm.

      Após instalar os pacotes do sistema e as extensões do PHP, instalaremos o Composer, copiando o executáve composer de sua última imagem oficial para nossa imagem do aplicativo.

      Então, um novo usuário do sistema é criado e configurado usando os argumentos user e uid que foram declarados no início do Dockerfile. Esses valores serão injetados pelo Docker Compose no momento da compilação.

      Por fim, definimos o dir padrão em funcionamento como /var/www e trocamos para o usuário recém-criado. Isso garantirá que, ao executar os comandos do composer e do artisan no contêiner do aplicativo, você esteja se conectando como um usuário comum e que esteja no diretório correto.

      Passo 4 — Configurando os arquivos de configuração do Nginx e os arquivos de despejo do banco de dados

      Ao criar ambientes de desenvolvimento com o Docker Compose, com frequência, é necessário compartilhar os arquivos de configuração ou de inicialização com os contêineres de serviço, para assim configurar ou inicializar esses serviços. Essa prática facilita fazer alterações nos arquivos de configuração para ajustar seu ambiente enquanto estiver desenvolvendo o aplicativo.

      Agora, vamos definir uma pasta com os arquivos que serão usados para configurar e inicializar nossos contêineres de serviço.

      Para configurar o Nginx, compartilharemos um arquivo travellist.conf que configurará como o aplicativo será atendido. Crie a pasta docker-compose/nginx com:

      • mkdir -p docker-compose/nginx

      Abra um novo arquivo chamado de travellist.conf dentro desse diretório:

      • nano docker-compose/nginx/travellist.conf

      Copie a seguinte configuração do Nginx para aquele arquivo:

      docker-compose/nginx/travellist.conf

      
      server {
          listen 80;
          index index.php index.html;
          error_log  /var/log/nginx/error.log;
          access_log /var/log/nginx/access.log;
          root /var/www/public;
          location ~ .php$ {
              try_files $uri =404;
              fastcgi_split_path_info ^(.+.php)(/.+)$;
              fastcgi_pass app:9000;
              fastcgi_index index.php;
              include fastcgi_params;
              fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
              fastcgi_param PATH_INFO $fastcgi_path_info;
          }
          location / {
              try_files $uri $uri/ /index.php?$query_string;
              gzip_static on;
          }
      }
      

      Esse arquivo irá configurar o Nginx para escutar na porta 80 e usar o index.php como a página de índice padrão. Ele definirá o diretório base como /var/www/public e, em seguida, configurará o Nginx para usar o serviço app na porta 9000 para processar os arquivos *.php.

      Salve e feche o arquivo quando terminar de editar.

      Para configurar o banco de dados do MySQL, compartilharemos um banco de dados de despejo que será importado quando o contêiner for inicializado. Esta é uma característica fornecida pela imagem do MySQL 5.7, que usaremos naquele contêiner.

      Crie uma nova pasta para seus arquivos de inicialização do MySQL dentro da pasta docker-compose:

      • mkdir docker-compose/mysql

      Abra um novo arquivo .sql:

      • nano docker-compose/mysql/init_db.sql

      O arquivo de despejo do MySQL se baseia no banco de dados que configuramos em nosso guia do Laravel em LEMP. Ele criará uma nova tabela chamada places. Então, ele preencherá a tabela com um conjunto de exemplos de localidade.

      Adicione o código a seguir ao arquivo:

      docker-compose/mysql/db_init.sql

      DROP TABLE IF EXISTS `places`;
      
      CREATE TABLE `places` (
        `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
        `name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
        `visited` tinyint(1) NOT NULL DEFAULT '0',
        PRIMARY KEY (`id`)
      ) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
      
      INSERT INTO `places` (name, visited) VALUES ('Berlin',0),('Budapest',0),('Cincinnati',1),('Denver',0),('Helsinki',0),('Lisbon',0),('Moscow',1),('Nairobi',0),('Oslo',1),('Rio',0),('Tokyo',0);
      

      A tabela places contém três campos: id, name e visited. O campo visited é um sinalizador utilizado para identificar os lugares que ainda não foram visitados. Sinta-se à vontade para modificar os exemplos de localidade ou incluir novos locais. Salve e feche o arquivo quando terminar.

      Terminamos de configurar o Dockerfile do aplicativo e os arquivos de configuração de serviço. Em seguida, configuraremos o Docker Compose para usar esses arquivos ao criar nossos serviços.

      O Docker Compose permite a criação de ambientes multicontêiner para os aplicativos em execução no Docker. Ele usa as definições de serviço para compilar ambientes totalmente personalizáveis com vários contêineres que podem compartilhar redes e volumes de dados. Isso permite uma integração perfeita entre os componentes do aplicativo.

      Para configurar nossas definições de serviço, criaremos um novo arquivo chamado docker-compose.yml. Este arquivo fica normalmente localizado na raiz da pasta do aplicativo. Ele define seu ambiente em contêiner, incluindo as imagens base que você usará para compilar seus contêineres e como seus serviços irão interagir.

      Vamos definir três serviços diferentes em nosso arquivo docker-compose.yml: app, db e nginx.

      O serviço app compilará uma imagem chamada travellist, com base no Dockerfile que criamos anteriormente. O contêiner definido por esse serviço executará um servidor php-fpm para analisar o código PHP e enviará os resultados de volta para o serviço do nginx, o qual estará em execução em um contêiner separado. O serviço mysql define um contêiner que executa um servidor do MySQL 5.7. Nosso serviços irão compartilhar uma conexão de rede de ponte chamada de travellist.

      Os arquivos do aplicativo serão sincronizados nos serviços do app e do nginx através de montagens associadas. As montagens bind são úteis em ambientes de desenvolvimento porque elas levam em conta um desempenho sincronizado bidirecional entre o computador host e os contêineres.

      Crie um novo arquivo docker-compose.yml na raiz da pasta do aplicativo:

      Um arquivo típico do docker-compose.yml começa com uma definição de versão, seguido de um nó de services, sob o qual todos os serviços são definidos. As redes compartilhadas são geralmente definidas no final desse arquivo.

      Para começar, copie este código boilerplate para o seu arquivo docker-compose.yml:

      docker-compose.yml

      version: "3.7"
      services:
      
      
      networks:
        travellist:
          driver: bridge
      

      Agora, vamos editar o nó de services para incluir os serviços app, db e nginx.

      O serviço app

      O serviço app configurará um contêiner chamado travellist-app. Ele compila uma nova imagem do Docker com base em um Dockerfile - localizado no mesmo caminho que o arquivo docker-compose.yml. A nova imagem será salva localmente sob o nome travellist.

      Embora o diretório base que está sendo atendido como o aplicativo esteja localizado no contêiner do nginx, também precisamos dos arquivos do aplicativo em algum lugar dentro do contêiner de app, para que possamos executar tarefas de linha de comando com a ferramenta Laravel Artisan.

      Copie a seguinte definição de serviço sob seu nó de services, dentro do arquivo docker-compose.yml:

      docker-compose.yml

        app:
          build:
            args:
              user: sammy
              uid: 1000
            context: ./
            dockerfile: Dockerfile
          image: travellist
          container_name: travellist-app
          restart: unless-stopped
          working_dir: /var/www/
          volumes:
            - ./:/var/www
          networks:
            - travellist
      

      Essas configurações fazem o seguinte:

      • build: esta configuração diz ao Docker Compose para compilar uma imagem local para o serviço app, usando o caminho especificado (contexto) e o Dockerfile para obter instruções. Os argumentos user e uid são injetados no Dockerfile para personalizar os comandos de criação de usuário no momento da compilação.
      • image: o nome que será usado para a imagem que está sendo criada.
      • container_name: define o nome do contêiner desse serviço.
      • restart: sempre reinicia, a menos que o serviço seja interrompido.
      • working_dir: define o diretório padrão para esse serviço como /var/www.
      • volumes: cria um volume compartilhado que sincronizará o conteúdo do diretório atual para o /var/www, dentro do contêiner. Note que esse não é o seu diretório raiz, uma vez que ele ficará no contêiner nginx.
      • networks: define esse serviço para usar uma rede chamada travellist.

      O serviço db

      O serviço db usa uma imagem de MySQL 5.7 pré-compilada do Docker Hub. Como o Docker Compose carrega automaticamente os arquivos da variável .env, localizados no mesmo diretório que o arquivo docker-compose.yml, podemos obter nossas configurações de banco de dados do arquivo .env do Laravel que criamos em um passo anterior.

      Inclua a seguinte definição de serviço no nó de seus services, logo após o serviço app:

      docker-compose.yml

        db:
          image: mysql:5.7
          container_name: travellist-db
          restart: unless-stopped
          environment:
            MYSQL_DATABASE: ${DB_DATABASE}
            MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
            MYSQL_PASSWORD: ${DB_PASSWORD}
            MYSQL_USER: ${DB_USERNAME}
            SERVICE_TAGS: dev
            SERVICE_NAME: mysql
          volumes:
            - ./docker-compose/mysql:/docker-entrypoint-initdb.d
          networks:
            - travellist
      

      Essas configurações fazem o seguinte:

      • image: define a imagem do Docker que deve ser usada para este contêiner. Neste caso, estamos usando uma imagem MySQL 5.7 do Docker Hub.
      • container_name: define o nome do contêiner para este serviço: travellist-db​​​.
      • restart: sempre reinicia este serviço, a menos que ele seja explicitamente interrompido.
      • environment: define as variáveis de ambiente no novo contêiner. Estamos usando valores obtidos a partir do arquivo .env do Laravel para configurar nosso serviço do MySQL, o qual irá criar - automaticamente - um novo banco de dados e um usuário, com base nas variáveis de ambiente fornecidas.
      • volumes: cria um volume para compartilhar um arquivo de despejo de banco de dados .sql que será usado para inicializar o banco de dados do aplicativo. A imagem do MySQL importará automaticamente os arquivos .sql colocados no diretório /docker-entrypoint-initdb.d dentro do contêiner.
      • networks: define esse serviço para usar uma rede chamada travellist.

      O serviço nginx

      O serviço nginx usa uma imagem do Nginx pré-compilada sobre o Alpine, uma distribuição de Linux leve. Ela cria um contêiner chamado travellist-nginx e usa a definição de ports para criar um redirecionamento da porta 8000 - no sistema host - para a porta 80 - dentro do contêiner.

      Inclua a seguinte definição de serviço no nó de seus services, logo após o serviço db:

      docker-compose.yml

        nginx:
          image: nginx:1.17-alpine
          container_name: travellist-nginx
          restart: unless-stopped
          ports:
            - 8000:80
          volumes:
            - ./:/var/www
            - ./docker-compose/nginx:/etc/nginx/conf.d
          networks:
            - travellist
      

      Essas configurações fazem o seguinte:

      • image: define a imagem do Docker que deve ser usada para este contêiner. Neste caso, estamos usando a imagem do Alpine Nginx 1.17.
      • container_name: define o nome do contêiner para este serviço: travellist-nginx​​​.
      • restart: sempre reinicia este serviço, a menos que ele seja explicitamente interrompido.
      • ports: define um redirecionamento de porta que permitirá o acesso externo através da porta 8000 para o servidor Web em execução na porta 80, dentro do contêiner.
      • volumes: cria dois volumes compartilhados. O primeiro sincronizará o conteúdo do diretório atual para o /var/www, dentro do contêiner. Dessa forma, quando fizer alterações locais nos arquivos do aplicativo, elas serão refletidas rapidamente no aplicativo que está sendo atendido pelo Nginx, dentro do contêiner. O segundo volume garantirá que o nosso arquivo de configuração do Nginx, localizado em docker-compose/nginx/travellist.conf, seja copiado para a pasta de configuração do Nginx do contêiner.
      • networks: define esse serviço para usar uma rede chamada travellist.

      Arquivo docker-compose.yml finalizado

      Nosso arquivo docker-compose.yml finalizado ficará com esta aparência:

      docker-compose.yml

      version: "3.7"
      services:
        app:
          build:
            args:
              user: sammy
              uid: 1000
            context: ./
            dockerfile: Dockerfile
          image: travellist
          container_name: travellist-app
          restart: unless-stopped
          working_dir: /var/www/
          volumes:
            - ./:/var/www
          networks:
            - travellist
      
        db:
          image: mysql:5.7
          container_name: travellist-db
          restart: unless-stopped
          environment:
            MYSQL_DATABASE: ${DB_DATABASE}
            MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
            MYSQL_PASSWORD: ${DB_PASSWORD}
            MYSQL_USER: ${DB_USERNAME}
            SERVICE_TAGS: dev
            SERVICE_NAME: mysql
          volumes:
            - ./docker-compose/mysql:/docker-entrypoint-initdb.d
          networks:
            - travellist
      
        nginx:
          image: nginx:alpine
          container_name: travellist-nginx
          restart: unless-stopped
          ports:
            - 8000:80
          volumes:
            - ./:/var/www
            - ./docker-compose/nginx:/etc/nginx/conf.d/
          networks:
            - travellist
      
      networks:
        travellist:
          driver: bridge
      

      Certifique-se de salvar o arquivo quando terminar.

      Agora, usaremos os comandos do docker-compose para compilar a imagem do aplicativo e executar os serviços que especificamos em nossa configuração.

      Compile a imagem do app com o seguinte comando:

      Esse comando pode levar alguns minutos para completar. Você verá um resultado similar a este:

      Output

      Building app Step 1/11 : FROM php:7.4-fpm ---> fa37bd6db22a Step 2/11 : ARG user ---> Running in f71eb33b7459 Removing intermediate container f71eb33b7459 ---> 533c30216f34 Step 3/11 : ARG uid ---> Running in 60d2d2a84cda Removing intermediate container 60d2d2a84cda ---> 497fbf904605 Step 4/11 : RUN apt-get update && apt-get install -y git curl libpng-dev libonig-dev ... Step 7/11 : COPY --from=composer:latest /usr/bin/composer /usr/bin/composer ---> e499f74896e3 Step 8/11 : RUN useradd -G www-data,root -u $uid -d /home/$user $user ---> Running in 232ef9c7dbd1 Removing intermediate container 232ef9c7dbd1 ---> 870fa3220ffa Step 9/11 : RUN mkdir -p /home/$user/.composer && chown -R $user:$user /home/$user ---> Running in 7ca8c0cb7f09 Removing intermediate container 7ca8c0cb7f09 ---> 3d2ef9519a8e Step 10/11 : WORKDIR /var/www ---> Running in 4a964f91edfa Removing intermediate container 4a964f91edfa ---> 00ada639da21 Step 11/11 : USER $user ---> Running in 9f8e874fede9 Removing intermediate container 9f8e874fede9 ---> fe176ff4702b Successfully built fe176ff4702b Successfully tagged travellist:latest

      Quando a compilação estiver concluída, você poderá executar o ambiente em segundo plano com:

      Output

      Creating travellist-db ... done Creating travellist-app ... done Creating travellist-nginx ... done

      Isso executará seus contêineres em segundo plano. Para exibir informações sobre o estado de seus serviços ativos, execute:

      Você verá um resultado como esse:

      Output

      Name Command State Ports ------------------------------------------------------------------------------- travellist-app docker-php-entrypoint php-fpm Up 9000/tcp travellist-db docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp travellist-nginx nginx -g daemon off; Up 0.0.0.0:8000->80/tcp

      Agora, seu ambiente está funcionando! Porém, ainda precisaremos executar alguns comandos para concluir a configuração do aplicativo. Você pode usar o comando docker-compose exec para executar comandos nos contêineres de serviço, como um ls -l para exibir informações detalhadas sobre os arquivos no diretório do aplicativo:

      • docker-compose exec app ls -l

      Output

      total 256 -rw-rw-r-- 1 sammy 1001 738 Jan 15 16:46 Dockerfile -rw-rw-r-- 1 sammy 1001 101 Jan 7 08:05 README.md drwxrwxr-x 6 sammy 1001 4096 Jan 7 08:05 app -rwxr-xr-x 1 sammy 1001 1686 Jan 7 08:05 artisan drwxrwxr-x 3 sammy 1001 4096 Jan 7 08:05 bootstrap -rw-rw-r-- 1 sammy 1001 1501 Jan 7 08:05 composer.json -rw-rw-r-- 1 sammy 1001 179071 Jan 7 08:05 composer.lock drwxrwxr-x 2 sammy 1001 4096 Jan 7 08:05 config drwxrwxr-x 5 sammy 1001 4096 Jan 7 08:05 database drwxrwxr-x 4 sammy 1001 4096 Jan 15 16:46 docker-compose -rw-rw-r-- 1 sammy 1001 1015 Jan 15 16:45 docker-compose.yml -rw-rw-r-- 1 sammy 1001 1013 Jan 7 08:05 package.json -rw-rw-r-- 1 sammy 1001 1405 Jan 7 08:05 phpunit.xml drwxrwxr-x 2 sammy 1001 4096 Jan 7 08:05 public -rw-rw-r-- 1 sammy 1001 273 Jan 7 08:05 readme.md drwxrwxr-x 6 sammy 1001 4096 Jan 7 08:05 resources drwxrwxr-x 2 sammy 1001 4096 Jan 7 08:05 routes -rw-rw-r-- 1 sammy 1001 563 Jan 7 08:05 server.php drwxrwxr-x 5 sammy 1001 4096 Jan 7 08:05 storage drwxrwxr-x 4 sammy 1001 4096 Jan 7 08:05 tests -rw-rw-r-- 1 sammy 1001 538 Jan 7 08:05 webpack.mix.js

      Agora, vamos executar o composer install para instalar as dependências do aplicativo:

      • docker-compose exec app composer install

      Você verá um resultado como esse:

      Output

      Loading composer repositories with package information Installing dependencies (including require-dev) from lock file Package operations: 85 installs, 0 updates, 0 removals - Installing doctrine/inflector (1.3.1): Downloading (100%) - Installing doctrine/lexer (1.2.0): Downloading (100%) - Installing dragonmantank/cron-expression (v2.3.0): Downloading (100%) - Installing erusev/parsedown (1.7.4): Downloading (100%) - Installing symfony/polyfill-ctype (v1.13.1): Downloading (100%) - Installing phpoption/phpoption (1.7.2): Downloading (100%) - Installing vlucas/phpdotenv (v3.6.0): Downloading (100%) - Installing symfony/css-selector (v5.0.2): Downloading (100%) … Generating optimized autoload files > IlluminateFoundationComposerScripts::postAutoloadDump > @php artisan package:discover --ansi Discovered Package: facade/ignition Discovered Package: fideloper/proxy Discovered Package: laravel/tinker Discovered Package: nesbot/carbon Discovered Package: nunomaduro/collision Package manifest generated successfully.

      A última coisa que precisamos fazer - antes de testar o aplicativo - é gerar uma chave única para o aplicativo com a artisan, a ferramenta de linha de comando do Laravel. Esta chave é usada para criptografar sessões de usuário e outros dados confidenciais:

      • docker-compose exec app php artisan key:generate

      Output

      Application key set successfully.

      Agora, vá até seu navegador e acesse o nome de domínio ou endereço IP do seu servidor na porta 8000:

      http://server_domain_or_IP:8000
      

      Você verá uma página como esta:

      Demo do aplicativo Laravel

      Você pode usar o comando logs para verificar os registros gerados por seus serviços:

      • docker-compose logs nginx
      Attaching to travellist-nginx
      travellist-nginx | 192.168.160.1 - - [23/Jan/2020:13:57:25 +0000] "GET / HTTP/1.1" 200 626 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"
      travellist-nginx | 192.168.160.1 - - [23/Jan/2020:13:57:26 +0000] "GET /favicon.ico HTTP/1.1" 200 0 "http://localhost:8000/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"
      travellist-nginx | 192.168.160.1 - - [23/Jan/2020:13:57:42 +0000] "GET / HTTP/1.1" 200 626 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"
      …
      

      Se quiser pausar seu ambiente do Docker Compose ao mesmo tempo que mantém o estado de todos seus serviços, execute:

      Output

      Pausing travellist-db ... done Pausing travellist-nginx ... done Pausing travellist-app ... done

      Em seguida, você poderá retomar os seus serviços com:

      Output

      Unpausing travellist-app ... done Unpausing travellist-nginx ... done Unpausing travellist-db ... done

      Para fechar seu ambiente do Docker Compose e remover todos os seus contêineres, redes e volumes, execute:

      Output

      Stopping travellist-nginx ... done Stopping travellist-db ... done Stopping travellist-app ... done Removing travellist-nginx ... done Removing travellist-db ... done Removing travellist-app ... done Removing network travellist-laravel-demo_travellist

      Para obter um panorama de todos os comandos do Docker Compose, verifique a Referência da linha de comando do Docker Compose.

      Conclusão

      Neste guia, configuramos um ambiente do Docker com três contêineres, usando o Docker Compose para definir nossa infraestrutura em um arquivo YAML.

      A partir deste ponto, você poderá trabalhar no seu aplicativo do Laravel sem a necessidade de instalar e configurar um servidor Web local para desenvolvimentos e testes. Além disso, você estará trabalhando com um ambiente descartável e que pode ser facilmente replicado e distribuído, o que pode ser útil ao desenvolver seu aplicativo e ao passar para um ambiente de produção.



      Source link