Un po' di numeri

IDI Incontro DevOps Italia 2024 è la 12° edizione della conferenza italiana dedicata alle tematiche DevOps. La conferenza si è svolta Venerdì 15 Marzo 2024 in modalità ibrida: in presenza a Bologna, e online con 17 speakers, circa 200 partecipanti in presenza e un centinaio di partecipanti da remoto.

Workshops

Il giorno prima, Giovedì 14 Marzo, nella stessa location a Bologna, si è svolto un workshop dedicato a Kubernetes. Inoltre, Giovedì 14 Marzo nella stessa venue, si è svolta anche la prima edizione di dxday, una conferenza GrUSP dedicata alla Developer Experience.

Presentazioni

I contenuti sono tanti, 17 persone suddivise in 2 track si sono succedute nel corso della giornata (programma). Ricordo alcune presentazioni in particolare, tra cui il keynote di Jacopo Nardiello "Pillars of k8s security" che offre una prospettiva che va al di là del contenuto tecnico. Siamo nel 2024 e, purtroppo, diverse tensioni globali rendono sempre più importanti queste tematiche. La Cloud Native Security è qualcosa di cui tenere conto se non lo facevate già.

"Crossplane", la presentazione di Steven Borrelli(qui le slides) è DENSA di contenuti. Crossplane è un progetto opensource CNCF ma sviluppato da UpBound. È un progetto basato sulle API di Kubernetes per cui il cluster kubernetes su qualsiasi piattaforma (aws, gcp...) diventa un oggetto "kubectl" e Crossplane si occupa di dialogare con il cloud provider. Lo proverò sicuramente.

Punti salienti

• Siamo nel 2024, i concetti di security devono essere un pilastro fondamentale nel ciclo di sviluppo del software, a tutti i livelli (sviluppo, delivery, deploy, runtime).
• Kubernetes is (still) everywhere!

A presto

Ci vediamo al ContainerDay o al DevSecOpsDay A presto!

Save yourself from the Python dependency conflict

Anyone that has worked with Python for more than a few days knows the struggle of keeping packages isolated. Multiple Python projects, that need to co-exist on the same computer, can have different and often conflicting requirements.

Here I want to discuss a Python tool that helps you to keep Python packages isolated: Virtualenv.

Virtualenv allows you:

• to create a “virtual” isolated Python installation and
• to install packages into that virtual installation.

Virtualenv

What is virtualenv and why you should use it

What: Virtualenv is a Python package that creates a folder where Python programs can run. Period.

Why: because you want to play with different versions of libraries and you don't want to mess with other projects and, most importantly, the System libraries. Horribly dangerous things happen when you try to tame the complicated, ever-growing, dependency tree of Python in a Linux machine.

How to install virtualenv

Using the Python package manager (pip)

root@65ded660d870:~# python3 -m pip install virtualenv

Or using the system package manager (e.g. apt):

root@65ded660d870:~# apt install virtualenv

Create a virtualenv

I will use the virtualenv pip package.

root@65ded660d870:~# python3 -m venv env

This command creates a virtual environment in the env folder. A virtualenv, as you can see, is just a bunch of directories needed for running Python programs (with a copy of python included)

root@65ded660d870:~# ls -a env/
./  ../  bin/  include/  lib/  lib64@  local/  pyvenv.cfg  share/

Work in a virtualenv

You have to activate the virtualenv in order to work in it.

 root@65ded660d870:~# . env/bin/activate
 (env) root@65ded660d870:~# pip install ansible

Nice, the activation puts a friendly reminder in my prompt.

But... What is happening under the hood?

A bash session works by searching the executables in the $PATH environment variable, which is affected by the activation of the virtualenv. Activating the env means giving the env/bin folder the highest priority.

 (env) root@65ded660d870:~# echo $PATH
 /root/env/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Let's wrap our head around it:

root@16abbefbfa05:~# echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@16abbefbfa05:~# which python
/usr/local/bin/python
root@16abbefbfa05:~# . env/bin/activate
(env) root@16abbefbfa05:~# echo $PATH
/root/env/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
(env) root@16abbefbfa05:~# which python
/root/env/bin/python

