DevOps Foundations : Infrastructure as Code

Transcription

1 DevOps Foundations : Infrastructure as Code Ernest Mueller, James Wickett DevOps Fundamentals 1 1. Infrasturcture automation 2. Continuous Delivery 3. Reliability Engineering Infrastructure as Code There are two common approaches to configuration management code. Imperative and declarative. Imperative, procedural commands to produce a desired state are defined and executed. You're creating a list of things to do,and the system does them Your average Bash script is imperative. declarative, functional. define the desired state, and the tool conforms the system to the model of your desired state. You don't describe the control flow of exactly what to do, you specify what you want done and the tool does it. Declarative is more efficient, assuming the declarative framework supports exactly what you want it to do

2 Chef, Puppet manifests, SQL queries and makefiles... Like application code, you want to have tests for your infrastructure code and for your infrastructure. Artifacts Code usually gets compiled, parsed, or even just bundled up into what we call artifacts. Artifacts are what get versioned, tested, and deployed. Consider what artifacts you intend to use as the deliverables in your infrastructure code pipeline. For app code, it's usually executable binaries or JARs or similar. For infrastructure, you usually see DEBs, RPMs, or other OS packages. Docker images, AMIs, VM images, and stuff like that.you may have multiple layers of artifacts. Java WAR files that then get built into RPMs and then get built into VM images, for example. build OS packages, scripts, Java into DEBs or Debian packages so that we can leverage that format's built in dependency management. Then as a second layer, we build VM images and AMIs using Packer, and build Docker images directly with docker files. All this is controlled through our last seen Bamboo build system. We then use Artifactory as our artifact repository for both infrastructure and application artifacts so that our provisioning and deployment can leverage that single-source of truth. We can't stress enough the importance of creating and managing artifacts. After they're built, they never get changed, and as they're deployed from tier to tier, they're provably identical.don't just pull code out of Git, use artifacts. But how do you know these artifacts are any good? Testing. 2

3 Testing your Infrastructure UT Code level, smallest, formaters and linters IT several components together Security positive and neg sec attributes Unit Testing Infrastructure Formatter Style check, shop std Java use IDE s ie Eclipse or IntelliJ or Netbeans Linter Enforces rules specific to languages Chef Foodcritic w/61 rules Java use IDE s ie Eclipse or IntelliJ or Netbeans Std UT testing - declaring what you expect a function to do under a variety of scenarios, then validate that behavior Chef ChefSpec Infrastructure testing Java junit and other tools automatically run through Jenkins - Selenium, Cucumber, Mockio Artifacts to Running systems Provisioning The process of making a server ready for operation including H/W, OS, system services, and network connectivity. Deployment Process of auto deploying and upgrading applications on a svr Orchestration Performing coordinated ops across multiple systems 3

4 Configuration Management (CM) After initial provisioning Upgrading Cloud Computing AWS Software as a Service (SaaS) TurboTax, Salesforce, Office 365 Platform as a Service (PaaS) Azure, Cloud Foundry Infrastructure as a Service (IaaS) AWS EC2 Hardware, VMs and Private Cloud AWS, etc Containers with Docker Isolation Docker Hub, public images Layers Docker compose multiple containers like Vagrant Serverless with Lambda Functions as deploy units Scaling by provider Pay per compute No management updates Ops model is hard to keep up with Model-driven provisioning overview The idea is pretty simple, you provide a declarative model of what you want your system to look like, all the networks, nodes, databases and so on, like a Blueprint, and then it gets created for you programmatically. This beats the old model of, make a visio diagram, try to build systems that vaguely resemble it, make more visio diagrams that vaguely resemble what you actually came out with, repeat until insanity sets in. 4

