
Deploy Rails: Suba seu APP para a Digital Ocean facilmente
Fala, galera! Hoje vamos apresentar um assunto que tem fervilhado de pedidos da galera: como fazer um Deploy Rails na Digital Ocean. E aqui utilizaremos um grande aliado: o Capistrano.
Então segue o passo a passo logo a baixo para deixar seu APP no ar (de forma automatizada) e não se esqueça de fazer o download do bônus no final desse artigo: [PDF] Checklist completo de deploy
Estrutura do tutorial \o/
- Conceitos importantes: Deploy
- O que é VPS
- O que é Deploy
- Porque automatizar
- Passo a passo do Deploy
- Projeto de exemplo
- Criando VPS
- Configurando o Postgres
- Instalando o Capistrano e Configurando o App
- Configurando o Capistrano para o Deploy
- Conceitos importantes: Capistrano
- Roles? Variáveis? Arquivos e Diretórios Linkados?
- Arquivos e Diretórios ‘Linkados’
- Roles
- Tudo é Task
- Roles? Variáveis? Arquivos e Diretórios Linkados?
- Executando o Deploy
- [PDF bônus] Checklist completo de deploy
Ferramentas
- Git
- Capistrano
- Ubuntu Server na Digital Ocean
- Rails 5.2
Conceitos importantes: Deploy
O que é VPS?
VPS significa Virtual Private Server, ou Servidor Virtual Privado. Nada mais é do que uma máquina virtual que compartilha, com outras máquinas virtuais, os recursos de uma máquina física como memória, processador, disco etc.
Esta máquina virtual é também um servidor dedicado, pois existe uma camada de virtualização que fica abaixo do Sistema Operacional.
Exemplos de empresas que fornecem VPS são Amazon, Google, Azure e outras menores como a Digital Ocean, Locaweb e Umbler (entre outras milhares).
O que é Deploy?
Deploy é simplesmente entregar um sistema para ser utilizado, seja num ambiente de testes ou produção, simples assim.
Por que automatizar?
Bem, no deploy de uma aplicação, nós seguimos uma sequência de passos para entregar o app em qualquer ambiente. Precisamos, por exemplo num app Rails, baixar o código, executar os migrations, restartar o app server e tudo mais que sua aplicação pode exigir.
Nós, seres humanos criadores (e falhos), não seguimos um script tão bem quanto uma máquina que foi programada pra fazer aquilo. E esse é o interessante de automatizar.
Conseguimos entregar um trabalho que requer um passo a passo às vezes minucioso (e por vezes até chato) para o computador fazer enquanto nos preocupamos em criar as soluções.

