Protegendo e monitorando a implantação do ShinyProxy de aplicativos R Shiny

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


[Esteartigofoipublicadopelaprimeiravezem[Thisarticlewasfirstpublishedon R databentobox, e gentilmente contribuiu para os R-blogueiros]. (Você pode relatar um problema sobre o conteúdo desta página aqui)


Deseja compartilhar seu conteúdo com R-blogueiros? clique aqui se você tiver um blog ou aqui se não tiver.

Índice

Introdução

Há um tempo atrás eu escrevi um
tutorial sobre a implantação de aplicativos R Shiny usando ShinyProxy. Após isso, você poderá implantar um aplicativo Shiny funcional na instância do AWS EC2 que possa atender a vários usuários simultaneamente. No entanto, o aplicativo não é realmente de qualidade de produção devido a algumas falhas. Primeiro, o método de autenticação do ShinyProxy foi definido como “Simples”, o que significa que o nome de usuário e a senha foram armazenados como texto sem formatação no application.yml. Segundo, a comunicação entre usuários e a instância da AWS não é segura, pois não configuramos o HTTPS. Terceiro, estávamos usando o domínio padrão da AWS, que dificilmente é amigável. Por fim, precisamos de uma função adequada para registrar estatísticas de uso e métricas do sistema para manter os aplicativos a longo prazo. Neste tutorial, abordarei esses quatro problemas estendendo a estrutura de implantação atual, utilizando alguns serviços fáceis de configurar.

Em poucas palavras, vamos usar
Certbot (vamos criptografar) junto com um nome de domínio válido para configurar o site HTTPS e usar
Nginx como um proxy para rotear o tráfego HTTP para HTTPS. Para autenticação, usaremos
AWS Cognito, um serviço fornecido pela AWS que usa o protocolo OpenID Connect, que o ShinyProxy também suporta. Para registro e monitoramento, usaremos
InfluxDB, um banco de dados de séries temporais de código aberto, para armazenar as estatísticas de uso do ShinyProxy. Nós vamos usar
Telegraf para coletar outras métricas sobre a máquina host e os contêineres do Docker e alimentá-las ao InfluxDB. Por fim, usaremos
Grafana, uma plataforma de análise e monitoramento de banco de dados bem estabelecida para visualizar as métricas. O gráfico abaixo ilustra a estrutura.

Estrutura

Isso pode parecer muito, mas vou tentar dividi-lo em partes diferentes. Além disso, você não precisa implementar tudo isso de uma só vez, pois eles são amplamente independentes, exceto o AWS Cognito, que depende da configuração do HTTPS primeiro. No entanto, se você não estiver familiarizado com o ShinyProxy, verá que este tutorial faz mais sentido depois de conferir minha postagem anterior
Implantando aplicativos R Shiny usando ShinyProxy no Windows 10.

Pré-requisitos

Antes de mergulharmos no tutorial, há algumas coisas que precisam ser feitas primeiro, que não abordarei em muitos detalhes aqui.

Etapa 1: Configurando o Docker

A configuração do mecanismo do Docker em sua máquina local para desenvolvimento é importante para este tutorial. por favor, verifique
nesta seção para obter detalhes sobre como configurar o mecanismo do Docker no Windows 10. Se você estiver usando outro sistema operacional, verifique o
guia de instalação oficial do Docker.

Etapa 2: compilando o aplicativo demo brilhante e imagens em contêiner ShinyProxy Docker

Você pode pular esta etapa se já tiver uma imagem de Docker de função. Caso contrário, siga
nesta seção. Você deve ter uma imagem chamada shiny-euler-app (ou um nome de sua escolha).

Agora, precisamos criar uma imagem do Docker que contenha o mecanismo ShinyProxy. Segue
nesta seção para criar uma imagem do Docker chamada shinyproxy-example (ou um nome de sua escolha). Não se preocupe com as configurações em application.yml, pois os substituiremos quando o compormos no docker. Além disso, você não precisa configurar o container-network mencionado nesse tutorial também.

Agora, enviaremos as duas imagens para o DockerHub.

docker login

Digite seu nome de usuário e senha quando solicitado. Você verá “Login com êxito” no console. Agora, marque e envie as imagens para o seu repositório do DockerHub:

docker tag shinyproxy-example YOUR_USERNAME/shinyproxy-example
docker tag shiny-euler-app YOUR_USERNAME/shiny-euler-app
docker push YOUR_USERNAME/shinyproxy-example
docker push YOUR_USERNAME/shiny-euler-app

Agora, você deve conseguir extrair esta imagem de qualquer lugar usando o comando abaixo. Obviamente, você precisará fazer login primeiro se definir o repositório como privado.

docker pull YOUR_USERNAME/shiny-euler-app
docker pull YOUR_USERNAME/shinyproxy-example

Etapa 3: iniciando instâncias do AWS EC2

Seguindo essa estrutura, precisaremos de duas instâncias do AWS EC2, uma para hospedar o ShinyProxy e outra para registrar e monitorar estatísticas de uso. Abaixo estão as especificações mínimas:

Máquina ShinyProxy:

  • Ubuntu 16.04 LTS (embora outras versões também possam funcionar)
  • Porta aberta 22 (SSH), 80 (HTTP) e 443 (HTTPS)
  • Mínimo de 1 GiB de memória
  • Armazenamento mínimo de 8 GB
  • Instalar o Docker Engine e o Docker Compose

Monitor de uso da máquina:

  • Ubuntu 16.04 LTS (embora outras versões também possam funcionar)
  • Porta aberta 22 (SSH), 3000 (Grafana) e 8086 (InfluxDB)
  • Mínimo de 0,5 GiB de memória
  • Armazenamento mínimo de 8 GB
  • Instalar o Docker Engine

Mais adiante neste tutorial, vou me referir às duas instâncias da AWS como ShinyProxy Instance e Usage Monitor Instance. Teoricamente, podemos usar uma instância para hospedar o ShinyProxy e as ferramentas de monitoramento de uso, mas não teremos muita flexibilidade se decidirmos lançar outro ShinyProxy no futuro.

A instalação do Docker Engine e do Docker Compose no Ubuntu não será abordada aqui. Você pode conferir os guias oficiais:
Instale o Docker Engine no Ubuntu e
Instale o Docker Compose.

De acordo com a minha experiência, o ShinyProxy em contêineres costuma ter muita memória. Ele usa cerca de 300 MiB, mesmo quando ocioso. O uso total de memória depende do seu aplicativo Shiny, mas acho que devemos procurar obter pelo menos 1 GiB de memória para que ele funcione sem problemas. Na produção, garantir que você tenha memória suficiente e adicionar memória de oscilação são sempre boas idéias. Felizmente, um AWS t2.micro instância é suficiente para a demonstração e está no nível gratuito!

Etapa 4: configurando um nome de domínio (opcional)

Se você já possui um nome de domínio (por exemplo, example.com), é fácil configurar um subdomínio (por exemplo, app.example.com) para hospedar seu aplicativo Shiny. Você precisará configurar um registro A com o seu registrador de domínio e apontá-lo para o endereço IP do ShinyProxy Instance. Usando o
Verificador de DNS para verificar seu nome de domínio recém-configurado antes de continuar nas próximas etapas.

Leia Também  Privacidade Diferencial Local: Obtendo Respostas Honestas em Perguntas Embaraçosas

Etapa 5: configurando o AWS Cognito (opcional)

Se você decidir usar o AWS Cognito para autenticação (o que eu recomendo), será necessário configurar um pool de usuários do Cognito com antecedência. Isso é relativamente simples e o guia oficial pode ser encontrado
aqui. As etapas 1 e 2 do guia são essenciais para este tutorial. Depois de definir o pool de usuários, você precisará fazer algumas coisas:

  1. Tome nota da sua Pool Id, que segue o formato Pool {region} _ {id} (por exemplo, us-east-1_XXXXXXXXX). A partir daqui, você também pode obter o region do seu pool de usuários, que será útil mais tarde.
  2. Crie uma conta de usuário de teste para você mesmo, sob o Users and groups aba. Crie um grupo chamado admins e atribua a conta de teste a esse grupo.
  3. Crie um App client chamado “teste de simulador brilhante” (ou um nome de sua escolha). Anote o App client id e App client secret.
  4. Debaixo de App integration/App client settings, Verifica Cognito User Pool Enquanto o Enabled Identity Providers. Você também pode usar outros Identity providers como o Facebook ou o Google, mas não os abordarei aqui.
  5. Na mesma página, defina o Callback URL(s) para “https: // {seu_domínio} / login / oauth2 / code / shinyproxy” e o Sign out URL(s) para “https: // {seu_domínio}”. No tutorial, usarei ‘app.example.com’ como espaço reservado.
  6. Novamente, na mesma página, em OAuth 2.0, Verifica Authorization code grant, Implicit grant para Allowed OAuth Flows e depois verifique tudo, exceto phone para Allowed OAuth Scopes.
  7. No App integration/Domain name, colocou o Domain prefix de sua escolha e anote todo Amazon Cognito domain. Esse é o nome de domínio da página de entrada para a qual os usuários serão redirecionados quando visitarem seu site. Você pode configurar seu próprio domínio para a página de entrada.

Configurando HTTPS (SSL / TLS)

Etapa 1: Preparando Arquivos de Configuração

Para os principais serviços (por exemplo, ShinyProxy, Nginx e Certbot), usaremos o Docker Compose para configurá-los de uma só vez. Eu preparei um modelo para isso com base nesse maravilhoso
tutorial. Eu o adaptei para trabalhar com o ShinyProxy, mas fique à vontade para verificar a postagem original para obter detalhes técnicos, que não abordarei aqui.

Primeiro, bifurque (e clone) o repositório do modelo:

https://github.com/presstofan/shinyproxy-docker-compose-demo.git

Abaixo está a estrutura do diretório shinyproxy-docker-compose-demo:

| docker-compose.yml
| init-letsencrypt.sh
|
+---application
| application.yml
|
---data
---nginx
app.conf

Agora, precisaremos atualizar alguns arquivos de configuração antes de compor o docker. Primeiro, vamos dar uma olhada no application.yml

application.yml

proxy:
title: My Awesome Shiny Portal
port: 8080 # use Port 8080 for ShinyProxy
container-wait-time: 30000 # how long should we wait for the container to spin up (30s as default as this is enough for our Shiny apps)
heartbeat-rate: 10000 # the user's browser will send a heartbeat call every heartbeat-rate milliseconds (10s as default)
heartbeat-timeout: 60000 # if the server does not receive a heartbeat for heartbeat-timeout milliseconds, the relevant proxy will be released (60s as default)
usage-stats-url: http://{your_InfluxDB_instance_domain}:8086/write?db=shinyproxy_usagestats # use InfluxDB to store usage statistics; can be in a different server
# usage-stats-username: xxxx # influxdb username if needed
# usage-stats-password: xxxx # influxdb password if needed
#### OpenID Connect Authentication ####
authentication: openid # use openid auth framework
openid:
roles-claim: cognito:groups # use the groups value passed by AWS cognito to identify user groups
auth-url: # https://{cognito_domain_prefix}.auth.{region}.amazoncognito.com/oauth2/authorize
token-url: # https://{cognito_domain_prefix}.auth.{region}.amazoncognito.com/oauth2/token
jwks-url: # https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json
logout-url: # https://{cognito_domain_prefix}.auth.{region}.amazoncognito.com/logout?client_id={client_id}&logout_uri={your_host_url}
client-id: # get this from AWS Cognito user pool management page
client-secret: # get this from AWS Cognito user pool management page
#### Simple Authentication ####
# authentication: simple
# admin-groups: admins
# users:
# - name: admin
# password: admin
# groups: admins
docker:
internal-networking: true
# Below is a list of Shiny app and their config (including who can access to which)
specs:
- id: euler
display-name: Euler's number
container-cmd: ["R", "-e", "shiny::runApp('/root/euler')"]
container-image: shiny-euler-app
access-groups: admins
container-network: sp-net
server:
useForwardHeaders: true # this is very important to make the AWS Cognito auth working
logging:
file:
shinyproxy.log

Não vou entrar em detalhes para o application.yml configurado como ShinyProxy tem uma abrangente
guia sobre isso. No entanto, vou apontar algumas coisas importantes:

  1. O padrão port para ShinyProxy é 8080 e nós o usamos. Se isso for alterado, os arquivos de composição de encaixe abaixo precisam ser atualizados de acordo.
  2. usage-stats-url é necessário atualizar para apontar para a instância do AWS EC2 que hospeda as ferramentas de estatísticas de uso. O bit ‘: 8086 / write? Db = shinyproxy_usagestats’ é importante, pois especifica a porta do InfluxDB e o nome do banco de dados (que criaremos posteriormente).
  3. Todos os itens em openid precisa ser atualizado se você configurou o AWS Cognito User Pool (ou seja, substitua o conteúdo em {} pelas informações anotadas na página de configuração do AWS Cognito User Pool). Se você não o estiver usando, basta comentar este bloco e descomentar o bloco “Autenticação simples” e configure-o de acordo.
  4. Debaixo de specs é o local em que você especifica quais aplicativos Shiny devem estar disponíveis no seu portal ShinyProxy. o container-cmd dependeria do nome do diretório que contém seu aplicativo R Shiny (por exemplo, server.R e ui.R). container-image precisa ser consistente com o nome da imagem que você enviou ao DockerHub. Observe que quando você puxa, ele adiciona YOUR_USERNAME/ para a imagem por padrão. Finalmente access-groups define quem pode acessar o aplicativo. Certifique-se de incluir o grupo em que a conta de teste está (por exemplo, administradores).
  5. Debaixo server, a useForwardHeaders precisa ser definido como “true” para que o AWS Cognito funcione corretamente.

Agora, vamos para app.conf, que é o arquivo de configuração do Nginx.

app.conf

server {
listen 80;
server_name app.example.com;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name app.example.com;
access_log /var/log/nginx/shinyproxy.access.log;
error_log /var/log/nginx/shinyproxy.error.log error;
server_tokens off;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_pass http://shinyproxy:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 600s;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Você precisará alterar todas as instâncias de app.example.com (4 no total) ao seu próprio nome de domínio e pronto! Esse arquivo de configuração instrui o Nginx a ouvir os desafios da porta 80 (HTTP) (uma etapa importante para configurar o certificado SSL) e redirecionar o tráfego para a porta 443 (HTTPS), que possui o certificado. Em seguida, o tráfego será direcionado para a porta 8080 do local shinyproxy serviço onde a mágica acontece. A configuração completa do Nginx é bastante complicada e você pode verificar as
guia oficial para adequá-lo à sua necessidade.

Em seguida, vamos configurar docker-compose.yml, que vinculam tudo.

docker-compose.yml

version: '3.5'
services:
nginx:
image: nginx:1.15-alpine
depends_on:
- shinyproxy
- certbot
restart: unless-stopped
volumes:
- ./data/nginx:/etc/nginx/conf.d
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
ports:
- "80:80"
- "443:443"
networks:
- sp-net
command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g "daemon off;"'"
certbot:
image: certbot/certbot
restart: unless-stopped
volumes:
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
networks:
- sp-net
entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
shinyproxy:
image: YOUR_USERNAME/shinyproxy-example
depends_on:
- euler
container_name: shinyproxy
expose:
- 8080
volumes:
- ./application/application.yml:/opt/shinyproxy/application.yml
- /var/run/docker.sock:/var/run/docker.sock
networks:
- sp-net
euler:
image: YOUR_USERNAME/shiny-euler-app
networks:
sp-net:
name: sp-net

Os detalhes desta configuração (especialmente para serviços Nginx e Certbot) podem ser encontrados em
esta postagem. Algumas coisas importantes a serem destacadas:

  1. Você precisará atualizar as duas imagens YOUR_USERNAME/shiny-euler-app e YOUR_USERNAME/shinyproxy-example.
  2. Precisamos vincular o Certbot e o Nginx usando dois volumes compartilhados ./data/certbot/conf:/etc/letsencrypt e ./data/certbot/www:/var/www/certbot. Dessa forma, quando o Certbot obtém o certificado, o Nginx pode acessá-lo.
  3. O código após entrypoint no serviço Certbot é garantir que o Certbot verifique se o seu certificado pode ser renovado a cada 12 horas, conforme recomendado pelo Let’s Encrypt.
  4. O código após command sob o serviço Nginx é fazer com que o Nginx recarregue os certificados recém-obtidos a cada 6 horas.
  5. Precisamos instruir o docker-composite para criar uma rede de contêineres chamada sp-net que vincula todos os serviços.
Leia Também  Oportunidades de trabalho: cientista e engenheiro de dados

Por fim, precisamos do Nginx para realizar a validação Vamos criptografar. No entanto, o Nginx não será iniciado se os certificados estiverem ausentes. O autor de
este post propôs uma solução. Ou seja, primeiro criamos um certificado fictício, iniciamos o Nginx, excluímos o fictício e solicitamos os certificados reais usando o Certbot. Esse progresso é automatizado com o script de shell abaixo.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

init-letsencrypt.sh

#!/bin/bash
if ! [ -x "$(command -v docker-compose)" ]; then
echo 'Error: docker-compose is not installed.' >&2
exit 1
fi
domains=(app.example.com)
rsa_key_size=4096
data_path="./data/certbot"
email="YOUR_EMAIL" # Adding a valid address is strongly recommended
staging=0 # Set to 1 if you're testing your setup to avoid hitting request limits
if [ -d "$data_path" ]; then
read -p "Existing data found for $domains. Continue and replace existing certificate? (y/N) " decision
if [ "$decision" != "Y" ] && [ "$decision" != "y" ]; then
exit
fi
fi
if [ ! -e "$data_path/conf/options-ssl-nginx.conf" ] || [ ! -e "$data_path/conf/ssl-dhparams.pem" ]; then
echo "### Downloading recommended TLS parameters ..."
mkdir -p "$data_path/conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf > "$data_path/conf/options-ssl-nginx.conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot/certbot/ssl-dhparams.pem > "$data_path/conf/ssl-dhparams.pem"
echo
fi
echo "### Creating dummy certificate for $domains ..."
path="/etc/letsencrypt/live/$domains"
mkdir -p "$data_path/conf/live/$domains"
docker-compose run --rm --entrypoint "
openssl req -x509 -nodes -newkey rsa:1024 -days 1
-keyout '$path/privkey.pem' 
-out '$path/fullchain.pem' 
-subj '/CN=localhost'" certbot
echo
echo "### Starting nginx ..."
docker-compose up --force-recreate -d nginx
echo
echo "### Deleting dummy certificate for $domains ..."
docker-compose run --rm --entrypoint "
rm -Rf /etc/letsencrypt/live/$domains && 
rm -Rf /etc/letsencrypt/archive/$domains && 
rm -Rf /etc/letsencrypt/renewal/$domains.conf" certbot
echo
echo "### Requesting Let's Encrypt certificate for $domains ..."
#Join $domains to -d args
domain_args=""
for domain in "${domains[@]}"; do
domain_args="$domain_args -d $domain"
done
# Select appropriate email arg
case "$email" in
"") email_arg="--register-unsafely-without-email" ;;
*) email_arg="--email $email" ;;
esac
# Enable staging mode if needed
if [ $staging != "0" ]; then staging_arg="--staging"; fi
docker-compose run --rm --entrypoint "
certbot certonly --webroot -w /var/www/certbot 
$staging_arg 
$email_arg 
$domain_args 
--rsa-key-size $rsa_key_size 
--agree-tos 
--force-renewal" certbot
echo
echo "### Reloading nginx ..."
docker-compose exec nginx nginx -s reload

