Image for post
Image for post
Photo by Hack Capital on Unsplash

*DevOps: {Des}complicado?!

Guia sobre DevOps… :)

Segundo a AWS podemos entender DevOps como “combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e consigam competir de modo mais eficaz no mercado.”

Essa é uma prática em que somos capazes de provisionar e configurar a infraestrutura de forma programável, utilizando técnicas da engenheira de software, como controle de versão e integração continua.

A partir de soluções de automatização conseguimos facilitar e incrementar muitas soluções em diversos cenários para ter entregas muito mais eficazes e eficientes, alguns desses cenários onde podemos utilizar de párticas de infraestrutura como código são:

1 . Gerenciamento de maquinas virtuais: Vagrant

Um dos grandes problemas durante o desenvolvimento de um software é sua configuração em relação ao ambiente e suas dependências, com isso muita das vezes, o desenvolvedor perde algum tempo com o objetivo de instalar tudo que é necessário para trabalhar localmente, além de ter cenários, onde o ambiente de desenvolvimento seria muito diferente do servidor, aonde aquele mesmo projeto seria instalado e ficaria executando(“aonde seria feito o deploy”).

Buscando minimizar esse problema, temos como criar uma maquina virtual que pode ser replicada tanto no ambiente de desenvolvimento do programador como no servidor onde o código vai estar hospedado.

Para provisionar maquinas virtuais utilizando de programação, podemos utilizar o Vagrant, solução desenvolvida pela HashiCorp com intuito de facilitar a criação e configuração de maquinas virtuais. Com o Vagrant além de provisionar a maquina virtual, conseguimos alterar configurações de redes, SSH, portas, etc.

2. Gerenciamento de configuração: Puppet

Quando começamos a ter um ambiente com várias maquinas virtuais, fica muito complicado configurar cada uma delas, muitas das vezes é comum nesse cenário ter conflito de configurações ou uma maquina ficar sem alguma configuração.

//Imagina, vc, em plena sexta-feira, tendo de configurar um ambiente de 400 maquinas, uma de cada vez… :)

Uma solução para esse problema é utilizar o Puppet, um gerenciador de configurações via código, sendo, na prática, alguns arquivos de configuração que serão aplicados durante o provisionamento das maquinas ou contêineres utilizadas em conjunto ao Vagrant, ou Terraform.

// Vc provavelmente está pensando que pode usar de shell script para isso, boa sorte…

3. Provisionamento automatizado: Ansible

Outra solução que também pode ser utilizada tanto para o provisionamento automatizado, gerenciamento unificado de configuração e uma alternativa feliz ao Shell script, é o Ansible.

Com o Ansible, a partir de poucos arquivos, conseguimos fazer as mais diversas instalações e configurações nas maquinas ou contêineres, sendo necessário apenas o Python instalado e o SSH configurado no destino aonde serão aplicadas as configurações, além de termos uma comunidade muito ativa mantendo essa solução. Utilizando do Ansible, podemos criar automações reutilizáveis nos mais diferentes cenários para os mais diversos ambientes.

// Vai configurar um Gitlab na mão… :)

Extra: Packer
Já imaginou criar uma imagem, provisionar essa imagem em alguma cloud como AWS, Azure ou Google cloud, configura-la utilizando o Ansible ou Puppet, apenas com um aquivo Json, essa é a ideia do Packer.

4. Contêineres

Ao passar do tempo, viu-se que manter varias maquinas virtuais poderia ser um problema, pois além de exigirem instalar em cada uma dessas maquinas virtuais, um sistema operacional e seus drivers, além de ser uma solução que consume muitos recursos computacionais.

Com a objetivo de resolver os mesmo problemas das maquinas virtuais, surgiu os contêineres, mesmo ambos sendo soluções muito utilizadas na cultura de DevOps e tendo a missão isolar a aplicação, os contêineres consomem menos recursos computacionais, além de ter um gerenciamento mais facilitado do ambiente e configuração valendo-se de Kubernetes e do Rancher.

  • Docker

Essa é a solução mais famosa e adotada no mercado para criação de imagens customizadas de contêineres, tendo ainda a possibilidade de compartilhar essa imagem no Docker Hub de forma pública ou privada.

  • Kubernetes

