OpenShift - 快速指南
OpenShift - 概述
OpenShift 是由 Red Hat 托管的云开发平台即服务 (PaaS)。它是一个基于云的开源用户友好平台,用于创建、测试和运行应用程序,并最终将它们部署到云上。
OpenShift 能够管理用不同语言编写的应用程序,例如 Node.js、Ruby、Python、Perl 和 Java。OpenShift 的主要功能之一是可扩展,这有助于用户支持用其他语言编写的应用程序。
OpenShift 带有各种虚拟化概念作为其抽象层。OpenShift 背后的底层概念基于虚拟化。
虚拟化
一般来说,虚拟化可以定义为从系统、存储或操作系统开始创建虚拟系统,而不是任何物理或实际版本。虚拟化的主要目标是使 IT 基础架构更具可扩展性和可靠性。虚拟化的概念已经存在了几十年,随着当今 IT 行业的发展,它可以应用于从系统级、硬件级到服务器级虚拟化的各个层面。
工作原理
它可以被描述为一种将任何应用程序或操作系统从其实际物理层中抽象出来的技术。虚拟化技术的一个关键用途是服务器虚拟化,它使用一种称为虚拟机管理程序的软件将该层从底层硬件中抽象出来。在虚拟化上运行的操作系统的性能与在物理硬件上运行时一样好。然而,虚拟化的概念很流行,因为大多数系统和应用程序的运行不需要使用底层硬件。
物理与虚拟架构
虚拟化的类型
应用程序虚拟化 − 在此方法中,应用程序从底层操作系统中抽象出来。此方法非常有用,其中应用程序可以独立运行,而不依赖于底层操作系统。
桌面虚拟化 − 此方法用于减少工作站负载,其中可以使用桌面上的瘦客户端远程访问桌面。在此方法中,桌面大多在数据中心运行。一个典型的例子是大多数组织中使用的虚拟桌面映像 (VDI)。
数据虚拟化 − 这是一种抽象和摆脱传统数据和数据管理方法的方法。
服务器虚拟化 − 在此方法中,与服务器相关的资源被虚拟化,包括物理服务器、进程和操作系统。实现此抽象的软件通常称为虚拟机管理程序。
存储虚拟化 − 它是将多个存储设备集中到从单个中央控制台管理的单个存储设备的过程。
网络虚拟化 −这是一种将所有可用网络资源通过分割可用带宽和通道组合在一起的方法,每个带宽和通道彼此独立。
OpenShift
OpenShift 是一个支持云的应用程序平台即服务 (PaaS)。它是一种开源技术,可帮助组织将其传统应用程序基础架构和平台从物理、虚拟介质迁移到云。
OpenShift 支持各种各样的应用程序,这些应用程序可以在 OpenShift 云平台上轻松开发和部署。OpenShift 基本上为开发人员和用户支持三种平台。
基础设施即服务 (IaaS)
在这种形式下,服务提供商提供具有一些预定义虚拟硬件配置的硬件级虚拟机。该领域有多个竞争对手,从 AWS Google Cloud 开始,Rackspace 等等。
经过漫长的设置和投资过程后,拥有 IaaS 的主要缺点是,用户仍然需要负责安装和维护操作系统和服务器包、管理基础设施网络以及负责基本的系统管理。
软件即服务 (SaaS)
使用 SaaS,用户无需担心底层基础设施。它就像即插即用一样简单,用户只需注册服务并开始使用即可。这种设置的主要缺点是,用户只能执行服务提供商允许的最低限度的自定义。SaaS 最常见的示例之一是 Gmail,用户只需登录即可开始使用。用户还可以对其帐户进行一些小的修改。但是,从开发人员的角度来看,它并不是很有用。
平台即服务 (PaaS)
它可以被视为 SaaS 和 IaaS 之间的中间层。PaaS 评估的主要目标是开发人员,其中开发环境可以通过几个命令启动。这些环境的设计方式是,它们可以满足所有开发需求,从拥有带有数据库的 Web 应用程序服务器开始。为此,您只需要一个命令,服务提供商就会为您完成所有工作。
为什么使用 OpenShift?
OpenShift 为企业单位提供了一个通用平台,可以在云上托管他们的应用程序,而无需担心底层操作系统。这使得在云上使用、开发和部署应用程序变得非常容易。其中一个关键功能是,它为各种开发和测试提供托管硬件和网络资源。借助 OpenShift,PaaS 开发人员可以自由地根据规范设计所需的环境。
OpenShift 在服务计划方面提供不同类型的服务级别协议。
免费 − 此计划限制为三年,每个计划 1GB 空间。
青铜级 − 此计划包括 3 年,每年可延长至 16 年,1GB 空间。
Sliver − 这是 16 年的青铜级计划,但存储容量为 6GB,无需额外费用。
除了上述功能外,OpenShift 还提供称为 OpenShift Enterprise 的本地版本。在 OpenShift 中,开发人员可以利用设计可扩展和不可扩展的应用程序,这些设计是使用 HAproxy 服务器实现的。
功能
OpenShift 支持多种功能。其中很少有 −
- 多语言支持
- 多数据库支持
- 可扩展的盒式系统
- 源代码版本管理
- 一键部署
- 多环境支持
- 标准化开发人员工作流程
- 依赖项和构建管理
- 自动应用程序扩展
- 响应式 Web 控制台
- 丰富的命令行工具集
- 远程 SSH 登录应用程序
- Rest API 支持
- 自助式按需应用程序堆栈
- 内置数据库服务
- 持续集成和发布管理
- IDE 集成
- 应用程序的远程调试
OpenShift - 类型
OpenShift 诞生于名为 OpenShift V2 的基础,它主要基于Gear和Cartridges的概念,其中每个组件都有其规格,从机器创建到应用程序部署,从构建到部署应用程序。
Cartridges − 它们是构建新应用程序的焦点,从运行它们的环境所需的应用程序类型以及本节中满足的所有依赖关系开始。
Gear − 它可以定义为具有特定资源、内存和 CPU 规格的主机或服务器。它们被视为运行应用程序的基本单元。
Application − 这些只是指将在 OpenShift 环境中部署和运行的应用程序或任何集成应用程序。
随着我们深入本节,我们将讨论 OpenShift 的不同格式和产品。早期,OpenShift 有三个主要版本。
OpenShift Origin − 这是 OpenShift 的社区补充或开源版本。它也被称为其他两个版本的上游项目。
OpenShift Online − 它是一个托管在 AWS 上的公共 PaaS 服务。
OpenShift Enterprise − 是具有 ISV 和供应商许可证的 OpenShift 强化版本。
OpenShift Online
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 Dedicated
这是 OpenShift 产品组合中新增的另一项产品,客户可以选择在他们选择的任何公共云上托管容器化平台。这让最终用户真正感受到了多云产品,他们可以在任何满足其需求的云上使用 OpenShift。
这是 Red Hat 的最新产品之一,最终用户可以使用 OpenShift 在托管在云上的 OpenShift 上构建测试部署并运行他们的应用程序。
OpenShift Dedicated 的功能
OpenShift Dedicated 在公共云上提供定制的解决方案应用程序平台,它继承自 OpenShift 3 技术。
可扩展和开放 − 它建立在 Docker 的开放概念上并部署在云上,因此它可以根据需要进行扩展。
可移植性 −由于它是使用 Docker 构建的,因此在 Docker 上运行的应用程序可以轻松地从一个地方运送到另一个支持 Docker 的地方。
编排 − 使用 OpenShift 3,容器编排和集群管理的主要功能之一由 Kubernetes 支持,Kubernetes 随 OpenShift 版本 3 一起提供。
自动化 − 此版本的 OpenShift 启用了源代码管理、构建自动化和部署自动化功能,这使其作为平台即服务提供商在市场上非常受欢迎。
OpenShift 的竞争对手
Google App Engine − 这是 Google 用于开发和托管 Web 应用程序的免费平台。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 − Red Hat 为云计算提供的另一种云技术。
Kubernetes − 它是一种直接编排和集群管理技术,旨在管理 Docker 容器。
OpenShift - 架构
OpenShift 是一个分层系统,其中每一层都使用 Kubernetes 和 Docker 集群与其他层紧密绑定。OpenShift 的架构设计使其能够支持和管理 Docker 容器,这些容器使用 Kubernetes 托管在所有层之上。与早期版本的 OpenShift V2 不同,新版本的 OpenShift V3 支持容器化基础设施。在此模型中,Docker 有助于创建基于 Linux 的轻量级容器,而 Kubernetes 支持在多个主机上编排和管理容器的任务。
OpenShift 的组件
OpenShift 架构的关键组件之一是在 Kubernetes 中管理容器化基础设施。Kubernetes 负责基础设施的部署和管理。在任何 Kubernetes 集群中,我们都可以拥有多个主节点和多个节点,从而确保设置中没有故障点。
Kubernetes 主机组件
Etcd − 它存储配置信息,集群中的每个节点都可以使用这些信息。它是一个高可用性键值存储,可以分布在多个节点之间。它应该只能由 Kubernetes API 服务器访问,因为它可能包含敏感信息。它是一个分布式键值存储,所有人都可以访问。
API 服务器 − Kubernetes 是一个 API 服务器,它使用 API 提供集群上的所有操作。API 服务器实现了一个接口,这意味着不同的工具和库可以随时与其通信。kubeconfig 是一个包,其中包含可用于通信的服务器端工具。它公开 Kubernetes API"。
控制器管理器 − 此组件负责大多数收集器,这些收集器调节集群的状态并执行任务。它可以被视为一个在非终止循环中运行的守护进程,负责收集信息并将其发送到 API 服务器。它致力于获取集群的共享状态,然后进行更改以使服务器的当前状态达到所需状态。关键控制器是复制控制器、端点控制器、命名空间控制器和服务帐户控制器。控制器管理器运行不同类型的控制器来处理节点、端点等。
调度程序 − 它是 Kubernetes master 的关键组件。它是 master 中的一项服务,负责分配工作负载。它负责跟踪集群节点上的工作负载利用率,然后将工作负载放在可用资源上并接受工作负载。换句话说,这是负责将 pod 分配给可用节点的机制。调度程序负责工作负载利用率并将 pod 分配给新节点。
Kubernetes 节点组件
以下是节点服务器的关键组件,这些组件是与 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 中存在的域的重命名版本。
容器 − 它们是在将映像部署到 Kubernetes 集群节点后创建的容器。
节点 − 节点是 Kubernetes 集群中的工作机器,也称为 master 的 minion。它们是工作单元,可以是物理、VM 或云实例。
Pod − Pod 是 Kubernetes 集群节点内的容器及其存储的集合。可以创建一个包含多个容器的 Pod。例如,将数据库容器和 Web 服务器容器保留在 Pod 内。
OpenShift - 环境设置
在本章中,我们将了解 OpenShift 的环境设置。
系统要求
为了设置企业 OpenShift,需要有一个活跃的 Red Hat 帐户。由于 OpenShift 在 Kubernetes 主节点架构上运行,我们需要在不同的机器上设置它们,其中一台机器充当主节点,另一台机器在节点上运行。为了设置两者,有最低系统要求。
主机配置
以下是主机配置的最低系统要求。
托管在物理、虚拟或任何云环境中的基础机器。
该实例上至少有 Linux 7 和所需的软件包。
2 个 CPU 核心。
至少 8 GB RAM。
30 GB 内部硬盘内存。
节点机配置
- 主机提供的物理或虚拟基础映像。
- 机器上至少有 Linux 7。
- 安装的 Docker 不低于 1.6版本。
- 1 个 CPU 核心。
- 8 GB RAM。
- 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 中的 Docker 文件。如果该文件不存在,则需要手动创建它。
# vi /etc/sysconfig/docker OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24
在主机上配置 Docker 后,我们需要在两台机器之间设置无密码通信。为此,我们将使用公钥和私钥身份验证。
步骤 3 −在主机上生成密钥,然后将 id_rsa.pub 密钥复制到节点机的授权密钥文件中,这可以使用以下命令完成。
# ssh-keygen
# ssh-copy-id -i .ssh/id_rsa.pub root@ose3-node.test.com
完成上述所有设置后,接下来是在主机上设置 OpenShift 版本 3。
步骤 4 −从主机运行以下 curl 命令。
# sh <(curl -s https://install.openshift.com/ose)
上述命令将为 OSV3 完成设置。下一步是在机器上配置 OpenShift V3。
如果您无法直接从互联网下载,则可以从 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 reloadfirewalld
#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
Pod 可以定义为 OpenShift (Kubernetes) 集群节点内的容器及其存储的集合。一般来说,我们有两种类型的 pod,从单容器 pod 到多容器 pod。
单容器 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
多容器 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 中,构建是将图像转换为容器的过程。它是将源代码转换为图像的处理。此构建过程基于将源代码构建为图像的预定义策略。
构建处理多个策略和来源。
构建策略
源到图像 − 这基本上是一个工具,可帮助构建可重现的图像。这些图像始终处于准备就绪阶段,可以使用 Docker run 命令运行。
Docker 构建 − 这是通过运行简单的 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 USER 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 和 Web 套接字
配置服务时,选择器用于配置服务并使用该服务查找端点。下面是一个示例,说明如何使用适当的协议创建服务以及该服务的路由。
{
"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 中,在配置主服务器和客户端结构时,主服务器会提供 OAuth 服务器的内置功能。OAuth 服务器用于生成令牌,用于对 API 进行身份验证。由于 OAuth 是主服务器的默认设置,因此我们默认使用允许所有身份提供者。存在不同的身份提供者,可在 /etc/openshift/master/master-config.yaml 中配置。
OAuth 中存在不同类型的身份提供者。
- Allow All
- Deny All
- HTPasswd
- LDAP
- Basic Authentication
Allow All
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
Deny All
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
HTPasswd
为了使用 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 。<听。表示当前工作目录>
以下是尝试从远程存储库构建特定分支的示例。
$ 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 作业定义中的作业定义进行比较。在创建构建流程时,我们必须选择构建策略。
BuildConfig 文件
在 OpenShift 中,BuildConfig 是一个用于连接到 API 然后创建新实例的 rest 对象。
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
USER 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
有多种策略策略。
- Forcepull
- 增量构建
- 外部构建
Docker 策略
在此流程中,OpenShift 使用 Dockerfile 构建映像,然后将创建的映像上传到 Docker 注册表。
strategy:
type: Docker
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "ubuntu:latest"
Docker 文件选项可以在多个位置使用,从文件路径、无缓存和强制拉取开始。
- 从图像
- Dockerfile 路径
- 无缓存
- 强制拉取
自定义策略
这是不同类型的构建策略之一,其中没有强制要求构建的输出是图像。它可以与 Jenkins 的自由式作业进行比较。通过它,我们可以创建 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') {
stage 'build'
openshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')
stage 'deploy'
openshiftDeploy(deploymentConfig: 'backend')
}"
使用构建管道
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\10.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 客户端
我们可以将 Mac OS 安装二进制文件下载到与 Windows 相同的位置,然后将其解压到某个位置,并在环境 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]
示例
# 以交互方式登录 oc login # 使用给定的证书颁发机构文件登录到给定的服务器 oc login localhost:8443 --certificate-authority = /path/to/cert.crt # 使用给定的凭据登录到给定的服务器(不会以交互方式提示) oc login localhost:8443 --username = myuser --password=mypass
选项 −
-p, --password = " − 密码,如果未提供,将提示
-u, --username = " −用户名,若未提供,将会提示
--certificate-authority = " − 证书颁发机构的证书文件路径
--insecure-skip-tls-verify = false − 如果为 true,则不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全
--token = " − 用于向 API 服务器进行身份验证的 Bearer 令牌
要获取有关任何命令的完整详细信息,请使用 oc <命令名称> --help 命令。
构建和部署命令
下表列出了构建和部署命令。
| Sr.No. | 命令和说明 |
|---|---|
| 1 | Rollout 管理 Kubernetes 部署或 OpenShift 部署 |
| 2 | Deploy 查看、启动、取消或重试部署 |
| 3 | Rollback 将应用程序的一部分恢复到之前的状态 |
| 4 | new-build 创建新的构建配置 |
| 5 | start-build 启动新build |
| 6 | cancel-build 取消正在运行、待处理或新建的构建 |
| 7 | import-image 从 Docker 注册表导入镜像 |
| 8 | Tag 将现有镜像标记到镜像流中 |
应用程序管理命令
下表列出了应用程序管理命令。
| 序号 | 命令和说明 |
|---|---|
| 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 管理项目中的服务帐户 |
故障排除和调试命令
下表列出了故障排除和调试命令。
| 序号 | 命令和说明 |
|---|---|
| 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 集群日志不过是从集群的主服务器和节点机器生成的日志。这些可以管理任何类型的日志,从服务器日志、主日志、容器日志、pod 日志等开始。目前有多种用于容器日志管理的技术和应用程序。
下面列出了一些可用于日志管理的工具。
- Fluentd
- ELK
- Kabna
- Nagios
- Splunk
ELK 堆栈 − 此堆栈在尝试从所有节点收集日志并以系统格式呈现时很有用。ELK 堆栈主要分为三大类。
ElasticSearch − 主要负责从所有容器收集信息并将其放到中央位置。
Fluentd − 用于将收集到的日志提供给 elasticsearch 容器引擎。
Kibana − 图形界面,用于将收集的数据作为有用信息呈现在图形界面中。
需要注意的一点是,当此系统部署在集群上时,它会开始从所有节点收集日志。
日志诊断
OpenShift 有一个内置的 oc adm dignostics 命令和 OC,可用于分析多种错误情况。集群管理员可以从主服务器使用此工具。此实用程序在排除故障和诊断已知问题方面非常有用。它在主客户端和节点上运行。
如果在没有任何参数或标志的情况下运行,它将查找客户端、服务器和节点机器的配置文件,并使用它们进行诊断。可以通过传递以下参数单独运行诊断 −
- AggregatedLogging
- AnalyzeLogs
- ClusterRegistry
- ClusterRoleBindings
- ClusterRoles
- ClusterRouter
- ConfigContexts
- DiagnosticPod
- MasterConfigCheck
- MasterNode
- MetricsApiProxy
- NetworkCheck
- NodeConfigCheck
- NodeDefinitions
- ServiceExternalIPs
- UnitStatus
只需使用以下命令即可运行它们。
$ oc adm diagnostics <DiagnosticName>
升级集群
集群升级涉及升级集群内的多个内容,并使用新组件和升级更新集群。这涉及 −
- 主组件升级
- 节点组件升级
- 策略升级
- 路由升级
- 图像流升级
为了执行所有这些升级,我们需要首先获取快速安装程序或实用程序。为此,我们需要更新以下实用程序 −
- atomic-openshift-utils
- atomic-openshift-excluder
- atomic-openshift-docker-excluder
- etcd 包
在开始升级之前,我们需要在主机上备份 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。最后,我们运行自动执行程序以使集群进入所需位置。但是,在开始升级之前,我们需要首先在每个主服务器上激活原子 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 drip <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 - 应用程序扩展
自动扩展是 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 来启动新服务器。启动新主服务器时,我们需要使用主服务器和 start 命令,而启动新节点时,我们需要使用节点和 start 命令。为此,我们需要为主服务器和节点创建配置文件。我们可以使用以下命令为主服务器和节点创建一个基本配置文件。
对于主服务器配置文件
$ 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
Node configuration files
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 中的所有操作。我们可以使用以下命令来管理节点。
For listing a node
$ 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 中有不同类型的身份验证级别,可以与主配置文件一起配置。
- Allow all
- Deny all
- HTPasswd
- LDAP
- Basic authentication
- Request header
在定义主配置时,我们可以定义识别策略,其中我们可以定义我们希望使用的策略类型。
Allow All
Allow All
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Deny All
这将拒绝访问所有用户名和密码。
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
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 代理
在大多数生产环境中,直接访问互联网受到限制。它们要么不暴露在互联网上,要么通过 HTTP 或 HTTPS 代理暴露。在 OpenShift 环境中,此代理机器定义设置为环境变量。
这可以通过在位于 /etc/sysconfig 下的主文件和节点文件上添加代理定义来完成。这与我们对任何其他应用程序所做的类似。
主机
/etc/sysconfig/openshift-master
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY=master.vklnld908.int.example.com
节点机
/etc/sysconfig/openshift-node
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY=master.vklnld908.int.example.com
完成后,我们需要重新启动主机和节点机器。
对于 Docker Pull
/etc/sysconfig/docker
HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY = master.vklnld1446.int.example.com
为了让 pod 在代理环境中运行,可以使用 −
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
OC 环境命令可用于更新现有环境。
OpenShift Storage with NFS
在 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 命令创建持久卷。
$ 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 <file name> 创建用户。
$ 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 主节点,它控制所有节点并将容器部署到所有节点。Kubernetes 的主要功能是使用不同类型的配置文件控制 OpenShift 集群和部署流程。与 Kubernetes 一样,我们使用 kubctl 的方式与使用 OC 命令行实用程序在集群节点上构建和部署容器的方式相同。
以下是用于在集群中创建不同类型对象的不同类型的配置文件。
- Images
- POD
- 服务
- 复制控制器
- 副本集
- 部署
Images
Kubernetes (Docker) Images 是容器化基础设施的关键构建块。截至目前,Kubernetes 仅支持 Docker Images。Pod 中的每个容器都有其 Docker Images 在里面运行。
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
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 名称,通过该 IP 地址和 DNS 名称可以访问 pod。使用服务,可以非常轻松地管理负载平衡配置。它可以帮助 POD 轻松扩展。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999
复制控制器
复制控制器是 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,管理员可以使用、修改和扩展这些 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 中,容器的安全性基于容器平台的安全性以及容器在哪里运行的概念。当我们谈论容器安全性以及需要注意的事项时,有多种因素需要考虑。
镜像来源 − 已建立安全标签系统,可以准确且无可辩驳地识别生产环境中运行的容器来自何处。
安全扫描 − 镜像扫描程序会自动检查所有镜像是否存在已知漏洞。
审计 − 定期审核生产环境,以确保所有容器都基于最新的容器,并且主机和容器都经过安全配置。
隔离和最小特权 − 容器以有效运行所需的最少资源和特权运行。它们不能过度干扰主机或其他容器。
运行时威胁检测 −此功能可在运行时检测针对容器化应用程序的活动威胁并自动做出响应。
访问控制 − Linux 安全模块(例如 AppArmor 或 SELinux)用于强制执行访问控制。
有几种关键方法可以实现容器安全。
- 通过 oAuth 控制访问
- 通过自助服务 Web 控制台
- 通过平台证书
通过 OAuth 控制访问
在此方法中,对 API 控制访问的身份验证通过 OAuth 服务器获得安全令牌进行身份验证,该令牌内置于 OpenShift 主机中。作为管理员,您可以修改 OAuth 服务器配置的配置。
有关 OAuth 服务器配置的更多详细信息,请参阅本教程的第 5 章。
通过自助服务 Web 控制台
此 Web 控制台安全功能内置于 OpenShift Web 控制台中。此控制台可确保所有一起工作的团队在未经身份验证的情况下无法访问其他环境。OpenShift 中的多 telnet 主控具有以下安全功能 −
- TCL layer is enabled
- Uses x.509 certificate for authentication
- Secures the etcd configuration on the master machine
通过平台证书
在此方法中,每个主机的证书在安装期间通过 Ansible 配置。由于它通过 Rest API 使用 HTTPS 通信协议,因此我们需要与不同组件和对象建立 TCL 安全连接。这些是预定义的证书,但是,甚至可以在主集群上安装自定义证书以供访问。在主服务器的初始设置期间,可以使用 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-networkisolate-projects <项目名称 1> <项目名称 2>
这意味着上面定义的项目无法与集群中的其他项目通信。
卷安全
卷安全显然意味着保护 OpenShift 集群中项目的 PV 和 PVC。主要有四个部分来控制对 OpenShift 中卷的访问。
- Supplemental Groups
- fsGroup
- runAsUser
- seLinuxOptions
补充组 − 补充组是常规 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)
UID 454265 和组 2325 可以访问 /opt/nfs/ 导出。
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
fsGroup 代表文件系统组,用于添加容器补充组。补充组 ID 用于共享存储,fsGroup 用于块存储。
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325
runAsUser
runAsUser 使用用户 ID 进行通信。这用于在 pod 定义中定义容器映像。如果需要,可以在所有容器中使用单个 ID 用户。
在运行容器时,定义的 ID 与导出上的所有者 ID 匹配。如果指定的 ID 在外部定义,则它将成为 pod 中所有容器的全局 ID。如果它与特定 pod 一起定义,则它将成为单个容器的特定 ID。
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265

