Loading

從 ”以應用為中心“ 的交付看DevOps平臺的演進趨勢

引子-從傳統的安裝包到云原生時代的應用

過去，在傳統的通過shell命令行部署的時代，開發者們習慣于按照面向過程的方式一步步通過代碼編譯構建打包，然后把安裝包遠程部署到環境上，安裝包就是安裝包，環境就是環境，部署腳本就是部署腳本。

隨著k8s云原生和DevOps的普及，一種新的實踐形式“應用” 脫穎而出，它的具體表現是通過一組聲明式資源配置（Deployment、Service、ConfigMap 等）定義的容器化服務，可伸縮，可觀測，通過GitOps直接從“代碼”到“可運行的服務”。

在持續交付中，“應用”是最終要交付給用戶的功能性實體，可以是單體應用（Monolithic Application）、云原生應用（Cloud-Native Application）、移動應用，這些僅僅是技術架構層面的解釋，那么對于研發生命周期而言，應用又會帶來什么不同的價值呢？

本篇文章將帶大家從“研發生命周期”和“DevOps平臺建設”的角度，詮釋“應用新的含義”。

以“應用為中心”-建立“管理過程”和“研發過程”的紐帶

如下圖，這是一個很典型的產品版本需求迭代，到部署發布的簡單示意圖。

接著下面的圖，當代碼提交入庫，觸發Pipeline，最終形成一個可部署運行的應用服務。

這里我們思考幾個問題

1. 從“產品（需求）” 到“服務應用”之間是什么關系？前者是業務，后者是技術，從業務到技術實現如何表達？
2. 將”一個市場需求“，快速的實現并且上線，需要多少個步驟？需要幾個代碼庫的變更？涉及哪幾個安裝包/鏡像？又有幾個流水線需要編排？
3. 在復雜且冗長的工具鏈編排中，如何精準的定位追溯每一次變更，快速的試錯和回滾？

看到這里，可能你會習以為常，我們平時就是這樣做的，有什么問題？

從“面向過程”到“面向對象”，用“聲明方式”描述“產品骨架”

如下圖，和上面的圖進行對比，是不是有點“面向對象”的感覺？

對照上面的圖，再看看下面的術語解釋，仔細琢磨下

1. 產品：提供用戶價值（即組織發布活動）的獨立單元，是由獨立的產、研、測共同維護的功能和服務的集合。
2. 應用：對應一個可獨立運行、發布的線上服務叫做應用，是軟件交付和運維的最小單元。應用對應某一個代碼庫，對應部署發布的應用。
3. 版本：版本是產品的基礎屬性，產品每一次發布（可能涉及多個開發團隊多個應用），產生該產品（系列需求）的一個新版本（結果）。新版本制作過程包含產研全生命周期。

云原生應用

基于上面的圖，AI幫忙編寫了對應的配置聲明，幫助大家理解（片段有點長，可以快速跳過）

# ================================================
# 應用部署模板 - Kubernetes 云原生服務編排示例
# 對應架構圖左側「代碼庫」「制品/鏡像」「配置信息」與右側「部署環境」
# ================================================

---
# 部署環境定義（對應架構圖右側「dev/uat/prod」）
# 使用命名空間隔離不同環境（此處以prod為例）
apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    env: production

---
# ------------------------------------------------
# 核心部署配置（對應架構圖左側「制品/鏡像」+「配置信息」）
# ------------------------------------------------

# 配置信息（ConfigMap對應架構圖左側「配置信息」模塊）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: prod  # 綁定prod環境命名空間
data:
  app.properties: |
    # 應用運行時配置
    db.host=mysql.prod.svc.cluster.local
    cache.enabled=true
    log.level=INFO

---
# 敏感信息配置（Secret屬于特殊類型的配置信息）
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: prod
type: Opaque
data:
  username: YWRtaW4=  # admin base64編碼
  password: cGFzc3dvcmQxMjM=  # password123 base64編碼

---
# ------------------------------------------------
# 服務編排核心定義（對應架構圖下方「服務編排(云原生)」模塊）
# ------------------------------------------------

# 部署控制器（Deployment實現滾動更新策略）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment  # 部署版本標識
  namespace: prod
  labels:
    app: myapp
    track: stable  # 部署策略標識
spec:
  replicas: 3  # 初始副本數
  strategy:
    type: RollingUpdate  # 部署策略-滾動更新
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        env: prod
    spec:
      containers:
      - name: app-container
        image: registry.example.com/myapp:v1.2.3  # 制品/鏡像（來自CI/CD流水線構建）
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: db.host
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: username
        resources:
          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        livenessProbe:  # 健康檢查（可觀測性）
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

---
# 服務暴露（Service實現服務發現）
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: prod
spec:
  type: ClusterIP  # 生產環境建議使用LoadBalancer
  selector:
    app: myapp
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP

---
# ------------------------------------------------
# 彈性伸縮策略（對應架構圖「部署策略」模塊）
# ------------------------------------------------
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

# ================================================
# 部署執行說明：
# 1. 代碼庫變更觸發CI/CD流水線構建鏡像（更新image版本）
# 2. 通過kubectl apply -f 應用部署模板文件.yaml
# 3. 監控部署狀態：kubectl -n prod get pods,svc,hpa
# ================================================

傳統主機部署應用

上面說的是k8s應用，那么傳統安裝包主機部署呢？怎么通過應用表達？

通過 YAML 定義主機環境、應用包版本和全局配置（對應圖中「制品/鏡像」「配置信息」模塊）