Neste script de shell, você precisará alterar app.example.com com seu próprio nome de domínio e insira seu endereço de e-mail, para que o Criptografar possa entrar em contato com você se seu certificado estiver prestes a expirar ou tiver algum problema.

Quando estiver satisfeito com os arquivos de configuração, você pode confirmar e enviá-lo para seu próprio repositório GitHub para facilitar o acesso. Agora temos tudo o que precisamos. Vamos entrar no nosso ShinyProxy Machine e experimente!

Etapa 2: Configurando ShinyProxy Machine

SSH para o ShinyProxy Machine e git puxe seu próprio repositório de configuração shinyproxy-docker-compose-demo (ou outro nome que você especificou). A estrutura dos arquivos e diretório deve permanecer a mesma. Você já deve ter o Docker Engine e o Docker Compose instalados. Inicie o serviço Docker:

sudo service docker start

E verifique se os serviços estão em execução:

sudo docker version
sudo docker-compose version

E puxe as imagens do Docker. Observe que você pode precisar fazer login aqui (se as imagens estiverem em repositórios particulares).

sudo docker pull YOUR_USERNAME/shiny-euler-app
sudo docker pull YOUR_USERNAME/shinyproxy-example

Se tudo estiver funcionando bem, CD em shinyproxy-docker-compose-demo. Primeiro, executaremos o init-letsencrypt.sh, mas não antes de torná-lo executável primeiro. Siga o prompt da linha de comando para concluir o progresso, durante o qual todos os serviços serão executados usando o docker-compose e, se for a primeira vez que você estiver executando o script, levará algum tempo para criar as imagens para Certbot e Nginx.

