Getting Started:

This guide will show you how to install the platform and demonstrate the major capabilities we bring to the DC/OS ecosystem, specifically:

  • Management Layer
    • Container Support with DC/OS Adapter
  • Lambda Engine
  • Policy
  • DC/OS Federation

Prerequisites
Installation:
Containers
Lambdas!
Policy:
Limit Policy
Event Policies
DCOS Federation:

Prerequisites:

You will need a DCOS installation with Marathon running and at least 4gb ram and 4 cores free.

Optional: If you want to use CALICO support then you will need to install CALICO and etcd from universe.

Installation:

To access the latest Gestalt Framework you will need to add the Galactic Fog universe repo server to the list of repo servers for your DC/OS cluster. Follow these steps:

  1. On the DC/OS dashboard sidebar, click System, then click the Repositories tab in the right pane.
  2. Click "Add Repository", and add a repository with the following properties:
    • Repository name: does not matter, galactic-fog is good
    • URL: https://universe.galacticfog.com/repo
    • Priority: 0 (this is necessary so that the 1.0.0 version in our repo overrides the 0.2.0 version in Mesosphere's repo)
  3. Click System from the dashboard sidebar, then scroll down to or search for the gestalt-framework. The version should be 1.0.0.
  4. Install the framework as before. Feel free to override the default login username/password on the security tab under Advanced install, and to set a top-level domain for virtual hosts for the services, if you'll be accessing them via marathon-lb virtual hosts.
  5. From Services on the dashboard sidebar, you should be able to se the Gestalt Framework launcher that the universe installed. As soon as it is up and healthy, you should be able to open the launcher dashboard by clicking on the icon that appears when you hover over the launcher service.

List of repos (this view already has the Galactic Fog repo):

Adding the Galactic Fog repo:

Searching for the gestalt-framework package fro the list of Universe packages:

The framework advanced config properties:

The database advanced config properties:

The security advanced config properties:

The laser advanced config properties:

Finding the gestalt-framework launcher on the services listing:

It may take up to a minute for it to appear depending on your network. If you click on the little window to the right of the scheduler service it will take the status page for the scheduler. Gestalt Framework Launcher in progress:

The gestalt-framework launcher, after all services have converged. The "Virtual Host" column will only be populated if a top-level domain (TLD) was specified in the advanced installer, and will only function properly if DNS, load-balancing and marathon-lb have been configured for standard DC/OS procedure. Otherwise, the IP:port under the "Container Instance" column will give the host ip:port for each component service.

The installer will deploy the following containers:

  • Gestalt Security
  • Gestalt Policy
  • Gestalt Meta
  • Gestalt Lambda
  • Gestalt API-Gateway
  • Gestalt-UI
  • Gestalt-Data (Postgres)
  • Rabbit MQ
  • Kong API Gateway
  • API-Proxy

For production environments we recommend building out the postgres and rabbit enviroment separately, and you can override the configuration in the installer.

After clicking "Install" you can find the framework scheduler under the DCOS services tab:

Gestalt has two framework schedulers, the gestalt service and the the lambda service. Outside of those two frameworks everything else is a normal container. We use Marathon to deploy and manage our own services. The default install location in Marathon is /gestalt You should see this in Marathon if everything is working correctly:

The UI container is the primary interface for gestalt. You can access it by clicking on the link in the Framework scheduler, or by finding it's IP:Port in the Marathon UI.

The next step is to log into Gestalt. The login and password are specified by the installer. The defaults are gestalt-admin / letmein.

To help get you started we automatically add a couple of providers during the deployment process, including a DCOS adapter for the Marathon node we used, and a Kong Provider, so that you can immediately begin to deploy and test lambdas. You can find these providers by clicking on the providers tab for the root org.

As part of the process we also create a default org, a demo workspace and a demo dev environment. Lambdas and containers can only be deployed inside an environment. So the process is typically:

  1. Create organization
  2. Create workspace
  3. Create environment
  4. Deploy lambdas/containers.

Containers

To create a container navigate to the demo dev environment and click the container icon followed by the + button.

First you need to select a provider. At this point there should only be a single provider. The minimal things to specify are the container name, the image, and the network. Most DCOS implementations are plumbed to the docker public repo by default, so you can simply punch in a common image like "nginx" and it will work.

The network drop down can be tricky. In a standard bare bones environment Gestalt supports Host and Bridged mode, which are similar to DCOS implementation. Gestalt also supports PROJECT CALICO, and you can add CALICO networks by tweaking the networking section of the provider. In the example above we are using the "apps" network. Simply click deploy at any point to deploy the container.

After it is deployed you should see this:

You can scale, migrate and delete it by clicking the icon under the "state" section of the container list.

Lambdas!

For the next step lets create a lambda. To do this, use the navigation pane on the left or the bread crumb menu a the top of the screen to navigate back to the demo dev enviornemnt and this time click on the lambda icon followed by the (+) button. You should see a screen like this:

Select a provider, provide a name for your lambda, select a type (inline to use code editor), and then enter the follow lambda code:

function hello(event, context) { // Call the console.log function. console.log("Hello World"); return "<html><head></head><body><h1><center>HELLO WORLD INLINE CODE!!<hr></h1><br><h4>This is a serverless webpage!!!</h4><br></center></body></html>";};

You will need to provide an entry point. This is the name of the function that should be called in code. This takes the form of namespace plus separator plus functioname. (be aware this can vary across language runtime, set github docs for more language examples.) For this example enter in: "hello;hello" In this inline code there is no namespace so the first hello is abitrary and creates an implied namespace.

Make sure you check the Public flag. This ensure you lambda is publically available. (eg, Gestalt Security will not protect it). Click Create. You now have a lambda. Click on the "Copy" icon in the UUID column of your lambda in the list. This will copy the UUID to your clipboard.

Next we need to create an API endpoint for accessing our lambda. Select the "APIS" tab in the environment, and click "CREATE API".

Select the API Gateway provider from the dropdown, name the API and click create. Now you can add endpoints to your API. Click "CREATE ENDPOINT". Select "Lambda" as the type. Enter a path for the endpoint, and paste the lambda UUID. If you forgot to click on the COPY icon in the lambda, you can back out of the endpoint and go back to lambdas and copy it, or search for lambda by name. Click create.

You should now have a lambda and an API endpoint to access it. A link is provided to test access to the API endpoint and lambda.

So here is our process for creating a lambda:

  1. Create the lambda.
  2. Copy the UUID or remember the name.
  3. Create an endpoint, endpoints must start with a slash. (eg "/sayhello")
  4. Click the "CREATE" button
  5. After a few seconds a URL should pop up. Click the URL run the lambda.

Policy:

The Gestalt policy engine can currently be used for two different use cases. The first is constraining what a user can do with infrastructure. We call this Limit Policies.

Limit Policy

Some examples of things you can do with a limit policy:

  • Restrict which user a container runs as.
  • Restrict the number of instances in a workspace or environment.
  • Restrict the cpu/mem/disk consumption in an environment.

Event Policies

The second major use case for the Policy engine is around integration. We give you hooks for the deployment of resources and let you run lambdas against them. We call these For example every time you launch a container you might need to update your ITSM solution. Or maybe you don't like how we do container migrations and want to do you own. They great thing is that you can bend gestalt to do whatever you need in your programming language of choice. You don't have to modify gestalt, you just configure the behavior and point it at a lambda.

DCOS Federation:

A common use case in enterprise is the need to federate DCOS clusters. Gestalt providers first class support for this using meta service. Meta has the ability to emulate the Marathon APIs and to combine them into a single view using our federation capabilities. This lets you use the dcos command line utility as you normally would but you can see your workspaces resource across all dcos clusters.

The way this works is by pointing the dcos cli at meta for it's Marathon communications. We provide a simple command line tool that makes this easy to use. It's called meta-dcos and you can find it at: https://github.com/GalacticFog/meta-dcos