Seguici

Archive for the
‘Sviluppo’ Category

Home / Sviluppo

15 Giugno 2022

m.fontana@bluecube.it

KoDaKoDa-Engine

KoDa

KoDa-Engine

KoDa-Engine 0

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

 

25 Maggio 2022

m.fontana@bluecube.it

azure devopsdevops

DevOpsSviluppoTipologie & Campi di Applicazione

Azure DevOps: Perché certificarsi?

Azure DevOps: Perché certificarsi? 0

Come anticipato nell’articolo precedente, quando le aziende decidono di affidarsi a qualche figura esterna, è bene fare molto attenzione ad un elemento chiave che unirà le due realtà, ovvero la fiducia, necessaria in ogni tipo di relazione.

Per valutare la fiducia è bene tenere in considerazione alcuni fattori, SPECIALMENTE quando si ha a che fare con ingenti investimenti e si delocalizza il proprio budget (parzialmente o totalmente) al di fuori.

Per scegliere il partner ideale bisogna prendere in considerazione realtà che certificano le proprie competenze e NON solo con le parole.

In questo articolo seguirà un’interessante intervista rilasciata da 3 dei nostri tecnici che ci spiegheranno con parole semplici e comprensibili, l’importanza di ottenere la certificazione Azure DevOps e cosa rappresenta il DevOps secondo il loro punto di vista.

Prima di mostrare le domande fatte, facciamo un piccolo chiarimento sul concetto di DevOps, che rappresenta un approccio culturale relativamente nuovo, che nasce dall’integrazione di Dev (development) e Ops (Operators), ovvero unisce il mondo dello sviluppo e degli operatori IT in modo CONTINUO, facilitando i processi, la risoluzione di eventuali bug di sistema, ecc, rendendo il sistema Agile ed è  una logica integrata in cui i diversi aspetti di pianificazione, sviluppo, test, deploy, produzione e monitoraggio si relazionano all’interno di un processo organico e continuo.

 

A tal proposito, presentiamo Matteo Sposato (Team Leader), Eduardo Zapata (Team Leader) ed infine Ivan Soreca (Developer) che hanno risposto ad alcune domande, quali: 

 

  1. Come definireste il DevOps?
  2. Perché è necessario certificarsi? 
  3. Qual è stata la difficoltà che avete riscontrato durante il vostro percorso verso la certificazione?
  4. Qual è il valore aggiunto/pratico che dà la certificazione?
  5. Pensate che il DevOps sia il futuro dell’informatica? 

 

Matteo Sposato (Team Leader): 

 

  1.  Il devops lo definirei come una metodologia di lavoro,  basata sulla collaborazione tra figure complementari. Per essere più chiari, se uno sviluppatore e un sistemista collaborano nella maintenance di un applicativo è più probabile che i problemi che emergono vengano risolti grazie al fatto che i due “rami” lavorano all’unisono.
  2. Non credo che certificarsi sia necessario a livello personale, la necessità sorge quando ci si deve rapportare con realtà enterprise, poiché queste ultime,  per come sono strutturate, hanno bisogno di avere delle certezze!
  3. La difficoltà più grande è quella di dover imparare come vengono fatte le domande all’esame dato che non c’è parte pratica!
  4. Il valore aggiunto come dicevo prima è la possibilità di prender parte a progetti enterprise, che, di conseguenza, comporta anche il dover rapportati con persone molto competenti. Sicuramente studiare ti permette di avere anche una panoramica dei servizi, quindi più consapevolezza nella scelta della tecnologia.
  5. Penso che il DevOps sia un nuovo modello per una piccola parte del mondo informatico, principalmente se si forniscono servizi. Credo anche che la collaborazione a qualsiasi livello sia una cosa auspicabile in generale.

 

