開放應用模型操做指南（一）| 雲服務一鍵接入 OAM 體系

做者 | 鄧洪超  阿里雲容器平臺軟件工程師

導讀： Open Application Model（OAM）是阿里雲聯合微軟等國際頂級技術團隊聯合發佈的開放應用模型技術。旨在經過全新的應用定義、運維、分發與交付模型，推進應用管理技術向「輕運維」的方向邁進，全力開啓下一代雲原生 DevOps 的技術革命。本《開放應用模型操做指南》系列文章，將爲廣大技術人員（研發、運維、基礎設施工程師）提供接地氣的、體系化的 OAM 操做和接入指南。

前言

自 OAM 標準推出以來，愈來愈多的平臺和服務開始接入 OAM 標準，朝着 BaaS (Backend as a service) 化的方向邁進。在阿里巴巴集團，咱們見證了 EDAS、內部中間件交付平臺等以 OAM 的方式打造和推出應用交付和運維產品。而且，ROS、PolarDB 等以開放的姿態逐步接入 OAM 做爲跨平臺集成方案。

隨着跟終端用戶和平臺提供方的交流日益增多，咱們也同時更加清楚地瞭解到在 OAM 集成各個平臺和服務的時候仍是有一些不一致、不標準的地方。舉些例子，DB 等資源建立起來後鏈接信息該如何暴露，已有的資源定義該如何模型化成 OAM，什麼應該做爲 Workload？什麼應該做爲 Trait 等等。這些問題在不一樣團隊的解決方式是相似卻有些許差別的，不只形成重複勞做，實踐經驗也缺少進一步沉澱。

咱們但願用戶去使用和接入 OAM，可以有一個統一的、清晰的流程和架構。這就是本文嘗試去闡述問題、提供解法的地方。

什麼人適合讀這篇文章？

這篇文章主要面向服務集成方，他們但願本身的服務可以經過 OAM 去被使用。這包括：

• 服務提供方。好比監控服務 ARMS、日誌服務 SLS、分佈式追蹤服務等；
• 平臺提供方。好比 EDAS、中間件交付平臺、ROS、DBaaS 等，一個平臺每每包含不少服務。

用 OAM 描述雲資源/服務

若是你有一個服務，怎樣才能以雲原生的方式暴露呢？答案就是在 Kubernetes 上提供該服務。而 OAM，正是幫助你們更好地在 K8s 上描述服務能力、實現擴平臺集成的一種標準。

1. 歸類 OAM 類型

首先，服務的能力須要歸類爲 OAM 類型中的某一種。這裏有三種類型：

類型	定義	例子
Workload	能單獨跑起來、單獨使用的服務須要定義的類型。	DB (MySQL)、MQ (Kafka)、Cache (Redis)、Service Mesh
Trait	跟運維相關的服務須要定義的類型。	Ingress、Monitoring、Logging、服務發現、灰度發佈
Scope	囊括一組服務組件的邊界。目前僅適用少數場景。	網絡邊界 (VPC、Firewall、Gateway)、健康邊界 (互相關聯的組件的總體健康檢測)

服務提供方須要將己方服務歸類爲上述一種。這樣可以在平臺上清楚地表達本身的目的，更好地被集成和使用。

2. 編寫 OAM 定義

咱們一般在把一個服務歸類爲一種 OAM 類型以後，就會去編寫這個服務的 OAM 定義。這包括兩部分：

• 編寫 OAM 定義裏面的通用元數據；
• 編寫服務自定義的 API。

服務自定義的 API 是用來描述服務對外提供的能力的 API。在這方面，咱們選擇使用 JSON Schema 來做爲 API 描述語言，由於它是一種開放、標準的方式，在工程領域爲你們所熟知。

下面，咱們就分別以 Workload 和 Trait 爲例，結合註釋來詳解如何去編寫服務的 OAM 定義。

OAM Workload 例子

apiVersion: oam.dev/v1alpha1
kind: WorkloadType
metadata:
  name: rds
spec:
  group: alibaba.io/v1
  names: [RDS]
  # 下面用 JSON schema 描述服務能力
  settings: |
    {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "storageType"
      ],
      "properties": {
        "storageType": {
          "type": "string",
          "description": "The type of storage for RDS instance"
        }
      }
    }

OAM Trait 例子

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: ManualScaler
  annotations:
    version: v1.0.0
    description: "Allow operators to manually scale a workloads that allow multiple replicas."
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.Server
    - core.oam.dev/v1alpha1.Worker
    - core.oam.dev/v1alpha1.Task
  # 下面用 JSON schema 描述運維能力
  properties: |
    {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "replicaCount"
      ],
      "properties": {
        "replicaCount": {
          "type": "integer",
          "description": "the target number of replicas to scale a component to.",
          "minimum": 0
        }
      }
    }

