Add in HTTPS
See cert-manager.io. In any case, DigitalOcean offers a free certificate, enabling and using it is not difficult.
We will only do it in the production environment, it is not necessary for the development environment.
Microservices with Node JS and React (Next.js + Kubernetes)
Source Code Download
Current situation
My free trial with Google Cloud has ended …
My free trial with Google Cloud has ended but we can continue with the DigitalOcean free trial.
We are going to continue working on the project that we have talked about in this post (Next.js + Kubernetes). Now, let’s imagine that we will have several teams working on our project.
Every time they make some changes to the services, we should expect that those changes will be deployed into some production Kubernetes cluster.
This is a little diagram or a workflow that many engineers used in many projects and it is the workflow that we are going to follow to achieve what we want.
What do we want to do?
DigitalOcean
GitHub Repo
Mono Repo Approach
It might seem like it makes a lot of sense to create a single git for each service. But you’re going to see that in reality what a lot of different companies do, they actually trend towards using a single repository to track all the code inside of their project.
Repo-Per-Service Approach
Every single time that you create a new git repository, there’s actually a lot of overhead that goes along with that. You have to create a separate repository, you might have to create a separate set of authentication keys just to get access to that repository, and you have to set up a separate CI and CD pipeline. There’s a lot of work that goes into creating each of these Git repositories when we’re working with microservices.
ADD IN HTTPS
SSL Certificates
In this link, you can find documentation on how to activate an SSL certificate in DigitalOcean. On the other hand, DigitalOcean offers a free Let’s Encrypt type certificate, it is easy to activate and use. We have activated it in the production environment, for this environment we have created a cluster and the branch associated with it is the main branch.
In the file that deploys the load balancer, you can see the configuration of the certificate.
DEV and PROD environments
Run a Github Action: Running Tests on PR Creation
GitHub Actions makes it easy to automate all your software workflows.
We’ve added code to our own GitHub repository to make sure our tests run every time we create a new pull request to merge the code into our main branch, let’s take a look at one quick diagram.
Every time a pull request is created the test must be passed correctly to allow the merging of the code into the main branch.
Creating a Hosted Cluster
2 clusters have been created, one for the production environment and the other for the development environment. Code belonging to the production environment is in the main branch and code belonging to the development branch is in the development branch.
In another post, we have already talked about how to connect to the context of a Google Cloud Kubernetes cluster. In this case, it will be with a DigitalOcean K8 cluster which is very similar.
After creating the cluster, the DigitalOcean pages will give you all the instructions to install the necessary tools.
The Deployment Plan
Add in an additional Dockerfile to build each service before deployment (this is the code before applying these changes, it is in another repository and deployed in Google Cloud).
In each service, we have created an additional Dockerfile for each service. The main branch will be the branch associated with the production environment, and this Dockerfile is the one that will build the images for this environment. “Dockerfile.dev” is the one that will build the images for the development environment.
Our digital ocean clusters are up and running, we can connect to them, and now it’s time to start deploying our application to them. I’m going to show you a diagram that’s going to outline how we are going to use a GitHub action workflow to automatically deploy all of our different services to this running cluster.
So, in total, we’re going to have about fourteen different workflow files. Seven for the production environment and seven for the development environment. In each of these different workflow files, we are going to have a little bit of configuration that’s going to run any time we merge a pull request into the master branch or push code to the development branch.
We can do that very easily by creating a separate workflow for each of our different services. Now, beyond each of our services, we also have that set of Kubernetes config files, which is where we create all of our different actual services, where we define our ingress service, and where we also define all the different deployments themselves.
Summary
All of what we have discussed in this post is a generic vision of what we have done. If you are a programmer, you will end up understanding everything better by reading the existing code. You can even create an account on DigitalOcean and try to deploy this code in your Kubernetes environment. I hope the video I created and posted at the top of the post will help you better understand everything we’ve done. If you wish, you can always ask us, and we will try to give you an answer.
Deploy a Next.js App to App Platform
Thank you so much for your attention.
Maybe I should have called it the STAGE environment and not the DEV environment.
Difference Between Development, Stage, And Production.
https://dev.to/flippedcoding/difference-between-development-stage-and-production-d0p