跳到主要内容

· 阅读需 10 分钟
南哥

什么是自签名证书​

自签名证书（Self-signed certificate）是一种数字证书，其签名者和证书所有者相同。这意味着证书是由其所有者自己签发的，而不是由受信任的证书颁发机构（CA）签发。自签名证书主要用于测试、开发和内部使用，通常不适用于公共互联网服务，因为其缺乏信任链。

当客户端（如浏览器）访问使用自签名证书的服务器时，通常会收到一个安全警告，提示证书不受信任。这是因为浏览器无法验证自签名证书的合法性，所以在使用自签名证书时需要谨慎。尽管如此，自签名证书仍然可以提供数据加密，以保护数据在传输过程中的安全。但由于它们无法证明服务器的身份，因此更容易受到中间人攻击。

tls详细原理​

tls (Transport Layer Security)是一种安全协议，用于在互联网上为客户端和服务器之间的通信提供加密和身份验证

  1. 握手阶段：客户端（如浏览器）与服务器建立连接时，首先进行 SSL/TLS 握手。客户端会发送一个 "ClientHello" 消息，包含支持的加密套件、协议版本以及一个随机数。

  2. 服务器响应：服务器收到 "ClientHello" 消息后，会选择一个加密套件（从客户端提供的选项中选择），并发送一个 "ServerHello" 消息。同时，服务器会发送其数字证书，以证明自己的身份。

  3. 客户端验证：客户端收到服务器的证书后，会验证证书的有效性。这通常包括验证证书的签名、有效期以及证书颁发机构（CA）的信任。如果证书验证失败，客户端会中断连接并给出警告。

  4. 密钥交换：客户端验证证书成功后，会使用服务器证书中的公钥对一个预主密钥（Pre-master secret）进行加密，并将其发送给服务器。这个预主密钥只能由服务器的私钥解密。此时，客户端和服务器都有了预主密钥，然后双方根据预主密钥和之前交换的随机数生成相同的主密钥（Master secret）。

  5. 完成握手：客户端和服务器使用主密钥生成会话密钥（Session keys），这些会话密钥用于加密和解密数据，以及验证数据完整性。双方发送 "Finished" 消息，确认握手已完成。

  6. 加密通信：握手完成后，客户端和服务器使用会话密钥加密和解密数据进行通信。这样，即使数据被拦截，攻击者也无法阅读原始内容，保证了数据的机密性和完整性。

第三步，如何验证是非自签名的​

在SSL/TLS握手的第三步中，客户端验证服务器证书以确认服务器身份。验证非自签名证书涉及以下几个关键步骤：

  1. 检查证书颁发机构（CA）：非自签名证书是由受信任的证书颁发机构颁发的。客户端（如浏览器）通常内置有一个受信任CA列表。当收到服务器证书时，客户端会检查证书签名中的CA是否在其受信任的列表中。如果不在列表中，证书可能会被视为不受信任。

  2. 验证证书链：一个有效的非自签名证书需要具有完整的证书链，从服务器证书到根CA证书。证书链中可能包含一个或多个中间CA证书。客户端会按照证书链，逐个验证每个证书的签名，直到到达受信任的根CA。这个过程构建了一个信任链，证明了服务器证书的有效性。

  3. 检查证书有效期：客户端需要检查服务器证书的有效期，确保证书在有效期内。如果证书已过期，客户端会认为证书不可信。

  4. 检查证书吊销状态：证书可能在其有效期内被吊销。客户端可以通过在线证书状态协议（OCSP）或证书吊销列表（CRL）检查证书的吊销状态。如果证书被吊销，客户端将不再信任它。

  5. 检查服务器域名：为了防止中间人攻击，客户端需要检查服务器证书中的域名是否与访问的域名一致。如果域名不匹配，客户端会认为证书不可信。

通过以上步骤，客户端可以验证非自签名证书的有效性。只有当所有检查均通过时，客户端才会认为证书可信并继续SSL/TLS握手过程。

