The following specification is made using an example of YAML file, through which you can create a Pod with official WordPress and MySQL container images configured for the WordPress web-site comprehensive work. You can find YAML file in our github repository (https://github.com/cloudlinux/kuberdock_predefined_apps).
Note that you can use variables to set proper values for YAML file fields, transfer values from one field to another, generate value automatically and to show variables values in pre- and postDescription. For example:
To define field values use format:
$VAR_NAME|default:default_value|some text to show”
$VAR_NAME - variable name that can be used in other parts of YAML file;
default - this variable default value. If enter "autogen", then this value will be autogenerated (8 characters, lower case, letters and numbers). For cPanel use “user_domain_list”, to enter the domans and subdomains list for user to choose;
some text to show - title for a field specified by a user;
For pre-, postDescription and cPanel sections use %VAR_NAME% (between percent symbols). This will show $VAR_NAME value in pre- or postDescription.
To use a variable in some other part of YAML file use syntax $VAR_NAME$. This will return value of variable $VAR_NAME.
Note that you can use global variables in YAML. Their values can not be set. Use percent symbol (e.g. %PUBLIC_ADDRESS%) to show global variables values. Available global variables:
PUBLIC_ADDRESS - returns Public IP allocated to the pod;
USER_DOMAIN - returns main user domain in cPanel.
YAML File Description:
metadata - application name in cPanel and Pod name in KuberDock at the same time.
$APP_NAME|default:autogen|app name$ -
kuberdock section defines Pod parameters for KuberDock:
icon - link to application icon in .png;
packageID - optional, package ID in KuberDock database. If this parameter is not specified in YAML, then package_id value will equal 0 when started from KuberDock, or equal to value from Application defaults when started from cPanel.
preDescription - text to show user before application start, will be displayed on the page with plans;
postDescription - text to show user after application start. BBCode can be used to format text. Note that if you use YAML in cPanel then write [url]http://%APP_DOMAIN%[url] instead of [url]http://%PUBLIC_ADDRESS%[/url]. APP_DOMAIN must be equal to domain parameter in proxy section.
name - defines application name for user in cPanel web-interface.
appPackages - starts describing packages available for user to start predefined application; a bunch of resources allocated to a Pod and to containers in it. In one YAML can be 4 or less appPackages.
name - appPackage name. We recommend to use 3 or less words in the field (e.g. -S, -M, -XL, -XXL) because it is good for existing theme.
recommended - only one plan can be recommended, it will be highlighted in web-interface.
goodFor - short text to show to user.
publicIP - defines if Public IP is available for this appPackage. If container parameter for isPublic port in specification is "true", then publicIP should be "true" as well, to assign public IP. If publicIP value is "false", then public IP will not be assigned.
baseDomain - defines if pod will get service address based ob domain instead of public IP if any container port has parameter isPublic with value “true”. In case when domain user does not see the price for domain in the application package details. Note, that it is strongly recommended not to use publicIP and baseDomain in one appPackage.
packagePostDescription - use this description if you need to explain the difference between application usage in each package. For example, if you have not provide public IP in one of the packages, then postDescription for a whole YAML cannot be used.
pods - resources allocated to each pod.
name - name of the pod for which resources are allocated.
kubeType - Kube type ID in KuberDock database.
containers - describes Kubes number to be assigned to each container in YAML.
name - container name in container specification below.
kubes - number of Kubes for this container.
persistentDisks - persistent discs capacity.
name - persistent disk name.
pdSize - persistent disk size in GB. Note that in case of CEPH as a backend for persistent storage it is impossible to resize storage thus when customer will switch application package than persistent storage size will be the same for all packages which is equal to the current application package. In other case, it is possible to resize persistent storage if application package will have the same Kube Type as current application package.
proxy - sub-section is required for cPanel to do proxy to user domain. Not used in our original YAML for Wordpress application. This is just an example. You can set as many path as you need:
wordpress - path after domain, for example: http://domain.com/wordpress;
container - container image name used in YAML for which path will be used;
domain - show user domain list during predefined application setup to use with that path.
You can set paths for each container image in YAML.
spec section starts describing each YAML container specification.
In template subsection we need to have metadata, where name field must be the same variable as in name field of metadata section above. This is required for KuberDock system pod name.
spec subsection starts describing pod specification. We begin to describe persistent volumes that will be used in the pod:
name - this is a name of volume to be used in container.
persistentDisk - if this volume uses some of persistent storages (ceph for example).
pdName - name of persistent disk within persistent storage. We use $PD_RAND$ variable to autogenerate random part of name. That will give possibility to create different volumes names for each user.
restartPolicy field describe which restart policy will be used for this pod.
resolve field allows to resolve dns-name within a pod. This part is not used in YAML file for Wordpress application from our github repository. But, for example, Redmine needs to resolve dns-name mysql.
You can add more dns-names, separated by space.
containers field shows containers list within the pod.
name - name of a container within the pod.
image - container image name in DockerHub and a tag of image after “:”. You can find a tag in DockerHub registry in Tag tab on container image page. It is strongly recommended not to use tag latest, otherwise proper restore function of the application (pod) is not guaranteed, because latest means latest image at the current time,but latest image days or month ago can be different.
env - begins a list of environment variables of this container image “mysql:5”
name - environment variable name.
value - environment variable value.
Note that it is recommended to specify value in quotes. If value consists of digits only, then quotation marks are required (for example, “1234”). If you use variable in value parameter, then quotes are not required.
Note that to connect containers within the same pod you need to use IP 127.0.0.1 instead localhost.
ports field begins a list of ports to expose for this container image.
containerPort - ports number to be exposed.
protocol - protocol type for this port.
podPort - defines Pod port for this containerPort. Learn more about Pod port here. If podPort value is missing, it equals to containerPort by default.
isPublic - expose port to PublicIP. If you want to make this port available from the web, then this value must be "true".
If at least one PublicIP parameter in the whole YAML is "true", then Public IP will be assigned.
readinessProbe or livenessProbe (read more in official Kubernetes documentation) allows to add tests to check if application (pod) successfully launched with all its containers. It is available to add the following tests:
exec: executes a specified command inside the container expecting on success that the command exits with status code 0. Example:
Where “- cat” is the command and “- /tmp/health” is the parameter.
tcpSocket: performs a TCP check against the container’s IP address on a specified port expecting on success that the port is open.
Where “port” is a number of port to be tested.
httpGet: performs an HTTP Get against the container’s IP address on a specified port and path expecting on success that the response has a status code greater than or equal to 200 and less than 400.
- name: X-Custom-Header
Where “path” is the path for http request, “port” is the number of the port to be used, “httpHeader” name and value for request header.
Each probe will have one of three results:
Success: indicates that the container passed the diagnostic and status of pod becomes Running.
Failure: indicates that the container failed the diagnostic and status of the pod becomes Pending.
It is also possible to add conditions to the test:
initialDelaySeconds - number of seconds after the container has started before liveness probes are initiated.
timeoutSeconds - number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1.
periodSeconds - how often (in seconds) to perform the probe. Defaults to 10 seconds. Minimum value is 1.
successThreshold - minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Minimum value is 1.
failureThreshold - minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.
volumeMounts begins a list of container directories which will be mounted to persistent storage or persistent local storage. It depends on type of volumes above.
mountPath - mount path within the container.
name - name of persistent storage to be used (name parameter from volumes section).
Here we describe the next MySQL container image in the pod.