Cicd

GitOps 最初由 Weaveworks (weave cni的组织) 在 2017 年的博客中提出 [1]，使用 “Git” 作为 CI/CD 的 “单一事实来源”，将代码的更改集成到每个项目的存储库中，并使用拉取请求来管理 infra 和部署。 在理解上就可以理解为 “是一种基于 git 的操作框架” Argo CD 是一种 kubernetes 之上的 “声明式” (declarative) 的 gitops CD， 在本文作为了解如何在 Kubernetes 集群中安装和配置 Argo CD。 前提准备 想要安装 Argo CD 首先环境需要具备如下： 已经安装好 kubectl 命令行工具 拥有 kubeconfig 文件 一个可供测试的 Kubernetes 集群，如：kind, minikube, kubeadm, binary 等任意的集群 步骤1 - 选择适配 kubernetes 版本的 Argo 根据官方的解释， Argo CD 在任何给定时刻所支持的版本，这些版本是 N 和 N - 1 次要版本的最新修补版本 (x.x.new)。这些 Argo CD 版本与 Kubernetes 项目官方支持的 Kubernetes 版本相一致，通常是 Kubernetes 的最近发布的 3 个版本。...

Argo组件 API Server Repository Server Application Controller API Server：一个 gRPC/REST 服务器，提供了 “Web UI”、“CLI” 和 “CI/CD” 使用的 API 应用管理和状态报告 调用应用操作（例如同步、回滚、用户定义的操作） 存储库和 Cluster credential 管理（作为 kubernetes secret 存储） 为外部提供身份认证和代理授权功能 RBAC 试试 Git webhook 事件的 listener/forwarder Repository Server：内部服务，用于维护 git 中的应用清单 (manifests) 的本地缓存。负责接收生成和返回 kubernetes 清单 仓库URL revision (commit, tag, branch) APP PATH 模板特定的参数 Application Controller：Kubernetes controller，主要做的工作是持续监控运行的 Application，并于当前实时状态和目标所需状态进行对比（与 Kubernetes Controller 功能是相同的），并且不仅仅是 KC 还会和存储库中指定目标状态进行比较，检测到 OutOfSync 状态将进行纠正。 Argo 架构 Argo CD 时最常见的三种架构：单实例方案, 集群级方案，以及折衷方案 (compromise between the two)。...

Prerequisites 具有一个 Kubernetes 集群 以部署 Spinnaker 可运行 Docker 的环境 (1 vCPU, 3.75 GB) 或者是 Ubuntu，用以安装 Halyard (用于 spinnaker 的服务) 对象存储 (MinIO)，用于持久化 Spinnaker 的数据 对象存储的 Bucket 的访问账号 安装执行步骤 安装 Halyard 可以直接使用 Docker 方式安装，这个没什么必要性，就是管理工具而已，参考附录1 [1] 首先创建映射目录 bash 1 2 mkdir ~/.hal -pv mkdir ~/.kubeconfig -pv 然后执行 docker run 运行容器 bash 1 2 3 4 5 6 7 docker run -d -p 8084:8084 -p 9000:9000 \ --name halyard --rm \ -v ~/.hal:/home/spinnaker/.hal \ -v ~/....

pipline demo https://jenkins.io/zh/doc/book/pipeline/syntax/ git 插件 https://jenkins.io/doc/pipeline/steps/git/ pipline pipeline{ agent any stages{ stage("build"){ steps{ echo "11111" } } } } pipeline总体介绍 基本结构 以下每一个部分都是必须的，少一个Jenkins都会报错 pipline pipeline{ agent any stages{ stage("build"){ steps{ echo "hellp" } } } } pipeline 代表整个流水线，包含整条流水线的逻辑 stage 阶段，代表流水线的阶段，每个阶段都必须有名称。 stages 流水线中多个stage的容器，stages部分至少包含一个stage. steps 代表stage中的一个活多个具体步骤的容器，steps部分至少包含一个步骤 agent 制定流水线的执行位置，流水线中每个阶段都必须在某个地方执行（master节点/slave节点/物理机/虚拟机/docker容器），agent部分指定具体在哪里执行。agent { label '***-slave'} 可选步骤 post 包含的是在整个pipeline或stage完成后的附件条件 always 论Pipeline运行的完成状态如何都会执行这段代码 changes 只有当前Pipeline运行的状态与先前完成的Pipeline的状态不同时，才能触发运行。 failure 当前状态为失败时执行 success 当前完成状态为成功时执行 demo 使用${test}，可以引入自定义变量 pipeline post { always { script { allure includeProperties: false, jdk: '',report: 'jenkins-allure-report', results: [[path: 'allure-results']] } } failure { script { if (gitpuller == 'noerr') { mail to: "${email_list}", subject: "[jenkins Build Notification] ${JOB_NAME} - Build # ${BUILD_NUMBER} 构建失败", body: "'${env....

需要安装的插件 Role-Based Strategy（可以对构建的项目进行授权管理，让不同的用户管理不同的项目，将测试和生产环境分开） 选择授权策略 当Role-based Authorization Strategy 这个插件安装好之后，授权策略会多出一个Role-Based Strategy 选项，选择此项 添加配置权限 系统设置 » Manage and Assign Roles Manage Roles 设置全局角色（全局角色可以对jenkins系统进行设置与项目的操作） admin:对整个jenkins都可以进行操作 root:可以对所有的job进行管理 other:只有读的权限 other必须有，否则给用户分配角色时分配没有全局role会导致分配失效 Assign Roles为用户指派角色 项目角色是根据正则匹配的，