Arquivo da categoria: DEVOPS

Projeto Honolulu – Gestão do Windows via web.

20180324_153614910216901548475097.jpg

Você terá a capacidade controlar totalmente a infraestrutura do servidor, permitindo que você os gerencie de qualquer lugar com o Microsoft Edge ou o Google Chrome. Vamos seguir passo a passo para implementá-lo.

O Projeto Honolulu ainda está em pré-visualização técnica (mas em breve!), Aqui estão as suas capacidades atuais:

  • Exibindo recursos e utilização de recursos
  • Gerenciamento de Certificados
  • Visualizador de eventos
  • File Explorer
  • Gerenciamento de Firewall
  • Configurando usuários e grupos locais
  • Configurações de rede
  • Exibindo / finalizando processos e criando despejos de processo
  • Edição do Registro
  • Gerenciando os Serviços do Windows
  • Ativando / desativando funções e recursos
  • Gerenciando VMs do Hyper-V e Comutadores Virtuais (Que vida)
  • Gerenciando Armazenamento
  • Gerenciando o Windows Update

Existem 3 opções para implantar o Microsoft Project Honolulu da seguinte forma:

101017_2308_STEPBYSTEPI2

Eu vou usar a opção 2 para implantar o Microsoft Project Honolulu. Projeto Honolulu requer recursos PowerShell que não estão incluídos no Windows 2012 e 2012 R2 Server, você precisa seguir as etapas para instalá-lo se você estiver usando o Windows 2012 e Windows 2012 R2 como um gateway de projeto Honolulu ou nó gerenciado.

Para Windows Server 2016 não requer os pacotes pois já fazem parte.

Este LAB é com Windows Server 2016.

Registre e baixe o software do Projeto Honolulu no seguinte link:

https://www.microsoft.com/pt-br/evalcenter/evaluate-windows-server-honolulu

honolulu01

3. Faça logon no servidor gateway.

4. Abra o PowerShell e execute o cmdlet a seguir para garantir que o Windows Management Framework 5 ou superior seja carregado.

honolulu02

Vamos instalar?

honolulu03

Na instalação ele vai gerar um certificado temporario a você ou se você tiver um certificado valido já pode instalar direto.

Certifique se a porta 443 é a ideal para você acessar de fora da sua rede, geralmente para acesso de fora usam NAT ou outra porta.

Aqui irei manter a porta 443.

honolulu04

Prossiga com a instalação

honolulu05

Como estamos com uma maquina virtual no Azure libere para acesso externo no NSG (Network Security Group).

honolulu06

Porta liberada vamos la

honolulu07

Finalizado a instalação vamos as configurações.

Você vai acessar https://localhost ou http://127.0.0.1 ou https://iplocaldamaquina

Para instalação via Powershell:

msiexec /i <HonoluluInstallerName>.msi /qn /L*v log.txt SME_PORT=<port> SSL_CERTIFICATE_OPTION=generate

Com certificado próprio:

msiexec /i <HonoluluInstallerName>.msi /qn /L*v log.txt SME_PORT=<port> SME_THUMBPRINT=<thumbprint> SSL_CERTIFICATE_OPTION=installed

honolulu08

Que lindo já esta no ar.

 

honolulu09

Liberamos a porta 443 no Azure, de fora ele pedira autenticação oviamente pelo administrador local cadastrado na instalação do Windows.

honolulu10

Veja que só tem a maquina que eu instalei, mas é possivel como server manager gerenciar as maquinas da sua rede ou datacenter.

Realmente a Microsoft se superou com o Porjeto Honolulu.

Para Windows Server 2012 tem alguns passos a mais

  1. Faça o download e instale o WMF 5.1 para o Project Honolulu Gateway ou o nó gerenciado (é necessário o servidor de reinicialização).

Faça o downloads do pacote abaixo para que instale o pacote do honolulu https://www.microsoft.com/pt-br/download/details.aspx?id=54616

 

honolulu11

Para acessar a maquina ele irá pedir as credenciais. Se você tiver Domain Controle, faça a autenticação com o usuário do domínio.

honolulu12

Veja que praticamente o que você fazia via RDP via web você fará com muita facilidade.

Eu vejo que uma das grande vantagens é gestão de maquinas do Hyper-V, tudo isso via Web.

Um projeto legal é instalar um servidor com Honolulu e ele ser o JumpServer por Network ou por barramento de network. Isso melhora a segurança dos acessos e a concessão mais centralizada.

