Application Onboarding Workshop: Red Hat OpenShift

Application Onboarding
Workshop
Red Hat OpenShift
Yohanes
MW Consultant
Application Migration and
Modernization
What is Application Migration?
Definition
Major technical upgrade of an application landscape,

its runtime environments and life cycles
without business functional change.
Different vendor
and / or AS - IS Migration TO - BE
major version
RED HAT CONSULTING

What is Application Modernization?
Definition
Integration & extension of new functionality by replatforming,

rehosting, recoding,rearchitecting,reengineering,
interoperability, replacement & retirement
BPMN, Business Rules,

COBOL, proprietary
CI/CD
Scheduled deployments
Real time,messaging
Batch, file based AS - IS Modernization TO - BE Containerization
Virtualization
Mobile first
Mode 1 waterfall
Mode 2 agile
http://www.gartner.com/it-glossary/application-modernization-services
RED HAT CONSULTING

App Migration & Modernization Benefits
Productivity to develop, deploy and operate
● Simplify and streamline application environments

○ Reduce operational complexity
○ High degree of automation
○ Infrastructure to support better process, not get in the way
● Enable business agility, align IT and business
○ Boost developer productivity
○ Cloud / DevOps / PaaS readiness
New apps and features faster, focus creative

energies on innovations that make a difference.
INSERT DESIGNATOR, IF NEEDED
JBoss EAP on OpenShift Benefits
Productivity to develop, deploy and operate
Calculate the business benefits and

impacts of PaaS:
● Accelerated application
development
● Automated application
provisioning and config
● Web-scale application
operations
● Increased hardware utilization
Customize to your own situation and download report:
efficiency https://www.openshift.com/enterprise-paas/paas-demo-and-benefits
● Containerization -estimator

Migrations to JBoss Middleware
Red Hat's Catalyzers
Red Hat JBoss Migration Toolkit

Migrations to JBoss Middleware
Red Hat's Catalyzers
Red Hat Jboss Collaboration, Consulting methodology

Migration Toolkit Sharing, Knowledge and approach

Common migration challenges
Monolithic Applications Staff
● Historically grown ● SME no longer in-house

● Tightly coupled ● Missing knowledge of the target
● Poorly documented platform
● Customized standards ● Technical and business releases
● Horrifying tech. debt combined
● Highly tuned ● Weak automation across the app.
● Company critical life-cycle
● “Do not touch” sticker ● No automated tests, low coverage

Enterprise class challenges
● Highly disparate implementations across enterprise

○ Java 3, 4, 5, 6, 7
○ No standard: any version of any imaginable framework
○ Customized version of the above
● Too many tightly coupled applications
○ Hard to define a migration strategy (big bang vs. pragmatic)
○ Effort to estimate itself takes too much time
○ Unknowns creates fear to get started
● Impact on the whole application life-cycle
○ Development → Build → Test → Operations

Scope of a migration
Application Code
Infrastructure
hardware + virtualization + OS +JVM + application container
Processes & Governance

application lifecycle, build, configuration, deployment, provisioning, DevOps,
environments, test, integration, continuity *, monitoring
Knowledge

Key Migration Practices
Information sharing Reuse, automate, Minimalist and

based on a central standardize as much pragmatic
collaborative platform as possible methodology
Least effort: no issue solved - infrastructure, environment, As few changes as possible to
twice, no question asked dependencies, processes, get a running functionally
twice operations identical application
- strategy for software
versioning and revision
control
- functional and nonfunctional


control

Collaboration and information sharing
Establish one living collaborative documentation platform:
● Central entry point for the migration

● Significant catalyst and time-saver
● Exhaustive, concise, comprehensive and accurate documentation
● Easy to browse and to search
● (tagged content, lean structure)

Collaboration content
Step-by-Step Migration Guide
Comprehensive and pragmatic approach to migrate an application from scratch
Migration Cookbook
Thematic collection of “How-to” and “Known-solution” recipes
Recipe = article (“issue”, “resolution”, “learn more”)
Platform FAQ
Learning fast and more about the new platform
Pilot changes
Description of all changes done to specific projects


control

Automation
Wind-up your applications
Windup = open source reverse-engineering tool

generating top-down HTML report foreseeing migration
changes
● Shows a holistic picture of the Level of Effort in story points needed

to migrate or upgrade applications to Red Hat JBoss EAP
→ Application complexity not taken into account.
● Decompiles and analyzes specific packages and files
→ No source code required. Only the JAR / WAR / EAR files.
● Rule-based estimation, listing potential changes for the migration
Windup
Usage example
Some generated
HTML reports ... Use-cases
● Migration assessment
○ Identify critical issues
○ Do estimates
○ Build application cluster
○ Select pilots
● Exhaustive migration support
● Extend with new/custom rules
○ Linking collaboration platform
○ Specific pattern detection


control

Application Modernization and Migration
Methodology
DISCOVER DESIGN DEPLOY
Migrate in
Explore Analyze Prove Plan
Iterations
Discovery Session: Define Migration Strategy, Migration Factory:

Discuss options Prove Technology and Business Case Scale & Execute
RED HAT CONSULTING

Planning for Large Scale Migrations
CATALOG RATIONALIZE PLAN
Analyze
A
C
B
D E F

Application Migration and Modernization Factory
Migration Project Strategy and Structure: Divide, Scale and Conquer
Migration Project Team Structure
A
C
B
D E F
Red Hat
Consulting
and/or Partner’s Partner and/or
Migration Knowledge Customer
specialists Migration
and/or Customer’s Specialists / base Teams
specialists Center of (wiki and migration
rules) (1…N)
Excellence
Challenge
Backlog
22 INSERT DESIGNATOR, IF NEEDED

DevOps Maturity Assessment
1 Request a VM 2 Request a 3 Set up the 4 Configure build
DEV middleware platform environment for the
application
scripts
8 Integration test 7 Deploy to Share 6 Unit test 5 Write code

Dev for application
1 Request a VM 2 Request a middleware platform 3 Set up the environment for
TEST Integration testing

the application
Regression testing
6 Sign off to deploy 5 Functional testing 4 Build and deploy application
application Non-functional testing
Performance testing
Stress testing
Manual testing
1 Request a VM 2 Request a middleware 3 Set up the environment for

OPS platform the application
9 Get application fix 4 Build and deploy application
8 Root cause analysis 7 Production 6 Monitor the 5 Smoke test

issue application
24 RED HAT CONSULTING

application
scripts

Dev for application

the application
Regression testing
Developers should focus on

Performance testing
Stress testing
Manual testing
writing code.

issue application

application
scripts
Quality engineers should focus on testing.

Dev for application

the application
Regression testing
Performance testing
Stress testing
Manual testing

issue application

application
scripts

Dev for application
Ops engineers should focus on

providing reliable and stable environments.

the application
Regression testing
Performance testing
Stress testing
Manual testing

issue application

Idea to Product
Increased quality
Rapid delivery of product

features and service
Doing more
with less
Align IT with business

PRODUCT MANAGERS DEVELOPERS OPERATIONS
Lines of business Rapid development Stability
Agile DevOps
ALL TEAMS ARE THERE TO ENABLE THE BUSINESS
RED HAT CONSULTING

DevOps Improvement Program
30 DEVOPS MATURITY ASSESSMENT Based on Mike Rother's Improvement Kata, highlighted in Lean Enterprise (Humble et al.,
2015)
DevOps/Continuous Delivery
Improvement Model
People
Process Technology
31 DEVOPS MATURITY ASSESSMENT

