OpenShift Concepts TODEPLETE: Difference between revisions
| Line 198: | Line 198: | ||
S2I allows to build the application consistently if an underlying image needs a patch due to a security issue. | S2I allows to build the application consistently if an underlying image needs a patch due to a security issue. | ||
A Git repository URL and a builder image must be specified to start a S2I build. | <font color=red>A Git repository URL and a builder image must be specified to start a S2I build.</font> | ||
===Custom Build=== | ===Custom Build=== | ||
Revision as of 20:50, 30 April 2017
Internal
Overview
OpenShift is supported anywhere RHEL is: bare metal, virtualized infrastructure (Red Hat Virtualization, vSphere, Hyper-V), OpenStack platform, public cloud providers (Amazon, Google, Azure). It runs on RHEL and Red Hat Atomic.
OpenShift Hosts
Master
A master is a RHEL or Red Hat Atomic host that orchestrates and schedules resources. It maintains the state of the OpenShift environment. Multiple masters can be present to insure HA.
The master provides the single API all tooling clients must interact with.
The access is protected via fine-grained role-based access control (RBAC).
The master monitors application health via user-defined pod probes. It handles restarting pods that failed probes automatically. Pods that fail too often are marked as "failing" and are temporarily not restarted. The OpenShift service layer sends traffic only to healthy pods.
Node
A node is a RHEL or Red Hat Atomic Host where applications run inside containers. Nodes are orchestrated by masters. The node daemon runs on node.
Container
All application instances run inside containers on the nodes. For more details, see Docker Containers.
The node Daemon
Pod
Pod Probe
Users can configure pod probes for liveness or readiness.
Storage
Volume
etcd
Scheduler
Docker Registry
OpenShift contains an integrated Docker registry. Users push images into registry and whenever a new image is stored in the registry, the registry notifies OpenShift about it and passes along image information such as the namespace, the name and the image metadata.
Service
Service Layer
The service layer provides an abstraction of service endpoints and internal load balancing.
API
Label
Selector
Replication Controller
Networking
Router
The router component routes external requests to applications inside the OpenShift environment. The router is the ingress point for all traffic destined for OpenShift services. Runs in a container on any node in an OpenShift environment.
Route
A route is a way to expose a service by giving it an externally reachable hostname. A route is a mapping of an FQDN and path to the endpoints of a service. Each route consist of a route name, a service selector and an optional security configuration.
Routing Layer
The routing layer cooperates with the service layer. It runs in pods and it provides automated load balancing to pods, and routing around unhealthy pods. The routing layer is pluggable and extensible.
Projects
Projects allows groups of users to work together, define ownership of resources and manage resources. The project restricts and tracks use of resources with quotas and limits. A project is a Kubernetes namespace with additional annotations.
A project lets a community of users to organize and manage their content in isolation from other communities.
Each project has its own set of:
Objects
The objects include pods, services, replication controllers, etc.
User Accounts
Are created upon login or via the API and represented with the User object.
System Users
These users are created automatically when the infrastructure is defined, for the purpose of enabling the infrastructure to interact with the API securely. The cluster administrator has access to everything.
Service Accounts
Non-human users that act automatically with designated access to objects in their projects or other projects.
Group
Policies
Constraints
Constraints are quotas for each kind of object that can be limited.
Resources
- cpu, requests.cpu
- memory, requests.memory
- limits.cpu
- memory.cpu
- pods
- replicationcontrollers
- resourcequotas
- services
- secrets
- configmaps
- persistentvolumeclaims
- openshif.io/imagestreams
Resource Quota
ResourceQuota object enumerates hard resource usage limits per project.
ClusterResourceQuotaobject enumerates hard resource usage limits across the cluster.
Operations:
Template
A template describes a set of objects that can be parameterized and processed to produce a list of objects for creation in OpenShift. The template can be processed to create anything within a project, provided that permissions exist. The template may define a set of labels to apply to every object defined in the template.
CICD Support
OpenShift enables DevOps. It has built-in support for the Jenkins CI server, providing a native way of doing CICD.
OpenShift can integrate with Git-based source code repositories. When a developer pushes code to the GIt repository, Jenkins pulls the code and performs a project build. After the build is complete, Jenkins invokes the OpenShift master node API to initiate a "source-to-image" (S2I) build. As part of the SI process, the latest project artifact is downloaded from Jenkins and included in the image that runs in the OpenShift node.
Source-to-Image (S2I)
Build
Build Config
A BuildConfig object is the definition of an entire build. It contains the specification of triggers, which specify events for invoking builds, for example when a newer base image is available, or new deployments.
OpenShift creates Docker containers from build images and pushes the to an integrated registry.
oc new-app creates a BuildConfig object.
Build Strategy
Docker Build
The Docker build expects repository with Dockerfile and all artifacts required to produce runnable image. It invokes the docker build command, and the result is a runnable image.
Source-to-Image (S2I) Build
It is a tool for building reproducible Docker images, which produces runnable images by injecting application source into a Docker image and assembling a new Docker image. The new image incorporates the base image and the built source code and it is ready to use with the docker run command. S2I supports incremental builds, which reuse previously downloaded dependencies, previously built artifacts, etc.
S2I scripts can be written to inject application code into almost any existing Docker image.
The assemble process can perform a large number of complex operations without creating a new layer at each step, resulting in a fast process.
S2I allows to build the application consistently if an underlying image needs a patch due to a security issue.
A Git repository URL and a builder image must be specified to start a S2I build.
Custom Build
The custom build strategy allows to define a specific builder image responsible for the entire build process, which allows you to customize the build process.
The custom builder image is a plain Docker image embedded with build process logic.
Pipeline Build
The pipeline build strategy allows developers to define a Jenkins pipeline for execution by Jenkins pipeline plugin.
Deployment
Deployments allow rollbacks to previous versions of an application.
Deployment Configuration
A deployment configuration is a user-defined template for running applications.
The OpenShift environment creates a replication controller to run the application in response to a deployment configuration. The deployment configuration contains a version number that is incremented each time a replication controller is created from the configuration.
Support automatic rolling back to the last successful revision of configuration, in case the current template fails to deploy.
Deployment Strategy
The deployment configuration defines a deployment strategy. The deployment strategy determines the deployment process. It uses readiness checks to determine if a new host is ready for use. If the readiness check fails, the deployment configuration retries until it times out.
Rolling Deployment Strategy
The default deployment strategy. It performs rolling updates. It supports life-cycle hooks for injecting code into the deployment process.
It consists in the following steps:
- Execute the "pre" life-cycle hook.
- Scale up new deployment by one or more pods, based on maxSurge value.
- Wait for readiness checks to complete.
- Scale down the old deployment by one or more pods, based on maxUnavailable value.
- Repeat scaling until the new deployment reaches desired replica count and the old deployment has scaled to zero.
- Execute any "post" life-cycle hook.
Recreate Deployment Strategy
It consists in the following steps:
- Execute "pre" life-cycle hook.
- Scale own previous deployment to zero.
- Scale up new deployment.
- Execute "post" life-cycle hook.
Custom Deployment Strategy
Image Stream
An image stream is a number of Docker images identified by tags. It is similar to a Docker image repository. builds and deployments can watch an image stream to receive notifications when new images are added and react by performing a build or a deployment.
Pipeline
A pipeline is a Jenkins jobs enabled by the pipeline plugin.
Used by the pipeline build.