Ao compreender como o Scheduling funciona no Kubernetes, os desenvolvedores e administradores de sistemas podem otimizar a utilização dos recursos, garantir a escalabilidade e a confiabilidade dos aplicativos, além de facilitar a manutenção e a implantação contínua.

Este artigo é um resumo do curso que fiz sobre Kubernetes. Decidi focar no tema de Scheduling por considerá-lo essencial para entender como o Kubernetes gerencia a alocação de recursos e organiza os pods nos nós do cluster, revelando aspectos fundamentais do funcionamento interno da plataforma.

Agendamento manual

O agendamento manual de um pod no cluster se dá quando o serviço do kube-scheduler não está em execução no momento, que é o serviço padrão do Kubernetes para o escalonamento, nesse caso o agendamento não será possível de forma automática.

Para isso, é possível informar manualmente na definição do arquivo de manifesto em qual nó o pod em questão será agendado, isso é feito durante a criação do pod.

Na definição do arquivo do pod, use a propriedade nodeName com o valor do nome do nó, por exemplo node01.

# file: myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels: 
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 8080
  nodeName: node01

Agendamento manual de um pod usando o atributo nodeName

Com esse manifesto, podemos aplicar ao cluster e veremos que o pod será escalado no nó node01, o mesmo que informamos manualmente.

kubectl apply -f myapp.yaml
'pod/nginx' created.

kubectl get pods -o wide
NAME         READY   STATUS      RESTARTS   AGE    IP            NODE
nginx        1/1     Running     0          35s    10.244.0.4    node01

Labels e Selectors

Labels

As labels (rótulos) são pares chave/valor que são adicionados no objeto com o objetivo de agrupá-los. Você pode usar para especificar atributos de identificação dos objetos que podem ser relevantes para os usuários, por exemplo, agrupar serviços por seu ambiente com uma label environment=dev , ou um conjunto de aplicações que executam rotinas de processamento de vídeo, poderia conter uma label tier=video-processing. Labels também pode ser usado para selecionar subconjuntos de objetos.

metadata:
  labels:
    environment: "dev"
    tier: "video-processing"

Definição de labels

Selectors

Os selectors (seletores), são filtros que podem ser aplicados em cima das labels existentes de um objeto, através dos critérios dos filtros você teria o resultado dos grupos de pods.

Temos abaixo o manifesto de um pod usando a imagem do Nginx, com duas labels e um pod usando a imagem do Mysql. A seguir podemos ver como interagir com os objetos usando os seletores.

apiVersion: v1
kind: Pod
metadata:
  name: webserver
  labels:
    environment: dev
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    environment: prod
    app: mysql
spec:
  containers:
  - name: mysql
    image: mysql
    ports:
    - containerPort: 3306

Definição de Pods com Nginx e Mysql

Podemos listar todas as labels adicionadas à um objeto com o parâmetro --show-labels.

kubectl get pods --show-labels
NAME               READY   STATUS             RESTARTS           AGE   LABELS
nginx              1/1     Running            0                     2m    app=nginx,enviroment=dev

Para listar todos os objetos filtrando por uma determinada label, pode ser usado a flag --selector ou -l que é a sua abreviação. Os seguintes operadores são suportados: '=' , '==' e '!='.

kubectl get pods -l app=nginx
NAME        READY   STATUS    RESTARTS   AGE
webserver   1/1     Running   0          32s

kubectl get pods --selector app!=nginx
NAME    READY   STATUS    RESTARTS   AGE
mysql   1/1     Running   0          41s

kubectl get pods --selector app=nginx,environment=dev
NAME        READY   STATUS    RESTARTS   AGE
webserver   1/1     Running   0          47

kubectl get pods --selector app=mysql,environment=dev
No resources found in default namespace.

Um ponto interessante para entendermos, é que o Kubernetes internamente usa as labels e selector para vincular um replica set em um pod, um service no deployment, e assim por diante.

Taints e Tolerations

Os taints são uma forma de marcar (ou manchar) um nó para que esse não receba novos pods que não correspondam a um determinado critério (tolerância), ou seja, repelir os pods.

As tolerations seriam marcar um pod que seja tolerante a essa restrição, ou seja, para um determinado nó que foi marcado para não receber pods, um pod com tolerations irá ignorar essa restrição e será agendado nesses nós marcados.

Exemplo:

O nó node01 for marcado da seguinte forma:

kubectl taint nodes node01 monitoring=prometheus:NoSchedule

Dessa forma, somente pods que contenham uma tolerância poderá ser agendado nesse nó. No exemplo a seguir, esse pod contém uma tolerância e será agendado no nó que foi marcado.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-toleration
spec:
  containers:
  - name: nginx
    image: nginx
  tolerations:
  - key: "monitoring"
    operator: "Equal"
    value: "prometheus"
    effect: "NoSchedule"

Definição de Pod com tolerância ao nó

Vamos entender um pouco mais...

Uma tolerância corresponde a uma mancha (taint) se as chaves forem iguais e os efeitos forem os mesmos, e:

• O operator é Exists (nesse caso, o value não deve ser especificado), ou

• O operator é Equal e os valores devem ser iguais.

Para o campo effect, são permitidos os seguintes valores:

NoExecute:

Isso afeta os pods que já estão em execução no nó da seguinte maneira:

• Os pods que não toleram a contaminação são despejados imediatamente.

• Os pods que toleram a contaminação sem especificar tolerationsSeconds em sua especificação de tolerância permanecem vinculados para sempre.

• Os pods que toleram a contaminação com a propriedade tolerationsSeconds especificada, permanecem vinculados pelo período informado, após esse tempo, os pods são despejados dos nós.

NoSchedule:

Nenhum pod será agendado no nó contaminado a menos que tenha uma tolerância correspondente. Os pods em execução não são removidos.

PreferNoSchedule:

Essa é uma versão preferencial do NoSchedule, o plano de controle tentará evitar colocar o pod que não tolere a contaminação, mas não é garantido.

Despejos baseados em contaminação

O controlador de nó contamina automaticamente um nó quando certas condições são verdadeiras. Exemplo:

• node.kubernetes.io/not-ready: o nó não está pronto, corresponde a condição/status do nó Ready ser false.

• node.kubernetes.io/unreachable: o nó está inacessível pelo controlador de nó, corresponde a condição/status do nó Ready ser Unkown.

• node.kubernetes.io/memory-pressure: o nó tem pressão de memória.

• node.kubernetes.io/disk-pressure: o nó tem pressão de disco.

• node.kubernetes.io/pid-pressure: o nó tem pressão PID.

• node.kubernetes.io/network-unvailable: a rede do nó está indisponível.

• node.kubernetes.io/unschedulable: o nó não é programável.

Os pods que são criados a partir de um DaemonSet são criados com tolerâncias para que evitem de serem removidos no caso de uma contaminação, por exemplo.

O pod já vem com essa duas tolerâncias:

• node.kubernetes.io/unreachable

• node.kubernetes.io/no-ready

NodeSelector

O seletor de nó é a forma mais simples para determinar em qual nó o pod deve ser agendado através de seus rótulos. Você pode adicionar a propriedade nodeSelector à especificação do pod e informar qual o rótulo correspondente para que o pod seja agendado, se vários nós corresponderem ao rótulo informado, o scheduler do Kubernetes decidirá em qual nó o pod será colocado com base em outros fatores, como capacidade de recursos e afinidade.

Para visualizar todos as labels existentes em um nó, use o seguinte comando:

kubectl get nodes --show-labels

NAME      STATUS    ROLES    AGE     VERSION        LABELS
worker1   Ready     <none>   1d      v1.24.0        ...,kubernetes.io/hostname=worker1

Para adicionar uma label ao nó, execute o comando:

kubectl label nodes worker1 disktype=ssd 

kubectl get nodes --show-labels

NAME      STATUS    ROLES    AGE     VERSION        LABELS
worker1   Ready     <none>   1d      v1.24.0        ...,disktype=ssd

Agora a propriedade nodeSelector, pode ser usada da seguinte maneira:

...
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

Definição de um Pod com a propriedade nodeSelector

Dessa forma, o pod será agendado em nó que corresponder a esse rótulo.

Node Affinity e anti-affinity

Afinidade e anti-afinidade expandem os tipos de restrições que você pode definir para o agendamento. Alguns benefícios de usar afinidade e anti-afinidade:

• Poder usar lógicas mais elaboradas para escolher o nó de destino, ao contrário do nodeSelector que apenas nós com as labels especificadas são escolhidas.

• Poder escolher se a regra é flexível ou preferencial para que o agendador agende um pod mesmo que não consiga encontrar um nó correspondente.

Afinidade de nó

A afinidade do nó tem o mesmo conceito da propriedade nodeSelector, que permite restringir em quais nós o pod dever se agendado. Existem dois tipos de afinidade de nó:

• requiredDuringSchedulingIgnoredDuringExecution: O agendador irá agendar o pod conforme a regra definida. Caso não encontre um nó que atenda as condições, o pod não será agendado.

• preferredDuringSchedulingIgnoredDuringExecution: O agendador irá tentar encontrar um nó que atenda a regra definida. Caso não encontre um nó que corresponda as condições, o agendar ainda irá agendar o pod.

Dado o seguinte manifesto, temos:

apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

Definição de Pod com a propriedade nodeAffinity

• Este pod só será agendado em nós que tenham o rótulo disktype=ssd.

• Se não houver nós com este rótulo, o pod ficará em estado pending.

Para entender melhor sobre cada tipo de afinidade, vamos dividir em duas partes cada propriedade do tipo de afinidade:

1. Primeira parte é o início de cada tipo de afinidade:

requiredDuringScheduling: Nesse trecho, estamos dizendo para o agendador que as condições definidas são obrigadas durante o agendamento, ou seja, deverá atender estritamente as regras para que o agendamento possa ser realizado.

preferredDuringScheduling: Nesse trecho, estamos dizendo para o agendador que se as condições propostas ao pod não for possível atender, se por exemplo, o label disktype=ssd não corresponder a nenhum nó, então o agendador poderá escolher outro nó para agendar esse pod.

2. Segunda parte é o final de cada tipo de afinidade:

ignoreDuringExecution: Nesse trecho, estamos dizendo ao Kubernetes que se um pod que já está em execução em um nó e uma label é removida desse nó, esse pod não será removido. Exemplo: o pod foi agendado no nó worker1 devido a label disktype=ssd que correspondeu aos critérios do pod, se essa label for removida, o agendador não irá remover esse pod do nó, pois será ignorado durante a execução.

Anti-afinidade de nó

Anti-afinidade de nó funciona no mesmo conceito de afinidade de nó, só que ao invés de trabalhar com regras de "este pod deve", será da forma de "este pod não deve" ser agendado em um determinado nó.

Dado o seguinte manifesto:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: NotIn
            values:
            - linux

Definição de Pod com anti-affinity

No exemplo acima, estamos instruindo o Kubernetes a não agendar o pod em nós que estejam executando o sistema operacional Linux. Ele restringe o agendamento apenas para nós que rodam outro sistema operacional, como Windows.

Se não houver nós com sistema operacional diferente de Linux, o pod ficará pendente e não será agendado.

Requests e limits

Os recursos de solicitações e limites são informações de consumo de CPU e memória que você pode especificar opcionalmente para um contêiner.

Ao usar a solicitação de recurso para os contêineres em um pod, o agendador usa essas informações para decidir em qual nó o pod deve ser agendado.

O agendador irá sempre buscar um nó que tenha recursos disponíveis para que o pod seja agendado. Caso não encontre nenhum nó, o pod ficará com o status Pending e provavelmente se visualizar o status do pod, usando o comando kubectl describe pod verá que houve uma falha no agendamento devido a CPU insuficiente Insufficient cpu (3).

Recursos de CPU

As solicitações e limites de CPU são medidos em unidade de CPU, no Kubernetes, 1 unidade de CPU equivale a 1 núcleo de CPU físico ou 1 núcleo virtual.

São permitidas usar solicitações fracionárias, por exemplo 0.5, está solicitando metade do tempo de CPU, em relação a uma CPU de 1 core.

Recursos de Memória

As solicitações e limites de memória são medidos em bytes, você pode informar a memória como um número inteiro simples ou como um número de ponto fixo usando os sufixos de quantidade.

Exemplo de uso:

spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Definição de Pod com requests e limits

resources: Esta seção configura os recursos de CPU e memória que o contêiner solicita e o limite máximo que pode usar. Ela contém dois subitens:

• requests: Define a quantidade mínima de recursos que o contêiner precisa para ser executado. Isso garante que, quando o pod for agendado, o nó terá pelo menos essa quantidade de recursos disponível.

• limits: Define a quantidade máxima de recursos que o contêiner pode usar. O contêiner pode consumir mais do que o request, mas nunca ultrapassará o valor do limit.

Análise Detalhada dos Recursos

requests

• memory: "64Mi": Especifica que o contêiner solicita 64 MiB (Mebibytes) de memória. Isso significa que o Kubernetes tentará agendar este pod apenas em nós que tenham pelo menos 64 MiB de memória disponível.

• cpu: "250m": Especifica que o contêiner solicita 250 milicores (ou 0,25 core) de CPU. Esse é o recurso de CPU mínimo que o Kubernetes garantirá para o contêiner, mas ele pode usar mais até o limite especificado.

limits

• memory: "128Mi": Especifica que o contêiner terá um limite máximo de 128 MiB de memória. Se o contêiner tentar usar mais do que isso, o Kubernetes poderá terminá-lo com um erro de OutOfMemory (OOM).

• cpu: "500m": Especifica que o contêiner terá um limite máximo de 500 milicores (ou 0,5 core) de CPU. Isso significa que o contêiner poderá consumir até metade de um núcleo de CPU, mas não mais do que isso.

Limit Range

Por padrão os contêineres são executados com recursos de computação ilimitados no cluster. O limit range é uma política para restringir as alocações de recursos que você pode especificar para objetos como Pod e PersistenVolumeClaim em um namespace específico.

Um LimitRange fornece restrições que podem:

• Definir o uso mínimo e máximo de recursos de computação por pod ou contêiner em um namespace.

• Aplicar solicitação de armazenamento mínimo e máximo por PersistentVolumeClaim em um namespace.

• Definir uma proporção entre solicitação e limite para um recurso em um namespace.

• Definir solicitação/limite padrão para recursos de computação em um namespace e injetá-los automaticamente em contêineres em tempo de execução.

apiVersion: v1
kind: LimitRange
metadata:
  name: resources-limits
  namespace: default
spec:
  limits:
  - type: Container
    max:
      cpu: "2"           # Máximo de 2 cores de CPU por contêiner
      memory: "1Gi"      # Máximo de 1 GiB de memória por contêiner
    min:
      cpu: "200m"        # Mínimo de 200 milicores (0.2 cores) de CPU por contêiner
      memory: "100Mi"    # Mínimo de 100 MiB de memória por contêiner
    default:
      cpu: "500m"        # Solicitação padrão de CPU se não especificado
      memory: "200Mi"    # Solicitação padrão de memória se não especificado
    defaultRequest:
      cpu: "300m"        # Request padrão de CPU para contêineres que não especificarem um valor
      memory: "150Mi"    # Request padrão de memória para contêineres que não especificarem um valor

Definição de LimitRange para Contêiner no namespace default

LimitRange para PersistentVolumeClaim

Outro uso comum do LimitRange é para definir limites em PersistentVolumeClaims (PVCs). Isso pode garantir que o armazenamento seja usado de forma responsável.

apiVersion: v1
kind: LimitRange
metadata:
  name: storage-limits
  namespace: default
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: "10Gi"    # Máximo de 10 GiB de armazenamento por PVC
    min:
      storage: "1Gi"     # Mínimo de 1 GiB de armazenamento por PVC

Definição de LimitRange para PVCs no namespace default

Resource Quotas

A cota por recursos é definido por um objeto ResourceQuota, e fornece restrições que limitam o consumo de recursos por namespace. Ele pode limitar a quantidade de objetos que podem ser criados em um namespace por tipo.

Para recursos de CPU e Memória, ResourceQuota impõe que cada novo pod nesse namespace defina um limite para esse recurso. Se você aplicar uma cota de recursos em um namespace para CPU ou memória, o requests e limits sempre deverão ser especificados para o pod enviado. Caso contrário a admissão do pod poderá ser rejeitada.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota
  namespace: default
spec:
  hard:
    pods: "10"                      # Limita o número máximo de pods para 10
    requests.cpu: "2"               # Limita o total de requests de CPU para 2 cores
    requests.memory: "1Gi"          # Limita o total de requests de memória para 1 GiB
    limits.cpu: "4"                 # Limita o total de CPU para 4 cores
    limits.memory: "2Gi"            # Limita o total de memória para 2 GiB

Definição de ResourceQuota para o namespace default

1. pods: "10": Limita o número total de pods que podem ser criados no namespace default a 10. Se um usuário tentar criar mais do que 10 pods, o Kubernetes irá bloquear a criação.

2. requests.cpu: "2": Define que a soma de todas as solicitações de CPU (requests.cpu) dos pods no namespace não pode ultrapassar 2 núcleos. Ou seja, se os pods no namespace já estiverem usando 2 núcleos de CPU solicitados, não será possível agendar novos pods que aumentem essa demanda.

3. requests.memory: "1Gi": Limita o total de memória solicitada pelos pods no namespace para 1 GiB. Esse é o valor máximo acumulado de requests.memory que todos os pods combinados podem solicitar.

4. limits.cpu: "4": Define que o consumo máximo de CPU para o namespace é de 4 núcleos. Esse limite considera o uso de limits.cpu, o que significa que o Kubernetes permitirá a criação de pods até que o consumo total de CPU atinja esse valor.

5. limits.memory: "2Gi": Define que o total máximo de memória, usando limits.memory, é de 2 GiB. Isso limita o uso total de memória dentro do namespace.

Conclusão

Entender as diferentes formas de agendamento de pods no Kubernetes é essencial para aproveitar ao máximo a infraestrutura e garantir que os recursos sejam utilizados de maneira inteligente e equilibrada.

Desde as políticas de afinidade e anti-afinidade até quotas e limites de recursos, cada técnica contribui para um ambiente mais resiliente e adaptado às necessidades da sua aplicação.

Até a próxima.

Neste artigo, explico como configurar alertas no Grafana para monitorar métricas e enviar notificações por e-mail. Após revisar as etapas básicas, como ajustar as configurações do SMTP no Grafana via docker-compose e definir pontos de contato para alertas, mostro como criar uma política de notificação e configurar alertas específicos para, por exemplo, uso de CPU ou disco. O artigo é parte de uma série sobre monitoramento com Grafana e Prometheus, voltado para usuários que desejam aprimorar suas habilidades de monitoramento e alerta.

Fala pessoal tudo beleza?

Se você está lendo este artigo pela primeira vez, saiba que ele faz parte de uma série onde explico como montar uma stack de monitoramento usando Grafana e Prometheus com Docker e Docker Compose.

Neste artigo, parte 4, vamos entender como funciona o envio de notificações e criar um alerta no Grafana para uma métrica específica. Quando esse alerta for acionado, um e-mail será enviado para notificar sobre o incidente.

O Grafana disponibiliza vários recursos que nos ajudam no gerenciamento de alertas, podendo criar rótulos, adicionar políticas de notificação e a integração com várias ferramentas de chats, como o Slack, Discord, Telegram, Microsoft Teams entre outras. Nesse link da documentação contém uma lista de todas as ferramentas.

Pré requisitos

• Ter uma instância do Grafana em execução.

• Ter acompanhado os artigos anteriores onde subimos uma stack do Grafana e Prometheus.

Caso queira, pode acessar os arquivos dessa stack clicando aqui.

Obs: A versão do Grafana utilizada nesse artigo foi a v10.4.1. Versões mais antigas ou futuras podem conter diferenças.

Grafana Alerta

O Grafana Alerta permite que sua equipe de monitoramento seja alertada sobre as métricas e logs. Ele consolida em uma única página todos seus alertas gerenciados pelo Grafana ou por outras fonte de dados compatível com o Prometheus.

Uma regra de alerta pode alertar sobre vários itens de uma só vez e você pode também agrupar instâncias de alertas com base em rótulos para não receber muitas notificações de uma só vez.

Como funciona o Grafana Alerta

Basicamente, temos uma regra de alerta que é criada em base de uma métrica, por exemplo, o uso de CPU ou memória de um servidor.

Os rótulos correspondem as instâncias de alerta às políticas de notificação e podem ser usadas para agrupar seus alertas por gravidade.

Como funciona o Grafana Alerta - Fonte: Grafana

A política de notificação é o conjunto de regras para onde, quando e como os alertas são roteados.

Os pontos de contatos definem como seus contatos são notificados quando um alerta é acionado.

Conhecendo a página de Alertas do Grafana

A página de alertas é acessada no menu lateral clicando em Alerting ➡ Alert rules. Nessa primeira página, irá conter os alertas que foram criados através da interface do Grafana e alertas que foram criados a partir de uma fonte de dados como o Prometheus.