# File: infrastructure.yaml
# 定義主機環境、應用包版本等基礎設施信息
environments:
  - name: dev
    hosts:
      - ip: 192.168.1.101
        user: dev-user
        deploy_dir: /opt/apps/dev
    app_version: 1.0.0-SNAPSHOT

  - name: prod
    hosts:
      - ip: 192.168.1.200
        user: prod-admin
        deploy_dir: /opt/apps/prod
    app_version: 1.0.0-RELEASE

# 全局配置模板（與環境解耦）
global_config:
  app_name: "my-spring-boot-app"
  java_opts: "-Xmx512m -Xms256m"
  health_check_url: "/actuator/health"

每個環境（dev/prod）獨立維護敏感配置（對應圖中「配置信息」與「部署環境」分離）

# File: config/prod.env
# 生產環境數據庫配置（敏感信息單獨管理）
DB_HOST=mysql.prod.internal
DB_PORT=3306
DB_USER=admin
DB_PASSWORD=encrypted_password_here  # 建議使用加密工具（如Ansible Vault）

# File: config/dev.env
# 開發環境數據庫配置
DB_HOST=localhost
DB_PORT=3306
DB_USER=dev
DB_PASSWORD=dev123

通過 Shell 腳本實現自動化部署（對應圖中「部署腳本」模塊）

#!/bin/bash
# File: deploy.sh
# 參數化部署：指定環境（dev/prod）和應用包路徑
ENV=$1
APP_PACKAGE=$2

# 加載基礎設施定義
INFRA_FILE="infrastructure.yaml"
APP_NAME=$(yq eval '.global_config.app_name' $INFRA_FILE)
DEPLOY_DIR=$(yq eval ".environments[] | select(.name == \"$ENV\").hosts[0].deploy_dir" $INFRA_FILE)
REMOTE_USER=$(yq eval ".environments[] | select(.name == \"$ENV\").hosts[0].user" $INFRA_FILE)
REMOTE_IP=$(yq eval ".environments[] | select(.name == \"$ENV\").hosts[0].ip" $INFRA_FILE)

# 加載環境配置
CONFIG_FILE="config/$ENV.env"
source $CONFIG_FILE

# 生成動態應用配置（模板化）
cat > application.properties <<EOF
# Auto-generated configuration for $ENV
spring.datasource.url=jdbc:mysql://${DB_HOST}:${DB_PORT}/${APP_NAME}_${ENV}
spring.datasource.username=${DB_USER}
spring.datasource.password=${DB_PASSWORD}
server.port=8080
EOF

# 執行部署動作
echo "Deploying $APP_NAME ($ENV) to $REMOTE_IP..."
ssh $REMOTE_USER@$REMOTE_IP "mkdir -p $DEPLOY_DIR && systemctl stop $APP_NAME"
scp $APP_PACKAGE $REMOTE_USER@$REMOTE_IP:$DEPLOY_DIR/
scp application.properties $REMOTE_USER@$REMOTE_IP:$DEPLOY_DIR/config/

# 啟動服務（假設已配置systemd服務單元）
ssh $REMOTE_USER@$REMOTE_IP "\
  chmod +x $DEPLOY_DIR/$(basename $APP_PACKAGE) && \
  systemctl daemon-reload && \
  systemctl start $APP_NAME && \
  systemctl status $APP_NAME"

通過模板定義應用服務管理（對應「基礎設施即代碼」）

# File: templates/my-spring-boot-app.service.j2
# Systemd 服務單元模板（由部署腳本動態生成）
[Unit]
Description={{ global_config.app_name }} ({{ env }})
After=network.target

[Service]
User={{ user }}
WorkingDirectory={{ deploy_dir }}
ExecStart=/usr/bin/java {{ global_config.java_opts }} -jar {{ deploy_dir }}/{{ app_package }}
EnvironmentFile={{ deploy_dir }}/config/application.properties
Restart=always

[Install]
WantedBy=multi-user.target

根據環境參數執行相同腳本部署不同的包

# 部署到生產環境
./deploy.sh prod my-app-1.0.0-RELEASE.jar

# 部署到開發環境
./deploy.sh dev my-app-1.0.0-SNAPSHOT.jar

從“應用為中心“看DevOps平臺演進的趨勢

通過上面對于”應用“在研發生命周期的橋梁作用，再到具體的技術實踐，作為DevOps平臺或者體系的搭建者，我總結了以下幾點趨勢：

1. 越來越多的平臺開始通過“應用”來進行“構建編排流程的封裝”，從“面向過程”到“面向對象”，通過更簡單的聲明，屏蔽底層工具和步驟的復雜性，幫助產品更快交付。

2. DevOps平臺的建設從開始的“工具統一”到代碼“工程化統一”（應用），最終會向到“研發流程標準化”演進，將更多的研發規范，最佳實踐等標準化要求變成“企業的研發模版”。開發者只用專注于業務代碼本身，規范和要求在潛移默化中被遵守。
3. 對于持續交付而言，逐步的從”面向過程“（1.0-腳本編排）到”面向對象“（2.0-應用配置聲明），再到 ”面向業務流程“ （3.0-研發標準流程模版化），這個是必然趨勢。特別是在AI時代，更快的代碼交付，對于工程化，基礎設施，標準規范的快速切實執行提出了更高的要求。

本文使用文章同步助手同步

posted @ 2025-07-03 23:29 DevOps在路上閱讀(72) 評論(0) 收藏舉報

刷新頁面返回頂部