title	description	position	category
Описание файла (YAML) стандарт	Стандарт описания файла (YAML) для Serverless Devs	3	Обзор

Стандарт описания файла (YAML)

Текущий документ следует модели пользователя Serverless и соответствующим стандартам.

Обзор описания файла
Формат/стандарт описания файла

Обзор описания файла

В режиме, отличном от cli, для выполнения операций с приложением и использования компонентов, необходимо предоставить соответствующее описание ресурсов/действий, которое должно соответствовать следующим условиям:

Расширение может быть .yaml или .yml
Формат должен соответствовать стандарту YAML

👉 Для проектов, которые требуют изоляции окружений с помощью описания файла, рекомендуется назвать файл в формате s-${ENV}.yaml или s-${ENV}.yml. Например: s-prod.yaml.

По умолчанию, инструменты разработки Serverless Devs предполагают, что имя описания файла будет s.yaml или s.yml, причём s.yaml имеет приоритет перед s.yml. Таким образом, если в одном приложении Serverless присутствуют оба файла s.yaml и s.yml, система будет использовать s.yaml.Конечно, разработчики могут указать конкретный файл с помощью параметра -t, --template [templatePath]. Например, если имя описания файла для приложения в среде production равно s-prod.yml, то при выполнении команд можно добавить параметр -t s-prod.yml или --template s-prod.yml.

Формат/стандарт описания файла

Основной формат описания ресурсов/действий, поддерживаемый Serverless Devs, выглядит следующим образом:

edition: 1.0.0          # Версия стандартного YAML, следует стандарту семантической версии (Semantic Versioning)
name: applicationName   # Имя приложения
access: xxx-account1    # Алиас ключа

vars: # [глобальные переменные, доступные для всех услуг]
  Key: Value

actions: globalActions # Глобальные пользовательские логики выполнения

services: # Может включать несколько услуг
  ServiceName: # Имя услуги
    access: xxx-account1      # Алиас ключа, если совпадает с access проекта, можно опустить
    component: componentName  # Имя компонента
    props: serviceProp        # Значения свойств компонента
    actions: serviceActions   # Глобальные пользовательские логики выполнения

Например, полный пример документа YAML может выглядеть следующим образом:

edition: 1.0.0        # Версия спецификации YAML для командной строки, использующая семантическую версию
name: FullStack       # Название проекта
access: xxx-account1  # Алиас ключа

vars: # [Глобальные переменные, доступные для всех служб]
  logo: https://image.aliyun.com/xxxx.png
