© 2015 IBM Corporation
IBM DataPower Gateways
devOps with UrbanCode Deploy
March 2016
DataPower devOps
Operational Context
▪Role-Base Access Control
▪Auditing
▪who, what, where, when
Common Activities
▪Quiesce traffic to the appliance
▪Deploy new firmware
▪Create an application domain
▪Deploy a new version of an application
domain with environment-specific
parameters
▪Rollback to a previous version
▪Quiesce traffic to an application domain
2
Manual Approach
3
Manual Approach
o Pros
 Uses built-in DataPower features
 All activities within the context of DataPower’s Role Based Management
framework
o Cons
➢ Least scalable
➢ Least consistent/repeatable
o Human Error is very likely
o DataPower is completely alien to most Operations teams
o Configurations in each domain become inconsistent, over time
4
“Role-Your-Own Automation” Approach
o Pros
 Use one of DataPower’s management interfaces
 XML Management Interface, REST Management Interface, Command Line
Interface
 All DataPower changes performed within the context of DataPower’s Role
Based Management framework
o Cons
 Automation via scripting (e.g. Shell Script, Jython, PERL, etc)
 Inconsistent approaches to scripting; incomplete devOps features
 Relies on a few “heroes” that know how the scripts are written, what they do.
 Expensive to build & maintain
 Not consistent with tools/how Ops teams deploy everything else; requires
developers to be close-by
 Not fault tolerant 5
Automated with UrbanCode Deploy
6
Automation with UrbanCode Deploy
o Pros
 Full application domain and firmware life-cycle management.
 Integration with 3rd party Source Code Control Repositories
 Functions executed within context of DataPower’s Role Based Management
framework
 Easily understood and adopted by Operations teams
 Fault tolerant - can roll-back to earlier version if necessary
 Most cost-effective approach (buy a world-class capability, versus attempting to build
the capability)
 UrbanCode Deploy usage can be expanded to automate devOps for many other
parts of your environment
o Cons
o ???
7
IBM UrbanCode Deploy – Deployment Automation
Deployment of Applications through
Environments
 Rapidly deliver to multiple environments for testing
 Visibility into deployment status via dashboards
 Easily roll back applications due to errors or
changes
 Compliance via audit trails and security
 Integrated with existing investments (middleware,
database, source control, configuration
management, change management, etc.)
Versioned
Artifacts
QA
Environment
Production
Environment
Development
Environment
Artifacts Artifacts Artifacts
Execute Against Execute Against Execute Against
Deploy or
Rollback
Deploy or
Rollback
Deploy or
Rollback
Application Blueprint
8
DataPower UrbanCode Deploy Plugin
o Available for downloaded from the developerWorks UrbanCode
plugins site:
‒ https://developer.ibm.com/urbancode/plugins/ibm-urbancode-deploy/
o The plugin utilizes the DataPower Configuration Management (DCM)
tool as the basis for plugin functionality. Ant is included and is used to
drive the automation and is included in the plugin
o The DCM tool connects remotely to a DataPower instance and
executes the steps via that connection. Therefore, any UCD agent
that has network connectivity to the DataPower nodes can be used.
‒ Note: Since the plugin utilizes Ant, a JDK must be used as the basis of the
agent instead of a JRE.
9
DataPower UrbanCode Deploy Plugin
o The available DataPower plugin steps:
‒ Backup Device
‒ Backup Domains
‒ Checkpoint Delete
‒ Checkpoint Restore
‒ Checkpoint Save
‒ Create Domain
‒ Crypto Identity Credential from Definition
‒ Crypto Validation Credential from Definition
‒ Delete Domain
‒ Host Alias Remove
‒ Host Alias Set
‒ Import (Basic)
‒ Import (Definition)
‒ Import (Deployment Policy Object)
10
– Invoke any deploy.ant.xml
target
– Load Balancer Group from
Definition
– Quiesce Domain
– Restart Domain
– Restore Backup
– Save Configuration
– Set Log Level
– Unquiesce Domain
– Upload Directory
– Upload from Definition
DataPower UrbanCode Deploy Plugin
o Every plugin step contains the same 5 hidden properties that capture
the connection information
o The values should be captured in resource and/or environment
properties
o Target Environment property specifies the properties to use from the
configuration file (see next slide)
11
DataPower UrbanCode Deploy Plugin
o DCM takes a properties file to override values that are environment
specific. Many plugin steps accept the properties file as input.
o Various ways to address these environment specific property values:
‒ Config files (see below)
‒ Store them in UCD and generate the file
12
<dcm:definition xmlns:dcm="urn:datapower:configuration:manager">
<dcm:loadbalancergroup environment="dev" name="ucdDemo‐backends"> 
<dcm:member server="192.168.13.89" port="443" enabled="true"/>
</dcm:loadbalancergroup>
<dcm:loadbalancergroup environment=“test" name="ucdDemo‐backends">
<dcm:member server="192.168.13.81" port="443" enabled="true"/> 
</dcm:loadbalancergroup> 
</dcm:definition>
IBM Datapower Gateways - Devops with UrbanCode Deploy

