Readme start

This commit is contained in:
Lorenzo Venerandi
2025-01-25 18:30:08 +01:00
parent f11aa6d1dc
commit e900231bf1
4 changed files with 147 additions and 16 deletions

View File

@@ -3,7 +3,7 @@ services:
image: nats:alpine image: nats:alpine
container_name: nats container_name: nats
restart: always restart: always
command: -c /etc/nats/nats.conf command: -js -c /etc/nats/nats.conf
ports: ports:
- "4222:4222" # client port - "4222:4222" # client port
- "8222:8222" # monitoring port - "8222:8222" # monitoring port

BIN
project/img/infra.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 571 KiB

106
project/schemi.drawio Normal file

File diff suppressed because one or more lines are too long

View File

@@ -1,21 +1,46 @@
# Scope of project # Infrastuttura
Tha annotation must tell the splitter how to aggregate and where to send each task.
## Possible implementation L'infrastuttura simula un flusso IoT ed è composta da:
- ambiente Cloud, deployato su kubernetes e dotato di cluster NATS, WADM e Wasmcloud Host
- ambiente Edge, semplice macchina Linux con docker compose, Wasmcloud e NATS Leaf come docker container
- dispositivi IoT collegati all'ambiente Edge
The code will be processed and splitted into possible modules. Inside the path /build will be created a directory for each module. Inside there will be the wasm compiled bytecode, a file scheduler.config that will list all the information that schedule could need to schedule the module. ![infra](/project/img/infra.png)
## Targets # Pipeline
Possible devices that run the task:
- Cloud device, prossibly the same cloud that runs the scheduler
- Edge device
- IoT device, the only one that can run device specific tasks
## Annotations Il processo si divide in due fasi principali, cioè quello di generazione del componente wasm e quella di deploy.
List of possible annotations: ## Generazione del componente WASM
- `@TaskGeneric` defines a generic task that can run everywere Questa fase si occupa di trasformare una serie di files descrittivi in codice, selezionare il template corretto, buildare il progetto, generare il file di deploy e quindi pushare l'artifact OCI in un registry.
- `@CloudSpecific` runs only on cloud
- `@EdgeSpecific` runs only on edge ### Parsing del codice
- `@EndDeviceSpecific` runs only on end device, in particular the device can be specified with `@EndDeviceSpecific(device_name)`
Il progetto di partenza è composto da un file `workflow.yaml`, nel quale vengono descritti tutti i componenti, e da una cartella `tasks` contenente le porzioni di codice che devono essere eseguite dai vari componenti.
```
├─ workflow.yaml
└─ tasks
   ├─ sensor_read.go
   ├─ aggregate.go
   └─ db_sync.go
```
#### Workflow
Nel file workflow vengono descritti i vari componenti, un esempio potrebbe essere
```yaml
tasks:
- name: Data Aggregation # Displayed name
type: processing # Used to select template
code: aggregate.go # Go code file inside tasks/ dir
target: # Where the component will be deployed
- edge
- cloud
source_topic: temp_sensor # Source NATS topic
dest_topic: aggregated_data # Destination NATS topic
component_name: data_aggregation # Component name displayed in the OCI artifact
version: 1.0.0 # Component version
...
```