Antes de criarmos nosso primeiro alerta, devemos configurar o SMTP no Grafana para que os e-mails possam ser enviados, e assim poder criar nosso Ponto de Contato.

Configurando um SMPT

Para esse passo, você deve ter um SMPT em qualquer provedor de internet para poder enviar alertas, estou usando o serviço de e-mail da SparkPost.

Como estamos usando a stack do docker, iremos alterar o arquivo docker-compose.yaml adicionando algumas variáveis de configuração do SMTP.

services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: always
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    environment:
      - GF_SECURITY_ADMIN_USER=${GF_SECURITY_ADMIN_USER}
      - GF_SECURITY_ADMIN_PASSWORD=${GF_SECURITY_ADMIN_PASSWORD}
      - GF_INSTALL_PLUGINS=${GF_INSTALL_PLUGINS}
      - GF_SMTP_ENABLED=${GF_SMTP_ENABLED}
      - GF_SMTP_HOST=${GF_SMTP_HOST}
      - GF_SMTP_USER=${GF_SMTP_USER}
      - GF_SMTP_PASSWORD=${GF_SMTP_PASSWORD}
      - GF_SMTP_FROM_ADDRESS=${GF_SMTP_FROM_ADDRESS}
      - GF_SMTP_FROM_NAME=${GF_SMTP_FROM_NAME}
      - GF_SERVER_ROOT_URL=${GF_SERVER_ROOT_URL}
    ports:
      - 3000:3000
    networks:
      - monitoring

Arquivo docker-compose.yaml

Entendendo as variáveis de configuração para o caso do servidor SparkPost:

• GF_SMTP_ENABLED: true para ativar o serviço

• GF_SMTP_HOST: host do servidor SMTP, ex: smtp.sparkpostmail.com:2525

• GF_SMTP_USER: usuário do servidor SMTP, ex: SMTP_Injection

• GF_SMTP_PASSWORD: <api_key>

• GF_SMTP_FROM_ADDRESS: e-mail de um domínio válido configurado no SparkPost

• GF_SMTP_FROM_NAME: nome do remetente de envio

• GF_SERVER_ROOT_URL: url do grafana hospedado

Após adicionar essas variáveis de ambiente ao arquivo do docker-compose, adicione essas mesmas variáveis com os seus valores no arquivo .env na raiz do projeto.

Suba o ambiente com o comando docker-compose up -d. Verifique os logs para validar se os containers subiram corretamente sem erros, também pode usar docker-compose ps para ver os status de cada um deles.

Pontos de contato

Os pontos de contato são as configurações que definimos como os usuários serão notificados quando um alerta é acionado, seja por um e-mail, uma mensagem no Slack, Microsoft Teams ou qualquer outra ferramenta de chat suportada pelo Grafana.

Para isso, clique no menu lateral em Alerting ➡ Contact points e em seguida no botão Add contact point.

Na página de configuração, dê um nome para o alerta, nesse caso será My Company Alerts - Email. Em Integration escolha o tipo E-mail, no campo Addresses adicione um e-mail que deseja receber as notificações.

As outras opções não iremos alterar, mas caso queiram podem dar uma olhada nelas. Após inserir as informações, clique no botão Test para testar o envio de e-mail e clique em Save contact point.

Tela de criação de um ponto de contato

Política de notificação

As políticas de notificação determinam como os alertas são roteados para os pontos de contato.

As políticas possuem uma estrutura em árvore, onde cada política pode ter uma ou mais políticas aninhadas. Cada política, exceto a política padrão, também pode corresponder a rótulos de alerta específicos.

Cada alerta é avaliado pela política padrão e, posteriormente, por cada política aninhada.

Acesse a página de criação da política clicando no menu lateral em Alerts ➡ Notification policies. Na política padrão clique no menu suspenso e em Editar. No campo de ponto de contato padrão, escolha o ponto de contato que criamos anteriormente, chamado My Company Alerts - Email.

As próximas informações não serão alteradas, vamos deixar as configurações padrões. Mas estarei explanando pelas configurações disponíveis.

Em Group by, podemos escolher rótulos para agrupar os alertas. Se vários alertas corresponderem a esta política, eles serão agrupados por esses rótulos. Uma notificação é enviada por grupo, se o campo estiver vazio, todas as notificações serão enviadas em um único grupo.

Em Timing options, há três opções que podem ser configuradas:

• Group wait: Tempo de espera para armazenar alertas do mesmo grupo antes de enviar uma notificação inicial. Padrão é 30 segundos.

• Group interval: Intervalo de tempo mínimo entre duas notificações para um grupo. Padrão é 5 minutos.

• Repeat interval: Intervalo de tempo mínimo para reenviar uma notificação caso nenhum alerta novo tenha sido adicionado ao grupo. Padrão é de 4 horas.

Editando a política de notificação padrão

Criando um alerta

Para criar nosso primeiro alerta, clique no botão New alert rule no lado direito para ser direcionado à página de configuração.

Essa tela é dividida em 5 sessões.

1. Nome do alerta: deve ser informado um nome para identificar seu alerta, por exemplo: Uso de CPU acima de 90%.

2. Definição da query e condição do alerta: é onde definimos a query e a condição do alerta, ou seja, através da query podemos selecionar as métricas que iremos acompanhar e dizer que essa métrica deve ter alguma condição atrelada, como por exemplo: "Se durante 1 hora o uso de CPU tiver acima de 90%, a condição do alerta deve ser disparado".

3. Definição do comportamento de avaliação: deve determinar com que frequência uma regra de alerta deve ser avaliada e com que rapidez ela deve alterar seu estado.

4. Configurar rótulos e notificações: anote suas regras com rótulos para facilitar uma pesquisa ou o direcionamento para uma política de notificação.

5. Adicionar anotações: informações para complementar a mensagem de notificação enviada.

Criando um alerta de uso de disco

Vamos criar um alerta e para isso, insira um nome, nesse exemplo vamos dar o nome de Uso do disco > 80%.

Na sessão dois, iremos definir a condição que queremos que o Grafana fique observando para que qualquer anomalia que venha ocorrer, um alerta seja disparado.

Para isso, clique no botão Code no canto direito e cole a query abaixo no campo de métricas:

100 - ((node_filesystem_avail_bytes{job="node_exporter",device!~'rootfs',mountpoint="/"} * 100) / node_filesystem_size_bytes{job="node_exporter",device!~'rootfs',mountpoint="/"})

Para validar a query, clique no botão Run queries no canto direito. Será exibido mais abaixo, uma tabela contendo os valores encontrados em sua base de dados do Prometheus. Se você tiver seguindo esse tutorial desde o início, a seguinte tela será exibida com apenas uma entrada, caso contrário, irá aparecer as referências da sua base atual.

Definindo query e condição de alerta

Explanando sobre a query utilizada, podemos resumir da seguinte maneira:

100 - ((espaço_disponível * 100) / tamanho_total)

Isso é feito para representar a porcentagem de espaço livre, ou seja, 100 menos a porcentagem do espaço ocupado. Este cálculo é comum em monitoramento de sistemas para avaliar rapidamente a capacidade restante em um sistema de arquivos.

Mais abaixo, podemos ver duas caixas que são chamadas de Expressões (B e C). Nessas caixas podemos manipular o resultado da expressão A. Veja que na expressão B, existe um warning dizendo que a operação de Reduce não é necessária devido que a expressão A já contém os dados tratados, podemos dizer que os dados obtidos na primeira expressão já estão prontos para criação do alerta.

Caixa de expressões para configuração do alerta

Nesse caso, vamos remover a expressão B, clicando no ícone de lixeira no canto direito.

Para mantermos uma consistência de letras, renomeie a expressão C para B e altere o campo Input para A (isso é opcional, mas meu toque não me deixa ver essa sequência quebrada).

No campo abaixo, mantenha a opção Is above (acima de) selecionada e coloque o valor 80. Essa expressão diz ao Grafana que quando o resultado da expressão A for acima de 80% (uso de armazenamento do disco), um alerta seja disparado.

Na terceira sessão, iremos configurar o comportamento do alerta, como ele será avaliado. Os alertas são armazenados dentro de uma pasta, sendo necessário escolher uma existente ou podendo criar uma. Vamos criar uma pasta chamada Alerts.

Em Evaluation group (grupo de avaliação), deve escolher um grupo existente ou criar um para que você possa agrupar alertas que devem ser avaliados dentro de um determinado período. Vamos criar um grupo chamado de Usage resources e definir um intervalo de avaliação de 2 minutos.

No campo Pending period (período pendente), deve ser informado o período que uma regra de alerta pode violar a condição até que a regra de alerta seja acionada, ou seja, esse será o período em que o Grafana irá aguardar até que o alerta seja disparado por definitivo, enviando uma notificação pelos canais configurados. Se dentro desse período a regra de alerta for resolvida o alerta não será disparado.

Definindo comportamento de avaliação

Na quarta sessão, podemos configurar rótulos para anotar os alertas, facilitando uma pesquisa ou direcionando para uma política de notificação.

Os rótulos podem ser criados conforme sua necessidade e cenário. Para esse exemplo, iremos criar dois, um chamado company que terá como valor o nome da empresa, My Company e outro será resource_type que terá como o valor disk, apenas para dizer que o alerta se trata de um problema relacionado a recursos, que nesse caso é o uso do disco.

Clicando no botão Preview routing, será exibido qual política de notificação será usada para esse disparo, veja que a política exibida é a padrão que utilizará o ponto de contato já configurado nos passos anteriores.

Configurando labels e notificações

Na quinta sessão, é possível customizar um pouco mais o conteúdo do e-mail enviado. Além dos três campos pré-definidos como o resumo e descrição, podemos adicionar mais rótulos.

Após o preenchimento de todos os campos, podemos finalmente salvar o alerta clicando no botão Save rule and exit no canto superior direito.

E para sabermos se tudo está funcionando como deveria? Na prática, esse alerta só será disparado quando o disco estiver acima de 80% em uso, provavelmente em nosso ambiente de desenvolvimento, nossa máquina estará abaixo disso.

Então para validarmos vamos diminuir o critério de avaliação de 80 para 30. Clique em editar seu alerta e altere apenas a configuração de avaliação do alerta e clique em salvar. Aguarde pelo menos 2 minutos que você verá na tela inicial de alertas que o status será alterado para pending e logo após para firing.

Se tudo estiver correto, você irá receber um e-mail bem parecido com a imagem abaixo.

E-mail de alerta para uso excedido do disco

Edite seu alerta novamente voltando o critério de avaliação de 30 para 80 e aguarde até que tudo seja normalizado. Assim que o Grafana identificar que as coisas voltaram ao normal, que não existe mais alertas, um novo e-mail será enviado mas com o objetivo de informar que o incidente que acabará de ser notificado, foi resolvido.

E-mail de alerta de incidente resolvido

Conclusão

Com este artigo foi possível entender os principais recursos do Grafana Alerta. Passamos pelo ponto de contato, política de notificação, criação do alerta além da configuração do SMTP e o fluxo de envio de notificações.

Espero que de alguma maneira posso ter ajudado com esse artigo e qualquer dúvida, melhorias ou comentários, não deixe de comentar abaixo.

E não deixe de acompanhar a série dos artigos sobre a stack Prometheus e Grafana que estou escrevendo.

Até a próxima.

Esse artigo é uma extensão de um artigo que escrevi há alguns anos, onde fiz a criação de um simples script de backup para bancos Mysql.

Hoje estarei refatorando aquele primeiro script e adicionando uma opção para poder armazenar o backup no S3 da AWS.

Caso queira ver o primeiro artigo que escrevi, acesse aqui.

Instalando AWS S3 CLI

Primeiro vamos instalar e configurar a ferramenta de CLI que a AWS fornece para podermos interagir com os recursos na nuvem.

A instalação será feita em um sistema Linux, para a instalação em outros sistemas, pode ser encontrado nesse link.

Execute os comandos:

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

$ unzip awscliv2.zip

$ sudo ./aws/install

Podemos confirmar se a instalação ocorreu com sucesso, com o comando:

$ aws --version

aws-cli/2.10.3 Python/3.9.11 Linux/5.10.0-21-amd64 exe/x86_64.debian.11 prompt/off

Caso já tenha o aws-cli instalado, poderá verificar se há alguma atualização para ser feita. No terceiro comando mostrado acima, pode usar a flag --update para atualizar para a versão mais recente.

$ sudo ./aws/install --update

You can now run: /usr/local/bin/aws --version

Criando usuário na AWS

Agora é necessário configurar o aws-cli com as credenciais de um usuário, para isso é necessário ter uma conta na AWS.

Nesse artigo irei pressupor que você já tem uma conta na AWS, não irei abordar o processo de criação de conta, mas iremos passar pela criação de um usuário programático e gerar as credenciais.

Com o foco na segurança, esse usuário terá um permissão restrita a um determinado bucket no S3, podendo apenas realizar ações nesse bucket e não tendo acesso nenhum a outros bucket que não seja o que definimos.

Acesse o console da AWS e navegue até a sessão do IAM.

1. No menu esquerdo, clique em Usuários.

2. Na tela de listagem de usuários, clique em Adicionar usuários.

3. Informe o nome de usuário, nesse exemplo vamos criar um usuário chamado backup-s3. Clique em Próximo.

4. Nessa tela, iremos adicionar uma política ao usuário. Clique no card Anexar políticas diretamente.

5. Na listagem de políticas, clique em Criar política.

6. Na tela de criação, clique na aba JSON para informar a política manualmente.

7. Copie a seguinte política e cole no editor de política - Altere o nome do bucket conforme sua preferência, nesse exemplo estou usando backups-aristides-dev

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::backups-aristides-dev/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::backups-aristides-dev"
            ]
        }
    ]
}

8. Clique em Próximo duas vezes até chegar na tela para informar o nome da política.

9. Informe o nome BackupS3ReadWriteAccess e clique em Criar política.

10. Nesse ponto, a política foi criada. Volte para a aba inicial e procure na listagem a política que acabou de ser criada, selecione ela e clique em Próximo.

11. Revise os dados e clique em Criar usuário.

Até aqui acabamos de criar um usuário e anexamos uma política para que esse usuário tenha acesso somente a um bucket chamado backups-aristides-dev. Com essa política, o usuário poderá executar as ações de Leitura/Escrita/Remoção de arquivos dentro do bucket.

Para dar continuidade precisamos que o bucket já esteja criado. Para isso crie um bucket pela console da AWS com o mesmo nome que foi definido por você ao criar a política, no meu caso backups-aristides-dev. Não irei abordar a criação por se tratar de um passo simples, apenas informe o nome e deixe as opções padrões do bucket.

Gerar credenciais de segurança

Após a criação do usuário e do bucket, acesse novamente a listagem de usuários do IAM e clique sobre o usuário backup-s3 que acabamos de criar.

1. Na aba Credenciais de segurança, na sessão Chaves de acesso, clique em Criar chave de acesso.

2. Selecione a opção Command Line Interface (CLI), marque o checkbox Compreendo a recomendação acima e quero prosseguir para criar uma chave de acesso. e clique em Próximo.

3. Caso queira deixar alguma descrição (essa informação é opcional), informe na caixa de texto e clique em Criar chave de acesso.

4. Esse passo é muito importante, as chaves geradas serão mostradas apenas uma vez na tela. Clique em Baixar arquivo .csv e salve em um lugar seguro as credenciais.

5. Após baixar o arquivo .csv, clique em Concluído.

Configurando AWS S3 CLI

Após todo os passos acima de criação de usuário e geração das chaves de acesso, devemos configurar a ferramente de CLI para podermos interagir com o S3.

Execute o comando abaixo para configurar o acesso e informe as credenciais do usuário criado.

$ aws configure

AWS Access Key ID [None]: <access-key-id>
AWS Secret Access Key [None]: <secret-access-key>
Default region name [None]: us-east-1
Default output format [None]: json

Para validarmos o acesso, vamos copiar um arquivo para o bucket e em seguida listarmos.

# Cria um arquivo de teste com conteúdo
$ touch teste.txt && echo "Backup Mysql" > teste.txt

# Copia o arquivo criado para o bucket
$ aws s3 cp teste.txt s3://backups-aristides-dev/
upload: ./teste.txt to s3://backups-aristides-dev/teste.txt

# Lista o conteúdo do bucket
$ aws s3 ls s3://backups-aristides-dev/
2023-03-11 18:45:18          13 teste.txt

Podemos validar também se o nosso usuário tem acesso para visualizar outros buckets:

# Para listar todos os bucket no S3
$ aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

# Copiando um arquivo para outro bucket
$ aws s3 cp teste.txt s3://meu-bucket-pessoal/       
upload failed: ./teste.txt to s3://meu-bucket-pessoal/teste.txt An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

Show de bola, como visto acima o usuário criado tem acesso somente a um determinado bucket. Com isso nós garantimos uma segurança a mais para o nosso script de backup.

Script de backup Mysql

Nesse script, deixei toda parte do código comentado para um melhor entendimento de cada linha. Mas em resumo o script executará os seguintes passos:

1. Define algumas variáveis que serão usadas durante a execução do script.

2. Define o nome dos bancos de dados que devem ser realizado o backup.

3. Verifica se o diretório de armazenamento dos arquivos e do log existem, caso não, serão criados.

4. Faz um loop nos bancos de dados para realizar o backup, compactar e sincronizar com o S3.

5. O script irá sincronizar todo o conteúdo do diretório de backup, caso um arquivo já exista no S3, esse não será enviado novamente.

6. Remove arquivos de backups antigos conforme a quantidade de dias determinada. Essa remoção será somente do servidor, no S3 os arquivos irão ser mantidos normalmente.

Abaixo segue todo o código de backup:

#!/bin/bash
# 
# Autor: Aristides Neto
# Email: falecom@aristides.dev
#
# Data: 11/03/2023
#
# Realiza o backup de bancos de dados MySQL
# Sincroniza com o S3 da AWS
#

# Define usuario e senha do banco
USER='root'
PASS='root'

# Datas
DIA=`date +%d`
MES=`date +%m`
ANO=`date +%Y`
DATA_ATUAL=`date +%Y-%m-%d-%H-%M`

# Data de Inicio do Backup
DATA_INICIO=`date +%d/%m/%Y-%H:%M:%S`

# Caminho do arquivo de log
LOG_DIR=/var/log/backup
LOG=$LOG_DIR/backup_db_$ANO$MES$DIA.log

# Diretorio onde serão salvos os backups
DIR_BK=/backups/mysql

# Lista dos bancos de dados que serão realizados o backup
DATABASES=(banco01 banco02)

# Verifica se existe o diretorio para armazenar os logs
if [ ! -d $LOG_DIR ]; then
    mkdir $LOG_DIR
fi

# Verifica se existe o diretorio para o backup
if [ ! -d $DIR_BK ]; then
    mkdir -p $DIR_BK
fi

# Inicio do backup
echo -e "MYSQLDUMP Iniciado em $DATA_INICIO\n" >> $LOG

# Loop para backupear todos os bancos
for db in "${DATABASES[@]}"; do
    # Mysql DUMP
    # Para backupear procedures e functions foi adicionado o --routines
    echo "...Realizando backup do banco ...........................[ $db ]" >> $LOG
    mysqldump --routines -u$USER -p$PASS $db > $DIR_BK/$db'_'$DATA_ATUAL.sql

    # Compacta o arquivo sql em BZ2
    echo "...Compactando arquivo de backup ........................[ $db ]" >> $LOG
    bzip2 $DIR_BK/$db'_'$DATA_ATUAL.sql

    # Sincroniza o diretório local com o bucket S3
    aws s3 sync $DIR_BK s3://backups-aristides-dev
    echo "...Sincronização do diretório de backup com S3 ..........[ OK ]" >> $LOG
done

DATA_FINAL=`date +%d/%m/%Y-%H:%M:%S`
echo -e "\nMYSQLDUMP Finalizado em $DATA_FINAL\n" >> $LOG

# Remove arquivos de backups antigos - 5 dias
find $DIR_BK -type f -mtime +5 -exec rm -rf {} \;

Para executar esse script recomendo que seja feito com o usuário root, pois serão criados diretórios e arquivos em locais que serão necessárias permissões de super usuário. Caso deseja executar com um usuário não root, certifique que terá as permissões corretas.

Log de execução do script

Ao executar o script, será criado um arquivo de log no caminho definido na variável LOG => /var/log/backup que conterá informações do banco backupeado e sincronização com o S3.

Esse é um arquivo bem simples, mas é uma forma de monitorar o andamento do backup.

MYSQLDUMP Iniciado em 11/03/2023-19:00:34

...Realizando backup do banco ...........................[ banco01 ]
...Compactando arquivo de backup ........................[ banco01 ]
...Sincronização do diretório de backup com S3 ..........[ OK ]

...Realizando backup do banco ...........................[ banco02 ]
...Compactando arquivo de backup ........................[ banco02 ]
...Sincronização do diretório de backup com S3 ..........[ OK ]

MYSQLDUMP Finalizado em 11/03/2023-19:04:14