[PDF] Checklist completo de deploy o/
Para você não esquecer nenhum detalhe na hora de subir seu APP 😁
Passo a passo do Deploy Rails
Projeto de exemplo
Neste post vamos seguir passos bem curtos, desde a instalação das dependências, configurações de banco de dados e configurações iniciais do próprio Capistrano até o sucesso no deploy.
Nós vamos utilizar uma aplicação que construímos num post anterior: “ActiveStorage: Usando na prática a nova ferramenta de upload do Rails”.
Este app utiliza Rais 5.2 e sua nova ferramenta, o Active Storage. Nós informaremos nos passos que forem específicos para utilização do Active Storage para que você use somente se for necessário pra você. 🙂
Então partiu pra tela!
Servidor e Dependências do App
Vamos começar configurando nosso servidor do zero e instalar as dependências do nosso app.
1- Caso você não possua uma conta na Digital Ocean crie com este link e ganhe $50 em créditos
2 – Agora vamos criar o nosso Droplet (VPS):
a) No seu menu da Digital Ocean (logado) clique em “Create” e escolha droplets.
c) Escolha o tamanho:
d) Escolha uma região:
e) Defina uma chave ssh para se conectar ao seu VPS caso queira (ou deixe em branco para usar com senha como no exemplo)
f) Escolha um nome e mande criar \o/
g) Pronto, agora você vai receber no seu email o ip e senha da VPS criada.
3- Depois de criado, vamos logar no servidor com as credenciais do root.
1 |
ssh root@<ip do seu servidor> |
4- Agora vamos digitar a senha fornecida pela DO (que foi enviada para você por email)
5- No primeiro login, vai solicitar mudança de senha do usuário root. Escolha uma nova e confirme.
6- Vamos criar um novo usuário de aplicação chamado deploy:
1 |
adduser deploy |
7- Digite e confirme a senha deste novo usuário
8- Agora vamos adicionar este usuário no grupo root e admin
1 |
addgroup deploy root |
1 |
addgroup deploy admin |
9- Agora vamos acessar o arquivo Sudoers para poder dar permissão para o usuário deploy executar comandos com sudo sem senha. Vamos adicionar na ultima linha do arquivo sudoers (/etc/sudoers):
1 |
deploy ALL=(ALL) NOPASSWD: ALL |
10- Vamos deslogar do servidor como root e logar novamente com o usuário deploy
11- Feito isso, vamos começar a instalar as ferramentas que precisaremos utilizar
12- Vamos começar instalando o GIT
1 |
sudo apt-get install git |
13- Agora vamos instalar o NGINX (servidor)
1 |
sudo apt-get install nginx |
14- Vamos mudar o dono do diretório /var/www para deploy. Este é o diretório onde ficará nossa aplicação.
1 |
sudo chown deploy:deploy /var/www |
15- Agora é a vez o RVM. Para instalar, vamos executar o comando:
1 |
curl -sSL https://get.rvm.io | bash |
16- Seguindo as instruções de instalação do RVM, para que ele possa começar a ser utilizado, executaremos:
1 |
source /home/deploy/.rvm/scripts/rvm |
17- Vamos aproveitar e instalar a versão 2.4.2 do Ruby, a mesma que está lockada no nosso Gemfile:
1 |
rvm install 2.4.2 --default |
18- Agora vamos instalar o Bundler
1 |
gem install bundle |
19- Vamos instalar o nodejs
1 |
sudo apt-get install nodejs |
20- Agora o Postgres
1 |
sudo apt-get install postgresql |
21- Agora vamos instalar uma dependência para a gem Postgresql (Banco de dados) que adicionaremos daqui a pouco:
1 |
sudo apt-get install libpq-dev |
22- Instalar o ImageMagick (dependência comum de gems do ruby para processar imagens):
1 |
sudo apt-get install imagemagick |
O passo a cima é obrigatório pra quem estiver utilizando o Rails 5.2 e o Active Storage
Configurando o Postgres
Após instalar o postgres, vamos criar um usuário para aplicação no banco de dados também. Mas para isso, primeiro precisamos acessar o banco de dados com o usuário postgres e criar este usuário.
Como acabamos de instalar o Postgres e não sabemos a senha, vamos seguir alguns passos para acessarmos o banco sem senha, alterarmos a senha do usuário postgres e depois logar com esta senha e criar nosso usuário da aplicação.
1- Vamos abrir o arquivo chamado pg_hba.conf do Postgres. Como instalamos a versão 9.5 no Postgres, que é a versão que está no repositório do Ubuntu, este arquivo está no caminho:
1 |
/etc/postgresql/9.5/main/pg_hba.conf |
2- Aberto o arquivo, vamos procurar a linha que contém o seguinte conteúdo:
1 2 |
# Database administrative login by Unix domain socket local all postgres peer |
3- Agora vamos substituir a palavra “peer” por “trust“, ficando deste jeito:
1 2 |
# Database administrative login by Unix domain socket local all postgres trust |
O que fizemos aqui foi setar uma configuração dizendo que é permitido logar localmente em todos os banco de dados com o usuário postgres sem senha.
4- Feito isso, vamos reiniciar o Postgres para que as configurações tenham efeito:
1 |
sudo service postgresql restart |
5- Agora vamos conectar no Postgres com o usuário postgres sem senha:
1 |
psql -U postgres |
6- Agora vamos executar um comando SQL para podemos configurar a senha do usuário postgres:
1 |
ALTER USER postgres WITH ENCRYPTED PASSWORD '<sua senha>'; |
Não esqueça de trocar <sua senha> pela sua senha 😉
7- Feito isso, vamos sair do Postgres e abrir novamente o arquivo pg_hba.conf (/etc/postgresql/9.5/main/pg_hba.conf)
8- Agora vamos substituir a linha abaixo que alteramos anteriormente:
1 2 |
# Database administrative login by Unix domain socket local all postgres trust |
Pelo seguinte conteúdo:
1 2 |
# Database administrative login by Unix domain socket local all postgres md5 |
Agora estamos reconfigurando o Postgres para que o login (com o usuário postgres ) seja feito com uma senha encriptada em MD5, por isso que ao alterarmos a senha, nós utilizamos “WITH ENCRYPTED PASSWORD”, para que a senha seja salva em MD5
9- Agora vamos reiniciar novamente o Postgres
1 |
sudo service postgresql restart |
10- Logar no Postgres com o usuário postgres digitando a senha que foi configurada anteriormente:
1 |
psql -U postgres -W |
11- Agora vamos criar um novo usuário no banco para a aplicação:
1 |
CREATE USER deploy WITH ENCRYPTED PASSWORD '<sua senha>'; |
12- Agora vamos conceder privilégios de super usuário para ele:
1 |
ALTER USER deploy WITH SUPERUSER; |
13- Por último, vamos criar o banco de dados do nosso app:
1 |
CREATE DATABASE awesome_bucket_production; |
Com o Postgres configurado e todas as nossas dependências instaladas, agora vamos instalar e configurar o Capistrano numa aplicação que já temos pronta e foi feita num Post anterior. Então, vamos para os próximos passos.
Instalando o Capistrano e Configurando o App
Nesta parte nós vamos configurar o Capistrano com o Plugin adicional para o Rails, Puma e RVM. Como exemplo, vamos pegar o código de um Post anterior que fizemos, adaptar para o Capistrano e depois subiremos num novo repositório.
Vamos utilizar o app que construímos no post “ActiveStorage: Usando na prática a nova ferramenta de upload do Rails”. O link do repositório é https://onebitcode.com/best-sites-for-dating/ (é só baixar)
Lembrando que o que faremos aqui não é exclusivo para esse sistema e pode ser utilizado em diversas outras aplicações.
Então partiu código 🙂
1- Como nosso projeto inicialmente estava com Sqlite3, primeiro vamos adicionar a gem do Postgres.
Vamos remover do nosso Gemfile:
1 |
gem 'sqlite3' |
E adicionar:
1 |
gem 'pg', '~> 0.18' |
2- Vamos executar o bundle
1 |
bundle install |
3- Após instalado a gem pg, nós não vamos configurar o database.yml e isso graças ao Capistrano. Mas daqui há pouco vamos ver 😉
4- Agora vamos adicionar no nosso Gemfile as gems que utilizaremos para o Capistrano. Lembre-se de adicionar no grupo :development do Gemfile, afinal só precisamos do Capistrano no ambiente de dev:
1 2 3 4 |
gem "capistrano", "~> 3.10", require: false gem "capistrano-rails", "~> 1.3", require: false gem 'capistrano3-puma', require: false gem 'capistrano-rvm', require: false |
Adicionamos um require: false nas gems para que elas não sejam carregadas na aplicação. O Capistrano funcionará fora do contexto da aplicação.
5- Executar o bundle:
1 |
bundle install |
6- Com a gem instalada, vamos instalar o capistrano no nosso projeto apenas para produção:
1 |
cap install STAGES=production |
Por padrão, o Capistrano traz arquivos de configuração para staging e production, mas com este parâmetro STAGES no comando cap install nós podemos escolher que arquivos de configuração vamos querer. Como o nosso foco neste post é produção, criei um apenas para production.
Com este comando que executamos, foram criados os arquivos:
• Capify que é responsável pela importação dos plugins para o Capistrano;
• um arquivo config/deploy.rb que é utilizada para adicionar as configurações de deploy que serão válidas para todos os ambinentes;
• e o arquivo config/deploy/production.rb que é onde colocaremos as configurações de deploy exclusivas para produção.
Se fôssemos usar mais ambientes, mais um arquivo para cada ambiente seria criado dentro do diretório config/deploy.
7- Como adicionamos a gem pg e precisaremos dela no repositório, não podemos esquecer de comitar e subir a branch master.
8 – Crie um novo repositório no github e suba o seu projeto atualizado 🙂
Configurando o Capistrano para o Deploy
Com o Capistrano instalado e inicializado, agora podemos fazer as configurações para o Deploy Rails.
1- Vamos abrir o arquivo Capfile e adicionar e instalar os plugins. O nosso arquivo Capfile ficará desse jeito:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
require "capistrano/setup" require "capistrano/deploy" require "capistrano/scm/git" require 'capistrano/rails' require 'capistrano/rvm' require 'capistrano/puma' install_plugin Capistrano::SCM::Git install_plugin Capistrano::Puma install_plugin Capistrano::Puma::Workers install_plugin Capistrano::Puma::Nginx Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r } |
O que fizemos neste arquivo foi adicionar os requires dos plugins para o Capistrano do Rails, RMV e Puma. E depois instalamos 3 recursos do plugin do Puma: o suporte para o Puma, seus Workers e o Nginx.
2- Agora vamos adicionar algumas configurações globais para os nossos deploys, começando pelo nome da aplicação e o link do repositório (config/deploy.rb):
O capistrano já vem com alguns valores padrão, então onde estiver:
1 2 |
set :application, "my_app_name" set :repo_url, "git@example.com:me/my_repo.git" |
Vamos substituir por:
1 2 |
set :application, "<seu app>" set :repo_url, "<url do git do seu app>" |
No Capistrano, utilizamos a função set para pode inserir um valor numa variável do próprio Capistrano.
3- Ainda no arquivo deploy.rb, vamos adicionar mais estas linhas e explicar o que significam (config/deploy.rb):
1 2 3 4 5 6 7 |
set :deploy_to, "/var/www/awesome_bucket" append :linked_files, "config/database.yml", "config/storage.yml", "config/master.key" append :linked_dirs, "log", "tmp" set :keep_releases, 5 set :migration_role, :app |
No Capistrano, utilizamos a função append para podermos adicionar um valor numa variável do Capistrano que seja do tipo Array. Se quisermos sobrescrever o valor desse array, podemos usar o set.
Na linha com deploy_to estamos configurando o caminho que ficará o nosso app no servidor. Na liked_files e linked_dirs, estamos configurando os diretórios e arquivos que serão linkados na nossa aplicação. No keep_releases é a quantidade de versões do app que será armazenada no servidor. E no migration_role, que é específico para o Capistrano-Rails, estamos informando com que role o Capistrano vai executar as migrations do banco de dados.
Se você estiver utilizando o arquivo de secrets.yml que vem em versões anteriores ao Rails 5.2, adicione-o no linked_files no lugar do master.key e remova o storage.yml caso não esteja utilizando o ActiveStorage.
Mais pra frente vamos explicar o que é uma Role e o que significa aqueles linked_files e linked_dirs no Capistrano.
4- Agora adicionaremos alguns últimos itens ainda no nosso arquivo deploy.rb (config/deploy.rb):
1 2 3 4 5 6 7 8 9 |
set :puma_pid, "#{shared_path}/tmp/pids/puma.pid" set :puma_bind, "unix://#{shared_path}/tmp/sockets/puma.sock" set :puma_access_log, "#{shared_path}/log/puma_access.log" set :puma_error_log, "#{shared_path}/log/puma_error.log" set :nginx_sites_available_path, "/etc/nginx/sites-available" set :nginx_sites_enabled_path, "/etc/nginx/sites-enabled" set :rvm_ruby_version, '2.4.2' |
Adicionamos algumas configuração do plugin Capistrano-Puma. A variável shared_path é um padrão do Capistrano para mapear uma pasta onde podemos colocar os arquivos compartilhados ou que precisamos linkar com a aplicação (no próximo tópico vamos falar sobre isso). E na última linha, estamos utilizando uma configuração do Capistrano-RVM para informar a versão do Ruby que queremos usar. Repare que é a mesma versão que temos lockada no Gemfile.
5- Agora vamos adicionar as seguintes linhas no deploy.rb (config/deploy.rb)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
namespace :puma do desc 'Create Puma dirs' task :create_dirs do on roles(:app) do execute "mkdir #{shared_path}/tmp/sockets -p" execute "mkdir #{shared_path}/tmp/pids -p" end end desc "Restart Nginx" task :nginx_restart do on roles(:app) do execute "sudo service nginx restart" end end before :start, :create_dirs after :start, :nginx_restart end |
Criamos duas tasks customizadas: uma chamada puma:create_dirs e outra chamada puma:nginx_restart e fizemos a chamada delas no final.
As tasks são responsáveis por criar os diretórios tmp/pids e tmp/sockets e por enviar um comando para restart do Nginx.
6- Agora vamos ao arquivo de configuração específico para Produção adicionar as seguintes linhas (config/deploy/production.rb):
1 2 3 4 5 6 7 8 |
set :branch, 'master' set :server_address, '<endereço do seu servidor>' ask(:password, nil, echo: false) server fetch(:server_address), user: "deploy", roles: %w{app db web} set :nginx_server_name, fetch(:server_address) set :puma_preload_app, true |
Na primeira linha, estamos informando qual branch do Git o Capistrano deve usar para baixar nossa aplicação, no nosso caso é a master mas você pode configurar conforme o seu fluxo de desenvolvimento ou ambiente.
Na segunda linha, estamos configurando uma variável nossa com o endereço do servidor.
Na terceira linha, estamos utilizando a função ask do Capistrano, que abre um prompt para input do usuário durante a execução e o valor digitado é armazenado na variável password. No nosso caso estamos solicitando que o usuário digite a senha de acesso ao servidor, que utilizaremos na linha de baixo.
Na quarta linha, estamos configurando um servidor com o endereço, o usuário (nosso caso é o deploy), a senha e as roles desse servidor.
Na quinta linha, estamos informando um server_name que será utilizando pelo Nginx.
E na última linha, estamos configurando o Puma para pré-carregar o aplicativo para que ele não precise carregar toda vez que uma requisição chegar.
Para que possamos pegar o valor de uma variável do Capistrano, utilizamos a função fetch. Na linha que configuramos o servidor, por exemplo, estamos passando a senha que armazenamos na variável password.
Conceitos importantes: Capistrano
Roles? Variáveis? Arquivos e Diretórios Linkados?
Estes são três conceitos do Capistrano que as vezes podem confundir um pouco.
Bem, então vamos por partes (um olá para o Jack).
1. Variáveis
O Capistrano possui variáveis internas que são utilizadas durante a configuração do deploy.
Estas variáveis podem ser padrão, como a variável :branch, e podem ser variáveis que nós criamos, como a :server_address. Para acessar essas variáveis, o Capistrano possui algumas funções:
- set: atribui um valor a uma variável
- append: utilizada para acrescentar um valor numa variável do tipo Array
- fetch: resgata o valor de uma variável
- ask: é parecida com a set. Porém o valor atribuído vem de prompt com o usuário
2. Arquivos e Diretórios Linkados
O Capistrano possui duas variáveis padrão, a linked_files e a linked_dirs. Estas duas variáveis armazena os arquivos e os diretórios que queremos linkar com a nossa aplicação.
Ok, mas o que é isso? No momento do deploy, o Capistrano cria no diretório da nossa aplicação, umas pasta chamada releases e outra chamada shared. Na pasta releases ficam as versões do app e na shared ficam os arquivos e diretórios que queremos linkar com a nossa aplicação. Colocamos nesse diretório tudo que achamos que deve ser algo exclusivo do ambiente e que não pode ou não precisa ser comitado.
Por exemplo, podemos colocar um link com a pasta tmp e outro com o arquivo config/database.yml e no momento do deploy o Capistrano vai remover esses dois diretórios do app e adicionar um link com a pasta shared.
3. Roles
Este é um conceito que não veremos profundamente nesse post, mas é um conceito muito legal do Capistrano.
Uma Role no Capistrano é um grupo de servidores. Um servidor pode ter diversas roles e uma role pode ter diversos servidores. É um relacionamento N x N.
Anteriormente nós declaramos um server e nele colocamos roles: %w{app db web}. Podemos fazer o contrário também, declarar uma role e nela colocar uma lista de servers. E o interessante: não há um impedimento para um server estar em duas ou mais roles e vice-versa.
Este conceito é muito útil quando estamos lidando com deploy em diversos servidores diferentes e podemos fazer um agrupamento lógico e aplicar determinadas tarefas a roles específicas.
O Capistrano possui três roles padrão que são app, web e db. Como estamos lidando com apenas um servidor, nós declaramos estas três roles para um único server.
4. Tudo é Task
Tudo que é executado no Capistrano é uma sequencia de rake tasks que vai seguindo um fluxo padrão de deploy.
O fluxo padrão do Capistrano possui diversas fases bem divididas. Mais fases podem ser acrescentadas, assim como o plugin Capistrano-Puma o faz.
Assim como o Rails possui os before_action e after_action o Capistrano também possui um before e um after para que tasks customizadas sejam executadas entre uma fase e outra do fluxo de deploy, nos tornando capaz de agir sobre o fluxo padrão dele e customizar como precisarmos.
Executando o Deploy Rails
Com tudo configurado e alguns pontos esclarecidos, vamos agora voltar para o nosso deploy. Não se preocupe, falta pouco para completarmos a nossa jornada 😀
1- Para ver se falta algo que precisamos fazer, vamos executar o comando:
1 |
cap production deploy:check |
Este comando verifica se os arquivos e diretórios obrigatórios para rodar o Deploy estão lá. No nosso caso, estamos vendo para o deploy em produção (production).
2- Digite a senha
3- Olha o retorno que o Capistrano trouxe:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
00:00 git:wrapper 01 mkdir -p /tmp 01 deploy@xxx.xxx.xxx 0.812s Uploading /tmp/git-ssh-awesome_bucket-production-daniel.sh 100.0% 02 chmod 700 /tmp/git-ssh-awesome_bucket-production-daniel.sh 02 deploy@xxx.xxx.xxx 0.817s 00:03 git:check 01 git ls-remote git@github.com:OneBitCodeBlog/awesome_bucket_capistrano.git HEAD 01 63412e31efe5f42aaf007d787e260322d94cf95e HEAD 01 deploy@xxx.xxx.xxx 2.553s 00:06 deploy:check:directories 01 mkdir -p /var/www/awesome_bucket/shared /var/www/awesome_bucket/releases 01 deploy@xxx.xxx.xxx 0.779s 00:06 deploy:check:linked_dirs 01 mkdir -p /var/www/awesome_bucket/shared/log /var/www/awesome_bucket/shared/tmp /var/www/awesome_bucket/shared/public/assets 01 deploy@xxx.xxx.xxx 0.876s 00:07 deploy:check:make_linked_dirs 01 mkdir -p /var/www/awesome_bucket/shared/config 01 deploy@xxx.xxx.xxx 0.815s 00:09 deploy:check:linked_files ERROR linked file /var/www/awesome_bucket/shared/config/database.yml does not exist on 178.62.47.155 |
O Capistrano está nos informando que o arquivo que queremos criar, chamado database.yml na pasta shared/config ainda não existe. Pois bem, vamos criar os arquivos que serão linkados.
4- Vamos acessar o servidor com o usuário deploy e digitar a senha:
1 |
ssh deploy@<ip do droplet> |
5- Agora vamos até o diretório /var/www/awesome_bucket
1 |
cd /var/www/awesome_bucket |
6- Perceba que os diretórios releases e shared foram criados, como dissemos anteriormente. Basta digitar o comando:
1 |
ls |
7- Agora vamos criar database.ym, storage.yml e master.yml dentro no shared/config:
1 |
touch shared/config/database.yml |
1 |
touch shared/config/storage.yml |
1 |
touch shared/config/master.key |
Se você não estiver utilizando o ActiveStorage, não se preocupe com storage.yml.
Se estiver utilizando alguma versão do Rails anterior ao 5.2 que utilize o secrets.yml ou o arquivo pertinente à versão. Não se esqueça de criá-lo neste diretório e adicioná-lo ao linked_files.
8- Agora vamos acrescentar o conteúdo do database.yml:
1 2 3 4 5 6 7 |
production: adapter: postgresql encoding: unicode database: awesome_bucket_production pool: 5 username: deploy password: <sua senha> |
9- Agora acrescente o conteúdo de configuração do storage.yml e o master.key (Se você estiver em uma aplicação rails >= 5.2).
10- Se executarmos o check novamente, não teremos mais nenhum erro
1 |
cap production deploy:check |
11- Agora vamos executar as configurações do Puma:
1 |
cap production puma:config |
12- Agora as configurações do Nginx:
1 |
cap production puma:nginx_config |
13- E por fim, vamos executar o nosso deploy:
1 |
cap production deploy |
Com este último deploy, agora podemos verificar o endereço do servidor no navegador e ver que o deploy foi um sucesso! =D
[PDF] Checklist completo de deploy o/
Para você não esquecer nenhum detalhe na hora de subir seu APP 😁
Conclusão
Neste artigo nós realizamos o deploy completo na Digital Ocean com Rails + Nginx + Postgresql e automatizamos tudo isto com o Capistrano \o/
Siga o passo a passo adaptando às suas necessidades e se possível deixa aí em baixo nos comentários o link para a sua aplicação no ar, ficaremos felizes em ver tudo funcionando.
Não se esqueça de criar seu VPS usando esse https://onebitcode.com/dating-profile-pics/ para ganhar os $10 na Digital Ocean e de baixar o Checklist de deploy logo a cima, valeu \o/
Primeira vez no OneBitCode? Curtiu esse conteúdo?
O OneBitCode tem muito mais para você!
O OneBitCode traz conteúdos de qualidade, e em português, sobre programação com foco em Ruby on Rails e também JavaScript.
Além disso, aqui sempre levamos à você conteúdos valiosos sobre a carreira de programação, dicas sobre currículos, portfólios, perfil profissional, soft skills, enfim, tudo o que você precisa saber para continuar evoluindo como Programador(a)!
Fique por dentro de todos os conteúdos o/
Nossas redes sociais:
📹 • https://youtube.com/Onebitcode [Live todas as terças-feiras às 19h)
💻 • https://linkedin.com/company/onebitcode
🙂 • https://facebook.com/onebitcode
📱 • https://instagram.com/one_bit_code
🐦 • https://twitter.com/onebitcode
Nossos cursos:
🥇 • Programador Full Stack Javascript em 8 Semanas
💎 • Curso Completo de Ruby
⚙ • Minicurso: API Rails 5 Completo
🐞 • Minicurso de Testes para Ruby on Rails com RSpec
Espero que curta nossos conteúdos e sempre que precisar de ajuda, fala com a gente!
Estamos aqui para você 🙂
Bem-vindo à família OneBitCode o/
Show de bola essa postagem, ainda não a fiz por completo, mas como fiquei em duvida, estou aqui para perguntar. 🙂
Em um determinado servidor, observei que o mesmo tem varias aplicações em ruby on rails e todas elas estão sendo executadas ao mesmo tempo e na mesma porta (80). A diferença é no dominio (ex: app1.example.com, app2.example.com, app3.example.com), cada aplicação tem um dominio diferente! Existe alguma configuração especifica para ser feita, qual seria?
E ai cara, beleza?
Fico feliz que esteja acompanhando o tutorial, pega o final de semana pra terminar ele 🙂
Sobre essa configuração de domínio você pode ver mais aqui: http://do.co/2plOfqu
Abraço
Show de bola… Em pouco tempo consegui colocar a aplicação no ar!
Opa, que bom que deu certo Tiago 🙂
Você viu esse post pela comunidade ou google?
Abraço
Segui o tutorial certinho. Mas quando eu tento acessar a url, ele dá um erro 500.
Quando eu vou ver o log de erro do nginx, ele diz isso:
shared/tmp/sockets/puma.sock failed (2: No such file or directory) while connecting to upstream
Já sei o que está ocorrendo, mas ainda não sei como resolver. xD Acontece que eu organizei os meus shared files de forma diferente que o do tutorial. Ao invés de colocar o database e o secrets.yml, eu coloco um arquivo de configuração de ambiente. (Assim eu teria um por ambiente) e seto as varíaveis lá.
Logo, minha estrtura é essa:
var/www/app/enviroment/shared
ao invés devar/www/app/shared
. Quando eu fui olhar o arquivo de configuração que ele gera no meu ngnx, ele espera da segunda forma. estou vendo onde posso mudar isso. 🙂Opa, Gustavo.
Assim que encontrar uma solução, fala aqui com a gente.
Ou se precisar de um help, só chamar em alguma rede social ou Slack do Onebitcode que a gente pensa junto.
: )
Participa da nossa comunidade aqui -> https://onebitcodeslack.herokuapp.com/ e chama a gente lá se precisar de um help 🙂
Abraço
Fala galera, bem bacana o tutorial. Vai ajudar bastante gente. Acho que seria bacana complementar com um passo para desativar o login de root do servidor (premissa básica de segurança).
Também acho legal para configuração em produção mudar o Puma para o Passenger ou até mesmo para o Unicorn. Eu particularmente já tive problemas com o Puma, porém, isso vai de dev para dev.
Abração, continuem com o bom trabalho.
Valeu pela contribuição Francisco 🙂
Bom dia
Fiz o deploy de uma aplicação e funcionou corretamente. Mas em vez de ser um dominio, ele está em um subdominio (ex: http://www.site.com.br/app1).
Tentei fazer o deploy de uma segunda app, no mesmo servidor, com um outro subdominio, mas não consegui fazer funcionar. O deploy não mostra erro, entretanto ao acessar o app no navegador, ele não é encontrado.
Existe alguma configuração especial no nginx para o caso de mais de um app no mesmo servidor, onde cada um é um subdominio do servidor?
Obrigado.
E ai pessoal, beleza?
Excelente artigo.
Tentei utiliza-lo com um projeto meu, e estou tendo o seguinte problema:
00:34 deploy assets precompile:
01 ~/.rvm/bin/rvm 2.5.1 do bundle exec rake assets:precompile
01 rake aborted!
01 ActiveSupport::MessageEncryptor::InvalidMessage: ActiveSupport::MessageEncryptor::InvalidMessage::
O Estranho eh que rodando esse comando la direto na VPS ele da o mesmo erro, mas se eu substituir o ‘rake assets:precompile’ por ‘rails assets:precompile’ funciona. =/
Meu projeto usa rails 5.2.1 e Ruby 2.5.1.. sera algum problema com versao? é possivel alterar esse comando assets:precompile no projeto?
Também passei por esse problema. Acontece que não tinha configurado corretamente a credentials do rails 5.2
Até deu a dica ActiveSupport::MessageEncryptor
tentou rails assets:precompile?
Boa noite, utilizei o tutorial para subir uma aplicação para a digital ocean, mas estou tendo problema com as imagens, quando faço um novo deploy as imagens que tenho gravado na aplicação são removidas. Até que um novo deploy seja feito as imagens permanecem gravadas e são exibidas corretamente. Alguem poderia ajudar a resolver este problema.
No seu arquivo de deploy.rb tem que configurar o caminho da pasta que n quer subistituir acada deploy, exemplo:
append :linked_dirs, “log”, “tmp/pids”, “tmp/cache”, “tmp/sockets”, “public/system”
Boas pessoal fiz o tutorail certinho.
Mas quando acesso a minha aplicacao a patir di IP da esse erro
“We’re sorry, but something went wrong.”
Mas nos logs de error diz que o ngnix esta a start
To com o mesmo problema. Voce conseguiu resolver?
Daniel, estou fazendo um teste com Active Storage, o upload da imagem é feito corretamente, mas ao tentar apresentar a imagem está dando um erro: Failed to load resource: net::ERR_CONNECTION_REFUSED, isso no console do google chromme.
Em ambiente de desenvolvimento funciona perfeitamente, usando apenas o Puma sem o nginx.