Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 21 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

• Les nouvelles fonctionnalités de la distribution ;
• Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
• La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
• La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

• Gérer l'accroissement des ambassadeurs à travers le mentoring ;
• Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
• Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
• Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
• S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

• La communication entre les équipes, notamment entre la technique et le marketing ;
• Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
• Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
• Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce nouveau comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

Original post of Renault.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Pour la 48ème semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Retours sur /e/ dans un OnePlus 5T
• Comment être un développeur plus efficace
• Comment j’ai résilié ma Dedibox chez Online
• Une backdoor vient d'être trouvée dans un paquet npm connu
• Ce que peut faire votre Fournisseur d’Accès à l’Internet
• Bloquer des pays par règles de pare-feu iptables et le module xt_geoip
• Mercure : un nouveau protocole web pour mettre à jour les navigateurs en temps réel ("push")
• La hype statique ne fait que commencer
• Les services du Fédiverse fin 2018
• Il y a presque 6 ans, la NASA a migré tous les ordinateurs portables à bord de l'ISS vers Linux

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Ce ne sera pas un scoop car j’ai distillé l’information à travers mes derniers articles : j’ai transformé mon serveur de virtualisation en serveur de containers Docker depuis quelques mois. C’est l’occasion de faire un bilan en listant ce qui a bien fonctionné mais aussi ce qui a posé problème, et les avantages et inconvénients d’un serveur de containers. Au préalable, je n’utilise pas Docker dans un contexte professionnel mais pour héberger mes services personnels.

Docker n’est pas une lubie… je suis ses avancées depuis plus de trois ans. Il a eu sa période très instable où le choix de la distribution et surtout du kernel étaient primordiaux, puis celle où la sécurité était discutable. Mais aujourd’hui il est difficile de trouver des arguments pour ne pas au moins l’essayer. Docker est une vague de fond qui a déjà conquis les grandes entreprises et les développeurs. Ces derniers maintiennent de plus en plus souvent une version Docker de leurs logiciels en plus (mais jusqu’à quand ?) des paquets pour telle ou telle distribution. J’ai déjà abordé le sujet : pour moi Docker, c’est la fin de la distribution serveur à court terme comme flatpak et consorts annoncent la fin de la distribution bureau à moyen terme.

On entend souvent :

Docker n'a rien inventé, les containers existaient déjà !

Oui c’est vrai, on avait déjà chroot, LXC, OpenVz, les jails. D’ailleurs Docker s’est appuyé sur LXC dans ses premières versions. Mais ça, c’est la plomberie du sous-sol. C’est nécessaire et ça doit être performant mais ça ne résume pas Docker et ça n’explique pas son succès qui, pour moi, a 3 raisons principales :

1. l’abstraction (partielle) au système d’exploitation, ce qui donne accès à Docker à un autre public que des ingénieurs système
2. un langage de description Dockerfile / docker-compose.yml facile d’apprentissage
3. et, surtout, un écosystème communautaire : je parle bien sûr du marché au containers : le Hub

Si je fais un parallèle rapide avec le langage Java, Maven a beaucoup concouru à son succès en donnant accès à toutes les librairies tierces Open Source. Et bien c’est exactement ce que fait Docker avec le hub : récupérer une image pour l’enrichir et fabriquer la sienne.

On est en plein dans l’essence même de l’Open Source, le partage. Il faut toutefois prendre des précautions :

• priviligier une image officielle d’un logiciel
• ne pas se dispenser de lire son Dockerfile pour voir comment elle est construite et sur quelles couches elle s’appuie

En fait, ce sont les mêmes réflexes qu’avec l’intégration d’une librairie inconnue à son programme. Cela explique aussi l’engouement des développeurs pour Docker et on peut faire plein de parallèles avec le développement. J’ai passé du temps à pratiquer et j’ai pris de la compétence progressivement. Je pense avoir atteint le 2ème dan, selon ma vision de la courbe d’apprentissage de Docker :

• 1er dan : docker file : écriture, réutilisation, exposition / attachement de ports, utilisation des volumes, publication dans une registry
• 2ème dan : docker compose : composition de containers, communication intra-container, compréhension du cycle de vie des images et des containers
• 3ème dan : orchestration, supervision, sécurité avancée : Kubernetes, Docker Swarm, audits de sécurité

Ma prochaine étape est d’effleurer le 3ème dan avec Swarm. Faute de ressources matérielles suffisantes, je ne me formerai probablement pas à Kubernetes dans la sphère personnelle.

Pour progresser, j’ai déployé au plus vite pour me confronter en situation réelle. A l’époque, mon serveur fonctionnait avec des containers LXC dans Proxmox. Il a donc été aisé de migrer des bouts vers Docker sans faire la bascule d’un coup. De plus, j’avais le pare-feu de Proxmox et mes containers s’exécutaient dans une marchine virtuelle KVM ; cela m’a permis de me concentrer sur la création des images et des containers et retarder l’apprentissage de la sécurisation.

Une bonne partie des containers font tourner des projets persos écrits en Python. j’ai donc naturellement créé une image commune pour les applications Python. Par paresse et comme je ne suis pas dans un contexte professionnel, j’ai réutilisé la même image pour plusieurs containers / applications en connectant un volume avec les sources Python dessus. Dans un contexte professionnel, j’aurais créé une image versionnée pour chaque application embarquant les sources. J’ai publié mes quelques images sur le Hub et les sources sont sur mon GitHub

J’ai basé mon démarrage sur un simple fichier docker-compose qui décrit tous mes containers et une commande docker-compose up pour tout démarrer. Quand je me suis senti à l’aise et capable de sécuriser correctement Docker, j’ai réinstallé le serveur de zéro avec une Debian et Docker pour en faire un serveur de containers bare metal.

