Skip to main content


Showing posts from January, 2020

How to work with Ansible templates

Ansible is a very powerful language that can be used in infrastructure as code , or the idea of using playbooks that can deploy IT environments in a reproducible manner. One of the powerful features that Ansible provides is the concept of templates. Here, we’ll go over a simple example of how to deploy a MailEnable installation with a domain name, catch-all mailbox and other configuration options. First, we’ll need a short PowerShell script which will configure the MailEnable instance. Save this file as templates/install_mailenable.ps1 . $ErrorActionPreference = 'stop' Add-PSSnapin MailEnable.Provision.Command try { New-MailEnablePostOffice -Postoffice '' -Domain '' } catch { if (-Not ($_.Exception.Message -Like '*because they already existed')) { throw } } $mailbox_map = Get-MailEnableAddressMap -Postoffice '' -Mailbox postmaster | Where-Object { $_.SourceAddress -eq '[SMTP:*@]' } if ($mailbox_map -eq $nu

Backing up your cloud instances with AWS Lifecycle Policy

Are you doing backups of your cloud instances? The cloud is great because a lot of the regular maintenance is delegated to the cloud provider. If you want to run a new VM in the AWS cloud, you go to the console and spin up a new EC2 instance. You don’t have to worry about provisioning the hardware, worry about power management, cooling, or even having enough resources on your hypervizor to get that new VM powered up. All of that is taken care of automatically by the Amazon staff. However, the cloud takes care of very specific tasks, and backups isn’t one of them. Even for a service like S3, where Amazon claims a 99.5% to 99.99% reliability, it’s still up to you to make sure your data is backed up. Deciding what you should be backing up is totally dependent on your specific workloads, but anything that contains user data or other types of data that would be costly or time sensitive to replace, should probably be backed up. When it comes to EC2 instances, snapshots is th

Checking the health of AWS ELB targets using a Lambda function

AWS Elastic Load Balancing provides redundant access to computing resources such as EC2 instances. By placing several instances behind a single load balancer, you ensure that traffic will only go to active instances, and if any node becomes unhealthy, the load balancer will automatically drive traffic away from them. This is configured using target groups which group instances together in a pool, and defines what healthy means. While this system provides various reporting facilities, there’s no direct way to parse the health status of those targets using custom filters, so that you can be notified if a target becomes unhealthy, but not if the instance has been shut down for maintenance on purpose, for example. This is where using a Lambda function can come in handy. For this tutorial, we’ll need the following resources: One or more EC2 instances mapped to one or more target groups. These are the instances that we will monitor the health of. An ELB load balancer driving