Infrastructure

I recently rebuilt my monitoring environment for the servers I manage. In this post I describe what technologies I chose and how they fit together to form a monitoring stack that - once set up – gives you quick access to relevant metrics and logs and doesn’t burden you much with operations. A couple of requirements were important for me: Everything should be self-hosted and I wanted a central monitoring server which collects data from all monitored hosts Since most servers I manage are internal and not reachable from the outside, pushing metrics and logs is more practical than pulling (partially allowed outbound access is a given). Pushing also skips maintaining a list of servers on the monitoring host. Distributing collectors to the servers to be monitored should be easy Servers should authenticate to push logs and metrics and it should be easy for me to onboard new servers or revoke access. There should only be a limited amount of management overhead to manage credentials/PKI on my side Monitoring dashboards and exploratory tools for logs need only be accessible for me without much compartmentalization but should obviously also be properly protected When certain metrics go out of normal range or relevant errors pop up I should get alerts. The notifications should arrive as emails in my mailbox and as notifications on my phone (iOS). I operate at a relatively small scale, so keep this in mind :-) ...

I’m currently in the process of setting up several cloud servers for a new project. The whole infrastructure will run on Hetzner Cloud and be codified. Since it’s the first time I’m using the Terraform provider for Hetzner Cloud, I want to write down some of the notes I took. I’ll focus on creating a small, simplified, self-contained example to create a server, set up a firewall, and get a public IP assigned (no private network). If you want to manage multiple stacks and/or multiple projects, it generally makes sense to create your own modules and shared configurations. This is, however, out of scope for this post and not really any different when using Hetzner Cloud vs. other providers. ...

The problem statement Let’s say you have a (Windows or Linux) EC2 instance in a private subnet and want to access it interactively. There are several ways to do this: You could use a bastion host in your public subnet, harden it and limit access to a certain IP range, and then tunnel your SSH or RDP (or any other TCP) traffic through this host using SSH. Alternatively, you could set up a VPN server through which to connect to your instance. ...

When you have set up your infrastructure with Terraform and then do any change to the user_data of a EC2 instance, Terraform will detect the change and generally do a force-replacement of the instance. In the planning stage this could look something like this: # aws_instance.web_backend must be replaced -/+ resource "aws_instance" "web_backend" { [...] ~ user_data = "1c4e236bd5dec74fecc99d3a3d57679b9b12a927" -> "f8d9add08d4ead74d44af35452c6070dbfcb1576" # forces replacement + user_data_base64 = (known after apply) [...] So what can you do when you want to make changes to user_data but don’t want to destroy your instance and create a new one? ...

I recently worked with Terraform to codify IT infrastructure, i.e. server deployments, network configurations and other resources. Based on my working notes, I want to give an introduction on how to write infrastructure resource definitions and execute them using Terraform. I’ll be using AWS as a cloud provider in my examples, but many more providers are available. In fact, one of the advantages of using a platform agnostic tool is that you can manage all your infrastructure in one place – not individually for every provider or on-premise platform you use. ...