Archive for the
‘KoDa’ Category

Il koda engine è il componente che si occupa di interfacciarsi con il docker-engine.

E’ stato scelto docker come “backend” per via della sua ampia diffusione, in quanto container engine mette a disposizione tutti gli strumenti necessari per sviluppare e buildare immagini.

Ma non solo, docker è di fatto lo standard nell’industria, in particolare la maggior parte degli sviluppatori utilizza proprio questo container engine.

Scegliere un altro engine avrebbe soltanto ridotto la potenziale platea.

Ci teniamo anche a dire che per esempio in Kubernetes docker non è l’engine più diffuso; infatti il supporto a docker-shim è stato rimosso se non fosse stato per Mirantis con cri-dockerd quest’ultimo sarebbe stato tagliato fuori.

 

Quindi, nel concreto, questo koda-engine cosa fa?

 

KoDa Engine è principalmente un server api, si basa sulla Docker SDK per python e su flask-RESTful.

La SDK ci permette di connetterci alle api di docker-engine, questi api possono essere in locale oppure su un server remoto,

mentre flask-RESTful data la sua minimalità ci permette di sviluppare in fretta le api.

 

Come si gesticono le risorse con la SDK?

 

Per implementare la CRUD è sufficiente connetersi all’engine e interrogarlo.

Le risorse che abbiamo deciso di gestire sono:

 

– Images

– Networks

– Volumes

– Containers

 

Dato che sotto la scocca del SDK vengono effettuate chiamate REST al’engine, per ogni classe di risorse abbiamo gratis i metodi CRUD.

Eventualmente stiamo anche valutando se può essere utile aggiungere un database per salvare i metadati.

 

Come si creano ambienti di sviluppo con la SDK?

 

Questo passaggio è quello più macchinoso nel senso che si divide in questi passaggi:

 

– Buildare / Pullare le imagini da un registry;

– Creare una network;

– Far partire i container collegandoli alla rete creata nel passo precedente.

 

Questi passaggi ricalcano le funzionalità di docker-compose in un certo senso, ma permettono anche una maggiore configurabilità.

Vorremmo fare anche una precisazione sui volumi, la SDK è agnostica rispetto allo storage backend, perciò se sull’host ad esempio c’è installato CEPH KoDa funzionarà lo stesso.

 

Come si creano le build automatiche?

 

Per creare le build sono necessarie due dipendenze, la SDK come sempre e python-jinja2.

Jinja2 è un template engine, quindi nel nostro caso è sufficiente creare una libreria di immagini per i casi d’uso più frequenti:

 

– react

– node.js

– python

– larave

– golang

– dotnet

 

Successivamente, creati questi template, si passeranno i parametri di build alle api di KoDa-engine, quest’ultimo eseguira i seguenti passaggi:

 

– Parserà i template valorizzandoli;

– La SDK, usando le Low-Level API creerà un’ immagine;

– Sempre la SDK, potrà o pushare su un registry oppure farà partire il container.

 

Ovviamente, per creare le immagini è necessario passare a KoDa un archivio di tutto il sorgente.

 

Per il momento questo è tutto, a presto con nuovi aggiornamenti

 

KoDa é un progetto che nasce dal desiderio di sperimentare, ma di cosa si tratta? 

Il nome stesso significa Container (Qui la C diventa K) e Da (che nelle lingue slave vuol dire si), l’idea nasce da queste due immagini:

 

 

Il desiderio è quello di creare un prodotto che sia in grado di ottimizzare l’uso dei container e che comunque permetta di sperimentare, quindi di “giocare” con essi.
Una menzione speciale va alla lettera K del nome, infatti oggi va di moda usarla per i prodotti cloud, secondo noi questo deriva dalla fama di Kubernetes, per fare qualche esempio: Knative, Kubeflow, Katacoda, Kind.

Architettura

KoDa non sarà un progetto monolitico, sarà composto da 3 componenti:

– Il front end, aiuterà gli utenti meno esperti a muoversi in questo mondo

– La cli, sarà dedicata ad utenti più avanzati

– L’engine, avrà il compito di eseguire tutte le operazioni 

Feature

Le feature principali che vorremmo implementare sono queste:

– La visualizzazione delle risorse dei container, quindi le reti, i volumi, le immagini e i container stessi. Questa feature di per se non è nulla di innovativo dato che la stessa linea di comando di docker lo fa

– La creazione di ambienti di sviluppo, l’idea è quella di creare dei template di configurazione degli ambienti. Per chiarire il concetto: se la tua app è in php e deve usare postgres come db allora ti crea sia il db, che adminer che il container con php-fpm

– L’auto creazione di immagini partendo dal codice, per fare questo sarà necessario un file in cui si descrivono le proprietà e KoDa.

Partendo da una libreria di template genera l’immagine, che puoi può essere integrata nell’ambiente di sviluppo

Obiettivi

KoDa è pensato per una vasta platea, partendo da chi non ha mai usato i container fino a chi ne conosce in maniera approfondita le potenzialità. Se si dovesse parlare di roadmap il passo iniziale è quello di arrivare a semplificare il loro sviluppo, quindi è pensato per girare in locale, in un futuro ci aspettiamo di renderlo installabile su un server condiviso e da un unico punto centrale gestire gli ambienti. A questo punto sarebbe necessaria non solo la gestione degli utenti ma anche un’integrazione con un registry.

Lo sviluppo completo delle 3 componenti è previsto per la fine del 2022, il progetto sarà open-source e disponibile su github. Non ci aspettiamo chiaramente di ricevere pull request esterne dato che siamo ancora a gli inizi, ma in ogni caso sarebbero bene accette.

Engine

L’engine ad alto livello si preoccupa di parlare con le API di docker e da queste gestire la CRUD delle risorse e questa sarebbe la prima feature nella sua interezza. Le altre due feature invece sono più sfidanti, la creazioni di ambienti di sviluppo richiedono la gestione di più risorse contemporaneamente per fare un esempio più pratico: per creare un ambiente per un app con il db è necessario creare la rete per i due container, creare il volume per il db e infine i due container.

Per gestire questi ambienti l’idea era quella di creare dei template, anche se al momento sono in corso analisi per capire quale può essere il modo migliore.

L’auto creazione delle immagini è la feature su cui puntiamo di più per questi motivi:

– Creare un libreria di immagini per i framework più utilizzati

– Non perdere tempo a reinventare la ruota 

Attualmente non abbiamo ancora deciso che strada prendere per questa feature, l’idea appunto era quella di creare un file in cui si descrivono le proprietà del progetto, in questo modo l’engine scegliendo dai template può generare l’immagine, una cosa importante è che il codice che viene passato deve rispettare degli standard altrimenti non è possibile far funzionare il workflow della build. Seguire uno standard nei progetti è comunque una cosa che va oltre KoDa ma è auspicabile in generale.

CLI

La cli la possiamo vedere come un estensione della cli di docker e del frontend, ci teniamo a fare questa perché per noi la linea di comando è l’interfaccia che utilizziamo di più.

Frontend

Il front end servirà ad agevolare quanto spiegato sopra. Verrà implementata un’interfaccia grafica in modo tale che tutti gli utenti, anche quelli meno esperti, possano interagire in maniera chiara e semplice con il nostro progetto. L’interfaccia grafica comprenderà un’area nella quale sarà possibile vedere i vari container che si hanno, quali sono attivi e quali no. Avrà inoltre una sezione dedicata per esporre sotto forma di “manuale” i vari passaggi che devono essere svolti per poter configurare un container in maniera autonoma e i passi che sono stati svolti per implementare le nostre feature in modo tale che l’utente non debba andare per forza a vedere il codice su github.

Proseguo

Nel prossimo aggiornamento approfondiremo lo sviluppo del componente Engine,
Fino ad allora restate sintonizzati.