OpenShift实战：自动化部署与管理指南

需积分: 10 82 浏览量更新于2024-07-18 收藏 5.71MB PDF 举报

"Deploying to OpenShift" 是一本由Graham Dumpleton撰写的书籍，主要关注Red Hat的OpenShift平台，这是一个基于容器的软件部署和管理平台，提供了一个安全的多租户环境，适用于企业级应用。这本书深入介绍了如何利用OpenShift（建立在Kubernetes之上）自动化创建、分发和运行应用程序的方式，特别适合开发者和管理员，帮助他们学习如何在OpenShift中运行、访问和管理容器，以及如何大规模地编排这些容器。书中详细涵盖了以下关键知识点： 1. **构建应用容器镜像**：讲解如何从源代码构建并部署应用容器镜像，这是将应用程序转化为可以在OpenShift上运行的格式的基础步骤。 2. **实现和扩展应用镜像构建器**：介绍如何定制和扩展OpenShift的构建过程，以适应不同项目的需求。 3. **增量和链式构建**：通过这种方法，可以显著加快构建速度，提高开发效率。 4. **自动化构建流程**：利用webhook将OpenShift与Git仓库连接，实现在代码更改时自动触发构建，提高持续集成和持续部署(CI/CD)的效率。 5. **配置和秘密管理**：将应用的配置和敏感信息作为项目资源添加到容器中，确保安全且易于管理。 6. **外部访问应用**：学习如何让应用程序暴露在OpenShift集群之外，使外部用户或系统能够访问应用服务。 7. **管理持久存储**：在OpenShift容器内处理持久化数据存储，确保数据在容器重启或迁移后仍然可用。 8. **监控应用健康**：了解如何监测应用的运行状态，以便及时发现并解决性能问题。 9. **管理应用生命周期**：包括启动、更新、扩展、故障恢复等，确保应用的稳定性和高可用性。本书是《OpenShift for Developers: A Guide for Impatient Beginners》的理想补充，针对忙碌的开发者提供了实用的指导，旨在帮助读者快速掌握OpenShift的使用，无论是对于云原生应用还是传统的有状态应用，都能提供有力的支持。这本指南将帮助IT专业人员更好地理解和利用OpenShift的强大功能，提升他们在容器化环境中的部署和管理能力。无论是开发人员希望优化他们的CI/CD流程，还是管理员寻求更有效地管理多租户环境，这本书都是一份宝贵的参考资料。

The Role of Containers

The National Institute of Standards and Technology (NIST) defines as part of their

definition of cloud computing three standard service models for the provision of

cloud computing services:

Soware as a Service (SaaS)

The capability provided to the consumer is to use the provider’s applications run‐

ning on a cloud infrastructure. The applications are accessible from various client

devices through either a thin client interface, such as a web browser (e.g., web-

based email), or a program interface. The consumer does not manage or control

the underlying cloud infrastructure including network, servers, operating sys‐

tems, storage, or even individual application capabilities, with the possible excep‐

tion of limited user-specific application configuration settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastruc‐

ture consumer-created or acquired applications created using programming lan‐

guages, libraries, services, and tools supported by the provider. The consumer

does not manage or control the underlying cloud infrastructure including net‐

work, servers, operating systems, or storage, but has control over the deployed

applications and possibly configuration settings for the application-hosting envi‐

ronment.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, net‐

works, and other fundamental computing resources where the consumer is able

to deploy and run arbitrary software, which can include operating systems and

applications. The consumer does not manage or control the underlying cloud

infrastructure but has control over operating systems, storage, and deployed

applications; and possibly limited control of select networking components (e.g.,

host firewalls).

Under these traditional definitions for cloud service computing models, OpenShift

would be classified a PaaS. In both PaaS and SaaS models, containerization is often

used for separating applications from each other and from different users.

Containers as a technology have a long history, with forerunners being FreeBSD jails

and Solaris Zones. In Linux, support for containers revolves around the Linux Con‐

tainers project (LXC). This brought user-space tooling on top of Linux kernel features

such as cgroups and namespaces, with security additions from Seccomp and SELinux.

The LXC tools made the use of containers in Linux accessible, but it could still be a

fiddly process to set up and run applications in containers.

2 | Chapter 1: The OpenShift Container Platform

In 2013 a company called dotCloud, a PaaS provider, announced in a lightning talk at

PyCon US a tool called Docker. This tool was an outgrowth of the proprietary tech‐

nology that dotCloud used to help run applications in containers; it provided a wrap‐

per for making it easier to launch applications in containers using LXC.

The Docker tool was quickly picked up by developers as it addressed two key issues.

The first was a definition of a common packaging format for an image, which con‐

tained an application and all the dependencies it required, including operating system

libraries and programs. The second was tooling for building this image.

These together made it possible to create application images that could be easily

moved between different systems, to then be run in a container, with higher confi‐

dence that they would work out of the box.

The technology around the Docker tool was split out separately from the company

dotCloud and a new company, Docker Inc., was created to manage development of

the technology. Because of the growing interest in the technology, the Open Contain‐

ers Initiative (OCI) was later formed to provide an open governance structure for the

express purpose of creating open industry standards around the container format and

runtime. This process was seeded with specifications derived from the Docker tool.

OCI currently acts as the steward for two specifications: the Runtime Specification

(runtime-spec) and the Image Specification (image-spec).

Orchestrating at Scale

The Docker tool made it easier for developers to build application images and run a

single application in a container on a single host. But scaling up an application to

have multiple instances running on the same host, or across multiple hosts, required

additional software components to help orchestrate the deployment and running of

the application, as well as a router to load-balance traffic to each instance of the appli‐

cation.

During the initial phase of Docker adoption, no out-of-the-box solutions existed for

the orchestration and routing layer, which resulted in users handcrafting homegrown

solutions.

In mid-2014, Google announced the Kubernetes project, an open source system for

automating deployment, scaling, and management of containerized applications. This

provided one of the missing components required in trying to handle running con‐

tainers at scale.

At the time, Red Hat was already well into a project to reimplement OpenShift

around Docker but had been implementing its own orchestration layer. With the

announcement of Kubernetes, Red Hat decided to drop its own efforts, adopting

Kubernetes and becoming a major contributor to the project.

Orchestrating at Scale | 3

剩余161页未读，继续阅读

seecsea

粉丝: 3
资源: 25

OpenShift实战：自动化部署与管理指南

【开源容器云OpenShift：构建基于Kubernetes的企业应用云平台】 文前.pdf

【开源容器云OpenShift：构建基于Kubernetes的企业应用云平台】 正文.pdf

OpenShift笔记-V3.5.pdf

machine trading_deploying computer algorithms to conquer the markets.pdf

You are running Vue in development mode. Make sure to turn on production mode when deploying for production. See more tips a

You are running Vue in development mode. Make sure to turn on production mode when deploying for production.

scrapyd-deploy question Packing version 1686490650 Deploying to project "dingdian_info" in http://localhost:6800/addversion.json Deploy failed: <urlopen error [WinError 10061] 由于目标计算机积极拒绝，无法连接。>

You are running Vue in development mode. Make sure to turn on production mode when deploying for production问题解决

cloud to use to build image

最新资源

【开源容器云OpenShift：构建基于Kubernetes的企业应用云平台】文前.pdf

【开源容器云OpenShift：构建基于Kubernetes的企业应用云平台】正文.pdf