Improvement Model
Information Build and
and Reporting Deploy
People
Test and Data

Verification Management
Process Technology
Culture and
Release
Organization

Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization
INITIAL IMPROVED OPTIMIZING

Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Red Hat Consulting DevOps Continuous
Delivery Model
1 (Initial) 2 3 (Improved) 4 5 (Optimizing)

Culture & Teams organised based Agile Adoption Scaled Agile Approach Cross-team continuous Cross functional teams.
Organization on platform/technology. (SAFe or other) improvement.
One backlog per team. High cooperation or
Defined and documented Extended team Teams responsible all the performance-oriented.
processes. Remove team boundaries. collaboration. way to production.
Low cooperation or Share the pain. Remove boundary dev/ops.

power-oriented.
Modest cooperation or Common process for all
rule-oriented. changes.
Derived from Continuous Delivery Maturity Models from InfoQ, UrbanCode, ThoughtWorks,
35 DEVOPS MATURITY ASSESSMENT Bekk, and others.
Culture and Organization
Pathological (power-oriented) Bureaucratic (rule-oriented) Generative
(performance-oriented)
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to enquiry
Novelty crushed Novelty leads to problems Novelty implemented
36 DEVOPS MATURITY ASSESSMENT From Ron Westrum’s “A Typology of Organizational Cultures”

Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Delivery Model

Test & Automated unit tests on Some automatic integration Automatic component Full automatic acceptance Verify expected business
Verification every build. tests. tests. tests. value.
Separate test environment. Code analysis. Full automatic integration Manual exploratory testing. Defects found and fixed
tests. immediately (roll forward).
Test coverage analysis. Automatic performance
Behavior-driven tests.
development.
Automatic security tests.
Test and Verification

Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Delivery Model

Information & Baseline process metrics. Measure the process. Automatic generation of Report trend analysis. Dynamic self-service of
Reporting release notes. information.
Manual reporting. Static code analysis. Real time graphs on
Pipeline traceability. deployment pipeline Customizable dashboards.
Automatic reporting. metrics.
Reporting history.
Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Delivery Model
Build & Centralized version control. Continuous Integration Deployment Pipelines Team prioritises keeping Zero touch continuous
Deploy codebase deployable over deployments.
Automated scripts for Polling or triggered builds Fail builds if more general doing new work.
building software. (commit hook). quality is not met.
Orchestrated deployments.
Nightly builds. Fail builds if they do not Automated provisioning of
compile and pass unit tests. environments. Blue/green deployments.
No management of artifacts.
Any build can be re-created Automated deployments.
Manual deployment. from source control.
Standardized environment
Management of build templates.
artifacts.
Standard deployment
Builds are not left broken. process for all environments.
Build and Deploy
Continuous Integration
DEFINITION:
Every time somebody commits a change, the entire application is built and a comprehensive
set of automated tests are run against it. (Humble and Farley, 2011)
● Requires frequent code check ins, good test coverage, preferably a CI server
BENEFITS:
● Normal state of the application is working, functional
● If the application is broken, it is treated as abnormal and requiring immediate attention
TOOLS:
● Version control, CI server

Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Delivery Model

Data Data migrations Automated and versioned Changes to datastores Automatic datastore
Management unversioned and changes to datastores. automatically performed as changes and rollbacks
performed manually. part of the deployment tested with every
process. deployment.
Improvement Model
People
Test and Data

Process Technology
Culture and
Release
Organization

Delivery Model

Release Infrequent and unreliable Painful infrequent but Infrequent but fully Frequent fully automated No rollbacks, always roll
releases. reliable releases. automated and reliable releases. forward.
releases in any environment.
Deployment disconnected
from release.
LINUX CONTAINERS
WHAT ARE CONTAINERS?
It Depends Who You Ask
INFRASTRUCTURE APPLICATIONS
● Application processes on a shared kernel ● Package apps with all dependencies

● Simpler, lighter, and denser than VMs ● Deploy to any environment in seconds
● Portable across different environments ● Easily accessed and shared
50 OPENSHIFT TECHNICAL OVERVIEW

VIRTUAL MACHINES AND CONTAINERS
VIRTUAL MACHINES CONTAINERS
VM Container Container Container Container
App App App App

App App App App
OS Dependencies OS deps OS deps OS deps OS deps
Kernel Container Host (Kernel)
Hypervisor
Hardware
Hardware
VM virtualizes the hardware Container virtualizes the process

Virtual Machine Container
Application Application
OS dependencies OS dependencies
Operating System
Container Host
VM Isolation Container Isolation

Complete OS Shared Kernel
Static Compute Burstable Compute
Static Memory Burstable Memory
High Resource Usage Low Resource Usage

Virtual Machine Container
Application Application
Clear ownership boundary Dev
IT Ops OS dependencies between Dev and IT Ops OS dependencies
(and Dev, sort of)
drives DevOps adoption
Operating System and fosters agility Container Host
IT Ops
Infrastructure Infrastructure
Optimized for stability

Optimized for agility

APPLICATION PORTABILITY WITH VM
Virtual machines are NOT portable across hypervisor and

do NOT provide portable packaging for applications
Guest VM VM Type X VM Type Y VM Type Z
Application Application Application Application

Application
OS dependencies OS dependencies OS dependencies OS dependencies
OS dependencies
Operating System Operating System Operating System Operating System

Operating System
LAPTOP BARE METAL VIRTUALIZATION PRIVATE CLOUD PUBLIC CLOUD

APPLICATION PORTABILITY WITH CONTAINERS
RHEL Containers + RHEL Host = Guaranteed Portability

Across Any Infrastructure
Container Container Container Container Container
Application Application Application Application Application
OS dependencies OS dependencies OS dependencies OS dependencies OS dependencies
RHEL RHEL RHEL RHEL

RHEL
Guest VM Virtual Machine Virtual Machine Virtual Machine
LAPTOP BARE METAL VIRTUALIZATION PRIVATE CLOUD PUBLIC CLOUD

RAPID SECURITY PATCHING USING
CONTAINER IMAGE LAYERING
Image Layer 3
Application Layer
Image Layer 2 Java Runtime Layer
Image Layer 1 OS Update Layer
Base Image Base RHEL
Container Image Layers Example Container Image

OPENSHIFT CONCEPTS
OVERVIEW
A container is the smallest compute unit
CONTAINER

containers are created from
container images
CONTAINER
CONTAINER
IMAGE
BINARY RUNTIME

container images are stored in
an image registry
IMAGE REGISTRY
CONTAINER CONTAINER CONTAINER

IMAGE IMAGE IMAGE
CONTAINER

IMAGE IMAGE IMAGE

an image repository contains all versions of an
image in the image registry
IMAGE REGISTRY
myregistry/frontend myregistry/mongo
frontend:latest mongo:latest
frontend:2.0 mongo:3.7
frontend:1.1 CONTAINER mongo:3.6 CONTAINER
frontend:1.0 IMAGE
mongo:3.4 IMAGE

containers are wrapped in pods which are
units of deployment and management
POD POD
IP: 10.1.0.11 IP: 10.1.0.55

pods configuration is defined
in a deployment
POD POD POD

image name
replicas
labels
cpu CONTAINER CONTAINER CONTAINER
memory
storage
DEPLOYMENT

