Seguici

Archive for Marzo, 2022

Home / 2022 / Marzo

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

Archeologia DigitaleCultura InformaticaTexas Instruments TI-99/4A

Archeologia Digitale

Texas Instruments TI-99/4A

Texas Instruments TI-99/4A 0

 

Conosciuto come TI-99/4A o TI99/4A, il Texas Instruments TI-99/4A fu uno dei primi home computer che vennero prodotti e lanciati sul mercato da parte della Texas Instruments tra il 1981 e il 1983.

La sua diffusione avvenne soprattutto negli USA ma, a seguito di una guerra commerciale contro la Commodore International, la Texas Instruments non raggiunge un livello significativamente alto di vendite e, con il successo del Commodore 64, la Texas Instruments vide la cessazione della produzione dopo solo due anni dal lancio. 

Il Texas Instruments TI-99/4A a differenza di alcuni home pc e macchine d’epoca che richiedevano una specifica espansione con tastiera ad escursione, supportava la scrittura in minuscolo ed era basata sul TMS-9900, CPU a 16 bit con clock a 3 MHz. 

Altre caratteristiche relative alla grafica erano:

  1. Presenza di 16 colori 
  2. Risoluzione video di 256*192 pixel (32 colonne * 24 righe)
  3. Caratteri 8*8 pixel (ASCII o definibili dall’utente).

Com’era composto l’hardware? 

L’ hardware del Texas Instruments TI-99/4A era stato costruito intorno ad unico blocco.

All’interno di esso c’era la CPU, la scheda madre ed uno slot a cartucce.

Disponeva inoltre di un drive per floppy da 5.25”, una scheda seriale RS-232 con due porte seriali ed una parallela, una scheda P-Code per supportare il linguaggio di programmazione Pascal, un accoppiatore acustico, una stampante termica ed una coppia di joystick per videogames (memoria espandibile fino a 32 kB)  L’ azienda chiamava l’apertura per la coppua di Joystick, “wired remote controllers”, in italiano “controlli a distanza”.

Ciò che caratterizzava il Texas Instruments TI-99/4A era la sua vendita: l’esemplare veniva venduto con tanto di monitor incluso poiché l’adattatore RF utilizzato per collegarlo ad una normale TV non ebbe mai la certificazione da parte della Federal Communications Commission. 

Solo in Italia veniva venduto sprovvisto di monitor perché l’uscita video era compatibile con le televisioni dell’epoca. 

Per non dimenticare un’altra delle particolarità che hanno caratterizzato il Texas Instruments TI-99/4A era la presenza di un sintetizzatore vocale opzionale, come quello dell’Atari 2600, fornito in maniera gratuita ai clienti dopo l’acquisto di un numero determinato di cartucce.

Il sintetizzatore vocale opzionale permetteva di dotare il software o i giochi di sintesi vocale (venne infatti molto utilizzato da numerosi videogames, lanciati dalla Texas Instruments).

Ed il software? 

Il Texas Instruments TI-99/4A utilizzava il TI BASIC come linguaggio di programmazione, che poteva essere espanso anche in TI Extended BASIC (si trattava di una versione più avanzata di quello BASIC che venivano usati dai precedenti pc prodotti dalla Texas Instruments).

L ’home pc non permetteva però di utilizzare il linguaggio macchina creato dall’utente e neppure di scrivere programmi che accedevano in maniera grafica in alta risoluzione.

Per fare ciò bisognava acquistare il modulo “MINIMEMORY” in maniera separata (sempre prodotto dalla Texas Instruments), oppure si poteva espandere grazie al Peripheral Expansion box (prodotto sempre dalla Texas Instruments) con previa espansione anche della RAM da 32 KB.

Come si utilizzava il Texas Instruments TI-99/4A? 

Una cosa molto particolare del Texas Instruments TI-99/4A era che il manuale di istruzione in realtà era una vera e propria guida all’uso e alla programmazione del linguaggio di programmazione TI BASIC.

All’interno del manuale di istruzione è tutto spiegato molto in dettaglio (con tanto di esempi di programmazione); è scritto in modo molto semplice per dare a tutti gli utilizzatori, la possibilità di apprendere tale linguaggio senza avere nessun tipo di nozione nel mondo della programmazione. 

Qual era il “difetto”?

Il TI BASIC è molto lento e limitato, soprattutto per il Texas Instruments TI-99/4A e ciò faceva nascere la necessità di fare un cambiamento e di avere una marcia in più per avere un rapporto di funzionalità/velocità ottimale. 

La Texas Instruments era al corrente di questo problema e si era già portata avanti, preparando una cartuccia, l’Extended Basis, che dava la velocità necessaria!

Qui sotto, un’immagine delle istruzioni del Texas Instruments TI-99/4A.

 

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.

 

Follow Us

Latest posts

Contact us