Configurando o servidor

Como configurar o servidor para hospedar o site

Esta plataforma funciona sob o paradigma de conter todo o código num só diretório, com o mínimo de alterações no ambiente do servidor. Como estamos usando dois servidores - server shiny para os dashboards e nginx para a parte estática -, depender do mínimo de coisas do ambiente do servidor parece ser uma boa escolha de design. Aparentemente é possível guardar páginas estáticas num shiny server. Embora pareça uma boa ideia depender apenas de um servidor, não está claro para nós se é possível guardar páginas estáticas num shiny server sem que ele incie uma nova sessão de R para cada novo acesso (o que é muito custoso). Além disso, o nginx é uma opção antiga, simples e customizável para servidores, com vasta documentação online. Por conta disso, fizemos a escolha por nginx combinado com shiny server.

shiny server

A instalação do shiny server está documentada no site da posit. As instruções necessárias para um servidor shiny estão contidas num arquivo de nome shiny-server.conf, geralmente guardado em /etc/shiny-server Por default, ele vem assim (sem comentários).

run_as shiny;

server {
  listen 3838;

  location / {
    site_dir /srv/shiny-server;
    log_dir /var/log/shiny-server;
    directory_index on;
  }
}

O argumentos básicos são estes:

• run_as diz em nome de qual usuário a aplicação vai rodar.
• listen é o número da porta em que o site vai rodar, por default é a 3838 (é bom não mexer niso).
• site_dir é a pasta onde devem estar os aplicativos shiny; se você tem um aplicativo numa pasta de nome meu_app e colá-la no caminho especificado nesse agumento, a aplicação shiny vai rodar em root:3838/meu_app, em que root é o seu domínio, que pode ser checado via hostname -I.
• directory_index pode ser on ou off, quando está on aparece uma página com um índice de todos os projetos em site_dir caso o usuário acesse root:3838 sem especificar o projeto.

Gerenciadores de serviços

Em servidores linux, há a necessidades de rodar processos em segundo plano, como servidores shiny e nginx. Nesse contexto são usados gerenciadores de serviços do sistema, como service e systemctl. Dentre outras coisas, esses gerenciadores permitem a execução de serviços em segundo plano, a incialização automática de serviços após boot, o gerenciamento de logs, e a padronização de comandos. O systemctl é um sistema mais moderno que service e alguns comandos úteis desses gerenciadores são mostrados abaixo.

Ação	systemctl	service
Iniciar serviço	systemctl start serviço	service serviço start
Parar serviço	systemctl stop serviço	service serviço stop
Reiniciar serviço	systemctl restart serviço	service serviço restart
Recarregar config	systemctl reload serviço	service serviço reload
Ver status	systemctl status serviço	service serviço status
Habilitar no boot	systemctl enable serviço	(não disponível direto)
Desabilitar no boot	systemctl disable serviço	(não disponível direto)
Listar serviços	systemctl list-units	service --status-all

Também é possível rodar o shiny server em segundo plano via shiny-server &, embora isso não tenha todas as vantagens de um gerenciador, a vantagem dessa abordagem é que ela permite especificar qual o arquivo de configuração de sistema do shiny server. Isso é necessário em parte porque é difícil fazer alterações nos aplicativos se eles estiverem armazenados site_dir default (/srv/shiny-server). Isto é assim porque alterações nas pastas raízes precisam de permissões de administrador (o famoso sudo).

Para contornar isso, podemos especificar um site_dir numa pasta em ~, no nosso caso optamos por ~/website. Parte do problema da ausência de um gerenciador é solucionada pelo argumento log_dir, pasta na qual serão armazenados os logs do shiny server. O arquivo com a configuração do sistema pode ser visto aqui. Um servidor personalizado pode ser executado via shiny-server caminho/para/shiny-server.conf &, o que não pode ser feito diretamente via service ou systemctl.

nginx

nginx é um servidor web amplamente usado na internet que aqui é usado para gerenciar as páginas estáticas do projeto.

Mudando a máscara dos shiny apps

Uma das alterações no ambiente do servidor que é necessária para um uso mais agradável do site é a criação de máscaras para as aplicações Shiny. Por padrão, o shiny server guarda as aplicações na porta 3838. Se *nome_app* - por exemplo - é o nome de uma palicação, então isso ficará disponível em dominio:3838/*nome_app*, em que dominio é a URL raíz, como http://127.0.0.1 ou http://site.com. Para que o usuário tenha uma melhor experiência ao navegar pelo site, gostaríamos que essa aplicação ficasse disponível em dominio/*nome_app*(sem número da porta).

Ao executar sudo nano /etc/nginx/sites-available/default, aparecerá algo como o trecho abaixo.

server {
    listen 80 default_server;
    listen [::]:80 default_server
    root /var/www/html;
    index index.html

    location /dashboards/arvore/ {
        proxy_pass http://127.0.0.1:3838/arvore/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 20d;
    }

}

A criação do que estamos chamando de ‘máscara’ nada mais é que uma especificação de caminho. Como isso fica num local fora da raíz do projeto, optamos por não automatizar a criação dessas máscaras, apenas explicar o procedimento nesse artigo. Para um novo dashboard shiny chamado *nome_app*, o seguinte snippet deve ser adicionado na seção server do arquivo /etc/nginx/sites-available/default. Atenção, o arquivo em questão não deve ser substituído pelo código abaixo, isso deve apenas ser adicionado ao arquivo.

location /dashboards/*nome_app*/ {
        proxy_pass http://127.0.0.1:3838/*nome_app*/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 20d;
    }

Deploying (on one click)

Em nosso projeto há um arquivo chamado deploy.sh que contém uma série de comandos bash que automatizam certas tarefas. Grosso modo, este arquivo está assim.

quarto render ~/website

rm -rf /var/www/html/*
cp -r ~/website/_site/. /var/www/html

sudo pkill -f shiny-server || true
shiny-server ~/website/conf/shiny-server.conf

Três coisas estão acontecendo aqui:

• O projeto é renderizado.
• Todos os arquivos em /var/www/html são apagados e os arquivos de output do website são copiados para lá. O diretório /var/www/html é onde o servidor nginx busca os arquivos do site.
• Processos antigos do shiny server são encerrados (de maneira meio rudimentar) e uma nova instância do shiny server é inicializada com as configurações de conf/shiny-server.conf.

Como os arquivos em /var são restritos, é necessário rodar essa série de comandos com permissões de administrador, assim sudo bash ~/website/conf/deploy.sh &. Usar esse recurso de um arquivo bash é necessário pois não é possível criar um arquivo com configurações do nginx, para - dentre outras coisas - apontar o site para website/_site, como fizemos com o arquivo shiny-server.conf.

Sobre autoindex

Ainda em /etc/nginx/sites-available/default é possível adicionar a seginte configuração de autoindex.

    location /autoindex {
    root /var/www;
    autoindex on;
    autoindex_exact_size on;
    autoindex_localtime on;
}

O Autoindex é um recurso que gera automaticamente uma página listando os arquivos de um diretório (gerando inclusive um arquivo de index.html). Isso permite navegar e baixar conteúdos diretamente pelo navegador e é útil para transmitir pastas estruturadas. No diretório do website, há uma pasta chamada autoindex e tudo nela deve ficar disponível em dominio/autoindex. Para automatizar essa tarefa, esse código consta no deploy.sh.

rm -rf /var/www/autoindex
mkdir -p /var/www/autoindex
cp -r ~/website/autoindex/. /var/www/autoindex