Eduardo Zapata (Team Leader): 

 

  1. Il DevOps è un concetto molto difficile da spiegare; è utile e va bene sia per tutti coloro che hanno nel loro bagaglio una serie di competenze IT, sia per la programmazione, perciò sia per il team degli sviluppatori, sia per il team Operation, un po’ come succede tra Matteo, Ivan ed io (come Matteo Ivan ed io) e quindi possiamo mettere mano al DevOps direttamente senza passare da un’analista funzionale.
    Un altro approccio relativo al DevOps facile fa spiegare è che una persona che non conosce nulla di programmazione, grazie ai tool offerti da Microsoft, può arrivare ad ottenere gli stessi risultati e gli stessi obiettivi perché si hanno molti elementi già precompilati.
  2. E’ un piccolo traguardo personale (ce l’ho fatta, ho una certificazione e gratificazione personale); dal punto di vista aziendale invece è stata necessaria per poterci offrire la possibilità di gestire progetti molto più grandi e ci avrebbe aperto le porte a future ed ottimali collaborazioni con partner di una certa notorietà.
  3. Il tempo, perché per prepararsi era molto difficile ed il tempo, era quasi inesistente! L’impegno e la volontà di raggiungere questa certificazione però, hanno abbattuto ogni ostacolo ed ogni presunta difficoltà.
  4. Il valore aggiunto si ritrova nella possibilità di gestire progetti di grande valore, potendo collaborare con clienti importanti! Ormai si sta passando tutto al Cloud e quindi avere persone competenti in materia ed orizzontali allo stesso tempo sulle tecnologie utilizzate, risulta essere un plus a livello aziendale.
    Le persone competenti hanno quindi la possibilità di gestire il progetto in tutte le parti di esso!
  5. Secondo me sì, rappresenta una parte del futuro dell’informatica! Avere coesione tra il team di sviluppo e di operation è davvero un punto di forza da riconoscere alle aziende IT.

 

Ivan Soreca (Developer): 

  1. Il DevOps a mio avviso lo identifico come l’insieme delle capacità e delle conoscenze di strumenti generici, nel senso che non c’è una vera e propria e singola specializzazione che comprende TUTTO ciò che viene fatto oggi in termini di infrastruttura, che confluiscono in un’unica persona.
  2. Di certo la soddisfazione personale di avere raggiunto un traguardo così importante!
  3. Direi il tempo e le domande! Il DevOps non è un argomento facile e le domande all’esame sono davvero toste! Inizialmente poi alcuni concetti non erano per niente semplicissimi (configurazione di file ad esempio) e non è come imparare un qualsiasi linguaggio di programmazione nuovo; una volta che impari un linguaggio di programmazione lo conosci e continui senza problemi; hai delle perplessità? Trovi le risposte con un’infinità di dispense online che ti aiutano; il DevOps no!
  4. La certificazione ti porta (non solo come detto prima ad una tua soddisfazione personale), ma a poter lavorare per clienti grandi gestendo progetti di una certa portata.
  5. Secondo me sì, può rappresentare il futuro dell’ informatica che è un campo che cambia moltissimo in base a quello che piace di più e si sta puntando su questa soluzione (devops) avendo una figura unica che fa più o meno tutto e alle aziende fa comodo e più stabile perché non hai tante persone che fanno cose diverse.

E’ molto importante poter dare voce a chi nel settore se ne intende: ciò può essere utile a tutti (chi già sa e chi no) di poter imparare nozioni nuove ed approcciarsi al mondo del DevOps a piccoli passi.

Se devi scegliere un partner esperto, fallo in maniera intelligente: ascolta le parole, ma guarda i fatti!!

 

12 Aprile 2022

m.fontana@bluecube.it

azure devopspipelinespipelines azure devops

SviluppoTipologie & Campi di Applicazione

Perché è necessario usare le Pipelines?

Perché è necessario usare le Pipelines? 0

Ti sei mai chiesto perché la tua azienda ha bisogno di utilizzare le pipelines?

Facciamo un piccolo passo indietro per capirci di più.

