DEV Community: Serena Sensini

Quando muore un Pod

Serena Sensini — Thu, 07 Dec 2023 00:00:00 +0000

Quando un container fallisce e un Pod muore , possono esserci diverse ragioni, e queste sono sempre descritte all’interno dei termination messages.

Questo tipo di dato è fondamentale per comprendere quali siano gli eventi che hanno portato all’arresto dell’applicazione e quindi per permettere ai team di indagare sull’origine della causa.

Di default, questi messaggi risiedono nella cartella /dev/termination-log: questo vuol dire che, quando il Pod termina, il campo relativo al suo status viene aggiornato con le informazioni che riguardano le cause di arresto, come mostrato di seguito.

Creando un Pod come il seguente, facciamo sì che il container attenda 30 secondi prima di stampare in output il messaggio “Good night!”, riportandone il contenuto nel path di default:

apiVersion: v1
kind: Pod
metadata:
 name: demo
spec:
 containers:
 - name: demo
 image: centos
 command: ["/bin/sh"]
 args: ["-c", "sleep 30 && echo Good night! > /dev/termination-log"]

Questo messaggio è recuperabile sfruttando il campo status del template del Pod, in questo modo: utilizzando il comando kubectl get pod e recuperando l’output in formato yaml, dovremmo ottenere un risultato simile al seguente, dove il campo status contiene al suo interno una serie di dettagli sullo stato dei container e della causa del loro arresto:

kubectl get pod demo --output=yaml

>>>
apiVersion: v1
kind: Pod
...
 lastState:
 terminated:
 containerID: ...
 exitCode: 0
 finishedAt: ...
 message: | #################
 Good night! ################
 ...

Si è già detto che Kubernetes recupera i messaggi di arresto dal file /dev/termination-log; qualora volessimo però specificare un path diverso, potremmo utilizzare il campo terminateMessagePath all’interno delle specifiche del container.

Kubernetes utilizzerà il contenuto del file specificato per popolare il messaggio di stato del container sia in caso di successo che di errore.

Il messaggio di terminazione deve essere un breve stato finale, ad esempio un messaggio di errore rispetto a dei test o delle asserzioni che controllano lo stato di integrità del pod; dev’essere breve perché kubelet tronca i messaggi più lunghi di 4096 byte.

Un’altra nota interessante è che non è possibile impostare il percorso del messaggio di terminazione dopo l’avvio di un pod : questo deve essere impostato prima del suo avvio, altrimenti verrà utilizzato quello di default.

apiVersion: v1
kind: Pod
metadata:
 name: demo
spec:
 containers:
 - name: demo
 image: centos
 terminationMessagePath: "/tmp/my-custom-log-file"

Risorse utili

Documentazione ufficiale

Voglio diventare... SEO Specialist

Serena Sensini — Tue, 28 Nov 2023 00:00:00 +0000

Descriviti in 100 parole

Sono una SEO Specialist , ovvero una specialista dell’ottimizzazione dei siti web per i motori di ricerca. Negli anni mi sono occupata sia di realtà locali, che di realtà internazionali e al momento lavoro prevalentemente su ecommerce Magento e Shopify - molti dei quali nel settore fashion.

Sono una persona con una grande passione per ciò che fa, ho la fortuna di lavorare in un settore che mi piace, mi trasmette passione e mi genera un desiderio di scoperta continua. La SEO è un grande amore per me, oltre che un lavoro.

Ma il mio cuore non batte solo per il digital marketing , sono anche amante del cinema e laureata in filosofia.

In cosa consiste il ruolo di SEO Specialist?

Il mio lavoro consiste in una serie di ottimizzazioni legate ai siti web e alle piattaforme ecommerce che permettono di ottenere visibilità sui motori di ricerca. Le tre macro aree su cui lavora un SEO sono: tecnica, contenutistica e off-site.

Per quanto riguarda la parte più tecnica ogni piattaforma online richiede spesso gli interventi di un SEO con lavori come migrazioni, setting di tag html o generazione di sitemap e file robots.txt.

La parte contenutistica riguarda invece tutti quei contenuti che tipicamente il bot del motore di ricerca ritrova su una pagina, rientrano in questa area i lavori di analisi semantica, ricerca keywords, stesura dei metadati, ecc…

Infine, il ramo off-site riguarda tutto ciò che avviene al di fuori di un sito web, ma ne influenza la reputazione agli occhi del motore di ricerca. Un esempio di ciò è l’attività di link building.

Qual è la soft skill più importante che deve possedere una SEO Specialist?

Curiosità senza ombra di dubbio, in quanto si tratta di un’attività in fermento ed evoluzione, che necessita studi continui.

La maggior parte di noi utilizza i social per parlare dei propri successi, ma la realtà è che siamo quel che siamo grazie al 90% dei nostri errori. Racconta il tuo più grande fallimento da quando lavori nel settore, che però ti ha reso ciò che sei.

Non c’è mai stato un vero e proprio caso di fallimento, ma spesso capitano gli errori. Gli errori avvengono nelle carriere di ciascuno di noi e sono ciò che ci permette sempre di crescere e avanzare, evolverci! Ogni santo giorno imparo qualcosa soprattutto grazie agli errori che compio.

Come fare per diventare una SEO Specialist?

Si tratta di un percorso composto da due elementi necessari: tanto studio e tanta pratica. Ho iniziato anni fa letteralmente lavorando gratis su progetti personali e non solo, studiando molto nel mentre. In definitiva, in fase di colloquio, conta ciò che si sa effettivamente, non tanto le certificazioni presentate.

Parlando di successi, qual è il tuo prossimo obiettivo? Quale ruolo vorresti ricoprire entro i prossimi 3 anni?

Al momento sono molto felice del mio lavoro attuale.

Conosci il tema gender gap in ambito STEM? Se sì, come fare per superarlo?

Si tratta di un tema ampio, che non coinvolge solo l’ambito STEM. Personalmente ritengo ci siano realtà dove è più o meno accentuato il gender gap. Come superarlo? Partendo da un educazione collettiva, fin dall’infanzia, alla meritocrazia.

Risorse utili

Letture consigliate

SEO Checklist di Verdiana AmorosiSEO Audit Avanzato di Marco Maltraversi, Davide Prevosto e Giovanni SacheliManuale di SEO Gardening di Francesco MargheritaKeywords research Avanzata di Alvise CanalLink Building di Ivano Di BiasiSEO per E-commerce di Gaetano RomeoThe Art of SEO di Eric Enge, Jesse C. Stricchiola, Stephan Spencer

Corsi consigliati

Deep SEO di Marco Maltraversi SEO per E-commerce di Massimo Fattoretto Tech SEO Pro - Advanced Technical SEO Course di Kristina Azarenko Search Engine Optimization (SEO) Specialization di University California Davis

Contatti

Profilo LinkedIn

Voglio diventare... SEO Strategist

Serena Sensini — Tue, 21 Nov 2023 00:00:00 +0000

Descriviti in 100 parole

Ciao, sono Francesca e sono un’amante dei gatti, del buon cibo e del True Crime. Sono_leggermente_ appassionata di questioni di genere, tanto da aver dedicato la mia tesi di laurea magistrale proprio agli stereotipi nelle serie TV (ovviamente Crime).

A livello professionale mi definisco un’umanista a cui piacciono i dati.

Dopo essermi laureata in Studi Internazionali e Scienze della Comunicazione, ho attraversato per qualche anno la fase critica dei tirocini (poco) formativi e sottopagati, senza smettere però di formarmi in autonomia e con progetti personali.

Per puro caso nel 2018 sono arrivata in un’agenzia SEO , nella quale sono rimasta fino a pochi giorni fa. Sono infatti in procinto di iniziare una nuova avventura come Content Specialist in un’altra realtà!

In cosa consiste il ruolo di SEO Strategist?

Non sono sicura che quello di SEO Strategist sia un Job Title effettivamente “codificato”. È un ruolo che mi sono attribuita perché mi sembrava idoneo a definire la mia attività quotidiana all’interno del team. Non avendo le competenze pratiche a livello informatico per potermi definire una SEO Specialist a tutto tondo, ma nemmeno occupandomi esclusivamente di SEO Copywriting, ho pensato di “affibbiarmi” il titolo di stratega.

Nel corso degli anni il mio ruolo è andato evolvendosi, passando dalla creazione e ottimizzazione di contenuti e definizione di piani editoriali per i siti dei clienti, allo sviluppo di strategie basate sui dati, passando per SEO Audit , ottimizzazioni tecniche e contenutistiche e follow-up degli andamenti.

