FlexDeploy can be configured to automatically build and scan Docker images as part of your build workflow. In cases where you are running your container directly on a docker runtime you can automatically configure that here as well.
...
As of FlexDeploy 6.0.0.0 the way Containers are configured has changed completely. There is no longer specific pages for Docker and Kubernetes configurations on the project. Docker, Kubernetes and Helm plugins have now been updated to use project properties and plugin inputs putting them in line with other plugins. This makes configuration a bit less confusing, if you are already familiar with FlexDeploy concepts.
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.
...
Optionally, a path to Dockerfile can be provided. If it is empty, a default Dockerfile in a project source checkout folder is expected. If the checkout folder is empty, then a Dockerfile is expected in the root of the FD_TEMP_DIR. A Dockerfile must be present to build an image. This behavior changed slightly in 5.0.3 beta. Previously, the location was expected to be in FD_TEMP_DIR/FD_PROJECT_NAME.
| Info |
|---|
See the migration guide for steps on migrating. |
Image Settings/Build
Everything under the Image Settings section will be used during the build workflow of your Project. If Build Image is checked then FlexDeploy will automatically add the dockerBuildProjectImage operation of the FlexDeployDockerPlugin at the end of your workflow.
| Info |
|---|
If you wish to change the location of the dockerBuildProjectImage step in your workflow, you can manually add the step anywhere you wish and FlexDeploy will no longer automatically add it at the end. |
At the end of the build, the workflow execution will store a reference to the built Docker Image which is available on the Artifacts tab of the workflow execution screen.
The build instance must be a Docker host to use this feature, and the dockerBuildProjectImage operation of the FlexDeployDockerPlugin must be associated to the build instance. See Creating and Editing Instances for more information on how to add a plugin operation to an Instance.
...
Setting
...
Input Type
...
Description
...
Example
...
Image Name
...
Groovy
...
A Groovy Script that evaluates to the local image tag that should be built. This should include the full registry prefix, user repository, image name and tag.
docker.io can be omitted as a registry prefix as that is the default.
...
"joelwenzel/natours:"+ProjectVersion
"comp.azureio.registry/ourcompany/app:"+ProjectVersion
...
Registry Account
...
Selection
...
Specify a Registry Account (created in Topology->Integrations→Containers) you would like to push your image to.
Note that this is optional and can be set in Topology Overview Properties as well.
...
DockerIO
...
Build Image
...
Boolean
...
Should FlexDeploy automatically add the buildProjectImage workflow step?
...
true
...
Push Image
...
Boolean
...
After building the image should it be pushed to the specified Registry?
...
true
...
Tag Latest
...
Boolean
...
Should the image also be tagged with 'latest'?
...
true
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. The configuration here will always scan the locally built Docker image. If you want to analyze a remote image or publish results to an Anchore Engine application, you will need to modify your workflow with the appropriate Anchore Operations.
...
Setting
...
Input Type
...
Description
...
Example
...
Scan Image
...
Selection
...
No Scan - No scan will take place
...
Before Push - The built image will be scanned prior to pushing it to a registry
...
.
...
BEFORE_PUSH
...
Fail When
...
Groovy
...
See the Anchore
...
If the script should evaluate to true (I.E. a failure) then the image building process will halt and the workflow execution will fail.
...
STATUS == "fail"
...
Custom Policy Bundle
...
Plain Text
...
Anchore uses "policy bundles" to define analysis/scanning criteria. You can provide a custom bundle here defining your own scanning requirements.
You can reference an absolute path on your docker build server or a relative location in your source control for the image.
...
anchore/customPolicy.json
| Info |
|---|
Windows ScanningAt this time, inline(local) image scanning is not supported on windows. |
Pre-deploy Scanning
The configuration shown here executes the scan during the BUILD workflow. Another option can be to execute the scan plugin guide for configuration details.| Info |
|---|
Scans can also be executed as a Pre-deploy Workflow. This has the added benefit of creating approval tasks from the scan results. |
Container
...
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
...
Optional Groovy script of ports to expose. Separate entries by a comma.
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