Workflow comparisson Virtual vs. PAAS

|<WRAP>
**Physical**
  - Have idea
  - Get budget
  - Submit hardware acquisition request
  - Wait
  - Get hardware
  - Rack and stack hardware
  - Install operating system
  - Install OS patches/fix-packs
  - Create user accounts
  - Deploy framework/application server
  - Deploy testing tools
  - Test testing tools
  - Code
  - Configure production servers (buy them if needed)
  - Push to production
  - Launch
  - Order more servers to meet demand
  - Wait
  - Deploy new servers
  - Etc.
</WRAP>|<WRAP>
**Virtual**
  - Have  idea
  - Get budget
  - Submit VM request
  - Wait
  - Deploy framework/application server
  - Deploy testing tools
  - Test testing tools
  - Code
  - Configure production VMs
  - Push to production
  - Launch
  - Order more production VMs to meet demand
  - Wait
  - Deploy application to new VMs
  - Etc.
</WRAP>|<WRAP>
**PAAS**
  - Have idea
  - Get budget
  - Code
  - Test
  - Launch
  - Scale automatically
</WRAP>|


==== OpenSHift Architecture ====

{{https://lh3.googleusercontent.com/-FjcsgKOj4C0/Wo0tU9NSO6I/AAAAAAAAAC4/-591GHiNoy0CongXcZal7VSxZSAyMq8CACHMYCw/s0/2018-02-21_09-26-57.png}}

  * Only x86 platforms supported
    * OpenShift runs on either RHEL or Red Hat Enterprise Atomic Host
      * Nodes are instances of RHEL 7 or Red Hat Atomic Host with OpenShift installed
        * Nodes are orchestrated by masters
  * Hybrid approach supports deploying OpenShift instances across all of these infrastructures
  * OpenShift is supported anywhere that Red Hat Enterprise Linux is


|Scheduler|<WRAP>Determines placement of new pods onto nodes within OpenShift cluster.
Select best-fit node
  *     Sort nodes based on scores
  *     Select node with highest score to host pod
  *     If multiple nodes have same high score, select one at random
</WRAP>|
|Replication Controller|Ensures that specified number of pod replicas running at all times. Adds or deletes pods according to life signs.|
|OpenShift Networking|<WRAP>
  *     Container networking based on integrated Open vSwitch
  *     Platform-wide routing tier
  *     Ability to plug in third-party software-defined network (SDN) solutions
  *     Integrated with DNS and existing routing and load balancing

**Scenario**: External client points browser to myApp.cloudapps.ml.opentlc.com:80

  *     DNS resolves to host running router container
  *     Using openshift-sdn overlay network:     Router checks if route exists for request
  *     Proxies request to internal pod IP:port (10.1.2.3:8080)


**Scenario**: Pod transmits packet to pod in another node host in OpenShift environment

  *     Container sends packet to target pod using IP 10.1.2.3:8080
  *     OpenShift node uses Open vSwitch to route packet to OpenShift node hosting target container
  *     Receiving node routes packet to target container

</WRAP>|
|Route|<WRAP>
Exposes service by giving it externally reachable hostname (FQDN). 
</WRAP>|
| Router|<WRAP>
  * Router is ingress point for traffic destined for OpenShift-hosted pods
  * The Router serves routes - consumes a defined route and endpoints, identified by a service.
  * The Router serves the routing layer.
  * Router container can run on any node host in environment
</WRAP>|
| Services |<WRAP>
  * Services often used to provide permanent IP to group of similar pods
  * Internally, when accessed, services load-balance and proxy to an appropriate backing pod
  * Backing pods can be added to or removed from service arbitrarily while service remains consistently available
    * Enables anything that depends on service to refer to it at consistent internal address

</WRAP>|
| XXX |<WRAP>
</WRAP>|


===Container Deployment Workflow===

Scenario: New application requested via CLI, web console, or API

==OpenShift API/authentication layer:==

  * Approves request, considering user’s permissions, resource quotas, and other information
  * Creates supporting resources: deployment configuration, replication controllers, services, routes, and persistent storage claims

==OpenShift scheduling layer:==

  * Designates node host for each pod, considering resources' availability and load and application spread between nodes for application high availability

==OpenShift node:==

  * Pulls down image to be used from external or integrated registry
  * Starts container (pod) on node



==== OpenShift CICD ====


== Update Rollout strategies ==

|Rolling Update|Pre life cycle hook. Scale up/down new/old pods one by one. Wait for readiness checks. Post life cycle hooks. No downtime.|
|Recreate| Scale down all old. Scale up all new. Has downtime.|


== Concepts ==

| BuildConfig |<WRAP>
Definition of the entire build process as code.
</WRAP>|
| Build Strategies|<WRAP>
Build strategies for building artifacts. Artifact resulting from build depends on builder used to create it.
  *     Docker build
  *     Source-to-Image (S2I) build
  *     Custom build
  *     Pipeline build (Tech-preview in OCP 3.3)

For Docker and S2I builds, resulting objects are runnable images.
For custom builds, resulting object are whatever builder image author specified.

</WRAP>|
| Source-to-Image (S2I) Build|<WRAP>
  * Source-to-Image (S2I) is tool for building reproducible Docker images
  * Produces ready-to-run images by injecting application source into Docker image and assembling new Docker image
  * New image incorporates base image (builder) and built source and is ready to use with docker run command

Reproducability. S2I supports incremental builds, which reuse previously downloaded dependencies, previously built artifacts, etc. 

Security. Builds and runs are executed as root, which may be exposed. S2I can execute commands with less rights.

</WRAP>|
| Image Stream |<WRAP>
Docker images from different sources, identified by the same tag. \\
Can be monitored, to trigger a build as a result.
</WRAP>|
| Jenkins pipeline |<WRAP>
  * A Jenkins can be used to build artifacts via OPenShift.
  * A Jenkins strategy is chose in BuildConfig
  * A Jenkins-Pipeline is defined as code in BuildConfig

During the build the following will then happen
  * A Jenkins will be started in a container and reused by all Jobs with the Jenkins-build-strategy.
  * A Pipeline will be created.
  * An image will be build.
  * An image will be put into the registry.
  * Then optionally, via trigers, the pod can be replaced by new pods with the container from new image.

Build via OpenShift pipelines:
{{https://developers.redhat.com/blog/wp-content/uploads/2016/12/FireShot-Capture-50-OpenShift-Web-Console_-https___192.168.123.1_8443_console-1024x174.png}}

More:
https://developers.redhat.com/blog/2017/01/09/using-pipelines-in-openshift-3-3-for-cicd/

</WRAP>|
| XXX |<WRAP>
</WRAP>|
| XXX |<WRAP>
</WRAP>|
| XXX |<WRAP>
</WRAP>|
| XXX |<WRAP>
</WRAP>|
==== API ====


<code>


# list pods
oc get pod

</code>