Cloud Docs Home > F5 Container Integrations Index

F5 Marathon Container Integration

Overview

The F5 Marathon Container Integration consists of the F5 Marathon BIG-IP Controller, the F5 Application Services Proxy (ASP), and the F5 Marathon ASP Controller.

The F5 Marathon BIG-IP Controller configures BIG-IP Local Traffic Manager (LTM) objects for Applications in a Mesos cluster, serving North-South traffic.

The F5 Application Services Proxy provides load balancing and telemetry for containerized applications, serving East-West traffic. The F5 Marathon ASP Controller deploys ASP instances ‘on-demand’ for Marathon Applications.

F5 Container Solution for Marathon

General Prerequisites

The F5 Mesos/Marathon Integration’s documentation set assumes that you:

  • already have a Mesos cluster running;
  • are familiar with the Marathon Web Interface ;
  • are comfortable using HTTP methods to make REST API calls;
  • already have a BIG-IP device licensed and provisioned for your requirements; [1] and
  • are familiar with BIG-IP Local Traffic Manager (LTM) concepts and tmsh commands. [1]
[1](1, 2) Not required for the F5 Application Services Proxy and ASP controllers (f5-kube-proxy, marathon-asp-ctlr).

F5 Application Services Proxy

The F5 Application Services Proxy (ASP) provides container-to-container load balancing, traffic visibility, and inline programmability for applications. Its light form factor allows for rapid deployment in datacenters and across cloud services. The ASP integrates with container environment management and orchestration systems and enables application delivery service automation.

F5 Marathon ASP Controller

The F5 Marathon ASP Controller – marathon-asp-ctlr – deploys the F5 Application Services Proxy. Like the F5 Marathon BIG-IP Controller, the F5 Marathon ASP Controller watches the Marathon API for Apps defined with a specific set of labels. When it finds an Application configured with the f5-asp: enable label, it launches an instance of the F5 Application Services Proxy to front the App and creates a virtual server on the F5 Application Services Proxy instance. The F5 Marathon ASP Controller maintains an address in the F5 Application Services Proxy pool configuration for each of an Application’s tasks.

The F5 Marathon ASP Controller App definition contains a set of default Marathon ASP configuration labels. These configurations – set in the “env” (or, “Environment”, in the Web UI) section of the marathon-asp-ctlr App definition – apply to each ASP instance the marathon-asp-ctlr launches. The F5 Marathon ASP Controller also has a set of “override” labels. [2] When you add these labels to the definition for an Application you want the ASP to proxy, they take precedence over the default marathon-asp-ctlr settings.

By default, the marathon-asp-ctlr starts one (1) F5 Application Services Proxy instance per application. You can override this setting using the ASP_COUNT_PER_APP F5 application label.

The F5 Application Services Proxy collects traffic statistics for the Applications it load balances; these stats are either logged locally or sent to an external analytics application. You can set the location and type of the analytics application using the ASP_DEFAULT_STATS_URL label.

[2]See the Marathon ASP configuration labels table.

F5 Marathon BIG-IP Controller

The F5 Marathon BIG-IP Controller is a container-based Marathon Applicationmarathon-bigip-ctlr. You can launch the F5 Marathon BIG-IP Controller in Marathon via the Marathon REST API or the Marathon Web Interface.

The marathon-bigip-ctlr watches the Marathon API for special “F5 Application Labels” that tell it:

  • what Marathon Application we want it to manage, and
  • what BIG-IP LTM objects we want to create for that specific Application.

When the F5 Marathon BIG-IP Controller discovers new or updated Marathon Applications with the F5 Application Labels, it dynamically applies the desired settings to the BIG-IP device.

Important

The F5 Marathon BIG-IP Controller cannot manage objects in the /Common BIG-IP partition.

You can use the F5 Marathon BIG-IP Controller to:

Key Apache Mesos/Marathon Concepts

Application Labels

In Marathon, you can associate labels with Application tasks for tracking/reporting purposes. We’ve developed a set of custom “F5 Application Labels” as a way notify the F5 Marathon BIG-IP Controller and F5 Marathon ASP Controller that they have work to do.

When the F5 Marathon BIG-IP Controller discovers Applications with new or updated F5 Application Labels, it dynamically creates BIG-IP virtual servers, pools, pool members, and HTTP health monitors for each of the Application’s tasks.

When the F5 Marathon ASP Controller discovers Applications configured with the "f5-asp": "enable" label, it launches an ASP instance for that app. F5 Application Labels define the ASP configurations.

See the marathon-bigip-ctlr product documentation for the full list of F5 Application Labels.

Tip

You can download the code example used in the next few sections and modify it to suit your needs.

iApps Application Labels