Pour la supervision, je suis resté simple en installant Portainer pour redémarrer les containers, voir les logs… et Glances pour avoir une vision détaillés de l’usage des ressources. Les 2 outils sont s’exécutent eux-même dans des containers.

Voilà j’en suis à 18 containers déployés avec 30% des 4 Go de RAM du serveur utilisé. Les performances sont très proches d’une installation monolithique. Docker demande un peu plus de RAM car même si les images sont légères on duplique des OS légers. En tout cas, on est très au dessus des performances de la virtualisation.

Le plus gros bénéfice de ma migration est un environnement de test identique, le truc que je n’ai jamais pu avoir auparavant. Pour cela, j’ai souscrit un nom de domaine .space à 0,99 centimes (merci les promos) et j’ai décliné la configuration de mon environnement sur ce domaine. Résultat, j’ai un environnement complet qui tourne sur mon PC de développement : très appréciable quand la moitié des containers exécutent du code écrit par soi-même et quand on veut tester des nouveaux containers avant de les mettre en production. Autre avantage, la sauvegarde en un tour de main : une arborescence de données, quelques volumes Docker.

Ce qui a moins bien marché, c’est le 1er démarrage de mes containers Python dépendants les uns des autres et habitués à avoir les services dépendants opérationnels. Dans Compose, on ne définit pas plus d’ordre de démarrage. le cycle de vie des containers est aussi plus volatile : une modification de docker-compose recrée juste les containers impactés. On a donc plus souvent des containers détruits / recréés. C’est donc une bonne approche d’avoir du code orienté micro-services, capable de :

• gérer la non disponibilité d’un service en fournissant un service dégradé
• stocker localement les données reçues pour les traiter quand l’ensemble du système redevient opérationnel

J’ai donc revu le code de certains de mes projets pour leur ajouter une base de donnée locale SQLite et gérer le dynamisme de l’environnement. C’est positif et pas forcé par Docker ; son fonctionnement rend juste cette approche pertinente et on obtient du code plus résilient. Je suis très satisfait de cette migration et pas prêt de revenir en arrière.

Est-ce que Docker est indétrônable ? Est-ce qu’il y aura une alternative libre ?

Une partie de Docker est sous licence Open Source et on a des alternatives pour l’exécution de containers (comme rkt de CoreOS). L’arrivée un peu tardive de Swarm et les lacunes de ses premières versions ont permis à Kubernetes de remporter une grosse partie du marché de l’orchestration. Mais Docker a construit une communauté ces cinq dernières années et démocratisé la publication de containers au format Dockerfile, difficile d’imaginer qu’il puisse disparaitre comme ça. En tout cas, je pense que la mode de la containerisation a gagné le marché durablement.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Il y a quelques jours, je cherchais comment tracer rapidement et simplement les entrées sorties d’une API REST en appliquant quelques formatages, des filtres, et des insertions en base si besoin.

Travaillant sur une stack SpringBoot, vous allez me dire : oui tu peux faire des filtres. Pour être franc, j’ai essayé d’ appliquer des interceptor et filtres mais dans mon contexte, ça ne collait pas.

Me voilà donc à la recherche d’une solution faisant le taff et qui soit peu intrusive dans mon contexte.

J’ai trouvé par hasard au fil de mes lectures sur Stackoverflow le framework logbook réalisé par … Zalando ( et oui, ils ne font pas que des chaussures) en licence MIT. 
Ce composant ne fait qu’une seule chose, mais il le fait bien !

Il permet entre autres de s’intégrer dans une stack JAVA ( JAX-RS ou SpringMVC), de filtrer, récupérer les différentes informations des requêtes et réponses et enfin de formatter selon l’envie (ex. JSON).

Voici un exemple de mise en œuvre dans un projet SpringBoot:

Dans le  fichier pom.xml, ajouter cette dépendance:

    org.zalando
    logbook-spring-boot-starter
    1.11.2

Dans une de vos classes Configuration, définir la factory de Logbook

@Bean
public Logbook createLogBook() {
    // too easy : return Logbook.create();
    return Logbook.builder()
            .condition(Conditions.requestTo("/helloworld"))
            .formatter(new JsonHttpLogFormatter())
            .build();
}

Dans mon cas j’ai fait un filtre en n’incluant que l’ API /helloworld et j’ai formatté en JSON.
On peut également modifier le processus d’écriture pour ne pas écrire dans un fichier mais en base par ex.

Ensuite, j’ai ajouté la configuration du logger dans le fichier application.properties

logging.level.org.zalando.logbook:TRACE

Et voila !

Dans la console, lors d’un appel ou d’une réponse à mon API, j’ai le message suivant :

018-12-01 15:14:18.373 TRACE 3605 --- [nio-8080-exec-1] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"c6b345013835273f","protocol":"HTTP/1.1","remote":"127.0.0.1","method":"GET","uri":"http://127.0.0.1:8080/helloworld","headers":{"accept":["/"],"host":["127.0.0.1:8080"],"user-agent":["curl/7.52.1"]}}

2018-12-01 15:14:18.418 TRACE 3605 --- [nio-8080-exec-1] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"c6b345013835273f","duration":48,"protocol":"HTTP/1.1","status":200,"headers":{"Content-Length":["11"],"Content-Type":["text/plain;charset=UTF-8"],"Date":["Sat, 01 Dec 2018 14:14:18 GMT"]},"body":"Hello world"}

Vous remarquerez que les requêtes / réponses peuvent désormais être associés grâce à un identifiant de corrélation. On peut facilement déterminer le temps de traitement d’une requête ou encore faciliter les recherches.

Vous trouverez tout le code dans ce repo github.

Original post of Littlewing.Votez pour ce billet sur Planet Libre.