Innanzitutto con “pipeline” si intende una successione di passaggi orchestrati con la capacità di portare il codice sorgente fino alla produzione. 

I passaggi sono: creazione, confezionamento, test, convalida verifica dell’infrastruttura ed infine, implementazione in tutti gli ambienti necessari.

Una pipeline si può attivare nel momento in cui viene richiesto un determinato evento, ad esempio dalla richiesta di modifica del codice. 

E’ più facile immaginare il concetto di pipelines affiancandolo al suo significato tradotto, ovvero “conduttore” ed il concetto è molto simile: un “tubo” nel quale scorrono e fluiscono una successione di dati.

Oggi giorno i dati si moltiplicano in maniera esponenziale, molto velocemente, ed il mondo dell’IT e del digitale corrono con ritmi frenetici; questo comporta la necessità di avere pipelines di dati all’interno della propria azienda, necessarie anche per ottimizzare il proprio tempo ed il potenziale dei dati stessi, soddisfando, in maniera ideale, i bisogni richiesti dai propri clienti. 

Sono infiniti i dati presenti all’interno di database, applicazioni ed altre sorgenti di informazioni (si pensi anche solo ai fogli di calcolo di Excel); tutti i dati devono essere fruiti all’interno di tutte le sorgenti utilizzate. 

Una pipeline di dati include e racchiude in sé una successione di azioni che iniziano dall’acquisizione di dati grezzi (provenienti da una sorgente) per essere poi trasformati nel minor tempo possibile, in dati pronti per essere analizzati.

Quando si parla di pipelines, si fa riferimento ad Azure Pipelines che integra e combina l’integrazione continua (indicata con CI) ed il recapito continuo (CD) al fine di testare e compilare il codice spedendolo a qualsiasi destinazione.

Vantaggi della pipeline CI/CD:

Utilizzando le pipelines si ottengono numerosi vantaggi; pensiamo al mondo delle applicazione ad esempio: è raro che due applicazioni (compresa l’infrastruttura di supporto) siano uguali; l’attività di sviluppo e la consegna del software sono esercizi ripetitivi ed iterativi e le pipelines dovrebbero essere eseguite più volte al giorno (specialmente per la correzione di eventuali bug si sistema).

Quando si adotta una pipelines CI/CD, il team di sviluppo e quello operativo adottano una comprensione più chiara di ciò che è necessario per concretizzare le proprie idee. 

Inoltre, adottando un approccio sistematico con questa tipologia di pipelines, gli stessi bug possono essere facilmente individuati e risolti, poiché il processo è coeso ed unito e non disgiunto. 

Fasi di una pipeline CI/CD:

Le pipelines CI/CD si suddividono in fasi??

Assolutamente sì, e di seguito ve le mostriamo: 

1) Build – La fase in cui viene compilata l’applicazione.

2) Test – La fase in cui viene testato il codice.

3) Rilascio – La fase in cui l’applicazione viene consegnata al repository.

4) Distribuzione – In questa fase il codice viene distribuito in produzione.

5) Convalida – In questa fase avviene la convalida del software come la presenza di vulnerabilità.

Cosa c’è dentro una pipeline?

Come già sopra accennato, una pipeline di dati contiene l’intero percorso che i dati stessi compiono all’interno dell’azienda.

All’interno di una pipeline di dati quindi, si hanno tre fasi principali: 

  1. Fase di raccolta di dati grezzi: i dati vengono rilevati ed estratti da un numero di sorgenti diverso, arrivando in formati molto diversi da loro (da tabelle, a code, a nomi di file, ecc).
    In questa prima fase quindi i dati non hanno una loro identità ed una loro forma, ed è per questo che vengono definiti come “grezzi”

  2. Fase di governance dei dati: dopo la fase di raccolta dei dati grezzi, le imprese stabiliscono una governance di dati, ovvero devono decidere delle regole per organizzare i dati grezzi precedentemente raccolti; solitamente i dati grezzi raccolti vengono connessi al contesto aziendale al fine di assumere un significato.
    Questa è la fase di controllo della qualità dei dati e della sicurezza, organizzandoli poi per il consumo di massa.

  3. Fase di trasformazione dei dati: è la fase decisiva, in cui i dati vengono puliti, viene data loro una forma ed un’identità, ottengono quindi il formato di report corretto; tutti i dati sterili vengono eliminati.

