[DOCKER] Vérification de l'automatisation de la gestion de la configuration des équipements réseau avec oxydé et git lab

introduction

<! - Description du début et du plan-> Un mémo personnel de vérification qui automatise la gestion de la configuration des périphériques réseau avec oxydé et git lab. Cela peut être utile sur le terrain où de nombreux périphériques réseau sont utilisés.

Dans cette vérification, nous allons lancer vSRX avec Vagrant et oxydé et gitlab avec docker. Le but est d'acquérir automatiquement la configuration vSRX par oxydé et de la sauvegarder dans gitlab.

Ce serait bien si le travail inutile d'acquisition manuelle de la configuration après avoir modifié les paramètres, le déplacement du fichier vers le NW interne via USB, le stockage dans un dossier partagé et la gestion de la configuration serait réduit autant que possible.

Si la dernière configuration n'est pas correctement gérée, il sera difficile de remplacer le périphérique en raison d'une panne, il sera donc correctement automatisé.

environnement

• mac OS Catalina 10.15.7
• docker 19.03.13
• docker-compose 1.27.4
• vagrant 2.2.10

table des matières

<! - Modifier le titre et le nom de l'ancre->

1. [Préparation Docker](#docker préparation)
2. [Préparation pour vSRX](Préparation pour #vSRX)
3. [Préparez-vous pour gitlab](Préparez-vous pour #gitlab)
4. [Préparation pour oxydé](Préparation pour #oxydé)
5. Exécuter

<! - Chaque chapitre->

docker prêt

Préparez-vous autour du docker

installation de docker

Installez docker et docker-compose en vous reportant à cet article

Sous mon environnement

# docker -v
Docker version 19.03.13, build 4484c46d9d

$ docker-compose -v
docker-compose version 1.27.4, build 40524192

Augmenter la limite de mémoire disponible pour le docker

La version Mac de docker ne peut utiliser que 2 Go de mémoire par défaut, alors référez-vous à cet article. Augmentez la sensation. Mémoire 4G / Swap 1G? Consultez les spécifications de la machine.

Si vous ne le faites pas, vous serez frappé par une erreur 502 dans gitlab pour le reste de votre vie. Notez que gitlab utilise beaucoup de mémoire!

Préparation vSRX

Cette fois, nous utiliserons Vagrant + vSRX pour simuler des équipements réseau.

Installer une boîte vagabonde et virtuelle

Installez vagrant et Virtual Box en vous référant à cet article

Sous mon environnement

$ vagrant -v
Vagrant 2.2.10

Installer le plugin vagrant

Ai-je besoin d'un plug-in pour exécuter vSRX?

$ vagrant plugin install vagrant-host-shell
$ vagrant plugin install vagrant-junos

Sous mon environnement

$ vagrant plugin list
vagrant-host-shell (0.0.4, global)
vagrant-junos (0.2.1, global)

Lancement de vSRX

Lancez l'ancien vSRX sur vagrant. Utilisez vSRX en mode paquet (routeur). Si vous faites une erreur et utilisez vSRX en mode flux (FireWall), il sera dupliqué (DUP) pour le reste de votre vie par ping et vous serez fou.

#Créer le répertoire
$ mkdir vSRX

#Déplacer vers le répertoire
$ cd vSRX

#Créer un vSRX Vagrantfile
$ vagrant init juniper/ffp-12.1X47-D15.4-packetmode

#Définissez l'adresse IP vSRX de manière appropriée. Cette fois 192.168.33.10
$ sed -i '' -e 's/# config.vm.network "private_network", ip: "192.168.33.10"/config.vm.network "private_network", ip: "192.168.33.10"/' Vagrantfile

#Démarrez vSRX Attendez patiemment Cela prend un certain temps
$ vagrant up

#Vérification de l'état OK si en cours d'exécution
$ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

Création d'utilisateurs vSRX

Créez un utilisateur pour oxydé pour une utilisation ultérieure. Travaillez dans le même répertoire que l'élément précédent. Vous utiliserez l'utilisateur et le mot de passe plus tard.

#connexion ssh à vSRX
$ vagrant ssh
--- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
root@vsrx%

#Passer en mode cli vSRX
root@vsrx% cli
root@vsrx> 

#Passer en mode de configuration vSRX
root@vsrx> configure
root@vsrx#

#Ajout d'un utilisateur oxydé
root@vsrx# set system login user oxidized class super-user
root@vsrx# set system login user oxidized authentication plain-text-password
New password:[Entrez votre mot de passe préféré]
Retype new password:[Remettez-le et entrez]

#Paramètres de validation
root@vsrx# commit

#Quittez vSRX en effectuant exit plusieurs fois
# ssh [email protected] y a aussi une confirmation que vous pouvez ssh avec 10
#Pendant ssh, AVERTISSEMENT: REMOTE HOST IDENTIFICATION HAS CHANGED!Sachez quand ça sort_192 des hôtes.168.33.Essayez d'effacer 10

préparation gitlab

Je vais mettre en place un git lab avec docker.

Créer docker-compose.yml

Créez un fichier docker-compose pour gitlab.

#Créer le répertoire
$ mkdir gitlab

#Déplacer vers le répertoire
$ cd gitlab

# docker-compose.création de fichier yaml
$ touch docker-compose.yaml

Modifiez docker-compose.yaml ci-dessous.

gitlab/docker-compose.yaml

version: '3.8'
services:
  gitLab:
    image: gitlab/gitlab-ce:latest
    ports:
     - "10080:80"
    volumes:
     - './config:/etc/gitlab'
     - './logs:/var/log/gitlab'
     - './data:/var/opt/gitlab'

gitlab run

Exécuter avec docker-compose up

$ docker-compose up -d

docker-compose up lui-même est rapide, Attendez patiemment jusqu'à ce que vous puissiez le voir sur le Prouser. Ça prend beaucoup de temps. Jusqu'à ce que le lancement soit terminé, vous vous sentirez triste avec une erreur telle que woops! Ou 502. Attendons.

accès gitlab

Accès du navigateur à http : // localhost: 10080

Suivez les instructions à l'écran pour initialiser le mot de passe root.

Utilisateur gitlab oxydé créé

Créez un utilisateur pour oxydé.

Accès du navigateur à http : // localhost: 10080

Créez un utilisateur oxydé et procédez comme indiqué à l'écran.

Créer un référentiel gitlab

Créez un référentiel privé à utiliser avec oxidized. Cette fois avec le nom suivant. Project name: config-auto-collector

La création du référentiel est terminée.

Préparé pour être oxydé

Préparez-vous autour oxydé

Créer docker-compose.yml

Créez un fichier docker-compose oxydé.

#Créer le répertoire
$ mkdir oxidized

# oxidized/Déménager à
$ cd oxidized

# docker-compose.création de fichier yaml
$ touch docker-compose.yaml

Modifiez docker-compose.yaml ci-dessous. J'ai dormi 2 jours sans connaître l'existence de ʻextra_hosts` Pratique car les hôtes sont automatiquement définis dans le conteneur Docker

oxidized/docker-compose.yaml

oxidized:
  restart: always
  image: oxidized/oxidized:latest
  ports:
    - 8888:8888/tcp
  environment:
    CONFIG_RELOAD_INTERVAL: 600
  volumes:
    - ./oxidized:/root/.config/oxidized
  extra_hosts:
    - vSRX:192.168.33.10

config oxydé

Nous allons définir la configuration oxydée.

#Créer un répertoire Moiko
$ mkdir oxidized

# oxidized/oxidized/Déménager à
$ cd oxidized

#Créer un fichier de configuration
$ touch config

Modifiez la configuration ci-dessous. Je sens qu'il y a des paramètres inutiles, mais je crois et copie. Veuillez saisir des adresses IP et des mots de passe pour votre environnement. Étant donné que l'intervalle d'acquisition (intervalle) est de 10 secondes, un réglage est nécessaire lors de sa mise en environnement de production. (Une demi-journée, peut-être tous les jours)

oxidized/coxidized/config

---
username: oxidized
password: oxidized
model: junos
resolve_dns: true
interval: 10
use_syslog: false
log: "/root/.config/oxidized/logs/oxidized.log"
debug: false
threads: 30
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@-]+[#>]\s?)$/
rest: 127.0.0.1:8888
next_adds_job: false
vars: {}
groups: {}
models: {}
pid: "/root/.config/oxidized/pid"
crash:
  directory: "/root/.config/oxidized/crashes"
  hostnames: false
stats:
  history_size: 10
input:
  default: ssh, telnet
  debug: false
  ssh:
    secure: false
  ftp:
    passive: true
  utf8_encoded: true
output:
  default: git
  git:
      user: oxidized
      email: [Adresse e-mail spécifiée lors de la création de rouge oxydé avec gitlab]
      single_repo: true
      repo: "/root/.config/oxidized/config-auto-collector"
hooks:
  push_to_remote:
    type: githubrepo
    events: [post_store]
    remote_repo: "http://[IP réelle de l'hôte local]:10080/oxidized/config-auto-collector.git"
    username: oxidized
    password: [mot de passe gitlab]
source:
  default: csv
  csv:
    file: "/root/.config/oxidized/router.db"
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      model: 1
      username: 2
      password: 3
    vars_map:
      enable: 4
model_map:
  cisco: ios
  juniper: junos

paramètres oxydés (router.db)

Nous allons définir le router.db de oxydé. C'est comme configurer le périphérique réseau à acquérir par oxydé.

# oxidized/oxidized/Travailler sous des subordonnés
# router.création de fichier db
$ touch router.db

Modifiez router.db ci-dessous.

oxidized/coxidized/router.db

vSRX:juniper:oxidized:[Mot de passe utilisateur oxydé vSRX]

Préparation du référentiel

Clonons le référentiel que vous avez créé. Assurez-vous d'accéder avec la vraie adresse IP sans utiliser localhost, etc. Ce référentiel est un fichier partagé avec le conteneur Docker, donc Si vous le définissez sur localhost, vous ne pourrez pas y accéder facilement du côté du conteneur Docker. (peut être)

# oxidized/oxidized/Travailler sous des subordonnés
$ git clone http://oxidized@[IP réelle de l'hôte local]:10080/oxidized/config-auto-collector.git

Courir

Exécution enfin oxydée. Exécutez-le avec gitlab et vSRX en cours d'exécution.

début oxydé

# oxidized/Travailler sous des subordonnés
$ docker-compose up -d

Si tout se passe bien, la configuration vSRX sera automatiquement ajoutée au référentiel. Bien sûr, si vous modifiez la configuration de vSRX, il sera automatiquement poussé vers le référentiel. Je suis heureux.

Après cela, déployons-le dans l'environnement de production en réglant finement et en enregistrant l'hôte.

Tips

Quand le vagabond gèle

Supprimons le pid qui sort avec ps -ef | grep VBox. Impression que vSRX durcit bien

Entrez dans le conteneur Docker

J'ai googlé "Enter docker" environ 20 000 fois. Souvenons-nous

$ docker-compose exec [nom du conteneur] bash

TODO --Je veux faire quelque chose pour que le nom du fichier devienne le nom d'hôte --Je veux faire quelque chose pour que la commande d'exécution ne soit pas affichée dans le fichier de configuration de sortie. --Je veux étendre les informations acquises avec mon propre modèle (show int terse, etc.)

• Essayer dans un environnement réel ――Je me demande s'il existe un bon moyen de gérer les hôtes, mais lorsque le nombre d'hôtes cibles augmente, c'est difficile à gérer

Impressions

• La désoxydation est douloureuse avec peu de documents ――Si vous pouvez accéder à Internet, vous n'avez pas besoin de configurer gitlab localement. ――Une fois déployé, il semble facile à utiliser
• Comme l'interface utilisateur de cvs n'est pas bonne, j'ai essayé d'utiliser gitlab, mais je pense que cvs est plus facile à voir s'il ne s'agit que de gestion de génération de fichiers de configuration. ――Je sens que j'ai un surplus de fonctions gitlab. Je me demande si je peux faire quelque chose d'intéressant
• Il peut être préférable de ne pas utiliser d'environnement virtuel car il utilise trop de ressources gitlab. ―― Étant donné que git n'est pas familier aux membres des opérations réseau en premier lieu, il vaut peut-être mieux ne pas l'utiliser autant ――Même si vous créez un utilisateur avec vSRX et un mot de passe en texte brut, la configuration est chiffrée. Pourquoi? Est-ce quelque chose comme ça?

fin