Riassumendo in poche parole: il SEO Strategist è una figura che analizza il settore e i dati organici a disposizione per sviluppare una strategia SEO a tutto tondo, sia On Site che Off Site e si affianca, laddove non arriva da solo, a figure IT per le implementazioni più consistenti.

Qual è la soft skill più importante che deve possedere una SEO Strategist?

Credo siano necessarie diverse skills, tra cui la flessibilità mentale e il problem solving.

Ma credo che la regina delle soft skills per fare SEO sia il pensiero laterale: mai come negli ultimi anni ci sono stati aggiornamenti dell’algoritmo di Google, che hanno rimescolato le carte e cambiato i fattori che determinano il posizionamento di un contenuto.

Per quanto alcuni elementi di ranking non siano mai stati messi in discussione, è fondamentale saper analizzare, cogliere i segnali e prendere delle decisioni spesso basate su dati a bassa storicità e sulla propria esperienza, pensando fuori dai canoni che potevano essere veri fino a qualche settimana prima (ovviamente partendo da un buon set di conoscenze teoriche e pratiche).

Da persona quadrata quale sono, sono spesso rimasta stupita di quanto alcune decisioni_istintive_ abbiano portato più risultati di quelle prese razionalmente, manuale alla mano.

La maggior parte di noi utilizza i social per parlare dei propri successi, ma la realtà è che siamo quel che siamo grazie al 90% dei nostri errori. Racconta il tuo più grande fallimento da quando lavori nel settore, che però ti ha reso ciò che sei.

Sarò sincera: non sopporto i post motivazionali , né tantomeno i professionisti su LinkedIn che usano lo storytelling per raccontare anche il più banale degli avvenimenti. Questo perché credo, come dici tu, che a formarci siano i nostri errori e i periodi neri che ovviamente non andiamo a raccontare sui social (guai risultare fragili e fallaci in questa_società della performance_!).

Faccio fatica però ad associare il termine fallimento all’ambito lavorativo. Nel corso di questi anni ho commesso diversi errori, fortunatamente mai tanto gravi da compromettere il successo di un sito, ma ho sempre pensato che in questi casi è fondamentale prendersi la propria responsabilità con l’azienda e con il cliente e intervenire per risolvere al meglio.

Solo in questo modo si può imparare e non perseverare nell’errore, perché lo “sbattimento” affrontato la volta precedente non lo scorderemo con facilità. Questo ci renderà molto più responsabili e consapevoli delle nostre azioni.

E poi bisogna anche imparare ad essere clementi con sé stessi/e - come ripeto sempre, solo chi non fa, non sbaglia mai - a delegare e a fidarsi del proprio team.

Come fare per diventare una SEO Strategist?

Forse andrò controcorrente, ma credo che per fare bene SEO sia importante avere una formazione umanistica in Semiotica o in Comunicazione, non tanto per le competenze in sé (quelle si possono sempre acquisire con il tempo), quanto per la forma mentis più aperta che solo le facoltà umanistiche sanno darti.

Questo non toglie che sia fondamentale integrare le competenze tecniche, magari con libri e
corsi mirati. Indispensabile è fare pratica con i tool principali per la SEO (Screaming Frog,Search Console, GA4, ecc…) in modo da familiarizzare anche con l’interpretazione dei dati e facilitare la comprensione del processo causa-effetto.

Ho aperto il mio primo blog a 15 anni, ai tempi di Fotolog e MySpace, e iniziato a smanettare con HTML e CSS quando non sapevo nemmeno si chiamassero così: per me erano solo le “cose” che dovevo fare per personalizzare esteticamente il sito e mettere online i miei pensieri.

Credo proprio che il modo migliore per imparare sia questo: aprire un proprio sito e sbatterci la testa, andando a tentativi, sbagliando e applicando ciò che si è imparato.

Parlando di successi, qual è il tuo prossimo obiettivo? Quale ruolo vorresti ricoprire entro i prossimi 3 anni?

Il mio obiettivo a brevissimo termine, come anticipavo poco fa, è quello di buttarmi a capofitto nel nuovo ruolo di Content Specialist che andrò a ricoprire.

Onestamente sono molto fan del “qui e ora” per quanto riguarda il lavoro, perché le ambizioni possono cambiare da un giorno all’altro, così come rimanere le stesse per anni.

Di una cosa però sono certa: voglio continuare a lavorare con i contenuti in modo da tenere sempre viva la mia passione per la scrittura.

Conosci il tema gender gap in ambito STEM? Se sì, come fare per superarlo?

Come dicevo in apertura, sono molto coinvolta nei discorsi che riguardano la disparità di genere e l’emancipazione femminile. Credo il gender gap in ambito STEM abbia radici legate allo stereotipo per cui il maschio ragiona in maniera analitica, mentre la donna prende le proprie decisioni sulla base dell’emotività.

Questo stereotipo si traduce fin dall’infanzia in una sorta di “ruolo assegnato”: le bambine vengono “naturalmente” spinte verso le materie umanistiche, mentre i bambini verso quelle scientifiche. Mancano dei modelli di riferimento storici e attuali per le ragazze e, allo stesso tempo, TV e Social Network rappresentano la donna quasi sempre come figura secondaria, subalterna o limitata a particolari ambiti, a scapito delle sue competenze.

Credo che per superare il gender gap ognuno dovrebbe fare il suo: bisognerebbe in primis intervenire fin dall’infanzia in famiglia e a scuola, dando la possibilità ai bambini e alle bambine di sviluppare con il gioco e lo studio le proprie potenzialità a 360° , senza alcun tipo di limite attribuito al genere o inconsciamente imposto dalla società.

In secondo luogo, è importantissimo creare una narrazione diversa del femminile , rappresentando più spesso modelli positivi e di successo in ambito accademico (per la mia generazione sono state Margherita Hack e Rita Levi Montalcini, per quelle attuali potrebbe essere, ad esempio, Samantha Cristoforetti).

Bisogna, in sostanza, superare l’errata convinzione secondo cui in base al genere si sia più portati per una materia, piuttosto che per un’altra.

D’altronde, diversi dati dimostrano come le donne iscritte alle facoltà STEM, seppur in quantità inferiore, abbiano delle carriere accademiche più brillanti rispetto ai colleghi uomini, palesando la totale assurdità dello stereotipo che ci portiamo dietro da secoli.

Contatti

Profilo LinkedIn

Kubectl: namespace vs context

Serena Sensini — Thu, 16 Nov 2023 00:00:00 +0000

Se usi kubectl, ti sarà capitato di vedere su qualche guida online il comando set-context: ma a che serve?

Partiamo dal concetto di namespace : questo serve a creare un raggruppamento logico di oggetti Kubernetes, proprio come raggruppiamo i file all’interno di cartelle diverse nei sistemi operativi.

Infatti, i namespaces forniscono un meccanismo per isolare gruppi di risorse all’interno di un singolo cluster. I nomi delle risorse devono essere univoci all’interno di uno stesso namespace, ma non tra namespace diversi.

I namespace sono pensati per essere usati in ambienti con molti utenti che appartengono a più team o progetti. Per i cluster con pochi utenti, non dovrebbe essere necessario creare dei namespace, come avviene in un ambiente di sviluppo locale.

Il concetto e il termine context in Kubernetes invece si applica solo sul lato client di Kubernetes, ovvero il luogo in cui esegui il comando kubectl. Ad esempio, quando lavori tramite terminale ed esegui il comando seguente, stai dicendo a kubectl che, in questo ambiente dove viene eseguito, deve considerare come contesto corrente (quindi come ambiente di lavoro) il namespace chiamato test.

kubectl config set-context --current --namespace=test

Questo vuol dire che, lato server, Kubernetes non riconosce questo “contesto”, ma che d’ora in poi, quando andremo a eseguire dei comandi, kubectl ci risparmierà la fatica di dover aggiungere il parametro che specifica il namespace dove quell’istruzione dev’essere eseguita.

Di base, la differenza è la seguente: quando esegui un comando come questo:

kubectl get pods -n test

stai recuperando l’elenco dei pod situati nel namespace “test”.

Se invece esegui il comando precedente senza specificare il namespace, questo risultato potrebbe variare dal namespace in cui l’utente è loggato:

kubectl get pods

kubectl config current-context # per verificare il contesto corrente

Il contesto diviene quindi un modo perfetto per specificare che, in questa sessione di lavoro con il cluster Kubernetes a cui abbiamo acceduto, i comandi eseguiti fanno tutti riferimento a un solo namespace.

