bots, devops e docker - msdnshared.blob.core.windows.net€¦ · bots, devops e docker microsoft dx...

Última Atualização: 20/Set/2016

Bots, DevOps e Docker

Lições Aprendidas em 48 horas

Autores:

Alessandro Jannuzzi

Daniel Semedo

Fabio Hara

Fabricio Catae

Lucas Humenhuk

(c) 2016 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in

this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using

it. Some examples are for illustration only and are fictitious. No real association is intended or inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may

copy and use this document for your internal, reference purposes.

ÍNDICE

Introdução ..................................................................................................................................4

Objetivo: Super Bot Cloud.............................................................................................................................. 4

Visão do Processo Completo.......................................................................................................................... 4

Entregas Consistentes e Confiáveis ............................................................................................................... 5

Tecnologias Open Source ............................................................................................................................... 5

Resultado do Projeto ..................................................................................................................................... 6

Processo de Build ........................................................................................................................7

Controle de Versão ........................................................................................................................................ 7

Automação de Build ....................................................................................................................................... 8

Integração com o Slack .................................................................................................................................. 9

Testes e Cobertura de Código .................................................................................................... 10

Testes Automatizados .................................................................................................................................. 11

Análise de Código ......................................................................................................................................... 11

Testes Funcionais ......................................................................................................................................... 12

Deployment.............................................................................................................................. 14

Azure Container Services ............................................................................................................................. 14

Administração .............................................................................................................................................. 15

Docker Client ................................................................................................................................................ 15

Monitoramento da solução ......................................................................................................................... 16

Implementação ........................................................................................................................ 17

Instalando as ferramentas do ASP.NET Core para Visual Studio ................................................................. 17

Criando um projeto ASP.NET com suporte a .NET Core .............................................................................. 18

Criando o Bot usando Microsoft Bot Framework ........................................................................................ 20

Adicionando ao Repositório GIT .................................................................................................................. 23

Configurando o Build Automatizado ............................................................................................................ 25

Customizando o Dashboard do VSTS ........................................................................................................... 29

Criando Testes Funcionais com CodedUI ..................................................................................................... 31

Criando o Azure Container Service com Docker Swarm .............................................................................. 33

Configurando o cliente para conectar com o Cluster Docker ...................................................................... 34

Validando o serviço do Azure Container Service ......................................................................................... 35

Monitorando os serviços com Log Analytics ................................................................................................ 36


Microsoft DX Brasil 4

INTRODUÇÃO

Foram 2 longos dias que passamos trabalhando em um Hackathon (maratona de programação) com o

objetivo de desenvolver um Bot. Nosso time era composto por pessoas com diferentes especialidades e,

por isso, decidimos empregar as técnicas de DevOps para garantir uma entrega ágil e sem perda de

qualidade.

Objetivo: Super Bot Cloud

A ideia era criar um Bot para responder dúvidas sobre Azure. No front-end, usamos o Microsoft Bot

Framework para conectar o Bot com diferentes canais de comunicação (Skype, SMS, e-mail, etc). No back-

end, decidimos colocar robôs de busca rodando em Linux e containers Docker.

Visão do Processo Completo

Nossa preocupação desde o início foi em construir um pipeline de entrega (Build, Release e Teste) para

apoiar na automação de processo. O principal objetivo era remover os passos manuais envolvidos desde

o processo de compilação até a publicação do aplicativo em produção.

Figura 1 – Dashboard de acompanhamento das entregas

Além da economia de tempo, o pipeline minimizava o risco de incluir erros de aplicação no ambiente

produtivo graças aos testes integrados e funcionais. O acompanhamento do pipeline era feito através do

Dashboard (Figura 1), que fornecia informações sobre: tarefas pendentes, resultado dos builds,

distribuição da aplicação, resultado dos testes, monitoração da aplicação e infraestrutura.



Entregas Consistentes e Confiáveis

Nos 5 minutos finais antes do término do Hackaton, o time de desenvolvimento realizou 4 check-ins de