Essa é uma solução de criação e gerenciamento de “clusters” para o deploy de containers, tendo a possibilidade ser manoseado via API, além de ter uma extensa documentação e uma grande comunidade com intenção de mante-lo.

//Seu concorrente mais famoso é o OpenShift

  • Helm

Esse é um poderoso gerenciador de pacotes para kubernetes possibilitando a definição, instalação e atualização das mais complexas aplicações no kubernetes através de poucos comandas via CLI e um arquivo de definição YMAL, o chart.

// Já temos charts para deploy do Apache Spark e outras soluções de Big Data de forma automatizada no kubernetes. Chart_Spark

  • Rancher

É uma plataforma de deliver Kubernetes as a Service, ou seja, vai facilitar a gerenciamento, configuração e utilização de um ambiente kubernetes em 300% no mínimo. :)

//Certificação gratuita aqui! <<

Por meio do sonarqude conseguimos verificar de forma automatizada a qualidade do código, sua segurança; desde da etapa de desenvolvimento até sua integração e deploy continuo no ambiente de produção.

Um registry é o local para ficar salva a imagens de containers criadas com a intenção de serem reutilizadas em um momento oportuno, existem atualmente diversas soluções e uma das mais utilizadas é o Jfrog Artifactory por sua versatilidade e fácil gerenciamento de repositórios.

// Uma alternativa é o Sonatype Nexus

Trabalhando em um time de desenvolvimento, graças ao tempo é perceptível que muito dos desenvolvedores colocam seus códigos em um repositório comum, somente bem perto ou quase no prazo final da entrega e com isso temos muitas situações como uma funcionalidade parrar de funcionar ou não dar tempo de fazer todos os testes em conjunto ao desenvolvimento.

De modo a solucionar isso, dento do movimento cultural de DevOps, começarão a surgir esteiras que integram e automatizam parte do desenvolvimento para que tanto o desenvolvimento, teste e aceitação do código, acontecerem dentro dos prazos estipulados, de forma correta.

Durante o desenvolvimento de código, geralmente é adotado a organização da aplicação em Mono-Repo, onde em apenas em um repositório centralizado está toda a solução ou Multi-Repo, onde a solução é divida em módulos independentes entre si que ficam diferentes repositórios.

Uma das propostas mais adotadas nesse sentido é o GitOps, onde através de versionamento de código com git, SVN ou outra solução de versionamento em repositório de código como GitHub ou Gitlab é acionado uma esteira automatizada com o Jenkins, que vai:

  • Diminuir os riscos e burgs, melhorar a qualidade e segurança durante o desenvolvimento, através do uso do sonarqube com finalidade de aplicar testes automatizados e criar relatórios customizados.
  • Salvar os códigos copilados, bibliotecas, binários e imagens criadas com intenção de serem utilizada no futuro através de registry como Jfrog Artifactory ou Nexus.
  • Fazer os deploys nos ambientes de desenvolvimento, homologação e produção de forma contínua e automatizadas ou utilizar o Argo Project.

O Jenkins é uma solução de código aberto com o objetivo de criação de pipelines automatizadas muito adotadas pelo mercado com uma enorme quantidade de puglins de integração com as mais diversas soluções para as mais diferentes estrategias.

//Além do Jenkins somos capazes de recorrer ao GoCD, Bamboo, Travis CI, Team City, Circle CI, Gitlab, AWS Code Pipeline, Azure

O deploy continuo geralmente é a última ou penúltima fase da integração continua, onde todo o sistema já foi amplamente testado em relação qualidade e segurança do código e está ¨pronto¨ para que aconteça instalação nos ambientes(deploy).

A grande diferença do deploy continuo e da entregação continua é a interação humana na aprovação dos códigos, quando o time ver que a aplicação já está madura o suficiente a ponto de ir à produção em uma nova versão e para que isso ocorra tem der ter aprovação tanto do times envolvidos como até a área de negócio.

O Argo é uma das muitas soluções existentes, o grande diferencial é sua fácil utilização, rica interface gráfica e controles avançados que possibilita utilizar diferentes estrategias até mesmo de recovery em alguns cenários.

//Uma alternativa ao Argo é o urban{code}

As estratégias de CD mais utilizadas são:

  • Blue-Green