services provide internal load-balancing and
service discovery across pods
BACKEND SERVICE
role: backend
POD POD POD POD
CONTAINER CONTAINER CONTAINER CONTAINER
role: frontend role: backend role: backend role: backend

apps can talk to each other via services
Invoke
Backend API
BACKEND SERVICE
role: backend
POD POD POD POD
CONTAINER CONTAINER CONTAINER CONTAINER
role: frontend role: backend role: backend role: backend

routes add services to the external load-balancer and
provide readable urls for the app
ROUTE
app-prod.mycompany.com
> curl http://app-prod.mycompany.com
BACKEND SERVICE
POD POD POD

projects isolate apps across environments,
teams, groups and departments
PAYMENT DEV CATALOG
POD POD POD POD POD POD

❌
C C C C C C
PAYMENT PROD INVENTORY
POD POD POD POD POD POD

❌ ❌
C C C C C C

OPENSHIFT ARCHITECTURE
YOUR CHOICE OF INFRASTRUCTURE
PHYSICAL VIRTUAL PRIVATE PUBLIC HYBRID

NODES RHEL INSTANCES WHERE APPS RUN
NODE NODE NODE
RHEL RHEL RHEL
NODE NODE NODE
RHEL RHEL RHEL

APPS RUN IN CONTAINERS
NODE NODE NODE
Container
C Cc
Image
C C C
RHEL RHEL RHEL

Container
NODE NODE NODE
C C C C
Pod C
RHEL RHEL RHEL

PODS ARE THE UNIT OF ORCHESTRATION
NODE NODE NODE
C C
c
C C C
RHEL RHEL RHEL
NODE NODE NODE
C C C C
RHEL RHEL RHEL

MASTERS ARE THE CONTROL PLANE
NODE NODE NODE

MASTER
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

API AND AUTHENTICATION
NODE NODE NODE

MASTER
API/AUTHENTICATION
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

DESIRED AND CURRENT STATE
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL
PHYSICAL
PHYSICAL
VIRTUALVIRTUAL
PRIVATEPRIVATEPUBLIC PUBLICHYBRID HYBRID

INTEGRATED CONTAINER REGISTRY
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
NODE NODE NODE REGISTRY
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ORCHESTRATION AND SCHEDULING
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE NODE REGISTRY
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

PLACEMENT BY POLICY
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C
DATA STORE
RHEL RHEL RHEL
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

AUTOSCALING PODS
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C
DATA STORE
RHEL RHEL RHEL
HEALTH/SCALING
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

SERVICE DISCOVERY
SERVICE LAYER
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
HEALTH/SCALING C C C C
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

PERSISTENT DATA IN CONTAINERS
SERVICE LAYER
NODE NODE NODE PERSISTENT

MASTER STORAGE
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ROUTING AND LOAD-BALANCING
ROUTING LAYER
SERVICE LAYER

MASTER STORAGE
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ACCESS VIA WEB, CLI, IDE AND API
ROUTING LAYER
SERVICE LAYER

SCM
MASTER STORAGE
(GIT)
C Cc
API/AUTHENTICATION
C C C
CI/CD DATA STORE
RHEL RHEL RHEL
EXISTING C C C C
HEALTH/SCALING
AUTOMATION
TOOLSETS
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

MONITORING
APPLICATION HEALTH
AUTO-HEALING FAILED PODS
NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE NODE
C C
HEALTH/SCALING c
RED HAT
ENTERPRISE LINUX RHEL RHEL RHEL

AUTO-HEALING FAILED CONTAINERS
NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
c c
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE
C C
HEALTH/SCALING
RED HAT
ENTERPRISE LINUX RHEL RHEL

NETWORKING
BUILT-IN SERVICE DISCOVERY
INTERNAL LOAD-BALANCING
SERVICE Name: payroll-frontend

IP: 172.10.1.23
app=payroll role=frontend Port: 8080
POD POD POD

app=payroll app=payroll
role=frontend role=frontend app=payroll
version=1.0 version=1.0 role=backend

BUILT-IN SERVICE DISCOVERY
INTERNAL LOAD-BALANCING
SERVICE Name: payroll-frontend

IP: 172.10.1.23
app=payroll role=frontend Port: 8080
POD POD POD POD

app=payroll app=payroll app=payroll
role=frontend role=frontend role=frontend app=payroll
version=2.0 version=1.0 version=1.0 role=backend

ROUTE EXPOSES SERVICES EXTERNALLY
EXTERNAL TRAFFIC
ROUTER
INTERNAL TRAFFIC
SERVICE
POD POD POD

ROUTING AND EXTERNAL LOAD-BALANCING
● Pluggable routing architecture
○ HAProxy Router
○ F5 Router
● Multiple-routers with traffic sharding

● Router supported protocols
○ HTTP/HTTPS
○ WebSockets
○ TLS with SNI
● Non-standard ports via cloud load-balancers,

external IP, and NodePort

ROUTE SPLIT TRAFFIC
Split Traffic Between ROUTE
Multiple Services For A/B 90% traffic 10% traffic
Testing, Blue/Green and

SERVICE A SERVICE B
Canary Deployments
App A App A App B App B

EXTERNAL TRAFFIC TO A SERVICE
ON A RANDOM PORT WITH NODEPORT
● NodePort binds a service to a CLIENT
unique port on all the nodes connect

192.10.0.10:31421
192.10.0.11:31421
● Traffic received on any node 192.10.0.12:31421
redirects to a node with the SERVICE

running service INT IP: 172.1.0.20:90
● Ports in 30K-60K range which

usually differs from the service
POD POD POD
● Firewall rules must allow traffic to 10.1.0.1:90 10.1.0.2:90 10.1.0.3:90
all nodes on the specific port

NODE NODE NODE
192.10.0.10 192.10.0.11 192.10.0.12

EXTERNAL TRAFFIC TO A SERVICE
ON ANY PORT WITH INGRESS
● Access a service with an external CLIENT
IP on any TCP/UDP port, such as connect

200.1.0.10:90
○ Databases
○ Message Brokers SERVICE
EXT IP: 200.1.0.10:90

● Automatic IP allocation from a INT IP: 172.1.0.20:90
predefined pool using Ingress IP

Self-Service
POD POD POD
● IP failover pods provide high
10.1.0.1:90 10.1.0.2:90 10.1.0.3:90
availability for the IP pool
NODE NODE NODE
192.10.0.10 192.10.0.11 192.10.0.12

CONTROL OUTGOING TRAFFIC
SOURCE IP WITH EGRESS ROUTER
POD
EGRESS
EXTERNAL
POD EGRESS SERVICE ROUTER SERVICE
INTERNAL-IP:8080
POD
IP1 Whitelist: IP1
NODE
IP1
POD

OPENSHIFT NETWORKING
● Built-in internal DNS to reach services by name
● Split DNS is supported via SkyDNS

○ Master answers DNS queries for internal services
○ Other name servers serve the rest of the queries
● Software Defined Networking (SDN) for a unified

cluster network to enable pod-to-pod communication
● OpenShift follows the Kubernetes

Container Networking Interface (CNI) plug-in model

OPENSHIFT NETWORK PLUGINS
OPENSHIFT
KUBERNETES CNI
Contrail
OpenShift Essentials Cisco VMware Open
Flannel Nuage (OpenCont Big Switch
Plugin (Calico) Contiv NSX-T Daylight
Plugin* Plugin rail) Plugin
Plugin Plugin Plugin Plugin
DEFAULT Plugin
Certified Plugin Validated Plugin In-Progress
* Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on OpenStack reference architecture