3. 實現 OAM Operator

在定義了 OAM API 以後，咱們還須要有實現層能讓這個 spec 「跑」起來。這裏咱們推薦實現 K8s Operator 來做爲這個 OAM API 的服務。Operator 具體細節有不少文章介紹，這裏再也不贅述。

阿里巴巴雲原生應用團隊實現並開源了 OAM framework（oam-go-sdk）來幫助你們簡化【構建 API + 實現 Operator】。

你們若是在實現 OAM Operator 過程當中有什麼問題，歡迎聯繫咱們。能夠在上游提 issue 或者釘釘發消息。

服務的暴露與消費

OAM 能給你們帶來的一個重要好處就是可以橫向聯通不一樣平臺之間的服務能力。這裏咱們介紹下如何實現。

在集成服務的時候，一般要作兩件事情：

• 服務提供方須要暴露服務信息，好比 DB 鏈接信息寫到 CMDB；
• 服務信息須要提供給用戶應用去消費，好比將 DB 鏈接信息自動注入到（消費者）應用的環境變量。

當前現狀是，OAM 對接的項目每每都有本身的一套系統暴露和消費服務的方式。下面咱們舉些例子：

• Service Broker 將服務信息寫入到 CRD 實例狀態中，而後經過工做流讀取並寫入應用環境變量；
• ROS 在 DB 模板執行完後有 outputs 屬性包含服務信息，而後做爲用戶應用模板的參數入參；
• CrossPlane 在多家雲廠商上提供統一的 MySQL Resource 定義，而後經過將 connection 信息寫入 secret 並掛載到用戶應用文件系統裏。

除了上面的例子，咱們還有不少其餘或大或小的服務暴露與消費的例子。如今這裏有一個問題，那就是不一樣的項目之間，沒有統一的服務暴露與消費方式，致使不一樣的平臺之間沒法互通。在這裏，咱們但願定義一個統一的接口，讓不一樣平臺不一樣服務在接入 OAM 之後可以互通，更簡單地透出服務能力賦能雲用戶。

解決思路

針對上述問題，咱們接下來描述下解決思路：

• OAM Runtime 解析 AppConfig，發現一個 Component (微服務應用) 須要消費另外一個 Component (雲服務) 。因而 Runtime 須要安排好 Component 之間的建立順序；
• 首先，OAM Runtime 建立雲服務 Workload Component，並將相應的服務信息暴露到一個 spec 指定名字的 secret 裏面去；
• 而後，OAM Runtime 建立微服務應用 Component，並將 spec 聲明的消費內容經過名字相關聯，並將 secret（經過 env、file 等方式）注入到應用中去。

總體架構圖以下：

示例

下面咱們經過舉例來講明整個過程。

經過 CrossPlane 建立一個 CloudSQL Component:

apiVersion: oam.dev/v1alpha1
kind: Component
metadata:
  name: mysql
spec:
  workloadType: database.cloud.io/v1beta1.CloudSQL
  expose:
    name: mysql-connection 
  ... # 其餘一些參數輸入

上面咱們看到 expose 字段聲明瞭暴露信息的名字，這樣作是爲了讓消費者能關聯。具體如何暴露與消費服務信息，則是由 Runtime 層來實現。在這裏，建立完 MySQL Workload 實例以後，MySQL 鏈接信息會被寫入到一個  mysql-connection secret 裏面去。

另外一個應用 Web Component 則以下面定義所示來消費 MySQL：

apiVersion: oam.dev/v1alpha1
kind: Component
metadata:
  name: web
spec:
  workloadType: Server
  consume:
  - name: mysql-connection
    as: env # 注入到環境變量當中。也能夠設置爲 file，則會注入到本地文件當中

總結

在這篇文章裏，咱們主要針對雲服務提供方講了如何用 OAM 描述服務能力、定義和實現相應的 OAM Runtime、以及如何經過 OAM 集成不一樣平臺的服務。

目前，OAM 還處於一個早期階段，阿里巴巴團隊正在上游貢獻和維護這套技術，但願這篇文章能給你們對於 OAM 以及如何接入雲服務有更多的瞭解。若是你們有什麼問題或者反饋，也很是歡迎跟咱們在上游或者釘釘聯繫。

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論羣

• 經過 Gitter 直接參與討論：https://gitter.im/oam-dev/

期待你們的參與！

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」