个人访问令牌用于对Buddy API中开发人员应用程序进行身份验证。在上一个版本中，我们通过两个新选项进一步对其加强：工作区域名限制和IP地址限制。
一个可能的用例涉及DevOps工程师使用个人访问令牌在其公司的工作区中管理自动化。这意味着该工作区的成员可以使用该令牌参与自动化过程。但是，如果我们的工程师同时在多个工作区工作，则存在用户可以使用令牌访问他们不属于工作区的风险。新的限制允许您解决此种情况。
要启用限制，请转到用户配置文件中的API设置，然后单击要调整的令牌：
检查字段访问限制以展开详细信息。您可以在此处定义允许使用令牌的工作区和IP地址：
您还可以在令牌详细信息中使用这些范围定义对系统各个部分的访问：
我们全新的功能允许您充值账户余额，以确保您的工作区运行自如，例如，在您的信用卡或银行账号出现意外问题时而不受影响。
要向钱包中充值资金，请转到用户账单设置之下的余额 & 交易选项卡：
Buddy为100%客户驱动！告诉我们您需要哪些集成才能将您的自动化开发运维提升到一个新的水平！如果您错过了某个功能或集成，请在客服聊天与我们联系，或者直接给我们发邮件：support@buddy.red
本指南内容需要基本的Git知识。如果您没有版本控制系统的经验，您可以在此处上手Git
作为开发人员，您应该知道，在计算机上运行应用程序之前，您需要先配置其环境。执行此操作所需的任务列表可能很长，包括如下：
诸如此类...
环境中的每个更改(例如数据库版本更改)、新添软件包或任何其他依赖项都意味着：
如果没有适当的工具，很难跟踪依赖项。而且，无论是否使用，与配置相关的问题往往会意外出现，并且难以调试和修复。这就是为什么多年来我们测试了各种排除方法。
我们使用虚拟机和配置管理工具，如Vagrant、Ansible或Puppet。然而，虚拟机非常耗费资源，并且启动和停止所需的时间非常长，以至于减慢了工作进度。处理配置管理工具也非常耗时，并且需要专业知识。
Docker如何帮助您处理上述问题？ 让我们从Docker本身的定义开始并从实践中证明。
Docker容器将一个软件包装在一个完整的文件系统中，其中包含运行所需的一切：代码、运行时、系统工具、系统库 —— 任何可以安装在服务器上的东西。无论其环境如何都能保证软件将始终以相同的方式运行。
明确思路:
听起来，Docker是不是很不错，要不要试试? 接下来我们来看看使用它有多么容易。
假设我们刚刚聘请您作为负责我们网站的开发人员。要开始工作，您需要访问至：
在使用Docker时，我们消除了处理配置时最棘手的问题：
让我们来看一个简单的例子，证明Docker是如何处理。
首先，您需要根据供应商网站上的指南安装Docker：
为了向您展示Docker的工作原理，我们将使用一个具有已Docker化应用程序的存储仓，下载此压缩文件并将内容解压到任何目录中。
运行终端，转到解压缩文件的目录，然后执行docker compose up命令：
cd 解压文件目录
docker compose up
搞定！您的开发环境正在运行，您可以浏览网站于http://localhost:8080:
注: 您所做的只是安装Docker，没有安装HTTP服务器、无需处理依赖项，一个组件都不需要配置。然而一切就绪，是不是很赞？那让我们继续深入其中！
现在，用您喜欢的编辑器打开 index.html 文件并随意更改，例如，更改：
<body class="bg-black">
为
<body class="bg-blue">
保存更改并刷新网站。目前网站背景已变为蓝色，您的更改立即可见！给您什么样的工作结论呢? 快速地向您介绍我们的团队，您的工作做得很棒！
您可能已注意到目录里不仅仅只有 index.html 文件，让我们来看看项目里的内容：
index.html：网站源码文件nginx.conf, NGINX服务器配置文件docker-compose.yml 环境配置的所有信息由于我们已经对index.html进行了一些更改，让我们看看其他两个文件。
这是NGINX服务器的基本配置文件， 它所说的是服务器应该对/www目录提供服务:
server {
index index.html;
root /www;
}
此文件包含应用程序环境的定义。乍一看，该文件的代码可能有点吓人，但不要担心，我们将一一说明。
version: “2”
services:
web:
image: nginx
ports:
- "8080:80"
volumes:
- .:/www
- ./nginx.conf:/etc/nginx/conf.d/default.conf
version: “2“ – 决定整个文件中使用的语法。docker-compose文件格式有两个版本： 版本1(老版本，不支持文件集或网络)和版本2(最新版本)services: – 此区域定义容器。目前，此文件只定义一个名为web的容器。image: nginx – 这意味着容器将基于NGINX镜像创建。镜像存储于Docker注册中心。您可以选取一个从Docker Hub上现成可用的镜像或者您自己创建一个镜像。ports: – 这部分将端口从本地主机(8080)重定向到NGINX服务器正在侦听的容器(80)。因此，我们能够在http://localhost:8080查看该网站。volumes: – 这部分是将磁盘挂载至容器。此示例中，它确保项目文件伴随着docker-compose.yml 被置于/www 目录并且我们的NGINX配置文件将覆盖容器中的文件。万一您的Dockerfile配置出问题，您随时可以联系我们support@buddy.red。当然，阅读完整个指南后，您应该能理解它如何工作并可自己写一个。
到目前为止，作为我们的新员工，您不必担心环境配置。 为了确保不让您觉得太轻松，再给您分配一个新任务。很简单：您必须在我们网站上的“hello world”语句下面添加当前日期和时间。
为此，您需要PHP。默认情况下，NGINX服务器不处理PHP文件，但我们可以通过完成两个任务来处理：
配置NGINX服务器只需更新nginx.conf文件：
server {
index index.php;
root /www;
location ~ \.php$ {
fastcgi_pass php:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
上述更改表明，所有PHP文件都应该由端口号为9000的PHP服务解析。
接下来我们需要的是PHP服务器。我们将添加另一个容器，负责解析PHP文件。为此，将php服务添加到docker-compose.yml文件中并定义NGINX服务的镜像版本和链接命令顺序。第二件事是将web服务容器链接到PHP容器，以便两者可以互通：
version: "2"
services:
web:
image: nginx
ports:
- "8080:80"
volumes:
- .:/www
- ./nginx.conf:/etc/nginx/conf.d/default.conf
links:
- php
php:
image: php:7-fpm
volumes:
- .:/www
我们已经准备好了配置，这意味着是时候继续进行实际开发和处理index.html文件了。我们想在网站上显示日期和时间，我们需要做两件事：
index.php<?php
echo "<p>".date("Y-m-d H:i:s")."</p>";
?>
现在我们可以尝试新的配置，并检查日期和时间是否真的显示在我们的网站上。为此，从终端运行以下命令：
docker compose down
docker compose up
刷新网站，即可看到想要的结果：
按照以上说明，您可以将其他服务，如MySQL、MongoDB、PostgreSQL等添加到docker-compose.yml文件中。而且，最重要的是，每次向Git存储仓推送时，您所做的更改都可供其他团队成员使用。谁都不需要配置任何东西，无论本地操作系统或PHP服务器安装，只要运行docker compose up命令即可启动环境。
到目前为止，我们一直在使用本地开发环境在本地开发网站。但我们如何使用Docker实际部署？答案很明显：在生产服务器上安装docker-compose，在那里上传新的源文件，然后在服务器上执行docker compose down和docker compose up。
听起来很简单，但当您每天要手动做几次时，都需要烦人的重复同样的工作。您要交付存储仓中的每一项更改都需要连接服务器、将文件上传到服务器、登录并来回运行命令，这不仅耗时，还很容易出错。而且您可能每天要处理不止一个项目和一个交付。
换句话说，将流程自动化将会非常好。这就是Buddy介入的地方，Buddy的交付流水线让Docker自动化变得轻而易举。
您所需要做的是：
在此例中，我们将使用之前的网站，并在Buddy中对其进行版本控制：
从此链接下载并解压文件: https://assets.buddy.works/guides/buddy-docker-nginx.zip
在已解压的文件目录中运行以下命令：
git init
git add *
git commit -m "init repo"
git push --all BUDDY_REPO_URL
BUDDY_REPO_URL 是添加项目时显示的URL：
我们将使用流水线--自动化部署工具
首先，添加一个流水线，该流水线自动将引入存储仓的更改部署到生产服务器。
添加将应用程序源文件上传到服务器的操作。在Buddy，您可以从众多上传选项中进行选择，从裸机服务器到AWS、DigitalOcean和Microsoft Azure等云服务。在本例中，我们将使用SFTP：
在操作详细信息栏目上，输入授权数据和上传路径：
添加SSH操作以运行docker compose down 和 docker compose up -d。此操作需要在工作目录中执行授权数据和定义方法。工作目录必须与上传操作的目录相同，以便在放置源文件的目录中运行命令。
当操作添加于流水线完成之后，应该显示有如下图:
您可以看到上传操作之后是SSH操作，脚本触发Docker命令。通过这种设置，存储仓中的每次更改都将自动推送到服务器，并在生产环境中可见。配置与源码紧密结合。
您可以手动检查流水线的工作方式，只需单击流水线名称右侧的运行按钮即可。现在打开页面(服务器 IP:8080)并在实时服务器上查看您的网站。
现在我们还有一个诀窍给您。在开发过程中，我们建议使用暂存服务器。这是变更在发布之前进行测试的地方。使用Docker和Buddy配置很容易，只需按照下面列出的步骤操作即可。
将新分支添加到存储仓(暂存分支)。Git分支让您可以同时处理多个完全不同的功能而无需处理项目依赖关系或同步更改：
为暂存服务器新添流水线。此流水线将执行与生产服务器流水线完全相同的任务，但用于另一个分支。您可以复制现有流水线。之后，您需要稍微修改一下：
将分支名称从生产更改为暂存
编辑文件上传操作：更改路径，使其指向您的暂存服务器(暂存应用程序文件必须放置在与实时应用程序文件不同的目录中）
编辑SSH操作：
最后，确保将分支重新分配到暂存分支staging
现在，您的生产和暂存应用程序正在同一服务器上运行：
它们可能使用不同的配置，并且暂存应用程序中的任何更改都不会影响您的生产环境，因为这两个应用程序都在单独的容器中运行并且彼此隔离。
docker-compose.yml文件在很短的时间内设置应用程序环境。感谢Docker、感谢Buddy，让我们快速地部署自动化运维！您所要做的就是安装Docker，从存储仓中提取文件，然后就可以在短时间内提交代码，为我们的公司提供巨大价值。您还知道如何在服务器上执行相同的操作，以及如何使用Buddy及其流水线来自动化您的工作。
让我们骑着这头大蓝鲸在海上快乐地航行吧！
在此文章中，我们将探索Kubernetes(K8s)，结合DigitalOcean Kubernetes集群与Buddy自动化运维系统部署以达到以下列出的目标：
K8s可以将其描述为一个容器编排平台，它可以在云端或远程机器上扩展和运行您的应用程序。为了更容易理解，您可以把它想象成一个容器管理器，它会自动处理您必须手动执行的操作。
以下是使用K8s的一些优势：
即使没有持续部署，K8s也能够在几乎没有停机时间的情况下促进和管理各种规模的发布。
K8s本身由几个组件组成。但我们不会在本文中介绍所有内容，主要关注于容器，我们还将使用Docker。
K8s上的容器以称为Pod的组合运行。Pod中的容器共享相同的网络、存储和地址。这说明访问pod的地址实际上意味着访问pod中的容器之一：
虽然您确实不需要流水线来让应用程序在云服务上运行，但由于SDK，在更大范围内，团队会发现依赖本地机子部署效率非常低。
流水线可以被认为是将服务或应用程序从A点移动到B点的一种方式。在CI/CD方面，我们可以将其分为三种类型：
微服务模式引入了一种新的软件实现方式。将此视为一种移动模式，涉及多个移动部件，所有部件都统一起来以呈现单个应用程序。
无论有没有DevOps工作人员，您的团队都不必担心与运维相关的问题，比如弄清楚三个应用程序组件的交付。最重要的是保持对产品的聚焦。
过去，部署堆栈主要基于Shell脚本构建。对于以前没有堆栈经验的团队成员来说，这通常很复杂。现在，几乎每个平台都提供 YAML。作为一种声明式和更透明的语言，YAML的学习曲线相当容易。然而，不幸的是，有些平台仍然需要YAML上对shell的解决方案。
Buddy凭借着其直观的GUI和流水线声明式YAML配置解决了这些问题。
安全性是任何流水线的关键组成部分。关键的安全问题之一是处理密钥和敏感信息。在大多数情况下，密钥或敏感信息在进行加密后作为环境变量添加到平台上，然后在构建过程中进行转译和解密。在定义这些作业的过程中，很容易通过打印密钥或对公共Docker镜像进行版本控制来泄露这些细节信息。同时还建议避免在第三方服务上使用不受限制的API密钥。
Buddy如何处理安全问题
平台关联肯定是最大的挑战之一。不同的团队以不同的方式处理此问题：从开箱即用的特定于平台YAML模块到脚本连接。建议采用模块化方法代替脚本化流水线，通常涉及几个步骤：从获取SDK到授权，再到实际部署。这通常会导致相当复杂、容易出错且体积庞大的流水线。
Buddy提供与各大商家的各种集成，以及具有声明性流水线操作模式丰富的buddy.yml脚本。
本文的K8s示例应用可以在这个GitHub Repo中下载源码！
首先创建一个名为hello的Buddy项目，并选择Buddy自带的Git托管作为代码存储仓:
下载GitHub存储仓中的源码并推送至刚刚创建的项目存储仓：
然后在Buddy中添加DigitalOcean集成，以方便持续集成所要使用的DigitalOcean Kubernetes集群：
在hello项目中创建一条流水线：
接下来，我们将在流水线上添加第一个操作，即Docker构建镜像，为将所构建的镜像推送至Docker Hub而做准备：
选择存储仓上的Dockerfile文件并提交完成添加Docker构建镜像操作：
添加第二个操作：推送Docker镜像
推送Docker镜像的作用是可将上一个操作构建好的镜像推送至目标Docker注册中心，也就是Docker镜像存储仓，例如：Docker Hub、Amazon ECR、Google GCR以及私有的镜像注册中心等等不一。
如果您是第一次接触Docker镜像构建，推荐使用Docker Hub，目前只需要在Docker官方网站上免费注册一个帐户即可使用。
填写好相关要推送的镜像信息完成添加推送Docker镜像
此时，您应该看到如下图有两个操作添加于流水线之中：
点击以上蓝色“运行”按钮开始运行流水线：
运行完成之后，我们就可以在Docker Hub帐户中看到已有相关镜像信息显示：
在hello项目存储仓中添加第一个Hello World YAML文件hello-kubernetes-first.yaml，同时在文件中添加以下代码：
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-first
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-first
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-first
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-first
template:
metadata:
labels:
app: hello-kubernetes-first
spec:
containers:
- name: hello-kubernetes
image: dogeek/hello-kubernetes:1.2
ports:
- containerPort: 8080
env:
- name: MESSAGE
value: 这是第一个Hello World部署!
此配置定义了部署(Deployment)和服务(Service)。 部署包含aulbouwer/hello-kubernetes:1.7镜像的三个副本(replicas)和一个名为MESSAGE的环境变量(您将在访问应用程序时看到此信息)。这里的服务(Service)定义为在80端口显露(expose)集群内的部署(Deployment)。
在流水线中添加K8s提交部署操作：
添加hello-kubernetes-first.yaml文件，这个文件将在流水线运行时提交部署至K8s集群中：
根据以上相同的添加步骤再添加一个hello-kubernetes-second.yaml文件作为第二个Hello World演示，并在文件中添加以下代码：
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-second
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-second
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-second
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-second
template:
metadata:
labels:
app: hello-kubernetes-second
spec:
containers:
- name: hello-kubernetes
image: dogeek/hello-kubernetes:1.2
ports:
- containerPort: 8080
env:
- name: MESSAGE
value: 这是第二个Hello World部署!
此时我们就可以在流水线中看到如下图所示的流水线信息：
如上图在流水线上点击蓝色“运行”按钮，将会看到如下图所示的构建Docker镜像、推送Docker镜像以及提交两个Hello World YAML配置文件至K8s集群的流水线运行信息：
在命令行界面上运行以下命令：(创建DigitalOcean Kubernetes集群时会提示您如何配置您的电脑与其连接)
kubectl get service
运行以上代码后会显示以下信息
hello-kubernetes-first和hello-kubernetes-second都已列出，说明已经创建成功Kubernetes。
您已经使用Buddy自动化运维创建了hello-kubernetes应用程序的两个部署。每个在部署规范中都有不同的信息显示，以便在测试期间区分。 下一步，我们将安装Nginx Ingress Controller：
我们将使用Helm安装Nginx Ingress 控制器
Nginx Ingress控制器 由一个Pod和一个Service组成。Pod运行控制器，控制器不断轮询集群API服务器上的/ingresses端点以获取可用Ingress资源的更新。该服务的类型为LoadBalancer。因为您将其部署到DigitalOcean Kubernetes集群，集群将自动创建一个DigitalOcean负载均衡器，所有外部流量将通过该负载均衡器流向控制器。然后控制器会将流量路由到适当的服务，如Ingress资源中定义的那样。
只有LoadBalancer服务知道自动创建的负载均衡IP地址。某些应用程序(例如：ExternalDNS)需要知道其IP地址，但只能读取Ingress的配置。通过在helm install安装期间将controller.publishService.enabled参数设置为true，可以将控制器配置为在每个Ingress上发布IP地址。建议启用此设置以支持可能依赖于负载均衡器IP地址的应用程序。
要安装 K8s Nginx Ingress 控制器，我们首先需要通过运行以下命令将其存储库添加到Helm：
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
更新系统，让Helm知道所包含的内容：
helm repo update
最后，运行以下命令安装Nginx Ingress：
helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true
此命令从稳定chart存储仓安装Nginx Ingress，将Helm版本命名为nginx-ingress，并将publishService参数设置为true。
运行后，您将看到类似以下的输出：
Helm已将其在Kubernetes中创建的资源记录为chart安装的一部分。
运行此命令以查看负载均衡器是否可用：
kubectl --namespace default get services -o wide -w nginx-ingress-ingress-nginx-controller
该命令在默认命名空间中获取Nginx Ingress服务并输出其信息，但该命令不会立即退出。使用-w参数，它会在发生更改时监测并刷新输出信息。
我们已经安装了由Kubernetes社区维护的Nginx Ingress。它将HTTP和HTTPS流量从负载均衡器路由到Ingress资源中适配后端服务。 下一步，我们将显露(expose)公开hello-kubernetes应用程序部署。
在公开应用程序之前，我们需要准备两个域名并指向负载均衡器IP，我们将使用以下两个域名作为演示：
首先，通过以上已在Buddy创建的hello项目存储仓中再创建一个名为hello-kubernetes-ingress.yaml的文件，并添加以下代码部署两个示例域名以便在浏览器中测试：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: "1.m2jd.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-first
port:
number: 80
- host: "2.m2jd.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-second
port:
number: 80
我们使用名称hello-kubernetes-ingress定义Ingress资源。然后指定两个主机规则，以便将1.m2jd.com域名转向路由到hello-kubernetes-first服务，并将2.m2jd.com域名转向路由到第二个部署hello-kubernetes-second的服务。
接下来，添加hello-kubernetes-ingress.yaml文件到流水线操作提交Kubernetes部署之中并运行流水线。我们就可看到如下图的hello-kubernetes-ingress部署到K8s集群的Buddy流水线运行记录：
现在我们可以在浏览器中打开域名1.m2jd.com即可看到如下显示：
在浏览器中打开域名2.m2jd.com即可看到如下显示：
为了保护Ingress资源，我们将安装Cert-Manager，为生产运营创建ClusterIssuer，并修改Ingress的配置以使用TLS证书。安装和配置后，应用程序将在HTTPS之下运行。
ClusterIssuers是Kubernetes中的Cert-Manager资源，它为整个集群提供TLS证书。ClusterIssuer是一种特定类型的发行者。
在通过Helm将Cert-Manager安装到您的集群之前，您将为它创建一个命名空间：
kubectl create namespace cert-manager
这时，您需要将Jetstack Helm存储仓添加到托管Cert-Manager图谱(chart)的Helm。 为此，运行以下命令：
helm repo add jetstack https://charts.jetstack.io
Helm将显示以下输出信息：
更新Helm图谱缓存：
helm repo update
更新命令运行将显示以下输出信息：
最后，通过运行以下命令将Cert-Manager安装到cert-manager命名空间中：
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.10.1 --set installCRDs=true
在此命令中，我们也将installCRDs参数设置为true，以便在Helm安装期间安装cert-managerCustomResourceDefinition配置清单。在写本文时，v1.10.1是最新版本。您可以参考ArtifactHub查找最新版本号。
除了在命令行界面上运行Helm命令，您也可以在Buddy流水线上添加Helm CLI操作并运行流水线：
输出信息将显示如下：
我们现在创建一个由Let's Encrypt颁发的证书，并将其配置存储在名为production_issuer.yaml的文件中。在hello项目存储仓中创建并打开此文件并添加以下代码：
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
# Email address used for ACME registration
email: 请在此输入您的电子邮件地址
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Name of a secret used to store the ACME account private key
name: letsencrypt-prod-private-key
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
class: nginx
接下来，同样在流水线中添加production_issuer.yaml文件到流水线操作提交Kubernetes部署之中并运行流水线:
在hello-kubernetes-ingress.yaml文件中添加以下高亮背景颜色的代码：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- 1.m2jd.com
- 2.m2jd.com
secretName: hello-kubernetes-tls
rules:
- host: "1.m2jd.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-first
port:
number: 80
- host: "2.m2jd.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-second
port:
number: 80
提交文件后Buddy将自动为您运行流水线，此时您的域名已支持SSL证书，恭喜！
在实际操作中，请将域名换成您自己的域名，而不是照搬1.m2jd.com与2.m2jd.com，那样将不会正常运行！
Kubernetes是一个基于容器的平台，用于部署、扩展和运行应用程序。Buddy让您可以通过一系列专用的K8s操作来自动化您的Kubernetes交付工作流。
每次更改应用程序代码或Kubernetes配置时，您都有两个选项来更新集群：kubectl apply 或 kubectl set image。
在这种情况下，您的工作流程通常如下所示：
kubectl apply 或 kubectl set image如果您经常使用 kubectl apply 或 kubectl set image，这个就是更好的解决方案!
如果你经常在容器中运行任务，比如：
您可以使用pods或任务，第一种类型使用任务启动单个pod；第二个启动系列pod，直到指定数量的pod以成功状态结束。
假设您在K8s集群上有一个应用程序，存储仓包含如下内容：
在这种情况下，您可以配置一个流水线：
A. 构建应用程序并迁移镜像(第一个操作)
B. 推送至Docker Hub(第二个操作)
C. 触发数据库迁移 使用先前构建的镜像(第三个操作)。您可以使用YAML文件定义镜像、命令和部署：
进行推送后，流水线将自动构建并将镜像推送到存储仓并运行迁移脚本，是不是很酷？
作业操作将等到命令执行完毕，如果退出状态不同于0，则操作将被标记为“失败”。
D. 最后一个操作是使用提交Kubernetes部署或Kubernetes设置镜像来更新K8s应用程序中的镜像。添加操作后，整个流水线将如下所示：
一切就绪后，再次推送，即可看到Buddy自动执行整个工作流程。
希望您有所收获，非常感谢您花时间阅读本文！
如果您不确定是否可以将我们的解决方案应用于您的工作流程，请联系客服聊天或写信至 support@buddy.red，我们会协助您解决所遇到的疑问。
在这篇文章中，我将向您展示如何管理依赖项以及使用Gulp构建前端应用程序，并将其安全地部署到服务器。
回想过去，一切都很简单：你只需将HTML上传到服务器，可能还带有一些(严重)压缩的图片，现在，大多数Web应用程序都需要在部署之前构建。该过程通常类似以下步骤：
列出的所有工具使项目工作更容易：控制依赖项，提高应用程序性能，从而提供更好的代码、优化和排错。
然而，在开发过程中有个事情可能会失控，那就是：部署！
正如我们以上所说，之前您只要将文件上传到服务器，OK，发布就搞定了！一些开发人员认为，他们如今依然想通过将依赖项(vendor、node_nodules等)和编译后的资产保存在存储仓/仓库中来保持这种简单性。如果您是这些开发人员之一并有这种想法，请千万不要这样做。这些东西是不应该放到您的存储仓/仓库之中！
好！既然我们知道将工件和依赖项保留在存储仓中不是一个好办法，那么问题是：我们应该如何将应用程序部署到服务器？如果没有持续部署工具，它通常类似以下步骤所示：
前面提到的人为因素增加了发布所耗的时间长度。更糟糕的是，它可能会产生很难发现和诊断的错误。
总而言之，整个部署过程应简化为单个操作:
在本文此部分中，我将向您展示如何在5分钟内创建一个交付流水线，该流水线将自动获取依赖项并运行Gulp任务。
访问Buddy网站https://buddy.red 并使用您的GitHub/Bitbucket帐户或工作电子邮件进行注册
如果您使用电子邮件地址进行Buddy帐户注册，请使用您的工作邮箱，例如，带您的企业网址域名邮箱或您所在企业的域名邮箱。Buddy暂不开放一般免费电子邮件地址。
Buddy支持GitHub、Bitbucket、GitLab或者其他任何私有或开源的Git存储仓，您还可以使用具有合并请求和分支权限的Buddy自带全功能Git托管。
设置您想要部署的分支并配置触发模式: 事件(自动触发)、手动(点击触发)或定时(设定时间间隔触发)。
为将提取依赖项并生成应用程序的项目类型选择生成操作。在此例中，我将下载Node模块并运行Gulp任务，因此选择Node.js操作：
提供应用程序的构建命令并选择Node版本：
请确保保存更改以将操作添加至流水线：
应用程序已生成并准备好上传到服务器。Buddy允许您在几乎任何地方、任何方式部署代码：
在此，我们将选择SFTP作为示例。单击该操作后，系统将提示您选择要从何处部署文件。确保选择文件系统，因为它包含上一步中构建的应用程序：
提供您的服务器访问信息于传输目标，您可根据所需提供相关的服务器IP地址、用户名、密码等相关信息，您也可以提供SSH密钥信息对部署目标进行配置。为了更好地保护您的相关服务的敏感信息，您也可以通过环境变量的方式对敏感数据进行加密保护。
最后，最好添加一个通知操作，让我们随时了解已完成的部署：
如果使用任务管理器运行测试，还可以添加条件通知，以便在测试失败时向您发送消息:
万事俱备！现在，推送到触发分支，并查看Buddy流水线它将自动构建和部署您的应用程序。
2023年已到来，我们也准备好迎接新的挑战，迎接未知的激动人心的冒险！🤩 首先，我们提供了一个新的权限捆扎：流水线！
随着流水线权限的发布，职能现工作如下：
Buddy中的权限在职能中定义，在将用户添加到项目中或在“人员”选项中分配角色。在项目级中有三个默认角色：
在这三个职能之上是管理员，管理员可以无限地访问工作区中所有项目和资源。
如果帐户所有者愿意，可以创建自定义职能，自定义职能具有对项目资源(流水线、存储仓源码、沙盒)的单独权限。
新的权限级别允许您重新定义各个流水线中的访问级别。您现在可以在流水线设置的“权限”标签页中对其进行更改：
以下为可用的职能：
Buddy为100%客户驱动！请告诉我们您需要哪些集成，才能将您的自动化开发运维提升到另一个新水平！如果您尚缺某个功能或集成，请直接给我们发邮件: support@buddy.red
亲爱的Buddy用户!
这是我们在2022年最后一次为您做的年度总结及更新，同时我们期待；即将来临的2023持续为您更新Buddy动态信息、新的一年继续为您提供更优质的自动化运维系统服务：
简而言之，Buddy是一个让开发人员能够以简单可靠的方式构建、测试和发布软件的平台(系统支持本地部署、自托管私有云/专有云部署与云服务)。Buddy基于持续集成的原则，这意味着对代码的每次更改都会自动测错并为部署做好准备。部署也是自动化，这消除了人为错误风险并显著缩短操作时间。因此，您可以更快地收集客户反馈并进行更改，而不会有白白浪费数月工作的风险。
Buddy: DevOps(开发运维一体)自动化平台
最易用的CI/CD没有之一
大大降低企业使用DevOps的入门门槛！
Buddy中文版自今年6月上线以来，受到广大用户的使用、试用、反馈、提出意见建议与视频会议支持，以下为我们要特别鸣谢的企业以及相关产品研发部门的主要用户(由于用户众多如果您在使用Buddy未列入其中并有信息反馈，请给我们来信：support@buddy.red)：
Buddy祝大家新年快乐！
Buddy: 开发运维(DevOps)自动化平台
https://www.buddy.red