```actions: # Пользовательские логики выполнения
  pre-deploy: # Выполняется перед развертыванием проекта
    - run: npm install # Команда для выполнения
      path: ./src # Путь выполнения команды
  success-deploy: # Выполняется после успешного развертывания проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 
  fail-deploy: # Выполняется после неудачного развертывания проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 
  complete-deploy: # Выполняется после завершения развертывания проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 

services:
  nextjs-portal: # Название службы
    access: xxx-account1  # Алиас ключа, если совпадает с ключом проекта, можно опустить
    component: vue-component  # Название компонента
    props: # Значения свойств компонента
      src: ./frontend_src
      url: url
    actions: # Пользовательские логики выполнения
      pre-deploy: # Выполняется перед развертыванием
        - run: s exec --publish  # Команда для выполнения
          path: ./backend_src # Путь выполнения команды
        - run: s build  # Команда для выполнения
          path: ./backend_src # Путь выполнения команды
      post-deploy: # Выполняется после развертывания
        - run: s clean
          path: ./frontend_src

  assets:
    component: static
    props:
      cache-control: "public, max-age=604800, immutable"
      www: "./public"

  express-blog:
    component: express
    props:
      app: ./express-blog
      url: ${vars.domain}
    actions:
      pre-deploy:
        - run: npm run build
          path: ./express-blog  gateway:
    component: serverless-gateway # Компонент маршрутизации: правила отображения HTTP URL на службы
    props:
      routes:
        - route: /~assets
          value: ${assets.output.url}
        - route: /
          value: ${nextjs-portal.output.url}
          index: index.html
        - route: /~portal
          value: ${nextjs-portal.output.url}
          inex: index.html
        - route: /~blog
          value: ${express-blog.output.url}

### Метаданные

В данном формате:

| Параметр | Описание |
| ---- | ---- |
| edition | Версия YAML-спецификации для командной строки, которая следует стандарту семантической версии (Semantic Versioning) |
| name | Название приложения |
| access | Алиас ключа, который можно использовать для ключей, настроенных с помощью команды [config](./command/config.md#config-add-команда) или [конфигурации ключей через переменные окружения](./command/config.md#конфигурация ключей через переменные окружений) |
| vars | Глобальные переменные, которые предоставляются для использования всеми службами в формате Key-Value |
| actions | Пользовательские логики выполнения |
| services | Службы, которые включены в приложение, представлены в формате Key-Value |

Описание параметров Service:| Параметр | Описание |
| ---- | ---- |
| access | Алиас ключа, который можно опустить, если он совпадает с алиасом проекта |
| component | Название компонента |
| actions | Пользовательские логики выполнения |
| props | Атрибуты компонента |### Присваивание переменных

YAML-файл, соответствующий модели Serverless Application, поддерживает несколько форматов переменных:

- Получение переменных окружения с текущего компьютера: `${env(переменная окружения)}`, например `${env(secretId)}`
- Получение переменных из внешнего документа: `${file(путь)}`, например `${file(./path)}`
- Получение глобальных переменных: `${vars.*}`
- Получение переменных из других проектов: `${projectName.props.*}`
- Получение переменных результатов из других проектов в YAML: `${projectName.output.*}`
- Получение переменных конфигурации: `${config(AccountID)}`
  Суть заключается в получении значений переменных из команды `s config get`
- Получение информации о текущем модуле: `${this.xx}`
  Например, в следующем YAML:

edition: 1.0.0 name: NextProject access: default-access

services: nextjs-portal: component: fc actions: pre-deploy: - run: s invoke ${this.props.url} path: ./backend_src props: codeUri: ./frontend_src url: url

В `nextjs-portal`:
  - `${this.name}` указывает на `nextjs-portal`
  - `${this.props.codeUri}` указывает на `./frontend_src`
  - `${this.access}` указывает на `default-access`

### Специальные переменные
В Serverless-Devs существуют специальные переменные с определенными назначениями, которые следует избегать использовать без особых причин:
- `${aliyun-cli}`
Используется в значении параметра `access`, чтобы получить [профиль по умолчанию](https://github.com/aliyun/aliyun-cli) из команды `aliyun configure list` и применить его.> Выполнение команды `aliyun configure list` позволяет просмотреть текущий активный профиль.### Порядок развертывания

Если в YAML-файле, соответствующем модели Serverless Application, присутствует слишком много служб, система по умолчанию анализирует порядок развертывания. Этот порядок развертывания состоит из двух шагов:

1. Анализ зависимости между компонентами проекта.
2. Службы с зависимостями развертываются в порядке их зависимости, а службы без зависимостей развертываются в порядке их расположения в YAML-файле.

### Описание действий

#### Глобальные действия

Основной формат глобальных действий:

```yaml
actions: # пользовательские глобальные логики выполнения
pre-команда: # выполняется перед выполнением команды deploy проекта
  - run: npm install # команда для выполнения
    path: ./src # путь выполнения команды
success-команда: # выполняется после успешного выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value 
fail-команда: # выполняется после неудачного выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value 
complete-команда: # выполняется после завершения выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value 
``````yaml
actions: # пользовательские глобальные логики выполнения
pre-deploy: # выполняется перед выполнением команды deploy проекта
  - run: npm install # команда для выполнения
    path: ./src # путь выполнения команды
