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.
component dependency)#Startup dependency control (
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.
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
Component dependency)#Injecting Environment variable (
#Injecting Global variable
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
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
The priority of
env is higher than that of
#Injecting variables at the level of container
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
envFrom are in line with the application level's.
#Automatic port forwarding after installation
The configuration rules are similar to the container and variable injection declarations, and need to be configured in
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.
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
onPreInstalloccurs 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.
onPostInstalloccurs 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
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.yamland can be interspersed with Helm syntax.