Reset GCP migration settings

From GCP to GCP

GCP gives you 300 credits for free, so I think it's really good for initially creating a POC or doing simple cloud testing. I decided to use Gemini because I wanted to create a service that would allow me to simply apply what I learned during Google Study Jam. I used Gemini and deployed the project on GCP, which allows credits for free. Recently, after using up all the credits, I changed the account and tried to apply them again. I briefly considered migrating to AWS, but considering cost and service uniformity, I decided it would be right to use GCP again.

During the first deployment, I encountered various issues and recorded them all in Obsidian, but there were many issues that came from lack of learning, as if I was just starting from scratch, so I had a lot of trouble posting on the tech blog. I would like to take this opportunity to write down the GCP migration process one by one.

What is your current project?

The target project structure is as follows. Since it is currently a backend-only service, the project structure is simple.

• Deploy the Docker image to Artifact Registry using GitHub Action and then deploy to GCE.
• SSL authentication on the load balancer enables service using HTTPS.
• DNS settings are also set for Gabia domains purchased in advance.
• The load balancer increases instances depending on the situation to respond to issues flexibly.
• Security is processed using VPC network settings rather than default.

Super simple migration

In fact, there is a way to transfer the project to another account within GCP, but when the free service ended, access to the project was blocked and it did not work, so I chose to set it up again. So, in the end, I wrote it as migration, but it is the same as just recreating(?). You can specify the order arbitrarily, but I wrote it in a way that I became familiar with after deploying to GCP several times.

1. Setting up IAM

First, set up IAM. To apply the service account to GCE, grant the relevant Artifact Registry, Cloud SQL, Compute Instance Manager (v1), and Vertex AI permissions. Depending on usage, a manager or leader was selected. Here, Artifact Registry is where Docker images are uploaded, and Cloud SQL used Postgresql as the database. Vertex AI has added features to the API required to use Gemini.

2. Create a VPC

There are many people who say that you should never use the default values provided by GCP for network settings, so I made a new one to apply to this project. First, open TCP 443, 22, and 8080 as firewall ingress ports and add them while checking as needed. Getting Started with VPC Networking and Google Compute Engine, so you can get a feel for it by using it, so it is very helpful to look for documents or courses like this. After setting, check whether it is set properly with telnet.

3. Create an instance

When you create a GCE instance, you can immediately create an instance group, so create an instance to be used as a template. Set the basic OS and capacity, and in the networking section, write the same name as the previously opened port so that it can be applied as the target port. When deploying a container, I previously tried to process .env with GitHub Action, but instead of that, it is better to set the GCE container environment variables directly as discussed in [How to take environment variables?]({{site.baseurl}}/devops/2023/05/08/DevOps.html#Environment variables-How to take them). This is because you can view previously written details and set it so that it can be automatically set as an instance template by the load balancer. The network tag part is really important here. If you do not add it when setting the health check on the load balancer later, only no health upstream will be displayed and it will not work properly. More details will be added later in the load balancer section.

Once settings are complete, you can create a template and group simultaneously by clicking the Create instance group based on this VM button at the top. At this time, check the access scope in ID and API access one more time to prevent any unfortunate events such as 🚴 Vertex AI integration issue in GCE. In the Firewall section, select ‘Allow HTTP traffic’, ‘Allow HTTPS traffic’, and ‘Allow load balancer health checks’. In the instance group configuration section, specify how much the number of instances will be automatically expanded when connection is not possible in the 'Automatic expansion' section.

4. Setting up domain and load balancer

Register the prepared domain in the Cloud DNS zone. After creating a zone, register a name server (NS) as a standard addition and add a subdomain of type A to make requests starting with www and api.

• An A record associates an IPv4 address and an AAAA record associates an IPv6 address.
• CNAME records can be used to alias a domain or redirect to another domain.
• MX records are servers that receive emails, and TXT records store random text information related to the domain.
• NS records contain the names of name servers hosted by your domain registrar. It is generally managed with multiple name servers to improve availability and performance by distributing the load and deploying it in multiple locations.

If you need to Process SSL within a project or manage certificates for individual instances, it is too cumbersome and has the disadvantage of having to be replaced for a certain period of time (in the case of 90-day certificates that can be used for free). Therefore, after verifying authentication through the load balancer using Google Managed SSL, we decided to open an http port in the backend service to communicate.

There is a good guide for load balancer in official document, so I applied it in order. Initially, only the group and template settings were based on the default instance, so there are some parts applied differently, but the overall flow is the same. In the frontend configuration, connect the Google-managed certificate using the HTTPS (including HTTP/2 and HTTP/3) protocol. In the backend service, we connected the instance group created earlier and set up the cache and status check. Autoscaling was based on a target CPU utilization of 60%, but because we were using very small instances, scaling occurred even if it was slightly slow, so we recreated the template by increasing the ratio and increasing instance performance. Once complete, you will see a new instance created by the template. At this time, open the instance created in Cloud SQL and set it up to avoid hassle by reserving a static IP.