chmod +x init-letsencrypt.sh

Em seguida, execute-o com

sudo ./init-letsencrypt.sh

Você verá algo como abaixo se o certificado for emitido com sucesso.

Congratulations! You have successfully enabled https://example.com and https://www.example.com
-------------------------------------------------------------------------------------
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com//privkey.pem
Your cert will expire on 2017-12-12.

Em seguida, se você verificar os contêineres do Docker usando o comando abaixo, encontrará shinyproxy, nginx e certbot corrida.

sudo docker stats

Caso contrário, basta compor o docker.

sudo docker-compose up

Aguarde alguns segundos e visite app.example.com. Você deve ver a página de login do AWS Cognito ou a página de login do ShinyProxy, dependendo da sua configuração.

Se você decidir derrubar o site, basta usar o seguinte comando e tudo ficará bem e limpo.

sudo docker-compose down

Configurando o InfluxDB, Telegraf e Grafana para o registro de estatísticas de uso

A configuração das ferramentas de monitoramento de estatísticas de uso é relativamente simples e pode ser feita sem agendar o tempo de inatividade do seu ShinyProxy Machine.

Etapa 1: Configurando o Telegraf no ShinyProxy Machine

O ShinyProxy possui uma função interna que envia as informações básicas de uso (login, logout, aplicativos start / stop etc.) para o InfluxDB. No entanto, também precisamos coletar métricas (como uso de memória e CPU) da máquina host e do Docker Engine. Para conseguir isso, precisaremos usar
Telegraf.

