服務規範是用於指定服務部署的資料結構。以下是 YAML 中的服務規範示例：

service_type: rgw
service_id: realm.zone
placement:
  hosts:
    - host1
    - host2
    - host3
unmanaged: false
networks:
- 192.169.142.0/24
spec:
  # Additional service specific attributes. -- 附加服務特定屬性

在此示例中，此服務規範的屬性是：

類 ceph.deployment.service_spec.ServiceSpec（service_type， service_id = None， placement = None， count = None， config = None， unmanaged = False， preview_only = False， networks = None， extra_container_args = None）

服務建立的詳細資訊。

向編排器請求一組守護程序，例如 MDS、RGW、iscsi 閘道器、MON、MGR、Prometheus。

這個結構應該是足夠的資訊來啟動服務。

networks: List[str] -- 指示守護程式僅繫結在該列表中的特定網路上的網路身份列表。如果叢集分佈在多個網路中，您可以新增多個網路。請參閱網路和埠、 指定網路和指定網路。

placement: ceph.deployment.service_spec.PlacementSpec -- 請參閱守護程式放置。

service_id -- 服務的名稱。iscsi, mds, nfs, osd, rgw, container，需要ingress。

service_type -- 服務的型別。需要是 Ceph 服務（mon、crash、mds、osd或 rbd-mirror） mgr、閘道器（nfs或rgw） 、監控堆疊的一部分（alertmanager 、grafana 、node-exporter或 prometheus ）或（container）用於自定義容器。 

unmanaged -- 如果設定為true，編排器將不會部署或刪除與此服務關聯的任何守護程式。放置和所有其他屬性將被忽略。如果您不希望臨時管理此服務，這很有用。對於 cephadm，請參閱禁用守護程式的自動部署。
 

每種服務型別都可以具有其他特定於服務的屬性。

mon型別，mgr和監控型別的服務規範不需要service_id。

高階 OSD 服務規範中描述了osd服務型別。

通過ceph orch apply -i提交多文件 YAML 檔案，可以一次應用許多服務規範：

cat <<EOF | ceph orch apply -i -
service_type: mon
placement:
  host_pattern: "mon*"
---
service_type: mgr
placement:
  host_pattern: "mgr*"
---
service_type: osd
service_id: default_drive_group
placement:
  host_pattern: "osd*"
data_devices:
  all: true
EOF
 

檢索正在執行的服務規範

如果服務是通過 ceph orch apply... 啟動的，那麼直接更改服務規範會很複雜。我們建議不要嘗試直接更改服務規範，而是按照以下說明匯出正在執行的服務規範：

ceph orch ls --service-name rgw.<realm>.<zone> --export > rgw.<realm>.<zone>.yaml
ceph orch ls --service-type mgr --export > mgr.yaml
ceph orch ls --export > cluster.yaml

然後可以如上所述更改和重新應用規範。

更新服務規範

Ceph Orchestrator 在 ServiceSpec 中維護每個服務的宣告狀態。對於某些操作，例如更新 RGW HTTP 埠，我們需要更新現有規範。

列出當前ServiceSpec：

ceph orch ls --service_name=<service-name> --export > myservice.yaml

更新 yaml 檔案：

vi myservice.yaml

應用新的ServiceSpec：

ceph orch apply -i myservice.yaml [--dry-run]