Jenkins Blue Ocean 的使用 基于 Jenkins 的 CI/CD(三) 上节课我们讲解了使用Jenkins Pipeline来自动化部署一个Kubernetes应用的方法，在实际的项目中，往往一个代码仓库都会有很多分支的，比如开发、测试、线上这些分支都是分开的，一般情况下开发或者测试的分支我们希望提交代码后就直接进行CI/CD 操作，而线上的话最好增加一个人工干预的步骤，这就需要Jenkins对代码仓库有多分支的支持，当然这个特性是被Jenkins支持的。 Jenkinsfile 同样的，我们可以使用上节课的方法直接把要构建的脚本配置在 Jenkins Web UI 界面中就可以，但是我们也提到过最佳的方式是将脚本写入一个名为 Jenkinsfile 的文件中，跟随代码库进行统一的管理。 我们这里在之前的 git 库中新建一个 dev 分支，然后更改 main.go 的代码，打印当前运行的代码分支，通过环境变量注入进去，所以我们我们通过 k8s.yaml 文件的环境变量把当前代码分支注入进去，具体代码可以参考https://github.com/cnych/jenkins-demo/tree/dev。 然后新建一个 Jenkinsfile 文件，将上节课的构建脚本拷贝进来，但是我们需要对其做一些修改：(Jenkinsfile)node('haimaxy-jnlp') {   ...

Jenkins Pipeline 部署 Kubernetes 应用(二) 基于 Jenkins 的 CI/CD上节课我们实现了在Kubernetes环境中动态生成Jenkins Slave 的方法，这节课我们来给大家讲解下如何在 Jenkins 中来部署一个 Kubernetes 应用。 Jenkins Pipeline 介绍 要实现在 Jenkins 中的构建工作，可以有多种方式，我们这里采用比较常用的 Pipeline 这种方式。Pipeline，简单来说，就是一套运行在 Jenkins 上的工作流框架，将原来独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排和可视化的工作。 Jenkins Pipeline 有几个核心概念： Node：节点，一个 Node 就是一个 Jenkins 节点，Master 或者 Agent，是执行 Step 的具体运行环境，比如我们之前动态运行的 Jenkins Slave 就是一个 Node 节点 Stage：阶段，一个 Pipeline 可以划分为若干个 Stage，每个 Stage 代表一组操作，比如：Build、Test、Deploy，Stage 是一个逻辑分组的概念，可以跨多个 Node Step：步骤，Step 是最基本的操作单元，可以是打印一句话，也可以是构建一个 Docker 镜像，由各类 Jenkin...

kubernetes集群证书一年后过期，如何续期 模拟证书过期 由kubeadm部署的集群，所生成的证书证书有效期为一年，过期之后集群就不能再次使用了，我们可以对证书进行续期，这样集群就可以继续使用。 可以通过如下命令查看具体过期时间：kubeadm alpha certs check-expiration 这里显示证书在2021年7月5日过期，然后把所有节点的系统时间调整到 2022年10月1日： 所有节点的时间都要调整。 然后在master（vms71上）执行kubectl命令：[root@vms71 ~]# kubectl get nodes Unable to connect to the server: x509: certificate has expired or is not yet valid [root@vms71 ~]# 此时提醒证书已经过期。 对证书进行续期 用如下命令申请续期一年： kubeadm alpha certs renew all[root@vms71 ~]# kubeadm alpha certs renew all ...输出... certificate for the front proxy client renewed certificate embedded in the kubeconfig file for the scheduler manager to use renewed [root@vms71 ~]# 现在查看证书过期时间： 更新kubeconfig文件： 验证 验证集群是否可用： 已经可以继续使用了。查看集群过期时间： 过期时间已...

Kubelet 证书自动续签 K8s证书一般分为两套：K8s组件（apiserver）和Etcd 假如按角色来分，证书分为管理节点和工作节点。 • 管理节点：如果是kubeadm部署则自动生成，如果是二进制部署一般由cfssl或者openssl生成。 • 工作节点：工作节点主要是指kubelet连接apiserver所需的客户端证书，这个证书由controller-manager组件自动颁发，默认是一年，如果到期，kubelet将无法使用过期的证书连接apiserver，从而导致无法正常工作，日志会给出证书过期错误（x509: certificate has expired or is not yet valid） 二进制，这个是k8s apiserver的一套证书[root@k8s-master ~]# ls /opt/kubernetes/ssl/ ca-key.pem kubelet-client-2020-09-30-11-12-16.pem kubelet.crt server-key.pem ca.pem kubelet-client-current.pem kubelet.key server.pem 这个是apiserver连接etcd所需要的证书[root@k8s-master ~]# ls /opt/etcd/ssl/ ca-key.pem ca.pem server-key.pem server.pem kubeadm部署的两套证书都放在这里[root@k8s-master ~]# ls /etc/kubernetes/pki/ apiserver.crt etcd apiserver-etcd-client.crt ...

CentOS 7下Docker桥接网络,实现与宿主同一网络,实现独立IP与独立端口效果为什么要让docker桥接物理网络？ docker默认提供了一个隔离的内网环境，启动时会建立一个docker0的虚拟网卡，每个容器都是连接到docker0网卡上的。而docker0的ip段为172.17.0.1，若想让容器与宿主机同一网段的其他机器访问，就必须在启动docker的时候将某个端口映射到宿主机的端口上才行，例如：docker run -itd -p 22 centos。这是我们所不能接受的，想想每个应用都要绞尽脑汁的去设置端口，因为不能重复，如果应用有多端口那更是不堪设想啊。所以为了让容器与宿主机同一个网段，我们需要建立自己的桥接网络。    centos7宿主机上建立Docker桥接物理网络过程 宿主机网卡信息： DEVICE=ens33 IPADDR=192.168.179.99 GATEWAY=192.168.179.2 NETMASK=255.255.255.0 DNS1=114.114.114.114 DNS2=8.8.8.8 创建桥接物理网络 （1）新建br0桥接网络，brctl show可以查看（需安装bridge-utils） （2）将宿主机物理网卡IP、掩码、网关、dns（或者dhcp）配置到br0上 （3）删除宿主机物理网卡IP、掩码、网关、dns（或者dhcp）配置 （4）将宿主机物理网卡加入到br0   过程步骤如下 自定义br0...