Virtualenv and pip

Virtualenv is the tool that creates the isolated environment. pip is a tool for installing Python packages from the Python Package Index. You'll find pip automatically installed in the virtual environment. You have to use pip to manage packages in a virtualenv.

Keep the versions under control

Now, can we keep the virtual environment under control? In order to make reproducible software we have to care about making reproducible environments. You can use the pip freeze command to write down the versions of the packages installed:

(env) root@16abbefbfa05:~# pip install ansible
(env) $ pip freeze
ansible==2.8.0
cffi==1.13.2
cryptography==2.8
enum34==1.1.6
ipaddress==1.0.23
Jinja2==2.10.3
MarkupSafe==1.1.1
pkg-resources==0.0.0
pycparser==2.19
PyYAML==5.2
six==1.13.0

Then you can redirect the output to a file and put it under some version control system, e.g. git:

(env) root@65ded660d870:~# mkdir my-app && cd my-app
(env) root@65ded660d870:~# git init
(env) root@65ded660d870:~# pip freeze > requirements.txt
(env) root@16abbefbfa05:~/my-app# git add requirements.txt && git commit -m 'The requirements'

Keep the versions updated

A thing that I find very neat is to add a git-hook to remind myself of updating the requirements file.

(env) root@16abbefbfa05:~/my-app# cat .git/hooks/pre-commit
#!/bin/bash
diff requirements.txt <(pip freeze)
if [ $? != 0 ]
then
  echo "Env changes not updated in requirements.txt. Run 'pip freeze > requirements.txt' to update."
  exit 1
fi

If the output of pip freeze and the requirements file are different, the action of git commit will be prevented by this message.

Can I roll back to a previous state?

No. Virtualenv is not aware of its story, so in order to roll back to a previous state you are bound to using a version control tool.

Can you uninstall packages?

Yes, you just run pip remove package command in the virtualenv.

Nel 2018 abbiamo collaborato con l'Università di Padova e quella di Bologna per dare supporto bioinformatico e computazionale al progetto Fido-SNP. La notizia dei risultati del lavoro svolto (presenti qui, nel lavoro congiunto pubblicato) è stato ripreso anche dal quotidiano Padova Oggi e la cosa ci fa molto piacere. Citiamo dall'articolo quanto spiegato dalla dottoressa Ludovica Montanucci, che riassume i risultati del lavoro svolto:

«La nostra idea è stata quella di integrare, attraverso un algoritmo di machine learning (la così detta intelligenza artificiale), la dettagliata conoscenza delle mutazioni associate a malattie nell’uomo con le informazioni disponibili nel cane. Trattandosi di due specie diverse, per fare ciò è stato necessario sfruttare l’informazione evolutiva ottenuta dal confronto dei genomi di un totale di 100 specie di mammiferi. Grazie a questo approccio innovativo e integrato, Fido-SNP è in grado di predire l’effetto (benigno o dannoso) delle mutazioni nel cane. Fido-SNPraggiunge una accuratezza di predizione molto elevata, paragonabile a quella che otteniamo per le mutazioni del genoma umano, nonostante le evidenze sperimentali sulla genomica del cane siano molto ridotte. Fido-SNP è quindi un potente strumento computazionale a servizio della medicina veterinaria del cane».

The 7th edition of The Italian DevOps Conference IDI2019 is over. During Friday, March 8th, in the beatiful Bologna 370+ people gathered together to attend the main Italian event on DevOps, automation tools, testing and much more.

One theme dominated the conference: Microservices and how can we adopt it (but also, should we?).

Let the numbers talk

• There were 370+ people
• 320 tickets (Sold Out! Again!)
• 33 speakers
• 4 tracks
• 28 talks

Well, let me say that this conference delivers multiple insights at a quick pace.

There were about 50% of talks given in Italian, but, following the huge success of the previous editions, we continue to feature keynotes and talks in English to extend our audience and to create a bridge between the Italian and the international DevOps communities.

