Введение​

Kusion Configuration Language (KCL) — это простой и удобный в использовании язык конфигурации, на котором пользователи могут просто написать повторно используемый код конфигурации.

В этой первой лабораторной работе мы узнаем, как написать простую конфигурацию с помощью KCL.

Изучение этого лабораторного кода требует только базовых знаний в области программирования, а опыт работы с Python сделает его еще проще.

В этой лаборатории кода мы узнаем, как совместно писать конфигурацию, используя функции работы с конфигурацией KCL.

Чему мы научимся

  1. Определите схемы и организуйте каталоги проектов.
  2. Создавайте несколько конфигураций среды с помощью функций работы с конфигурацией KCL.
  3. Настройте параметры компиляции и тесты.

2. Определите схемы и организуйте каталоги проектов

Определения схемы

Предположим, мы хотим определить конфигурацию сервера с определенными атрибутами, мы можем создать простую конфигурацию, создав server.k, мы можем заполнить следующий код, как показано ниже, который определяет повторно используемую схему конфигурации сервера.

import units

type Unit = units.NumberMultiplier

schema Server:
    replicas: int = 1
    image: str
    resource: Resource = {}
    mainContainer: Main = {}
    labels?: {str:str}
    annotations?: {str:str}

schema Main:
    name: str = "main"
    command?: [str]
    args?: [str]
    ports?: [Port]

schema Resource:
    cpu?: int = 1
    memory?: Unit = 1024Mi
    disk?: Unit = 10Gi

schema Port:
    name?: str
    protocol: "HTTP" | "TCP"
    port: 80 | 443
    targetPort: int
    check:
        targetPort > 1024, "targetPort must be larger than 1024"

В приведенном выше коде мы определяем схему с именем Server, которая представляет тип конфигурации, который будет писать пользователь, который содержит некоторые атрибуты базового типа (например, replicas, image и т. д.) и некоторые атрибуты составного типа (например, resource, main, и т. д). В дополнение к некоторым базовым типам, упомянутым в schema codelab, мы можем видеть два типа в приведенном выше коде Unit и units.NumberMultiplier. Среди них units.NumberMultiplier обозначает тип единицы номера KCL, что означает, что после номера KCL может быть добавлена ​​натуральная единица или двоичная единица, например 1K для 1000, 1Ki для 1024. Unit — это псевдоним типа units.NumberMultiplier, который используется для упрощения написания аннотаций типов.

Каталоги проектов

Чтобы завершить совместную разработку конфигурации, нам сначала нужен проект конфигурации, который содержит конфигурацию тестового приложения и дифференциальную конфигурацию различных сред, поэтому мы создаем следующий каталог проекта:

.
├── appops
│   └── test_app
│       ├── base
│       │   └── base.k
│       ├── dev
│       │   ├── ci-test
│       │   │   └── stdout.golden.yaml
│       │   ├── kcl.yaml
│       │   └── main.k
│       └── prod
│           ├── ci-test
│           │   └── stdout.golden.yaml
│           ├── kcl.yaml
│           └── main.k
├── kcl.mod
└── pkg
    └── sever.k

Каталог проекта в основном состоит из трех частей:

  • kcl.mod: файл, используемый для определения корневого каталога проекта KCL.
  • pkg: Server Структура схемы повторно используется в различных конфигурациях приложений.
  • appops: Серверные конфигурации различных приложений, в настоящее время размещено только одно приложение test_app.
  • base: Общие конфигурации приложения для всех сред.
  • dev: Конфигурация приложения для среды разработки.
  • prod: Конфигурация приложения для производственной среды.

Значение base.k, main.k, kcl.yaml и ci-test/stdout.golden.yaml будет упомянуто в последующих разделах.

3. Создайте несколько конфигураций среды с помощью функций работы с конфигурацией KCL

Создайте базовую конфигурацию

После того, как мы организовали каталог проекта и базовую модель конфигурации сервера, мы можем написать конфигурацию пользовательского приложения. Мы можем создать собственную папку тестового приложения test_app и поместить ее в папку конфигурации приложения appops.

Для настройки приложения мы часто делим его на базовую конфигурацию и дифференциальную конфигурацию нескольких сред и объединяем их. Благодаря функции слияния конфигураций KCL мы можем легко это сделать. Предполагая, что у нас есть две конфигурации среды разработки и производственной среды, мы можем создать три папки: base, dev и prod для хранения базовой конфигурации, среды разработки и конфигураций производственной среды соответственно. Сначала пишем конфигурацию base/base.k:

import pkg

server: pkg.Server {
    # Set the image with the value "nginx:1.14.2"
    image = "nginx:1.14.2"
    # Add a label app into labels
    labels.app = "test_app"
    # Add a mainContainer config, and its ports are [{protocol = "HTTP", port = 80, targetPort = 1100}]
    mainContainer.ports = [{
        protocol = "HTTP"
        port = 80
        targetPort = 1100
    }]
}

Как и в приведенном выше коде, мы используем ключевое слово import в base.k для импорта схемы Server, расположенной под pkg, и используем ее для создания экземпляра конфигурации с именем server, в которой мы устанавливаем для атрибута image значение "nginx:1.14.2" и добавляем метку app со значением test_app. . Кроме того, мы также добавили конфигурацию основного контейнера mainContainer со значением [{protocol = "HTTP", port = 80, targetPort = 1100}] для атрибута ports.

