Fearchen's Blog

把我的过程记录下来,以免以后忘了


  • 首页

  • 归档

  • 关于

OpenShift-对象定义文件示例

发表于 2018-04-25 | 分类于 OpenShift

Image Stream

模版地址

https://github.com/openshift/origin/blob/release-3.6/examples/image-streams/image-streams-centos7.json

example

{ “kind”: “ImageStream”, “apiVersion”: “v1”, “metadata”: { “name”: “ivops-mariadb”, “creationTimestamp”: null }, “spec”: { “dockerImageRepository”: “dtr.ivops.cn:5443/ivops/mariadb”, “tags”: [ { “name”: “v1.1.x”, “annotations”: null, “from”: { “kind”: “DockerImage”, “name”: “dtr.ivops.cn:5443/ivops/mariadb:v1.1.x” }, “generation”: 1, “importPolicy”: { “insecure”: true } } ] } }

Deployment Config

dc.json

{ “kind”: “DeploymentConfig”, “apiVersion”: “v1”, “metadata”: { “name”: “frontend” }, “spec”: { “strategy”: { “type”: “Recreate”, “resources”: {} }, “triggers”: [ { “type”: “ImageChange”, “imageChangeParams”: { “automatic”: true, “containerNames”: [ “helloworld” ], “from”: {}, “lastTriggeredImage”: “” } } ], “replicas”: 1, “selector”: { “name”: “frontend” }, “template”: { “metadata”: { “creationTimestamp”: null, “labels”: { “name”: “frontend” } }, “spec”: { “containers”: [ { “name”: “helloworld”, “image”: “openshift/openshift/origin-ruby-sample”, “ports”: [ { “containerPort”: 8080, “protocol”: “TCP” } ], “resources”: {}, “terminationMessagePath”: “/dev/termination-log”, “imagePullPolicy”: “IfNotPresent”, “capabilities”: {}, “securityContext”: { “capabilities”: {}, “privileged”: false } } ], “restartPolicy”: “Always”, “dnsPolicy”: “ClusterFirst” } } } }

example

kind: DeploymentConfig apiVersion: v1 metadata: name: tmsweb-deploy spec: replicas: 1 template: metadata: labels: name: tmsweb spec: containers: - image: dtr.ivops.cn:5443/ivops/nodejs6-alpine:v1.1.x imagePullPolicy: Always name: tmsweb-containers ports: - containerPort: 7200 protocol: TCP command: - /usr/bin/node args: - /opt/TenancyWeb/iv_web.js volumeMounts: - mountPath: /opt/TenancyWeb name: tmsweb-mount volumes: - name: tmsweb-mount persistentVolumeClaim: claimName: nfs-pvc-tmsweb
  1. Replication Controller

  2. Routes

route.json

{ “kind”: “Route”, “apiVersion”: “v1”, “metadata”: { “name”: “hello-route” }, “spec”: { “host”: “hello-openshift.v3.rhcloud.com”, “to”: { “kind”: “Service”, “name”: “hello-openshift” } } }

Service

service.json

{ “kind”: “Service”, “apiVersion”: “v1”, “metadata”: { “name”: “hello-openshift” }, “spec”: { “ports”: [ { “protocol”: “TCP”, “port”: 27017, “targetPort”: 8080, “nodePort”: 0 } ], “selector”: { “name”: “hello-openshift” }, “type”: “ClusterIP”, “sessionAffinity”: “None” } }

example

apiVersion: v1 kind: Service metadata: annotations: openshift.io/generated-by: OpenShiftWebConsole labels: app: opsweb-deploy name: opsweb-deploy namespace: iv-ops spec: ports: - name: 7300-tcp port: 7300 protocol: TCP targetPort: 7300 selector: deploymentconfig: opsweb-deploy sessionAffinity: None type: ClusterIP status: loadBalancer: {}

Pod

pod.json

{ “kind”: “Pod”, “apiVersion”: “v1”, “metadata”: { “name”: “hello-pod”, “labels”: { “name”: “hello-openshift” } }, “spec”: { “containers”: [ { “name”: “hello-openshift”, “image”: “openshift/hello-openshift”, “ports”: [ { “containerPort”: 8080, “protocol”: “TCP” } ], “resources”: {}, “terminationMessagePath”: “/dev/termination-log”, “imagePullPolicy”: “IfNotPresent”, “capabilities”: {}, “securityContext”: { “capabilities”: {}, “privileged”: false } } ], “restartPolicy”: “Always”, “dnsPolicy”: “ClusterFirst” } }

Template

模版地址

https://github.com/openshift/origin/tree/release-3.6/examples/quickstarts

Persistent Volume

example

apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv-tmsweb spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /mnt/nfs/tmsweb server: 10.10.31.161 readOnly: false

Persistent VolumeClain

example

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc-tmsweb spec: accessModes: - ReadWriteMany volumeName: nfs-pv-tmsweb resources: requests: storage: 1Gi status: #后加的 accessModes: - ReadWriteMany phase: Bound

OpenShift-持续集成-Jenkins

发表于 2018-04-25 | 分类于 OpenShift

部署Jenkins

使用自带模版部署
./media/image1.png
  1. 准备Dockfile

  2. 生成Builder Image

  3. 上传OpenShift

  4. 根据源代码构建

  5. 生成Template

OpenShift-安全与配额

发表于 2018-04-25 | 分类于 OpenShift

概述:

容器是在linux命名空间和CGroup的基础上,通过SELinux限制容器进程对资源的读取访问或限制容器的容量。容器的安全隔离已经达到了生产可用级别。

容器安全涉及到多个层面:1、容器自身安全;2、容器镜像安全;3、宿主机安全

用户认证:

openshift通过OAuth进行用户认证,OAuth是一个开源的认证和授权框架,OAuth通过用户登录认证以后,返回一个token,用户可以在有效的时间内对系统进行访问。

  • 获取token:oc whoami -t

  • 获取tokenAPI:/oauth/token/request

身份验证 identity provider

openshift提供不同的适配器链接不同的用户信息管理系统:LDAP、Active
Directory、HTPasswd。

openshift默认采用HTPasswd的文件存储用户信息。该文件存储位置在:/etc/origin/master/htpasswd

使用htpasswd命令可以对用户数据库进行增删改查

用户组

  • 查看provider来源:oc get identity

  • 认证系统:authentication

  • 授权系统:authorization

  • 角色访问控制系统:RBAC (role based access control)

权限cluster local

  1. role:角色,一组权限的集合,RBAC系统中,权限–>role–>用户或者组

  2. rule:规则,rule三要素:角色role、资源resource、动作verb。

  3. policy:策略,若干role组成的集合

  4. role binding ,角色与用户或者组的绑定关系

  5. policy binding,若干role组成的集合与用户或者组的绑定关系。

权限操作

  1. 授予用户查看当前项目权限:

oc policy add-role-to-user view user2

  1. 编辑权限:

oc policy add-role-to-user edit user2

删除:oc policy remove-role-from-user edit user2

  1. 查看角色绑定关系:

oc get rolebinding

  1. 查看role的详细信息

oc describe clusterrole admin

  1. 创建组:

oc adm groups new newgroups

  1. 增加用户到组

oc adm groups add-users newgroups user2

  1. 绑定cluster-admin role到新建组

oc adm policy add-cluster-role-to-group cluster-admin newgroups

cluster-admin是系统管理员角色,这个角色可以在系统中对任意对象执行任意操作。

Service Account

  • builder对象:用于S2I

  • default对象:用于运行容器

  • depolyer对象:用于部署容器

每个service account包含secret 和token
./media/image1.png

安全上下文SCC

privileged权限最大,restricted权限最小,普通用户及其创建的项目,都属于restricted组。这个组不允许容器以root用户运行,如该要容器以root权限运行,可以把项目默认的default
service account加入到高权限的组中,

比如加入到anyuid组中,因为anyuid组中的RUNASUSER属性值为:RUNASANY,命令如下:

oc adm policy add-scc-to-user anyuid -z default -n projectname

查看当前用户的scc(Security content constraint)
./media/image2.png

Quota额度配置

额度的控制通过资源额度对象resource quota管理(集群用clusterresourcequota),

resource
quota是基于项目的,以项目为单位对资源进行额度管理,资源的额度对象分为两种:

- 计算资源:compute resource

  1. 计算资源:对CPU、内存资源的额度管理

CPU:

limits.cpu: “40” #limits :容器所能使用的cpu上限值。 limits.memory: 40Gi requests.cpu: “4” #requests:容器运行所需的cpu下限值。 requests.memory: 4Gi

CPU资源的度量最小单位是Millicore,一个计算节点上CPU核数乘以1000,即为该节点CPU资源总量。

例如:4Core=4000m

注意:设置计算资源以后,用户部署容器的时候,必须显示的为每一个容器指定CPU和内存的requests及limits的值,否则容器无法部署。

  1. 对象数量额度:pod、rc、rq、svc、cm、pvc、is、secrets
openshift.io/imagestreams: “400” persistentvolumeclaims: “400” pods: “40” replicationcontrollers: “40” resourcequotas: “40” secrets: “100” services: “100”
  1. cluster resource quota

ClusterResourceQuota允许限制多个project,多个project可以通过annotation 或者
label
进行选择,比如某个用户下的所有project就可以通过:annotations:openshift.io/requester=
进行限制。项目管理员不能创建和修改ClusterResourceQuota,但是可以查看集群限额在当前项目的应用情况,通过以下命令查看:

oc describe AppliedClusterResourceQuota

Limit Range 资源限制

资源限制是更具体的控制每个容器具体使用多少CPU和内存资源。

可以通过两个层面进行定义:

  • 项目级别统一定义每个容器资源是用总量

  • 容器级别单独定义某个容器资源是用总量

OpenShift-S2I构建过程

发表于 2018-04-25 | 分类于 OpenShift

概念介绍

OpenShift的s2i过程是把基础镜像和源代码结合,生成可以运行的application镜像的过程,s2i中的四个脚本详细介绍请参考:https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md。

如果我们有特殊的要求,比如自定义build过程,一般通过重写s2i脚本实现。

编译和部署自己的应用程序

docker生成镜像的过程,当我们创建自己的应用程序镜像的时候,一般来说有两种途径:

  1. 通过Dockerfile来创建:

传统做法是自己编写Dockerfile,使用基础镜像,copy源代码、RUN命令来安装依赖包、shell命令来编译程序、CMD名字指定可运行程序,最后使用
docker build 生成镜像。

  1. 通过docker run和docker commit来创建

还有一种比较小众的做法。是docker run
运行基础镜像,然后使用交互式shell下载源代码、安装依赖包最后使用docker
commit提交容器生成镜像。

理解s2i 历程中的三个镜像

要了解 s2i的过程我们先来理解三个阶段的三个镜像:

  1. 基础镜像 base image:

是我们在docker hub下载的某个语言的官方镜像,比如python
2.7、PHP3.5,这些镜像只包含语言的编译环境,没有做任何加工。

  1. 编译镜像 builder image:

这个镜像是我们在基础镜像的基础上,经过加工以后,可以自动编译代码,并自动完成部署运行的镜像,这个镜像是通过dockerfile生成,继承自上面的base
image。制作过程参考:https://github.com/openshift/source-to-image/

  1. 运行时镜像 runtime image:

这个镜像是通过s2i构建出来的镜像,已经完成了编译工作,直接运行容器就可以启动,这个镜像的生成包括三个要素:1:builder
image; 2:source code; 3:s2i script;这个镜像的生成过程是,运行builder
image,在容器中注入代码,并使用s2i脚本安装依赖包以及编译工作,最后把生成的镜像comit
出一个新的image ,称为 runtime image

OpenShift由builder image到runtime image的过程如下图:

自定义s2i脚本

openshift官方已经提供了各种语言的 builder image,(当然这些builder
image中已经注入了写好的s2i脚本,一般保存在/usr/libexec/s2i目录下),这些脚本通常适用于一些简单的程序部署,如该应用程序的编译和部署过程比较复杂,这些脚本就不能满足要求,这时候我们可以通过自定义s2i脚本来控制build和deploy过程,自定义s2i脚本的编写过程不再赘述,可以参考s2i官方文档,这里说明一下怎么应用自己编写的s2i脚本:

有以下三种方式可以使用自定义s2i脚本来替换默认脚本:

  1. 在代码中包含s2i脚本:在代码仓库的跟目录创建文件夹
    .s2i/bin,把脚本放到这个目录中,当编译时会自动调用这个脚本,值得注意的是,早期版本使用的是
    .sti/bin文件夹,后期版本使用的是.s2i/bin。

  2. 指定网络上的s2i脚本地址:通过设置bc的bc.spec.strategy.sourceStrategy.scripts项目来指定s2i脚本地址,系统会自动去该地址下载脚本。

  3. 如果使用s2i工具创建,可以通过三种方式设置脚本位置

s2i配置文件信息

主要包含四个文件,分别为:

  1. assemble 用于对源码编译以及安装配置的脚本

  2. run 启动应用镜像时执行的脚本

  3. save-artifacts
    用于保存一些编译中复用的内容,这样下次编译可以直接使用这些文件,从而加快编译安装等速度

  4. usage 打印生成镜像的帮助信息

这四个文件都需要用户自行定义,s2i会通过三种方式寻找这些文件,分别为:

  • 源码中.s2i/bin下

  • -scripts-url 参数指定的位置

  • 镜像中label:io.openshift.s2i.scripts-url指定的位置

推荐使用第一种方式,这样方便管理和持续集成,其他两种url都支持以下三种形式:

image://path_to_scripts_dir 在镜像内的绝对路径

file://path_to_scripts_dir 在主机上的绝对或者相对路径

http(s)://path_to_scripts_dir 网络上的文件

OpenShift-Project权限管理

发表于 2018-04-25 | 分类于 OpenShift

环境准备

环境中有两个Project:Project1和Project2。测试需求如下:

普通用户 admin 作为管理员 普通用户 p1admin 作为 project1 管理员 普通用户 p1dev1 作为 project1 的开发人员,有修改权限 普通用户 p1test1 作为 project1 的测试人员,有查看权限
普通用户 p2admin 作为 project2 管理员 普通用户 p2dev1 作为 project2 的开发人员,有修改权限 普通用户 p2test1 作为 project2 的测试人员,有查看权限

超级管理员登陆

oc login -u system:admin

创建各个用户

htpasswd -b /etc/origin/master/htpasswd admin admin htpasswd -b /etc/origin/master/htpasswd p1admin p1admin htpasswd -b /etc/origin/master/htpasswd p2admin p2admin htpasswd -b /etc/origin/master/htpasswd p1dev1 p1dev1 htpasswd -b /etc/origin/master/htpasswd p1test1 p1test1 htpasswd -b /etc/origin/master/htpasswd p2dev1 p2dev1 htpasswd -b /etc/origin/master/htpasswd p2test1 p2test1
默认情况下,创建账户后,使用 oc login -u \<账户> -p \<口令> 登录后,该账户就可以创建 Project,创建 Project 后,就成为这个 Project 的管理员,具有 admin 角色
如果是多 master 结构,需要在每一个 master 节点上创建同样的账户。

为admin账户授权管理员权限

oadm policy add-cluster-role-to-user admin admin
如果授予 admin cluster-admin 角色,则 admin 为超级管理员。
oadm policy add-cluster-role-to-user cluster-admin admin
cluster-admin 和 admin 角色区别在于 cluster-admin 可以查看和修改 clusterPolicy,二者都可以管理集群中所有 Project
常用的授权命令如下:
(1)在当前 Project 下,列出能对指定资源执行指定操作的用户和组 oadm policy who-can verb resource
(2)在当前 Project 下,把指定的角色和用户绑定起来 oadm policy add-role-to-user role username
(3)在当前 Project 下,删除指定用户的指定角色 oadm policy remove-role-from-user role username
(4)在当前 Project 下,在所有的角色中删除指定的用户 oadm policy remove-user username
(5)在当前 Project 下,把指定的角色和组绑定起来 oadm policy add-role-to-group role groupname
(6)在当前 Project 下,删除指定组的指定角色 oadm policy remove-role-from-group role groupname
(7)在当前 Project 下,在所有的角色中删除指定的组 oadm policy remove-group groupname
(8)在集群中所有 Project 下,把指定的角色和用户绑定起来 oadm policy add-cluster-role-to-user role username
(8)在集群中所有 Project 下,把指定的角色和用户绑定起来 oadm policy add-cluster-role-to-user role username
(10)在集群中所有 Project 下,把指定的角色和组绑定起来 oadm policy add-cluster-role-to-group role groupname
(11)在集群中所有 Project 下,删除指定组的指定角色 oadm policy remove-cluster-role-from-group role groupname

创建各个Project

oc new-project project1
oc new-project project2
./media/image1.png

为project1分配权限

oc project project1
oc policy add-role-to-user admin p1admin
oc policy add-role-to-user edit p1dev1
oc policy add-role-to-user view p1test1

为project2分配权限

oc project project2
oc policy add-role-to-user admin p2admin
oc policy add-role-to-user edit p2dev1
oc policy add-role-to-user view p2test1

一共有多少种 Role?

oc get clusterroles
NAME admin basic-user cluster-admin cluster-debugger cluster-reader cluster-status edit hawkular-metrics-admin management-infra-admin registry-admin registry-editor registry-viewer self-access-reviewer self-provisioner storage-admin sudoer system:auth-delegator system:basic-user system:build-controller system:build-strategy-custom system:build-strategy-docker system:build-strategy-jenkinspipeline system:build-strategy-source system:certificate-signing-controller system:controller:attachdetach-controller system:controller:certificate-controller system:controller:cronjob-controller system:controller:daemon-set-controller system:controller:deployment-controller system:controller:disruption-controller system:controller:endpoint-controller system:controller:generic-garbage-collector system:controller:horizontal-pod-autoscaler system:controller:job-controller system:controller:namespace-controller system:controller:node-controller system:controller:persistent-volume-binder system:controller:pod-garbage-collector system:controller:replicaset-controller system:controller:replication-controller system:controller:resourcequota-controller system:controller:route-controller system:controller:service-account-controller system:controller:service-controller system:controller:statefulset-controller system:controller:ttl-controller system:daemonset-controller system:deployer system:deployment-controller system:deploymentconfig-controller system:discovery system:disruption-controller system:endpoint-controller system:garbage-collector-controller system:gc-controller system:heapster system:hpa-controller system:image-auditor system:image-builder system:image-pruner system:image-puller system:image-pusher system:image-signer system:job-controller system:kube-aggregator system:kube-controller-manager system:kube-dns system:kube-scheduler system:master system:namespace-controller system:node system:node-admin system:node-bootstrapper system:node-problem-detector system:node-proxier system:node-reader system:oauth-token-deleter system:openshift:controller:build-config-change-controller system:openshift:controller:build-controller system:openshift:controller:cluster-quota-reconciliation-controller system:openshift:controller:deployer-controller system:openshift:controller:deployment-trigger-controller system:openshift:controller:deploymentconfig-controller system:openshift:controller:horizontal-pod-autoscaler system:openshift:controller:image-import-controller system:openshift:controller:image-trigger-controller system:openshift:controller:origin-namespace-controller system:openshift:controller:pv-recycler-controller system:openshift:controller:resourcequota-controller system:openshift:controller:sdn-controller system:openshift:controller:service-ingress-ip-controller system:openshift:controller:service-serving-cert-controller system:openshift:controller:serviceaccount-controller system:openshift:controller:serviceaccount-pull-secrets-controller system:openshift:controller:template-instance-controller system:openshift:controller:unidling-controller system:openshift:template-service-broker system:openshift:templateservicebroker-client system:persistent-volume-provisioner system:registry system:replicaset-controller system:replication-controller system:router system:sdn-manager system:sdn-reader system:statefulset-controller system:webhook view

查看 view 角色具体能操作哪些资源

oc describe clusterrole view
./media/image2.png

查看 clusterPolicy 拥有的角色

oc get clusterpolicy
./media/image3.png

查看 clusterPolicy default 具体能操作哪些资源

oc describe clusterPolicy default

查看当前/指定 Project 下的角色和用户、组的绑定关系

oc get rolebinding
./media/image4.png

查看集群角色和用户、组的绑定关系

oc get clusterrolebinding
1234…14

Chen Fei

把我的过程记录下来,以免以后忘了

68 日志
15 分类
40 标签
© 2019 Chen Fei
由 Hexo 强力驱动 v3.7.1
|
主题 – NexT.Mist v6.3.0