dwmkerr.com

In this article I’m going to give a brief overview of some techniques to build ’least privilege’ roles in AWS. This assumes a basic knowledge of AWS and Identity and Access Management. It uses the (at time of writing) newly announced features in the AWS IAM Access Analyser I’ll be demoing the techniques using a project built on The Serverless Framework but you don’t need to know anything about how this framework works to follow the article - it is just used to demonstrate the concepts.

When building Terraform modules, it is a common requirement to want to allow the client to be able to choose which region resources are created in, and which availability zones are used. I’ve seen a few ways of doing this, none of which felt entirely satisfactory. After a bit of experimentation I’ve come up with a solution which I think really works nicely. This solution avoids having to know in advance how many availability zones we’ll support.

In this article I’m going to show you how to set up OpenShift to integrate with Splunk for logging in a Docker container orchestration environment. These techniques could easily be adapted for a standard Kubernetes installation as well! The techniques used in this article are based on the Kubernetes Logging Cluster Administration Guide. I also found Jason Poon’s article Kubernetes Logging with Splunk very helpful. First, clone the Terraform AWS OpenShift repo:

OpenShift is Red Hat’s platform-as-a-service offering for hosting and scaling applications. It’s built on top of Google’s popular Kubernetes system. Getting up and running with OpenShift Online is straightforward, as it is a cloud hosted solution. Setting up your own cluster is a little more complex, but in this article I’ll show you how to make it fairly painless. The repo for this project is at: github.com/dwmkerr/terraform-aws-openshift. Creating the Infrastructure OpenShift has some fairly specific requirements about what hardware it runs on1.

In this article I’m going to show you how to create a resilient Consul cluster, using Terraform and AWS. We can use this cluster for microservice discovery and management. No prior knowledge of the technologies or patterns is required! The final code is at github.com/dwmkerr/terraform-consul-cluster. Note that it has evolved somewhat since the time of writing, see the Appendices at the end of the article for details. Consul, Terraform & AWS Consul is a technology which enables Service Discovery1, a pattern which allows services to locate each other via a central authority.

tl;dr: Run DynamoDB locally using Docker: docker run -d -p 8000:8000 dwmkerr/dynamodb Try it out by opening the shell, localhost:8000/shell: That’s all there is to it! DynamoDB Amazon DynamoDB is a NoSQL database-as-a-service, which provides a flexible and convenient repository for your services. Building applications which use DynamoDB is straightforward, there are APIs and clients for many languages and platforms. One common requirement is to be able to run a local version of DynamoDB, for testing and development purposes.

tl;dr? Check your mongodb.conf bind_ip settings to make sure that you’re not allowing connections only from localhost. This may just end up being the first part of a wider troubleshooting guide, but this is one I’ve spent a few hours fixing, after assuming I was making terrible mistakes with my security groups. If you find you cannot connect to your MongoDB server from an EB app server (or anything for that matter), before you spend ages checking your Elastic IP, VPC and Security Group config, don’t forget that you may have simply used bind_ip in your config file.