Novamente, precisamos SSH para ShinyProxy Machine e crie uma nova pasta chamada telegraf no etc diretório.

sudo mkdir -p /etc/telegraf

Agora, precisamos garantir que o serviço Docker esteja em execução:

sudo service docker start

Semelhante a outros serviços, o Telegraf precisa de um arquivo de configuração para funcionar corretamente e pode ser bastante complicado. Felizmente, podemos criar um arquivo de configuração de modelo executando o comando config comando do contêiner Docker do Telegraf. O comando a seguir fará o download do telegraf imagem e execute-a para gerar o arquivo de configuração padrão.

sudo docker run --rm telegraf telegraf config | sudo tee /etc/telegraf/telegraf.conf < /dev/null

Agora, é hora de testar sua habilidade em vim. Precisamos abrir o telegraf.conf e faça duas coisas. Primeiro, localize o [[outputs.influxdb]] seção e atualize o urls para o endereço ip / domínio do Usage Monitor Machine. Não se esqueça de especificar a porta 8086.

urls = ["http://{domain_name}:8086"]

Em seguida, localize o HTTP Basic Auth seção e modifique as credenciais adequadamente, se você planeja configurar credenciais para o seu InfluxDB

username = ""
password = ""

Por fim, localize o [[inputs.docker]] seção, descomente o bloco e configure-o com as seguintes configurações:

# Read metrics about docker containers
[[inputs.docker]]
## Docker Endpoint
## To use TCP, set endpoint = "tcp://[ip]:[port]"
## To use environment variables (ie, docker-machine), set endpoint = "ENV"
endpoint = "unix:///var/run/docker.sock"
## Set to true to collect Swarm metrics(desired_replicas, running_replicas)
## Note: configure this in one of the manager nodes in a Swarm cluster.
## configuring in multiple Swarm managers results in duplication of metrics.
gather_services = false
## Only collect metrics for these containers. Values will be appended to
## container_name_include.
## Deprecated (1.4.0), use container_name_include
container_names = []
## Set the source tag for the metrics to the container ID hostname, eg first 12 chars
source_tag = false
## Containers to include and exclude. Collect all if empty. Globs accepted.
container_name_include = []
container_name_exclude = []
## Container states to include and exclude. Globs accepted.
## When empty only containers in the "running" state will be captured.
## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]
## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]
## container_state_include = []
## container_state_exclude = []
## Timeout for docker list, info, and stats commands
timeout = "5s"
## Whether to report for each container per-device blkio (8:0, 8:1...) and
## network (eth0, eth1, ...) stats or not
perdevice = true
## Whether to report for each container total blkio and network stats or not
total = false
## docker labels to include and exclude as tags. Globs accepted.
## Note that an empty array for both will include all labels as tags
docker_label_include = []
docker_label_exclude = []
## Which environment variables should we use as a tag
tag_env = ["JAVA_HOME", "HEAP_SIZE"]
## Optional TLS Config
## tls_ca = "/etc/telegraf/ca.pem"
## tls_cert = "/etc/telegraf/cert.pem"
## tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
## insecure_skip_verify = false

