The Kubernetes/OpenShift Service Catalog and Open Service Broker API are creating a new way for users to provision and manage services on Kubernetes/OpenShift through a collection of Service Brokers. One of these brokers, the Ansible Service Broker, is focused on providing a mechanism for allowing applications defined with Ansible to be exposed to the Service Catalog. We call this application definition an Ansible Playbook Bundle (APB); a lightweight definition that is essentially a few Ansible playbooks named for each of the Open Service Broker API methods. The bundle is packaged as a container image with an Ansible runtime for distribution to be consumed by the Ansible Service Broker. In this talk we will introduce the concept of the Ansible Playbook Bundle and Ansible Service Broker. Additionally, we will walk through a few example and live demo demonstrating how to define and deploy multi-container applications.

1. 1
OpenShift DevOps
CICDPipelines
Nicholas Gerasimatos
Red Hat CCSP

2. OPEN SOURCE DRIVING THIS TRANSFORMATION
DEVOPS PRACTICES,
CULTURE, AND TOOLS
CLOUD PLATFORMS CLOUD LEADERS
USING DEVOPS
2

3. Source: 2014 State of DevOps Report
Puppet Labs, IT Revolution Press, ThoughtWorks
DEVOPS TO THE RESCUE!
3

4. WHAT
REALLY IS
DEVOPS?
4
WHY
SHOULD I
CARE?

5. 5

6. • Delivering new business applications and services
• Increased agility and quality
• Improved technology and collaboration
• From development through ongoing operations
DEVOPS IS AN I.T. PROCESS
6

7. DEVOPS + CLOUD = INDUSTRIALIZE
7

8. 8
The Keys to Devops. What We Learned, What We Know
• Standardize parts
• Drive modularity and reuse Standardize
process
• Automate repeatable processes
• Standardize infrastructure instrumentation and control
• Continuous iteration and improvement

9. SOME EARLY STANDARD PARTS
Système Gribeauval (1765)
Cannons
Standard bores
Eli Whitney (1801)
Muskets with interchangeable parts
Still costly and handmade
9

10. START WITH A CHOICE OF MANY STANDARD PARTS
Standardized
Open
Multi-vendor
Multi-platform
But these are just piece parts
10

11. COMMON PLATFORMS
11

12. MICROSERVICES ENABLE SOFTWARE COMPONENT REUSE
12

13. TYPICAL MICROSERVICES CHARACTERISTICS
• Single function, but can be any size
• Each microservice can be unique or part of other builds
• Can use unique languages, runtime, etc
• Sometimes stateless but can also be persistent
• Built to scale horizontal
13

14. BRINGING PROCESS TO STANDARDIZATION:
BRUNEL AND MAUDSLAY’S SAILING BLOCKS
“...So that ten men, by
the aid of this machinery,
can accomplish with
uniformity, celerity and
ease, what formerly
required the uncertain
labour of one hundred
and ten.”
14

15. TYPICAL DEVOPS WORKFLOW
15

16. AUTOMATION INCREASES PRODUCTIVITY
20

17. AUTOMATING APPLICATION
SCALING WITH PAAS
17

18. VALUE OF STANDARDIZED INFRASTRUCTURE
Process drives tools
Abstraction of
implementation
Simplification
Eliminates human
error
18

19. A CLOUD PLATFORM FOR MICROSERVICE CLOUD APPS
Provision appsfrom
service catalog
Orchestrate and placeapps
Runcomposed
microservices in containers
Provide dynamic,
Programmable infrastructure
OPS MANAGEMENT
SERVICE CATALOG
(RED HAT CLOUDFORMS)
19
CONTENT
ENTITLEMENT
LIFECYCLE
(RED HAT SATELLITE)
SERVICE SCHEDULER/ORCHESTRATOR
(KUBERNETES, MESOS)
OPENSHIFT
BYREDHAT
RED HAT ENTERPRISE
LINUX GUEST
RED HAT ENTERPRISE
LINUX GUEST
CloudForms
Monitoring
Docker
Image
CloudForms
Orchestration
Docker
Image
Satellite
Content
Docker
Image
JBoss
AMQ
Docker
Image
App
DB
Docker
Image
JBoss
BRMS
Docker
Image

20. YOU CAN’T CHANGE WHAT YOU CAN’T SEE
20

21. WHAT MIGHT YOU MONITOR? EVERYTHING!
21
Category Type of data
Capacity Storage capacity, network utilization, CPU utilization, number of VMs/
containers/servers
Performance Query time, page load time, upload/download speeds, I/O rates
Service health Service outages, service instance failures, timeouts
Compliance/security Intrusion detection, DoS/DDoS attempts, Authentication failures,
Password resets
Traffic flows HTTP(S) requests, end-to-end packet flows
User metrics Pageviews and time/page, registrations, clicks, abandons

22. TRADITIONAL MANUFACTURING
Any customer can have a car
painted any color that he wants so
long as it is black.
Henry Ford
(probably apocryphal)
General Motors Fairfax Assembly Plant in Kansas City, Missouri
22

23. DEMING CIRCLE / SHEWHART CYCLE
30
Plan
Do
Check
Adjust

24. A DIFFERENT APPROACH
Lean manufacturing
Kaizen (Japanese)
JIT
BTO
Systems thinking
(“The ToyotaWay”)
24

25. A FEW KEY POINTS
• Make process as flexible as necessary without
stress or since this generates waste
• Long-term philosophy but tactical improvements
also valuable
• Can’t directly attack outcomes without
understanding underlying concepts
• Significant organizational / incentives / culture /
elements
25

26. CICD PRINCIPLES
26
• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Test in a clone of the production environment
• Everyone can see what’s happening
• Automate all the things

27. AUTOMATING CONTINUOUS INTEGRATION
WITH MAVEN AND JENKINS
Code
28

28. USING JENKINS FOR CI/CD
• New build triggered on push to git repository
• No application downtime during the build process
• Failed builds do not get deployed (leaving the
previous working version in place)
• Can have different deployment stages (e.g. dev,
test, stage, production)
29

29. GARTNER DEVOPS METRICS PYRAMID
Data-DrivenDevOps:Use Metrics to Help GuideYour Journey
May2014
30

30. • Apply agile continuous improvement
• Ensure that each DevOps process implemented (such as test-
driven infrastructure, continuous delivery, etc.) maps to a
business impact
• Monitor for unintended side effects
• Foster a learning-centric approach to process improvement,
rather than to use these exercises as a means to punish missing
expectations
Summarized from
Data-Driven DevOps: Use Metrics to Help Guide Your Journey
May 2014
31
GARTNER DEVOPS RECOMMENDATIONS