Kube Cloud Pt2 | Database Configuration in Kubernetes

Kube Cloud Pt2 | Database Configuration in Kubernetes

Kubernetes Application Hosted in the Cloud (Part 2)

full course
  1. Cloud Kube Pt2 | Setting Up a Datastore
  2. Kube Cloud Pt2 | Automated Testing with TestContainers
  3. Kube Cloud Pt2 | Database Configuration in Kubernetes

We now have an application that will connect to our MongoDB locally, but we’ll need to tell it how to connect when its deployed to Okteto.

Create Kubernetes Configuration

First, create a secret in okteto with the database details. Run this command on your terminal. The uri should look like your uri in the application.yml file

kubectl create secret --namespace ${your okteto namespace} generic mongo-secrets --from-literal=SPRING_DATA_MONGODB_URI='mongodb+srv://${your mongo username}:${your mongo password}@bullyrooks.4zqpz.mongodb.net/bullyrooks?retryWrites=true&w=majority'

Now update deployment.yaml in the helm templates to add an environment variable that will be provided from the secret.

            - name: http
              containerPort: {{ .Values.port.containerPort }}
              protocol: TCP
          - name: SPRING_DATA_MONGODB_URI
                name: mongo-secrets
                key: SPRING_DATA_MONGODB_URI     

Git Commit and Push

$ git add .

$ git commit -m "added database connection"

$ git push

This should trigger a build on the main branch which will result in a deployment to okteto. You can then manually confirm the functionality.

Test with Postman


At this point, I decided to try out dependabot integration with github actions. It’s very simple to use. In your /.github directory (not /.github/workflows) create a file called dependabot.yaml with this content

version: 2
  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
      interval: "daily"
  - package-ecosystem: "maven"
    directory: "/"
      interval: "daily"

Now, on the first commit and daily after that, the dependabot script will find any updated versions of libraries used in github actions or maven dependencies, create a PR and kick off your feature branch build. Once that passes, you can merge that into your main branch. Its really helpful, because you’ll be up to date with your dependencies and you’ll know if an update will be problematic because your build/test will fail.

0 comments on “Kube Cloud Pt2 | Database Configuration in KubernetesAdd yours →

Leave a Reply

Your email address will not be published. Required fields are marked *