OPENSHIFT NETWORKING
POD POD VxLAN Overlay POD POD

10.1.2.2 10.1.2.4 10.1.4.2 10.1.4.4
Network
NODE NODE
172.16.1.10 172.16.1.20
IP Network

OPENSHIFT SDN
FLAT NETWORK (Default)

● All pods can communicate with PROJECT A PROJECT B PROJECT C
each other across projects DEFAULT NAMESPACE
MULTI-TENANT NETWORK
NODE NODE
●
●
Project-level network isolation
Multicast support
POD POD
✓ POD POD
● Egress network policies POD POD POD POD
NETWORK POLICY (Tech Preview)
● Granular policy-based isolation Multi-Tenant Network

OPENSHIFT SDN - NETWORK POLICY
PROJECT A PROJECT B Example Policies

● Allow all traffic inside the project
● Allow traffic from green to gray
POD
8080
✓ POD ● Allow traffic to purple on 8080
5432
POD POD apiVersion: extensions/v1beta1

kind: NetworkPolicy
✓ metadata:
name: allow-to-purple-on-8080
POD POD spec:
podSelector:
✓ ✓ matchLabels:
color: purple
POD POD ingress:
- ports:
- protocol: tcp
port: 8080

OPENSHIFT SDN - OVS PACKET FLOW
Container to Container on the Same Host
NODE
veth0
POD 1
10.1.15.2/24
br0
vxlan0 eth0
10.1.15.1/24
192.168.0.100
veth1
POD 2
10.1.15.3/24

Container to Container on the Different
Hosts
NODE 1
veth0 br0 eth0

POD 1 vxlan0
10.1.15.2/24 10.1.15.1/24
192.168.0.100
NODE 2
veth0 br0
POD 2 vxlan0 eth0
10.1.20.2/24 10.1.20.1/24
192.168.0.200

Container Connects to External Host
Container
NODE 1 to Container on Different Hosts
POD 1
veth0 br0
tun0 eth0
External
10.1.15.2/24 10.1.15.1/24 Host
192.168.0.100

OPENSHIFT SDN WITH
FLANNEL FOR OPENSTACK
NODE 1
veth0 docker0 Routing

POD 1 eth0
10.1.15.2/24 10.1.15.1/24 Table
192.168.0.100
flanneld
etcd
NODE 2 flanneld
veth0 docker0 Routing

POD 2 eth0
10.1.20.2/24 10.1.20.1/24 Table
192.168.0.200
Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift
on OpenStack reference architecture https://access.redhat.com/articles/2743631

LOGGING & METRICS
CENTRAL LOG MANAGEMENT WITH EFK
● EFK stack to aggregate logs for hosts and applications
○ Elasticsearch: a search and analytics engine to store logs
○ Fluentd: gathers logs and sends to Elasticsearch.
○ Kibana: A web UI for Elasticsearch.
● Access control
○ Cluster administrators can view all logs
○ Users can only view logs for their projects
● Ability to send logs elsewhere

○ External elasticsearch, Splunk, etc

CENTRAL LOG MANAGEMENT WITH EFK
NODE
POD POD OPERATION LOGS

FLUENTD
NODE
ELASTIC ELASTIC
POD POD ELASTIC ELASTIC
ELASTICSEARCH KIBANA
POD POD
FLUENTD
ADMIN
NODE
RHEL
POD POD APPLICATION LOGS
POD POD
FLUENTD
ELASTIC ELASTIC
ELASTIC ELASTIC
RHEL ELASTICSEARCH KIBANA
POD POD
USER
RHEL

CONTAINER METRICS

CONTAINER METRICS
NODE
RED HAT
POD POD CLOUDFORMS
CONTAINER METRICS
FLUENTD
NODE
POD POD API OPENSHIFT
HEAPSTER HAWKULAR
WEB CONSOLE
POD POD
FLUENTD
NODE
RHEL USER
POD POD CUSTOM
DASHBOARDS
POD POD ELASTIC
CADVISOR
ELASTIC
CASSANDRA
RHEL
POD POD
RHEL

SECURITY
TEN LAYERS OF CONTAINER SECURITY
Container Host & Multi-tenancy Federated Clusters
Container Platform API Management
Network Isolation Deploying Container
Container Registry Container Content
Storage Building Containers

SECRET MANAGEMENT
● Secure mechanism for holding sensitive data e.g.
MASTER
○ Passwords and credentials
○ SSH Keys
Distributed Store
○ Certificates
● Secrets are made available as

○ Environment variables
○ Volume mounts
○ Interaction with external systems NODE
Container Container
● Encrypted in transit and at rest
● Never rest on the nodes

CERTIFICATE MANAGEMENT
● Certificates are used to provide secure

✓ MASTER
connections to
✓ NODES
○ master and nodes Check
Expiry
Ansible
○ router and registry Playbook ✓ ROUTER
Redeploy
○ etcd Certs
✓ REGISTRY
● Ansible playbooks to automate redeployment
✓ ETCD
● Redeploy all at once or specific components
● Certificate expiry report generator

CERTIFICATE EXPIRY REPORT
CERTIFICATE CHECKS
● master and nodes
● router and registry service

certificates from etcd secrets
● master, node, router,

registry, and kubeconfig files
for cluster-admin users
● etcd certificates

PERSISTENT STORAGE
PERSISTENT STORAGE
● Persistent Volume (PV) is tied to a piece of network storage
● Provisioned by an administrator (static or dynamically)
● Allows admins to describe storage and users to request storage
● Assigned to pods based on the requested size, access mode, labels and type
OpenStack
NFS iSCSI Azure Disk AWS EBS FlexVolume
Cinder
GCE Persistent VMWare

GlusterFS Ceph RBD Fiber Channel Azure File
Disk vSphere VMDK

PERSISTENT STORAGE
POOL OF PERSISTENT VOLUMES
register PV Ceph
iSCSI GlusterFS NFSP NFSP NFSP
RBD
PV PV V V V
PV
Admin
PROJECT Pod Pod Pod
create claim
claim claim claim

User

DYNAMIC VOLUME PROVISIONING
Slow Azure
Azure-Disk Provisioner
define StorageClass AWS

Fast
AWS-SSD Provisioner
provision
Admin Fastest NetApp
PV
NetApp-Flash Provisioner
Pod
create claim: Fastest OpenShift

PV Controller
bound
claim
User

BUILD AND DEPLOY
CONTAINER IMAGES
BUILD AND DEPLOY CONTAINER IMAGES
DEPLOY YOUR DEPLOY YOUR DEPLOY YOUR

SOURCE CODE APP BINARY CONTAINER IMAGE

DEPLOY SOURCE CODE WITH
SOURCE-TO-IMAGE (S2I)
Git code
BUILD APP Repository
(OpenShift)
Developer
Source-to-Image
BUILD IMAGE (S2I)
(OpenShift) Builder Image

Image Registry
DEPLOY Application
Container
deploy
(OpenShift)
User/Tool Does OpenShift Does

DEPLOY APP BINARY WITH
SOURCE-TO-IMAGE (S2I)
Application build
Binary
BUILD APP (e.g. WAR)
(Build Infra) Existing Build

Process
Source-to-Image
BUILD IMAGE (S2I)
(OpenShift) Builder Image

Image Registry
DEPLOY Application
Container
deploy
(OpenShift)

