Welcome back, fellow adventurers! In this new installment of my blog, we're diving deeper into the Cloud Resume Challenge, exploring the additional steps beyond the core requirements.

Having successfully completed the initial challenge, I'm eager to share with you the next phase of my journey. These extra steps promise to further enrich our understanding of cloud technologies and push the boundaries of our skills.

Join me as we embark on this exciting continuation!

Implementation

Extra Step 1: Package Everything in Helm

I'm not very familiar in using Helm, fortunately, Helm offers extensive and understandable documentation.
, making it an invaluable resource for Kubernetes resource management.

In this step, I realized the efficiency and convenience Helm brings to the table compared to manually creating Kubernetes resource definition files. While creating .yaml files was essential for laying the foundation of Kubernetes resource creation, Helm allows us to recycle these files and manage them more gracefully.

One of the standout features of Helm is its ability to group Kubernetes resources as needed and handle their management seamlessly. By utilizing the values.yaml file, we can define dynamic data for each Kubernetes resource, enhancing flexibility and convenience.

To dive into the world of Helm, you can start by creating, packaging, and deploying your own Helm chart using the following commands:

helm create deis-workflow
helm package deis-workflow
helm install deis-workflow ./deis-workflow-0.1.0.tgz

These commands, straight from the Helm documentation, provide a solid starting point for exploring Helm and its capabilities.

Extra Step 2: Implement Persistent Storage

Throughout the Cloud Resume Challenge, I encountered scenarios where modifying the database required either recreating the Deployment or experiencing database Pod restarts. In both cases, all previously applied configurations in the database would be overwritten, essentially resetting it to a blank slate.

To address this kind of scenarios, I realized the importance of implementing persistent storage for our database. With the assistance of Kubernetes resources such as PersistentVolume and PersistentVolumeClaim, we can ensure that the data in our database remains persistent, regardless of Deployment recreation or Pod restarts.

The outcome of this step is significant: the lifecycle of the database becomes separated from the storage itself, ensuring that our data will Retain and accessible even amidst infrastructure changes or failures.

Extra Step 3: Implement Basic CI/CD Pipeline

In this phase, we'll streamline the build and deployment process of our resources, extending beyond just our Docker Image and Helm Charts. To achieve this, we'll leverage GitHub Actions, a powerful automation tool provided by GitHub.

Here are some of the GitHub Marketplace Actions that I've utilized to accomplish these tasks. I hope you find them as useful as I did. It's worth noting that there are several ways to achieve these steps, whether by using different GitHub Marketplace Actions or running your own custom commands.

name: ci

on:
  push:
    branches: main

jobs:
  login:
    runs-on: ubuntu-latest
    steps:
      -
        name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

name: ci
on:
  push:
    branches: main

jobs:
  login:
    runs-on: ubuntu-latest
    steps:

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout
        uses: actions/checkout@v4
      -
        # Add support for more platforms with QEMU (optional)
        # https://github.com/docker/setup-qemu-action
        name: Set up QEMU
        uses: docker/setup-qemu-action@v3
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

- uses: azure/setup-helm@v4.1.0
  with:
     version: '<version>' # default is latest (stable)
  id: install

By automating our build and deployment workflows, we can ensure faster and more consistent releases, ultimately enhancing the efficiency and reliability of our development pipeline.

Conclusion

And with that, this is my conclusion for this challenge, I reflect on the invaluable experiences gained throughout this journey. As I navigated each step, from setting up the infrastructure to fine-tuning the deployment, I encountered various obstacles and triumphs that deepened my understanding of cloud technologies. I reflect on the invaluable experiences gained throughout this journey. As I navigated each step, from setting up the infrastructure to fine-tuning the deployment, I encountered various obstacles and triumphs that deepened my understanding of cloud technologies.

Moving forward, I carry with me the lessons learned and insights gained from this experience. I'm excited to continue exploring new avenues in Kubernetes, Containerization, Cloud Computing and further honing my skills.

I trust that you've found this article helpful in some capacity. It's been a pleasure documenting my journey through the Cloud Resume Challenge and sharing insights and learnings along the way.

If you have any feedback, questions, or suggestions for future topics, I'd love to hear from you. Feel free to reach out at Twitter and LinkedIn and let's continue the conversation. Here's to more learning and growth ahead!