Supergiant Blog

Product releases, new features, announcements, and tutorials.

Stop By Our Booth at KubeCon!

Posted by Adam Vanderbush on October 20, 2016

Supergiant will join other containerization experts at KubeCon in Seattle to introduce their new open-source container orchestration system on November 8 - 9. KubeCon (a CNCF event) gathers leading Kubernetes technologists from multiple open source cloud native communities to further the education and advancement of Docker, Kubernetes, and Cloud Native architectures. The event is co-located with CloudNativeCon.

Supergiant is the first production-grade container orchestration system that makes it easy to manage auto-scaling, clustered, stateful datastores.

Keep reading

Auto-Scaling Kubernetes Cluster on AWS EC2 with Supergiant

Posted by Brian Sage on September 19, 2016

By the end of this very brief tutorial, you will successfully deploy a Kubernetes cluster using Supergiant on AWS EC2, and it won’t take long at all.

Your cloud hardware will auto-scale according to the parameters you set to keep costs as low as possible. AWS hardware usage rates apply.

Sound awesome? It is.

For This Tutorial, You Will Need:

Note: This is the second article in a series to help you get up and running quickly with Kubernetes using Supergiant. If Supergiant is not yet running, see our previous article: How to Install Supergiant Container Orchestration Engine on AWS EC2. This article has been updated for Supergiant 0.11.x.


Kubernetes that Auto-Scales for You

Administering container orchestration systems and cloud hardware can be tedious because computing needs change. For everyone. All the time.

We got tired of manually doing the same things over and over, so we created Supergiant’s packing algorithm to automatically handle the work of scaling up and scaling down. When you launch a Kube with Supergiant, the packing algorithm is already active, and there is nothing more you need to do to reap auto-scaling cost-saving benefits.

After these few steps, you will have an auto-scaling Kubernetes cluster, too. Let’s get started.

Step 1: Log in to Supergiant

To log in to Supergiant, if you haven’t created a user, you will need the generated admin password. To retrieve it, go to your AWS EC2 console and access the system log for your Supergiant server.

With the instance selected, click Actions > Instance Settings > Get System Log.

Find your Supergiant admin Username and Password near the bottom of the System Log.

Now that you have credentials, access the Supergiant dashboard using the public DNS address of your instance. This address will be shown in your EC2 console.

Log in with your admin Username and Password, and you will be taken to the Sessions view.

Welcome to the Supergiant dashboard! From the Sessions view, we can see that our session has been created, and we can see and administrate who else is logged in.

Step 2: Add Cloud Credentials

Click to visit the Cloud Accounts view, and click to create a new entry with an AWS access key and secret key with full administrator access.