código no repositório. Com base no histórico positivo de alteração de código e deploy para a produção

(Figura 2), o time estava confiante no pipeline de entrega e decidiu subir para o ambiente de produção.

Figura 2 - Histórico de sucesso de deployment

Em um cenário sem esse acompanhamento detalhado, talvez o time não se sentisse seguro em executar

tais modificações em um momento tão crítico, assim como foi ao final do Hackaton.

Tecnologias Open Source

Desde o começo imaginamos criar um projeto baseado em ASP.NET Core rodando em containers Docker.

Todo o desenvolvimento foi realizado com o Visual Studio 2015 rodando em Windows, porém, utilizamos

a versão do .NET Core para garantir compatibilidade com o ambiente Linux (Figura 3).

Figura 3 - Ferramentas de linha de comando do .NET Core

No processo de Build Automation e Release Management, usamos as ferramentas de linha de comando

para distribuir o aplicativo para rodar em máquinas Linux no ambiente de produção (Figura 4).



Figura 4 – Build agente rodando o Docker Client para distrbuir a aplicação em containers

A vantagem em usar o Linux em produção é sua integração nativa com o Docker. No caso do Windows, os

containers estarão disponíveis a partir do Windows Server 2016.

Resultado do Projeto

Conseguimos finalizar o projeto do Bot usando as tecnologias propostas inicialmente. Ganhamos muito

conhecimento ao longo desses dois dias que nos servirá para as próximas semanas e meses. No final,

nosso resultado foi positivo e, por isso, decidimos consolidar parte do aprendizado nesse documento.

Convidamos você também a participar de um Hackathon. Essa é uma experiência totalmente diferente da

rotina de trabalho, pois você será desafiado a trabalhar com novas tecnologias em um tempo

extremamente curto e sob alta pressão.



PROCESSO DE BUILD

Dedicamos muito tempo para montar o processo de build automatizado. Esse esforço inicial se traduziu

em economia de tempo ao longo do projeto.

Controle de Versão Todos os códigos ficaram armazenados em repositórios GIT, que facilitou muito a colaboração em time

(Figura 5).

Figura 5 - Colaboração de código usando GIT

Em um ambiente de desenvolvimento com GIT, é importante que haja commits pequenos e frequentes

para evitar os conflitos.

Figura 6 - Visual Studio Team System permite criar múltiplos repositórios GIT

O Visual Studio Team System (VSTS) permite criar vários repositórios GIT privados (Figura 6). A vantagem

de usar múltiplos repositórios foi diminuir a quantidade de conflitos em merge.



Automação de Build

Usamos o processo de Build automatizado no Visual Studio Team System (VSTS) para centralizar as

compilações de código e rodar os testes unitários. No caso, definimos um processo para cada um dos

projetos: Bot, WebCrawler e Worker (Figura 7).

Figura 7 - Definição do Build Automation no Visual Studio Team System (VSTS)

O processo de compilação é realizado em agentes (Figura 8).

Figura 8 - Agente rodando o processo de build

Usamos os Hosted Agents (disponibilizados pelo VSTS) e instalamos agentes adicionais em máquinas Linux

para ajudar no empacotamento da aplicação em container Docker. Curiosamente, nosso processo iniciava

com a compilação em Windows e terminava na distribuição para máquinas Linux.



Integração com o Slack

Sempre que um novo build era realizado, a equipe recebia notificações via Slack (Figura 9).

Figura 9 - Notificações via Slack

A integração do Visual Studio Team Services (VSTS) com o Slack ocorria sempre que subíamos uma nova

versão, alterássemos o status de um Work Item ou ocorresse um novo Deployment (Figura 10).

Figura 10 - Integração entre VSTS e Slack, especificando quais notificações são disparadas

Essa comunicação dava maior visibilidade ao processo de desenvolvimento e deployment, ajudando no

nosso trabalho durante o Hackaton.



TESTES E COBERTURA DE CÓDIGO