5 Provisioning with CloudFormation 5 Instantiate system with design YAML See ec2.yml file in this folder Ec2.yml file # These parameters are set in an external file Parameters: InstanceType: Description: "Instance type to use" Type: "String" Default: t2.micro AllowedValues: - t2.micro - m1.small - m1.large Description: Enter t2.micro, m1.small, or m1.large. Default is t2.micro. KeyName: Description: "Name of an existing ssh keypair to use to access the instance" Type: "String" # You can create lookups Mappings: RegionMap: us-east-1: AMI: "ami-e13739f6" us-west-2: AMI: "ami-b7a114d7" # A single EC2 instance Resources: Ec2Instance: Type: "AWS::EC2::Instance" Properties: InstanceType: Ref: "InstanceType" KeyName: Ref: "KeyName" SecurityGroups: - Ref: "InstanceSecurityGroup" ImageId:!FindInMap [ RegionMap,!Ref "AWS::Region", AMI ] # User-data will execute commands on boot using cloud-init UserData: Fn::Base64: Fn::Join: - "" - - "#!/bin/bash -ex" - "apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62" - "echo \"deb xenial nginx\" >> /etc/apt/sources.list" - "echo \"deb-src xenial nginx\" >> /etc/apt/sources.list " - "apt-get update" - "apt-get install -y nginx" - "service nginx start" # Create a security group for this instance that allows SSH and port 80 InstanceSecurityGroup:

6 Type: "AWS::EC2::SecurityGroup" Properties: GroupDescription: "Open up SSH and HTTP to everyone on the Internet" SecurityGroupIngress: - IpProtocol: "tcp" FromPort: "22" ToPort: "22" CidrIp: " /0" - IpProtocol: "tcp" FromPort: "80" ToPort: "80" CidrIp: " /0" Outputs: PublicIP: Description: "The instance's public IP address" Value:!GetAtt Ec2Instance.PublicIp Parameter file Split out ssh key and instance size One template and multiple files with dev and production files [ { "ParameterKey": "KeyName", "ParameterValue": "infra-auto" }, { "ParameterKey": "InstanceType", "ParameterValue": "t2.micro" } ] CLI AWS you can validate template command File is the CLI commands to run Ch_deploy.sh #!/usr/bin/env bash export AWS_REGION=us-east-1 aws --region $AWS_REGION cloudformation validate-template --template-body file://./ec2.yml aws --region $AWS_REGION cloudformation create-stack --stack-name myec2demo -- parameters file://./ec2-parameters.yml --template-body file://./ec2.yml AWS GUI CloudFormation tab you can see it s created. 6

7 Stack is now running 7

8 On the Desktop with Vagrant Virtualization consistent between dev and prod environments open source, multi-platform development tool. Vagrant allows us to emulate our production environment right on a laptop. You can churn out virtual machines using an API-driven approach just like you would in production. This means your provisioning scripts or Chef recipes behave the same on both your laptop and the cloud. Vagrant works with multiple virtual machines at a time, which means you can build your whole stack using it. Since Vagrant is driven through the use of a plain text file known as a Vagrantfile, it's easy to store in version control. To run Vagrant, you need two things: Vagrant and a virtual machine host.you can get Virtual machine hosts include Oracle Virtualbox, VMware, and even Amazon Web Services. Win bash or git bash to start it cat Vagrantfile bootstrap.sh #!/usr/bin/env bash # Use single quotes instead of double quotes to make it work with special-character passwords PASSWORD=' ' # update / upgrade sudo apt-get update sudo apt-get -y upgrade # install apache 2.5 and php 5.5 sudo apt-get install -y apache2 sudo apt-get install -y php5 # setup hosts file VHOST=$(cat <<EOF <VirtualHost *:80> DocumentRoot "/var/www/html/class" <Directory "/var/www/html/class"> AllowOverride All Require all granted </Directory> </VirtualHost> EOF ) echo "${VHOST}" > /etc/apache2/sites-available/000-default.conf # enable mod_rewrite sudo a2enmod rewrite # restart apache service apache2 restart 8

