clay commit : ci/cd相关软件安装
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
70a34e1841
commit
6594effa84
|
|
@ -20,7 +20,7 @@ module.exports = {
|
|||
// {text: "简体中文", link: "/language/chinese"}
|
||||
// ]
|
||||
// },
|
||||
{text: "博客", link: "https://blog.isww.cn/"}
|
||||
{text: "博客", link: "https://blog.odliken.cn/"}
|
||||
],
|
||||
/**
|
||||
* 设置侧边栏最大深度
|
||||
|
|
@ -52,6 +52,17 @@ module.exports = {
|
|||
'/wiki/back-build/'
|
||||
] // 根据自己的需求来订,对应自己在docs下的文件夹名,默认首页是README.md
|
||||
},
|
||||
{
|
||||
title: 'CI/CD',
|
||||
collapsable: false,
|
||||
children: [
|
||||
'/ci-cd/',
|
||||
'/ci-cd/gitea/',
|
||||
'/ci-cd/drone/',
|
||||
'/ci-cd/harbor/',
|
||||
'/ci-cd/rancher/',
|
||||
] // 根据自己的需求来订,对应自己在docs下的文件夹名,默认首页是README.md
|
||||
},
|
||||
]
|
||||
}
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
# CI/CD
|
||||
CI/CD 具有不同的含义, "CI"始终指持续集成,它属于开发人员的自动化流程。"CD"指的是持续交付和/或持续部署,这些相关概念有时会交叉使用。在现在的devops模式下,可以使用ci/cd持续集成对项目进行部署,通过,ci/cd中的一些环境变量则可以区分出对应的环境,以便于软件开发流程的控制。
|
||||
|
||||
## CI 持续集成(Continuous Integration)
|
||||
现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是,如果企业安排在一天内将所有分支源代码合并在一起(称为"合并日"),最终可能造成工作繁琐、耗时,而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时,有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境(IDE),而不是让团队就一个基于云的 IDE 达成一致,那么就会让问题更加雪上加霜。
|
||||
|
||||
持续集成(CI)可以帮助开发人员更加频繁地(有时甚至每天)将代码更改合并到共享分支或"主干"中。一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行不同级别的自动化测试(通常是单元测试和集成测试)来验证这些更改,确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突,CI 可以更加轻松地快速修复这些错误。
|
||||
|
||||
> 现有的CI工具则有
|
||||
> - gitee (码云)
|
||||
> - GitHub
|
||||
> - gitlab (企业内部仓库)
|
||||
> - gitea (轻量化代码仓库)
|
||||
|
||||
## CD 持续部署(Continuous Deployment)
|
||||
对于一个成熟的 CI/CD 管道来说,最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸,持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控,因此持续部署在很大程度上都得依赖精心设计的测试自动化。
|
||||
|
||||
实际上,持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效(假设它通过了自动化测试)。这更加便于持续接收和整合用户反馈。总而言之,所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险,因此更便于以小件的方式(而非一次性)发布对应用的更改。不过,由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段,因此前期投资还是会很大。
|
||||
|
||||
> 现有的CD工具
|
||||
> - jekenis (主流)
|
||||
> - drone (小众轻量化)
|
||||
> - gitlab (自带cd环境,需要配置一台外部的ranner执行构建任务)
|
||||
|
||||
## 集群部署环境k8s
|
||||
Kubernetes是Google 2014年创建管理的,是Google 10多年大规模容器管理技术Borg的开源版本。它是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
|
||||
|
||||
在开发过程中,大多时候开发人员或运维人员并不会使用Kubernetes client 命令行工具,更多的是使用Kubernetes的可视化管理界面。
|
||||
> - kuboard
|
||||
> - Lens
|
||||
> - KubeSphere
|
||||
> - Wayne
|
||||
> - Kubernetes Dashboard
|
||||
> - Rancher
|
||||
|
||||
Kubernetes在应对分布式,集群管理的情况下可谓是的心应手。
|
||||
|
||||
|
||||
## 完整的CI/CD组合
|
||||
完整的ci/cd组合,即ci工具+cd工具联通,实现持续集成与持续部署的功能
|
||||
- gitee + jekenis + k8s
|
||||
- gitlab + jekenis + k8s
|
||||
- gitea + jekenis + k8s
|
||||
- gitea + drone + k8s
|
||||
|
||||
## 系统ci/cd
|
||||
本系统由于资源紧张则选用轻量化的组合,gitea+drone+k8s(rancher)
|
||||
下面会介绍每个组件的相关安装以及如何运用于本系统。
|
||||
另外,如需要参考ci/cd运用于其他的单体项目则可以参考
|
||||
|
||||
[Gitea+Drone+Rancher CI/CD持续集成解决方案](https://blog.odliken.cn/2022/08/07/giteadronerancher-ci-cd%e6%8c%81%e7%bb%ad%e9%9b%86%e6%88%90%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
# Drone
|
||||
## 关于Drone
|
||||
Dron是一个现代化的持续集成平台,它使用强大的云原生pipeline引擎自动化构建、测试和发布工作流。Drone 与多个源代码管理系统无缝集成,包括 GitHub、GitHubEnterprise、Bitbucket、GitLab和Gitea;**它的每个构建都在一个隔离的 Docker 容器中运行**;另外它也支持插件,可以使用你熟知的语言轻松的扩展它们。
|
||||
## 安装
|
||||
### 依赖安装
|
||||
需要安装docker和docker-compose,参照上方安装方式即可
|
||||
### 安装Drone
|
||||
安装参考: [Gitea | Drone](https://docs.drone.io/server/provider/gitea/ "Gitea | Drone")
|
||||
|
||||
此处同样采用docker-compose.yml的方式安装
|
||||
```sh
|
||||
version: '3'
|
||||
services:
|
||||
drone-server:
|
||||
restart: always
|
||||
image: drone/drone:2
|
||||
ports:
|
||||
- "映射宿主机端口:80"
|
||||
volumes:
|
||||
- 宿主机挂载目录:/var/lib/drone/
|
||||
- 宿主机挂载目录:/data/
|
||||
environment:
|
||||
- DRONE_GITEA_SERVER=http://gitea服务器地址 # 支持http, https
|
||||
- DRONE_GITEA_CLIENT_ID=gitea生成的OAuth2客户端ID
|
||||
- DRONE_GITEA_CLIENT_SECRET=gitea生成的OAuth2客户端密钥
|
||||
- DRONE_SERVER_HOST=drone服务器地址
|
||||
- DRONE_SERVER_PROTO=http # 支持http, https
|
||||
- DRONE_RPC_SECRET=自定义的Drone与runner通信密钥
|
||||
- DRONE_GIT_ALWAYS_AUTH=true
|
||||
- DRONE_GIT_USERNAME=部署账户的用户名
|
||||
- DRONE_GIT_PASSWORD=部署账户的密码
|
||||
- DRONE_USER_CREATE=username:你的管理员账户名,admin:true # 开启管理员账户
|
||||
drone-runner-docker:
|
||||
restart: always
|
||||
image: drone/drone-runner-docker:1
|
||||
ports:
|
||||
- "3000:3000"
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
environment:
|
||||
- DRONE_RPC_PROTO=http # 支持http, https
|
||||
- DRONE_RPC_HOST=drone-server
|
||||
- DRONE_RPC_SECRET=自定义的Drone与runner通信密钥
|
||||
- DRONE_RUNNER_NAME=drone-runner-docker
|
||||
- DRONE_RUNNER_CAPACITY=2
|
||||
```
|
||||
其中需要将gitea的授权信息填写到上方yml文件中
|
||||
|
||||
Gitea个人中心的应用设置创建Gitea OAuth application
|
||||

|
||||
点击创建后将秘钥妥善保管并替换到上面的docker-compose.yml
|
||||
```
|
||||
- DRONE_GITEA_CLIENT_ID=gitea生成的OAuth2客户端ID
|
||||
- DRONE_GITEA_CLIENT_SECRET=gitea生成的OAuth2客户端密钥
|
||||
- DRONE_GIT_USERNAME=令牌名称
|
||||
- DRONE_GIT_PASSWORD=令牌秘钥
|
||||
```
|
||||
生成Drone与runner通信密钥,并替换上面docker-compose.yml对应的字段
|
||||
```
|
||||
openssl rand -hex 16
|
||||
93b722f581830b9abf11345536b9ecfb
|
||||
```
|
||||
启动drone
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
### 访问drone
|
||||
访问:[http://drone-server-domain](http://server-ip:80/ "http://drone-server-domain")
|
||||
|
||||

|
||||
|
||||
授权
|
||||
|
||||

|
||||
|
||||
填写登录信息
|
||||
|
||||

|
||||
|
||||
登录之后就可以看到刚刚我们gitea中的项目
|
||||
|
||||

|
||||
|
||||
在设置中激活
|
||||
|
||||

|
||||
|
||||
激活保存
|
||||
|
||||

|
||||
|
|
@ -0,0 +1,122 @@
|
|||
## 关于Gitea
|
||||
Gitea 是一个自己托管的Git服务程序。他和GitHub, Bitbucket or Gitlab等比较类似。他是从 [Gogs](http://gogs.io/) 发展而来,Gitea 是一个开源社区驱动的轻量级代码托管解决方案,采用 MIT 许可证。极易安装,运行非常快速,安装和使用体验良好的自建 Git 服务。并且他还支持跨平台,支持 Linux, macOS 和 Windows 以及各种架构,除了x86,amd64,还包括 ARM 和 PowerPC。
|
||||
## 系统要求
|
||||
- 最低的系统硬件要求为一个廉价的树莓派
|
||||
- 如果用于团队项目,建议使用 2 核 CPU 及 1GB 内存
|
||||
## [功能特性](https://docs.gitea.io/zh-cn/#%E5%8A%9F%E8%83%BD%E7%89%B9%E6%80%A7)
|
||||
- 支持活动时间线
|
||||
- 支持 SSH 以及 HTTP/HTTPS 协议
|
||||
- 支持 SMTP、LDAP 和反向代理的用户认证
|
||||
- 支持反向代理子路径
|
||||
- 支持用户、组织和仓库管理系统
|
||||
- 支持添加和删除仓库协作者
|
||||
- 支持仓库和组织级别 Web 钩子(包括 Slack 集成)
|
||||
- 支持仓库 Git 钩子和部署密钥
|
||||
- 支持仓库工单(Issue)、合并请求(Pull Request)以及 Wiki
|
||||
- 支持迁移和镜像仓库以及它的 Wiki
|
||||
- 支持在线编辑仓库文件和 Wiki
|
||||
- 支持自定义源的 Gravatar 和 Federated Avatar
|
||||
- 支持邮件服务
|
||||
- 支持后台管理面板
|
||||
- 支持 MySQL、PostgreSQL、SQLite3、MSSQL 和 TiDB(MySQL) 数据库
|
||||
- 支持多语言本地化(21 种语言)
|
||||
- 支持软件包注册中心(Composer/Conan/Container/Generic/Helm/Maven/NPM/Nuget/PyPI/RubyGems)
|
||||
## 安装
|
||||
### 安装环境依赖
|
||||
gitea 依赖于docker和docker-compose
|
||||
#### 安装docker
|
||||
安装所需的安装包yum-utils:
|
||||
```sh
|
||||
yum install -y yum-utils
|
||||
```
|
||||
添加yum源
|
||||
```sh
|
||||
yum -y update
|
||||
#设置镜像仓库地址
|
||||
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
|
||||
#更新yum软件包索引
|
||||
yum makecache fase
|
||||
```
|
||||
查看可用版本
|
||||
```sh
|
||||
yum list docker-ce --showduplicates | sort -r
|
||||
```
|
||||
安装docker社区版和社区办对应的cli工具已经依赖
|
||||
```sh
|
||||
yum install -y docker-ce docker-ce-cli containerd.io
|
||||
```
|
||||
启动 Docker 并设置开机自启
|
||||
```sh
|
||||
systemctl start docker
|
||||
systemctl enable docker
|
||||
```
|
||||
添加镜像源地址
|
||||
```
|
||||
tee /etc/docker/daemon.json <<-'EOF'
|
||||
{
|
||||
"registry-mirrors": ["https://uyah70su.mirror.aliyuncs.com"]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
重新启动 Docker 服务
|
||||
```
|
||||
systemctl daemon-reload && sudo systemctl restart docker
|
||||
```
|
||||
验证配置是否生效
|
||||
```
|
||||
docker info | grep Mirrors -A1
|
||||
```
|
||||
#### 安装docker-compose
|
||||
安装epel源
|
||||
```
|
||||
yum install -y epel-release
|
||||
```
|
||||
安装docker-compose
|
||||
```
|
||||
yum install -y docker-compose
|
||||
```
|
||||
### 安装gitea
|
||||
安装参考链接:[使用 Docker 安装 - Docs](https://docs.gitea.io/zh-cn/install-with-docker/ "使用 Docker 安装 - Docs")
|
||||
|
||||
最简单的设置只是创建一个卷和一个网络,然后将 `gitea/gitea:latest` 镜像作为服务启动。由于没有可用的数据库,因此可以使用 SQLite3 初始化数据库。创建一个类似 `gitea` 的目录,并将以下内容粘贴到名为 `docker-compose.yml` 的文件中。
|
||||
```
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: gitea/gitea:1.16.7
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- /home/data:/data # /home/data可以替换成你想要的挂载目录
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3030:3000" # 3030可以替换成你想要的端口
|
||||
- "322:22" # 322可以替换成22
|
||||
```
|
||||
在后台启动
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
### 配置gitea
|
||||
访问:[http://server-ip:3030](http://server-ip:3030/ "http://server-ip:3030")
|
||||
|
||||
设置域名访问地址等信息
|
||||
|
||||

|
||||
|
||||
设置管理员账号密码
|
||||
|
||||

|
||||
|
||||
点击安装后,系统安装完毕会自动登录
|
||||
|
|
@ -0,0 +1,165 @@
|
|||
### **Harbor介绍**
|
||||
Harbor 是由 VMware 开源的一款云原生制品仓库,Harbor 的核心功能是存储和管理 Artifact。Harbor 允许用户用命令行工具对容器镜像及其他 Artifact 进行推送和拉取,并提供了图形管理界面帮助用户查看和管理这些 Artifact。在 Harbor 2.0 版本中,除容器镜像外,Harbor 对符合 OCI 规范的 Helm Chart、CNAB、OPA Bundle 等都提供了更多的支持。
|
||||

|
||||
|
||||
### **安装准备**
|
||||
|
||||
1.需要安装docker和docker-compose并运行,docker安装可以参考:
|
||||
[Gitea+Drone+Rancher CI/CD持续集成解决方案](https://blog.odliken.cn/2022/08/07/giteadronerancher-ci-cd%e6%8c%81%e7%bb%ad%e9%9b%86%e6%88%90%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88/)中有详细解决方案
|
||||
|
||||
### **安装**
|
||||
|
||||
下载地址:[https://github.com/goharbor/harbor/releases](https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fgoharbor%2Fharbor%2Freleases)
|
||||
直接选择编译好的包
|
||||

|
||||
|
||||
这里有两个包Harbor offline installer 和 Harbor online installer,两者的区别的是 Harbor offline installer 里就包含的 Harbor 需要使用的镜像文件
|
||||
|
||||
下载成功,并解压
|
||||
```
|
||||
tar zxf harbor-offline-installer-v1.10.1.tgz -C /data/
|
||||
```
|
||||
|
||||
进入解压的目录,并 ls
|
||||
```
|
||||
[root@master ~]# cd /data/harbor/
|
||||
[root@master harbor]# ls
|
||||
common.sh harbor.v1.10.1.tar.gz harbor.yml install.sh LICENSE prepare
|
||||
```
|
||||
|
||||
### **编辑配置文件**
|
||||
编辑 harbor.yml 配置文件,hostname 是 harbor 对外暴露的访问地址,HTTP 服务对外暴露 80 端口。这里可暂时先不配置HTTPS,可将HTTPS 相关内容注释。
|
||||
|
||||

|
||||
|
||||
修改完成后运行`./prepare `命令
|
||||
|
||||
# 部署
|
||||
```
|
||||
./install.sh
|
||||
```
|
||||
|
||||
### **登录页面**
|
||||
浏览器输入 http://192.168.101.105 访问 Harbor 页面,用户名和密码为 harbor.yml 配置文件中默认设置的 admin,Harbor12345。
|
||||
|
||||

|
||||
|
||||
编辑 /etc/docker/daemon.json,设置允许访问的 HTTP 仓库地址。
|
||||
```
|
||||
{
|
||||
"insecure-registries":["11.8.36.21:8888"]
|
||||
}
|
||||
```
|
||||
### **HTTPS 配置(可选)**
|
||||
在生产环境中建议配置 HTTPS,可以使用由受信任的第三方 CA 签名的证书,也可以使用自签名证书。如果想要启用 Content Trust with Notary 来正确签名所有图像,则必须使用 HTTPS。
|
||||
#### **生成 CA 证书**
|
||||
|
||||
本次实验中我们使用自签名证书。生产环境中应使用受信任的第三方 CA 签名的证书。
|
||||
|
||||
##### **生成 CA 证书私钥**
|
||||
```
|
||||
openssl genrsa -out ca.key 4096
|
||||
```
|
||||
##### **生成 CA 证书**
|
||||
|
||||
-subj 表示证书的组织。CN 后面的值改成 harbor 的 IP 地址或者域名。
|
||||
```
|
||||
openssl req -x509 -new -nodes -sha512 -days 3650 \ -subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=11.8.36.21" \ -key ca.key \ -out ca.crt
|
||||
```
|
||||
#### **生成 Server 证书**
|
||||
|
||||
生成 Harbor 使用的证书和私钥。
|
||||
|
||||
##### **生成 Server 私钥**
|
||||
```
|
||||
openssl genrsa -out server.key 4096
|
||||
```
|
||||
##### **生成 Server 证书签名请求(CSR)**
|
||||
|
||||
生成 Harbor 的证书签名请求,使用上面生成的 CA 证书来给 Server 签发证书。
|
||||
|
||||
```
|
||||
openssl req -sha512 -new \
|
||||
-subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=11.8.36.21" \
|
||||
-key server.key \
|
||||
-out server.csr
|
||||
```
|
||||
##### **生成 x509 v3 扩展文件**
|
||||
|
||||
通过 docker 或者 ctr 等工具拉取 HTTPS 的镜像时,要求 HTTPS 的证书包含 SAN 扩展。
|
||||
|
||||
SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 [SSL 证书](https://cloud.tencent.com/product/symantecssl?from=10680),可以扩展此证书支持的域名,使得一个证书可以支持多个不同域名的解析。例如下图中 Google 的这张证书的主题备用名称(SAN)中列了一大串的域名,因此这张证书能够被多个域名所使用。对于 Google 这种域名数量较多的公司来说,使用这种类型的证书能够极大的简化网站证书的管理。
|
||||
使用以下命令生成 x509 v3 扩展文件:
|
||||
```
|
||||
cat > v3.ext <<-EOF
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
|
||||
extendedKeyUsage = serverAuth
|
||||
subjectAltName = IP:11.8.36.21
|
||||
EOF
|
||||
```
|
||||
|
||||
如果是域名访问通过下面方式生成 x509 v3 扩展文件:
|
||||
|
||||
```
|
||||
cat > v3.ext <<-EOF
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
|
||||
extendedKeyUsage = serverAuth
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[alt_names]
|
||||
DNS.1=yourdomain.harbor.com
|
||||
EO
|
||||
```
|
||||
|
||||
##### **使用 CA 证书签发 Server 证书**
|
||||
|
||||
```
|
||||
openssl x509 -req -sha512 -days 3650 \
|
||||
-extfile v3.ext \
|
||||
-CA ca.crt -CAkey ca.key -CAcreateserial \
|
||||
-in server.csr \
|
||||
-out server.crt
|
||||
```
|
||||
#### **为 Harbor 和 Docker 配置证书**
|
||||
|
||||
##### **将 server 证书和密钥复制到 Harbor 主机上的 /data/cert 目录中**
|
||||
##### **转换 server.crt 为 server.cert**
|
||||
|
||||
Docker 守护程序会认为 .crt 文件是 CA 证书,因此需要将 server 证书转换为 server.cert 文件。其实改下后缀就可以了,证书里面的内容是一样的。
|
||||
```
|
||||
openssl x509 -inform PEM -in server.crt -out server.cert
|
||||
```
|
||||
|
||||
##### **重启 Docker Engine**
|
||||
|
||||
```
|
||||
systemctl restart docker
|
||||
```
|
||||
#### **重新部署 Harbor**
|
||||
|
||||
修改 harbor.yml 配置文件,添加 HTTPS 相关配置,指定 HTTPS 的端口号和证书路径:
|
||||
#### **使用 prepare 脚本生成 HTTPS 配置**
|
||||
|
||||
使用 prepare 脚本为反向代理 Nginx 容器生成 HTTPS 配置。
|
||||
|
||||
```
|
||||
./prepare
|
||||
```
|
||||
#### **删除原有 Harbor 容器**
|
||||
|
||||
Harbor 原有的数据文件默认是挂载在宿主机的 /data 目录下,因此删除 Harbor 容器并不会丢失数据。
|
||||
|
||||
```
|
||||
docker-compose down -v
|
||||
```
|
||||
|
||||
#### **重新启动 Harbor**
|
||||
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
# Rancher
|
||||
Rancher 是供采用容器的团队使用的完整软件堆栈。它解决了管理多个Kubernetes集群的运营和安全挑战,并为DevOps团队提供用于运行容器化工作负载的集成工具。简单来说是一个k8s的管理软件!
|
||||
## 安装
|
||||
rancher的latest版本是2.6以上,本次安装v2.4.15
|
||||
```
|
||||
docker run -d --privileged --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher:v2.4.15
|
||||
```
|
||||
访问(注意是https)
|
||||
https://ip-server
|
||||
输入admin 的密码
|
||||
|
||||

|
||||
|
||||
点击下一步,设置rancher的访问url,如果有域名则填写域名
|
||||
|
||||

|
||||
|
||||
进入管理页面
|
||||
|
||||

|
||||
|
||||
## 添加集群
|
||||
点击右上角的添加集群
|
||||
|
||||

|
||||
|
||||
选择自定义
|
||||
|
||||

|
||||
|
||||
配置集训信息
|
||||
|
||||

|
||||
|
||||
点击下一步进入添加节点页面,由于当前集群还没有节点,所以主机选项中的每一个角色都需要选择
|
||||
|
||||

|
||||
|
||||
复制下方的命令到装有docker的主机中运行即可,注意rancher安装的主机和其他节点主机的**ip都必须为静态ip**,不然主机重启后集群就失效了,原因为主机重启后ip变更,k8s不能够通过ip找到对应的节点
|
||||
|
||||

|
||||
|
||||
集群正在添加节点(等待时间很漫长)
|
||||
|
||||

|
||||
|
||||
添加完成
|
||||
|
||||

|
||||

|
||||
|
|
@ -1,50 +0,0 @@
|
|||
### 1001 害死人不偿命的(3n+1)猜想 (15分)
|
||||
|
||||
**卡拉兹(Callatz)猜想**:
|
||||
对任何一个自然数n,如果它是偶数,那么把它砍掉一半;如果它是奇数,那么把(3n+1)砍掉一半。这样一直反复砍下去,最后一定在某一步得到n=1。卡拉兹在1950年的世界数学家大会上公布了这个猜想,传说当时耶鲁大学师生齐动员,拼命想证明这个貌似很傻很天真的命题,结果闹得学生们无心学业,一心只证(3n+1),以至于有人说这是一个阴谋,卡拉兹是在蓄意延缓美国数学界教学与科研的进展……
|
||||
我们今天的题目不是证明卡拉兹猜想,而是对给定的任一不超过1000的正整数n,简单地数一下,需要多少步(砍几下)才能得到n=1?
|
||||
|
||||
**输入格式**:
|
||||
|
||||
每个测试输入包含1个测试用例,即给出自然数n的值。
|
||||
|
||||
**输出格式**:
|
||||
|
||||
输出从 n 计算到1需要的步数。
|
||||
|
||||
**输入样例**:
|
||||
|
||||
~~~ bash
|
||||
3
|
||||
~~~
|
||||
|
||||
**输出样例**:
|
||||
|
||||
~~~ bash
|
||||
5
|
||||
~~~
|
||||
|
||||
|
||||
|
||||
代码实现:
|
||||
|
||||
~~~ java
|
||||
//java代码:
|
||||
import java.util.Scanner;
|
||||
public class Main {
|
||||
public static void main(String[] args) {
|
||||
Scanner scanner =new Scanner(System.in);
|
||||
int N = scanner.nextInt();
|
||||
int steps =0;
|
||||
while (N !=1) {
|
||||
if (N %2 ==0) {
|
||||
N = N /2;
|
||||
} else {
|
||||
N = (3 * N +1) / 2;
|
||||
}
|
||||
steps++;
|
||||
}
|
||||
System.out.println(steps);
|
||||
}
|
||||
}
|
||||
~~~
|
||||
Loading…
Reference in New Issue