Введение
Kusion Configuration Language (KCL) — это простой и удобный в использовании язык конфигурации, на котором пользователи могут просто написать повторно используемый код конфигурации.
В этой первой лабораторной работе мы узнаем, как написать простую конфигурацию с помощью KCL.
Изучение этого лабораторного кода требует только базовых знаний в области программирования, а опыт работы с Python сделает его еще проще.
В этой лаборатории кода мы узнаем, как совместно писать конфигурацию, используя функции работы с конфигурацией KCL.
Чему мы научимся
- Определите схемы и организуйте каталоги проектов.
- Создавайте несколько конфигураций среды с помощью функций работы с конфигурацией KCL.
- Настройте параметры компиляции и тесты.
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 Repo: https://github.com/KusionStack/KCLVM
- Kusion Github Repo: https://github.com/KusionStack/
- Сайт KCL: https://kcl-lang.io/
- Конфигурация и автоматизация в KCL: https://medium.com/dev-genius/configuration-automation-in-kcl-f355732d9f20
- Определение схемы в KCL: https://medium.com/@xpf6677/schema-definition-in-the-kcl-programming-language-9dfc7867f8ea
Смотрите сообщество для способов присоединиться к нам.
Поставьте нам звездочку ⭐️ — Если вы используете KCL или считаете, что это интересный проект, мы будем рады звездочке на Github