Infrastructure as code with Pulumi (Configuration, Workflow)

The usual products for Infrastructure as code, such as Terraform, Ansible, Chef, Puppet, and others, usually have their own syntax, which makes it somewhat difficult to use. Pulumi allows the creation of the infrastructure using popular programming languages, such as TypeScript, JavaScript, Python, Go or C#. In this way we can use our usual or preferred language for the creation of the infrastructure in a simple way, without having to switch to another language and benefiting from the handling of variables and usual programming constructions, such as loops and conditions, basic aspects but not they are too simple to use in the rest of the products.objectives

Learn to deploy infrastructure through code.
Make changes to the infrastructure through code.
Organize the deployment code.
Manage errors from corrupted deployments.

Introduction
Infrastructure as Code (IaC) enables the definition and maintenance of infrastructure through code. This allows automation of the infrastructure creation instead of doing it manually. It is a declarative process in which, through a series of files, the infrastructure and configuration needed are specified declaratively (eg a backend environment consisting of a storage volume, a virtual machine with MySQL installed and connected to the volume created, a virtual machine with an installed framework such as Express, network configuration and security groups, ….). This avoids having to manually prepare virtual machines, operating systems, storage and configuration, obtaining instead the definition of an environment that guarantees to be repeatable, replicable, documenting the specifications and avoiding the practice of making changes on the fly and that are not documented. With IaC, changes are made on top of the code and applied by executing the developed code, rather than being made hot by commands on the infrastructure. In addition, the combination of IaC with the practice of version control will allow, as in any other software development, to keep track of each of the changes introduced in the infrastructure configuration. the changes are made on top of the code and are applied by executing the developed code, instead of making them hot by means of commands on the infrastructure. In addition, the combination of IaC with the practice of version control will allow, as in any other software development, to keep track of each of the changes introduced in the infrastructure configuration. the changes are made on top of the code and are applied by executing the developed code, instead of making them hot by means of commands on the infrastructure. In addition, the combination of IaC with the practice of version control will allow, as in any other software development, to keep track of each of the changes introduced in the infrastructure configuration.

Among the most popular IaC products are Terraform, Ansible, Chef, Puppet, … In these proposals, the infrastructure is specified in very different ways, such as in YAML format in the case of Ansible, or in its own DSL language (Domain Specific Language) such as Terraform's HCL (Hashicorp Configuration Language) and Puppet's Puppet Language , as well as Chef, which uses Ruby as the syntax for defining the infrastructure.

In this context , Pulumi emerges , a new IaC product that differs from the rest in that it uses conventional programming languages for infrastructure configuration, such as TypeScript, JavaScript, Python, Go or C#. This makes it especially interesting, since you will not have to learn an extra language for managing cloud infrastructure and the use of variables and programming constructs such as loops and conditions is facilitated.

Pulumi offers support for major cloud providers such as Amazon, Google Cloud, Microsoft Azure, Digital Ocean, Linode, OpenStack, vSphere, and more, as well as Kubernetes, infrastructure providers, databases, monitoring, and version control systems. .

In this tutorial we will focus on creating a managed Kubernetes cluster with Rancher and using OpenStack as the infrastructure provider. We will use TypeScript as the development language.

Pulumi Configuration
The installation will be done following the official installation guide .
In macOS we will do it through Homebrew with brew install pulumi.
In Windows we will do it through Chocolatey with choco install pulumi.
In Linux we will do it by executing the script .curl -fsSL https://get.pulumi.com | sh
Once installed we will verify that everything is correct with:

$ pulumi version
v3.7.0

Workflow with Pulumi
The usual workflow in Pulumi consists of creating the project, coding the initial infrastructure, deploying changes. However, this is not a sequential process, but rather after project creation you enter an iterative cycle of infrastructure coding and change deployment.

The project is created with the command pulumi new and we will normally pass a template to it as an argument. The template configures the platform with which we are going to work (cloud provider, database, …) and the programming language that we are going to use to code the infrastructure. We will see this in the section Creation and initial configuration of the project .

The changes introduced in the development cycle with Pulumi can be due to either the creation of code for new resources, or the modification or removal of the code of previously created resources. The way to carry out these changes is always with pulumi up. After confirming the deployment action, the changes will be moved to the infrastructure and Pulumi will save the deployment state , which consists of writing down each of the configured resources.

When code changes are later made and include new code for new resources, or modify or remove code from previously created resources, the last saved state of the project will be compared to the new state that would be reached after applying the changes. After confirming the deployment action, Pulumi would only deploy the resources related to the changes made, leaving the resources that have not been modified intact. In this sense, Pulumi is said to be idempotent since it does not recreate a resource that has not been modified. After a successful deployment, Pulumi re-saves the state of the deployment made.

If we remove a resource from the code and execute pulumi up it, that resource will be removed from the infrastructure. Therefore, there are no proper delete operations for each resource. Its code is simply removed from the project and the common changes are deployed pulumi up.

The created infrastructure is removed with pulumi destroy. It is a dangerous operation since it eliminates the entire infrastructure. If there is data or configurations stored in the deployment, there is a risk of data loss.