Concepts

A set of components that are developed together to serve a specific purpose. Applications in f8 are each defined with an f8.yaml file.

The Applications page shows all deployed applications. f8 itself is an application, as seen here.
A set of resources that together make up a single running instance of an application.

Environments are created and updated by the f8 CLI and information on all deployed environments is shown in the Environments page.
A file used to define an application, including its name, components/containers, tests, and volumes. It generally lives in the application's source code repository.

For detailed information on all fields available in this file, see Config Builder.
A command line tool used to manage environments for any application with an f8.yaml file.

f8 CLI commands are called from Jenkinsfiles to automate the build/release process for an application.

Various commands are offered, including build to build containers, deploy to deploy/update environments, and test to run tests. More information on available commands and options can be found by installing the CLI and running f8 -h.

Click here to see a Jenkinsfile which provides a basic deployment process with embedded f8 CLI commands. If you have GitHub OAuth integration enabled, this file can be automatically added to any of your GitHub repos via Config Builder.
In f8, all application components must run as containers. Containers are defined in an application's f8.yaml file, under components and tests.

Each container can either:
  • be built from a Dockerfile in a directory in the source repository (that f8.yaml lives in)
  • use the URL of an existing container image
A component of an application, e.g. a web server, a Postgres database, or a Redis cache.

Components manage containers, ensuring they're always running, and offering features like external networking and horizontal autoscaling.

The following types of components are available:
  • stateless - a long-running workload that uses no persistent storage
  • stateful - a long-running workload that has a separate persistent volume mounted to each instance
  • init - a workload that runs to completion one time, usually to initialize another component, e.g. to create a schema in a database
  • scheduled - a workload that runs to completion on a schedule
Components that expose ports (via the expose field) can be reached:
  • By other workloads in the cluster via DNS by simply using the component name
    • The component name is specified with the name field of the component definition
  • Externally via a unique URL if the external field is specified on the expose definition
    • This URL is logged in the output of the f8 deploy command and can also be reached via the icon on the Environments page
Similar to a component, tests also manage containers, however they only run to completion and are generally used to measure quality (functionality, performance, etc.).

Tests are run via the f8 test command, which succeeds only if the container(s) defined for the test exits with a status of 0, otherwise the test is considered a failure.
A name for a specific deployment configuration for an application, common examples are dev, qa, stage, and prod.

An environment's type is set when the --type option is passed to the deploy command of the f8 CLI. f8.yaml includes a section called env-types to provide the ability to define any adjustments that should be applied (prior to deploy) to the rest of the configuration (components, tests, etc.) when a given environment type is supplied.

These adjustments are processed very similarly to the addition operation in Jsonnet. The env-type resolver   in Config Builder is a useful tool for outputting the resolved environment configuration for a given environment type.

Additional notes:
  • A default environment type can also be set for an application with the field default-env-type in f8.yaml. If the --type option is not supplied and no default is otherwise specified, the type defaults to local.
  • The type for an environment is immutable after the environment is created and it can only be changed by deleting and re-creating the environment. When updating an environment, the CLI will always retrieve and use its existing type, throwing a warning if an alternate type is supplied to the deploy command.


Example Walkthrough: joker

joker is an application that simply returns a joke when a GET is performed at /joke.

The architecture consists of the following components:
  • A stateless component joker that responds external requests for jokes
  • A stateless component writer that feeds jokes to joker when asked
  • Functional and load tests to exercise the application


For the first step of this walkthrough, we'll create a fork of the joker source repository.

Onboard joker to f8 by going to the Applications page, clicking the icon at the top right, filling out details for your forked repository, and clicking Create.


This creates supporting resources in f8 for joker, including a Jenkins job to manage its builds.
Once successfully onboarded, click Configure to configure the deployment of joker.


This will bring you to Config Builder, which will scan the directory structure of the application's source code repository and provide a best-guess at what its deployment configuration file (its f8.yaml file) should look like.

Further modify its configuration to expose the joker component externally by selecting it in the "components" section.


Under its "expose" section, select Properties, and "external". Change its value to "true", which should also update the raw configuration shown on the right.


You may also further modify the configuration as needed, e.g. multiple instances, resource constraints, health checks, autoscaling parameters, and more.

If you are using DockerHub or Elastic Container Registry (ECR) as your container registry, you must create the following repositories:
  • DockerHub:
    • [dockerhub-org]/joker-joker
    • [dockerhub-org]/joker-writer
    • [dockerhub-org]/joker-func
    • [dockerhub-org]/joker-load
  • ECR:
    • [ecr-registry]/joker/joker
    • [ecr-registry]/joker/writer
    • [ecr-registry]/joker/func
    • [ecr-registry]/joker/load


Finally, click the cloud_upload icon to upload the configuration to the application's source code repository.
Open your joker application's source code repository by clicking on the source icon, and see two newly created files:
  • f8.yaml - The deployment configuration file we built with Config Builder
  • Jenkinsfile - A deployment pipeline-as-code file that includes f8 CLI commands to build, deploy, and test your joker application (learn more about Jenkinsfiles here)

Revisit the Jenkins job for joker, and find that (within about a minute) a build has started, which will build the application's containers, deploy them to f8, and run tests. Click the build to view information on its progress.



Once the "Deploy" stage has started in the above build, you will see joker in Applications (refresh as needed).


Click it to view information on joker, including its architecture and deployed environments, more details of which can be seen by clicking "View".


Click on the icon to open joker. Append "/joke" to the URL, hit enter, and hold on to your chair, because you will be given a hilarious joke.

Updates to this joker environment occur upon code changes to its source repository's main branch. You may also create a new branch, which will kick off the same build to deploy another environment dedicated to it in f8.


{{error}}

Version Info

container version {{componentVersion}}
source version {{sourceVersion}}
integrations {{integrations}}