Tohuwabohu excorcism

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

• 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

Exposes service by giving it externally reachable hostname (FQDN).

• 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

• 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

Definition of the entire build process as code.

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.

• 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.

Docker images from different sources, identified by the same tag.
Can be monitored, to trigger a build as a result.

• 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:

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