La missione e l’obiettivo delle pipelines di dati consiste nell’integrare i dati per fornire ai consumatori informazioni facilmente e velocemente fruibili in tempo reale.

 

 

Perché scegliere noi? 

Se si vuole stare al passo con l’innovazione, bisogna concretizzare questa idea e per farlo, bisogna scegliere persone qualificate ed esperte.

Il team Bluecube dispone di personale CERTIFICATO Azure DevOps ed è per questo che i nostri Partner che sono leader di mercato in hosting, housing e cloud hanno scelto noi, perciò, non stare con le mani in mano, contattaci!

 

29 Marzo 2022

m.fontana@bluecube.it

DevOpsSviluppo

DevOps: dalle parole ai fatti

DevOps: dalle parole ai fatti 0

Necessità iniziale del cliente/Obiettivo 

 

Per Moresi.com leader nel settore della digital transformation, abbiamo sviluppato un PoC (proof of concept)), per automatizzare e centralizzare i processi di provisioning e di configurazione delle risorse degli ambienti On-Premise ed in Cloud, sfruttando le potenzialità della metodologia DevOps.

L’obiettivo è quello di verificare la possibilità di provvedere alla gestione IT delle risorse infrastrutturali sfruttando le potenzialità di Azure DevOps come punto centralizzato, utilizzandolo per orchestrare e gestire tutte le componenti software coinvolte nell’operatività.

Per rendere il POC più completo, per ogni sistema, oltre a verificarne le possibilità di accesso si forniranno anche esempi di casi d’uso pratico.

Ora però, andiamo per step, partendo dagli ambienti e dalle tecnologie utilizzate.

 

Ambienti  e tecnologie utilizzati 

 

Gli ambienti che abbiamo preso in analisi sono i seguenti: 

 

On-Premise

  • Hypervisor

VMware  xSphere

VMware vCloud Director

ESXi (Bare Metal Hypervisor)

  • Network

Fortinet

Fortimanager

Cloud

  • AWS (Amazon Web Services): AWS simple Instance, AWS Multi Region deploy, 
  • Microsoft Azure

 

Sistemi Operativi

  • Linux: LAMP stack deployment using Ansible, LAMP stack deployment using Bash
  • Windows:  deploying IIS and ASP.NET using PowerShell
  • ForiOS: Apply to a FortiOS some firewall rules using Ansible and the self-hosted agent of azure devops

Ci siamo avvalsi dell’utilizzo del paradigma IaC (acronimo di Infrastructure as Code) che consente la gestione e la configurazione completa dell’infrastruttura in tutte le sue parti: reti, macchine virtuali, servizi di bilanciamento del carico e tipologia di connessione, circoscritti in un modello descrittivo.

Per poter raggiungere la nostra meta e soddisfare in maniera ottimale l’esigenza del cliente e la sua ambizione, abbiamo sfruttato le potenzialità di una serie di tecnologie che fanno parte del nostro DNA e che ci caratterizzano, quali: 

  1. Docker: Docker permette di costruire, impacchettare e poi distribuire applicazioni con facilità e velocità attraverso contenitori con le tutte le dipendenze necessarie invece di macchine virtuali. Elimina le banali attività di configurazione e favorisce la collaborazione efficace del team.