IBM Datapower Gateways - Devops with UrbanCode Deploy

  • 1.
    © 2015 IBMCorporation IBM DataPower Gateways devOps with UrbanCode Deploy March 2016
  • 2.
    DataPower devOps Operational Context ▪Role-BaseAccess Control ▪Auditing ▪who, what, where, when Common Activities ▪Quiesce traffic to the appliance ▪Deploy new firmware ▪Create an application domain ▪Deploy a new version of an application domain with environment-specific parameters ▪Rollback to a previous version ▪Quiesce traffic to an application domain 2
  • 3.
  • 4.
    Manual Approach o Pros Uses built-in DataPower features  All activities within the context of DataPower’s Role Based Management framework o Cons ➢ Least scalable ➢ Least consistent/repeatable o Human Error is very likely o DataPower is completely alien to most Operations teams o Configurations in each domain become inconsistent, over time 4
  • 5.
    “Role-Your-Own Automation” Approach oPros  Use one of DataPower’s management interfaces  XML Management Interface, REST Management Interface, Command Line Interface  All DataPower changes performed within the context of DataPower’s Role Based Management framework o Cons  Automation via scripting (e.g. Shell Script, Jython, PERL, etc)  Inconsistent approaches to scripting; incomplete devOps features  Relies on a few “heroes” that know how the scripts are written, what they do.  Expensive to build & maintain  Not consistent with tools/how Ops teams deploy everything else; requires developers to be close-by  Not fault tolerant 5
  • 6.
  • 7.
    Automation with UrbanCodeDeploy o Pros  Full application domain and firmware life-cycle management.  Integration with 3rd party Source Code Control Repositories  Functions executed within context of DataPower’s Role Based Management framework  Easily understood and adopted by Operations teams  Fault tolerant - can roll-back to earlier version if necessary  Most cost-effective approach (buy a world-class capability, versus attempting to build the capability)  UrbanCode Deploy usage can be expanded to automate devOps for many other parts of your environment o Cons o ??? 7
  • 8.
    IBM UrbanCode Deploy– Deployment Automation Deployment of Applications through Environments  Rapidly deliver to multiple environments for testing  Visibility into deployment status via dashboards  Easily roll back applications due to errors or changes  Compliance via audit trails and security  Integrated with existing investments (middleware, database, source control, configuration management, change management, etc.) Versioned Artifacts QA Environment Production Environment Development Environment Artifacts Artifacts Artifacts Execute Against Execute Against Execute Against Deploy or Rollback Deploy or Rollback Deploy or Rollback Application Blueprint 8
  • 9.
    DataPower UrbanCode DeployPlugin o Available for downloaded from the developerWorks UrbanCode plugins site: ‒ https://developer.ibm.com/urbancode/plugins/ibm-urbancode-deploy/ o The plugin utilizes the DataPower Configuration Management (DCM) tool as the basis for plugin functionality. Ant is included and is used to drive the automation and is included in the plugin o The DCM tool connects remotely to a DataPower instance and executes the steps via that connection. Therefore, any UCD agent that has network connectivity to the DataPower nodes can be used. ‒ Note: Since the plugin utilizes Ant, a JDK must be used as the basis of the agent instead of a JRE. 9
  • 10.
    DataPower UrbanCode DeployPlugin o The available DataPower plugin steps: ‒ Backup Device ‒ Backup Domains ‒ Checkpoint Delete ‒ Checkpoint Restore ‒ Checkpoint Save ‒ Create Domain ‒ Crypto Identity Credential from Definition ‒ Crypto Validation Credential from Definition ‒ Delete Domain ‒ Host Alias Remove ‒ Host Alias Set ‒ Import (Basic) ‒ Import (Definition) ‒ Import (Deployment Policy Object) 10 – Invoke any deploy.ant.xml target – Load Balancer Group from Definition – Quiesce Domain – Restart Domain – Restore Backup – Save Configuration – Set Log Level – Unquiesce Domain – Upload Directory – Upload from Definition
  • 11.
    DataPower UrbanCode DeployPlugin o Every plugin step contains the same 5 hidden properties that capture the connection information o The values should be captured in resource and/or environment properties o Target Environment property specifies the properties to use from the configuration file (see next slide) 11
  • 12.
    DataPower UrbanCode DeployPlugin o DCM takes a properties file to override values that are environment specific. Many plugin steps accept the properties file as input. o Various ways to address these environment specific property values: ‒ Config files (see below) ‒ Store them in UCD and generate the file 12 <dcm:definition xmlns:dcm="urn:datapower:configuration:manager"> <dcm:loadbalancergroup environment="dev" name="ucdDemo‐backends">  <dcm:member server="192.168.13.89" port="443" enabled="true"/> </dcm:loadbalancergroup> <dcm:loadbalancergroup environment=“test" name="ucdDemo‐backends"> <dcm:member server="192.168.13.81" port="443" enabled="true"/>  </dcm:loadbalancergroup>  </dcm:definition>