CoreOS on AWS with Ansible Part 2

Written by Mitch in Automation on Sat 09 January 2016. Tags: ansible, automation, coreos, docker, aws,

Description

Part 2 of CoreOS on AWS with Ansible, part 1 discussed the CoreOS Cluster Setup. As I was writing this, it did dawn on me that the order I'm writing these in, is probably backwards. You would need the Security Group setup before the cluster could come up. Sorry, but on we go.

AWS Security Groups, are "kinda" like firewalls. Except they do not exist on the typical network boundary, they exist within the virtual layers of the network bridges between the host OS and the Virtual Machines running on it. Its what allows EC2 instances that reside on multiple networks and separate Availability Zones to exist within the same Security Group, and thus the same access privileges. Overall, it does make Security on AWS simpler to manage. Then VPC's came along with the ability to put firewall ACL's on your private subnets in addition to them, and things can get pretty harry, quickly, but maybe another time.

I will again be running everything in one file, and not with a separate rules directory as is typical of Ansible play books, for simplicity. The first part is pretty typical of an Ansible EC2 play.

---
  - name: Configure Security Groups for AWS Infrastructure
    hosts: localhost
    gather_facts: false
    vars:
      security_group: docker-sg01
      vpc_id: vpc-1111111
      vpc_region: us-east-1
      my_ip: 10.1.1.1/32  # My Home Public IP

I'm using a few variables here, basically the name of the security group, region and the VPC id. I also have a variable ...

Continue reading »


CoreOS on AWS with Ansible Part 1

Written by Mitch in Automation on Sat 02 January 2016. Tags: ansible, automation, coreos, docker, aws,

Description

I Promised I would do some follow-ups on "Infastructure as Code". This is a 2 part write up on the subject.

First a quick note or two about how I run Ansible with AWS. I don't include AWS keys in my playbooks EVER. I rely on my config of the AWS CLI which is under ~/.aws/config and ~/.aws/credentials. Look up how to get that configured and tested before preceding here.

On with some of the variables in the playbook. They should all be self explanatory, but obviously will need to be changed to match your environment. Namely the key_name, region, iam_role and the subnet_id. All need to match up with your environment.

---
  - name: Create CoreOS Cluster on aws
    hosts: localhost
    gather_facts: False
    vars:
      name: coreos-test-public # Yes 4 boxes named this. Why? because cattle!
      security_group: docker-sg01 # Name of Security Group to Add Instances to
      role: docker-coreos-cluster1 # Role Tag assigned to each instance
      key_name: default  # SSH Key name from AWS
      instance_type: t2.medium  # Instance Type
      region: us-east-1  # AWS Region
      image: ami-cbfdb2a1  # Stable CoreOS Image ID from time of writing
      iam_role: linux # Role from IAM Roles
      subnet_id: subnet-12345ef # Subnet ID from VPC
      count: 4  # Number of CoreOS instances
      ebs_optimized: false # Because t2.medium is not EBS optimized

All of these settings should be well known as options for creating an AWS instance. The ec2 module has two options that are not passed to AWS. First is the count variable I used for the modules exact_count option, and the accompanying ...

Continue reading »