Em compliances de auditoria e segurança da informação melhora as não conformidades pois você não acessara o servidor no sistema operacional.

honolulu13

Veja do que o Honolulu é capaz.

Pessoal espero que eu tenha contribuído com as comunidades com este post.

Não esqueçam do MVPConf dia 06 e 07 de Abril aqui em https://www.mvpconf.com.br/

 

 

 

Microsoft MVP Conference – #mvpconf

Olá pessoal,
Nos dias 6 e 7 de Abril desde ano, acontecerá na UNIP Taubaté São Paulo o maior evento presencial de experts Microsoft do Brasil – www.mvpconf.com.br, vou tentar enumerar as 5 razões de qualificar como o maior evento de expects e impulsar sua curiosidade para realizar sua inscrição agora:

1. Da comunidade para a comunidade técnica: Primeiro evento técnico presencial organizado por MVPs do Brasil – ainda não sabe o que é MVP? dá uma clicada aqui;

2. Networking: São mais de 70 MVPs do Brasil envolvidos nesse evento, teremos 7 profissionais da Microsoft no Keynote. Já imaginou se conectar pessoalmente com todos presencialmente? Veja quem são:

KEYNOTES:

image

PALESTRANTES:

Palestrantes_mvpconf

3. Ajudar o próximo diretamente: Talvez seja, se não o primeiro evento com taxa de inscrição 100% doada para APAE que você participa diretamente com sua contribuição;

4. Dev e Infra no mesmo evento: São 10 diferentes trilhas, você poder interagir com profissionais de diferentes áreas de atuação. Essa é a transformação digital que todas as empresas estão buscando, como falar com desenvolvedores, profissionais de IT e entender como sinergia dessas áreas em Cloud é fundamental;

palestras_blog

5. Sério que você ainda precisa de uma 5ª razão? ok, a 5ª razão é ‘UP na sua carreira’, pense na sua carreira e o quão é importante o aprendizado constante + razão n.2  – foi em eventos assim que eu comecei minha jornada e você como começará a sua?;

FAÇA SUA INSCRIÇÃO PELO SYMPLA: https://www.sympla.com.br/microsoft-mvp-conference__246657

Post gentilmente cedido pela MVP Sara Barbosa em https://sarabarbosa.net/2018/03/20/microsoft-mvp-conference-mvpconf/

Profissões em transformação

 

Olá pessoal.

Quando comecei a trabalhar em arquitetura tive muito contato com a área de desenvolvimento, programação e novas tecnologias.

Com a transformação digital na boca de cada pessoa de TI perpetuando e ecoando a até ficar chato de tanto ouvir umas das transformações que vi.

Antigamente chamavam de consultor, algumas empresas ainda chamam. Outras chamam de pré-vendas. Mas o que mas tem se falado. Veja abaixo:

Arquiteto: Um arquiteto de solução, de cloud ou de software ou de infraestrutura é o cara que necessariamente esteve na linha de frente de um desenvolvimento de software ou aruando em infraestrutura por muito tempo e naturalmente evoluiu na area, atua primariamente na construção de solucões baseadas nas necessidades do negócio, fazendo uso dos serviços e recursos tecnológicos já existentes na empresa. Outro objetivo é o de alinhar novas solucões aos princípios arquiteturais já definidos, respeitando os padrões e integrações da empresa. Ele é o elo entre a área de negócios e a área de implantação e projetos atuando no desenho do projeto. Em alguns casos ele atua em pocs (provas de conceitos) e atua captando melhorias contínuas.

O velho e bom cara de ITPro tem se transformado.

Devops: É o novo e transformado ITPro. Além dele melhorar a produtividade automatizando ambientes tradicionais de virtualização ele é o cara que coda é desenvolve código para scripts e orquestração para subir ou realizar deploys de infra como serviço é plataforma como servico. Seja ela em AWS ou Azure ou Openstack ou Vmware ou HyperV ou Linux. Desde que orquestre, use serviços que automatize o ambiente que ele esteja proposto a fazer. Em resumo ele coda em infra.

DesignUX: User eXperience. É o cara que vai realizar os testes de experiência de um usuário. Exemplo: Ele vai pegar um celular e testar o App que foi desenvolvido e sentir o que o usuário sente e ver se ficou bom ou ruim. É um papel preponderante de o App vai ter sucesso ou não. Veja como é fácil de usar Whatsapp e Facebook. Um DesignUX realmente fez o teste antes de sair a atualização para a massa.

