diff --git a/index.json b/index.json index d581e55efbdb039e77b9854b166b5a68a5d000ec..aad0ea41b7566b789733264ed45678219a2e8a57 100644 --- a/index.json +++ b/index.json @@ -139,6 +139,13 @@ "description": "Jenkins 中文版本升级通知", "content": "部分 Jenkins 中文用户可能已经发现，在最近升级 Jenkins 版本，或下载较新的 Jenkins 后，界面上很多部分显示的是英文。对此，我简单介绍一下原因以及如何安装中文插件。\n各种语言的本地化资源文件都是集中存放在 Jenkins Core 及其插件中，这对于要做本地化贡献的人来说，需要向很多代码仓库中提交 PR。最明显的一个现象就是，这些仓库不一定都会有熟悉中文的维护者，因此导致 PR 无法真实、及时地进行 Review 以及合并发布。基于以上的考虑，我开发了简体中文插件，并从 Jenkins 2.145 版本中把大部分的中文本地化资源文件迁移到了该插件中。而且，最终会对 Jenkins Core 以及流行的插件中所有的中文本地化资源文件进行迁移。\n安装简体中文插件也很简单，只要在 Jenkins 的插件管理界面上，搜索*中文*就能找到该插件。安装并重启后就能看到中文界面。\n更多细节请查看 变更记录 。欢迎对中文本地化工作感兴趣的同学加入我们！\n" }, + { + "uri": "https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/", + "title": "Jenkins 和 Kubernetes -云上的神秘代理", + "tags": ["jenkinsworld", "jenkinsworld2018", "cloud-native", "kubernetes"], + "description": "运行在 K8S 上的 Jenkins 动态节点", + "content": " 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。\n如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。\n我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。\n下面是我在这些年中使用 Jenkins 的各个阶段.\n 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes.\n一旦你在 Jenkins 中把构建节点和 job 都容器化了的话，迁移工作平台将变的十分简单易行。在这里郑重声明一下，在我用这个方法之前我一直没有接触过 Kubernetes，一次也没有。也就是说，在 Google Cloud Platform（GCP）GKE 中创建 Kubernetes 集群，使用 Helm Chart启动 Jenkins master ,并在 Kubernetes 集群中的 Jenkins 代理中运行构建是非常简单的。\n流水线脚本中启动 K8s 中的代理 这篇文章就是为了向大家说明，如何配置 Jenkins 才能使流水线脚本能够在 K8s 集群中启动 Jenkins 节点。首先你要先安装 Kubernetes plugin 这个插件。有意思的是，当我用 Helm chart 来安装我的 Jenkins 时，安装好的 Jenkins 里面已经有了这个插件。还有一个前提，是你启动的 Jenkins 节点要和你的 Jenkins master 在同一个 K8s 集群里。\n一旦在 K8s 中运行了你的 Jenkins master 节点，那只需要再简单地配置几步，就能启动一个小构建啦。\n配置 Jenkins Master 为了保证 Jenkins 能够访问 K8s 集群的资源，首先你需要按照以下步骤创建一些凭据：\n 进入 Jenkins 的 UI 界面，点击左边导航栏里的凭据链接 点击 Stores scoped to Jenkins 列表下 global 中的 Add credentials (将鼠标悬停在链接旁边即可看到箭头) 点击添加凭证 写好 Kubernetes Service Account 将范围设置为全局 点击 OK 按钮 这样之后 Jenkins 就可以使用这个凭据去访问 K8s 的资源啦\n在 Jenkins Master 中配置云 下一步就是在 Jenkins 中设置云的配置\n 进入 Jenkins UI 界面，点击 系统管理 → 系统设置 进入管理界面后查找 『云』，一般在下面，然后点击 『新增一个云』，选择 kubernetes 类型 然后这些是必填的参数 Name: 这个自定义， 默认的是kubernetes Kubernetes URL: https://kubernetes.default- 这个一般是从你的 service account 自动配置的 Kubernetes Namespace: 一般是 default 除非你要在一个特殊的命名空间 ，否则不要动他 Credentials: 选择上一步你创建的凭据 Jenkins URL: http://\u0026lt;your_jenkins_hostname\u0026gt;:8080 Jenkins tunnel: \u0026lt;your_jenkins_hostname\u0026gt;:5555 - 这就是用来和 Jenkins 启动的 agent 进行交互的端口 你看，只需要几个参数就能在 K8s 集群中启动一些节点了，当然你的环境有需要的话，你也可以做一些其他的调整\n现在你已经可以通过定义一些 pod 来让 Jenkins master 访问 K8s 集群了。pod其实是 K8s 中的概念，在一个 pod 中里面会有一个或者多个容器，它们共享网络还有存储，然后我们可以在这个 pod 中执行一些构建工作。每一个 Jenkins 节点都是作为 K8s pod 来启动的。这个 pod 里面经常都会包含一个默认的 JNLP 的容器，还有一些你在 pod 模板中定义的容器。现在有至少两种方法来定义你的 pod template。\n通过 Jenkins UI 配置一个 pod template 还是老地方 Manage Jenkins → Configure Systems 还是老地方 找到之前配置 Jenkins K8s 的地方 点击 Add Pod Template button 选择 Kubernetes Pod Template 输入下面的值 Name:自定义 Namespace: default-除非你想换个你在上一步自定义的命名空间 Labels: 自定义 - 这个将用来匹配你在 jenkinsfile 中的 label 值 Usage: 如果你想让这个 pod 作为默认节点的话，就选择 \u0026ldquo;Use this node as much as possible\u0026rdquo;， 如果选择 \u0026ldquo;Only build jobs with label matching expressions matching this node\u0026rdquo; 的话 那就是只有在 Jenkins 脚本中定义的label匹配的构建才能使用这个节点 The name of the pod template to inherit from: - 这个可以置空. 现在还用不到 Containers: 你想在这个 pod 中启动的容器，在下面会有详细的介绍 EnvVars: 你想在 pod 中注入的环境变量 下面会有接受 Volumes: 你想在 pod 中挂载的任何一种的卷 需要记住，在一个 pod 中会有不止一个容器，它们都是同生共死的。如果你是用 Helm chart 安装 Jenkins 的话，pod 中就会包含 JNLP 这个容器，这个容器也是 Jenkins agent 中必须包含的。然而为了完成更多的服务的构建，你还需要添加一些其他工具链的容器。\n添加容器模板 进入 Jenkins UI 界面，回到上一步创建 pod template 的地方 点击 Add Container 按钮， 选择 Container Template 输入下面的值 Name:自定义 Docker image: 根据你自己的需求来写，比如你在构建一个用 go 写的应用，那你就可以输入 golang:1.11-alpine3.8 Label: 表明要用在流水线脚本中引用此容器模板的标签字符串 Always pull image: - 如果你想让 pod 启动的时候都去拉取镜像 那就选择这个 你可以保留其他参数的默认值，但是你可以看到该插件可以对你的 pod 以及在其中运行的各个容器进行很详细地控制。你可以通过此插件设置在 Kubernetes pod 配置中的任何值。你还可以通过输入原始 YAML 来注入配置数据。你无需因选项过多而分心，选择配置它们中得一小部分就可以获得工作环境啦。\n您可以单击容器模板中的“添加环境变量”按钮，将环境变量注入特定容器，也可以单击模板中的“添加环境变量”按钮，将环境变量注入所有的容器。 以下环境变量会自动注入默认的 JNLP 容器，来保障它能自动连接到 Jenkins 主服务器：\n JENKINS_URL: Jenkins 网页界面网址 JENKINS_JNLP_URL: Jenkins 特定 slave 中 jnlp 的 url JENKINS_SECRET: 身份验证的密钥 JENKINS_NAME: Jenkins 代理的名称 如果单击“添加卷”按钮，您将看到几个用于添加卷的选项,在这里我使用 Host Path Volume 选项将 docker socket 安装在 pod 中。然后，我可以运行安装了 Docker 客户端的容器，并且来构建和推送 Docker 镜像。\n此时，我们为 Kubernetes 集群创建了一个云配置，并定义了一个由一个或多个容器组成的 pod。现在，我们如何使用它来运行 Jenkins 工作？ 很简单，只需要我们在 Jenkins 流水线脚本中通过标签引用 pod 和容器就可以了。 本文中的示例是使用脚本流水线，当然您可以使用声明式流水线语法实现相同的结果：\nnode('test-pod') { stage('Checkout') { checkout scm } stage('Build'){ container('go-agent') { // This is where we build our code. } } } 用 jenkinsfile 来实现相同的功能 通过 UI 配置插件现在看起来是很不错的。但是有一个明显的问题是，配置不能像源代码一样能够进行版本控制和存储。幸运的是，您可以直接在 Jenkinsfile 中创建整个 pod 定义。哈哈，在 Jenkinsfile 中有什么你不能做的???\n可以将 UI 或 YAML 定义中可用的任何配置参数添加到 podTemplate 和 containerTemplate 部分。 在下面的示例中，我已经定义了一个包含两个容器模板的 pod。 pod 标签将会用于节点，表示我们想要启动此 pod 的实例。 直接在节点内定义但没有在容器块中定义的任何步骤，都可以在默认的 JNLP 容器中运行。\n容器块用于表示该容器块内的步骤应在具有给定标签的容器内运行。我已经定义了一个标签为 golang 的容器模板，我将用它来构建 Go 可执行文件，我最终将其打包成 Docker 镜像。在 volumes 中，我已经指出我想要挂载主机的 Docker 套接字，但我仍然需要 Docker 客户端使用 Docker API 与它进行交互。因此，我已经定义了一个标签为 docker 的容器模板，该模板使用安装了 Docker 客户端的镜像。\npodTemplate( name: 'test-pod', label: 'test-pod', containers: [ containerTemplate(name: 'golang', image: 'golang:1.9.4-alpine3.7'), containerTemplate(name: 'docker', image:'trion/jenkins-docker-client'), ], volumes: [ hostPathVolume(mountPath: '/var/run/docker.sock', hostPath: '/var/run/docker.sock', ], { //node = the pod label node('test-pod'){ //container = the container label stage('Build'){ container('golang'){ // This is where we build our code. } } stage('Build Docker Image'){ container(‘docker’){ // This is where we build the Docker image } } } }) 在我的基于 Docker 的流水线脚本中，我构建了 Docker 镜像并将它们推送到了 Docker 仓库，对我来说，能够复制这些配置信息非常重要。完成后，我已准备好使用 gcloud（Google Cloud SDK）构建我的镜像，并将该镜像推送到 Google Container Registry，以便部署到我的 K8s 群集。\n为此，我使用 gcloud 镜像指定了一个容器模板，并将我的 docker 命令更改为 gcloud 命令。 就这么简单！\npodTemplate( name: 'test-pod', label: 'test-pod', containers: [ containerTemplate(name: 'golang', image: 'golang:1.9.4-alpine3.7'), containerTemplate(name: 'gcloud', image:'gcr.io/cloud-builders/gcloud'), ], { //node = the pod label node('test-pod'){ //container = the container label stage('Build'){ container('golang'){ // This is where we build our code. } } stage('Build Docker Image'){ container(‘gcloud’){ //This is where we build and push our Docker image. } } } }) 在 Kubernetes 上运行 Jenkins master、 Jenkins 代理，构建和部署示例应用程序其实只花了我几个小时。但这之后，我花了一个周末的时间才深入了解了平台。如果你学得够快，我相信你在几天内就可以完全掌握并且灵活运用这个平台了。\n" + }, { "uri": "https://jenkins-zh.github.io/wechat/articles/2018-11-14-first-voice/", "title": "Jenkins 微信订阅号", @@ -167,6 +174,13 @@ "description": "", "content": "" }, + { + "uri": "https://jenkins-zh.github.io/tags/kubernetes/", + "title": "Kubernetes", + "tags": [], + "description": "", + "content": "" + }, { "uri": "https://jenkins-zh.github.io/tags/performance/", "title": "Performance", diff --git a/index.xml b/index.xml index 8eea17a0775c900701fd7c942615ecb6af32f393..3bc3f9fdbdc579fccc8f5ce1fc7928e0c5eaada4 100644 --- a/index.xml +++ b/index.xml @@ -133,6 +133,19 @@ JCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或 更多细节请查看 变更记录 。欢迎对中文本地化工作感兴趣的同学加入我们！ + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + Jenkins 微信订阅号 https://jenkins-zh.github.io/wechat/articles/2018-11-14-first-voice/ diff --git a/sitemap.xml b/sitemap.xml index 4f0cdbb17f6bb4467914322467f6741ecb29f88d..dddfab260d915a4169af9682e10cee2d96ce0637 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -96,6 +96,10 @@ https://jenkins-zh.github.io/wechat/articles/2019-01-16-localization-zh-cn-plugin/ + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + + https://jenkins-zh.github.io/wechat/articles/2018-11-14-first-voice/ @@ -114,6 +118,11 @@ 0 + + https://jenkins-zh.github.io/tags/kubernetes/ + 0 + + https://jenkins-zh.github.io/tags/performance/ 0 diff --git a/tags/cloud-native/index.html b/tags/cloud-native/index.html index 62719bc9e1bfd3044b97f0a61cdd2638b1c7c3d6..92334a59c8a5c5bd321b82b98df79381704cc035 100644 --- a/tags/cloud-native/index.html +++ b/tags/cloud-native/index.html @@ -172,6 +172,31 @@ + + + + +
+ +
+ + +

+ Jenkins 和 Kubernetes -云上的神秘代理 +

+ +
+ + 运行在 K8S 上的 Jenkins 动态节点 + + + + 查看更多 » + + +
+ +
diff --git a/tags/cloud-native/index.xml b/tags/cloud-native/index.xml index ba1182b65d9a4b57eb403899c01e9e78271539dc..58a2cd884cc99cb31d2106fded310119ac71dcc7 100644 --- a/tags/cloud-native/index.xml +++ b/tags/cloud-native/index.xml @@ -22,6 +22,19 @@ 正如 Jenkins 本身一样，Custom WAR Packager 开始于一个小的开发工具。在 Jenkins 内运行集成测试很长时间以来都是一个难题。 对此，我们有三个主要的框架： Jenkins Test Harness, Acceptance Test Harness, 和 Plugin Compatibility Tester. 这些框架都需要一个 Jenkins WAR 文件来运行测试。但是假如你想在类似 AWS 一样的自定义环境中进行 Jenkins 测试呢？ 或者，你希望基于 Pluggable Storage 的环境也可以复用 Jenkins 流水线测试，来确保没有回归缺陷？ + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + 从 Jenkins Master 扩展网络连接 https://jenkins-zh.github.io/wechat/articles/2018-12-19-scaling-network-connections/ diff --git a/tags/index.html b/tags/index.html index 3c0be6039abb652cfdfb2c5aaea7ee4144201c13..d5bca5922730014181dfd007b6e9319f2c9365ae 100644 --- a/tags/index.html +++ b/tags/index.html @@ -155,6 +155,12 @@ +

+ + Jenkins 和 Kubernetes -云上的神秘代理 + +

+

从 Jenkins Master 扩展网络连接 @@ -301,6 +307,12 @@

+

+ + Jenkins 和 Kubernetes -云上的神秘代理 + +

+

从 Jenkins Master 扩展网络连接 @@ -329,6 +341,12 @@

+

+ + Jenkins 和 Kubernetes -云上的神秘代理 + +

+

从 Jenkins Master 扩展网络连接 @@ -344,6 +362,22 @@ +
+

+ + kubernetes ↗ + +

+ +

+ + Jenkins 和 Kubernetes -云上的神秘代理 + +

+ +
+ +

diff --git a/tags/index.xml b/tags/index.xml index 3c15db55aabc656a864270cca2c2896340c0cdca..40a4e2bd4485a921b0d4583d1f5b3d9b61026f7c 100644 --- a/tags/index.xml +++ b/tags/index.xml @@ -100,6 +100,15 @@ + + Kubernetes + https://jenkins-zh.github.io/tags/kubernetes/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/tags/kubernetes/ + + + Performance https://jenkins-zh.github.io/tags/performance/ diff --git a/tags/jenkinsworld/index.html b/tags/jenkinsworld/index.html index 32a0f476d3993b0ed5f5bb908fd45d40571d6c77..c242b6e4507bad5612c8bcb39fa172822980a985 100644 --- a/tags/jenkinsworld/index.html +++ b/tags/jenkinsworld/index.html @@ -172,6 +172,31 @@

+ + + + +
+ +
+ + +

+ Jenkins 和 Kubernetes -云上的神秘代理 +

+ +
+ + 运行在 K8S 上的 Jenkins 动态节点 + + + + 查看更多 » + + +
+ +
diff --git a/tags/jenkinsworld/index.xml b/tags/jenkinsworld/index.xml index cf8b79280a4316cbdc1298f520699b26dcdd0538..4c90f264b8f2a733ce367b3aed612782f34e2549 100644 --- a/tags/jenkinsworld/index.xml +++ b/tags/jenkinsworld/index.xml @@ -25,6 +25,19 @@ Jenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥 JCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。 与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。 这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。 + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + 从 Jenkins Master 扩展网络连接 https://jenkins-zh.github.io/wechat/articles/2018-12-19-scaling-network-connections/ diff --git a/tags/jenkinsworld2018/index.html b/tags/jenkinsworld2018/index.html index 59b4dfb6102ccd96b1a615b690cac1522d4a1457..b7b63765407c9b4f79e48a3c7920639a611017ea 100644 --- a/tags/jenkinsworld2018/index.html +++ b/tags/jenkinsworld2018/index.html @@ -172,6 +172,31 @@ + + + + +
+ +
+ + +

+ Jenkins 和 Kubernetes -云上的神秘代理 +

+ +
+ + 运行在 K8S 上的 Jenkins 动态节点 + + + + 查看更多 » + + +
+ +
diff --git a/tags/jenkinsworld2018/index.xml b/tags/jenkinsworld2018/index.xml index 4a8c24f776f51d87f479454bdce005f57bc3baca..4243e98dc26e3aa224c30db12e52605346cd1aa8 100644 --- a/tags/jenkinsworld2018/index.xml +++ b/tags/jenkinsworld2018/index.xml @@ -25,6 +25,19 @@ Jenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥 JCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。 与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。 这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。 + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + 从 Jenkins Master 扩展网络连接 https://jenkins-zh.github.io/wechat/articles/2018-12-19-scaling-network-connections/ diff --git a/tags/kubernetes/index.html b/tags/kubernetes/index.html new file mode 100644 index 0000000000000000000000000000000000000000..c8185344c27eb2dd88d71234c76c24a81a13aec0 --- /dev/null +++ b/tags/kubernetes/index.html @@ -0,0 +1,286 @@ + + + + + + + + + + + + Kubernetes | Jenkins 中文社区 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+ +
+
+ + + +
+ +
+
+

+ Tag: Kubernetes +

+
+ +
+
+ + + +
+ +
+ +
+ +
+ + +

+ Jenkins 和 Kubernetes -云上的神秘代理 +

+ +
+ + 运行在 K8S 上的 Jenkins 动态节点 + + + + 查看更多 » + + +
+ + +
+
+ + +
+
+ +
+ +
+ +
+ +
+ + + + + + + + + + + + + + + + diff --git a/tags/kubernetes/index.xml b/tags/kubernetes/index.xml new file mode 100644 index 0000000000000000000000000000000000000000..068db00f9c4184137525eb6023db5e18782ee59b --- /dev/null +++ b/tags/kubernetes/index.xml @@ -0,0 +1,27 @@ + + + + Kubernetes on Jenkins 中文社区 + https://jenkins-zh.github.io/tags/kubernetes/ + Recent content in Kubernetes on Jenkins 中文社区 + Hugo -- gohugo.io + zh-CN + + + + + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + + + \ No newline at end of file diff --git a/wechat/articles/2018-11-14-first-voice/index.html b/wechat/articles/2018-11-14-first-voice/index.html index 5db1e273fa8c3da98075c485f860c055ccedd14a..afd3226f69a6d6cce79951819bc99e6d1ee7fd8b 100644 --- a/wechat/articles/2018-11-14-first-voice/index.html +++ b/wechat/articles/2018-11-14-first-voice/index.html @@ -171,7 +171,7 @@ - + diff --git a/wechat/articles/2018-12-19-scaling-network-connections/index.html b/wechat/articles/2018-12-19-scaling-network-connections/index.html index e613d1d131ec18b95048415b4a71c512b1364c70..ecd72cc2ccf2dcedb4b45c0515d98266f5751ea4 100644 --- a/wechat/articles/2018-12-19-scaling-network-connections/index.html +++ b/wechat/articles/2018-12-19-scaling-network-connections/index.html @@ -357,6 +357,15 @@ f6 ph3 pv1 br2 dib tc ttu mv3 bg-primary-color white hover-bg-green link +
  • + + Jenkins 和 Kubernetes -云上的神秘代理 + +
    • + + + + diff --git a/wechat/articles/2019-01-09-jenkins-evergreen/index.html b/wechat/articles/2019-01-09-jenkins-evergreen/index.html index a865cd716eac4a263687040f4e52e1fb4914ae3e..498240d7ac0056b56f1bea03d73917e6cf4e8692 100644 --- a/wechat/articles/2019-01-09-jenkins-evergreen/index.html +++ b/wechat/articles/2019-01-09-jenkins-evergreen/index.html @@ -362,6 +362,15 @@ f6 ph3 pv1 br2 dib tc ttu mv3 bg-primary-color white hover-bg-green link +
  • + + Jenkins 和 Kubernetes -云上的神秘代理 + +
    • + + + +
  • 从 Jenkins Master 扩展网络连接 diff --git a/wechat/articles/2019-01-16-localization-zh-cn-plugin/index.html b/wechat/articles/2019-01-16-localization-zh-cn-plugin/index.html index 4d5ebe508e38b9d8139a54244f6e7a57ccbc1535..4334f681caaaee7798da70f0d2efb8542f43682e 100644 --- a/wechat/articles/2019-01-16-localization-zh-cn-plugin/index.html +++ b/wechat/articles/2019-01-16-localization-zh-cn-plugin/index.html @@ -184,7 +184,7 @@ - + diff --git a/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/index.html b/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/index.html new file mode 100644 index 0000000000000000000000000000000000000000..12ca724f7c611c60eca7c582a5e1c10eb2ca8ee2 --- /dev/null +++ b/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/index.html @@ -0,0 +1,683 @@ + + + + + + + + + + + + Jenkins 和 Kubernetes -云上的神秘代理 | Jenkins 中文社区 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + +
    +
    +
    + + +
    + + + + + + + + + +
    + +
    +
    +
    +
    +
    + +

    Jenkins 和 Kubernetes -云上的神秘代理

    +
    + + + + + +
    + + + +

    最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。

    + +

    如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。

    + +

    我的 Jenkins 的进阶之路

    + +

    作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。

    + +

    下面是我在这些年中使用 Jenkins 的各个阶段.

    + +
      +
    1. 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. +(我给这个阶段起了个可爱的名字， Hello Jenkins)
      2. +
    2. 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 +(这个阶段我起的名字是 Monster Agent.)
      3. +
    3. 为每种服务创建不同的 Jenkins EC2 的节点 +(这个阶段我起的名字叫做 Snowflake Agent.)
      4. +
    4. 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host
      5. +
    5. 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD)
      6. +
    6. 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。
      7. +
    7. 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建
      8. +
    8. 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤
      9. +
    + +

    以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes.

    + +

    一旦你在 Jenkins 中把构建节点和 job 都容器化了的话，迁移工作平台将变的十分简单易行。在这里郑重声明一下，在我用这个方法之前我一直没有接触过 Kubernetes，一次也没有。也就是说，在 Google Cloud Platform（GCP）GKE 中创建 Kubernetes 集群，使用 Helm Chart启动 Jenkins master ,并在 Kubernetes 集群中的 Jenkins 代理中运行构建是非常简单的。

    + +

    流水线脚本中启动 K8s 中的代理

    + +

    这篇文章就是为了向大家说明，如何配置 Jenkins 才能使流水线脚本能够在 K8s 集群中启动 Jenkins 节点。首先你要先安装 Kubernetes plugin 这个插件。有意思的是，当我用 Helm chart 来安装我的 Jenkins 时，安装好的 Jenkins 里面已经有了这个插件。还有一个前提，是你启动的 Jenkins 节点要和你的 Jenkins master 在同一个 K8s 集群里。

    + +

    一旦在 K8s 中运行了你的 Jenkins master 节点，那只需要再简单地配置几步，就能启动一个小构建啦。

    + +

    配置 Jenkins Master

    + +

    为了保证 Jenkins 能够访问 K8s 集群的资源，首先你需要按照以下步骤创建一些凭据：

    + +
      +
    1. 进入 Jenkins 的 UI 界面，点击左边导航栏里的凭据链接
      2. +
    2. 点击 Stores scoped to Jenkins 列表下 global 中的 Add credentials (将鼠标悬停在链接旁边即可看到箭头)
      3. +
    3. 点击添加凭证
      4. +
    4. 写好 Kubernetes Service Account
      5. +
    5. 将范围设置为全局
      6. +
    6. 点击 OK 按钮
      7. +
    + +

    这样之后 Jenkins 就可以使用这个凭据去访问 K8s 的资源啦

    + +

    在 Jenkins Master 中配置云

    + +

    下一步就是在 Jenkins 中设置云的配置

    + +
      +
    1. 进入 Jenkins UI 界面，点击 系统管理 → 系统设置
      2. +
    2. 进入管理界面后查找 『云』，一般在下面，然后点击 『新增一个云』，选择 kubernetes 类型
      3. +
    3. 然后这些是必填的参数
      4. +
    4. Name: 这个自定义， 默认的是kubernetes
      5. +
    5. Kubernetes URL: https://kubernetes.default- 这个一般是从你的 service account 自动配置的
      6. +
    6. Kubernetes Namespace: 一般是 default 除非你要在一个特殊的命名空间 ，否则不要动他
      7. +
    7. Credentials: 选择上一步你创建的凭据
      8. +
    8. Jenkins URL: http://<your_jenkins_hostname>:8080
      9. +
    9. Jenkins tunnel: <your_jenkins_hostname>:5555 - 这就是用来和 Jenkins 启动的 agent 进行交互的端口
      10. +
    + +

    Jenkins Evergreen

    + +

    你看，只需要几个参数就能在 K8s 集群中启动一些节点了，当然你的环境有需要的话，你也可以做一些其他的调整

    + +

    现在你已经可以通过定义一些 pod 来让 Jenkins master 访问 K8s 集群了。pod其实是 K8s 中的概念，在一个 pod 中里面会有一个或者多个容器，它们共享网络还有存储，然后我们可以在这个 pod 中执行一些构建工作。每一个 Jenkins 节点都是作为 K8s pod 来启动的。这个 pod 里面经常都会包含一个默认的 JNLP 的容器，还有一些你在 pod 模板中定义的容器。现在有至少两种方法来定义你的 pod template。

    + +

    通过 Jenkins UI 配置一个 pod template

    + +
      +
    1. 还是老地方 Manage Jenkins → Configure Systems
      2. +
    2. 还是老地方 找到之前配置 Jenkins K8s 的地方
      3. +
    3. 点击 Add Pod Template button 选择 Kubernetes Pod Template
      4. +
    4. 输入下面的值
      5. +
    + +
      +
    • Name:自定义
      • +
    • Namespace: default-除非你想换个你在上一步自定义的命名空间
      • +
    • Labels: 自定义 - 这个将用来匹配你在 jenkinsfile 中的 label 值
      • +
    • Usage: 如果你想让这个 pod 作为默认节点的话，就选择 “Use this node as much as possible”， 如果选择 “Only build jobs with label matching expressions matching this node” 的话 那就是只有在 Jenkins 脚本中定义的label匹配的构建才能使用这个节点
      • +
    • The name of the pod template to inherit from: - 这个可以置空. 现在还用不到
      • +
    • Containers: 你想在这个 pod 中启动的容器，在下面会有详细的介绍
      • +
    • EnvVars: 你想在 pod 中注入的环境变量 下面会有接受
      • +
    • Volumes: 你想在 pod 中挂载的任何一种的卷
      • +
    + +

    Jenkins Evergreen

    + +

    需要记住，在一个 pod 中会有不止一个容器，它们都是同生共死的。如果你是用 Helm chart 安装 Jenkins 的话，pod 中就会包含 JNLP 这个容器，这个容器也是 Jenkins agent 中必须包含的。然而为了完成更多的服务的构建，你还需要添加一些其他工具链的容器。

    + +

    添加容器模板

    + +
      +
    1. 进入 Jenkins UI 界面，回到上一步创建 pod template 的地方
      2. +
    2. 点击 Add Container 按钮， 选择 Container Template
      3. +
    3. 输入下面的值
      4. +
    4. Name:自定义
      5. +
    5. Docker image: 根据你自己的需求来写，比如你在构建一个用 go 写的应用，那你就可以输入 golang:1.11-alpine3.8
      6. +
    6. Label: 表明要用在流水线脚本中引用此容器模板的标签字符串
      7. +
    7. Always pull image: - 如果你想让 pod 启动的时候都去拉取镜像 那就选择这个
      8. +
    + +

    Container Template

    + +

    你可以保留其他参数的默认值，但是你可以看到该插件可以对你的 pod 以及在其中运行的各个容器进行很详细地控制。你可以通过此插件设置在 Kubernetes pod 配置中的任何值。你还可以通过输入原始 YAML 来注入配置数据。你无需因选项过多而分心，选择配置它们中得一小部分就可以获得工作环境啦。

    + +

    您可以单击容器模板中的“添加环境变量”按钮，将环境变量注入特定容器，也可以单击模板中的“添加环境变量”按钮，将环境变量注入所有的容器。 +以下环境变量会自动注入默认的 JNLP 容器，来保障它能自动连接到 Jenkins 主服务器：

    + +
      +
    • JENKINS_URL: Jenkins 网页界面网址
      • +
    • JENKINS_JNLP_URL: Jenkins 特定 slave 中 jnlp 的 url
      • +
    • JENKINS_SECRET: 身份验证的密钥
      • +
    • JENKINS_NAME: Jenkins 代理的名称
      • +
    + +

    如果单击“添加卷”按钮，您将看到几个用于添加卷的选项,在这里我使用 Host Path Volume 选项将 docker socket 安装在 pod 中。然后，我可以运行安装了 Docker 客户端的容器，并且来构建和推送 Docker 镜像。

    + +

    此时，我们为 Kubernetes 集群创建了一个云配置，并定义了一个由一个或多个容器组成的 pod。现在，我们如何使用它来运行 Jenkins 工作？ +很简单，只需要我们在 Jenkins 流水线脚本中通过标签引用 pod 和容器就可以了。 +本文中的示例是使用脚本流水线，当然您可以使用声明式流水线语法实现相同的结果：

    + +
    node('test-pod') {
+    stage('Checkout') {
+        checkout scm
+    }
+    stage('Build'){
+        container('go-agent') {
+            // This is where we build our code.
+        }
+    }
+}
+
    + +

    用 jenkinsfile 来实现相同的功能

    + +

    通过 UI 配置插件现在看起来是很不错的。但是有一个明显的问题是，配置不能像源代码一样能够进行版本控制和存储。幸运的是，您可以直接在 Jenkinsfile 中创建整个 pod 定义。哈哈，在 Jenkinsfile 中有什么你不能做的???

    + +

    可以将 UI 或 YAML 定义中可用的任何配置参数添加到 podTemplate 和 containerTemplate 部分。 +在下面的示例中，我已经定义了一个包含两个容器模板的 pod。 +pod 标签将会用于节点，表示我们想要启动此 pod 的实例。 +直接在节点内定义但没有在容器块中定义的任何步骤，都可以在默认的 JNLP 容器中运行。

    + +

    容器块用于表示该容器块内的步骤应在具有给定标签的容器内运行。我已经定义了一个标签为 golang 的容器模板，我将用它来构建 Go 可执行文件，我最终将其打包成 Docker 镜像。在 volumes 中，我已经指出我想要挂载主机的 Docker 套接字，但我仍然需要 Docker 客户端使用 Docker API 与它进行交互。因此，我已经定义了一个标签为 docker 的容器模板，该模板使用安装了 Docker 客户端的镜像。

    + +
    podTemplate(
+    name: 'test-pod',
+    label: 'test-pod',
+    containers: [
+        containerTemplate(name: 'golang', image: 'golang:1.9.4-alpine3.7'),
+        containerTemplate(name: 'docker', image:'trion/jenkins-docker-client'),
+    ],
+    volumes: [
+        hostPathVolume(mountPath: '/var/run/docker.sock',
+        hostPath: '/var/run/docker.sock',
+    ],
+    {
+        //node = the pod label
+        node('test-pod'){
+            //container = the container label
+            stage('Build'){
+                container('golang'){
+                    // This is where we build our code.
+                }
+            }
+            stage('Build Docker Image'){
+                container(‘docker’){
+                    // This is where we build the Docker image
+                }
+            }
+        }
+    })
+
    + +

    在我的基于 Docker 的流水线脚本中，我构建了 Docker 镜像并将它们推送到了 Docker 仓库，对我来说，能够复制这些配置信息非常重要。完成后，我已准备好使用 gcloud（Google Cloud SDK）构建我的镜像，并将该镜像推送到 Google Container Registry，以便部署到我的 K8s 群集。

    + +

    为此，我使用 gcloud 镜像指定了一个容器模板，并将我的 docker 命令更改为 gcloud 命令。 +就这么简单！

    + +
    podTemplate(
+    name: 'test-pod',
+    label: 'test-pod',
+    containers: [
+        containerTemplate(name: 'golang', image: 'golang:1.9.4-alpine3.7'),
+        containerTemplate(name: 'gcloud', image:'gcr.io/cloud-builders/gcloud'),
+    ],
+    {
+        //node = the pod label
+        node('test-pod'){
+            //container = the container label
+            stage('Build'){
+                container('golang'){
+                    // This is where we build our code.
+                }
+            }
+            stage('Build Docker Image'){
+                container(‘gcloud’){
+                    //This is where we build and push our Docker image.
+                }
+            }
+        }
+    })
+
    + +

    在 Kubernetes 上运行 Jenkins master、 Jenkins 代理，构建和部署示例应用程序其实只花了我几个小时。但这之后，我花了一个周末的时间才深入了解了平台。如果你学得够快，我相信你在几天内就可以完全掌握并且灵活运用这个平台了。

    + +
    + + + + + + + + + + + + +
    +
    +
    + + + +
    + +
    +
    + +
    +
    +
    + + + + “Jenkins 和 Kubernetes -云上的神秘代理” + was last updated: January 1, 0001 +
    + + 改善此页 + + + + + + + +
    + +
    + + +
    +
    +
    + +
    + + + + + + + + + + + + + + + + diff --git a/wechat/index.html b/wechat/index.html index ea3642e9329d953bc88d3d42b484bde9e6f7146d..c02b9c340ce1aae43251e38bae2ab5d62b5fb058 100644 --- a/wechat/index.html +++ b/wechat/index.html @@ -282,15 +282,15 @@

    - Jenkins 微信订阅号 + Jenkins 和 Kubernetes -云上的神秘代理

    - 来自 Jenkins 官方的消息 + 运行在 K8S 上的 Jenkins 动态节点 - + 查看更多 » @@ -307,15 +307,15 @@

    - Jenkins 的重要安全更新 + Jenkins 微信订阅号

    - 重要安全更新 + 来自 Jenkins 官方的消息 - + 查看更多 » @@ -332,15 +332,15 @@

    - 从 Jenkins Master 扩展网络连接 + Jenkins 的重要安全更新

    - 从 Jenkins Master 扩展网络连接 + 重要安全更新 - + 查看更多 » @@ -357,15 +357,15 @@

    - 使用 YAML 文件配置 Jenkins 流水线 + 从 Jenkins Master 扩展网络连接

    - 这也是一种自定义流水线 DSL 的方法 + 从 Jenkins Master 扩展网络连接 - + 查看更多 » @@ -382,15 +382,15 @@

    - 回顾 2018: 革新的一年 + 使用 YAML 文件配置 Jenkins 流水线

    - Jenkins 创始人 KK 先生的年终总结 + 这也是一种自定义流水线 DSL 的方法 - + 查看更多 » diff --git a/wechat/index.xml b/wechat/index.xml index 51a05f320bd4b1180d7bf67a6938cce298d7b43c..4e298ff3487467180835e71d324c3a5d79077d18 100644 --- a/wechat/index.xml +++ b/wechat/index.xml @@ -79,6 +79,19 @@ JCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或 更多细节请查看 变更记录 。欢迎对中文本地化工作感兴趣的同学加入我们！ + + Jenkins 和 Kubernetes -云上的神秘代理 + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://jenkins-zh.github.io/wechat/articles/2019-01-30-k8s-jenkins-secet-agent/ + 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 +如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 +我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 +下面是我在这些年中使用 Jenkins 的各个阶段. + 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. + + Jenkins 微信订阅号 https://jenkins-zh.github.io/wechat/articles/2018-11-14-first-voice/ diff --git a/wechat/page/2/index.html b/wechat/page/2/index.html index 482b2b8203c437eea85f1cffb4a7b48c25f72fb6..37f3fd3cae3de6ba4e7648ee1250ed2b020259cd 100644 --- a/wechat/page/2/index.html +++ b/wechat/page/2/index.html @@ -156,6 +156,31 @@
    +

    + 回顾 2018: 革新的一年 +

    + +
    + + Jenkins 创始人 KK 先生的年终总结 + + + + 查看更多 » + + +
    + + +
    +
    + + +
    + +
    + +

    在 VS Code 中校验 Jenkinsfile