O deploy acontece, gerando uma versão nova(Green) e mantendo a antiga(Azul) no ambiente, entre as versões fica um roteador que em algum momento pre-definido vai direcionar ao poucos o fluxo de acesso para a nova versão, mantendo a versão antiga caso suja algum imprevisto.

  • Canary

Podemos considerar a Canary como evolução da Blue-Green, onde apenas uma pequena parcela dos usuários utiliza a nova versão para teste e logo após acontece a mudança de versão.

  • Feature Toggles

Essa estratégia é colocar alguma configuração anterior ao deploy via código que caracterize um determinado usuário como possível testador da nova versão.

Com a cultura de DevOps e o surgimento da grande quantidade de soluções e ferramentas para melhorar e automatizar o processo de desenvolvimento, as grandes aplicações começarão a ser segregadas em um conjuntos de APIs, com o passar do tempo e adoção de um ambiente Kubernetes, se tornaram functions e atualmente é muito comum termos um front-end requisitando um mundo de functions hospedadas em alguma nuvem que utiliza da arquitetura serverless.

  • Service Mash: Istio

Através da grande adoção do kubernetes e a facilidade de criação de API de formas automatizadas, começamos a ter cenário de uma determinada function é extremamente consumida, tendo milhares de requisições por segundos por isso surgiu os service Mash como o Istio.

O Istio tem como objetivo fazer o controle inteligente do trafego, fazendo ou excluídos os deploys de um determinado serviço, segurança automática com gerenciamento de autenticação, autorização e encriptação dos serviços, controle de políticas de acesso para diferentes APIs que utilizam o serviço, além de fazer monitoração e criação de logs dos serviços.

  • Mensageira/Streams: Apache Kafka

Outra estratégia em relação à finalidade de lidar com um grande volume de requisições é utilizar uma solução para streams de eventos como o apache Kafka, onde as requisições ficariam gravadas em uma fila ou em um grupo de filas e seriam respondidas em outra fila.

OBS: Essas duas estrategias funcionam muito bem se aplicadas no cenário correto!

Com arquiteturas descentralizadas em ambientes cada vez mais diversificados, monitorar uma aplicação tona-se uma atividade quase impossível dependendo da solução e isso geralmente só é visto quando um grande problema acontecer.

//É muito comum, só pensar em monitora o projeto quando ele já está em um ambiente de produção… :(

Existem diversas soluções que podem além de monitorar o ambiente consegue verificar a saúde da aplicação ou micros serviços, aqui temos algumas:

  1. Stack ELK( Elasticsearch + Logstash + Kibana)

A empresa Elastic criou um conjunto de soluções que começarão com o proposito de monitorar logs e com o passar do tempo, novos recursos foram sendo agregados e hoje temos a possibilidade de monitorar o ambiente de diversas formas com o Beats e gerar logs de monitoramento, utilizar o logstash para trabalhar a qualidade dos dados desses logs quase que como uma solução de ETL, o Elasticsearch, um motor de pesquisa customizado e o kibana, uma solução de visualização.

  • Beats:

Os Beats são agentes instalados no ambiente que monitoram e geram logs que podem ser requisitados via API, monitoram desde da utilização dos recucos computacionais como memoria e CPU, a rede da aplicação, integridade de aquivos de dados até o deploy de Function-as-a-Service (FaaS) em alguma cloud.

//Além dos mantidos pela Elastic, a comunidade principalmente no Github veem cada dia criado novos beats com propósitos bem diferentes…

  • Logstash

Essa é uma solução open source para centralizar logs, transformar os dados e inseri-los ou indexa-los em um destino, sendo muito simples de configura-lo e integra-lo com os Beats e outras soluções como o Apache Kafka.

  • Elasticsearch

Elasticsearch é um motor de pesquisa e análise RESTful distribuído, capaz de lidar com grandes volumes de dados. Como o coração do Elastic Stack, ele armazena centralmente seus dados para pesquisas extremamente rápidas, relevância ajustada e análises poderosas que podem ser escalonadas com facilidade.

  • Kibana

Essa é simplesmente uma “interface” de código aberto para visualização das mais diversas formas dos dados no Elasticsearch.

//Existem algumas diferenças nos produtos gratuitos e código abertos para suas versões pagas.

2. Prometheus + Grafana

