search
githubEdit

Multi-Tiered Deployment

hashtag
Deploy a Multi-Tiered Application

In this guide, we will deploy a multi-tier web application on Nexqloud. The example application will consist of two services: a front-end web service and a back-end database.

hashtag
Before We Begin

This guide is to be considered an extension of the Deploy an Applicationarrow-up-right guide. Please ensure you have successfully completed all steps leading up to the "Create the Deployment Configuration" step in said guide, as they will not be discussed here.

hashtag
Create the Deployment Configuration

Let's create a deployment configuration that specifies multiple services in a single deployment.

---
version: "2.0"

services:
  redis:
    image: bitnami/redis:6.2
    env:
      - REDIS_AOF_ENABLED=no
      - ALLOW_EMPTY_PASSWORD=yes
    expose:
      - port: 6379        
        to:
          - service: goosebin
  goosebin:
    image: hydrogen18/goosebin:latest
    env:
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - PASTE_SIZE_LIMIT=100000
      - HTTP_PORT=8000
    depends_on:
      - redis
    expose:
      - port: 8000
        as: 80
        to:
          - global: true        

profiles:
  compute:
    redis:
      resources:
        cpu:
          units: 1
        memory:
          size: 128Mi
        storage:
          size: 16Mi
    goosebin:
      resources:
        cpu:
          units: 1
        memory:
          size: 64Mi
        storage:
          size: 16Mi
  placement:
    dc1:      
      pricing:
        redis: 
          denom: unxq
          amount: 9999
        goosebin: 
          denom: unxq
          amount: 9999

deployment:
  redis:
    dc1:
      profile: redis
      count: 1
  goosebin:
    dc1:
      profile: goosebin
      count: 1

Let's break down the above SDL into its 3 primary categories: services, profiles, and deployment.

hashtag
Services

The services entries contain maps of workloads to be run on the Nexqloud deployment. This deployment has 2 service entries: redis and goosebin - the former being our backend and the latter being our frontend. Please note that while these service names are arbitrary, their usage must remain consistent across the whole .yml file.

We can see that goosebin is globally exposed and open to the public, while redis is internal to the deployment and is only shared with goosebin.

Within the goosebin entry, we set some environmental variables - these are declared internally within the goosebin image. Note that each application can choose whatever environment variables it wants to use on its own for configuration. The variable that ties our services together is REDIS_HOST. This is what goosebin looks at to determine which host to connect to for redis. In this case, we set REDIS_HOST=redis because we chose to name the service redis - had we named the service database, we would have set REDIS_HOST=database.

The expose section is similar to other HTTP examples - internally, the container for this example is listing on port 8000. The deployment will only be assigned a unique URI that can be visited in a web browser when expose has global: true and the port is set to 80.

hashtag
Profiles

The profiles entries contain named compute and placement profiles to be used in the deployment.

Since we have 2 services to deploy, details for each of them must be specified here. This section is very similar to a standard deployment, so it won't be covered in detail here. An important item to note, however, is that the named compute/placement profiles here (redis and goosebin) must match the names we had specified in the services section. Additional mappingsarrow-up-right can also be specified within profiles such as audited attributes and data center attributes.

hashtag
Deployments

The deployment entries map the datacenter profiles to compute profiles to create a final desired configuration for the resources required for the services.

Similar to the profiles entries, we must specify deployment criteria for both of our services. This says that the 1 instance of the redis service and 1 instance of the goosebin service should be deployed to a datacenter matching the dc1 datacenter profile. Each instance of the services will have the resources defined in its corresponding compute profile (redis or goosebin) available to it.

hashtag
Deployment

Now that we have the SDL configured, let's deploy this application and see what happens. A more detailed guide on this process can be found in the Deploy an Applicationarrow-up-right guide.

Create the Deployment

Create the deployment by running:

Once a provider is chosen, a lease is created, and the manifest is uploaded, we can view the status of our deployment by running:

You should see a response similar to:

The URI shown above will take you to the front-end service. We can verify the service is running and talking with the backend (redis) by running the following:

You should see a response similar to:

We can see the goosebin frontend has made some requests to the redis backend, and the containers are healthy.

PreviousUnstoppable Web 2.0NextHelium Validator

Last updated