Forem: Shawn Gestupa

Improving on DevOps with Kubernetes, Helm, and GitOps

Shawn Gestupa — Sun, 12 Apr 2026 02:54:30 +0000

For the past few weeks, I shifted my focus on building a three-tier application declaratively with Kubernetes, making it more configurable with Helm, and implementing GitOps with ArgoCD for automated deployments:

With the added help of Prometheus and Grafana deployed via Helm, I was also able to improve the observability of my application. Loki and Tempo were also implemented to enhance log tracing within my cluster.

In one of my posts, I've mentioned the growing demand for containerization skills, which was why I decided to learn more about Docker, and even tinker with it, as a way to further understand containers.

Adding my previous experience in GitOps where I started by building CI/CD pipelines, the training experience was smooth and made me truly believe that I'm getting closer to my aspirations after passing it.

Improving my DevOps skills

Disclaimer: I didn't link my repositories used for the training, since I'm not sure if I'm allowed to and the training was held internally by my employer as of writing.

Unfortunately, I had to temporarily postpone getting for certificates, but on the bright side, I was given the opportunity to improve my principles on DevOps engineering.

I've learned that DevOps engineering is more than just containerizing apps or automating deployments: it's about having a proactive mindset. Creating systems where problems can be mitigated before it reach customers with the use of automation & observability, turns a proactive engineer to react in real-time and to be constantly looking for bottlenecks/improvements.

Embracing the DevOps philosophy allows us to think that the systems we're building will never be "finished".

Throughout the training, I've spent most of my time reducing human error -- or my own error -- by making sure my progress is recorded with Git to complement my declarative configurations that I use to setup my local Kubernetes cluster with just a single command; I actually created three GitLab repositories for my architecture, one each for: Application code; Kubernetes manifests, with Helm charts; and ArgoCD configurations.

I've also leveraged the use of Helm charts to conveniently deploy not only my application, but the systems necessary for observability & GitOps, such as Prometheus, Grafana, and ArgoCD.

Then, I integrated Helm with my local ArgoCD to continuously monitor services due to its self-healing, continuous delivery, and additional monitoring capabilities.

Lastly, I linked all three of my repositories with their own deployment pipeline to commit to a true continuous integration (CI), continuous delivery (CD) setup:

My application code's repository with source codes for frontend & backend will create a merge request to the repository where my Helm charts are located to update the respective tag of an image used by either frontend or backend, though, only if their respective source code was updated, otherwise, no merge request will be made and only the Static Application Security Testing (SAST) job will run.

I've chosen to manually approve the merge requests, instead of directly pushing the changes, since I wanted to visualize working in a team where requests must be reviewed & approved before their deployment to production, and this opportunity allowed me to easily comprehend how my deployment pipeline works from one repository to another.

ArgoCD will be pulling the changes in a repository every 3 minutes, where it will then automatically deploy the new changes to respective systems without human intervention.

The journey was quite exhilarating, for it gave me new insights on how to solve more complex problems with creative solutions by actively utilizing my past experiences to continuously improve my architecture, which may be lacking in some way, but thanks to what I've learned in the training, it'll be easier to discover, learn, and understand what I'm missing out where I can apply improvements on the next system that I'm trusted to build.

Some tinkering with Docker

I've used Docker with Kubernetes, and considering I had previous experience with the former, it was easy to digest the provided Docker-related resources for the training, to the point I'm watching related YouTube videos in twice the normal playback speed.

My three-tier application with the frontend (presentation layer), backend (logic layer), and database (data layer), are all deployed with Docker, while the data layer uses an external Postgres image from the Docker Hub registry.

The backend was a Node application that was used to setup APIs, with the help of Express, for the frontend where it was simply a single-paged React application that connects to the former via an environment variable by default.

I also opted to use Alpine variants of Docker images as much as I can to reduce the resources used by containers, as well as speed up the provisioning of my three-tier application.

In addition, both the frontend & backend were initially deployed with root privileges, meaning anyone with access to their respective containers control them. I sought to improve the security posture of my application by creating separate Dockerfile files for both dev (also used for testing) & prod environments, where the Dockerfile for the prod will be using a non-root user, which greatly mitigates the risks of container breakout or impacts of an attacker inside the container.

The initial Dockerfile of the frontend was using a Node image for deployment, however, I leveraged an Nginx configuration file -- which was already included in the initial training repository -- to implement a multi-stage build where the deployment stage will be using a non-privileged Nginx image, specifically the nginxinc/nginx-unprivileged image, while only moving the necessary files from build to reduce the final image size of my container.

