4、自动化部署基础：CI/CD概念、Ansible基础、Docker基础、Kubernetes基础

各位，咱们进入第四章。这一章我把它叫做「地基工程」。你想想看，OPC UA 安全更新要是全靠手动，那跟用螺丝刀拧航母铆钉没啥区别。自动化部署就是把这些重复劳动交给工具，咱们只做决策和监控。

我个人习惯，学任何自动化工具之前，先搞清楚它解决什么问题。别一上来就敲命令，那是搬砖思维。咱们先看整体脉络，再逐个击破。

4.1 CI/CD 概念：从手动到自动的思维转变

CI/CD 全称持续集成/持续部署。说白了，就是让代码从提交到上线，全程自动化。我见过太多团队，开发写完代码，扔给运维，运维手动部署，出问题了互相甩锅。CI/CD 就是打破这堵墙的锤子。

持续集成（CI）：每次代码提交，自动触发构建、测试、静态分析。确保新代码不会搞坏现有功能。

持续部署（CD）：通过自动化测试的代码，自动部署到目标环境。注意，不是「一键部署」，是「零键部署」—— 代码合并到主分支，剩下的交给流水线。

CI/CD 的核心组件就这几样：

• 版本控制：Git，这是所有自动化的起点
• 构建服务器：Jenkins、GitLab CI、GitHub Actions
• 制品仓库：存放编译好的二进制或镜像，比如 Docker Registry
• 部署目标：测试环境、预发布环境、生产环境

4.2 Ansible 基础：无代理的配置管理利器

Ansible 是我个人最喜欢的配置管理工具。为什么？因为它不需要在目标机器上装 Agent。你想想看，工业现场有成百上千台 OPC UA 服务器，每台都装 Agent？那维护成本谁受得了。

Ansible 通过 SSH 连接目标机器，执行任务。它的配置叫 Playbook，用 YAML 写，人类可读性极强。

一个简单的 Ansible Playbook 长这样：

---
- name: 更新 OPC UA 服务器证书
  hosts: opcua_servers
  tasks:
    - name: 停止 OPC UA 服务
      systemd:
        name: opcua-server
        state: stopped

    - name: 复制新证书
      copy:
        src: /path/to/new_cert.pem
        dest: /etc/opcua/certs/server_cert.pem
        owner: opcua
        group: opcua
        mode: '0600'

    - name: 启动 OPC UA 服务
      systemd:
        name: opcua-server
        state: started

看到了吗？三个任务：停服务、换证书、启服务。这就是 Ansible 的威力 —— 把运维操作写成代码，可重复、可审计、可版本控制。

Ansible 的几个核心概念：

概念	说明	类比
Inventory	管理的主机列表	通讯录
Playbook	任务剧本，YAML 格式	操作手册
Task	单个操作步骤	一个动作
Module	执行具体功能的插件	工具箱里的工具
Role	可复用的 Playbook 集合	标准作业包

4.3 Docker 基础：让应用和环境一起打包

「在我机器上能跑啊！」—— 这句话是不是很耳熟？Docker 就是来解决这个问题的。它把应用和所有依赖（库、配置文件、环境变量）打包成一个镜像，走到哪跑到哪。

对于 OPC UA 安全更新，Docker 的价值特别明显。你想想，证书更新、安全策略变更、依赖库升级，这些操作如果直接在宿主机上搞，很容易污染环境。用 Docker，更新失败？删掉容器，重新拉一个镜像，几秒钟恢复。

一个 Dockerfile 示例：

FROM ubuntu:22.04

# 安装 OPC UA SDK 依赖
RUN apt-get update && apt-get install -y \
    libssl-dev \
    libmbedtls-dev \
    cmake \
    g++

# 复制 OPC UA 服务器源码
COPY ./opcua-server /app

# 编译
WORKDIR /app
RUN cmake . && make

# 暴露端口
EXPOSE 4840

# 启动命令
CMD ["./opcua-server"]

Docker 的核心操作就这几个：

• docker build：构建镜像
• docker pull/push：拉取/推送镜像到仓库
• docker run：启动容器
• docker stop/rm：停止/删除容器
• docker exec：进入运行中的容器执行命令

4.4 Kubernetes 基础：容器编排的工业级方案

Docker 解决了「怎么跑」的问题，Kubernetes（K8s）解决的是「跑在哪、跑几个、挂了怎么办」的问题。你想想，一个 OPC UA 服务器集群，可能有几十个节点，手动管理？不现实。

Kubernetes 的核心概念：

概念	说明	OPC UA 场景
Pod	最小部署单元，包含一个或多个容器	一个 Pod 跑一个 OPC UA 服务器实例
Deployment	管理 Pod 的副本数和滚动更新	安全更新时，逐个替换 Pod，零停机
Service	提供稳定的网络访问入口	客户端通过 Service 访问 OPC UA 服务器
ConfigMap/Secret	管理配置和敏感信息	存储证书、安全策略、连接字符串
Namespace	逻辑隔离资源	不同产线用不同 Namespace 隔离

一个简单的 Deployment YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-server
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: opcua-server
  template:
    metadata:
      labels:
        app: opcua-server
    spec:
      containers:
      - name: opcua
        image: registry.internal/opcua-server:2.1.0
        ports:
        - containerPort: 4840
        volumeMounts:
        - name: certs
          mountPath: /etc/opcua/certs
          readOnly: true
      volumes:
      - name: certs
        secret:
          secretName: opcua-tls-certs

4.5 四者如何协同工作

咱们把这四个东西串起来，看看 OPC UA 安全更新的完整自动化流程：

1. 开发提交代码：更新证书管理逻辑或安全策略
2. CI 流水线触发：自动编译、跑单元测试、安全扫描
3. 构建 Docker 镜像：打上版本标签，推送到私有仓库
4. Ansible 更新 K8s 配置：更新 ConfigMap 或 Secret 中的证书
5. Kubernetes 滚动更新：逐个替换 Pod，确保服务不中断
6. 验证：自动检查 OPC UA 连接是否正常，证书是否生效

这个流程跑通了，一次安全更新从小时级降到分钟级。而且全程可追溯，谁改了啥、啥时候改的，一目了然。