Avant toute chose, on définit notre manière d'automatiser !
Le process
Notre but ultime est que dès qu'un client est signé dans notre CRM, il envoie une requête à une API et cette dernière va contacter toute notre infra pour produire sa configuration (CPE et/ou Backbone). En fonction du client, plusieurs workflow peuvent s’exécuter. Il faut donc que la personne qui renseigne les informations soient dans la certitude (on pourra changer après mais c'est pas le but).
Les outils
On va développer l'API "master". Pour notre CRM, j'ai décidé de le monter après.
Dans un opérateur, il y a plein d'outils indispensables. Je vais vous en lister quelques-unes et les solutions que j'ai choisies :
- Supervision : Centreon
- Repo : Gitlab
- IPAM : Netbox
- Radius : FreeRadius
- DNS : PowerDNS
- Automatisation : AWX / Golang / etc
- ZTP Mikrotik : Le mien 😄
- ZTP Fortigate : Fortimanager
La liste est non exhaustive mais grosso modo c'est ceux là que je vais utiliser dans mon infra.
On commence à tout installer !
Architecture
Tous mes services vont être placés derrière un reverse proxy (un Caddy) sur un VLAN spécifique. Je trouve que c'est une bonne idée. J'ai un seul point d'entrée et mon certificat wildcard est géré par Caddy au lieu d'avoir un cron (ou un autre moyen) qui vient renouveler le certificat à chaque fois qu'il expire.
Gitlab
La vie est quand même vachement plus simple avec du packer/opentofu nan ?
Allez, un petit tofu apply (vu dans l'épisode précédent) et hop ma VM debian 13 est montée !
Pour installer Gitlab :
naradmin@gitlab:~$ curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash
naradmin@gitlab:~$ sudo EXTERNAL_URL="https://gitlab.naruto.ninja" apt install gitlab-ce
C'est normal si vous avez des errreurs. Gitlab utilise let's encrypt pour le certificat donc s'il n'y a pas d'enregistrement DNS, cela va merder mais ça gène en rien l'installation. Ensuite, on ajoute (ou décommente) ces lignes dans /etc/gitlab/gitlab.rb :
nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
"Host" => "$http_host_with_default",
"X-Real-IP" => "$remote_addr",
"X-Forwarded-For" => "$proxy_add_x_forwarded_for",
"Upgrade" => "$http_upgrade",
"Connection" => "$connection_upgrade"
}
Et un petit coup de reconfigure ! (sudo gitlab-ctl reconfigure)
Après configuration du reverse proxy et du DNS interne, j'ai bien accès :
Vu que mon gitlab est derrière un reverse, je ne ferai pas de ssh pour git (clone/push/pull/etc) mais plutôt via HTTPS !
On peut commencer à créer notre premier projet :
On crée un token pour notre utilisateur et ensuite sur notre PC de production (où on va push notre code) :
cd api-master/
git init --initial-branch=main
git config --global credential.helper store
git remote add origin https://naradmin:TOKEN_BIEN_CACHE@gitlab.naruto.ninja/naradmin/api-master.git
git config --global user.name "Naradmin"
git config --global user.email "naradmin@naruto.ninja"
git add .
git commit -m "first commit"
git push -u origin main
On a bien push notre code :
Plutôt pas mal nan ?
Maintenant on va voir comment la VM où va s’exécuter notre code va faire pour pull le code fraîchement push et passé par des pipelines CI/CD (on verra ça après, chaque chose en son temps). Pour cela on va utiliser Gitlab Runner. On commence par créer une autre VM où le code s'exécutera. Pour installer ce paquet :
root@netops:~# curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash
root@netops:~# apt install gitlab-runner -y
Ensuite, dans Gitlab, on va dans les settings du projet puis CI/CD et Runner pour en créer un :
Il sort une URL comme ça :
gitlab-runner register --url https://gitlab.naruto.ninja --token TOKEN_BIEN_CACHE
C'est très bien car il faut taper cette commande sur la VM pour qu'elle puisse être runner !
Une fois renseigné, il faut créer un fichier .gitlab-ci.yml dans notre projet (là où on développe) :
root@devops:~/api-master# cat .gitlab-ci.yml
stages:
- deploy
deploy-code:
stage: deploy
tags:
- go-build
script:
- rsync -av --delete ./ /opt/api-master/
C'est un fichier plus que basique ! Le but étant juste de déployer le code sur la VM quand un utilisateur a push une nouvelle fonctionnalité (je fais un rsync pour le mettre dans un dossier à part le /opt/api-master).
Allez on teste ? Un petit git push sur mon PC et on regarde l'état du job :
Et sur ma VM de prod ?
root@netops:/opt/api-master# ls -a
. .. .git .gitlab-ci.yml main.go test.go
Top, ça fonctionne ! On développera par la suite ce fichier (compilation du go, reload du service et ajout de test ...). On fera un runner par projet, en effet, la VM finale serait différente en fonction des services (API freeradius sur le freeradius, API ZTP Mikrotik, etc).
Bon notre repo à l'air opérationnel, passons à l'installation de notre radius !
Freeradius
On installe les paquets suivants :
naradmin@freeradius:~$ sudo apt install freeradius freeradius-postgresql -y
Ensuite, on crée la table radius et on attribue des droits à l'utilisateur qu'on a crée :
naradmin@freeradius:~$ sudo -u postgres psql
CREATE DATABASE radius;
CREATE USER radius_user WITH PASSWORD 'password';
GRANT ALL PRIVILEGES ON DATABASE radius TO radius_user;
GRANT ALL ON SCHEMA public TO radius_user;
GRANT ALL ON DATABASE radius TO radius_user;
ALTER SCHEMA public OWNER TO radius_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO radius_user;
(Changez bien le nom d'utilisateur et le password). On modifie le fichier pg_hba.conf en remplaçant la ligne "local all all peer" par "local all all md5" et on restart postgresql.
naradmin@freeradius:~$ sudo nano /etc/postgresql/17/main/pg_hba.conf
.
.
.
.
local all all md5
On peut enfin importer le schéma de la BDD :
root@freeradius:~$ psql -U user -d radius -f /etc/freeradius/3.0/mods-config/sql/main/postgresql/schema.sql
Dans le fichier /etc/freeradius/3.0/mods-config/sql/main/postgresql, on ajoute ces lignes
dialect = "postgresql"
driver = "rlm_sql_${dialect}"
server = "localhost"
port = 5432
login = "radius_user"
password = "password"
radius_db = "radius"
On fait un lien symbolique entre mods-available/sql et mods-enabled :
root@freeradius:~$ ln -s /etc/freeradius/3.0/mods-available/sql /etc/freeradius/3.0/mods-enabled/
C'est bientôt fini ! Dans les fichiers /etc/freeradius/3.0/sites-available/inner-tunnel et /etc/freeradius/3.0/sites-available/default, il faut décommenter toute ligne avec sql. Et on restart le service freeradius.
On peut enfin tester ! Créons un utilisateur dans la table radcheck :
INSERT INTO radcheck (username, attribute, op, value) VALUES ('user', 'Cleartext-Password', ':=', 'password');
radius=# select * from radcheck;
id | username | attribute | op | value
----+----------+--------------------+----+--------------
1 | user | Cleartext-Password | := | password
Testons en simulant un access-request : radtest user password 127.0.0.1 0 testing123
root@freeradius:~# radtest user password 127.0.0.1 0 testing123
Sent Access-Request Id 54 from 0.0.0.0:45953 to 127.0.0.1:1812 length 74
User-Name = "user"
User-Password = "password"
NAS-IP-Address = 127.0.1.1
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "password"
Received Access-Accept Id 54 from 127.0.0.1:1812 to 127.0.0.1:45953 length 38
Message-Authenticator = 0x0b8abc3eddcc7d1c927b7ecce63798b9
On obtient bien un access-accept à notre request ! Notre freeradius peut donc commencer à être opérationnel ! Je ne sais pas si vous vous en souvenez mais on utilisait déjà un radius pour nos clients PPP. La grande différence entre les deux c'est que celui là, les clients sont dans la BDD au lieu d'être dans le fichier user. C'est méga plus simple à automatiser !
Netbox
Pour que notre opérateur fonctionne, il faut une source de vérité. Chaque IP, chaque VLAN doivent être renseignés quelque part pour éviter des doublons. J'ai donc opté pour Netbox. Allez on l'installe la BDD (encore une fois postgresql) :
naradmin@netbox:~$ sudo apt install -y postgresql
naradmin@netbox:~$ sudo -u postgres psql
CREATE DATABASE netbox;
CREATE USER netbox_user WITH PASSWORD 'password';
ALTER DATABASE netbox OWNER TO netbox_user;
\c netbox;
GRANT CREATE ON SCHEMA public TO netbox_user;
Ensuite, on installe redis, paquets python (Netbox étant développé sur un django, un framework python) et netbox via un wget sur le repo github (à ce jour, la version 4.4.9 est la plus récente)
naradmin@netbox:~$ sudo apt install -y redis-server python3 python3-pip python3-venv python3-dev build-essential libxml2-dev libxslt1-dev libffi-dev libpq-dev libssl-dev zlib1g-dev
naradmin@netbox:~$ sudo wget https://github.com/netbox-community/netbox/archive/refs/tags/v4.4.9.tar.gz
naradmin@netbox:~$ sudo tar -xzf v4.4.9.tar.gz -C /opt/
On crée un lien symbolique entre ce repertoire et /opt/netbox (pour éviter de recréer toute la configuration si upgrade) et on change l'utilisateur de certains répertoires :
naradmin@netbox:/opt$ sudo ln -s /opt/netbox-4.4.9/ /opt/netbox
sudo adduser --system --group netbox
sudo chown --recursive netbox /opt/netbox/netbox/reports/
sudo chown --recursive netbox /opt/netbox/netbox/scripts/
Dans le fichier /opt/netbox/netbox/netbox/configuration.py, on doit renseigner quelques informations (Allowed_hosts, j'ai mis * pour pas me faire chier mais faudrait que je change ça, Configuration de la database avec les logins et une secret key). Ensuite, il faut utiliser le script /opt/netbox/upgrade.sh et crée un utilisateur avec le script /opt/netbox/netbox/manage.py createsuperuser :
cd /opt/netbox/netbox/netbox/
sudo cp configuration_example.py configuration.py
renseigner ALLOWED_HOSTS, conf bdd et SECRET_KEY
sudo /opt/netbox/upgrade.sh
source /opt/netbox/venv/bin/activate
cd /opt/netbox/netbox
python3 manage.py createsuperuser
Username: naradmin
Email address:
Password:
Password (again):
Superuser created successfully.
C'est bientôt fini ! On copie le fichier par défaut de gunicorn, on crée le démon netbox sur notre debian et on enable ce service :
naradmin@netbox:/opt/netbox$ sudo cp /opt/netbox/contrib/gunicorn.py /opt/netbox/gunicorn.py
naradmin@netbox:/opt/netbox$ sudo cp -v /opt/netbox/contrib/*.service /etc/systemd/system/
naradmin@netbox:/opt/netbox$ sudo systemctl daemon-reload
naradmin@netbox:/opt/netbox$ sudo systemctl enable --now netbox netbox
Notre service écoute maintenant sur 127.0.0.1:8001. Il faut donc utiliser un serveur web pour rediriger le trafic web sur ce port là. Pour ce faire, j'utilise nginx. Attention, vu qu'il est derrière mon caddy, je fais écouter nginx uniquement sur le port 80. Ma redirection sur mon reverse se fait de HTTPS vers HTTP :
naradmin@netbox:/opt/netbox$ sudo apt install -y nginx
naradmin@netbox:/opt/netbox$ sudo cp /opt/netbox/contrib/nginx.conf /etc/nginx/sites-available/netbox
naradmin@netbox:/opt/netbox$ sudo rm /etc/nginx/sites-enabled/default
naradmin@netbox:/opt/netbox$ sudo ln -s /etc/nginx/sites-available/netbox /etc/nginx/sites-enabled/netbox
La configuration de mon fichire nginx est (merci chatgpt) :
naradmin@netbox:~$ cat /etc/nginx/sites-available/netbox
server {
listen 80;
server_name netbox.domain.name;
client_max_body_size 25m;
location /static/ {
alias /opt/netbox/netbox/static/;
}
location / {
proxy_pass http://127.0.0.1:8001;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
}
J'ai bien accès en web via le nom de domaine :
Perfect ! Allez on installe notre supervision maintenant.
Centreon
Central
J'utilise centreon avec un central (l'interface web et la bdd) et des pollers (ceux qui effectuent les requêtes snmp). Je vais utiliser mariadb comme bdd (on a le choix avec mysql). Tout d'abord on installe les paquets nécessaires :
root@centreon-central:~# apt update && apt install lsb-release ca-certificates apt-transport-https software-properties-common wget gnupg2 curl -y
root@centreon-central:~# curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --os-type=debian --os-version=12 --mariadb-server-version="mariadb-10.11"
On mets les dépôts centreon dans la VM et on importe la clé GPG :
root@centreon-central:~# echo "deb https://packages.centreon.com/apt-standard/ $(lsb_release -sc)-25.10-stable main" | tee -a /etc/apt/sources.list.d/centreon-25.10-stable.list
root@centreon-central:~# echo "deb https://packages.centreon.com/apt-plugins-stable/ $(lsb_release -sc) main" | tee /etc/apt/sources.list.d/centreon-plugins.list
root@centreon-central:~# wget -O- https://apt-key.centreon.com | gpg --dearmor | tee /etc/apt/trusted.gpg.d/centreon.gpg > /dev/null 2>&1
On peut installer centreon via paquets :
root@centreon-central:~# apt update && apt install -y centreon-mariadb centreon
On restart les daemon et on enable des services (pour qu'ils soient up si le serveur redémarre). On en profite aussi pour nommer le serveur :
root@centreon-central:~# systemctl daemon-reload
root@centreon-central:~# systemctl restart mariadb
root@centreon-central:~# hostnamectl set-hostname centreon-central
root@centreon-central:~# systemctl enable php8.2-fpm apache2 centreon cbd centengine gorgoned centreontrapd snmpd snmptrapd mariadb
root@centreon-central:~# systemctl restart mariadb
Pour finir l'installation en CLI, il faut sécuriser notre BDD et lancer apache
root@centreon-central:~# mariadb-secure-installation
(repondre à oui sauf disable login root remotly)
root@centreon-central:~# systemctl start apache2
Maintenant en web. On attaque le serveur en http :
Next jusqu'à l'étape 5. Sur cette étape, il faut renseigner l'utilisateur admin :
A l'étape 6, il faut renseigner les informations de la database (le root password, c'est celui qu'on a indiqué avec la commande mariadb-secure-installation. L'utilisateur centreon sera crée au moment où on appuiera sur le bouton next.
Ensuite next. Une fois connecté sur centreon, on doit d'abord reload le central :
Puis on restart des paquets :
root@centreon-central:~# systemctl restart cbd centengine gorgoned
root@centreon-central:~# systemctl start snmptrapd centreontrapd
root@centreon-central:~# systemctl start snmpd
Le central est bien up !
Poller
La configuration du poller est un peu plus simple ! Tout d'abord, on le nomme bien et on installe les paquets nécessaires :
root@centreon-poller1:~# hostnamectl set-hostname centreon-poller1
root@centreon-poller1:~# apt update && apt install lsb-release ca-certificates apt-transport-https software-properties-common wget gnupg2 curl -y
On mets les dépôts centreon dans la VM et on importe la clé GPG :
root@centreon-poller1:~# echo "deb https://packages.centreon.com/apt-standard/ $(lsb_release -sc)-25.10-stable main" | tee -a /etc/apt/sources.list.d/centreon-25.10-stable.list
root@centreon-poller1:~# echo "deb https://packages.centreon.com/apt-plugins-stable/ $(lsb_release -sc) main" | tee /etc/apt/sources.list.d/centreon-plugins.list
root@centreon-poller1:~# wget -O- https://apt-key.centreon.com | gpg --dearmor | tee /etc/apt/trusted.gpg.d/centreon.gpg > /dev/null 2>&1
On installe centreon-poller et on enable/start/restart certains services :
root@centreon-poller1:~# apt update && apt install -y --no-install-recommends centreon-poller
root@centreon-poller1:~# systemctl enable centreon centengine centreontrapd snmptrapd gorgoned
root@centreon-poller1:~# systemctl start centreontrapd snmptrapd gorgoned
root@centreon-poller1:~# systemctl restart centengine
Depuis la version 24 (je crois), centreon a fait un script pour automatiquement renseigner les informations du poller au central. Pour l'utiliser, il faut que l'utilisateur admin puisse utiliser l'api (dans la configuration des users en web). Ensuite, il suffit juste de taper ça :
root@centreon-poller1:~# /usr/share/centreon/bin/registerServerTopology.sh -u admin -t poller -h 192.168.10.105 -n poller1
En web, on rajoute un poller :
Avec le script, les infos sont déjà mises (il faut choisir le bon dans select pending poller ip)
Une fois ajouté, il faut exporter la configuration gorgone du poller (bouton à droite) :
On pousse la configuration sur le poller :
root@centreon-poller1:~# cat < /etc/centreon-gorgone/config.d/40-gorgoned.yaml
name: gorgoned-poller1
description: Configuration for poller poller1
gorgone:
gorgonecore:
id: 2
external_com_type: tcp
external_com_path: "*:5556"
authorized_clients:
- key: e34GVFyyVVWAu9lY0R9mc1YHz878_DRIs-AlVywqbJ0
privkey: "/var/lib/centreon-gorgone/.keys/rsakey.priv.pem"
pubkey: "/var/lib/centreon-gorgone/.keys/rsakey.pub.pem"
modules:
- name: engine
package: gorgone::modules::centreon::engine::hooks
enable: true
command_file: "/var/lib/centreon-engine/rw/centengine.cmd"
EOF
Un petit systemctl restart gorgoned sur le poller et le central. Et pour finir ? On restart le poller depuis l'interface web (du moins que les services centreon 😄)
Le poller est bien up !
Donc quand on va ajouter un CPE à notre supervision, on va le mettre sur poller1 via API. On peut très bien aussi mettre plusieurs pollers pour faire du load balacing. Il suffit juste de reproduire les mêmes actions que pour rajouter un poller !
Presque tous nos outils sont construits. Il nous reste plus que ...
PowerDNS
Pourquoi des DNS me direz vous, surtout dans le cadre d'automatisation ? C'est un petit caprice de ma part mais j'ai envie de mettre de l'IPv6 sur mes CPE et donc que le management se fasse à travers l'IPv6. Perso, je n'arrive pas à me retenir d'une adresse de 128 bits (plus simple en v4 😅). Donc à chaque création de client, je souhaite rajouter un IN AAAA avec l'IP de management. Allez on installe tout ca. On commence (encore une fois) par renseigner les dépôts :
root@powerdns:~# echo "deb [signed-by=/etc/apt/keyrings/auth-50-pub.asc] http://repo.powerdns.com/debian trixie-auth-50 main" > /etc/apt/sources.list.d/pdns.list
root@powerdns:~# echo "Package: pdns-*
Pin: origin repo.powerdns.com
Pin-Priority: 600" > /etc/apt/preferences.d/auth-50
root@powerdns:~# install -d /etc/apt/keyrings; curl https://repo.powerdns.com/FD380FBB-pub.asc | sudo tee /etc/apt/keyrings/auth-50-pub.asc
Ensuite, on installe powerdns et notre database (postgresql). On crée aussi la base et on importe le schéma sql pour créer les tables :
root@powerdns:~# apt install pdns-server postgresql -y
root@powerdns:~# apt install pdns-backend-pgsql -y
root@powerdns:~# sudo -u postgres psql
postgres=# CREATE USER pdns ENCRYPTED PASSWORD 'password';
CREATE ROLE
postgres=# CREATE DATABASE pdns OWNER pdns;
CREATE DATABASE
root@powerdns:~# psql -U pdns -d pdns -f /usr/share/doc/pdns-backend-pgsql/schema.pgsql.sql
Il nous reste plus qu'à renseigner les informations de connexion pour que powerdns puisse accéder à la database et on remove le backend-bind (par défaut) :
root@powerdns:~# cat << EOF > /etc/powerdns/pdns.d/gpgsql.conf
launch=gpgsql
gpgsql-host=127.0.0.1
gpgsql-port=5432
gpgsql-dbname=pdns
gpgsql-user=pdns
gpgsql-password=password
gpgsql-dnssec=yes
EOF
root@powerdns:~# apt remove pdns-backend-bind -y
root@powerdns:~# rm /etc/powerdns/pdns.d/bind.conf
root@powerdns:~# nano /etc/powerdns/pdns.conf
api=yes
api-key=naruto
root@powerdns:~# systemctl restart pdns.service
Pour être honnête, cette installation m'aurait suffit MAIS j'ai toujours eu des problèmes avec DNS (j'y pigais rien au début) donc je me permets d'installer une interface web : Poweradmin. Pour ce faire, on commence par installer tous les paquets nécessaires :
rroot@powerdns:~# apt install -y php php-cli php-fpm php-intl php-xml php-mbstring php-curl php-zip php-common php-pgsql nginx unzip
Ensuite dans notre nginx, on met ce fichier : (il faut adapter le server_name)
root@powerdns:~# nano /etc/nginx/sites-available/poweradmin
server {
listen 80;
server_name ns1.naruto.ninja;
root /var/www/html;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# Deny access to .htaccess and .htpasswd files for security reasons
location ~ /\.ht {
deny all;
}
}
On crée un lien symbolique entre sites-available et sites-enabled et on télécharge poweradmin. On le dézip, on le copie colle dans /var/www/html et on restart nginx :
root@powerdns:~# ln -s /etc/nginx/sites-available/poweradmin /etc/nginx/sites-enabled/
root@powerdns:~# wget https://github.com/poweradmin/poweradmin/archive/refs/tags/v4.0.4.zip
root@powerdns:~# unzip v4.0.4.zip
root@powerdns:~# cp -r poweradmin-4.0.4/* /var/www/html/
root@powerdns:~# chown -R www-data:www-data /var/www/html/
root@powerdns:~# rm /etc/nginx/sites-enabled/default
root@powerdns:~# systemctl restart nginx
On peut se connecter en interface web maintenant :
Laissez vous guider dans l'installation. Toutefois, il faut bien respecter les indications (création des droits dans la bdd/config.php etc). Au final, on a cette vue là :
Pour tester que cela fonctionne bien, j'ai crée une zone toto.fr puis un IN A test.toto.fr 109.205.64.1. Avec un petit dig :
root@powerdns:/var/www/html# dig @127.0.0.1 test.toto.fr
; DiG 9.20.15-1~deb13u1-Debian @127.0.0.1 test.toto.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58527
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.toto.fr. IN A
;; ANSWER SECTION:
test.toto.fr. 86400 IN A 109.205.64.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Dec 26 14:52:38 CET 2025
;; MSG SIZE rcvd: 57
Top ! Notre résolution de nom fonctionne bien. Je compte un peu développer la partie DNS (pour m'améliorer sur cette archi) en mettant un second authoritative et des DNS récursifs.
ZTP Mikrotik
Ce sujet a déjà fait sujet d'un épisode donc je ne vais pas détailler l'installation ni la présentation. J'ai développé une API (et une interface WEB) en react/go qui vise à automatiser la production de ces CPE. Les mikrotiks peuvent émettre des requêtes HTTP via tool fetch en CLI 😄
Conclusion
Gros épisode aujourd'hui mais ca en valait clairement la peine ! Notre stack est au complète ( Gitlab / Netbox / Freeradius / Centreon / PowerDNS / ZTP Mikrotik). Nombreux d'entres vous me diront que ce ne sont pas des outils "devops" mais je pense qu'on peut faire du devops avec n'importes quelles solutions.
Le but final étant que la production soit entièrement automatisé. L'utilisateur va donc faire une requête à Netbox pour récupérer une IP, ensuite Freeradius pour le login PPP, Centreon et PowerDNS pour la supervision et l'enregistrement DNS, et pour finir la génération de la configuration via mon outil pour mes Mikrotik !
On va donc pouvoir enfin commencer à développer ce code. Une fois fini, j'aimerai automatiser la partie support N1 (coupure liaison fibre/cpe KO/etc). Je ne pense pas qu'il soit intéressant pour une personne de faire ce genre de travail ... Autant accompagner cette personne pour faire de l'expertise technique N2/N3 (bon la production N2 sera aussi automatisé mais bon lol).
Je vais travailler en parallèle sur mon infra VOIP (enfin !). Comme ca, si un nouveau client signe, je pourrai automatiser la création du tenant dans l'IPBX et la configuration des postes.
Je termine sur un mot de fin : Guillaume, tu seras mon directeur technique !