success-deploy: # выполняется после успешного выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value 
fail-deploy: # выполняется после неудачного выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value 
complete-deploy: # выполняется после завершения выполнения команды deploy проекта
  - plugin: dingding-robot # используемый плагин
    args: # параметры плагина
      key: value

Когда Serverless Devs инструменты выполняют команды, перед выполнением команд проекта выполняются глобальные pre-deploy команды, после успешного выполнения команд проекта выполняются глобальные success-deploy команды, после неудачного выполнения команд проекта выполняются глобальные fail-deploy команды, после завершения выполнения команд проекта выполняются глобальные complete-deploy команды.

Пример YAML:```yaml edition: 1.0.0 # версия YAML-спецификации, следует стандарту семантической версии (Semantic Versioning) name: FullStack # имя проекта access: default # ключ доступа

  pre-deploy: # Выполняется перед деплоем проекта
    - run: npm install # Команда для выполнения
      path: ./src # Путь выполнения команды
  success-deploy: # Выполняется после успешного деплоя проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 
  fail-deploy: # Выполняется после неудачного деплоя проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 
  complete-deploy: # Выполняется после завершения деплоя проекта
    - plugin: dingding-robot # Используемый плагин
      args: # Параметры плагина
        key: value 
```services:
  nextjs-portal: # Имя сервиса
    component: vue-component  # Имя компонента
    props: # Значения свойств компонента
      src: ./frontend_src
      url: url

Когда разработчик выполняет команду deploy в текущем приложении, система будет выполнять действия в следующем порядке:

Выполняется глобальное действие pre-deploy: выполнение команды npm install в директории ./src
Вызывается метод deploy компонента vue-component, передаются свойства props и базовая информация о проекте в метод deploy компонента vue-component
Если шаг 2 выполнен успешно, выполняется глобальное действие success-deploy, если неудачно — fail-deploy. Независимо от результата, после завершения выполнения всегда выполняется глобальное действие complete-deploy.

Вышеуказанный порядок действует только при отсутствии ошибок в процессе. Если процесс завершается с ошибкой, система выдаст ошибку и прекратит выполнение последующих шагов.

Описание actions:

run: требует указания пути выполнения, представляет собой просто "хук", который выполняет команду (вызывает системную команду).
plugin: представляет собой легковесный плагин, каждый плагин обычно поддерживает только одну функцию.

Внимание: глобальные действия actions поддерживают только run и plugin.

Действия сервисаВ YAML-файле модели Serverless Application можно определить действия для сервиса, его базовый формат следующий:

actions: # Пользовательские действия для выполнения логики
  pre-command: # Выполняется перед командой
    - run: command  # Команда для выполнения
      path: ./path # Путь выполнения команды
    - component: pgo  # Компонент для выполнения, формат: имя_компонента команда параметры
    - plugin: website-fc  # Используемый плагин
      args: # Параметры плагина
        key: value 
  post-command: # Выполняется после команды
    - run: command  # Команда для выполнения
      path: ./path # Путь выполнения команды
    - component: pgo  # Компонент для выполнения, формат: имя_компонента команда параметры
    - plugin: website-fc  # Используемый плагин
      args: # Параметры плагина
        key: value

Пример:```yaml actions: # Пользовательские действия pre-deploy: # Выполняется перед деплоем - run: npm install # Команда для выполнения path: ./backend_src # Путь выполнения команды - component: fc build --use-docker # Команда для выполнения post-deploy: # Выполняется после деплоя - plugin: fc-warm args: corn: '********'


Когда инструменты разработки Serverless Devs выполняют этот сервис, они сначала выполняют пользовательские действия `pre-deploy` в указанном порядке, а затем выполняют действия `post-deploy` после завершения всех операций.

Вот пример YAML:

```yaml
edition: 1.0.0        # Версия YAML-спецификации, следуя стандарту семантической версии (Semantic Versioning)
name: FullStack       # Название проекта