Workshops

The Italian DevOps Conference is a 2 days event. The day before the conference (7th of March 2019) is the Workshops day. This year 4 workshops were presented, on Docker, Kubernetes, AWS and Ansible. Going from 0 to designing a containerized infrastructure using automatic configuration tools has never been easier.

Topics and talks

Topics included DevOps, Continuous Delivery, Cloud, Microservices, Automation, Testing, Big Data, Containers, Data Center Operating Systems, Software Operability, IT operating models and how to plan and organize IT Operations.

There were many interesting talks but I remember vividly the keynote presentation by Giuseppe Lavagetto who gave its perspective on the adoption of Microservices at the Wikimedia Foundation. He condensed the lessons learned at Wikimedia during the transition from a monolithic architecture to a microservice-oriented infrastrucure. I also appreciated the presentation given by Andrea Tosatto who spoke about "Scaling Ansible". He showed how he reduced the execution time of a playbook from 60 minutes to 6 minutes by applying some small, but powerful, hacks.

My 6 key takeaways from #IDI2019

1. DevOps is more a cultural shift than a set of ever-evolving technologies.
2. Microservices, containers, etc.. can help you or trap you. A (not so) minimal knowledge of how things work under the hood is always required.
3. Infrastructure-as-Code tools (e.g. Ansible, Terraform) can be very beneficial to your company, whether you are migrating to microservices or not.
4. Kubernetes is everywhere.
5. Serverless applications still need to be monitored (just like any other thing on this planet).
6. Conferences like this are a great place to ramp up your knowledge and get inspired, whether you are an experienced DevOps superhero or new to the topic.

We look forward to see you next year!

#IDI2020 will take place, as usual, in Bologna at the beginning of March. Tickets are already available!

Cos'è Ansible?

Uno strumento semplice, scritto in un linguaggio che si avvicina al plain english, che permette di installare sistemi e servizi in modo standard e riproducibile. Si basa solo sul protocollo SSH e non occorre aggiungere altri componenti sui nodi target (a parte Python).

Panoramica del corso

Un corso hands on per imparare ad orchestrare Ansible al fine di creare delle pratiche automatiche nella gestione dei vostri server e servizi.

Verranno toccati i seguenti punti:

• installazione e troubleshooting di Ansible.
• La command line e i moduli di Ansible.
• Playbooks: le ricette di Ansible.
• Utilizzo di Ansible in un ambiente di virtualizzazione Vagrant.
• Ansible Galaxy e la creazione di codice Ansible aderente alle best practices.
• Come testare il codice Ansible.

Come?

È desiderabile lavorare in un ambiente omogeneo per cui si richiede ai partecipanti di installare Vagrant sul proprio pc e attivare una macchina virtuale basata su Debian seguendo istruzioni fornite da noi qualche tempo prima del corso.

A chi è rivolto: a sistemisti, programmatori e ... DevOps!

In generale a tutti coloro che desiderano utilizzare uno strumento moderno per automatizzare, documentare e standardizzare attività di gestione di programmi e sistemi.

Dove e quando?

Iscrivetevi sulla pagina dei Workshop del Container Day; il corso si terrà il 25 ottobre 2018 a Verona nel contesto del Container Day che si terrà il giorno successivo.

On Thursday 2018-03-08, the day before IDI2018 , the first edition of Glustered took place.

Twenty people showed up. Around half of them were new to Gluster and evaluating its adoption, while the other half comprised people with previous Gluster experience, from the novice up to the software-defined storage professional from Red Hat Italy.

In the morning there have been three tech talks. Niels presentation started from an introduction to Gluster, going through some of the latest features of the just-released Gluster 4.0, and finished illustrating what to expect from the 4.x road map. Marko did a live demo of gluster-colonizer , a brand new Ansible-based project to automatically provision Gluster clusters. Jiffin talked about what the duties of a release maintainer are, and did a live release of Gluster 3.12.

