{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"How to Take Control of Your Network Infrastructure. Chapter Four. Automation. Templates.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

This article is the sixth in the series \"How to Take Control of Your Network Infrastructure.\" You can find the content of all articles in the series and links. here<\/a><\/noindex><\/i>.<\/p>\n

Having left several topics behind, I decided to start a new chapter.<\/p>\n

I'll return to security a bit later. Here, I want to discuss one simple but effective approach that I believe can be useful to many in one way or another. This is more of a short story about how automation can change an engineer's life. The discussion will focus on using templates. At the end, I've included a list of my projects where you can see how everything described here works.<\/p>\n

DevOps for Networking<\/h2>\n

\nCreating configuration via scripts, using GIT for change control of the IT infrastructure, remote 'uploads' \u2014 these ideas come to mind first when considering the technical implementation of the DevOps approach. The benefits are obvious. But, unfortunately, there are also drawbacks.<\/p>\n

When more than five years ago, our developers approached us network engineers with these proposals, we weren't thrilled.
\n<\/a><\/noindex>
\nIt should be noted that we inherited a rather diverse network consisting of equipment from about 10 different vendors. Some configurations were convenient to handle through our favorite CLI, while in other cases, we preferred to use the GUI. Furthermore, long periods of working on 'live' equipment accustomed us to real-time control. For instance, when making changes, I feel much more comfortable working directly through the CLI. This allows me to quickly see if something went wrong and to 'rollback' changes. All of this somewhat contradicted their ideas.<\/p>\n

Other questions arise as well, for example, from version to version, the software interface may change slightly. Ultimately, this will lead to your script generating an incorrect 'config.' You wouldn't want to use production for 'testing.' <\/p>\n

Or, how can you ensure that the configuration commands were applied correctly, and what to do in case of an error?<\/p>\n

I don't want to say that all these questions are unsolvable. Just saying 'A,' it's probably wise to also say 'B.' If you want to use the same processes for change control as in development, you need to have not only production but also dev and staging environments. Then this approach looks complete. But how much will this cost?<\/p>\n

However, there is one situation where the drawbacks are practically outweighed, and only the advantages remain. I'm talking about project work.<\/p>\n

Project<\/h2>\n

\nFor the past two years, I've been involved in a project to build a data center for a large provider. I am responsible for F5 and Palo Alto in this project. From Cisco\u2019s perspective, this is '3rd party equipment.'<\/p>\n

Personally, I see two distinct phases in this project. <\/p>\n

The first phase<\/h3>\n

\nIn the first year, I was constantly busy, working nights and weekends. I couldn\u2019t lift my head. The pressure from management and the client was strong and relentless. In the midst of the routine, I couldn't even attempt to optimize the process. It wasn't just about configuring equipment; it was also about preparing project documentation. <\/p>\n

Then the first tests began, and I was shocked at how many small errors and inaccuracies had been made. Of course, everything worked, but there was a missing letter in one name, a missing line in a command... The tests went on and on, and I found myself in a constant, daily battle with errors, tests, and documentation. <\/p>\n

This continued for a year. The project, as far as I understand, was challenging for everyone, but gradually the client became more and more satisfied, which allowed us to bring in additional engineers to share the routine work.<\/p>\n

Now I could take a moment to look around.
\nAnd this was the beginning of the second phase. <\/p>\n

The second phase<\/h3>\n

\nI decided to automate the process.<\/p>\n

What I understood from my discussions with the developers at the time (and credit where it\u2019s due, we had a strong team) is that the text format, although it may seem at first glance like something out of the DOS operating system world, possesses a number of valuable properties.
\nFor example, the text format is useful if you want to fully leverage the advantages of GIT and all its derivatives. And I wanted to. <\/p>\n

Well, one might think that it would be enough to simply store the configuration or the list of commands, but making changes this way is quite inconvenient. Moreover, there\u2019s another crucial task in project design. You need documentation that describes your overall design (Low Level Design) and specific implementation (Network Implementation Plan). In this case, using templates seems like a very suitable option.<\/p>\n

Thus, when using YAML and Jinja2, the YAML file containing configuration parameters such as IP addresses, BGP AS numbers, etc., performs the role of the NIP excellently, while the Jinja2 templates incorporate syntax corresponding to the design, effectively reflecting the LLD. <\/p>\n

It took two days to study the YAML and Jinja2 languages. Understanding how it works is enough with a few good examples. Then, it took about two weeks to create all the templates that matched our design: a week for Palo Alto and another week for F5. All of this was uploaded to the corporate GitHub.<\/p>\n

Now the process of changes looked as follows:<\/p>\n