🥇 NGINX / UNICORN / CENTOS 6.6 / RESOLUÇÃO DE PROBLEMAS DE TRILHOS

Bem-vindo ao inferno

Como minha primeira implantação em um VPS Centos 6.6, eu estava um pouco animado para testar minhas habilidades de administrador de sistema, mas, ah, estava tão errado.

O guia a seguir usa a maior parte de um guia do Oceano Digital:
https://www.digitalocean.com/community/tutorials/how-to-deploy-rails-apps-using-unicorn-and-nginx-on-centos-6-5

Portanto, vou pular algumas etapas realmente fáceis e solucionáveis para configuração comum em qualquer sistema / máquina.

Para as primeiras etapas, precisamos:

RVM
RUBI
TRILHOS
UNICORN GEM
POSTGRESQL
NGINX

Tudo isso pode ser instalado seguindo o guia acima.

Quando tivermos uma instalação básica do Rails pronta, nosso aplicativo será implantado na pasta:

/var/www/appname
# change appname for your application folder

NGINX

A primeira configuração é a configuração Nginx, usaremos um único servidor de aplicativos, então usaremos nosso arquivo de configuração padrão dentro da instalação do nginx e colocaremos dentro dele o seguinte código:

# /etc/nginx/conf.d/default.conf
upstream app {
  server unix:/tmp/unicorn.myapp.sock fail_timeout=0;
}

server {
  listen 80;
  server_name localhost;

  root /root/my_app/public;

  try_files $uri/index.html $uri @app;

  location @app {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
     proxy_redirect off;
     proxy_pass http://app;
  }

  error_page 500 502 503 504 /500.html;
  client_max_body_size 4G;
  keepalive_timeout 10;
}

Aqui, a maior parte do código é explicada por si só, mas vou me aprofundar um pouco em alguns dos parâmetros que tendem a perder o entendimento e caminhos errados para iniciantes como eu.

Agora, a explicação para este código:

# "myapp" will be any name, I encourage you to use it on lowercase just remember it because
# through this exact file NGINX and unicorn will comunicate

server unix:/tmp/unicorn.myapp.sock fail_timeout=0;

O caminho raiz:

# this path will be for the public assets of your application, as we know (or may not) when assets are precompiled they go straight into:
# "public/assets/"
# and NGINX will serve our assets so unicorn will take care of the internal processing
root /root/my_app/public;

O Porto:

# theres not much to explain here but if you have to change the port on your server remember to change it here too
listen 80;

Unicórnio

Agora, dentro de nosso aplicativo, criaremos um arquivo de configuração de unicórnio:

# Yes this is a ruby file
/config/unicorn.rb

e coloque o seguinte código dentro dele:

# Set the working application directory unicorn will load the application workers from, as copies of this folder (your application folder)
working_directory "/var/www/appname"

# Unicorn PID file location if you dont have the pids dir just mkdir it
pid "/var/www/appname/pids/unicorn.pid"

# Path to logs. If you don't have the /log dir just mkdir it but it is part of the Rails core.
stderr_path "/var/www/appname/log/unicorn.log"
stdout_path "/var/www/appname/log/unicorn.log"

# Unicorn socket (THIS WILL BE THE SAME SOCKET ON NGINX)

listen "/tmp/unicorn.myapp.sock"

# Number of processes or workers to spawn this will be processes or daemons on your server
worker_processes 2

# Time-out for server workers
timeout 30

Solução de problemas

Agora vamos executar tudo com:

# As unicorn_rails is a gem, remember to have your rvm environment loaded bundle install it, rvm gemset use it when running this command or inside unicorn logs it will display a missing gem error and it will timeout. 

# NOTE: -c is for directory, -D for Daemon running it, -E for environment running.
unicorn_rails -c /var/www/appname/config/unicorn.rb -D -E “production"

# some times nginx don't get installed as a service so we need to create it or use the /etc/init.d/ variant.
sudo service nginx start

/etc/init.d/nginx restart

Na primeira vez, o serviço e tudo parecerão estar funcionando, mas se você olhar os registros (se você não conseguir acessar por um usuário normal, faça login em “su -“)

tail -n 200 /var/log/nginx/error.log

Notaremos desde tempos limite até permissões negadas , para resolver isso existem várias etapas que irei explicar (a maioria deles problemas):

1.- permissões var / www:

Se olharmos para as permissões da pasta com o seguinte comando (ou qualquer outro)

sudo -u nginx stat /var/www

veremos que a pasta não pertence ou não está acessível ao nginx, esse é um dos principais motivos pelos quais o nginx não consegue acessar a pasta pública ou nos dá uma resposta Bad-Gateway

para resolver isso, adicionaremos nosso usuário atual e o usuário nginx ao mesmo grupo, lembre-se de que não importa se fazemos chown ou chmod para uma pasta NGINX E UNICORN precisam ser capazes de usar a pasta de nosso aplicativo e chown nem chmod farão o truque, pois eles apenas mudam o proprietário e alteram as permissões de escrita / leitura em um nível superficial:

# www-data is the name of a group we are creating a group so we can assign it to the folder and our users can access it
group add www-data

# add users to the group, my_user must be the user running unicorn's daemon.
usermod -a -G www-data nginx
usermod -a -G www-data my_user

# then we add access on the folder to the group. (-R will make all the folders inside www accessible to the group). If you want to make only your app accessible (multi app server) just add the group to your apps folder
chgrp -R www-data www/

Agora, ao executar o unicórnio, podemos ter um problema de impossível escrever a pasta, isso pode ser resolvido por um chmod, mas com a atribuição de pasta deve ser suficiente (apenas lembre-se de NUNCA 777, apenas apenas 755 ou 775 níveis de permissão)

2.- Off to the socket issue

Algumas vezes você pode obter um (acesso negado) no log do seu nginx apontando para o arquivo de soquete, isso pode ser resolvido de várias maneiras, mas lembre-se de que seu soquete está em:

# Described in both configuration files for NGINX and Unicorn
/temp/unicorn.appname.sock

Mão única:

(um que você já deve ter encontrado) é chmod ou chown o arquivo sock, eu não recomendo porque o arquivo sock é um arquivo temporário gerado toda vez que seu unicórnio é iniciado, então deixe-o em / temp /

Ou de outra forma:

# find the failing access or denied exceptions under logs
sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M nginx

# (if you don't have semodule installed install it!!!!!)
# the above command will tell you to run a script when it finishes creating the policies, then run it
sudo semodule -i nginx.pp

Depois disso, basta reiniciar o nginx e matar / reiniciar os processos do unicórnio,

NOTA: Você pode encontrar outros problemas nas permissões de acesso, mas eles podem ser resolvidos atribuindo a pasta ao grupo descrito acima no caso 1.-.

Conclusão

Até onde eu encontrei, estes são os principais problemas que podem ser encontrados que não são erros de script, como um caminho errado ou coisas assim, a maioria deles são apenas problemas de permissões muito comuns em distribuições CENTOS principalmente por razões de segurança, lembre-se de O servidor deve ser seguro e encorajo todos a aprenderem algumas políticas de segurança e informações de diretório em seu servidor, pois cada uma delas é destinada a um propósito ou trabalho em distribuições diferentes como o servidor Ubuntu ou CENTOS.

Related Posts