...
Additionally a container blueprint has been created to make the process even simpler. It is highly recommended you use the container blueprint. For more information on blueprints check out the blueprints page.
| Info |
|---|
Anything previously configured in the Docker and Kubernetes tabs has been removed. If you’d like to reference your previous configuration please look inside of the <FlexDeployApplicationDirectory>/migration/6.0/container directory.See the migration guide for steps on migrating. |
Image Settings/Build
Image name (including repository) and image tag are now configurable as project properties. Several new variables have also become available with project properties, including the stream name, stream attributes, and project version. Most of the functionality previously available should be achievable with these additions. See the Docker plugin guide for details.
Container Settings/Deploy
After building the image there are 3 options to consider for deployment. Deploying via kubectl or Helm to a Kubernetes node. Or running the docker container directly. Check out the plugin guides for more info on how to use these:
Image Scanning
FlexDeploy supports local image scanning out of the box with the Anchore plugin. The only requirement is docker being installed on your build server. See the Anchore plugin guide for configuration details.
...
Windows Scanning
...
.
| Info |
|---|
Pre-deploy ScanningScans can also be executed as a Pre-deploy Workflow. This has the added benefit of creating approval tasks from the scan results. |
Container Settings/Deploy
After building the image there are 3 options to consider for deployment. Deploying via helm or standard kubectl to a Kubernetes node. Or running the docker container directly. The below configuration supports the latter approach to deploy and run a docker container directly using the image built during the build workflow.
Every setting here, apart from 'Run Container' is groovy script with ALL of the workflow execution properties available, though only a few of the commonly used are listed in the drop down.
...
Setting
...
Input Type
...
Description
...
Example
...
Run Container
...
Boolean
...
Should a container, using the built image and fields below, be started during the deploy workflow. Checking this as true will automatically add the 'deployProjectContainer' operation to your workflow as the first step.
...
true
...
Container Name
...
Groovy
...
Groovy script to determine what the started container name should be. Be sure to enclose literal strings in quotes.
...
"myapp-"+FD_ENVIRONMENT_CODE.toLowerCase()
...
Volumes
...
Groovy
...
Optional Groovy script of volumes to expose to the container. Separate entries by a comma.
hostPath:containerPath,hostPath:containerPath
...
"C:/data/myapp/"+FD_ENVIRONMENT_CODE.toLowerCase()+":/usr/src/app/data"
...
Ports
...
Groovy
...
. |
...
hostPort:containerPort,hostPort:containerPort
...
(FD_ENVIRONMENT_CODE == 'DEV' ? '80' : '89') + ":8099"
...
Additional Params
...
Groovy
...
Any additional parameters to the container, which will be added to the run command.
...
"--cidfile /test/file.cid -d -e MYVAR1"
| Info |
|---|
Empty WorkflowNote that because the deployProjectContainer is added to the workflow automatically, it is very well possible that your deploy workflow may be empty at design time. |
| Info |
|---|
Steps before deployProjectContainerIf you need to run steps prior to deploying the project container but still want to make use of the configuration above, simply add the deployProjectContainer operation anywhere in your workflow and FlexDeploy will forgo adding it automatically. |
Container Status/Monitoring
FlexDeploy no longer has the ability to monitor the status of containers as of Version FlexDeploy 6.0.0.0