Despite not being required by the training itself, it didn't feel right to me to keep the three-tier application "as-is" when I knew that I had the means to improve it, starting with its security.

As usual, I still had my own share of problems with Docker:

The frontend encountered host `backend` is not reachable error when it was trying to reach the backend's API server thru Nginx, which was why I had to provision my backend right after the database.
I had a hard time changing the value of the frontend's environment variable specifically for the prod Dockerfile, and apparently I had to add an ENV or ARG with the correct value to the the said environment variable because the correct value wasn't used during build-time and simply uses the fallback value specified in the source code.

My struggles with Kubernetes

When I was learning Kubernetes for the first time, I was struggling to digest the information, where I decided to document instead everything I've learned I've learned to the point my notes reached more than 20,000 lines and took me twice the time compared to when I was refreshing my knowledge on Docker.

For my cluster, I opted to use k3d, a lightweight wrapper to run k3s, which I believed to be a great way to start learning without worrying too much on the resource overhead.

My strategy for Kubernetes was to replicate how I deployed my three-tier application previously, by building the necessary manifests:

Using either ConfigMap (for non-sensitive values) or Secret (for sensitive credentials) to match the environment variables from docker-compose.yaml.
Replacing volume mounting of Docker from volumes to Kubernetes' VolumeMounts, with PersistentVolume & PersistentVolumeClaim for external volume creation.
Mirroring the Docker's healthcheck with Kubernetes' livenessProbe, as well as to add the ability for the latter to check if an application is ready with readinessProbe.
Connecting Kubernetes' deployments with Service -- by default are in ClusterIP type -- to mimic private connectivity within Docker Compose.
Ingress services were explicitly used for public-facing applications, similar to mapping an available host port to an internal port of a Docker container in order for it to be accessed from the host machine.

Nevertheless, learning Kubernetes allowed me to equip the knowledge to move from a simple deployment with Docker to having a complex yet flexible, scalable deployments, such as when to choose between Deployment or StatefulSet.

Of course, I don't think I'm learning when I didn't have problems:

I had to expose k3d with --api-port 127.0.0.1:<PORT> to map it to my localhost, otherwise, my Docker Desktop's kubectl won't be able to communicate to the cluster's API server.
A slight difference between Docker and Kubernetes when running a command inside a container/pod from a terminal, where I had to add -- before the command I want to run inside, as well as avoiding the / prefix on the command because it pointed to my local directory instead the command inside the container.
Encountered the One or more containers do not have resources error once made me always add limits on how much resources my deployments can use.
Deleting persistent volumes should be done right after deleting the persistent volume's claims, since I unknowingly waited longer than I needed to be when I deleted the volumes first.
I had an issue where I couldn't correctly mount a SQL file specifically for initialization when I pasted the contents of the said file within ConfigMap, so I opted to visualize how the contents should be added with kubectl create configmap init-sql --from-file=init.sql=./init.sql -o YAML.
Encountered issues when creating Secret for sensitive environment variables with echo, where I should've used echo -n instead to ensure to omit newlines.

Optimizing my infrastructure with Helm

I built separate Kubernetes manifests for each layer in my three-tier application, with their own ConfigMap or Secret and services, which became redundant (for me) to deploy the same applications with similar configurations and risked misconfigurations due to separate files.

As part of my training, I had to learn Helm then understood how useful it is for consistent deployments, where it enabled me to install third-party applications, known as "charts", from registries to complement my deployments without manually creating the manifests myself -- charts are stored in registries, usually in Artifact Hub, similar to container images from Docker Hub registry; it acts as a "package manager", similar to NPM.

With helm create and some time of tinkering, I was able to migrate my manifests to Helm as a single package, allowing me to manage each layers thru a single file named values.yaml.

Working with Helm was a breeze, especially its reliance on the Go templating language which allowed me to control the flow of my deployments and inject/replace data in a single manifest used by all of the layers in my application, and in addition:

Helm is considered to be a "homebrew" (a package manager used in MacOS) to Kubernetes.
Helm is similar to third-party Terraform modules that simplify deployments and avoids maintaing multiple yet similar YAML files.
The values in a Helm chart differ between charts as they are entirely on the choice of their respective developers, which reading documentations as necessary as always.
We can avoid "snowflake servers/clusters" where software/packages are installed imperatively and making it hard to be re-built by opting to a declarative workflow with Helm where configures can be stored in a source control, which results in a "phoenix server".
A library chart is a "library" of functions shared across multiple charts, while an application chart is a collection of templates.
Go lang is used by Helm developers.
Functions in Helm are called "pipelines" and are similar to the built-in functions of Terraform, where a pipeline syntax can be used to combine multiple pipelines with the pipe (|) symbol: {{ .Values.globalNamespace | default "default" }}.
Template flow controls can be done with if-statements, such as {{ if .Values.development }}-dev{{ end }} or even {{ if .Values.development }}-dev{{ else }}-prod{{ end }}.
The templating language by default creates a new whitespace, and adding - inside the syntax, such as {{- end }}, avoids the creation of said whitespace.
Professional Helm templates can be huge and rely heavily on utilizing values/variables for declarative workflows which avoids hardcoding values.