DEPLOY DOCKER IMAGE
build
Application
BUILD IMAGE Image
(Build Infra) Existing Image

Build Process
Image
PUSH Registry
(Build Infra)
DEPLOY Application
Container
deploy
(Openshift)

BUILD IMAGES IN MULTIPLE STAGES
BUILD STAGE 1
BUILD STAGE 3
BUILD STAGE 2

EXAMPLE: USE ANY RUNTIME IMAGE WITH
SOURCE-TO-IMAGE BUILDS
Use Source-to-Image to build app binaries and deploy on lean vanilla runtimes
WILDFLY S2I BUILD app.war DOCKER BUILD
WildFly S2I WildFly

Builder Runtime
Image Image
read more on https://blog.openshift.com/chaining-builds/

EXAMPLE: USE ANY BUILD TOOL WITH
OFFICIAL RUNTIME IMAGES
Use your choice of build tool like Gradle and deploy to official images like the JDK image
CUSTOM GRADLE BUILD app.war DOCKER BUILD
Custom Red Hat

Gradle S2I OpenJDK
Builder Image Image

EXAMPLE: SMALL LEAN RUNTIMES
Build the app binary and deploy on small scratch images
CUSTOM GO BUILD app DOCKER BUILD
Custom
Scratch
Go S2I
Image
Builder Image

CONTINUOUS INTEGRATION (CI)
CONTINUOUS DELIVERY (CD)
CI/CD WITH BUILD AND DEPLOYMENTS
BUILDS
● Webhook triggers: build the app image whenever the code changes
● Image trigger: build the app image whenever the base language or app runtime changes
● Build hooks: test the app image before pushing it to an image registry
DEPLOYMENTS
● Deployment triggers: redeploy app containers whenever configuration changes or the
image changes in the OpenShift integrated registry or upstream registries

CONTINUOUS DELIVERY WITH CONTAINERS
physical
virtual
private cloud
dev source CI/CD container
repository engine
public cloud

OPENSHIFT LOVES CI/CD
JENKINS-AS-A SERVICE HYBRID JENKINS INFRA EXISTING CI/CD

ON OPENSHIFT WITH OPENSHIFT DEPLOY TO OPENSHIFT

JENKINS-AS-A-SERVICE ON OPENSHIFT
● Certified Jenkins images with pre-configured plugins Plugins
Jobs
○ Provided out-of-the-box Configuration
○ Follows Jenkins 1.x and 2.x LTS versions
● Jenkins S2I Builder for customizing the image

○ Install Plugins Jenkins
○ Configure Jenkins (S2I)
○ Configure Build Jobs

Jenkins
Image
● OpenShift plugins to integrate authentication with
OpenShift and also CI/CD pipelines
Custom
Jenkins
● Dynamically deploys Jenkins slave containers Image

HYBRID JENKINS INFRA WITH OPENSHIFT
● Scale existing Jenkins infrastructure by dynamically provisioning Jenkins slaves on OpenShift
● Use Kubernetes plug-in on existing Jenkin servers
JENKINS JENKINS build

SLAVE SLAVE
run job JENKINS
APP APP
Run Job Run Job deploy
MASTER
OPENSHIFT

EXISTING CI/CD DEPLOY TO OPENSHIFT
● Existing CI/CD infrastructure outside OpenShift performs operations against OpenShift

○ OpenShift Pipeline Jenkins Plugin for Jenkins
○ OpenShift CLI for integrating other CI Engines with OpenShift
● Without disrupting existing processes, can be combined with previous alternative
EXISTING
S2I
run job CI/CD INFRA build Build
APP APP
Jenkins, Bamboo, deploy

TeamCity, etc
OPENSHIFT

OPENSHIFT PIPELINES
● OpenShift Pipelines allow defining a apiVersion: v1

CI/CD workflow via a Jenkins pipeline kind: BuildConfig
metadata: Provision a
which can be started, monitored, and name: app-pipeline
Jenkins slave for
spec:
managed similar to other builds strategy: running Maven
type: JenkinsPipeline
jenkinsPipelineStrategy:
● Dynamic provisioning of Jenkins slaves jenkinsfile: |-
node('maven') {
stage('build app') {
● Auto-provisioning of Jenkins server git url: 'https://git/app.git'
sh "mvn package"
● OpenShift Pipeline strategies }
stage('build image') {
○ Embedded Jenkinsfile sh "oc start-build app --from-file=target/app.jar
}
○ Jenkinsfile from a Git repository stage('deploy') {
openshiftDeploy deploymentConfig: 'app'
}
}

OpenShift
Pipelines in
Web Console

CONTINUOUS DELIVERY PIPELINE
ARTIFACT
DEV TEAM GIT SERVER
REPOSITORY
● S2I build from source code

JENKINS
IMAGE BUILD ● S2I build from app binary
● Existing docker container image
build process
APPLICATION
IMAGE

DEVELOPER GIT SERVER ARTIFACT REPOSITORY
OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD
& DEPLOY
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV PROD

OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE
& DEPLOY TO TEST
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV TEST PROD

OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV TEST UAT PROD

ServiceNow
DEVELOPER GIT SERVER ARTIFACT REPOSITORY RELEASE MANAGER
JIRA Service Desk
GO Zendeks
LIVE? BMC Remedy
☒
OPENSHIFT
CI/CD PIPELINE
(JENKINS)
☑
IMAGE BUILD PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

GIT SERVER ARTIFACT REPOSITORY RELEASE MANAGER
GO
LIVE?
☒
OPENSHIFT
☑
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT TO PROD
DEVELOPER
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

BUT…
SOME TEAMS ALREADY HAVE
AUTOMATED DELIVERY PIPELINES

WHAT IF THERE ARE EXISTING DELIVERY
PROCESSES?
BUILD APP RUN PROMOTE APP BUILD CONTAINER RUN PROMOTE CONTAINER
BINARY TESTS BINARY IMAGE TESTS IMAGE
SOURCE
VERSION
CONTROL
ENTERPRISE ENTERPRISE
BINARY REPO IMAGE REGISTRY

WHAT IF THERE ARE EXISTING DELIVERY
PROCESSES?
BUILD APP RUN PROMOTE APP BUILD CONTAINER RUN PROMOTE CONTAINER
BINARY TESTS BINARY IMAGE TESTS IMAGE
SOURCE
VERSION
CONTROL
ENTERPRISE ENTERPRISE
BINARY REPO IMAGE REGISTRY
AWS ECR

ENRICHING EXISTING DELIVERY PROCESSES
WITH OPENSHIFT
EXISTING
DELIVERY
PROCESS
DEPLOY DEPLOY DEPLOY
OPENSHIFT
CLUSTER

ENRICHING EXISTING DELIVERY PROCESSES
WITH OPENSHIFT
EXISTING
DELIVERY
PROCESS
ENTERPRISE
IMAGE
REGISTRY
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

HYBRID APPLICATION AUTOMATION
WITH OPENSHIFT AND ANSIBLE

HYBRID APPLICATION AUTOMATION
WITH OPENSHIFT AND ANSIBLE
CONTINUOUS
DELIVERY
PIPELINE
DEV PROD - REGION A PROD - REGION B
VIRTUAL VIRTUAL
MACHINE MACHINE
Hyper V VMware RHEV OpenStack AWS Azure Google Cloud