L’altro vantaggio nell’utilizzo dei contesti sta nel definire un contesto per ogni namespace , così da poter_switchare_ dall’uno all’altro a seconda del momento: immagina di creare un contesto per l’ambiente di sviluppo che si riferisce al namespace dev, uno per l’ambiente di collaudo, che si chiama preprod, e così via…

kubectl config set-context preprod-context --namespace=preprod

Senza contare il fatto che è possibile creare più contesti per più cluster, specificando il parametro –cluster, come mostrato di seguito: questo ci permetterà di passare non solo da un namespace all’altro, ma anche di cambiare il cluster di lavoro utilizzato!

kubectl config set-context preprod-context --cluster=mycluster --namespace=preprod

Come sfruttare i diversi contesti creati? Basterà eseguire il comando kubectl use-context per passare dall’uno all’altro!

kubectl config use-context preprod-context

Tip

Ma dove vengono salvate queste informazioni? Dai un’occhiata all’interno del file ~/.kube/config:

apiVersion: v1
clusters:
 - cluster:
 insecure-skip-tls-verify: true
 server: https://api.xxx.yyy.zzz:6443
 name: api-xxx-yyy-zzz:6443
contexts:
 - context:
 cluster: api-xxx-yyy-zzz:6443
 namespace: dev
 user: kube:admin/api-xxx-yyy-zzz:6443
 name: dev/api-xxx-yyy-zzz:6443/kube:admin
current-context: dev/api-xxx-yyy-zzz:6443/kube:admin
kind: Config
preferences: {}
users:
 - name: kube:admin/api-xxx-yyy-zzz:6443
 user:
 token: sha256~217823932n3j...

Certificati Self-Signed e OpenSSL

Serena Sensini — Thu, 09 Nov 2023 00:00:00 +0000

Definizione

Un certificato self-signed è un certificato SSL/TSL non firmato da un’autorità di certificazione pubblica o privata, che viene invece firmato dal certificato CA personale.

Come funziona

Il modo per richiedere un certificato SSL/TLS a pagamento da una nota autorità di certificazione, come Verisign o Comodo, è il seguente:

Creare una richiesta di firma del certificato (in inglese certificate signing request, abbreviato in CSR) con una chiave privata. Un CSR contiene dettagli su posizione, azienda e FQDN (ossia il nome di dominio completo);
Inviare la CSR all’autorità CA attendibile;
L’autorità (chiamata Certificate Authority, ossia CA) a cui abbiamo inviato la richiesta manderà indietro il certificato SSL firmato dall’autorità stessa e insieme a una chiave privata;
A questo punto, sarà possibile quindi convalidare e utilizzare il certificato SSL con le diverse applicazioni.

Se invece parliamo di un certificato self-signed, abbiamo bisogno di rivedere gli step precedenti, tenendo conto che la CA sarà interna.

Creare un’autorità locale e la chiave privata CA, e quindi prendere il posto della CA;
Creare una chiave privata per generare la CSR;
Creare un certificato SSL tramite la CSR utilizzando la nostra CA root e la chiave privata della CA;
Installare il certificato dell’autorità nel browser o nel sistema operativo per evitare avvisi di sicurezza.

Dove trovo le Certificate Authority del browser?

In Firefox, è sufficiente accedere alle “Impostazioni” e cercare la parola “certificati”: lì sarà presente una copia dei certificati che ogni sistema tiene a memoria di quelle che sono le autorità conosciute:

Allo stesso tempo, utilizzando un certificato self-signed, il browser genererà un avviso di sicurezza simile al seguente:

In ogni caso, è possibile forzare il browser ad accettare l’autorità di certificazione anche se creata, così da non vedere più nell’ambiente locale l’avviso di sicurezza una volta aggiunto all’elenco di quelli attendibili.

Chiaramente, è possibile anche condividere il certificato della CA con il team di sviluppo per installarlo anche nei loro browser, ma è un approccio che si consiglia di utilizzare solo su ambiente di test.

Come creare un certificato self-signed

Il procedimento che seguiremo è descritto nella figura seguente:

Come discusso in precedenza, dobbiamo creare il certificato principale della CA affinché i browser possano fidarsi del certificato self-signed.

Creiamo una directory denominata openssl per salvare tutte le chiavi e i certificati generati.

mkdir openssl && cd openssl

Esegui il seguente comando per creare il file rootCA.key e il file rootCA.crt. Sostituisci a example.com il tuo nome di dominio o l’indirizzo IP.

openssl req -x509 \
 -sha256 -days 356 \
 -nodes \
 -newkey rsa:2048 \
 -subj "/CN=exaple.com/C=US/L=San Francisco" \
 -keyout rootCA.key -out rootCA.crt

Utilizzeremo questi due file per firmare il certificato self-signed a breve.

A questo punto, creiamo una chiave privata :

openssl genrsa -out server.key 2048

Poi, iniziamo a lavorare alla CSR tramite un file csr.conf che conterrà tutte le informazioni circa la richiesta da inviare all’autorità:

cat > csr.conf <<EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = US
ST = California
L = San Francisco
O = TheRedCode
OU = TheRedCode
CN = example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
IP.1 = 192.168.1.5
IP.2 = 192.168.1.6

EOF

A questo punto, possiamo generare il file server.csr per richiedere la firma del certificato tramite la chiave privata generata in precedenza con il seguente comando:

openssl req -new -key server.key -out server.csr -config csr.conf

Ora la cartella dovrebbe contenere tre file: csr.conf, server.csr e server.key.

Eseguiamo quanto segue per creare il file cert.conf per il certificato SSL.

cat > cert.conf <<EOF

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com

EOF

Infine, eseguiamo il comando seguente per generare il certificato SSL firmato tramite i file rootCA.crt e rootCA.key creati come parte della nostra autorità di certificazione.

openssl x509 -req \
 -in server.csr \
 -CA rootCA.crt -CAkey rootCA.key \
 -CAcreateserial -out server.crt \
 -days 365 \
 -sha256 -extfile cert.conf

Il comando precedente genererà un file chiamato server.crt che verrà utilizzato con la chiave privata _server.key_per abilitare il protocollo SSL.

Ad esempio, nel caso di un server come Nginx , nella configurazione potremo andare a inserire quanto segue per riportare i riferimenti ai due file appena creati:

server {

listen 443;

ssl on;
ssl_certificate /etc/ssl/server.crt;
ssl_certificate_key /etc/ssl/server.key;

server_name your.domain.com;
access_log /var/log/nginx/nginx.vhost.access.log;
error_log /var/log/nginx/nginx.vhost.error.log;
location / {
root /home/www/public_html/your.domain.com/public/;
index index.html;
}

}

Non ci resta che installare la CA all’interno del browser per evitare che il browser mostri il messaggio precedente quando verrà utilizzato il certificato self-signed, e il gioco è fatto!

Nota : come detto in precedenza, questa procedura dovrebbe riguardare i soli ambienti di sviluppo o test; nei casi d’uso in produzione, una valida alternativa gratuita è Letsencrypt.

Drupal 9 + MySQL 5.7 su Kubernetes

Serena Sensini — Thu, 02 Nov 2023 00:00:00 +0000

Drupal è un CMS piuttosto popolare con una grande community dietro, ed è particolarmente popolare tra le grandi aziende e per i siti web complessi. Infatti, alcuni dei siti più visitati al mondo come Nokia,Wish, NASAutilizzano Drupal come CMS per i loro siti aziendali.

In questo post, andremo a vedere come configurare un’istanza di Drupal versione 9.5 con MySQL 5.7 su Kubernetes.

Spoiler : sarà più lungo l’articolo che la sua effettiva realizzazione!

Questo è lo schema di ciò che otterremo alla fine:

Persistenza

Sappiamo che i container non sono persistenti, quindi è necessario utilizzare dei Persistent Volumes per preservare i dati che Drupal dovrà salvare… Altrimenti, tutte le modifiche scritte nel database o in qualsiasi directory andranno perse dopo il riavvio del container!

Andiamo quindi a definire due PVC, supponendo che il cluster Kubernetes su cui lavoriamo abbia a disposizione un provisioner che si occupa di eseguire il binding tra le claim per lo storage e i volumi persistenti.

In questo caso richiediamo due volumi da 5 GB ciascuno, dove il primo sarà usato per i file del sito web e il secondo per il database MySQL. Chiaramente, questo dimensionamento è adatto a un ambiente di test o di demo, ma possono essere adattati!

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: drupal-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mysql-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi

Invece, per installare l’istanza di MySQL utilizzeremo un Deployment e un Service. Si noti che eseguiamo MySQL con un’utenza amministrativa, che può essere anche cambiata seguendo le indicazioni presenti nella documentazione ufficiale.

Infatti, quando lo si utilizza in produzione , utilizzare credenziali personalizzate e sicure. Peraltro, è buona pratica memorizzare questo tipo di informazioni in un Secret, per cui procediamo con la sua definizione e includiamo la password dell’utente root:

apiVersion: v1
kind: Secret
metadata:
 name: mysql-creds
stringData:
 MYSQL_ROOT_PASSWORD: root_password

Il Deployment di MySQL è piuttosto semplice: utilizza un’immagine mysql nella versione 5.7.8, tra le ultime disponibili e compatibili con la versione 9 di Drupal (vedi documentazione).

Inoltre, definiamo quelle che sono le variabili di ambiente che l’istanza dovrà utilizzare per configurare il database su cui l’istanza Drupal andrà a lavorare, e poi definiamo anche la porta 3306 come porta di ascolto per gli altri servizi e anche il path su cui il volume di MySQL creato in precedenza verrà montato.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: mysql
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - env:
 - name: MYSQL_ROOT_PASSWORD
 valueFrom:
 secretKeyRef:
 name: mysql-creds
 key: MYSQL_ROOT_PASSWORD
 - name: MYSQL_DATABASE
 value: drupal-database
 image: "mysql:5.7.8"
 imagePullPolicy: IfNotPresent
 name: mysql
 ports:
 - containerPort: 3306
 name: mysql
 protocol: TCP
 volumeMounts:
 - mountPath: /var/lib/mysql
 name: drupal-pvc
 subPath: dbdata
 volumes:
 - name: drupal-pvc
 persistentVolumeClaim:
 claimName: mysql-pvc
 selector:
 matchLabels:
 app: mysql

Il Deployment di Drupal sarà basato su un container con un’immagine di Drupal dal repository Docker Hub pari all’ultima versione ad oggi disponibile, ossia la 9.5.11.

Inoltre, utilizzeremo anche un container temporaneo (ovvero, un initContainer) la cui missione sarà quella di pre-popolare lo storage persistente con i dati utilizzati da Drupal.

Questo controller esporrà la porta 80 e ugualmente monterà un proprio volume con diverse cartelle per ogni componente necessario a Drupal per lavorare, come i themes, i modules o i sites.

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: drupal
 name: drupal
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: drupal
 spec:
 initContainers:
 - name: init-sites-volume
 imagePullPolicy: IfNotPresent
 image: drupal:9.5.11
 command: ['/bin/bash', '-c']
 args: ['cp -r /var/www/html/sites/ /data/; chown www-data:www-data /data/ -R']
 volumeMounts:
 - mountPath: /data
 name: pvc-drupal
 containers:
 - image: drupal:9.5.11
 imagePullPolicy: IfNotPresent
 name: drupal
 ports:
 - containerPort: 80
 volumeMounts:
 - mountPath: /var/www/html/modules
 name: pvc-drupal
 subPath: modules
 - mountPath: /var/www/html/profiles
 name: pvc-drupal
 subPath: profiles
 - mountPath: /var/www/html/sites
 name: pvc-drupal
 subPath: sites
 - mountPath: /var/www/html/themes
 name: pvc-drupal
 subPath: themes

 volumes:
 - name: pvc-drupal
 persistentVolumeClaim:
 claimName: drupal-pvc

 selector:
 matchLabels:
 app: drupal

Ultimo, ma non ultimo, creiamo i Service necessari per permettere ai due componenti di comunicare: quello per MySQL sarà di tipo ClusterIP, dal momento che dovrà interfacciarsi solo con Drupal, mentre quello per Drupal sarà di tipo LoadBalancer.

apiVersion: v1
kind: Service
metadata:
 name: mysql-service
spec:
 ports:
 - name: mysql
 port: 3306
 protocol: TCP
 selector:
 app: mysql

A seconda del tipo di infrastruttura Kubernetes su cui stiamo lavorando, sarà infatti possibile accedere all’istanza tramite browser : nel caso in cui si usi un cluster EKS su AWS, questo andrà a creare un Application Load Balancer che potremo usare per accedere alla prima pagina di Drupal:

apiVersion: v1
kind: Service
metadata:
 name: drupal-service
spec:
 ports:
 - name: http
 port: 80
 protocol: TCP
 selector:
 app: drupal
 type: LoadBalancer

Ora che la nostra soluzione è stata definita e importata, installiamo Drupal. È sufficiente navigare verso l’indirizzo ottenuto nel passaggio precedente e seguire le istruzioni per l’installazione guidata. Utilizzate le credenziali del database configurate in precedenza nel Deployment di MySQL.

Ad esempio, nel nostro caso, ecco i dati da specificare nella schermata di configurazione del database:

Nome del database: drupal-database, come la variabile d’ambiente MYSQL_DATABASE nel Deployment di MySQL.
Password del database: root_password, come la variabile d’ambiente MYSQL_PASSWORD nel Secret di MySQL.
Host: mysql-service, uguale al nome del Service MySQL
Porta: 3306, uguale alla porta specificato nel Service MySQL

Questo è tutto!

Ora avete un’istanza di Drupal funzionante, distribuita in meno di 10 minuti.

Docker AI: aumentare la produttività tramite un bot

Serena Sensini — Tue, 31 Oct 2023 00:00:00 +0000

Durante la DockerCon, a Los Angeles, Docker Inc ha presentato una novità: un programma che si occuperà di integrare tecniche di AI all’interno dei suoi strumenti, tra cui Docker AI , progettato per aiutare chi sviluppa a distribuire e ottimizzare i prodotti che includano questo tool.

Si tratta del primo prodotto che include degli strumenti AI per un prodotto che viene spesso utilizzato per creare a sua volta strumenti di AI, come Hugging Face e Replicate.

Secondo Scott Johnston, CEO di Docker, molti team rilasciano il proprio software a clienti e community attraverso container Docker:

“Le immagini dei container sono cosiddette immutabili, cioè riproducibili […]. Quando si costruiscono modelli, si analizzano dati, e così via, si vuole essere in grado di riprodurre i risultati indipendentemente dalla persona con cui si lavora, e indipendentemente dalla situazione. Il fatto che l’immagine del container sia immutabile aiuta molto in questo senso”.

Docker AI dovrebbe fornire una sorta di guida automatica quando le persone che sviluppano modificano un Dockerfile o simili, eseguono il debug della loro “docker build” in locale o eseguono un test, consentendo ai team di beneficiare della saggezza collettiva di milioni di professionisti/e che utilizzano Docker - alcuni da oltre 10 anni - seguendo le best practices di scrittura di questi file e selezionando immagini aggiornate e sicure per le proprie applicazioni.

Docker AI sarebbe dunque un bot che utilizza la GenAI progettato per assistere nell’utilizzo di Docker. È addestrato sui file per Docker Compose e sulla raccolta di errori che deriva dall’uso prodotto e dagli strumenti che offre Docker, ha dichiarato Johnston, senza “coinvolgere” o sfruttare i dati dei clienti.

Mentre Copilot e strumenti simili aiutano in attività come il completamento del codice si occupano del 10 o 15% della costruzione di un’applicazione, queste non sono mai fatte di un singolo “componente”: di solito utilizzano anche un database, un server web, uno strato di frontend e molto altro.

Questa percentuale è quella in cui Docker è spesso presente, perché fornisce immagini o docker-compose file utili a definire altre parti dell’applicazione attorno al core del prodotto. L’AI di Docker, quindi, servirebbe a completare questa fetta di componenti, occupandosi di quell'85-90% finale.

Sembra che, inoltre, questo strumento si integrerà con ambienti come Visual Studio Code e con gli ambienti di sviluppo web di JetBrains, tra i più utilizzati nell’ecosistema di chi programma.

Questo strumento è attualmente disponibile solo attraverso l’iscrizione a un programma di early access di Docker disponibilequi.

E tu, intendi provarlo?

Installa OpenShift Local con Podman Desktop

Serena Sensini — Thu, 26 Oct 2023 00:00:00 +0000

Qualche settimana fa abbiamo parlato di cosa fosse Podman e del nuovo strumento con interfaccia grafica chiamato Podman Desktop.

