OpenShift – 快速指南
OpenShift – 快速指南
OpenShift – 概述
OpenShift 是由 Red Hat 托管的云开发平台即服务 (PaaS)。它是一个开源的基于云的用户友好平台，用于创建、测试和运行应用程序，并最终将它们部署在云上。
OpenShift 能够管理用不同语言编写的应用程序，例如 Node.js、Ruby、Python、Perl 和 Java。OpenShift 的关键特性之一是它是可扩展的，这有助于用户支持用其他语言编写的应用程序。
OpenShift 带有各种虚拟化概念作为其抽象层。OpenShift 背后的基本概念基于虚拟化。
虚拟化
一般而言，虚拟化可以定义为虚拟系统的创建，而不是从系统、存储或操作系统开始的任何事物的物理或实际版本。虚拟化的主要目标是使 IT 基础架构更具可扩展性和可靠性。虚拟化的概念已经存在了几十年，随着当今 IT 行业的发展，它可以应用于从系统级、硬件级到服务器级虚拟化的广泛层次。
这个怎么运作
它可以描述为一种技术，其中任何应用程序或操作系统都从其实际物理层中抽象出来。虚拟化技术的一个关键用途是服务器虚拟化，它使用称为管理程序的软件从底层硬件中抽象出该层。在虚拟化上运行的操作系统的性能与其在物理硬件上运行时的性能一样好。然而，虚拟化的概念很流行，因为大多数系统和应用程序运行不需要使用底层硬件。
物理与虚拟架构
虚拟化类型
-
应用程序虚拟化– 在这种方法中，应用程序是从底层操作系统中抽象出来的。这种方法非常有用，应用程序可以独立运行而无需依赖于底层的操作系统。
-
桌面虚拟化– 此方法用于减少工作站负载，在其中可以使用桌面上的瘦客户端远程访问桌面。在这种方法中，桌面大多运行在数据中心。一个典型的例子是在大多数组织中使用的虚拟桌面映像 (VDI)。
-
数据虚拟化– 它是一种抽象和摆脱传统数据和数据管理方法的方法。
-
服务器虚拟化– 在这种方法中，与服务器相关的资源被虚拟化，包括物理服务器、进程和操作系统。支持这种抽象的软件通常称为管理程序。
-
存储虚拟化– 这是将多个存储设备汇集到一个由单个中央控制台管理的单个存储设备的过程。
-
网络虚拟化– 这是一种通过拆分可用带宽和通道来组合所有可用网络资源的方法，每个可用带宽和通道彼此独立。
开班
OpenShift 是一个支持云的应用程序平台即服务 (PaaS)。它是一种开源技术，可帮助组织将其传统应用程序基础架构和平台从物理、虚拟介质迁移到云。
OpenShift 支持种类繁多的应用程序，可以在 OpenShift 云平台上轻松开发和部署这些应用程序。OpenShift 基本上支持三种平台供开发者和用户使用。
基础设施即服务 (IaaS)
在这种格式中，服务提供商提供具有一些预定义虚拟硬件配置的硬件级虚拟机。这个领域有多个竞争对手，从 AWS 谷歌云、Rackspace 等等开始。
经过漫长的设置和投资过程后，拥有 IaaS 的主要缺点是，仍然需要负责安装和维护操作系统和服务器包、管理基础设施网络以及负责基本系统管理。
软件即服务 (SaaS)
使用 SaaS，人们最不担心底层基础设施。它就像即插即用一样简单，用户只需注册服务并开始使用它。这种设置的主要缺点是，您只能执行服务提供商允许的最少量定制。SaaS 最常见的例子之一是 Gmail，用户只需要登录并开始使用它。用户还可以对其帐户进行一些小的修改。但是，从开发人员的角度来看，它并不是很有用。
平台即服务 (PaaS)
它可以被视为介于 SaaS 和 IaaS 之间的中间层。PaaS 评估的主要目标是开发人员，其中开发环境可以通过一些命令来启动。这些环境的设计方式使其可以满足所有开发需求，从拥有带有数据库的 Web 应用程序服务器开始。为此，您只需要一个命令，服务提供商就会为您完成这些工作。
为什么要使用 OpenShift？
OpenShift 为企业单位提供了一个通用平台，可以在云上托管其应用程序，而无需担心底层操作系统。这使得在云上使用、开发和部署应用程序变得非常容易。关键特性之一是，它为各种开发和测试提供托管硬件和网络资源。借助 OpenShift，PaaS 开发人员可以根据规范自由地设计所需的环境。
在涉及服务计划时，OpenShift 提供了不同类型的服务级别协议。
免费– 此计划仅限三年，每个计划有 1GB 空间。
青铜– 此计划包括 3 年，并以每年 1GB 的空间扩展到 16 年。
Sliver – 这是青铜的 16 年计划，但具有 6GB 的存储容量，无需额外费用。
除了上述功能外，OpenShift 还提供称为 OpenShift Enterprise 的本地版本。在 OpenShift 中，开发人员可以设计可扩展和不可扩展的应用程序，这些设计是使用 HAproxy 服务器实现的。
特征
OpenShift 支持多种功能。他们中很少有人 –
- 多语言支持
- 多数据库支持
- 可扩展墨盒系统
- 源代码版本管理
- 一键部署
- 多环境支持
- 标准化开发人员的工作流程
- 依赖和构建管理
- 自动应用扩展
- 响应式 Web 控制台
- 丰富的命令行工具集
- 远程 SSH 登录到应用程序
- 休息 API 支持
- 自助点播应用程序栈
- 内置数据库服务
- 持续集成和发布管理
- 集成开发环境
- 应用程序的远程调试
OpenShift – 类型
OpenShift 从其名为 OpenShift V2 的基础开始存在，它主要基于年份和墨盒的概念，其中每个组件从机器创建到应用程序部署，从构建到部署应用程序都有其规范。
Cartridges – 它们是从环境运行它们所需的应用程序类型以及本节中满足的所有依赖项开始构建新应用程序的焦点。
year – 可以定义为对资源、内存和 CPU 具有一定规格的熊金属机器或服务器。它们被认为是运行应用程序的基本单元。
应用程序– 这些只是指将在 OpenShift 环境中部署和运行的应用程序或任何集成应用程序。
随着本节的深入，我们将讨论 OpenShift 的不同格式和产品。在早期，OpenShift 有三个主要版本。
OpenShift Origin – 这是OpenShift的社区添加或开源版本。它也被称为其他两个版本的上游项目。
OpenShift Online – 它是托管在 AWS 上的公共 PaaS 即服务。
OpenShift Enterprise – 是带有 ISV 和供应商许可证的强化版 OpenShift。
OpenShift 在线
OpenShift online 是 OpenShift 社区的一种产品，使用它可以在公共云上快速构建、部署和扩展容器化应用程序。它是 Red Hat 的公共云应用程序开发和托管平台，可实现应用程序的自动配置、管理和扩展，帮助开发人员专注于编写应用程序逻辑。
在 Red Hat OpenShift Online 上设置帐户
第 1 步– 转到浏览器并访问网站https://manage.openshift.com/
第 2 步– 如果您有 Red Hat 帐户，请使用以下 URL 使用 Red Hat 登录 ID 和密码登录 OpenShift 帐户。https://developers.redhat.com
第 3 步– 如果您没有 Red Hat 帐户登录，请使用以下链接注册 OpenShift 在线服务。
登录后，您将看到以下页面。
准备好所有内容后，Red Hat 将显示一些基本帐户详细信息，如下面的屏幕截图所示。
最后，当您登录时，您将看到以下页面。
OpenShift 容器平台
OpenShift 容器平台是一个企业平台，可帮助开发和 IT 运营团队等多个团队构建和部署容器化基础设施。OpenShift 内置的所有容器都使用非常可靠的 Docker 容器化技术，可以部署在任何公共托管云平台的数据中心。
OpenShift 容器平台的正式名称为 OpenShift Enterprises。它是一个 Red Hat 内部私有平台即服务，建立在由 Docker 提供支持的应用程序容器的核心概念之上，其中的编排和管理由 Kubernetes 管理。
换句话说，OpenShift 将 Docker 和 Kubernetes 结合到了企业级。它是一个容器平台软件，供企业单位在自己选择的基础设施中部署和管理申请人。例如，在 AWS 实例上托管 OpenShift 实例。
OpenShift 容器平台有两个包级别。
OpenShift Container Local – 这适用于希望在本地机器上部署和测试应用程序的开发人员。该软件包主要由开发团队用于开发和测试应用程序。
OpenShift Container Lab – 这是为从开发到部署到预生产环境的应用程序扩展评估而设计的。
OpenShift 专用
这是 OpenShift 产品组合中添加的另一个产品，其中客户可以选择在他们选择的任何公共云上托管容器化平台。这为最终用户提供了真正意义上的多云产品，他们可以在满足其需求的任何云上使用 OpenShift。
这是 Red Hat 的最新产品之一，最终用户可以使用 OpenShift 在托管在云上的 OpenShift 上构建测试部署和运行他们的应用程序。
OpenShift 专用的功能
OpenShift 专用在公共云上提供定制的解决方案应用平台，它继承自 OpenShift 3 技术。
-
可扩展和开放– 这是建立在 Docker 的开放概念之上并部署在云上的，因此它可以在需要时自行扩展。
-
可移植性– 由于它是使用 Docker 构建的，因此在 Docker 上运行的应用程序可以轻松地从一个地方运送到另一个支持 Docker 的地方。
-
编排– 在 OpenShift 3 中，容器编排和集群管理的关键特性之一是使用 Kubernetes 支持的，Kubernetes 随 OpenShift 版本 3 一起提供。
-
自动化– 此版本的 OpenShift 具有源代码管理、构建自动化和部署自动化的功能，这使其作为平台即服务提供商在市场上非常受欢迎。
OpenShift 的竞争对手
Google App Engine – 这是 Google 用于开发和托管网络应用程序的免费平台。Google 的应用引擎提供了快速的开发和部署平台。
Microsoft Azure – Azure 云由 Microsoft 在其数据中心托管。
Amazon Elastic Cloud Compute – 它们是 Amazon 提供的内置服务，有助于在云上开发和托管可扩展的 Web 应用程序。
Cloud Foundry – 是一个用于 Java、Ruby、Python 和 Node.js 应用程序的开源 PaaS 平台。
CloudStack – Apache 的 CloudStack 是 Citrix 开发的一个项目，旨在成为 OpenShift 和 OpenStack 的直接竞争对手。
OpenStack – 红帽为云计算提供的另一种云技术。
Kubernetes – 它是一种直接编排和集群管理技术，用于管理 Docker 容器。
OpenShift – 架构
OpenShift 是一个分层系统，其中每一层都使用 Kubernetes 和 Docker 集群与另一层紧密绑定。OpenShift 架构的设计使其可以支持和管理 Docker 容器，这些容器托管在使用 Kubernetes 的所有层之上。与早期版本的 OpenShift V2 不同，新版本的 OpenShift V3 支持容器化基础设施。在这个模型中，Docker 帮助创建基于 Linux 的轻量级容器，Kubernetes 支持在多个主机上编排和管理容器的任务。
OpenShift 的组件
OpenShift 架构的关键组件之一是管理 Kubernetes 中的容器化基础设施。Kubernetes 负责基础设施的部署和管理。在任何 Kubernetes 集群中，我们都可以有多个 master 和多个节点，这确保了设置中没有故障点。
Kubernetes 主机组件
Etcd – 它存储配置信息，集群中的每个节点都可以使用这些信息。它是一个高可用的键值存储，可以分布在多个节点之间。它应该只能由 Kubernetes API 服务器访问，因为它可能包含敏感信息。它是一个所有人都可以访问的分布式键值存储。
API Server – Kubernetes 是一个 API 服务器，它使用 API 提供集群上的所有操作。API 服务器实现了一个接口，这意味着不同的工具和库可以很容易地与之通信。kubeconfig 是一个包以及可用于通信的服务器端工具。它公开了 Kubernetes API”。
控制器管理器– 该组件负责调节集群状态并执行任务的大多数收集器。它可以被认为是一个守护进程，它运行在一个非终止循环中，负责收集信息并将其发送到 API 服务器。它致力于获取集群的共享状态，然后进行更改以使服务器的当前状态达到所需状态。关键控制器是复制控制器、端点控制器、命名空间控制器和服务帐户控制器。控制器管理器运行不同类型的控制器来处理节点、端点等。
Scheduler – 它是 Kubernetes master 的关键组件。它是 master 中的一个服务，负责分配工作负载。它负责跟踪集群节点上工作负载的使用情况，然后将可用资源放置在工作负载上并接受工作负载。换句话说，这是负责将 pod 分配给可用节点的机制。调度器负责工作负载利用率并将 Pod 分配给新节点。
Kubernetes 节点组件
以下是 Node 服务器的关键组件，它们是与 Kubernetes 主节点通信所必需的。
Docker – 每个节点的第一个要求是 Docker，它有助于在相对独立但轻量级的操作环境中运行封装的应用程序容器。
Kubelet 服务– 这是每个节点中的一个小服务，负责与控制平面服务之间的信息中继。它与 etcd 存储交互以读取配置详细信息和 Wright 值。这与主组件通信以接收命令和工作。然后 kubelet 进程负责维护工作状态和节点服务器。它管理网络规则、端口转发等。
Kubernetes 代理服务– 这是一个在每个节点上运行的代理服务，有助于使服务可用于外部主机。它有助于将请求转发到正确的容器。Kubernetes 代理服务能够执行原始负载均衡。它确保网络环境是可预测和可访问的，但同时也是隔离的。它管理节点上的 pod、卷、秘密、创建新容器健康检查等。
集成的 OpenShift 容器注册表
OpenShift 容器注册表是 Red Hat 的内置存储单元，用于存储 Docker 镜像。使用最新的 OpenShift 集成版本，它提供了一个用户界面来查看 OpenShift 内部存储中的图像。这些注册表能够保存带有指定标签的镜像，这些标签稍后用于从中构建容器。
常用术语
图像– Kubernetes（Docker）图像是容器化基础设施的关键构建块。目前，Kubernetes 仅支持 Docker 镜像。Pod 中的每个容器都有其 Docker 映像在其中运行。配置 Pod 时，配置文件中的 image 属性与 Docker 命令的语法相同。
项目– 它们可以定义为 OpenShift V2 早期版本中存在的域的重命名版本。
Container – 它们是在 Kubernetes 集群节点上部署映像后创建的。
节点– 节点是 Kubernetes 集群中的一台工作机器，也称为 master 的 minion。它们是可以是物理、VM 或云实例的工作单元。
Pod – Pod是容器及其存储在 Kubernetes 集群节点内的集合。可以创建一个包含多个容器的 pod。例如，将数据库容器和 Web 服务器容器保存在 pod 内。
OpenShift – 环境设置
在本章中，我们将了解 OpenShift 的环境设置。
系统要求
为了设置企业 OpenShift，需要有一个有效的 Red Hat 帐户。由于 OpenShift 工作在 Kubernetes master 和 node 架构上，我们需要将它们设置在不同的机器上，其中一台机器充当 master，其他机器在节点上工作。为了设置两者，有最低系统要求。
主机配置
以下是主机配置的最低系统要求。
-
托管在物理、虚拟或任何云环境上的基础机器。
-
至少 Linux 7 以及该实例上所需的软件包。
-
2个CPU核心。
-
至少 8 GB 内存。
-
30 GB 内部硬盘内存。
节点机器配置
- 为主机提供的物理或虚拟基础映像。
- 机器上至少有 Linux 7。
- Docker 安装不低于 1.6 版本。
- 1 个 CPU 内核。
- 8 GB 内存。
- 15 GB 硬盘用于托管图像，15 GB 用于存储图像。
OpenShift 设置分步指南
在下面的描述中，我们将设置 OpenShift 实验室环境，以后可以将其扩展到更大的集群。由于 OpenShift 需要设置主节点和节点，因此我们至少需要托管在云、物理或虚拟机上的两台机器。
步骤 1 – 首先在两台机器上安装 Linux，其中 Linux 7 应该是最低版本。如果您拥有有效的 Red Hat 订阅，则可以使用以下命令完成此操作。
# subscription-manager repos --disable = "*"
# subscription-manager repos --enable = "rhel-7-server-rpms"
# subscription-manager repos --enable = "rhel-7-server-extras-rpms"
# subscription-manager repos --enable = "rhel-7-server-optional-rpms"
# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install python-virtualenv
# yum install gcc
# yum install httpd-tools
# yum install docker
# yum update
一旦我们在两台机器上都安装了上述所有基础包，下一步就是在各自的机器上设置 Docker。
第 2 步– 配置 Docker，使其仅允许在本地网络上进行不安全的通信。为此，请编辑 /etc/sysconfig.conf 中的 Docker 文件。如果该文件不存在，则您需要手动创建它。
# vi /etc/sysconfig/docker OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24
在 master 机器上配置好 Docker 后，我们需要在两台机器之间设置无密码通信。为此，我们将使用公钥和私钥身份验证。
第 3 步– 在主机上生成密钥，然后将 id_rsa.pub 密钥复制到节点机器的授权密钥文件中，这可以使用以下命令完成。
# ssh-keygen
# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
完成上述所有设置后，接下来是在主机上设置 OpenShift 版本 3。
步骤 4 – 在主机上，运行以下 curl 命令。
# sh <(curl -s https://install.openshift.com/ose)
上面的命令将为 OSV3 进行设置。下一步是在机器上配置 OpenShift V3。
如果无法直接从 Internet 下载，则可以从https://install.openshift.com/portable/oo-install-ose.tgz作为 tar 包下载，安装程序可以在本地主机上运行。
一旦我们准备好设置，那么我们需要从机器上 OSV3 的实际配置开始。此设置非常特定于测试实际生产环境，我们已准备好 LDAP 和其他东西。
步骤 5 – 在主机上，配置位于 /etc/openshift/master/master-config.yaml 下的以下代码
# vi /etc/openshift/master/master-config.yaml identityProviders: - name: my_htpasswd_provider challenge: true login: true provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider file: /root/users.htpasswd routingConfig: subdomain: testing.com
接下来，为默认管理创建一个标准用户。
# htpasswd -c /root/users.htpasswd admin
第 6 步– 由于 OpenShift 使用 Docker 注册表来配置镜像，我们需要配置 Docker 注册表。这用于在构建后创建和存储 Docker 镜像。
使用以下命令在 OpenShift 节点机器上创建一个目录。
# mkdir /images
接下来，使用在设置注册表时创建的默认管理员凭据登录到主机。
# oc login Username: system:admin
切换到默认创建的项目。
# oc project default
第 7 步– 创建一个 Docker 注册表。
#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -
编辑用户权限。
#oc edit scc privileged users: - system:serviceaccount:openshift-infra:build-controller - system:serviceaccount:default:registry
创建和编辑图像注册表。
#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images
步骤 8 – 创建默认路由。
默认情况下，OpenShift 使用 OpenVswitch 作为软件网络。使用以下命令创建默认路由。这用于负载平衡和代理路由。路由器类似于 Docker 注册表，也运行在注册表中。
# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -
接下来，编辑用户的权限。
#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'
步骤 9 – 配置 DNS。
为了处理 URL 请求，OpenShift 需要一个有效的 DNS 环境。需要此 DNS 配置来创建通配符，这是创建指向路由器的 DNS 通配符所必需的。
# yum install bind-utils bind
# systemctl start named
# systemctl enable named
vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
10.38.55.13;
;
};
zone "lab.com" IN {
type master;
file "/var/named/dynamic/test.com.zone";
allow-update { none; };
};
步骤 10 – 最后一步是在 OpenShift V3 主机上设置 github 服务器，这是可选的。这可以使用以下命令序列轻松完成。
#yum install curl openssh-server
#systemctl enable sshd
# systemctl start sshd
# firewall-cmd --permanent --add-service = http
# systemctl reload firewalld
#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-
#yum install gitlab-ce
# gitlab-ctl reconfigure
完成上述设置后，您可以通过测试和部署应用程序进行验证，我们将在后续章节中详细了解。
OpenShift – 基本概念
在开始实际设置和部署应用程序之前，我们需要了解 OpenShift V3 中使用的一些基本术语和概念。
容器和图像
图片
这些是 OpenShift 的基本构建块，它们由 Docker 镜像构成。在 OpenShift 上的每个 pod 中，集群都有自己的映像在其中运行。当我们配置一个 pod 时，我们有一个将从注册表中汇集的字段。该配置文件将拉取镜像并将其部署在集群节点上。
apiVersion: v1
kind: pod
metadata:
name: Tesing_for_Image_pull -----------> Name of Pod
spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull
为了从中提取和创建映像，请运行以下命令。OC 是登录后与 OpenShift 环境进行通信的客户端。
$ oc create –f Tesing_for_Image_pull
容器
当 Docker 镜像部署在 OpenShift 集群上时，它就会被创建。在定义任何配置时，我们在配置文件中定义容器部分。一个容器内部可以运行多个镜像，集群节点上运行的所有容器都由 OpenShift Kubernetes 管理。
spec: containers: - name: py ------------------------> Name of the container image: python----------> Image going to get deployed on container command: [“python”, “SUCCESS”] restartPocliy: Never --------> Restart policy of container
以下是定义在其中运行多个图像的容器的规范。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
-name: Database
Image: mongoDB
Ports:
- containerPort: 7501
imagePullPolicy: Always
在上面的配置中，我们定义了一个多容器的 pod，里面有 Tomcat 和 MongoDB 两个镜像。
Pod 和服务
豆荚
Pod 可以定义为 OpenShift (Kubernetes) 集群节点内的容器及其存储的集合。一般来说，我们有两种类型的 pod，从单容器 pod 到多容器 pod。
Single Container Pod – 这些可以使用 OC 命令或基本配置 yml 文件轻松创建。
$ oc run <name of pod> --image = <name of the image from registry>
使用一个简单的 yaml 文件创建它，如下所示。
apiVersion: v1
kind: Pod
metadata:
name: apache
spec:
containers:
- name: apache
image: apache: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
创建上述文件后，它将使用以下命令生成一个 pod。
$ oc create –f apache.yml
Multi-Container Pod – 多容器 Pod 是指在其中运行多个容器的 Pod。它们是使用 yaml 文件创建的，如下所示。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
-name: Database
Image: mongoDB
Ports:
- containerPort: 7501
imagePullPolicy: Always
创建这些文件后，我们可以简单地使用与上述相同的方法来创建容器。
服务– 因为我们有一组容器在 pod 内运行，所以我们有一个可以定义为一组逻辑 pod 的服务。它是 pod 之上的一个抽象层，它提供了一个单一的 IP 和 DNS 名称，通过这些名称可以访问 pod。服务有助于管理负载平衡配置并非常轻松地扩展 pod。在 OpenShift 中，服务是一个 REST 对象，其定义可以发布到 OpenShift master 上的 apiService 以创建新实例。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999
构建和流
构建
在 OpenShift 中，构建是将图像转换为容器的过程。它是将源代码转换为图像的处理。此构建过程适用于将源代码构建为映像的预定义策略。
构建处理多种策略和来源。
构建策略
-
Source to Image – 这基本上是一个工具，有助于构建可重现的图像。这些镜像总是处于准备阶段，可以使用 Docker run 命令运行。
-
Docker Build – 这是通过运行简单的 Docker 构建命令使用 Docker 文件构建图像的过程。
-
自定义构建– 这些是用于创建基础 Docker 镜像的构建。
构建源
Git – 当 git 存储库用于构建图像时使用此源。Dockerfile 是可选的。源代码中的配置如下所示。
source: type: "Git" git: uri: "https://github.com/vipin/testing.git" ref: "master" contextDir: "app/dir" dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"
Dockerfile – Dockerfile 用作配置文件中的输入。
source: type: "Dockerfile" dockerfile: "FROM ubuntu: latest RUN yum install -y httpd"
图像流– 在拉取图像后创建图像流。图像流的优势在于它会查找图像新版本的更新。这用于比较由标签标识的任意数量的 Docker 格式的容器镜像。
创建新图像时，图像流可以自动执行操作。所有构建和部署都可以监视图像操作并相应地执行操作。以下是我们如何定义构建流。
apiVersion: v1
kind: ImageStream
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
generation: 1
labels:
app: ruby-sample-build
selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
tags:
- items:
- created: 2016-01-29T13:40:11Z
dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
generation: 1
image: vklnld908.int.clsa.com/vipin/test
tag: latest
路线和模板
路线
在 OpenShift 中，路由是一种通过创建和配置外部可访问主机名将服务暴露给外部世界的方法。路由和端点用于将服务暴露给外部世界，用户可以从那里使用名称连接 (DNS) 访问定义的应用程序。
在 OpenShift 中，路由是使用由 OpenShift 管理员在集群上部署的路由器创建的。路由器用于将 HTTP (80) 和 https (443) 端口绑定到外部应用程序。
以下是路由支持的不同类型的协议 –
- HTTP
- HTTPS
- TSL 和网络套接字
配置服务时，选择器用于配置服务并使用该服务查找端点。以下是我们如何使用适当的协议创建服务和该服务的路由的示例。
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {"name": "Openshift-Rservice"},
"spec": {
"selector": {"name":"RService-openshift"},
"ports": [
{
"protocol": "TCP",
"port": 8888,
"targetPort": 8080
}
]
}
}
接下来，运行以下命令并创建服务。
$ oc create -f ~/training/content/Openshift-Rservice.json
这是服务创建后的样子。
$ oc describe service Openshift-Rservice Name: Openshift-Rservice Labels: <none> Selector: name = RService-openshift Type: ClusterIP IP: 172.30.42.80 Port: <unnamed> 8080/TCP Endpoints: <none> Session Affinity: None No events.
使用以下代码为服务创建路由。
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {"name": "Openshift-service-route"},
"spec": {
"host": "hello-openshift.cloudapps.example.com",
"to": {
"kind": "Service",
"name": "OpenShift-route-service"
},
"tls": {"termination": "edge"}
}
}
当使用 OC 命令创建路由时，会创建一个新的路由资源实例。
模板
模板在 OpenShift 中被定义为可以多次使用的标准对象。它使用用于创建多个对象的占位符列表进行参数化。这可用于创建任何内容，从 pod 到网络，用户有权创建这些内容。如果图像中的 CLI 或 GUI 界面的模板上传到项目目录，则可以创建对象列表。
apiVersion: v1
kind: Template
metadata:
name: <Name of template>
annotations:
description: <Description of Tag>
iconClass: "icon-redis"
tags: <Tages of image>
objects:
- apiVersion: v1
kind: Pod
metadata:
name: <Object Specification>
spec:
containers:
image: <Image Name>
name: master
ports:
- containerPort: <Container port number>
protocol: <Protocol>
labels:
redis: <Communication Type>
认证和授权
验证
在 OpenShift 中，在配置 master 和 client 结构时，master 提供了 OAuth 服务器的内置功能。OAuth 服务器用于生成令牌，用于对 API 进行身份验证。由于 OAuth 作为 master 的默认设置，我们默认使用 Allow All 身份提供者。存在不同的身份提供者，可以在/etc/openshift/master/master-config.yaml进行配置。
OAuth 中存在不同类型的身份提供者。
- 允许全部
- 全部拒绝
- HT密码
- LDAP
- 基本认证
允许全部
apiVersion: v1
kind: Pod
metadata:
name: redis-master
spec:
containers:
image: dockerfile/redis
name: master
ports:
- containerPort: 6379
protocol: TCP
oauthConfig:
identityProviders:
- name: my_allow_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
全部拒绝
apiVersion: v1
kind: Pod
metadata:
name: redis-master
spec:
containers:
image: dockerfile/redis
name: master
ports:
- containerPort: 6379
protocol: TCP
oauthConfig:
identityProviders:
- name: my_allow_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HT密码
为了使用HTPasswd，我们需要先在主机上设置Httpd-tools，然后像我们在其他机器上一样配置它。
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
授权
授权是 OpenShift master 的一项功能，用于验证验证用户。这意味着它会检查尝试执行操作的用户，以查看该用户是否有权在给定项目上执行该操作。这有助于管理员控制对项目的访问。
授权策略使用 –
- 规则
- 角色
- 绑定
授权评估是使用 –
- 身份
- 行动
- 绑定
使用政策 –
- 集群策略
- 地方政策
OpenShift – 入门
OpenShift 包含两种类型的中位数来创建和部署应用程序，通过 GUI 或通过 CLI。在本章中，我们将使用 CLI 创建一个新应用程序。我们将使用 OC 客户端与 OpenShift 环境进行通信。
创建新应用程序
在 OpenShift 中，有三种创建新应用程序的方法。
- 从源代码
- 从图像
- 从模板
从源代码
当我们尝试从源代码创建应用程序时，OpenShift 会查找存储库中应该存在的 Docker 文件，该文件定义了应用程序构建流程。我们将使用 oc new-app 创建一个应用程序。
使用 repo 时要记住的第一件事是，它应该指向 repo 中的一个来源，OpenShift 将从那里提取代码并构建它。
如果 repo 是在安装了 OC 客户端的 Docker 机器上克隆的，并且用户在同一目录中，则可以使用以下命令创建它。
$ oc new-app . <Hear. Denotes current working directory>
以下是尝试从远程仓库为特定分支构建的示例。
$ oc new-app https://github.com/openshift/Testing-deployment.git#test1
在这里，test1 是我们尝试在 OpenShift 中创建新应用程序的分支。
在存储库中指定 Docker 文件时，我们需要定义构建策略，如下所示。
$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git
从图像
在使用图像构建应用程序时，图像存在于本地 Docker 服务器、内部托管的 Docker 存储库或 Docker 集线器中。用户唯一需要确保的是，他可以毫无问题地从集线器中提取图像。
OpenShift 能够确定使用的源，无论是 Docker 镜像还是源流。但是，如果用户愿意，他可以明确定义它是镜像流还是 Docker 镜像。
$ oc new-app - - docker-image tomcat
使用图像流 –
$ oc new-app tomcat:v1
从模板
模板可用于创建新应用程序。它可以是一个已经存在的模板或创建一个新的模板。
下面的 yaml 文件基本上是一个可以用于部署的模板。
apiVersion: v1
kind: Template
metadata:
name: <Name of template>
annotations:
description: <Description of Tag>
iconClass: "icon-redis"
tags: <Tages of image>
objects:
- apiVersion: v1
kind: Pod
metadata:
name: <Object Specification>
spec:
containers:
image: <Image Name>
name: master
ports:
- containerPort: <Container port number>
protocol: <Protocol>
labels:
redis: <Communication Type>
开发和部署 Web 应用程序
在 OpenShift 中开发新应用程序
为了在 OpenShift 中创建新应用程序，我们必须编写新的应用程序代码并使用 OpenShift OC 构建命令构建它。如前所述，我们有多种创建新图像的方法。在这里，我们将使用模板来构建应用程序。当使用 oc new-app 命令运行时，此模板将构建一个新应用程序。
以下模板将创建 – 两个前端应用程序和一个数据库。与此同时，它将创建两个新服务，这些应用程序将被部署到 OpenShift 集群。在构建和部署应用程序时，最初我们需要在 OpenShift 中创建一个命名空间并将应用程序部署在该命名空间下。
创建一个新的命名空间
$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" -- description = "This is an example project to demonstrate OpenShift v3"
模板
{
"kind": "Template",
"apiVersion": "v1",
"metadata": {
"name": "openshift-helloworld-sample",
"creationTimestamp": null,
"annotations": {
"description": "This example shows how to create a simple openshift
application in openshift origin v3",
"iconClass": "icon-openshift",
"tags": "instant-app,openshift,mysql"
}
}
},
对象定义
模板中的秘密定义
"objects": [
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {"name": "dbsecret"},
"stringData" : {
"mysql-user" : "${MYSQL_USER}",
"mysql-password" : "${MYSQL_PASSWORD}"
}
},
模板中的服务定义
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "web",
"protocol": "TCP",
"port": 5432,
"targetPort": 8080,
"nodePort": 0
}
],
"selector": {"name": "frontend"},
"type": "ClusterIP",
"sessionAffinity": "None"
},
"status": {
"loadBalancer": {}
}
},
模板中的路由定义
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {
"name": "route-edge",
"creationTimestamp": null,
"annotations": {
"template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
}
},
"spec": {
"host": "www.example.com",
"to": {
"kind": "Service",
"name": "frontend"
},
"tls": {
"termination": "edge"
}
},
"status": {}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "origin-openshift-sample",
"creationTimestamp": null
},
"spec": {},
"status": {
"dockerImageRepository": ""
}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "openshift-22-ubuntu7",
"creationTimestamp": null
},
"spec": {
"dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
},
"status": {
"dockerImageRepository": ""
}
},
在模板中构建配置定义
{
"kind": "BuildConfig",
"apiVersion": "v1",
"metadata": {
"name": "openshift-sample-build",
"creationTimestamp": null,
"labels": {name": "openshift-sample-build"}
},
"spec": {
"triggers": [
{ "type": "GitHub",
"github": {
"secret": "secret101" }
},
{
"type": "Generic",
"generic": {
"secret": "secret101",
"allowEnv": true }
},
{
"type": "ImageChange",
"imageChange": {}
},
{ "type": "ConfigChange”}
],
"source": {
"type": "Git",
"git": {
"uri": https://github.com/openshift/openshift-hello-world.git }
},
"strategy": {
"type": "Docker",
"dockerStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "openshift-22-ubuntu7:latest”
},
"env": [
{
"name": "EXAMPLE",
"value": "sample-app"
}
]
}
},
"output": {
"to": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
},
"postCommit": {
"args": ["bundle", "exec", "rake", "test"]
},
"status": {
"lastVersion": 0
}
}
},
模板中的部署配置
"status": {
"lastVersion": 0
}
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
}
},
"spec": {
"strategy": {
"type": "Rolling",
"rollingParams": {
"updatePeriodSeconds": 1,
"intervalSeconds": 1,
"timeoutSeconds": 120,
"pre": {
"failurePolicy": "Abort",
"execNewPod": {
"command": [
"/bin/true"
],
"env": [
{
"name": "CUSTOM_VAR1",
"value": "custom_value1"
}
]
}
}
}
}
}
"triggers": [
{
"type": "ImageChange",
"imageChangeParams": {
"automatic": true,
"containerNames": [
"openshift-helloworld"
],
"from": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
}
},
{
"type": "ConfigChange"
}
],
"replicas": 2,
"selector": {
"name": "frontend"
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "frontend"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld",
"image": "origin-openshift-sample",
"ports": [
{
"containerPort": 8080,
"protocol": "TCP”
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "IfNotPresent",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst"
},
"status": {}
},
模板中的服务定义
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "db",
"protocol": "TCP",
"port": 5434,
"targetPort": 3306,
"nodePort": 0
}
],
"selector": {
"name": "database
},
"type": "ClusterIP",
"sessionAffinity": "None" },
"status": {
"loadBalancer": {}
}
},
模板中的部署配置定义
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"strategy": {
"type": "Recreate",
"resources": {}
},
"triggers": [
{
"type": "ConfigChange"
}
],
"replicas": 1,
"selector": {"name": "database"},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {"name": "database"}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "database"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld-database",
"image": "ubuntu/mysql-57-ubuntu7:latest",
"ports": [
{
"containerPort": 3306,
"protocol": "TCP"
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"volumeMounts": [
{
"name": "openshift-helloworld-data",
"mountPath": "/var/lib/mysql/data"
}
],
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "Always",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"volumes": [
{
"name": "openshift-helloworld-data",
"emptyDir": {"medium": ""}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst”
}
}
},
"status": {}
},
"parameters": [
{
"name": "MYSQL_USER",
"description": "database username",
"generate": "expression",
"from": "user[A-Z0-9]{3}",
"required": true
},
{
"name": "MYSQL_PASSWORD",
"description": "database password",
"generate": "expression",
"from": "[a-zA-Z0-9]{8}",
"required": true
},
{
"name": "MYSQL_DATABASE",
"description": "database name",
"value": "root",
"required": true
}
],
"labels": {
"template": "application-template-dockerbuild"
}
}
上面的模板文件需要一次性编译。我们需要首先将所有内容复制到一个文件中，并在完成后将其命名为 yaml 文件。
我们需要运行以下命令来创建应用程序。
$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"
openshift-helloworld-sample
---------
This example shows how to create a simple ruby application in openshift origin v3
* With parameters:
* MYSQL_USER = userPJJ # generated
* MYSQL_PASSWORD = cJHNK3se # generated
* MYSQL_DATABASE = root
--> Creating resources with label app = ruby-helloworld-sample ...
service "frontend" created
route "route-edge" created
imagestream "origin-ruby-sample" created
imagestream "ruby-22-centos7" created
buildconfig "ruby-sample-build" created
deploymentconfig "frontend" created
service "database" created
deploymentconfig "database" created
--> Success
Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
Run 'oc status' to view your app.
如果我们希望监控构建，可以使用 –
$ oc get builds NAME TYPE FROM STATUS STARTED DURATION openshift-sample-build-1 Source Git@bd94cbb Running 7 seconds ago 7s
我们可以使用以下方法检查 OpenShift 上部署的应用程序 –
$ oc get pods NAME READY STATUS RESTARTS AGE database-1-le4wx 1/1 Running 0 1m frontend-1-e572n 1/1 Running 0 27s frontend-1-votq4 1/1 Running 0 31s opeshift-sample-build-1-build 0/1 Completed 0 1m
我们可以使用以下方法检查应用程序服务是否是按照服务定义创建的
$ oc get services NAME CLUSTER-IP EXTERNAL-IP PORT(S) SELECTOR AGE database 172.30.80.39 <none> 5434/TCP name=database 1m frontend 172.30.17.4 <none> 5432/TCP name=frontend 1m
OpenShift – 构建自动化
在 OpenShift 中，我们有多种自动化构建管道的方法。为此，我们需要创建一个 BuildConfig 资源来描述构建流程。BuildConfig 中的流程可以与 Jenkins 作业定义中的作业定义进行比较。在创建构建流程时，我们必须选择构建策略。
构建配置文件
在 OpenShift 中，BuildConfig 是一个 rest 对象，用于连接到 API 然后创建一个新实例。
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "<Name of build config file>"
spec:
runPolicy: "Serial"
triggers:
-
type: "GitHub"
github:
secret: "<Secrete file name>"
- type: "Generic"
generic:
secret: "secret101"
-
type: "ImageChange"
source:
type: "<Source of code>"
git:
uri: "https://github.com/openshift/openshift-hello-world"
dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "openshift-20-centos7:latest"
output:
to:
kind: "ImageStreamTag"
name: "origin-openshift-sample:latest"
postCommit:
script: "bundle exec rake test"
在 OpenShift 中，有四种类型的构建策略。
- 源到图像策略
- Docker 策略
- 自定义策略
- 管道策略
源到图像策略
允许从源代码开始创建容器映像。在此流程中，实际代码首先下载到容器中，然后在其中进行编译。编译后的代码部署在同一个容器中，映像是从该代码构建的。
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "builder-image:latest"
forcePull: true
有多种策略策略。
- 力拉
- 增量构建
- 外部构建
Docker 策略
在此流程中，OpenShift 使用 Dockerfile 构建镜像，然后将创建的镜像上传到 Docker 注册表。
strategy:
type: Docker
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "ubuntu:latest"
Docker 文件选项可用于从文件路径、无缓存和强制拉取开始的多个位置。
- 通过图片
- Dockerfile 路径
- 无缓存
- 力拉
自定义策略
这是不同类型的构建策略之一，其中没有强制构建的输出将是图像。它可以与詹金斯的自由风格工作相提并论。有了这个，我们可以创建 Jar、rpm 和其他包。
strategy:
type: "Custom"
customStrategy:
from:
kind: "DockerImage"
name: "openshift/sti-image-builder"
它由多个构建策略组成。
- 暴露 Docker 套接字
- 秘密
- 力拉
管道策略
管道策略用于创建自定义构建管道。这基本上用于在管道中实现工作流。此构建流程使用使用 Groovy DSL 语言的自定义构建管道流程。OpenShift 将在 Jenkins 中创建一个管道作业并执行它。这个管道流也可以在 Jenkins 中使用。在此策略中，我们使用 Jenkinsfile 并将其附加到 buildconfig 定义中。
Strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"
使用构建管道
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "test-pipeline"
spec:
source:
type: "Git"
git:
uri: "https://github.com/openshift/openshift-hello-world"
strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfilePath: <file path repository>
OpenShift – CLI
OpenShift CLI 用于从命令行管理 OpenShift 应用程序。OpenShift CLI 能够管理端到端的应用程序生命周期。通常，我们会使用 OC，它是一个 OpenShift 客户端来与 OpenShift 通信。
OpenShift CLI 设置
为了在不同的操作系统上设置 OC 客户端，我们需要执行不同的步骤顺序。
适用于 Windows 的 OC 客户端
步骤 1 – 从以下链接下载 oc cli https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
步骤 2 – 在机器上的目标路径上解压缩包。
步骤 3 – 编辑系统的路径环境变量。
C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH% C:\oraclexe\app\oracle\product.2.0\server\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86; C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\ v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ATI Technologies\ATI.ACE\C ore-Static;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;
步骤 4 – 在 Windows 上验证 OC 设置。
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version oc v3.6.0-alpha.2+3c221d5 kubernetes v1.6.1+5115d708d7 features: Basic-Auth
Mac OS X 的 OC 客户端
我们可以在与 Windows 相同的位置下载 Mac OS 安装二进制文件，然后将其解压缩到某个位置并在环境 PATH 变量下设置可执行文件的路径。
或者
我们可以使用 Home brew 并使用以下命令进行设置。
$ brew install openshift-cli
Linux OC 客户端
在同一个页面下，我们有Linux安装的tar文件，可以用来安装。稍后，可以设置指向该特定可执行位置的路径变量。
https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
使用以下命令解压 tar 文件。
$ tar –xf < path to the OC setup tar file >
运行以下命令检查身份验证。
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login Server [https://localhost:8443]:
CLI 配置文件
OC CLI 配置文件用于管理多个 OpenShift 服务器连接和身份验证机制。此配置文件还用于存储和管理多个配置文件以及在它们之间进行切换。正常的配置文件如下所示。
$ oc config view
apiVersion: v1
clusters:
- cluster:
server: https://vklnld908.int.example.com
name: openshift
contexts:
- context:
cluster: openshift
namespace: testproject
user: alice
name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
user:
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
设置 CLI 客户端
用于设置用户凭据
$ oc config set-credentials <user_nickname> [--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>] [--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]
用于设置集群
$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>] [--certificate-authority = <path/to/certificate/authority>] [--api-version = <apiversion>] [--insecure-skip-tls-verify = true]
例子
$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
用于设置上下文
$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>] [--user = <user_nickname>] [--namespace = <namespace>]
CLI 配置文件
在单个 CLI 配置文件中，我们可以有多个配置文件，其中每个配置文件都有不同的 OpenShift 服务器配置，稍后可用于在不同的 CLI 配置文件之间切换。
apiVersion: v1
clusters: --→ 1
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld908.int.example.com:8443
name: vklnld908.int.example.com:8443
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld1446.int.example.com:8443
name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
cluster: vklnld908.int.example.com:8443
namespace: openshift-project
user: vipin/vklnld908.int.example.com:8443
name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
cluster: vklnld908.int.example.com:8443
namespace: testing-project
user: alim/vklnld908.int.example.com:8443
name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}
users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
在上面的配置中，我们可以看到它分为四个主要部分，从定义两个 OpenShift 主机实例的集群开始。第二个上下文部分定义了两个名为 vipin 和 alim 的上下文。当前上下文定义了当前正在使用的上下文。如果我们在此处更改定义，则可以将其更改为其他上下文或配置文件。最后，定义了用户定义及其身份验证令牌，在我们的例子中是 vipin。
如果我们想检查当前正在使用的配置文件，可以使用 –
$ oc status oc status In project testing Project (testing-project) $ oc project Using project "testing-project" from context named "testing- project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".
如果我们想切换到其他 CLI，可以使用以下命令从命令行完成。
$ oc project openshift-project Now using project "Openshift-project" on server " https://vklnld908.int.example.com:8443".
使用上面的命令，我们可以在配置文件之间切换。在任何时候，如果我们想查看配置，我们可以使用 $oc config view 命令。
OpenShift – CLI 操作
OpenShift CLI 能够执行应用程序的所有基本和高级配置、管理、添加和部署。
我们可以使用 OC 命令执行不同类型的操作。该客户端可帮助您在任何 OpenShift 或 Kubernetes 兼容平台上开发、构建、部署和运行您的应用程序。它还包括用于在“adm”子命令下管理集群的管理命令。
基本命令
下表列出了基本的 OC 命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
Types 概念和类型介绍 |
| 2 |
Login 登录到服务器 |
| 3 |
new-project 申请新项目 |
| 4 |
new-app 创建一个新的应用程序 |
| 5 |
Status 显示当前项目的概览 |
| 6 |
Project 切换到另一个项目 |
| 7 |
Projects 显示现有项目 |
| 8 |
Explain 资源文件 |
| 9 |
Cluster 启动和停止 OpenShift 集群 |
登录
登录到您的服务器并保存登录以供后续使用。客户端的首次用户应运行此命令以连接到服务器，建立经过身份验证的会话，并将连接保存到配置文件。默认配置将保存到您的主目录下的“.kube/config”。
登录所需的信息——比如用户名和密码、会话令牌或服务器详细信息可以通过标志提供。如果未提供，该命令将根据需要提示用户输入。
用法
oc login [URL] [options]
例子
# Log in interactively oc login # Log in to the given server with the given certificate authority file oc login localhost:8443 --certificate-authority = /path/to/cert.crt # Log in to the given server with the given credentials (will not prompt interactively) oc login localhost:8443 --username = myuser --password=mypass
选项 –
-p, –password = “ – 密码，如果未提供将提示
-u, –username = “ – 用户名，如果未提供将提示
–certificate-authority = “ – 证书颁发机构的证书文件的路径
–insecure-skip-tls-verify = false — 如果为 true，则不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全
–token = “ – 用于对 API 服务器进行身份验证的承载令牌
要获取有关任何命令的完整详细信息，请使用oc <Command Name> –help命令。
构建和部署命令
下表列出了构建和部署命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
Rollout 管理 Kubernetes 部署或 OpenShift 部署 |
| 2 |
Deploy 查看、启动、取消或重试部署 |
| 3 |
Rollback 将应用程序的一部分恢复到以前的状态 |
| 4 |
new-build 创建一个新的构建配置 |
| 5 |
start-build 开始一个新的构建 |
| 6 |
cancel-build 取消正在运行、挂起或新的构建 |
| 7 |
import-image 从 Docker 注册表导入图像 |
| 8 |
Tag 将现有图像标记为图像流 |
应用管理命令
下表列出了应用程序管理命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
Get 显示一项或多项资源 |
| 2 |
Describe 显示特定资源或一组资源的详细信息 |
| 3 |
Edit 编辑服务器上的资源 |
| 4 |
Set 有助于在对象上设置特定功能的命令 |
| 5 |
Label 更新资源上的标签 |
| 6 |
Annotate 更新资源的注释 |
| 7 |
Expose 将复制的应用程序公开为服务或路由 |
| 8 |
Delete 删除一个或多个资源 |
| 9 |
Scale 更改部署中的 pod 数量 |
| 10 |
Autoscale 自动缩放部署配置、部署、复制、控制器或副本集 |
| 11 |
Secrets 管理机密 |
| 12 |
Serviceaccounts 管理项目中的服务帐号 |
故障排除和调试命令
下表列出了故障排除和调试命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
logs 打印资源的日志 |
| 2 |
Rsh 在 pod 中启动 shell 会话 |
| 3 |
Rsync 在本地文件系统和 pod 之间复制文件 |
| 4 |
port-forward 将一个或多个本地端口转发到一个 Pod |
| 5 |
Debug 启动一个新的 pod 实例进行调试 |
| 6 |
Exec 在容器中执行命令 |
| 7 |
Procy 运行到 Kubernetes API 服务器的代理 |
| 9 |
Attach 附加到正在运行的容器 |
| 10 |
Run 在集群上运行一个特定的镜像 |
| 11 |
Cp 将文件和目录复制到容器或从容器复制 |
高级命令
下表列出了高级命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
adm 管理集群的工具 |
| 2 |
create 通过文件名或标准输入创建资源 |
| 3 |
replace 通过文件名或标准输入替换资源 |
| 4 |
apply 通过文件名或标准输入将配置应用到资源 |
| 5 |
patch 使用战略合并补丁更新资源的字段 |
| 6 |
process 将模板处理为资源列表 |
| 7 |
export 导出资源，以便它们可以在其他地方使用 |
| 8 |
extract 将机密或配置映射提取到磁盘 |
| 9 |
idle 空闲的可扩展资源 |
| 10 |
observe 观察资源的变化并对其做出反应（实验性） |
| 11 |
policy 管理授权策略 |
| 12 |
auth 检查授权 |
| 13 |
convert 在不同 API 版本之间转换配置文件 |
| 14 |
import 导入应用程序的命令 |
设置命令
下表列出了设置命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 |
Logout 结束当前服务器会话 |
| 2 |
Config 更改客户端的配置文件 |
| 3 |
Whoami 返回有关当前会话的信息 |
| 4 |
Completion 输出指定 shell（bash 或 zsh）的 shell 完成代码 |
OpenShift – 集群
OpenShift 使用两种安装方法来设置 OpenShift 集群。
- 快速安装方法
- 高级配置方法
设置集群
快速安装方法
此方法用于运行快速未实现的集群设置配置。为了使用这种方法，我们需要先安装安装程序。这可以通过运行以下命令来完成。
互动方式
$ atomic-openshift-installer install
当您希望运行交互式设置时，这很有用。
无人值守安装方式
该方法用于设置无人值守的安装方式，用户可以定义一个配置yaml文件，放在~/.config/openshift/下，名称为installer.cfg.yml。然后，可以运行以下命令来安装–u 标签。
$ atomic-openshift-installer –u install
默认情况下，它使用位于~/.config/openshift/下的配置文件。另一方面，Ansible 用作安装的备份。
version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log
deployment:
ansible_ssh_user: root
hosts:
- ip: 172.10.10.1
hostname: vklnld908.int.example.com
public_ip: 24.222.0.1
public_hostname: master.example.com
roles:
- master
- node
containerized: true
connect_to: 24.222.0.1
- ip: 172.10.10.2
hostname: vklnld1446.int.example.com
public_ip: 24.222.0.2
public_hostname: node1.example.com
roles:
- node
connect_to: 10.0.0.2
- ip: 172.10.10.3
hostname: vklnld1447.int.example.com
public_ip: 10..22.2.3
public_hostname: node2.example.com
roles:
- node
connect_to: 10.0.0.3
roles:
master:
<variable_name1>: "<value1>"
<variable_name2>: "<value2>"
node:
<variable_name1>: "<value1>"
在这里，我们有角色特定的变量，如果希望设置一些特定的变量，可以定义它。
完成后，我们可以使用以下命令验证安装。
$ oc get nodes NAME STATUS AGE master.example.com Ready 10d node1.example.com Ready 10d node2.example.com Ready 10d
高级安装
高级安装完全基于 Ansible 配置，其中存在关于主节点和节点配置的完整主机配置和变量定义。这包含有关配置的所有详细信息。
一旦我们设置好并且剧本准备好，我们可以简单地运行以下命令来设置集群。
$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml
将主机添加到集群
我们可以使用以下方法将主机添加到集群中 –
- 快速安装工具
- 高级配置方法
快速安装工具可在交互和非交互模式下工作。使用以下命令。
$ atomic-openshift-installer -u -c </path/to/file> scaleup
扩展应用程序配置文件外观的格式可用于添加主节点和节点。
高级配置方法
在此方法中，我们更新 Ansible 的主机文件，然后在此文件中添加新的节点或服务器详细信息。配置文件如下所示。
[OSEv3:children] masters nodes new_nodes new_master
在同一个 Ansible 主机文件中，添加有关新节点的变量详细信息，如下所示。
[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"
最后，使用更新的主机文件，运行新配置并调用配置文件以使用以下命令完成设置。
$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml
管理集群日志
OpenShift 集群日志只不过是从集群的 master 和 node 机器生成的日志。这些可以管理任何类型的日志，从服务器日志、主日志、容器日志、pod 日志等开始。容器日志管理有多种技术和应用。
列出的工具很少，可以实现日志管理。
- 流利的
- 麋鹿
- 卡布纳
- 纳吉欧斯
- Splunk
ELK 堆栈– 此堆栈在尝试从所有节点收集日志并以系统格式呈现它们时很有用。ELK堆栈主要分为三大类。
ElasticSearch – 主要负责从所有容器收集信息并将其放入中央位置。
Fluentd – 用于将收集到的日志提供给elasticsearch容器引擎。
Kibana – 一个图形界面，用于将收集到的数据显示为图形界面中的有用信息。
需要注意的一个关键点是，当该系统部署在集群上时，它会开始从所有节点收集日志。
日志诊断
OpenShift 有一个带有 OC的内置oc adm dignostics命令，可用于分析多种错误情况。这个工具可以作为集群管理员从 master 使用。此实用程序在故障排除和诊断已知问题方面非常有用。这在主客户端和节点上运行。
如果在没有任何参数或标志的情况下运行，它将查找客户端、服务器和节点机器的配置文件，并将它们用于诊断。可以通过传递以下参数来单独运行诊断 –
- 聚合日志
- 分析日志
- 集群注册表
- 集群角色绑定
- 集群角色
- 集群路由器
- 配置上下文
- 诊断舱
- 主配置检查
- 主节点
- MetricsApiProxy
- 网络检查
- 节点配置检查
- 节点定义
- 服务外部IP
- 单位状态
可以使用以下命令简单地运行它们。
$ oc adm diagnostics <DiagnosticName>
升级集群
集群的升级涉及升级集群内的多个事物，并使用新组件和升级来更新集群。这涉及 –
- 主组件升级
- 节点组件升级
- 政策升级
- 航线升级
- 图像流升级
为了执行所有这些升级，我们需要首先获得快速安装程序或实用程序。为此，我们需要更新以下实用程序 –
- atomic-openshift-utils
- atomic-openshift-excluder
- atomic-openshift-docker-excluder
- etcd 包
在开始升级之前，我们需要在 master 机器上备份 etcd，这可以使用以下命令完成。
$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd $ etcdctl backup \ --data-dir $ETCD_DATA_DIR \ --backup-dir $ETCD_DATA_DIR.bak.<date>
主组件升级
在 OpenShift master 中，我们通过更新 etcd 文件开始升级，然后转到 Docker。最后，我们运行自动执行器，使集群进入所需的位置。但是，在开始升级之前，我们需要首先激活每个 master 上的原子 openshift 包。这可以使用以下命令来完成。
步骤 1 – 删除 atomic-openshift 包
$ atomic-openshift-excluder unexclude
第 2 步– 在所有主节点上升级 etcd。
$ yum update etcd
步骤 3 – 重新启动 etcd 服务并检查它是否已成功启动。
$ systemctl restart etcd $ journalctl -r -u etcd
第 4 步– 升级 Docker 包。
$ yum update docker
第 5 步– 重新启动 Docker 服务并检查它是否正确启动。
$ systemctl restart docker $ journalctl -r -u docker
步骤 6 – 完成后，使用以下命令重新启动系统。
$ systemctl reboot $ journalctl -r -u docker
步骤 7 – 最后，运行 atomic-executer 将包恢复到 yum 排除列表中。
$ atomic-openshift-excluder exclude
升级策略没有这种强制，只需要推荐升级就可以了，可以用下面的命令查看。
$ oadm policy reconcile-cluster-roles
在大多数情况下，我们不需要更新策略定义。
节点组件升级
一旦主更新完成，我们就可以开始升级节点了。要记住的一件事是，升级周期应该很短，以避免集群中出现任何类型的问题。
步骤 1 – 从您希望执行升级的所有节点中删除所有原子 OpenShift 包。
$ atomic-openshift-excluder unexclude
步骤 2 – 接下来，在升级前禁用节点调度。
$ oadm manage-node <node name> --schedulable = false
步骤 3 – 将所有节点从当前主机复制到另一台主机。
$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets
第 4 步– 升级主机上的 Docker 设置。
$ yum update docker
步骤 5 – 重新启动 Docker 服务，然后启动 Docker 服务节点。
$systemctl restart docker $ systemctl restart atomic-openshift-node
步骤 6 – 检查它们是否都正确启动。
$ journalctl -r -u atomic-openshift-node
步骤 7 – 升级完成后，重启节点机器。
$ systemctl reboot $ journalctl -r -u docker
步骤 8 – 在节点上重新启用调度。
$ oadm manage-node <node> --schedulable.
第 9 步– 运行 atomic-openshift 执行器以将 OpenShift 包重新放到节点上。
$ atomic-openshift-excluder exclude
步骤 10 – 最后，检查所有节点是否可用。
$ oc get nodes NAME STATUS AGE master.example.com Ready 12d node1.example.com Ready 12d node2.example.com Ready 12d
OpenShift – 应用程序扩展
Autoscaling 是 OpenShift 中的一项功能，部署的应用程序可以根据特定规范在需要时进行扩展和下沉。在 OpenShift 应用程序中，自动缩放也称为 pod 自动缩放。有两种类型的应用程序扩展如下。
垂直缩放
垂直扩展就是为一台机器增加越来越多的功率，这意味着增加更多的 CPU 和硬盘。这是 OpenShift 的一种旧方法，现在 OpenShift 版本不支持它。
水平缩放
当需要通过增加机器数量来处理更多请求时，这种类型的扩展非常有用。
在 OpenShift 中，有两种方法可以启用缩放功能。
- 使用部署配置文件
- 运行图像时
使用部署配置文件
在这种方法中，扩展功能是通过部署配置 yaml 文件启用的。为此，OC autoscale 命令与最小和最大副本数一起使用，这些副本需要在集群中的任何给定时间点运行。我们需要一个对象定义来创建自动缩放器。以下是 pod 自动缩放器定义文件的示例。
apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
name: database
spec:
scaleRef:
kind: DeploymentConfig
name: database
apiVersion: v1
subresource: scale
minReplicas: 1
maxReplicas: 10
cpuUtilization:
targetPercentage: 80
一旦我们有了文件，我们需要以 yaml 格式保存它并运行以下命令进行部署。
$ oc create –f <file name>.yaml
运行图像时
也可以在没有 yaml 文件的情况下自动缩放，方法是在 oc 命令行中使用以下oc autoscale命令。
$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75 deploymentconfig "database" autoscaled
这个命令也会生成一个类似的文件，以后可以参考。
OpenShift 中的部署策略
OpenShift 中的部署策略定义了具有不同可用方法的部署流程。在 OpenShift 中，以下是重要的部署策略类型。
- 滚动策略
- 重新创建策略
- 自定义策略
以下是部署配置文件示例，主要用于在 OpenShift 节点上进行部署。
kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
name: "database"
spec:
template:
metadata:
labels:
name: "Database1"
spec:
containers:
- name: "vipinopenshifttest"
image: "openshift/mongoDB"
ports:
- containerPort: 8080
protocol: "TCP"
replicas: 5
selector:
name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
imageChangeParams:
automatic: true
containerNames:
- "vipinopenshifttest"
from:
kind: "ImageStreamTag"
name: "mongoDB:latest"
strategy:
type: "Rolling"
在上面的 Deploymentconfig 文件中，我们将策略设置为 Rolling。
我们可以使用下面的OC命令进行部署。
$ oc deploy <deployment_config> --latest
滚动策略
滚动策略用于滚动更新或部署。此过程还支持生命周期钩子，用于将代码注入任何部署过程。
strategy:
type: Rolling
rollingParams:
timeoutSeconds: <time in seconds>
maxSurge: "<definition in %>"
maxUnavailable: "<Defintion in %>"
pre: {}
post: {}
重新创建策略
这种部署策略具有滚动部署策略的一些基本特性，并且还支持生命周期钩子。
strategy:
type: Recreate
recreateParams:
pre: {}
mid: {}
post: {}
自定义策略
当人们希望提供自己的部署过程或流程时，这非常有用。所有定制都可以根据要求完成。
strategy:
type: Custom
customParams:
image: organization/mongoDB
command: [ "ls -l", "$HOME" ]
environment:
- name: VipinOpenshiftteat
value: Dev1
OpenShift – 管理
在本章中，我们将涵盖诸如如何管理节点、配置服务帐户等主题。
主节点和节点配置
在 OpenShift 中，我们需要使用 start 命令和 OC 来启动新服务器。在启动一个新的 master 时，我们需要将 master 与 start 命令一起使用，而在启动新节点时，我们需要将 node 与 start 命令一起使用。为此，我们需要为主节点和节点创建配置文件。我们可以使用以下命令为 master 和 node 创建基本配置文件。
对于主配置文件
$ openshift start master --write-config = /openshift.local.config/master
对于节点配置文件
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
一旦我们运行以下命令，我们将获得可用作配置起点的基本配置文件。稍后，我们可以使用相同的文件来启动新服务器。
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600
节点配置文件
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory: /root/openshift.local.volumes
这就是节点配置文件的样子。一旦我们有了这些配置文件，我们就可以运行以下命令来创建主服务器和节点服务器。
$ openshift start --master-config = /openshift.local.config/master/master- config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node- config.yaml
管理节点
在 OpenShift 中，我们有 OC 命令行实用程序，主要用于执行 OpenShift 中的所有操作。我们可以使用以下命令来管理节点。
用于列出节点
$ oc get nodes NAME LABELS node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com node2.example.com kubernetes.io/hostname = vklnld1447.int.example.com
描述有关节点的详细信息
$ oc describe node <node name>
删除节点
$ oc delete node <node name>
列出节点上的 pod
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
评估节点上的 Pod
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
配置认证
在 OpenShift master 中，有一个内置的 OAuth 服务器，可用于管理身份验证。所有 OpenShift 用户都从该服务器获取令牌，这有助于他们与 OpenShift API 进行通信。
OpenShift 中有不同类型的身份验证级别，可以与主配置文件一起配置。
- 允许全部
- 全部拒绝
- HT密码
- LDAP
- 基本认证
- 请求头
在定义主配置时，我们可以定义标识策略，我们可以在其中定义我们希望使用的策略类型。
允许全部
允许全部
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
全部拒绝
这将拒绝访问所有用户名和密码。
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HT密码
HTPasswd 用于根据加密文件密码验证用户名和密码。
要生成加密文件，以下是命令。
$ htpasswd </path/to/users.htpasswd> <user_name>
使用加密文件。
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
LDAP 身份提供者
这用于 LDAP 身份验证，其中 LDAP 服务器在身份验证中起着关键作用。
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"
基本认证
当根据服务器到服务器的身份验证完成用户名和密码的验证时使用。身份验证在基本 URL 中受到保护，并以 JSON 格式显示。
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca: /path/to/ca.file
certFile: /path/to/client.crt
keyFile: /path/to/client.key
配置服务帐号
服务帐户提供了一种访问 OpenShift API 的灵活方式，公开了用于身份验证的用户名和密码。
启用服务帐户
服务帐户使用公钥和私钥的密钥对进行身份验证。API 的身份验证是使用私钥完成的，并根据公钥对其进行验证。
ServiceAccountConfig: ... masterCA: ca.crt privateKeyFile: serviceaccounts.private.key publicKeyFiles: - serviceaccounts.public.key - ...
创建服务帐户
使用以下命令创建服务帐户
$ Openshift cli create service account <name of server account>
使用 HTTP 代理
在大多数生产环境中，直接访问 Internet 是受到限制的。它们要么不公开给 Internet，要么通过 HTTP 或 HTTPS 代理公开。在 OpenShift 环境中，此代理机器定义被设置为环境变量。
这可以通过在位于/etc/sysconfig下的 master 和 node 文件上添加代理定义来完成。这与我们对任何其他应用程序所做的类似。
主机
/etc/sysconfig/openshift-master
HTTP_PROXY=http://USERNAME:[email protected]:8080/ HTTPS_PROXY=https://USERNAME:[email protected]:8080/ NO_PROXY=master.vklnld908.int.example.com
节点机
/etc/sysconfig/openshift-node
HTTP_PROXY=http://USERNAME:[email protected]:8080/ HTTPS_PROXY=https://USERNAME:[email protected]:8080/ NO_PROXY=master.vklnld908.int.example.com
完成后，我们需要重新启动 master 和 node 机器。
对于 Docker 拉取
/etc/sysconfig/docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/ HTTPS_PROXY = https://USERNAME:[email protected]:8080/ NO_PROXY = master.vklnld1446.int.example.com
为了使 pod 在代理环境中运行，可以使用以下方法完成 –
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
OC 环境命令可用于更新现有的 env。
使用 NFS 的 OpenShift 存储
在 OpenShift 中，持久卷和持久卷声明的概念构成了持久存储。这是创建第一个持久卷然后声明相同卷的关键概念之一。为此，我们需要在底层硬件上有足够的容量和磁盘空间。
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
接下来，使用 OC create 命令创建 Persistent Volume。
$ oc create -f storage-unit1.yaml persistentvolume " storage-unit1 " created
声明创建的卷。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
创建索赔。
$ oc create -f Storage-claim1.yaml persistentvolume " Storage-clame1 " created
用户和角色管理
用户和角色管理用于管理用户、他们对不同项目的访问和控制。
创建用户
预定义的模板可用于在 OpenShift 中创建新用户。
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"
使用 oc create –f <文件名> 创建用户。
$ oc create –f vipin.yaml
使用以下命令删除 OpenShift 中的用户。
$ oc delete user <user name>
限制用户访问
ResourceQuotas 和 LimitRanges 用于限制用户访问级别。它们用于限制集群上的 pod 和容器。
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
使用上述配置创建报价
$ oc create -f resource-quota.yaml –n –Openshift-sample
描述资源报价
$ oc describe quota resource-quota -n Openshift-sample Name: resource-quota Namespace: Openshift-sample Resource Used Hard -------- ---- ---- pods 3 10
定义容器限制可用于限制部署容器将使用的资源。它们用于定义某些对象的最大和最小限制。
用户项目限制
这基本上用于用户在任何时间点可以拥有的项目数量。它们基本上是通过在青铜、白银和黄金类别中定义用户级别来完成的。
我们需要首先定义一个对象，该对象保存青铜、白银和黄金类别可以拥有多少个项目的价值。这些需要在 master-confif.yaml 文件中完成。
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5
重新启动主服务器。
将用户分配到特定级别。
$ oc label user vipin level = gold
如果需要，将用户移出标签。
$ oc label user <user_name> level-
向用户添加角色。
$ oadm policy add-role-to-user<user_name>
从用户中删除角色。
$ oadm policy remove-role-from-user<user_name>
为用户添加集群角色。
$ oadm policy add-cluster-role-to-user<user_name>
从用户中删除集群角色。
$ oadm policy remove-cluster-role-from-user<user_name>
向组添加角色。
$ oadm policy add-role-to-user<user_name>
从组中删除角色。
$ oadm policy remove-cluster-role-from-user<user_name>
将集群角色添加到组。
$ oadm policy add-cluster-role-to-group<groupname>
从组中删除集群角色。
$ oadm policy remove-cluster-role-from-group <role> <groupname>
集群管理用户
这是最强大的角色之一，用户可以在其中管理从创建到删除集群的整个集群。
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
拥有终极权力的用户
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>
OpenShift – Docker 和 Kubernetes
OpenShift 构建在 Docker 和 Kubernetes 之上。所有的容器都建立在 Docker 集群之上，Docker 集群基本上是 Linux 机器之上的 Kubernetes 服务，使用 Kubernetes 编排功能。
在这个过程中，我们构建了 Kubernetes master 来控制所有节点并将容器部署到所有节点。Kubernetes 的主要功能是使用不同类型的配置文件来控制 OpenShift 集群和部署流程。与在 Kubernetes 中一样，我们使用 kubctl 的方式与使用 OC 命令行实用程序在集群节点上构建和部署容器的方式相同。
以下是用于在集群中创建不同类型对象的不同类型的配置文件。
- 图片
- 荚
- 服务
- 复制控制器
- 副本集
- 部署
图片
Kubernetes (Docker) 镜像是容器化基础设施的关键构建块。目前，Kubernetes 仅支持Docker镜像。Pod 中的每个容器都有其 Docker 映像在其中运行。
apiVersion: v1 kind: pod metadata: name: Tesing_for_Image_pull -----------> 1 spec: containers: - name: neo4j-server ------------------------> 2 image: <Name of the Docker image>----------> 3 imagePullPolicy: Always ------------->4 command: [“echo”, “SUCCESS”] -------------------> 5
荚
Pod 是容器及其存储在 Kubernetes 集群节点内的集合。可以创建一个包含多个容器的 pod。以下是将数据库容器和 Web 界面容器保存在同一个 pod 中的示例。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
服务
服务可以定义为一组逻辑 pod。它可以定义为 pod 之上的抽象，提供单个 IP 地址和 DNS 名称，可以通过它访问 pod。使用 Service，可以非常轻松地管理负载平衡配置。它可以帮助 POD 非常轻松地扩展。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999
复制控制器
Replication Controller 是 Kubernetes 的关键特性之一，它负责管理 pod 生命周期。它负责确保指定数量的 pod 副本在任何时间点都在运行。
apiVersion: v1
kind: ReplicationController
metadata:
name: Tomcat-ReplicationController
spec:
replicas: 3
template:
metadata:
name: Tomcat-ReplicationController
labels:
app: App
component: neo4j
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7474
副本集
副本集确保应该运行多少个 pod 副本。它可以被认为是复制控制器的替代品。
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
selector:
matchLables:
tier: Backend
matchExpression:
- { key: tier, operation: In, values: [Backend]}
app: App
component: neo4j
spec:
containers:
- name: Tomcat-
image: tomcat: 8.0
ports:
containerPort: 7474
部署
部署升级和更高版本的复制控制器。他们管理副本集的部署，这也是复制控制器的升级版本。它们具有更新副本集的能力，也能够回滚到以前的版本。
apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
template:
metadata:
lables:
app: Tomcat-ReplicaSet
tier: Backend
spec:
containers:
name: Tomcat-
image: tomcat: 8.0
ports:
- containerPort: 7474
所有配置文件都可用于创建各自的 Kubernetes 对象。
$ Kubectl create –f <file name>.yaml
以下命令可用于了解 Kubernetes 对象的详细信息和描述。
对于 POD
$ Kubectl get pod <pod name> $ kubectl delete pod <pod name> $ kubectl describe pod <pod name>
对于复制控制器
$ Kubectl get rc <rc name> $ kubectl delete rc <rc name> $ kubectl describe rc <rc name>
服务
$ Kubectl get svc <svc name> $ kubectl delete svc <svc name> $ kubectl describe svc <svc name>
有关如何使用 Docker 和 Kubernetes 的更多详细信息，请使用以下链接kubernetes访问我们的 Kubernetes 教程。
OpenShift – 安全性
OpenShift 安全主要是两个主要处理安全约束的组件的组合。
- 安全上下文约束 (SCC)
- 服务帐号
安全上下文约束 (SCC)
它基本上用于 pod 限制，这意味着它定义了 pod 的限制，例如它可以执行哪些操作以及它可以访问集群中的所有内容。
OpenShift 提供了一组预定义的 SCC，可供管理员使用、修改和扩展。
$ oc get scc NAME PRIV CAPS HOSTDIR SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY anyuid false [] false MustRunAs RunAsAny RunAsAny RunAsAny 10 hostaccess false [] true MustRunAs MustRunAsRange RunAsAny RunAsAny <none> hostmount-anyuid false [] true MustRunAs RunAsAny RunAsAny RunAsAny <none> nonroot false [] false MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> privileged true [] true RunAsAny RunAsAny RunAsAny RunAsAny <none> restricted false [] false MustRunAs MustRunAsRange RunAsAny RunAsAny <none>
如果希望使用任何预定义的 scc，只需将用户或组添加到 scc 组即可。
$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>
服务帐号
服务帐户基本上用于控制对 OpenShift 主 API 的访问，当从任何主计算机或节点计算机发出命令或请求时调用该 API。
任何时候应用程序或进程需要受限 SCC 未授予的功能，您都必须创建一个特定的服务帐户并将该帐户添加到相应的 SCC。但是，如果 SCC 不适合您的要求，那么最好根据您的要求创建一个新的 SCC，而不是使用最适合的 SCC。最后，将其设置为部署配置。
$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin
容器安全
在 OpenShift 中，容器的安全性基于容器平台的安全性以及容器在哪里运行的概念。当我们谈论容器安全性以及需要注意的事项时，会涉及很多方面。
Image Provenance – 一个安全的标签系统到位，可以准确无误地识别在生产环境中运行的容器的来源。
安全扫描– 图像扫描仪会自动检查所有图像是否存在已知漏洞。
审核– 定期审核生产环境，以确保所有容器都基于最新的容器，并且主机和容器均已安全配置。
隔离和最低权限– 容器以有效运行所需的最少资源和权限运行。他们不能过度干扰主机或其他容器。
运行时威胁检测– 一种在运行时检测针对容器化应用程序的主动威胁并自动响应的功能。
访问控制– Linux 安全模块，例如 AppArmor 或 SELinux，用于实施访问控制。
归档容器安全的关键方法很少。
- 通过 oAuth 控制访问
- 通过自助服务 Web 控制台
- 按平台证书
通过 OAuth 控制访问
在这种方法中，API 控制访问的身份验证被存档，通过 OAuth 服务器获取用于身份验证的安全令牌，OAuth 服务器内置于 OpenShift 主机中。作为管理员，您可以修改 OAuth 服务器配置的配置。
有关 OAuth 服务器配置的更多详细信息，请参阅本教程的第 5 章。
通过自助服务 Web 控制台
此 Web 控制台安全功能内置于 OpenShift Web 控制台中。此控制台可确保所有协同工作的团队在未经身份验证的情况下无法访问其他环境。OpenShift 中的多 telnet master 具有以下安全功能 –
- TCL层已启用
- 使用 x.509 证书进行身份验证
- 保护主机上的 etcd 配置
按平台证书
在这种方法中，每个主机的证书都是在安装过程中通过 Ansible 配置的。由于它通过 Rest API 使用 HTTPS 通信协议，我们需要 TCL 安全连接到不同的组件和对象。这些是预定义的证书，但是，您甚至可以在主集群上安装自定义证书以供访问。在 master 的初始设置期间，可以通过使用openshift_master_overwrite_named_certificates参数覆盖现有证书来配置自定义证书。
例子
openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt",
"keyfile": "/path/on/host/to/master.key",
"cafile": "/path/on/host/to/mastercert.crt"}]
有关如何生成自定义证书的更多详细信息，请访问以下链接 –
https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux
网络安全
在 OpenShift 中，软件定义网络 (SDN) 用于通信。网络命名空间用于集群中的每个 pod，其中每个 pod 都有自己的 IP 和一系列端口来获取网络流量。通过这种方法，一个人可以隔离 Pod，因为它不能与另一个项目中的 Pod 通信。
隔离项目
这可以由集群管理员使用CLI 中的以下oadm 命令来完成。
$ oadm pod-network isolate-projects <project name 1> <project name 2>
这意味着上面定义的项目无法与集群中的其他项目进行通信。
卷安全
卷安全显然意味着保护 OpenShift 集群中项目的 PV 和 PVC。OpenShift 中主要有四个部分来控制对卷的访问。
- 补充组
- 组
- 以用户身份运行
- seLinux 选项
补充组 – 补充组是常规的 Linux 组。当一个进程在系统中运行时，它以用户 ID 和组 ID 运行。这些组用于控制对共享存储的访问。
使用以下命令检查 NFS 挂载。
# showmount -e <nfs-server-ip-or-hostname> Export list for f21-nfs.vm: /opt/nfs *
使用以下命令检查挂载服务器上的 NFS 详细信息。
# cat /etc/exports /opt/nfs *(rw,sync,no_root_squash) ... # ls -lZ /opt/nfs -d drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs # id nfsnobody uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)
该的/ opt / NFS /出口是UID访问454265和组2325。
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: ...
volumeMounts:
- name: nfs
mountPath: /usr/share/...
securityContext:
supplementalGroups: [2325]
volumes:
- name: nfs
nfs:
server: <nfs_server_ip_or_host>
path: /opt/nfs
组
fsGroup 代表文件系统组，用于添加容器补充组。补充组ID用于共享存储，fsGroup用于块存储。
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325
以用户身份运行
runAsUser 使用用户 ID 进行通信。这用于在 pod 定义中定义容器映像。如果需要，可以在所有容器中使用单个 ID 用户。
在运行容器时，定义的 ID 与导出的所有者 ID 匹配。如果指定的 ID 是在外部定义的，那么它对 pod 中的所有容器都是全局的。如果它是用特定的 pod 定义的，那么它就特定于单个容器。
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265