Conclusão

Esse é um script simples, que não contém validações em caso de possíveis erros nos comandos executados. É uma boa prática e recomendado adicionar validações nos comandos executados e validar se foi executado com sucesso ou não.

Não será o foco desse artigo essa implementação, mas recomendo que tenha validações e em casos de erros tenha um alerta, seja o envio de um e-mail ou uma notificação em um canal como o Slack, Microsoft Teams ou outro. Esses programas disponibilizam um webhook para esses casos que irá te ajudar a enviar as notificações.

Espero que seja útil esse script e qualquer dúvida, melhorias ou comentários, não deixe de comentar abaixo.

Até a próxima.

Neste artigo, parte 3 de uma série sobre monitoramento com Grafana, Prometheus, Docker e Docker Compose, exploramos a configuração de alertas personalizados utilizando o Prometheus e o Alertmanager. Aprendemos a instalar e integrar o Alertmanager com o Prometheus para enviar alertas por e-mail, criamos regras de alerta no Prometheus para monitorar uptime e uso de CPU, e configuramos o Alertmanager para enviar notificações via SMTP. Além disso, validamos todo o processo simulando condições de alerta e observamos como as notificações são disparadas e resolvidas.

Fala pessoal tudo beleza?

Se você está lendo este artigo pela primeira vez, saiba que ele faz parte de uma série onde explico como montar uma stack de monitoramento usando Grafana e Prometheus com Docker e Docker Compose.

Neste artigo, parte 3, vou criar alertas personalizados para suas métricas no Prometheus e Alertmanager, que será responsável por enviar o evento para um e-mail.

Pré requisitos

• Ter uma instância do Prometheus em execução.

• Ter acompanhado os artigos anteriores onde subimos uma stack do Grafana e Prometheus.

Instalando o Alertmanager

O Alertmanager é um software que lida com alertas enviados por aplicativos clientes, como o servidor Prometheus. Ele é responsável em gerenciar esses alertas recebidos e encaminhar para algum cliente que esteja pré configurado, como um e-mail.

Com ele também é possível configurar o modo de silenciamento, ou seja, silenciar algum alerta já esperado por algumas horas ou apenas para o fim de semana.

Para subir uma instância do Alertmanager, iremos usar o docker. Para isso, utilize a stack que estamos criando nessa série de artigo e abra o arquivo docker-compose.yaml. Você pode encontrar no meu Github.

Para nosso exemplo de hoje com o Alertmanager, iremos usar o Node Exporter em uma imagem docker. No arquivo docker-comose.yaml já existe um serviço para ele, que está comentado. Descomente o bloco referente ao node_exporter e adicione logo abaixo o bloco do Alertmanager:

# Arquivo: docker-compose.yaml
services:

  # ...services

  # Exemplo de usar o exporter com o Docker ao invés do binário
  node_exporter:
    image: quay.io/prometheus/node-exporter:latest
    container_name: node_exporter
    command:
      - '--path.rootfs=/host'
    pid: host
    restart: always
    volumes:
      - '/:/host:ro,rslave'
    networks:
      - monitoring

  alertmanager:
    image: prom/alertmanager:v0.25.0
    container_name: alertmanager
    restart: always
    volumes:
      - ./alertmanager/:/etc/alertmanager/
    command:
      - '--config.file=/etc/alertmanager/config.yaml'
      - '--storage.path=/alertmanager'
    ports:
      - 9093:9093
    networks:
      - monitoring

Explicando algumas linhas importantes do Alertmanager no arquivo docker-compose.yaml:

1. No serviço alertmanager, informamos a versão do Alertmanager que será utilizada que é a 0.25.0 (a mais recente na data desse artigo).

2. Criamos um volume para mapear um arquivo de configuração para o Alertmanager, que ao iniciar o serviço essa configuração será aplicada.

3. Em command, estamos passando dois parâmetros para o Alertmanager, o primeiro --config.file informamos que o arquivo de configuração deve ser lido no diretório /etc/alertmanager/config.yaml e o segundo --storage.path informamos que o local de armazenamento dos dados serão armazenados no próprio host em /alertmanager.

4. Em ports estamos expondo a porta 9093 do host para a porta 9093 do container.

5. Em networks informamos ao docker-compose que iremos utilizar uma rede já criada por nós, que no caso é a rede monitoring.

Agora vamos subir os containers na nossa stack. No diretório raiz do projeto, execute o comando do docker compose para subir todas as instâncias de containers:

$ docker-compose up -d

Verifique se todos os containers estão em execução:

$ docker-compose ps
NAME                COMMAND                  SERVICE             STATUS              PORTS
alertmanager        "/bin/alertmanager -…"   alertmanager        running             0.0.0.0:9093->9093/tcp, :::9093->9093/tcp
grafana             "/run.sh"                grafana             running             0.0.0.0:3000->3000/tcp, :::3000->3000/tcp
node_exporter       "/bin/node_exporter …"   node_exporter       running             9100/tcp
prometheus          "/bin/prometheus --c…"   prometheus          running             0.0.0.0:9090->9090/tcp, :::9090->9090/tcp

Agora o Alertmanager está running e está acessível na porta 9093. Acesse o navegador com o endereço localhost:9093 e confirme se o Alertmanager irá carregar.

Tela inicial Alertmanager

Integrando Alertmanager com Prometheus

Já temos nossa instância do Alertmanager em execução, precisamos agora configurar o Prometheus para qualquer evento de alerta seja enviado ao Alertmanager e ele ser responsável em disparar para um cliente.

Abra o arquivo de configuração do Prometheus que está em prometheus/prometheus.yaml. Adicione a seguinte entrada no final do arquivo referenciando ao Alertmanager:

# ...

alerting:
  alertmanager:
  - scheme: http
    static_configs:
    - targets: 
      - 'alertmanager:9093'

prometheus/prometheus.yaml

Nesse bloco de código, informamos ao Prometheus que existe agora um cliente de alerta. Na sessão alerting criamos um, chamado alertmanager. Informamos que o Alertmanager está rodando no protocolo http e no host alertmanager:9093.

Vamos validar se o Prometheus reconheceu essa nossa configuração. Para isso reinicie o serviço do Prometheus com o comando:

$ docker-compose restart prometheus

Abra o Prometheus no seu navegador em localhost:9090 e navegue no menu Status -> Runtime & Build Information. Certifique que na sessão Alertmanagers, agora há um endpoint apontando para a instância do Alertmanager.

Com isso já temos a integração entre os dois serviços. Agora é necessário criar os alertas no Prometheus e quando acionado será enviado um evento de alerta para o Alertmanager.

Criando regras de alertas no Prometheus

Agora que já temos nossa instância em execução, vamos criar as regras de alertas no Prometheus. Para isso vamos criar um arquivo chamado alert.rules no diretório do prometheus.

Adicone o seguinte conteúdo nesse arquivo:

groups:

# Grupo de alertas: hosts
- name: hosts
  rules:
  - alert: Uptime
    expr: up == 0
    for: 15s
    labels:
      severity: critical
    annotations:
      summary: "O servidor {{ $labels.alias }} está offline!"
      description: "O servidor {{ $labels.alias }} parou de responder."

  - alert: Uso de CPU
    expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[2m])) by(instance) * 100) > 80
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: Consumo alto de CPU (instance {{ $labels.instance }})
      description: "O servidor {{ $labels.alias }} está com o consumo de CPU acima de 80%\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

prometheus/alert.rules

Foram criadas duas regras de alertas, onde o primeiro é o Uptime, que verifica se a instância está no ar e a segunda verifica o uso de CPU se está acima de 80% em um período de 2 minutos.

Lembre-se de validar as regras para seu ambiente antes de usar em produção.

Após criarmos o arquivo de regras, devemos informar ao Prometheus que ele deve carregar esse arquivo a aplicar suas configurações. Para isso abra novamente o arquivo prometheus/prometheus.yaml e adicione no inicio do arquivo o seguinte trecho:

# Arquivo: prometheus/prometheus.yaml
global:
  scrape_interval: 15s

# Carrega arquivo de regras de alertas
rule_files:
  - "alert.rules"

Nesse arquivo adicionamos a sessão de regras rules_files, que indica que o Prometheus deve carregar o arquivo correspondente que contém as regras de alertas.

Agora reinicie o Prometheus para aplicar as configurações:

$ docker-compose restart prometheus

Para validarmos todo esse processo, vamos abrir o Prometheus no navegador e acessar o menu Status -> Rules. Você verá a seguinte tela com as regras criadas.

Regras de alertas para Prometheus

Acesse também o menu Alerts, você verá as regras criadas e o status de cada uma.

Prometheus rules status Inactive

Nessa tela, é possível acompanhar o status de cada evento de alerta. Podemos ver os status:

• Inactive: Esse status significa que não há nenhum evento de alerta que possa ser acionado, ou seja, está tudo bem!

• Pending: Quando um alerta entra nesse status, quer dizer que alguma regra definida foi acionada, ficará nesse status pelo tempo determinado no arquivo de regras.

• Firing: Após o status de Pending, o status Firing entra em ação, após um evento ficar em espera por alguns segundos seu status muda para Firing e automaticamente é dispardo um alerta para o Alertmanager.

Configurando Alertmanager com SMTP

Agora é hora de configurar o Alertmanager com as informações de credenciais de e-mail usando o SMTP. Para isso, crie um arquivo config.yaml no diretório alertmanager. Cole o seguinte conteúdo no arquivo:

# Arquivo: alertmanager/config.yaml
global:
  smtp_smarthost: smtp.email.com:587
  smtp_from: noreply@email.com
  smtp_auth_username: noreply@email.com
  smtp_auth_password: suaSenhaAqui

route:
  group_by: ['alertname']
  group_interval: 5m
  group_wait: 30s
  receiver: 'email'
  repeat_interval: 3h

receivers:

  - name: 'email'
    email_configs:
    - to: alerta@gmail.com
      send_resolved: true

Você deve adicionar as suas configurações SMTP do seu provedor de e-mail.

Basicamente neste arquivo eu digo ao Alertmanager que ele deverá enviar um e-mail para receivers.name.email_configs: alerta@gmail.com após 30 segundos route.group_wait que ele receber o alerta.

Em receivers.name.email_configs.send_resolved: true informo que após a resolução de um incidente, o Alertmanager deverá enviar outro e-mail alertando que o incidente foi resolvido.

Defino o remetente padrão em route.receiver: email. Na sessão global informo as credenciais de e-mail SMTP.

Esse é um arquivo simples de configuração, é possível realizar mais configurações, realizar matchers dos e-mails e enviar para determinados grupos. Caso queira entender mais como funciona, acesse a documentação oficial.

Após criarmos esse arquivo de configuração, reinicie o serviço do Prometheus e Alertmanager:

$ docker-compose restart alertmanager

$ docker-compose restart prometheus

Validando toda a configuração

Vamos validar todo esse processo de configuração que fizemos, primeiro vamos ver o que acontece quando um dos hosts que está sendo monitorado fica down, por algum motivo seu servidor Linux não está mais acessível exportando as métricas, métricas essas que o Prometheus utiliza para saber da saúde do seu servidor.

Para simular um servidor que esteja down, vamos parar o container do node_exporter. Execute o comando:

$ docker-compose stop node_exporter

$ docker-compose ps
NAME                COMMAND                  SERVICE             STATUS              PORTS
alertmanager        "/bin/alertmanager -…"   alertmanager        running             0.0.0.0:9093->9093/tcp, :::9093->9093/tcp
grafana             "/run.sh"                grafana             running             0.0.0.0:3000->3000/tcp, :::3000->3000/tcp
node_exporter       "/bin/node_exporter …"   node_exporter       exited (143)        
prometheus          "/bin/prometheus --c…"   prometheus          running             0.0.0.0:9090->9090/tcp, :::9090->9090/tcp

Podemos ver que agora o container node_exporter está com o status de exited. Abra o Prometheus no navegador e acessa o menu Alerts.

Veja que agora o status está como Pending e depois de alguns segundos ficará como Firing.

Prometheus rules status pending

Prometheus rules status firing

Se abrirmos agora o Alertmanager no navegador, veremos que foi enviado um alerta para ele.

Alertmanager alerta recebido

Dentro de alguns instantes será enviado um e-mail informando que host está down, conforme imagem:

Prometheus Alert Host Down

Show de bola. Agora vamos consertar esse host que está fora, execute o comando abaixo para subir o container do node_exporter e vamos aguardar até que o Prometheus consiga se comunicar novamente com ele.

$ docker-compose up -d

$ docker-compose ps
NAME                COMMAND                  SERVICE             STATUS              PORTS
alertmanager        "/bin/alertmanager -…"   alertmanager        running             0.0.0.0:9093->9093/tcp, :::9093->9093/tcp
grafana             "/run.sh"                grafana             running             0.0.0.0:3000->3000/tcp, :::3000->3000/tcp
node_exporter       "/bin/node_exporter …"   node_exporter       running             9100/tcp
prometheus          "/bin/prometheus --c…"   prometheus          running             0.0.0.0:9090->9090/tcp, :::9090->9090/tcp

Veja no Prometheus no menu Alerts que o evento de alerta que antes estava como Firing voltará ao seu estado normal e desejado que é Inactive. Quando tudo tiver "verdinho" o Prometheus irá enviar um novo evento ao Alertmanager, só que agora um evento que informa que o host voltou a responder.

O Alertmanager por sua vez, irá remover o alerta e enviará um outro e-mail informando que o problema de host down foi resolvido.

Prometheus Alert Host UP

Mais uma vez, show de bola. Caso você queira fazer um teste também pelo alto consumo de CPU para receber o alerta, fique a vontade, pode até dimunuir o percentual de 80% para 30% apenas para validar o envio.

Acredito que chegamos ao fim desse artigo com o recebimento desse alerta.

Download código

Todo o código dessa stack você pode baixar pelo link do Github.

Conclusão

Nesse artigo fizemos a instalação, configuração e integração do Alertmanager com o Prometheus. Criamos duas regras de alertas e validamos o envio de uma delas.

O Alertmanager em si, o uso dele é bem simples, não estarei abordando ele aqui, mas acessando a página dele é possível criar alertas por lá e silenciar um alerta por um período de tempo. Para saber mais sobre o template de notificação acesse a documentação.

Espero que tenha ajudado até aqui.

Se você encontrar algum erro, sugestões de melhorias ou se tiver alguma dúvida, deixe seu comentário abaixo.

Até a próxima.

Neste artigo, mostramos como instalar e configurar o Node Exporter em um servidor Linux para exportar métricas que o Prometheus possa coletar e armazenar. Os passos incluem fazer download do Node Exporter, configurá-lo como um serviço do systemd, e garantir que inicie automaticamente com o sistema. Além disso, explicamos como ajustar o arquivo de configuração do Prometheus para iniciar a coleta dessas métricas e sugerimos um dashboard no Grafana para visualizá-las. Também discutimos a opção de usar o Node Exporter com Docker e fornecemos links para mais recursos e para o código completo no GitHub.

Fala pessoal tudo beleza?

Se você está lendo este artigo pela primeira vez, saiba que esta é uma série de artigos onde explico como montar uma stack de monitoramento usando Grafana e Prometheus com Docker e Docker Compose.

Neste artigo, parte 2, vou configurar um servidor Linux para exportar métricas que o Prometheus pode ler e armazenar em seu banco de dados, permitindo a análise em tempo real através de dashboards do Grafana.

Para isso é necessário instalar e configurar o node exporter, que é um arquivo binário que irá obter várias métricas de seu servidor Linux e expor em um endpoint HTTP. Para saber mais sobre o node exporter acesse a documentação.

Pré requisitos

• Ter acompanhado a parte 1 dessa série (Monitorando seus servidores com Grafana e Prometheus)

• Um servidor Linux instanciado em qualquer clodud ou em uma VM, por exemplo o Virtual Box

• Acesso via SSH a instância do servidor

Instalando Node Exporter

Para a instalação do node exporter você pode acessar o github do projeto e verificar qual a última versão disponível para download. No momento desse artigo, a última versão estável é a 1.5.0.

Acesse seu servidor via SSH e vamos começar com a instalação do exporter. Crie uma variável de ambiente apenas para facilitar no processo de instalação que irá conter o valor da versão do node exporter:

export VERSION=1.5.0

Os comandos listados abaixo, irão realizar o download do arquivo, descompactar e mover o arquivo binário do node exporter para o diretório /usr/local/bin.

curl -LO https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/node_exporter-${VERSION}.linux-amd64.tar.gz

tar -xvf node_exporter-${VERSION}.linux-amd64.tar.gz

sudo mv node_exporter-${VERSION}.linux-amd64/node_exporter /usr/local/bin/

Configurando Node Exporter

Até agora apenas baixamos e copiamos o binário para seu diretório, mas ainda é necessário configurar o serviço.

Crie um usuário no Linux para que possamos usar ele para executar o node exporter. Esse usuário só irá executar o binário, não sendo possível acessar via SSH com ele:

sudo useradd -rs /bin/false node_exporter

Crie um arquivo de inicialização no systemd para o binário:

sudo vim /etc/systemd/system/node_exporter.service

Cole o seguinte conteúdo dentro do arquivo node_exporter.service:

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Reinicie o deamon e inicie o serviço node_exporter que acabamos de criar:

# Reinicia o deamon e inicia o serviço 
sudo systemctl daemon-reload

sudo systemctl start node_exporter

Para gerenciar o serviço do node_exporter, você poderá usar os comandos:

# Os comandos start / restart / status / stop estarão disponíveis para o serviço
sudo systemctl status node_exporter

Após o start do serviço, se tudo ocorrer bem, o resultado deve ser o seguinte:

