...

...

A plugin can be implemented as a Docker image (instead of Java implementation). In this case the "plugin.jar" file contains plugin.xml file only. The Docker image should be stored in a Docker repository accessible from an endpoint (Docker host or Kubernetes cluster) executing the plugin. The full name of the image including repository should be specified in ImageName element of plugin.xml file.

...

While executing a plugin operation on a Docker host, FlexDeploy runs the following command on the target endpoint:

docker run -rm --env-file env.list --name STEP_NAME_WF_EXEC_ID  -v ${FD_WORKING_DIR}:/fd_working_dir FULL_IMAGE_NAME:PLUGIN_VERSION FD_PLUGIN_OPERATION_TARGET

While executing a plugin operation on a Kubernetes cluster, FlexDeploy runs the following commands

kubectl create -f pod.json
kubectl cp ${FD_WORKING_DIR} ${INTERNAL_POD_NAME}:/fd_working_dir
kubectl exec -it ${INTERNAL_POD_NAME} -- ${FD_PLUGIN_OPERATION_TARGET}
kubectl cp ${INTERNAL_POD_NAME}:/fd_working_dir ${FD_WORKING_DIR}
kubectl delete pod ${INTERNAL_POD_NAME}

Note that images utilizing an entrypoint will not have their entrypoints called by the Kubernetes framework.  This is to allow time for the working directory to be copied before execution starts.  

FlexDeploy passes into the Docker container or K8 Pod values of the following environment variables (through env.list filefor docker) or (pod.json for K8):

• FD_WORKING_DIR
• FD_ARTIFACTS_DIR
• FD_TEMP_DIR
• FD_INTERNAL_DIR
• FD_TEST_RESULTS_DIR
• FD_OBJECT_RESULTS_DIR
• FD_TRANSFER_DIR
• FD_ENVIRONMENT_CODE
• FD_ENVIRONMENT_NAME
• FD_INSTANCE_CODE
• FD_INSTANCE_NAME
• FD_PROJECT_NAME
• FD_PLUGIN_INSTALL_DIR
• FD_ENDPOINT_NAME
• FD_ENDPOINT_ADDRESS
• FD_PLUGIN
• FD_PLUGIN_OPERATION
• FD_RESULT_FILE_NAME
• All plugin operation inputs 
• All properties (by Name from metadata) for current project and environment instance

...

Once the plugin operation finishes its execution, the corresponding Docker container or Kubernetes POD will be removed.

Best Practices

...