DEVELOPER WORKFLOW
LOCAL DEVELOPMENT WORKFLOW
Local
Bootstrap Develop Verify Git Push Pipeline
Deploy

Local
Deploy
BOOTSTRAP
● Pick your programming language and application runtime of choice
● Create the project skeleton from scratch or use a generator such as
○ Maven archetypes
○ Quickstarts and Templates
○ OpenShift Generator
○ Spring Initializr

Local
Deploy
DEVELOP
● Pick your framework of choice such as Java EE, Spring, Ruby on Rails, Django, Express, ...
● Develop your application code using your editor or IDE of choice
● Build and test your application code locally using your build tools
● Create or generate OpenShift templates or Kubernetes objects

Local
Deploy
LOCAL DEPLOY
● Deploy your code on a local OpenShift cluster
○ Red Hat Container Development Kit (CDK), minishift and oc cluster
● Red Hat CDK provides a standard RHEL-based development environment
● Use binary deploy, maven or CLI rsync to push code or app binary directly into
containers

Local
Deploy
VERIFY
● Verify your code is working as expected
● Run any type of tests that are required with or without other components (database, etc)
● Based on the test results, change code, deploy, verify and repeat

Local
Deploy
GIT PUSH
● Push the code and configuration to the Git repository
● If using Fork & Pull Request workflow, create a Pull Request
● If using code review workflow, participate in code review discussions

Local
Deploy
PIPELINE
● Pushing code to the Git repository triggers one or multiple deployment pipelines
● Design your pipelines based on your development workflow e.g. test the pull request
● Failure in the pipeline? Go back to the code and start again

APPLICATION SERVICES
A PLATFORM THAT GROWS WITH YOUR BUSINESS
Web Data Intelligent Micro

Application Virtualization Process services
API Single Java EE

Mobile
Management Sign-On Application
Real Time
Integration Messaging Data Grid
Decision

TRUE POLYGLOT PLATFORM
Third-party
.NET
LANGUAGES Java NodeJS Python PHP Perl Ruby Language
Core Runtimes
DATABASES MySQL PostgreSQL MongoDB Redis ...and virtually Third-party

Databases
CrunchyData
any docker GitLab

Iron.io
Apache
image Third-party
Phusion Couchbase
WEB SERVERS HTTP
Server
nginx Varnish Passenger Tomcat
out there! App
Runtimes Sonatype
EnterpriseDB
JBoss NuoDB
Spring Wildfly JBoss JBoss JBoss Third-party
Vert.x Web Middleware
Boot Swarm EAP A-MQ Fuse
Server Fujitsu
MIDDLEWARE and many more
3SCALE JBoss JBoss JBoss JBoss RH Third-party

RH SSO Middleware
API mgmt BRMS BPMS Data Virt Data Grid Mobile

LAUNCH
SUPPORTED RUNTIMES TESTED & VERIFIED
Spring Cloud
Eclipse Vert.x WildFly Swarm Node.js Spring Boot
(partial)
OPENSHIFT
Modern, Cloud-Native Application Runtimes and

an Opinionated Developer Experience

DEPLOYMENT STRATEGY
DEPLOYMENTS
● Deployment strategy determines the deployment process for containers
● Rolling strategy
○ Performs rolling updates
○ Supports life-cycle hooks for injecting code into deployment process
○ Waits for pods to pass readiness check before scaling down old components
○ Used by default if no strategy specified on deployment configuration
● Recreate strategy
○ Has basic rollout behavior
○ Scales down previous deployment before deploying the new one
○ Supports life-cycle hooks for injecting code into deployment process
● Custom strategy for custom deployment behaviour
OPENSHIFT
ROLLING STRATEGY
All rolling deployments in OpenShift Container Platform are canary deployments; a new
version (the canary) is tested before all of the old instances are replaced. When to Use a
Rolling Deployment:
● When you want to take no downtime during an application update.
● When your application supports having old code and new code running at the same time.

BLUE-GREEN DEPLOYMENT
● Reducing downtime and risk associated with release
● Two identical environments in containing two
different releases (Blue and Green)
● After validating new release, can switch all traffic to
new version
● Quickly roll application back if you find issues router
● Blue-green deployments involve running two versions
of an application at the same time and moving
production traffic from the old version to the new
version.
OPENSHIFT
BLUE GREEN STRATEGY
Use a blue-green deployment when you want to test a new version of your application in a
production environment before moving traffic to it.
Blue-green deployments make switching between two different versions of your application
easy. However, since many applications depend on persistent data, you will need to have an
application that supports N-1 compatibility if you share a database, or implement a live data
migration between your database, store, or disk if you choose to create two copies of your
data layer.

A/B DEPLOYMENT
● A/B testing is a way of testing features in
application for various reasons like usability,
popularity, noticeability, etc
● Usually associated with application UI however
the back-end services need to be available
● Can implement with either application-level or
static switches
● The simplest form of an A/B deployment is to
divide production traffic between two or more
distinct shards — a single group of instances
with homogeneous configuration and code.
OPENSHIFT
A/B STRATEGY
When to Use an A/B Deployment

● When you want to test multiple versions of code or configuration, but are not planning to
roll one out in preference to the other.
● When you want to have different configuration in different regions.

CONFIGURATION MANAGEMENT
CONFIGMAPS
● A ConfigMap can be used to store fine-grained
information like individual properties or coarse-grained
information like entire configuration files or JSON
blobs.
● A ConfigMap can be consumed in the pod by:

○ Consuming in Environment Variables
○ Setting Command-line Arguments
○ Consuming in Volumes
● ConfigMaps are useful for storing and sharing

non-sensitive, unencrypted configuration information

SECRET
● The Secret object type provides a mechanism to hold
sensitive information such as passwords, OpenShift
Container Platform client configuration files, dockercfg
files, private source repository credentials, and so on.
● A Secret can be consumed in the pod by:

○ Consuming in Environment Variables
○ Setting Command-line Arguments
○ Consuming in Volumes
● When you create a Secret, you can secure it with

base64-encoded username and password.

Configuration Load Example
1

Configuration Load Example - Cont
4