In the afternoon I did my part by illustrating most of the use cases I addressed as a consultant, while Ramon Selga from Datalab gave the audience a lot of information about disperse volumes and how to host virtual machines within Gluster volumes. Both sessions included lively discussion and questions from the audience. I liked it.

Being a first, I think the event has been a success.

Will there be another one? Possibly, if the community will keep showing interest. Although it would be nice to have a larger fraction of the attendance coming from outside Italy.

Ansible roles and private git repos

Ansible is a python tool that automates the management of an IT infrastructure. It is easy to learn but rushing to use it with a limited knowledge of its best practices (roles) leads to not reusable code. To quote the documentation about roles: “You absolutely should be using roles. Roles are great. Use roles. Roles! Did we say that enough? Roles are great.”.

So, writing reusable ansible roles is not easy but it's a task worth doing. This post will walk you through the construction of an ansible role scaffold supported by private git repos.

Install Ansible and git

Be sure to have git and Ansible installed. You should at least be working with ansible==2.3.0. Install Ansible in a virtualenv using pip to keep this environment clean.

$ pip install virtualenv
$ virtualenv myproject
$ . myproject/bin/activate
$ (myproject) pip install Ansible==2.3.0

Create an Ansible role

The first step

The first step in creating a role is creating its directory structure. Use the init command of ansible-galaxy, which comes bundled with Ansible, to initialize the base structure of a new role, saving time (and increase reproducibility) on creating the various directories.

What if you don't use Github?

Keep in mind that Ansible relies on Github, therefore the test files created by ansible-galaxy init command are meant to run CI (Continuous Integration) tests on Travis. But we work with GitLab! Our CI files are called .gitlab-ci.yml files and have a different syntax compared to Travis files. So, how can one leverage the ansible-galaxy command when he/she is not testing on Travis?

Write your own role scaffold

Starting from ansible==2.3.0 the ansible-galaxy command supports creating roles using a different role skeleton:

ansible-galaxy init --role-skeleton biodec.template/ -p . biodec.role_name

biodec.template is git project that we have developed during this year. It is an Ansible role scaffold to work and test things on GitLab. The main difference with respect to the default scaffold is the test file: .gitlab-ci.yml:

stretch:
    image: buildpack-deps:stretch
    script:
       - apt-get update -y && apt-get install -y python python-dev python-pip
       - pip install -r requirements.txt
       - echo localhost > inventory
       - ansible-playbook -i inventory test.yml --connection=local -v

Advantages of our scaffold

We found convenient to use our own scaffold for a series of reasons besides testing on GitLab rather than on Travis:

• write your own README (and licence);
• write a custom dependency file that will gather roles from various sources (including another private git repository);
• write a requirements file for pip that will keep Ansible's version fixed (a missing feature in ansible-galaxy which encourages you to work always with the latest version).

Summary

When developing Ansible code:

• write/use roles!
• write roles using standard tools like ansible-galaxy init
• you can tweak the role skeleton if you want to and still adhere to Ansible's best practices
• you can build your private Ansible Galaxy privately, on a self-hosted GitLab platform

A talk on this subject

We presented a talk at PyCon 8 this year talking about this subject. Feel free to download the slides if you like it.

Dear Gluster developers,

Last few days has been tense since a R3 3.8.5 Gluster cluster that I built has been plagued by problems.

The first symptom has been a continuous stream in the client logs of messages like:

[2016-12-17 15:55:02.047508] E [MSGID: 108009] [afr-open.c:187:afr_openfd_fix_open_cbk] 0-prod-1-replicate-0: Failed to open /galaxy/java/lib/java/jre1.7.0_51/jre/lib/rt.jar on subvolume prod-1-client-2 [Transport endpoint is not connected]

together with very frequent peer disconnections/reconnections and a continuous stream of files to be healed on several volumes.

The problem has finally been traced back to a flaky X540-T2 10GBE NIC embedded in one of the peers motherboard. The thing was incapable of keeping the correct 10Gbit speed negotiation with the switch.

