Skip to main content

Spec

Overview / Deploy Config / Spec



Some configurations require additional components

Some functions of the deployment configuration rely on the Nocalhost-Dep component. If you use Nocalhost Server, we will automatically install this component for you. Otherwise an additional installation is required.

If the Nocalhost-Dep component is not installed, some functions will be restricted. This article will mark those functions that need Nocalhost-Dep.

Startup dependency control (component dependency)#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
services:
- name: whatever
serviceType: deployment
dependLabelSelector:
pods:
- "name=mariadb"
- "app.kubernetes.io/name=example"
jobs:
- "job-name=init-job"

When a resource declares dependLabelSelector in the deployment configuration, the characters in the pods array represent the labels of the pods to be waited for. The format is key-value pairs. The characters in the jobs array represent the labels of the jods to be waited for. The format is also key-value pairs.

Both pods and jobs are optional. When you actually deploy your application, it will generate an initContainer for the specified workload, wait for the status of all pods matching the label to be Ready, and wait for the status of all jobs matching the label to be Succeeded.



Injecting Environment variable (Component dependency)#

Injecting Global variable#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
##### start
env:
- name: DEBUG
value: false
- name: DOMAIN
value: nocalhost.dev
envFrom:
envFile:
- path: relpath/to/env/file
##### end

Injecting global variables needs to be declared at the level of application. During the deployment, it will inject the corresponding environment variables into all deployed Deployment, DaemonSet, ReplicaSet, StatefulSet, Job, and CronJob.

Injecting variables supports two kinds syntax, which can be mixed
  • The first one is to declare key-value pairs directly
  • The second is to declare an env file relative to config.yaml, the content is line-by-line Key=Value:
DEBUG=true
DOMAIN=nocalhost.dev

The priority of env is higher than that of envFrom


Injecting variables at the level of container#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
services:
- name: whatever
serviceType: deployment
containers:
- name: your-container-name
install:
##### start
env:
- name: DEBUG
value: false
- name: DOMAIN
value: nocalhost.dev
envFrom:
envFile:
- path: relpath/to/env/file
##### end

The container-level variable injection is declared in application.services[*].containers[*].install, indicating that the corresponding variables are injected into the corresponding container during deployment. The rules of env and envFrom are in line with the application level's.



Automatic port forwarding after installation#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
services:
- name: whatever
serviceType: deployment
containers:
- name: your-container-name
install:
##### start
portForward:
- 5005:5005
- 3306:3306
##### end

The configuration rules are similar to the container and variable injection declarations, and need to be configured in application.services[*].containers[*].install.

The port forwarding after installation is as it's name implies. After the application is installed, it can automatically forward port to the local for some services. For instance, database, MQ and other commonly used services' ports are suitable for automatic forwarding and configuration rules after installation. The port forwarding rules are consistent with K8s, namely local port: container port.



Hook#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
##### start
onPreInstall:
- path: manifest/templates/pre-install/print-num-job-01.yaml
weight: "0"
- path: manifest/templates/hook/pre-install.yaml
weight: "1"
onPostInstall:
- path: manifest/templates/hook/post-install.yaml
weight: "1"
onPreUpgrade:
- path: manifest/templates/hook/pre-upgrade.yaml
weight: "1"
onPostUpgrade:
- path: manifest/templates/hook/post-upgrade.yaml
weight: "1"
onPreDelete:
- path: manifest/templates/hook/pre-delete.yaml
weight: "1"
onPostDelete:
- path: manifest/templates/hook/post-delete.yaml
weight: "1"
##### end

Nocalhost supports injecting various hooks in the life cycle of the application. Hooks currently only support Job, where path is the RawManifest relative to the home directory, which must be the job type. weight is the weight. The lower ones are executed first.


The limits on the Hook

Hook is similar to Helm's Hook. Hook itself is to make up for the shortcomings of non-Helm applications, so Helm-type applications cannot configure Hook (You can use Helm's Hook directly).


The explanation of Hook
  • onPreInstall occurs before the employment of the application, including performing some initialization operations such as clusters and databases. The deployment will start after the job status is Successed. If it fails, the installation will be terminated.
  • onPostInstall occurs after the application is deployed. When all resources are submitted to the K8s Api Server, this job will be executed. After the status is Successed, the deployment is successful. Otherwise, it will roll back and perform the uninstall operation.

By analogy, the Upgrade Hook and Delete Hook will not roll back after the execution fails, and only prompt failure.



The customization of the HelmValues#

Example:

application:
name: example
manifestType: rawManifestGit
resourcePath: [ "example" ]
##### start
helmValues:
- key: nocalhost.example
value: foo
- key: nocalhost.deploy.example
value: bar
helmVals:
nocalhost:
example: foo
deploy:
example: {{ Release.Name }}
##### end

HelmValues supports two kinds of syntax
  • The first syntax only supports pure strings and has a higher priority.
  • The second syntax is the same as values.yaml and can be interspersed with Helm syntax.
Last updated on by anurnomeru