CLI

Overview

Freight Forwarder CLI consumes the SDK and makes requests to a docker registry api and the docker client api. The CLI must be run in the same location as the configuration file (freight-forwarder.yml). Additional information regarding the configuration files can be found Config documentation.

For full usage information:

freight-forwarder --help

Note

Example Service Definition

1
2
3
4
5
6
7
api:
    build: "./"
    test: "./tests/"
    ports:
        - "8000:8000"
    links:
        - db

Info

class freight_forwarder.cli.info.InfoCommand(args)

Display metadata about Freight Forwarder and Python environment.

Options:
  • -h, --help (info) - Show the help message.

Example:

$ freight-forwarder info
Freight Forwarder: 1.0.0
docker-py: 1.3.1
Docker Api: 1.19
CPython version: 2.7.10
elapsed: 0 seconds
Returns:exit_code
Return type:int

Deploy

class freight_forwarder.cli.deploy.DeployCommand(args)

The deploy command pulls an image from a Docker registry, stops the previous running containers, creates and starts new containers, and cleans up the old containers and images on a docker host. If the new container fails to start, the previous container is restarted and the most recently created containers and image are removed.

Options:
  • -h, --help (info) - Show the help message
  • --data-center (required) - The data center to deploy. example: sea1, sea3, or us-east-1
  • --environment (required) - The environment to deploy. example: development, test, or production
  • --service (required) - The Service that will be built and exported.
  • --tag (optional) - The tag of a specific image to pull from a registry. example: sea3-development-latest
  • -e, --env (optional) - list of environment variables to create on the container will override existing. example: MYSQL_HOST=172.17.0.4
Returns:

exit_code
Return type:

integer

Export

class freight_forwarder.cli.export.ExportCommand(args)

The export command builds a “service” Docker image and pushes the image to a Docker registry. A service is a defined in the configuration file.

The export command requires a Registry to be defined in the configuration file or it will default to Docker Hub, private registries are supported.

The export command by default will build the container and its defined dependencies. This will start the targeted service container after it’s dependencies have been satisfied. If the container is successfully started it will push the image to the repository.

If test is set to true a test Dockerfile is required and should be defined in the configuration file. The test Dockerfile will be built and ran after the “service” Dockerfile. If the test Dockerfile fails the application will exit 1 without pushing the image to the registry.

The configs flag requires integration with CIA. For more information about CIA please to the documentation.

When the export command is executed with --no-validation it will perform the following actions.

  1. Build the defined Dockerfile or pull the image for the service.
  2. Inject a configuration if defined with credentials.
  3. Push the Image to the defined destination registry or the defined default, if no default is defined, it will attempt to push the image to Docker Hub.

To implement with a Continuous Integration solution (i.e. Jenkins, Travis, etc); please refer to below and use the -y option to not prompt for confirmation.

Options:
  • -h, --help (info) - Show the help message.
  • --data-center (required) - The data center to deploy. example: us-east-02, dal3, or us-east-01.
  • --environment (required) - The environment to deploy. example: development, test, or production.
  • --service (required) - The Service that will be built and exported.
  • --clean (optional) - Clean up anything that was created during current command execution.
  • --configs (optional) - Inject configuration files. Requires CIA integration.
  • --tag (optional) - Metadata to tag Docker images with.
  • --no-tagging-scheme (optional) - Turn off freight forwarders tagging scheme.
  • --test (optional) - Build and run test Dockerfile for validation before pushing image.
  • --use-cache (optional) - Allows use of cache when building images defaults to false.
  • --no-validation (optional) - The image will be built, NOT started and pushed to the registry.
  • -y (optional) - Disables the interactive confirmation with --no-validation.
Returns:

exit_code
Return type:

integer

Offload

class freight_forwarder.cli.offload.OffloadCommand(args)

The offload Command removes all containers and images related to the service provided.

Options:
  • -h, --help (info) - Show the help message.
  • --data-center (required) - The data center to deploy. example: sea1, sea3, or us-east-1
  • --environment (required) - The environment to deploy. example: development, test, or production
  • --service (required) - This service in which all containers and images will be removed.
Returns:

exit_code
Return type:

integer

Quality Control

class freight_forwarder.cli.quality_control.QualityControlCommand(args)

The quality-control command allows development teams to validate freight forwarder work flows without actually deploying or exporting.

Options:
  • -h, --help (info) - Show the help message
  • --data-center (required) - The data center to deploy. example: sea1, sea3, or us-east-1.
  • --environment (required) - The environment to deploy. example: development, test, or production.
  • --service (required) - The service that will be used for testing.
  • --attach (optional) - Attach to the service containers output.
  • --clean (optional) - Remove all images and containers after run.
  • -e, --env (optional) - list of environment variables to create on the container will override existing. example: MYSQL_HOST=172.17.0.4
  • --configs (optional) - Inject configuration files. Requires CIA integration.
  • --test (optional) - Run test Dockerfile must be provided in the configuration file.
  • --use-cache (optional) - Allows use of cache when building images defaults to false.
Returns:

exit_code
Return type:

integer

Test

class freight_forwarder.cli.test.TestCommand(args)

The test command allows developers to build and run their test docker file without interfering with their current running application containers. This command is designed to be ran periodically throughout a developers normal development cycle. Its a nice encapsulated way to run a projects test suite.

Warning

This command requires your service definition to have a test Dockerfile.

Options:
  • -h, --help (info) - Show the help message
  • --data-center (required) - The data center to deploy. example: sea1, sea3, or us-east-1
  • --environment (required) - The environment to deploy. example: development, test, or production
  • --service (required) - The service that will be used for testing.
  • --configs (optional) - Inject configuration files. Requires CIA integration.
Returns:

exit_code
Return type:

integer

Marshalling Yard

class freight_forwarder.cli.marshaling_yard.MarshalingYardCommand(args)

MarshalingYard interacts with a docker registry and provides information concerning the images and tags.

  • --alias (optional) - The registry alias defined in freight-forwarder config file. defaults: ‘default’.

One of the options is required

  • search Searches defined registry with keyword
  • tags Returns tag associated with value provided from the specified registry
Returns:exit_code
Return type:integer