58 lines
5.4 KiB
Markdown
58 lines
5.4 KiB
Markdown
# Application Kubernetes Deployment - SmartBuilding
|
|
|
|
## 1. Description of the Application
|
|
This application is a Smart Building Management Dashboard built with Node.js and an Express web server. It primarily relies on a MySQL database to securely track system infrastructure components, connected devices (like sensors, thermostats, air conditioning), and different member privilege tiers. Members can authenticate to control and view resources associated with the buildings they manage.
|
|
|
|
## 2. Containers Used
|
|
- **`web-app:1.0` (Node.js)**: A custom Docker image built from `node:18-alpine` using the provided `Dockerfile`. It serves the Express application and manages API routing, web views (using EJS), and database interactions.
|
|
- **`mysql:8.0`**: The official MySQL container image. It is initialized safely with custom user schemas for our objects, users, and sensor mappings (using our `user.sql` script mounted as a ConfigMap).
|
|
|
|
## 3. Kubernetes Objects
|
|
- **Namespace (`smartbuilding-namespace`)**: Logically isolates all deployment resources within the Kubernetes cluster.
|
|
- **PersistentVolume (`mysql-pv`)**: Defines physical storage capacity dynamically provisioned for the database onto the node.
|
|
- **PersistentVolumeClaim (`mysql-pvc`)**: Formulates the formal storage request by the `StatefulSet`, linking it tightly with the above `PersistentVolume` ensuring persistence.
|
|
- **StatefulSet (`mysql-statefulset`)**: Responsible for preserving the single stateful instance of our database, reliably linking persistent network identity across potential pod restarts.
|
|
- **ConfigMap (`mysql-initdb-config`)**: Converts the local `user.sql` file natively into Kubernetes configuration format to be mounted intelligently inside `docker-entrypoint-initdb.d` within the MySQL Pod to initialize the database upon container recreation.
|
|
- **Service (`mysql-service`)**: A Headless Service mapping dns directly for the StatefulSet, preserving an internal DNS mapping so the web API node securely resolves the database host organically.
|
|
- **Deployment (`webapp-deployment`)**: Defines the stateless scaling tier managing the custom Node.js web-app container instances. Environment variables to control database location (`DB_HOST`) are natively overridden using specs referencing `mysql-service`.
|
|
- **Service (`webapp-service`)**: Exposes our load-balancer / NodePort for the Node.js frontend so standard browsers can interface with the cluster externally.
|
|
|
|
## 4. Virtual Networks and Named Volumes
|
|
- **Virtual Networks**: The application securely utilizes the isolated cluster SDN (Software-Defined Network) isolating nodes using headless services. Specifically, `webapp-service` maps port 3000 on the containers locally to a global `NodePort` (30000) allowing bridge access from external networks.
|
|
- **Named Volumes**: The MySQL state is physically bound to `mysql-persistent-storage`. The initial schema (`mysql-initdb`) behaves as a simulated mounted file dynamically injected directly from the ConfigMap volume into `/docker-entrypoint-initdb.d`.
|
|
|
|
## 5. Container Configuration
|
|
- **Node app configuration**: Containerized with a lightweight Alpine filesystem. Dependencies (`package.json`) are pulled securely during building. Native port exposure binds to TCP `3000`. The code was modified specifically (`config/db.js`) to parse connection configurations dynamically relying gracefully on the environment variables defined within `deployment.yaml` (`DB_HOST`, `DB_USER`, `DB_PASSWORD`, `DB_NAME`).
|
|
- **MySQL app configuration**: Managed uniquely with secure environment hooks. Initializing automatically utilizing the `MYSQL_ROOT_PASSWORD` variable and implicitly creates initial mappings executing our SQL via the configured ConfigMap entry.
|
|
|
|
## 6. How to Prepare, Run, Pause, and Delete the Application
|
|
The `webapp` directory must be in the same path as these scripts. Ensure Minikube and Docker Daemon are configured.
|
|
|
|
- **Prepare Application**: Execute the associated preparation script. This directs your Docker CLI locally to Minikube's Docker Daemon natively and packages the image seamlessly.
|
|
```bash
|
|
./prepare-app.sh
|
|
```
|
|
- **Run Application**: Execute the start script to orchestrate all objects inside the Minikube environment. Wait slightly upon deployment creation.
|
|
```bash
|
|
./start-app.sh
|
|
```
|
|
- **Pause Application**: To temporarily freeze deployments natively scale them gracefully to zero instances without permanently destroying metadata bindings.
|
|
```bash
|
|
kubectl scale deployment webapp-deployment --replicas=0 -n smartbuilding-namespace
|
|
kubectl scale statefulset mysql-statefulset --replicas=0 -n smartbuilding-namespace
|
|
```
|
|
- **Delete Application**: Ensure resources inside the workspace securely dismantle.
|
|
```bash
|
|
./stop-app.sh
|
|
```
|
|
|
|
## 7. How to view the application on the web
|
|
Since it operates dynamically via Minikube scaling out an external NodePort, use Minikube's native proxy redirect function. After ensuring deployments are completely `Ready`, open the terminal natively and type:
|
|
```bash
|
|
minikube service webapp-service -n smartbuilding-namespace
|
|
```
|
|
This correctly resolves external mappings locally exposing a URL automatically inside your standard Web Browser to begin authenticating into SmartBuilding.
|
|
|
|
## How Artificial Intelligence was natively used
|
|
In this project ai was used to help understand kubernetes intrications between files. It was also used to help Write the README.me file (add state clearly what does this application do, list all the dependencies and write it smoothly).
|