Una delle caratteristiche uniche di Podman Desktop è la sua integrazione con Red Hat OpenShift Local, che consente agli utenti di sviluppare e testare le applicazioni localmente, utilizzando le stesse immagini e lo stesso ambiente di container che utilizzerebbero in un ambiente di produzione su Red Hat OpenShift, ma più in piccolo.

Questo significa che potete assicurarvi che le vostre applicazioni funzionino senza problemi in un ambiente OpenShift prima di distribuirle!

Configurazione

Podman Desktop 1.0 include un’estensione per OpenShift Local, che si può installare dalla dashboard o attraverso le Impostazioni.

Configurazione tramite pagina principale

Configurazione tramite le impostazioni

Una volta installata, l’estensione consente di configurare le diverse impostazioni utilizzabili per OpenShift Local:

OpenShift con un singolo nodo alimentato da OpenShift Container Platform: completo, e più impegnativo dal punto di vista delle risorse consumate
MicroShift: leggero e ottimizzato (ad oggi ancora sperimentale) alimentato da un set di servizi minimo, ma molto veloce e leggero

Opzioni disponibili per l’estensione di OpenShift

Con Podman Desktop, è possibile facilitare la transizione di un’applicazione da un ambiente locale a un ambiente OpenShift remoto di produzione!

Se ti stai chiedendo come funziona per Docker Compose, sappi che esiste un’alternativa: Podman Compose!

Schedule di una AWS Lambda

Serena Sensini — Thu, 12 Oct 2023 00:00:00 +0000

Grazie al servizio Lambda di AWS, è possibile scrivere del codice tramite l’editor integrato della console di gestione AWS in diversi linguaggi e poter eseguire le tue funzioni in pochi attimi, il tutto in modalità serverless.

Per cosa può tornarci utile?

Per pianificare, ad esempio, lo spegnimento automatico di una serie di macchine EC2 durante il weekend, piuttosto che per recuperare i log di alcuni servizi critici per il proprio flusso di lavoro.

Per far sì che questa funzione venga eseguita in maniera automatica e programmata, è possibile avvalersi di un servizio che segua una regola per mettere in moto Lambda.

Partiamo da un esempio semplice, che poi può essere adattato a qualsiasi tipo di funzione Lambda, in qualsiasi linguaggio essa sia scritta.

Immaginiamo di avere la seguente Lambda scritta in Python. In questo caso, recupera dei dati qualsiasi dal sitohttps://random-data-api.com/ e li riporta sotto forma di JSON, tramite il modulo json e requests di Python e sfruttando la funziona lambda_handler all’interno della quale avviene la request:

import json
import requests

base_url = "https://random-data-api.com/"

def lambda_handler(event, context):
 res = requests.get(url=base_url+'api/v2/users?size=1&is_xml=true')
 return {
 'statusCode': res.status_code,
 'body': res.json
 }

Vogliamo che questa chiamata venga eseguita ogni giorno, a mezzanotte: per farlo, possiamo sfruttare un servizio chiamato EventBridge. Si tratta sempre di un servizio serverless che permette di creare delle applicazioni basate su eventi : questo vuol dire che utilizza una serie di eventi, come un cambio dello stato di un servizio o di una funzione per scatenare delle azioni su altri servizi o applicazioni, tramite delle regole o delle vere e proprie pipeline.

Nel nostro caso, è necessario utilizzare il servizio di creazione delle regole tramite la pianificazione: colleghiamoci al servizio Eventbridge, come prima cosa, e clicchiamo su “Crea Regola”.

Pagina principale del servizio

Si aprirà una pagina che riporta il wizard per la creazione della regola : scegliamo un nome parlante, inseriamo eventualmente una descrizione e poi procediamo verso la sezione chiamata “Modello di pianificazione”, dove potremo specificare lo schedule con cui eseguire la funzione Lambda:

Creazione della regola

Selezioniamo la voce “Pianificazione ricorrente”, così da poter definire sotto forma di cron qual è la ricorrenza con la quale questa funzione dev’essere invocata. Nell’esempio in figura, la pianificazione prevede che la funzione venga eseguita tutti i giorni (terzo asterico) a mezzanotte (primi due zeri) ogni mese di ogni anno. Come forma di verifica, viene infatti anche riportata la data e l’ora che corrispondono all’espressione inserita delle prossime occorrenze: vediamo se tutto torna, e procediamo.

Configurazione dei dettagli della pianificazione ricorrente

Piccola nota: la voce “Finestra temporale flessibile” permette di impostare un range temporale entro il quale eseguire la funzione. Questo vuol dire che la funzione potrebbe essere eseguita con un po’ di ritardo rispetto all’orario indicato, ma sempre all’interno di questo intervallo.

A questo punto, andiamo a selezionare quale servizio collegare alla pianificazione , ossia Lambda, tramite l’azione di invocazione:

Configurazione del servizio Lambda per l’esecuzione programmata

Fatto questo, verrà mostrata una finestra che permette di selezionare una tra le funzioni presenti nella _regioni_utilizzata e specificare un eventuale payload da associare a questa: nel caso di esempio, non era necessario, quindi selezioniamo la Lambda e procediamo.

Selezione della funzione Lambda

Nello step successivo, vengono specificate una serie di opzioni su come configurare questa pianificazione: se abilitarla immediatamente al momento della creazione, se cancellarla dopo il completamento, l’eventuale meccanismo di crittografia da utilizzare e le autorizzazioni: lasciamo che venga creato un ruolo in maniera automatica da AWS e clicchiamo su “Successivo”.

Configurazioni opzionali

Ultimo step: controlliamo il riepilogo di quanto fatto finora, e creiamo la pianificazione.

Riepilogo della pianificazione

Una volta finito, la pianificazione sarà riportata nell’ elenco delle pianificazioni a cui è possibile accedere dalla pagina principale del servizio EventBridge: questo riporterà anche qual è il servizio a cui è collegato, nonché tutti i dettagli sulla sua esecuzione.

A questo punto, come verificare che la funzione venga invocata correttamente e funzioni secondo pianificazione?

Utilizzando il servizio CloudWatch: selezionando questo servizio e scegliendo dal menù di sinistra la voce “ Logs ” e poi “ Gruppi di log ”, possiamo cercare tramite il nome della funzione Lambda i log a essa associati:

Pagina principale di CloudWatch

Ricerca dei log delle funzioni Lambda su CloudWatch

Se la pianificazione è appena stata creata e ha una data successiva a quella attuale, è possibile che non ci sia ancora nulla.

A questo punto, non ci resta che attendere la prossima esecuzione e incrociare le dita! 🤞

Risorse utili

AWS Cloud Computing Concepts and Tech Analogies: A guide to understand AWS services using easy-to-follow analogies from real life

Configurare OpenShift Local

Serena Sensini — Thu, 05 Oct 2023 00:00:00 +0000

Con le ultime versioni di OpenShift, il vecchio e caro Minishift ha cominciato a sparire, finché qualche tempo fa, Red Hat ha rilasciato OpenShift Local (prima CodeReady Containers), per consentire a chi sviluppa di testare una configurazione di OpenShift 4.x in un ambiente locale installando un cluster minimale.

Cos’è

Red Hat OpenShift Local è il modo più rapido per iniziare a lavorare su un cluster OpenShift. È progettato per essere eseguito su un computer locale per semplificare la configurazione e i test e per emulare l’ambiente di sviluppo cloud a livello locale con tutti gli strumenti necessari per sviluppare applicazioni basate su container come su un cluster di produzione.

Come funziona

OpenShift Local è essenzialmente un cluster OpenShift con un singolo nodo che viene eseguito localmente sul computer dello sviluppatore. Si basa sulla stessa tecnologia di OpenShift e fornisce un ambiente coerente per lo sviluppo e il test delle applicazioni.

Installazione

Naturalmente, ha dei requisiti minimi, sia dal punto di vista software che hardware. Vediamo quali:

Requisiti software

