Help on Multi-tenant and Multi-region deployment

Legacy Modelling
1

Hi Guys,

I’m new to octopus deploy and appreciate if you could provide your suggestions/opinion on following.

We have a web based product and that needs to be deployed among multiple customers (tenants).
For each tenant there will be a unique instance of the product. Furthermore, each tenant can have their instance deployed in, one or more geographical regions (most probably with Azure) depending on their preference.
Also in each region there can be shared/dedicated deployments.

Let me elaborate this with following example.

  • Tenants: Tenant 1, Tenant 2, Tenant 3

  • Geographical regions: Region 1, Region 2, Region 3

  • Deployment preferences:

    • Tenant 1 - [Shared] - Region 1 and Region 2
    • Tenant 2 - [Shared] - Region 1 and Region 3
    • Tenant 3 - [Dedicated] - Region 1 and Region 2

After looking at documentation, we considered to go with Environment per Region approach and create a single Project for the product.

Then create a Tenant in Octopus for each customer then link them with the project and environments as necessary.

What do you think about above approach?

We didn’t see any use case to utilize Cloud Regions with above approach. Do you think we should use that

Also with this approach, when we deploy for a given tenant, would it be possible to simultaneously deploy to all the assigned environments for that tenant?

2

Hi,

Thanks for getting in touch! I’m sorry for the delay in getting back to you. I think we will need to get some more information to better understand your requirements and current scenario.

Are you deploying an Azure web app?
What does your current deployment pipeline look like?

Also, regarding cloud regions, Generally they are used for splitting up your app across geographic boundaries.

The above information should help us get a better idea of your requirements and what exactly you need to achieve with your deployment. Any further information you think may help here would be appreciated.

Looking forward to hearing from you. :slight_smile:

Best regards,
Daniel

3

Hi Daniel,

Thank you for your reply. Let me elaborate this little more.

We have a product which is a web application.
When new customer(=Tenant) comes in, we should deploy a new instance of our product exclusively for this customer.
Also, we are going to have deployment infrastructure in different geographical regions on Azure. So, this customer can specify one or more regions where this application needs to be deployed. Then we should deploy an instance in each specified region.

Are you deploying an Azure web app?

Not yet decided. Maybe we will have VMs with IIS installed.

What does your current deployment pipeline look like?

We have not yet finalized that. But, usually we will have Dev, Staging, Production environments. In production, we are planning to have an Environment per each region.

Then we have to select one approach out of following two alternatives,

  1. Create single Project for the product. Then create a Tenant for each customer. (as explained in original question.)
  2. Create a project for each customer.

Hope that helps you to get an idea on our concerns. If you need more information feel free to ask.

What do you think about above approach?

We didn’t see any use case to utilize Cloud Regions with above approach. Do you think we should use that?

Also if we go with one of above approaches, when we deploy for a given tenant, would it be possible to simultaneously deploy to all the assigned environments for that tenant?

4

Any feedback on this?

5

Hi,

I’m very sorry for the delay in responding to you here. I’m currently looking into your options here and what will work best. I’ll have a response for you ASAP.

Best regards,
Daniel

6

Hi,

So I have some information here that should give you a good idea of your options here and what should work for you.

As per your notes, it does look like Tenants + tentacles(or cloud regions if azure web apps) & roles will be your best option here if you are using VM’s.

I set this up in my VM and it looks to work fine on my end.

Project for the product looks like the way to go here with a tenant for each customer. I believe that creating a project for each customer would be a bit cumbersome here and add unnecessary complication.

You are unable to deploy to multiple environments during a tenanted deployment, however, this should not be an issue if you are following the method below. A single production environment should be all you need.

If you are deploying to a VM with IIS, you can create your targets in the environment and tag them with roles. Region1 - Region3 - Region3. (See tenant.jpg)

The use for cloud regions would be if you were deploying an Azure web app, you can have a single environment with three cloud regions. These can also be tagged Region1 - 2 & 3. Cloud targets are useful for targets which need to run scripts on the Octopus server (Like Azure web apps)

I think you should give your approach a try, with a single environment for production with your deployments targets tagged for each region as above. You are able to select tenants on each target to control which regions are selected when you deploy to the tenant.

In your projects deployment process, you are able to select tenants for each step, this will give you control over which step should be run for each tenant. Combined with tenant specific variables, you should have all the control you need for your deployments.

You have probably already seen this, but with the chance that you have not, it is a very in depth source of information regarding tenanted deployments:

https://octopus.com/docs/guides/multi-tenant-deployments/multi-tena…

If you have any further specific questions here that I may not have answered in the above, please don’t hesitate to let me know, I’ll be sure to answer them with less delay in the future. :slight_smile:

Let me know how you go here, I’ll be interested to hear your results.

Best regards,
Daniel

tenant.JPG

7

Hi Daniel,

Thank you very much for your reply.

I actually tested following approach by the time I get this response.

Environment per cloud region, project for the product and tenant per customer. This seems to be working fine.

Overall, what are the pros/cons on this approach compared to the approach mentioned by you?

Furthermore, as you said there is no option to deploy multiple environments via Octopus Web UI (with above approach).
However, I managed to mimic that using the Octopus.Client. (sending deployment request per region) Do you see any disadvantage by doing so?

Beat Regards,
Sampath

8

Hi Sampath,

Thanks for getting back. It sounds like your method is working, so that’s great. Ill try not to confuse you too much with the following. :slight_smile:

I believe the benefit to the approach I mentioned is not requiring the use of the API for deploying to each target at once. Having them all in the same environment means you can deploy your tenants in any configuration to multiple “Cloud regions” and have them configured via your tenant specific variables.

The method I proposed is for a single environment like Prod. You could still deploy region 1, 2, & 3 at the same time, it would look like this: (I tried modelling this off your initial post’s configuration)

Environment - Prod
Cloud Region - Region1 - Machine Role - Region1 - Tenant - Tenant1 | Tenant2 | Tenant 3
Cloud Region - Region2 - Machine Role - Region2 - Tenant - Tenant1 | Tenant3
Cloud Region - Region3 - Machine Role - Region3 - Tenant - Tenant2

Creating a release for Prod where your deployment steps are scoped to their respective role(s) (Region1 - Region2 - Region3) would deploy each step to the matching role in the environment/tenant selected. If a step needs to be run on all three regions, you can specify all three region machine roles.

So if I create a release and select to deploy to the Prod environment for Tenant1 & Tenant3, my deployment will run on the cloud targets Region1 & Region2, running all steps that have the Region1 & Region2 machine role and gaining all relevant scoped variables. This allows you complete customization over your deployments. This method also conforms more to how our dashboard displays relevant information regarding your deployments.

The benefit of the above method is the ability to easily configure who gets what and modify the scale of your deployments.

If you have any further questions here or if I have made things confusing, please don’t hesitate to let me know. I’ll be happy to model this up on my VM and give you some screenshots showing my implementation.

Best regards,
Daniel