Developer Frontend: É o cara responsável pela interfaceweb. Ele projeta e constroi e otimiza toda frente de desenvolvimento. Em resumo HTML, Javascript, CSS, webstandard, aplicação de SEO (Search OFF Engine). Obviamente este cara tem que manjar de programação e ele tem facilidade em desenvolver com um viés de design.

Developer backend: É o cara por traz das “cameras”, ele que faz as ligações do que o Frontend projetou. Interage o que o é coletado recebendo os dados programando regras de negócios, api realizando scripts e códigos um pouco mais complexos com conexões para banco de dados e ligações tambem com outros sistemas e webservices.

Fullstack developer: Bem, este é o cara, ele trata tanto do frontend como também o que o backend faz. É o cara mais completo.

Hoje em ambiente Ágil tem se dividido muito as tarefas de desenvolvimento por isso que as tarefas de desenvolvedores ficaram mais segmentadas.

Empresas maiores estão nesta mudança. É também tem se dividido e segmentado justamente pela agilidade na entrega.

Uma pitada de segurança neste meio tem o tester ou robôs que analisam o codigo que o front e o back desenvolveram e aplicam na camada para achar vulnerabilidades para que os mesmos possam melhorar e entregar os projetos com seguranca.

As corporações contratam empresas pentesters ou sistemas baseados em OWASP.

Um dos meus favoritos é da Qualys. https://www.qualys.com/

Analista de Segurança da Informação: Este irei resumir bastante mas muito é uma peça chave. Ele analisa os riscos dentro de um compliance, garante a confidencialidade, a integridade e a disponibilidade dos dados da empresa.

Dentro de segurança da informação temos a área ativa onde a atuação pelo nome já se fala por si mesma, na atuação de firewalls, pentest, vulnerabilidades e atuação na segurança dos dados.

A segurança passiva é mais nos compliances da corporação garantindo a políticas, plano de continuidade e toda documento criada seja cumprida dentre os funcionários e fornecedores respeitem.

Claro que tudo que mencionei pode mudar daqui 3 ou 4 anos.

Os níveis de conhecimento garantem que o RH segmente salarios e beneficios de dentro das políticas de cargos Junior, pleno e sênior de cada corporação.

Espero que tenha esclarecido em minhas palavras as profissões em transformação.

Até mais pessoal

O que é o Rancher? Deploy no Azure.

Olá pessoal

Hoje irei orientar como realizar o deploy do Rancher no Azure.

Mas você sabe o que é o Rancher?

Rancher

O Rancher é uma plataforma opensource de gerenciamento e gestão de contêiner docker. Ele faz muito bem o chamado deploy e orquestração tanto local, em ambiente onpremissess e movimentação e gestão de contêiner com Azure, AWS, Digital Ocean, dentre outras.

Levante Kubernetes em minutos

A instalação do Docker e Kubernetes requer muitos elementos: drivers para armazenamento e rede, monitoramento, segurança, RBAC e muito mais. No entanto, instalá-los usando Rancher é realmente fácil. Simplesmente, adicione um novo ambiente. Rancher irá guiá-lo através do processo de anexar hosts locais ou baseados na nuvem, bem como instalar e configurar todos os componentes para você.

Veja a arquitetura de gestão do Rancher

container-management

 

Leia o resto deste post

2018 vem ai

Olá pessoal

2018 vem aí. 2017 foi intenso e prazeroso. Quero agradecer aos quase 2000 assíduos, os mais de 100Mil views e acessos, frequentadores dos grupos, blogs, fanpage, redes sociais, palestras, cursos e parceiros que disseminamos Microsoft Azure, Office 365 e Cloud Computing.

Sem vocês a disseminação, a passagem de conhecimento não aconteceria.

O conhecimento precisa ser passado.

Cloud Computing Brasil https://www.facebook.com/ccomputingbrasil/

Microsoft Brasil não oficial https://www.facebook.com/groups/microsoftbr/

Linux ABC https://www.facebook.com/groups/linuxabc/

Meu Perfil https://www.facebook.com/fabiosilvacloud/

Grupo Azure Brasil

https://www.facebook.com/groups/azurebrasil/

YouTube

https://www.youtube.com/channel/UCqxKrvBO23tA81PQiIlkP4Q

LinkedIn

https://www.linkedin.com/in/silvapfabio

Perfil MVP

https://mvp.microsoft.com/en-us/PublicProfile/5002105