aristides@my-server:~$ sudo systemctl status node_exporter 
● node_exporter.service - Node Exporter
   Loaded: loaded (/etc/systemd/system/node_exporter.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-10-17 00:25:38 -03; 20s ago
 Main PID: 25276 (node_exporter)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/node_exporter.service
           └─25276 /usr/local/bin/node_exporter

Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - sockstat" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - stat" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - textfile" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - time" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - timex" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - uname" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - vmstat" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - xfs" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg=" - zfs" source="node_exporter.go:104"
Oct 17 00:25:38 my-server node_exporter[25276]: time="2022-10-17T00:25:38-03:00" level=info msg="Listening on :9100" source="node_exporter.go:170"

Como pode ser visto no log, o serviço está escutando na porta 9100. Se você acessar o endereço IP da sua instância http://IP-SERVIDOR:9100/metrics, terá um resultado semelhante a esse:

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 1.9151e-05
go_gc_duration_seconds{quantile="0.25"} 5.6041e-05
go_gc_duration_seconds{quantile="0.5"} 9.2601e-05
go_gc_duration_seconds{quantile="0.75"} 0.000134661
go_gc_duration_seconds{quantile="1"} 0.000524014
go_gc_duration_seconds_sum 0.250765764
go_gc_duration_seconds_count 1720
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 8
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.19.1"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 2.153176e+06
...

Pronto, você já está expondo as métricas do seu servidor Linux para que uma instância do Prometheus possa ler e armazenar em seu banco de dados.

Ative o serviço do node exporter para que sempre que o servidor reiniciar, o serviço seja iniciado automaticamente:

sudo systemctl enable node_exporter

Agora para seguir a diante, iremos usar a stack que criamos na parte 1 dessa séria, se você ainda não viu, recomendo dar uma olhada aqui nesse link para que você possa acompanhar sem grandes dúvidas as alterações necessárias no arquivo de configuração do Prometheus.

Configurando o Prometheus para "raspar" as métricas

Já estamos com o nosso servidor expondo as métricas na porta 9100, o que precisamos agora é configurar o Prometheus para que ele raspe esse servidor e colete suas métricas.

Para isso, abra o arquivo prometheus/prometheus.yaml. O arquivo contém esse conteúdo atualmente:

global:
  scrape_interval: 15s  # Por padrão, o alvo será 'raspado' a cada 15 segundos

scrape_configs:

  - job_name: 'prometheus'

    # Esse valor irá sobreescrever o valor padrão global para esse alvo
    scrape_interval: 5s

    metrics_path: /metrics # Endpoint padrão para a raspagem das métricas
    static_configs:
      - targets: ['localhost:9090']

Adicione a seguinte entrada:

global:
  scrape_interval: 15s  # Por padrão, o alvo será 'raspado' a cada 15 segundos

scrape_configs:

  - job_name: 'prometheus'

    # Esse valor irá sobreescrever o valor padrão global para esse alvo
    scrape_interval: 5s

    metrics_path: /metrics # Endpoint padrão para a raspagem das métricas
    static_configs:
      - targets: ['localhost:9090']

  # Nova entrada adicionada
  - job_name: 'node_exporter'
    scrape_interval: 5s
      - targets: ['IP-SEU-SERVIDOR:9100'] # <-- Insira o IP público do servidor
        labels:
          alias: webserver

Como visto acima, foi adicionado um novo JOB chamado de node_exporter, esse nome é sugestivo ao exporter, mas pode ser qualquer coisa.

Após adicionar a entrada de um novo target, reinicie o container docker caso ele esteja em execução ou inicie todos os containers:

docker-compose restart prometheus
# ou
docker-compose up -d

A partir desse momento, sua instância do Prometheus já deve estar recebendo os dados da sua instância Linux, dados esses de CPU, memória RAM, uso de disco, rede entre várias outras métricas.

Dashboard Node Exporter Full

Para visualizar métricas do node exporter, podemos utilizar um dashboard que está disponível no site do Grafana, você pode visualizar acessando esse link https://grafana.com/grafana/dashboards/1860-node-exporter-full.

Para usar esse dashboard, copie esse ID 1860 e no painel do Grafana, acesse o menu Dashboard e Importar. Insira esse ID na caixa de texto e clique em Carregar.

Após a importação, você terá esse belo Dashboard, com métricas de vários recursos da sua máquina. Show de bola!

Dashboard Node Exporter Full - Imagem 1

Dashboard Node Exporter Full - Imagem 2

Download código

Todo o código dessa stack você pode baixar pelo link do Github.

Conclusão

Nesse artigo fizemos a instalação e configuração do binário do node exporter, que irá expor métricas de CPU, memória RAM, uso de diso, de rede e tantas outras métricas.

Para seu conhecimento, caso você queira usar o node exporter através de uma imagem docker também é possível. Ao invés de baixar, instalar e configurar seu binário, é possível usar o docker para executar o exporter e expor a métricas da sua máquina Linux. Veja mais nesse link.

Ao usar o docker, se atente ao arquivo de configuração prometheus.yaml, pois deverá ajustar o target para que acesse o endpoint do container docker.

Espero que tenha ajudado até aqui.

Se você encontrar algum erro, sugestões de melhorias ou se tiver alguma dúvida, deixe seu comentário abaixo.

Até a próxima.

Neste artigo, você aprenderá a criar uma stack de monitoramento utilizando Grafana e Prometheus em containers com Docker e Docker-compose. Abordamos a configuração inicial do Grafana, incluindo volumes para armazenar dados e provisionar datasources automaticamente. Também mostramos como configurar o Prometheus para monitorar alvos específicos. Ao final, você terá um ambiente onde poderá acessar o Grafana e o Prometheus através de seus respectivos links para visualizar e gerenciar métricas em tempo real. Este é o ponto de partida para montar uma solução de monitoramento pronta para produção.

Fala pessoal tudo beleza?

Neste artigo, vou mostrar como configurar uma stack de monitoramento usando Grafana e Prometheus. Vou usar Docker para criar os containers com as imagens e Docker Compose para definir os requisitos dos containers.

Pré requisitos

• Docker e Docker-compose instalados em sua máquina

Configurando o Grafana

O Grafana é um projeto Open Source que centraliza a análise e a visualização das métricas através de gráficos de aplicações, de serviços de nuvens, de serviços como o kubernetes entre outros.

Para saber mais acesse a documentação oficial.

Para iniciar, crie uma rede no docker para podermos usar em nossa stack de monitoramento:

docker network create monitoring

Crie o diretório grafana-prometheus e em seguida crie o arquivo docker-compose.yaml. De início esse arquivo terá o conteúdo abaixo:

# Arquivo: docker-compose.yaml
version: "3.8"

volumes:
  grafana_data:

networks:
  monitoring:
    external: true

services:

  grafana:
    image: grafana/grafana:9.1.6
    container_name: grafana
    restart: always
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning/datasources
    environment:
      - GF_SECURITY_ADMIN_USER=${GF_SECURITY_ADMIN_USER}
      - GF_SECURITY_ADMIN_PASSWORD=${GF_SECURITY_ADMIN_PASSWORD}
      - GF_INSTALL_PLUGINS=${GF_INSTALL_PLUGINS}
    ports:
      - 3000:3000
    networks:
      - monitoring

Explicando algumas linhas importantes do arquivo docker-compose.yaml:

1. networks: Nessa linha informamos ao docker-compose que iremos utilizar uma rede já criada por nós (external: true), que no caso é a rede monitoring.

2. No serviço grafana, informamos a versão do Grafana que será utilizada que é a 9.1.6 (a mais recente na data desse artigo).

3. Criamos dois volumes, o primeiro para armazenar o banco de dados do Grafana, com as informações de usuários, configurações, dashboards, etc. O segundo volume é o mapeamento da pasta de provisionamento onde definimos o datasource padrão que será usado pelo Grafana assim que ele iniciar.

4. Nas variáveis de ambiente passamos alguns parâmetros do Grafana, esses valores estão sendo obtidos através de um arquivo .env na raiz do projeto.

5. Em ports estamos expondo a porta 3000 do host para a porta 3000 do container.

Para saber mais sobre todas as possíveis configurações do Grafana, acesse a sessão de Configuração da documentação.

Provisionando datasource

Como visto no serviço do Grafana, foi criado um volume que podemos adicionar um datasource de forma automatizada assim que o serviço do Grafana subir. Para isso, crie um arquivo chamado ds-prometheus.yaml dentro do diretório grafana/provisioning/, e cole o conteúdo abaixo:

# Arquivo: grafana/provisioning/ds-prometheus.yaml
datasources:
- name: Prometheus
  access: proxy
  type: prometheus
  url: http://prometheus:9090

Nesse arquivo informamos ao Grafana que ele irá cadastrar um datasource com o nome de Prometheus, também é informamdo outras configurações, como a url da instância do Prometheus e o modo de acesso.

Esse mesmo passo pode ser feito manualmente na interface do Grafana, acessando o menu Configuração e Datasources.

Arquivo de variáveis

Como visto acima, o Grafana recebe algumas variáveis que estão vindo do arquivo .env. Esse arquivo será responsável em armazenar todas as informações de senhas e algumas outras.

O uso desse arquivo torna o processo mais simples para manutenção, podendo reaproveitar variáveis quando necessário.

Crie o arquivo .env na raiz do diretório grafana-prometheus e cole o conteúdo abaixo:

# Arquivo: .env
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=password
GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-simple-json-datasource,grafana-worldmap-panel,percona-percona-app

Configurando o Prometheus

O Prometheus é um projeto Open Source usado para monitoramento e alertas. O Prometheus busca as métricas nos targets e grava em um banco de séries temporais, podendo visualizar essas métricas em tempo real.

Para saber mais acesse a documentação oficial.

Vamos agora adicionar ao arquivo docker-compose.yaml criado, o serviço do Prometheus. Adicione após o serviço do Grafana as seguintes linhas:

# Arquivo: docker-compose.yaml
...
volumes:
  grafana_data:
  prometheus_data: <-- volume adicionado

services:

  # Serviço do Prometheus adicionado
  prometheus:
    image: prom/prometheus:v2.37.1
    container_name: prometheus
    restart: always
    volumes:
      - ./prometheus/:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yaml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=360h'
      - '--web.enable-lifecycle'
    ports:
      - 9090:9090
    networks:
      - monitoring

Além do serviço do Prometheus, foi adicionado um volume para que o Prometheus possa salvar os dados dos seus alvos.

Explicando algumas linhas importantes do serviço do Prometheus:

1. No serviço prometheus informamos a versão do Prometheus que será usada, que no caso é a v2.37.1 (a mais recente no momento).

2. Criamos dois volumes, o primeiro é o diretório que contém o arquivo de configuração do Prometheus, o segundo volume é referente ao volume criado para salvar todas as métricas obtidas dos seus alvos.

3. Em command são passados alguns parâmetros de configuração para o Prometheus.

4. Em ports estamos expondo a porta 9000 do host para a porta 9000 do container.

Arquivo de configuração do Prometheus

O Prometheus precisa de um aquivo que irá determinar quais são os alvos que ele terá que raspar para obter as métricas.

Esses alvos podem ser uma aplicação web, um servidor linux, um banco de dados, um serviço na nuvem e todos eles devem exportar essas métricas em algum endpoint HTTP para que o Prometheus possa raspar e gravar esses valores em seu banco.

Crie um arquivo chamado prometheus.yaml dentro do diretório prometheus. Esse arquivo terá o seguinte conteúdo:

# Arquivo: prometheus/prometheus.yaml
global:
  scrape_interval: 15s  # Por padrão, o alvo será 'raspado' a cada 15 segundos

scrape_configs:

  - job_name: 'prometheus'

    # Esse valor irá sobreescrever o valor padrão global para esse alvo
    scrape_interval: 5s

    metrics_path: /metrics # Endpoint padrão para a raspagem das métricas
    static_configs:
      - targets: ['localhost:9090']

Nesse exemplo simples, o Prometheus irá se auto monitorar através de um endpoint, veja que o endpoint para isso é localhost:9090/metrics. Caso queira alterar o path padrão, basta alterar o atributo metrics_path.

Há diversas configurações possíveis para esse arquivo, você pode ver mais na documentação oficial.

Subindo a stack de monitoramento

Agora que passamos pelos dois serviços e falamos um pouco sobre suas configurações, vamos ver isso funcionar. Mas antes, vamos ver como ficou todo o arquivo do docker-compose.yaml.

# Arquivo: docker-compose.yaml
version: "3.8"

volumes:
  grafana_data:
  prometheus_data:

networks:
  monitoring:
    external: true

services:

  grafana:
    image: grafana/grafana:9.1.6
    container_name: grafana
    restart: always
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning/datasources
    environment:
      - GF_SECURITY_ADMIN_USER=${GF_SECURITY_ADMIN_USER}
      - GF_SECURITY_ADMIN_PASSWORD=${GF_SECURITY_ADMIN_PASSWORD}
      - GF_INSTALL_PLUGINS=${GF_INSTALL_PLUGINS}
    ports:
      - 3000:3000
    networks:
      - monitoring

  prometheus:
    image: prom/prometheus:v2.37.1
    container_name: prometheus
    restart: always
    volumes:
      - ./prometheus/:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yaml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=360h'
      - '--web.enable-lifecycle'
    ports:
      - 9090:9090
    networks:
      - monitoring

E a estrutura de diretórios e arquivos ficou assim:

grafana-prometheus
├── docker-compose.yaml
├── .env
├── .env.example
├── grafana
│   └── provisioning
│       └── ds-prometheus.yaml
└── prometheus
    └── prometheus.yaml

3 directories, 5 files

Podemos validar nosso arquivo compose para certificar que as variáveis de ambiente estão sendo passadas corretamente para o docker-compose:

$ docker-compose config

Todo o conteúdo do arquivo será impresso na tela e os valores das variáveis contidas no .env deverá assumir as variáveis do serviço do Grafana.

Se tudo tiver ok, execute o comando docker-compose up -d para subir os containers e aguarde até que seja feito o download das imagens e estejam prontos. Assim que terminar você pode executar o comando abaixo para certificar que tudo está rodando como deveria:

$ docker-compose ps

NAME                COMMAND                  SERVICE             STATUS              PORTS
grafana             "/run.sh"                grafana             running             0.0.0.0:3000->3000/tcp, :::3000->3000/tcp
prometheus          "/bin/prometheus --c…"   prometheus          running             0.0.0.0:9090->9090/tcp, :::9090->9090/tcp

Agora você poderá acessar o Grafana pelo link localhost:3000 e o Prometheus por esse link localhost:9090.

Acessando a aplicação

Grafana

Ao acessar o Grafana, você verá a tela de login, sendo necessário informar o usuário e senha. No arquivo .env que foi criado contém as credenciais de acesso.

Para acessar, entre com o usuário admin e senha password.

Para validarmos que foi provisionado corretamente um datasource, vá no menu lateral no ícone de engrenagens e clique em Datasources. Verá que foi criado um com o nome de Prometheus.

Ao clicar nele irá abrir as configurações de acesso ao Prometheus. Ao adicionar esse datasource, por padrão há disponível três opções de Dashboards para ser utilizado.

Clique na segunda aba Dashboards e clique em Import para criar o dashboard.

Datasources Prometheus

Ao clicar em importar clique em cima do nome do Dashboard, por exemplo o Prometheus 2.0 Stats. Você verá o Dashboard apresentar os valores da própria instância do Prometheus.

Dashboard Prometheus 2.0 Stats

Esse é o início de uma configuração para usar o Grafana. Você pode procurar por mais tipos de Dashboard direto do site do Grafana.

Prometheus

Ao acessar o Prometheus, você verá a seguinte tela:

Tela de consultas do Prometheus

Nessa tela é possível visualizar as métricas que estão sendo exportadas do container do Prometheus.

Visualizar métricas no Prometheus

Download código

Todo o código dessa stack você pode baixar pelo link do Github.

Conclusão

Esse é apenas o começo de uma stack de monitoramento, existem muitas outras configurações a se fazer para um ambiente de produção. Nesse artigo o objetivo principal é subir o Grafana e Prometheus com uma configuração simples mas seguindo boas práticas e com algumas pequenas customizações.

Pretendo e quero lançar uma série de artigos para subir uma stack pronta para produção, focando também em segurança, alertas entre outras possíveis configurações.

Espero que tenha ajudado até aqui.

Se você encontrar algum erro, sugestões de melhorias ou se tiver alguma dúvida, deixe seu comentário abaixo.

Até a próxima.

Hoje vamos subir um servidor web completo, rodando os serviços Nginx, PHP 7.4 e MySQL 5.7/MySQL 8.0. Esse script foi testado e validado para funcionar corretamente nas versões 18.04 e 20.04 do Ubuntu.

Por padrão, o script irá instalar a versão do MySQL que está no repositório da distribuição, ou seja, se você usar o Ubuntu 18.04 a versão do MySQL que será instalada será a 5.7. Se você usar o Ubuntu 20.04, a versão instalada será a 8.0.

Disclaimer

O objetivo desse artigo é mostrar um script pronto de como provisionar um servidor web com os serviços Nginx, PHP e Mysql instalados e configurados. Se eu for explicar cada passo para a instalação de cada serviço, o artigo irá ficar bem extenso e cansativo de ler.

Por esse motivo, achei melhor explicar somente o que foi feito para a instalação do MySQL, explicando cada arquivo necessário para criar o mesmo. Nos próximos tópicos você verá de forma automatizada como fazer:

• Instalação do MySQL

• Configurar senha do usuário root

• Criação de usuários

• Criação dos bancos de dados

• Envio de um arquivo .sql para o servidor

• Importação do arquivo .sql

Como eu disse, meu objetivo é ter um script para provisionar um servidor web completo, por isso no final do artigo irei disponibilizar um link para você obter esse script por completo.

Ansible

Para nos ajudar, iremos utilizar uma ferramenta chamada Ansible. O Ansible é uma ferramenta de automação de código aberto para gerenciar, automatizar, configurar servidores e implementar serviços. O Ansible foi desenvolvido por Michael DeHaan, mas em 2015 foi adquirido pela Red Hat que o mantém até hoje.

O Ansible funciona de uma forma muito simples, ele não precisa de um agente instalado em seu alvo. Utiliza-se apenas de uma conexão via SSH podendo gerenciar múltiplos servidores de uma vez.

Instalação

Para a instalação do Ansible em sua máquina host, siga os passos abaixo conforme sua distribuição. Para uma lista completa para outras distribuições verifique a documentação do Ansible.

Ubuntu

sudo apt update
sudo apt install software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install ansible

Debian

Adicione a linha abaixo no arquivo /etc/apt/sources.list:

deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main

Execute os seguintes comandos:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
sudo apt update
sudo apt install ansible

Nosso cenário

Para esse tutorial, irei utilizar um droplet criado na Digital Ocean, fique a vontade para utilizar qualquer provedor de serviço como AWS, Linode, Google entre outros.

Antes de prosseguir para o próximo passo, crie sua máquina e obtenha o endereço IP que seu cloud irá disponibilizar.

Criando o arquivo de inventário

Vamos criar um diretório onde os arquivos do Ansible serão criados. Execute o comando abaixo:

mkdir ~/ansible && cd ~/ansible

Vamos criar o nosso arquivo de inventário chamado de hosts.

vim hosts

Cole o seguinte conteúdo dentro do arquivo.

[webserver]
192.168.10.100 ansible_user=root ansible_python_interpreter=/usr/bin/python3

Substitue o IP 192.168.10.100 para um IP válido, disponibilizado pelo seu cloud. É através desse arquivo de inventário que o Ansible irá obter o endereço do servidor e executar os comandos necessários.

A estrutura e a forma que iremos trabalhar com o Ansible, será seguindo as boas práticas. Iremos trabalhar com roles, variables, files e outros recursos.

Criando uma role

Uma role é usada para organizar, compartilhar a separar as responsabilidades de cada tarefa. Podemos ter várias roles, cada uma fazendo uma coisa, por exemplo: uma para instalar o MySQL, outra para criar os usuários SSH, configurar firewall, entre outras.

Vamos criar a nossa primeira role, para isso iremos utilizar o comando ansible-galaxy, digite em seu terminal:

# Cria o diretório onde as roles serão armazendas
mkdir roles

# Cria uma role chamada mysql
ansible-galaxy init roles/mysql

Ao executar o comando ansible-galaxy init roles/mysql, será criado toda a estrutura de uma role, contendo alguns diretórios e arquivos responsáveis em executar determinadas tarefas.

Podemos ver melhor a estrutura criada ao criarmos a role mysql.

# Diretório: ~/ansible
.
├── hosts
└── roles
    └── mysql
        ├── defaults
        │   └── main.yml
        ├── files
        ├── handlers
        │   └── main.yml
        ├── meta
        │   └── main.yml
        ├── README.md
        ├── tasks
        │   └── main.yml
        ├── templates
        ├── tests
        │   ├── inventory
        │   └── test.yml
        └── vars
            └── main.yml

Trabalhando na role MySQL

Iremos agora criar as tarefas que a role MySQL executará. Vou começar pelos arquivos de variavéis para quando chegarmos na tarefa em si, você possa entender de onde as variavéis foram obtidas.

Os próximos tópicos estão nomeados em inglês para manter os mesmos nomes utilizados pelo Ansible.

Vars

Podemos definir variáveis para o nosso script utilizando o arquivo vars/main.yml ou o defaults/main.yml. No diretório default, utilizamos quando queremos que uma determinada variável seja usada caso não for declarada em algum lugar do script, ou seja, seria onde colocaríamos as variavéis padrões para evitar algum erro durante o provisionamento, caso não declarada.

No diretório vars podemos declarar as variáveis que deverão ser usadas durante a execução do script.

Para a criação dos usuários e dos bancos de dados MySQL, iremos utilizar o arquivo vars/main.yml. Cole o seguinte conteúdo.

---
# vars file for roles/mysql
db_password: password

mysql_users:
  - user: aristides
    password: user@123
    host: '%'
    priv: '*.*:ALL,GRANT'

  - user: example
    password: example@123
    host: '%'
    priv: 'example.*:SELECT,INSERT,UPDATE,DELETE,LOCK TABLES,EXECUTE,SHOW VIEW'

  - user: sakila
    password: sakila@123
    host: '%'
    priv: 'sakila.*:SELECT,INSERT,UPDATE,DELETE,LOCK TABLES,EXECUTE,SHOW VIEW'

mysql_databases:
  - database: example
    encoding: utf8mb4
    name: example.sql
    dest: /tmp

  - database: sakila
    encoding: utf8mb4
    name: sakila.sql
    dest: /tmp

• Definimos a senha que será configurada para o usuário root do Mysql em db_password.

• Definimos uma variável chamada mysql_users que recebe um array de usuários, nela informamos o nome e senha do usuário, o host e seus privilégios.

• Na variável mysql_databases, informamos os bancos de dados que serão copiados da máquina host para a máquina remota (servidor).

Tasks

Vamos criar nossa primeira tarefa, para isso vamos editar o arquivo tasks/main.yml. Cole o seguinte conteúdo dentro do arquivo, logo abaixo explico o que será feito.

---
# tasks file for roles/mysql
- name: Instalando MySQL Server
  apt: 
    name: "{{ packages }}"
    state: latest
    update_cache: yes
  vars:
    packages:
      - mysql-server
      - python3-pymysql
      - python3-mysqldb
  notify: restart mysql

- name: Certifica que o serviço do MySQL está rodando
  service:
    name: mysql
    state: started
    enabled: true

- import_tasks: config.yml
- import_tasks: import.yml

• Na task do MySQL, iremos instalar o pacote mysql-server e extensões do python para que o Ansible possa executar comandos do MySQL.

• Repare na linha notify: restart mysql, ela será explicada mais a diante.

• Após a instalação será feita uma checagem para certificar que o serviço do MySQL está ativo.

• Logo após é feito a importação de duas tasks config.yml e import.yml que foi criada para executar outros comandos. Essa é uma boa prática para dividir as responsabilidades dos arquivos.

Crie o seguinte arquivo mysql/tasks/config.yml e cole o conteúdo abaixo:

---
# tasks file for roles/mysql
- name: Altera plugin de autenticação para mysql_native_password
  shell: mysql -u root -e 'UPDATE mysql.user SET plugin="mysql_native_password" WHERE user="root" AND host="localhost"'
  # Caso queira executar o mesmo script na segunda vez, descomente a linha abaixo e comente a de cima.
  # Na primeira vez que o script é executado é criado uma senha para o usuário root, por isso a necessidade de informar a senha no comando abaixo
  # shell: mysql -u root -p{{ db_password }} -e 'UPDATE mysql.user SET plugin="mysql_native_password" WHERE user="root" AND host="localhost"'

- name: Recarrega privilégios
  shell: mysql -u root -e 'FLUSH PRIVILEGES'
  # shell: mysql -u root -p{{ db_password }} -e 'FLUSH PRIVILEGES'

- name: Configura a senha do root
  mysql_user:
    login_host: 'localhost'
    login_user: 'root'
    login_password: ''
    name: 'root'
    password: '{{ db_password }}'
    state: present

- name: Criando usuario Mysql
  mysql_user:
    login_user: 'root'
    login_password: '{{ db_password }}'
    name: '{{ item.user }}'
    password: '{{ item.password }}'
    priv: "{{ item.priv }}"
    host: "{{ item.host }}"
    state: present
  with_items: "{{ mysql_users }}"

- name: Criando bancos de dados
  mysql_db:
    name: '{{ item.database }}'
    login_user: root
    login_password: "{{ db_password }}"
    state: present
    encoding: "{{ item.encoding }}"
  with_items: "{{ mysql_databases }}"

• O arquivo config.yml é responsável em realizar algumas configurações no banco de dados e setar uma senha para o usuário root.

• Veja que existe algumas variáveis, por exemplo a {{ db_password }}, declarada no arquivo vars/main.yml.

• Um ponto importante e crucial para entender como a funcionalidade de loop funciona no Ansible é analisar a linha with_items: "{{ mysql_users }}" e with_items: "{{ mysql_databases }}". O Ansible irá percorrer esse array acessando os valores através da palavra reservada item e a chave do array declarado, por exemplo: item.name. Como informado as variáveis foram declaradas no arquivo vars/main.yml.

Crie o seguinte arquivo mysql/tasks/import.yml e cole o conteúdo abaixo:

---
# tasks file for roles/mysql
- name: Copiando arquivos SQL para o servidor
  copy:
    src: "{{ item.name }}"
    dest: "{{ item.dest }}/{{ item.name }}"
  with_items: "{{ mysql_databases }}"

- name: Import arquivo de dump do banco de dados
  mysql_db:
    name: '{{ item.database }}'
    login_user: root
    login_password: "{{ db_password }}"
    state: import
    target: "{{ item.dest }}/{{ item.name }}"
  with_items: "{{ mysql_databases }}"

• O arquivo import.yml é responsável em copiar para o servidor os arquivos .sql de backup e realizar a importação do mesmo.

• Veja que a importação é feita utilizando o recurso de loop e pode ser utilizado para importar vários bancos de dados de maneira rápida e eficiente.

Veja que iremos importar dois bancos de dados, você pode fazer o download clicando aqui. Descompacte o arquivo .zip e salve os dois arquivos .sql no diretório roles/mysql/files. Os dois são os mesmos bancos só que com nomes diferentes, isso apenas para entender que podemos importar vários bancos de dados.

Handlers

Os handlers são gatilhos que irá acionar uma task. No arquivo vars/main.yml durante a instalação do MySQL, existe uma chamada para o handler restart mysql através da linha notify: restart mysql.

Os handlers quando acionados são executados somente no final do script, independentemente de onde são chamados, sendo essa a diferença de uma task normal.

O arquivo que será utilizado é o handlers/main.yml. Copie e cole o conteúdo abaixo:

---
# handlers file for roles/mysql
- name: restart mysql
  service:
    name: mysql
    state: restarted
    enabled: yes

• Nesse arquivo criamos um handler chamado de restart mysql que como o próprio nome diz, ao finalizar a execução do script o Ansible irá restartar o serviço do MySQL para que entre em vigor as alterações realizadas.

Playbook

Para que tudo isso funcione, temos que criar um arquivo responsável em executar nossas tarefas, esse arquivo é chamado de playbook.

Crie um arquivo chamado my-server.yml na raiz do seu projeto e cole o seguinte conteúdo nele.

---
- hosts: webserver
  gather_facts: no

  roles:
    - mysql

• Informamos ao Ansible que ao ler esse arquivo utilize o host informado no arquivo hosts que contenha a chave webserver. Esse arquivo hosts criamos lá no início, o arquivo de inventário.

• Na linha gather_facts deixei como no para ganhar um tempo na execução do script. Caso for yes, o Ansible irá obter várias informações do servidor como por exemplo, sistema operacional, memória ram, hd e várias outras. Essas informações podem ser usadas para outros fins, mas para o nosso caso não é necessário.

• Em roles definimos que será executada a role mysql. Você pode adicionar quantas roles que desejar.

Arquivo de configuração (opcional)

A criação de um arquivo de configuração na raiz do projeto é opcional, pois o arquivo principal se encontra em /etc/ansible/ansible.cfg e você pode realizar qualquer configuração necessária.

Existe uma configuração que eu tenho preferência em alterar que se chama host_key_checking. Setando essa chave para false quer dizer que no primeiro acesso ao servidor não será feita a verificação da chave do host, ou seja, aquela pergunta se o host é confiável e sendo necessário digitar yes para continuar.

Por padrão o Ansible deixa essa opção como true por motivos de segurança, ele protege contra spoofing de servidor. Caso queira saber mais clique aqui.

Para desativar, crie na raiz do projeto o arquivo ansible.cfg e cole o seguinte contéudo:

[defaults]
host_key_checking = False

Vamos ver como está nossa estrutura de diretórios depois da criação dos nossos arquivos:

# Diretório: ~/ansible
.
├── ansible.cfg
├── hosts
├── my-server.yml
└── roles
    ├── mysql
        ├── defaults
        │   └── main.yml
        ├── files
        │   ├── example.sql
        │   └── sakila.sql
        ├── handlers
        │   └── main.yml
        ├── meta
        │   └── main.yml
        ├── README.md
        ├── tasks
        │   ├── config.yml
        │   ├── import.yml
        │   └── main.yml
        ├── templates
        ├── tests
        │   ├── inventory
        │   └── test.yml
        └── vars
            └── main.yml

Execução do script

Vamos entender o que será feito com esse script:

• Será feito a instalação do MySQL

• A senha do root será alterada conforme definimos no arquivo vars/main.yml

• Serão criados usuários para o acesso ao MySQL

• Serão criados bando de dados

• Serão importados dois arquivos .sql para os bancos recém criados

Agora precisamos executar o nosso playbook, para isso digite o comando abaixo informando o arquivo de inventário utilizado e o nosso playbook. O comando time no início do comando para a execução do playbook, é um comando do Linux, utilizo ele para que no final ele informe o tempo que levou na execução do comando.

time ansible-playbook -i hosts my-server.yml

Após a finalização do script, você verá a informação:

PLAY RECAP ******************************************************************************************
192.168.10.100  : ok=10   changed=9    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   


real    2m46,517s     <-- tempo de execução do script
user    0m20,500s
sys 0m2,520s

A partir desse momento você terá o MySQL rodando com todas as configurações devidas de uma forma automatizada, lindo né? E isso tudo levou apenas 2 min e 46 segundos. Se fosse fazer isso na mão, quanto tempo seria?

Conclusão

Para finalizarmos esse artigo, como disse, meu objetivo é mostrar como subir um servidor web completo com Nginx, PHP e MySQL, se você seguir exatamente os passos aqui citados você terá seu servidor MySQL pronto.

Você pode encontrar o código no meu repositório no github.

Se você encontrar algum erro, sugestões de melhorias ou se tiver alguma dúvida, deixe seu comentário abaixo.

Até a próxima!

Acredito que todos conheçam o Google Analytics, uma ferramenta de análise web que cria estatísticas de visitas, você precisa apenas adicionar um script no seu site e esperar que esses dados coletados pelo Google vire relatórios, gráficos e números para você!

Como descrito no título desse artigo, não será sobre o Google Analytics que irei falar, mas sim, do Matomo Analytics.

Disclaimer

Esse não é um artigo técnico, não estarei ensinando como instalar e/ou configurar a ferramenta, mas estarei compartilhando mais a respeito sobre os recursos, comunidade e contribuições.

Logo estarei publicando um artigo mais técnico ;)

