Other writings

My current client has a Rails application that is tightly coupled to Nginx. This sort of coupling is fairly common and used to avoid static files being served by the Rails stack. The files most notable in this respect are the applications assets. The assets are created as part of the application using a command like rake assets:precompile. Those assets are specific to the particular version of the code.

Logs are great. They are easy when you’re running on one or two boxes. However, they get harder when you’re running in a modest distributed environment and even more so if you’ve embraced micro-services and containers. I’ve compiled some notes and thoughts on getting Logentries running in a Kubernetes environment.

Whether or not root volumes on AWS need to be encrypted is a subject of debate. The encrypted AMI is all about protecting data at rest.           Encryption at rest protects against three things: The disk with the root volume on it being stolen from an AWS data center The disk not being properly destroyed when Amazon recycles it Some sort of leak in AWS infrastructure code that allows another entity to access your volume All three scenarios are pretty unlikely, but (as with most things in life) there are no guarantees. Some of our clients don’t keep the kind of sensitive information that mandates encryption. However, others who are entrusted with such data and are under regulatory mandates demand encryption. At one point, it was only (easily) possible to encrypt data volumes. Many used these additional volumes to store sensitive information and avoid writing to the root volume. However, late in 2015, AWS announced encrypted EBS boot volumes- a great feature that closed the gap on the encryption front across the instance. For organizations with compliance requirements, encrypted EBS boot volumes aren’t just a feature, but a must have. Creating an encrypted EBS volume is straightforward and simple: Find an AMI you want to use as your base Copy the AMI to your AWS account and check the Encrypted box Use the new encrypted AMI as the boot volume for your instances You can find command line examples of how to create an encrypted EBS volume from this AWS Blog. At Fairwinds, we like to automate even further. Since we use Ansible, we put together a role that creates an encrypted AMI. In addition to handling the copy, the role will also help you find a base AMI to use for your encrypted AMI. (You can find the role on our Fairwinds GitHub page. If you’re going down the root volume encryption route, we hope this role will prove useful.) In short, encryption is a no-brainer for those with regulatory requirements. Many questions go away if you can check the “all data is encrypted” box. For those on the fence, I’ll offer this rule of thumb: If you encrypt your data volumes, you should also encrypt the root volume. After all, why put three deadbolts on the front door and then leave the back door open?

Ansible tag's simple requirements make it very easy to get started. Overall, it works extremely well, but once you get a bit deeper some things might end up causing discomfort. Here are 3 things I’ve learned about Ansible (or re-learned) the hard way.

Amazon Elasticsearch Service is a managed service intended to make it easy to deploy, operate and scale Elasticsearch clusters in the AWS Cloud. When we first looked at Amazon Elasticsearch Service shortly after it was released in October 2015, we weren’t very impressed. Several aspects and features of Amazon Elasticsearch Service didn’t meet our needs or our clients’ needs at the time, chief among them the fairly dated version offered and limited access controls.