You can use the F5 Marathon BIG-IP Controller to deploy BIG-IP iApps using a special set of customizable iApps Application Labels. The iApp you want to deploy must already exist on the BIG-IP device (can be in the /Common partition).

A few of the key iApp Application Labels depend on the iApp you want to deploy, as well as your environment and needs. See Required iApp Application Labels and the marathon-bigip-ctlr product documentation for more information.

Apache Mesos DNS and ASP Discovery

Each F5 Application Services Proxy instance is discoverable via an Apache Mesos DNS SRV query, which returns its IP address, port, and protocol. By convention, the DNS name of an F5 Application Services Proxy instance for an Application is “<ASP_ENABLE_LABLE>-<application name>.<domain name>”.

For example:

  • ASP_ENABLE_LABEL: ASP +
  • Application name: “app1” +
  • Domain name: “marathon.mesos” =
  • ASP DNS name: “ASP-app1.marathon.mesos”

Port Mapping

In Marathon, container-based applications using Docker BRIDGE mode must have port mappings configured. [3] For Applications proxied by the F5 Marathon BIG-IP Controller, these port mappings make it possible for the BIG-IP device to route external traffic to service ports inside the Apache Mesos cluster. You can define multiple port mappings for a Marathon Application.

Important

Apache Mesos commonly restricts binding to ports in a specific range. Consult the Apache Mesos ports resource to see what ports are available in your cluster before defining service ports and/or port mappings for your applications.

Incorrect port mappings may result in deployment failures. See Troubleshooting your Marathon deployments for more information.

Most F5 Application Labels let you specify an index into the port mapping array, beginning at 0. These parameters include {n} in the label key; simply replace {n} with the port index to which you want the setting to apply.

For example:

The code sample below defines an Application with three (3) port indices.

Service definition with multiple ports
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// REMOVE ALL COMMENTS BEFORE USING
{
  "id": "server-app4",
  "cpus": 0.1,
  "mem": 16.0,
  "instances": 2,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "docker-user/node-web-app",
      "network": "BRIDGE",
      "forcePullImage": false,
      "portMappings": [
        { "containerPort": 8088,
          "hostPort": 0,
          "protocol": "tcp" },
        { "containerPort": 8188,
          "hostPort": 0,
          "protocol": "tcp" },
        { "containerPort": 8288,
          "hostPort": 0,
          "protocol": "tcp" }
      ]
    }
  },

In the labels section, we specify that we want to create HTTP virtual servers on the BIG-IP device for port indices 0 and 1. In this example, 0 refers to the first mapping defined above ("containerPort": "8088") and 1 refers to the second ("containerPort": "8188").

marathon-bigip-ctlr labels defining BIG-IP objects for two (2) port indices
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
  "labels": {
    "F5_PARTITION": "mesos",
    // Assigns an IP address to the BIG-IP front-end virtual server
    // Omit this label if creating pools without virtual servers
    // (Available as of v1.1.0-beta.1 )
    "F5_0_BIND_ADDR": "10.190.25.240",
    "F5_0_MODE": "http",
    "F5_0_PORT": "8080",
    // Assigns an IP address to the BIG-IP front-end virtual server
    // Omit this label if creating pools without virtual servers
    // (Available as of v1.1.0-beta.1 )
    "F5_1_BIND_ADDR": "10.190.25.242",
    "F5_1_MODE": "http",
    "F5_1_PORT": "8090"
  },
[3]See the Docker Networking documentation for more information.

Marathon Health Checks

The F5 Marathon BIG-IP Controller provides compatibilty with existing Marathon Health Checks. For ports configured with Marathon health checks, the marathon-bigip-ctlr:

  • creates corresponding BIG-IP health monitors;
  • checks the specified port’s health status before adding it to a BIG-IP pool. [4]

To continue our example:

Here, we create health checks for each of the port indices defined for our Application.

Defining health checks for multiple ports
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
  "healthChecks": [
    {
      "protocol": "HTTP",
      "portIndex": 0,
      "path": "/",
      "gracePeriodSeconds": 5,
      "intervalSeconds": 20,
      "maxConsecutiveFailures": 3
    },
    {
      "protocol": "HTTP",
      "portIndex": 1,
      "path": "/",
      "gracePeriodSeconds": 5,
      "intervalSeconds": 20,
      "maxConsecutiveFailures": 3
    },
    {
      "protocol": "HTTP",
      "portIndex": 2,
      "path": "/",
      "gracePeriodSeconds": 5,
      "intervalSeconds": 20,
      "maxConsecutiveFailures": 3
    }
  ]
[4]Occurs when F5_CC_USE_HEALTHCHECK‘s value is “True”.