Covers Google Cloud Platform and live demo of Ansible's Google Cloud (gc*) modules. Also a demo on how to wire up other Google Cloud services to create a Continuous Deployment architecture using ansible locally.
very small <-> VERY LARGE • Persistent Disks • SSD and "standard" • Up to 10TB per VM • Shared r/o across many VMs • Global snapshots • Advanced Networking • Global private network • Load-balancing (L3 and L7) • Custom routes / Firewall rules Google Compute Engine
(2 per zone) 2. Create a Firewall Rule and Load-Balancer 3. Set up a DNS record for the LB IP 4. Deploy "app" and manage software (in a non-typical way...) Region: us-central1 Target Pool (lb-tp) us-central1-a app1 app3 us-central1-b app2 app4 Forwarding Rules tcp:80 ➔ lb-tp GCP APIs $ ansible-playbook gce-demo.yml
APIs pub/sub instance tags CD with Ansible and Google Cloud Platform, 1. PTC Agent deployed via metadata during instance create 2. "App" development with git hosted in Google Cloud Repositories 3. Ansible configures the VM and "app" locally
and instance tag change events • On event, a "start" script in top-level of configuration tree executes ansible-playbook • Configuration - Pure Ansible • Role to deploy Apache, custom web page (our "app"), and a debugging script • Application "versions" deployed are based on instance tags (prod or canary) • Uses a local dynamic inventory script for classification by instance tags • Debugging • /cgi-bin/ptcd
instance tag and v1 deployed a. site.yml initially only specifies 'v1.yml' b. v1.yml targets machines with the prod tag (e.g. tag_apache:&tag_prod ) 2. We start the "canary" rollout verification using production traffic a. Select an instance and change its instance tags (prod -> canary) b. Enable both v1.yml and v2.yml (v2.yml targets tag_apache:&tag_canary ) c. Commit and push d. Verify that the canary instance is running v2 and others are still running v1 i. Revert? Yes, flip canary instance tags back to prod (no need to commit/push!) 3. Assuming we like this, proceed with remainder of rollout a. Comment out v1.yml in the site.yml b. Edit v2.yml and set the target to tag_apache:&tag_prod c. Commit and push
configured automatically (auto-scaling, PoG, etc) • Demo used instance metadata, but could use project-metadata • Scalable to very large sets of machines • Good prototype for adapting to your needs (git branches vs versions, environments, etc) • Cons • No all-up view of state of managed machines • Needs thought toward ACLs around update mechanism (who can git push / change tags) • Can be difficult to debug, no immediate feedback • Scopes can be challenging • Alternative: Ansible Tower! • All-up views • ACLs, audit history • Hands-free scheduled updates • Visualization
credit to launch your idea! Build. Store. Analyze. On the same infrastructure that powers Google Start building Go to g.co/cloudstarterpack Click ‘Apply Now’ and complete the application with promo code: ansible-con Starter Pack Offer Description 1 2 3
https://cloud.google.com/products/compute-engine • Ansible + Compute Engine: http://docs.ansible.com/guide_gce.html • ... and look for the new gc_dns module soon! [pull-request #110] Get Started on Google Cloud Platform • $500 credit, http://g.co/cloudstarterpack (use promo code: ansible-con) Questions? {'Freenode': 'erjohnso', 'GitHub': 'erjohnso', 'Twitter': 'no!'}