Arquivo da categoria: DEVOPS

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

 

Sulamita Dantas

DBA SQL Server & Analista BI

Ao redor do buraco tudo é beira!

Um cavalo morto é um animal sem vida!

Exame

Notícias do Brasil e do Mundo. Economia, Política, Finanças e mais. ➤ Entrevistas, Análises e Opinião de quem entende do Assunto! ➤ Acesse!

randieri.com

Il blog di Cristian Randieri

TEC OFFICE PRODUTIVO

Tec Office Produtivo é um grupo de treinamentos, dicas e tutorias de informática sobre aplicativos utilizados em escritórios.

GOLD RECIPES.

GOLD RECIPES.

%d blogueiros gostam disto: