使用rancher知足程序猿刚需

经过将近1个季度的努力，基本上完成了内网开发、测试以及生产环境（借助公有云容器引擎服务）关键服务容器化工做。 在这个过程当中，原本是把已经验证过的技术和方案进行落地，只是执行上的问题。可是研发大爷在使用过程当中又提出了许多新的需求，见招拆招以后，发现仍是有些许收获，所以整理成文，本文介绍rancher server的应用。

1、什么是rancher？

Rancher是一个开源的企业级容器管理平台，经过使用rancher，能够快速的构建出kubernetes环境并对其进行可视化管理。 Rancher由如下四个部分组成：
一、基础设施编排
Rancher可使用任何公有云或者私有云的Linux主机资源。对计算资源进行整合和统一调度使用

二、容器编排与调度
Rancher包含了当前所有主流的编排调度引擎，同一个用户能够建立Swarm或者Kubernetes集群。而且可使用原生的Swarm或者Kubernetes工具管理集群。

三、应用商店
Rancher的用户能够在应用商店里一键部署由多个容器组成的应用，例如容器的日志集中收集应用套件。

四、企业级权限管理
Rancher支持灵活的插件式的用户认证。支持Active Directory，LDAP， Github等 认证方式。 Rancher支持在环境级别的基于角色的访问控制 (RBAC)，能够经过角色来配置某个用户或者用户组对开发环境或者生产环境的访问权限。

更多信息请移步官网：https://rancher.com/

2、为何要用rancher？

每一个人选择用rancher的缘由可能各不同，这里列出rancher能解决的一些实际问题。

一、下降kubernetes集群的部署门槛
咱们一般使用kubeadm或者二进制方式部署kubernetes集群，若是你想拥有一个kubernetes学习环境，经过使用rancher，只须要按照向导在主机上运行指定的命令，而后等待片刻，就能够获得一个kubernetes环境，大大下降了集群的入门门槛。

二、统一管理各个环境的kubernetes集群
当有开发环境、测试环境、正式环境甚至更多的kubernetes集群的时候，如何集中管理这些集群资源是个问题。rancher提供了很好的解决方案，支持各大公有云的云容器和自建kubernetes的纳管工做。
简单来讲，kubernetes实现了各个主机上docker资源的统一管理，rancher在kubernetes之上，实现了对kubernetes的集中管理。

三、替换kubernetes原生的dashboard
原生的dashboard虽然能够经过rbac来控制用户的访问权限，但在实际的配置中仍是太繁琐了，尤为是用户数多，且每一个用户的权限又要求设置的不同的时候。Rancher经过项目和namespace挂钩，对用户受权各个项目的权限来有效简化了配置。

其次原生的dashboard的shell web窗口是不支持黏贴的，这个在内网开发和测试环境被无数的吐槽。Rancher提供了完美的解决方案。

3、使用rancher纳管k8s集群

Rancher server自己就是一个docker 容器，能够运行在kubernetes集群外部。固然若是你有需求的话，也能够部署在集群内。

# yum -y install docker
# docker run -d -p 80:80 -p 443:443  --name rancher-server \
-v /root/star_59iedu_com.pem:/etc/rancher/ssl/cert.pem \
-v /root/star_59iedu_com.key:/etc/rancher/ssl/key.pem \
-v /var/lib/rancher:/var/lib/rancher \
--restart=unless-stopped  rancher/rancher

设置初始密码和访问url地址


添加集群，选择导入方式纳管已存在的k8s集群

在k8s master节点上建立对应的资源，完成纳管。

这里常常遇到的问题是DNS解析问题，建议在dns后台将对应的记录添加好，避免出现纳管失败的状况。

4、rancher使用

纳管完成后能够看到k8s集群的资源状况

建立全局用户

经过建立project和namespace挂钩

点击集群中的“成员”设置全局用户对全部项目的权限，相似组的概念

点击项目“编辑”设置全局用户对项目的权限

终端使用
点击“集群”，能够运行kubectl工具

经过点击项目的工做负载“执行命令行”，能够运行一个shell终端，终端支持黏贴。

后记：

来自程序猿的若干需求：
一、我使用rancher的初衷是为了解决shell终端黏贴的问题，在内网开发和测试环境，码农们出于固定思惟，喜欢登录到容器内部瞧瞧看看，美其名曰debug。

二、适配完终端黏贴的问题以后，码农提出了新的需求，他们在终端里面捣鼓半天，须要把结果文件下载到本地，而后但愿经过sz命令下载下来，或者经过rz命令能上传一些class文件进去编辑，这个是任何web终端工具都解决不了的问题，由于lrzsz不能适配web终端。解决方案是把文件保留到PVC里面，经过共享存储来解决这种无聊的需求。

三、紧接着，无聊的程序猿又要求能在pod里面远程debug，仍是固定思惟。原来tomcat非容器编排部署的是/home/tomcat/bin/catalina.sh jpda start 方式启动，默认会启动一个8000的端口，程序猿们就能够在IDE工具上进行断点debug。目前咱们开发、测试和生产环境用的jdk、tomcat等基础镜像是同一个，程序猿们又不想修改maven上相关的配置，从运维上看，也不想维护多个基础镜像，那么如何解决这个问题呢？同一个基础镜像，相同的代码包，如何适配多个环境呢？且看下回分解。