Sobre Matomo Analytics

Matomo Analytics é uma ferramenta de análise web Open Source, responsável em coletar dados de visitantes para ajudar em tomadas de decisões.

Matomo tem como filosofia dar às pessoas a liberdade e o direito à sua própria privacidade e dados. E em 2007 nasce a base atual do Matomo que originalmente se chamava Piwiki.

O fundador do Matomo, Matthieu Aubry tinha como objetivo ter uma alternativa de código livre para o Google Anaytics, que deveria ser tão poderoso quanto e que também respeitasse os dados, propriedade e privacidade do usuário.

Com a ajuda da comunidade o projeto cresceu e se tornou a plataforma de análise web de código aberto nº 1 do mundo. Hoje, é usado em mais de 1,4 milhão de sites, em mais de 190 países, e acessível em mais de 50 idiomas.

E Piwik evoluiu para Matomo.

O que o Matomo oferece

• 100% de propriedade dos dados - seus dados em suas mãos

• Flexibilidade

• Confiabilidade e Segurança

• Uma ferramenta fácil de usar

• Proteção de privacidade do usuário

• Opções de hospedagem On-Premise ou em Cloud

• Open Source

• Conformidade com GDPR

• Mais de 100 integrações

Quando se diz 100% de propriedade dos dados, quer dizer que você pode simplesmente baixar o código fonte da ferramenta e instalar em seu próprio servidor, tendo todo o controle dos dados coletados pela ferramenta, e essa é uma grande vantagem, pois você sabe que você não precisará concordar com os Termos e Políticas onde esses dados serão compartilhados com outros serviços.

A comunidade Matomo

Por ser um projeto Open Source, a ferramenta é vista com bons olhos por devs e por amantes do código livre. Você também pode contribuir com o projeto, veja como:

1. Ajude a comunidade através dos fóruns de discussões.

2. Se você é um desenvolvedor.

3. Ajude na tradução da ferramenta.

Outros links úteis:

• https://matomo.org/

• https://github.com/matomo-org/

• https://matomo.org/docs/installation/

Minha contribuição

Gostaria de compartilhar aqui a minha pequena parte onde ajudo na tradução da ferramenta. Iniciei nessa comunidade em Maio de 2018, e vi no Matomo uma oportunidade de ajudar e de certa forma aprender.

Enviei um e-mail para o suporte para entender mais sobre como eu poderia ajudar, e de uma forma bem atenciosa, foi me passado todas as informações para que eu pudesse começar.

Depois de um tempo contribuindo com o projeto, recebi um e-mail agradecendo pelas contribuições e que gostariam de retribuir. Assim, fui presenteado com uma bela blusa e uma carta escrita a mão por @matthieuaubry.

Presenteado por Matomo

Quando começamos a fazer algo para a comunidade, o primeiro objetivo é sempre compartilhar com outras pessoas nossas experiências, nossos problemas e como resolvemos esse problema, e comigo não é diferente. Você sempre terá algo para compartilhar, então, comece agora mesmo!

Dashboard Matomo

Para mostrar mais sobre essa ferramenta incrível, irei aqui mostrar algumas imagens dos dados que são coletados pelo Matomo.

Matomo dashboard

Matomo visitas

Matomo navegadores

Matomo sistemas operacionais

Matomo visão geral de visitas

Bom pessoal, espero que tenha atiçado a vontade de conhecer mais essa ferramenta.

Esse artigo foi mais para apresentar a ferramenta para vocês, irei publicar outro artigo mais técnico onde mostrarei como instalar e configurar a ferramenta para a coleta de dados.

Até a próxima!

Nesse artigo vamos ver como é fácil criar certificados SSL para o seu site usando o Let's Encrypt e como servidor web usaremos o Nginx.

Let's Encrypt é uma Autoridade de Certificação (CA), que fornece certificados gratuitamente e gerencia seus certificados de uma forma automatizada, facilita todo o processo de criação, validação, instalação e renovação de certificados.

Para instalar e utilizar o Let's Encrypt é necessário que tenha acesso ao shell do seu servidor com um usuário root ou que tenha privilégios de sudo, para que possamos executar os comandos de instalação dos pacotes e para a geração dos certificados.

Disclaimer

Para esse tutorial, utilizei a distribuição Ubuntu 18.04, mas se você estiver usando o Ubuntu 20.04, Debian 9 ou Debian 10, continue, pois irá funcionar sem problemas.

Para serviço de VPS, estou usando um droplet na Digital Ocean.

A Digital Ocean oferece um serviço de hospedagem de VPS excelente, estável e com vários recursos disponíveis em seu painel. Caso queira conhecer mais, utilize meu link de referência para se cadastrar e ganhe créditos assim que começar a utilizar seus serviços. Você ganha e eu também ;)

Instalando o Let's Encrypt

O Let's Encrypt recomenda o uso do cliente Certbot ACME para a maioria das pessoas, pois possuem modos avançados de configurações, e para nós que gostamos de fazer as coisas sem esforço, é uma boa!

Primeiro vamos instalar o pacote Certbot com o plugin do Nginx, digite o comando abaixo:

sudo apt install python-certbot-nginx

Esse comando irá instalar o pacote do Certbot e o plugin para Nginx, caso você ainda não tenha o Nginx instalado, será instalado junto.

Após a instalação do certbot e do plugin, vamos gerar o nosso certificado.

Para que seja possível gerar o certificado SSL seu site deve estar acessível na web, com o DNS já configurado. Caso queira configurar um servidor Nginx veja esse arquivo Aprenda a instalação e a configuração básica de como criar um server block com o servidor web Nginx

Se você usa um firewall em seu servidor, certifique-se que a porta 443 esteja liberada. Para quem usa o utilitário UFW, pode verificar com os comandos:

# Para verificar se a porta está liberada
sudo ufw status

# Para liberar a porta caso não esteja
sudo ufw allow 443

Gerando certificado SSL

Para o nosso exemplo, criei o subdomínio meublog.aristides.dev.

Para gerar o certificado, utiliza-se o utilitário certbot com o plugin do nginx, em seguida o parâmetro -d seguido do seu domínio.

sudo certbot --nginx -d meublog.aristides.dev

Caso queira criar certificados para mais de um domínio ao mesmo tempo, basta informar os mesmos com o parâmetro -d.

sudo certbot --nginx -d meusite.com.br -d meusite2.com.br

Ao executar o comando acima, algumas perguntas serão feitas e devem ser respondidas, a primeira é sobre os Termos de Serviço. Informe A para concordar e continuar.

A segunda é se gostaria de compartihar seu e-mail e receber notícias, campanhas entre outras informações sobre Let's Encrypt.

A terceira pergunta é se deseja que todo o tráfego para seu site seja redirecionado para HTTPS, digite 2 para Sim.

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

Pronto. Certificado gerado com sucesso. Congratulations!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://meublog.aristides.dev

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=meublog.aristides.dev
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/meublog.aristides.dev/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/meublog.aristides.dev/privkey.pem
   Your cert will expire on 2020-12-20. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Muito bom! Seu certificado foi gerado com sucesso e nesse momento seu site já deve estar funcionando com HTTPS.

Validando a configuração do SSL

Veja que após a conclusão do processo, ele informe que é possível testar a "força" que sua configuração possui. Para isso é necessário acessar o site https://www.ssllabs.com/ssltest e digitar o endereço do seu site.

Nota: Se você testar seu site agora, é muito provável que receba a letra B, que se refere à algumas variavéis de segurança que é testado. Na instalação que usamos aqui, não geramos uma chave RSA e nem a chave DHPARAM, a geração dessas chaves são um passo a mais para aumentar a segurança.

Utilizamos aqui o plugin do Nginx para a instalação, por isso que automaticamente nosso arquivo de configuração foi atualizado com as informações dos certificados e redirecionamento para HTTPS.

Para ter um certificado mais seguro, geralmente utilizamos o certbot certonly, para apenas gerar os certificados e manualmente as configurações e a geração de chaves RSA e DHPARAM deve ser feitas pelo administrador.

Estarei escrevendo um outro post a respeito dessa configuração!

Renovação automática

O certificado gerado tem validade por 90 dias. Para que o certificado seja renovado e você não tenha problemas com seu site, o Let's Encrypt cria uma entrada no cron do Linux para que automaticamente seja renovado o certificado quando necessário.

Veja o arquivo criado em /etc/cron.d/certbot, o mesmo é executado a cada 12 horas.

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

Caso queira simular manualmente a renovação dos certificados, execute o comando certbot renew com o parâmetro --dry-run.

# Para simular
sudo certbot renew --dry-run

# Para renovar
sudo certbot renew

Se você executar o comando para renovar e se ainda não for necessário, será retornada uma mensagem que não existe certificado para renovação.

Listar informações sobre certificados

Para saber maiores informações sobre todos os certificados que foram gerados pelo certbot, execute o comando certbot certificates:

sudo certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: meublog.aristides.dev
    Domains: meublog.aristides.dev
    Expiry Date: 2020-12-20 00:12:05+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/meublog.aristides.dev/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/meublog.aristides.dev/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Remover um certificado

Caso você não precise mais de um certificado criado para um domínio, seja por qual motivo for, a maneira mais simples e eficiente de fazer isso é utilizar os comandos que o certbot nos fornece.

# Remover através de uma lista fornecida pelo Certbot
sudo certbot delete

# Remover pelo domínio
# Esse comando não solicita confirmação, ao executar o certificado será removido
sudo certbot delete --cert-name meublog.aristides.dev

Diretório dos certificados gerados

Veja que no diretório /etc/letsencrypt é onde todos os arquivos referente aos certificados são salvos. Dentro dele existe um diretório chamado live.

root@ubuntu-letsencrypt:/etc/letsencrypt# ls -l
total 40
drwx------ 3 root root 4096 Sep 21 01:11 accounts
drwx------ 3 root root 4096 Sep 21 01:12 archive
-rw-r--r-- 1 root root  121 Oct 10  2019 cli.ini
drwxr-xr-x 2 root root 4096 Sep 21 01:11 csr
drwx------ 2 root root 4096 Sep 21 01:11 keys
drwx------ 3 root root 4096 Sep 21 01:12 live
-rw-r--r-- 1 root root 1143 Sep 21 01:11 options-ssl-nginx.conf
drwxr-xr-x 2 root root 4096 Sep 21 01:12 renewal
drwxr-xr-x 5 root root 4096 Sep 21 01:11 renewal-hooks
-rw-r--r-- 1 root root  424 Sep 21 01:11 ssl-dhparams.pem

Dentro do diretório live estão salvos os arquivos referente ao seu site, veja que existe um diretório com o nome do meu domínio e dentro existe 4 arquivos com a extensão .pem que são as chaves e certificados gerados, e que são necessários para a validação do SSL.

root@ubuntu-letsencrypt:/etc/letsencrypt/live# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 21 01:12 meublog.aristides.dev

root@ubuntu-letsencrypt:/etc/letsencrypt/live# ls -l meublog.aristides.dev/
total 4
-rw-r--r-- 1 root root 682 Sep 21 01:12 README
lrwxrwxrwx 1 root root  45 Sep 21 01:12 cert.pem -> ../../archive/meublog.aristides.dev/cert1.pem
lrwxrwxrwx 1 root root  46 Sep 21 01:12 chain.pem -> ../../archive/meublog.aristides.dev/chain1.pem
lrwxrwxrwx 1 root root  50 Sep 21 01:12 fullchain.pem -> ../../archive/meublog.aristides.dev/fullchain1.pem
lrwxrwxrwx 1 root root  48 Sep 21 01:12 privkey.pem -> ../../archive/meublog.aristides.dev/privkey1.pem

Os arquivos fullchain.pem e privkey.pem são usados dentro do arquivo de configuração do Nginx do seu site em /etc/nginx/sites-available.

Veja como ficou o arquivo /etc/nginx/sites-available/default.conf do Nginx após o certificado ser gerado:

# Arquivo: /etc/nginx/sites-available/default.conf
# partes das linhas foram ocultadas 

listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/meublog.aristides.dev/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/meublog.aristides.dev/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