要获取一个SSL/TLS证书，您需要经历以下步骤​

  1. 选择证书颁发机构（CA）：首先，您需要选择一个受信任的证书颁发机构，如Let's Encrypt、DigiCert、GlobalSign等。这些机构颁发的证书在绝大多数浏览器和操作系统中都会被接受。

  2. 生成CSR和私钥：在您的服务器上生成一个证书签名请求（CSR）和相应的私钥。CSR包含您的网站信息，如域名、组织名称、地理位置等。您可以使用OpenSSL或其他工具生成CSR和私钥。

  3. 提交CSR：将CSR提交给所选的证书颁发机构。他们将验证您的网站和组织信息。对于域名验证（DV）证书，您只需证明对域名的所有权；对于组织验证（OV）和扩展验证（EV）证书，您还需要提供公司和联系信息的证明。

  4. 验证域名所有权：证书颁发机构会要求您验证对申请证书的域名的所有权。通常有以下几种验证方法：

  • 通过DNS记录：在您的域名的DNS设置中添加一个特定的TXT记录。
  • 通过文件验证：在您的网站服务器上放置一个特定的文件，证书颁发机构将通过访问该文件进行验证。
  • 通过电子邮件验证：接收和回复证书颁发机构发送到域名注册联系人电子邮件中的验证代码。

  1. 领取证书：验证成功后，证书颁发机构将向您提供数字证书。通常，您会收到一个包含证书链的文件，其中包括您的服务器证书、中间证书和根证书。

  2. 安装证书：将证书文件安装到您的服务器上，并配置Web服务器以使用SSL/TLS。具体安装步骤因Web服务器类型（如Apache、Nginx、IIS等）而异。在安装过程中，请确保同时配置私钥和证书链。

  3. 测试证书：在安装证书后，使用浏览器或在线SSL检查工具测试您的网站以确保证书已正确安装。

请注意，证书的有效期通常为1-2年，因此您需要在证书过期前进行续期。有些证书颁发机构（如Let's Encrypt）提供自动续期功能，这可以简化维护过程。

标签：

· 阅读需 7 分钟
南哥

介绍​

An industry-standard container runtime with an emphasis on simplicity, robustness and portability

  • containerd 是什么？

在Containerd官网我们可以看到一个很简单明白的解析，一个工业级的容器运行时，着重于简单性，健壮性和可移植性；通俗点来说：如果你需要开发一个容器编排工具或者要简单地运行一个容器服务，有我就足够了

  • containerd 是如何诞生的？

Containerd是脱胎于Docker这个软件的，它的诞生也是由于Docker公司的商业模式一直处于摇摆。起初Docker的出现直接吊打了其他容器技术一家独大，连Google也幸免不了，于是Google想着联合一起退出一个容器运行时作为Docker的底层依赖，但Docker公司并不愿意合作。在此之后，Docker为了进一步扩大影响力将libcontainer捐赠给了（OCI，Open Container Intiative）。 以至于后面Google为了与之抗衡联合了几位行业巨头成立（CNCF，Cloud Native Computing Fundation）想着在底层玩不过就在编排层来抢占市场，后面就上演了前几年的Docker Swarm和Kubernetes之争，结局大家也知道Docker Swarm全面败北。 Docker公司并不甘心只当一个底层的容器运行时，于是花了大力气把自己的核心（Contaienrd）依赖剥离出来捐给了CNCF，只为了标榜自己是一个PaaS平台，这波骚操作让一众巨头们都看不懂。 当初让你一起玩你不玩，现在还捐出来了。 Kubernetes为了表示自己的中立性，故而直接搞了容器运行时标准化（CRI, Container Runtime Interface），后面为了继续突出Docker的重要性继而搞了各种shim来转换接口。其实研究过Containerd的同学们都知道，Containerd完全是可以独立运行容器的况且Kubernetes搞了CNI来应对容器的复杂网络需求。这样做只是为了等待Containerd羽翼丰满之时。 大家也知道Kubernetes 自v1.20后弃用Docker，总而言之Docker这个技术是成功的且开创了一个时代。

containerd 架构​

可以看到Containerd是一个C/S模式的，由containerd client通过containerd提供的GRPC接口进行操作。 Containerd是有不同总类的Plugin组成的如上图看到，Services层即Services Plugin类型，以此类推MetaData Plugin，Content Plugin， Snapshotter Plugin，Runtime Plugin。总之每一个核心模块就是会有一个或多个类型的Plugin组成，如果想知道更多containerd的源码分析可以留意后续推出的文章.

安装​

  • 下载
