Meetup-Notes

NetOps and Hugo with GitLab CI

🕑 Estimated reading time: 5mn

Table of Contents

How to become a future-proof network engineer

By Alexandre Azario, Network Engineer @ OVHcloud

History

A few decades ago, the network domain consisted of a triad containing Routers, Switches and Servers. Then came vSwitches, Virtual Machines, Load Balancers, Containers and finally the Cloud. With these new components, the complexity of managing network configuration is very different today than it was then.

It is possible to identify four acts in the evolution of networks:

  1. vLans, Spanning-Trees and Static routing;
  2. Dynamic routing, WANs and Backbones;
  3. MultiProtocol-BGP, vXLan, Software Defined Networking, Controllers;
  4. Cloud, REST and Python on-board, NetConf, Yang, NFV.

Evolution of network consumption

Changing habits with the superior layers of the OSI Model requires improving the lowest layers. At the lowest layer of this model, we find the following skills:

Today, there is a dichotomy between network designers which handle the first three skills and consumers of such services which possess the last three skills. The expectations of network designers and consumers are different and “DevOps” naturally chose to fit in the middle as intermediaries.

DevOps

DevOps should not be regarded as a role but rather as a state of mind, a culture. DevOps embraces failure, change and automation.

The culture of fear in change

Changes in network are infrequent, consequent and complex. Therefore, they are considered risky and fail from time to time. So much that it is common to regard errors as inevitable, which makes changes less frequent and more complex, etc.

Changes should be frequent, simple; usual, tested and verified. Atomic changes should reduce the occurrence and gravity of potential issues. Consequently, changes are seen as successes.

Tooling

Rather than sending commands to follow, today it is usual to express a state to reach. Tools will help to bridge the existing state with the desired one. This reconciliation loop can lead to these kinds of scenarios:

Choosing a tool is often dependent on the community around the domain you are aiming to cover and on the support of protocols and communication interfaces used by your existing hardware or software stack. Testing tools are relatively recent in that space. We are here talking about VIRL and EVE.

Teams often decide on a tool based on the following traits:

Questions and Answers session

Are tests realistic on a virtual network?

Virtual networks may not provide the full set of features an actual network would contain. A physical test network can complete the tests for behaviors that cannot easily be virtualized.

How to run tests with interconnects?

Tests with interconnects are difficult to run natively. Nevertheless, tools can reproduce such behaviors such as Packet Design.

Is it viable to run end-to-end tests in large-scale environments?

Spawning an entire fleet of network appliances is impossible today. Some of the tools are billed by the node and when your network reaches a large enough scale end-to-end testing becomes unwise.

Static website deployment using GitLabCI and Hugo

By Michael Bonfils, Backend developer @ OpenIO
Slides

Presentation

Wordpress is the typical example of a heavy CMS that can easily break. On the other hand, Hugo is a static website generator. It is less feature-rich but the fact that it uses Go makes it lightweight and portable. By default, Hugo is delivered with no theme and natively supports Markdown syntax.

GitLab can easily compile and host code from a Hugo website thanks to its CI/CD and GitLab Pages. Be careful about the Docker image you use for your Hugo website, though!

A Hugo website generated by GitLab CI can be saved thanks to GitLab Artifacts. Artifacts are downloadable by users as well as the next steps of your pipeline. Be careful to change the strategy for your submodules in case you use them to import a theme.

On GitLab, whenever a job is called “pages”, the content of its artifacts is automatically uploaded on GitLab Pages. It is possible to configure the Pages domain for the repository through the settings. By default, that domain will be <your-username>.gitlab.io/<project-name>. In any case, be careful about CORS when you deploy your website, as this can prevent loading external resources.

You may add plugins to extend Hugo’s features.

Testing a website before its deployment

When you are ready to deploy your website, on your staging environment:

Questions and Answers session

Is there a limitation on runner minutes for hosted runners?

No, there is not. Additionally, you can host your runners on Kubernetes, on premise, etc.