Deploying with Panamax

Before you run your application on your cluster, you’ll need to set up a Panamax remote agent and the Marathon adapter on the cluster. In order to install and utilize the Panamax Remote Agent, Panamax uses a dedicated installer node. The Panamax remote agent can run on Linux with docker installed. However, we recommend using CoreOS for simplicity.

Following the normal methods of adding VM with your cloud provider. Ensure that the node resides on the same VPN as your deployment node or cluster and the node has a publicly accessible IP.

Docker must be installed on the node where you agent will reside. After Docker is installed successfully, follow these steps to install the Panamax Remote Agent:

SSH into the Panamax remote agent node created above

Run $ sudo su to ensure your docker commands will run with correct privileges

Copy the displayed token (needed when adding the deployment endpoint to the client)

Next, use this token to add a remote deployment target to your Panamax client. From the Manage nav button, go to the Remote Deployment Targets page. Click on Add a new Remote Deployment Target, enter a friendly name and your copied token from the Remote Agent. Click Create Remote Deployment Target to save. The deploy target is now available to deploy applications.

Next, back on the search page, enter the term for the application you want to deploy. Click “Run Template” but now select “Deploy to Target.” On the modal window, select your Marathon target. From here, you’ll have the option to specify scaling information.

After you’ve deployed, you’ll see the deployment jobs and applications in your Marathon UI.

Note: In order to reach your deployed application, additional ports may need to be opened on your cloud provider.

Best Practices for using the Marathon Adapter

Using Docker and Marathon requires some unique considerations, depending on how you've chosen to architect your application. First, Marathon does not support Docker links. Panamax has translated these dependency declarations into pre- and post-deployment conditions that must be satisfied for a successful deployment.

For example, if your web service depends on a database service, the Marathon adapter will wait for the database to finish deployment before firing off the web service. In this example, the database has a post-condition that it must have an available port. The web service has a pre-condition that expects to access environment variables indicating the database’s available host and port. If the database service were to fail deploying, or if any of these conditions were not met, the application deployment job would time out.

Instead of Docker links, the dependency relationship is defined via these pre- and post-conditions, and through environment variables and port forwarding rules.

Additionally, dependent services must either be fronted by a proxy that you have set up, or they are limited to one instance, regardless of scaling information given at the time of deployment. If an application asks for 3 web services and 3 databases, the database service will be limited to one instance.