How I switched the domain names of Laravel Apps hosted on the Google Cloud Platform: Learn and Save time
My journey as a self-taught developer began with a burning curiosity. Growing up in Uganda, where resources were scarce, I couldn't afford a formal education. Instead, I relied on handwritten notes from friends and online tutorials. As time went on, I got good at building websites for local businesses, each project proving my self-taught skills. But my dream of joining a major tech company seemed unreachable. Rejections piled up, all due to my academic background and self-doubt crept in. Then, a turning point. A friend I had shared my knowledge with landed a job at a promising startup in Kampala. He believed in me and recommended me. For five years now, I've been working remotely for that very company. They saw the potential in passionate, self-taught talent. But my heart is saddened by the millions in Uganda and the world facing the same challenges. That's why I am sharing my knowledge on this platform and other social platforms. My expertise is in PHP, JavaScript, WordPress, Technical Writing and business leadership. If you want to learn from me or collaborate, consider to follow or send me a on X.com/davidofug
At a certain company, we developed a B2B web application and a mobile application. The web application also serves as the REST API to integrate the mobile app. The web application was developed using Laravel. And we deployed this web application on a Compute engine (CE) in the Google Cloud Platform (GCP).
So recently, we developed a new major version, code-named version 2, of the web application and the API. To put version 2 to the test, we published it to the public through a subdomain such as v2.patasente.me and we left the older version accessible via patasente.me
Fortunately, the users have liked version two of the system; hence, there is a need to change domain names so that the newer major version will be on patasente.me, whereas the older version will be on v1.patasente.me I have two systems:
Steps I will most likely take to achieve the goal.
I believe the following are the steps that I will have to perform to ensure that we server the newer version through a patasente.me and the older version through a v1.patasente.me sub-domain with minimal or no downtime at all.
First of all, I want to avoid as much downtime as possible. I want the system to be accessible throughout the process. The good thing is that both the old and new versions store and access data in the same database. That means if a user is using an old version or a new version, we are not worried about Data loss and synchronisation.
Create v1.patasente.me sub-domain at the domain registrar and point it to the public IP address of GCP CE instance. To do this, I will have to login to our godaddy.com account and choose the patasente.me domain name, then go to DNS and add a new A record. Since the value of the A record is the public IP address of the CE instance, I can access this from the GCP Instances listing page.
Access the CE instance via SSH. I will use the GCP's web based SSH to avoid extra steps of setting SSH client and keys.
Rename the web directory from patasente.me to v1.patasent.me and ensure that the file permissions and ownership are intact otherwise reset them.
Rename the web directory from v2.patasente.me to patasente.me and ensure that the file permissions and ownership are intact otherwise reset them.
Rename /etc/apache/sites-available/patasente.me.conf to /etc/apache/sites-available/v1.patasente.me.conf
Edit and set webroot in /etc/apache/v1.patasente.me.conf to /var/www/domains/v1.patasente.me
Disable v2.patasente.me in apache
Enable v1.patasente.me in apache
Restart Apache, and if everything is good, proceed to the next steps.
Generate an SSL certificate for v1.patasente.me domain
Delete the v2.patasente.me SSL certificates to declutter the CE Instance of unnecessary files and avoid errors at the point of renewing SSL certificates.