I contenitori Docker possono essere eseguiti ovunque, in locale, nel data center, in un provider di servizi esterno o nel cloud. I contenitori di immagini Docker possono essere eseguiti in modo nativo in Linux e Windows.

 

  1. Git: Git è uno strumento per il controllo della versione usato per tenere traccia dei cambiamenti nel codice sorgente e coordinare efficacemente il lavoro fra i componenti del Team.

 

  1. Ansible: Ansible è uno strumento di automazione IT. È possibile configurare sistemi, distribuire software ed eseguire attività IT più avanzate come distribuzioni in sequenza o aggiornamenti senza tempi di inattività utilizzando file di configurazione in formato YAML (YAML Ain’t Markup Language) sotto forma di Playbook Ansible, che permettono di descrivere le configurazioni desiderate in un linguaggio colloquiale.

 

  1. Terraform: Terraform è uno strumento per creare, modificare e aggiornare l’infrastruttura in modo sicuro ed efficiente utilizzando un linguaggio di configurazione di alto livello chiamato HCL (HashiCorp Configuration Language) che consente di descrivere ed attuare lo stato desiderato.

Terraform è in grado di gestire fornitori di servizi noti ed esistenti, nonché soluzioni interne personalizzate.

 

  1. Scripts: Qualora qualche particolare configurazione non sia attuabile con i moduli disponibili per strumenti sopracitati è possibile sfruttare i linguaggi di scripting propri del sistema da configurare:

        Bash: CLI (Command Line Interface) usata nei sistemi operativi Unix e Unix-Like;

        Powershell: CLI (Command Line Interface) usata prevalentemente sei sistemi operativi Windows;

     VMware PowerCLI: modulo di powershell per la gestione, la configurazione e l’automazione dei prodotti VMware.

  1. Azure DevOps: Azure DevOps è una piattaforma Software as a Service (SaaS) di Microsoft che fornisce un insieme di strumenti per lo sviluppo e la distribuzione di software. Si integra inoltre con la maggior parte degli strumenti DevOps presenti sul mercato, ed è un’ottima opzione per orchestrare una Toolchain DevOps.

 

  Metodologia ed approccio utilizzato

 

Inoltre, per poter sviluppare il PoC al meglio, ci siamo avvalsi di una metodologia che, da diversi anni  è presente nel mondo dell’IT a livello internazionale; stiamo parlando dell’approccio DevOps. 

Quando si parla di DevOps bisogna far riferimento ad una nuova cultura, ad un cambiamento radicale applicato al mondo Dev (development) ed Ops (Operations) e, quindi, un approccio rivolto all’automazione dei processi e ad una modalità collaborativa tra i membri del team coinvolti. 

E’ un paradigma che descrive le metodologie da adottare per accelerare i processi di un’idea da concretizzarsi passando in maniera facile dalla fase di sviluppo e progettazione, a quella di produzione. 

Che cosa deve essere chiaro per approcciarsi al DevOps? 

Il team deve essere solido, compatto, collaborativo, con un buon livello di comunicazione ed una continuità nel medio-lungo periodo.

Elemento chiave? L’empatia e la capacità di comprendere tutti i membri del team per affinare al meglio la propria cooperazione, giungendo alla perfezione operativa nel minor tempo possibile. 

Grazie al DevOps si hanno una serie di vantaggi:

  1. Efficienza, passando dal self-service e l’automazione;
  2. Velocità: gli sviluppatore lavorano a stretto contatto con l’anima operativa per velocizzare le fasi di creazione, collaudo, rilascio dei software e delle infrastrutture ad essi correlate
  3. Affidabilità: riduzione degli errori dovuti all’intervento umano.

Come già accennato, quando parliamo di DevOps, parliamo di cambiamento; ogni cambiamento richiede impegno e richiede la capacità di sfruttare al meglio le competenze, le capacità e le tecnologie adeguate.

L’elemento da non dimenticare mai quando si parla di DevOps è l’automazione. 

Perché?

E’ grazie all’automazione che si verifica l’ottimizzazione del tempo per integrare, in maniera agile, eventuali modifiche effettuate al software, scalando ed adattando in maniera flessibile tutte le componenti dell’infrastruttura sottostante. 