Richiede un hypervisor per eseguire la VM contenente OpenShift: – macOS: xhyve (predefinito), VirtualBox – GNU/Linux: KVM (predefinito), VirtualBox – Windows: Hyper-V (predefinito), VirtualBox
Un account su RedHat (è gratuito!) per accedere alla console ed essere in grado di ottenere il pull secret – Windows: per Microsoft, Red Hat OpenShift Local richiede l’aggiornamento Windows 10 Fall Creators Update (versione 1709) o successivo. Red Hat OpenShift Local non funziona su versioni precedenti di Microsoft Windows. Microsoft Windows 10 Home Edition non è supportato. – macOS: Red Hat OpenShift Local richiede macOS 11 Big Sur o successivo. Red Hat OpenShift Local non funziona su versioni precedenti di macOS. – Linux: Red Hat OpenShift Local è supportato solo sulle ultime due release minori di Red Hat Enterprise Linux/CentOS 7, 8 e 9 e sulle ultime due release stabili di Fedora. Quando si utilizza Red Hat Enterprise Linux, la macchina che esegue Red Hat OpenShift Local deve essere registrata nel Red Hat Customer Portal. Ubuntu 18.04 LTS o versioni successive e Debian 10 o versioni successive non sono supportate e potrebbero richiedere la configurazione manuale della macchina host.

Requisiti hardware

4 core fisici della CPU
9 GB di RAM
35 GB di spazio di archiviazione

Per procedere, accedere alla Red Hat Console, loggarsi e, facendo clic sulla voce “Services”, cercare la parola “OpenShift”.

Pagina principale della console Red Hat

Installazione di OpenShift locale

Ci verrà chiesto di scaricare un pacchetto in base al sistema operativo; facciamo clic su “Download OpenShift Local” senza chiudere però la pagina; tra poco dovremo recuperare il pull secret.

Download del file eseguibile

In base al sistema operativo, installiamo OpenShift Local tramite il file eseguibile seguendo tutti i passaggi descritti dalla procedura guidata e lasciando il percorso predefinito per l’installazione.

Verranno apportate molte modifiche al sistema, riguardanti la configurazione di rete, i servizi, l’ambiente e così via, per cui si consiglia di riavviare il sistema.

Esempio di schermata di installazione di OpenShift Local per Windows

Una volta riavviato il sistema, aprire RedHat OpenShift Local:

Configurazione iniziale di OpenShift Local

Fare clic su “Avanti” e passare alla seconda fase. Qui si può scegliere se proseguire la configurazione usando OpenShift o Podman; le due cose non si escludono a vicenda, ma si può scegliere di installare Podman successivamente o manualmente. Lasciare la selezione attuale su OpenShift e continuare.

Tornare alla Red Hat Console e copiare e incollare il pull secret facendo clic sul link mostrato nell’immagine sottostante:

Recupero del pull secret dalla console Red Hat

Proseguire e concludere il setup.

L’installazione potrebbe richiedere fino a 5-15 minuti. Se richiede più tempo, provare a chiudere e ricominciare.

Una volta completata l’installazione , sarà possibile avviare OpenShift Local e cominciare a utilizzarlo: per chi usa Windows, dovrebbe essere possibile trovare un’icona rossa nella barra degli strumenti in basso a destra: fare clic con il pulsante destro del mouse e verificare se il cluster è in esecuzione. Altrimenti, continuate a leggere.

Icona di OpenShift Local per Windows nella barra degli strumenti

Si noti che questo strumento sarà gestito attraverso questa finestra: qui è possibile arrestare il cluster, eliminarlo e ripartire da zero (opzione “Delete”), aprire la console web (opzione “Open console”), copiare e incollare il comando di accesso come amministratore (opzione “Copy…”) e così via.

CLI

Non è finita qui: OpenShift Local è dotato di uno strumento CLI chiamato crc : è possibile utilizzarlo per configurare il cluster, avviarlo, arrestarlo e così via.

Il suggerimento è, per la prima volta che si installa il cluster, di aprire un terminale in base al proprio sistema operativo ed eseguire i seguenti comandi: crc setup configura e verifica che tutto il necessario al cluster sia presente e funzionante.

$ crc setup
>>> Expected output:
INFO Using bundle path C:\Users\xxx\.crc\cache\crc_hyperv_4.10.18_amd64.crcbundle
INFO Checking if current user is in Hyper-V Admins group
INFO Checking if CRC bundle is extracted in '$HOME/.crc'
INFO Checking if C:\Users\xxx\.crc\cache\crc_hyperv_4.10.18_amd64.crcbundle exists
INFO Checking if the daemon task is installed
INFO Checking if the daemon task is running
INFO Running the daemon task
INFO Checking admin helper service is running
Your system is correctly setup for using CRC. Use 'crc start' to start the instance

Nel caso in cui qualcosa vada storto, possiamo provare ad aumentare il livello di log per eseguire un po’ più di informazioni:

$ crc setup --log-level debug
>>> Expected output:
DEBU CRC version: 2.5.1+5b02b826
DEBU OpenShift version: 4.10.18
DEBU Podman version: 4.1.0
DEBU Running 'crc setup'
INFO Using bundle path C:\Users\xxx\.crc\cache\crc_hyperv_4.10.18_amd64.crcbundle
INFO Checking if current user is in Hyper-V Admins group
DEBU Running '$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-578")
 @([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole($sid)'
INFO Checking if CRC bundle is extracted in '$HOME/.crc'
INFO Checking if C:\Users\xxx\.crc\cache\crc_hyperv_4.10.18_amd64.crcbundle exists
DEBU C:\Users\xxx\.crc\cache\crc_hyperv_4.10.18_amd64.crcbundle exists
DEBU Running 'Get-ScheduledTask -TaskName crcDaemon'
DEBU Running '(Get-ScheduledTask -TaskName "crcDaemon").Version'
INFO Checking if the daemon task is running
DEBU Running '(Get-ScheduledTask -TaskName "crcDaemon").State'
INFO Checking admin helper service is running
DEBU Running '(Get-Service crcAdminHelper).Status'
Your system is correctly setup for using CRC. Use 'crc start' to start the instance
DEBU Running '(Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name ReleaseId).ReleaseId'
DEBU Running '(Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").EditionID'
INFO Checking if running in a shell with administrator rights
INFO Checking Windows 10 release
INFO Checking Windows edition
INFO Checking if Hyper-V is installed and operational
INFO Checking if crc-users group exists
INFO Checking if current user is in Hyper-V Admins group
INFO Checking if vsock is correctly configured
INFO Checking if the daemon task is installed
INFO Checking if the daemon task is running
INFO Checking admin helper service is running
INFO Loading bundle: crc_hyperv_4.10.18_amd64...
INFO Creating CRC VM for OpenShift 4.10.18...
...

Una volta che il cluster sarà stato avviato (usando il comando crc start nella riga di comando o usando l’interfaccia utente), la console sarà disponibile all’indirizzo https://oauth-openshift.apps-crc.testing.

crc start
>>>
Starting...

Ci siamo quasi! Per ottenere le credenziali per accedere alla console, basta eseguire il seguente comando:

$ crc console --credentials
>>>
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p PASSWORD https://api.crc.testing:6443'

A questo punto, collegandosi all’indirizzo mostrato in precedenza, sarà possibile visualizzare la pagina principale della console OpenShift.

Ora che abbiamo un cluster OpenShift pronto all’uso… Come sfruttarlo al meglio?

Nei prossimi articoli, vedremo diversi esempi di utilizzo!

Voglio diventare... Full-Stack Recruiter

Serena Sensini — Tue, 03 Oct 2023 00:00:00 +0000

Descriviti in 100 parole

Ciao! 👋 Sono Guido e sono un Tech Recruiter @ Polaris Engineering. Lavoro nel settore già da qualche anno, adoro il networking e creare relazioni, mi piace vivere le community di dev, gli eventi e i meetup e da marzo 2023, spinto dall’esigenza di fare qualcosa di utile per l’ecosistema IT italiano ho aperto un canale Twitch (che nel frattempo è anche diventata una bella community su Telegram che al momento conta oltre 600 persone) che si chiama La Locanda del Tech , dove parliamo di lavoro, crescita professionale e molto altro!

In cosa consiste il ruolo di Full-Stack Recruiter?

Fun fact : il ruolo in sé non esiste! E’ un “job title” immaginario che abbiamo coniato per unire un termine “tipico” del mondo dello sviluppo alla figura del/della recruiter , anche in maniera un pò provocatoria volendo.

Fra chi sviluppa c’è sempre questa diatriba fra l’essere full stack o meno, abbiamo voluto quindi utilizzare questa “leva comunicativa”.

In generale, l’ obiettivo è quello di fornire ai/alle recruiter gli strumenti necessari per avere delle skill tecniche più approfondite e diminuire le distanze comunicative e tecniche fra “noi e voi”.

Qual è la soft skill più importante che deve possedere?

Personalmente è troppo difficile rispondere a questa domanda scegliendone una sola. Fare recruiting è un mestiere dannatamente complicato: il settore è iper-competitivo, l’ansia da fallimento è sempre dietro l’angolo, l’universo di tecnologie/framework/linguaggi e chi più ne ha più ne metta è sconfinato, quindi le soft skills da possedere a mio avviso devono essere tante: pazienza, empatia, saper costruire relazioni, non farsi trascinare nel vortice della “pesca a strascico” ma cercare , per quanto possibile, di fare questo lavoro in maniera etica , trasparente e responsabile

Quali sono le difficoltà che può incontrare la figura di un/a recruiter in ambito tech?

Ne ho parlato parzialmente nella domanda precedente: altissima competitività , domanda sbilanciata enormemente rispetto all’offerta, skill tecniche che devono essere presenti (un minimo quantomeno, per non cadere nel classico errore Java=Javascript), e mediamente una “diffidenza” dei dev nei nostri confronti, unita anche al fatto che 9/10 non cercano attivamente lavoro e quindi proporre una nuova opportunità lavorativa davvero interessante è complicato.

Come fare per diventare un/a Full-Stack Recruiter?

Che io sappia non esistono certificazioni nel recruiting (ancora), se non attestati di frequenza erogati da enti privati. Sicuramente è estremamente utile aver frequentato un master in HR per padroneggiare anche temi squisitamente burocratico/fiscali (ovvero sapere cos’è un CCNL, cosa vuol dire RAL, i livelli, superminimi e molto altro, per riuscire a gestire efficacemente una contrattazione economica).

Per il resto, avere un’ esperienza pregressa , anche minima, nel settore HR o Recruiting è indubbiamente un vantaggio. Infine, tocca studiare! Il settore, il mercato, le communities e altro. Il settore è molto tecnico, e tipicamente chi di lavoro è “tecnico” è in costante aggiornamento e formazione. Dobbiamo (anzi, dovremmo) farlo anche noi!

Per questa ragione, insieme a Simone Torrisi di TomorrowDevs abbiamo creato questo percorso per diventare recruiter in ambito tech: comprendere il CV di un/a developer, seguire tutte le ultime novità in merito alle tecnologie e framework, acquisire le terminologie e via dicendo è estremamente complesso. In questo corso , mettiamo a disposizione la conoscenza e l’esperienza di chi questo mestiere lo fa ogni giorno e che quindi può supportare il/la recruiter di domani a muoversi più agilmente in questo contesto, in modo da avere una conoscenza di base del mondo tech e dei relativi ruoli che andranno a intervistare e con cui collaboreranno.

Sito del corso

Il corso partirà il 23 ottobre e conta già 20 iscritti, per cui rimangono solo 5 posti.

Senza menzionare che ci sono anche due borse di studio per seguire il corso gratuitamente, che TomorrowDevs mette a disposizione per persone laureande/neolaureate in ambito HR o che hanno terminato un Master e vogliono entrare nel mondo del Tech Recruiting!

Parlando di successi e di questo percorso creato tramite la vostra sinergia, qual è il vostro prossimo obiettivo?

Onestamente non ci aspettavamo un riscontro così entusiasta, stiamo già pianificando la seconda edizione per inizio 2024. Per il resto, le idee sono sempre tantissime perché il settore ha tanto margine di innovazione e “freschezza”. Vedremo cosa ci riserverà il futuro!

Conosci il tema gender gap in ambito STEM? Se sì, come fare per superarlo?

Certo , conosco molto bene il tema e a mio avviso una delle cose fondamentali è parlarne. Organizzare eventi, condividere esperienze, fare rete e community su questi temi può davvero fare la differenza. Personalmente trovo che nel tech questo tema risulta forse poco sentito e bisogna parlarne maggiormente.

Nel mio piccolo , per quanto possibile sia nella community Telegram sia nelle live su Twitch cerco di fare “awareness” di questi temi e noto che, piano piano, qualcosa si muove (soprattutto nelle nuove generazioni, estremamente più attente a questi temi rispetto a noi, che apparteniamo a generazioni precedenti).

Contatti

Come avviare un'istanza SQL Server su macOS Apple Silicon

Serena Sensini — Thu, 28 Sep 2023 00:00:00 +0000

Microsoft SQL Server è uno dei sistemi di gestione dei database (RDBMS) più popolari al mondo ma tradizionalmente era stato limitato all’uso su piattaforme con sistema operativo Windows. Attualmente, Microsoft SQL Server non è ufficialmente supportato per essere eseguito su macOS Apple Silicon ma solo su piattaforme hardware basate su architettura x86_64 e sistemi operativi Windows e Linux.

Per maggiori informazioni sul supporto Linux, consiglio la lettura del documento Installation guidance for SQL Server on Linux e in particolare il paragrafo Supported platforms.

Qualora tu fossi un utente macOS (Apple Silicon) e avessi bisogno di utilizzare SQL Server per lo sviluppo o per altre attività, sarebbe possibile eseguire quest’ultimo utilizzando unamacchina virtuale (VM) o un ambiente di containerizzazione. L’obiettivo è facilmente raggiungibile grazie a Colima, e questo articolo ti guiderà attraverso i passaggi necessari per avviare SQL Server utilizzando Colima su macOS.

Cos’è Colima

Colima è un progetto Open Source che implementa un container runtime che richiede una configurazione minima e funziona su sistemi operativi macOS e Linux. Le caratteristiche principali di questo tool sono:

Intel and M1 Macs support
Simple CLI interface
Docker and Containerd support
Port Forwarding
Volume mounts
Kubernetes
Multiple instances

Colima è quindi un container runtime che esegue una VM Linux sul tuo Mac (in modo simile a come funziona Docker Desktop per Mac). Grazie al sistema di template (o anche da linea di comando), è possibile configurare la VM in modo tale che sia eseguita utilizzando l’hypervisor del framework di virtualizzazione nativo in macOS.

Installazione del software

Le prime operazioni da eseguire, riguardano l’installazione di tre principali componenti software:

Rosetta
Docker CLI
Colima

Rosetta è un software di emulazione sviluppato da Apple per i computer Mac con processori basati su architettura ARM, come il chip Apple M1. L’obiettivo principale di Rosetta è consentire l’esecuzione di applicazioni sviluppate per i processori Intel x86_64 su Mac con processori ARM64 senza richiedere alcuna modifica da parte degli sviluppatori delle applicazioni stesse. Questa tecnologia permette agli utenti di continuare a utilizzare le loro applicazioni esistenti su nuovi Mac con processori ARM.

Docker CLI è uno strumento potente e flessibile che consente agli sviluppatori e agli amministratori di sistema di automatizzare il processo di creazione, gestione e distribuzione di applicazioni in container Docker.

A seguire sono indicati i comandi necessari per l’installazione dei tre componenti. Per l’installazione di Docker e Colima è necessario che sul vostro Mac sia installato il package manager Homebrew.

Le versioni di riferimento di Docker e Colima, per questo articolo, sono rispettivamente: 24.0.6 e 0.5.5.

# Installazione di Rosetta, Docker e Colima
$ sudo softwareupdate --install-rosetta
$ brew install docker
$ brew install colima

# Verifica della versione di Docker
$ docker --version
Docker version 24.0.6, build ed223bc820

# Verifica della versione di Colima
$ colima version
colima version 0.5.5
git commit: 6251dc2c2c5d8197c356f0e402ad028945f0e830

runtime: docker
arch: aarch64
client: v24.0.6
server: v23.0.6

Output 1 - Installazione del software di base necessario per l’uso di Colima

Al fine di poter sfruttare il framework di virtualizzazione nativo di macOS in combinazione con Rosetta, è necessario che la versione di macOS sia almeno la 13.x.

Configurazione di Colima

Una volta che l’installazione del software è stata portata a termine con successo, possiamo procedere con la configurazione della macchina virtuale che deve essere creata al fine di fornire un kernel Linux per i container specifici x86_64 in esecuzione su macOS.

Per configurare la VM secondo le specifiche richieste per l’esecuzione di SQL Server, è possibile agire sulla configurazione della VM attraverso il meccanismo dei template (in formato yaml). Il template per il profilo di default è locato all’interno del folder $HOME/.colima/_templates/default.yaml, in ogni caso, usando il comando colima template --print riusciamo a ottenere il path assoluto del template di default.

I parametri da configurare sul template per la nostra specifica VM sono:

vmType : imposta il tipo di VM che in questo caso deve essere vz anziché quello predefinito, qemu. In questo modo potremo sfruttare il framework di virtualizzazione nativo di macOS (che richiede la versione 13 del sistema operativo);
rosetta : abilita Rosetta in modo che sia possibile attivare l’emulazione per architetture amd64, così come richiesto da SQL Server Server. Il valore da impostare è true (valido solo per Apple Silicon e vmType vz.) Il valore di default è false;
mountType : imposta il driver per il mount dei volumi. Nel caso di macOS la scelta ricade su virtiofs, dedicato alle VM vz su macOS. Il valore predefinito è sshfs;
cpu : imposta il numero di CPU da allocare per la VM. Il valore di default è 2 ma consiglio di impostare il valore a 4;
memory : imposta la dimensione (in GiB) da allocare per la VM. Il valore di default è 2GiB che è il requisito minimo per l’SQL Server 2022, il mio consiglio è di portare il valore a 4.

Per apportare le modifiche sopra indicate alla configurazione del template, è necessario eseguire il comando colima template. Il comando aprirà il file yaml del template per il profilo di default (se non diversamente specificato) utilizzando l’editor di default del vostro sistema o quello impostato tramite l’environment $EDITOR. Nel caso in cui l’editor sia vim, una volta eseguite le modifiche, usare il comando :x per salvare la configurazione e uscire dall’editor.

Su questo GitHub Gist è disponibile il file di configurazione del template completo.

Le configurazioni sopra impostate nel file del template, possono essere passate come parametri del comando colima start. La mia preferenza è avere questi parametri di configurazione persistenti in un file.

Starting up Colima

Da questo momento è possibile creare la macchina virtuale dal template configurato in precedenza eseguendo il comando colima start.

Il comando crea e avvia una VM così come configurata in precedenza. Inoltre, modifica il contesto del comando docker, pertanto, quando si utilizzeranno i comandi docker, questi saranno inviati al runtime appena creato.

L’output finale che dovreste ottenere eseguendo il comando colima start dovrebbe essere quello indicato a seguire.

INFO[0000] starting colima
INFO[0000] runtime: docker
INFO[0000] creating and starting ... context=vm
INFO[0021] provisioning ... context=docker
INFO[0021] starting ... context=docker
INFO[0026] done

Output 2 - Output finale a fronte dell’esecuzione del comando colima start

Eseguendo il comando colima status dovreste ottenere le informazioni circa il runtime appena avviato.

L’output dovrebbe essere uguale a quello indicato a seguire a meno delle coordinate del socket.

INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/<vostra-username>/.colima/default/docker.sock

Output 3 - Output del comando colima status

Eseguendo il comando docker context list è possibile verificare che il contesto di default sia quello di Colima (identificato attraverso il carattere *). A seguire l’output del comando.

NAME DESCRIPTION DOCKER ENDPOINT ERROR
colima * colima unix:///Users/<vostra-username>/.colima/default/docker.sock
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
desktop-linux Docker Desktop unix:///Users/<vostra-username>/.docker/run/docker.sock

Output 4 - Visualizzazione dei contesti Docker con evidenza di quello attivo (in questo caso colima)

Su asciinema è disponibile l’intero processo di starting up e verifica del runtime di Colima.

Asciicast 1 - Processo di starting up e verifica del runtime di Colima

Starting SQL Server Container

Adesso che il runtime di Colima è operativo, siamo nelle condizioni di poter creare ed eseguire il container di SQL Server a partire da una delle immagini pubblicate sull’account Docker Hub ufficiale di Microsoft. La pagina Docker Hub descrive nel dettaglio le modalità d’uso, i tag dell’immagini (quindi delle versioni di SQL Server) che sono disponibili su https://mcr.microsoft.com/v2/mssql/server/tags/list e il significato dei nomi dei tag.

Per avviare una configurazione minimale di SQL Server, è possibile eseguire il comando docker indicato seguire. Nello specifico, la versione di riferimento di SQL Server è la 2022 CU7 Ubuntu 20.04. Il comando docker run si occuperà di eseguire il pull dell’immagine se necessario.

$ docker run \
 --env 'ACCEPT_EULA=Y' \
 --env 'MSSQL_SA_PASSWORD=YourStrong@Passw0rd' \
 --name 'sqlserver-2022' \
 --hostname 'sqlserver-2022' \
 --publish 1433:1433 \
 --detach \
 --platform linux/amd64 mcr.microsoft.com/mssql/server:2022-CU7-ubuntu-20.04

Output 5 - Creazione e run del container SQL Server versione 2022

Per chi ha della curiosità sull’uso dei tag, esiste questo post sul perché il tag “latest” non vada utilizzato.

Riprendendo la configurazione, a seguire è mostrato l’output che dovreste ottenere a fronte dell’esecuzione del comando precedente. La prima riga informa che l’immagine non è presente sul sistema locale e di conseguenza provvede a reperire l’immagine dal registry. Una volta completato il pull dell’immagine mcr.microsoft.com/mssql/server:2022-CU7-ubuntu-20.04, il container sarà creato ed eseguito; l’ultima riga mostra l’identificativo assegnato al container, ovvero, il containerId (vedi riga 9 di Console 6).

Unable to find image 'mcr.microsoft.com/mssql/server:2022-CU7-ubuntu-20.04' locally
2022-CU7-ubuntu-20.04: Pulling from mssql/server
5b07ce5bcac1: Pull complete
b5f87f539427: Pull complete
8cf84f077c03: Pull complete
05a221025c3d: Pull complete
Digest: sha256:5362c818aad4a787e3bac20d19a2e8db7ac91cdc30b359c176bc986547b0c2d0
Status: Downloaded newer image for mcr.microsoft.com/mssql/server:2022-CU7-ubuntu-20.04
52a65e2200082558ac1accaf9ccc7d03679096a19f095b97809abfb1b7462a30

Output 6 - Output del comando docker run di creazione ed esecuzione del container SQL Server

Eseguendo il comando docker ps -l, dovreste vedere una serie d’informazioni circa l’ultimo container creato. A seguire un esempio dell’output.

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
52a65e220008 mcr.microsoft.com/mssql/server:2022-CU7-ubuntu-20.04 "/opt/mssql/bin/perm…" 2 hours ago Up 2 hours 0.0.0.0:1433->1433/tcp, :::1433->1433/tcp sqlserver-2022

Output 7 - Output del comando docker ps -l

Come ultima verifica, potremmo provare a controllare il banner della versione di SQL Server eseguendo l’istruzione SQL SELECT @@VERSION attraverso il comando docker exec, così come mostrato a seguire.

$ docker exec -it sqlserver-2022 /opt/mssql-tools/bin/sqlcmd -S localhost,1433 -U SA -P "YourStrong@Passw0rd" -Q 'SELECT @@VERSION'

# Output del comando
Microsoft SQL Server 2022 (RTM-CU7) (KB5028743) - 16.0.4065.3 (X64)
 Jul 25 2023 18:03:43
 Copyright (C) 2022 Microsoft Corporation
 Developer Edition (64-bit) on Linux (Ubuntu 20.04.6 LTS) <X64>

(1 rows affected)

Output 8 - Esecuzione dell’istruzione SQL per verificare la versione di SQL Server

Se non diversamente specificato tramite l’environment MSSQL_PID, l’edizione di default è la Developer Edition (vedi riga 7 del codice precedente).

Su asciinema è disponibile l’intero processo di creazione ed esecuzione del container di SQL Server e la successiva esecuzione del comando docker exec di verifica del banner di SQL Server.

Asciicast 2 - Processo di creazione ed esecuzione del container di SQL Server e successiva esecuzione del comando docker exec

Nota personale

Per lo sviluppo software utilizzo due tipi di macchine: una Workstation basata su AMD e Fedora Linux (da me assemblata) e il Mac Book Pro con macOS. Dal momento in cui ho eseguito il passaggio a Apple Silicon, sono stato costretto a trovare una soluzione che mi consentisse l’esecuzione di quei container esclusivamente compatibili con piattaforme x86. SQL Server è uno degli strumenti che uso regolarmente e compatibile solo con architetture x86 e lo stesso vale per esempio vale per Oracle Database.

Colima è stato la mia salvezza, soprattutto per il fatto che supporta K8s e la configurazione tramite template YAML. Ho buttato via Docker Desktop (anche per via del cambio delle politiche di licenza) e sostituito con Colima.

Per chi non conosce Docker nel dettaglio o desidera approfondire l’argomento, si consiglia il libro Docker - Sviluppare e rilasciare software tramite container di Serena Sensini (la versione eBook è scontata del 50% fino al primo ottobre).