services:
  nextjs-portal: # Название сервиса
    access: xxx-account1  # Алиас ключа доступа, если совпадает с ключом доступа проекта, можно опустить
    component: vue-component  # Название компонента
    props: # Значения свойств компонента
      src: ./frontend_src
      url: url
    actions: # Пользовательские действия
      pre-deploy: # Выполняется перед деплоем
        - run: npm install  # Команда для выполнения
          path: ./backend_src # Путь выполнения команды
        - component: fc build --use-docker  # Команда для выполнения
      post-deploy: # Выполняется после деплоя
        - plugin: fc-warm
          args:
            key: value 
```Когда разработчик выполняет команду `deploy` в текущем приложении, система выполняет следующие действия в указанном порядке:
1. Выполняет `npm install` в директории `./backend_src`
2. Для сервиса `nextjs-portal` использует метод `build` компонента `fc`, передавая параметр `--use-docker` (то есть, выполняет сборку сервиса `nextjs-portal` в контейнере Docker)
3. Вызывает метод `deploy` компонента `vue-component`, передавая свойства `props` и базовую информацию о проекте
4. Передает результаты деплоя и другие данные в плагин `fc-warm`, передавая параметры `{"corn": "********"}`Этот порядок действует только при отсутствии ошибок в процессе. Если возникают ошибки, система выдает сообщение об ошибке и прекращает выполнение последующих действий. Определение и различия между `run`, `component` и `plugin` в `actions`:
 - `run` требует указания рабочей директории и представляет собой только возможность запуска `hook` (то есть просто выполнение команды системы).
 - `component` используется в формате `имя_компонента команда параметры` и передает текущую информацию о ключах, атрибутах и других параметрах проекта в методы заданного компонента.
 - `plugin` представляет собой легковесное расширение, которое обычно поддерживает только один функционал. Основное отличие от `component` заключается в возможности изменения атрибутов. Например, если пользователь настроил `props` таким образом, что `codeUri: ./code`:
     - После использования `component` текущая информация (`codeUri: ./code`) останется параметром выполнения проекта и не изменится.
     - После использования `plugin` текущая информация (`codeUri: ./code`) может измениться, и изменённые параметры будут использоваться для выполнения проекта. Примеры для трех случаев:
 - Если Yaml выглядит так:
     ```yaml
     edition: 1.0.0        # Версия спецификации YAML для командной строки, которая следует стандарту семантической версии (Semantic Versioning)
     name: FullStack       # Название проекта
     services:
       nextjs-portal: # Название сервиса
         component: test-component  # Название компонента
     ```        props: # Значения свойств компонента
           src: . /frontend_src
           url: url 
     ```
     После выполнения команды `s deploy -a mytest` система передаст ключ `mytest` и параметры `props` (`{"src": ". /frontend_src", "url": "url"}`) методу `deploy` компонента `test-component`.- Если Yaml выглядит так:
    ```yaml
    edition: 1.0.0        # Версия спецификации YAML для командной строки, которая следует стандарту семантической версии (Semantic Versioning)
    name: FullStack       # Название проекта
    
    services:
      nextjs-portal: # Название сервиса
        component: test-component  # Название компонента
        actions: # Пользовательские действия
          pre-deploy: # Выполняется перед деплоем
            - run: s build
              path: ./
        props: # Значения свойств компонента
          src: ./frontend_src
          url: url 
    ```
    После выполнения команды `s deploy -a mytest` система выполнит:
    - Команду `s build` в директории `./`, при этом параметр `-a mytest` не передается методу `s build`, можно считать, что это просто выполнение команды без передачи состояния;
    - Передаст ключ `mytest` и параметры `props` (`{"src": "./frontend_src", "url": "url"}`) методу `deploy` компонента `test-component`.- Если Yaml выглядит так:
    ```yaml
    edition: 1.0.0        # Версия YAML-спецификации для командной строки, следует стандарту семантической версии (Semantic Versioning)
    name: FullStack       # Название проекта
    
    services:
      nextjs-portal: # Название сервиса
        component: test-component  # Название компонента
        actions: # Пользовательские действия
          pre-deploy: # Выполняется перед деплоем
            - component: fc build
        props: # Значения свойств компонента
          src: ./frontend_src
          url: url 
    ```
    После выполнения команды `s deploy -a mytest` система выполнит:
    - Передаст ключ `mytest` и параметры `props` (`{"src": "./frontend_src", "url": "url"}`) методу `build` компонента `fc`;
    - Передаст ключ `mytest` и параметры `props` (`{"src": "./frontend_src", "url": "url"}`) методу `deploy` компонента `test-component`.```yaml
edition: 1.0.0        # Версия YAML-спецификации для командной строки, следует стандарту семантической версии (Semantic Versioning)
name: FullStack       # Название проекта
```services:
  nextjs-portal: # Название сервиса
    component: test-component  # Название компонента
    actions: # Пользовательские действия
      pre-deploy: # Выполняется перед деплоем
        - plugin: qbuild
          args:
            key: value
    props: # Параметры компонента
      src: ./frontend_src
      url: url