Enter the following, and click Create.

    "credentials": {
        "access_key": "AWS ACCESS KEY",
        "secret_key": "AWS SECRET KEY"
    "name": "ANY VALID JSON STRING",
    "provider": "aws"

After the cloud account is created, make a mental note of the Cloud Account ID that Supergiant assigns. You’ll use it in the next step.

Step 3: Create a Kube

Click to go to the Kubes view, and click to create a Kube.

You will be asked which cloud provider you prefer to use to create a Kube and its hardware. This tutorial contains examples for AWS; however, you may select any provider you like.

When you select a provider, the correct provider JSON syntax will be populated in the editor. There is nothing more happening in the background that that.

Some values will be pre-populated for you. Edit whatever you like, but be sure to edit or review the following entries:

  • "cloud_account_id": enter the ID number of the Cloud Account you created above. Since v0.11 "cloud_account_id" is replaced by "cloud_account_name". Enter the friendly name you gave your cloud account when you created it above.
  • “name”: enter a string that starts with a letter, limited to 12 characters, made of lowercase letters and numbers, and/or dashes (-).
    Note: On AWS, we recommend no dashes, as some AWS services can be finicky with dashes in certain places.
  • “node_sizes”: these are the AWS EC2 instance types Supergiant uses to provision new hardware while auto-scaling to meet demand, starting with the smallest size that fits your needs. We’ve had very reliable performance running Kubernetes on the M4 family of instances, so the list is pre-populated with M4 values. For a complete list, see AWS Instance Types.
  • “availability_zone”: AWS hardware availability changes depending on your account. At times, AWS will make some zones available to you, while some not. Supergiant can deploy a Kube to any zone available to you, so reference this knowledge article to discover which AWS Regions and AZs are available to you.
  • “region”: Must be updated to be compatible with your availability_zone choice. E.g., if availability_zone is us-west-2a, the region must be updated to us-west-2.

When your edits are complete, click Create.

Step 4: Watch Supergiant Go!

Supergiant will orchestrate the provisioning of AWS services, including security settings, load balancers, routing tables and more. Finally, it will provision your Kube master and Kube minion and will display log output as it does it.

The longest wait time will be “waiting for Kubernetes” as you wait for the EC2 instance to be provisioned and boot. This could take 5 minutes or longer, depending on what instance types you have selected. Just be patient. Your order is up next.

Any errors will also be displayed in the log as they happen. There is no need to refresh the browser window.

Access Kubernetes

Once the process completes, you may click on the Kube ID to get details. To verify Kubernetes is running, get the username, password, and master_public_ip from the Kube details.

From the Kube details view, get the username, password, and master_public_ip.

From your terminal, enter the following:

curl --insecure https://USERNAME:PASSWORD@MASTER_PUBLIC_IP/api/v1/

You should see a JSON response describing the API. Congratulations -- you’ve just launched an auto-scaling Kubernetes cluster!


In case you want to tear down your tutorial Kube, simply click to view Kubes, select the one you wish to delete, and then select Delete from the Actions menu.

It’s as simple as that. Supergiant will clean up after itself and remove all the associated AWS services unique to the Kube.

Access the Supergiant Community

Remember, if you have trouble, or if you want to talk to other users about how they're making the most of Supergiant, our community hangs out on the Supergiant public Slack channel.

We would love any feedback you want to leave. We're working hard to add features that our community wants most, so all your comments are helpful to us. Visit our Slack channel, and post your questions and comments.

Where To Next?

This tutorial is one in a series to help you get started with Kubernetes using Supergiant. From here we recommend you check out the following:

Keep reading

Supergiant Announces Winners of Echo Drawing

Posted by Mark Brandon on August 31, 2016

The Supergiant team had a great time at the Linux Foundation’s LinuxCon and ContainerCon last week in Toronto. It was a special week for the Linux community, celebrating 25 years since Linus Torvalds sent an email missive requesting help on the kernel he had been developing, giving birth to the open-source movement. Torvalds himself stopped by the Supergiant booth.

Visitors to our booth were entered into a drawing to win an Amazon Echo. We had hoped to do this drawing at the event, but we didn’t actually get the list until after we got home. To show that everything was on the up and up, we recorded this video of Mark Brandon demonstrating the Echo and Alexa Voice Assistant before he randomly drew the names of the winners.

Supergiant Announces Winners of Echo Drawing

The two winners were John-Alan Simmons, CTO of Conference Cloud, and Salman Saidi from Intel.

Keep reading

How to Install Supergiant Container Orchestration Engine on AWS EC2

Posted by Brian Sage on August 22, 2016

The goal of this walkthrough is to help you provision Supergiant on an Amazon Web Services EC2 test server. By the end of this tutorial, you will be ready to deploy your first App on Supergiant. Supergiant is the easiest open-source container orchestration system to install and use. AWS hardware usage rates apply.

You won’t need to download any source code or binaries. We’ve packaged everything into an Amazon machine image for AWS; however, if you want to take a look at the source, it’s all on GitHub.

Prepare for Launch

Sign into your AWS console and prepare to launch a new EC2 instance through a series of wizarding steps.

Step 1

From the EC2 console, push the Launch Instance button, choose Community AMIs, and search for "supergiant". You should be able to find the latest stable Supergiant AMI release quickly.

Note: when we release new versions of Supergiant, the AMI ID will change and will be different for each region, but we will always release new AMIs under the name "Supergiant".

Search for the latest release of supergiant AMI, then press Select to choose your instance type.

Step 2

Supergiant creates a dashboard that helps you manage any number of Supergiant Kubernetes instances. We recommend a single m4.large instance to hold the latest version of Supergiant, but you can experiment with what works best for you. After you select your instance type, click Next: Configure Instance Details.

Select your instance  type, then click Next: Configure Instance Details.

Step 3

There’s nothing we need to change, here. You may select to change whatever you like, but the defaults are sensible enough. When you’ve made your changes (or not), click Review and Launch.

Configuring these settings are out of the scope of this tutorial. To simply get started, we can leave everything here, as-is. Click Review and Launch.

Step, er... 7

The wizard skips a few steps, but hey, today that works for us. We only need to change one thing we skipped over. We need to take a step back to allow HTTP and HTTPS traffic. Click Edit security groups on this screen.

Click Edit security groups to add rules to allow HTTP and HTTPS traffic.

Add Security

The Dashboard will listen for HTTP traffic on port 9090 when it's ready, so we need to click Add Rule to allow HTTP traffic to that port.

0.8.x UPDATE: The Dashboard now listens for HTTP traffic on port 80.

0.9.x UPDATE: For better security, Supergiant now creates a self-signed certificate and serves the dashboard over HTTPS on port 443.

Click Add Rule and make the Type HTTP and the Port Range 80. Click Add Rule one more time and make the Type HTTPS and the Port Range 443. I’ve changed the Source to My IP in this example. Click Review and Launch when done.

Review and Launch Supergiant

It’s time to launch. If you want to use tags to identify this EC2 server, now is the time to add them. When you’re emotionally prepared for all the excitement, click Launch, and you will be asked what key pair you wish to use. Select whatever option you prefer.

Review changes, add tags if you want them, and click Launch.

Access the Dashboard

To access the dashboard, we will need to access the server’s logs to get the randomly-generated dashboard password. From the Launch Status page, click on the server’s ID to go to the EC2 console with only your new instance visible in the list. With the instance selected, click Actions > Instance Settings > Get System Log and then find your Supergiant Login Info, close to the bottom of the log.

With the instance selected, click Actions > Instance Settings > Get System Log.

Find your Supergiant Login UserName and Password near the bottom of the System Log.

Use your instance’s public DNS or IP address to access it with a web browser on port 80, then use the UserName and Password from the System Log to authenticate. You're now ready to administrate Kube clusters using your Supergiant dashboard!

Access the Supergiant Community

Remember, if you have trouble, or if you want to talk to other users about how they're making the most of Supergiant, our community hangs out on the Supergiant public Slack channel.

We would love any feedback you want to leave. We're working hard to add features that our community wants most, so all your comments are helpful to us. Visit our Slack channel, and post your questions and comments.

Where-To Next?

This tutorial is first in a series to help you get started with Kubernetes using Supergiant. From here we recommend checking out the following tutorials:

Keep reading

Stop By Our Booth at LinuxCon + ContainerCon!

Posted by Adam Vanderbush on August 17, 2016

Supergiant will join other containerization experts at LinuxCon and ContainerCon in Toronto to introduce their new open-source container orchestration system on August 22 - 24. LinuxCon is the place to learn from the best and the brightest, delivering content from the leading maintainers, developers and project leads in the Linux community and from around the world. ContainerCon expands upon the Linux Foundation’s success in Linux by bringing together leaders in the development and deployment of containers, the Linux kernel, to continue to innovate on the delivery of open source infrastructure. 

By co-locating with LinuxCon, ContainerCon will bring together a diverse range of experts from cloud computing and Linux to offer a general technical conference that is open to everyone; creating a place where companies on the leading edge can network with users and developers to advance computing. 

Supergiant is the first production-grade container orchestration system that makes it easy to manage auto-scaling, clustered, stateful datastores.

Scan your badge at our booth for your chance to win 1 of 2 Echos. 

Supergiant began in 2015 when the team at needed a production-ready, scalable solution for their Hosted Elasticsearch Service. After massive initial internal success, it was refined to easily launch and manage any containerized application. Supergiant solves many huge problems for developers who want to use scalable, distributed databases in a containerized environment.

Built on top of Kubernetes, Supergiant exposes many underlying key features and makes them easy to use as top-layer abstractions. A Supergiant installation can be up and running in minutes, and users can take advantage of automated server management/capacity control, auto-scaling, shareable load balancers, volume management, extensible deployments, and resource monitoring through an effortless user interface.

We also have free astronauts, shirts, and stickers. 

Supergiant uses a packing algorithm that typically results in 25% lower compute-hour resources. It also enhances predictability, enabling customers with fluctuating resource needs to more fully leverage forward pricing such as AWS Reserved Instances.

Supergiant is available on Github. It is free to download and usable under an Apache 2 license. It currently works with Amazon Web Services. Google Cloud, Rackspace, and Openstack are next on the roadmap. Supergiant is a member and contributor to The Linux Foundation and the Cloud Native Computing Foundation.

Keep reading

Deploy a MongoDB Replica Set with Docker and Supergiant

Posted by Ben Hundley on July 19, 2016

Despite a number of annoying challenges, it is totally possible to run distributed databases at scale with Docker containers. This tutorial will show you how to deploy a MongoDB replica set in 5 steps using Docker containers, Kubernetes, and Supergiant.

NOTE: This tutorial was depricated when Components were removed in version 0.11.x. This tutorial is valid for Supergiant version =< 0.10.x.

About the Tools

Docker is much-loved for bundling applications with dependencies into containers. I’m going to assume you already have knowledge of Docker, or you wouldn’t be reading this tutorial. We’re going to use the official MongoDB container already on DockerHub.

Kubernetes solves many container orchestration challenges for us, including networking (for clustering) and external storage (for state and data persistence). However, the sequence of Kubernetes commands needed to deploy a clustered application with storage is far from straightforward. We’ll use Supergiant to solve these problems.

Supergiant solves Kubernetes complications by allowing pre-packaged and re-deployable application topologies. Or, in more specific terms, Supergiant lets you use Components, which are somewhat similar to a microservice. Components represent an almost-uniform set of Instances of software (e.g., Elasticsearch, MongoDB, your web application, etc.). They roll up all the various Kubernetes and cloud operations needed to deploy a complex topology into a compact entity that is easy to manage. If you don’t already have Supergiant running on AWS, you can do this pretty quickly from the Install Supergiant page.

So let’s get down to business. This tutorial will use the Supergiant’s API directly with cURL for clarity on all the configuration and inputs, and we’ll have a running replica set in just 5 steps.

Step 1: Create an App

An App allows you to group your components. For example, you might have an app named “my-site-production”, where one of the components is “my-mongodb”.

curl -XPOST $API_HOST/v0/apps -d '{
 "name": "test"

Step 2: Create an Entrypoint

An Entrypoint represents a cloud load balancer (such as an ELB on AWS). When you create components that expose network ports, you can optionally allow external access by assigning them to entrypoints, which then gives the component a publicly-reachable address. This will allow us to communicate with MongoDB from anywhere outside of the Kubernetes cluster.

Note: we’ll do this for our tutorial, but if you don’t need external access, it is smarter to leave communication on the private network by just using the private address without an entrypoint.

curl -XPOST $API_HOST/v0/entrypoints -d '{
 "domain": “"

Step 3: Create a Component

The component contains only 2 attributes: name and custom_deploy_script. Custom Deploy Scripts allow components to extend the standard Supergiant deployment flow. The deploy script used here is supergiant/deploy-mongodb, which configures a replica set based on the component information.

curl -XPOST $API_HOST/v0/apps/test/components -d '{
 "name": "mongo",
 "custom_deploy_script": {
   "image": "supergiant/deploy-mongodb:latest",
   "command": [

Step 4: Create a Release

A Release holds all the configuration for a component. You can think of it like a commit to a git repo. Creating new releases allows you to adjust configuration, and deploy changes when needed.

curl -XPOST $API_HOST/v0/apps/test/components/mongo/releases -d '{
 "instance_count": 3,
 "volumes": [
     "name": "mongo-data",
     "type": "gp2",
     "size": 10
 "containers": [
     "image": "mongo",
     "command": [
     "cpu": {
       "min": 0,
       "max": 0.25
     "ram": {
       "min": "256Mi",
       "max": "1Gi"
     "mounts": [
         "volume": "mongo-data",
         "path": "/data/db"
     "ports": [
         "protocol": "TCP",
         "number": 27017,
         "public": true,
         "per_instance": true,
         "entrypoint_domain": ""

Since the release is the real meat of the matter, I’ve highlighted the parts that can be adjusted without altering the actual topology. First, there’s the volumes section, in which the name, size, and type of EBS (hard drive) can be edited. Then, cpu and ram, both of which control the allotted min/max (or reserve/limit) range for each instance of the component. The mounts section corresponds to volumes, so make sure that the volume value matches the name used for the drive.

Step 5: Deploy

This will deploy the Component as outlined by the Release.

curl -XPOST $API_HOST/v0/apps/test/components/mongo/deploy

When the deploy finishes, you can retrieve the assigned address of each Instance of the component like so:


curl $API_HOST/v0/apps/test/components/mongo/releases/current/instances/0


 "id": "0",
 "base_name": "mongo-0",
 "name": "mongo-020160715200942",
 "status": "STARTED",
 "cpu": {
   "usage": 7,
   "limit": 250
 "ram": {
   "usage": 36270080,
   "limit": 1073741824
 "addresses": {
   "external": [
       "port": "27017",
       "address": ""
   "internal": [
       "port": "27017",
       "address": "mongo-0-public.test.svc.cluster.local:27017"

Using the external address of the first instance (highlighted above), we can connect to the MongoDB shell remotely (from your local computer for instance) like so:


Your output upon connecting should look like this (the important part being the prompt, rs0:PRIMARY>, confirming the replica set is configured):

MongoDB shell version: 2.4.10
connecting to:

Note:  if you’re looking to deploy larger, sharded MongoDB clusters, you could use the following layout:

  • Component for each shard (optionally as a replica set), just as defined above. Runs the mongod process (see command section of the container definition).

  • Component for the config server replica set. Runs mongod with the --configsvr option.

  • Component for the routing layer. Runs mongos.

View Deploy a Sharded Cluster in the MongoDB manual for an overview of the setup.

And there you have it -- a MongoDB replica set running as containers, with data stored reliably on detachable external drives.

This setup can be resized at any time (CPU, RAM, or disk; volumes can be resized), by creating a new release that defines the new resource allocations you want. Supergiant will then gently rebuild each container upon deploy.

Keep reading