[DOCKER] Network device config management automation verification with oxidized and gitlab

Introduction

<!-Description the beginning and outline-> A personal memo of verification that automates the configuration management of network devices with oxidized and gitlab. It may be useful in the field where many network devices are operated.

In this verification, we will launch vSRX with Vagrant and oxidized and gitlab with docker. The purpose is to automatically get the vSRX config by oxidized and save it in gitlab.

It would be nice if the wasteful work of manually acquiring the config after changing the settings, moving the file to the in-house NW via USB, storing it in a shared folder, and managing the configuration is reduced as much as possible.

If the latest config is not properly managed, it will be difficult to replace the device due to a failure, so it will be automated properly.

environment

table of contents

<!-Edit title and anchor name->

  1. [Docker preparation](#docker preparation)
  2. [Preparing for vSRX](Preparing for #vSRX)
  3. [Prepare for gitlab](Prepare for #gitlab)
  4. [Preparing for oxidized](Preparing for #oxidized)
  5. Run

<!-Each chapter->

docker ready

Get ready around docker

docker installation

Install docker and docker-compose by referring to this article

Below my environment

# docker -v
Docker version 19.03.13, build 4484c46d9d
$ docker-compose -v
docker-compose version 1.27.4, build 40524192

Raise the memory limit that docker can use

Mac version docker can only use up to 2GB of memory by default, so please refer to this article. Increase it to the feeling. Memory 4G / swap 1G? Consult with machine specs.

If you don't do this, you'll be struck by a 502 error in gitlab for the rest of your life. Note that gitlab uses a lot of memory!

vSRX preparation

This time, we will use Vagrant + vSRX to simulate network equipment.

Install vagrant and virtual box

Install vagrant and virtual box by referring to this article

Below my environment

$ vagrant -v
Vagrant 2.2.10

Install vagrant plugin

Do I need a plugin to run vSRX?

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

Below my environment

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

vSRX launch

Launch the ancient vSRX on vagrant. Use vSRX in packet mode (router). If you make a mistake and use vSRX in flow mode (FireWall), it will be duplicated (DUP) for the rest of your life by pinging and you will be crazy.

#Directory creation
$ mkdir vSRX

#Move to directory
$ cd vSRX

#Create a vSRX Vagrantfile
$ vagrant init juniper/ffp-12.1X47-D15.4-packetmode

#Set the IP of vSRX appropriately. This time 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

#Start vSRX Wait patiently It takes a long time
$ vagrant up

#Status check OK if running
$ 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`.

vSRX user created

Create a user for oxidized for later use. Work in the same directory as the previous item. You will use the user and password later.

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

#Shift to vSRX cli mode
root@vsrx% cli
root@vsrx> 

#Move to vSRX configure mode
root@vsrx> configure
root@vsrx#

#Added oxidized user
root@vsrx# set system login user oxidized class super-user
root@vsrx# set system login user oxidized authentication plain-text-password
New password:[Enter your favorite password]
Retype new password:[Put it in again and enter]

#Commit settings
root@vsrx# commit

#Exit vSRX by doing exit several times
# ssh [email protected] is also a confirmation that you can ssh with 10 or something
#WARNING at ssh: REMOTE HOST IDENTIFICATION HAS CHANGED!Know when it comes out_192 from hosts.168.33.Try to erase 10

gitlab preparation

I will set up gitlab with docker.

Create docker-compose.yml

Create a docker-compose file for gitlab.

#Directory creation
$ mkdir gitlab

#Move to directory
$ cd gitlab

# docker-compose.yaml file creation
$ touch docker-compose.yaml

Edit docker-compose.yaml below.

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'

run gitlab

Execute with docker-compose up

$ docker-compose up -d

docker-compose up itself is fast, Wait patiently until you can see it on the Prouser. It takes a lot of time. Until the launch is complete, you will be saddened by an error such as woops! Or 502. let's wait.

gitlab access

Browser access to http : // localhost: 10080

fig1.png

Follow the on-screen instructions to initialize the root password.

gitlab oxidized user created

Create a user for oxidized.

Browser access to http : // localhost: 10080

fig2.png

Create an oxidized user and proceed as shown on the screen.

gitlab repository creation

Create a private repository for use with oxidized. This time with the following name. Project name: config-auto-collector

fig3.png

The repository creation is complete.

fig4.png

Prepared to be oxidized

Prepare around oxidized

Create docker-compose.yml

Create an oxidized docker-compose file.

#Directory creation
$ mkdir oxidized

# oxidized/Move to
$ cd oxidized

# docker-compose.yaml file creation
$ touch docker-compose.yaml

Edit docker-compose.yaml below. I slept for 2 days without knowing the existence of ʻextra_hosts` Convenient because hosts are automatically set in the docker container

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

oxidized config

We will set the oxidized config.

#Create Moiko directory
$ mkdir oxidized

# oxidized/oxidized/Move to
$ cd oxidized

#Create config file
$ touch config

Edit the config below. I feel that there are unnecessary settings, but I believe and copy and paste. Please enter some IPs and passwords for your environment. Since the acquisition interval (interval) is 10 seconds, tuning is required when putting it in the production environment. (Half day, maybe every day)

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: [Email address specified when creating oxidized red with gitlab]
      single_repo: true
      repo: "/root/.config/oxidized/config-auto-collector"
hooks:
  push_to_remote:
    type: githubrepo
    events: [post_store]
    remote_repo: "http://[Real IP of localhost]:10080/oxidized/config-auto-collector.git"
    username: oxidized
    password: [gitlab password]
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

oxidized settings (router.db)

We will set router.db of oxidized. It's like setting the network device to be acquired by oxidized.


# oxidized/oxidized/Work under subordinates
# router.db file creation
$ touch router.db

Edit router.db below.

oxidized/coxidized/router.db


vSRX:juniper:oxidized:[vSRX oxidized user password]

Repository preparation

Let's clone the repository you created. Be sure to access with the real IP without using localhost etc. This repository is a file shared with the docker container, so If you set it to localhost, you will not be able to easily access it from the docker container side. (maybe)

# oxidized/oxidized/Work under subordinates
$ git clone http://oxidized@[Real IP of localhost]:10080/oxidized/config-auto-collector.git

Run

Finally oxidized execution. Execute it with gitlab and vSRX running.

oxidized start

# oxidized/Work under subordinates
$ docker-compose up -d

If all goes well, the vSRX config will be automatically added to the repository. Of course, if you change the vSRX config, it will be automatically pushed to the repository. I'm happy.

fig5.png

After that, let's deploy it in the production environment by fine tuning and host registration.

Tips

When vagrant freezes

Let's kill the pid that comes out with ps -ef | grep VBox. Impression that vSRX hardens well

Enter docker container

I googled about 20,000 times saying "Enter docker". Let's remember

$ docker-compose exec [container name] bash

TODO --I want to do something about the file name becoming the host name --I want to manage that the execution command is not displayed in the output config file. --I want to extend the acquired information with my own model (show int terse, etc.) --Try in a real environment ――I wonder if there is a good way to handle hosts ... When the number of target hosts increases, it is difficult to handle.

Impressions

--Deoxidized is painful with few documents ――If you can go to the Internet, you don't have to set up gitlab locally. ――Once deployed, it seems that you can operate it easily --Since the UI of cvs is not good, I tried using gitlab, but I feel that cvs is easier to see if it is just generation management of config files. ――I feel like I have extra features of gitlab. I wonder if I can do something interesting --It may be better not to use a virtual environment because it uses too much gitlab resources ――Since git is not familiar to network operation members in the first place, it may be better not to use it so much ――Even if you create a user with vSRX and plain-text-password, the config is encrypted. Why? Is that something like that?

end

Recommended Posts

Network device config management automation verification with oxidized and gitlab
Communicate Gitlab and Gitlab Runner launched with Docker