server {
    if ($host = meublog.aristides.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80 default_server;
    listen [::]:80 default_server;

    server_name meublog.aristides.dev;
    return 404; # managed by Certbot
}

Bom pessoal é isso aí. O Let's Encrypt nos ajuda a criar e gerenciar certificados automaticamente, sem esforço nenhum, do jeito que gostamos :)

Se ficou com alguma dúvida fique a vontade para perguntar.

Até a próxima!

Hoje o assunto é manipulação de imagens com PHP.

Imagine é uma biblioteca OOP (Programação Orientada a Objetos) para manipulação de imagens criada no PHP 5.3. Usa as melhores práticas de desenvolvimento com um design cuidadoso permitindo um código desacoplado e testável.

É um projeto open source, caso queira contribuir veja mais clicando aqui.

Imagine unifica as bibliotecas ImageMagick, GraphicsMagick e GD, de forma orientada a objetos e de uma maneira muito simplista. Isso significa que você deve ter pelo menos uma dessas bibliotecas instaladas no seu ambiente.

Com ela você pode criar miniaturas de imagens, cortar, girar, redimensionar, inverter e até criar uma imagem composta.

Requisitos

Em nosso exemplo vamos usar a biblioteca GD, então certifique-se se possui instalada. Para instalar execute o comando abaixo e substitua a versão do seu PHP:

sudo apt install php7.4-gd

Instalação da Imagine

Para a instalação vamos utilizar o composer, em seu terminal digite o comando:

composer require imagine/imagine

Iniciando com Imagine

Precisamos importar a classe ou as classes para começar a manipular as imagens. Vamos utilizar o autoload do composer para importar as classes:

<?php

require 'vendor/autoload.php';

$imagine = new Imagine\Gd\Imagine();

Caso queira baixar os arquivos desse exemplo, deixei no meu GitHub, acesse esse repositório e clone na sua máquina. Os exemplos abaixo estão no arquivo index.php.

No próprio repositório há uma descrição melhor para que possa executar os exemplos.

Resize

O redimensionamento de imagens é o mais comum entre aplicações web, muito utilizado para gerar Thumbnails. Veja como é fácil:

<?php 

$imagine = new Imagine\GD\Imagine;

// Abre a imagem original
$image = $imagine->open(__DIR__ . '/email.png');

// Obtém o tamanho real da imagem
$size = $image>getSize();

// Resize da imagem definindo 450px de largura
$image->resize($size->widen(450))
    ->save(__DIR__ . '/images/email_resize.png');

Rotação

Rotacione a imagem de uma forma simples. Veja para rotacionar em 90 graus.

<?php 

$imagine = new Imagine\GD\Imagine;

// Abre a imagem original
$image = $imagine->open(__DIR__ . '/email.png');

// Rotaciona em 90 graus
$origin->rotate(90)
    ->save(__DIR__ . '/images/email_rotate.png');

Cortar

Corte a imagem baseado em um ponto inicial e seu tamanho. O método crop() deve receber dois parâmetros indicando posição e tamanho da imagem.

Nesse caso, será utilizada a classe Point para informar a posição e a classe Box para informar o tamanho da “caixa” que será cortada.

<?php

$imagine = new Imagine\GD\Imagine;

// Abre a imagem original
$image = $imagine->open(__DIR__ . '/email.png');

// Corta a imagem
$origin->crop(new Point(10,90), new Box(150, 150))
    ->save(__DIR__ . '/images/email_crop.png');

Este artigo foi bem ao ponto!

Essas são algumas das opções que podemos utilizar com a biblioteca Imagine. Acesse a documentação para conhecer mais e veja o quanto é simples trabalhar com manipulação de imagens no PHP.

Até próxima!

Mais um artigo hoje, no formato tutorial. Nesse artigo aprenderemos como fazer o deploy de uma aplicação desenvolvida com o Laravel, usando uma ferramenta de deploy.

Deployer

O Deployer é uma ferramenta desenvolvida em PHP e que faz todo o trabalho pesado em realizar o deploy da sua aplicação PHP, seja usando um framework ou não.

Todos os passos a seguir, foram executados usando o sistema operacional Linux.

Pré requisitos:

• Conta no Bitbucket (ou em outro repositório git)

• Uma VPS (estou usando a Digital Ocean)

• Servidor com Nginx, PHP e Mysql instalados

• Node e NPM instalados no servidor

• Acesso root (ou sudo) ao servidor via SSH

Te indico a leitura de 3 artigos do meu blog que pode te ajudar em caso de alguma dúvida de alguns tópicos desse tutorial, são eles:

1. Configuração de um servidor web usando LEMP no Debian 9. Criando um usuário e configurando o SSH

2. Aprenda a configurar um servidor web usando LEMP no Debian 9. Iremos instalar o Nginx, MariaDB e PHP 7.2

3. Aprenda a instalação e a configuração básica de como criar um server block com o servidor web Nginx

Serão criados dois ambientes, de produção e homologação. Para acessarmos a aplicação, nesse tutorial iremos utilizar o IP do servidor, mas caso queira pode ser usado um domínio válido e configurado. Por exemplo, caso esteja usando um domínio, crie um subdomínio com o prefixo homolog.seusite.com.br. Esse será o endereço para o ambiente de homologação, e o seusite.com.br o endereço de produção.

Para o meu caso, irei usar o IP e definir as portas para diferenciar os ambientes, por exemplo, a porta 80 para produção e 81 para homologação.

Instalando o Deployer

A instalação deve ser feita na máquina de desenvolvimento. Para isso digite os 3 comandos abaixo em seu terminal.

curl -LO https://deployer.org/deployer.phar
mv deployer.phar /usr/local/bin/dep
chmod +x /usr/local/bin/dep

No comando acima, é feito o download do arquivo deployer.phar e em seguinda movemos o arquivo para o diretório /usr/local/bin renomeando para dep, e para finalizar concedemos permissão de execução para o arquivo.

Para testar o deployer, execute no seu terminal o comando:

dep --version

Se aparecer a versão do Deployer, sucesso!

Instalando o Laravel

Nesse exemplo iremos baixar uma aplicação Laravel usando o composer. Não terá nenhuma regra de negócio na aplicação, apenas irei criar a autenticação padrão do Laravel e uma implementação a mais para que o deploy funcione corretamente.

mkdir -p ~/projetos/deployer/
cd ~/projetos/deployer
composer create-project --prefer-dist laravel/laravel blog

Com o projeto criado, entre no diretório da aplicação e execute os comandos abaixo para criar a autenticação padrão do Laravel 6 (Esse passo é somente para o Laravel 6+).

cd blog
composer require laravel/ui --dev
php artisan ui vue --auth
npm install && npm run dev

Para que esse exemplo funcione, é necessário criar um controller e alterar a rota barra / do Laravel. Durante o deploy é executado o comando artisan config:cache, e esse comando não funciona se existir uma rota que esteja usando uma função anônima, conhecida também como closure, ou seja, a rota inicial do Laravel utiliza uma função anônima.

Route::get('/', function() {
    return view('welcome');
});

Para resolver, crie um controller chamado WelcomeController e altere a rota para:

Route::get('/', 'WelcomeController@index');

No arquivo WelcomeController, adicione no método index(), o return para a view welcome.

<?php

namespace App\Http\Controllers;

class WelcomeController extends Controller
{
    public function index()
    {
        return view('welcome');
    }
}

No arquivo de rotas da API routes/api.php também existe uma função anônima, nesse caso basta remover a rota que o problema é resolvido.

Até esse momento temos nossa aplicação Laravel funcionando e com a autenticação padrão gerada, apenas faltando a conexão com o banco de dados, mas agora não será preciso se preocupar com isso. Vamos fazer isso mais para frente.

Conhecendo o Deployer

Antes de começar com o deployer, vamos conhecer alguns de seus comandos. Digite no terminal:

dep list

Você verá os comandos disponíveis e dentre eles existe o comando init. Essa opção criará o template inicial de uma configuração, é possível também passar um parâmetro informando qual template gostaria de usar. Vamos ver na prática o comando dep init.

Dentro do diretório do seu projeto, digite o comando abaixo:

dep init

Veja o retorno do comando:

Welcome to the Deployer config generator
This utility will walk you through creating a deploy.php file.
It only covers the most common items, and tries to guess sensible defaults.

Press ^C at any time to quit.

Please select your project type [Common]:
[0 ] Common
[1 ] Laravel
[2 ] Symfony
[3 ] Yii
[4 ] Yii2 Basic App
[5 ] Yii2 Advanced App
[6 ] Zend Framework
[7 ] CakePHP
[8 ] CodeIgniter
[9 ] Drupal
[10] TYPO3
>

O resultado desse comando é uma lista de Tipos de Projeto disponíveis para o uso, o padrão é uma aplicação Common, que seria uma aplicação comum em PHP, sem o uso de frameworks.

Selecione a opção 1 para escolher o template Laravel. Em seguida será solicitado que informe o repositório de onde está seu projeto, apenas dê enter, iremos configurar depois. Em seguida ele pergunta se deseja contribuir com a ferramenta enviando informações anônimas, escolha sim ou não.

Finalizado esses passos, veja que no diretório raiz da sua aplicação foi criado um arquivo chamado deploy.php.

Dica: Podemos criar o mesmo arquivo deploy.php informando o parâmetro -t seguido do nome do template. Veja como ficaria para nosso exemplo: dep init -t Laravel

Configurando o Deployer

Abra o arquivo deploy.php criado na raiz do seu projeto e vamos brincar um pouco.

No trecho abaixo, informamos o endereço do repositório onde a aplicação se encontra. Caso você não tenha essa url ainda, no tópico Versionando a aplicação eu falo sobre isso, deixe como está nesse momento, depois basta atualizar essa informação.

<?php

// Project repository
set('repository', 'git@bitbucket.org:username/deployer-laravel.git');

Dica importante: O repositório fica disponível através de dois endereços: git@bitbucket.org e https://username@bitbucket. Existem diferenças entre eles, para que a primeira opção funcione é necessário ter cadastrado a chave pública do SSH no Bitbucket. Na segunda opção é necessário informar a senha para cada requisição realizada.

Na próxima configuração, definimos o host da aplicação, podemos ter um, dois ou mais hosts configurados. Nesse exemplo criaremos dois, de produção e homologação.

<?php

// Hosts
host('production')
    ->hostname('deploy@174.138.55.236')
    ->port(33458)
    ->stage('prod')
    ->set('keep_releases', 6)
    ->set('branch', 'master')
    ->set('deploy_path', '/var/www/html/production-my-app');

host('homolog')
    ->hostname('deploy@174.138.55.236')
    ->port(33458)
    ->stage('hml')
    ->set('keep_releases', 3)
    ->set('branch', 'develop')
    ->set('deploy_path', '/var/www/html/homolog-my-app');

O código em si é bem simples de entender, mas vou explicar o que cada linha significa:

1. host: é o nome que identifica aquela conexão

2. hostname: usuário que será utilizado para fazer o deploy e o IP do servidor

3. port: porta SSH utilizada (se a porta for a padrão 22, essa opção pode ser omitida)

4. stage: um alias para o host (sempre utilize)

5. keep_releases: número de versões que será mantido no servidor

6. branch: branch que será utilizado ao realizar o deploy

7. deploy_path: diretório onde se encontra a aplicação

O parâmetro stage eu recomendo utilizar porque utilizando o stage com a opção abaixo, o default_stage, quer dizer que sempre ao realizar um deploy (sem informar o host como parâmetro) será realizado em homologação, assim evitando que seja feito deploy para produção sem querer.

<?php

// Stage default
set('default_stage', 'hml');

O restante das informações são bem auto explicativas, caso tiver com dúvidas deixe sua pergunta nos comentários, e não deixe de olhar a documentação do deployer, vale a pena.

Versionando a aplicação

Crie um repositório no bitbucket e copie a url do seu repositório, com essa url você poderá atualizar o arquivo deploy.php conforme mencionei no tópico anterior.

Dentro do diretório do seu projeto, vamos utilizar o git para versionar e enviar para o bitbucket.

cd ~/projetos/deployer/blog
git init
git add .
git commit -m “Primeiro commit”
git remote add origin https://username@bitbucket.org/username/deployer-laravel.git
git push -u origin master

Acabamos de enviar para o repositório nossa aplicação.

Branch develop

Vamos criar um branch chamado develop, que será nosso branch de homologação. Também iremos enviar para o bitbucket.

git checkout -b develop
git push -u origin develop

Pronto! Até o momento temos nossa aplicação Laravel versionada no Bitbucket com dois branchs (master e develop).

Criando banco de dados e usuário Mysql

Agora os passos a seguir serão executados no servidor.

Acesse o servidor via SSH para criarmos o banco de dados da nossa aplicação. Digite no terminal os comandos abaixo para criar o banco:

mysql -uroot -psenha
CREATE DATABASE laravel;
CREATE USER 'deployer'@'localhost' IDENTIFIED BY 'senhaforteaqui';
GRANT ALL PRIVILEGES ON laravel . * TO 'deployer'@'localhost';
FLUSH PRIVILEGES;

Pronto, criamos nosso banco de dados chamado laravel e criamos também um usuário com todos os privilégios para que possamos conectar no banco.

Configurando usuário deploy

Ainda logado no servidor, crie um usuário shell que será responsável em realizar o deploy da sua aplicação:

# Informe uma senha forte
adduser deploy

# Adicionando o deploy no grupo www-data
usermod -aG www-data deploy

Diretório WEB

Ainda no servidor, vamos criar dois diretórios que irão hospedar nossa aplicação web e alterar o dono para o usuário deploy. Digite os seguintes comandos:

mkdir -p /var/www/html/production-my-app
mkdir -p /var/www/html/homolog-my-app
chown deploy:deploy /var/www/html/production-my-app
chown deploy:deploy /var/www/html/homolog-my-app

Configurando arquivo host do Nginx

Entre no diretório de configuração de sites do nginx e crie dois arquivos de configuração.

cd /etc/nginx/sites-available
touch production.conf homolog.conf

Agora copie e cole o conteúdo abaixo dentro do arquivo production.conf.

Lembre-se de alterar as informações referente ao seu host, por exemplo o IP e a porta caso necessário.

# Arquivo production.conf
server {

    listen 80;
    listen [::]:80;       

    server_name 174.138.55.236;

    # Log
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    # Directory root
    root /var/www/html/production-my-app/current/public;
    index index.php index.html;

    client_max_body_size 128M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # pass PHP scripts to FastCGI server
    location ~ \.php$ {
        # Note que aqui definimos a versao que iremos utilizar do PHP
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }

    # deny access to .htaccess files
    location ~ /\.ht {
        deny all;
    }

    location ~ /\.well-known {
        allow all;
    }

    # Set header expirations on per-project basis
    location ~* \.(?:ico|css|js|jpe?g|JPG|png|svg|woff)$ {
        expires 365d;
    }
}

Abra o arquivo homolog.conf e cole o conteúdo abaixo:

# Arquivo homolog.conf
server {

    listen 81;
    listen [::]:81;       

    server_name 174.138.55.236;

    # Log
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    # Directory root
    root /var/www/html/homolog-my-app/current/public;
    index index.php index.html;

    client_max_body_size 128M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # pass PHP scripts to FastCGI server
    location ~ \.php$ {
        # Note que aqui definimos a versao que iremos utilizar do PHP
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }

    # deny access to .htaccess files
    location ~ /\.ht {
        deny all;
    }

    location ~ /\.well-known {
        allow all;
    }

    # Set header expirations on per-project basis
    location ~* \.(?:ico|css|js|jpe?g|JPG|png|svg|woff)$ {
        expires 365d;
    }
}

Ative os dois sites que acabamos de configurar:

ln -s /etc/nginx/sites-available/production.conf /etc/nginx/sites-enabled/
ln -s /etc/nginx/sites-available/homolog.conf /etc/nginx/sites-enabled/
service nginx restart

Pronto. Arquivos vhost do nginx configurados. Se você tentar acessar agora, não funcionará, pois ainda falta realizar o deploy da aplicação, calma que vamos chegar lá.

Configurando chaves SSH no Bitbucket

Para que o deploy funcione sem a necessidade de informar a senha, vamos criar uma chave SSH para o usuário deploy.

Logue no servidor com o usuário deploy criado neste tutorial e digite o comando:

# Acessando o servidor com o usuário deploy
ssh deploy@174.138.55.236

# Gerar chaves SSH
ssh-keygen

Confirme as informações, quando solicitar uma senha, não é necessário informar, apenas dê enter até finalizar.

Será gerado dois arquivos em /home/deploy/.ssh chamado id_rsa (chave privada) e id_rsa.pub (chave pública).

Copie todo o conteúdo do arquivo id_rsa.pub e siga os passos:

1. Abra sua conta do bitbucket

2. Clique sobre sua foto de perfil e em Bitbucket settings

3. No painel da esquerda clique em SSH Keys

4. Clique no botão Add key e cole o conteúdo no campo key

5. Dê um nome para identificar essa chave

6. Clique em Add key para salvar as informações

Nesse ponto a comunicação do servidor e bitbucket já pode ser feita através das chaves SSH de maneira segura e sem a necessidade de informar uma senha.

Apenas para efeito de teste, vamos clonar nosso repositório no servidor. Copie a url do repositório que pode ser obtida no próprio repositório, e dentro do diretório /home/deploy (no servidor) cole a url do repositório e dê enter:

git clone git@bitbucket.org:username/deployer-laravel.git

Irá aparecer uma mensagem para que confirme o host e que seja adicionado na lista de hosts confiáveis, informe yes para continuar.

Sucesso. Seu repositório foi clonado.

Ufa, chegamos no deploy!

Bom, vamos ver como ficou o nosso arquivo de deploy? Após nossas configurações o arquivo deve estar parecido com esse:

<?php

namespace Deployer;

require 'recipe/laravel.php';

// Project name
set('application', 'My APP');

// Project repository
set('repository', 'git@bitbucket.org:username/deployer-laravel.git');

// [Optional] Allocate tty for git clone. Default value is false.
set('git_tty', true);

// Shared files/dirs between deploys
add('shared_files', []);
add('shared_dirs', []);

// Writable dirs by web server
add('writable_dirs', []);

// Stage default
set('default_stage', 'hml');

// Hosts
host('production')
    ->hostname('deploy@174.138.55.236')
    ->port(33458)
    ->stage('prod')
    ->set('keep_releases', 6)
    ->set('branch', 'master')
    ->set('deploy_path', '/var/www/html/production-my-app');

host('homolog')
    ->hostname('deploy@174.138.55.236')
    ->port(33458)
    ->stage('hml')
    ->set('keep_releases', 3)
    ->set('branch', 'develop')
    ->set('deploy_path', '/var/www/html/homolog-my-app');

// Tasks

task('npm_run', function () {
    // Descomente esse if após o primeiro deploy
    //if (has('previous_release')) {
    //    run('cp -R {{previous_release}}/node_modules {{release_path}}/node_modules');
    //}

    run('cd {{release_path}} && npm install');
    run('cd {{release_path}} && npm run prod');
});

// [Optional] if deploy fails automatically unlock.
after('deploy:failed', 'deploy:unlock');

// Migrate database before symlink new release.

// Descomente essa linha após o primeiro deploy
// before('deploy:symlink', 'artisan:migrate');

Um detalhe muito importante para fazermos antes do primeiro deploy é comentar a última linha, ela é responsável em executar a migrate, se fizermos o deploy com a migrate sem antes configurar o arquivo .env no servidor, irá dar erro de conexão com o banco de dados e isso é fato.

Mais um teste rápido antes de iniciar, dentro do seu projeto local, digite no terminal o comando dep ssh:

Executar login SSH no servidor

Viu que bacana? O deployer identificou que foi configurado dois hosts e ele te deu a opção de escolher em qual host deseja conectar via SSH. Informei o host de homologação e ele realizou o login no servidor.

A mensagem de erro dizendo que o diretório current não existe é normal, pois ainda não realizamos o deploy e a estrutura de diretórios que a ferramenta de deploy cria, não existe no momento.

Chega de enrolação, bora fazer esse deploy. Se ainda continua logado no servidor, digite exit para sair e voltar para sua máquina. Dentro do diretório do seu projeto digite o comando dep deploy. Veja que não passamos nenhum parâmetro, nesse caso o deploy será realizado no host de homologação.

Realizando o deploy da aplicação

Agora precisamos configurar o arquivo .env, se tentar acessar o endereço IP na porta 81 irá receber um erro 500.

Logando no servidor através do comando dep ssh, dentro do diretório current de homologação (diretório atual quando se faz login usando o dep ssh), se abrirmos o arquivo .env verá que está em branco. Copie o conteúdo do arquivo .env.example para .env:

cp .env.example .env

Agora abra o .env e adicione as informações de acesso ao Mysql que criamos no início do tutorial. Salve as alterações e saia do arquivo.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=deployer
DB_PASSWORD=senhaforteaqui

É necessário gerar a chave de segurança do artisan para que a aplicação funcione corretamente, execute os comandos:

php artisan config:clear
php artisan key:generate

Nesse momento sua aplicação deve estar funcionando, acesse seu endereço IP na porta 81 e verifique se a página inicial do Laravel irá aparecer. Se não deu certo, verifique o log do Laravel para identificar o problema.

Vamos continuar pois ainda não acabou. Agora que configuramos nosso arquivo .env com as informações de acesso ao Mysql, vamos executar o deploy novamente agora com a opção de executar a migrate. Lembra que comentamos a linha responsável em executar a migrate, vamos descomentar esse linha e aproveite para descomentar a linha da tarefa do npm_run, ficando assim:

<?php

// Descomente o if da tarefa npm_run
if (has('previous_release')) {
    run('cp -R {{previous_release}}/node_modules {{release_path}}/node_modules');
}

// Descomente o artisan migrate
before('deploy:symlink', 'artisan:migrate');

Ou seja, antes da tarefa symlink, será executado as migrations. Vamos executar o deploy novamente:

Deploy da migration realizado com sucesso

Veja que lindo que foi o resultado. Foi executada uma tarefa nova agora, a tarefa responsável em criar as migrations, veja a linha artisan:migrate no log acima.

Bom, agora se você acessar sua aplicação e realizar o cadastro de um usuário verá que funcionará lindamente.

Deploy em produção

Configuramos o deployer para que seja feito em dois ambientes, em homologação e produção. Ao executar o comando dep deploy é feito o deploy em homologação. Para que seja feito em produção é necessário informar um parâmetro a mais no comando, veja:

dep deploy prod

O prod na frente do comando vem do stage definido no arquivo deploy.php. Agora que você já sabe como fazer o deploy em homologação que tal fazer a mesma coisa para produção?

Execute os mesmos passos que você fez para homolog, crie um banco de dados para produção e após o primeiro deploy configure seu .env com os dados de acesso ao Mysql.

A implantação de uma ferramenta de deploy apesar de parecer simples, se torna um pouco complicado se o seu ambiente não está preparado ainda, por exemplo, as configurações essenciais do servidor como o Mysql, Nginx, PHP, etc...

Fico a disposição caso tenham alguma dúvida ou algum problema.

Até a próxima!

Nesse artigo vou mostrar um script bem bacana para fazer backup de banco de dados Mysql.

O script irá gerar um arquivo de log para futuras consultas e também terá a opção de remover os backups antigos. Uma dica interessante é utilizar notificações para que quando ocorrer algum erro seja enviado um email ou uma notificação.

Atualização (11/03/2023): Backup na AWS S3 - Escrevi um novo artigo onde adicionei a opção de sincronizar o backup do Mysql no S3 da AWS. Acesse o novo artigo nesse link.

Bora então ver esse script?

Irei colocar trechos do código do script separadamente e com explicações. No final deixarei o script completo para vocês, ok?

Aqui iremos definir o caminho de onde serão salvos os arquivos de logs.

# Caminho do arquivo de log
LOG_DIR=/var/log/backup
LOG=$LOG_DIR/backup_db_$ANO$MES$DIA.log

Nesse trecho definimos o diretório que os backups serão salvos.

# Diretorio onde serão salvos os backups
DIR_BK=/var/backups/database

Para evitar erros durante o processo, antes de salvarmos os arquivos de log e backup iremos verificar se o diretório existe, caso não, iremos criar.

# Verifica se existe o diretorio para armazenar os logs
if [ ! -d $LOG ]; then
    mkdir $LOG
fi

# Verifica se existe o diretorio para o backup
if [ ! -d $DIR_BK ]; then
    mkdir -p $DIR_BK
fi

Aqui vai uma dica bastante útil, você pode definir os bancos de dados que serão backupeados durante o processo. Para isso informe o nome dos bancos separados por espaços.

# Lista dos bancos de dados que serão realizados o backup
DATABASES=(banco01 banco02 banco03)

Agora nesse trecho, iremos fazer um loop percorrendo a lista de bancos que foram informados na linha acima. Após o término do backup iremos compactar o arquivo sql em bz2.

# Loop para backupear todos os bancos
for db in "${DATABASES[@]}"; do
    # Mysql DUMP
    mysqldump -u$USER -p$PASS $db > $DIR_BK/$db'_'$DATA_ATUAL.sql

    # Compacta o arquivo sql em BZ2
    bzip2 $DIR_BK/$db'_'$DATA_ATUAL.sql
done

Nessa linha, informamos que os backups com mais de 5 dias serão removidos, assim economizando espaço. Você pode alterar o número de dias conforme sua necessidade.

# Remove arquivos de backups antigos
find $DIR_BK -type f -mtime +5 -exec rm -rf {} \;

Bom, até aqui vimos alguns trechos do script de backup, que somente eles não fazem sentido.

Esse é um script simples, mas que pode ser melhorado e já resolve e muito nas rotinas de backups.

Veja abaixo o script completo.

#!/bin/bash
# 
# Autor: Aristides Neto
# Email: falecom@aristides.dev
#
# Data: 09/06/2019
#
# Realiza o backup de bancos de dados MySQL
#

# Define usuario e senha do banco
USER='root'
PASS='root'

# Datas
DIA=`date +%d`
MES=`date +%m`
ANO=`date +%Y`
DATA_ATUAL=`date +%Y-%m-%d-%H-%M`

# Data de Inicio do Backup
DATA_INICIO=`date +%d/%m/%Y-%H:%M:%S`

# Caminho do arquivo de log
LOG_DIR=/var/log/backup
LOG=$LOG_DIR/backup_db_$ANO$MES$DIA.log

# Diretorio onde serão salvos os backups
DIR_BK=/var/backups/database

# Lista dos bancos de dados que serão realizados o backup
DATABASES=(banco01 banco02)

# Verifica se existe o diretorio para armazenar os logs
if [ ! -d $LOG_DIR ]; then
    mkdir $LOG_DIR
fi

# Verifica se existe o diretorio para o backup
if [ ! -d $DIR_BK ]; then
    mkdir -p $DIR_BK
fi

# Inicio do backup
echo "MYSQLDUMP Iniciado em $DATA_INICIO" >> $LOG

# Loop para backupear todos os bancos
for db in "${DATABASES[@]}"; do
    # Mysql DUMP
    # Para backupear procedures e functions foi adicionado o --routines
    mysqldump --routines -u$USER -p$PASS $db > $DIR_BK/$db'_'$DATA_ATUAL.sql

    echo "Realizando backup do banco ...............[ $db ]" >> $LOG

    # Compacta o arquivo sql em BZ2
    bzip2 $DIR_BK/$db'_'$DATA_ATUAL.sql
done

DATA_FINAL=`date +%d/%m/%Y-%H:%M:%S`
echo "MYSQLDUMP Finalizado em $DATA_FINAL" >> $LOG

# Remove arquivos de backups antigos - 5 dias
find $DIR_BK -type f -mtime +5 -exec rm -rf {} \;

Conclusão

Lembre-se, sempre faça backup e restore dos seus backups... Tenha certeza que quando for precisar restaurar um banco, você tenha um backup confiável!

O que achou desse script? Se tiver alguma dúvida deixa um comentário que faço questão em ajudar!

Até a próxima!

Vejo muito gente perguntando nos grupos se vale a pena usar CloudFlare e como configurar um DNS.

Se você usa Linode, DigitalOcean, AWS ou qualquer outro serviço e até uma hospedagem compartilhada veja como é fácil configurar.

Se vale a pena? Claro que sim. A CloudFlare é um serviço de distribuição de conteúdo, ao usar seus serviços você terá várias “cópias” dos seus sites em diversos servidores da CloudFlare espalhados pelo mundo.

Assim quando os usuários acessarem seu site ele terá acesso a uma cópia do seu site em cache, e o download será muito mais rápido comparando a um site que não usa a CloudFlare.

Além disso fornece um certificado SSL totalmente gratuito. Proteção contra ataques e muito mais...

Bom, bora configurar então!

Antes de começarmos vamos fazer um pequeno teste. Execute no seu terminal o comando de ping para seu site:

ping aristides.dev

Preste atenção ao tempo de resposta do seu ping. Somente guarde esses valores ok? Iremos usar lá em baixo.

Adicionando o Site

Acesse o site da CloudFlare clicando aqui e realize seu cadastro.

Após o login, a tela que você verá será o dashboard, onde os sites já adicionados estarão disponíveis para configurar. No nosso caso iremos adicionar um novo site. Então clique no botão Add Site.

Você irá digitar o domínio que deseja adicionar. Vou usar um domínio fictício para esse exemplo: dev-linkinside.com.br. Clique no botão Add Site.

A próxima tela diz que a Cloudflare irá consultar os registros de DNS do seu domínio para agilizar o nosso trabalho para que não precisamos digitar todas as informações. Apenas clique em Next.

Tela de informação sobre o processo de consulta de DNS

Após clicar em Next será necessário escolher o plano que deseja. Escolha o plano Free e clique em Confirm Plan. Para saber mais sobre cada plano clique no link ao lado Learn More.

Listagem de planos

Na seguinte tela será exibido todos os registros DNS que a CloudFlare encontrou. Na figura abaixo existem somente 3 registros do tipo A (por ser um exemplo). Caso você já tenha um site funcionando há algum tempo, pode ser que tenha mais registros. Por exemplo: Tipo A, TXT, CNAME, etc.

Listagem de registros DNS encontrados

Após clicar em continuar, virá a informação mais importante que é alterar o DNS para a CloudFlare. Para isso entre no registro.br e altere o DNS para o informado abaixo. No meu caso, já esta com o DNS da CloudFlare por isso a tabela de From e To são iguais.

Alterar registros DNS

Após você alterar seu registro de DNS no registro.br, espere alguns minutos para que a CloudFlare reconheça essa alteração e seu domínio fique ativado como a imagem abaixo.

Status de alteração do serviço

As configurações básicas já estão prontas. Agora você já pode configurar adicionando SSL, cache de arquivos, entre outras opções. Irei citar aqui algumas.

Opções de serviços na Cloudflare

No menu acima existem várias opções para você alterar que deixam seu site mais otimizado, vou citar algumas e deixar você fazer o resto ok?

• Overview: Mostra o status do seu domínio e o resumo de algumas informações.

• Analytics: Estatísticas de tráfego do seu site.

• DNS: A mais importante, onde você irá configurar o IP do seu atual servidor, criar registro para contasde emails, para subdominios e ativar o SSL do seu site deixando a nuvem amarela ligada.

• Speed: Otimizar a performance do seu site minificando os arquivos JS, CSS e HTML.

Deixo para vocês consultarem cada item do menu e ver o que cada um oferece de configuração. Se tiver alguma dúvida deixe sua pergunta nos comentários.

Ah! Lembra quando você executou o comando ping no seu site para ver o tempo de resposta? Então, faça novamente após estiver tudo certo na CloudFlare e veja como estará seu ping agora.

Até a próxima!

Hoje vai uma dica de como visualizar os logs do Laravel de uma maneira mais amigável. Quem nunca abriu aquele arquivo de log do Laravel e se deparou com um monte de linhas e se perdeu com tantas informações? Normal.

O LogViewer é um pacote desenvolvido por Arcanedev e está disponível em seu repositório no GitHub. Para mais detalhes sobre o pacote clique aqui.

Instalando LogViewer

Podemos usar o comando abaixo para instalar o pacote no Laravel 5.6:

composer require arcanedev/log-viewer

Para instalação do pacote na versão 5.5 do Laravel execute o comando:

composer require arcanedev/log-viewer:4.4.*

Nota: Para versões anteriores ao 5.5 verifique esse link e altere o comando conforme sua aplicação.

Para quem estiver usando uma versão do Laravel anterior ao 5.5 será necessário registrar o Service Provider em config/app.php no array providers. Caso não seja seu caso pule esse passo.

'providers' => [
    ...
    Arcanedev\LogViewer\LogViewerServiceProvider::class,
],

Configuração

Antes de começar, devemos fazer uma pequena alteração em nosso arquivo .env.

O LogViewer suporta apenas o canal de log diário. Então se sua versão é a 5.6 vamos alterar a variável LOG_CHANNEL que deve estar como slack, alterando seu valor para daily.

LOG_CHANNEL=daily

Para instalação do Laravel versão 5.5 ou inferior adicione a linha abaixo no seu arquivo .env.

APP_LOG=daily

Comandos Artisan

O pacote disponibiliza alguns comandos que facilitam o gerenciamento da aplicação. São eles:

• Para publicar os arquivos de configuração e traduções

php artisan log-viewer:publish

• Para forçar a publicação

php artisan log-viewer:publish --force

• Publicar somente o arquivo de configuração

php artisan log-viewer:publish --tag=config

• Publicar somente o arquivo de tradução

php artisan log-viewer:publish --tag=lang

• Requisitos da aplicação e a verificação do arquivo de log

php artisan log-viewer:check

É isso ai. A partir de agora sua aplicação estará rodando no seguinte endereço: http://example.com/log-viewer.

Veja algumas imagens do LogViewer.

Dashboard Logviewer

Listagem de logs

Detalhes do log

Dicas adicionais

Bom até aqui esta rodando tudo perfeitamente correto? Mas essa url é manjada, qualquer pessoa com conhecimento no framework pode acessar minha url não é? Então bora lá para resolver isso.

Vamos executar um comando que citei acima, irá publicar os arquivos de configurações e traduções do LogViewer.

php artisan log-viewer:publish

Agora temos o arquivo de configuração no diretório config/log-viewer.php. Nesse arquivo podemos destacar as seguintes opções:

<?php

/* -----------------------------------------------------------------
    |  Diretório do arquivo de Log do Laravel
    | -----------------------------------------------------------------
    */

   'storage-path'  => storage_path('logs'),

/* -----------------------------------------------------------------
    |  Configuração da Rota
    | -----------------------------------------------------------------
    */

   'route'         => [
       'enabled'    => true,

       'attributes' => [
           'prefix'     => 'log-viewer',

           'middleware' => env('ARCANEDEV_LOGVIEWER_MIDDLEWARE') ? explode(',', env('ARCANEDEV_LOGVIEWER_MIDDLEWARE')) : null,
       ],
   ],

No array route temos o attributes e a chave prefix que é a URL atual para acessarmos o LogViewer. Podemos alterar para log-laravel por exemplo. A URL ficaria http://example.com/log-laravel. Bem fácil né?

Ainda assim falta alguma coisa... Dessa maneira qualquer pessoa pode acessar essa página, até mesmo aquele usuário que não esteja autenticado no site. Para alteramos isso reparem que logo abaixo do prefix temos middleware. Ou seja, você pode definir um middleware de autenticação e somente pessoas autorizadas terão acesso a esse link.

Para isso abra seu arquivo .env e adicione a seguinte linha:

ARCANEDEV_LOGVIEWER_MIDDLEWARE=web,auth,custom

Dessa maneira definimos que os middlewares web, auth e custom terão acesso ao LogViewer. Altere conforme sua aplicação.

É isso aí pessoal. Espero que tenha gostado dessa dica e desse pacote que é uma mão na roda para decifrarmos melhor o log do Laravel.

Até a próxima.

Conheci o painel ISPConfig 3 buscando uma solução para meu droplet na Digital Ocean, onde eu tinha meu site e gerenciava ele apenas via SSH. Fazer tudo via SSH muitas das vezes não é produtivo (mas é muito insano), então um painel é uma ótima opção.

Encontrei um site ótimo onde aprendi mais sobre o ISP. Hoje gerencio meu site (este mesmo que você está acessando) através desse painel que otimiza e muito nosso trabalho.

ISPConfig é um painel para gerenciar sites, banco de dados, e-mails, relatórios e muito mais. Para mais informações sobre o painel visite o site https://www.ispconfig.org/.

Só que hoje não será dele que irei falar, mas de como instalar e configurar as diretivas do servidor web para que o Laravel funcione corretamente em seu ISPConfig.

No final do artigo deixarei um link muito bom para quem quiser aprender sobre o ISPConfig.

Criando um site

Para criar um site no ISPConfig vá em Site -> Adicionar novo site. Preencha os campos necessários na aba Domínio e clique em Salvar.

Nota: Para que o site responda pelo seu domínio não esqueça de apontar na sua tabela de DNS o IP do servidor ISPConfig.

Após criar o site entre nele novamente e vá na aba Opções. No final da página você verá a caixa de Diretivas do Nginx. Será aí que iremos adicionar nossas diretivas para que o Laravel funcione.

Caixa de diretivas Nginx

Diretivas do Nginx

Para que o Laravel funcione corretamente, a configuração abaixo é essencial. Copie e cole na caixa de diretivas.

location = /robots.txt {
   root {DOCROOT}public;
   access_log off;
   log_not_found off;
   allow all;          
}

location / {
   root {DOCROOT}public;
   try_files $uri $uri/ /index.php?q=$uri&$args;
}

location @php {
   try_files $uri =404;
   root {DOCROOT}public;
   include /etc/nginx/fastcgi_params;
   fastcgi_pass unix:/var/lib/php7.1-fpm/web1.sock;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_intercept_errors off;
}

Nota: a diretiva acima está definida para o usuário web1 conforme a linha fastcgi_pass unix:/var/lib/php7.1-fpm/web1.sock. Altere essa diretiva para o usuário que você estará usando em seu Painel.

Se vocês notarem nas 3 diretivas acima todos possuem a linha:

root {DOCROOT}public

Essa variável docroot é o próprio painel que facilita nossa vida. Então ficaria algo como:

root /var/www/example.com/web/public

Nessa linha indicamos ao Nginx que ele irá buscar os arquivos nesse diretório, ou seja, quando usamos um Framework que é o caso do Laravel, o diretório onde ficam os arquivos é a pasta public e não a raiz do site. Portanto devemos indicar isso ao nosso servidor web.

Note que até o arquivo robots.txt é necessário essa diretiva, pois caso contrário o servidor retornará um erro 404 caso tentarmos acessar o endereço http://example.com/robots.txt.

Instalando o Laravel

Primeiro vamos criar um usuário shell pelo painel ISP. Vá em Sites -> Usuários shell e clique em adicionar novo usuário. Preencha todas as informações necessárias.

Na opção Shell enjaulado (chroot) sempre escolha Jailkit. Isso deixará o usuário shell sempre em Jail (enjaulado), evitando que caso alguém consiga quebrar sua senha e ter acesso ao servidor fique enjaulado dentro de um espaço do site e não tenha acesso ao resto do servidor.

Acesse seu servidor via SSH com o usuário que foi criado agora (em Jail) e vamos fazer uma instalação limpa do Laravel utilizando o composer no diretório /web do usuário. Será necessário remover todo o conteúdo do diretório /web para que o composer consiga baixar a aplicação. Execute os comandos:

cd /web
rm -rf *
composer create-project --prefer-dist laravel/laravel .

O ponto no final quer dizer que a instalação será feita no diretório atual, ou seja, no /web do usuário. Após o composer finalizar toda a instalação acesse o endereço da sua aplicação e verá a tela inicial do Laravel.

Agora basta criar um banco de dados, usuário para o banco e configurar seu arquivo .env para conectá-lo ao seu banco e começar a brincar.

Bom, vou deixar aqui dois links de sites que eu acompanho bastante e que me ajuda muito com o painel ISPConfig.

• HowtoForge: https://www.howtoforge.com

• Fator Binário: https://fatorbinario.com

Até a próxima.

Esse é o segundo artigo da série Configurando um servidor web com Debian 9. Você pode ver o primeiro artigo clicando aqui.

Nesse artigo irei instalar e configurar o Nginx, MariaDB e o PHP 7.2. E vamos também fazer algumas configurações para deixar nosso servidor web bem bacana.

Atualizando os pacotes

Primeiro vamos atualizar a lista de pacotes do sistema com o comando abaixo:

sudo apt update && sudo apt -y upgrade && sudo apt -y dist-upgrade

Instalar Nginx

O Nginx é um servidor web, proxy reverso e proxy balanceador de carga e pode ser usado também junto com Apache. Ele tem uma performance muito boa comparando com um servidor web rodando o Apache. O interessante que os dois podem ser configurados juntos e fazem um belo serviço.

Execute o comando abaixo para instalar o Nginx:

sudo apt install nginx

Se tudo ocorrer bem, seu servidor web já estará rodando. Verifique no link http://localhost e confira a página de boas vindas.

Instalar Mariadb

MariaDB é baseado no MySQL, uma banco de dados muito robusto e muito utilizado hoje em dia para projetos pequenos e grandes portes. É também o mais utilizado para quem esta começando com a programação.

Execute o comando abaixo para instalar o MariaDB:

sudo apt install mariadb-server

Após a instalação é altamente recomendado executar um script para configurar algumas informações.

Execute o comando:

sudo mysql_secure_installation

• A primeira pergunta é se você já tem uma senha para o usuário root. Caso sim entre com ela e caso contrário apenas tecle enter sem preencher nada.

• Segunda pergunta é se deseja alterar a senha de root.

• Terceira, é se você deseja remover os usuários anônimos do mysql: Y

• Quarta, desabilitar o login remoto do root? Y (Sempre)

• Quinta, remover a base de dados teste e o acesso a ela? Y

• Sexta, recarregar os privilégios? Y

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Conforme a mensagem acima, as alterações foram feitas com sucesso. Agora você esta com o banco configurado e pronto para usar.

Instalar o PHP 7.2

Para instalarmos o PHP7.2 no Debian precisaremos baixar de outro repositório, pois essa versão não é nativa do Debian 8 (Jessie) e 9 (Stretch).

Para instalar execute os seguintes comandos:

sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
sudo apt-get update && sudo apt-get install php7.2-cli php7.2-fpm php7.2-mysql php7.2-curl php-memcached  php7.2-dev php7.2-sqlite3 php7.2-mbstring php7.2-gd php7.2-json php7.2-xmlrpc php7.2-xml php7.2-zip

Caso o comando acima apresenta algum erro ao atualizar, verifique no arquivo /etc/apt/sources.list.d/php.list se o nome da distribuição foi inserida corretamente conforme a linha abaixo.

• Para Debian 8 Jessie

deb https://packages.sury.org/php/ jessie main

• Para Debian 9 Stretch

deb https://packages.sury.org/php/ stretch main

Caso não tenha gravado corretamente, copie a linha correspondente a sua distribuição e altere no arquivo. E tente atualizar a lista de pacotes novamente.

Dica

Vamos alterar uma configuração no PHP para deixarmos ele mais seguro. Navegue até o diretório /etc/php/7.2/fpm/ e abra o arquivo php.ini.

Localize a linha onde existe a diretiva cgi.fix_pathinfo. Deve estar comentado com o sinal # no início da linha. Remova o comentário e caso tiver o valor 1 altere para 0.

cgi.fix_pathinfo=0

Reinicie o PHP:

sudo service php7.2-fpm restart

Configurando o Nginx com o PHP 7.2

Temos agora que configurar um site no Nginx utilizando a nova versão do PHP. Entre no diretório /etc/nginx/sites-available e altere o arquivo default para a configuração abaixo:

server {

    listen 80;
    listen [::]:80;       

    server_name example.com.br www.example.com.br;

    # Log
    access_log off;
    error_log /var/log/nginx/error.log;

    # Directory root
    root /var/www/html/example;
    index index.php index.html;

    client_max_body_size 128M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # pass PHP scripts to FastCGI server
    location ~ \.php$ {
        # Note que aqui definimos a versao que iremos utilizar do PHP
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }

    # deny access to .htaccess files
    location ~ /\.ht {
        deny all;
    }

    location ~ /\.well-known {
        allow all;
    }

    # Set header expirations on per-project basis
    location ~* \.(?:ico|css|js|jpe?g|JPG|png|svg|woff)$ {
        expires 365d;
    }
}

Salve o arquivo e execute o comando abaixo para verificar se as alterações estão corretas.

nginx -t

E reinicie o serviço do Nginx:

sudo service nginx restart

Feito! Seu servidor já estará rodando com sucesso. Caso tenha algum problema ou alguma dúvida não deixe de perguntar.

Até a próxima!

Hoje vou mostrar como é fácil instalar e configurar o Nginx que é um servidor web, proxy reverso, proxy balanceador de carga e tem um desempenho muito bom.

Existem muitas configurações que podemos fazer para melhorar nosso servidor em termos de desempenho e segurança, quero mostrar aqui algumas delas. Irei dividir esse artigo em algumas partes para não ficar muito extenso. Aqui irei começar com a instalação e configuração básica.

Após a leitura desse artigo, acesse meu outro artigo Instalando Let's Encrypt no Ubuntu e Debian com Nginx e complemente a configuração do seu servidor web com certificado SSL gratuito

Instalação

Estou utilizando a distribuição GNU/Linux Debian 9 para esse exemplo. Nada impede que use uma diferente, apenas adapte o comando para o seu sistema.

apt update && apt install -y nginx

Após finalizar a instalação você já pode conferir se seu servidor local esta rodando corretamente. Entre com o endereço http://localhost e veja se a página de boas vindas do Nginx apareceu.

Comandos básicos

Para saber sobre o status, para reiniciar o serviço e checar se as configurações alteradas foram bem sucedidas utilizamos os comandos abaixo:

Verificar o status do serviço Nginx.

service nginx status

Iniciar, parar ou reiniciar o serviço.

service nginx start / stop / restart

Checar se alterações feitas estão corretas.

nginx -t

Configurando Nginx

Os arquivos de configuração ficam em /etc/nginx por padrão. No diretório sites-available ficam os arquivos de configuração dos sites e no diretório sites-enabled ficam os sites que estão ativos no servidor, que na verdade é um link simbólico para o diretório sites-available.

No diretório sites-available temos um arquivo chamado default que é o arquivo padrão do Nginx. Essa é a configuração usada quando acessamos a página de boas vindas após a instalação.

Vamos criar uma configuração nova, para isso entre no diretório /etc/nginx/sites-available e crie um arquivo vazio para o nosso site:

touch example.com

Abra o arquivo com seu editor e cole todo o conteúdo abaixo nele.

server {
    # Porta WEB
    listen 80 default_server;
    listen [::]:80 default_server;

    # Nome do servidor
    server_name example.com www.example.com;     

    # Diretorio de Log
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    rewrite_log on;

    # Diretorio dos arquivos web
    root /usr/share/nginx/html/example.com;

    # Extensões de arquivos que serão lidos
    index index.php index.html;

    client_max_body_size 128M;

    # URL amigáveis
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Configurações PHP FPM.
    location ~* \.php$ {
        fastcgi_pass unix:/run/php/php7.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }

    # Bloqueia arquivo com .ht (Nginx não utiliza o .htaccess como o Apache)
    location ~ /\.ht {
        deny all;
    }

    # Configura cache das extensões abaixo para expirar em 365 dias
    location ~* \.(?:ico|css|js|jpe?g|JPG|png|svg|woff)$ {
        expires 365d;
    }
}

No arquivo acima definimos algumas configurações essenciais para o funcionamento do um site. Vou ressaltar as principais.

1. Na linha listen devemos colocar a porta que o Nginx escutará que é a porta padrão 80. A opção default_server deverá ser usada em somente uma configuração, pois essa será a principal do servidor.

2. Na linha server_name deverá ser inserido o nome do seu domínio.

3. Na directiva root deverá ser o caminho da sua aplicação, dos seus arquivos em PHP por exemplo.

4. No bloco de configurações do PHP é usado o PHP 7.1, caso esteja usando outra versão do PHP deve ser alterado a opção fastcgi_pass unix:/run/php/php7.1-fpm.sock; alterando o php7.1 para a versão instalada no seu servidor.

Testando nossa configuração

Precisamos testar nossa configuração após essas alterações, para isso execute o comando abaixo:

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Se o retorno for igual a resposta acima quer dizer que deu tudo certo. Agora devemos ativar esse site para termos acesso a ele no navegador e reiniciar o serviço Nginx. Entre no diretório /etc/nginx/sites-enabled e digite o comando:

ln -s /etc/nginx/sites-available/example.com
service nginx restart

Pronto, agora seu site deve estar no ar.

Nesse artigo falei sobre uma configuração mais básica do Nginx. Irei fazer uma segunda parte onde irei dar algumas dicas para melhorar o desempenho ativando o cache do Nginx e como configurar para utilizar um certificado SSL grátis.

Até a próxima!

Hoje quero compartilhar um código bem bacana para gerar o sitemap do seu blog automaticamente sem que você precise se esforçar para isso. Parece bom né?!

Se você tem um blog que semanalmente você posta artigos novos e depois precisa manualmente ir no arquivo sitemap e atualizar na mão e até mesmo ir no Google e enviar seu sitemap seu problema irá acabar.

Esse código busca todos os seus posts no banco de dados e cria o sitemap atualizado e sem esforço nenhum envia para o Google! Bom vamos ver como funciona.

Conexão com o banco

Primeiro vamos conectar com o nosso banco.

<?php

// Dados de conexao com o banco
define('MYSQL_HOST', 'localhost');
define('MYSQL_USER', 'db_user');
define('MYSQL_PASSWORD', 'db_password');
define('MYSQL_DB_NAME', 'db_name');
define('HOME', 'http://example.com');

Vamos realizar a conexão dentro de um try catch, podendo assim tratar um possível erro de conexão.

<?php

try
{
    // Realiza a conexao com o banco - PDO
    $PDO = new PDO('mysql:host=' . MYSQL_HOST . ';dbname=' . MYSQL_DB_NAME, MYSQL_USER, MYSQL_PASSWORD);
    $PDO->exec("set names utf8");
}
catch (PDOException $e)
{
    echo 'Erro ao conectar com o banco: ' . $e->getMessage();
}

Conexão realizada. Vamos agora buscar os posts no banco de dados.

Realizando a busca

Agora vamos buscar no banco de dados todos os posts ativos e definir em uma variável a data e hora atual do sistema em formato ISO8601 (2017-11-22T00:06:23-02:00).

<?php

// Realiza a consulta no banco de todas as postagens ativas
$sql = "SELECT * FROM posts WHERE status = 'PUBLISHED'";
$result = $PDO->query($sql);
$rows = $result->fetchAll(PDO::FETCH_ASSOC);

// Data e hora atual
$datetime = new DateTime(date('Y-m-d H:i:s'));
// A linha abaixo me retornará uma data no seguinte formato: 2017-11-22T00:06:23-02:00
$date = $datetime->format(DateTime::ATOM); // ISO8601

Gerando o XML

Agora aqui que é a sacada. Iremos criar o XML e nos posts iremos colocar um foreach para que ele percorra todo nosso array e gere uma lista com os posts atualizados.

<?php

// Gera o arquivo XML do sitemap
$xml = '<?xml version="1.0" encoding="UTF-8"?>
<urlset
    xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9
    http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">
    <url>
        <loc>'.HOME.'</loc>
        <lastmod>'.$date.'</lastmod>
        <changefreq>weekly</changefreq>
        <priority>1.00</priority>
    </url>';
    foreach($rows as $v){
        $datetime = new DateTime($v['updated_at']);
        $date = $datetime->format(DateTime::ATOM);
        $xml .='
        <url>
            <loc>'.HOME.'/'.$v['slug'].'</loc>
            <lastmod>'.$date.'</lastmod>
            <changefreq>weekly</changefreq>
            <priority>0.85</priority>
        </url>';
    }
$xml .= '
</urlset>';

Agora vamos criar o arquivo sitemap propriamente dito.

<?php

// Abre o arquivo ou tenta cria-lo se ele não exixtir
$arquivo = fopen('sitemap.xml', 'w');
if (fwrite($arquivo, $xml)) {
    echo "Arquivo sitemap.xml criado com sucesso";
} else {
    echo "Não foi possível criar o arquivo. Verifique as permissões do diretório.";
}
fclose($arquivo);

Usando a função fopen do PHP iremos abrir o arquivo e caso ele não exista o PHP irá criar um. Depois escreveremos o conteúdo da variável $xml no arquivo que acabamos de criar.

Compactando o arquivo sitemap

Após criarmos vamos compactar o arquito sitemap.xml para sitemap.xml.gz. Para isso usaremos a função do PHP gzencode.

<?php

// Compactar arquivo sitemap para GZIP
$data = implode("", file("sitemap.xml"));
$gzdata = gzencode($data, 9);
$fp = fopen("sitemap.xml.gz", "w");
fwrite($fp, $gzdata);
fclose($fp);

Maravilha! Até agora vimos como criar o arquivo sitemap automaticamente buscando seus posts e gerando o XML e compactando no formato .gz. Esses dois arquivos são os que enviamos para o Google para que ele reconheça a estrutura do nosso site e melhore nosso SEO.

Enviando sitemap para o Google

Que tal fazer o envio automaticamente para o Google? Bora lá!

<?php

// Envia para o Google o novo sitemap gerado
$urlSitemap = "http://www.google.com/webmasters/sitemaps/ping?sitemap=" . HOME . "/";
// Arquivos a serem enviados
$Files = ['sitemap.xml', 'sitemap.xml.gz'];

// Envia os dois arquivos sitemap gerados para a URL do Google
foreach ($Files as $file) {
    $url = $urlSitemap . $file;
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
}

Nesse script definimos a URL do Google Webmaster e os arquivos a serem enviados.

No foreach verificamos os arquivos e enviamos um por vez para a URL utilizando a biblioteca cURL.

Para enviar ao Google você pode configurar o cron do Linux para executar semanalmente por exemplo, ou se adaptar às suas necessidades.

Bom galera espero que seja útil para vocês como é para mim. Caso queiram contribuir com melhorias e ou correções podem deixar um comentário abaixo.

Veja abaixo o código completo:

<?php

// Dados de conexao com o banco
define('MYSQL_HOST', 'localhost');
define('MYSQL_USER', 'user_db');
define('MYSQL_PASSWORD', 'pass_db');
define('MYSQL_DB_NAME', 'name_db');
define('HOME', 'http://example.com');

try
{
    // Realiza a conexao com o banco - PDO
    $PDO = new PDO('mysql:host=' . MYSQL_HOST . ';dbname=' . MYSQL_DB_NAME, MYSQL_USER, MYSQL_PASSWORD);
    $PDO->exec("set names utf8");

    // Realiza a consulta no banco de todas as postagens ativas
    $sql = "SELECT * FROM posts WHERE status = 'PUBLISHED'";
    $result = $PDO->query($sql);
    $rows = $result->fetchAll(PDO::FETCH_ASSOC);

    // Data e hora atual
    $datetime = new DateTime(date('Y-m-d H:i:s'));
    // A linha abaixo me retornará uma data no seguinte formato: 2017-11-22T00:06:23-02:00
    $date = $datetime->format(DateTime::ATOM); // ISO8601   

    // Gera o arquivo XML do sitemap
    $xml = '<?xml version="1.0" encoding="UTF-8"?>
    <urlset
        xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9
            http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">

        <url>
            <loc>'.HOME.'</loc>
            <lastmod>'.$date.'</lastmod>
            <changefreq>weekly</changefreq>
            <priority>1.00</priority>
        </url>';

        foreach($rows as $v){
            $datetime = new DateTime($v['updated_at']);
            $date = $datetime->format(DateTime::ATOM);
            $xml .='
                <url>
                    <loc>'.HOME.'/'.$v['slug'].'</loc>
                    <lastmod>'.$date.'</lastmod>
                    <changefreq>weekly</changefreq>
                    <priority>0.85</priority>
                </url>    ';
        }

    $xml .= '
    </urlset>';

    // Abre o arquivo ou tenta cria-lo se ele não exixtir
    $arquivo = fopen('sitemap.xml', 'w');
    if (fwrite($arquivo, $xml)) {
        echo "Arquivo sitemap.xml criado com sucesso";
    } else {
        echo "Não foi possível criar o arquivo. Verifique as permissões do diretório.";
    }
    fclose($arquivo);

    // Compactar arquivo sitemap para GZIP
    $data = implode("", file("sitemap.xml"));
    $gzdata = gzencode($data, 9);
    $fp = fopen("sitemap.xml.gz", "w");
    fwrite($fp, $gzdata);
    fclose($fp);

    // Envia para o Google o novo sitemap gerado
    $urlSitemap = "http://www.google.com/webmasters/sitemaps/ping?sitemap=" . HOME . "/";
    // Arquivos a serem enviados
    $Files = ['sitemap.xml', 'sitemap.xml.gz'];

    // Envia os dois arquivos sitemap gerados para a URL do Google
    foreach ($Files as $file) {
        $url = $urlSitemap . $file;
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_HEADER, 0);
        curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        curl_close($ch);
    }

}
catch (PDOException $e)
{
    echo 'Erro ao conectar com o banco: ' . $e->getMessage();
}