Che altro OFFRE il DevOps?

L’automazione permette a tutti i professionisti IT di dedicarsi alle attività importanti, garantendo loro coerenza e riducendo le possibilità di errore, evitando quindi di perdere il loro tempo in compiti banali e ripetitivi. 

I servizi offerti da Azure DevOps sono:

    • Azure Board : Usato per la pianificazione del team basato sulla filosofia Agile/Scrum;
  • Azure Repos : Usato per l’hosting dei repository e la gestione del versioning;
  • Azure Pipelines : Usato per automatizzare le compilazioni e le distribuzioni;
  • Azure Test Plans : Usato per il testing pianificato ed esplorativo;
  • Azure Artifacts : Aggiunge la gestione dei pacchetti integrata alle pipeline;

Tra questi, per la PoC, ci concentreremo su Azure Repos, come contenitore dei repositories, e su Azure Pipelines, come aggregatore di pipeline.

Questi due servizi sono essenziali per seguire la metodologia di lavoro GitOps, la quale necessita che tutto il sorgente sia centralizzato in un repository e che per certi eventi sul sorgente venga eseguita una Pipeline alla quale viene delegato il compito di eseguire azioni finalizzate eventualmente al deploy.

 

Per ogni casistica definita nel paragrafo precedente verrà realizzata una repository che conterrà il codice necessario per conseguire l’obiettivo definito, ad ogni repository è associata una pipeline.

Tutte le pipeline vengono triggerate ad ogni nuovo “commit” sul “branch” principale della repository.
Per ogni casistica si concorderà quali permessi sono necessari per eseguire le pipelines.

Un’organizzazione così modulare del sorgente permette di:

  • Rende lo sviluppo più semplice e veloce, permettendo allo sviluppatore di concentrarsi solo sul sorgente necessario
  • Permette un maggior controllo sulle feature/fix che vengono effettuate e riduce i permessi necessari per eseguire le pipelines.

 

Se volete conoscere i risultati ottenuti, seguiteci e leggete il prossimo, capitolo…

 

Coming soon…

17 Marzo 2022

m.fontana@bluecube.it

KoDa

KoDa

KoDa – IT Project

KoDa – IT Project 0

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.

 

22 Febbraio 2022

m.fontana@bluecube.it

devops

DevOpsSviluppoTipologie & Campi di Applicazione

DevOps: il sinonimo del nostro presente e futuro informatico 

DevOps: il sinonimo del nostro presente e futuro informatico  0

DevOps: il sinonimo del nostro presente e futuro informatico 

DevOps è un termine relativamente nuovo nel mercato dell’informatica e della tecnologia. 

Nato dall’incontro di due parole, Developer e Operations, è diventato in poco tempo una metodologia di lavoro che consente di ottenere molteplici vantaggi, ottimizzando il lavoro di entrambe le parti (ramo sviluppo e team IT operation). 

DevOps: Quando è nato esattamente? 

L’origine della parola è riconducibile al 2009 quando due parole, Developer e Operations si unirono. 

Che cosa indicano entrambi i termini?

Con Developers si indicano gli sviluppatori e tutti coloro che sono coinvolti nello sviluppo del prodotto (ad esempio: Product Owner & Quality Assurance). 

Con Operations si indicano invece tutte le competenze professionali, ed in particolare connesse alle figure di system engineer, administrator, tutto il team di operation, network engineer e professionisti della sicurezza. 

Detto ciò, l’obiettivo principale di questo approccio è proprio quello di riuscire il più possibile ad avvicinare i due team, quello di programmazione e quello di sistemisti che, vista la loro intrinseca natura, alle volte hanno obiettivi che non combaciano e che possono entrare in contrasto! 

Perciò, lo scopo principale di questa metodologia è quello di poter realizzare un flusso unico di lavoro che, all’inizio specialmente, dovrà essere pianificato.

