Syndiquer le contenu
Mis à jour : il y a 20 heures 23 min

Présentation technique de Canopsis

7 février, 2016 - 10:41

Supervision et visualisation des données : des domaines de l'informatique qui nous permettent de surveiller, analyser une infra, des données afin de comprendre et éventuellement prédire des dysfonctionnements.

De nombreux outils existent et excellent dans chacune de ces tâches. Les accorder ensemble afin d'unifier l'information permet ainsi de faciliter la prise de décision.

C'est ce que l'on appelle l'hypervision.

Canopsis se veut une solution d'hypervision (on évite l'appellation hyperviseur qui reste dans le langage courant spécifique à la virtualisation). Solution open-source sous licence AGPL3 développée par la société française Capensis, elle se veut simple d'utilisation, et suffisamment souple pour répondre à un maximum de besoin.

Sommaire La problématique

Dans une infra hétérogène, on dispose de nombreuses sources d'information :

  • côté supervision, on peut avoir un mélange de :
    • Nagios/Icinga
    • Centreon
    • Shinken
    • HPOV
    • Zabbix
    • SNMP
  • côté récolte de données, on peut avoir :
    • CollectD
    • Logstash
    • Munin
    • Telegraf (de la pile TICK)
  • ou encore :
    • des logs
    • des données stockées en base de données
    • un résultat de tests unitaires et fonctionnels (jMeter, Sikuli…)

La mise en place d'un accès à l'ensemble de ces informations peut être fastidieuse, et dans la plupart des cas, l'utilisateur (l'administrateur technique et/ou fonctionnel) devra accéder à plusieurs interfaces et maîtriser plusieurs outils.

Cela empêche d'avoir une vue d'ensemble cohérente et rend difficile l'anticipation ainsi que la prise de décision.

Objectif : la solution

C'est là que Canopsis intervient.

Étape 1 : les connecteurs

Dans un premier temps, nous devons récupérer les informations produites par cet ensemble hétérogène.

Ainsi, pour chaque source de données, nous sommes en mesure de développer un connecteur, capable d'extraire les informations voulues, et de les transmettre à Canopsis sous la forme d'événements standardisés.

Un certain nombre de connecteurs sont déjà disponibles sur le Gitlab.

Le cas le plus simple est donc celui ci :

#!/usr/bin/env python from time import time # lib qui nous permet de nous connecter au bus de données (cf étape 2) from kombu import Connection # module qui sera utilisé pour envoyer les événements from kombu.pools import producers # construction de l'événement selon le standard Canopsis event = { "timestamp": int(time()), # émetteur de l'événement "connector": "myconnector", "connector_name": "myconnector-instance0", # nature de l'événement "event_type": "check", # source de l'événement "source_type": "resource", "component": "<hostname>", "resource": "<job's name>", # données portées par l'événement "state": 0, # 0 = INFO, 1 = MINOR, 2 = MAJOR, 3 = CRITICAL "output": "<message>" } # construction de la routing_key, qui sert à identifier l'événement et à le router routing_key = "{0}.{1}.{2}.{3}.{4}".format( event['connector'], event['connector_name'], event['event_type'], event['source_type'], event['component'] ) if event['source_type'] == "resource": routing_key = "{0}.{1}".format( routing_key, event['resource'] ) # Connexion uri = 'amqp://cpsrabbit:canopsis@localhost:5672/canopsis' with Connection(uri) as conn: # Création de l'émetteur with producers[conn].acquire(block=True) as producer: # Publication producer.publish( event, serializer='json', exchange='canopsis.events', routing_key=routing_key )

Bien évidemment, du moment qu'un connecteur envoie ses événements, il peut être développé dans n'importe quel langage, c'est le cas du connecteur Nagios qui se présente comme un Nagios Event Broker, et est donc développé en C.

Étape 2 : le bus de données et les moteurs

Les événements produits par les connecteurs sont transmis au bus de données de Canopsis, basé sur RabbitMQ.

Source : http://igm.univ-mlv.fr/~dr/XPOSE2011/rabbitmq/usages.html

Ces événements vont être consommés par des daemons que nous appelons moteurs.

Leur but est simple :

  • traiter la donnée
  • enregistrer les informations pertinentes en base de données
  • transmettre, si nécessaire, l'événement à un ou plusieurs autres moteurs

Nous avons, par exemple :

  • le moteur event_filter qui se charge de filtrer/modifier les événements entrants
  • le moteur context qui se charge d'enregistrer les informations sur l'entité cible de l'événement (connecteur source, composant/ressource qui a produit l'événement…)
  • le moteur perfdata qui s'occupe d'historiser les données de performance (comme remontées par Nagios ou CollectD)

Comme pour les connecteurs, les moteurs peuvent être développés dans n'importe quel langage, bien que pour le moment nous les avons tous faits en Python.

Étant un daemon, un moteur dispose de 2 fonctions :

  • une pour consommer les événements (dans un thread à part)
  • une pour exécuter une tâche régulièrement (recharger la configuration, envoyer des stats…)

Ainsi que la configuration suivante :

[engine:myengine] # chemin Python de la méthode de consommation event_processing=canopsis.myfeature.process.event_processing # chemin Python de la méthode exécutée régulièrement beat_processing=canopsis.myfeature.process.beat_processing # nom de l'exchange AMQP sur lequel écouter (par défaut: amq.direct) exchange_name=canopsis.event # RK à consommer routing_keys=nagios.#,shinken.# # intervalle entre 2 exécutions du beat_processing (en secondes) beat_interval=60 # liste des moteurs sur lesquels retransmettre l'événement reçu, possiblement modifié (par défaut: aucun) next=myengine2,myengine3

Et donc l'implémentation se résume à :

def event_processing(engine, event, **_): # traiter l'événement return event def beat_processing(engine, **_): # faire des choses Étape 3 : les schémas

Toutes les données qui véhiculent dans le bus et qui sont sauvegardées en base sont munies de schémas les décrivant.

Ces schémas servent à plusieurs choses :

  • valider que la donnée est bien formatée
  • décrire comment la donnée sera représentée
  • décrire comment la donnée sera éditée

Ces deux derniers points permettent de générer une partie du code de l'UI (cf étape 5).

À terme, ils serviront également à :

  • décrire comment la donnée sera utilisée
  • décrire comment la donnée pourra être transformée

Ce qui permettra de générer une partie du code backend (cf étape 4).

Le formalisme qui permet d'écrire un schéma est actuellement inspiré du standard JSON Schema :