9 Convergent Provisioning 9 Chef Configuration Management tool idempotent code same if run over and over handle orchestration by tracking state in a master registry Chef Compents Run-list Roles Recipes Immutable deployment with Docker Dockerfile Ubuntu nginx web server expose port 80 test by curling local host port 80 Docker Hub, push to Docker Hub public registry so other people can use this image Docker Hub public or private Artifactory for private registry Amazon Elastic Container repository EC2 container registry Repositories Create your own repository within a docker registry dedicated to your AWS account Gives you commands you need to push to it Docker has bridged the gap between the world of development artifacts and the world of operational artifacts. With Docker you can do the same thing, with the large part of your systems. Instead of logging in and changing them manually, or using a Convergent CM system like Chef or Puppet to change them. You simply destroy and recreate them like in an app environment. You build the new version, you push it out and you're done. Since each container is self-contained you don't have problems with conflicting versions of system libraries, or the other sorts of conflicts that you get when you run multiple apps on one system. Apps are built and tested in the OS and library versions that are right for them. Change control becomes simple. And can be tied directly to your CI system. Many security and compliance issues are effectively bypassed. There's little reason to even login to servers in this model. At my current job, one of our products has been designedentirely from Docker based microservices and AWS cloud infrastructure. There aren't changes made in production ever, except for deployments from our CI system. If we need to change configuration, we change it in source control. A build automatically runs, runs unit tests, deploys it to a CI system. Runs automated integration tests, and if it passes, deploys to production less than five minutes later. We perform larger scope changes, via CloudFormation templates. Also updated out of our build system. Some folks like Netflix use the immutable model at the cloud image level. By building AMIs and having that be their unit of deployment. This is effective for very large scale shops but it's perhaps not granular enough for a smaller scale apps. Like with Vagrant you build and run entire topologies both on your desktop and in production.

10 Docker compose To do this, we use Docker compose Here's an example of a Docker compose file docker-compose.yml version: '2' services: ubuntu-nginx: build:./ubuntu-nginx ports: - "80:80" depends_on: - elasticsearch - postgres - consul elasticsearch: build:./elasticsearch command: elasticsearch -Des.node.name=ernest -Des.cluster.name=ernest - Des.index.number_of_shards=1 -Des.index.number_of_replicas=0 - Des.index.refresh_interval='1s' -Des.index.merge.scheduler.max_thread_count=1 - Des.threadpool.bulk.queue_size='-1' -Des.bootstrap.mlockall='true' - Des.node.master='true' -Des.discovery.zen.ping.multicast.enabled - Des.script.inline='on' -Des.script.indexed='on' -Des.http.cors.enabled='false' - Des.discovery.zen.minimum_master_nodes=1 -Des.discovery.zen.ping.unicast.hosts=ubuntunginx ports: - "9200:9200" - "9300:9300" depends_on: - consul postgres: build:./postgres environment: - POSTGRES_USER=test - POSTGRES_PASSWORD=test volumes: -./postgres/data:/var/lib/postgresql/data:rw depends_on: - consul consul: image: consul:latest ports: - "8500" describes several containers that run and connect together. I've created a mock composite app here, that uses our ubuntu-nginx web server that we just built. An elasticsearch node. A postgres node. a consul node, So we were in this directory just with a Docker file. One layer above that, I have a directory with the Docker compose file that I just showed you, and sub directories for elasticsearch, postgres and our ubuntu-nginx containing the Docker files for those containers. 10

11 So to build and run locally this entire composite application, I just have to run Docker compose up. In the Docker compose file you saw that depends on syntax, that essentially causes compose to hook the services up together and create the required network topology. So with Docker compose you have a choice, you can still do for example, a Docker PS and see all of the individual containers. But you can also, use those same sets of commands, through Docker compose, and it will show you things, kind of grouped into compose. I could add in another container, that runs server spec tests against the other containersto ensure my stack's working right. Make a change to the compose file or to the individual Docker files. Rebuild and restart that part of the system with a new container. The resulting system is dynamic, but each piece is immutable, in that it's not changed after it's built. In production, you can do the same thing. You can use Docker swarm, which actually uses the compose file and instantiates it across a swarm of servers instead of having a batch of containers on one server. 11