Cooking Assistant (Team DevSecOps)

Try It Out!

Rancher deployment (Kubernetes): https://devsecops.stud.k8s.aet.cit.tum.de

Azure deployment (Docker Compose): Unfortunately, all of us almost ran out of credits on Azure. Therefore, we can only serve it on-demand: Run the vm-start workflow to activate an Azure instance, and run vm-stop.

Coverage reports: https://aet-devops26.github.io/team-devsecops/

Public API scheme (Swagger UI): https://devsecops.stud.k8s.aet.cit.tum.de/swagger-ui/index.html

Monitoring (Grafana): https://grafana.devsecops.stud.k8s.aet.cit.tum.de/

Setup Guide

All components of the project can be deployed locally through the docker-compose.yml at the root level. In order to use the AI features, run the following command to copy the template for the environment variable setup.

cp .env.example .env

Now edit .env: Specify your API provider and insert your API keys. Then run

docker compose watch # watch enables live rebuild on src changes

This starts

• the web client: http://localhost:8080
• the Spring API: http://localhost:8081
• the GenAI services on the internal network
• SwaggerUI: http://localhost:8083 (switch to the internal API spec using the dropdown in the top right corner)

Architecture

Use Case Diagram

Analysis Object Diagram

System Component Diagram

Repository Overview

team-devsecops/
├── .github/                    # CI/CD workflows
├── ansible/                    # Playbooks for CD to Azure VM
├── api/
│   ├── scripts/gen-all.sh      # Auto generate models for api specs
│   ├── openapi-internal.yaml   # Internal API spec
│   └── openapi.yaml            # Public API spec
├── infra/                      # Terraform and K8s configuration
├── services/
│   ├── py-help-service/        # Help-Service source code
│   ├── py-recipe-service/      # Recipe-Service source code
│   └── spring-api/             # Server source code
├── web-client/                 # Client source code
├── .env.example
└── docker-compose.yml

API Docs

The public API specification is documented at api/openapi.yaml. It provides the communication contract between the client and the server. The internal communication protocol between the server and the GenAI Services is documented at api/openapi-internal.yaml. In particular it specifies how user information is appended to client requests. Both specs can be viewed through SwaggerUI at:

https://devsecops.stud.k8s.aet.cit.tum.de/swagger-ui/index.html

http://localhost:8083 (while the system is running locally)

Models implementing the specified schemas can be autogenerated by running ./api/scripts/gen-all.sh.

CI/CD and Monitoring Instructions

The .github/ directory contains various workflows for running lint and test jobs, building the components and deploying them. Deployments are triggered when merging branches into main. If you want to contribute please install pre-commit using pipx install pre-commit and set up the pre-commit hooks using pre-commit install.

Deployment to Azure VM

IaC configurations are provided to simplify the deployment to Azure. The following commands allow a reproducible instantiation of a suitable VM.

cd infra            # Navigate to IaC configurations
az login            # Login to Azure
terraform init      # Initialize working directory
terraform plan      # Generates an execution plan
terraform apply     # Executes plan - requires manual confirmation

The GitHub Actions workflow .github/workflows/deploy-ansible.yml triggers the execution of the Ansible playbook ansible/site.yml. The playbook connects to the VM via ssh, clones the repository and deploys all components including a nginx instance via the infra/docker-compose.yml. Before running the workflow make sure to set up all necessary repository variables and secrets. These are: SSH_PRIVATE_KEY (SSH-Key to Azure-VM), GEMINI_MODEL, GEMINI_HELP_SERVICE_KEY, GEMINI_RECIPE_SERVICE_KEY, INTERNAL_AUTH_SECRET (Authentication between Server and GenAI Services), AZURE_DB_USER and AZURE_DB_PASSWORD.

K8s Deployment & Monitoring

The production environment is hosted on the TUM CIT Kubernetes cluster (managed via Rancher) using a GitOps-style approach.

• Deployment Architecture & Setup: The cluster state is defined declaratively in infra/k8s/, with an Ingress controller routing external traffic to web-client, spring-api and the GenAI services. Deploying from scratch is three steps:

  cp infra/k8s-secrets.env.example infra/k8s-secrets.env   # then fill it in
  kubectl apply -f infra/k8s/namespace.yaml
  infra/k8s-secrets.sh && kubectl apply -R -f infra/k8s/

• CI/CD Pipeline: Deployments are fully automated. When code is merged into the main branch, a GitHub Actions workflow validates the code, containerizes the updated components, pushes the images to the registry, and automatically rolls out the changes to the Rancher cluster.

• Observability & Monitoring: We utilize Grafana, Prometheus, Alloy, Loki and Tempo for gathering and displaying metrics, logs, and traces. The Spring API and GenAI services expose metrics endpoints (e.g., via Spring Boot Actuator) that Prometheus scrapes, while traces and logs are collected by Alloy and stored in Tempo and Loki respectively.

• Live Dashboards: System health, resource utilization, API latencies, logs, and traces all can be monitored in real-time through our Live Grafana Dashboards.

Student Responsibilities

Role	Name
Client	Jakob
Server	David
GenAI	Paul