{ "title": "MyData", "description": "Schéma décrivant la donnée, comment l'afficher et l'éditer" // description de la donnée "type": "object", "properties": { "color": { "type": "string", "required": true, /* comment la donnée sera affichée/éditée * le rôle 'color' : * - affichera un carré de couleur lorsqu'on l'affichera * - affichera un colorpicker lorsqu'on l'éditera */ "role": "color", // les champs suivants servent pour le formulaire "title": "Couleur de la donnée", "description": "Tooltip d'aide" } }, // les champs suivants aident à générer le formulaire d'édition "categories": [ { "title": "General", "keys": ["color"] } ] }

L'id d'un schéma est construit de la manière suivante :

  • mydata
  • mydata.mydata2 : ici mydata2 hérite de mydata

On obtient donc en base de données :

{ "_id": "<id du schema>", "schema": // le schéma à proprement parler } Étape 4 : gérer et servir la donnée

Maintenant que nous avons la structure pour récupérer la donnée, et que nous sommes en mesure de la schématiser, il faut mettre en place les mécanismes permettant d'interagir avec et de la servir à l'UI.

A. Les managers

La gestion de la donnée est prise en charge par ce que l'on appelle les managers. Pour bien comprendre son rôle, il faut plonger un peu dans le code.

Un configurable est un objet Python dont les propriétés sont définies par son fichier de configuration :

from canopsis.configuration.configurable import Configurable from canopsis.configuration.configurable.decorator import conf_paths from canopsis.configuration.configurable.decorator import add_category from canopsis.configuration.model import Parameter CONF_PATH = 'myfeature/manager.conf' # {sys.prefix}/etc/{CONF_PATH} CATEGORY = 'MYFEATURE' # Définition du contenu de la catégorie CONTENT = [ Parameter('foo'), Parameter('bar', parser=int) ] # ajoute un fichier de configuration à lire par le configurable @conf_paths(CONF_PATH) # permet de spécifier la catégorie de configuration depuis laquelle on peut lire les paramètres @add_category(CATEGORY, content=CONTENT) class MyFeatureManager(Configurable): pass

Ainsi, avec le fichier de configuration suivant :

[MYFEATURE] foo=bar bar=42

Ou :

{ "MYFEATURE": { "foo": "bar", "bar": 42 } }

En effet, le configurable va tester différents drivers, actuellement on dispose de INI et JSON mais il est envisageable d'avoir un driver MongoDB ou autre

Lorsque l'on instanciera la classe, on obtiendra :

obj = MyFeatureManager() assert obj.foo == "bar" assert obj.bar == 42

Et à partir de cette classe Configurable on va définir l'arbre d'héritage suivant :

Un ConfigurableRegistry permet de spécifier, dans un paramètre de configuration, un autre Configurable à instancier :

otherconfigurable_value = canopsis.myotherfeature.manager.MyOtherFeatureManager

Et on y accèdera, dans l'instance, de la manière suivante :

assert isinstance(self['otherconfigurable'], MyOtherFeatureManager)

Le MiddlewareRegistry fait de même pour les Middleware (qui identifient un protocole ainsi qu'un type de données) :

mymiddleware_uri = protocol-datatype-datascope://

De même que pour le ConfigurableRegistry, on y accède de la manière suivante :

assert self['mymiddleware'].connected()

En général, un manager sera un MiddlewareRegistry, ce qui permettra de changer de techno utilisée, sans modifier le code :

[MYFEATURE] mystorage_uri = mongodb-timed-mydata:// # mystorage_uri = influxdb-timed-mydata:// mymanager_value = canopsis.myotherfeature.manager.MyOtherFeatureManager # mymanager_value = canopsis.myotherfeature.manager2.MyOtherFeatureManager2

Et ce manager sera utilisé par le moteur et le webservice.

En reprenant l'exemple du moteur :

from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager def event_processing(engine, event, manager=None, **_): if manager is None: # instancie la classe une seule fois par module manager = singleton_per_scope(MyFeatureManager) # faire des choses avec l'événement et le manager return event def beat_processing(engine, event, manager=None, **_): if manager is None: manager = singleton_per_scope(MyFeatureManager) # faire des choses avec le manager B. Les webservices

Afin de servir la donnée à l'UI, on dispose d'une application WSGI découpée en modules, que l'on appelle webservice.

Ces derniers se trouvent dans le paquet Python canopsis.webcore.services.

Et grâce au code suivant (à placer dans le __init__.py), on peut avoir plusieurs paquets Python fournissant du code à cet emplacement :

from pkgutil import extend_path __path__ = extend_path(__path__, __name__)

Bref, un webservice s'écrit très simplement :

# couche d'abstraction qui nous permettra de passer de Bottle à Flask from canopsis.common.ws import route from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager # Sera appelé par l'application WSGI pour charger les routes HTTP def exports(ws): # ici `ws` désigne donc le webserver manager = singleton_per_scope(MyFeatureManager) # ici on créé la route /foo qui accepte la méthode GET @route(ws.application.get) def foo(): return manager.foo # l'API retournera : # { # "total": 1, # "data": ["bar"], # "success": true # } # cette fois ci, on créé la route /bar/:baz @route(ws.application.get) def bar(baz): return (manager.bar == baz) Étape 5 : l'application web

Côté backend, on dispose désormais du nécessaire pour fournir à l'UI tout ce dont elle a besoin.
Ainsi, nous avons également travaillé la modularité de cette UI, basée sur Ember, au maximum.

A. Les briques

Afin de répondre à cette problématique de modularité, nous avons mis en place un système de briques, permettant de sélectionner les fonctionnalités effectivement chargées.

Concrètement, on peut voir une brique comme étant un addon apportant plusieurs fonctionnalités telles que :

  • nouveaux éléments graphiques (composants)
  • nouveaux outils de rendus (widgets, renderers)
  • nouveaux outils d'éditions (éditors)

Pour construire une brique, il suffit de créer un paquet NPM avec le package.json suivant :

{ "name": "<nom de la brique>", "description": "<description de la brique>", "version": "0.1.0", // il s'agit du fichier principal de la brique, il pointera vers la version de dev ou minifiée "main": "init.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "compile": "rm -Rf tmp/build && broccoli build tmp/build && cp tmp/build . -RT", "lint": "eslint src", "doc": "./node_modules/canopsis-ui-toolbelt/scripts/buildDoc", "minify": "node node_modules/canopsis-ui-toolbelt/scripts/minify.js" }, "repository": { "type": "git", "url": "<url du dépôt>" }, "author": "<auteur>", "license": "AGPL-3.0", "devDependencies": { "broccoli": "^0.16.9", "broccoli-funnel": "^1.0.1", "broccoli-merge-trees": "^1.0.0", "broccoli-sourcemap-concat": "^1.1.6", "broccoli-template": "^0.1.1", "broccoli-uglify-js": "^0.1.3", // outil de gestion des briques Canopsis "canopsis-ui-toolbelt": "https://git.canopsis.net/canopsis/canopsis-ui-toolbelt/repository/archive.tar.gz?ref=<branche git de canopsis-ui-toolbelt>", "jsdoc": "^3.3.0", "pre-commit": "^1.1.1" }, "pre-commit": [ "lint", "doc" ] }

Puis, dans un dossier src on placera le code source de la brique :

  • components/mycomponent/component.js
  • components/mycomponent/template.hbs
  • renderers/renderer-myrole.hbs
  • editors/editor-myrole.hbs
  • widgets/mywidget/controller.js
  • widgets/mywidget/mywidget.hbs
  • mixins/mymixin.js

L'outil canopsis-ui-toolbelt se charge de :

  • récupérer récursivement tout le code JS dans le dossier src
  • référencer le code JS dans le fichier init.js qui représente la brique
  • récupérer récursivement tout les templates (*.hbs) dans le dossier src
  • référencer les templates également dans le fichier init.js
  • référencer les templates dans Ember.TEMPLATES :
    • pour un composant, il est requis d'avoir le dossier components/<mycomponent>, afin que le template soit reconnu comme étant un template de composant
    • pour le reste, le nom du template dans Ember sera le nom du fichier sans extension

NB: Le découpage n'est donc obligatoire que pour les composants, le reste peut être mis en vrac dans src.

Une fois que l'on a créé tout cela (ou récupéré le dépôt Git), on peut finaliser la brique :

$ npm install $ npm run compile

Chaque fichier source contiendra au moins un Ember Initializer :

Ember.Application.initializer({ name: 'MyModule', after: ['Dependency1', 'Dependency2'], initialize: function(container, application) { var Dependency1 = container.lookupFactory('deptype:dependency1'), Dependency2 = container.lookupFactory('deptype:dependency2'); // do stuff application.register('modtype:mymodule', /* stuff */); } });

Cela permet ainsi de s'assurer du bon chargement de chaque module.

Au final, pour installer une brique, il suffit de :

  • cloner le dépôt finalisé dans : /opt/canopsis/var/www/canopsis
  • lancer la commande webmodulemanager enable mybrick afin de l'activer au chargement de l'UI

L'ensemble des briques existantes (hormis celle par défaut livrées avec Canopsis) sont disponible ici.

B. Les composants

Le composant, l'élément le plus basique de l'UI, sera utilisé par tout les autres éléments.
Il s'agit simplement d'un composant Ember avec un template à fournir.

On définira notre composant dans src/components/mycomponent/component.js :

Ember.Application.initializer({ name: 'MyComponent', after: [], initialize: function(container, application) { var MyComponent = Ember.Component.extend({ init: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // on implémente les actions, déclenchable depuis le template foo: function() { alert('bar'); } } }); application.register('component:component-mycomponent', MyComponent); } });

Et le template dans src/components/mycomponent/template.hbs :

<h1>My awesome component</h1> <a {{action foo}}>Launch action</a> C. Les renderers/éditeurs

Une fois nos composants définis, on est en mesure de les utiliser dans des renderers ou des éditeurs.

Le but de ces éléments est simple :

  • lorsqu'on demande l'affichage d'une donnée avec le composant renderer :
    • le champ role du schéma JSON est également lu
    • si un renderer du même nom est trouvé, il est utilisé dans le template
    • sinon, on affiche la donnée telle quelle
  • lorsqu'un formulaire d'édition est généré à partir du schéma JSON, en utilisant le composant editor :
    • le champ role est lu
    • si un éditeur du même nom est trouvé, il est utilisé dans le formulaire
    • sinon, on utilise l'éditeur par défaut

Les renderers/éditeurs ne sont donc que de simple templates HTMLBars.

On aura le renderer dans src/renderers/renderer-myrole.hbs :

<p>My rendered data: {{value}}</p> {{component-mycomponent}}

Et l'éditeur dans src/editors/editor-myrole.hbs :

<p>My data is being edited :</p> {{input type="password" value=attr.value}} {{component-mycomponent}} D. Les widgets

Enfin, on aura les widgets, qui seront en mesure d'utiliser composants et
renderers afin d'implémenter des outils de visualisation de données plus complexes.

Un widget est un MVC complet :

  • on implémente un contrôleur
  • on implémente des mixins qui viendront s'appliquer à la vue
  • on écrit un template

Ce qui donne :

Ember.Application.initializer({ name: 'MyWidget', after: ['WidgetFactory'], initialize: function(container, application) { var WidgetFactory = container.lookupFactory('factory:widget'); var widgetOptions = {}; var MyWidgetViewMixin = Ember.Mixin.create({ didInsertElement: function() { this._super.apply(this, arguments); // faire des choses }, willDestroyElement: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // actions de la vue } }); var widget = WidgetFactory('mywidget', { viewMixins: [ MyWidgetViewMixin ], actions: { // actions du contrôleur }, init: function() { // faire des choses }, findItems: function() { // méthode appelée lors de la récupération des données pour le template } }, widgetOptions); application.register('widget:mywidget'); } });

Ensuite, il est nécessaire de créer un schéma widget.mywidget.json qui sera utilisé pour configurer le widget lors de son ajout dans une vue :

{ "title": "MyWidget", "description": "Schéma de configuration de MyWidget", "metadata": { // icône dans le formulaire d'ajout de widget "icon": "fa fa-cog" }, "categories": [ { "title": "General", "keys": ["foo"] } ], "type": "object", "properties": { "foo": { "title": "Foo", // nom du champ dans le formulaire "description": "Foo field", // tooltip dans le formulaire "type": "string", "role": "myrole" } } } E. Les mixins

Lorsque l'on a des fonctionnalités communes à plusieurs widgets (comme le PeriodicRefresh qui actualise le widget régulièrement), il convient de factoriser le code en un mixin.

Ce dernier pourra être ajouté et configuré au widget via l'UI, et ensuite appliquer la-dite configuration au contrôleur du widget :

Ember.Application.initializer({ name:'MyMixin', after: ['MixinFactory'], initialize: function(container, application) { var Mixin = container.lookupFactory('factory:mixin'); var get = Ember.get; var MyMixin = Mixin('mymixin', { mixinsOptionsReady: function() { this._super.apply(this, arguments); var mixinOptions = get('mixinOptions.mymixin'); // faire des choses } }); application.register('mixin:mymixin', MyMixin); } });

Et il ne manque plus que le schéma mixin.mymixin.json décrivant la configuration du mixin :

{ "title": "MyMixin", "description": "Schéma de configuration de MyMixin", "metadata": { // description affiché dans l'UI "description": "Add stuff to widget" }, "categories": [ { "title": "General", "keys": ["bar"] } ], "type": "object", "properties": { "bar": { "title": "Bar", "description": "Bar field", "type": "string" } } } F. Les vues

Tout les outils sont désormais à notre disposition pour construire nos dashboards.

Donc si on résume :

  • une vue est composée de widgets
  • un widget est composé de composants et de mixins

L'UI fournit les outils qui permettent de construire ces vues, le résultat final est un document JSON stocké en base :

{ "_id": "id de ma vue", "description": "description de ma vue" "crecord_name": "nom de ma vue", "crecord_type": "view", "author": "<user qui a créé la vue>", "enable": true, "internal": false, "tags": [], // le widget initial de la vue "containerwidget": { // identifiant du widget "xtype": "widgetcontainer", "title": "container title vbox", // le widget "widgetcontainer" s'attend à avoir un champ "items" "items": [ { // le widget "widgetwrapper" sert à inclure des widgets dans un container pour les placer correctement "xtype": "widgetwrapper", "title": "wrapper", // le widget encapsulé : "widget": { "xtype": "mywidget", "title": "My awesome widget", // configuration spécifique au widget "foo": "bar", // mixins appliqués via l'UI : "mixins": [ { "name": "periodicrefresh", // paramètres du mixin "refreshInterval": 60 }, { "name": "mymixin", // paramètres du mixin "bar": "baz" } ] } } ], // le container de base de la vue à un widget de layout par défaut "mixins": [ { "name": "lightlayout" } ] } }

La totalité de l'UI est générée à partir de ces vues JSON, et est donc complètement personnalisable.

Le bac à événements

Parmi les vues par défaut qui sont livrées avec Canopsis, on trouve le Bac à événements.

Cette vue fournit un dashboard de supervision commun, unifiant ainsi la totalité des superviseurs remontant des informations à Canopsis.

Depuis ce bac, on voit apparaître les différentes alarmes avec comme informations :

  • leurs sources d'émission (le connecteur)
  • leurs sources cible (composant/ressource, qui dans la plupart des cas correspond au couple host/service)
  • le dernier message associé à un check (Nagios, Shinken, Centreon, …)
  • le statut de l'alarme associé au check :
    • Off : aucune alarme n'est présente
    • On Going : un problème a été remonté et n'est toujours pas résolu
    • Stealthy : une alarme a été remontée et est immédiatement repassée OK (durée paramétrable)
    • Flapping : il y a eu X changements d'état en 1h sur l'alarme (durée et fréquence paramétrable)
    • Cancelled : l'alarme a été annulée par un utilisateur (pour éviter les faux-positifs)
  • l'état du check :
    • INFO : tout va bien
    • MINOR : équivalent au Warning de Nagios
    • MAJOR : équivalent au Critical de Nagios
    • CRITICAL : les Unknown de Nagios sont remontés en tant que tel, mais cela ne se limite pas à cette notion
    • UNKNOWN : état non pris en charge à l'heure actuelle, c'est tout ce qui est supérieur à CRITICAL (3)
  • la présence d'un acquittement et/ou d'un ticket :
    • les connecteurs pour Nagios, Shinken, etc… peuvent remonter les acquittements posés
    • depuis Canopsis, on peut en poser manuellement
  • la date du dernier changement d'état

Sur chaque alarme, on peut réaliser différentes actions :

  • l'acquittement (permet de déverrouiller les autres actions), cela émettra le même événement qui serait remonté par un superviseur, soit un événement de type ack
  • une suppression de l'acquittement, cela émettra un événement de type ackremove
  • une annulation de l'alarme, cela émettra un événement de type cancel
  • une fois l'alarme annulée, on peut annuler cette action, cela émettra un événement de type uncancel
  • une déclaration de ticket :
    • cela émettra un événement de type declareticket
    • cet événement pourra être capturé par le moteur event_filter pour déclencher un job (voir plus bas) qui communiquera le ticket à un outil tiers (par exemple iTop)
  • une association de ticket existant :
    • cela émettra un événement de type assocticket
    • on peut imaginer que le job qui communique la déclaration du ticket à l'outil tiers récupère le numéro du ticket nouvellement créé, et l'associe automatiquement
  • une requalification de l'événement :
    • cela changera l'état du check manuellement, et ce dernier gardera cet état jusqu'à la résolution de l'alarme
    • cela émettra un événement de type check, comme le superviseur
    • la seule différence est la présence d'un champ keep_state qui vaut true dans l'événement

Toutes ces actions permettent ainsi d'unifier une supervision hétérogène, et l'administrateur (technique) ne devra utiliser/maîtriser qu'un seul outil.

Sélecteur et widget météo : simplifier la supervision

Lorsque l'on supervise une grosse infrastructure, les informations remontées via les checks deviennent tout de suite beaucoup plus conséquentes. C'est pourquoi nous avons mis en place la possibilité d'agréger ces checks afin d'avoir une visibilité plus simple sur l'infra.

Cette agrégation se fait à l'aide des sélecteurs :

  • on créé un filtre d'événements
  • on applique un algorithme à l'état de chaque check qui matche le filtre (actuellement seul l'algo Worst State est disponible)
  • on produit un événement de type selector qui contient :
    • l'état agrégé
    • le champ output qui est le rendu du template spécifié dans la configuration du sélecteur
  • si le sélecteur est configuré pour, on déclenche le calcul des SLA :
    • sur une période de temps (spécifiée dans la configuration du sélecteur)
    • on calcule le pourcentage de temps passé sur chaque état possible
    • on produit une métrique pour chacune de ces métriques, ainsi qu'un événement de type sla
    • l'état remonté par l'événement correspond aux seuils de SLA configurés dans le sélecteur

Le résultat est finalement affichable avec un widget weather :

NB: Le sélecteur peut afficher également des checks unitairement

On peut ainsi noter les couleurs suivantes :

  • vert : l'état du sélecteur est INFO
  • jaune : l'état du sélecteur est MINOR
  • orange : l'état du sélecteur est MAJOR
  • rouge : l'état du sélecteur est CRITICAL
  • violet : toutes les alarmes du sélecteur ont été acquittée
  • la couleur du widget est celle du pire état des sélecteurs positionnés dans celui ci

Un clic sur le sélecteur dans le widget nous redirigera sur le Bac à événements, filtré avec le filtre du sélecteur.

Monitoring et séries

Chaque connecteur, moteur, et sélecteur produisent des données de performances :

  • temps d'exécution d'un check
  • usage CPU/RAM/Disque
  • temps moyen passé sur un événement
  • nombre moyen d'événements par seconde
  • donnée de SLA

Tout cela est remonté dans Canopsis dans un événement via le champ perf_data_array :

{ // info de l'événement classique "perf_data_array": [ { "metric": "nom_de_ma_metrique", "value": 42.1337, "type": "GAUGE", // GAUGE, COUNTER, ABSOLUTE ou DERIVE // champs optionnels "unit": "...", "min": 0, "max": 1337.42, "warn": 1000, "crit": 1300 } ] }

Ces données vont être historisée dans Canopsis. On peut donc noter 4 types de métriques :

  • GAUGE : on historise la valeur telle quelle
  • COUNTER : lorsque l'on récupère la valeur, on fait l'addition des valeurs historisées
  • ABSOLUTE : on historise la valeur absolue
  • DERIVE : il s'agit de la valeur dérivée par rapport au temps

Une métrique est ensuite identifiée par :

  • le composant de l'événement
  • la ressource de l'événement
  • le nom de la métrique dans le tableau de perfdata

Le tout peut être affiché dans un chart :

On est ainsi en mesure de sélectionner un ensemble de métrique avec un filtre basé sur des expressions régulières :

  • co:.*\.myhost re:cpu-.* me:system me:user me:wait

Qui se traduit en filtre MongoDB :

{ '$and': [ {'component': {'$regex': '.*\.myhost'}}, {'resource': {'$regex': 'cpu.*'}}, { '$or': [ {'name': {'$regex': 'system'}}, {'name': {'$regex': 'user'}}, {'name': {'$regex': 'wait'}} ] } ] }

Une fois les identifiants de métriques récupérés, on peut aller demander les points stockés en base, dans une fenêtre de temps bien définie.

Une série est donc munie :

  • d'un filtre de métrique
  • d'une période d'agrégation avec un opérateur d'agrégation (le manager de perfdata nous retournera les données agrégées)
  • d'une période de consolidation
  • d'une formule de consolidation

Ici la partie consolidation sert à consolider les différents points agrégés en un seul, afin de produire une nouvelle métrique.

La formule se construit de la manière suivante :

  • on a des opérateurs qui prennent en paramètre un filtre de métrique qui sera appliqué sur l'ensemble de métriques déjà sélectionnées
  • ces opérateurs retournent un point consolidé
  • on peut les utiliser dans une expression mathématique classique

Par exemple, SUM("me:.*") / COUNT("me:.*"), permet de réaliser une moyenne.

Les tâches ordonnancées et les notifications

Parmi les moteurs de Canopsis, certains sont dédiés à une fonction précise : exécuter une tâche.

Il y a donc un moteur scheduler qui, régulièrement, va chercher à exécuter des jobs configurés selon une règle de récurrence.
En fonction du type de job, ce dernier sera redirigé au moteur correspondant, que l'on appellera un taskhandler.

Cela permet de construire un équivalent de crontab au sein de Canopsis.

Ces taskhandlers ne servent pas uniquement à l'exécution de tâches ordonnancées, ils peuvent être utilisés en tant que notification :

  • une règle du moteur event_filter peut déclencher l'exécution d'un job si l'événement reçu matche le filtre de la règle
  • par exemple, à la réception d'un événement declareticket, on peut lancer l'exécution d'un job réalisant une requête d'insertion de ticket à un outil tiers
Conclusion

Grâce à tout ces éléments, Canopsis est en mesure de répondre à de nombreux besoins, allant de la supervision simple, à l'analyse poussée de données afin de générer des rapports sur une infrastructure (ou autre).

Notre objectif premier est la modularité du projet, afin de pouvoir fournir une solution sur mesure et de ne pas transformer l'outil en énorme usine à gaz. Pour résumer, on a répondu à cette problématique avec :

  • le découpage du backend en projets Python embarquant : un manager, éventuellement un moteur et un webservice
  • le découpage du frontend en briques embarquant : des composants, des renderers, des éditeurs, des mixins, des widgets
  • la schématisation des données et à l'avenir des actions possibles sur cette dernière (transformation, schématisation de l'API des managers, …)
  • le développement d'API générique permettant le changement de technologies sans modification du code

Beaucoup de choses ont été faites, et beaucoup de travail reste à faire, notamment :

  • la finalisation des rôles Ansible
  • l'intégration d'une notion de graphe pour les entités qui sont le centre de toutes les données stockées par Canopsis, afin de rendre le système complètement réflexif
  • une séparation totale du backend et du frontend, permettant d'utiliser l'un sans l'autre
  • génération de code à partir des schémas

Bref, Canopsis est en constante évolution, et touche à de nombreuses problématiques toutes plus intéressantes les unes que les autres.

Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 6 de l'année 2016

7 février, 2016 - 01:18

Calendrier web, regroupant des évènements liés au Libre (logiciel, salon, atelier, install party, conférence) en France, annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 28 événements est en seconde partie de dépêche.

Sommaire Agenda du Libre pour la semaine 6 de l'année 2016 [Kunheim] Formation Linux - Le lundi 8 février 2016 de 18h00 à 22h00.

Tous les lundis à partir de 18h00 jusqu'à 22h00 venez découvrir ou vous former sur Linux et les logiciels libres.
Ces séances de formation ont lieu à la salle "Kegreiss" au 56 rue principale - Kuhneim - face à la mairie - cette salle est accessible aux personnes à mobilité réduite.
Nous vous attendons nombreux. Le Team Linux

[Paris] Atelier OpenData - Le lundi 8 février 2016 de 19h00 à 22h00.

L'atelier « Opendata : les enjeux des données ouvertes » est organisé par Ritimo et animé par Regards Citoyens.
Il est à destination du monde associatif (venir avec son portable). L'entrée est libre et l'inscription obligatoire.
Extrait de la présentation :

[Teyran] Notions PC - Le mardi 9 février 2016 de 09h00 à 10h00.

Réaliser une carte d’invitation avec le traitement de texte LibreOffice Writer
Writer est le composant de traitement de texte de LibreOffice. En plus des fonctionnalités habituelles d’un traitement de texte (correcteur orthographique, dictionnaire des synonymes et de coupure de mots, autocorrection, rechercher et remplacer, génération automatique de table des matières et d’index, mailing et autres) Writer fournit des modèles et styles, des méthodes de mise en page incluant les cadres, les colonnes et les tableaux, incorporer ou lie des images, des feuilles de calcul et d’autres objets, il a des outils de dessins natifs, possède un suivi de modification, exporte en PDF, incluant les repères de texte…
La participation aux ateliers nécessite :

[Castelnau-le-Lez] Section GNU/Linux - Le mardi 9 février 2016 de 10h00 à 12h00.

Rendez-vous hebdomadaire, tous les mardis, salle 38 de la mjc (hors vacances scolaires).
L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.
Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi d’adapter l’acquisition de nouvelles compétences au rythme de chacun.

[Castelnau-le-Lez] Atelier de développement et programmation - Le mardi 9 février 2016 de 10h00 à 12h00.

Rendez-vous hebdomadaire, tous les mardis, salle 40 de la mjc (fermé pendant les vacances).
Cet atelier de développement est essentiellement axé sur les langages du Web : html, css (même si ce ne sont pas des langages à proprement parler) javascript et PHP, possibilité aussi d’utiliser Ajax, Jquery, Sqlite et MySql.
Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.

[Brignoles] Atelier Libre - Le mardi 9 février 2016 de 18h30 à 21h30.

Les membres de l'association GULLIVAR (Groupe d'Utilisateurs de Logiciels Libres de l'Intérieur du Var) vous invitent à une soirée atelier / présentation logiciel libre qui aura lieu le 9 février 2016, dans la salle des Saint Anges, chemin de San Sumian à Brignoles à partir de 18h30.
À 19h30, l'atelier / présentation.
Cette soirée est ouverte à tous, adhérents et sympathisants.

[Bordeaux] Atelier CLI - Le mardi 9 février 2016 de 19h00 à 21h00.

Damien Goutte-Gattat, post-doctorant à l'Institut Européen de Chimie et Biologie, présentera GnuPG (GNU Privacy Guard) pour les utilisateurs avancés.
Déjà habitué avec ses articles, tel que « De la gestion des clefs OpenPGP », postés dans son journal sur linuxfr.org, cet atelier sera certainement très instructif. On pourra, en autre, créer sa clé GPG et la partager :)
L'atelier sera suivi d'un apéritif permettant aux participants de se rencontrer et de poursuivre la discussion.

[Paris] Tuppervim #43 - Le mardi 9 février 2016 de 20h00 à 22h00.

Le tuppervim est un évènement mensuel organisé dans les locaux de Mozilla.
Il a lieu un mardi du mois (généralement le premier).
Le texte suivant a été honteusement copié du site http://tuppervim.org

[Teyran] Notions PC - Le mercredi 10 février 2016 de 09h30 à 10h30.

Ajouter de la profondeur de champ à une photographie avec Gimp
Gimp offre de nombreuses fonctionnalités. Il peut être utilisé comme un simple programme de dessin, comme un programme de retouche photo, comme un système en ligne de traitement par lot, comme un générateur d’image pour la production en masse, pour convertir un format d’image en un autre. GIMP est extensible. On peut lui ajouter de nombreux « Greffons » (plug-ins). Une interface de scripts bien développée permet de créer des procédures, les scripts, regroupant plusieurs opérations.
La participation aux ateliers nécessite :

[Nantes] Quadr'apéro - Le mercredi 10 février 2016 de 19h00 à 23h00.

Venez discuter des libertés et d'Internet au quadr'apéro mensuel.
Venez nombreux.
Entrée Libre. Tout Public.

[Paris] Atelier design : les couleurs - Le mercredi 10 février 2016 de 19h00 à 21h00.

Atelier Do It Yourself Design : 16,8 Millions de couleurs, et moi et moi!
Dans la série des atelier Do it yourself, l’association Silex Labs vous propose un nouvel atelier pour découvrir l’importance des couleurs dans les projets numériques. Cet atelier sera animé par Pol Goasdoué designer professionnel spécialiste de l’UX UI Président de l’entreprise UFO et co-fondateur du projet Silex.
Au programme de cet atelier

[Paris] Apéro des nouveaux mozilliens - Le mercredi 10 février 2016 de 19h00 à 21h00.

L'apéro des nouveaux aura lieu le 10 février à partir de 19h chez Mozilla (16 bis boulevard Montmartre, 75009 Paris).
Ça sera bien évidement l'occasion pour les nouveaux de rencontrer une partie de la communauté mozfr et pour tous de (re)découvrir comment il est possible de participer. Plus largement, ça serait chouette qu'on profite de l'occasion pour se dire sur quoi on bosse et sur quoi on aimerai bosser. Ça permet de mieux savoir qui est intéressé par quoi et de faciliter la participation de nouvelles personnes. Tout cela se faisant bien sûr  de manière informelle et dans la bonne humeur.
Afin de gérer l'intendance, veuillez-vous inscrire sur le pad:https://public.etherpad-mozilla.org/p/aperoNouveaux

[Proposition en ligne] Appel à communications AgoraCMS 2016 - Du jeudi 11 février 2016 à 00h00 au vendredi 12 février 2016 à 00h00.

La 3ème édition d'AgoraCMS, premier événement européen dédié aux CMS se tient à Paris le 1er avril prochain.
L'appel à communications pour les conférences vient d'être lancé: http://agoracms.com/appel-a-communication.
Vous pouvez y proposer vos idées de conférences, de retours d'expérience, de vos projets.

[Mauguio] Infolibres - Le jeudi 11 février 2016 de 17h00 à 19h00.

Rendez-vous salle de formation informatique de la médiathèque.
L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à apprivoiser votre système GNU/Linux au quotidien. Le contenu de l’atelier s’adapte aux problèmes des personnes présentes.
Vous pourrez y aborder entre autre :

[Paris] Mapathon Missing Maps - Le jeudi 11 février 2016 de 19h00 à 22h00.

Venez découvrir comment contribuer à OpenStreetMap, le "Wikipedia de la carte", durant un « mapathon » !
(un événement convivial où l'on se retrouve pour cartographier, échanger et apprendre à utiliser les outils permettant de contribuer à OSM).
Cet événement s'inscrit dans le cadre de l'initiative globale Missing Maps, projet humanitaire qui vise à cartographier en amont les parties du mondes vulnérables aux catastrophes naturelles, crises sanitaires, environnementales, aux conflits et à la pauvreté.

[Lyon] Jeudi du Graphisme - Le jeudi 11 février 2016 de 19h00 à 21h00.

L'Association Lyonnaise pour le Développement de l'Informatique Libre organise un atelier découverte du logiciel : Darktable : Corrections et profils d’effet qui est animé par les étudiants de la licence CoLibre.
Darktable est un logiciel de développement et retouche de photo. L’application pour les photographes passionnés. Cette année, nous appliquerons à voir quelques techniques de retouche simple et utile et surtout comment créer des profils d’effets qui seront la signature de votre touche personnelle.
Entrée Libre et gratuite

[Paris] Soirée de Contribution au Libre - Le jeudi 11 février 2016 de 19h30 à 23h00.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.
Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies)).
Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

[Montpellier] Formation sécurité informatique et cryptographie - Le vendredi 12 février 2016 de 09h00 à 13h00.

Montpel’libre a le plaisir de vous proposer un nouveau cycle de formation, cryptographie et sécurité informatique.
Merci d’avoir choisi de participer aux ateliers « Sécurité Informatique et Cryptographie » organisés par Le Club de la Presse et Montpel’libre. Les trois ateliers auront lieu les vendredis 5, 12 et 19 février 2016 de 9h00 à 13h00 à l’Atelier des Pigistes du Club de la Presse de Montpellier.
Formation Crypto, séance de préparation, premier module :

[Paris] Locasprint MozFR n°4 - Du vendredi 12 février 2016 à 14h00 au dimanche 14 février 2016 à 20h00.

La communauté Mozilla francophone organise son 4e évènement autour de la traduction. La communauté Mozilla de bénévoles francophones est à l’origine de l’ensemble du contenu en français publié par Mozilla (logiciels, sites web, documentation, pages d’assistance, etc.)
Cet évènement est ouvert à toute personne qui souhaite nous aider à produire des traductions françaises de qualité. Vous avez juste besoin de venir avec un ordinateur et de la motivation.
Ce week-end de travail est l’occasion d’accueillir de nouveaux contributeurs, de leur expliquer notre façon de travailler, nos outils, nos bonnes pratiques…

[Montpellier] Permanence Les logiciels libres - Le vendredi 12 février 2016 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?
Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00 (ou au delà sous réserve d’accord préalable), au 19, rue du Faubourg de Nîmes, 34000 Montpellier.
Si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante et si vous êtes intéressés par la promotion des logiciels libres, des biens communs, de l’accessibilité, de l’économie sociale et solidaire, de l’innovation sociale et numérique, de l’éducation populaire, ou encore du développement durable.

[Villeneuve d'Ascq] Libre à Vous - Le samedi 13 février 2016 de 09h00 à 12h00.

Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres ?
Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.
C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

[Castelnau-le-Lez] Café Numérique GNU/Linux & Logiciels Libres - Le samedi 13 février 2016 de 09h00 à 11h00.

Samedi 13 février 2016 de 9h00 à 11h00 MJC Centre André Malraux 10, avenue de la Moutte, 34170 Castelnau-le-Lez
Bus Ligne 35 arrêt Collège Frédéric Bazille Tramway ligne 2 arrêt La Galine
GPS : Latitude : 43.633946 | Longitude : 3.905794

[Teyran] Notions PC - Le samedi 13 février 2016 de 09h30 à 10h30.

Enregistrer, importer, manipuler des fichiers sonores avec Audacity
Audacity est un logiciel libre4 pour la manipulation de données audio numériques. Audacity permet d’enregistrer du son numérique par le biais des entrées ligne/micro/cd des cartes sons. Il permet d’éditer (copier, coller, sectionner…) les sons sur plusieurs pistes, et il est accompagné de divers filtres et effets : pitch, tempo, réduction de bruit, égaliseur, filtres de Fourier, augmentation de fréquences précises, compression, amplification, normalisation, écho, phaser, wahwah, inversion…
La participation aux ateliers nécessite :

[Toulouse] Atelier Blender pour tous - Le samedi 13 février 2016 de 10h00 à 18h00.

La communauté toulousaine des utilisateurs de Blender est l'une des plus actives de France.
Elle se retrouve régulièrement pour organiser des ateliers, des repas, des soirées.
C'est donc dans ce cadre que le Blender User Group toulousain organise, en coopération avec Toulibre, environ un samedi par mois, de 10h à 18h dans les locaux de l'espace Ékito, 15 rue Gabriel Péri à Toulouse.

[Saint-Denis] Assemblée générale de l'April - Du samedi 13 février 2016 à 13h00 au dimanche 14 février 2016 à 19h00.

L'assemblée générale de l'April aura lieu le samedi 13 février 2016 de 14h à 18h (accueil à partir de 13h00) à l'université Paris 8 à Saint-Denis (bien que l'AG se tienne en 2016, elle concerne le bilan de l'année 2015 mais bien sûr les perspectives 2016 seront abordées).
Il s'agit d'un des événements importants de la vie de l'association, l'occasion de voter les rapports moral et financier, faire un point sur l'année qui vient de s'écouler, de rencontrer les autres adhérents et d'élire le conseil d'administration.
L'assemblée générale est l'occasion d'organiser un week-end de réunion des membres. Le dimanche sera consacré à des ateliers en petits groupes ou discussions en plénière. Ce week-end est en cours d'organisation, plus de détails bientôt. Cette partie atelier est ouverte à tout le monde et aura lieu à la Fondation pour le Progrès de l'Homme à Paris. Une soirée festive est prévue le samedi soir et des ateliers sont prévus le dimanche. Le lieu pour la soirée n'est pas encore fixé.

[Ramonville Saint Agne] Atelier web: les squelettes sous SPIP - Le samedi 13 février 2016 de 14h00 à 18h00.

Deux nouvelles animations organisées très prochainement par le Projet Internet et Citoyenneté à la Maison des Associations de Ramonville. Ces deux animations sont complémentaires: c'est une bonne idée de participer aux deux, mais ce n'est pas obligatoire.
1/ SAMEDI 30 JANVIER 2016: Personnaliser son site Web avec les CSS: Initiation aux CSS. À partir de la version distribuée de SPIP, personnaliser son site en modifiant les fichiers CSS.
2/ SAMEDI 13 FEVRIER 2016: Initiation à l’écriture/modification des squelettes qui conditionnent les fonctionnalités présentes dans les pages d’un site sous SPIP. Modifier le squelette des articles, rubriques, etc. pour changer l’aspect et les fonctionnalités présentes dans les pages du site.

[Saint-Aunès] Permanence Emmabuntüs et Logiciels Libres - Le samedi 13 février 2016 de 14h00 à 18h00.

Samedi 13 févier 2016 de 14h00 à 18h00 Communauté Emmaüs Montpellier-Saint-Aunès La Vieille Cadoule 34130 Saint-Aunès
GPS Latitude : 43.649363 | Longitude : 3.991591
Rendez-vous mensuel, le deuxième samedi. Pour les animateurs, réservez les repas et le covoiturage le jeudi au plus tard.

[Marseille] Atelier « Découverte des Logiciels Libres Firefox » - Le samedi 13 février 2016 de 14h30 à 18h00.

L’association CercLL vous invite à l’ Atelier du Samedi Libre qui se déroule le samedi 13 février 2016 de 14h30 à 18h00, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille.
Ces ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé.
Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

Télécharger ce contenu au format Epub

Lire les commentaires

Mais où est donc la révolution des imprimantes 3D ?

6 février, 2016 - 13:54

Depuis quelques temps déjà on nous annonce la révolution des imprimantes 3D. Mais, dans notre vie quotidienne, toujours rien ! Mais où est donc cette révolution ?

Ceux qui possèdent une imprimante 3D ont une approche un peu différente de la consommation. Par exemple, quelqu'un de chez Ckab s'est fabriquée un autre bouton de pantalon, certains ont facilement réparé leur chasse d'eau ou un autre objet en plastique. La plupart des objets deviennent réparables :-)

Pour les professionnels aussi c'est une approche différente, par exemple en cuisine, remplacer le plastique par une pâte, comme la pâte à pain ou une pâte de chocolat.

Et cette révolution est d'autant plus importante qu'elle est animée par l'esprit du partage et de l'open hardware.

Sommaire La révolution en marche

De plus en plus de particuliers s'offrent une imprimante 3D (~1000€), de plus en plus d'entreprises se créent sur ce secteur, les passionnés s'organisent en fablabs et des objets libres peuvent être dupliqués :

Il y a aussi la possibilité de faire du prototypage rapide pour les projets industriels, beaucoup plus facilement et rapidement. Par exemple, le projet de caméra cinéma ouverte Apertus AXIOM a pu créer des prototypes de son futur boîtier en taille réelle.
Cela ouvre la création hardware, même à objectif final professionnel et industriel, à bien plus de gens.

Bientôt, au lieu de jeter un appareil électroménager, nous pourrons fabriquer la pièce défectueuse… À condition que les plans des objets soient librement disponibles. (Oui c'est vrai : combien de fois, un petit élément en plastique se casse, comme dans sa chasse d'eau, et plus rien ne fonctionne correctement).

Et c'est bien cet esprit de matériel ouvert qui permet d'éviter que des industriels monopolisent l'innovation en brevetant les systèmes. Ainsi le projet RepRap partage sous licence libre des imprimantes 3D qui sont capables de s'auto-dupliquer, excepté les tiges métalliques et circuits électroniques (mais cela viendra peut-être).

En pas libre, des sociétés proposent d'imprimer des objets proposés par des créateurs très geeks matheux comme des fractales 3D, des polygones réguliers, et autres pavages hexagonaux projetés à la bougie … Il devient aussi possibles d'imprimer des figurines pour les geeks de types board game … ouvrant la voix à un modèle économique pour le jeu de plateau libre ?

Retour aux sources

Les RepRaps sont nées de l'idée d'un professeur anglais qui a décidé que cette impression 3D, inventée même avant le noyau Linux, devait l'être pour tous. L'engouement des passionnés a fait le reste et, devant ce succès, sont nées des machines grand public prêtes à l'emploi. Mais ce sont bien les RepRaps qui ont permis deux choses :

  • Rassembler des citoyens pour défendre la liberté de créer des objets
  • Définir les standards techniques

Dans ce domaine, le monde du Libre joue, avec des leviers considérables, de tous ces atouts (rapidité et flexibilité des modèles, contributions ultra-actives, recherches pointues et audacieuses !), laissant souvent derrière les industriels les plus motivés. Et c'est tant mieux car cela a déjà permis d'imposer le consommable sous forme de bobine et non pas en cartouches munies de puces ! Rien que ça, c'est une titanesque victoire !

États des lieux entre brevets et communautés libres

D'un côté nous avons de plus en plus d'entreprises qui se créent pour répondre aux besoins d'autres entreprises et institutions de créer des objets décoratifs, intelligents et connectés. C'est le cas de la jeune start-up CKAB qui a bien voulu répondre à nos questions.

Il y a aussi les fabricants d'imprimantes 3D qui sont tentés de déposer des brevets pour affaiblir les marges d'innovation des concurrents, puis monopoliser le marché pour pratiquer ses propres tarifs, et ainsi pérenniser/augmenter leurs revenus. Tous les industriels n'ont pas ce comportement, mais comme d'autres le pratiquent (et que c'est légal), pourquoi s'en priver ?

Parmi les concurrents, de l'autre côté, nous avons les particuliers qui s'émancipent et partagent librement leur passion. Ce sont des communautés rassemblées le plus souvent en fablabs. Mais aussi, des particuliers qui s'équipent chez eux tels des artisans.

Tous ne viennent pas du monde du logiciel libre (pour ne pas dire presque pas). Mais tous ont goûté la satisfaction de l'entraide, du partage des sources et des bienfaits de l'open hardware.

Entretien avec Romain Pouzol, directeur des opérations de la société CKAB

Cette jeune start-up CKAB est revendeur officiel de la marque d'imprimantes 3D Makerbot et propose également la conception et la fabrication d'objets plus ou moins complexes.

D'où est venue l'idée de créer CKAB ?

Lorsque le matériel open-source (ou libre, attention #troll_inside) est apparu, porté par l’émergence du financement participatif, non seulement on a relativement1 décloisonné certaines technologies mais en plus et surtout, on a ouvert un univers d’usages collaboratifs, circulaires, inédits et virtuellement infinis.
En d’autres termes, l’OSHW nous a donné le pouvoir de dématérialiser, de transformer et de re-matérialiser notre environnement physique.

Dès lors, nous avons commencé à explorer cet univers des possibles, d’abord par la voie de la petite électronique open-source par le biais de notre e-shop Hackable-Devices (transféré et intégré depuis sur CKAB.io) puis par la voie des imprimantes 3D de bureau.
Pour être tout à fait clair, ce n’est pas la Technologie en tant que telle qui nous intéresse au premier plan, ce sont les usages que l’on peut en faire et sur ce point, je ne vois pas comment le monde privatif pourrait rivaliser, à terme, avec le monde ouvert.

À titre plus personnel, ce sont plus particulièrement les répercussions au plan politique — au sens strict du terme — qui m’intéressent. Je vois en l’impression 3D la même lame de fond « d’empowerment » des masses que celle que l’on a connue avec les médias sociaux, à la différence près que cette fois, on fait disparaître toute frontière entre environnement matériel et immatériel. Ma conviction est que si les ténors du secteur n’embrassent pas dès maintenant le phénomène de la fabrication numérique, les consommateurs le feront pour eux et là, oui, les industriels souffriront.

CKAB se définit aujourd’hui comme « l’agence de la fabrication numérique et des objets intelligents » et il suffit de nous rendre visite (1 place Saint-Gervais – 75004 Paris) pour se rendre compte que, si nous sommes une entreprise commerciale et non un FabLab, notre environnement ressemble plus au laboratoire du professeur Tournesol qu’à de cliniques bureaux d’import/export d’électronique.

Quelle est la première activité ou l'activité la plus lucrative ?

Au début de l’activité, les ventes d’imprimantes 3D portaient la société. Sauf erreur de ma part, CKAB a été, avec notre partenaire belge de l’époque, l’importateur historique de MakerBot en Europe. On a donc la petite fierté de compter parmi les rares à avoir mis les mains sur les cinq générations de machine… et à les avoir bien modifiées.
Aussi fou que cela puisse paraître, je crois que nous sommes les seuls à avoir pris la peine de, par exemple, traduire l’interface de la machine en français. Ce n’était clairement pas un immense exploit mais le plus cocasse est qu’aucun de nos confrères ne semble s’être donné la peine de reprendre notre travail pour un portage en allemand, espagnol, etc.
C’est assez révélateur de l’état d’esprit du marché. Cela était prévisible mais reste dommage.

Aujourd’hui, ce sont nos activités de conseil et d’évènementiel qui sont les plus importantes. Non pas que nous ne vendons plus de machines mais plutôt que l’acquisition du matériel intervient en fin de parcours.
Nous avons dorénavant affaire au responsable du bureau d’étude, au CTO voire à des achats stratégiques décidés au niveau de la direction générale. Dans le secteur public, nous sommes passés d’achats isolés de tel ou tel collège/lycée à des investissements portés par des Régions, des académies ou encore des Ministères.

Les équipements sont donc plus réfléchis mais ne nous y trompons pas, les entreprises restent très souvent perdues dans la jungle.
C’est sur ce point que nous intervenons : établir la (non-)pertinence directe de ces technologies pour l’entreprise, les accompagner dans une phase exploratoire en prototypant produit ou service, et enfin, si nécessaire, les équiper avec le matériel adéquat et former les collaborateurs.
CKAB représente aujourd’hui une cellule de veille technologique qui performe parce qu’elle dispose d’un savoir et d’un savoir-faire tant du côté software que du côté hardware.

Pour autant, si l’on a travaillé dur pour gagner la confiance de groupes tels que Safran, Air Liquide, Chanel, Auchan, Renault (…), nous ne voulons surtout pas perdre les relations que nous entretenons avec les PME et les artisans car ce sont aussi voire surtout ces entreprises qui, de par leur souplesse inhérente à leur taille, sont à la source de l’innovation dans notre cher pays.
Et quitte à paraître un peu prétentieux, je pense qu’assez rares sont les entreprises qui peuvent se permettre ce grand écart…surtout quand on est une équipe qui vient tout juste de passer à 3 personnes :-)

À quel point le secteur est-il en croissance ?

La recherche est très active, en particulier dans le domaine de la santé. L’avenir (15~25 ans) nous réserve de très belles choses.
On parle d’impressions de tissus vivants, d’organes, de prothèses et si l’on a un peu d’imagination et que l’on associe la bio-impression 3D aux nanotechnologies, on verse rapidement dans l’humain augmenté, le trans-humanisme, la fameuse singularité.
À ce niveau expérimental, l’open-source fonctionne à plein régime et m’est avis que si 2016 verra de nombreux FabLabs et assimilés fermer, on verra également un essor de lieux tiers orientés biologie tels que le bio-hackerspace « La Paillasse » à Paris.

La recherche un peu plus appliquée est également en ébullition depuis quelques années. Il reste de nombreux obstacles à lever et tous ne sont pas de nature technique mais, globalement, les efforts sont portés sur le passage du prototypage à celui de la production d’objet fini ; qu’il s’agisse d’outillage rapide ou de sous-ensembles présents dans des biens de consommation.

Au niveau des particuliers, certes les machines s’améliorent et peuvent se simplifier — ce qui est souvent synonyme d’un enfermement dans une prison dorée avec une perte de contrôle conséquente sur le matériel — mais il n’y a pas de révolution. On reste par exemple toujours ou presque sur du dépôt de filament fondu donc une seule matière et une seule couleur.
À ce niveau, l’Open-Source est moteur avec tout ce que cela sous-entend en termes de collaboration. Il suffit d’examiner l’arbre généalogique du mouvement RepRap pour s’en rendre compte : plus de 400 projets et encore, cela ne couvre que 2006-2012 !

Et je ne parle même pas des machines qui tirent parti du firmware open-source Marlin mais qui ne sont pas des RepRap pour autant car pas OSHW.

À côté de cela, je fais partie des personnes qui ne pensent pas que chaque famille Michu aura une imprimante 3D chez soi à court voire à moyen terme.
En effet, même si l’on pose l’hypothèse que le matériel sera accessible financièrement et techniquement parlant, même si l’on admet que les matériaux seront disponibles pour tous, reste la question de la CAO.
Dessiner un objet véritablement utile en 3D est quelque peu plus complexe que d’ouvrir son traitement de texte…
Certes des solutions logicielles apparaissent mais ce n’est pas la panacée.
En ce sens, les machines qui clament haut et fort un comportement plug’n play sont soit de quasi-jouets soit sont techniquement capables mais tellement castrées par un logiciel privatif que leur usage est des plus restreints.
Au niveau de cette dernière strate, on voit donc beaucoup d’agitation mais beaucoup moins de choses réellement innovantes, fonctionnelles et pérennes ; ce qui est normal car elles appellent un marché qui ne répond pas.

De là à dire que l’impression 3D n’impactera jamais le grand public, il y a un pas que je me garde bien de franchir. Nous avons quelques idées mais ça, c’est une autre question… ;-)

Y a-t-il de la place pour d'autres entreprises dans ce secteur ?

Le marché de la distribution de matériel est devenu très concurrentiel, malheureusement parce que certains ont évidemment fait le choix de la chasse au dernier euro au détriment de la qualité du matériel et du service, ce qui a tiré une bonne partie du marché vers le bas.
Démarrer aujourd’hui une activité de revente de machines me semble donc compliqué.

Par contre, il y a encore de la place dans le secteur de la conception de machines même si partir la fleur au bout du fusil avec un produit minimum viable (MVP) financé par crowdfunding est aujourd’hui relativement illusoire.

Quelle est la philosophie de Makerbot ?

Avant son rachat par Stratasys (2e acteur mondial) en 2012 pour 400 M$, Makerbot travaillait pour et avec les Makers. Grosso-modo, on peut dire que si l’on cherchait une machine de bureau qui fonctionne bien pour en faire un usage professionnel, il n’y avait que MakerBot qui comptait.

Depuis le rachat, il y a eu de nombreux changements de stratégie et de direction générale, la ligne directrice est plus floue. Trop souvent les produits n’ont pas été en phase avec le marketing.
En guise d’exemple, CKAB ne vend quasiment pas d’imprimante 3D MakerBot de 5e génération, nous préférons l’avant-dernière génération : moins chère, plus silencieuse, plus rapide, plus évolutive, plus performante.
Ces machines de 4e génération sont par ailleurs toujours open-source au niveau du firmware et nous les avons bien transformées au niveau matériel ce qui fait que même 3 ans après leur sortie, les Replicator2 améliorées par CKAB comptent toujours parmi les meilleures machines du marché.

Je ne vais pas m’attarder sur les dessous de l’affaire, je vous conseille de lire ces quelques articles :

Quelle est la part de marché de Makerbot ?

Je ne saurais dire précisément. Je pense qu’ils sont toujours les premiers au plan mondial même si la 5e génération de machines leur a fait du mal. Quoi qu’il en soit, ils ont les ressources pour atteindre leurs objectifs.

Quelles relations avec l'open hardware, les licences libres, les forums d'entraide, les fablabs ?

Si l’on parle de MakerBot, plus aucune à ma connaissance depuis le rachat par Stratasys.

Si l’on parle de CKAB, nous ne sommes pas des sectaires du Libre ou du propriétaire mais tant que faire se peut, on essaye de travailler avec des composants ouverts, qu’il s’agisse de logiciel ou de matériel.
Quand on développe des prototypes d’objets intelligents pour nos clients, il ne s’agit pas forcément de payer moins cher telle ou telle brique logicielle ou matérielle mais plutôt de bénéficier de documentation, de souplesse d’utilisation, de partage (…) bref d’efficacité.

Quant à donner en retour, on privilégie les actions concrètes sur le terrain plutôt qu’en ligne : atelier de soudure, prix doux pour fablabs, etc.

Que conseiller aux lecteur de LinuxFr.org pour s'y mettre ?

Tout dépend de ce que vous cherchez. Si vous souhaitez vous amuser à bidouiller – au sens noble du terme – une imprimante 3D, alors on pourra vous conseiller mais CKAB ne sera probablement pas votre interlocuteur commercial.
Par contre, si vous préférez avoir un outil stable bien qu’ouvert donc évolutif et vous concentrer sur les objets qui sortiront de votre machine, alors on sera probablement beaucoup plus en phase.

En ce qui concerne l’électronique, nous avons quelques joyeusetés en boutique mais nous ne cherchons pas à concurrencer selectronics ou sparkfun. Nous avons des compétences de sourcing, de dev soft et hard donc on peut accompagner pas mal de projets.

En tout état de cause, je recommanderais une bonne dose de patience enrobée de logique, quelques épices de passion voire de folie, le tout baignant dans un nuage d’imagination.

N’hésitez pas à nous rendre visite, sur rendez-vous :

  • 1 place Saint-Gervais – 75004 Paris, chez les Compagnons du Devoir,
  • Métro Pont-Marie ou Hôtel de ville.
  • Tel : 01 85 09 96 42
  • Courriel : contact@ckab.io
Faire ses premiers pas, la communauté, les fablabs Avantages et inconvénients de l'impression 3D Technologies actuelles

Les imprimantes 3D sont utilisées depuis plusieurs décennies pour la réalisation de prototypes. En effet, de manière générale, une pièce mécanique est d'abord conçue en CAO, prototypée, puis modifiée pour pouvoir la produire grâce aux méthodes traditionnelles (extrusion, moulage, etc.).

Aujourd'hui, que ce soit par stéréolithographie ou SLA, frittage sélectif par laser ou SLS, ou tout autre procédé dit additifs, voici les avantages :

  • possibilité de créer des pièces infaisables autrement (sphères internes, porosité pré-calculée, etc.)
  • rapidité relative pour la création de pièces à petit tirage ;
  • coûts en chute libre ;

Néanmoins, les impressions 3D ne sont pas très utilisées pour produire massivement pour plusieurs raisons :

  • lenteur pour produire des pièces à la chaîne ;
  • consommation énergétique très élevée ;
  • sécurité particulière (atmosphère sous Argon pour certains processus, toxicité des poudres nanométriques nécessaires en intrants, etc.).

En outre, toutes les technologies additives fabriquent des pièces non-isotropes, et mécaniquement peu viables. En effet, une pièce mécanique possède ainsi une résistance différente dans la direction perpendiculaire au plan d'impression par rapport au plan d’impression. L'état de surface est rugueux par définition, mais l'état interne est identique.

Or, il est connu des mécaniciens que tout angle vif est le siège le plus propice d'un développement d'une fracture de la pièce : il est possible d'utiliser cette propriété pour faire en sorte qu'une pièce casse à un endroit privilégié, et ainsi augmenter la sécurité. Mais avec une pièce contenant des irrégularités internes partout, il est impossible de faire confiance à cette pièce.

Demain

Ne nous voilons pas la face : tant qu'il faudra plusieurs heures ou jours pour fabriquer un produit, il est peu probable que cette technique s'impose pour la production de masse.

Néanmoins, on voit émerger de nouveaux produits tels ceux de l'entreprise Carbon3D qui permettent de produire des objets en polymères quelconques (même élastiques), de manière continue (aucune strate affaiblissante), et surtout de 25 à 100 fois plus rapidement (inspiré par Terminator 2).

Bref, les possibilités restent limitées par l'imagination humaine, mais j'attends personnellement que quelqu'un vienne avec une batterie où les anodes et cathodes sont des fractales tridimensionnelles pour faire un petit bond en densité d'énergie !

Conclusion : gare aux brevets !

Les années 90 ont vu le grand public s'équiper d'imprimantes 2D (encre sur papier). Un phénomène similaire peut aussi de se produire avec les imprimantes 3D, propulsant le grand public dans l'économie du partage. La révolution serait alors la possibilité de créer/partager pour un coût "abordable".

Comme pour le logiciel libre, le succès viendra des réseaux sociaux de partage des sources comme github. Mais comme le logiciel libre, la menace est celle des brevets qui risquent de verrouiller l'innovation.

C'est déjà le cas avec les codecs : nous en sommes toujours au JPEG standardisé en 1992 et le grand public ne profite pas librement des avancées majeures des Jpeg2000/…/HEVC car quelques pays puissants (USA, Japon) autorisent les brevets logiciels.

Et dans le monde des imprimantes 3D c'est pire, car les brevets matériels sont autorisés, même en Europe.

Donc ce sont les libertés des citoyens qui se jouent dans cette révolution. Est-ce que le grand public s'appropriera ces nouvelles technologies des imprimantes 3D et entrera dans l'économie du partage. Ou est-ce que nos gouvernements se laisseront séduire par les lobbies pour verrouiller le marché ?

Télécharger ce contenu au format Epub

Lire les commentaires

Présentation d’OpenStack

5 février, 2016 - 08:15

OpenStack, vous connaissez ? Virtualisation et nuage/cloud, ça vous dit quelque chose ? Si vous n’êtes pas un expert, vous voulez sans doute en savoir un peu plus. Cet article est fait pour vous.

Nous allons rappeler ce qu’est un cloud, les différents types de clouds, et où se situe OpenStack. Ensuite, nous ferons une présentation d’OpenStack et de ses différents services.

La version d’OpenStack baptisée Kilo est sortie le 30 avril 2015. Elle incluait à cette date un nouveau service : Ironic. Le 16 octobre 2015, ce fut le tour de la version Liberty. D’autres sont à venir, à commencer par Mitaka, annoncé pour le 7 avril 2016. Pour mémoire, la première lettre du nom de version suit l’alphabet latin.

Cet article a pour but de faire une présentation assez rapide d’OpenStack et de servir de référence aux prochains articles, en particulier lors de la sortie de Mitaka en avril.

NdM. : Cette dépêche est incomplète, elle a longtemps traîné en rédaction. Elle a cependant le mérite de proposer un rare tour d’horizon. Les modérateurs la publient en comptant sur l’excellence de vos commentaires pour nous raconter les évolutions depuis la version Kilo.

Sommaire Les différents clouds Qu’est‐ce que le Cloud computing ?

Le Cloud computing est un concept fourre‐tout. C’est le fait d’utiliser de la puissance de calcul ou de stockage de serveurs informatiques distants par l’intermédiaire d’un réseau, avec certaines caractéristiques comme la disponibilité, l’élasticité, la mutualisation et le paiement à l’usage.

Le plus souvent il s'agit d'un service informatique extérieur à l'entreprise. Cela est donc une façon d'économiser des moyens humains en informaticiens et de les remplacer par un service externe qui peut gérer au besoin une demande importante.

Prenons un exemple pour bien comprendre : le cas d'une suite bureautique. Pour l'entreprise, il y a 2 manières de gérer l'utilisation d'un traitement de texte :

  • Installer sur les postes clients un traitement de texte et payer éventuellement les licences qui vont avec (Microsoft Office 2013, LibreOffice).
  • Utiliser un traitement de texte via un navigateur web (exemple : Microsoft Office 365, Google Doc, Etherpad instancié sur le Framapad).

La première méthode est moins souple, car l'entreprise paie les licences même si le logiciel n'est pas utilisé ; alors qu'avec la seconde, le paiement est à la demande. Par ailleurs, il n'y a pas la phase d'installation du logiciel qui permet d'économiser du temps. Par contre les données sont externalisées, ce qui peut poser des problèmes de sécurité et de confidentialité.

L'exemple qui vient d'être évoqué est un SaaS : Software as a Service/logiciel en tant que service

Mais il y a différents degrés d'informatique en nuage.

On peut faire l'analogie pour manger une pizza :

  • La méthode "à la maison" : on achète les ingrédients, on les cuisine et on met la table. C'est la méthode traditionnelle. L'acheteur (entreprise ou particulier) contrôle tout et en a les compétences.
  • La méthode "à emporter puis cuisiner" : on te fournit les ingrédients. C'est à toi de les cuisiner à ta manière et de s'occuper du reste. L'entreprise en tant qu'utilisateur n'a pas à s'occuper des matières premières mais elle a le contrôle du reste. En cloud, c'est IaaS : Infrastructure as a Service/infrastructure en tant que service, avec les compétences afférentes
  • La méthode "pizza 30 minutes" : on appelle un vendeur de pizza. Il ne reste plus qu'à s'occuper de l'accompagnement et de la table. Dans le nuage, c'est PaaS : Platform as a Service/ plate-forme en tant que service
  • La méthode "pizzeria" : on entre dans une pizzeria et on n'a rien à prendre en charge (ou presque). En cloud, c'est SaaS : Software as a Service/logiciel en tant que service.

OpenStack est un ensemble de logiciels libres permettant de déployer un cloud orienté IaaS, mais il est de plus en plus possible de faire un PaaS.

Cloud privé vs public

Le cloud public est un cloud qui permet à l'entreprise d'externaliser ses moyens. Il y a donc moins d'informaticiens à embaucher. L'entreprise doit par contre payer une autre entreprise et perd le contrôle de l'infrastructure et les données.

Exemple IaaS public connu : Amazon EC2, Windows Azure, RackSpace et CloudWatt.

Le cloud privé est un cloud qui permet de ne pas perdre le contrôle de l'infrastructure et des données tout en améliorant la qualité de service. Ce type de cloud est de plus en plus utilisé dans les grandes entreprises. Cela demande des compétences en interne.

Exemple IaaS privé connu : OpenStack, OpenNebula.

Il y a aussi le cloud hybride qui permet d'utiliser les avantages du cloud privé et du cloud public.

Avec un cloud hybride, une possibilité est de mettre les données sensibles et importantes dans le cloud privé et le reste dans le cloud public. Une autre possibilité dans l'optique de réduire ses coûts d'exploitation est de dimensionner son cloud privé pour une charge moyenne et d'utiliser le cloud public afin d'absorber les surcharges ponctuelles.

OpenStack Présentation

GNU/Linux est né entre deux projets : le noyau Linux créé par Linus Torvalds et des outils systèmes du projet GNU. De la même manière, l'entreprise Rackspace a créé un service de stockage (Swift) et a besoin d'un système pour la gestion de la virtualisation automatique. Des employés de la NASA créent une solution toute trouvée : Nova. Ainsi, en 2010, OpenStack est né de 2 services : Nova et Swift.

OpenStack est sous licence Apache 2.0, licence de logiciel libre. Elle n'est pas Copyleft.

Historique des versions

Avec un rythme de quatre mois puis de six mois, les versions d'OpenStack sont sorties.

En 2011, le service Nova s'est séparé du service de gestion d'image de machine virtuelle pour créer un nouveau service : Glance.

En avril 2012, un nouveau service apparaît : Horizon. C'est l'interface web qui permet de visualiser les différents services d'OpenStack. Par ailleurs Nova se sépare du service d'identification pour créer un nouveau service : Keystone.

En septembre 2012, la gestion réseau de Nova (nova network) commence à prendre beaucoup trop de place. Un nouveau service apparaît : Quantum. Il sera appelé par la suite Neutron. Par ailleurs, la gestion du stockage bloc de Nova explose et un nouveau service naît : Cinder.

En 2013, deux nouveaux services apparaissent : Heat et Ceilometer. Heat est un service de gestion de l'orchestration. Ceilometer est un service de calcul de consommation de chaque client.

En avril 2014, le service Trove apparaît. C'est un service de gestion d'instance de base de données.

En octobre 2014, le service Sahara apparaît. C'est un service dédié au Big Data.

Technologies communes

Tous les services utilisent Python 2.7. Il y a un projet pour porter vers Python 3.

Chaque service utilise une base de données relationnelle. Par défaut, il utilise MySQL mais il est possible d'utiliser une autre base de données. OpenStack utilise comme ORM : SQLAlchemy.

Pour accéder, modifier une ressource, OpenStack utilise l'API REST qui est basée sur HTTP.

Pour la communication entre les services et à l'intérieur des services, OpenStack utilise AMQP. Par défaut, il utilise l'implémentation en Erlang : RabbitMQ.

Les différents composants Nova

Développé à l'origine par la NASA, c'est le cœur d'OpenStack. Il s'occupe principalement de la gestion des hyperviseurs (ordonnanceur et gestion des machines virtuelles) et du contrôle des ressources (CPU, RAM, réseaux et stockages).

Glance

Glance a été extrait rapidement de Nova pour en faire un composant à entière. Il permet la gestion des images de machine virtuelles (découverte, enregistrement, récupération et états des images).

Keystone

Keystone permet la gestion de l'identification. L'utilisation d'un autre composant dépend de Keystone (accréditation).

Neutron

À l'origine ce composant s'appelait Quantum, il permet la gestion du réseau dans OpenStack. Il a des fonctionnalités réseaux avancées (tunneling, QoS, Réseaux virtuels et équilibrage de charge, etc.).

Avec Nova, Neutron est l'élément où le développement est le plus important (voir les statistiques de stackalystics grâce notamment à l'arrivé de Cisco dans le projet.

Swift

Ce composant permet la gestion du stockage objet. Il a été développé avant OpenStack par Rackspace. Il est ainsi indépendant d'OpenStack et est considéré comme le composant le plus stable. Il peut s'utiliser comme frontend avec le composant Glance.

Le stockage objet est une notion bien différente d'un stockage classique qu'on connaît sur les ordinateurs de bureau. Il n'y a pas de notion de montage de partition par exemple. Mais l'avantage principale de ce type de stockage est la disponibilité, la tolérance aux pannes et un agrandissement du stockage à l'infini. En contre-partie, il est considéré moins performant et beaucoup plus compliqué à paramétrer qu'un stockage classique. Un concurrent à Swift que vous connaissez certainement est Ceph.

Cinder

Ce composant permet la gestion du stockage de type bloc.

Ironic

Ironic est un nouveau composant du projet OpenStack. Il permet la gestion du Bare Metal c'est à dire des véritables ordinateurs et non des machines virtuelles. Il s'occupe ainsi le démarrage et l'extinction des ordinateurs. Il va utiliser des technologies comme PXE, TFTP ou IPMI par exemple.

Horizon

Horizon est une interface web pour la gestion d'OpenStack. Il utilise comme framework Django. Il permet ainsi de visualiser les différents composants d'OpenStack et d'agir dessus.

Heat

Heat est le composant d'orchestration d'OpenStack. Il permet par exemple de demander à Nova de démarrer une machine virtuelle supplémentaire en cas de charge importante de façon automatique.

Ceilometer

Ceilometer est le composant de facturation d'OpenStack. Il permet de calculer la consommation (CPU, RAM, données, etc) de chaque client (utile pour créer un cloud public)

Trove

Trove est le composant de provisionnement de bases de données d'OpenStack. Il prend en charge MySQL, PostgreSQL, MongoDB. Depuis kilo, il prend par ailleurs en charge Vertica et Vertica Cluster, DB2 et CouchDB.

Sahara

Sahara est le composant pour le Big Data d'OpenStack. Il permet d'utiliser Hadoop avec OpenStack.

Télécharger ce contenu au format Epub

Lire les commentaires

Loi de finances 2016 en France : des nouvelles du front

4 février, 2016 - 20:43

La loi de finances 2016 en France dispose d’un article 88 qui vise à réglementer le secteur des logiciels d’encaissement.

Citons‐en la partie essentielle :

Lorsqu’elle enregistre les règlements de ses clients au moyen d’un logiciel de comptabilité ou de gestion ou d’un système de caisse, utiliser un logiciel ou un système satisfaisant à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale, attestées par un certificat délivré par un organisme accrédité dans les conditions prévues à l’article L115-28 du code de la consommation ou par une attestation individuelle de l’éditeur, conforme à un modèle fixé par l’administration.

Alerté au début de l’été 2015, votre humble serviteur a entamé depuis octobre 2015 une action vis‐à‐vis de cet article potentiellement nuisible au logiciel libre et qui entrerait en vigueur le 1er janvier 2018.

La coordination principale a lieu sur la liste comptabilite@ de l’April, liste ouverte à tous sans besoin d’adhésion à l’association.

TL;DR

Nous avons été reçus par Infocert, société de certification, et le Gouvernement. Nous avons reçu une écoute attentive. Les problèmes que nous soulevons ont été reconnus comme vrais. Le front est situé autour de la liberté de modification et de la notion d’éditeur d’un logiciel communautaire.

Aucun engagement concret n’a cependant été pris.

Où en étions‐nous ?

La dernière fois que je me suis exprimé en ce lieu, la loi n’était pas votée. Je n’avais rencontré personne, l’action se cantonnant à des contacts téléphoniques avec le cabinet du secrétaire d’État au budget.
Beaucoup des conclusions présentes dans les commentaires, renforcées par des échanges sur la liste comptabilité se sont avérées.

Accélération et préparation

Alerté par du remous sur Internet, le Gouvernement a pris contact. Un échange rapide a conclu à un engagement de rencontre en janvier, engagement qui s’est réalisé.
Je suis également rentré en contact avec Infocert, seul organisme proposant une certification en rapport à cette loi. Il y a eu deux rencontres fin janvier.

Une intervention dans l’Écho des gnous, émission FM sur radio Campus Lille, avait mobilisé la communauté.
Les échanges sur comptabilite@ mais, aussi surprenant que ce soit, également sur LinuxFr.org, ont été productifs.
Un article sur Numerama a donné de la visibilité au sujet, produisant des retours.

Je me suis mis en rapport avec l’April qui, mixé aux analyses juridiques de l’avocate de Scil (éditeur du logiciel Pastèque), a été indispensable sur le plan juridique et politique.

Rencontre avec Infocert

Infocert confirme : la norme Logiciel de gestion et d’encaissement a précédé la loi.

Infocert reconnaît qu’en l’état, les sujets du logiciel libre, du cloud et des tablettes (dans cet ordre) sont à creuser. Infocert a indiqué que la certification serait revue aux lumières des précisions apportées par le Gouvernement autour de la loi.

Infocert invite les acteurs du monde libre à rejoindre son Club Access (ce n’est pas gratuit) afin de débattre du sujet.

Rencontre avec le Gouvernement

L’équipe de l’April et moi‐même avons été reçus au ministère des finances. Les participants du côté de l’État soulignent a minima une considération sérieuse pour le sujet.

Nous venions avec trois points principaux et des sujets connexes.

Les trois points principaux :

  1. Protection des éditeurs de logiciels libres en cas de dévoiement du logiciel par un utilisateur. A priori, ce point est déjà assuré par plusieurs principes juridiques. Pour résumer, un constructeur de vélos ne sera jamais mis en cause pour un problème lié aux bricolages d’une personne sur son vélo.
  2. Protection du droit à modifier un logiciel : la loi ne doit pas empêcher un utilisateur d’apporter des modifications à un logiciel, y compris aux sections concernant les données. Nous avons émis des propositions, elles ont été prises en note.
  3. Proposition de télétransmission des données en temps réel (déclarations TVA, signatures comptables) : cela a été repoussé à après la mise en œuvre de la loi actuelle. Ce point est une manœuvre pour réduire la complexité de la vérification de l’intégrité des données locales dans un environnement logiciel totalement ouvert.

Les sujet connexes :

  • Définition de la notion d’éditeur de logiciel. Rien n’existe dans la loi à ce propos, cela a été reconnu. Ce point est pourtant plein de conséquences pour les projets libres communautaires et, mais on s’en fout, pour les systèmes d’information propriétaires complexes avec plusieurs intervenants.
  • Question du commerce électronique : est‐il concerné ? Si oui, la masse de personnes concernées serait énorme.
  • Retour sur la loi de 2013 de lutte contre la fraude, qui contient des dispositions récusées par l’April.
  • Retour sur le rejet de la priorité au logiciel libre.

Nous n’avons pas abordé la question de la conservation de données privées. Nous passerons le sujet à la Quadrature du Net quand cette dernière aura un peu plus d’air ; l’état d’urgence est toujours l’actualité.

Le Gouvernement lancera prochainement une consultation dans le but de clarifier tous les points flous de la loi d’ici au mois de juin 2016. Nous l’avons invité à le faire en ligne.

Piste bonus

Nous en sommes restés coi : un de nos interlocuteurs, inspecteur général des impôts, nous a dit avoir lu les commentaires de la dépêche LinuxFr.org précédente.

Télécharger ce contenu au format Epub

Lire les commentaires

saloon : débuter simplement une application web avec erlang et angular

4 février, 2016 - 10:41
Le problème des piles pour applications web

Si vous avez déjà cherché à développer une appli web moderne, vous avez déjà dû vous heurter à la question de choisir les bons composants parmi la foultitude de ceux existants… et surtout les faire fonctionner.

Premièrement, quand je parle d'applis web modernes, il faut savoir qu'elles partagent en général cette architecture :

  • un serveur HTTP,
  • un cadriciel pour exposer des API REST,
  • un cadriciel JavaScript pour la partie frontend: il consomme les API REST et met en forme les données en HTML,
  • un système de construction (build), ou plutôt des, la partie serveur et la partie frontend utilisant en général un système différent.

Bref, il fait fonctionner tout cela ensemble, vérifier les incompatibilités, etc.

Les générateurs d'applications yeoman

Le projet yeoman vise à fournir des générateurs d'applications qui intègrent des piles complètes et prêtes à l'emploi dans le domaine des applis web. Même si le projet est issu de la communauté node.js, on peut aisément écrire des générateurs pour n'importe quelle techno.

saloon, faites entrer le cowboy

Le générateur saloon (licence Apache v2) est un générateur yeoman pour débuter simplement une application web avec erlang et angular.

Il intègre les composants suivants:

  • partie serveur:
  • partie frontend:
    • bootstrap pour des composants graphiques pas trop moches,
    • angular.js, le cadriciel bien connu pour faire des applis web dynamiques,
    • Sass pour faciliter l'écriture de CSS,
  • intégration / construction: un projet généré avec saloon est construit avec make et intègre:
    • pour la partie serveur: erlang.mk, l'excellent Makefile pour erlang,
    • pour la partie javascript:
    • Bower pour les dépendances javascript,
    • Grunt pour la partie javascript qui a besoin d'être construite.
Comment se lancer ?

Il vous suffit de lancer yo saloon dans un répertoire vide, puis de lancer make. Vous avez alors une appli prête à l'emploi que vous pouvez modifier / étendre comme bon vous semble. Mais toutes les bases sont là et fonctionnelles.

Télécharger ce contenu au format Epub

Lire les commentaires