Aos parceiros ChurropsOnDevops TIEspecialistas BlogUOL Diveo Fabio FOL Arqgenti

Ser MVP antes de tudo é ser comunidade e ajudar a disseminação do conhecimento.

F e l i z N a t a l e 2 0 1 8 P r o s p e r o

Provisionar maquinas virtuais através de GIT, AzureCLI e Visual Studio.

azurecli

Olá Pessoal

Na ultima WEBCAST que fiz no canal ARQGENTI eu mostrei como está o mercado tanto do lado corporativo como empresa e como anda o lado do profissional.

Muitas mudanças para os 2 lados.

Não é mais uma tendencia, é uma constatação.

O mercado está mudando, as empresas estão mudando com a transformação digital.

Leia o resto deste post

Visual Studio, Deploy Máquina Virtual Azure

Para quem está iniciando ou está utilizando plataforma de nuvem como o Azure, quer ser ágil e iniciar a cultura DEVOPS, o visual studio é a ferramenta aliada a infra “AGIL”.

Hoje quando falamos de agilizar processos e melhorar tempo de projeto o Visual Atudio será seu amigo de notebook ou Desktop.

Irei mostrar um passo a passo para um deploy de máquina virtual no Azure.

PRIMEIRO PASSO.


Iremos abrir a ferramenta no menu Conectar a uma subscrição do Azure.

É bem simples, é a mesma conta do Azure

Conecte na conta do Azure

Após a sua conexão ele exibe suas assinaturas e os serviços que o Azure tem conectividade através do Azure. A caixa do lado esquerdo mostra os serviços do Azure e do lado direito está mostrando as assinaturas do Azure e as regiões que você pode criar os serviços.

Como estamos a criar uma infra ágil vamos realizar um deploy de máquina virtual.

Vamos clicar com botão direito do mouse em Virtual Machines e ir em create Virtual Machines.

Vamos escolher a subscrição que iremos usar.

A escolha do sistema operacional é bem simples e bem didático. Escolha e clique em NEXT.

O próximo passo é o mesmo passo que temos para criação do nome da máquina, usuário e senha.

Este passo iremos criar o serviço de Cloud Service.

Cloud Services criado iremos para o próximo passo. Lembrando que este Deploy esta baseado em ASM.

Como estamos criando baseado em ASM este passo irá mostrar as portas que serão liberados para acesso. No caso Powershell remoto e RDS.

Aguardo o deploy ser concluído.

Deploy concluído e maquina pronta para ser acessada.

Veja no Visual studio que a maquina está em ASM ela é diferente das ARMS.

Pelo próprio Visual Studio podemos conectar via RDP.

Acesse com usuário e senha criados.

Pronto, sua maquina criada e provisionada através do visual studio.

O tempo de criação é bem mais rápido do que no Tenant.

Então Visual Studio aprovado para quem está adotando cultura DEVOPS e melhorar tempo de projeto.

Veja no Azure que a máquina foi criada com êxito.

Próximo post máquina virtual em modo ARM.

Até a próxima

Modelos de migração IaaS para Azure parte 01

Olá pessoal

Muita gente tem dúvida ou quer ter ideia de como levar seus, servidores, workloads e apps locais para nuvem.

Pois bem, o maior desafio e um administrador ou gestor é levantar informações para apresentar ao seu superior o investimento em capex que vai utilizar pelo menos nos próximos 5 anos.

Dependendo do levantamento o valor mesmo diluído pode até passar mais de 5 anos pagando seu capex através de financiamentos e o que investiu depreciou.

Isso é um tormento por que passa os 5 anos e novamente seu parque de hardware e software está ultrapassado.

E vai além por que dependendo do tempo você estende para mais tempo perdendo até em conhecimento e atualização de capacidade do time de TI.

A nuvem traz capacidade de investimento baixo inicial, capacidade de crescimento rápido, sazonalidade e elasticidade.

A orientação que estamos passando independe de nuvem e neste post irei mostrar como podemos decidir levar seus insumos para o Azure.

Normalmente o cliente quer levar “AS IS”, ou seja quer levar do jeito que é seu parque.

Mas para otimizar e melhorar o uso e adoção para jornada para nuvem o aconselhamento é analisar o quanto cada servidor ou aplicação está consumindo.

Quando você trabalhava com seu ambiente de hardware puro você avaliava o quanto sua aplicação estava consumindo e comprava um hardware com o dobro da capacidade para manter o ambiente com performance e espaço.