Outra estratégia de monitoramento é fazer a própria aplicação gerar suas próprias métricas, fazer o Prometheus indexa-las e utilizar o Grafana para visualizar e criar aleta dessas métricas monitoradas.

  • Prometheus

Essa é um conjunto de ferramentas código aberto com o objetivo de monitoramento e gerar alertas, compostas de um server, onde os dados são armazenados em formato de séries temporais, bibliotecas, que podem ser utilizada na aplicação a fim de gerar as métricas, um push gateway apropriado a capturar essas métricas, exporters, para compartilhar os dados das métricas e o alertmanager para criar os alertas e envia-los ompatível com os mais diversos canais como e-mail ou Telegram.

  • Grafana

O Grafana é um projeto código aberto que permite que você consulte, visualize, alerte e entenda suas métricas, independentemente de onde estejam armazenadas. Crie, explore e compartilhe painéis com sua equipe e promova uma cultura baseada em dados criando a mais diversas formas de visualização, Dashboards dinâmicos com a possibilidade de explorar as metrificas e logs, criar aletas e se integram diferentes fontes de dados seja um banco de dado como MySQL, MongoDB e soluções de pesquisas indexadas como o Elasticsearch.

//É possível integrar o Grafana a chatbots para fazer alertas no Telegram.

// A recente super utilização (hype) de Inteligência Artificial(IA), podemos monitorar o ambiente, o contêiner, a function, mas o modelo, sua qualidade e eficacia é outra história. Uma estratégia que vem ganhando forma na comunidade é o Model Drift…

Atualmente temos diversas opções de cloud que temos potencial de utilizar com o objetivo de manter nossa infraestrutura como Google Cloud, AWS e Azure. Para cada uma dessa temos configurações diferentes e maneiras diversas de gerecia-las, a fim de abstrair essa dificuldade podemos usar o Terraform.

O Terraform é uma solução de infraestrutura como código, criado e mantido pela HashiCorp com a finalidade de provisionar e gerenciar infraestrutura independente da nuvem escolhida de forma simples e automatizada.

Na prática, utilizamos o Terrafrom em conjunto com outras soluções como o Ansible para aplicar configurações mais facilmente e gerenciar ambiente de forma customizável.

#Imagine ter de provisionar vários nós kubernetes em diferentes clouds, gerenciar aplicações que estão no AWS e Azure ao mesmo tempo…

Com crescente utilização da cultura DevOps, os engenheiros e arquitetos de dados começaram a utilizar as mais diversas soluções desse meio com o objetivo de automatizar gerenciamento de configuração e provisionamento de ambientes, utilizando, por exemplo, do Vagrant para criação de máquinas virtuais, Ansible para aplicar configurações em massa e Terraform para provisionar os mais diferentes ambientes nas principais nuvens disponíveis.

Muitas soluções de Big Data começarem a ganhar versões para um ambiente de contêineres, veja a seguir:

Alguns exemplos de implementações do Hive com Docker:

Apache Spark para kubernetes:

HDFS:

HBASE:

Apache Kylin:

Apache Airflow:

Kafka:

//Existem muitas outras soluções de Big data que estão ganhando implementações adequado a essa nova realidade, vc está preparado?

Com a popularização da inteligência artificial e seu uso nos mais diferentes meios ao final de 2018, grandes comunidades pelo mundo enxergaram a necessidade de automatização do processo de estudo, treinamento, teste, deploy e monitoramento de novos modelos, em algumas situações demoravam meses apenas para fazer o deploy no ambiente de produção.

A partir da utilização da cultura de devops por parte de um grande número de cientistas de dados e engenheiros de machine learning foi possível criar esteiras customizadas e até mesmo soluções de código aberto que otimizarão a criação e manutenção de modelos compatível com os mais diferentes cenários e ambientes.

Exemplo de esteira automatizada para modelos de IA:

Essa publicação foi apenas uma introdução à cultura Devops, alguns das diferentes soluções existentes, suas utilizações e problemas que buscam resolver, seja na área de desenvolvimento, infraestrutura, Big Data e até mesmo, Inteligência Artificial.

Mais Referências:

Cursos indicados:

#Obrigado por sua leitura! :)

Written by

Estou compartilhando minha opinião e o pouco que sei de forma eventual por aqui. #Obrigado por sua leitura! :) https://www.linkedin.com/in/josueluzardo

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store