Application definition language¶
There is a description of current syntax of application definition framework.
Application definition template¶
service:
name: service-name
kind: DaemonSet
ports:
- internal-port:external-port
headless: true
hostNetwork: true
hostPID: true
antiAffinity: local
annotations:
pod:
description: frontend ports
service:
description: frontend service
containers:
- name: container-name
image: container-image
probes:
readiness: readiness.sh
liveness: liveness.sh
volumes:
- name: volume-name
type: host
path: /path
pre:
- name: service-bootstrap
dependencies:
- some-service
- some-other-service
type: single
image: some_image
command: /tmp/bootstrap.sh
files:
- bootstrap.sh
user: user
- name: db-sync
dependencies:
- some-dep
command: some command
user: user
daemon:
dependencies:
- demon-dep
command: daemon.sh
files:
- config.conf
user: user
post:
- name: post-command
dependencies:
- some-service
- some-other-service
type: single
command: post.sh
files:
- config.conf
files:
config.conf:
path: /etc/service/config.conf
content: config.conf.j2
perm: "0600"
user: user
bootstrap.sh:
path: /tmp/bootstrap.sh
content: bootstrap.sh.j2
perm: "0755"
Parameters description¶
service¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
name | Name of the service. | true | string | – |
kind | Kind of k8s object to use for containers deployment. | false | one of: [“Deployment”, “DaemonSet”, “StatefulSet”] | Deployment |
containers | List of containers under multi-container pod. | true | container array | – |
ports | k8s Service will be created if specified (with NodePort type for now). Only internal or both internal:external ports can be specified. | false | internal-port: external-port array | – |
hostNetwork | Use the host’s network namespace. | false | boolean | false |
headless | Create headless service. | false | boolean | false |
hostPID | Use the host’s pid namespace. | false | boolean | false |
strategy | The strategy that should be used to replace old Pods by new ones. | false | one of: [“RollingUpdate”, “Recreate”] | RollingUpdate |
antiAffinity | Restrict scheduling of pods on the same host: local - within namespace, global - within k8s cluster | false | one of: [null, “global”, “local”] | null |
annotations | pod - annotations for pods, service - annotations for service. | false | string dict | null |
container¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
name | Name of the container. It will be used to track status in etcd. | true | string | – |
image | Name of the image. registry, namespace, tag will be added by framework. | true | string | – |
probes | Readiness, liveness or both checks can be defined. Exec action will be used for both checks. | false | dict with two keys:
|
– |
volumes | – | false | volume array | – |
pre | List of commands that need to be executed before daemon process start. | false | command array | – |
daemon | – | true | command | – |
post | The same as for “pre” except that post commands will be executed after daemon process has been started. | false | command array | – |
env | An array of environment variables defined in kubernetes way. | false | env array | – |
volume¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
name | Name of the volume. | true | string | – |
type | host and empty-dir type supported for now. | true | one of: [“host”, “empty-dir”] | – |
path | Host path that should be mounted (only if type = “host”). | false | string | – |
mount-path | Mount path in container. | false | string | path |
readOnly | Mount mode of the volume. | false | bool | False |
command¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
name | Name of the command. Required only for pre and post with type single. | string | ||
image | Image that will be used to run the command. Can be used only for pre and post with type single. | false | string | same as for daemon |
command | – | true | string | – |
dependencies | These keys will be polled from etcd before commands execution. | false | string array | – |
type | type: single means that this command should be executed once per openstack deployment. For commands with type: single Job object will be created. type: local (or if type is not specified) means that command will be executed inside the same container as a daemon process. |
false | one of: [“single”, “local”] | local |
files | List of the files that maps to the keys of files dict. It defines which files will be rendered inside a container. | false | file keys array | – |
user | – | false | string | – |
files¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
Name of the file to refer in files list of commands | – | false | file array | – |
file¶
Name | Description | Required | Schema | Default |
---|---|---|---|---|
path | Destination path inside a container. | true | string | – |
content | Name of the file under {{ service_repo }}/service/files directory. This file will be rendered inside a container and moved to the destination defined with path. | true | string | – |
perm | – | false | string | – |
user | – | false | string | – |
DSL versioning¶
Some changes in CCP framework are backward compatible and some of them are not. To prevent situations when service definitions are being processed by incompatible version of CCP framework, DSL versioning has been implemented.
DSL versioning is based on Semantic Versioning model. Version has a format
MAJOR.MINOR.PATCH
and is being defined in dsl_version
field of
fuel_ccp/__init__.py
module. Each service definition contains
dsl_version
field with the version of DSL it was implemented/updated for.
During the validation phase of ccp deploy those versions will be compared according to the following rules:
- if DSL version of
fuel-ccp
is less than service’s DSL version - they are incompatible - error will be printed, deployment will be aborted; - if
MAJOR
parts of these versions are different - they are incompatible - error will be printed, deployment will be aborted; - otherwise they are compatible and deployment can be continued.
For dsl_version
in fuel-ccp
repository you should increment:
- MAJOR version when you make incompatible changes in DSL;
- MINOR version when you make backward-compatible changes in DSL;
- PATCH version when you make fixes that do not change DSL, but affect processing flow.
If you made a change in service definition that is not supposed to work with
the current `dsl_version`
, you should bump it to the minimal appropriate
number.