DrenSokoli

Kubernetes - Current setup

Currently, we’re deploying our Vue.js static page frontend app to Kubernetes, a platform for managing containerized workloads and services. Kubernetes allows us to scale our app horizontally, automate deployments and updates, and manage our app’s resources and configuration. However, Kubernetes also comes with some challenges, such as complexity, cost, and security.

We deploy our app to 4 different environments - testing, development, staging and production. These deployments are managed through Azure DevOps build and release pipelines, which add complexity and cost of implementation to our infrastructure.

Another downside of deploying a frontend app to Kubernetes is poor reachability from users. Since Kubernetes runs your app on a centralized server or cluster, your app may suffer from high latency and slow loading times for users who are far away from the server location. This can negatively affect your app’s user experience and performance. Moreover, if your server or cluster goes down or gets overloaded, your app may become unavailable or unreliable for your users.

Overall, deploying a frontend app to Kubernetes has some advantages, such as scalability, automation, and resource management. However, it also has some disadvantages, such as complexity, cost, security, and reachability. Depending on your app’s requirements and goals, you may want to consider other deployment options that can offer better simplicity, speed, and security for your frontend app. One of these options is CloudFlare Pages, which we will discuss in the next section.

CloudFlare Pages

CloudFlare Pages is a platform for building and deploying fast and secure web applications. CloudFlare Pages offers several benefits over Kubernetes, such as:

CloudFlare Pages is a platform for building and deploying fast and secure web applications. It is based on the JAMstack architecture, which stands for JavaScript, APIs, and Markup. JAMstack applications are composed of static files that can be served from a global network of edge servers, without relying on traditional web servers or databases.

CloudFlare Pages lets you connect your GitHub or GitLab repository and automatically builds and deploys your web application on every commit. You can use any frontend framework or tool that you like, such as React, Vue, Gatsby, or Hugo. CloudFlare Pages also provides unique preview URLs for each commit and pull request, so you can easily share and test your changes before deploying them to production.

CloudFlare Pages offers several benefits over other deployment options, such as:

Simplicity: You don’t need to worry about managing containers, clusters, or infrastructure. You just need to connect your GitHub repository and CloudFlare Pages will handle the rest.
Speed: CloudFlare Pages builds and deploys your app in seconds, using Vite 3 , a next-generation build tool for front-end developers. Vite 3 offers faster development, hot module replacement, and code splitting out of the box.
Scalability: CloudFlare Pages automatically scales your app to handle any amount of traffic, using CloudFlare’s global network of edge servers. Your app will be served from the closest location to your users, ensuring low latency and high performance.
Security: CloudFlare Pages protects your app from malicious attacks, using CloudFlare’s built-in security features such as SSL encryption, DDoS mitigation, and firewall rules.

Because of these reasons we decided to migrate our deployment strategy to CloudFlare Pages. In the next section, we will provide a step-by-step guide on how to deploy a Vue.js app to CloudFlare Pages and explain the benefits of this deployment option.

Requirements

Before we start with the deployment process, we need to make sure we meet the following requirements:

A frontend app hosted on GitHub or GitLab
A CloudFlare account (free)
A custom domain or subdomain to use with your app (optional)

Overview

Let’s start. Deploying a Vue.js application using CloudFlare Pages is relatively easy, so we’ll skim through it.

Navigate to https://dash.cloudflare.com and login to your dashboard or create an account if you haven’t already. Go to Workers & Pages and click on Create Application. Navigate to the Pages tab and click on Connect to Git. Choose the repository you wish to deploy.

Configure the app build and deployment configuration on the next screen by choosing the necessary options like production branch, framework preset, build command, build output directory and environment variables (if any). Click on Save and Deploy and that’s it. Your frontend app is ready to be viewed on the web.

Let’s take a look at some problems my team and I found ourselves in when trying to migrate from Kubernetes to CloudFlare Pages.

Problems we faced and solutions

We faced some difficulties when migrating to CloudFlare Pages, which increased the complexity of this deployment strategy for us.

Version Control

Initially, our source code is not hosted in GitHub nor GitLab, which as we already learned is a requirement to create deployments in CloudFlare Pages. We host our source code in Azure Repo and we planned to keep using it as our version control. The solution we came up with included creating a private repository in GitHub nevertheless and creating build pipelines in Azure DevOps that get triggered on branch merges and mirror the respective branches to the GitHub repository, which connects to CloudFlare Pages.

The build pipeline consists of only one Command Line Task with the following contents:

# Delete the existing mirror clone if any
rm -rf $(REPO_DIR)

# Clone the Azure Repo with the --single-branch option to get only the current branch
git clone --mirror --single-branch --branch $(BRANCH_NAME) https://$(AZURE_TOKEN)@dev.azure.com/<AZURE_ORG>/<AZURE_PROJECT>/_git/<AZURE_REPO>

# Change directory to the mirror clone
cd $(REPO_DIR)

# Add the GitHub repo as a remote with the --mirror=fetch option
git remote add --mirror=fetch secondary https://$(GITHUB_TOKEN)@github.com/<GITHUB_USER>/$(GITHUB_REPO)

# Fetch the origin branch
git fetch origin

# Push the current branch to the secondary remote
git push secondary $(BRANCH_NAME)

You can write the variables as static values directly in the Command Line Task but I don’t recommend it and I suggest that you create them as Environment Variables. Read more

Deploying multiple environments from monorepo

Another issue we faced was deploying multiple environments (testing, development, staging and production) based on different branches of the same repo which have different source code and that need to be accessed on individual static domains. CloudFlare Pages does not support this feature (although apparently it’s in the roadmap 🙄). It only supports creating two environments - production (for which you can assign a custom domain) and preview (which creates a new domain with a hash prefix for each deployment) so we had to come up with an ugly but creative solution.

We created a GitHub repository for each branch (environment) we wanted to deploy and connected these repositories to their respective branch of our single Azure Repo through the build pipelines that we mentioned earlier. Then we created a CloudFlare Page for each GitHub repository which allowed us to create custom domains for each environment.

Sources on this feature:

Other workaround

Another solution we considered was to create a worker that checks every time a preview deployment is created, fetches the domain for that preview deployment and its associated branch and changes the content of a dns record for a custom domain (e.g. stg.example.com) that i have created beforehand to this new preview deployment domain through the CloudFlare API. This aproach has its advantages and and dissadvantages.

Its main advantage is that it somewhat reduces the complexity of this workflow by removing the need for creating multiple GitHub repos for a single project.

Some of the downsides are:

You will need to pay for the worker usage, which depends on the number of requests, CPU time, and KV operations.
You will need to handle errors and failures in your worker code, such as network issues, API rate limits, or invalid responses.
There may be some delay or inconsistency in the DNS propagation, depending on the TTL value and the caching behavior of different DNS resolvers.
There may be some downtime or broken links for your custom domain until the DNS record is updated and the new preview deployment is ready.
There may be some conflicts or confusion if you have multiple workers or scripts that try to modify the same DNS record.

This didn’t prove to be the right solution to this problem.

Conclusion

In this document, we have discussed the current setup of deploying our Vue.js app to Kubernetes, and the reasons why we decided to change our deployment strategy to CloudFlare Pages.

Despite the added complexity from these challenges, we found CloudFlare Pages to be a great choice for us. We have seen that CloudFlare Pages offers a simpler, faster, more scalable, and more secure way of building and deploying web applications that enhances user experience. By using CloudFlare Pages, we can focus on developing our frontend app, without worrying about the backend infrastructure.

Deploying Vue.js app to CloudFlare Pages