How to deploy a web container on a Google powered Mesos cluster

 

Alternative Text by Thijs Schnitger

Lately I’ve been getting my hands dirty deploying applications on Mesos clusters, using Marathon to run Docker containers. I appreciate how it enables you to deploy a wide variety of applications using very little configuration, and seeing your applications scale up and down in a matter of seconds is really neat, but I have had a hard time trying to make an application available to an end user. Hosting your web site on a Mesos cluster, which seems like a basic use case to me, appears to be rather involved, especially when you take into account the infrastructure specifics of your cloud provider. Surely you can get a container running in no time, but then routing a request to it and getting a response back is no trivial matter. In this post I will show how to deploy a simple container with a web server on a Mesos cluster running in the Google Cloud.

Prerequisites

If you want to follow along, you will need the following:

Create the cluster

Once you have the basics set up, visit https://google.mesosphere.com and follow the three simple steps to create a cluster. Just choose a development cluster, enter your public SSH key and your Google Project ID. Review the settings and click Launch, and in a few minutes you’ll have a shiny new Mesos cluster, with both the Marathon and Chronos frameworks available for scheduling your tasks. We’ll be using Marathon to deploy our web application in a container.

Application configuration

Next we’ll need to create a configuration for your application. For the purpose of this example I’m using a simple Nginx application. Surely there are more interesting applications to deploy, but I just want to demonstrate the process of running a webserver so a static web page will suffice. You can specify all kinds of things in the configuration, consult the Documentation for an overview of the possibilities. Below are the contents of my nginx.json configuration file:

The container will expose port 80 (containerPort), and we’ll use this as the port for our service as well. This servicePort can be used to link different applications running on the cluster to each other. The Mesosphere setup on Google Cloud comes with HAProxy and the haproxy-marathon-bridge script installed on every node (master and slaves). The bridge script will consult the Marathon API every minute and create an HAProxy configuration with pools of servers listening on the servicePorts specified in the application configuration, and then reload HAProxy if needed. The benefit is that any application running on the cluster can find any other application by using the servicePort on it’s own host. This host is set as an environment variable on startup of the container so there is no need for any service discovery. However, you’ll need to tell your application about the servicePorts of other applications, for instance through environment variables that you can add to the configuration file. The nice thing is that you can also make use of the HAProxy to let outside users connect to your application running anywhere on the cluster, as we’ll see later.

VPN Connection

Before we can post the configuration file to the Marathon server, we’ll have to set up a VPN connection. On the overview page of your cluster, at https://google.mesosphere.com/clusters/<your cluster name> you can download the configuration for the connection. Save the file on your computer, open a terminal and execute:

If all is well you will now be able to visit the Marathon and Mesos consoles listed on the same page. These are only exposed on port 8080 and 5050 respectively of the internal network interface of the Mesos master node. You will need the IP address of this interface to talk to Marathon on port 8080 in the next step.

Launch the application

Now, open another terminal and post the JSON config to Marathon:

The response will be like below. I piped it through jq for better readability:

You can check in either the Marathon or Mesos consoles to see your application being deployed and running. Congratulations! You’ve just launched your first Docker container on a Mesos cluster! You can check that it’s really working by visiting the private ip address of any of the Mesos nodes (master or slaves) in your browser. You might need to wait a minute for the cronjob to fire the bridge script and update the HAProxy configuration but then you should see the default Nginx page. This only works over VPN though, so it’s not what we want.

Enable traffic to the application

So now that we have our application running, how do we make it accessible to the outside world? In the case of Google’s Cloud we’ll need to take care of a few things. We’ll need to create a forwarding rule, open a port in the firewall and configure iptables on the Mesos master and slaves. We probably could get away with just opening up port 80 on the master node, but this would leave us with a single point of failure. In case the master node is down or unreachable, our web application would not be available. What we would like is to have a fixed external address to connect to, so we can for instance point to it with our DNS. Connections to this address on port 80 should be forwarded to a target pool of servers, in which we put all our nodes. Then we open up port 80 in the firewall so we can access the application in our browser. So let’s get to it!

First, let’s create an external address to connect to. In your terminal, issue the following:

If you do not specify a region you will be asked for one. Be sure to pick the same region your cluster is running in. You can find this on the cluster overview page, but in my case it lists the zone (us-central1-a) instead of the region (us-central1). You will get a response like:

Take note of the ip address because we’ll need it shortly. Next we need to create a target pool to forward the traffic to:

Add instances to the pool, using the names of the nodes listed on the cluster overview page:

And then create a forwarding rule to forward connections on port 80 on the external address to the target pool:

Open up the firewall

When this is done, we need to open up the firewall. We’ll tag the nodes and create a firewall rule to allow connections on port 80 to the servers with the corresponding target tags.

In order to create the firewall rule you need to specify the network that the cluster is running on. First let’s list the networks in our project:

That should list all the networks in your project. If you are still unsure which one to pick, check the description of any of the nodes:

The output will be something like:

Now we can create the firewall rule:

Iptables

That should be it, but there’s another catch which took me a while to figure out. It turns out that on the nodes there’s iptables running which blocks the connections. To fix this, we need to ssh into every node and open up the port in iptables. Again, you can find the SSH user and the external ip addresses of the nodes on the cluster overview page.

Once you’re in, add two rules to the iptables:

If you would like to save these rules in case you need to reboot the server, do the following:

Don’t forget to repeat these steps for the other nodes in the cluster. You probably could (and should) lock it down further to prevent users from accessing your Mesos nodes directly, by only allowing traffic from the external ip address. I haven’t looked into that though so I don’t know what source and destination you would need to specify.

Finally

When you’re done, it’s finally time to visit the site in your browser. Go to the address you created in the ‘gcloud compute addresses create’ step above. You should see the Nginx default page:

Nginx Screenshot

So that’s all there is to it. Of course there’s loads more involved in running a proper web application like scaling, persistence, container linking and such. I just wanted to demonstrate how to run a web application on Mesos and actually show a web page to your audience.

The following two tabs change content below.

Thijs Schnitger

Senior Engineer at Container Solutions
Thijs is a Systems Engineer specialized in all things Linux. At Container Solutions he mainly focuses on programmable infrastructure, when he’s not busy lending a hand. His years of experience with development, delivery and operations make him an allround application debugger and problem solver.

Latest posts by Thijs Schnitger (see all)

4 Comments

  1. gcloud compute addresses create myipaddress –region <cluster region>
    In this command what is myipaddress? Is this master ip or slaves ip.Can you please update on this.

    • Hi there!
      myipaddress is just a name for the address. It’s not the address of a master or slave, but the command will reserve a public ip address that you can then connect to a loadbalancer that balances traffic to all nodes in the cluster, masters and slaves.

  2. gcloud compute addresses create myipaddress –region=us-central1-a <cluster region>

    when I am providing this command I am getting this error,

    ERROR: (gcloud.compute.addresses.create) Some requests did not succeed:
    – Invalid value for field ‘region’: ‘us-central1-a’. Unknown region.
    If I typed this,
    gcloud compute addresses create myipaddress –region <cluster region>
    ERROR: (gcloud.compute.addresses.create) argument –region: expected one argument
    As my cluster region is us-central1-a I am giving as argrument.Can you please help me on this what I should give the command.

    • us-central1-a is a zone. You probably mean to use us-central1.
      To list the available regions: gcloud compute regions list
      To list the zones: gcloud compute zones list.
      hth

Leave a Reply

Your email address will not be published. Required fields are marked *