Depois veio a era da virtualização e já melhorou e deu disponibilidade de o ambiente ser migrado para outro ambiente de host com mais flexibilidade e rapidez de transferência de um host para o outro. Não se preocupando muito com o tamanho da máquina e mantendo ainda performance e espaço.

Com o advento da nuvem recebemos o boom da transformação e avaliar realmente o que pode ser feito e avaliar em detalhes o que o seu servidor esta consumido em alguns pilares:

  1. CONSUMO DE PROCESSAMENTO
  2. CONSUMO DE MEMORIA
  3. CONSUMO DE ESPAÇO EM DISCO
  4. CONSUMO DE I/O DE DISCO
  5. CONSUMO DE BANDA

Estes 5 pilares te credenciam preferencialmente em ambiente Iaas (Infraestrutura como serviço) a garantir que você terá um custo baixo com boa performance.

Para isso irei mostrar 2 ferramentas que você pode utilizar para avaliar ir para nuvem com saúde e performance.

Microsoft Azure Virtual Machine Readiness Assessment.

Esta ferramenta lhe traz um relatório e lista de verificação bem detalhado de Workloads e Servidores que estão prontos e gabaritados para nuvem Azure.

Para baixar esta ferramenta clique neste link https://go.microsoft.com/fwlink/?LinkId=391029&clcid=0x416

Instale a ferramenta que é bem simples e siga os passos.

Aguarde a instalação finalizar.

Ferramenta finalizada agora vamos analisar.

A ferramenta permite que eu faça analise de um ambiente Active Directory, SQL Server e Sharepoint.

Ele checa requisitos do ambiente para que você possa coletar de forma correta.

Alguns requisitos de banda são necessários para a analise.

Requisitos de Firewall são necessários para que a ferramenta possa analisar de forma correta.

Requisitos de localidade são importantes para que sejam criados ambiente no Azure.

Muito importante informa se o ambiente é de produção, dev ou teste.

Importante se o que você irá levar para o Azure será dados ou a imagem VHD e se os requisitos cobrem a levar imagem de sua máquina virtual ou física local.

Como mencionei acima é importante se a sua aplicação tem participação no uso de I/O de disco para que seja escolhido de forma correta os modelos de maquinas no Azure.

Se seu ambiente tem DR (Disaster Recover)

Neste caso está sendo coletado dados de um ambiente de Active Directory.

Finalizado irá gerar um relatório.

Salve em um diretório onde possamos ver o relatório de laboratório.

O relatório eu coloquei neste link para ser analisado que é montado um template com informações do Active Directory e através dele é possível informações de objetos de dados de servidores da sua rede.

Baixe aqui https://1drv.ms/w/s!An-dPolj_Ee_g5Qw45EZwP5FkwkErg

Fique ligado no próximo post

Até mais

Transferências de dados com AZCOPY para Azure

Olá pessoal

Hoje irei demonstrar a vocês de uma forma fácil e barata a transferência de dados através do AZCOPY.

Se você já tem a familiaridade do XCOPY o AZCOPY é semelhante.

Além de você ter como ferramenta de transferência o Azure File Explorer ou o REDGATE Azure explorer o Azcopy é uma forma barata ou para automação através do Windows com Schedule.

