Differences

This shows you the differences between two versions of the page.

--- openshift [2018/02/21 08:57] – [API] skipidar
+++ openshift [2020/12/27 20:35] (current) – external edit 127.0.0.1
@@ Line 63: / Line 63: @@
   * OpenShift is supported anywhere that Red Hat Enterprise Linux is
-==== OpenSHift UX ====
+|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
@@ Line 69: / Line 134: @@
+== 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 ====