Se preferir, acesso o repositório no Github.

Até a próxima!

Esse é o primeiro artigo de alguns que irei publicar com o objetivo de ajudar a configurar um servidor web do zero. Mostrarei como configurar os principais serviços e instalar um servidor web para rodar aplicações e sites.

Essa série será sempre com exemplos práticos sem muito entrar em detalhes, irei simplificar o máximo para não ficar maçante. Chega de enrolação e vamos começar...

Nessa série estou utilizando uma instalação limpa do Debian 9 - Stretch.

Criando um novo usuário

Sabemos que por motivos de segurança não devemos usar o usuário root para tarefas rotineiras. Para isso devemos criar um usuário para nós.

O comando abaixo irá criar um usuário com o nome john. Após confirmar com o Enter, você terá que digitar uma senha para o usuário, insira uma senha forte!

Entre com o seu nome e preencha as informações seguintes caso desejar. Não é obrigatório preencher tudo e você pode apenas confirmar com o Enter para pular as perguntas.

adduser john

Agora devemos adicionar seu usuário para podermos executar alguns comandos com super poderes. Para isso execute o comando abaixo:

usermod -aG sudo john

Assim você já poderá executar comandos com privilégios de root utilizando o sudo.

Aumentando a segurança com autenticação de chaves

Podemos melhorar a segurança do nosso servidor inserindo uma chave pública para autenticação. Vamos criar um par de chaves e adicionar ao nosso servidor.

