Whilst creating our reference microservices application for Weave, I wanted to use minimesos as a controlled Mesos environment for demos and testing. The key benefit for this use case was the static definition of the Mesos environment. The stability not only helps during integration testing, but also during user experiments. I can (almost) guarantee that the demonstration will work for them.
But the testing requirement forced me to use cloud infrastructure as my host. This post describes how I used minimesos on AWS.
I used Terraform to perform the provisioning step. The goal was to start a single AWS instance with enough grunt to power minimesos and the application. All the code is available on github in the microservices repository.
The Terraform scripts are typical, so I won’t describe them verbatim. But I would like to highlight a few key points. In the aws.tf script, I’ve specifically chosen to use Ubuntu 14.04, a rather old version of Ubuntu, due to package support for Mesos and Docker. In other versions there would be support for one, but not for the other. This will undoubtedly change over time.
The script opens all TCP ports to the world. Despite the obvious security hole, I’m convinced that the simplicity is more important. On many occasions I’ve had to view the Mesos UI, or curl one of the microservices on some unspecified port. I doubt that this is ever a problem because the nature of the test environment is that it will only be alive for a few minutes and there is no sensitive information there.
In the main.tf script, the Ireland AWS region is selected and then starts the provision.sh bash script.
The provisioning script starts by installing some dependencies, then installs the Docker engine.
sudo apt-get update ; sudo apt-get install -y curl git jq # Install docker curl -sSL https://get.docker.com/ | sh
Next, it installs minimesos from the helpful install script and copies the binary into a folder that is accessible by all users:
# Install minimesos curl -sSL https://minimesos.org/install | sh sudo cp ~/.minimesos/bin/minimesos /usr/local/bin/minimesos
This is necessary because Docker installed under root, so we need to run minimesos as root in order to access Docker. By default, the minimesos script installs as the current user.
Next, the script installs items required by the microservices application and checks out the project. You may want to remove this, or replace with your project.
# Install weave sudo curl -L git.io/weave -o /usr/local/bin/weave sudo chmod +x /usr/local/bin/weave # Clone repo to get deployment scripts git clone https://github.com/weaveworks/weaveDemo.git cd weaveDemo
Weave Net is a software defined network that we are using to provide networking features within this demo. I encourage the reader to check it out.
Now that the infrastructure is in place, we need to deploy minimesos and the demo application.
The provisioning script will call a deployment script located elsewhere in the repository. But to summarise it performs the following steps.
# Start minimesos sudo minimesos init sudo minimesos up
The first command initialises the working directory with a minimesosFile, the configuration file that specifies the architecture of the upcoming Mesos cluster. The second command starts minimesos. It will take a moment to download the images.
Next, the script can obtain the ip addresses of the running minimesos cluster with a little bash foo:
eval $(sudo minimesos info | grep export)
This will add the typical minimesos environmental variables to the current session. Finally, you can submit your application via marathon in the usual way. This code is taken from the mesos-marathon deployment script in the microservices repository.
If you’d like to try this yourself, feel free to test the reference microservices application. Simply clone the microservices repository and navigate to the minimesos-aws installation folder. Export the following variables that provide the scripts with your AWS credentials:
export TF_VAR_aws_key_name=<AWS-SSH-KEY-NAME> ; export TF_VAR_private_key_file=path/to/ssh/
The ip addresses will be printed at the end of the provisioning step. Alternatively, here is a demo I recorded performing the same steps.
If you have any problems, please get in touch via Github. If you’d like some help with your application, all of us at Container Solutions would love to help.