Faltando 5 minutos para terminar o Hackathon, ainda faltavam recursos cruciais para o funcionamento

correto do Bot. Nesses últimos minutos, o time de desenvolvimento disparou 4 check-ins de código – um

deles, faltando 5 segundos para acabar o tempo.

Imagine o nosso desespero se o build falhasse logo nos últimos minutos antes de acabar o Hackaton. Após

noites mal dormidas, 2 dias intensos de planejamento e trabalho, tudo seria em vão. Entretanto, depois

de várias entregas realizadas com sucesso em produção (Figura 11), tínhamos plena certeza de que a

versão final chegaria pronta para ser demonstrada aos jurados.

Figura 11 - Histórico do pipeline de entrega

Foi exatamente isso que aconteceu: mais um Deployment feito com sucesso. Os números ajudam a

explicar o grau de confiança. O segredo para entregas consistentes e confiáveis é ter Build e testes

automatizados (Figura 12).

Figura 12 - Build e testes automatizados

Configuramos os testes unitários, cobertura e qualidade de código para melhorar o sucesso de entrega

do build nos ambientes de Desenvolvimento, Homologação e Produção.



Testes Automatizados

Em momentos de extrema urgência, é comum ver desenvolvedores criando “gambiarras” para resolver

problemas e terminar sua alteração sem testar. Como efeito colateral, essa prática pode causar

comportamentos inesperados, prejudicando o comportamento da aplicação em produção.

O primeiro passo para automatizar testes é, na definição do Build do Visual Studio Team System (VSTS),

configurar os testes unitários para rodar junto com a compilação dos binários.

Figura 13 – Definição de Build Automatizados no VSTS

Assim, teremos uma primeira estatística sobre a porcentagem de Builds criados com sucesso (Figura 13).

Análise de Código