O AzCopy pode ser baixado deste link ( http://aka.ms/downloadazcopy ). Para instalar, basta seguir as instruções de instalação.

A instalação é bem tranquila.

Depois de baixar siga com NEXT

Aceite os termos do contrato e siga com NEXT.

Escolha o diretório onde o software ficará armazenado e siga com NEXT

Continue com o procedimento e clique em INSTALL

Finalize a instalação com FINISH para continuarmos com o procedimento.

O modelo de conexão que iremos realizar é este abaixo.

@echo off

cd C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy

AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

Vejamos cada componente do comando AzCopy em detalhes:

  • / Source: – Especifica a origem do arquivo. Essa fonte pode ser armazenamento de arquivos regular ou qualquer uma das opções de armazenamento do Microsoft Azure . Neste caso, estamos especificando uma pasta em nossa unidade C.
  • / Dest: – Especifica o destino do comando. Se o destino for uma das opções de armazenamento do Microsoft Azure, será necessário especificar uma chave de destino para acessar o armazenamento.
  • / DestKey – Especifica a chave da conta de armazenamento para a chave de destino
  • / S – Define o modo para recursivo, o que fará com que o AzCopy copie todos os blob ou arquivos.
  • / Y – Confirma que o comando será feito do AzCopy

Agora você precisa criar um storage acount no Azure.

Acessamos o portal e criamos um storage como General purpose que o foco é transferência de arquivos como OBJETO em geral.

Lembrando que temos 4 tipos de arquivos como BLOCO, ARQUIVOS, TABELAS e FILAS.

Saiba mais aqui sobre ARMAZENAMENTO em https://docs.microsoft.com/pt-br/azure/storage/storage-introduction

Storage criado, vamos criar a pasta que vai receber os dados dentro de FILES. Iremos clicar em FILES e criar a pasta.

Clicamos em File Share e criamos a pasta

Criamos com nome como exemplo acima e configure o tamanho até 5120GB ou 5TB (Cinco terabyte) que é o tamanho máximo de casa pasta.

Pasta criada, e veremos o endereço URL e a chave para que faça sentido o comando AZCOPY para a cópia dos arquivos.

Em Connect teremos um exemplo para conexão e iremos usar como exemplo para utilizar o comando para transferir os dados.

AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

Seguindo o exemplo AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

A copia dos arquivos que fiz através da minha maquina é da pasta Documentos

C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy>AzCopy /Source:C:\Users\fpere\Documents\ /Dest:https://storagefabiosilva.file.core.windows.net/pastafabio /DestKey:C4br1VX27L8P67BFQ1yrr0U7qYnaZ2hFHIevE8Ph/999jXV0BOnisxAkUOuWDpIjXsXFnhbposten9jUtwpg6g== /S /Y

Veja que quando é dado o comando em amarelo ele mostra em tempo real os arquivos sendo transferidos.

Para conferir que os arquivos estão sendo transferidos através do portal vá na pasta criada e veja os arquivos.

Outra forma também de visualizar os arquivos podemos utilizar através no mapeamento em https://fabiosilva.com.br/2016/11/23/mapeando-storage-no-linux-e-no-windows-no-azure/ ou pelo Azure explorer ou Redgate Azure Explorer mencionado acima.

Arquivos transferidos finalizados com êxito.

Espero que tenham gostado.

Até o próximo post.

Automatização de ambiente com Ansible

ansible

Você que tem ambientes grandes e complexos, ambiente com muitas maquinas hoje é até um pecado não automatizar ambiente.

Com o advento de Nuvem e virtualização cada vez mais teremos mais servidores e serviços separados com elasticidade.

O Ansible veio para automatizar ambiente e facilitar as tarefas chatas de atualização ou instalação de patchs e muito mais.

Eu não vou mostrar como instalar o Ansible pois é uma tarefa relativamente facil

yum install ansible ou apt-get e blá blá blá o google mostra o caminho a você que se interessar.

header2

Introdução

Ansible é um sistema de gerenciamento de configuração fácil que pode ser usada para automatizar e organizar suas tarefas de configuração do sistema para uma grande rede de computadores. Enquanto alguns outros sistemas de gerenciamento de configuração exigem muitos pacotes diferentes para ser instalado nos sistemas de servidor e cliente, com Ansible, você só precisa instalar um componente do servidor e ter acesso SSH para as máquinas clientes.

Neste guia, vamos discutir playbooks ansible, que são forma de criar scripts automatizados para configurar computadores clientes do Ansible.

Vamos supor que você tem um servidor Ansible configurado e alguns clientes.

No nosso guia, o servidor é um Ubuntu 12.04 máquina, e os clientes que vão ser configuração também são Ubuntu 12.04 máquinas, para facilidade de explicação.

Quais são Playbooks ansible?

Playbooks ansible são uma forma de enviar comandos para computadores remotos via script através do SSH. Em vez de usar comandos Ansible individualmente para configurar remotamente os computadores a partir da linha de comando, você pode configurar ambientes complexos inteiros por meio de um script para um ou mais sistemas.

Playbooks ansible estão escritos no formato de serialização de dados YAML. Se você não sabe o que é um formato de dados, pense nisso como uma maneira de traduzir uma estrutura de dados (listas, matrizes, dicionários, etc) em um formato que pode ser facilmente armazenado no disco. O arquivo pode então ser utilizada para criar a estrutura em um momento posterior. JSON é um outro formato  de dados popular, mas YAML é muito mais fácil de ler.

Cada cartilha contém uma ou mais peças, que mapeiam hosts para uma determinada função. Ansible faz isso através de tarefas, que são basicamente as chamadas em módulos.

Explorando um Playbook Básico

Veja o comando.

--- - hosts: droplets tasks: - name: Installs nginx web server apt: pkg=nginx 
state=installed update_cache=true notify: - start nginx handlers: 
- name: start nginx service: name=nginx state=started 

Vamos em seções para que possamos entender como esses arquivos são construídos e que cada peça significa.

O arquivo começa com:

 --- 

Este é um requisito para YAML para interpretar o arquivo como um documento adequado. YAML permite que vários “documentos” em um arquivo, cada um separado por --- , mas Ansible só quer um por arquivo, de modo que este só deve estar presente na parte superior do arquivo.

YAML é muito sensível ao espaço em branco, e usa isso para agrupar diferentes peças de informação em conjunto. Você deve usar apenas espaços e não tabs e você deve usar espaçamento consistente para o arquivo a ser lido corretamente. Itens no mesmo nível de recuo são considerados elementos irmãos.

Os itens que comecem com um - são considerados itens da lista. Os itens que têm o formato de key: value operar como hashes ou dicionários. Isso é muito bonito tudo o que há para YAML básica.

Documentos YAML, basicamente, definir uma estrutura de árvore hierárquica com os que contêm elementos mais à esquerda.

Na segunda linha, temos o seguinte:

 --- - hosts: droplets 

Este é um item de lista no YAML como aprendemos acima, mas uma vez que é no mais à esquerda do nível, é também uma “peça” Ansible. Peças são basicamente grupos de tarefas que são executadas em um determinado conjunto de hosts, que lhes permitam cumprir a função que deseja atribuir a eles. Cada jogo deve especificar um host ou grupo de exércitos, como fazemos aqui.

Em seguida, temos um conjunto de tarefas:

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - start nginx 

No nível superior, temos “tarefas:” no mesmo nível “hosts:”. Este contém uma lista (porque começa com um “-“), que contém pares chave-valor.

O primeiro, “nome”, é mais do que uma descrição do que um nome. Você pode chamar isso de qualquer coisa que você gostaria.

A próxima chave é “apto”. Esta é uma referência a um módulo Ansible, assim como quando usamos o comando ansible e digitar algo como:

 ansible -m apt -a 'whatever' all 

Este módulo permite especificar um pacote e o estado que ele deve estar em, que é “instalado” no nosso caso. O update-cache=true parte diz a nossa máquina remota para atualizar seu cache de pacotes (apt-get update) antes de instalar o software.

O item “notificar” contém uma lista com um item, o que é chamado de “começar nginx”. Este não é um comando interno Ansible, é uma referência a um manipulador, que pode executar determinadas funções quando é chamado a partir de uma tarefa. Vamos definir o “start nginx” manipulador abaixo.

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - 
start nginx handlers: - name: start nginx service: name=nginx state=started 

A seção “manipuladores” existe ao mesmo nível que os “hosts” e “tarefas”. Manipuladores são como tarefas, mas eles só correr quando lhes foi dito por uma tarefa que ocorreram alterações no sistema do cliente.

Por exemplo, temos um manipulador aqui que inicia o serviço Nginx após o pacote é instalado. O manipulador não é chamado a menos que o “Instal servidor web nginx” resultados da tarefa em mudanças no sistema, o que significa que o pacote teve de ser instalado e já não estava lá.

Nós podemos salvar este em um arquivo chamado algo como “nginx.yml”.

Só por algum contexto, se você fosse escrever esse mesmo arquivo em JSON, que poderia ser algo como isto:

 [ { "hosts": "droplets", "tasks": [ { "name": "Installs nginx web server", 
"apt": "pkg=nginx state=installed update_cache=true", "notify": [ "start nginx" ] } ], 
"handlers": [ { "name": "start nginx", "service": "name=nginx state=started" } ] } ] 

Como você pode ver, YAML é muito mais compacto e maioria das pessoas diria mais legal.

Executando um Ansible Playbook

Depois de ter um guia estratégico construído, você pode chamá-lo facilmente usando este formato:

 playbook.yml ansible-playbook

Por exemplo, se queríamos para instalar e iniciar o Nginx em todos os nossos servidores, poderíamos emitir este comando:

 ansible-playbook nginx.yml 

No entanto, se nós gostaríamos de filtrar a lista , aplicar-se apenas a um desses hospedeiros, podemos adicionar um sinalizador para especificar um subconjunto dos arquivos:

 ansible-playbook -l host_subset playbook.yml

Então, se nós só quesermos instalar e executar o Nginx em um servidor, por exemplo “host3”, que poderia digitar o seguinte:

 ansible-playbook -l host3 nginx.yml 

Adicionando recursos ao Playbook

Agora a nossa cartilha tem esta aparência:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

É simples e funciona, em vários hosts ou em um só.

Podemos começar a expandir a funcionalidade através da adição de tarefas.

Adicionar um padrão Index Arquivo

Podemos dizer-lhe para transferir um arquivo do nosso servidor Ansible no host, adicionando algumas linhas como este abaixo:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644

  handlers:
    - name: start nginx
      service: name=nginx state=started

Podemos, então, fazer um diretório chamado static_files em nosso diretório atual e coloque um arquivo index.html dentro.

 mkdir static_files nano static_files/index.html 

Dentro desse arquivo, vamos apenas criar uma estrutura básica html:

 <html> <head> <title>This is a sample page</title> </head> <body> 
<h1>Here is a heading!</h1> <p>Here is a regular paragraph. Wow!</p> 
</body> </html> 

Salve e feche o arquivo.

Agora, quando executar novamenter o playbook, Ansible irá verificar cada tarefa. Vai ver que Nginx já está instalado no host, por isso vai deixá-lo ser. Ele vai ver a nova seção tarefa e substituir o arquivo index.html padrão com o do nosso servidor.

Resultados

Quando instalar e configurar os serviços manualmente, é quase sempre necessário saber se suas ações foram bem-sucedidas ou não. Podemos cozinhar essa funcionalidade em nossos playbooks usando “registrar”.

Para cada tarefa, que pode, opcionalmente, registrar seu resultado (sucesso ou falha) em uma variável que podemos verificar mais tarde.

Ao utilizar esta funcionalidade, também temos de dizer Ansible para ignorar erros para essa tarefa, já que normalmente ele aborta a execução cartilha para aquela máquina se qualquer problema acontece.

Assim, se quiser verificar se uma tarefa falhou ou não para decidir sobre os passos subsequentes, podemos usar a funcionalidade de registo.

Por exemplo, poderíamos dizer o nosso guia estratégico para carregar um index.php  se ele existir. Se essa tarefa falhar, poderíamos em vez de tentar carregar um index.html. Vamos verificar a condição de falha na outra tarefa, porque nós só queremos fazer o upload do arquivo HTML se o arquivo PHP falhar:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.php for host
      copy: src=static_files/index.php dest=/usr/share/nginx/www/ mode=0644
      register: php
      ignore_errors: True

    - name: Remove index.html for host
      command: rm /usr/share/nginx/www/index.html
      when: php|success

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644
      when: php|failed

  handlers:
    - name: start nginx
      service: name=nginx state=started

 

Esta nova versão tenta carregar um arquivo de índice PHP para o local indicado. Ela regista com sucesso da operação em uma variável chamada “PHP”.

Se esta operação foi bem sucedida, a tarefa ira remover o arquivo index.html é executado em seguida.

Se a operação falhar, o arquivo index.html é carregado em vez disso.

Conclusão

Agora, você deve ter um bom controle sobre como automatizar tarefas complexas usando Ansible.

Este é um exemplo básico de como você pode começar a construir a sua biblioteca de configuração.

Combinando definições de host e do grupo como nós aprendemos sobre este tutorial, e com variáveis disponíveis para preencher as informações, podemos começar a montar sistemas complexos que interagem uns com os outros. Em um artigo futuro, vamos discutir como implementar variáveis em nossos playbooks e criar funções para ajudar a gerenciar tarefas complexas.

Como ainda falamos de nuvem o Ansible em ambiente IaaS publico ou não é ideal.

Teste no Azure e Amazon e não precisa falar que ambiente Onpremisses, todos funcionaram.

Tem um demo sensacional no site oficial:

https://www.ansible.com/

Veja um howto facil.

Se você quer seguir para um caminho de DEVOPS o Ansible é a porta de entrada.

Espero ter ajudado.

Abraços

 

Escotilha Livre

Um canal para lançar as sementes do conhecimento, promovendo o uso de soluções livres.

simple Ula

I want to be rich. Rich in love, rich in health, rich in laughter, rich in adventure and rich in knowledge. You?

Junior Galvão - MVP - Data Platform

Select 'MVP | MCC | MSTC | MIE' As Awards

Keith Tenzer

Cloud Computing Platforms and Code

odelot stuff

Tech, Dev, Games and Life!

iCutsman

Technology Blog