APPLICATION CONFIGURATION
- apiVersion: v1 - apiVersion: v1
kind: ConfigMap kind: DeploymentConfig
metadata: ...
name: app-config spec:
data: template:
product.per.page: 10 spec:
thumbnail.size: medium containers:
ui.properties: |- - env:
header.bg.color=red - name: CFG_PRODUCTS_PER_PAGE
header.fg.color=white valueFrom:
... configMapKeyRef:
name: app-config
key: product.per.page
- name: CFG_THUMBNAIL_SIZE
valueFrom:
configMapKeyRef:
name: app-config
key: thumbnail.size
...
OPENSHIFT
APPLICATION CONFIGURATION
kind: ConfigMap kind: DeploymentConfig
metadata: ...
name: app-config spec:
data: template:
product.per.page: 10 spec:
thumbnail.size: medium containers:
ui.properties: |- volumeMounts:
header.bg.color=red - name: config-volume
header.fg.color=white mountPath: /etc/config
... volumes:
- name: config-volume
configMap:
name: app-config
...
OPENSHIFT
TEMPLATES
TEMPLATES
● Describes set of resources that an application is composed of
○ Pods
○ BuildConfigs
○ DeploymentConfigs
○ etc
● Simplifies deploying multi-component applications e.g. create instantly deployable applications for developers or
customers
● Can be parameterized
○ Application name, datasource, passwords, etc
● Some provided by OpenShift.
● Users are encouraged to create their own
OPENSHIFT
TEMPLATES
frontend integration cache
template frontend backend batch
messaging backend database
OPENSHIFT
TEMPLATES
apiVersion: v1
kind: Template
labels:
template: eap64-basic-s2i
xpaas: 1.2.0
metadata:
annotations:
description: Application template for EAP 6 applications built using S2I.
iconClass: icon-jboss
tags: eap,javaee,java,jboss,xpaas
version: 1.2.0
Template name name: eap64-basic-s2i
namespace: openshift
Parameters parameters:
to set when - description: The name for the application.
instantiated name: APPLICATION_NAME
required: true
value: eap-app
List of objects in this ...
template
objects:
...
OPENSHIFT
TEMPLATES
● Describes set of resources that an application is composed of
○ Pods
○ BuildConfigs
○ DeploymentConfigs
○ etc
● Simplifies deploying multi-component applications e.g. create instantly deployable
applications for developers or customers
● Can be parameterized
○ Application name, datasource, passwords, etc
● Some provided by OpenShift.
● Users are encouraged to create their own
OPENSHIFT
TEMPLATES
frontend integration cache
template frontend backend batch
messaging backend database
OPENSHIFT
TEMPLATES
apiVersion: v1
kind: Template
labels:
template: eap64-basic-s2i
xpaas: 1.2.0
metadata:
annotations:
description: Application template for EAP 6 applications built using S2I.
iconClass: icon-jboss
tags: eap,javaee,java,jboss,xpaas
version: 1.2.0
Template name name: eap64-basic-s2i
namespace: openshift
Parameters parameters:
to set when - description: The name for the application.
instantiated name: APPLICATION_NAME
required: true
value: eap-app
...
List of objects in this objects:

template ...
OPENSHIFT
Creating App From Template
OPENSHIFT
CREATING APP FROM TEMPLATE
● Default templates in OpenShift are installed in the openshift namespace. Examine the
list of installed templates
$ oc get templates -n openshift
● Examine the cakephp-mysql-example template
$ oc get template cakephp-mysql-example -n openshift -o yaml
● Review the defined parameters and how they are referenced throughout the template
- displayName: Database Password

from: '[a-zA-Z0-9]{16}'
generate: expression
name: DATABASE_PASSWORD
OPENSHIFT
● Create a new application based on the cakephp-mysql-example template
$ oc new-project lab6
$ oc new-app cakephp-mysql-example
Parameter values can be specified through the -p option. Otherwise default values will
be used as defined in the template
$ oc new-app cakephp-mysql-example -p DATABASE_NAME=cakedb,DATABASE_USER=cakeuser
OPENSHIFT
● Examine the default, specified and generated parameter values used for creating the app
--> Deploying template cakephp-mysql-example in project openshift for "cakephp-mysql-example"
With parameters:
Memory Limit=512Mi
Memory Limit (MySQL)=512Mi
Git Repository URL=https://github.com/openshift/cakephp-ex.git
Git Reference=
Context Directory=
Application Hostname=
GitHub Webhook Secret=in8i20Rpx65o2sOQofNxP7qYXFKWeUn2lyjPUWvf # generated
Database Service Name=mysql
Database Engine=mysql
Database Name=default
Database User=cakephp
Database Password=0JCtLW8st4VVibwu # generated
CakePHP secret token=HX80JvCJyVR1CybPqiYsCEmEOGlySMXzg9Dyn396u8ewRZfvga # generated
CakePHP Security Salt=n8ss4YPtNCJoevCnTqm2niJpddOg6rpkMkywCMDq # generated
CakePHP Security Cipher Seed=245017463845348753867547461804 # generated
OPcache Revalidation Frequency=2
--> Creating resources with label app=cakephp-mysql-example ...
...
--> Success
OPENSHIFT
● Verify the application is
deployed by pointing the
browser to the route url
OPENSHIFT
Creating Templates
OPENSHIFT
CREATING TEMPLATES
● Multiple approaches
○ Modify an example template in YAML/JSON
○ Create objects individually, export as template and add parameters
● In this lab, you will create a database and two components and convert that to a template
● Create a new project
$ oc new-project lab7
● Create a PostgreSQL container using the provided PostgreSQL template
$ oc new-app --labels=app=lab7
--file=https://raw.githubusercontent.com/openshift/origin/master/examples/db-templates/postgresql-ephemeral-templat
e.json
OPENSHIFT
CREATING TEMPLATES
● Take note of the database name and generated username and password
--> Deploying template postgresql-ephemeral for

"https://raw.githubusercontent.com/openshift/origin/master/examples/db-templates/postgresql-ephemeral-template.json
"
With parameters:
Memory Limit=512Mi
Namespace=openshift
Database Service Name=postgresql
PostgreSQL User=userF6V # generated
PostgreSQL Password=JN7lF7KtIVTp5xxn # generated
PostgreSQL Database Name=sampledb
--> Creating resources ...
Service "postgresql" created
DeploymentConfig "postgresql" created
--> Success
Run 'oc status' to view your app.
OPENSHIFT
CREATING TEMPLATES
● Verify PostgreSQL container is running
$ oc get pods
NAME READY STATUS RESTARTS AGE
postgresql-1-h7nz4 1/1 Running 0 8m
● Create a NodeJS application as backend. Set the database info recorded in previous
steps as environment variables for the backend component
$ oc new-app https://github.com/openshift/nodejs-ex.git --name=backend --labels=app=lab7 \
-e POSTGRESQL_USER=userF6V,POSTGRESQL_PASSWORD=JN7lF7KtIVTp5xxn,POSTGRESQL_DB_NAME=sampledb
● Verify the build has been successful and the application is running
$ oc get pods
backend-1-build 0/1 Completed 0 2m
backend-1-5ozaa 1/1 Running 0 42s
OPENSHIFT
CREATING TEMPLATES
● The backend component can find and access the PostgreSQL database through the
environment variables. Verify the env vars set within the backend container
$ oc get pods | grep backend
backend-1-5ozaa 1/1 Running 0 4s
$ oc exec backend-1-5ozaa env | grep POSTGRESQL

POSTGRESQL_DB_NAME=sampledb
POSTGRESQL_PASSWORD=JN7lF7KtIVTp5xxn
POSTGRESQL_USER=userF6V
POSTGRESQL_SERVICE_PORT=5432
POSTGRESQL_SERVICE_HOST=172.30.34.200
PostgreSQL host and port env vars are set by OpenShift to inform containers about
available services within the project.
OPENSHIFT
CREATING TEMPLATES
OPENSHIFT
CREATING TEMPLATES
● Create a PHP application as frontend
$ oc new-app https://github.com/openshift/cakephp-ex.git --name=frontend --labels=app=lab7
● Verify the build has been successful and the application is running
[vagrant@rhel-cdk vagrant_data]$ oc get pods
backend-1-t8e0d 1/1 Running 0 10m
frontend-1-6q1ka 1/1 Running 0 23s
frontend-1-build 0/1 Completed 0 1m
● Scale the frontend and backend containers to 2 containers

$ oc scale dc backend --replicas=2
$ oc scale dc frontend --replicas=2
OPENSHIFT
CREATING TEMPLATES
● Create a route for the frontend service
$ oc expose service frontend --name=app --labels=app=lab7
● Now the entire application is created and ready to be exported
$ oc get pods | grep Running

