One place for hosting & domains

      desenvolvimento

      Como Instalar o Django e Configurar um Ambiente de Desenvolvimento no Ubuntu 20.04


      Introdução

      O Django é um framework web de código aberto, escrito em Python com seus princípios fundamentais sendo escalabilidade, reusabilidade e desenvolvimento rápido. Ele também é conhecido por sua consistência a nível de framework e pelo baixo acoplamento, permitindo que os componentes sejam independentes uns dos outros.

      Neste tutorial, vamos configurar um ambiente Django para fins de desenvolvimento em um servidor Ubuntu 20.04. Para um site ativo, você terá considerações adicionais, incluindo a conexão a um banco de dados, configuração de um nome de domínio e adição de camadas de segurança. Temos uma variedade de tutoriais de Django que podem ajudar você enquanto você cria sob nossa tag Django.

      Pré-requisitos

      Para completar este tutorial, você irá precisar de:

      Passo 1 — Instalando o Django

      Há várias maneiras de instalar o Django, usando o gerenciador de pacotes Python pip dentro de um ambiente virtual.

      Estando no diretório home do servidor, vamos criar o diretório que conterá nossa aplicação Django. Execute o seguinte comando para criar um diretório chamado django-apps, ou outro nome de sua escolha. Em seguida, vá até o diretório.

      • mkdir django-apps
      • cd django-apps

      Estando dentro do diretório django-apps, crie seu ambiente virtual. Vamos chamá-lo de generic env, mas você deve usar um nome que é significativo para você e seu projeto.

      Agora, ative o ambiente virtual com o seguinte comando:

      Você saberá que ele está ativado assim que o prefixo for alterado para (env), que será parecido com o seguinte, dependendo de qual diretório você está:

      Dentro do ambiente, instale o pacote Django usando o pip. A instalação do Django nos permite criar e executar aplicações Django.

      Uma vez instalado, verifique sua instalação do Django executando uma verificação de versão:

      Esta, ou algo parecido, será a saída resultante:

      Output

      3.0.6

      Com o Django instalado em seu servidor, podemos seguir em frente para criar um projeto de teste para garantir que tudo esteja funcionando corretamente. Criaremos uma aplicação web esqueleto.

      Passo 2 — Ajustando as Configurações de Firewall

      Se você seguiu nosso tutorial de configuração inicial do servidor ou tiver um firewall em execução em seu servidor, vamos precisar abrir a porta que vamos usar no firewall do nosso servidor. Para o firewall UFW, você pode abrir a porta com o seguinte comando:

      Se você estiver usando o Firewall da DigitalOcean, você pode selecionar HTTP das regras de entrada. Você pode ler mais sobre o Firewall da DigitalOcean e criar regras para ele modificando as regras de entrada.ou inbound rules

      Passo 3 — Iniciando o Projeto

      Agora, podemos gerar uma aplicação usando o django-admin, um utilitário de linha de comando para tarefas de administração em Python. Em seguida, podemos usar o comando startproject para criar a estrutura de diretórios do projeto para nosso site de teste.

      Estando no diretório django-apps, execute o seguinte comando:

      • django-admin startproject testsite

      Nota: executar o comando django-admin startproject <projectname> irá nomear tanto o diretório do projeto quanto o pacote de projeto como <projectname> e criar o projeto no diretório em que o comando foi executado. Se o parâmetro opcional <destination> for fornecido, o Django utilizará o diretório de destino fornecido como diretório do projeto e criará o manage.py e o pacote do projeto dentro dele.

      Agora podemos ver quais arquivos de projeto foram criados. Navegue até o diretório testsite , em seguida liste o conteúdo desse diretório para ver quais arquivos foram criados:

      Output

      manage.py testsite

      Você notará a saída que mostra que este diretório contém um arquivo chamado manage.py e uma pasta chamada testsite. O arquivo manage.py é similar ao django-admin e coloca o pacote do projeto no sys.path. Ele também define a variável de ambiente DJANGO_SETTINGS_MODULE para apontar para o arquivo settings.py do seu projeto.

      Você pode ver o script manage.py em seu terminal executando o comando less dessa forma:

      Quando você terminar de ler o script, pressione q para parar de visualizar o arquivo.

      Agora, vá até o diretório testsite para visualizar os outros arquivos que foram criados:

      Em seguida, execute o seguinte comando para listar o conteúdo do diretório:

      Você verá quatro arquivos:

      Output

      __init__.py asgi.py settings.py urls.py wsgi.py

      Vamos analisar o que são esses arquivos:

      • __init__.py atua como o entry point para seu projeto Python.
      • O asgi.py contém a configuração para o deployment opcional na Interface de Gateway de Servidor Assíncrono ou ASGI, que fornece um padrão para aplicativos que são síncronos e assíncronos, e é considerado como um sucessor do WSGI (veja abaixo).
      • settings.py descreve a configuração de sua instalação do Django e permite que o Django saiba quais configurações estão disponíveis.
      • urls.py contém uma lista de urlpatterns, que roteia e mapeia URLs para suas views
      • wsgi.py contém a configuração para a Interface de Gateway do Servidor Web ou WSGI, que fornece um padrão para aplicativos Python síncronos.

      Nota: embora os arquivos padrão sejam gerados, você ainda tem a capacidade de ajustar os arquivos asgi.py ou wsgi.py, a qualquer momento para os adequar às necessidades da implantação.

      Passo 4 — Configurando o Django

      Agora, podemos iniciar o servidor e visualizar o site em um host e porta designados executando o comando runserver.

      Vamos precisar adicionar o endereço IP do seu servidor à lista ALLOWED_HOSTS no arquivo settings.py, localizado em ~/test_django_app/testsite/testsite/.

      Como indicado em Django docs, a variável ALLOWED_HOSTS contém “uma lista de strings representando os nomes de host/domínio que este site de Django pode servir. Esta é uma medida de segurança para evitar ataques de cabeçalhos de Host HTTP, que são possíveis mesmo em muitas configurações de servidor web aparentemente seguras.

      Você pode usar seu editor de texto favorito para adicionar seu endereço IP. Por exemplo, se você estiver usando o nano, execute o seguinte comando:

      • nano ~/django-apps/testsite/testsite/settings.py

      Assim que executar o comando, você irá querer acessar a seção Allowed Hosts do documento e adicionar o endereço IP do seu servidor dentro de colchetes entre aspas simples ou duplas.

      settings.py

      """
      Django settings for testsite project.
      
      Generated by 'django-admin startproject' using Django 2.0.
      ...
      """
      ...
      # SECURITY WARNING: don't run with debug turned on in production!
      DEBUG = True
      
      # Edit the line below with your server IP address
      ALLOWED_HOSTS = ['your-server-ip']
      ...
      

      Você pode salvar a alteração e sair do nano mantendo pressionadas as teclas CTRL + x e, em seguida, pressionando a tecla y. Em seguida, vamos seguir em frente para acessar nosso app web através de um navegador.

      Passo 5 — Acessando o App Web do Django

      Com nossa configuração concluída, certifique-se de voltar para o diretório onde o manage.py está localizado:

      • cd ~/django-apps/testsite/

      Agora, execute o seguinte comando substituindo o texto your-server-ip pelo IP do seu servidor:

      • python manage.py runserver 0.0.0.0:8000

      Por fim, você pode acessar o link abaixo para ver como seu site esqueleto se apresenta, substituindo novamente o texto destacado pelo IP real do seu servidor:

      http://your-server-ip:8000/
      

      Assim que a página carregar, você verá o seguinte:

      Django Default Page

      Isso confirma que o Django foi instalado corretamente e o projeto de teste está funcionando corretamente.

      Para acessar a interface de administração, adicione /admin/ ao final do seu URL:

      http://your_server_ip:8000/admin/
      

      Isso o levará a uma tela de login:

      Django admin login

      Se você digitar o nome de usuário e senha do admin que você acabou de criar, você terá acesso à seção de administração principal do site:

      Django admin page

      Para mais informações sobre como trabalhar com a interface de administração do Django, consulte “Como Habilitar e Conectar a Interface Admin do Django”.

      Quando você terminar de testar seu app, você pode pressionar CTRL + C para parar o comando runserver. Isso o retornará para seu ambiente de programação.

      Quando estiver pronto para deixar seu ambiente Python, você pode executar o comando deactivate:

      A desativação do seu ambiente de programação o levará de volta ao prompt de comando do terminal.

      Conclusão

      Neste tutorial, você instalou o Django com sucesso e configurou um ambiente de desenvolvimento para começar a trabalhar em seu app Django.

      Agora você tem a base necessária para começar a desenvolver aplicações Web no Django.



      Source link

      Como usar o Visual Studio Code para o desenvolvimento remoto por meio do plug-in Remote-SSH


      Introdução

      O Visual Studio Code é um Ambiente integrado de desenvolvimento (IDE) para desenvolvedores. Sua grande seleção de plug-ins, de design mínimo e suporte multiplataforma tornam-no uma ótima escolha para os desenvolvedores de todos os níveis. Este tutorial se concentra no uso do plug-in Remote-SSH para habilitar o desenvolvimento de softwares remotos. Com esse plug-in , você pode editar arquivos na sua estação de trabalho local, mas executar tarefas de desenvolvimento, como a execução do programa, testes de unidade ou análise estática, em um servidor remoto.

      Há muitas razões para que isso seja benéfico para você. Por exemplo, você pode ter uma estação de trabalho Windows e querer desenvolver no Windows, mas seu código acabará sendo executado no Linux. Você pode precisar de mais RAM ou poder de processamento do que sua máquina atual tem disponível, ou querer manter o código fora da sua máquina pessoal devido a uma política de empresa ou pela vontade de manter sua estação de trabalho inalterada.

      Neste tutorial, você irá habilitar o plug-in Remote-SSH, configurar o Visual Studio Code para executar o código no servidor remoto e executar o código de sua instalação local do Visual Studio Code no servidor remoto.

      Pré-requisitos

      Para acompanhar este guia, você vai precisar do seguinte:

      • Uma máquina local de desenvolvimento executando o Windows, MacOSX ou Linux. Este tutorial não funcionará nos dispositivos ChromeOS.
      • O Visual Studio Code, que pode ser baixado e instalado no site oficial.
      • Um par de chaves SSH gerado:
      • Um servidor Ubuntu 18.04 configurado conforme o Guia de configuração inicial do servidor Ubuntu 18.04, incluindo um usuário não raiz habilitado para o sudo e um firewall.

      Passo 1 — Instalando o plug-in Remote-SSH

      O Marketplace de extensões é o local onde pode você pode baixar extensões compatíveis e de terceiros para uma variedade de ferramentas e linguagens de programação diferentes. É aqui que você procurará pelo plug-in Remote-SSH e o instalará

      No lado esquerdo da IDE, há uma linha vertical de cinco ícones. O ícone mais abaixo, que se parece com quatro quadrados em uma caixa, estando o do topo direito descolando, é o ícone para o Marketplace de extensões:

      Localização do ícone do Marketplace de extensões

      Você também pode acessar essa seção pressionando Ctrl+Shift+X. Quando a página for aberta, você verá os plug-ins sugeridos para baixar e instalar.

      Assim que tiver o Marketplace de extensões aberto, digite Remote-SSH na barra de busca Search Extensions in Marketplace. Quando encontrar o plug-in, selecione-o e, em seguida, clique no botão verde Install para instalar a extensão.

      Procurando pelo plug-in Remote-SSH

      A extensão agora está instalada. Em seguida, você configurará a extensão para que você consiga conectar-se ao seu servidor.

      Passo 2 — Configurando o plug-in Remote-SSH e conectando-se ao seu servidor

      Agora que o plug-in está instalado, você pode configurá-lo para que se conecte a um servidor. Para fazer isso, serão necessárias as seguintes informações:

      • O IP ou nome do host do servidor.
      • O nome de usuário com o qual você se conectará.
      • A chave privada que você usará para autenticar seu usuário.

      Você usará essas informações para criar um arquivo de configuração SSH, que o Visual Studio Code pode usufruir para usar o SSH no servidor para sincronizar os arquivos e executar códigos em seu nome. Essa configuração será criada usando o Visual Studio Code.

      Agora que você tem o plug-in Remote-SSH instalado, verá uma pequena caixa verde no canto inferior esquerdo da interface do Visual Studio Code. Se você passar o ponteiro do mouse pela caixa, o pop-up dirá Open a remote window (Abrir uma janela remota). O botão se parece com um sinal “maior que” abaixo de um sinal “menor que” ><, como o da seguinte imagem:

      Botão de UI verde para abrir uma janela remota

      Clique no botão e uma caixa de diálogo aparece no centro superior. Selecione Remote-SSH: Open Configuration File… da lista:

      Selecionando configurar SSH na UI

      O próximo prompt perguntará qual arquivo de configuração você deseja abrir. Se estiver no Windows, verá duas localizações: uma no seu diretório de usuário pessoal e outra na localização de instalação para o SSH. Você deve utilizar o arquivo no seu diretório de usuário enquanto estiver configurando o servidor.

      Selecione o arquivo e seu editor abrirá o arquivo config. Adicione o código a seguir ao arquivo para definir a conexão com seu servidor, substituindo as seções destacadas pelas informações do seu servidor:

      config

      Host my_remote_server
          HostName your_server_ip_or_hostname
          User sammy
          IdentityFile /location/of/your/private/key
      

      Aqui está como este arquivo de configuração funciona:

      • Host: especifica um nome para seu host. Isso permite que você use como alternativa um nome curto ou uma abreviação, em vez do endereço IP completo ou nome do host ao se conectar ao servidor.
      • HostName: o nome real do host do servidor, que é um endereço IP ou um nome de domínio totalmente qualificado.
      • User: o usuário com o qual você deseja se conectar.
      • IdentityFile: o caminho para sua chave SSH privada. Em sistemas Mac e Linux, você encontrará isso em seu diretório base, em um diretório .ssh escondido, chamado normalmente de id_rsa. Se estiver no Windows, você terá especificado um local para salvar este arquivo quando o criou usando o putty-gen.

      Especifique os valores apropriados no seu arquivo e salve o arquivo.

      O Visual Studio Code está agora configurado e pronto para se conectar ao seu servidor. Clique no botão verde Open a remote window, no canto inferior esquerdo e selecione Remote-SSH: Connect to Host…

      Conectando-se ao servidor através do Visual Studio Code

      Assim que tiver feito isso, todos os servidores disponíveis e configurados aparecerão no menu suspenso. Selecione o servidor ao qual você deseja se conectar dessa lista.

      Se essa é a primeira vez que você se conecta a este servidor de sua máquina, provavelmente será exibido um diálogo de verificação do SSH Fingerprint, como a da seguinte imagem:

      Confirmando seu SSH Fingerprint

      Isso é para garantir que você esteja se conectando ao servidor correto. É possível verificar isso fazendo login manualmente e executando ssh-keygen -l -f /etc/ssh/ssh_host_key.pub para visualizar as impressões digitais do servidor. Se essa impressão for a mesma que aquela sendo apresentada a você no Visual Studio Code, então você de fato está se conectando ao servidor correto, logo, clique em Continue.

      Por padrão, o Visual Studio Code abre uma nova janela quando uma nova conexão é feita. Uma nova janela aparecerá com a tela de boas-vindas. Você saberá se sua conexão foi bem-sucedida caso veja SSH: your_ip_address_or_hostname na caixa verde no canto inferior esquerdo. Isso significa que o Visual Studio Code está conectado e se comunicando com seu servidor remoto.

      Conexão SSH bem-sucedida

      Agora que está conectado, execute comandos e códigos do seu editor.

      Passo 3 — Executando códigos no servidor remoto

      O plug-in Remote-SSH está configurado e é hora de executar algum código em sua máquina remota. Abra uma janela de terminal selecionando Terminal da barra de navegação no topo da janela do Visual Studio e clicando em New Terminal. Também é possível abrir um terminal pressionando CTRL+Shift+`. O terminal que é aberto é um terminal no seu servidor remoto, não um na sua máquina local.

      Quando o terminal abrir, emita o seguinte comando para visualizar o endereço IP do seu servidor para verificar se você está conectado ao seu servidor remoto:

      Você verá o seguinte resultado no seu terminal:

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 16:cb:05:5b:30:f1 brd ff:ff:ff:ff:ff:ff inet your_server_ip brd your_broadcast_address scope global eth0 valid_lft forever preferred_lft forever ...

      Para testar a capacidade de executar códigos remotos, crie um novo arquivo do Python chamado hello.py no seu editor. Quando estiver conectado ao seu servidor remoto, todos os arquivos criados através do Visual Studio Code serão salvos no servidor, não na sua máquina local.

      Adicione o conteúdo a seguir ao arquivo:

      hello.py

      print("Hello Sammy!")
      

      Para executar este programa no seu servidor, abra um terminal no Visual Studio Code por meio do menu de navegação ou pressionando a sequência de teclas CTRL+Shift+`. Como essa sessão de terminal está conectada ao seu servidor remoto, execute o seguinte comando no terminal para executar seu programa hello.py:

      O resultado do seu programa será exibido.

      Executando seu script em Python

      Também é possível executar o arquivo a partir do menu de contexto Debug, selecionando Run without Debugging.

      Nota: caso tenha qualquer extensão de desenvolvimento instalada no Visual Studio Code, como a extensão do Python, será necessário reinstalar essas extensões no seu servidor através do Marketplace de extensões. Caso já tenha instalado previamente esses plug-ins no Visual Studio Code, quando for procurar por eles novamente, o Marketplace dirá Install on SSH: hostname. Sempre tenha cuidado sobre qual o contexto de desenvolvimento em que você está, pois é aqui onde o Visual Studio Code instalará seus plug-ins e criará seus arquivos. Se tentar executar seu código sem esses plug-ins instalados, caixas de diálogo de erro aparecerão no canto inferior direito da tela, solicitando pela instalação deles no seu servidor remoto. Depois de instalá-los, eles provavelmente exigirão que você recarregue o Visual Studio Code. Quando você reiniciá-lo, ele continuará funcionando no servidor remoto, sem que você tenha que se reconectar manualmente.

      Conclusão

      Agora, você tem o Visual Studio Code configurado para o desenvolvimento em um servidor remoto usando o SSH. A execução remota com uma IDE traz muitos benefícios, incluindo a capacidade de testar rapidamente como seu código é executado em diferentes sistemas operacionais e diferentes especificações de hardware. Enquanto tiver uma conexão de Internet, você pode se conectar ao seu servidor e trabalhar em seu código de qualquer computador e será capaz de desenvolver usando um ambiente Linux, mesmo se estiver usando o Windows como seu sistema operacional primário.



      Source link

      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