Orquestrando sua rede com Ansible e Gitlab - Histórico de revisão

Redstud: /* Introdução */

2020-08-18T16:46:39Z

Introdução

Fernando.frediani: Adicionado tag à categoria Infraestrutura

2020-01-10T15:21:23Z

Adicionado tag à categoria Infraestrutura

Renato.Oliveira: /* Criando templates com Jinja2 */ Correção na identação

2020-01-10T11:09:11Z

Criando templates com Jinja2: Correção na identação

Fernando.frediani: Ajustes na formatação dos códigos fonte

2020-01-10T05:55:05Z

Ajustes na formatação dos códigos fonte

Mostrar alterações

Fernando.frediani: Ajustes na formatação do texto

2020-01-10T05:28:54Z

Ajustes na formatação do texto

Mostrar alterações

Renato.Oliveira: /* Referências */

2020-01-10T00:18:35Z

Referências

Renato.Oliveira: /* Referências */

2020-01-09T22:51:08Z

Referências

Renato.Oliveira em 22h04min de 9 de janeiro de 2020

2020-01-09T22:04:42Z

Mostrar alterações

Renato.Oliveira em 22h03min de 9 de janeiro de 2020

2020-01-09T22:03:00Z

Mostrar alterações

Renato.Oliveira em 21h46min de 9 de janeiro de 2020

2020-01-09T21:46:37Z

