Multi-Tenancy: Serving Multiple Apps From the Same Stack

what is multi-tenancy?

a multi-tenancy architecture allows for multiple independent instances of one or more applications to share the same environment, which can include the data model, servers, and database layers.

why choose a multi-tenant environment for your application?

there are times when you'll need to run multiple applications on the same stack. this might be because:

• the applications you're running share common resources, or
• your applications don't have enough traffic to run on separate stacks.

the primary benefit of a multi-tenant environment is the ongoing cost-savings of shared infrastructure. additionally, it can help you maximize the performance of the different components in the stack. as it's easier to monitor and administer one server (i.e. a single, centralized place), as opposed to applications hosted in different environments, you can save time spent on configuration and managing software updates.

multi-tenancy for your docker stack with cloud 66

to achieve your multi-tenancy requirements, you'll first need to modify your service.yml file. to start, place each of your applications into its own service in order to host multiple applications on the same stack.

for example:

services:  
    first_app:
        git_url: git@github.com:kasia/my_first_app.git
        git_branch: master
        ports: ["3000:80:443"]
    second_app:
        git_url: git@github.com:kasia/my_second_app.git
        git_branch: master
        ports: ["3000:80:443"]
    third_app:
        git_url: git@github.com:kasia/my_third_app.git
        git_branch: master
        ports: ["3000:80:443"]

in the example above, you'll notice that all the specified applications share the same public ports (80 and 443). this means that any inbound traffic to the stack on port 80 or port 443, will be randomly served by any application each time.

this problem can be solved by using the domain matching feature in cloud 66. this feature allows you to still share ports and have the ability to split traffic by the url domain name that client has requested:

for example:

services:  
    first_app:
        git_url: git@github.com:kasia/my_first_app.git
        git_branch: master
        ports: ["3000:80:443"]
        traffic_matches: ["firstpplication.com"]
    second_app:
        git_url: git@github.com:kasia/my_second_app.git
        git_branch: master
        ports: ["3000:80:443"]
        traffic_matches: ["secondapp.com", "www.secondapp.com", "second-app.com", "www.second-app.com"]
    third_app:
        git_url: git@github.com:kasia/my_third_app.git
        git_branch: master
        ports: ["3000:80:443"]
        traffic_matches: ["thirdapplication.com", "*.thirdapplication.com"]

the example above shows how traffic has been split based on the requested domain. however, you can match the traffic based on multiple domains, as well as wildcard (*) subdomains.

configuring your docker service allows you to provide more explicit control settings to cater for custom setup scenarios (like multi-tenant stacks). to find out more about configuring your service.yml , visit our help page on docker service configuration .