I'm always open to encountering problems with Helm, because it will allow me to reinforce what I've learned to be creative with my solutions:

Some of my pods encountered ImagePullBackoff from Helm charts that I used, which meant that the chart may be outdated/non-existent, so I opted to look for alternatives, such as using Bitnami's MariaDB chart while the tutorials I've consumed were still using their MySQL chart.
There's a difference between indent and nindent when programmatically injecting data to my Helm templates, where the former only indents the first line while the latter indents all of the lines and making it to work as expected compared to the former.

After Helm, I started to use it heavily on my deployments which helped me reduce the risks of misconfigurations as much as possible.

Hands-off deployments with GitOps thru ArgoCD

In order to achieve the "continuous delivery" part of my architecture, I opted to deploy ArgoCD as a Helm chart and a required software to learn during my training.

ArgoCD was necessary to implement the GitOps framework, since majority of its capabilities are tied to Git repositories and permitting it to read my repositories allowed my deployments to self-heal whenever a critical component within them gets unhealthy, reducing the time it takes for them to be available.

Fortunately, Helm charts are compatible with ArgoCD, which was why I combined my three Git repositories and third-party Helm charts to setup my architecture with it; ArgoCD allowed me to come up with a creative solution to setup my architecture correctly, allowing me to learn:

An imperative setup introduces the risk of setting up snowflake servers/clusters, as well as having to extensively configure a cluster's RBAC and lacking visibility on the deployment status, whereas ArgoCD solves this by delegating access to Git repositories while providing visibility on deployed applications.
The best practice was to separate unrelated deployments in separate Git repositories instead in a single repository for everything, especially a separate repository for system configurations to reduce the risk of exposign sensitive credentials.
ArgoCD supports both Kubernetes manifests & Helm charts, combining the best of both worlds for deployments; ArgoCD is basically an extension of Kubernetes, then I used Helm to deploy it.
Git repositories must be synced with ArgoCD for continuous monitoring to allow applications have "easy rollback", where ArgoCD watches changes in those repositories and apply updates automatically, though it can be disabled and an alert can be sent instead for new changes.
ArgoCD can be used to control Kubernetes cluster -- by acting as an agent -- which can avoid providing external access to the a cluster, where management can be indirectly done thru Git repos.
Git repositories will be the desired while Kubernetes clusters will be the actual live state, and ArgoCD ensures the two to be in sync.

ArgoCD has its own external Custom Resource Definitions (CRDs), where my three-tier application as well as the necessary components for my Kubernetes cluster are deployed with Application manifests, especially for Helm charts that I choose to deploy that aren't in my Git repositories and updated default values inside the same manifest.

I did have my own fair share of problems when I was deploying with ArgoCD:

Before I can deploy my applications with ArgoCD, I had to deploy first ArgoCD since it contained the CRDs used for deployments, especially for Application manifests.
Had a hard time using my GitLab repository's Deploy Keys for my ArgoCD, which led me to read the documentation in order to use the correct syntax for SSH-related keys.

To avoid committing sensitive credentials in my Git repository for ArgoCD, I utilized External Secrets Operator to create a Kubernetes secret that syncs with an AWS Secrets Manager secret:

I'm aware that I could've used a webhook for immediate syncing between my Git repository and ArgoCD, though, that required additional setup than what was needed and I've taken note of this instead where I'll be implementing this in the future.

Enhancing observability starting with Prometheus & Grafana

The last part of my training was to implement Prometheus and Grafana to enhance the observability of my deployments, which I was able to do so as Helm charts deployed with ArgoCD.

Prometheus & Grafana were originally separate external Helm charts, however, I opted to use the kube-prometheus-stack chart which combines both of them in a single package. At first, kube-prometheus-stack was deployed as an external Helm chart, but throughout the training, I found myself needing more flexiblity to configure either Prometheus, Grafana, or any components included in the same chart, which was why I ended up adding it in my Git repository for Kubernetes manifests & Helm charts thru helm pull.

