Fedora - Deploy Fedora CoreOS servers with Terraform

Fedora - Deploy Fedora CoreOS servers with Terraform - Printable Version

+- Sick Gaming (https://www.sickgaming.net)
+-- Forum: Computers (https://www.sickgaming.net/forum-86.html)
+--- Forum: Linux, FreeBSD, and Unix types (https://www.sickgaming.net/forum-88.html)
+--- Thread: Fedora - Deploy Fedora CoreOS servers with Terraform (/thread-98898.html)

Fedora - Deploy Fedora CoreOS servers with Terraform - xSicKxBot - 12-24-2020

Deploy Fedora CoreOS servers with Terraform

<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/12/deploy-fedora-coreos-servers-with-terraform.png" width="693" height="458" title="" alt="" /></div><div>Fedora CoreOS is a lightweight, secure operating system optimized for running containerized workloads. A YAML document is all you need to describe the workload you’d like to run on a Fedora CoreOS server.
This is wonderful for a single server, but how would you describe a fleet of cooperating Fedora CoreOS servers? For example, what if you wanted a set of servers running load balancers, others running a database cluster and others running a web application? How can you get them all configured and provisioned? How can you configure them to communicate with each other? This article looks at how Terraform solves this problem.
 
<h2>Getting started</h2>
Before you start, decide whether you need to review the basics of Fedora CoreOS. Check out this <a href="https://fedoramagazine.org/getting-started-with-fedora-coreos/">previous article</a> on the Fedora Magazine:
<figure class="wp-block-embed-wordpress wp-block-embed is-type-wp-embed is-provider-fedora-magazine">
<div class="wp-block-embed__wrapper">
<blockquote class="wp-embedded-content" data-secret="tFk8xcK0hL"><a href="https://fedoramagazine.org/getting-started-with-fedora-coreos/">Getting started with Fedora CoreOS</a></blockquote>
</div>
</figure>
Terraform is an open source tool for defining and provisioning infrastructure. Terraform defines infrastructure as code in files. It provisions infrastructure by calculating the difference between the desired state in code and observed state and applying changes to remove the difference.
HashiCorp, the company that created and maintains Terraform, offers an RPM repository to install Terraform. 
<pre class="wp-block-preformatted">sudo dnf config-manager --add-repo \ https://rpm.releases.hashicorp.com/fedora/hashicorp.repo
sudo dnf install terraform</pre>
To get yourself familiar with the tools, start with a simple example. You’re going to create a single Fedora CoreOS server in AWS. To follow along, you need to install awscli and have an AWS account. awscli can be installed from the Fedora repositories and configured using the aws configure command
<pre class="wp-block-preformatted">sudo dnf install -y awscli
aws configure</pre>
Please note, AWS is a paid service. If executed correctly, participants should expect less than $1 USD in charges, but mistakes may lead to unexpected charges. 
<h2>Configuring Terraform</h2>
In a new directory, create a file named config.yaml. This file will hold the contents of your Fedore CoreOS configuration. The configuration simply adds an SSH key for the core user. Modify the authorized_ssh_key section to use your own.
<div class="wp-block-group">
<div class="wp-block-group__inner-container">
<pre class="wp-block-preformatted">variant: fcos
version: 1.2.0
passwd: users: - name: core authorized_ssh_keys: - "ssh-ed25519 AAAAC3....... user@hostname"</pre>
Next, create a file main.tf to contain your Terraform specification. Take a look at the contents section by section. It begins with a block to specify the versions of your providers.
</div>
</div>
<pre class="wp-block-preformatted">terraform { required_providers { ct = { source = "poseidon/ct" version = "0.7.1" } aws = { source = "hashicorp/aws" version = "~> 3.0" } }
}</pre>
Terraform uses providers to control infrastructure. Here it uses the AWS provider to provision EC2 servers, but it can provision any kind of AWS infrastructure. The <a rel="noreferrer noopener" href="https://github.com/poseidon/terraform-provider-ct" target="_blank">ct provider</a> from <a rel="noreferrer noopener" href="https://www.psdn.io/" target="_blank">Poseidon Labs</a> stands for config transpiler. This provider will <a href="https://en.wikipedia.org/wiki/Source-to-source_compiler">transpile</a> Fedora CoreOS configurations into Ignition configurations. As a result, you do not need to use <a rel="noreferrer noopener" href="https://docs.fedoraproject.org/en-US/fedora-coreos/using-fcct/" target="_blank">fcct</a> to transpile your configurations. Now that your provider versions are specified, initialize them.
<pre class="wp-block-preformatted">provider "aws" { region = "us-west-2"
} provider "ct" {}</pre>
The AWS region is set to us-west-2 and the ct provider requires no configuration. With the providers configured, you’re ready to define some infrastructure. Use a <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/data-sources.html" target="_blank">data source</a> block to read the configuration.
<pre class="wp-block-preformatted">data "ct_config" "config" { content = file("config.yaml") strict = true
}</pre>
With this data block defined, you can now access the transpiled Ignition output as data.ct_config.config.rendered. To create an EC2 server, use a <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/blocks/resources/syntax.html" target="_blank">resource</a> block, and pass the Ignition output as the user_data attribute.
<pre class="wp-block-preformatted">resource "aws_instance" "server" { ami = "ami-0699a4456969d8650" instance_type = "t3.micro" user_data = data.ct_config.config.rendered
}</pre>
This configuration hard-codes the virtual machine image (AMI) to the latest stable image of Fedora CoreOS in the us-west-2 region at time of writing. If you would like to use a different region or stream, you can discover the correct AMI on the <a rel="noreferrer noopener" href="https://getfedora.org/en/coreos/download?tab=cloud_launchable&stream=stable" target="_blank">Fedora CoreOS downloads page</a>.
Finally, you’d like to know the public IP address of the server once it’s created. Use an <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/outputs.html" target="_blank">output</a> block to define the outputs to be displayed once Terraform completes its provisioning.
<pre id="block-5c4fc71c-60bb-49c4-a04e-fc67b2aff056" class="wp-block-preformatted">output "instance_ip_addr" { value = aws_instance.server.public_ip
}</pre>
Alright! You’re ready to create some infrastructure. To deploy the server simply run:
<pre class="wp-block-preformatted">terraform init # Installs the provider dependencies
terraform apply # Displays the proposed changes and applies them</pre>
Once completed, Terraform prints the public IP address of the server, and you can SSH to the server by running ssh core@{public ip here}. Congratulations — you’ve provisioned your first Fedora CoreOS server using Terraform!
<h2>Updates and immutability</h2>
At this point you can modify the configuration in config.yaml however you like. To deploy your change simply run terraform apply again. Notice that each time you change the configuration, when you run terraform apply it destroys the server and creates a new one. This aligns well with the Fedora CoreOS philosophy: Configuration can only happen once. Want to change that configuration? Create a new server. This can feel pretty alien if you’re accustomed to provisioning your servers once and continuously re-configuring them with tools like <a rel="noreferrer noopener" href="https://www.ansible.com/" target="_blank">Ansible</a>, <a rel="noreferrer noopener" href="https://puppet.com/" target="_blank">Puppet</a> or <a rel="noreferrer noopener" href="https://www.chef.io/" target="_blank">Chef</a>.
The benefit of always creating new servers is that it is significantly easier to test that newly provisioned servers will act as expected. It can be much more difficult to account for all of the possible ways in which updating a system in place may break. Tooling that adheres to this philosophy typically falls under the heading of Immutable Infrastructure. This approach to infrastructure has some of the same benefits seen in functional programming techniques, namely that mutable state is often a source of error.
<h2>Using variables</h2>
You can use Terraform <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/variables.html" target="_blank">input variables</a> to parameterize your infrastructure. In the previous example, you might like to parameterize the AWS region or instance type. This would let you deploy several instances of the same configuration with differing parameters. What if you want to parameterize the Fedora CoreOS configuration? Do so using the <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/functions/templatefile.html" target="_blank">templatefile</a> function.
As an example, try parameterizing the username of your user. To do this, add a username variable to the main.tf file:
<pre class="wp-block-preformatted">variable "username" { type = string description = "Fedora CoreOS user" default = "core"
}</pre>
Next, modify the config.yaml file to turn it into a template. When rendered, the ${username} will be replaced.
<pre class="wp-block-preformatted">variant: fcos
version: 1.2.0
passwd: users: - name: ${username} authorized_ssh_keys: - "ssh-ed25519 AAAAC3....... user@hostname"</pre>
Finally, modify the data block to render the template using the templatefile function.
<pre class="wp-block-preformatted">data "ct_config" "config" { content = templatefile( "config.yaml", { username = var.username } ) strict = true
}</pre>
To deploy with username set to jane, run terraform apply -var=”username=jane”. To verify, try to SSH into the server with ssh jane@{public ip address}.
<h2>Leveraging the dependency graph</h2>
Passing variables from Terraform into Fedora CoreOS configuration is quite useful. But you can go one step further and pass infrastructure data into the server configuration. This is where Terraform and Fedora CoreOS start to really shine.
Terraform creates a <a rel="noreferrer noopener" href="https://www.terraform.io/docs/internals/graph.html" target="_blank">dependency graph</a> to model the state of infrastructure and to plan updates. If the output of one resource (e.g the public IP address of a server) is passed as the input of another service (e.g the destination in a firewall rule), Terraform understands that changes in the former require recreating or modifying the later. If you pass infrastructure data into a Fedora CoreOS configuration, it will participate in the dependency graph. Updates to the inputs will trigger creation of a new server with the new configuration.
Consider a system of one load balancer and three web servers as an example.
<figure class="wp-block-image size-large"><img loading="lazy" width="693" height="458" src="https://www.sickgaming.net/blog/wp-content/uploads/2020/12/deploy-fedora-coreos-servers-with-terraform.png" alt="" class="wp-image-32437" /></figure>
The goal is to configure the load balancer with the IP address of each web server so that it can forward traffic to them.
<h2>Web server configuration</h2>
First, create a file web.yaml and add a simple Nginx configuration with a templated message.
<pre class="wp-block-preformatted">variant: fcos
version: 1.2.0
systemd: units: - name: nginx.service enabled: true contents: | [Unit] Description=Nginx Web Server After=network-online.target Wants=network-online.target [Service] ExecStartPre=-/bin/podman kill nginx ExecStartPre=-/bin/podman rm nginx ExecStartPre=/bin/podman pull nginx ExecStart=/bin/podman run --name nginx -p 80:80 -v /etc/nginx/index.html:/usr/share/nginx/html/index.html:z nginx [Install] WantedBy=multi-user.target
storage: directories: - path: /etc/nginx files: - path: /etc/nginx/index.html mode: 0444 contents: inline: | <html> <h1>Hello from Server ${count}</h1> </html></pre>
In main.tf, you can create three web servers using this template with the following blocks:
<pre class="wp-block-preformatted">data "ct_config" "web" { count = 3 content = templatefile( "web.yaml", { count = count.index } ) strict = true
} resource "aws_instance" "web" { count = 3 ami = "ami-0699a4456969d8650" instance_type = "t3.micro" user_data = data.ct_config.web[count.index].rendered
}</pre>
Notice the use of count = 3 and the count.index variable. You can use <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/meta-arguments/count.html" target="_blank">count</a> to make many copies of a resource. Here, it creates three configurations and three web servers. The count.index variable is used to pass the first configuration to the first web server and so on.
<h2>Load balancer configuration</h2>
The load balancer will be a basic <a rel="noreferrer noopener" href="https://www.haproxy.org/" target="_blank">HAProxy load balancer</a> that forwards to each server. Place the configuration in a file named lb.yaml:
<pre class="wp-block-preformatted">variant: fcos
version: 1.2.0
systemd: units: - name: haproxy.service enabled: true contents: | [Unit] Description=Haproxy Load Balancer After=network-online.target Wants=network-online.target [Service] ExecStartPre=-/bin/podman kill haproxy ExecStartPre=-/bin/podman rm haproxy ExecStartPre=/bin/podman pull haproxy ExecStart=/bin/podman run --name haproxy -p 80:8080 -v /etc/haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro haproxy [Install] WantedBy=multi-user.target
storage: directories: - path: /etc/haproxy files: - path: /etc/haproxy/haproxy.cfg mode: 0444 contents: inline: | global log stdout format raw local0 defaults mode tcp log global option tcplog frontend http bind *:8080 default_backend http backend http balance roundrobin
%{ for name, addr in servers ~} server ${name} ${addr}:80 check
%{ endfor ~}</pre>
The template expects a <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/expressions/types.html#maps-objects" target="_blank">map</a> with server names as keys and IP addresses as values. You can create that using the <a rel="noreferrer noopener" href="https://www.terraform.io/docs/configuration/functions/zipmap.html" target="_blank">zipmap</a> function. Use the ID of the web servers as keys and the public IP addresses as values.
<pre class="wp-block-preformatted">data "ct_config" "lb" { content = templatefile( "lb.yaml", { servers = zipmap( aws_instance.web.*.id, aws_instance.web.*.public_ip ) } ) strict = true
} resource "aws_instance" "lb" { ami = "ami-0699a4456969d8650" instance_type = "t3.micro user_data = data.ct_config.lb.rendered
}</pre>
Finally, add an output block to display the IP address of the load balancer.
<pre class="wp-block-preformatted">output "load_balancer_ip" { value = aws_instance.lb.public_ip
}</pre>
All right! Run terraform apply and the IP address of the load balancer displays on completion. You should be able to make requests to the load balancer and get responses from each web server.
<pre class="wp-block-preformatted">$ export LB={{load balancer IP here}}
$ curl $LB
<html> <h1>Hello from Server 0</h1>
</html>
$ curl $LB
<html> <h1>Hello from Server 1</h1>
</html>
$ curl $LB
<html> <h1>Hello from Server 2</h1>
</html></pre>
Now you can modify the configuration of the web servers or load balancer. Any changes can be realized by running terraform apply once again. Note in particular that any change to the web server IP addresses will cause Terraform to recreate the load balancer (changing the count from 3 to 4 is a simple test). Hopefully this emphasizes that the load balancer configuration is indeed a part of the Terraform dependency graph.
<h2>Clean up</h2>
You can destroy all the infrastructure using the terraform destroy command. Simply navigate to the folder where you created main.tf and run terraform destroy.
<h2>Where next?</h2>
Code for this tutorial can be found at <a href="https://github.com/nsmith5/fcos-terraform-tutorial">this GitHub repository</a>. Feel free to play with examples and contribute more if you find something you’d love to share with the world. To learn more about all the amazing things Fedora CoreOS can do, dive into <a href="https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/" target="_blank" rel="noreferrer noopener">the docs</a> or come chat with <a href="https://discussion.fedoraproject.org/c/server/coreos/5" target="_blank" rel="noreferrer noopener">the community</a>. To learn more about Terraform, you can rummage through <a href="https://www.terraform.io/docs/index.html" target="_blank" rel="noreferrer noopener">the docs</a>, checkout #terraform on <a href="https://freenode.net/" target="_blank" rel="noreferrer noopener">freenode</a>, or contribute on <a href="https://github.com/hashicorp/terraform" target="_blank" rel="noreferrer noopener">GitHub</a>.
</div>

https://www.sickgaming.net/blog/2020/12/23/deploy-fedora-coreos-servers-with-terraform/