In realtà, dare una definizione specifica a questo approccio non è semplice come sembra!

Il fondatore di questo approccio, Patrick Debois, diede questa definizione:  “It’s a movement of people who think it’s change in the IT Industry – time to stop wasting money, time to start delivering great software, and building systems that scale and last”. 

DevOps: alcune definizioni per spiegare il concetto 

DevOps è: unione di processi, tecnologia e persone per offrire valore agli utenti finali

DevOsp è: metodologia Agile di sviluppo software, utilizzata per migliorare la procedura di distribuzione e la manutenzione dei contenuti creati. 

DevOps è: una logica integrata in cui i diversi aspetti di pianificazione, sviluppo, test, deploy, produzione e monitoraggio si relazionano all’interno di un processo organico e continuo. 

DevOps: semplicemente una nuova cultura, un nuovo approccio, un’evoluzione che migliora ed ottimizza i tempi, le risorse ed i processi aziendali ed ha come obiettivo principale il miglioramento della collaborazione tra sviluppatori ed operations per velocizzare la realizzazione di software e rendere più efficienti i relativi processi. 

DevOps: keep C.A.L.M.S. e scegli questo approccio!

DevOps racchiude in sé una serie di principi che, uniti tra loro in una forma sinergica, vengono riconosciuti con l’acronimo C.A.L.M.S. (da non confondere con l’Agile, i cui principi sono iscritti sul famoso Manifesto). 

“Sciogliamo” l’acronimo e scopriamo insieme i vari prinicpi: 

  1. C = Culture: quando si lavora in ambito DevOps è prioritario avere una cultura di tale concetto connesso ad un chiaro percorso verso obiettivi comuni.
  2.  A = Automation: la metodologia DevOps trova negli strumenti la fonte importante per realizzare tutti i processi di provisioning, system integration, release management, system integration, control…
  3. L = Lean: quando si parla di DevOps il proprio pensiero connette due parole tra loro, quali, snello e veloce! Proprio così, perché all’interno di questo approccio è fondamentale snellire e velocizzare i processi per ottimizzare un lavoro al meglio!
  4. M = Measurement: beh, la misurazione dei risultati, delle performance ottenute ed anche dei processi diventa necessario per realizzare un continuo miglioramento. Ecco perché l’analisi e la misurazione deve essere parte integrante di ogni lavoro.
  5. S = Sharing: condividere i risultati ed il proprio lavoro è parte del DNA DevOps ed è allo stesso tempo il modo di lavorare che DevOps stesso propone, così che Developers ed Operations vedano il nemico nel problema e non tra di loro!!! 

DevOps: perché utilizzarlo? 

Grazie a DevOps, la programmazione e lo sviluppo lavorano in sinergia e a ciclo unico sun porzioni di software e non su tutta l’applicazione e ciò permette di: 

  1. Accelerare i tempi di rilascio del software
  2. Migliorare la qualità del codice
  3. Garantire una maggior stabilità e sicurezza
  4. Standardizzare l’infrastruttura
  5. Automatizzare le distribuzioni
  6. Testare l’applicazione in ambienti diversi
  7. Assicurare il successo del software. 

DevOps: perché scegliere proprio noi? 

Il team Bluecube è composto da personale esperto e fortemente skillato in ambito di DevOps; abbiamo applicato questa metodologia dal 2016 quando ancora si parlava di DevOps ma non si conosceva a pieno.

Una dimostrazione di ciò che diciamo? Il progetto con Moresi.com! Nessuna informazione supplementare in merito a questo lavoro.

Volete saperne di più? Cliccate il link seguente e date un’occhiata a quella che noi chiamiamo solitamente “Partnership di Valore”!.

https://www.bluecube.it/moresi-com-e-bluecube-annunciano-una-nuova-partnership-per-offrire-servizi-di-azure-devops/

Ottimizza e facilita anche tu tutti i processi grazie al DevOps! 