I also integrated Loki & Tempo as external Helm charts, to specifically enhance log tracing in my log applications.

Improving my cluster's observability allowed me to learn:

Prometheus can be used as a monitoring tool for highly, dynamic container environments or traditional, bare servers -- a mainstream monitoring solution of choice for containers and microservice architectures.
Used to constantly monitor all deployments/services in order to identify for problems before they occur, as well as check for containers' resource usage while setting a threshold to alert for breaches; automated monitoring & alerting can be achieved with observability-related components.
Usually, metrics can be retrieved from /metrics endpoint by default, where client libraries can expose the said endpoint to an application for many services don't have default native support for Prometheus.
Prometheus pulls metrics from targets, while Grafana can be used to visualize the said metrics to gain insights.
Other monitoring systems, such as AWS CloudWatch, use a push system that push data to a centralized collection platform which can result in high load of network traffic, in contrast to Prometheus where it uses a pull system -- a pull system can have better detection/insight since it'll know immediately if something is dead or not.
Prometheus can use the Alert Manager component (included in the kube-prometheus-stack chart) to notify respective recipients/communication channels.
PromQL can be used to communicate with the Prometheus server or specifically used for querying a target directly, which can be used by visualization tools, such as Grafana; PromQL can be used in the background when creating a Grafana dashboard.
Prometheus is designed to be reliable and meant to work with other services, even if one of them are broken which can result in a less complex & extensive setup, however, it can be difficult to scale or has limits on monitoring (can be solved by increasing the Prometheus server capacity or limit the number of metrics pulled).

My three-tier application wasn't initially designed to send metrics, which was why I enjoyed going back to programming when I implemented metrics for my frontend & backend: backend was setup with the prom-client Node library to create the metrics for both frontend & backend, then created a /metrics endpoint for it.

The prom-client library wasn't compatible with client side, especially when the frontend was deployed with Nginx. My solution for this was to basically send the data for its own metric to the /metrics endpoint of the backend via the fetch API:

The initial metrics for my frontend was simply to get the First Contentful Paint, which was retrieved from the web-vitals Node library, and the page load duration.

Since this was somewhat my first time dealing with Prometheus & Grafana, my problems with them allowed me to be resourceful:

I had to manually (in a declarative way) create a Service Monitor for my layers in order for Prometheus to retrieve their metrics, otherwise, Prometheus won't see them as targets.
I thought kube-prometheus-stack chart was incompatible with the Loki chart, and what I had to do was basically stop setting the latter to be the default data source since the former uses Prometheus as the default data source.
I had to add @opentelemetry/api and @opentelemetry/auto-instrumentations-node libraries in my Node applications in order for Tempo to retrieve their traces and output it within Grafana.

The journey ahead

I prioritized the DevOps training because I believed this will keep me ahead in this ever-changing field, where automation and efficiency are no longer optional, and I believe it was the right decision; I emerged from the training equipped with new, comprehensive knowledge and deeper insights into architecture and system design.

Combined with my existing knowledge in Cloud Engineering, the training also provided me the principles necessary to build a robust, scalable, and stable infrastructure that I can bring with me wherever I go, achieving the adaptability that I always aim to have.

I'm thankful for being given the opportunity to improve myself, as well as having the guidance of my seniors which gave me the confidence to finish the training.

Maybe I'll continue getting the AWS Associate CloudOps Engineer since I was in the middle of it when I was given the training and had to stop abruptly.

I originally planned to learn Kubernetes thru the DevOps with Kubernetes course from the same instructors of DevOps with Docker, but I still recommend the two courses despite not taking the Kubernetes one -- I'm acting upon my experience with the Docker course, because I had a great experience with that.

If you want to upskill in DevOps engineering: take your time with what you can digest, don't rush with what you're learning because it's important for you in the long-term to build the necessary principles organically.

Don't forget to believe in yourself!

Taking The Cloud Resume Challenge: GCP Style

Shawn Gestupa — Mon, 11 Aug 2025 12:10:43 +0000

What's self-learning without some challenges to shape us, hence for the past few weeks, I've taken upon The Cloud Resume Challenge by Forrest Brazeal and re-created my resume using Google Cloud services, instead of my usual cloud platform (nothing wrong with exploring a little hehe).

Feel free to checkout my recreated resume here: https://resume.smgestupa.dev -- this won't replace my resume in my portfolio website.

I followed most of the requirements/steps, except for steps 1. Certification (got too excited to do this), and 12. Infrastructure as Code (saving this for another blog post). Still, I was able to finish the challenge:

Disclaimer: this isn't a step-by-step guide, instead, it's focused more on my process, the decisions I made from researching. I do give out some tips on certain things, but finding something out yourself will always be better.

How did I start this?

This challenge tested me, especially when building the CI/CD pipeline for my repositories. Thankfully, I got to utilize my skills as a Full-Stack Developer to good use -- thanks to my previous clients who trusted me to build their theses, capstones, etc.

I went with SvelteKit to make everything easier for me (feel free to use what works for you to achieve your goal). I also used TailwindCSS' preflight script to reset the default browser styles to make styling super easy.

From there, I was able to recreate my original resume for steps 2. HTML and 3. CSS, though it's not an exact 1-to-1 match -- I did my best to keep the look somewhat similar, but things like the exact font and dimensions were hard to determine.

At first, everything was just running locally:

Since no one can visit what I've made, my next step was to deploy it with Google Cloud as a static website.

Enter Google Cloud

Before deploying, I had to activate the free $300 credits, since some services require billing to be enabled beforehand, such as the Cloud Storage which is used to host my recreated resume as a static website (as part of 4. Static Website).

Note: You may have to enable the Cloud Storage API before creating a bucket.

Hosting a static website with Cloud Storage was simple:

Create my bucket.
Select Uniform Access (as recommended by Google Cloud).
Upload my website files.
Disable the Prevent public access setting.
Add the allUsers principal with the Storage Legacy Object Reader permission.
Set the bucket's website configuration to point to index.html, and boom! I have a static website with HTTPS, for free!

The architecture for this deployment was:

My estimated cost for the GCS bucket is $0.00/month since my files are under a gigabyte, since storage in Singapore (asia-southeast1) incurs a $0.020/month per GB -- rates vary depending on the bucket's region.

But this was not enough, we can't expect visitors to remember a long domain, which is why my website will need a user-friendly URL and this can be done with Cloud DNS.

DNS

I created a managed zone in Cloud DNS for my subdomain: https://resume.smgestupa.dev/, as part of step 6. DNS.

Note: You may have to enable the Cloud DNS API before creating a managed zone.

But before that, I bought my own, personal domain (smgestupa.dev) which will be required for this step -- I paid $12.62 for one year, upfront. If you plan on purchasing a domain, decide as if you'll be using it for the rest of your life.

It's was also pretty easy to migrate my domain to Cloud DNS, specifically a subdomain since I don't want to migrate my whole domain to it.

If you don't plan on moving your whole domain (like mine!), then the process will be simple:

Look up the nameservers generated by your Cloud DNS.
Import the nameservers to your primary DNS management service.

After importing the nameservers, you'll have to create new DNS records in your managed zone moving forward.

Tip: you should consult your DNS management service's documentation for importing nameservers.

My estimated cost for a managed zone is $0.20/month

Load Balancing

As part of 5. HTTPS, I used a Cloud Load Balancer to add a user-friendly domain with HTTPS for my static website by linking it with my managed zone. It's also used to distribute user traffic.

Note: You may have to enable the Compute Engine API before creating a load balancer.

I deployed a public-facing, global load balancer with a rule that uses port 443 (for HTTPS) with a static IP address for the Frontend configuration, which will be used to map my subdomain to it. Since I'm using a managed zone, I secured the rule with a Google-managed SSL certificate.

For the Backend configuration, a backend bucket was created that points to my bucket that hosts the static website with Cloud CDN enabled.

Routing rules were left as-is. After finalizing my changes, I proceeded to create it and had to wait for a few seconds for the load balancer to initialize.

The architecture for this deployment was:

My estimated cost is $20.44/month, since my rule incurs $0.28/hour (for the first 5 rules) in Singapore. The rates will vary depending on the load balancer's region.

Database

For step 8. Database, I used a native, regional Firestore database to track the number of visits to my static website.

Note: You may have to enable the Cloud Firestore API before creating a database.

Firestore is a NoSQL document database that was easy to setup. In my case, I created two for each environment: production and staging.

The production database uses the (default) database, since Firestore has a free quota for this database and I believe will be useful to prevent incurring any extra charges.

Additionally, a named database is used for staging, since named databases have no free quota and will be useful for my pipelines.

My estimated total cost for my Firestore databases is $0.00/month, for I don't expect my production database to exceed the free quota while my pipelines call less than 10 operations per workflow.

Of course, I can't just directly give my static website permissions to modify my databases, which is why I created a Cloud Function as a "middle-man" -- we should always assume there will be malicious actors that will cause irreparable damage if they have direct access to a database (I don't want to get charged by Google Cloud hehe).

Function

To give a controlled way for my static website to increment the total visits, I provisioned a Python function (as part of steps 9. API & 10. Python).

