FlexDeploy can be configured to automatically build and scan Docker images as a 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.
| Info | ||
|---|---|---|
| ||
For a full walkthrough of setting up a FlexDeploy Container Project deploying to Kubernetes via Helm, check out this Getting Started guide. |
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.
...
| Setting | Input Type | Description | Example |
|---|---|---|---|
| Scan Image | Selection |
| BEFORE_PUSH |
| Fail When | Groovy | An optional Groovy script to determine if the scan should fail. See the Anchore Plugin for a list of variables and sample scripts. 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 | ||
|---|---|---|
| ||
At this time, inline(local) image scanning is not supported on windows. |
| Info | ||
|---|---|---|
| ||
The configuration shown here executes the scan during the BUILD workflow. Another option can be to execute the scan as a Pre-deploy Workflow. This has the added benefit of creating approval tasks from the scan results. |
Container Settings/Deploy
...
| 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 | FD_TEMP_DIR+"C:/homedata/usermyapp/temp" or "C:/data/natours:/"+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 | "80(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 | ||
|---|---|---|
| ||
Note 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 | ||
|---|---|---|
| ||
If 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
FlexDeploy has the ability to retrieve the status of the container as well as view logs, start and stop. There are a couple of prerequisites in order to make use of this functionality.
...