При выполнении команды s deploy -a mytest система будет:

Передавать ключ mytest, параметры props ({"src": "./frontend_src", "url": "url"}) и параметры plugin ({"key": "value"}) плагину qbuild. После завершения обработки плагином qbuild:
- Если возвращаемая информация включает изменения параметров props, то ключ mytest и изменённые параметры props передаются методу deploy компонента test-component.
- Если возвращаемая информация не включает изменений параметров props, то ключ mytest и исходные параметры props передаются методу deploy компонента test-component.

Как можно一键部署整个应用？或者只部署应用中的某个Service？可以参考自定义命令使用指南

Шаблонные действия

Глобальные действия и действия сервиса поддерживают шаблонные переменные. Инструмент распознает магические переменные regex для регулярного соответствия текущего метода выполнения. Например, глобальное pre-${regex(.)} означает, что действие pre будет выполнено перед выполнением любого метода проекта.

Как можно однокнопочным способом развернуть весь проект? Или развернуть только определённый сервис? См. руководство по использованию пользовательских команд```yaml actions: # Глобальные пользовательские действия pre-${regex(.)}: # Выполняется перед выполнением любого метода проекта - run: npm install # Команда для выполнения path: ./src # Путь выполнения команды success-${regex(.)}: # Выполняется после успешного выполнения любого метода проекта - plugin: dingding-robot # Используемый плагин args: # Параметры плагина key: value fail-${regex(.)}: # Выполняется после неудачного выполнения любого метода проекта - plugin: dingding-robot # Используемый плагин args: # Параметры плагина key: value complete-${regex(.)}: # Выполняется после завершения выполнения любого метода проекта - plugin: dingding-robot # Используемый плагин args: # Параметры плагина key: value

OSCHINA-MIRROR/serverless-devs-Serverless-Devs

Стандарт описания файла (YAML)

Обзор описания файла

Формат/стандарт описания файла

Действия сервисаВ YAML-файле модели Serverless Application можно определить действия для сервиса, его базовый формат следующий:

Шаблонные действия

Опубликовать ( 0 )

Введение

Обновления (98)

Участники

Язык

Недавние действия

OSCHINA-MIRROR/serverless-devs-Serverless-Devs .gitee-modal { min-width: 500px !important; } .gitee-modal .close { right: 0.6rem !important; }

Стандарт описания файла (YAML)

Обзор описания файла

Формат/стандарт описания файла

Действия сервисаВ YAML-файле модели Serverless Application можно определить действия для сервиса, его базовый формат следующий:

Шаблонные действия

Опубликовать ( 0 )

Введение

Обновления (98)

Участники

Язык

Недавние действия

OSCHINA-MIRROR/serverless-devs-Serverless-Devs