Note: You may have to enable the Cloud Functions API before creating a function.

The process for my code was straightforward:

My static website sends a GET HTTP requests to my function.
The function increments the counter in Firestore by 1.
Right before the function returns a response, it retrieves the counter's value which is added to the response body.

I opted to use a first-generation environment for faster cold starts, while I configured the function to have a 128MiB RAM and 0.167 vCPU -- I believe my function does not need more to do simple operations.

An environment variable is also used to determine the Firestore database to be used, depending on the environment for my pipeline's testing job.

My estimated cost is $0.00/month, since the billing is request-based and I don't expect the function to invoke anywhere near a million per month.

For my static website, I created a new section to display the total number of visits. Additionally, a JavaScript code was added that will send a request to the function to increment the total visits, and display the new value from the response body.

The architecture for this deployment was:

Source Control

Of course, I didn't forget to use a source control for all of my code. I've always had the habit to create a repository before I start a new project.

For this challenge, I used GitHub (as part of step 13. Source Control) to store my front-end (static website) and back-end (Python function) in separate, private repositories.

Front-end

Manually building my website then uploading it to my bucket was good and all, for about 5 seconds. I realized that I'd be repeating this tedious process for weeks while doing this challenge, which is why I decided to setup a pipeline with GitHub Actions (as part of step 15. CI/CD (Front-end)).

For my pipeline, I created two workflows depending on the action:

Pull Request to `main` Branch

Use actions/setup-node@v4 to install NodeJS, which will be accessible for the whole runner.
Checkout to the repo with actions/checkout@v4, install pnpm, install dependencies then build, all with pnpm.

Push to `main` Branch

Use actions/setup-node@v4 to install NodeJS, which will be accessible for the whole runner.
Checkout to the repo with actions/checkout@v4, install pnpm, install dependencies then build, all with pnpm. The compiled code will be reused as an artifact via actions/upload-artifact@v4.
Authenticate to Google Cloud, setup gcloud CLI, and download the compiled code artifact with actions/download-artifact@v4. The artifact will then be uploaded to my bucket via gcloud storage cp.

Back-end

The Cloud Functions has an option to link a function to a repo, but I instead opted to manually setup my automation process (as part of step 14. CI/CD (Back-end)) so that I can deepen my understanding of pipelines a little bit more.

I also had a similar realization when working on my front-end repo, where I will repeatedly doing the tedious process of copy-and-pasting my code to update my function, leading me to build a new pipeline.

Additionally, I implemented unit testing (as part of step 11. Tests) for my pipelines:

Should return an HTTP 200 status code.
Should return an HTTP 200 status code, a counter should be in the response, and the counter should be greater than or equal to 0.
Should return an HTTP 204 status code, and includes Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers in the headers with these values:
- Access-Control-Allow-Origin: ['https://resume.smgestupa.dev']
- Access-Control-Allow-Methods: ['GET']
- Access-Control-Allow-Headers: ['Accept']
Should return an HTTP 200 status code, and Access-Control-Allow-Origin with ['https://resume.smgestupa.dev'].

Similar to the pipeline in my front-end repo, I created two workflows depending on the action:

Pull Request to `main` Branch

Update the FIRESTORE_DATABASE environment variable to point to the staging database, checkout to the repo with actions/checkout@v4, and run unit testing.

Push to `main` Branch

Update the FIRESTORE_DATABASE environment variable to point to the staging database, checkout to the repo with actions/checkout@v4, and run unit testing.
Checkout to the repo with actions/checkout@v4, authenticate to Google Cloud, setup gcloud CLI, create a build folder, copy the main.py and requirements.txt inside the build folder, and update the function via gcloud run deploy.

CI/CD

I made heavy use of compose actions to reuse repetitive steps, like authenticating to Google Cloud, so it could reduce the time for me to manually update the repetitive steps across multiple jobs.

For authentication, I utilized OIDC via Workload Identity Federation which lets me selectively choose which repo can deploy to my Google Cloud project without needing to download a service account's credentials.

Fortunately, GitHub Actions offer free quota for private repos and I estimated the cost to be $0.00/month since I don't expect to run my pipelines for more than 33 hours in total.

Final Architecture

I recreated my resume with SvelteKit, deployed it as a static website with Cloud Storage, connected it to a Cloud Load Balancer, then pointed my subdomain to it with Cloud DNS.

To streamline my deployment to both of my static website & function, I automated the process with GitHub Actions.

After all is done, I'm proud to bring myself to the greatest part: my final architecture that is running now for my static website.

With the help of Google Cloud Pricing Calculator, I estimated my total monthly cost to be $21.69 -- I only included the cost of provisioning services and omitted specific metrics such as data transfers:

Item	Monthly	Yearly
Personal Domain (1-year, upfront)	$1.052	$12.62
Cloud Storage	$0.00	$0.00
Cloud Load Balancer	$20.44	$245.28
Cloud DNS	$0.20	$2.4
Cloud Firestore	$0.00	$0.00
Cloud Run Functions	$0.00	$0.00
GitHub Actions	$0.00	$0.00
Total Cost	$21.69/month	$260.3/year

I still have more than $200 free credits that have yet to expire in less than 90 days, so at least for now, I can keep everything running.

If you're reading this and want to deploy something similar, I do have an alternative in mind that should bring your monthly cost to $0.00/month.

Alternative

Assuming you already bought a personal domain, this setup should reduce your monthly cost to $0.00/month by removing both the Cloud Load Balancer and Cloud DNS:

How this works: you can redirect/forward your domain/subdomain to the public URL of the index.html with your DNS management service. The trade-off for this is that the public URL will always be displayed after redirection.

Ultimately, it's about deciding what you'll compromise or the trade-offs you'll be comfortable with, especially avoiding to pay every month just to host a resume.

What I've learned

This was an exciting journey. I already planned on doing this a few months ago, but couldn't decide to proceed because I felt the challenge was unnecessary at the time.

I was fortunate to see myself fail, learn, and grow in new ways -- especially in a new cloud platform -- I've always wanted to grow beyond my current responsibilities, starting with automating more of my deployments.

Failing with automation and monitoring (there were moments I couldn't understand something) was essential to prepare myself to become a DevOps or Site Reliability Engineer. And I could clearly see my progress over time, and one of those is successfully deploying my static website.

I also applied as much as I could from what I've learned from my usual cloud platform: to design an architecture that is operational, secure, reliable, performant, while optimizing for cost.

I know this can be better and there's always for my improvement, but I'm proud to say what I've learned here and now will help me to become better for what is next for me.

Next Steps

I've actually already started preparing for one the Google Cloud Associate Cloud Engineer, since I want to broaden my skills even more while pushing myself further.

Nevertheless, I'll keep on doing this self-learning journey, focusing more on automation, monitoring, or anything that is related to DevOps or Site Reliability Engineer (hehe).

All in all, it was fun to fail and learn.

Thanks for making it this far, I truly appreciate it!

Is it worth taking HashiCorp's Terraform Associate exam?

Shawn Gestupa — Fri, 25 Jul 2025 02:58:27 +0000

Initially, I overlooked Terraform for the past few years, something I never imagined I'll be using.

Until for the past few months and now, after falling in love with it, I am proud to announce that I've passed the HashiCorp Certified: Terraform Associate (003) examination and am now officially certified.

As someone new to Terraform (just started this year), I aimed to get this certificate not because I want to, but because of necessity: I won't be able to utilize it anymore due to difference in tools used in my current team, so I had to take an initiative by using what I've learned to the fullest and make it worth as much as I can. So for me, I truly believe the Terraform Associate exam is worth it.

I had a hard time learning Terraform's opinionated structure -- being much more opinionated than the web frameworks that I've used before. Like any other person that is starting with something (or except to those that are built different), I struggled but for the next few months, I've started to get a hang of it and even find beauty within it for the way it handles automation for you and simplifies how you provision large infrastructure, making you love your job more (hopefully hehe).

About the exam, it's 1 hour long and must be scheduled 48 hours in advance. There are less situational questions and lean more on being "direct", so if you want to pass the exam, you can start with the official Terraform documentation.

Personally, you don't have to buy courses but it would be hypocritical for me to not say that I've used one. In addition to courses, here are some resources that helped me pass the exam:

If you don't want to read the Terraform documentation, you can start with the practice exams (just like what I did hehe).

Besides these resources, don't forget to keep on learning Terraform, especially getting a practical experience as this one of the key factors that built my confidence. I would also recommend to take notes if you want to, since for me, typing what I'm watching and hearing from the courses helped me remember.

All in all, keep on learning, believe in yourself, and be confident as much as you can.

Now on to the next challenge! I will aim to get a new AWS Associate certificate, either the SysOps Administrator (soon to be CloudOps Engineer) or Developer.

What started me to (re-)learn programming

Shawn Gestupa — Thu, 15 Dec 2022 14:44:04 +0000

Before I started to love programming, I stressed about how and where I should start learning: should I learn C++ or Java instead? Should I start on web development or game development?

This is my first post and I'll be writing about how I pushed myself to become a programmer.

🤔 How I started and stopped learning programming

I always dreamt of making websites; I even dreamt of making something cool on the internet to the point of thinking of making a game after playing so much AdventureQuest Worlds, despite having no experience in game development.

Fast forward, I had my first exposure to programming during Grade 11. We were taught Virtual Basic, with one of our final projects was to make a 2D game using it.

Since this was my first exposure to programming languages, making a game was hard. Though I made one despite the game looking simple, bad, and riddled with bugs/glitches. But the experience felt rewarding.

Then in Grade 12, we were taught how to program an Arduino board. For me, it was extremely hard compared to making software/games, and I realized that I'm bad at hardware programming. Nonetheless, the experience was amazing, even if the board was simply programmed to blink LED lights in intervals.

Even after stepping into college and doing some simple web development for our final project, I still couldn't push myself to keep on learning or commit to a specific language.

I would be stuck thinking about where I should start. I began to get anxious from the dilemma, pushing me away from my dream of becoming a programmer.

🎉 Open source to the rescue!

After my 1st year of college, I had the idea to learn something related to web development since I was familiar with HTML, CSS, and JavaScript.

I thought about making a Twitter bot that checks articles if they contain false information (too hard, I don't even know why I came up with this) or a website that gets food information. I settled with the latter.

Then I started to choose a framework, I was contemplating using React because 1. It is widely adopted; 2. It has an extensive library to choose from; and 3. I could get a job with an experience in React.

However, I settled with Svelte, because it caught my eye for how simple it is to use and learn, despite 1. It is less popular; 2. It has fewer options in choosing a library; and 3. I likely won't get a job with an experience in Svelte.

But I pushed on, because of how I'm getting comfortable with using the framework.

After a month of developing the website, I started to love programming. The joy of making something that you want to share felt like it is something that I've been meaning to find. The idea of open source helped me find that joy.

It took me a few months to complete the website, but I did it. I don't care how slow I made the website, how the HTML code was a convoluted mess nor how troubled I am in understanding how JSON and API work because I was so eager to publish and share what I made to the internet. I didn't even know how components worked in Svelte or how to use them.

After the website was complete, I hastily published the website's code on GitLab, then later on GitHub after switching there.

Publishing the code on a code-hosting platform helped me find the motivation to keep on making and learning, I even found the confidence to contribute to other open source projects - even if my pull request was for a documentation/CSS fix, I was nonetheless happy as I was able to contribute.

Now I'm happily publishing what I made on GitHub. Regardless if the project is simple, I'll already be happy to share what I've made. I've also decided to publish my programming-related college projects, just to showcase what my group had made.

I even re-wrote the first website I published and then published it on GitHub, after watching and understanding different videos & articles regarding code efficiency and better standards (I chose to generalize this because I genuinely couldn't remember the resources I've used, though they ingrained to me).

I felt like I now have a better grasp when it comes to learning different technology and programming languages.

The idea of open source gave me a purpose. Pushing myself to explore different technology is beneficial, so I may contribute to more open source projects and expose myself to more opportunities.

👌 Conclusion

Joining the open source community became an amazing experience. It slowly moved me out of my comfort zone and allowed me to appreciate the combined efforts of programmers to make something happen.

If you want to learn to code/programming, then learn something you're passionate about or interested in. Of course, start with something easy so that you're more motivated to finish it. You can even apply what you've learned for your next project.

Whoever you are, wherever you are, it's not too late to join the open source community, you may even find your purpose to keep on learning.

tl;dr I love open source!

Forem: Shawn Gestupa

Improving on DevOps with Kubernetes, Helm, and GitOps

Improving my DevOps skills

Some tinkering with Docker

My struggles with Kubernetes

Optimizing my infrastructure with Helm

Hands-off deployments with GitOps thru ArgoCD

Enhancing observability starting with Prometheus & Grafana

The journey ahead

Taking The Cloud Resume Challenge: GCP Style

How did I start this?

Enter Google Cloud

DNS

Load Balancing

Database

Function

Source Control

Front-end

Pull Request to main Branch

Push to main Branch

Back-end

Pull Request to main Branch

Push to main Branch

CI/CD

Final Architecture

Alternative

What I've learned

Next Steps

Is it worth taking HashiCorp's Terraform Associate exam?

What started me to (re-)learn programming

🤔 How I started and stopped learning programming

🎉 Open source to the rescue!

👌 Conclusion

Pull Request to `main` Branch

Push to `main` Branch

Pull Request to `main` Branch

Push to `main` Branch