Em seguida, executamos o seguinte comando. Como o telegraf é executado dentro de um contêiner, o soquete unix precisará ser exposto dentro do contêiner de telegraf. Isso pode ser feito na CLI do docker, adicione a opção -v /var/run/docker.sock:/var/run/docker.sock.

sudo docker run -d -p 998:998 --name=telegraf 
--net=sp-net 
-e HOST_PROC=/host/proc 
-v /var/run/docker.sock:/var/run/docker.sock 
-v /proc:/host/proc:ro 
-v /etc/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro 
telegraf

Execute o comando abaixo para verificar se o contêiner telegraf está em execução.

sudo docker container logs -f --since 10m telegraf

Etapa 2: Configurando o InfluxDB no Usage Monitor Machine

Agora, SSH para o Usage Monitor Machine, que já deve ter o Docker Engine em execução. A instalação do InfluxDB deve ser bastante fácil. Se você iniciou sua instância do AWS EC2 usando um sistema Ubuntu 16.04 LTS, o InfluxDB pode ser baixado e instalado com os seguintes comandos:

wget https://dl.influxdata.com/influxdb/releases/influxdb_1.8.0_amd64.deb
sudo dpkg -i influxdb_1.8.0_amd64.deb

Você também pode usar a imagem do Docker para criar o InfluxDB ou mesmo o Docker Compose para configurar, mas achei a versão autônoma simples o suficiente para configurar e manter. Depois que a instalação for concluída, inicie o serviço:

sudo service influxdb start

E verifique se o serviço está sendo executado corretamente.

sudo service influxdb status

Agora, vamos criar dois bancos de dados, um para o ShinyProxy e outro para o Telegraf. Observe que o nome dos bancos de dados precisa ser consistente com as configurações no ShinyProxy application.yml e telegraf.conf. Abra a CLI do InfluxDB com:

influx

E depois

CREATE DATABASE shinyproxy_usagestats
CREATE DATABASE telegraf

Se tudo estiver funcionando bem e seu ShinyProxy Machine está correndo. Em breve, você poderá ver os dados nos dois bancos de dados. Observe que, para ver os dados em shinyproxy_usagestats pode ser necessário fazer login no seu aplicativo uma vez. A linguagem de consulta que o InfluxDB usa não é tão diferente do SQL, mas a estrutura de dados é diferente, pois é um banco de dados de séries temporais.
Aqui estão alguns comandos para você começar. Eu também listei alguns abaixo:

USE telegraf
SHOW FIELD KEYS
SHOW SERIES
USE shinyproxy_usagestats
SHOW FIELD KEYS
SHOW SERIES
SELECT * FROM event
quit

Obviamente, não vamos monitorar nossos aplicativos usando o cliente CLI do InfluxDB, então vamos para a próxima parte para configurar o Grafana!

Leia Também  Mais da metade do público do Reino Unido espera abandonar o dinheiro nos próximos dois anos, de acordo com novo relatório de pesquisa global

Etapa 3: configurar o Grafana no Usage Monitor Machine

No Usage Monitor Machine, vamos executar o Grafana usando o Docker.

sudo docker run -d --name=grafana -p 3000:3000 grafana/grafana

Agora, abra o navegador e acesse a página inicial do Grafana. Se você estiver usando a instância do AWS EC2, deve ser algo como: 'http://ec2-XX-XX-XX-XX.compute-1.amazonaws.com:3000'. Não se esqueça de especificar a porta 3000, pois é a que é ouvida pela Grafana. Você verá a seguinte interface de usuário de login. O nome de usuário e a senha padrão são ambos "admin". Quando você faz login pela primeira vez, ele solicita que você altere sua senha.

