First 3 underneath are using REST API, but using directly REST API to create resources in AWS might be cumbersome due to authentication that needs to be performed on REST API requests.

CLI/SDK/REST API/Chef/Ansible are more of an imperative/procedural way to define infrastructure (where each step must be explicitly defined so as to create a desired state of it)

Automation tools such as Terraform/SaltStack/Puppet/Pulumi are examples of declarative way (a definition of desired state is provided and it is up to a tool to create a desired state in AWS).

CloudFormation is declarative as well and it is up to AWS to create a desired state as defined in a CloudFormation template. Template is JSON/YAML/text file which can be accompanied with parameters to fill in template values (template can contain default values for parameters).

A template can be built directly by editing a file. However, what if resources were created in AWS Console and one would like save a current state and share it over Slack as file or check it in to git to have versioning ?

CloudFormer can be of help and while it is still in Beta (at least since end of 2018) meaning it should not be used for critical/prod enviroments, it is ideal for demo/PoC/dev purposes:

Terraform by Hashicorp is a pioneer in the area of IaC tooling which allows to define infrastructure in a declarative manner by using its own language (HCL – Hashicorp Configuration Language). That means:

it takes definition of the infrastructure (simplistic example could be a couple of VMs running in AWS or OpenStack) found in the config file (can be a single .tf file) defined in HCL

connects to the IaaS by using an appropriate provider – plugin/extension that allows to talk to AWS/Openstack etc.

compares current state of the infrastructure against what is found in the definition file (.tf)

tries to meet the desired state found definition file (using example below it means to deploy VMs)

Approach as above allows to have a deterministic state of your infrastructure and deployment is performed by calling API of the infrastructure provider rather than manually or using different methods already offered by them (e.g. HEAT templates for Openstack, python client vs CloudFormation for AWS, awscli tool). If a VM is deleted for any reason on the IaaS re-running the terraform apply (command to check current state of the infra, comparing against the definition file and trying to meet the desired state from the file) will just deploy the missing VM.

It allows to have a common language for defining the infrastructure on different infrastructure providers (bearing in mind that each of them use basic different building blocks to create the infrastructure e.g. aws_subnet resource vs openstack_networking_subnet_v2 resource).

Terraform allows for more than just creating resources on public/private cloud providers, it can deploy on kubernetes (more of a PaaS than IaaS), or interact with RESTAPI. People/companies create their custom providers.

However, anyone with some development background will see that that HCL language is limited – even writing a simple loop, while possible – it is somehow done indirectly (I admit I did not have time to check 0.12 option which was supposed to add some typical programming constructs like for loop). Immediately the feeling is that it should be done differently – you want to write a code and have appropriate programming libraries to wrap API calls to different providers. This is where Pulumi comes in – its tenets are the same:

it is declarative

it compares the current state against the definition (defined in the programming language of choice – at the moment of writing JS/TS/Python/Golang are supported)

What is new is that it’s SaaS by default and requires to setup an account on Pulumi website. Pulumi service keeps state on Amazon S3, but there is also an option to keep it locally (different backends). If it is kept on Pulumi then you can check your created infrastructure resources via their website (actually this is very cool, you can even click to connect to created VMs consoles’).

Rather than having a separate language to define the infrastructure you just import appropriate libraries and start defining the infrastructure directly in code. There is no better source of introduction to Pulumi than Joe Duffy’s blog post: http://joeduffyblog.com/2018/06/18/hello-pulumi/.

So which one should you choose? I would say it depends on the people who are going to use it:

Developers, people with development skills should opt for Pulumi so as not to be constrained by HCL. That also means learning curve is steeper for Pulumi.

People without such skills will feel more comfortable with HCL and might not feel constrained by it. They should go with Terraform. I just felt I had to create a lot of boilerplate with it.

Terraform is more mature (older tool) but Pulumi’s people are quite helpful and available on Slack so it is just kicking off.

Tail-F, originally a Swedish company bought over by Cisco Systems, created a management agent software framework for network elements and applications – ConfD. If employed as a part of software – ConfD allows to be programmability an inherent part of it. This post will us a very tangible example of its power – while Linux natively doesn’t offer NETCONF to manage interfaces – with use of ConfD and special program that makes use of it – programmability is made possible.

ConfD uses, what most of up-to-speed network engineers should know, YANG – a data modeling language for NETCONF (if we treat NETCONF as a new SNMP then YANG is like SMI – “special version” of ASN.1 was for SNMP) – better description can be found here: http://www.tail-f.com/what-is-yang/

The way to depict what ConfD does is – let’s say if you create your own program that acts as a router and you need a CLI for e.g. show ip route and additionally you would like to have a possibility to check routes over the NETCONF then it’s going to be done automatically for you. ConfD will run as a process next to your routing process and will manage it’s configuration, offer CLI and NETCONF (also RESTCONF/SNMP/WebAPI if Premium version is used). Of course that means that a if you want to implement ConfD shall be a part of implementing your software, whole configuration, CLIs etc.

More on how ConfD works and its composition (for example there is a database – CDB – that keeps the config) can be found on Tail-F site.

Let’s get to business, demonstration of how it can be used is based on:

confd basic 6.3

ydk 0.7.1 (there will be a separate post on ydk, installation, usage and what is it)

The very reason for using confd 6.3 is that newer versions i.e. 6.4 and 6.6 use YDK 1.1 for modelling and example program I wanted to test with YDK on newer confd versions uses YANG 1.1 while YDK has just partial support for it (full support is for YDK 1.0 – RFC 6020).

access confd CLI by running confd_cli command unless you started using make cli that takes you directly to CLI

Run the example:

Example I would like to use is called linuxcfg but id doesn’t work out of the box. When both versions 6.3.and 6.4 are installed the Makefile in ipmibsdirectory must be overwritten in 6.3 examples folder:

From now on you are on your own….just kiddn’ in the next post I will show how to setup YDK and query linucfg over NETCONF with YANG models provided with this example. Now we have a running linuxcfg with confd that exposes NETCONF. More to follow…