KCL-команда:

kcl appops/test_app/base/base.k

Выход:

server:
  replicas: 1
  image: nginx:1.14.2
  resource:
    cpu: 1
    memory: 1073741824
    disk: 10737418240
  mainContainer:
    name: main
    ports:
    - protocol: HTTP
      port: 80
      targetPort: 1100
  labels:
    app: test_app

На данный момент у нас есть базовая конфигурация.

Создание нескольких конфигураций среды

Затем мы настраиваем дифференцированную конфигурацию с несколькими средами. Сначала предположим, что мы хотим использовать временный образ нашего собственного nginx:1.14.2-dev в среде разработки, а затем использовать его для переопределения конфигурации сервера в базовой линии, мы можем написать следующую конфигурацию в dev/main.k:

import pkg

server: pkg.Server {
    # Override the image declared in the base
    image = "nginx:1.14.2-dev"
}

KCL-команда:

kcl appops/test_app/base/base.k appops/test_app/dev/main.k

Выход:

server:
  replicas: 1
  image: nginx:1.14.2-dev
  resource:
    cpu: 1
    memory: 1073741824
    disk: 10737418240
  mainContainer:
    name: main
    ports:
    - protocol: HTTP
      port: 80
      targetPort: 1100
  labels:
    app: test_app

Видно, что поле image выходного YAML перезаписывается на nginx:1.14.2-dev. Предположим, мы также хотим добавить метку в среду dev с ключом env и значением dev, мы добавляем следующий код в dev/main.k:

import pkg

server: pkg.Server {
    # Override the image declared in the base
    image = "nginx:1.14.2-dev"
    # Union a new label env into base labels
    labels.env = "dev"
}

KCL-команда:

kcl appops/test_app/base/base.k appops/test_app/dev/main.k
server:
  replicas: 1
  image: nginx:1.14.2-dev
  resource:
    cpu: 1
    memory: 1073741824
    disk: 10737418240
  mainContainer:
    name: main
    ports:
    - protocol: HTTP
      port: 80
      targetPort: 1100
  labels:
    app: test_app
    env: dev

Видно, что в поле labels выходного YAML есть две метки.

Кроме того, мы также можем использовать оператор += для добавления новых значений в атрибуты типа списка, такие как конфигурация mainContainer.ports в базовой среде, продолжайте изменять код в dev/main.k:

import pkg

server: pkg.Server {
    # Override the base image.
    image = "nginx:1.14.2-dev"
    # Union a new label env into base labels.
    labels.env = "dev"
    # Append a port into base ports.
    mainContainer.ports += [{
        protocol = "TCP"
        port = 443
        targetPort = 1100
    }]
}

KCL-команда:

kcl appops/test_app/base/base.k appops/test_app/dev/main.k

Выход:

server:
  replicas: 1
  image: nginx:1.14.2-dev
  resource:
    cpu: 1
    memory: 1073741824
    disk: 10737418240
  mainContainer:
    name: main
    ports:
    - protocol: HTTP
      port: 80
      targetPort: 1100
    - protocol: TCP
      port: 443
      targetPort: 1100
  labels:
    app: test_app
    env: dev

Используя тот же метод, мы можем построить производственную конфигурацию, записать код в файл dev/main.k и добавить к нему метку.

import pkg

server: pkg.Server {
    # Union a new label env into base labels
    labels.env = "prod"
}

KCL-команда:

kcl appops/test_app/base/base.k appops/test_app/prod/main.k

Выход:

server:
  replicas: 1
  image: nginx:1.14.2
  resource:
    cpu: 1
    memory: 1073741824
    disk: 10737418240
  mainContainer:
    name: main
    ports:
    - protocol: HTTP
      port: 80
      targetPort: 1100
  labels:
    app: test_app
    env: prod

4. Настройте параметры компиляции и тесты

В предыдущем разделе мы создали конфигурацию с несколькими средами с помощью кода. Видно, что параметры компиляции командной строки KCL для разных сред схожи, поэтому мы можем настроить эти параметры компиляции в файл и ввести их в командную строку KCL для вызова. Настройте следующий код в dev/kcl.yaml:

kcl_cli_configs:
  files:
    - ../base/base.k
    - main.k
  output: ./ci-test/stdout.golden.yaml

Затем мы можем скомпилировать конфигурацию в среде разработки с помощью следующей команды:

cd appops/test_app/dev && kcl -Y ./kcl.yaml

Кроме того, мы настроили поле output в dev/kcl.yaml для вывода YAML в файл для последующего распространения или тестирования конфигурации. Вы можете убедиться, что конфигурация приложения соответствует ожиданиям, просмотрев kcl.yaml сборок в каждой среде и сравнив их с ./ci-test/stdout.golden.yaml.

Дополнительные документы

Смотрите сообщество для способов присоединиться к нам.

Поставьте нам звездочку ⭐️ — Если вы используете KCL или считаете, что это интересный проект, мы будем рады звездочке на Github