🕑 Estimated reading time: 5mn
By Alexandre Azario, Network Engineer @ OVHcloud
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:
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 should not be regarded as a role but rather as a state of mind, a culture. DevOps embraces failure, change and automation.
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.
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:
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.
Tests with interconnects are difficult to run natively. Nevertheless, tools can reproduce such behaviors such as Packet Design.
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.
By Michael Bonfils, Backend developer @ OpenIO
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.
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.
When you are ready to deploy your website, on your staging environment:
.gitlab-ci.ymlusing a Yaml linter and GitLab’s own CI Linter;
No, there is not. Additionally, you can host your runners on Kubernetes, on premise, etc.