The motherboard has been replaced on the peer and, after that, the volumes healed quickly to complete health. In the meantime, the users kept running some heavy-duty bioinformatics applications (NGS data analysis) on top of Gluster. No user noticed anything, despite a major hardware problem and the off-lining of a peer.

This is a RESILIENT system, in my book.

Despite the constant stream of problem reports and requests for help that you see on both the ML and IRC, rest assured that you are building a nice piece of software, at least according to my experience.

Keep-up the good work and Merry Christmas.

Ivan Rossi

PS I have the strong feeling that people running Gluster in a cloud environment will have experiences like this one more time that they would like. But it is not Gluster fault, IMHO.

5 modi per migliorare la produttività aziendale

Il mondo dell' IT è in continua trasformazione e i cambiamenti diventano sempre più veloci ed imprevedibili. Assistiamo alla proliferazione di piccole realtà (startup) che, grazie all’utilizzo di metodi di lavoro innovativi, riescono a tenere testa a grosse aziende che spesso sono refrattarie al cambiamento.

Gli approcci vincenti sono in gran parte ispirati alle metodologie agili (qui il manifesto originale) e vedono affermarsi la figura del Devops.

Noi di Biodec abbiamo adottato un mix di pratiche agili ed organizziamo, da 5 anni, il principale evento devops in Italia.

Oggi vogliamo parlare di qualche spunto per trasformare la vostra azienda in una realtà agile e resiliente:

#1 Agevolare il cambiamento

Siamo nell’era della “digital transformation”:

• usiamo molto meno hardware e molti più sistemi virtuali (cloud, containers)
• amministriamo l’infrastruttura con strumenti software di alto livello (che evolvono rapidamente)

Favoriamo il cambiamento imparando a gestire questi strumenti.

Strumenti che usiamo: AWS, Ganeti, Gluster e Docker

#2 Aumentare le competenze

Esistono prodotti per facilitare la transizione verso una mentalità agile e devops. Biodec ha adottato, da qualche anno, ansible: un sistema per orchestrare l'installazione e la configurazione di sistemi ed applicazioni. Offriamo la nostra esperienza per affiancare l’adozione di ansible in azienda con un corso o realizzando soluzioni direttamente.

Strumenti che usiamo: ansible

#3 Scegliere gli strumenti di lavoro

Essere un’azienda agile e resiliente significa rispondere ai cambiamenti improvvisi (del team o delle richieste del cliente) senza andare off-line. Alcuni strumenti fondamentali per questo sono:

• il version control system perchè il codice evolve (anche se lavoriamo da soli) e il team anche
• strumenti di test e Continuous Integration
• ambienti di test
• strumenti di monitoraggio

Strumenti che usiamo: Git, Gitlab, Gitlab-CI, Docker, OMD

#4 Instaurare un feedback continuo

Fissiamo riunioni (almeno settimanali) in cui il team si ritrova e parla dell’andamento delle attività. Usiamo un “issue tracker” come Redmine per schedulare le attività e avere un feedback continuo col cliente includendolo come membro del team.

Strumenti che usiamo: Redmine, Scrum

#5 Praticare la consistenza

Aderiamo al metodo di lavoro adottato.

Un workshop introduttivo su Docker

Kiratech e il Docker User Group di Roma hanno organizzato presso il Talent-Garden un workshop (gratuito e organizzato molto bene!) su Docker. Il Workshop, di carattere introduttivo, ha offerto una panoramica dettagliata sull'ecosistema Docker toccando i punti principali

• Cos’è Docker
• I comandi base per interagire con i container
• Docker orchestration
• CI/CD con docker

Noi abbiamo partecipato in quanto utilizzatori di docker e partner, insieme a Kiratech e xpeppers, di 4devops.

A seguito del workshop si è poi svolto il Docker-meetup, una serie di presentazioni più interessanti per chi vuole stare dalla parte dello sviluppo dei container.

A concludere.. pizza e birra & Networking!

Complimenti a Kiratech per la bella iniziativa!