介绍一些常用的命令类操作的模块。 command模块command模块可以帮助我们在远程主机上执行命令注意：使用command模块在远程主机中执行命令时，不会经过远程主机的shell处理，在使用command模块时，如果需要执行的命令中含有重定向、管道符等操作时，这些符号也会失效，比如"<", ">", "|", ";" 和 "&" 这些符号，如果你需要这些功能，可以参考后面介绍的shell模块，还有一点需要注意，如果远程节点是windows操作系统，则需要使用win_command模块。 此处我们介绍一些command模块的常用参数，你可以先对这些参数有一个大概了解，然后再看小示例。free_form参数 ：必须参数，指定需要远程执行的命令，需要说明一点，free_form参数与其他参数并不相同，在之前的模块示例中，如果想要使用一个参数，那么则需要为这个参数赋值，举个例子，之前的示例模块中，大多都有path参数，当我们需要指定要操作的文件时，通常需要对path参数赋值，比如，path=/testdir/test，表示我们想要操作/testdir/test文件，但是free_form参数则不同，"free_form"并不是一个"实际存在"的参数名，比如，当我们想...

docker安装jenkins使用npm容器构建Node.js+实现cicd部署 目标: docker中运行jenkins,通过npm容器构建项目，项目资源打包部署到远程主机的目录中。 一、jenkins 的安装 1，配置要求 docker主机IP: 192.168.1.20，系统：centos7 ,需要安装docker,再创建一个jenkins容器，挂载目录: /opt/jenkins 。 部署nginx服务器IP: 192..168.1.41，系统：centos7 ，保存jenkins通过sftp传送过来的项目构建的资源的文件目录：/opt/app， 服务器IP: 192..168.1.41，安装docker,创建一个 nginx容器挂载目录为 /opt/cicd/nginx，用来部署静态资源。 整个流程原理, docker主机安装jenkis-->构建一个nodejs的容器,git源码，打包出静态资源--->通过sftp将打包文件传送到nginx容器所在主机的/opt/app/web目录---> 再将/opt/app/web/目录下的资源，复制到nginx的挂载目录 /opt/cicd/nginx下，当然也可以直接sftp到nginx的目录。 实现项目的静态资...

gitlab+docker安装gitlab-runner进行cicd自动化部署过程1，先到gitlab官方注册账号，并创建一个仓库 demo，这里就导入ruoyi-cloud中的ruoyi-ui前端项目代码。2，在到阿里云上买一个国外的ECS主机。3，在ecs主机上面安装apache,docker. 1),下面是ecs主机操作记录：sudo yum install -y yum-utils #配置docker的yum地址 sudo yum-config-manager \ --add-repo \ http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo# 启动&开机启动docker systemctl enable docker --now # docker加速配置 sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2" } EOF sudo systemctl daemon-reload sudo systemctl restart docker3，docker中安装gitlab-runner,并创建/opt/runner作为挂载目录[root@gitlab-runner ~]# mkdir /opt/runner[root@gitlab-runner ~]# d...

github的前端项目通过action自动打包推送部署1,在github中，创建一个新仓库 名为: demo2,将本机windows中的前端目录文件推送到 demo仓库中，具体不再说了。我这里就以ruoyi-ui的前端UI为例，将项目文件推送到demo仓库中。创建目录 G:\vscode\ruoyi-ui,将文件复制到目录下。PS G:\vscode\ruoyi-ui> git initInitialized empty Git repository in G:/vscode/ruoyi-ui/.git/PS G:\vscode\ruoyi-ui> git add .PS G:\vscode\ruoyi-ui> git commit -m "first commit"[master (root-commit) 4ca694c] first commit 283 files changed, 24423 insertions(+) create mode 100644 .editorconfig create mode 100644 .env.development.......................PS G:\vscode\ruoyi-ui> git branch -M masterPS G:\vscode\ruoyi-ui> git remote add origin https://github.com/yjvps/demo.gitPS G:\vscode\ruoyi-ui> git push origin masterwarning: ----------------- SECURITY WARNING ----------------warning: | TLS certificate verification has been disabled! |warning: ---------------------------------------------------warning: ...

使用GitHub Actions实现前端自动化打包、部署 一、前言 作为一名前端菜鸡，服务器小白，刚开始在Linux服务器上部署网站时，前端代码我一般都是打包后手动FTP传上去， 后端代码直接在vscode中使用SSH连接服务器，直接同步代码更改。 但小黑作为一个生命不息折腾不止的程序猿，肯定要探索更好玩更高效的方法，所以这次，咱就上手折腾了下自动化部署方案 二、准备工作 1、持续集成服务（CI）方案选择 实现代码提交的自动化工作流，要依靠持续集成（CI）（或者加上持续交付(CD)）服务。现在主流的公用免费的持续集成服务有： Travis CI Jenkins Circle CI Azure Pipeline GitHub Actions 其中GitHub Actions是GitHub自家的持续集成及自动化工作流服务，简单易用，也是小黑本次使用的服务。它使用起来非常简单， 只要在你的仓库根目录建立.github/workflows文件夹，将你的工作流配置(YAML文件)放到这个目录下，就能启用GitHub Actions服务。 小黑...