cd /usr/local/src
wget https://github.com/containerd/containerd/releases/download/v1.4.4/containerd-1.4.4-linux-amd64.tar.gz
tar xvf containerd-1.4.4-linux-amd64.tar.gz
cd containerd-1.4.4
copy -av bin/* /usr/local/bin/
  • 生成配置文件，配置文件可能看起来比较复杂，但暂时先不太关注，其实都是在配置plugin的参数，这些参数更多的需要跟着源码一起解析；
mkdir -p /etc/container
containerd config default > /etc/containerd/config.toml
  • 配置一个镜像加速地址，找到"docker.io" 把endpoint换一下
cat config.toml
...
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
          endpoint = ["https://dockerhub.mirrors.nwafu.edu.cn"]
...

  • 在config.toml文件中，有两个不同的存储路径，一个用来保存持久化数据，一个用来保存运行时状态。后面推出的文章聊到snapshotter, content等源码内容时再详细介绍。
root = "/var/lib/containerd"
state = "/run/containerd"
  • 启动containerd, 输入containerd即可
containerd 

ctr version
Client:
 Version:  v1.4.1
 Revision: c623d1b36f09f8ef6536a057bd658b3aa8632828
 Go version: go1.13.15

Server:
 Version:  v1.4.1
 Revision: c623d1b36f09f8ef6536a057bd658b3aa8632828
 UUID: 2539c5fb-cf92-4dd5-8d77-2f1c39e6959d

ctr 的使用​

-> ctr -h
COMMANDS:
  plugins, plugin            provides information about containerd plugins
  version                    print the client and server versions
  containers, c, container   manage containers
  content                    manage content
  events, event              display containerd events
  images, image, i           manage images
  leases                     manage leases
  namespaces, namespace, ns  manage namespaces
  pprof                      provide golang pprof outputs for containerd
  run                        run a container
  snapshots, snapshot        manage snapshots
  tasks, t, task             manage tasks
  install                    install a new package
  oci                        OCI tools
  shim                       interact with a shim directly
  help, h                    Shows a list of commands or help for one command

GLOBAL OPTIONS:
  --debug                      enable debug output in logs
  --address value, -a value    address for containerd's GRPC server (default: "/run/containerd/containerd.sock") [$CONTAINERD_ADDRESS]
  --timeout value              total timeout for ctr commands (default: 0s)
  --connect-timeout value      timeout for connecting to containerd (default: 0s)
  --namespace value, -n value  namespace to use with commands (default: "default") [$CONTAINERD_NAMESPACE]
  --help, -h                   show help
  --version, -v                print the version

从命令的子模块看来，containerd还是偏向于更专注容器的本身，比如网络模块就没见到身影，所以它更适合开发者或者说程序去使用它，而docker明显对人会更加的友好易用。

images​

-> ctr i -h
NAME:
  ctr images - manage images

USAGE:
  ctr images command [command options] [arguments...]

COMMANDS:
  check       check that an image has all content available locally
  export      export images
  import      import images
  list, ls    list images known to containerd
  mount       mount an image to a target path
  unmount     unmount the image from the target
  pull        pull an image from a remote
  push        push an image to a remote
  remove, rm  remove one or more images by reference
  tag         tag an image
  label       set and clear labels for an image

OPTIONS:
  --help, -h  show help

  • 可以看到很多和docker类似的命令, 下面先下载镜像
ctr i pull docker.io/library/nginx:alpine
  • 将镜像挂载到目录上
-> ctr i mount docker.io/library/nginx:alpine /mnt
-> tree /mnt
/mnt
├── bin
├── dev
├── docker-entrypoint.d
├── docker-entrypoint.sh
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var

  • 将镜像从目录上卸载
-> ctr i unmounnt /mnt
  • 创建容器
ctr c create docker.io/library/nginx:alpine nginx
  • 进入容器，暂停容器 省略

ps： 作者 shadowyd https://juejin.cn/post/6942502047119835143

· 阅读需 3 分钟
南哥

背景​

随着社会的进步，程序员的业余时间越来越多，这些时间被用来创造价值，整个社会“劳动业余价值”不断增长。业余价值往往发起于个人，当达到一定规模后部分转化为“劳动企业价值“，最终都会转化为”消费价值“。 服务业与社会生产力，经济成正比，经济越发达的国家制造业转移到国外，相对教育和服务业越发达，站在服务教育业的交汇处，是未来20年的长期风口

受众​

拥有创造力的人群，能够快速创造价值，例如程序员，硬件工程师，小说家, 这些人有个特点，容易接受新事物，容易形成小团体，具有较高文化水平，付费能力强

他们业余创造价值的过程和企业不同，表现在创造的多样性，周期变短，成本更低，团队更小等...

创造价值过程要素​

  • 积累

    我们提供更好的学习方式，沉静式学习，场景式学习，陪伴式学习，我们提供更强的资金支持，帮助你解决资源问题，没有后顾之忧

  • 合作

    我们提供更靠谱的合伙人，助力筛选人才

  • 推广

    我们提供流量，不同价值有不同的流量入口，我们提供一系列入口

  • 持续

    我们提供持续创造的环境，让你越做越大

产品形态​

  • 初期：手机端社交为主；web端主要是沉静式学习，助力价值的积累
  • 前期：手机端团体为主；web端主要是订阅式学习，积累平台原始资本
  • 中期：为创造价值助力，核心产品护城河和社区，引入行业顶尖人才
  • 后期：服务创造价值的整个生命周期，包括后续价值消费

名词解释​

  1. 劳动业余价值：劳动力在工作时间之外创造的价值
  2. 劳动企业价值：劳动力在企业创造的价值
  3. 消费价值：劳动力消费掉的价值

【写于2021年12月16日】

· 阅读需 10 分钟
南哥

argo-workflow介绍​

Argo Workflows是一个开源的容器化云原生工作流项目，其主要通过Kubernetes CRD实现的。

特点如下：

  • 工作流的每一步都是一个容器
  • 将多步骤工作流建模为一系列任务，或者使用有向无环图（DAG）描述任务之间的依赖关系
  • 可以在短时间内轻松运行用于机器学习或数据处理的计算密集型作业
  • 在Kubernetes上运行CI/CD Pipeline，无需复杂的软件配置

安装​

命令​

要安装 Argo Workflows，请导航至 Release 页面并找到您希望使用的版本（最好是最新的大版本）。

以下是安装命令的示例，请确保替换 ARGO_WORKFLOWS_VERSIO 变量以安装正确的版本号：

kubectl create namespace argo
kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v<<ARGO_WORKFLOWS_VERSION>>/install.yaml

安装好后我们可以使用 kubectl 命令查看 argo 命名空间下的服务，我们可以看到主要是2个服务，argo-server 用来接收前端请求，workflow-controller 用来执行 crd 控制器逻辑。

补丁 argo-server 认证​

argo-server（以及 UI）默认为客户端身份验证，这需要客户端提供其 Kubernetes 承载令牌才能进行身份验证。有关详细信息，请参阅 Argo 服务器身份验证模式文档。我们将身份验证模式切换为 server ，以便我们现在可以绕过 UI 登录：

kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

ui界面端口转发​

将ui端口转发到本地

kubectl -n argo port-forward deployment/argo-server 2746:2746 & open https://localhost:2746

我们可以看到argo-workflow的界面啦 ，默认会显示 argo 命名空间下的工作流任务列表。

提交一个最简单的工作流​

提交工作流​

让我们从创建一个非常简单的工作流模板开始，使用来自 Docker Hub 的 docker/whalesay 容器镜像来回应“hello world”

您可以使用简单的 docker 命令直接从 shell 运行它：

$ docker run docker/whalesay cowsay "hello world"
 _____________
< hello world >
 -------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/


Hello from Docker!
This message shows that your installation appears to be working correctly.

我们尝试让argo系统帮助我们运行这个容器，点击argo界面 +SUBMIT NEW WORKFLOW 按钮，将下面的yaml文件，提交到argo系统。

apiVersion: argoproj.io/v1alpha1
kind: Workflow                  # 自定义类型
metadata:
  generateName: hello-world-   
spec:
  entrypoint: whalesay          # 入口
  templates:
    - name: whalesay              # 模版名字
      container:
        image: docker/whalesay
        command: [ cowsay ]
        args: [ "hello world" ]
        resources: # limit the resources
          limits:
            memory: 32Mi
            cpu: 100m

查看工作流​

我们可以看到界面上多了个绿色的任务，点击右下角的Logs按钮，我们能查看容器中的日志，打印出了我们要的鲸鱼。

多步骤工作流​

如果我们想执行多个工作流，如何做呢？试试提交下下面的yaml文件吧！

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: steps-
spec:
  # 程序入口模版名字
  entrypoint: hello-hello-hello

  # 包含两个模版: hello-hello-hello and whalesay
  templates:
  - name: hello-hello-hello
    # 这个模版有好几个步骤，hello1 先执行
    steps:
    - - name: hello1            # hello1 先执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello1"
    - - name: hello2a           # 在hello1后执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello2a"
      - name: hello2b           # 与hello02a并发执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello2b"

  
  - name: whalesay
    inputs:
      parameters:
      - name: message
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["{{inputs.parameters.message}}"]

看图秒懂！我们创建了3个任务，hello2b 和 hello2a 在 hello1 任务之后并发执行。同时这三个任务接受的参数不同，打印的结果也不同哦！

4大模版​

argo-workflow 系统重定义的模版有4种类别，如下：

Container​

也许是最常见的模板类型，它会调度一个容器。模板的规范与 Kubernetes 容器规范相同，因此您可以像在 Kubernetes 中的其他任何地方一样在这里定义容器。

  - name: whalesay
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world"]

Script​

执行脚本，添加了 source: 字段，允许您就地定义脚本。该脚本将保存到一个文件中并为您执行。脚本的结果会自动导出到 变量 {{steps.<NAME>.outputs.result}} 中，你可以在下一阶段使用这个结果。

  - name: gen-random-int
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        import random
        i = random.randint(1, 100)
        print(i)

Resource​

直接对集群资源进行操作。它可用于获取、创建、应用、删除、替换或修补集群上的资源。此示例在集群上创建一个 ConfigMap 资源

  - name: k8s-owner-reference
    resource:
      action: create
      manifest: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          generateName: owned-eg-
        data:
          some: value

Suspend​

暂停模板将暂停工作流的执行，持续一段时间或直到手动恢复。用户可以使用 cli、API 接口或 UI点击操作来恢复暂停的工作流，让其继续执行。

  - name: delay
    suspend:
      duration: "20s"

2大流程控制​

Steps​

steps 模板允许您在一系列 steps 中定义您的任务。模板的结构是“列表的列表”。外部列表将按顺序运行，内部列表将并行运行。如果要逐一运行内部列表，请使用同步功能。您可以设置各种选项来控制执行，例如 when: 子句以有条件地执行步骤。 在此示例中， step1 首先运行。完成后， step2a 和 step2b 将并行运行：

  - name: hello-hello-hello
    steps:
    - - name: step1
        template: prepare-data
    - - name: step2a
        template: run-data-first-half
      - name: step2b
        template: run-data-second-half

Dag​

dag 模板允许您将任务定义为依赖关系图。在 DAG 中，您列出所有任务并设置在特定任务开始之前必须完成哪些其他任务。没有任何依赖关系的任务将立即运行。在此示例中， A 首先运行。一旦完成， B 和 C 将并行运行，一旦它们都完成， D 将运行：

  - name: diamond
    dag:
      tasks:
      - name: A
        template: echo
      - name: B
        dependencies: [A]
        template: echo
      - name: C
        dependencies: [A]
        template: echo
      - name: D
        dependencies: [B, C]
        template: echo

CI 示例​

一般将代码构建成镜像，有两种方式 ，一种是dind，一种是使用本地构建工具，比如 kaniko，buildkit等工具。这里我们展示如何使用argo-workflow 来构建镜像。

# in a workflow. The resource template type accepts any k8s manifest
# (including CRDs) and can perform any `kubectl` action against it (e.g. create,
# apply, delete, patch).
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: k8s-jobs-
spec:
  serviceAccountName: default
  entrypoint: pi-tmpl
  templates:
  - name: pi-tmpl
    resource:                   # indicates that this is a resource template
      action: create            # can be any kubectl action (e.g. create, delete, apply, patch)
      # The successCondition and failureCondition are optional expressions.
      # If failureCondition is true, the step is considered failed.
      # If successCondition is true, the step is considered successful.
      # They use kubernetes label selection syntax and can be applied against any field
      # of the resource (not just labels). Multiple AND conditions can be represented by comma
      # delimited expressions.
      # For more details: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
      successCondition: status.succeeded > 0
      failureCondition: status.failed > 3
      manifest: |               #put your kubernetes spec here
        apiVersion: v1
        kind: Pod
        metadata:
          generateName: kaniko-pod
        spec:
          containers:
            - name: kaniko
              image: gcr.io/kaniko-project/executor:debug
              args:
                - "--dockerfile=Dockerfile"
                - "--context=git://github.com/mouuii/golang-dockerfile.git#refs/heads/main"
                - "--destination=上传到镜像仓库地址"
              volumeMounts:
                - name: kaniko-secret
                  mountPath: "/kaniko/.docker"
              env:
                - name: GOOGLE_APPLICATION_CREDENTIALS
                  value: /secret/kaniko-secret.json
          restartPolicy: Never
          volumes:
            - name: kaniko-secret
              secret:
                secretName: dockersecret
                items:
                - key: .dockerconfigjson
                  path: config.json

我们使用argo-workflow简单创建一个镜像，传入 dockersecret 和代码仓库地址，执行后，会将我们的代码打包成镜像并上传到我们配置的镜像仓库地址，如果不熟悉，可以去百度下 kaniko。

个人感受​

概念太多，使用姿势太多，很多东西看的出都是功能的堆叠，并没有一个很好的兼容，上手成本比较高。

· 阅读需 7 分钟
南哥

工作流分类​

  1. 工艺产品流水线
  2. 团队协作流程
  3. 软件开发工作流
  4. 应用平台工作流

工艺产品流水线​

马斯克在2017年的一次财报会上说过："最难的产品不是车，而是制造车的工厂，发现像福特流水线那样的造车方式！"。事实上高度自动化的流水线是所有汽车制造工厂的核心引擎，能够大幅度提升造车产能同时降低成本，是企业的核心命脉！

团队协作流程​

在公司内部，我们日常使用的OA系统中，众多精致的工作流程支持着企业每日数万员工的请假、报销、入职等事务。

软件开发工作流​

在软件开发中，工作流是一个描述从项目开始到最终部署的一系列任务和步骤的过程。它涵盖了整个软件开发生命周期（SDLC），包括需求分析、设计、编码、测试和部署等阶段。工作流的目标是提高开发团队的协同效率，确保软件质量并降低错误风险。

CI/CD工作流​

CI/CD 工作流是指持续集成（Continuous Integration, CI）和持续交付/部署（Continuous Delivery/Deployment, CD）的过程。它是一种自动化软件开发实践，旨在加速软件的构建、测试和发布。CI/CD 工作流有助于提高开发团队的协作效率，降低错误风险，并确保软件质量。

CI/CD 工作流通常包括以下几个阶段：

  • 代码提交：开发人员将修改后的代码提交到版本控制系统（如 Git）。
  • 持续集成：自动检查新提交的代码，合并到主分支，并触发构建过程.
  • 构建：编译源代码，生成可执行文件，打包和准备部署。
  • 自动化测试：执行单元测试、集成测试和其他自动化测试，确保软件无缺陷。
  • 静态代码分析：检查代码质量和编码规范，提高代码可维护性。
  • 部署到预发布环境：将软件部署到类似生产环境的预发布环境，进行验证。
  • 持续交付：当软件通过所有测试和验证后，将其部署到生产环境的过程。在持续交付模式下，部署需要手动触发。
  • 持续部署：自动将通过所有测试和验证的软件部署到生产环境。这种模式下，部署是完全自动化的，无需人工干预。

CI/CD 工作流的实施通常依赖于专用的工具和平台，如 Jenkins、Travis CI、GitLab CI/CD 和 GitHub Actions 等。这些工具可以帮助团队轻松地自动化构建、测试和部署过程，实现快速、可靠的软件交付。

工作流能力​

在工作流系统中，提供一些常见功能以方便用户对工作流的操作和监控。这些功能使得团队可以更好地控制和管理整个工作流程，以应对各种不同的场景和需求。以下是一些常见的工作流能力：

  1. 暂停（Pause）：允许用户在需要的时候暂停工作流的执行。暂停功能可以在调试过程中，或者在需要检查或修改某些参数时使用。
  2. 恢复（Resume）：在暂停工作流后，恢复功能允许用户继续执行未完成的任务。恢复操作通常在解决了问题或调整了参数后进行。
  3. 取消（Cancel）：取消功能允许用户终止正在进行的工作流。这在遇到错误或需要中止整个流程时非常有用。
  4. 重试（Retry）：如果工作流中的某个任务失败，重试功能可以让用户尝试重新执行该任务。这在处理短暂的故障或网络问题时很有用。
  5. 回滚（Rollback）：回滚功能允许用户将工作流恢复到之前的稳定状态，以便快速解决问题或撤销错误的更改。
  6. 通知（Notification）：工作流系统可以向用户发送通知，提醒他们关于任务完成、失败或其他重要事件的信息。这有助于确保团队及时了解工作流状态并采取相应行动。
  7. 条件分支（Conditional Branching）：条件分支功能允许工作流根据特定条件执行不同的任务。这使得工作流能够灵活地处理不同场景和需求。
  8. 参数化（Parameterization）：通过参数化，用户可以在不修改工作流本身的情况下调整任务的输入和设置。这有助于实现更高程度的自定义和灵活性。

这些常见的工作流能力有助于团队更有效地管理和监控工作流程，提高生产力并降低错误发生的风险。

提示

工作流本质是控制