Developer's introduction to the eGlobalTech Cloud Automation Platform, a multi-cloud DevOPS orchestration tool for one-click complex deployments

1. 1Global Tech, Inc. 1
eCAP – EGlobaltech Cloud Automation Platform
Developer’s Walkthrough
Delivering Value, Achieving Results
© 2015 eGlobalTech. All rights reserved.

2. Table of Contents
• Overview
• Architecture
• First steps – a simple “Basket of Kittens”
• Deployment and Cleanup
• A more advanced “Basket of Kittens”

3. eCAP Overview
eCAP is a complete cloud deployment solution to
• Provision, orchestrate and manage complex
platforms and applications.
• Automate any arbitrarily complex application,
platform or combination on a wide range of
infrastructure targets
This presentation briefly covers core eCAP
architecture, utilities, capabilities, and usage for
platform and application developers
A brief business presentation is available:
• Remote Presentation
• Local File

4. eCAP Architecture by Layers
eCAP Interface:
• Available from nearly any
interface
• Most often accessed via Jenkins
or command line
• This developer presentation
focuses on command line access
eCAP Services:
• Utilities provide entry point
• Services provide orchestration,
monitoring, management
• Libraries called by both
• Four key areas of library
capability

5. Abstracted eCAP Services (1)
Provisioning Service
Configuration Service
Provisioning
abstraction currently
addresses the AWS
API
Future versions will
address Azure,
Google, OpenStack
Configuration
abstraction currently
addresses Chef
Future versions
possible for puppet,
ansible, salt…

6. Non-Abstracted eCAP Services (2)
Management Service
Orchestration Service
• Currently uses Nagios to provide continuous
monitoring
• Manages Nagios access from Master and agents
per node
Orchestration is a native ability of eCAP
• Momma-cat processes interact with deployed
artifacts through their lifecycle
• Including initial configuration
• Including scaling events

7. eCAP Architecture by Components
•Can support a CentOS or RedHat linux instance.
•Network connections to the target infrastructure
•Typically single eCAP Master in AWS VPC
Environment
•Build via install/setup_master.sh script on CentOS
•Deploys within the scope of the master server’s account.
eCAP Masters and Master VPCs
•Target deployments are managed by the deploying eCAP Master
•Extend master scope to multiple amazon accounts by cross-account role delegation
•Deploy to target AWS VPC (virtual private clouds) to better control access and security
•Communicate across VPC boundaries by means of VPC peering
•Can provision, configure and orchestrate wide range of artifacts in target VPCs
•Instances, instance pools, load balancers, databases, DNS records, security groups, and
virtually any resource the target environment supports by API
Target VPCs and Nodes

8. eCAP Deployment Patterns
Deployer accesses their eCAP server, in this case by means of a
Jenkins interface
Deployer issues a “cap-deploy …” command which references
a deployment descriptor file.
Deployment descriptor is called a “Basket of Kittens” or BOK,
named for the related artifacts it deploys.
BOK is maintained in a deployment source control repository,
typically Git.
eCAP master manages the relationship with the Git repository
through its utilities.
Deploy command creates a target VPC, provisions all
necessary artifacts including instances, server pools, machine
images, security groups, load balancers, etc.
Artifacts “call home” to an eCAP “Momma-Cat” service which
configures and orchestrates each artifact. The configuration
and orchestration is called “grooming”.
Artifacts continue to communicate with “Momma
Cat” for updates and notifications.

9. Deployment Descriptor Basics
“Basket of Kittens” or BOK declares:
– All components of a deployment
– Interrelationships and dependencies
– Encrypted credential locations.
• Expressed in JSON/YAML enhanced with ERUBIS
• ERUBIS allows for modular development and
invocation
• All but simplest BOKs involve a master BOK and
child BOKs, typically one BOK per class of service.

10. Deployment Descriptor Classes
• BOK Classes represent infrastructure artifacts to be
orchestrated
• Online documentation is available from any eCAP server
• Some top level classes:
– admins
– databases (RDS)
– servers (EC2)
– pools (autoscale groups)
– DNS records
– load balancers
– firewall (security groups)

11. A Very Simple BOK
1. Every BOK requires an appname, which drives all notifications, tags and other identifiers
2. Server array is often included rather than specified. Multiple classes of server can be specified
3. Here’s an illustration of an ERUBIS include defining a common AWS AMI
4. An optional stanza to create and attach a volume to the server.
5. Configuration information in the form of a Chef runlist. The recipes and roles in the runlist will be applied to
the server class to configure it by momma-cat.
6. Size of the instance, a valid AMI size
7. Some firewall rules for the server. Usually specified in a firewall-rules stanza instead

12. Simple BOK Deployment
Simple deploy without parameters:
Extensive log display:
• Each artifact is provisioned then configured for security
hardening and basic eCAP capabilities.
• Nodes “phone home” to momma-cat, who configures the
artifact in its final form, logging to the momma-cat log.

13. Administrative Access
• Access via ssh or
RDP
• Credentials created
by deploy, kept on
master
• Find node in
deploy result
• Access directly
from eCAP master
• Note address for
application access
as well
Find your node, then…

14. Deployment Cleanup
• Deployment creates many artifacts
– Firewall rules
– Nodes
– load balancers
– security roles, keys, etc.
– All artifacts are tagged, but removing them by hand
would be tedious and error prone.
• All deploy artifacts are tagged with a base
designation,
• Individual elements expand off the base.
• Complete teardown in a single command

15. A MORE ADVANCED “BASKET OF KITTENS”
• Creates a virtual private cloud in Amazon AWS
• Creates a bastion host to access private subnets
• Creates a load balancer
• Securely provides credentials
• Configures firewall rules and interconnection
• Creates an autoscale group and instance

16. Platform Repositories
Use a separate platform repository for
deployment code
• Applications folder contains deployment
descriptors and related artifacts
• Cookbooks folder contains third party
cookbooks required by the deployment
• Roles folder contains the chef roles used
in the deployment
• Site_cookbooks folder contains optional
additional deployment-specific
cookbooks

17. BOK Repository Structure
1. Overall platform
deployment repository
2. The applications folder,
containing BOKs for all
deployments in the
repository
3. A specific deployment of
interest, in this case
GeoShape.
4. Various included BOKs
that apply to more than
one deployment

18. Top Level
(master.json)
master BOKs shows the
overall structure of a
deployment, leaving details
to child BOKs.
 Require parameters and
abort or warn in their
absence
 Declare global variables
for use in child BOKs
 Required identifiers and
admins
 Optional and mandatory
parameters
 “Includes” for child BOKs

19. Example of BOK Programming
A previous ERUBIS call dynamically retrieved all Availability Zones, then:

20. Configuring Pools of Servers
Pool defines a group of
scaling servers
Basis provides key parameters
for the servers in the pool
themselves, including the
AMI, credentials, volumes,
etc.

21. Final: Look at Credential Exchange
• Credentials
offered in
BOK:
• Credentials
Retrieved in
Recipe: