„VIGGY“ — The story of an apprentice project at MediaMarktSaturn Technology

by Michael Ibel

At MediaMarktSaturn (MMS) we train our own apprentices in different teams of the organization. This article describes a community project of a few departments, bringing the agile way of working and a new technology stack closer to our employees of tomorrow.

Background

Our apprentices are part of our organization and switch between the teams in a 6 month-rhythm from department to department to learn everything they’ll need in their career as an application developer. As many parties are involved during the creation of an application/product here at MMS, we wanted to show our apprentices the process from start to go-live and the connections between our teams and processes.

Involved teams on our side to support such a project were our central Cloud Platform, the Agile coaches and our central Monitoring Platform team. The apprentices of these teams — in this case five “first-year” apprentices who just started their apprenticeship in September — created a virtual development team following our company standards and the agile way of working in a SCRUM team.

I have an idea

After the agreement to form a joint effort virtual team we had to find a project idea that they could take over.

After some time the idea of a knowledge base made from apprentices for apprentices was born. This knowledge base should contain information about the daily business as an apprentice, but also department specific content, which lets all apprentices have an insight into team specific knowledge. The solution should be also extendable and be used as blog where the apprentices can find useful trainings, tools or even information or tasks they’ll need in their final exams.

Let’s find a tool

The ideas reached from developing an own solution to use already existing ones. Most importantly, apprentices of all occupational directions (includcing e.g. office administrators or marketing apprentices) who are not used to write documentation in GitHub as markdown files, should also be able to use the tool.

The market is full of solutions that offer the necessary features, so we started the evaluation phase.

As Kubernetes — or to be more precise GCP’s managed variant, the Google Kubernetes Engine (GKE) — is one of the main platforms to host our applications on in MMS, we decided to deploy a containerized version of the tool. Because of this, the apprentices deployed the application containers to local machines using Docker during the evaluation phase. They checked out the functionalities and the UIs of different tools, always double checking with apprentices with less technical skills to make sure everyone can use it.

Finally, after the first sprint, an architectural design was developed, and a tool was found. A decision was taken, to use wiki.js and a team-name was found — “VIGGY” was on its rise.

All beginnings are difficult

With a tool to go, the apprentices started experimenting on the latest company tech stack that uses Terraform for managing the cloud infrastructure (check out our Terraform blog article here) and an automated GitOps deployment process using FluxCD.

As a fresh product team, the starting point was to create the infrastructure in the Google Cloud. To follow company standards and best practices, they moved on with creating own Terraform Enterprise workspaces for their GCP projects. After doing all the setup for Terraform, they are good to go for creating infrastructure in the cloud, based on the application needs.

For running wiki.js, a Kubernetes cluster and a database for storing documents are needed.

After the infrastructure components were in place, it was time to develop the deployment mechanism. As mentioned earlier, the delivery pipeline should use FluxCD and so we started with bootstrapping the stack onto our Kubernetes cluster.

Rollout phase

After infrastructure and deployment components were set up, it was time to start writing Kubernetes manifests that could be applied by Flux. Wiki.js can be deployed using Helm, so we created a manifest for installing the Helm release. In the manifest, the general application settings like database properties and Ingress specifications can be configured.

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: viggy
  namespace: viggy
spec:
  interval: 5m
  timeout: 5m
  chart:
    spec:
      chart: wiki
      sourceRef:
        kind: HelmRepository
        name: wikijs
        namespace: flux-system
  upgrade:
    remediation:
      remediateLastFailure: true
  values:
    replicaCount: 1
    postgresql:
      enabled: false
      postgresqlHost: xxx.xxx.xxx.xxx
      postgresqlPort: 5432
      postgresqlUser: postgres
      postgresqlDatabase: wiki
      existingSecret: viggy-db-password
    ingress:
      enabled: true
      annotations:
        kubernetes.io/ingress.global-static-ip-name: apps-static-address-prod
        ingress.gcp.kubernetes.io/pre-shared-cert: prod-lb-cert
      hosts:
        - host: xxxxxx.mms.tech
          paths:
            - path: "/"
              pathType: Prefix

As we want to store everything in our GitOps manifest repository in GitHub, we also needed to store the secret to access the database in there. For this purpose, the apprentices decided to use Bitnami SealedSecrets to be able to save encrypted secrets in our GitHub repsository and afterwards decrypt the secrets on our Kubernetes cluster. Therefore, we also installed the operator for SealedSecrets using Flux & Helm within our repository. Afterwards, we were able to upload an encrypted version of the database password to our GitHub repository.

---
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: viggy-db-password
  namespace: viggy
spec:
  encryptedData:
    postgresql-password: AgCM6rL/e8KwMqURR4IoWEI0cD3OSV0XUraSOt+bmHRh/vYMD13+5yx0mOvoKxVbnInxNAWZDOgzRiO30PSMWWCKz5rbPpmA5qkjhV24lJJtdz+twfxjSi2SJeBcwtSx1ajCjV0hPacfbU08B6sM8vnOjvDt0rD3GuHJFLB6/8QmLdKhA7CPSZxwLzyVYgTVWvcesJ+mYjDMXygEIg4uUSxpbbuSt0rqfJSMeqnORdXx2KNQxoyx7A3mj7Cfz3xUFG4CJ5meesXnu5V5nP8/KTUHrapFXN7Hk10QmFwX3SyogtJdCDDQx7hOfnZ2BsqCTwimteMyyLmdo8yanl+ncgzJd0yBubFH+62+wY41XvNsPLZpfQXHYJDMngAd6t9cEcFOr1kY5a91ITtXTe0h/I/BuzvO9sXUYc/OSJr7qr8dLwfdyze8FN2mKWGysuXF4OKmUzZSmu/L2ydjpLawpu/tCLuD6K0qJoNoe4CaTC9pRWWS+4ZXfyTFfDk2cn5axYp6HUFUJ0PNAD92XiHEbt7ShgmvVvHOLjklKvdzQEtCOgXvE1aAMWRV+WYuJPkh3c3ZYRuVDgTAaFdbZPswxiSIAv/gXmTExyNqxg8yXJkeOGToU2UfEL81HXPXoFfMwxu6yFEoUM7cS5VgZ0/3bFmgitC0W9xKg08qxTihQ9inroyaLTR8Zu7zzLBPZz8egXwyta9TRcJ8grbUsGiHXW5xotZrXQ==
  template:
    metadata:
      creationTimestamp: null
      name: viggy-db-password
      namespace: viggy

Finally, all manifests got synced to our Kubernetes cluster and the application was up and running.

VIGGY is alive

After the initial deployment, we are ready to go, filling VIGGY with love and live. The apprentices started to deploy permission sets and integrated our login and identity provider for authentication. They also set up monitoring/alerting based on application metrics. Other apprentices outside of the virtual project team started to create content on the pages. VIGGY and its community started to grow. Soon, we announced the “GoLive” together with our internal Young Talents team and introduced the tool in MMS.

Conclusion

We hope, this article could give you some nice insights into our small apprentice project. I am very happy, how this project was going. It once more showed me, that our young talents are highly motivated and can get fast into completely new topics. They enhanced their understanding about cloud, Infrastructure as Code (IaC) and deployment processes in a very short amount of time. With this knowledge they are well prepared for their start in one of our product teams after they’ll finish their apprenticeship.

If you have any feedback or comment to the project or this post in general, just let us know!

get to know us 👉 https://mms.tech 👈