Caso ainda não tenha uma chave execute o comando abaixo. Caso já tenha pode pular para a parte de Instalar a chave manualmente.

Execute o comando abaixo no seu computador local, assumindo que você esteja usando Linux como sistema operacional. Caso esteja usando Windows busque por Criar chave ssh windows no Google.

$ ssh-keygen

Você poderá cadastrar uma senha caso queira é uma segurança a mais para você. Eu particularmente não utilizo. Com uma senha ou sem, a autenticação com a chave privada é uma maneira mais segura de efetuar o login do que uma autenticação básica com apenas a senha.

O comando acima irá gerar uma chave privada id_rsa e uma chave pública id_rsa.pub no diretório local do usuário na pasta ~/.ssh.

Instalar a chave manualmente

Agora vamos instalar essa chave pública que acabamos de criar no servidor. O comando abaixo irá exibir o conteúdo do arquivo id_rsa.pub. Apenas copie o conteúdo do arquivo.

$ cat ~/.ssh/id_rsa.pub

Logado no servidor como root dê o comando abaixo para trocar de usuário assumindo o usuário que criamos nesse tutorial.

su - john

Crie um diretório chamado .ssh dentro do seu diretório home e restrinja suas permissões com os comandos:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

Vamos criar agora um arquivo dentro desse diretório chamado authorized_keys. Nesse exemplo vamos utilizar o editor nano.

$ nano ~/.ssh/authorized_keys

Cole todo o conteúdo do arquivo que você copiou no passo acima para este que acabamos de criar. Para salvar pressione CTRL+O e CTRL+X para sair do arquivo.

Agora vamos restringir o acesso a esse arquivo para que apenas seu usuário tenha acesso com o comando abaixo:

$ chmod 600 ~/.ssh/authorized_keys

Pronto. Chave instalada no servidor e agora poderá acessar seu servidor com mais segurança. Para sair do seu usuário digite exit que ele irá voltar para o usuário root.

Configurando o SSH

Podemos realizar algumas alterações no arquivo de configuração do SSH para proteger nosso servidor um pouco mais.

Abra o arquivo abaixo utilizando o usuário root com seu editor de texto:

nano /etc/ssh/sshd_config

Agora vamos fazer as alterações.

Desabilitar login com usuário root

Vamos bloquear o acesso via SSH para o usuário root, este é um procedimento altamente recomendado para servidores. Iremos deixar que apenas o usuário que criamos tenha acesso ao servidor.

Para isso altere a linha abaixo de yes para no. Ficando conforme exemplo:

PermitRootLogin no

Isso irá restringir o login de root. Pessoas má intencionadas sempre utilizam ataques de força bruta em cima desse usuário e se a senha não for forte o suficiente é certeza que seu sistema estará vulnerável à esse ataque.

Alterando a porta padrão

Agora vamos deixar nosso servidor um pouco mais seguro alterando a porta padrão do SSH que é a 22. Procure a linha abaixo no arquivo de configuração.

Port 22

Nesse exemplo vamos utilizar a porta 54122. Altere a linha deixando a dessa forma:

Port 54122

Nesses dois exemplos que fizemos, nós melhoramos a segurança do nosso servidor. A partir de agora para efeturar login no servidor será necessário especificar a porta SSH nova. Veremos um exemplo mais abaixo.

Quer melhorar a segurança um pouco mais?

Vamos especificar no arquivo de configuração do SSH que apenas o nosso usuário poderá acessar via SSH. Restringindo qualquer outro usuário do sistema.

Abra o arquivo de configuração caso já tenha fechado.

nano /etc/ssh/sshd_conf

Podemos inserir a linha abaixo em qualquer lugar do arquivo, mas para ficar mais organizado vamos inserir após a linha do PermitRootLogin.

AllowUsers john

Para salvar pressione CTRL+O e CTRL+X para sair do arquivo. Para que todas essas alterações surjam efeitos devemos reiniciar o serviço SSH com o comando.

service ssh restart

E como saber se tudo que fizemos deu certo? Vamos testar antes de fechar nossa conexão com o servidor.

Abra uma nova janela do seu terminal e efetue uma nova conexão com o servidor via SSH utilizando seu novo usuário. Agora especificando a porta que escolhemos para o serviço.

ssh john@ip_servidor -p 54122

Se tudo correr bem você estará logado no servidor sem utilizar uma senha. Ao logar o sistema verifica sua chave privada com a chave pública no servidor e autoriza sua entrada caso esteja tudo certo.

Para executar comando com privilégios de root informe o sudo antes do comando.

$ sudo apt update

Maravilha. Agora elevamos o nível de segurança do nosso servidor. Lembre-se que só isso não deixará seu servidor com segurança nível hard, é necessário um conjunto de configurações e serviços executando para ter uma proteção maior.

Até a próxima!