Instalamos um servidor SONAR (http://www.sonarqube.org) para auxiliar na análise da qualidade de

código (Figura 14).

Figura 14 - Código-fonte analisado pelo SONAR

http://www.sonarqube.org/



Essa ferramenta auxilia na identificação de código-fonte duplicado ou mal-feito, ajudando a melhorar a

qualidade de entrega.

Figura 15 - Integração do SONAR com o VSTS

A integração do SONAR com o Visual Studio Team System (VSTS) é feita através de passos adicionais na

definição do Build (Figura 15).

Testes Funcionais

O Visual Studio Team System (VSTS) permite configurar os ambientes de Desenvolvimento, Stage,

Produção com diferentes pipelines de tarefa.

Figura 16 - Ambientes de desenvolvimento, stage e produção

Usamos o ambiente de Stage para rodar os testes funcionais. Nesse caso, referenciamos os artefatos

gerados no processo de build e copiamos para o agente de teste (Figura 17).

Figura 17 - Cópia da DLL do projeto de testes funcionais, que foi gerada durante o build



Usamos máquinas virtuais como agentes pré-configurados para permitir rodar testes de UI (Figura 18).

Figura 18 - Rodando os testes automatizados em um agente customizado

Configuramos testes de desempenho para medir o tempo de resposta nas API’s do Bot (Figura 19).

Figura 19 - Teste de desempenho

Durante o Hackaton, criamos um único teste funcional, que validava a conversação do usuário com o Bot.

Essa era a principal funcionalidade do projeto e, por isso, jamais poderia falhar em produção.



DEPLOYMENT

Uma das principais características do projeto era a possibilidade de aumentar o poder de processamento

dos robôs com apenas um comando. Decidimos usar containers (Figura 20), orquestrados pelo Docker

Swarm e com a infraestrutura disponibilizada pelo Azure Container Services.

Figura 20 - Containers Docker em execução

Azure Container Services

Utilizamos o Azure Container Services para hospedar os microserviços de back-end da aplicação

(WebCrawler e Worker). Este serviço possibilita a criação de um cluster de múltiplas máquinas virtuais

para hospedar e gerenciar containers Docker, permitindo a implementação de alta disponibilidade e

escalabilidade dos containers em execução.

Durante a criação do cluster, o administrador tem a opção de escolher o gerenciador de containers:

DCOS: solução da Mesosphere baseada nos projetos Mesos e Marathon da Apache Foundation.

O serviço possui uma interface web de administração, permitindo que o administrador aumente

o número de containers através do portal administrativo do Marathon.

Docker Swarm: solução da própria Docker, que permite agrupar um conjunto de máquinas

virtuais executando Docker Engine em uma única visão lógica.

Para este projeto, escolhemos o Docker Swarm, pois nossa intenção foi continuar explorando as

ferramentas de administração de linha de comandos do projeto Docker (Figura 21).

Figura 21 - Ferramentas de linha de comando do Docker Swarm



Os componentes de uma implementação de Docker Swarm criada pelo Azure Container Services contém

um conjunto de máquinas virtuais no Azure com o Docker Engine instalado, chamados de agentes.

Quando um container é instanciado, sua execução será direcionada para um dos nós (VMs) deste grupo

de agentes (Figura 22).

Figura 22 - Componentes do Azure Container Services com Docker Swarm

Há também um grupo de máquinas virtuais de administração. Os nós de administração, chamados de

master, são os responsáveis por monitorar os agentes e agrupá-los de forma a prover uma visão

centralizada do pool de recursos (CPUs e memória) disponíveis no cluster.

Neste projeto utilizamos um único nó como master, mas poderia ser escolhida uma configuração multi-

master para aumentar a disponibilidade de toda a solução.

Administração

Para acessar os serviços e aplicações dentro dos containers em execução nos agentes, o Azure Container

Services cria automaticamente um componente de Load Balancer para as portas 80, 443 e 8080 e

direcionadas para as mesmas portas das máquinas virtuais. Isso possibilita executarmos containers com

essas portas expostas (mapeadas para as mesmas portas que a dos nós).

As VMs dos masters e agentes são hospedadas em diferentes subnets. Para administrar os agentes, o

Azure Container Service implementa um NAT com tradução de IP e portas para que qualquer conexão

externa para a porta 2200 seja entregue na porta 22 (SSH) do master.

Dentro deste túnel seguro, criamos uma outra conexão para o serviço de administração do Docker Swarm,

que utiliza a porta 2375.

Docker Client Uma vez configurado o Azure Container Services com suporte a SSH, utilizamos no projeto mais um host

Linux simples. Esse host tem as ferramentas de Docker Client instaladas e serve como interface de



administração do Docker Swarm. Neste host cliente administrativo, iniciamos o túnel SSH com o endpoint

exposto no master para trafegar a comunicação do Docker Swarm – porta 2375 (Figura 23).

Figura 23 - A exposição do serviço da porta 2200 no master serve para fecharmos um túnel SSH

Essa máquina foi usada como agente de build do VSTS.

Monitoramento da solução

A monitoração da solução utilizou o Log Analytics, parte integrante do Operations Management Suite

(OMS). Através deste recurso é possível monitorar os principais serviços do Microsoft Azure e, por isso,

aplicamos para o cenário do Hackathon.

Figura 24 - Dashboard final da solução de monitoração

Recursos incluídos na monitoração:

Servidor Linux de produção com Docker + Swarm

Servidor Linux do ambiente de Stage

Servidor Windows Server 2016 TP5 com Container Services

Foi utilizado uma Storage Account para armazenar os logs do SYSLOG e Event Viewer dos servidores

monitorados. A quantidade de logs recebidos diariamente atingiu a média de 69MB, portanto optamos

por utilizar uma subscription grátis do Log Analytics (500MB de log diário e 7 dias de retenção).



IMPLEMENTAÇÃO

Instalando as ferramentas do ASP.NET Core para Visual Studio

O primeiro passo é instalar o Visual Studio 2015 (https://www.visualstudio.com/) e suas dependências:

Visual Studio 2015 Update 3

https://go.microsoft.com/fwlink/?LinkId=691129

.NET Core 1.0.0 - VS 2015 Tooling Preview 2

https://go.microsoft.com/fwlink/?LinkID=824849

Durante a instalação, foi necessário rodar a linha de comando.

DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1

Para testar a instalação, rodamos o comando dotnet na linha de comando.

https://www.visualstudio.com/

https://go.microsoft.com/fwlink/?LinkId=691129

https://go.microsoft.com/fwlink/?LinkID=824849



Criando um projeto ASP.NET com suporte a .NET Core

Se você já está acostumado ao Visual Studio, a criação do projeto usando o Visual Studio é feita

diretamente a partir do Menu: File -> New Project.

Em seguida, podemos escolher o template inicial. No nosso caso, criamos um microserviço baseado em

REST API.

Ao invés do Visual Studio, o projeto poderia ser criado via linha de comando:

Em seguida, podemos rodar o site diretamente pela linha de comando. O primeiro passo é restaurar as

dependências usando dotnet restore.



Depois rodamos o projeto com dotnet run.

O site está no ar e disponível na porta 5000.



Criando o Bot usando Microsoft Bot Framework

Faça o download do template para Bot Application (http://aka.ms/bf-bc-vstemplate), salvando o arquivo

ZIP na pasta Visual Studio 2015 Project Templates.

Crie um novo projeto no Visual Studio usando o template:

O modelo é um Bot funcional que recebe um texto do usuário como entrada e repete o texto como saída.

A lógica do Bot se encontra no MessagesController.cs. Neste caso, o código recebe o texto da mensagem

do usuário e cria uma mensagem de resposta.

http://aka.ms/bf-bc-vstemplate



Podemos testar o código usando o Bot Framework Channel Emulator (https://aka.ms/bf-bc-emulator).

No exemplo abaixo, estamos rodando o Bot no endereço http://localhost:3979 e, por isso, ajustamos o

parâmetro Bot URL para apontar para http://localhost:3979/api/messages.

O passo seguinte é publicar a aplicação no Azure. A forma mais fácil é usar a opção “Publish” do projeto

e escolher Microsoft Azure App Service.

Depois de publicar a aplicação na Web, podemos entrar no portal https://dev.botframework.com e

registrar o Bot.

https://aka.ms/bf-bc-emulator

http://localhost:3979/

http://localhost:3979/api/messages

https://dev.botframework.com/



Um passo importante é configurar o “Messaging endpoint”, apontando para o website publicado nos

passos anteriores. Normalmente, o endereço é http://<meu-site>.azurewebsites.net. Em seguida, clique

no botão “Create Microsoft App ID and password” para obter a identidade do aplicativo e sua credencial.

Essas informações devem ser copiadas para o arquivo Web.config do projeto.

Por fim, configure os canais de comunicação do Bot.



Adicionando ao Repositório GIT

É importante começar o projeto com controle de versão. Para isso, basta usar a linha de comando no

diretório raiz do projeto.

git init

Depois executamos os comandos:

Git add .

Git commit -m "initial commit"

O projeto está versionado em um Git Local na máquina do desenvolvedor.

Podemos replicar o código do repositório local para um repositório remoto. Dessa forma, será possível

compartilhar o código com a equipe, além de servir como um backup do código.

Nesse caso, usamos o Visual Studio Team System (VSTS) e começamos com “Create Team Project”.

O novo projeto possui uma série de itens no menu: Code, Work, Build, Test, Release.



Em seguida, selecionamos o Menu -> Code para obter as informações necessárias de como associar o

repositório local ao repositório remoto recém criado.

Vamos executar o GIT PUSH do repositório local através dos seguintes comandos.

git remote add origin <url>

git push -u origin --all

Ao finalizar a execução do git push, observamos que a opção Menu -> Code do VSTS apresenta uma

interface diferente. Isso significa que o repositório remoto recebeu as alterações do repositório local.



Configurando o Build Automatizado

Antes de começar, é importante certificar que os arquivos .SLN e .CSPROJ existam dentro do projeto. Esses

arquivos são gerados automaticamente pelo Visual Studio ao abrir o projeto do ASP.NET Core.

Na opção Menu -> Build do VSTS, existe a possibilidade de configurarmos o Build automatizado.

Iniciamos criando uma nova definição de Build e selecionamos o template “Visual Studio”, que já

contempla tarefas associadas com o MSBUILD.

Em seguida configuramos o repositório e branch (master). Podemos configurar com Continuous

Integration, ou seja, toda vez que houver um GIT PUSH, haverá uma compilação automática no servidor.



Esse template contém os seguintes passos pré-definidos: restaurar dependências NuGet, build da solution,

rodar os binários de teste, publicação dos símbolos, upload do arquivo como artefato.

No caso do ASP.NET Core, podemos modificar os passos e deixar somente as tarefas essenciais. Além disso,

é necessário incluir um novo passo de Command Line.



Nesse passo, restauramos as dependências manualmente.

Salvamos a definição do build e enfileiramos sua execução com “Queue new build”.

O resultado será a console do agente de Build:

Se o build rodar com sucesso, o resultado fica armazenado em um repositório denominado artefato.



Os resultados podem ser baixados ou visualizados na interface gráfica:



Customizando o Dashboard do VSTS

A criação do dashboard e integração são recursos nativos do VSTS e em poucos cliques você consegue

inseri-los em seus projetos.

Você poderá escolher quais builds, releases, branches e repositórios, requisitos e queries que gostaria de

inserir no dashboard, além de customizar views e relatórios.

O nosso dashboard, por exemplo, apresentava um resumo sobre os principais componentes do pipeline.

No canto inferior do

dashboard clique nas

opções de edição

Escolha o seu

widget e adicione

ao dashboard



Além disso, integramos com o PowerBI para trazer informações de segurança do Azure e dados analíticos

sobre o uso do Bot



Criando Testes Funcionais com CodedUI

Uma das preocupações que tínhamos era de garantir que o Bot em nenhum momento falaria palavrões

ou respondesse aos jurados uma pergunta fora do contexto. Visando atender a este cenário, criamos uma

rotina de teste funcional para perguntar e validar as respostas do Bot.

Criamos um projeto de Coded UI utilizando o Visual Studio Enterprise 2015.

No script criamos um método de avaliação para cada pergunta. Assim, analisamos a resposta do Bot com

base no histórico.

Uma vez que temos o script e projetos criados no Visual Studio, torna-se necessário inserir o projeto como

parte da solução do projeto. Esse código irá gerar uma DLL ao final do processo de build.

Em seguida, criamos um novo plano de testes para definir a ação.



Para integrarmos os testes do Visual Studio Coded UI com o VSTS é preciso criar o plano de testes e um

caso de testes, relacionando a DLL do projeto do Coded UI.

Usando os agentes pré-configurados, esse teste roda dentro do Visual Studio Team System (VSTS).



Criando o Azure Container Service com Docker Swarm

No portal do Azure, procuramos pelo template Azure Container Services e clicamos em Create. Precisamos

informar os dados do endpoint que permitirá a conexão do tunel SSH. A chave pública de SSH a ser

informada deverá ter o comentário “<usuario>@<host-de-origem>” no final.

Na segunda tela do assistente, escolhemos a infraestrutura de serviços para o cluster. Selecionamos o

orquestrador Swarm.

Neste momento, definimos o número de agentes e de masters do cluster, bem como o prefixo DNS que

será usado como nome do serviço. Este prefixo será usado como base para criação dos hostnames dos

componentes do Swarm.

As telas subsequentes são para confirmação das informações e criação do ambiente.



Configurando o cliente para conectar com o Cluster Docker

No nosso projeto, configuramos o host “dxbrstaging” como uma VM Linux para se comunicar com o

cluster Docker Swarm. Neste host, no diretório home do usuário root, existe o diretório “.ssh” com a chave

privada correspondente a esta chave pública aqui informada.

Após o cluster Docker Swarm ser criado, utilizamos o host de administração (dxbrstaging) para iniciarmos

o tunel SSH:

As opções “-N” e “-p”, especificam respectivamente o usuário/host para fechar o tunel e a porta a ser

utilizada. A opção “-L”, especifica uma porta local para criar um socket TCP em estado LISTEN, pronto para

receber conexões e encaminhá-las para dentro do túnel SSH.

Uma vez entregue a conexão na extremidade do tunel, a conexão é encaminhada para o hostname:porta

informado também na opção “-L”. Neste caso, o hostname “localhost” indica que a própria extremidade

do tunel receberá a conexão encapsulada na porta 2375.

Esta porta é o serviço do Docker Swarm. Com o tunel criado, o host está pronto para emitir comandos

para o Swarm.

Para isso, precisamos indicar ao utilitário de linha de comando do Docker que ele deve se conectar ao

Swarm. Isso é feito através do ajuste da variável de ambiente DOCKER_HOST conforme abaixo:

A partir deste momento, podemos executar os comandos tradicionais do Docker.



Validando o serviço do Azure Container Service

Nesse documento, abordamos a configuração dos containers Dockers seguindo os passos:

1. Criação do Azure Container Service com Docker Swarm

2. Definição das chaves SSH no servidor (Portal Azure) e no cliente (diretório .ssh)

3. Configuração do túnel SSH entre o host cliente e o Azure Container Service

4. Configuração da variável ambiente DOCKER_HOST

Ao rodar os comandos do Docker Client, teremos o seguinte comportamento: toda conexão do comando

docker ocorrerá no host local na porta 2375. Esta porta, por sua vez, é o socket criado localmente para

ser encapsulado via tunel SSH para o host master do Azure Container Services. O mapeamento de porta

recebe a conexão encapsulada e conecta à porta 2375 equivalente ao serviço Swarm.

Quando tudo isso estiver funcionando, os comandos tradicionais do Docker vão rodar (Ex: docker run).

Será possível visualizar os containers em execução com docker ps:

Podemos ver toda a configuração do agrupamento de VMs do Swarm com docker info:



Monitorando os serviços com Log Analytics

O processo para habilitar o Log Analytics deve ser realizado pelo Azure Portal:

Clicar em NEW e digitar LOG ANALYTICS

Clicar em CREATE

No setup inicial é importante definir alguns parâmetros:

OMS Workspace: Nome da solução de gerenciamento

Subscription: Selecionar a subscription

Resource Group: Voce pode utilizar o mesmo Resource Group onde estão localizadas as VMs ou

criar um novo.

Location: Selecionar a localidade onde possui o serviço.

Pricing Tier: Selecionar o preço de acordo com a necessidade. Por exemplo, Free é suficiente para

o nosso ambiente de Hackathon



Depois de criado o serviço, é necessário definir uma Storage Account para receber todos os logs de

SYSLOG, Event Viewer, etc.

Após selecionar o Storage Account, basta selecionar quais máquinas virtuais serão monitoradas. Através

do próprio portal, você pode selecionar as VMs e marcar para conectar. Desta forma o Log Analytics

automaticamente vai instalar o agente dentro da VM e passar a coletar seus dados.

Feito este processo, já teremos os logs sendo enviados para a Storage Account, restando apenas

selecionar quais eventos desejamos filtrar e quais monitorações serão utilizadas.

Atraves do portal do OMS, você terá um controle separado do ambiente:



No portal do OMS acesse o menu lateral direito em Settings. Selecione o menu Data em seguida adicione

os Facilities (em SYSLOG) ou eventos (em Windows Event Logs).

Em seguida retorne a tela inicial do OMS e clique em Solutions Gallery. Adicione as seguintes Solutions:

Agent Health

Change Tracking

Security and Audit

Antimalware Assessment

Containers

Dashboard final da solução de monitoração

bots, devops e docker - msdnshared.blob.core.windows.net€¦ · bots, devops e docker microsoft dx...

Documents