Grafana Login

Depois de fazer login, você verá a página inicial abaixo. Agora, clique no Add data source e escolha InfluxDB quando solicitado.

Grafana Principal

Fonte de dados Grafana

Abaixo estão as configurações da fonte de dados. As configurações mínimas básicas que precisamos especificar são as Name, URL e Database. URL deve apontar para o endereço do seu Usage Monitor Machine, seguido pela porta 8086. "Http://ec2-XX-XX-XX-XX.compute-1.amazonaws.com:8086". Vamos definir o ShinyProxy primeiro. Então, vamos precisar colocar shinyproxy_usagestats para Database.

Configurações do banco de dados Grafana

Quando terminar, clique no ícone Save & Test no final da página e você verá algo como abaixo que indica que seu banco de dados está conectado. Agora, repita o mesmo processo para conectar-se ao banco de dados Telegraf (que é chamado telegraf se você seguiu o tutorial), que armazena as métricas do sistema host e as estatísticas do Docker.

Configurações do banco de dados Grafana concluídas

O próximo passo é criar os painéis para visualizar os dados. Existem duas maneiras de fazer isso. Podemos construí-los do zero ou usar os painéis oficiais e criados pela comunidade. Para métricas do Docker e do host, existem painéis bem estabelecidos. Para adicioná-los, você precisa pairar no sinal "Mais" à esquerda e depois em "Importar". Em seguida, insira o ID do painel, que você pode encontrar
aqui. Abaixo estão os dois painéis que eu gosto (1443 para host e 1150 para Docker). Depois de escolher o painel desejado, você precisa especificar a fonte de dados do InfluxDB, que acabamos de configurar.

Host do painel Grafana

Grafana Dashboard Docker

No momento da redação deste documento, não havia um painel Grafana disponível para ShinyProxy. Então, precisamos construir um do zero. Para fazer isso, passe o mouse sobre o sinal "Mais" novamente e clique em "Painel". Um painel contém um ou mais painéis e cada painel consiste na parte da consulta e na parte de visualização. Começaremos clicando em "Adicionar consulta". Abaixo está o editor do painel. Ele contém um construtor de consultas que ajuda você a começar. Abaixo está uma consulta simples para monitorar o login. Você também pode alternar para o modo de edição de texto da consulta, que é mais flexível na minha opinião. Não há muitas informações gravadas pelo ShinyProxy, mas você tem o básico, como login, logout, inicialização e parada de aplicativos. Consultas mais complicadas podem ser criadas para mostrar o número de usuários no momento, por quanto tempo cada um deles usa os aplicativos e etc. Examinarei isso no futuro. Enquanto isso, fique à vontade para se explorar e contribuir com a comunidade Grafana compartilhando seus painéis ShinyProxy!

Grafana Dashboard ShinyProxy

Isso conclui este tutorial. Agora temos um aplicativo Shiny funcional servido por ShinyProxy com um host seguro e capacidade de monitoramento. Uma coisa que podemos melhorar ainda mais é a escalabilidade do aplicativo. Atualmente, ele é atendido por uma única instância do AWS EC2. Dependendo do tamanho da memória e do número de vCPUs, ele pode atender de uma a algumas dezenas de usuários simultaneamente. No entanto, geralmente não esperamos usuários 24 horas por dia, 7 dias por semana. Assim, construir uma pilha elástica usando o Docker Swarm ou o Kubernetes seria muito mais econômico. No próximo post, explorarei essa rota. Então fique ligado!

var vglnk = {key: '949efb41171ac6ec1bf7f206d57e90b8'};

(função (d, t) {
var s = d.createElement
s.src = '//cdn.viglink.com/api/vglnk.js';
var r = d.getElementsByTagName
} (documento, 'script'));

Para Deixe um comentário para o autor, siga o link e comente no blog: R databentobox.

R-bloggers.com oferece atualizações diárias por email sobre notícias e tutoriais do R sobre o aprendizado do R e muitos outros tópicos. Clique aqui se você deseja publicar ou encontrar um emprego em ciência da dados / R.


Deseja compartilhar seu conteúdo com R-blogueiros? clique aqui se você tiver um blog ou aqui se não tiver.



cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br