Openshift Book Guide for Cloud-Native Applications

Developing cloud-native applications requires a container orchestration platform that can handle scalability, high availability, and automation. OpenShift is a leading platform for building and deploying cloud-native applications.

OpenShift is built on top of Kubernetes, the industry-standard container orchestration system. This means that OpenShift inherits all the benefits of Kubernetes, including scalability, high availability, and automation.

To get started with OpenShift, you need to have a basic understanding of Docker and Kubernetes. Docker is a containerization platform that allows you to package your application and its dependencies into a single container, while Kubernetes provides the orchestration layer to manage and scale your containers.

OpenShift provides a web-based console for managing and deploying applications, as well as a command-line interface (CLI) for automating tasks.

To deploy an application, you need a builder image. This is a fundamental requirement for getting started with OpenShift.

A container platform is made up of a container runtime and an orchestration engine, such as Kubernetes (k8s). Containers are isolated from each other, with their own mounted filesystems, shared memory resources, and network resources.

Each container shares the same Linux kernel as the host machine, but has its own isolated environment. Containers use server resources more effectively, increasing application density and making it easier to scale up or down with an integrated load balancer.

Here are some key components of a container platform:

In OpenShift, the master/node architecture is used to manage containers and applications. The master node is responsible for managing the cluster, while the node nodes run the containers and applications.

OpenShift provides multiple ways to interact with it, including REST API, Web UI, and CLI.

To get started with OpenShift, you'll need to understand its core concepts. This includes projects, which are logical groups that collect applications and help with security.

A project in OpenShift can contain various application components, such as custom container images, image streams, application pods, build configs, deployment configs, deployments, and services.

Here are the various application components you can expect to find in a project:

To create a custom container image, you'll need to combine a build config, source code, and a builder image.

Image streams are used to monitor changes and trigger builds and deployments as needed.

A deployment config defines how to deploy an application, which results in unique deployments per app version. Each deployment is made up of one or more pods, which are essentially the application running in a container. Services provide a way to access the application, while load balancers map routes to the deployed application.

OpenShift uses docker to create and manage containers. Containers are discrete, portable, scalable units that are isolated from other containers.

Each container shares the same Linux kernel as the VM it's running on, but has its own isolated environment. This allows containers to use server resources more effectively and increase application density.

Containers are stateless, meaning they don't store any data and need a separate storage solution. This makes it easy to scale up and down with an integrated load balancer.

A pod is a logical host for one or more containers, and its lifecycle can be Pending, Running, Succeeded, Failed, or Unknown. OpenShift uses a service to connect multiple pods and map to an IP address on one or more nodes in the cluster.

The service acts as a proxy, allowing users to access applications through a routing layer that manages and shares IP addresses. OpenShift uses software-defined networking (SDN) to manage network resources.

Each node in the cluster has its own virtualized Linux kernel, and OpenShift uses a build pod to combine a builder image with application code. The application is then deployed on nodes, and a service is created to connect it to the routing layer.

Linux is the foundation of container technology, and understanding its basics is essential for working with containers. Linux provides several kernel components for isolation, including namespaces, control groups (cgroups), and SELinux contexts.

Linux namespaces allow for the isolation of applications within containers, while cgroups limit CPU and memory usage. SELinux contexts further limit access to system resources.

Kernel components for isolation are crucial for secure containerization. Linux namespaces include mount, network, own process counters, own host name and domain name, and shared memory.

Here are some key Linux namespaces:

Control groups (cgroups) provide a mechanism for resource limitation, allowing for efficient resource utilization. Docker uses cgroups to control resource utilization per container.

Linux-based containerization relies on low-level kernel technologies, making it efficient and scalable. Linux containers use standard features of the Linux kernel, including namespaces and control groups.

Containers are stateless, meaning you can bring them up and down without affecting your application's performance.

This stateless nature makes it easy to create or destroy containers at any time, without worrying about the impact on your application.

One of the greatest features of containers is their ability to be brought up and down without affecting your application's performance.

Deploying cloud-native applications on OpenShift is a straightforward process. To get started, you'll need to create a project and import a template into it. From there, you can instantiate the application from the template.

One of the key benefits of working with OpenShift is the hands-on experience you'll gain with Kubernetes and Docker. This will help you learn how to deploy and manage applications in a cloud-based environment.

To give you a better idea of what you can accomplish with OpenShift, here are some of the key benefits:

Deploying cloud-native applications is a straightforward process. You can deploy an application in OpenShift by creating a project, importing a template into the project, and instantiating the application from the template.

To get hands-on experience with Kubernetes and Docker, you can follow the steps to deploy an application in OpenShift. This will give you a solid understanding of how to deploy and manage applications in OpenShift.

If you're looking to gain hands-on experience with Kubernetes and Docker, you can start by deploying an application in OpenShift. This will also give you a practical approach to managing applications on a cloud-based platform.

Some key benefits of deploying cloud-native applications in OpenShift include gaining hands-on experience with Kubernetes and Docker, learning how to deploy and manage applications, and getting a practical approach to managing applications on a cloud-based platform.

Here are some specific benefits you can expect from deploying cloud-native applications in OpenShift:

Working with Services is a crucial aspect of building Cloud-Native Applications. You can use Replication Controllers to scale up and down your application, and describe replicas for your application in advanced info as YAML.

Replication Controllers use selectors to find labeled pods to manage. This allows for a decoupled API component, avoiding stateful information and looping through control loops against various microservices.

Pods are tracked by labels and selectors, which can define a bi-directional relationship between pods. This enables efficient management of your application.

Here's a brief overview of the objects in OpenShift:

Users access your application through the routing layer, which gets pod IP addresses from the OpenShift API server. This allows the routing layer to connect directly to the presentation layer pod on user access, without an extra hop through the service.

To scale pods, you can use Liveness probes, which check for HTTP Checks, Container execution check, and TCP socket check. Readiness probes check if a container is ready to receive traffic.

Avoid using environment variables for service discovery, as it's a bad idea. Instead, use the OpenShift API server to manage your services and pods.

Application Isolation is a crucial aspect of Cloud-Native Applications. It ensures that different applications can co-exist on the same Operating System without affecting each other.

Imagine having ten different applications hosted on the same server, each with its own dependencies. Updating one application can easily break the others.

Containers and virtualization provide environment isolation for your applications, solving the issue of different versions of the same package. This is especially important for customer-facing and content-sensitive applications.

With container technology like Docker, you can isolate applications and other computer resources libraries from each other. This allows you to update and patch your containerized applications independently of each other.

In a CI/CD pipeline, container images are the centerpiece, reducing deployment risk on production and allowing for easy rollbacks to previous versions. Container images can be promoted to higher environments using image tagging.

Image streams are used to solve the problem of consistent application deployment when an application consists of more than one container. This involves marking containers with new tags to trigger new deployments in test environments.

To combine projects, you need to give pull permissions, such as allowing the test environment to pull containers from the development environment, but not vice versa. This is necessary for moving deployments between environments using image stream triggers.

Deployment strategies include Rolling, Re-create, Blue/Green, Canary, and Dark launches. OpenShift uses YAML as its configuration format.

Autoscaling with metrics is a crucial aspect of managing workloads in a containerized environment. Determining expected workloads is difficult, making autoscaling a necessary feature.

To enable autoscaling, you need a metrics stack, which can be hawkular, heapster, cassandra, or in the future, Prometheus. The Horizontal Pod Autoscaler (HPA) component is responsible for autoscaling in OpenShift.

CPU is measured in OpenShift as millicore, which is 1/1000 of a core. Resource request specifies the resources needed, while resource limit sets the maximum resources provided.

Apache Benchmark can be used to generate load and test autoscaling. There are parameters to avoid thrashing by autoscaling, which is essential for stable operation.

CI/CD is a crucial part of the development process, and OpenShift makes it easier to manage. Container images are the centerpiece of a CI/CD pipeline.

In OpenShift, container images are tested and installed on production, reducing deployment risk. This means that you can be sure that the same binary is running on production as it was on development.

You can easily roll back to a previous version of your container if something goes wrong. This is a huge advantage over traditional deployment methods.

Image tagging is used to promote containers to higher environments, such as from development to acceptance. This makes it easy to move your container from one environment to another.

Webhooks from Git can trigger OpenShift builds, automating the deployment process. This saves time and reduces the risk of human error.

You can't patch an application in a container, as changes won't persist. This means that you need to rebuild your container whenever you make changes to the application.

Image streams are a concept in OpenShift that helps solve the problem of consistent application deployment when an application consists of multiple containers.

Deploying a CI/CD pipeline with OpenShift involves creating a container image that serves as the centerpiece of the pipeline. This image is tested and installed on production, reducing deployment risk.

You can't patch an application in a container since changes won't persist, so you need to rebuild it. Image streams are used to solve the problem of consistent application deployment when an application consists of more than one container.

To deploy OpenShift, you can choose from various deployment models, including OpenShift Dedicated, Azure Red Hat OpenShift, and Red Hat OpenShift on IBM cloud. Each model has its own description and benefits.

A fully managed instance of OpenShift on AWS or GCP is available through OpenShift Dedicated. Azure Red Hat OpenShift offers a managed instance of OpenShift on Azure cloud. Red Hat OpenShift on IBM cloud provides a fully managed OCP service on the IBM cloud.

Red Hat Code Ready Containers is a way to deploy a local instance of OpenShift to your laptop or test machine. However, be aware that Code Ready Containers are not viable for production deployment.

Here are the different OpenShift deployment models:

You can install SEP on OpenShift using one of the following methods: Starburst's Kubernetes deployment or Starburst's certified operator in the OpenShift Operator Hub.

To manage containers using the Docker CLI, start by checking if any containers are already running with the docker ps command. This gives you a quick overview of your container status.

The docker run command is used to run a container from an image, but be aware that containers cannot be left running in the foreground. You'll need to send a TERM signal (Ctrl + C) to kill it.

To execute commands inside a container, use the docker exec command with options like -i and -t to interact with the container. This allows you to run a Docker without dropping into the container, and you can enter the container by using -i and -t options.

You can fall into the container bash CLI by executing the docker exec command with the -it option, from which you can execute other general Linux commands. To exit the container console, simply type exit or press Ctrl + D.