Scegli persone che ti sappiano guidare, che sappiano offrirti la migliore soluzione per te e per il tuo business; scegli persone realmente certificate!

Scegli noi!

 

29 Luglio 2021

m.fontana@bluecube.it

#AWS#BluecubeAws#CERTIFICATOAWS

Sviluppo

L’AWS DAGLI OCCHI DI UN ESPERTO

L’AWS DAGLI OCCHI DI UN ESPERTO 0

 

L’ AWS DAGLI OCCHI DI UN ESPERTO

 

“Le skills validate tramite certificazione ti danno modo di essere un punto di riferimento ed anche un mentor per i colleghi così’ da guidare la crescita professionale del team” .

 

Queste, le parole del nostro Cloud Architect, Mourad Hassani.

Per Bluecube essere certificati vuol dire oltrepassare il confine della conoscenza fine a sé stessa.

Il mondo dell’IT e dell’High Tech è in continua evoluzione e la preparazione è fondamentale, in egual misura di come è la consapevolezza di lavorare in un team unito e preparato in grado di supportarsi e di farsi guidare per raggiungere i migliori risultati e di conseguenza, di raggiungere l’ottimizzazione dei processi e la soddisfazione dei propri clienti.

Sulla base di ciò, ottenere la certificazione AWS consente di:

  1. Migliorare la confidenza nella vita professionale -”Se ottieni la certificazione, la fai con principio e con voglia di imparare, acquisisci confidenza perché conosci le logiche di tale tecnologia. Tutto dipende da COME approcci il tuo studio e costruisci il tuo bagaglio di conoscenze ed approfondimenti che ti permettono di affrontare in serenità la gestione di progetti che ti vengono affidati”- dice Mourad.
  2. “Inoltre”- aggiunge – “per un futuro professionale ti si aprono le porte a maggiori possibilità lavorative nelle quali puoi apportare un valore aggiunto di grande rilievo”.
  3. “Infine, hai più credibilità, poiché alla base di qualsiasi preparazione si ritrovano due pilastri indispensabili, quali dedizione all’impegno e studio continuo, che si congiungono nella ‘fame’ di essere sempre più al passo con gli sviluppi presenti sul mercato tecnologico ed ogni singola fase della formazione ti fa crescere: gli esami ti testano, ed una volta in campo, porti la soluzione più adatta a ciascun esigenza.
     
  4. Una volta che termini questo percorso, hai un biglietto da visita che attesta le tue competenze, tenendo sempre presente che dietro a questo ‘biglietto’ c’è costruito un duro percorso”, conclude Mourad.

Al nostro esperto, che ha conseguito la “SA” Associate e Professional abbiamo domandato quali fossero i vantaggi effettivi di possedere questa certificazione e di seguito, il pensiero di Mourad: 

“Nel momento in cui lavori come Architect ricopri un ruolo critico in quanto hai la responsabilità e le capacità  per disegnare la soluzione più efficiente in termini di sicurezza, affidabilità, gestione e riduzione dei costi in un determinato contesto”.  

Ed i vantaggi individuali?

Sicuramente ci troviamo di fronte ad una soddisfazione personale e come ben si sa, ogni traguardo che il singolo individuo raggiunge, è un passo in avanti verso un prossimo obiettivo dalle difficoltà e dalle sfide maggiori.

La soddisfazione e l’auto-riconoscimento personale sono fattori rilevanti che spingono una persona al conseguimento di obiettivi di successo.

Essere certificati AWS significa poter accedere a servizi, eventi oltre contribuire allo sviluppo della partnership per la propria azienda.

Per finire, è bene ricordare che il mondo della tecnologia di sposa con il termine Cloud, ed è per questo che se anche tu hai bisogno di utilizzarlo ma non sai come iniziare, potresti scegliere di affidarti a personale esperto.

Che aspetti?

Contattaci!

 

Follow Us

Latest posts

Contact us