@@ Linha 218: / Linha 218: @@
 [10]   (https://github.com/renatoalmeidaoliveira/TutorialAnsible)
 '''AUTOR:''' [[Usuário:Renato.Oliveira|Renato.Oliveira]]
 [[Categoria:Infraestrutura]]

← Edição anterior		Edição das 15h21min de 10 de janeiro de 2020
Linha 220:		Linha 220:

	'''AUTOR:''' [[Usuário:Renato.Oliveira\|Renato.Oliveira]]		'''AUTOR:''' [[Usuário:Renato.Oliveira\|Renato.Oliveira]]
		+	[[Categoria:Infraestrutura]]

@@ Linha 33: / Linha 33: @@
 key: ${CI_COMMIT_REF_SLUG}
 paths:
-- cfg/tmp
+ - cfg/tmp
 </pre>
@@ Linha 88: / Linha 88: @@
 interface {{ interface.name }}
 {% if interface.description is defined %}
-description {{ interface.description}}
+ description {{ interface.description}}
 {% endif %}
 {% if (interface.address is defined ) and (interface.mask is defined ) %}
-ip address {{ interface.address }} {{ interface.mask }}
+ ip address {{ interface.address }} {{ interface.mask }}
 {% endif %}
 {% if interface.enabled == True %}
-no shutdown
+ no shutdown
 {% endif %}
 {% if interface.enabled == False %}
-shutdown
+ shutdown
 {% endif %}
 exit
@@ Linha 107: / Linha 107: @@
 <pre>
 - name: Cisco
-hosts: cisco
+  hosts: cisco
-roles:
+  roles:
-- cisco
+   - cisco
 - name: MikroTik
-hosts: routeros
+  hosts: routeros
-roles:
+  roles:
-- routeros
+   - routeros
 </pre>
 A relação de hosts para cada grupo é definida dentro do arquivo hosts, que tem a seguinte sintaxe:
@@ Linha 146: / Linha 146: @@
 <pre>
 - name: List interface directory
-find:
+  find:
-paths: roles/models/files/interfaces
+    paths: roles/models/files/interfaces
-patterns: "*{{ inventory_hostname }}.yml"
+    patterns: "*{{ inventory_hostname }}.yml"
-recurse: yes
+    recurse: yes
-file_type: file
+    file_type: file
-register: Files
+  register: Files
-delegate_to: localhost
+  delegate_to: localhost
 </pre>
 Perceba que a tarefa acima pesquisa na pasta /roles/models/files/interfaces todos os arquivos com o seguinte padrão ''"*<nowiki>{{ inventory_hostname }}</nowiki>.yml"'', note a sintaxe ''<nowiki>{{ inventory_hostname }}</nowiki>'', vista anteriormente nos templates em jinja2, que  faz referência ao equipamento que está sendo processado, registra o resultado de sua busca na variável Files e por fim executa esse procedimento localmente, sem a necessidade de se conectar via ssh no host.
@@ Linha 159: / Linha 159: @@
 <pre>
 - name: Include interface vars
-include_vars:
+  include_vars:
-file: roles/models/files/interfaces/{{ inventory_hostname }}.yml
+    file: roles/models/files/interfaces/{{ inventory_hostname }}.yml
-when: Files.files != []
+  when: Files.files != []
-delegate_to: localhost
+  delegate_to: localhost
 </pre>
 Com o modelo importado o próximo passo é a criação dos arquivos de configuração, nesta etapa é fundamental que na sua estrutura de diretórios já exista uma pasta destinada a estes arquivos, e para a sua configuração basta seguir o modelo abaixo:
 <pre>
 - name: Make Config
-template:
+  template:
-src: interface.j2
+    src: interface.j2
-dest: cfg/interfaces/{{ inventory_hostname }}.cfg
+    dest: cfg/interfaces/{{ inventory_hostname }}.cfg
-mode: 0777
+    mode: 0777
-when: Files.files != []
+  when: Files.files != []
-delegate_to: localhost
+  delegate_to: localhost
 </pre>
 Finalmente com todos os arquivos de configuração prontos, está na hora de aplicar as configurações nos equipamentos que no caso do ios é feito utilizando o módulo ios_config, conforme sintaxe abaixo:
 <pre>
 - name: Configure
-ios_config:
+  ios_config:
-src:  “cfg/interfaces/{{ inventory_hostname }}.cfg”
+    src:  “cfg/interfaces/{{ inventory_hostname }}.cfg”
-when: configFiles.files != []
+  when: configFiles.files != []
 </pre>
 Finalizadas estas configurações basta repetir o processo para cada funcionalidade que se deseja implementar em sua automação, e caso seja de interesse é possível simplificar ainda mais a criação dos playbooks, realizando a separação da configuração das tarefas por escopos, ou seja dentro da pasta roles/<role>/tasks existirá um arquivo main.yml que é responsável por importar as tarefas de cada uma das funcionalidades e cada funcionalidade terá um arquivo próprio como por exemplor interfaces.yml, ospf.yml , mpls.yml e etc, desta forma as configurações apresentadas acima residirão dentro de cada um dos playbooks de funcionalidades e o playbook main.yml irá apenas instanciar usando a seguinte sintaxe:
 <pre>
 - import_tasks: interfaces.yml
-vars:
+  vars:
-scope: interfaces
+    scope: interfaces
 </pre>
 Observe no código acima que foi introduzido uma variável durante a inclusão, e ao observar as configurações realizadas anteriormente é possível perceber que em nenhum momento foi utilizado alguma especificidade de alguma funcionalidade, portanto com é possível apenas com a alteração da variável scope, recém introduzida, replicar todo o código que criamos sem a necessidade de escreve-lo novamente.

← Edição anterior		Edição das 00h18min de 10 de janeiro de 2020
Linha 99:		Linha 99:

	[9] (https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html)		[9] (https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html)
		+
		+	[10] (https://github.com/renatoalmeidaoliveira/TutorialAnsible)

	'''AUTOR:''' [[Usuário:Renato.Oliveira]]		'''AUTOR:''' [[Usuário:Renato.Oliveira]]

@@ Linha 82: / Linha 82: @@
 === Referências ===
-[1]     (<nowiki>https://docs.gitlab.com/runner/register/</nowiki>)
+[1]     (https://docs.gitlab.com/runner/register<nowiki/>/)
-[2]     (<nowiki>https://docs.gitlab.com/ee/ci/quick_start/README.html#creating-a-gitlab-ciyml-file</nowiki>)
+[2]     (https://docs.gitlab.com/ee/ci/quick_start/README.html#creating-a-gitlab-ciyml-file)
-[3]     (<nowiki>https://docs.gitlab.com/ee/ci/yaml/</nowiki>)
+[3]     (https://docs.gitlab.com/ee/ci/yaml/)
-[4]     (<nowiki>https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html</nowiki>)
+[4]     (https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html)
-[5]     (<nowiki>https://galaxy.ansible.com/</nowiki>)
+[5]     (https://galaxy.ansible.com/)
-[6]     (<nowiki>https://docs.ansible.com/ansible/latest/modules/routeros_command_module.html#routeros-command-module</nowiki>)
+[6]     (https://docs.ansible.com/ansible/latest/modules/routeros_command_module.html#routeros-command-module)
-[7]     (<nowiki>https://docs.ansible.com/ansible/latest/modules/ios_config_module.html#ios-config-module</nowiki>)
+[7]     (https://docs.ansible.com/ansible/latest/modules/ios_config_module.html#ios-config-module)
-[8]     (<nowiki>https://docs.ansible.com/ansible/latest/user_guide/vault.html</nowiki>)
+[8]     (https://docs.ansible.com/ansible/latest/user_guide/vault.html)
-[9]     (<nowiki>https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html</nowiki>)
+[9]     (https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html)
 '''AUTOR:''' [[Usuário:Renato.Oliveira]]

@@ Linha 1: / Linha 1: @@
-=== '''Introdução''' ===
+=== Introdução ===
 Neste artigo será apresentado uma metodologia de automação de redes baseada em GitLab e Ansible, onde, utilizando templates em Jinja2, será possível entregar ao operador uma estrutura de configurações baseada em modelos de dados. As peculiaridades de cada fabricante estarão encapsuladas através de templates que podem abstrair desde a CLI específica o equipamento até modelos YANG. Este artigo será divido em 5 seções, sendo elas:
 * A instalação do ambiente que para simplificação será monolítica, com o Ansible e o GitLab instalado no mesmo servidor;
@@ Linha 11: / Linha 11: @@
 * Integrando a solução e realização de testes.
-=== '''Instalação''' ===
+=== Instalação ===
 O ambiente que será demostrado neste artigo utiliza como sistema operacional o CentOS 7 <!-- Atenção o CentoOS 7 é a versão mais recente suportada pelo GitLab -->, instalado a partir da imagem: CentOS-7-x86_64-DVD-1908, que pode ser encontrada no repositório da distribuição. Neste ambiente, todos os componentes foram instalados em conjunto, porém, para um ambiente de produção, pode ser recomendado separar os componentes GitLab-Runner e Ansible em outro servidor.
@@ Linha 18: / Linha 18: @@
              Finalizado o processo de instalação das ferramentas, execute o procedimento de registro do gitlab-runner conforme esta url da referência [1] .
-=== '''GitLab''' ===
+=== GitLab ===
 O GitLab é um gerenciador de repositório de software baseado em git com suporte à Wiki, gerenciamento de tarefas e CI/CD. GitLab é similar ao GitHub, mas o GitLab permite que os desenvolvedores armazenem o código em seus próprios servidores, ao invés de servidores de terceiros. Ele é um software livre, distribuído pela Licença MIT. (wikipedia)
              E com todas essas funcionalidades pode agregar valor à operação, sendo capaz de prover uma base de conhecimento com sua wiki e, através do gitlab-runner, é possível criar um ciclo onde o técnico escreve a configuração desejada e faz um commit no repositório, que automaticamente executa as tarefas de compilação e validação de sintaxe, podendo inclusive realizar o deploy das configurações em um ambiente de laboratório como o EVE-NG.
-=== '''Configurando a pipeline''' ===
+=== Configurando a pipeline ===
 Uma vez que o gitlab-runner foi instalado e configurado, é necessário adicionar no repositório o arquivo .gitlab-ci.yml que irá descrever todo o fluxo da pipeline [2].
@@ Linha 31: / Linha 31: @@
 [[Arquivo:Ciclo de execução.png|centro|miniaturadaimagem|800x800px|Figura 1. Ciclo de execução]]
-=== '''Ansible''' ===
+=== Ansible ===
 O Ansible é uma ferramenta open-source para gerenciamento de configuração e provisionamento, que utiliza uma comunicação com os nós baseadas em SSH sem a necessidade da instalação de agentes.
@@ Linha 46: / Linha 46: @@
 [[Arquivo:Renato-MikrotikRoles.png|centro|miniaturadaimagem|800x800px|Figura 4. Implementação de um Role para RouterOS]]
-=== '''Criando templates com Jinja2''' ===
+=== Criando templates com Jinja2 ===
 Neste tutorial irei demonstrar a criação dos templates apenas para o IOS, mas para o RouterOS a implementação é análoga.
@@ Linha 55: / Linha 55: @@
              Para a criação do template é necessário conhecer algumas estruturas de controle que nos permitirão realizar testes, e executar laços dentro da execução. A primeira estrutura que será apresentada é o laço '''{% for iterador in variável %} ... {% endfor %}'''. Ao observar o modelo que criamos acima pode se perceber que ele forma uma lista de interfaces, e será carregado dentro do Ansible como uma variável de nome interfaces, então para montar o laço iremos utilizar:<blockquote>{% for interface in interfaces %}</blockquote><blockquote>{% endfor %}</blockquote>              Outra estrutura que será usada extensivamente é condicional IF que possui a seguinte estrutura: <blockquote>{% if confição %}</blockquote><blockquote>..</blockquote><blockquote>{% elif condição %}</blockquote><blockquote>...</blockquote><blockquote>{% else %}</blockquote><blockquote>...</blockquote><blockquote>{% endif %}</blockquote>             E para acessar as variáveis basta utilizar a seguinte sintaxe <nowiki>{{ nome da variável }}</nowiki>.  O próximo passo é escrever a configuração que se deseja aplicar tomando muito cuidado com espaços, e sem a necessidade de se utilizar end ao final, pois o módulo executa uma comparação textual com a configuração em produção antes de configurar, no final a configuração do template será semelhando a abaixo:<blockquote>{% for interface in interfaces %}</blockquote><blockquote>interface <nowiki>{{ interface.name }}</nowiki></blockquote><blockquote>{% if interface.description is defined %}</blockquote><blockquote>description <nowiki>{{ interface.description}}</nowiki></blockquote><blockquote>{% endif %}</blockquote><blockquote>{% if (interface.address is defined ) and (interface.mask is defined ) %}</blockquote><blockquote>ip address <nowiki>{{ interface.address }}</nowiki> <nowiki>{{ interface.mask }}</nowiki></blockquote><blockquote>{% endif %}</blockquote><blockquote>{% if interface.enabled == True %}</blockquote><blockquote>no shutdown</blockquote><blockquote>{% endif %}</blockquote><blockquote>{% if interface.enabled == False %}</blockquote><blockquote>shutdown</blockquote><blockquote>{% endif %}</blockquote><blockquote>exit</blockquote><blockquote>{% endfor %}</blockquote>
-=== '''Integrando a solução''' ===
+=== Integrando a solução ===
 Com os modelos prontos e todos os templates está na hora de criar os playbooks, que serão utilizados pelo Ansible para guiar a automação. O primeiro playbook a ser criado fica na raiz do diretório e será responsável por “chamar” os playbooks de cada role, o que é entregue automaticamente, bastando se incluir o role no playbook, para esse primeiro playbook que chamarei de principal, será necessário criar um “Play” para cada grupo de ativos e neste play será incluído a role desejada, conforme exemplo abaixo:<blockquote>- name: Cisco</blockquote><blockquote>hosts: cisco</blockquote><blockquote>roles:</blockquote><blockquote>  - cisco</blockquote><blockquote>- name: MikroTik</blockquote><blockquote>hosts: routeros</blockquote><blockquote>roles:</blockquote><blockquote>  - routeros</blockquote>A relação de hosts para cada grupo é definida dentro do arquivo hosts, que tem a seguinte sintaxe:<blockquote>[cisco]</blockquote><blockquote>CPE7 ansible_host=192.168.237.206</blockquote><blockquote>PE4 ansible_host=192.168.237.202</blockquote><blockquote>P2  ansible_host=192.168.237.203</blockquote><blockquote>P1  ansible_host=192.168.237.205</blockquote><blockquote>PE5 ansible_host=192.168.237.207</blockquote><blockquote>CPE6 ansible_host=192.168.237.204</blockquote><blockquote>[routeros]</blockquote><blockquote>P3  ansible_host=192.168.237.183</blockquote>              Neste arquivo os grupos são definidos dentro dos colchetes, [cisco] e [routeros], enquanto os membros do grupo são definidos individualmente abaixo com a seguinte sintaxe: HOSTNAME  ansible_host=<endereço IP>.
@@ Linha 74: / Linha 74: @@
              Finalizado as configurações dos outros roles, para executar a automação basta executar o comando ansible-playbook <playbook).yaml na pasta raiz do projeto, comando este que deve ser inserido no .gitlab-ci.yml para que o gitlab execute a configuração sempre que o usuário realizar um commit.
-=== '''Conclusão''' ===
+=== Conclusão ===
              Neste tutorial foi apresentado uma metodologia de automação de redes baseada na integração de ferramentas open source, Ansible e gitlab. Onde através da utilização da abstração de modelos de dados e roles, é possível entregar ao administrador de redes uma interface de configuração agnóstica a fabricantes e com um mecanismo de aprovação característico de metodologias de desenvolvimento de software, com commits e processos de aprovação.
@@ Linha 81: / Linha 81: @@
 Muito obrigado pela atenção, espero que tenham gostado do conteúdo, e assim que possível estarei disponibilizando um vídeo no YouTube demonstrando e dando maiores explicações sobre a metodologia
-=== '''REFERÊNCIAS''' ===
+=== REFERÊNCIAS ===
 [1]     (<nowiki>https://docs.gitlab.com/runner/register/</nowiki>)