rancher的角色权限分配实践
rancher分为3种角色, 各自适用范围也不同 全局 集群 项目 项目下又包括了多个namespace 先使用管理员登陆创建1个可以管理全局的账户和角色的用户(全局管理员账户) 注: 此用户仅用来管理用户和角色, admin权限太大, 之后不再使用它进行登陆用户名: UserManager拥有角色:Manage RolesManage Users 退出管理员, 然后使用全局管理员账户创建一个集群管理员账户(集群管理员账户)全局权限: Standard User 用户名: ClusterManager 用ClusterManager身份登陆并进行创建集群.略 创建集群或项目时，Rancher 会自动将创建者分配为所有者。分配了所有者角色的用户可以在集群或项目中给其他用户分配角色。 然后使用UserManager为各集群(一个ClusterManager账户下可以创建多个集群, 例如release/production)创建用户 项目管理员ProjectsAdmin 全局权限: Standard User 创建和管理项目, 查看监控等,...
docker共享宿主机git私钥
Dockerfile123456789...# 共享宿主机git私钥RUN yum install git -y && \ mkdir -p /root/.ssh/ && \ echo "${SSH_KEY}" > /root/.ssh/id_rsa && \ chmod 600 /root/.ssh/id_rsa && \ touch /root/.ssh/known_hosts && \ ssh-keyscan <gitlab_id>/github.com/gitee.com >> /root/.ssh/known_hosts... 执行(~/.ssh/git/id_rsa是宿主机git私钥所在位置)1docker build -t <xxx> --build-arg SSH_KEY="$(cat ~/.ssh/git/id_rsa) .
rancher的安装
官网的话：Rancher 是为使用容器的公司打造的容器管理平台。 安装rancherdocker单节点安装 如果容器内的80端口映射到宿主机的 8xxx，那么容器内的443端口要映射到宿主机的 8443。如果容器内的80端口映射到宿主机的 9xxx，那么容器内的443端口要映射到宿主机的 9443。 123456##############使用存储卷###############docker run -d --privileged --name rancher-server \--restart=unless-stopped \-p 8080:80 -p 8443:443 \-v /opt/rancher:/var/lib/rancher \rancher/rancher:v2.6.3 基于helm安装rancher 如果能使用非自建证书, 那将会省下你绝大部分时间去折腾, 相信我!!! ps: 对应版本这块截至2022年2月28日,官方版本还是存在问题的rancher2.6.3 ,v1.21.7+k3s1别用了 现在测试v2.5.12 ,...
helm命令
查看所有repo1helm repo list 删除repo1helm repo remove stable 添加repo1helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts 更新1helm repo update 下载指定版本Rancher 版本 tgz 压缩包到本地1helm fetch rancher-stable/rancher --version=v2.5.8 部署升级,把读取的部署参数使用 --set <key>=<value> 的方式添加到命令中1234helm upgrade rancher rancher-stable/rancher \--namespace cattle-system \--set ingress.tls.source=secret \--set hostname=<domain_name> helm命令大全 - 链接
helm的安装
下载helm3.81wget https://get.helm.sh/helm-v3.8.0-linux-amd64.tar.gz 解压1tar -zxvf helm-v3.8.0-linux-amd64.tar.gz 赋权1mv linux-amd64/helm /usr/local/bin/helm && chmod +x /usr/local/bin/helm
加速Docker多阶段构建
多阶段构建虽然能够减小镜像体积，但是构建的速度慢了许多。原因在于：一是相比于原先的单阶段构建，多了一些构建步骤；二是缓存失效，多阶段编译之后只保留最终镜像的缓存，中间镜像的缓存丢失。其中缓存失效的问题在CI环境中尤为显著。 加快多阶段构建的措施有两项：并行构建和保留缓存并行构建 从Docker 18.09开始引入了并行构建，启用方法有两种： 临时启用：设置环境变量DOCKER_BUILDKIT=1； 原构建命令: docker build -f Dockerfile -t test_name . 增加DOCKER_BUILDKIT=1后的命令: DOCKER_BUILDKIT=1 docker build -f Dockerfile -t test_name . 默认启用：在/etc/docker/daemon.json中设置{ "features": { "buidkit": true...
记录docker构建优化
记录一次node项目优化方案优化前: 以ubuntu发行版为基础镜像 不带小版本号 每次构建都从头构建(这里也推荐将package*json先copy过来进行install再copy . .,如果文件没变化,那就使用缓存,不重新构建) 优化后： 建立runtime基础镜像(包含提前安装好的基础依赖和环境, 包括node_modules),并使用alpine为基础镜像发行版 使用nexus管理项目包(docker/npm/maven) 指定具体版本号(只有 major version，没有指定 minor version、patch version。当该基础镜像 minor 或 patch 版本更新后，如果本地的镜像缓存也被清除了，那么打包就会使用新版本的基础镜像) 构建 Docker 镜像的时候，会缓存 Dockerfile 中尚未更改的所有步骤。所以，如果新构建时更改任何指令，将后的指令步骤将会重新来不再使用缓存。举例来说，就是指令 3 发生了变更，其后的 4-n 就会重跑并重新生成缓存。因此，编写 Dockerfile...
加快docker构建java项目速度
前提 Python、Node.js、Go项目使用docker构建镜像的时候，在有 Docker cache 的情况下，连续构建镜像的速度是可以很快的。 一般的优化方式是先安装依赖模块，然后再编译打包代码库。这样安装依赖的 image layer 可以被 Docker 缓存，下次再构建就不用安装依赖。 但目前主流的java打包(这里不说像GraalVM等技术)方式都是将源码和依赖包打在一起, 这导致无法充分利用缓存层加快镜像的构建速度 思路 按照node项目打包思路, 先copy package*文件进行构建, 再copy源码 这里以springboot项目举例 先弄一份初始化springboot start工程放在所需项目里 然后需要写两份dockerfile文件 第一份用来copy springboot start工程以及pom文件 然后执行maven命令打包, 这里我们不需要源码正确与否, 因为我们已经将pom内的jar包打到了本地 第二份dockerfile以第一份镜像为基准, 将基础镜像的springboot...
Docker-compose网络
默认网络 默认情况下，compose中的多个服务会加入一个名为default的网络。这些服务在default网络中是互通的。该default网络的全称是以compose文件所在文件夹名字做为前缀。比如文件夹为hello_world的compose。其一组服务对应的网络名为：hello_world_default。 这组service在该网络中，以compose文件中的第二组端口通信。 12345678910version: "3"services: web: build: . ports: - "8000:8000" db: image: postgres ports: - "8001:5432" 比如上述配置中，在hello_world_default网络中，web服务使用8000端口和db服务的5432端口通信。第一组端口8000和8001是宿主机访问web和db服务的端口。 使用已存在的网络1234docker network create...
docker-compose中的特殊符号问题
$美元符号 docker-compose和$$语法均受支持。 不支持扩展的外壳样式功能，例如${VARIABLE-default}和${VARIABLE/foo/bar}。 当配置需要美元符号时，可以使用$$（双美元符号）。 这也可以防止Compose插值。 所以写作: $${Time.now}，其计算结果为${Time.now}
公告