backend-1-5ozaa 1/1 Running 0 43m
backend-1-bqiu6 1/1 Running 0 43m
frontend-1-6q1ka 1/1 Running 0 58m
frontend-1-swma0 1/1 Running 0 57m
postgresql-1-h7nz4 1/1 Running 0 1h
$ oc get service
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
backend 172.30.214.254 <none> 8080/TCP app=backend,deploymentconfig=backend 44m
frontend 172.30.10.30 <none> 8080/TCP app=frontend,deploymentconfig=frontend 1h
postgresql 172.30.34.200 <none> 5432/TCP name=postgresql 1h
$ oc get route
NAME HOST/PORT PATH SERVICE LABELS INSECURE POLICY TLS TERMINATION
app app-lab7.rhel-cdk.10.1.2.2.xip.io frontend app=lab7
OPENSHIFT
CREATING TEMPLATES
● Export all objects as a template
$ oc export is,dc,svc,route,bc -o yaml --as-template='lab7-template' > ~/lab7-template.yaml
● Clean up the template (remove image references, change label names, etc)
$ sed -i '.bak' -e 's/app:/application:/g' \

-e 's/image:.*backend.*/image: backend/g' \ Mac
-e 's/image:.*frontend.*/image: frontend/g' \
Linux -e 's/name:.*backend:latest/name: backend:latest/g' \
-e 's/name:.*frontend:latest/name: frontend:latest/g' \
~/lab7-template.yaml
$ sed -i -e 's/app:/application:/g' \ Linux

-e 's/image:.*backend.*/image: backend/g' \
-e 's/image:.*frontend.*/image: frontend/g' \
-e 's/name:.*backend:latest/name: backend:latest/g' \
-e 's/name:.*frontend:latest/name: frontend:latest/g' \
~/lab7-template.yaml
OPENSHIFT
CREATING TEMPLATES
● Template labels can be defined so that they get applied to every object defined in the
template. Add a template label org=internal
apiVersion: v1
kind: Template
metadata:
creationTimestamp: null
name: lab7-template
labels:
org: internal
objects:
...
OPENSHIFT
CREATING TEMPLATES
● PostgreSQL username and password are hard-coded in the template. Parametrize those
values to be generated when the template is instantiated
apiVersion: v1
kind: Template
metadata:
creationTimestamp: null
name: lab7-template
labels:
org: internal
parameters:
- description: Database user name
from: user[a-zA-Z0-9]{3}
generate: expression generate
name: DB_USERNAME
required: true
value
- description: Database user password
from: '[a-zA-Z0-9]{8}'
generate: expression
name: DB_PASSWORD
required: true
objects:
...
OPENSHIFT
CREATING TEMPLATES
● You also need to modify the PostgreSQL and backend DeploymentConfigs so that
they use the generate parameter values instead of the hard-coded ones
kind: DeploymentConfig kind: DeploymentConfig
metadata: metadata:
... ...
name: postgresql name: backend
spec: spec:
template: template:
spec: spec:
containers: containers:
- env: - env:
- name: POSTGRESQL_USER - name: POSTGRESQL_DB_NAME
value: ${DB_USERNAME} value: sampledb
- name: POSTGRESQL_PASSWORD - name: POSTGRESQL_PASSWORD
value: ${DB_PASSWORD} value: ${DB_PASSWORD}
- name: POSTGRESQL_DATABASE - name: POSTGRESQL_USER
value: sampledb value: ${DB_USERNAME}
... ...
OPENSHIFT
CREATING TEMPLATES
● Now you have a template file that can be imported to any OpenShift environment and
recreate the entire application on-demand for example for setting up new test
environments. Create a new project for test:
$ oc new-project lab7-test
● Import the template into the project

$ oc create -f ~/lab7-template.yaml
OPENSHIFT
CREATING TEMPLATES
● Create a new-application based on the template. Notice the generated values for the
template parameters
$ oc new-app lab7-template
--> Deploying template lab7-template for "lab7-template"
With parameters:
DB_USERNAME=userfPD # generated
DB_PASSWORD=QhfV17ES # generated
In order to specify value for the template parameters instead of generating them, you
can use the -p flag
$ oc new-app lab7-template -p DB_USERNAME=lab7user -p DB_PASSWORD=redhat!1
OPENSHIFT
THANK YOU
plus.google.com/+RedHat facebook.com/redhatinc
linkedin.com/company/red-hat twitter.com/RedHat
youtube.com/user/RedHatVideos

Application Onboarding Workshop: Red Hat OpenShift

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Onboarding Workshop: Red Hat OpenShift

Uploaded by

Copyright:

Available Formats

Application Onboarding

Major technical upgrade of an application landscape,

RED HAT CONSULTING

Integration & extension of new functionality by replatforming,

BPMN, Business Rules,

RED HAT CONSULTING

● Simplify and streamline application environments

New apps and features faster, focus creative

Calculate the business benefits and

INSERT DESIGNATOR, IF NEEDED

Red Hat JBoss Migration Toolkit

INSERT DESIGNATOR, IF NEEDED

Red Hat Jboss Collaboration, Consulting methodology

INSERT DESIGNATOR, IF NEEDED

Monolithic Applications Staff

● Historically grown ● SME no longer in-house

INSERT DESIGNATOR, IF NEEDED

● Highly disparate implementations across enterprise

INSERT DESIGNATOR, IF NEEDED

Processes & Governance

INSERT DESIGNATOR, IF NEEDED

Information sharing Reuse, automate, Minimalist and

INSERT DESIGNATOR, IF NEEDED

Information sharing Reuse, automate, Minimalist and

INSERT DESIGNATOR, IF NEEDED

● Central entry point for the migration

INSERT DESIGNATOR, IF NEEDED

INSERT DESIGNATOR, IF NEEDED

Information sharing Reuse, automate, Minimalist and

INSERT DESIGNATOR, IF NEEDED

Windup = open source reverse-engineering tool

● Shows a holistic picture of the Level of Effort in story points needed

INSERT DESIGNATOR, IF NEEDED

Information sharing Reuse, automate, Minimalist and

INSERT DESIGNATOR, IF NEEDED

DISCOVER DESIGN DEPLOY

Discovery Session: Define Migration Strategy, Migration Factory:

RED HAT CONSULTING

CATALOG RATIONALIZE PLAN

INSERT DESIGNATOR, IF NEEDED

Migration Project Team Structure

22 INSERT DESIGNATOR, IF NEEDED

8 Integration test 7 Deploy to Share 6 Unit test 5 Write code

1 Request a VM 2 Request a middleware platform 3 Set up the environment for

TEST Integration testing

1 Request a VM 2 Request a middleware 3 Set up the environment for

9 Get application fix 4 Build and deploy application

8 Root cause analysis 7 Production 6 Monitor the 5 Smoke test

24 RED HAT CONSULTING

8 Integration test 7 Deploy to Share 6 Unit test 5 Write code

1 Request a VM 2 Request a middleware platform 3 Set up the environment for

TEST Integration testing

Developers should focus on

OPS platform the application

9 Get application fix 4 Build and deploy application

8 Root cause analysis 7 Production 6 Monitor the 5 Smoke test

25 RED HAT CONSULTING

Quality engineers should focus on testing.

1 Request a VM 2 Request a middleware platform 3 Set up the environment for

TEST Integration testing

1 Request a VM 2 Request a middleware 3 Set up the environment for

OPS platform the application

9 Get application fix 4 Build and deploy application