Continuous Integration – Continuous Delivery (CICD) is becoming more and more popular for network automation but the problem is how to validate your scripts and stage the configuration because you don’t want to deploy untested code to a production system. Especially in networking that could be pretty destructive if you made a mistake which could cause a loss in connectivity.
I spend some days working on a Cumulus Linux lab using Vagrant which I use to stage configuration. You find the basic Ansible playbook and the gitlab-ci configuration for the Cumulus lab in my Github repo: cumulus-lab-provision
For the continuous integration and delivery (CI/CD) pipeline I am using Gitlab.com and their Gitlab-runner which is running on my server. I will not get into too much detail what is needed on the server, basically it runs vargant, libvirt (kvm), virtualbox, ansible and the gitlab-runner.
- You need to register your Gitlab-runner with the Gitlab repository.
- The next step is to create your .gitlab-ci.yml which defines your CI-pipeline.
--- stages: - validate ansible - staging - production validate: stage: validate ansible script: - bash ./linter.sh staging: before_script: - git clone https://github.com/berndonline/cumulus-lab-vagrant.git - cd cumulus-lab-vagrant/ - python ./topology_converter.py ./topology-staging.dot -p libvirt --ansible-hostfile stage: staging script: - bash ../staging.sh production: before_script: - git clone https://github.com/berndonline/cumulus-lab-vagrant.git - cd cumulus-lab-vagrant/ - python ./topology_converter.py ./topology-production.dot -p libvirt --ansible-hostfile stage: production when: manual script: - bash ../production.sh only: - master
In the gitlab-ci you see that I clone the cumulus vagrant lab which I use to spin-up a virtual staging environment and run the Ansible playbook against the virtual lab. The production stage is in my example also a vagrant environment because I had no physical switches for testing.
- Basically any commit or merge in the Gitlab repo triggers the pipeline which I define in the gitlab-ci.
- You can see the details in the running job. The first stage is only to validate that the YAML files have the correct syntax.
- Here the details of the running job of staging and when everything goes well the job succeeded.
- The last stage is production which needs to be triggered manually.
- After the changes run through all defined stages you see that you successfully validate, staged and deployed your configuration to a cumulus production system.
This is a complete different way of working for a network engineer but the way it goes in fully automated datacenter network environments. It gets very powerful when you combine this with the Cumulus NetQ server to validate the state of your switch fabric after you run changes in production.
The next topic I am working on, is using Cumulus NetQ to validate configuration changes.
Here again my two repositories I use:
Read my new posts about an Ansible Playbook for Cumulus Linux BGP IP-Fabric and Cumulus NetQ Validation and BGP EVPN and VXLAN with Cumulus Linux.
5 Replies to “Continuous Integration and Delivery for Networking with Cumulus Linux”
Bernd, could you do an article on how exactly you set up your gitlab-ci environment. I’m trying to lab this up myself and struggling. The commits on Gitlab don’t seem to integrate with the runner and local repository I have on my server. I can’t see the connection…..I’m missing something. I really want to get this framework into my work network environment. Any help much appreciated.
Ken, you need to check that the runner is successfully registered in your repo, also disable the shared runners.
How did you configure your runner?
I moved to a new server and also need to re-register my runner again, I will write a short post about it in the next few days and share it with you.
I published a new blog post about getting started with Gitlab-CI: https://techbloc.net/archives/2776
Have a look if that helps and answers some of your questions about Gitlab-CI.