Managing Infrastructure as Code

Allan Shone

Agenda• Look at some legacy concepts• Run through some ideas• Check out a few products• Put together some base requirements• Browse a few modern products• Throw in some more updated concepts• Dive into suitable products• Extra bits, concerns, and ideas

Back in the day...• Infrastructure was extremely manual• Hosts, meta details, and further information was

recorded in text files, or other plain text based systems

• Hostnames based on function• Documentation was fragmented• Legacy infrastructure becomes unmanageable

and can be forgotten• Nightmare to keep track of

Tools• Wiki / HTML Tables• Text Files

• Shared drives• Internal admin server• Shared FTP• Proprietary and specific software solutions• Shell scripts

Problems?• Keeping host lists up-to-date• Multiple users managing infrastructure• Recent status indicators• Cumbersome interfaces• Time consuming data interactions• What about software?

Ideas• Some sort of versioning• Easier interface for collaboration• Provision of host state• Start looking at automation

Bits and Pieces

• Databases• Services• Applications• Cache• Routers

Software?

• First, infrastructure requires orchestration• Then, software dependencies can be pushed within

each of those infrastructure items• Bare-metal is different with a separate set of

requirements• The premise for both though is still of value to the

general topic

Basic Provisioners

Ansible• Provides inheritance• Allows for variable configuration• Straight-forward to use with automation• Expressive with its syntax using YAML• Playbooks used for grouping of instructions• Playbooks versioned in a DIY fashion• Agentless model for deployment• Templating makes conf files a breeze

Simple Software# Playbook for Application- hosts: “{{hosts}}” remote_user: root sudo: yes

roles: - common - app-server

# Directory Structureroles/common/handlers/main.ymlroles/common/tasks/main.ymlroles/common/templates/ntpd.confroles/app-server/handlers/main.ymlroles/app-server/tasks/main.ymlroles/app-server/templates/apache.confroles/app-server/vars/example.yml

Provisioning Infrastructure- hosts: localhost connection: local gather_facts: false

tasks: - name: Provision instances ec2: key_name: my_key group: test instance_type: t2.micro image: “{{ami_id}}” count_tag: Name: Demo instance_tags: Name: Demo register: ec2

- name: Add Hosts to Host Group add_host: hostname={{ item.public_ip }} groups=ec2hosts with_items: ec2.instances - hosts: ec2hosts name: configuration play user: ec2-user gather_facts: true tasks: - name: Check NTP Service service: name=ntpd state=started

Drawbacks

• Difficult to track created instances• Supplier specific wrapper• Versioning is DIY• Basic in terms of complete solution

Chef

• Builds on Ruby for syntax• Fluent way of pushing modifications• Variable capabilities for ease of automation• Cookbooks used to group instructions• Cookbooks synchronised with the Chef Server• Server to client model

Simple Instances

num_instances = 10

1.upto(num_instances) do |inst|

machine "my-machine-#{inst}" do

add_machine_options bootstrap_options: {

security_group_ids: 'test-sg',

subnet_id: 'subnet-1234567',

instance_type: 't2.micro'

}

end

end

Resources

load_balancer "test-elb" do

machines [ "machine1", "machine2" ]

load_balancer_options :listeners => [{

:port => 80,

:protocol => :http,

:instance_port => 80,

:instance_protocol => :http,

}]

end

Drawbacks

• Dedicated server for management• Uses Ruby natively, which could be a positive if you

work with Ruby or don’t mind• What is required for some may not exist unless the

necessary Plugin is available for it• OS and Package restrictions for nodes

Puppet

• Simple syntax for configuration• Server model for deployments• Automation readily available• Parameterised configurations for easy environment

setup

Software

package { 'apache2': provider=>'apt', ensure=>'installed'} notify { 'Apache2 is installed.':} service { 'apache2': ensure=>'running'} notify { 'Apache2 is running.':}

ec2_securitygroup { 'sample-group': ensure => present, region => 'us-west-1', description => 'Group used for testing Puppet AWS module',}

ec2_instance { 'sample-instance': ensure => present, region => 'us-west-1', availability_zone => 'us-west-1a', image_id => 'ami-696e652c', instance_type => 't1.micro', security_groups => ['sample-group'],}

Resources

Resource - Finalising

ec2_loadbalancer { 'sample-load-balancer': ensure => present, region => 'us-west-1', availability_zones => ['us-west-1a', 'us-west-1b'], instances => ['sample-instance', 'another-instance'], security_groups => ['sample-group'], listeners => [{ protocol => 'tcp', port => 80, }], }

Drawbacks

• Requires learning the Puppet specific language for the actual infrastructure code

• Complex infrastructure can become quite cumbersome to manage

• Dependency based, order of execution can be tricky to control when it is required to be

What about hosts?

CloudFormation

• Complete “physical” infrastructure as code• Basic JSON file for definition• Services for usage easily interacted with• Tightly coupled with AWS• Versioned and stored within the console• Ease of automation

Beginning{

"AWSTemplateFormatVersion": "2016-01-01","Description": "My Template","Parameters": {

"KeyName": {"Description": "EC2 KeyPair","Type": "AWS::EC2::KeyPair::KeyName","ConstraintDescription": "must be the name of an existing EC2 KeyPair."

}}

}

Resources - Security Group"Resources": {

"WebServerSecurityGroup": {"Type": "AWS::EC2::SecurityGroup","Properties": {

"GroupDescription": "Minimal Access","SecurityGroupIngress": [{

"IpProtocol": "tcp","FromPort": "80","ToPort": "80","CidrIp": "0.0.0.0/0"

}]}

}}

