How to set up a multi-cloud GitLab deployment

This is a guest post by Geoff Sullivan, who's responsible for business development at MOBIA Technology Innovations’ Cloud Practice based in Montreal, Quebec. Geoff works with organizations to help them deliver more value to their customers more efficiently, through the use of modern cloud technologies.

Last week’s GitHub outage proved to the world that even the most modern, high-tech unicorns are not immune to outages. The outage showed us how critical it is to architect your cloud apps with built-in resilience, in expectation of unforeseen outages.

Leveraging multi-cloud architecture, or spanning apps or components of apps across multiple public cloud providers reduces risk, and minimizes downtime when a cloud provider experiences an outage. Cloud 66, DevOps-as-a-service provides a Failover Groups functionality that allows you to quickly switch traffic between stacks hosted on different providers in the case of an outage.

Here’s a quick tutorial to show how you can setup a multi-cloud GitLab deployment using Cloud 66 Failover Groups.

Deploy Gitlab with the EasyDeploy App Store

In the Cloud 66 dashboard deploy a new GitLab stack from the EasyDeploy App Store.

Once the code has been analyzed, you will have to select where to deploy the primary GitLab stack. For this tutorial, I'll use my friends over at Cloud-A.

The deployment process will take about 20 minutes, and Cloud 66 will send you an email when it's been successfully deployed.

Configuring a Failover Groups

Cloud 66 defines a Failover Group as a managed quick response DNS address that automatically follows your stack web endpoints. You can connect it to up to 2 stacks at any time - a primary and backup stack. Should you need to switch traffic between your stacks, simply flip the switch and your traffic will flow to the backup stack within 5 minutes.

There are three elements that we will have to consider when creating Failover Groups. The first is the application’s code. You'll want to make sure that your primary and backup stacks are very similar - for this example I will clone the primary stack.

Cloning your GitLab Stack

In your stack page you'll select " Clone this stack" from the sidebar on the right-hand side of the screen. This will allow you to choose a new stack name and environment. Cloning your stack will preserve any environment variables from the existing stack, and also allows you to define where to deploy to, along with other settings.

Cloud 66 will go through the code analysis step once again, and then you'll be required to make the same deployment decisions that you made when you deployed your production environment. For this tutorial, I will deploy our failover stack to Digital Ocean’s Toronto region.

Data Replication

You'll want to setup a master/slave database architecture to ensure your data is replicated between your primary and failover stacks. To achieve this, we'll enable database replication between the stacks. Cloud 66 supports database replication for MySQL, PostgreSQL, Redis and MongoDB databases. For more information on Cloud 66 database replication check out their database replication docs here.

In order to replicate your failover stack, you'll need to configure managed backups on your databases.

Once backups have been configured, in your stack detail page, click on the database server group (eg. PostgreSQL server), and click into your main database server page. Next, click " Configure Data Replication" in the right sidebar, and select a source stack. Confirm to commence the replication process.

Create Failover Groups

In your main stack page, select “ Failover Groups.” Once on the Failover Groups page select “ Add a Failover Groups.” Select your primary stack as the “ Primary Stack ” and select your failover stack as the “ Backup Stack.”

Select " Add Group"

Handling an Outage (Switching Traffic)

Once you've properly setup your primary and backup stacks, and the databases are replicated, you can use the Failover Groups tab to switch traffic in the case of an outage. The following is how Cloud 66 recommends using the Failover Groups to deal with an outage:

If and when your main stack fails, you'll need to switch to the failover stack.

1. Set your main stack into maintenance mode, to prevent new data being written to it.
2. Turn off the database replication.
3. Make your database slave a master (postgresql-failover-procedure)- this will allow data to be written to the database.
4. Turn off maintenance mode on your failover stack.
5. Use your Failover Groups menu to switch your traffic to the failover stack. The TTL on the Failover address is 5 minutes, so you should see your users on the new stack momentarily.

Adopting A Multi-Cloud Strategy Moving Forward

While Cloud 66 may not be the only option out there to implement multi-cloud functionality, they do a really good job at providing an easy-to-use toolkit with all the necessary orchestration components needed. If you haven’t already checked them out, sign up for a 14-day free trial and use the onboarding tips to deploy your first stack.