Resources - Instance

"Resources": {"WebServer": {

"Type": "AWS::EC2::Instance","Metadata": {

"AWS::CloudFormation::Init": {"install": {

"packages": {"yum": {

"httpd": []}

}}

}}

Tying it together

"Outputs": {"WebsiteURL": {

"Value": {"Fn::Join": ["", [

"http://",{

"Fn::GetAtt": ["WebServer","PublicDnsName"

]},"/ping"

]]},"Description": "Website"

}}

Drawbacks

• AWS specific• JSON for the configuration can be difficult to create

and maintain - No comments• Not idempotent• Templates are very large and can become quite

cumbersome to follow• Most functionality can be automated through the

command line interface within other tools

Infrastructure pieces

• Software management, host management, resources• A general tool provides one but not the other• Arbitrary scripts can shoehorn this• Duplication and Inconsistencies would become

problematic with keeping data sets in different tools

Combinations

• Software dependencies managed• Hosts instantiated or made available on demand• Configurations completed between environments to

allow for sand-boxed communication• Entire infrastructures brought up with a single

command as replica of production

TerraForm

• Will orchestrate and provision• Syntax is easy to grasp and maintain• Configurations can be quite simple• Parameterised capabilities for ease of scripting with

environments

Softwareresource "aws_instance" "web" { connection { user = "ubuntu" } instance_type = "m1.small" ami = "${lookup(var.aws_amis, var.aws_region)}" key_name = "${aws_key_pair.auth.id}" vpc_security_group_ids = ["${aws_security_group.default.id}"] subnet_id = "${aws_subnet.default.id}" provisioner "remote-exec" { inline = [ "sudo apt-get -y update", "sudo apt-get -y install nginx", "sudo service nginx start" ] }}

Resourcesresource "aws_elb" "web" { name = "terraform-example-elb" subnets = ["${aws_subnet.default.id}"] security_groups = ["${aws_security_group.elb.id}"] instances = ["${aws_instance.web.id}"] listener { instance_port = 80 instance_protocol = "http" lb_port = 80 lb_protocol = "http" }}resource "aws_key_pair" "auth" { key_name = "${var.key_name}" public_key = "${file(var.public_key_path)}"}

Drawbacks

• Tightly integrated with vendors• Learning curve for syntax• Delays with updated services and functionality• Newcomer to the fully managed tool suite, some

features are incomplete or in progress

ManageaCloud

• Complete solution, orchestration and provisioning• Simple, re-usable configuration• Built-in versioning for deployments and infrastructure• Open choice of vendor - no requirements• Framework approach for infrastructure management

Macfile

• Configuration template• Complete infrastructure specification• Versioned to allow for ease of use, deployment, and

rollback• Simple syntax no vendor specifics

App Instance

roles: demo_app: instance create: configuration: demo_application

infrastructures: demo_application_instance: name: demo provider: amazon location: us-east-1 hardware: t1.micro role: demo_app environment: - APP_BRANCH: master

Resource

resources: elastic_load_balancer: create bash: aws elb create-load-balancer --load-balancer-name infrastructure.param.name --listeners infrastructure.param.listeners --availability-zones infrastructure.param.availability-zones --region infrastructure.param.region destroy bash: aws elb delete-load-balancer --load-balancer-name infrastructure.param.name --region infrastructure.param.region

Resource Instance

infrastructures: load balancer 01: resource: elastic_load_balancer params: name: my-demo-load-balancer listeners: Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80 availability-zones: us-east-1b us-east-1c region: us-east-1

Associationactions: get_id: ssh: wget -q -O - http://169.254.169.254/latest/meta-data/instance-idregister_lb: create bash: aws elb register-instances-with-load-balancer --load-balancer-name infrastructure.param.load-balancer-name --instances infrastructure.param.instances --region infrastructure.param.regioninfrastructures: register_instance: ready: role.demo_app resource: register_lb params: load-balancer-name: my-demo-load-balancer instances: role.demo_app.get_id

Drawbacks

• Most components are open source, not all at the present time

• No unified syntax for providers

What about people?

DevOps

• Largely, DevOps came about as a hybrid role to help manage and facilitate process change

• Automation is a key aspect• Not Operations, but not Development either (but is

still both)• Provide an interface between infrastructure and

environments and deployments made

Concepts

• Even with automation, humans are still needed• Sanity checking and improving tools• Removing bottlenecks• Increasing developer and wider business productivity• Know the management tools and the details of how

the infrastructure functions

Workflows

• Very important to focus on processes• Tools are wonderful, but processes need to be suitable

for the tool of choice• Automation will bring down the Op aspects of DevOps• Cross functional efforts to bring the automation to the

infrastructure• Size of infrastructure

Infrastructure as Code

Decisions

• Situations make decisions difficult• Complete solutions are not always necessary• Preference and team knowledge makes a difference• A product is not specifically good just because others

use it

Options

• There’s always more options available than time to discuss - CFengine, Salt, Heat, OneOps

• It’s all about automation, and removing bottlenecks in cumbersome processes

Future

• Abilities to share, extend, and work better with infrastructures

• Inheritance for roles, resources, and instances• Complete control with automation of infrastructure

sets• Simple options for deployment strategies

Thank you!

Allan Shone

https://manageacloud.com