Planet Libre-entreprise

July 18, 2016

Azaé

Méga meetup parisien

Nous serons présent au méga-meetup Docker organisé le 19 juillet à la société générale. Après la keynote proposée par Jean-Laurent de Morlhon, nous présenterons à travers les "twelve-factor-apps" les bonnes pratiques pour faire une application scalable et dockerisable.

Après la conf vous retrouverez ici les supports de présentation.


Photo par mau_ry

by Thomas Clavier at July 18, 2016 10:00 PM

April 20, 2016

Scil

Pastèque 7.0 is coming & autres !

On vous fait un petit topo de ce qui s’est passé pour Pastèque ces quatre derniers mois ! En ce qui concerne les avancements techniques On est en train de bosser sur la version 7.0 de pastèque, elle devrait être opérationnelle dans le courant du mois. Mais, vous pouvez utiliser les versions « master » […]

by Morgane at April 20, 2016 02:38 PM

March 10, 2016

Code Lutin

Open Source School - Taxe d'apprentissage

Cette année 2016 voit le lancement de l'Open Source School (http://opensourceschool.fr/), école dédiée à la formation d'ingénieurs spécialisés dans le développement et l'intégration de produits sous licence libre ou open-source.

Afin d'encourager le développement de cette école, nous avons décidé, cette année de verser une partie de notre taxe d'apprentissage à cette école.

by couteau at March 10, 2016 01:52 PM

January 01, 2016

Scil

Pastèque Serveur 6.0.3

Une nouvelle version de Pastèque-Serveur a été publiée. Elle contient une micro-amélioration du CSS pour ceux qui veulent administrer depuis leur téléphone portable Elle peut être téléchargée ici : http://downloads.pasteque.coop/server/

by Philippe at January 01, 2016 10:40 AM

December 01, 2015

Champs Libres

Comparaison des données OpenStreetMap et des données Urbis

Les données Urbis publiées par la Région de Bruxelles capitale ont été intégrée à l'automne 2013 dans la base de donnée d'OpenStreetMap. Cependant, depuis la publication initiale, une nouvelle version a été publiée chaque trimestre. Les mises à jour n'ont pas toujours été intégrée à OSM, par manque d'outils notamment. Cet article explore une méthode pour détecter les bâtiment à mettre à jour dans OpenStreetMap à partir d'une comparaison entre les données d'OpenStreetMap et de celles d'UrbIS.

La première partie de l'article présente la méthode en général, le résultat et les perspectives. La seconde partie de l'article explique les détails techniques.

Présentation de la méthode

Pour ce travail nous allons utiliser PostGIS un extension de PostgreSQL qui permet la manipulation d'informations géographiques.

Les données d'OSM sont téléchargée à partir du service metro extracts de Mapzen. Ce service propose des exports d'OSM à l'échelle des villes. Une fois les données téléchargées, elles sont intégrées à la db via l'outil Osmosis.

Pour les données d'UrbIS. Nous nous sommes intéressés au shapefile UrbAdm_Bu de la suite UrbAdm. Cette suite peut être téléchargée via la page de téléchargement d'UrbIS. Les données sont injectées dans la db via l'outil shp2pgsql qui est fourni avec PostGIS.

Ensuite, nous avons lancé une requête sql sélectionnant les couples de bâtiments d'OpenStreetMap et d'UrbAdm tels que les deux bâtiments s'intersectent et que leur distance d'Hausdorff soit supérieure à 0.0015. De manière simple la distance d'Hausdorff entre deux géométries indique la similirité (ou non) de deux objects géomatriques.

A partir de ce résultat, nous créons un shapefile que JOSM peut ouvrir grâce au plugin OpenData.

Voici le shapefile créé.

Analyse des résultats

La méthode actuelle a détecté 133 polygones qui diffèrent entre OSM et Urbis. Dans beaucoup de cas, il est très dur de dire quel encodage est correct. Mais il semble que de temps en temps OSM est plus précis qu'Urbis.

En creusant l'analyse, il nous semble tout de même que beaucoup de différences ne sont pas détectées. C'est à améliorer.

Améliorations à apporter

Les multi-polygones ne sont pas gérés par la procédure. Pour ce point nous n'avons pas pour l'instant de solution.

Les bâtiments non existants dans OSM ne sont pas non plus détectés par la procédure. Pour détecter ces cas, c'est assez facile à faire : il suffit de créer un énorme multipolygone avec tous les bâtiments d'OSM, si un bâtiment d'UrbIS a une intersection nulle avec ce multipolygone, il ne se trouve pas dans OSM.

Aussi, il faudrait pouvoir automatiser la procédure pour analyser en direct les données d'OSM et ainsi indiquer aux mappeurs les points à régler.

Finalement, dans certains cas, la différence d'encodage peut être discutée longuement. Il serait bon d'avoir un moyen pour signaler que cette différence n'est pas à corriger. Nous pensons que si un bâtiment OSM et un bâtiment Urbis ont le même urbisid et urbisversion, cela peut indiquer qu'ils ont été vérifiés par un mappeur et que les différences sont acceptables.

Explications techniques

Import des données d'OSM dans PostGIS

$ createdb osm_urbis -O gis
$ psql -d osm_urbis -c "CREATE EXTENSION postgis; CREATE EXTENSION hstore;"
$ psql -d osm_urbis -U gis -f /usr/local/Cellar/osmosis/0.44.1/libexec/script/pgsnapshot_schema_0.6.sql 
$ psql -d osm_urbis -U gis -f /usr/local/Cellar/osmosis/0.44.1/libexec/script/pgsnapshot_schema_0.6_linestring.sql
$ osmosis --read-pbf file=/Users/marcu/Downloads/brussels_belgium.osm.pbf --tag-filter accept-ways building=* --tag-filter reject-relations --used-node --write-pgsql database=osm_urbis user=gis password=gis 

Transformation des lignes en polygones

--DROP TABLE osm_buildings CASCADE;

CREATE TABLE osm_buildings
(
    id bigint Not NULL,
    verion integer NOT NULL,
    user_id integer NOT NULL,
    tags hstore,
    polygon geometry(Geometry,4326),
    polygon_shrinked geometry(Geometry,4326),
    CONSTRAINT pk_osm_buildings PRIMARY KEY (id)
);

INSERT INTO osm_buildings 
    SELECT
        w.id, w.version, w.user_id, w.tags,
        ST_MakePolygon(w.linestring),
        ST_Buffer(ST_MakePolygon(w.linestring), -0.00001)
    FROM ways AS w WHERE ST_NumPoints(w.linestring) >= 4 AND ST_IsClosed(w.linestring);

La colonne polygon_shrinked est le polygone du batiment qui a été un peu rétréci. Ces polygones seront utilisés par la suite afin d'être sûr de bien comparer des polygones semblables.

Import des données UrbIS ADM dans PostGIS

$ shp2pgsql -s 31370:4326 Downloads/UrbAdm_21004_SHP/UrbAdm_Bu.shp UrbAdm_Bu | psql -h localhost -d osm_urbis -U gis


$ shp2pgsql -s 31370:4326 Downloads/UrbAdm_SHP/shp/UrbAdm_Re.sh UrbAdm_Re | psql -h localhost -d osm_urbis -U gis

La table UrbAdm_Bu contient les polygones des bâtiments d'UrbIS. La table UrbAdm_Re contient le polygone de la région de Bruxelles. Ce polygone va être utilisé pour ne sélectionner que les bâtiments d'OSM de la région.

Sélection des bâtiments d'OSM se trouvant dans la région de Bruxelles

-- DROP TABLE osm_buildings_RE CASCADE;

CREATE TABLE osm_buildings_RE
(
    id bigint Not NULL,
    verion integer NOT NULL,
    user_id integer NOT NULL,
    tags hstore,
    polygon geometry(Geometry,4326),
    polygon_shrinked geometry(Geometry,4326),
    CONSTRAINT pk_osm_buildings_re PRIMARY KEY (id)
);

INSERT INTO osm_buildings_RE SELECT b.* FROM osm_buildings AS b, UrbAdm_Re 
    WHERE UrbAdm_Re.id = 1
    AND ST_Intersects(b.polygon, UrbAdm_Re.geom);

Créer des index

Sans cette étape tous les polygones de UrbAdm_Bu sont comparés avec tous les polygones de osm_buildings_re et l'algo ne répond pas...

CREATE INDEX index_urbadm_geom  ON UrbAdm_Bu USING GIST (geom);
CREATE INDEX index_osm_b_re_poly  ON osm_buildings_re USING GIST (polygon);
CREATE INDEX index_osm_b_re_poly_shrinked  ON osm_buildings_re USING GIST (polygon_shrinked); 

Calcul des endroits posant problème

-- DROP TABLE results;

CREATE TABLE IF NOT EXISTS results
(
   osm_building geometry(Geometry,4326),
   osm_id bigint,
   osm_tags  hstore,
   urbis_building geometry(MultiPolygon,4326),
   urbis_id integer,
   urbis_versionid integer,
   hausdorff_distance numeric,
   CONSTRAINT pk_results_osm_urbis_id PRIMARY KEY (osm_id, urbis_id)
);

INSERT INTO results
    SELECT
    osm_b.polygon,
    osm_b.id,
    osm_b.tags,
    ua.geom,
    ua.id,
    ua.versionid,
    ST_HausdorffDistance(ST_Transform(ua.geom,4326),ST_Transform(osm_b.polygon,4326)) 
        FROM UrbAdm_Bu AS ua INNER JOIN osm_buildings_re as osm_b
            ON ST_Intersects(ua.geom, osm_b.polygon_shrinked)
            WHERE ST_HausdorffDistance(ua.geom,osm_b.polygon) > 0.0015;

Création du shapefile

Ouvrir la table avec QGIS et l'exporter en shapefile.

by Champs-Libres at December 01, 2015 08:00 PM

November 03, 2015

Code Lutin

Paris Open Source Summit 2015

Code Lutin sera présent au Paris Open Source Summit les 18 et 19 novembre aux Docks Pullman.

Venez nous rendre visite sur le stand Libre Entreprise (B18-B20).

Pour en savoir plus sur l'événement vous pouvez visionner la vidéo de présentation ou vous rendre sur le site du POSS.

by couteau at November 03, 2015 02:26 PM

October 16, 2015

Scil

Projet de loi de finances 2016

Le gouvernement français dans son projet de loi de finances 2016 continue son action de lutte contre contre la fraude fiscale, entamé avec la loi du 6 décembre 2013 Après des échanges sur LinuxFR.org et sur la liste de diffusion de l’April, et avoir creusé le sujet, on en arrive à Scil à la conclusion […]

by Philippe at October 16, 2015 12:39 PM

October 14, 2015

Code Lutin

Code Lutin recrute

Code Lutin grandit et recrute un développeur Java/Javascript. Vous pouvez retrouver notre offre sur la page recrutement

by couteau at October 14, 2015 01:56 PM

October 07, 2015

Scil

Publication de Pastèque 6, alias Fraise

Pastèque est une suite logicielle prévue pour gérer des points de vente. La nouvelle version de Pastèque, Pastèque 6 alias Fraise, a été mise en ligne il y a une paire de jours, après deux mois de tests. Cette nouvelle version est un grand pas pour une solution de caisse basée sur Android. Alors qu’est-ce […]

by Philippe at October 07, 2015 06:00 PM

September 09, 2015

Code Lutin

RRLL 2015

Code Lutin sera présent aux Rencontres Régionales du Logiciel Libre le 24 septembre à l'EMC à Nantes, un événement au programme de Nantes Digital Week.

Conférences, tables rondes et ateliers, l'événement est gratuit et ouvert à tous les professionnels. Vous pouvez d'ors et déjà vous inscrire pour obtenir votre badge d'accès (attention, les ateliers sont presque complets).

Vous pouvez retrouver le programme détaillé sur le site de l'événement (rrll.alliance-libre.org).

Un cocktail déjeunatoire sera proposé le midi afin de pouvoir échanger ensemble sur les différents contenus proposés lors d'un moment plus informel.

N'hésitez plus, rejoignez-nous !

by couteau at September 09, 2015 01:36 PM

August 18, 2015

Champs Libres

Ajouter une IP failover à un container LXC

Dans un précédent post nous expliquions comment attribuer une IP failover achetée chez OVH vers une machine virtuelle exécutée par l'hyperviseur KVM. Il est également possible d'associer l'IP au conteneur LXC, ce que nous proposons d'expliquer ici.

La configuration a lieu en deux étapes :

  • d'abord, configurer un bridge sur la machine hôte. Cette opération n'est, évidemment, à exécuter que lors de la première installation ;
  • ensuite, manipuler le fichier de configuration du conteneur pour qu'il crée une interface réseau qui ira se connecter au réseau OVH, via le bridge. Cette opération est à répéter pour chaque conteneur LXC.

Nous assumons que:

  • vous possédez une adresse IP Failover chez OVH ;
  • et que vous avez créé une adresse MAC virtuelle via l'interface d'administration du fournisseur.

Créer le bridge sur la machine hôte

Pour cela, éditer le fichier /etc/network/interfaces :

(conseil: sauvegardez le fichier d'origine avant toute modification ! Une mauvaise configuration peut faire perdre l'accès réseau au serveur, et, partant, toute possibilité de connexion via ssh. Si vous êtes dans le cas, vous devrez redémarrer le serveur en mode rescue et corriger la configuration.)

Dans l'exemple ci-dessous, l'IP de l'hôte est 94.23.44.XXX. Vous pouvez déterminer l'adresse de broadcast telle que décrit dans ce guide. Il suffit de remplacer les trois derniers chiffre de l'adresse IP de l'hôte par 254.

Voici ce vers quoi vous devriez arriver sur la machine hôte:

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet manual

iface eth0 inet6 manual

auto br0 
iface br0 inet static
        address 94.23.44.XX
        netmask 255.255.255.0
        network 94.23.44.0
        broadcast 94.23.44.255
        gateway 94.23.44.254
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridg_maxwait 0

iface br0 inet6 static
        address 2001:41D0:2:2D88::1
        netmask 64
        post-up /sbin/ip -f inet6 route add 2001:41D0:2:2Dff:ff:ff:ff:ff dev eth0
        post-up /sbin/ip -f inet6 route add default via 2001:41D0:2:2Dff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del default via 2001:41D0:2:2Dff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del 2001:41D0:2:2Dff:ff:ff:ff:ff dev eth0

Ceci fait, il est normalement possible de redémarrer le réseau sans quitter la console : service networking restart (en mode root). La machine doit continuer à répondre au ping.

La commande ifconfig doit renvoyer ceci :

br0       Link encap:Ethernet  HWaddr 74:d0:2b:26:be:82  
          inet addr:94.23.44.XXX  Bcast:94.23.44.255  Mask:255.255.255.0
          inet6 addr: 2001:41d0:2:2d88::1/64 Scope:Global
          inet6 addr: fe80::76d0:2bff:fe26:be82/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10158 errors:0 dropped:1 overruns:0 frame:0
          TX packets:10651 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1285075 (1.2 MB)  TX bytes:2848337 (2.8 MB)

eth0      Link encap:Ethernet  HWaddr 74:d0:2b:26:be:82  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11366 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11679 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1613287 (1.6 MB)  TX bytes:2998767 (2.9 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:5606 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5606 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:862871 (862.8 KB)  TX bytes:862871 (862.8 KB)

Créer et configurer le container LXC

Vous pouvez créer un container LXC suivant la démarche habituelle, avec la commande lxc-create. Cela aboutira à la création d'un container et... d'un fichier de configuration. C'est ce fichier qui va nous intéresser. Sous Ubuntu, le fichier de configuration d'un container créé sous l'utilisateur root est sité dans le répertoir /var/lib/lxc/<nom du conteneur>/config.

Dans l'exemple suivant, l'adresse IP failover est 87.98.253.aaa. Le fichier est à modifier comme suit (voir les commentaires) :

# Les premières options et en-têtes sont omises ici


# Network configuration
# ici est configuré un accès au réseau interne, qui permet aux containers de se connecter entre eux.
# Vous pouvez éventuellement la supprimer (jamais essayé)
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:55:52:55

# ici le fichier est modifié :

# on donne un nom à la première interface (celle pour le réseau interne)
lxc.network.name = eth0
# on donne un nom à l'interface telle qu'elle apparait depuis l'hôte
lxc.network.veth.pair = vethVMMailpriv

# on crée une seconde interface :
lxc.network.type= veth
lxc.network.flags = up
# cette interface va se connecter au bridge créé sur l'ĥôte:
lxc.network.link = br0
# on donne un nom à cette seconde interface :
lxc.network.name = eth1
# on attribue directement l'adresse IP failover
# la notation est importante: elle prend la forme ip/masque broadcast (ici l'adresse de broadcast est la même que l'adresse IP)
lxc.network.ipv4 = 87.98.253.aaa/32 87.98.253.aaa
# on indique également l'adresse MAC virtuelle générée par l'interface admin d'OVH:
lxc.network.hwaddr = 02:00:00:fb:8a:ef
# on indique un nom pour qu'elle soit évidente dans l'hôte
lxc.network.veth.pair = vethVMMailpub
# et on renseigne la gateway de la machine virtuelle, qui est la même que celle de l'hôte:
lxc.network.ipv4.gateway = 37.59.6.254

Il n'est pas nécessaire de modifier le fichier /etc/network/interfaces à l'intérieur du container. Si cela est fait, cela ne pose pas de problème particulier. Par contre, il ne faut pas omettre d'ajouter la configuration réseau au fichier de configuration du conteneur (le fichier config). En cas d'omission, le réseau est instable: il semble que parfois le conteneur suit son propre fichier de configuration (/etc/network/interfaces), parfois la machine hôte supprime la configuration créée à l'intérieur du conteneur, et l'accès à internet est perdu depuis le conteneur.

Si vous désirez ajouter des routes supplémentaires au démarrage de l'interface, il est possible de les ajouter au container :

  • directement dans le fichier /etc/network/interfaces du container (via la commande post-up)
  • via le fichier de configuration, en utilisant l'option lxc.network.script.up et lxc.network.script.down telle que décrite dans la documentaiton du fichier de configuration.

Effet sur l'hôte

Après le démarrage du container, la commande ifconfig devrait indiquer les nouvelles interfaces publiques et privée du container :

br0       Link encap:Ethernet  HWaddr 00:25:90:71:xx:xx  
          inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6899848 errors:0 dropped:7548 overruns:0 frame:0
          TX packets:5993110 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1423848105 (1.4 GB)  TX bytes:685448492 (685.4 MB)

eth0      Link encap:Ethernet  HWaddr 00:25:90:71:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38346657 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27003050 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7598557003 (7.5 GB)  TX bytes:10480865550 (10.4 GB)
          Interrupt:16 Memory:fbce0000-fbd00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2326626 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2326626 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:320451368 (320.4 MB)  TX bytes:320451368 (320.4 MB)

lxcbr0    Link encap:Ethernet  HWaddr fe:12:6f:93:75:6c  
          inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::509e:33ff:fe1c:b0f5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2293856 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2226704 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:182953795 (182.9 MB)  TX bytes:460284425 (460.2 MB)

vethVMMailpriv Link encap:Ethernet  HWaddr fe:1e:61:76:89:55  
          inet6 addr: fe80::fc1e:61ff:fe76:8955/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2109538 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1986346 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:426540050 (426.5 MB)  TX bytes:343043225 (343.0 MB)

vethVMMailpub Link encap:Ethernet  HWaddr fe:59:f4:31:xx:xx  
          inet6 addr: fe80::fc59:f4ff:fe31:222b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8697094 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39146399 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6831530014 (6.8 GB)  TX bytes:8189090228 (8.1 GB)

by Champs-Libres at August 18, 2015 03:00 PM

July 22, 2015

Champs Libres

Le logiciel Chill pré-sélectionné pour le prix de l'innovation sociale

Le logiciel Chill a été pré-sélectionné pour le prix de l'innovation sociale 2015, organisé par l'unipso. Votez pour notre projet et aidez-nous à faire parties des 3 lauréats du Prix Innovation Sociale 2015.

Le Prix Innovation Sociale est organisé par l’UNIPSO afin de soutenir, encourager et dynamiser l’innovation sociale.

Pour cette édition 2015, notre projet "Chill, logiciel libre d'accompagnement social" a été sélectionné parmi les 20 finalistes du Prix Innovation Sociale ! Il s’agit déjà d’une reconnaissance importante pour le logiciel, qui témoigne de son utilité sociale et qui va nous permettre de continuer à le développer via une formation adaptée à nos besoins.

Votez pour le projet

Mais le Prix Innovation Sociale ne s’arrête pas là et c’est pour cela qu’on a besoin de vous ! Le 27 novembre, lors de la remise des Prix officielle, 3 prix de 10.000€, 5.000€ et 2.500€ seront attribués aux projets lauréats, désignés sur base d’un classement tenant compte du vote des internautes (25%) et d’un jury indépendant (75%). Les 3 entreprises lauréates profiteront également d’un accompagnement personnalisé afin de développer leur projet d’innovation sociale.

Vous souhaitez nous aider à faire partie de ces 3 lauréats ?

Rien de plus simple ! Rendez-vous sur www.prixinnovationsociale.be avant le 30 septembre 2015 et votez pour notre projet "Chill, logiciel libre d'accompagnement social" en remplissant le formulaire de vote prévu à cet effet. Attention, vous n’avez le droit de voter qu’une fois et pour un seul projet !

D’avance un grand merci pour votre soutien, et surtout n’hésitez pas à partager l’info !

by Champs-Libres at July 22, 2015 07:00 PM

July 11, 2015

Champs Libres

Formation UDOS 2015

Champs-Libres a eu l'honneur d'être invité à dispenser une formation lors de la première édition d'UDOS, Universite d'Été du Développement de logiciels libres et Open Source.

Deux ateliers ont été dispensés et, fidèle à notre engagement, nous publions les ressources utilisées en formation :

L'organisation d'UDOS à Digne-Les-Bains permet également de découvrir l'environnement de la ville, agréable et ensoleillée, ce qui ne peut, évidemment, qu'enjoliver encore la qualité de l'organisation de l'événement.

by Champs-Libres at July 11, 2015 03:00 PM

June 29, 2015

Code Lutin

SAS Capital variable

Code Lutin vient de passer officiellement du statut de SARL à celui de SAS à capital variable.

Cela ne change strictement rien pour nos clients et toutes celles et ceux qui nous suivent, mais cela nous permet d’officialiser des fonctionnements que nous avions en interne puisque, par-exemple, désormais tous les salariés font maintenant partie du comité de direction qui élit le président de la société.

Cela nous permet également de faire participer plus facilement tous les salariés au capital de la société.

by couteau at June 29, 2015 01:26 PM

June 15, 2015

Azaé

Le fichier Deliverous

Le fichier Deliverous est le fichier de configuration utilisé par notre service, il est au format yaml et décrit l'ensemble des conteneurs ainsi que leurs relations.

Pour définir un conteneur, il suffit de le nommer en début de ligne, par exemple pour un conteneur que l'on appelle "front" :

front:
  clé1: valeur1
  clé2: valeur2

Certaines clés demandent simplement une valeur, d'autres, une liste de valeurs, voir même une liste de sous-clés et de valeurs. Par exemple :

front:
  clé1: valeur1
  clé2:
  - sous_clé1 : valeur2
  - sous_clé2 : valeur3

Voici en détail et par ordre alphabétique la liste de toutes les directives qu'il est possible de spécifier.

command

Définit la commande à exécuter. Cette valeur est ajoutée à la fin de la commande 'docker run'

Exemple:

front:
  image: deliverous/container
  command: --start --front 1.2.3.4

Dans cet exemple, le conteneur sera démarré avec docker run deliverous/container --start --front 1.2.3.4

deploy_conflict

Définit une restriction de déploiement, permet de s'assurer que 2 conteneurs seront déployés sur des machines physiques différentes.

Exemple:

front1:
  image: deliverous/blog
  deploy_conflict:
  - front2
front2:
  image: deliverous/blog

deploy_with

Définit une affinité de déploiement, permet de s'assurer que 2 conteneurs seront déployés sur la même machine physique.

Exemple:

front:
  image: deliverous/container
  deploy_with:
  - mysql
mysql
  image: mysql

dns

Définit un serveur DNS spécifique pour le conteneur. Correspond à l'option --dns de docker run

Exemple:

front:
  image: deliverous/blog
  dns:
  - 127.0.0.1

Dans cet exemple, le conteneur sera démarré avec docker run --dns=127.0.0.1 deliverous/blog. Cette option en plus de l'installation d'un serveur dnsmasq à l'intérieur du conteneur permet entre autres de résoudre les problèmes de modification du fichier /etc/hosts par le conteneur lui-même.

entrypoint

Définition du point d'entré. Cette valeur sera donnée à l'option --entrypoint de docker run

Exemple:

front:
  image: deliverous/container
  entrypoint: /usr/local/bin/debug

Dans cet exemple, le conteneur sera démarré avec docker run --entrypoint /usr/local/bin/debug deliverous/container.

environment

Permet de définir des variables d'environnement par une liste de clés valeur.

Exemple:

front:
  image: deliverous/blog
  environment:
    DB_NAME: blogdb
    DB_USER: blog
    ENVIRONEMENT: prod

hostname

Définit le nom réseau du conteneur, correspond à l'option --hostname de la ligne de commande

Exemple:

front:
  image: deliverous/container
  hostname: toto

Dans cet exemple, le conteneur sera démarré avec docker run --hostname=toto deliverous/container.

image

Définition du nom de l'image Docker à utiliser. C'est la seule clé obligatoire. Le nom doit correspondre à un tag complètement qualifié, par exemple "deliverous/blog" pour une image hébergé sur le hub Docker ou "registry.company.com/user/image" pour une image hébergé sur votre propre registry.

front:
  image: deliverous/blog

limits

Définition des limites du conteneur. Pour l'instant, il n'est possible de limiter que la mémoire. C'est la directive memory: <limit><unité> avec unité qui peut prendre une des valeurs b, k, m ou g.

Sans définition, les limites sont les suivantes:

  • memory: 4G

Exemple:

front:
  image: deliverous/blog
  limits:
    memory: 1G

links

Définition des liens entre les conteneurs avec une liste de lien. Chaque lien doit avoir une valeur name qui référence un autre conteneur et une valuer alias qui lui donnera son nom dans ce conteneur.

Exemple:

front:
  image: deliverous/container
  links:
  - name: mysql
    alias: db
mysql:
  image: mysql

Dans cet exemple, le conteneur 'front' demande à être lié au conteneur mysql qu'il nommera 'db'.

monitor

ports

Définitions de la configuration réseau. Permet d'appliquer des règles de routage sur les conteneurs. Par exemple :

front:
  image: deliverous/blog
  ports:
  - ip: blog.deliverous.com
    container_port: 8080
    host_port: 80

Dans cet exemple, alors que le conteneur expose le port 8080, le conteneur front sera accessible sur le port 80 de l'adresse IP blog.deliverous.com (c'est le nom qui lui a été donné dans le manager). Il est possible de définir l'ip soit par son nom, soit par l'ip elle-même.

snat

Permet de spécifier l'adresse source qui sera utilisé pour toutes les connections sortante du conteneur. Comme pour l'option 'ports' il est possible de définir l'ip soit par son nom, soit par l'ip elle-même.

Exemple:

front:
  image: deliverous/smtp
  snat: 1.2.3.4

volumes

Permet de définir des volumes pour persister les données à l'extérieur du conteneur. Je vous invite à lire l'article détaillé sur les volumes pour en savoir plus sur ce que nous avons mis en place. Si vous souhaitez en apprendre plus sur ce que les volumes peuvent apporter, alors je vous conseille la lecture de cette série d'articles : Les uploads

Exemple:

demo:
  image: deliverous/blog
  volumes:
  - name: photos
    path: /srv/photos

by Thomas Clavier at June 15, 2015 10:00 PM

June 10, 2015

Champs Libres

Linux Containers: changer le mot de passe d'un conteneur

Perdre le mot de passe root d'un conteneur LXC: voilà quelque chose qui peut arriver,surtout lorsque vous veillez à choisir un mot de passe unique pour chacune des machines que vous gérer.

Une recherche sur internet vous aura sans doute proposé différentes démarches pour le retrouver. Les principaux tutoriels indiquent une marche à suivre très simple: redémarrer en runlevel 1, ce qui permet de changer le mot de passe sans en connaitre l'ancien.

Mais problème: lorsqu'un conteneur lxc est démarré, il n'y a pas de grub, et pas de moyen simple de changer le runlevel. Par contre, il est possible d'accéder au système de fichiers directement depuis la machine hôte.

EDIT: Nicolas K. indique un moyen beaucoup plus simple que celui décrit initialement dans ce post: la commande lxc-attach permet de se placer en root dans le conteneur. À partir de là, il suffit de lancer la commande passwd.

Dès lors, il est possible d'avoir accès au fichier /etc/shadow, qui contient les mots de passe. Il devrait indiquer ceci :

root:*:16470:0:99999:7:::
# ...
ubuntu:$6$LongueSuiteDeChiffresEtLettres:16532:0:99999:7:::

Le fichier doit être lu en séparant les :. La première chaine de caractère avant le : est le nom de l'utilisateur, puis le mot de passe, encrypté.

Mais, par quoi le remplacer ? A moins de ne pouvoir réaliser un cryptage correct - pas impossible, mais il existe une méthode plus simple... - il suffit de le remplacer par une chaine vide, comme ceci :

ubuntu::16532:0:99999:7:::

Puis, se connecter avec l'utilisateur ubuntu - nous le réalisons par clé ssh, mais cela doit être possible également avec la commande lxc-console - puis de lancer la commande passwd pour indiquer un nouveau mot de passe.

by Champs-Libres at June 10, 2015 03:00 PM

Scil

Facebook mise sur beacon pour se connecter aux commerçants

Un article du blog SiliconValley du monde.fr relate l’information : Facebook veut connecter ses utilisateurs avec les commerçants. (…) il a annoncé l’extension de son service Place Tips(…). Il va même leur offrir des beacons, des petits capteurs sans fil à basse consommation d’énergie qui peuvent communiquer avec les smartphones des personnes présentes à proximité. Source : http://siliconvalley.blog.lemonde.fr/2015/06/10/facebook-parie-sur-les-beacons-pour-connecter-ses-utilisateurs-avec-les-commercants/ Scil, […]

by Philippe at June 10, 2015 05:57 AM

June 05, 2015

Scil

Sauvegardes de la base de données

Une nouvelle fonctionnalité dans la version 5.1 permet la sauvegarde de la base de données. Cet export est utile pour des fins de sauvegarde et pour la migration éventuelle de vos données, par exemple après avoir testé sur my.pasteque.coop pour migrer sur votre propre serveur auto-hébergé Cette fonctionnalité est accessible depuis la section du menu […]

by Philippe at June 05, 2015 10:15 AM

June 01, 2015

Champs Libres

Champs-Libres accepte les valeureux liégeois

Billet de valeureuxChamps-Libres accepte désormais les paiements en Valeureux, le "bon de soutien à l'économie locale" (parfois également appelé "monnaie alternative").

Nous sommes fiers de pouvoir ainsi contribuer à l'économie locale et à l'établissement de circuits courts, et faire émerger la nécessaire transition économie, écologique et sociale. Les valeurs portées par le Valeureux rejoignent celle de Champs-Libres, et que nous portons en développant le logiciel libre.

Plus d'informations: http://valeureux.be.

by Champs-Libres at June 01, 2015 03:00 PM

May 07, 2015

Scil

Projet loi renseignement : quelles conséquences pour Pastèque ?

Le gouvernement français a voté cette semaine son projet de loi controversé sur le renseigement, ouvrant une surveillance massive d’internet. À ce propos, nous vous recomandons de lire le site « ni pigeons ni espions » Qu’est-ce que cette loi change pour l’hébergement gratuit Pastèque ? Le gouvernement français peut à présent espionner des données […]

by Philippe at May 07, 2015 07:52 AM

April 13, 2015

Scil

Pastèque server 5.1 : what’s new ?

Pastèque server version 5.1 has been released today. It includes a few new features that were requested during the last months We now have a landing page after login. The blank page time is over ! :-) There is a backup-module that allow users to make their manual backups. Users of https://my.pasteque.coop can activate it […]

by Philippe at April 13, 2015 03:14 PM

April 10, 2015

Champs Libres

Créer une carte pour les cyclistes avec QGIS et les données d'OpenStreetMap

Dans ce tutoriel nous allons expliquer comment créer une carte avec l'outil QGIS et les données d'OpenStreetMap. Mais ce ne sera pas une simple carte : nous allons créer une carte cycliste, mettant en avant les aménagements cyclables.

Pour cet article nous nous sommes inspirés d'un article d'Anita Graser ainsi que d'une vidéo de Steven Bernard.

Pour la création de la carte, des styles sont fournis. Ils sont actuellement adaptés pour l'échelle 1:2000.

OpenStreetMap

OpenStreetMap est l'équivalent de wikipédia dans le monde des données cartographiques : toute personne (respectant les règles établies) peut y ajouter et mettre à jour les données. Cela a un énorme avantage : si vous exploitez ces données et que vous vous rendez compte qu'elles ne sont pas à jour, vous pouvez le faire.

De plus, comme certains cyclistes participent activement au projet, il a été prévu d'encoder les aménagements cyclables. Par exemple dans la documentation qui explique comment encoder les données, une page est dédiée au vélo et explique comment encoder un sens unique limité (SUL), une bande de bus partagée, ...

QGIS : présentation et installation

Quantum GIS (QGIS) est un logiciel libre de SIG (système d'information géographique). Il permet d'analyser, de traiter et présenter tous les types de données spatiales et géographiques.

Pour installer QGIS sur MacOS, nous vous conseillons d'utiliser homebrew avec les formules osgeo/osgeo4mac. Pour les autres OS, le site officiel de QGIS indique des méthodes pour l'installer. Veuillez installer la dernière version.

Pour ce tutoriel, vous devez aussi installer les plugins OpenLayers Plugin et Quick OSM. Ceci se fait de la manière suivante : allez dans le menu Plugins, cliquez sur Manage and Install Plugins....

Copie d'écran du menu menant à la gestion des plugins

Dans la fenêtre qui apparaît, recherchez (OpenLayers Plugin, QuickOSM) et installez les deux plugins.

Copie d'écran de l'installation du plugin QuickOSM

Téléchargement des données OSM

Nous devons délimiter la zone où télécharger les données. Pour cela, nous allons afficher un fond de carte et zoomer sur la zone qui nous intéresse. Pour afficher le fond de carte, allez dans le menu Web, cliquez sur OpenLayers plugin, ensuite sur OpenStreetMap et finalement sur OpenStreetMap.

Copie d'écran du chargement d'OpenStreetMap

Une fois le fond de carte affiché, zoomez sur la zone dont vous voulez télécharger les données (utilisez l'outil de zoom). La zone affichée sera la zone utilisée pour télécharger les données OSM. Pour ce tutoriel, nous avons sélectionné la ville de Mons (il faut prévoir une zone tampon autour de la zone que vous voulez cartographier).

Copie d'écran du zoom sur Mons

Maintenant nous pouvons télécharger les données OSM : allez dans le menu Vector, ensuite dans le sous-menu OpenStreepMap et cliquez sur Download Data....

Copie d'écran du menu menant au téléchargement des données OSM

Une fenête apparaît. Choisissez les options From map canvas (c'est à dire selon la zone affichée), l'endoit où sauvegarder les donnés et cliquez sur OK. Félicitations, vous avez téléchargé les données OSM !

Copie d'écran de l'écran de téléchargement des données pour Mons

Vous pouvez supprimer la couche Openlayers. Pour cela effectuez un clic droit sur la couche OpenStreetMap et sélectionnez l'option Remove.

Copie d'écran de l'écran de la suppression de la couche `OpenLayers`

Import des données dans QGIS

Pour importer les données d'OSM dans QGIS, ouvrez l'outil QuickOSM : cliquez sur le menu Web, puis sur QuickSOSM.

Copie d'écran de l'ouverture de QuickOSM

Dans l'onglet OSM File, renseignez l'endroit où se trouve les données. Choisissez d'importer les Lines et les Multipolygons, sélectionnez l'option OSMConf et cliquez sur Open. Une fois l'import fini, fermez la fenêtre. Les données brutes sont affichées. Il ne vous reste plus qu'à mettre les données en forme pour obtenir la carte.

Copie d'écran de avec les données brutes

Mise en forme des données

Pour cette étape, veuillez télécharger les styles que nous avons préparés et mis à disposition sur github. Ensuite, pour chaque couche, veuillez charger le style qui lui est dédié : double-cliquez sur le titre de la couche, la fenêtre layer properties apparaît, sélectionnez l'onglet Style, cliquez sur le bouton Style et choisissez Load Style. Utilisez style-for-multipolygons.qml pour la couche Mons.osm.multipolygons et style-for-lines.qml pour la couche Mons.osm.lines.

Pour ce style, veuillez choisir l'échelle 1:2000. De plus, mettez la couche Mons.osm.lines au dessus de la couche Mons.osm.multipolygons en faisant un glisser-déposer.

Copie d'écran de avec les données brutes

Sur la carte certains aménagements cyclabes sont mis en évidence. Le style le fait automatiquement si l'aménagement est renseigné dans OpenStreetMap. Ici vous pouvez voir les SUL (triangles verts - rue de Nimy) et les bandes cyclables à droite de la chaussée (pointillés verts - rue des Arbalestriers).

Export de la carte

Afin de transformer la carte en PDF, vous devez utiliser le composeur de cartes. Pour le charger, allez dans le menu Project et cliquez sur New Print Composer.

Copie d'écran du menu New Print Composer

Dans le menu vertical gauche du composer, cliquez sur Add new map.

Copie d'écran du menu Add a new map

Dessinez un rectangle sur l'entièreté de la zone blanche du composer.

Dessin d'un rectangle dans le composer

Une fois le rectangle dessiné, la carte y apparaîtra.

Copie d'écran du composer avec la carte

Choisissez l'échelle (ici elle est de 1:2588) et cliquez dans le menu du haut sur l'icône pdf afin de le générer et l'obtenir.

Actuellement le style ne fonctionne que pour une échelle proche de 1:2000 et seuls les SUL et les bandes cyclables sont mis en avant. Ce n'est qu'un début : nous avons l'intention de l'améliorer. Si vous avez envie de nous aidez dites le nous !

Références

Pour cet article nous nous sommes inspirés d'un article d'Anita Graser ainsi que d'une vidéo de Steven Bernard.

by Champs-Libres at April 10, 2015 03:00 PM

April 09, 2015

Code Lutin

Devoxx France 2015

Code Lutin est, de nouveau, présent au Devoxx France cette année. Retrouvez Éric et Sylvain dans les allées.

Read or add comments to this article

by couteau at April 09, 2015 03:41 PM

March 27, 2015

Azaé

Vous avez dit contextes ?

Dans cet article, le second de la série sur les volumes, je vais aborder un nouvel usage des volumes, la création de contextes séparés. En effet, avoir un nom de répertoire différent entre l'intérieur et l'extérieur du conteneur peut apporter un certain nombre d'avantages.

Séparation de logs

Prenons l'exemple d'un conteneur avec une application qui log tout dans /var/log/app/ avec les options de montage des volumes il est possible de lancer 3 fois cette même application et de sauver les fichiers générés dans 3 répertoires différents :

docker run -v /data/logs/app1:/var/log/app --name app1 conteneur
docker run -v /data/logs/app2:/var/log/app --name app2 conteneur
docker run -v /data/logs/app3:/var/log/app --name app3 conteneur

C'est par exemple utilisé pour sauvegarder les logs d'une application que l'on doit démultiplier pour faire face à la charge.

Pour une bonne analyse, il faudra, à intervalle régulier, collecter l'ensemble des fichiers. La centralisation de ces logs en continu dans un moteur dédié serait probablement plus efficace, mais un peu plus complexe à mettre en œuvre.

Certains vont faire remarquer qu'il est possible de lancer l'application de cette façon :

docker run -v /data/logs:/var/log/app --name app1 conteneur
docker run -v /data/logs:/var/log/app --name app2 conteneur
docker run -v /data/logs:/var/log/app --name app3 conteneur

Mais attention, il est peut probable que notre application lancée 3 fois arrive à gérer correctement l'accès concurrent aux mêmes fichiers de logs. Des applications comme Tomcat ou WebLogic ouvrent les fichiers au démarrage et écrivent dedans en continue en supposant être les seules au monde. De plus, en centralisant de cette façon on retombe sur le problème de système de fichiers partagé, abordé dans l'article précédent.

Contextes clients

Monter un répertoire différent pour plusieurs conteneurs identique peut aussi être utilisé pour différencier différentes instances d'un même conteneur. Prenons l'exemple d'une application qui lit et écrit l'ensemble de ses données applicatives dans /home/application. Il est possible de dédier chaque instance à un usage donné.

docker run -v /data/client1:/home/application --name app1 conteneur
docker run -v /data/client2:/home/application --name app2 conteneur

Avec cette configuration, chaque conteneur va pouvoir vivre sa vie avec ses propres données. Plus besoins de loadbalancer devant pour agréger le trafic vers les 2 conteneurs, mais 2 URLs différents pour accéder à 2 contextes clients différents. On peut imaginer que pour utiliser "app1" il faut visiter http://client1.app.com et pour se retrouver sur app2 http://client2.app.com. C'est un bon moyen de cloisonner les clients sans trop d'efforts, mais attention, si le nombre de clients est trop grand, la gestion des multiples conteneurs risque fort d'être périlleuse.

Conclusion

Dans le cas d'une multiplication de conteneur pour faire face à une augmentation de charge, il est possible de rapidement démultiplier les répertoires de logs, mais l'usage d'un serveur de centralisation à base de Logstash sera probablement bien plus générateur de valeur.

Dans le cadre d'une séparation de clients, il est important de regarder le nombre de contextes à réaliser avant de choisir une solution à base de volumes.


Photo par Ricky Artigas

by Thomas Clavier at March 27, 2015 11:00 PM

March 23, 2015

Code Lutin

RMLL2015 - Premier sponsor

L'édition 2015 des Rencontres Mondiales du Logiciel Libre aura lieu du 4 au 10 Juillet 2015 à Beauvais.

Comme chaque année, Code Lutin encourage l'événement en le sponsorisant. Cette année, nous sommes même le premier sponsor (https://2015.rmll.info/nouvelles-des-preparatifs-de-l-edition-2015).

Rendez-vous cet été !

by couteau at March 23, 2015 07:41 AM

March 11, 2015

Azaé

Vous avez dit volumes ?

À défaut de pouvoir vous apporter une réponse unique à la question : Quelles sont les bonnes pratiques avec les volumes ? À travers cette série d'articles, je propose de vous apporter quelques pistes de réflexions.

Le premier cas d'utilisation que nous aborderons ici concerne les uploads utilisateurs. Le second explore la notion de contextes.

Une histoire d'upload

Imaginons une application qui sauvegarde ses données utilisateurs dans un répertoire local, c'est le cas le plus classique. Wordpress, Magento et bien d'autres sauvegardent certains fichiers téléversés par les utilisateurs dans un répertoire du système de fichier. Ces fichiers sont des données applicatives, impossible de les laisser dans le conteneur. D'autant plus si ces données doivent être partagées entre plusieurs conteneurs.

La solution technique la plus évidente pour répondre à ce besoin, c'est d'avoir un système de fichier partagé à travers le réseau.

Seulement, sans passer par des technologies spécifiques et probablement onéreuses (agrégation de flux réseaux, fiber channel, ceph, Réseau de stockage spécialisé, ...) le passage à l'échelle d'un filesystème partagé pose problème. L'équilibre entre la taille du système et le coût de mise en œuvre est fragile, sans parler de certains paliers qui impliquent des changements de technologie très onéreux.

La majorité des plateformes de cloud ont résolue ce problème en mettant en avant des solutions beaucoup plus scalable comme du stockage clé/valeur. Par exemple, chez Amazon, il est impossible d'avoir ce genre de service sans monter son propre cluster dédié à ce service, en revanche, il est possible d'utiliser S3 pour sauver ses données.

Le problème est donc le suivant : une plateforme de PAAS ne peut pas proposer un système de fichier partagé efficace et scalable à volonté qui soit simple et efficace. Si vous souhaitez garder la possibilité d'utiliser ce genre de plateforme, il faut respecter le point 6 des 12 factors apps. Pour partager des éléments entre processus, on utilise une ressource distante à travers le réseau et c'est encore mieux si c'est en utilisant des connections non-persistante.

Voici donc quelques solution pratique qu'il est possible de mettre en place pour faire un stockage déporté de vos uploads.

Un serveur CDN

Monter son propre CDN, je devrais plus dire : monter un conteneur de statiques. L'idée, c'est de monter un conteneur qui distribuera à vos clients l'ensemble de vos statiques. Le premier avantage sera de pouvoir configurer ce conteneur pour ne pas avoir de session et imposer à vos clients la mise en cache des statiques. Un bon moyen pour optimiser les performances de votre site sans avoir à payer les services d'un réel CDN, et si vraiment vous avez besoins d'un CDN, rien n'empêchera de mettre la totalité de ce nouveau domaine derrière un CDN comme cloudflare. Ce conteneur de statiques pourra quand à lui enregistrer ses données sur un volume, il sera en effet le seul à accéder aux fichiers d'uploads.

Schéma CDN

Avec ce nouveau conteneur, le client va uploader son image sur 1 des conteneurs applicatifs, une fois l'upload terminé, l'application va déplacer l'image en ftp sur le serveur de statiques. À l'affichage des pages, l'application va injecter la bonne adresse de l'image avec le bon domaine.

Avec ce système, augmenter le nombre de conteneur applicatif est très simple, il suffit de leur donner l'adresse du conteneur de statiques. Pour augmenter les performances du conteneur de statiques, il suffit de lui ajouter une série de reverse proxy cache type Varnish ou de le mettre derrière un véritable CDN.

Le plus difficile reste à modifier l'application pour qu'elle gère correctement ce nouveau service. Avec Wordpress, il est possible d'utiliser le plugin W3 Total Cache pour réaliser ça. C'est l'option "personnal CDN" qui permet de configurer proprement les accès ftp et le nom du domain dédié aux statiques.

Stockage clé / valeur

Sans passer par un conteneur de statiques, il est possible de déporter le stockage de vos fichiers du disque vers un service de stockage d'objet clé/valeur comme S3 ou swift. Dans ce cas, le scénario est le suivant :

Le client upload son image, votre application stock le fichier dans le cluster swift et chaque appel de l'image dans les pages web se fait à travers votre application qui ira chercher le fichier dans le service de stockage avant de le renvoyer au client. Avec un peu de cache sur chaque serveur applicatif, tout fonctionnera sans aucune perte de performance, et ce, même si vous avez un très grand nombre de conteneurs applicatif. Déployer cette solution permet de ne pas avoir à configurer un conteneur supplémentaire, en revanche, elle dépend d'un service tiers.

Que ce soit avec Magento ou Wordpress, il existe des plugins pour faire ça. Si vous développer en rails ou en danjgo, il existe des gems et des packages python capable de vous aider à résoudre cette problématique.

Conclusion

Malgré ces défauts, le volume est une solution simple et efficace pour une application ne nécessitant pas d'avoir plus d'un conteneur.

En revanche, si l'on augmente le nombre de conteneurs il est préférable d'utiliser un système tièrs pour s'occuper des uploads. Qu'il soit fait maison avec un conteneur ou hébergé sur la toile, dans tous les cas, il est préférable de séparer les responsabilités pour éviter d'utiliser un système de fichier partagé.


Photo par Ben Grey

by Thomas Clavier at March 11, 2015 11:00 PM

March 05, 2015

Azaé

Une bassine de travail

Depuis quelque temps, Olivier de Deliverous et Étienne d'/ut7 expérimentent le pair programming à distance sur le code de Deliverous.

Nous utilisons un container en ligne (évidemment !) que nous appelons une bassine. Si vous voulez comprendre l'origine de ce nom, Étienne vous parle plus en détail de l'origine des bassines sur le blog d'/ut7 mais pour faire simple, disons que c'est un espace de travail créé à l'occassion de chaque session de programmation : chacun se connecte en ssh et nous utilisons tmux pour partager le même terminal (en fait pour être précis, nous utilisons byobu qui est une sur-couche pour tmux).

Évidemment, c'est en mode texte, mais heureusement, nous avons à notre disposition des éditeurs très puissants qui ont fait leurs preuves : vim et emacs.

Ci-après, nous allons vous expliquer en détail comment nous avons configuré notre bassine pour que vous puissiez faire la vôtre. Pour instancier vos bassines, vous êtes les bienvenus sur Deliverous ;-).

Nous avons construit deux containers :

  • Une bassine de base contenant sshd et vim.
  • Une bassine "Déliverous", dérivant de la bassine de base, et ajoutant tout ce qui est nécessaire pour notre session de travail. Cette bassine est un exemple de spécialisation de la bassine de base, dont vous pourrez vous inspirer pour construire votre propre bassine.

La bassine de base

Voici le début de notre fichier Dockerfile. Pour information, vous pouvez trouver la définition complète de la bassine de base sur github.

On commence par installer les packages de base. A priori, ici, vim a pris le dessus sur emacs...

FROM ubuntu:trusty

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update \
 && apt-get dist-upgrade -y \
 && apt-get install -y \
      vim-scripts \
      vim-syntax-docker \
      vim-syntax-go \
      build-essential \
      byobu \
      ca-certificates \
      curl \
      git \
      man \
      mercurial \
      openssh-server \
      openssl \
      time \
      vim \
      vim-addon-manager \
      vim-nox \
 && apt-get clean \
 && locale-gen en_US.UTF-8 fr_FR.UTF-8 \
 && mkdir /var/run/sshd

On créé ensuite un utilisateur, pierre, et on configure sshd. Comme vous le voyez, l'utilisateur Pierre n'a pas de mot de passe. En effet, l'idée ici est de ne s'authentifier que par clé ssh. Les clés ssh ne sont pas connue de la bassine de base. Il est de la responsabilité de la bassine spécifique de s'en occuper comme nous le verrons au chapitre suivant.

RUN adduser --disabled-login --gecos "Pierre D'eau,,," pierre \
 && adduser pierre sudo

ADD sshd_config /etc/ssh/sshd_config
ADD sudoers /etc/ssh/sudoers

Nous continuons en ajoutant deux fichiers de configurations pour git et vim. Nous ajoutons aussi un script utilitaire, qui nous permetra de configurer git pour un utilisateur (nom et email de l'auteur des commits) une fois que nous serons connetés dans le container.

ADD gitconfig /home/pierre/.gitconfig
ADD vimrc /home/pierre/.vimrc
ADD set-git-user /usr/local/bin/set-git-user

Il ne faut pas oublier de mettre les bons droits sur les différents fichiers ajoutés.

RUN chmod 755 /usr/local/bin/set-git-user \
 && chmod 440 /etc/sudoers \
 && chown -R pierre:pierre /home/pierre

Et on finit par lancer le service sshd après avoir défini son port.

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

La bassine deliverous

Pour notre projet deliverous, nous avons construit une bassine deliverous dérivant de la bassine de base. Voici le début du Dockerfile.

FROM deliverous/base-bassine

ENV GOVERSION 1.3.3
ENV RUBYVERSION 2.1.5

RUN apt-get update \
 && apt-get install -y qt4-dev-tools qt4-qmake \
 && apt-get clean

Puis, on install le langage Go

RUN curl -sSL https://storage.googleapis.com/golang/go$GOVERSION.linux-amd64.tar.gz  | tar -v -C /usr/local -xz

Il ne faut pas oublier de rajouter Go dans le path. On en profite pour rajouter le chargement de notre environnement à chaque démarrage de bash.

USER pierre
RUN echo "export PATH=/usr/local/go/bin:$PATH" >> /home/pierre/.bashrc \
 && echo "[ -f ~/workspace/bin/env.sh ] && source ~/workspace/bin/env.sh" >> /home/pierre/.bashrc

Ensuite, on installe le langage Ruby en utilisant rvm

RUN gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3 \
 && curl -sSL https://get.rvm.io | bash -s stable \
 && /bin/bash -l -c "rvm requirements" \
 && /bin/bash -l -c "rvm install ruby-$RUBYVERSION" \
 && /bin/bash -l -c "rvm use --default ruby-$RUBYVERSION" \
 && /bin/bash -l -c "rvm rvmrc warning ignore allGemfiles"

Comme nous utilisons Go et Docker, nous rajoutons les plugins respectifs dans vim

RUN vim-addon-manager install go-syntax dockerfile

On rajoute un script qui nous permet de mettre à jour notre workspace (rendez-vous sur github pour en consulter le contenu)

USER root

ADD get-deliverous /usr/local/bin/get-deliverous
RUN chmod 755 /usr/local/bin/get-deliverous

On déploie les clé ssh pour l'utilisateur pierre. Ce fichier doit contenir la clé publique de chaque utilisateur qui voudra se connecter pour travailler dans ce container.

ADD authorized_keys /home/pierre/.ssh/authorized_keys
RUN chown -R pierre:pierre /home/pierre/ \
 && chmod 600 /home/pierre/.ssh/authorized_keys

On déploie clustergit qui est bien pratique pour mettre à jour une arborescence de repo git.

RUN git clone https://github.com/mnagel/clustergit /usr/local/src/clustergit \
 && ln -s /usr/local/src/clustergit/clustergit /usr/local/bin/clustergit

On installe pelican avec ses dépendances. C'est notre moteur de blog.

RUN apt-get install -y \
      libfreetype6-dev \
      libjpeg8-dev \
      liblcms2-dev \
      libtiff5-dev \
      libwebp-dev \
      python-pip \
      python-dev \
      python-tk \
      tcl8.6-dev \
      tk8.6-dev \
      zlib1g-dev \
 && pip install pelican Markdown Pillow

En phase de rédaction, pour relire avec la mise en forme final, il est possible de lancer un serveur web sur le port 8000. Nous exposons donc le port 8000 en plus du 22.

EXPOSE 8000 22

Pour finir, on profite des volumes pour conserver notre workspace.

VOLUME ["/home/pierre/workspace"]
CMD ["/usr/sbin/sshd", "-D"]

Et voilà, notre bassine de travail est prête à être construite.

docker build -t deliverous/bassine .

Il ne reste plus qu'a envoyer l'image sur le registre Docker.

docker push deliverous/bassine

Et enfin, pour déployer cette image sur notre infrastructure, nous avons besoins d'un fichier Deliverous

bassine:
  image: deliverous/bassine
  ports:
  - ip: bassine.ut7.fr
    container_port: 22
    host_port: 22
  - ip: bassine.ut7.fr
    container_port: 8000
    host_port: 8000
  volumes:
  - name: workspace
    path: /home/pierre/workspace
  hostname: bassine

Photo par tetue

by Olivier Albiez at March 05, 2015 11:00 PM

February 26, 2015

Azaé

Docker Meetup Lillois de Mars

Nous organisons le 24 mars le prochain meetup Docker Lillois. Réservez dès aujourd'hui votre soirée. Ce mois ci, nous serons hébergé par Solidd et le buffet sera offert par Techsys. Venez nombreux !

Le nombre de places étant limité, si vous avez un empêchement, merci de libérer votre place.


Photo par ntr23

by Thomas Clavier at February 26, 2015 11:00 PM

February 24, 2015

Champs Libres

QGIS GeoJSON export plugin

Champs-Libres vient de créer son premier plugin QGIS. Le plugin a le doux nom de QgisGeoJSONExportPlugin et permet de générer du GeoJSON à partir de couches vectorielles et de les envoyer, sur un serveur distant via les protocoles traditionnels (FTP, FTPS, SFTP). Le GeoJSON généré conserve la table d'attributs de la couche d'origine. L'idée est d'utiliser ce plugin pour mettre à jour des cartes interactives basées sur du geojson.

Le plugin est publié sous license GPLv2 et le code source se trouve sur un dépot github.

Pourquoi ce plugin ?

La demande de notre client était la suivante :

Nous voulons une carte interactive sur notre site web, une carte simple qui ne demandera pas de modifier notre hébergement. Nous voudrions également un moyen simple pour la mettre à jour.

Nous avons donc imaginé ce plugin QGIS qui génère du GeoJSON à partir d'une couche vectorielle et le transfère sur un serveur. Ce plugin répond à cette demande car :

  • le GeoJSON généré contient la table des attributs,
  • la carte interactive est générée à partir du GeoJSON,
  • pour mettre à jour les infos affichées sur la carte, il suffit donc
    • de mettre à jour les attributs, directement depuis QGis,
    • et d'utiliser le plugin pour générer le GeoJSON et de l'envoyer sur le serveur.

Plus d'infos ici.

Et la suite ?

Etant donné la facilité d'utilisation du plugin, nous comptons l'intégrer dans l'utilisation de notre webGIS WombatGIS!

by Champs-Libres at February 24, 2015 03:00 PM

February 09, 2015

Azaé

Docker Meetup Lillois de Février

Nous organisons le 18 février le prochain meetup Docker Lillois. Réservez dès aujourd'hui votre soirée. Ce mois ci, nous serons hébergé par Ecreall. Venez nombreux !

On vient de me demander une courte présentation des meetup docker, je profite donc de l'annonce du prochain pour vous la partager :

Docker est la solution de conteneur applicatif du moment, que ce soit Google, Amazon ou vos clients tout le monde en parle. Venez découvrir, vous perfectionner ou expérimenter cette technologie avec nous durant une soirée forum ouvert. Tout le monde est bien venu, que vous soyez manager, développeur ou administrateur système, chacun apportera sa compétence pour qu'ensemble nous apprenions.

Vous en pensez quoi ?


Photo par Technically Learning

by Thomas Clavier at February 09, 2015 11:00 PM

February 04, 2015

Scil

Bar-kitchen update

We have just updated Bar-Kitchen module for Pasteque 5.x versions. Bar-Kitchen is a module for Pastèque-Desktop (not available for Pastèque-Android). It prints products orders to one or two locations, such as bar and kitchen. But you can use it for anything else, such as fabrication order. Module uses products references to know where to print […]

by Philippe at February 04, 2015 04:39 PM

January 30, 2015

Champs Libres

Travis: Composer `fails to download` packages

Dans nos builds travis, il arrive que composer ne parvienne pas à télécharger et installer correctement des packages : le message suivant s'affiche :

Failed to download doctrine/annotations from dist: Could not authenticate against github.com

Ce message est dû aux limites de l'API de Github, qui limite le téléchargement par adresse IP. Les machines virtuelles hébergées par travis partageant la même adresse IP, les limites de Github sont vite atteintes.

La solution ?

S'authentifier auprès de Github avant d'installer les packages, ce qui permet d'augmenter la limite de téléchargements. Pour cela, créez un token d'authentification sur github. Aucune autorisation ne doit être côchée :

Capture d'écran de github : créer un tocken

Le token doit être ajouté au fichier de configuration .travis.yml mais, étant personnel, il est très déconseillé d'être enregistré en clair.

Travis propose une solution tout simple pour l'encrypter. D'abord, l'installer :

gem install travis

Ensuite, crypter votre token. Si vous exécutez ce script depuis le répertoire de votre code, travis peut reconnaitre le dépôt concerné, et ajouter automatiquement les indications nécessaires à votre fichier .travis.yml :

travis encrypt GITHUB_COMPOSER_AUTH=123456789 --add #crypter votre token

Il ne reste plus qu'à ajouter une ligne dans votre fichier .travis.yml pour que composer utilise votre token :

install:
  - composer config -g github-oauth.github.com $GITHUB_COMPOSER_AUTH
  - composer install --dev --no-interaction

note: vous pouvez utilisez plusieurs fois le même token auprès de différents projets.

by Champs-Libres at January 30, 2015 08:00 AM

January 25, 2015

Azaé

Ouverture de la béta publique des volumes

Vous étiez nombreux à nous demander une solution pour garantir la persistance de vos données applicatives. Les tests ont été longs, il ne reste plus que l'épreuve du feu.

En théorie

Les volumes Docker permettent de sortir des données du conteneur. C'est particulièrement utile pour ne pas perdre les données de vos applications entre deux démarrages du conteneur.

Notre objectif était simple, vous fournir une solution pour monter des volumes dans vos conteneurs et faire en sorte que ces données suivent les conteneurs.

Imaginons que vous lancez un conteneur A:1 qui monte le volume /upload. La plateforme va le lancer sur un nœud X. Après une mise à jour, vous décidez de relancer la nouvelle version de votre conteneur A en version 2. La plateforme va lancer la nouvelle version de votre conteneur sur le nœud Y. Il est indispensable que les données créées par le conteneur A:1 sur le nœud X soit disponible pour le conteneur A:2 sur le nœud Y.

Pour faire ça de façon scalable et sécurisé, nous avons monté un cluster Ceph. Pour l'instant, faute de demande, la seule façon d'y accéder, c'est de passer par les volumes si vous cherchez une interface différente (S3 ou Swift) n'hésitez pas à demander.

En pratique

Pour mettre en œuvre cette nouvelle fonctionnalité dans vos projets, il suffit de modifier le fichier Deliverous comme ceci :

conteneur:
    image: monimage
    volumes:
    - name: mes_data
      path: /var/lib/data

volumes est la liste des volumes à monter dans le conteneur.

Pour chaque volume,

  • name identifie un répertoire qui sera créé dans un espace sécurisé et dédié du projet,
  • path correspond au point de montage dans le conteneur.

12 factor app

Comme évoqué dans The Twelve Factor Apps 1/2 et en particulier dans le point 6, pour qu'une application soit scalable il est important que chaque processus soit indépendant des autres. Donc n'utilisez pas ce filesysteme pour communiquer entre vos conteneurs. Il n'y a entre autre aucun verrou ni aucune gestion d'accès concurrents.

Si vous aviez dans l'idée d'y partager votre index Lucen ou d'en faire une file d'attente ce n'est pas le bon outils. En revanche, si vous souhaitez enregistrer les uploads de vos utilisateurs pour les servir depuis l'ensemble de vos conteneurs ou y stocker vos fichiers de base de données nous avons construit cette solution pour vous.


Photo par Andreina Schoeberlein

by Thomas Clavier at January 25, 2015 11:00 PM

January 13, 2015

Scil

Vœux 2015

Toute l’équipe vous souhaite ses meilleurs vœux pour 2015 Pastèque, c’est vous Nous remercions tous les utilisateurs de Pastèque, les bénévoles du forum qui s’activent à comprendre le logiciel, à compléter la documentation, ceux qui créent des nouveaux rapports, des scripts et même, pour certains, écrivent du code : merci à vous ! Pastèque n’est […]

by Philippe at January 13, 2015 02:12 PM

January 07, 2015

Champs Libres

Chill: testez la première version

Champs-Libres est fier de proposer de tester la première version du logiciel pour suivi social "Chill". Cette première version est encore limitée en fonctionnalités, mais elle vous permettra de découvrir, petit à petit, le logiciel final. En récoltant vos réactions, nous espérons également pouvoir améliorer cette version.

La page d'accueil du logiciel

Qu'est-ce que c'est, Chill ?

Chill est un logiciel libre de service social. Il poursuit deux objectifs :

  • simplifier les tâches administratives des travailleurs sociaux ;
  • apporter aux travailleurs sociaux les informations dont ils ont besoin pour assurer le suivi de leur travail.

Les premiers modules permettront de réaliser les tâches suivantes :

  • enregistrer des "rapports" à propos du public ;
  • enregistrer les activités avec le public : entretiens, appels téléphoniques, démarches, ... Ces activités pourront être utilisées pour le suivi des personnes, mais aussi pour compiler des statistiques pour les rapports annuels ou la justification de subsides ;
  • stocker des documents à propos des personnes reçues ;

Chaque service qui l'utilise pourra personnaliser le type d'informations suivies en fonction de ses besoins.

Vous trouverez plus d'informations dans un précédent billet.

Qui utilise Chill ?

Chill est maintenant utilisé par une ONG belge. Nous accompagnons l'ONG dans les premières implémentations du logiciel. Cette première expérience nous permet de tester

Qu'est-ce qu'on peut tester ?

Dans cette première version du logiciel, vous pouvez :

  • créer le dossier d'une personne et le consulter ;
  • introduire des "rapports" : un "rapport" est une photo, à un instant donné, de l'état d'une personne. Il pourrait s'agir d'un diagnostic, d'une description des problèmes rencontrés par une personne à une certaine date, etc.
  • utiliser des formulaires personnalisés : chaque association peut introduire les informations propres à son activité. Dans la version de démonstration, des rapports 'fictifs' personnalisés sont présentés en exemple ;
  • vous pouvez également tester la recherche dans le logiciel : plus d'infos dans notre billet dédié.

Qu'est qui va changer ?

De nombreuses fonctionnalités seront implémentées dans les prochaines semaines : la possibilité d'enregistrer des activités (appels téléphoniques, rendez-vous, actions effectuées), etc.

Le design va également évoluer : nous travaillons avec un graphiste afin d'avoir une application intuitive, un joli logo, ...

Nous vous invitons à vous inscrire à notre newsletter pour être informés de l'état d'avancement du projet.

#mcembedsignup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

Vous pouvez également suivre, réagir, et proposer des modifications sur notre programme de gestion de projet (n'ayez pas peur de l'anglais, aucun de nous ne le parle vraiment, mais ça permet à tous de plus ou moins comprendre).

Et si je veux l'utiliser ?

Vous pouvez installer Chill par vous même si vous disposez de quelques compétences techniques et d'un serveur : les instructions sont disponibles ici.

Chill est en développement : des fonctionnalités seront ajoutées dans les prochaines semaines. Si vous êtes pressés de disposer de l'une d'entre elles, ou de l'adapter à votre association, vous pouvez nous demander un devis ou, comme le code source est ouvert, contribuer à celui-ci. Pour vous aider, la documentation technique est disponible et se complète au fur et à mesure du développement.

Nous préparons une offre si vous désirez une installation "clé en main". Si vous êtes intéressés, n'hésitez pas à vous manifester en nous écrivant.

by Champs-Libres at January 07, 2015 08:00 AM

January 06, 2015

Champs Libres

Va chercher, Chill! (la recherche dans un logiciel de service social)

Chill, le logiciel libre pour service social, vise à aider les travailleurs sociaux à accomplir leurs missions. Le logiciel a deux missions :

  • simplifier les tâches administratives, et notamment les différents rapports d'activités. Chill est alors utilisé pour enregistrer les activités et aider à fournir des statistiques ;
  • fournir aux assistants sociaux les informations et outils dont ils ont besoin pour accomplir leurs tâches quotidienne. Chill ne sert pas qu'à "recevoir" des informations, il en fournit également, quotidiennement, à ses utilisateurs.

Pour atteindre ce deuxième objectif, nous avons travaillé sur la recherche de ces informations dans le logiciel: l'essentiel doit être à portée de main !

Tout d'abord, des personnes

Sur chaque page du logiciel, une barre de recherche est disponible. Elle permet de lancer, à tout endroit, une recherche sur différents éléments du logiciel.

Le champ recherche est présent sur toutes les pages

Le premier élément, la "matière" des travailleurs sociaux, ce sont les personnes ! Pour trouver une personne enregistrée, il suffit d'introduire quelques lettres de son prénom et/ou nom.

Ainsi, la recherche Depardieu permettra d'accéder immédiatement aux dossiers de personnes accompagnées qui répondent au nom de "Gérard Depardieu", "Jean Depardieu" ou "Charline Depardieu". Mais il aurait suffit d'introduire quelques lettres, par exemple "Depar", "dieu", ou simple "dep" pour que ces noms soient proposés. Voir dans la démo

Vous voulez voir uniquement Gérard Depardieu, et ne pas vous encombrer de ses homonymes ? Vous pouvez ajouter des morceaux de son prénom : Gérard dep va sélectionner directement les personnes qui contiennent "Gérard" et "dep" dans le prénom et/ou nom de famille. Mais l'on aurait pu simplement introduire Gé dep pour accéder au même résultat. Voir dans la démo

Des accents, des majuscules ? Au plus simple !

La recherche ne tient pas compte des accents et des majuscules : les recherches Gérard, gerard, GERARD sont équivalentes. Ainsi, si les utilisateurs n'ont pas respecté la casse, les accents, etc. votre recherche aboutira. Vous recevez des étrangers ? Elle fonctionne aussi avec les alphabets les plus inattendus : le ç, le å, etc. sont reconnus. Voir dans la démo

Recherche par date de naissance, nationalité, ...

Vous voulez trouver les personnes par date de naissance ? Les personnes originaires de l'un ou l'autre pays ? Après avoir appris quelques termes de recherches, vous y arriverez en moins d'un clic :

  • birthdate:1990-12-15 lancera la recherche pour toutes les personnes nées le 15 décembre 1990 (notez la date de naissance au format Année-mois-jour) ;
  • nationality:RU vous affichera les personnes dont la nationalité est Russe (Code pays RU). La liste des codes pays est disponible facilement sur le net;
  • firstname:Depardieu restreindra la recherche au nom de famille, lastname:Gérard au prénom. Il est possible de n'introduire qu'une partie du nom (firstname:dieu renverra "Depardieu").

Caractères spéciaux

Si vous utilisez des espaces, ou des caractères spéciaux dans votre recherche, mettez le terme entre parenthèse. Par exemple: firstname:(Van Snick) pour les personnes dont le nom de famille doit contenir la chaine "Van Snick" : "Van Snickenberg", "Van Snickenbroeck", mais pas "Van den snick".

Utilisez également des parenthèses lorsque votre recherche doit contenir des apostrophes (`firstname:(M'bola)`, etc.).

La liste des critères de recherche est publiée dans la documentation (en anglais technique). Elle sera jointe au manuel du logiciel.

Vous pouvez évidemment combiner plusieurs termes: dep birthdate:1948-12-27 donnera les personnes qui contiennent "Dep" dans le nom ou le prénom et qui sont nés le 27 décembre 1948. nationality:RU firstname:dep restreindra la recherche aux personnes de nationalité russe qui contiennent "dep" dans leur prénom, etc.

Recherche parmi les rapports, activités, etc.

Il est possible de chercher parmi d'autres entités que les personnes comme, par exemple, les rapports (des rapports de consultation, de problématique, etc.).

Pour étendre la recherche à ces rapports, il suffit d'introduire le terme @report dans le champ de recherche. Par défaut, pour les rapports, le champ entré correspond à une date : @report 2015-01-05 indiquera donc tous les rapports créés le 5 janvier 2015. Voir dans la démo

Regard vers le futur

Dans les prochains mois, en fonction des demandes, nous envisageons de développer d'autres fonctionnalités de recherche. Si vous êtes pressés de disposer de l'une d'entre elles, vous pouvez nous demander un devis ou, comme le code source est ouvert, contribuer à celui-ci. Pour vous aider, la documentation est disponible et se complète au fur et à mesure du développement.

Parmi nos idées :

by Champs-Libres at January 06, 2015 08:00 AM

January 02, 2015

Azaé

start-stop-daemon et Docker

Toute l'histoire a commencé par la nécessité de faire un conteneur Docker pour un Tomcat 7 basé sur une debian.

Le problème

La construction d'un conteneur tomcat sur base de debian semble pourtant trivial :

from deliverous/wheezy
run apt-get update && \
    apt-get install -y --no-install-recommends openjdk-7-jdk tomcat7 && \
    apt-get clean
expose 8080
cmd /etc/init.d/tomcat7 start; tail -f /var/log/tomcat7/*

Seulement avec ce Dockerfile impossible de lancer tomcat. En étudiant le problème on s'apperçoit que le script d'init lance un "start-stop-daemon --test" qui tombe en erreur. Pourtant un ps nous montre un processus java qui fonctionne et netstat nous indique que le port 8080 est occupé par ce même processus java.

Pourquoi start-stop-daemon considère que tomcat n'est pas correctement démarré ?

Un manque de droits

En lisant le code de start-stop-daemon on voit que si les options --test et --exec sont utilisés sous GNU/Linux alors start-stop-daemon va lire le lien /proc/%d/exec pour vérifier que c'est bien le même que l'argument --exec. Or pour avoir le droit de lire ce lien il faut les droits SYS_PTRACE, droits qui ont été supprimés de Docker en version 1.0.1 (cf bug 6607). Alors comment faire pour faire fontionner mon conteneur ? Surtout que la fonctionnalité --test de start-stop-daemon n'est pas utilisé que par tomcat7.

La première idée c'est de lancer le conteneur avec les bons droits :

docker run --cap-add SYS_PTRACE -p 8080:8080 tomcat

Et effectivement tout fonctionne parfaitement. Seulement comment faire pour lancer ce conteneur sur Deliverous ? Et sur les autres plate-forme d'hébergement Docker ?

La seconde idée c'est de maintenir un nouveau script de boot ... seulement maintenir un script c'est du travail, faut s'adapter aux changements de la distribution, prendre en compte les mises à jours de Tomcat et suivre les failles de sécurités. Ce n'est donc pas forcément une bonne idée.

La solution

Après la lecture du code de start-stop-daemon et de cet article la solution était évidente, le comportement de start-stop-daemon n'est pas le même si l'on utilise l'option --startas. Il faut donc changer tous les appels en "--test --exec" par des "--test --startas" dans le script d'init. La maintenance est bien plus simple, c'est en effet un simple patch à appliquer à la construction du conteneur. C'est automatique et sauf gros changement, patch s'occupe tout seul de fusionner le travail des mainteneurs avec le miens.

Le script d'init de tomcat n'utilise que 4 fois la commande start-stop-daemon avec --test et --exec, le remplacement est simple et le patch très léger.

--- tomcat7.org 2014-02-22 22:42:27.000000000 +0100
+++ tomcat7 2014-12-31 11:05:46.000000000 +0100
@@ -195,7 +195,7 @@

  log_daemon_msg "Starting $DESC" "$NAME"
  if start-stop-daemon --test --start --pidfile "$CATALINA_PID" \
-   --user $TOMCAT7_USER --exec "$JAVA_HOME/bin/java" \
+   --user $TOMCAT7_USER --startas "$JAVA_HOME/bin/java" \
    >/dev/null; then

    # Regenerate POLICY_CACHE file
@@ -217,7 +217,7 @@
    catalina_sh start $SECURITY
    sleep 5
          if start-stop-daemon --test --start --pidfile "$CATALINA_PID" \
-     --user $TOMCAT7_USER --exec "$JAVA_HOME/bin/java" \
+     --user $TOMCAT7_USER --startas "$JAVA_HOME/bin/java" \
      >/dev/null; then
      if [ -f "$CATALINA_PID" ]; then
        rm -f "$CATALINA_PID"
@@ -257,7 +257,7 @@
    status)
  set +e
  start-stop-daemon --test --start --pidfile "$CATALINA_PID" \
-   --user $TOMCAT7_USER --exec "$JAVA_HOME/bin/java" \
+   --user $TOMCAT7_USER --startas "$JAVA_HOME/bin/java" \
    >/dev/null 2>&1
  if [ "$?" = "0" ]; then

@@ -282,7 +282,7 @@
  ;;
   try-restart)
         if start-stop-daemon --test --start --pidfile "$CATALINA_PID" \
-   --user $TOMCAT7_USER --exec "$JAVA_HOME/bin/java" \
+   --user $TOMCAT7_USER --startas "$JAVA_HOME/bin/java" \
    >/dev/null; then
    $0 start
  fi

Bilan, voilà une solution simple et maintenable pour contourner un conflit de sécurité entre Debian et Docker. Pour appeler le patch dans le Dockerfile j'ai ajouté les lignes suivantes :

add tomcat7.patch /tmp/
run apt-get update && \
    apt-get install -y --no-install-recommends patch && \
    patch /etc/init.d/tomcat7 < /tmp/tomcat7.patch && \
    rm -f /tmp/tomcat7.patch && \
    apt-get remove --purge -y patch && \
    apt-get clean

Si vous préférez utiliser directement mon conteneur tclavier/tomcat vous pouvez le trouver sur le hub Docker.


Photo par Brian K YYZ

by Thomas Clavier at January 02, 2015 11:00 PM

December 23, 2014

Champs Libres

Doctrine migrations et multiples bundles avec composer

Un de nos projets (Chill, un logiciel pour services sociaux) assemble plusieurs bundles Symfony2 dans une application. Il est également prévu que les utilisateurs puissent, selon leurs besoins, installer plusieurs bundles de leur choix, voire d'en créer de nouveaux. Les bundles peuvent avoir éventuellement besoin de la base de données: ils doivent alors être capables de créer des tables, de les manipuler, etc.

Pour gérer la création du schéma de la base de données, nous utilisons DoctrineMigrationsBundle, un composant qui s'intègre à l'application et permet de gérer les modifications du schéma. Les modifications sont enregistrées dans des classes de migrations, dont la structure doit être celle-ci :

namespace Application\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration,
    Doctrine\DBAL\Schema\Schema;

# ici, 20100416130401 est un timestamp de l'heure 
# de création de la classe. Il l'identifie 
# de manière unique
class Version20100416130401 extends AbstractMigration
{
    public function up(Schema $schema)
    {}

    public function down(Schema $schema)
    {}
}

Les classes de migrations doivent être enregistrées dans un répertoire spécifique (app/DoctrineMigrations, par défaut).

Le problème

Notre application assemble différents bundles qui apportent leurs propres fichiers de migrations.

Or, si l'on peut éventuellement configurer le répertoire dans lequel le bundle DoctrineMigration s'attend à trouver les classes de migrations, est situé au niveau de l'application, et pas des bundles importés. Il est impossible, actuellement, de configurer plusieurs répertoires.

Notre solution

Nous utilisons composer pour gérer l'assemblage des bundles : nous nous sommes appuyés sur les scripts du gestionnaire de paquets pour s'assurer que le répertoire de l'application `app/DoctrineMigrations` soit synchronisé avec les fichiers de migrations apportées par les bundles.

Concrètement, après chaque installation et/ou mise à jour d'un package, un script :

  • vérifie si le nouveau venu apporte de nouveaux fichiers de migrations, ou si ceux-ci ont été modifiés (la comparaison utilise un timestamp md5) ;
  • si c'est le cas, le fichier est recopié dans le répertorie app/DoctrineMigrations; si un fichier a été modifié, une confirmation est demandée à l'utilisateur ;

Le code

La classe qui effectue les migrations peut être inspectée sur notre dépot. La partie la moins documentée consiste à

  • récupérer la liste des packages installés ;
  • trouver le chemin d'installation du package ;

Le code de ces parties a été isolé :

// le fichier est enregistré dans app/Composer/Migrations.php

namespace Chill\Composer;

use Composer\Script\CommandEvent;
use Symfony\Component\Filesystem\Filesystem;
use Composer\IO\IOInterface;


class Migrations
{
    
    public static function synchronizeMigrations(CommandEvent $event)
    {
        # récupère la liste des packages
        $packages = $event->getComposer()->getRepositoryManager()
              ->getLocalRepository()->getPackages();

        # l'installation manager permet de deviner le 
        # chemin d'installation du package
        $installer = $event->getComposer()->getInstallationManager();
        
        # ...

        foreach($packages as $package) {
            //pour trouver le chemin d'installation : 
            $installPath = $installer->getInstallPath($package);
            
            # ...
            
        }
        
    }
    
}

Les instructions dans composer.json

Le fichier composer.json doit contenir les instructions suivantes pour exécuter le script correctement :

  • instructions pour permettre de charger la classe "Migrations" enregistrée dans le répertoire app/Composer :
"autoload": {
   "psr-4": {"Chill\\Composer\\" : "app/Composer/"}
}
  • instructions pour exécuter les scripts après chaque commande composer update et composer install :
"scripts": {
   "post-install-cmd": [
      "Chill\\Composer\\Migrations::synchronizeMigrations"
   ],
   "post-update-cmd": [
      "Chill\\Composer\\Migrations::synchronizeMigrations"
   ]
}

Choix de l'évènement & développement

La documentation de composer propose l'évènement post-package-install et post-package-update, qui aurait, évidemment, parfaitement convenu à notre situation (exécuter un script après l'installation d'un paquet).

Cependant, l'évènement ne semble pas pouvoir être déclenché à volonté par le développeur : il semble qu'il faille manuellement supprimer puis ré-installer un paquet.

Nous avons préféré utiliser l'évènement post-update-cmd et post-install-cmd, qui peut être déclenché avec la commande composer run-scripts.

Notez que l'évènement post-package-* ne fournit pas une instance de Composer\Script\CommandEvent mais bien de Composer\Script\PackageEvent. La classe permet de récupérer immédiatement le package installé par Composer\Script\PackageEvent::getOperation()->getPackage() (ou Composer\Script\PackageEvent::getOperation()->getTargetPackage() dans le cas d'un update).

by Champs-Libres at December 23, 2014 07:00 AM

December 19, 2014

Azaé

Ambassadeurs Docker

Imaginons un conteneur A qui consomme le service du conteneur B, par exemple une application web qui consomme une base de données. Je vous propose de parcourir ensemble les solutions possibles pour que A et B communiquent.

Retour aux sources

L'une des promesses de Docker, c'est construire une fois et lancer ou on veux. Pour atteindre cet objectif il n'est pas envisageable de configurer en dure dans le conteneur A la façon de contacter le conteneur B. Nous n'avons donc que quelques solutions pour injecter l'information dans le conteneur durant l'exécution :

  • Par des variables d'environnement.
  • Par des liens Dockers, ce qui revient à injecter automatiquement des variables d'environnement.
  • Par fichier de configuration partagé dans des volumes.

Les links

La solution la plus simple, préconisée par Docker, c'est d'établir un lien entre A et B :

docker run --name B imageB
docker run --name A --link B:B imageA

Avec cette solution Docker injecte dans le conteneur A un certain nombre de variables d'environnement préfixées par B. Gros avantage, il suffit de savoir lire des variables d'environnement pour savoir se connecter au service B. Ce qui peut être fait au démarrage du conteneur pour écrire un fichier de configuration.

Cette solution simple et rapide présente 2 défauts majeurs :

  • si l'on relance le conteneur B, il faut aussi relancer A
  • il faut que A et B soient sur la même machine.

Il est possible de ne pas injecter automatiquement les variables par des liens et de les ajouter sur la ligne de commande. Ce qui complexifie le lancement, mais permet de s'affranchir de la dernière contrainte.

Fichier partagé

Certains produits ne savent pas travailler avec des variables d'environnement et préfèrent un fichier de configuration. Dans ce cas, il est possible de spécifier dans un fichier l'information pour contacter le conteneur B. Puis de partager dans le conteneur A par un volume. Par exemple :

docker run --name B -p PORT_B:PORT imageB
echo "B=proto://IP:PORT_B" > /path/to/fichier.conf
docker run --name A -v /path/to/:/etc/monapplie/ imageA

Cette solution peut très bien être mise en œuvre avec un outil de gestion de configuration comme Puppet, Ansible ou Chef. Autre avantage, il est possible de détecter le changement de fichier de configuration et de le recharger à chaud ... Seul problème, je ne connais pas beaucoup d'application qui recharge leur fichier de configuration sans être déclenchée par un signal. On se retrouve donc avec les inconvénients suivant :

  • À chaque changement du conteneur B, il faut signaler au processus dans le conteneur A que le fichier de configuration a changé.
  • En revanche avec votre outil de gestion de configuration, il est possible de lancer A et B sur deux machines séparer et de changer A et B de machine.

Dans tous les cas étudiés, il faut un tiers pour prévenir A et modifier le fichier ou injecter les variables.

DNS

Un tiers de confiance que tout le monde connaît et qui maintient une base de correspondance entre noms et adresses, ça fait beaucoup penser au système DNS. En injectant dans le conteneur, un serveur DNS spécifique, il est possible d'avoir une résolution de nom spécifique à chaque environnement. Seul petit problème, il faut que le conteneur B soit enregistré dans le DNS. Pour faire ça, nous avons 2 solutions, soit faire en sorte que le conteneur s'enregistre tout seul sur le service, soit utiliser un gestionnaire de configuration pour faire ce travail.

La solution est complexe, pas très pratique, et impose d'avoir un environnement de développement plus complexe que la production. En effet, il est probable que l'environnement de production se basera sur le DNS mondial et que le développeur utilise un DNS local. Au final, c'est une solution peut élégante.

Ambassadeur

Schéma ambassadeur

Avec les links, nous nous retrouvons donc avec des conteneurs qui communiquent facilement quand ils sont sur la même machine. Seulement, il faudrait arriver à les faire communiquer à travers le réseau. Imaginons que sur la machine de B, nous ayons un conteneur C qui s'occupe de la communication de B et que sur la machine de A nous ayons de la même façon un conteneur D pour la communication réseau de A. Les conteneurs C et D sont des ambassadeurs, ils sont spécifiques à l'environnement de production et gèrent l'ensemble de la communication réseau entre A et B.

Le conteneur C va se retrouver avec les missions suivantes :

  • faire croire à B qu'il est un client comme A.
  • exposer le service de B sur le réseau.
  • enregistrer le dit service dans un registre clé/valeur comme etcd

Le conteneur D va pour sa part avoir les missions suivantes

  • faire croire à A qu'il est la ressource du conteneur B
  • lire dans etcd l'adresse et le port du service B et se connecter dessus

Dans cette configuration, il est facile de faire tourner A et B en développement sur une seule machine et d'injecter en production les conteneurs C et D. On peut même imaginer que le conteneur D embarque la capacité de faire de l'équilibrage de charge vers plusieurs instances de C, de faire de la reprise sur erreur ou comprendre le protocole utilisé pour l'optimiser. Dans le cadre d'un service PostgreSQL le conteneur D pourrait embarquer pgpool. C et D peuvent aussi apporter une couche d'authentification ou de sécurisation, ils sont là pour prendre à leur charge toute la communication distante liée à un environnement complexe.

Comme C et D sont des conteneurs techniques, il n'est pas obligatoire d'en avoir 1 par conteneur applicatif, il est tout à fait possible d'avoir 1 conteneur de type C et 1 conteneur de type D par machine.

En Bref, la solution des ambassadeurs et très élégante mais loin d'être trivial, elle doit en effet être adaptée à chaque contexte.

Conclusion

L'ambassadeur est sans conteste la solution la plus élégante pour avoir une architecture simple en développement et très robuste en production. Elle permet d'extraire des conteneurs applicatifs un certain nombre de responsabilités techniques comme l'équilibrage de charge, l'authentification ou le dialogue avec des briques techniques externe (etcd, zookeeper, etc.). En revanche, l'implémentation de ces ambassadeurs requiert une bonne connaissance des applications et de l'environnement cible.


Photo par Stéfan

by Thomas Clavier at December 19, 2014 11:00 PM

December 16, 2014

Azaé

The Twelve Factor Apps 2/2

The Twelve Factor Apps c'est la définition des bonnes pratiques que doivent suivre un développeur pour produire une application portable et capable de passer à l'échelle. Ces 12 règles ont été rédigées par Adam Wiggins l'un des fondateurs de Heroku.

Cet article est la suite de notre traduction libre entammé dans The Twelve Factor Apps 1/2

7 - Exposition de port

La seule façon de contacter un service, c'est par le réseau. Pour exposer un service il suffit donc de déclarer le port réseau utilisé.

Par exemple, une application web en PHP pourra etre exécuté dans un Apache avec le module PHP et exposé sur le port 80. Une application Java pourra être lancé dans un Tomcat et exposé sur le port 8080.

Une application 12-factor est auto-suffisante elle ne doit pas dépendre d'éléments à l'exécution pour bien fonctionner. Elle écoute et parle sur un port réseau.

En développement il sera par exemple possible d'utiliser le service avec l'url http://localhost:8000. En production un loadbalancer pourra servir de point d'entrée vers de nombreuses instances de l'application.

C'est typiquement mis en place par l'introduction d'une librairie de service web dans l'application. Par exemple Tornado pour Python, Unicorn pour Ruby ou Jetty pour Java.

Le protocole HTTP n'est qu'un exemple des services réseau disponible. MySQL, Redis ou ejabberd utilisent des protocoles différents sur d'autres ports réseaux.

Notez qu'en exposant un service sur le réseau, il est alors utilisable comme une resource distante comme évoqué dans le point 4 en décrivant le service par son URL dans la configuration (cf point 3).

8 - Concurrence

La montée se charge se fait en augmentant le nombre d'instances des composants applicatifs.

C'est une base d'Unix, pour augmenter la capacité de traitement d'une application, il suffit bien souvent d'augmenter le nombre de processus. C'est par exemple vrai avec Apache httpd mais aussi avec Postifx ou Spamassassin. À l'inverse de Java qui réserve un ensemble de ressources au près du système et se débrouille avec.

Une application 12-factor doit suivre ce même principe pour augmenter la capacité, il faut pouvoir augmenter le nombre de nombre d'instance de composants applicatifs.

L'architecture de l'application doit permettre ce mode de fonctionnement. Par exemple pour prendre en charge les requêtes HTTP on pourra instanciés des processus web, pour prendre en compte les traitements longs on pourra instancier des composants "worker" si la charge lié à l'une ou l'autre des types de requête augmente il suffit d'augmenter le nombre de worker ou de processus web.

Cela n'influe en rien sur le fonctionnement interne d'un composant applicatif. Que l'architecture soit basé sur une consommation d'événements asynchrone comme avec node.js ou EventMachine ou sur des processus ou des threads Unix dédié à chaque client.

Chaque processus ne doit jamais passer en mode démon, écrire dans un fichier PID ou dépendre d'un systeme comme systemd, upstart ou un autre "process manager" cela reviendrait à dépendre d'un composant tierce et violerais le point 2.

9 - Disponibilité

Maximiser la robustesse grace à des démarrages rapides et des arrêts progressifs

Pour qu'une application soit robuste et scalable, il est important qu'elle démarre rapidement. Que ce soit pour déployer du nouveau code, un nouveau paramétrage ou faire face à un pic de charge. Plus le temps de démarrage est court, plus il sera simple de réduire le time to market.

La réception d'un signal SIGTERM doit permettre l'arrêt propre de l'application. Dans le cas de requêtes HTTP, à la réception du signal l'application pourra refuser les nouvelles connections et finir de répondre aux requêtes en cours. Dans le cas de requête de type long pooling, il faudra que le client soit capable de se reconnecté tout seul.

Pour un processus de type worker, la réception du signal doit remettre le travail dans la file pour qu'un autre worker le consomme, attention à la gestion des verrous. Dans l'idéal un worker doit être idempotent.

Les principes sont les mêmes en cas de crash d'un processus que ce soit lié à une erreur applicative ou un problème physique. Ce qui rejoint le principe du "Crash-only design".

10 - Équivalence des environnements

Garder l'environnement de développement, de test et de production aussi similaire que possible. Dit comme ça, certains diront que ça tombe sous le sens. Mais en regardant en détail les différences sont là et facilement explicable.

  • Les différences temporelles : le développeur travaille le code et ça prend du temps, des jours voir des semaines avant que ce code arrive en production.
  • Les différences humaines : le développeur code et l'admin système fait les déploiements. Deux équipes différentes donc potentiellement des différences.
  • Les différences d'outil : en développement, il est plus facile d'utiliser un micro serveur web sous OS X alors qu'en production, c'est apache sous GNU/Linux.

Une application 12-factor est conçue pour du déploiement continu. Afin de réduire les différences entre les environnements, il est possible de se concentrer sur les points suivants :

  • Les différences temporelles : une nouvelle ligne de code doit pouvoir arriver en production quelques minutes après avoir été écrite.
  • Les différences humaines : les gens qui codent devraient être impliqués dans le déploiement et la surveillance de leur code.
  • Les différences d'outil : essayer d'avoir les mêmes outils partout.

Utiliser une librairie d'abstraction pour certains services et exploiter une implémentation différente sur chaque environnement est globalement une fausse bonne idée. Par exemple, il vaut mieux utiliser PostgreSQL en développement si c'est la base de données utilisé en production, plutôt que SQLite. En effet, malgré les librairies d'abstractions, il reste des différences qui pourront entraîner des déploiements en erreur.

Les outils modernes (apt-get, Homebrew, Docker) simplifient grandement l'installation de ces outils à l'identique de la production, utilisez les.

11. Logs

Traiter les logs comme des flux d'evenements.

Une application 12-factor n'est pas concerné par le routage ou le stockage des logs. Chaque processus écrit son flux d'evenements, non bufferisé, sur stdout.

Pendant le développement, les développeurs pourront voir ses flux dans leur terminal.

En production, chaque flux de processus sera capturé par l'environnement d'exécution, assemblé avec les autres flux de l'application et routé vers une destination d'affichage ou d'archivage. Ces destinations ne sont pas visibles ou configurables par l'application. Elles sont complétement gérées par l'environnement d'exécution.

12. Processus d'Admin

Exécuter les tâches d'administration et de gestion comme des processus ponctuels.

Indépendamment du service rendu par une application, les développeurs ont souvent le besoin de réaliser des tâches d'administration ou de maintenance comme :

  • Réaliser des migrations de base de données,
  • Lancer une console pour lancer des commandes ou inspecter les données de l'application,
  • Lancer des scripts à usage unique, stockés dans le dépôt de code de l'application.

Ces actions doivent s'exécuter dans des environnements identiques à l'application. En particulier, elles s'exécutent pour une version en utilisant le même code et la même configuration que l'application. Ces taches d'administrations doivent être livrées avec le code applicatif pour éviter les problèmes de synchronisation.


Photo par endolith

by Thomas Clavier at December 16, 2014 11:00 PM

December 15, 2014

Azaé

Testons nos conteneurs Docker

Coder à l'endroit. Pour nous, l'ordre normal des choses, c'est identifier un besoin, le tester, s'il n'est pas rempli, le coder et enfin vérifier qu'il est bien présent. Pour tous les adeptes du Test Driven Developpement, c'est l'enchainement logique des phases de test et de codage. Seulement voilà, comment faire pour dérouler ces étapes pour réaliser un conteneur Docker.

L'ensemble du code présenté dans cet article est consultable dans un projet github

Une histoire de services

Après la lecture de Twelve Factor Apps, il apparait évident qu'un conteneur est une application ou une ressource distante. Donc pour tester ce service, il suffit de se connecter sur le port réseau exposé et de parler la même langue que le service. Aujourd'hui, il est possible de ranger les applications dans 3 grandes catégories :

  • les applications web : exposent de l'http et fournissent html, css et javascript
  • les services web : exposent de l'http et fournissent des objets sérialisés principalement en json et xml
  • les autres services : base de données, xmpp, etc.

On peut affirmer, sans prendre trop de risque, qu'il est possible de tester toutes ces applications dans nos langages de développement. Capybara permet par exemple de naviguer sur des applications web, il est aussi très simple de se brancher sur des services SOAP ou REST, enfin les pilotes pour accéder à des bases de données, des files de messages où d'autres services sont quasiment tous présents dans les langages populaires.

Pour l'exemple, j'ai choisi ruby, mais je vous invites à faire de même avec votre langage favori.

Extreme Startup

C'est un petit jeu que j'utilise de temps en temps en cours. Il permet de découvrir en quelques heures quelques bonnes pratiques du développement logiciel. Pour en savoir plus je vous invite à visiter la page github

C'est l'application que nous allons "dockerifier"

Un peu d'organisation

Pour nos conteneurs, nous avons pris l'habitude de ranger notre dossier de travail de la façon suivante :

  • Le fichier Dockerfile qui permet la construction automatique du conteneur
  • Un fichier Rakefile pour automatiser l'ensemble des taches
  • Un fichier Gemfile pour gérer nos dépendances ruby
  • un dossier src pour héberger les fichiers utile à la construction du conteneur et les sources de l'application si vous en êtes l'auteur.
  • un dossier test pour ranger tous nos tests
  • un dossier .target qui sert de répertoire de travail

Des dépendances

Les fichiers Gemfile et Rakefile sont là pour automatiser les taches récurrentes, typiquement :

  • Préparer l'environnement de travail
  • Construire le conteneur
  • Lancer le conteneur
  • Lancer les tests

Les 3 premières opérations se font avec la gem rake-docker qui automatise toutes les opérations de base sur les conteneurs docker. La dernière est gérée par la gem docker-tdd. Bien évidemment dans un but pédagogique, nous aurions pu tout réécrire en plus simple. Ce sera certainement le sujet d'un nouvel article.

Rakefile en détail

require 'rake/docker_lib'

Permet de charger rake-docker

directory '.target/app'  => '.target' do
  sh "git clone git@github.com/rchatley/extreme_startup.git .target/app"
end

.target/app est le répertoire avec les sources du projet amont, cloné à la création du répertoire.

Rake::DockerLib.new("tclavier/extreme-startup") do
  prepare do
     sh "cd app/ && git pull"
  end
end

On force un pull à chaque préparation. Cela implique de toujours avoir le réseau.

task test: :build
task prepare: '.target/app'

Quelques dépendances forcées.

TDD power !

Pour que docker ne hurle pas durant la phase de build, nous pouvons faire un premier Dockerfile presque vide

from deliverous/wheezy
cmd tail -f /var/log/*

Notez la présence du tail dans la commande à démarrer par défaut, il faut en effet être certain que le conteneur se lance et reste actif.

Premier test

Pour ce premier test, on va travailler dans le fichier test/test_extreme_startup.rb. Pour lancer le test, il faut lancer le conteneur ça se fait dans la fonction containers :

describe "Extreme-startup" do
  include DockerTdd::ContainerPlugin
  def containers
    @xs = DockerTdd::Container.new "tclavier/extreme-startup", boottime: 1
  end
  ...
end

L'application doit écouter en http sur le port 3000.

it "must listen in http on port 3000" do
  open("http://#{@xs.address}:3000/")).status[0].must_equal '200'
end

Notez que l'attribut @xs contient quelques attributs fort pratique entre autres l'adresse IP attribué par docker au conteneur.

Le "rake test" nous dit que le test est bien en échec, tout va bien.

Première implémentation

Passons à l'implémentation. Donc retour dans le fichier Dockerfile. On installe ruby et unicorn

run apt-get update && \
    apt-get install -y --no-install-recommends ruby && \
    apt-get clean

On installe les dépendances ruby

run apt-get update && \
    apt-get install -y bundler sudo libxslt-dev libxml2-dev && \
    cd /opt/extreme_startup && bundle update && \
    apt-get remove -y bundler libxslt-dev libxml2-dev &&\
    apt-get autoremove -y &&\
    apt-get clean

Je fais un bundle update et pas un bundle install, en effet la version de nokogiri présente dans le Gemfile.lock ne compile plus sous Debian stable.

Et on lance le service

cmd cd /opt/extreme_startup && ruby web_server.rb

Puis on relance le test

rake build test

Et voilà ! Premier test OK.

Warmup

Pour que le premier sprint ne génère pas d'inégalité technique, il y a une option warmup qui permet d'avoir toujours la même question.

Pour faire ce test, comme le conteneur est lancé durant le setup il faut faire une seconde classe de test pour passer les bonnes options au conteneur.

@xs = DockerTdd::Container.new "tclavier/extreme-startup", env: ['WARMUP=1'], boottime: 1

Une fois encore le conteneur doit écouter sur le port 3000, mais il doit aussi déclencher une erreur au changement de round

it "must listen in http on port 3000" do
  open(url('/')).status[0].must_equal '200'
end

it "must restart to change round" do
  params = {'param1' => 'value1'}
  url = URI.parse(url('/advance_round'))
  resp = Net::HTTP.post_form(url, params)
  resp.code.must_equal '500'
end

On lance les tests et tout est vert.

Dernier test

Nous avons bien testé que le changement de round déclenche une erreur en cas de warmup. Mais dans le cas nominal que ce passe-t-il ? Nous allons donc ajouter le test suivant dans test/test_extreme_startup.rb.

it "can change round" do
  params = {'param1' => 'value1'}
  url = URI.parse(url('/advance_round'))
  resp = Net::HTTP.post_form(url, params)
  resp.code.must_equal '200'
end

Il suffit de lancer le test pour voir que les 4 tests sont vert.

Conclusion

Nous avons fait 4 tests dans 2 classes avec une implémentation simple. Ce qui nous a permis de voir une bonne partie de notre environnement de test. Nous avons en particulier appris à :

  • déclarer un conteneur dans le fichier Rakefile
  • aller chercher le code source dans un autre projet durant la phase de préparation
  • déclarer des variables d'environnement à l'exécution du conteneur
  • utiliser la lib Net::HTTP pour interroger le conteneur published Ce qui couvre une grande partie de nos tests.

Photo par Med

by Thomas Clavier at December 15, 2014 11:00 PM

December 11, 2014

Champs Libres

Campagne de crowdfunding: carte participative du maillage vert à Liège

L'association Urbagora propose de créer une carte du maillage vert de la région de Liège.

Le projet permettrait de mettre en réseau les différents acteurs du secteur. Le financement devrait permettre d'identifier les espaces verts à protéger et à mettre en valeur.

La page de financement du projet donne plus d'explications :

L'outil que nous allons construire permettra aux particuliers, aux associations, aux écoles ou aux professionnels de participer à ce travail de recherche et de sensibilisation à la ville verte. Ils pourront par la suite l'utiliser pour développer de nouvelles idées et réflexions, de nouvelles collaborations.

Nous envisageons donc ce projet comme une opportunité de créer de façon collaborative un premier outil cartographique spécifiquement dédié à la place de l'élément naturel vert à l'échelle de l'agglomération de Liège.

Une vidéo permet d'explication est également disponible :

by Champs-Libres at December 11, 2014 03:00 PM

December 09, 2014

Champs Libres

Journée de conférence "be-opengis"

Champs-Libres a eu le plaisir de participer à la journée de conférence et d'ateliers "be-opengis", organisée par l'ULB le 6 novembre 2014. Marc Ducobu a pu présenter différents projets de réutilisations des données d'OpenStreetMap au profit d'associations.

La journée a permis, entre autres, de découvrir les nouveautés de GRASS7, un projet de SIG au Burkina Faso, etc. C'est également l'occasion d'échanger avec les autres participants au sujet du libre et des SIG. Et potentiellement, de petit à petit construire une communauté du libre, pragmatique et fonctionnelle, en Belgique...

by Champs-Libres at December 09, 2014 03:00 PM

November 13, 2014

Code Lutin

Devoxx 2014

Comme tous les ans, CodeLutin est encore présent au Devoxx en belgique.

Read or add comments to this article

by chatellier at November 13, 2014 12:34 PM

November 12, 2014

Azaé

Comment faire un container Tomcat

Non, je ne vais pas vous parler des F14 Tomcat de Top Gun, mais bien de container Docker et d'Apache Tomcat. Alors construisons ensemble quelques containers.

Une base de CentOS

En partant d'une distribution de base, il est facile d'installer Tomcat. Avec une Debian stable il est même possible de choisir entre Tomcat 6 et Tomcat 7. Avec une CentOS 6, c'est encore plus simple, il n'y a pas de choix possible :

yum install tomcat6

Avec une CentOS 7 c'est tout aussi simple, le rpm s'appelle tomcat et c'est un Tomcat 7.

Des RPMs

Dans beaucoup d'entreprise, les logiciels s'installent uniquement depuis les rpms officiels, une façon simple de suivre les mises à jour de sécurités et de réduire les coûts de maintenances. Dans ces conditions, si l'on souhaite un Tomcat 6 avec un java 7, il faut partir d'une CentOS 6. Le Dockerfile va donc commencer par :

FROM centos:centos6
RUN yum -y upgrade && yum clean all
RUN yum -y install java-1.7.0-openjdk && yum clean all
RUN yum -y install tomcat6 && yum clean all

Jusque-là, rien de très compliquer. Il reste à :

  • Ajouter une application,
  • exposer le bon port,
  • et lancer Tomcat

Ce dernier point présente une petite difficulté, en effet, le script de boot de Tomcat lance le serveur d'application en mode démon. Seulement Docker s'attend a lancer un processus qui ne se détache pas. Pour éviter d'avoir à refaire et surtout d'avoir à maintenir un nouveau script startup.sh il est possible de lancer juste après Tomcat un second processus qui gardera la main. Par exemple un tail de l'ensemble des fichiers logs. Le tail apporte en plus la possibilité de consulter les logs du Tomcat avec un simple docker logs, ce qui est fort pratique.

Pour l'application d'exemple, je propose de profiter de sample.war distribué par Apache Tomcat 6. Vous remarquerez au passage qu'il est possible de spécifier une URL pour laisser Docker télécharger des composants à la construction du container.

La suite de notre Dockerfile est donc la suivante :

ADD http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war /var/lib/tomcat6/webapps/
EXPOSE 8080
CMD service tomcat6 start && tail -f /var/log/tomcat6/catalina.out

Pour construire notre container lançons :

docker build -t tomcat6-centos6 .

Puis exécutons le, sans oublier d'exposer le port 8080 :

docker run -p 8080:8080 tomcat6-centos6

Et enfin, visitez http://localhost:8080/sample/ pour admirer votre travail.

Pour stopper le container, il faudra jouer avec docker ps et docker stop

L'archive officiel

Pour partir de l'archive officielle distribuée par Apache, le choix de la distribution de base n'a pas d'importance. Je propose donc de partir de la dernière CentOS. En ajoutant la même application d'exemple, nous obtenons un magnifique container capable de lancer un Tomcat 7 directement téléchargé chez Apache.

Pour le script de boot, nous utilisons la même astuce que précédemment.

FROM centos
MAINTAINER Thomas Clavier <tclavier@azae.net>
RUN yum upgrade -y && yum clean all
RUN yum -y install java-1.7.0-openjdk && yum clean all
RUN yum -y install tar && yum clean all

ADD http://mir1.ovh.net/ftp.apache.org/dist/tomcat/tomcat-7/v7.0.57/bin/apache-tomcat-7.0.57.tar.gz /tmp/
RUN mkdir /opt/tomcat
RUN tar -xzvf /tmp/apache-tomcat-7.0.57.tar.gz --directory /opt/tomcat/ --strip 1 && rm /tmp/apache-tomcat-7.0.57.tar.gz

ADD http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war /opt/tomcat/webapps/

EXPOSE 8080

CMD /opt/tomcat/bin/catalina.sh start && tail -f /opt/tomcat/logs/catalina.out

La grosse différence avec le container précédent, c'est que là le Tomcat est installé dans /opt/tomcat, ça ne respecte pas vraiment le Linux Standard Base, mais ça fonctionne.

Normalisation

Votre container Tomcat va probablement tourner dans un environnement de production normalisé. J'imagine aisément que votre DSI aimerait avoir les mêmes interfaces avec tous les containers. Les seules interfaces d'entrées-sorties du container sont les suivantes :

  • le port de communication et son protocole
  • un volume pour partager des fichiers
  • stdout pour les logs

Je propose de déposer les logs complémentaire dans /var/log/tomcat et d'exposer le port 8080 de Tomcat en http.

Pour le port et les logs sur stdout, c'est facile, c'est déjà fait, pour /var/log/tomcat il va falloir travailler un peu.

RPM

Avec le Tomcat 6 de CentOS les logs sont par défaut dans /var/log/tomcat6. Changeons ça :

RUN rm -rf /var/log/tomcat6/ ;\
    rm -rf /usr/share/tomcat6/logs ;\
    mkdir /var/log/tomcat/ ;\
    ln -s /var/log/tomcat/ /usr/share/tomcat6/logs ;\
    chown tomcat:tomcat /var/log/tomcat

Sans oublier de changer le tail pour pointer sur le bon répertoire.

CMD service tomcat6 start && tail -f /var/log/tomcat/catalina.out

Et à déclarer le volume

VOLUME ["/var/log/tomcat"]

Une fois le container reconstruit et relancé, on observe que tout fonctionne à merveille. En revanche si l'on teste en montant le volume, on observe la chose suivante :

$ docker run -p 8080:8080 -i -t -v /tmp/logs/:/var/log/tomcat tomcat-sample /bin/bash
bash-4.1# ls -la /var/log/tomcat/
total 8
drwxr-xr-x 2 1000 1000 4096 Aug  8 07:13 .
drwxr-xr-x 5 root root 4096 Aug  8 07:09 ..

Le répertoire /tmp/logs a été créé avec mon utilisateur local d'id 1000. Une fois le volume monté, les droits sont préservés. Pour être certains que tout fonctionnera tout le temps, il est nécessaire de changer les droits depuis le container à chaque lancement.

CMD chown tomcat:tomcat /var/log/tomcat; service tomcat6 start && tail -f /var/log/tomcat/catalina.out

Archive

La problématique est identique, seule différence, le Tomcat se lance en root et il est installé dans /opt/tomcat. Ce qui nous donne :

RUN rm -rf /opt/tomcat/logs ;\
    mkdir /var/log/tomcat/ ;\
    ln -s /var/log/tomcat/ /opt/tomcat/logs
VOLUME ["/var/log/tomcat"]
CMD chown root:root /var/log/tomcat; /opt/tomcat/bin/catalina.sh run

Attention, la mise à jour de systemd peut produire l'erreur suivante :

error: unpacking of archive failed on file /usr/sbin/suexec: cpio: cap_set_file

En effet, CentOS utilise par défaut les attributs étendus du file-system, or aufs ne les supporte pas tous. Il faut donc changer de backend de stockage, soit vers brtfs, soit vers devicemapper.

Et après ?

À travers cet article, nous avons appris à construire des containers Tomcat sur une base de CentOS, le tout, près à être déployé dans un environnement normalisé. La prochaine étape serait de déployer ces containers. Sur Deliverous, le volume de log ne serait pas exploité, en effet seul les logs présent sur stdout et stderr sont collectés. À défaut de configurer Tomcat pour ne pas utiliser de fichier, un tail -f /var/log/tomcat/* fonctionnerait très bien.

Il est possible de retrouver l'ensemble des fichiers sources sur le projet GitHub docker-sample. Pour les plus motivés je vous invite à rejoindre le prochain meetup Docker.


Photo par storem

by Thomas Clavier at November 12, 2014 11:00 PM

October 30, 2014

Les Développements Durables

Gestion de pub sous SPIP 3.0

LDD a développé de nouvelles fonctionnalité pour La tribune de l'Art, site de référence sur l'actualité de l'histoire de l'art occidental du moyen-âge aux années 30.

L'objectif était avant tout de répondre à des besoins techniques urgents (avant refonte graphique), notamment par la migration du site sous SPIP 3.0, ainsi que par la mise en place du plugin Accès Restreint permettant de limiter la visibilité de certains contenus aux seuls abonnés.

Mais ce projet a aussi permis à LDD de réaliser le développement d'un plugin permettant d'optimiser la gestion d'un régie publicitaire intégrée à SPIP.

Il offre la possibilité de créer une publicité dans un article, une rubrique ou en page d'accueil, à une position précise, définie par les emplacements disponibles. Il permet aussi d'ajouter une limitation par période optionnelle (pouvoir donner une fourchette de dates hors de laquelle la publicité est désactivée) et propose un formulaire pour l'export des statistiques dans un tableur (format CSV). De plus, il est aussi possible d'ajouter une limitation suivant différentes variables (type de page et/ou objets éditoriaux), dans ce cas, la publicité ne s'affiche que si le contexte de la page correspond à ces variables.

Cette nouvelle extension est dès maintenant disponible en téléchargement sur SPIP-Zone et sa documentation technique sera prochainement publiée.

Nous remercions au passage La Tribune de l'Art qui a rendu cette contribution possible.

by Jean Grégoire at October 30, 2014 09:46 AM

October 21, 2014

Code Lutin

Financement OpenStreetMap France

Tous les ans, Code Lutin reverse une petite partie de son chiffre d'affaire à la communauté du logiciel libre. Cette année, ce choix s'est porté sur l'association OSM France.

Code Lutin a utilisé avec succès OSM au gré de ses projets réalisés pour ses clients. Par ailleurs, les lutins sont très contents de pouvoir utiliser des logiciels tels que OsmAnd, entre autres et certains contribuent au projet.

Code Lutin a donc effectué un don de 4850€ qui permettra de financer les activités de l'association.

by couteau at October 21, 2014 09:00 AM

October 01, 2014

Champs Libres

En route pour Chill, le logiciel pour travailleurs sociaux

Il y a quelques semaines, Champs-Libres lançait un questionnaire pour identifier les besoins des travailleurs sociaux. Les réponses aux questions, mais également les rencontres avec les différents partenaires, ont permis de dégager les besoins prioritaires.

Nous vous présentons les grands principes de ce futur logiciel, même si les rencontres prochaines nous permettront encore de préciser et faire évoluer certains points.

Pour être tenus informés, n'hésitez pas à vous inscrire à notre mailing-list.

un Milan royal, en vol Chill le Milan est un personnage du Livre de la Jungle de Rudyard Kipling. En Europe, le Milan est présent du Portugal jusque dans les Ardennes belges.  Noel Reynolds, CC-BY 2.0

Un nom pour le projet : Chill

Dans le livre de la jungle, Chill le Milan accompagne Mowgli, capturé par les singes hurleurs (les bandar-logs). Du haut du ciel, il guide Baloo et Bagheera vers le repaire des ravisseurs de Mowgli. C'est ainsi que nous voyons notre projet : une aide, un coup de main pour "suivre" les personnes accompagnées, et guider l'action sociale.

S'adapter aux besoins des équipes

C'est le premier constat de toutes nos rencontres et du dépouillement du questionnaire : les processus sont globalement semblables, mais comportent également des différences que le logiciel devra intégrer.

Par exemple, un grand nombre d'association voudrait pouvoir enregistrer des informations liées à une personne (son nom, son âge, etc.), mais la nature de ces informations peut varier : certains voudront retenir les derniers diplômes obtenus, d'autres les coordonnées de leur propriétaire, etc.

Autre type de variations : des institutions auront besoin d'une partie des fonctionnalités imaginées, mais pas de l'ensemble.

Chill s'adaptera donc à ces besoins.

D'une part, chaque association pourra définir les données qu'elle veut enregistrer : besoin d'un champ "permis de conduire" ? "Médecin traitant" ? Il suffira de le définir et il sera proposé pour toutes les personnes existantes.

D'autre part nous avons imaginé une architecture au logiciel qui permettra de choisir les fonctionnalités que l'institution veut utiliser. Le logiciel sera découpé en "modules" et chaque association pourra choisir les modules qu'il voudra installer. De cette manière, Chill restera plus ergonomique en se concentrant sur vos besoins.

Des modules extensibles

Il sera possible de programmer un grand nombre de modules. D'ici à décembre, Champs-Libres proposera les modules qui sont les plus récurrents. Ainsi, nous développerons en priorité :

  • un module "Personne" qui enregistrera toutes les données liées à la personne ;
  • un module "Activités" qui permettra de garder une trace de toutes les activités liées à une personne (rendez-vous, appels téléphoniques, etc.).
  • un module "Documents" pour stocker des documents électroniques (PDF, scans, etc);
  • un module "Notes" pour enregistrer des courtes notes sur une personne

Chacun d'eux offrira des fonctionnalités d'export qui permettront de compléter rapidement les différents rapports d'activités.

Vous ne vous retrouvez pas dans ces besoins ? N'hésitez pas nous contacter : vous pourrez nourrir notre réflexion. Suivez également notre projet, il pourra évoluer.

D'abord, des personnes !

La première brique de Chill permettra d'encoder les principales caractéristiques des personnes suivies (nom, âge, coordonnées de contact, etc.).

Chaque association pourra ajouter des champs d'informations qui l'intéressent et qui n'auraient pas été prévues par les développeurs.

Une fois les personnes enregistrées, il faudra pouvoir les retrouver ! Chill s'adaptera à toutes les orthographes : si vous cherchez un 'Johan', le module vous proposera aussi les 'Johanne', 'Joan' et autres déclinaisons du nom.

Vous encodez un nouvel arrivant ? Le logiciel vous suggérera des homonymes avant que vous n'ayez renseigné toutes les caractéristiques : peut-être que votre "nouveau" s'y cache déjà ; vous gagnerez du temps.

Garder une trace des activités

Les travailleurs sociaux pourront enregistrer toutes les activités liées à une personne. Par exemple : encoder un rendez-vous, avec une note sur le contenue de celui-ci. Il pourra ajouter également plusieurs descripteurs standardisés, comme par exemple "contact avec un service juridique", "problème de logement", "entretien de première rencontre", etc.

Deux objectifs pour ce module :

  • permettre de générer des statistiques, utiles pour les pouvoirs subsidiants, les rapports d'activités, ou pour suivre la récurrence d'une problématique ;
  • mais également permettre aux assistants sociaux de retrouver facilement des activités avec la personne rencontrée : besoin de connaitre la dernière fois que vous avez contacté un service juridique ? Une recherche dans le module le permettra directement !

Des notes & des documents

Accompagner des personnes, c'est également récolter une série d'informations sur elles. Les notes sont là pour ça : elles vous permettront de garder des traces de discussions, de faits, d'idées, ...

Chill permettra également de stocker des documents de manière sécurisée. Le but ?

  • permettre d'avoir en permanence, sous la main, les documents qui ont été échangés avec les personnes, sans encombrer les locaux d'archives ;
  • retrouver de manière automatique certains types de documents. Besoin de collecter les diplômes de vos bénéficiaires pour votre dossier de subvention ? Chill automatisera tout ça, et les fouilles dans les archives ne seront plus que de l'histoire ancienne.

Une gestion fine des accès

Chill sera très attentif à la sécurité. Un de ces impacts est que chaque équipe pourra décider de manière très fine les informations auquel chacun de ses membres a accès.

Concrètement, les utilisateurs pourront être répartis en équipes : par exemple : l'équipe "psy", l'équipe "assistant sociaux", l'équipe "administratif", etc. Chaque équipe pourra créer certaines ressources et avoir accès à d'autres.

Exemple :

  • l'équipe psy pourra créer des "notes psy" que seule l'équipe psy pourra lire ;
  • l'équipe assistants sociaux pourra créer des "notes assistants sociaux" qui pourront être lues par les membres de l'équipe psy, mais pas par les administratifs ;
  • etc.

Chaque institution pourra paramétrer ces règles, en fonction de son organisation. Il sera également possible que tous les utilisateurs aient accès à toutes les informations.

Bien évidemment, la connexion au logiciel sera également sécurisé. Le sujet occupe tant d'importance que nous y consacrerons un futur billet.

Et la suite ?

Vous pouvez suivre le développement de Chill sur notre forge. Ces outils sont plutôt destinés aux développeurs mais le débat y est ouvert. Nous avons l'intention d'ouvrir un forum qui permettra de participer aux non-initiés d'échanger de manière électronique sur le sujet.

Si vous souhaitez nous rencontrez, n'hésitez pas à nous écrire à info@champs-libres.coop.

Dans les prochaines semaines, nous publierons des billets spécifiques aux fonctionnalités, ainsi qu'une version démo.

Pour être tenus informés, abonnez-vous à notre mailing-list ci-dessous.

#mcembedsignup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

by Champs-Libres at October 01, 2014 08:00 AM

September 18, 2014

Champs Libres

Carte interactive du Parc naturel des deux Ourthes

Champs-Libres a développé la carte interactive du Parc naturel des deux Ourthes. La carte est consultable sur cette page.

Carte interactive du Parc naturel des deux Ourthes

Le Parc naturel des deux Ourthes nous a demandé de développer une carte interactive afin de présenter les différentes activités se déroulant sur son territoire telles que les marchés fermiers, les producteurs locaux, les sites Natura2000, les vergers de variétés anciennes, etc.

Un de défit majeur de ce projet a été de s'adapter aux contraintes matérielles : PHP sans base de données.

Le résultat est un logiciel permettant de présenter des données géographiques via une carte web interactive. Il est basé sur la librairie javascript Leaflet et utilise PHP pour modifier la carte. Le logiciel est consultable sur le site du Parc.

Copie d'écran de la carte interactive du Parc naturel des deux Ourthes

WombatGIS

Le travail qui a été effectué pour le Parc Naturel des deux Ourthes est publié sous licence libre sous le nom de WombatGIS. Le code source du projet se trouve sur le dépôt Git de Champs-Libres et sur Github. Cette approche permet une certaine mutualisation du développement informatique : les développements futurs du logiciel seront mis à disposition du Parc gratuitement.

Logo de WombatGIS

Une version test est disponible (la carte interactive et interface d'administration) !

by Champs-Libres at September 18, 2014 03:00 PM

September 05, 2014

Champs Libres

Install mapnik 2.3 with the python plugin

Mapnik is a python librairy that creates png images from geographical sources like OpenStreetMap data, PostGIS databases and shapefiles. The librairy is mainly used to create the different map layers used in OpenStreetMap.

Mapnik can be extended with some plugins. One of this is the "python plugin" that allows to use python as a data source.

This article explain how to install mapnik with the python plugin for ubuntu 14.04. Indeed, the use of the python plugin installed with aptitude triggers a segfault. This segfault is generated by the boost librairy. The only way to use the python plugin is to reinstall boost with a patch and then to install mapnik from scratch. This post explains the method.

This article is based on this blog post and on this issue.

Install ICU

Follow the instructions from http://blog.jedf.com/2012/06/installing-boost-libraries-150-on.html but choose /usr/local as prefix.

cd icu/source
./runConfigureICU Linux --prefix=/usr/local --enable-static
make
make install

Install the Boost Librairy with the patch

Download and decompress the Boost Library source.

cd ~/Software/Boost
wget -O boost_1_56_0.tar.bz2 http://sourceforge.net/projects/boost/files/boost/1.56.0/boost_1_56_0.tar.bz2/download
tar -xvf boost_1_56_0.tar.bz2

Edit the file libs/python/src/converter/builtin_converters.cpp as described here.

The lines

void shared_ptr_deleter::operator()(void const*)
{
owner.reset();
}

must be replaced by

void shared_ptr_deleter::operator()(void const*)
{
PyGILState_STATE gil = PyGILState_Ensure();
owner.reset();
PyGILState_Release(gil);
}

Then, configure and install the Boost Library.

cd boost_1_56_0
./bootstrap.sh 
./b2 install --prefix=/usr/local

Install mapnik 2.3

Download mapnik.

cd ~/Software/mapnik
git clone https://github.com/mapnik/mapnik mapnik
git checkout 2.3.x
cd mapnik

Configure mapnik.

./configure
make

Install mapnik.

sudo make install

That's it !

P.S. This article was written a few months after the installation of mapnik. So it is possible that some steps are missing. Please contact us if it is the case.

by Champs-Libres at September 05, 2014 10:00 AM

September 01, 2014

Easter-eggs

Les labels PME ? 3 bonnes raisons de s'y intéresser - Bpifrance

Article publié le 1 septembre 2014 sur le site de bpifrance

Export, innovation, environnement… Les labels destinés aux PME se multiplient. À quoi servent-ils ? Sont-ils vraiment utiles ? À condition de bien choisir, la réponse est oui : un label peut apporter des avantages décisifs.

Trouver le label qui correspond vraiment au profil et à l'activité de son entreprise n'est pas simple. Les labels se multiplient et il est conseillé de bien valider sa démarche avant de se lancer. Le temps passé doit se justifier par des retours concrets. Surtout, rester dans le champ des labels officiels est plus que recommandé.

Pourtant, décrocher un label peut apporter de multiples avantages, que ce soit pour décrocher des financements, conquérir des nouveaux clients ou asseoir sa légitimité. Trois bonnes raisons de s'intéresser à une démarche de labellisation !

1. Décrocher des financements

« Notre premier objectif en demandant la labellisation « Économie sociale et solidaire » était de faciliter les démarches administratives pour l'obtention de prêts ou de subventions » explique Pierre-Yves Dillard, fondateur d'Easter Eggs, une SSII parisienne. Cette entreprise du Numérique Libre a opté pour un actionnariat constitué par les salariés, qui perçoivent tous le même salaire et élisent chaque année leurs dirigeants. Ce qui, précisément la rendait éligible au label ESS.
Accéder à des soutiens financiers est souvent la première motivation des PME qui tentent l'aventure d'un label. Cet aspect est par exemple inclus dans le label French Tech, qui sera accordé aux territoires innovants : les start-up sélectionnées de ces régions labellisées accéderont à des soutiens financiers et des accompagnements.

2.Développer ses réseaux et conquérir de nouveaux clients

Cultiver son réseau est aussi une finalité importante pour les PME candidates à la labellisation. « Intégrer des listings et être contacté par des entreprises sensibles à ce type de label. C'est ainsi que nous avons commencé à travailler avec de nouveaux clients, ce qui nous a positionné dans ce milieu professionnel », précise Yves Dillard. Dans le cas d'Easter Eggs, la reconnaissance de son statut « d'entreprise sociale et solidaire » lui a permis de cultiver son réseau.
Dans un autre domaine, le label RGE (Reconnu Garant de l'Environnement) est devenu tout récemment un avantage commercial officiel : un particulier qui voudra bénéficier des prêts à taux zéro et crédits d'impôts devra obligatoirement faire appel à une entreprise du bâtiment labellisée.

3.Intégrer une communauté d'entreprises

Au-delà des aspects commerciaux, le label a permis à Easter Eggs de rejoindre « une communauté de sens » estime son fondateur. Ce sentiment d'appartenance à une communauté fondée autour de la qualité, de la responsabilité sociale ou encore du respect de l'environnement a un impact important sur les salariés et sur tous les partenaires de l'entreprise, publics ou privés. Il valide l'image de compétence et de sérieux de l'entreprise.

Pierre-Yves Dillard, estime pour sa part que les labels doivent prouver leur valeur en appliquant des « critères de sélection stricts, assortis de contrôles systématiques, proche d'une démarche de certification. » Avec un bémol : la certification est une démarche plus coûteuse pour les PME, qui se justifie surtout pour des domaines très spécialisés. Plus généraliste, le label est aussi plus accessible. Ce qui ne l'empêche pas, s'il est bien choisi, d'apporter une longueur d'avance !

Lire l'article sur le site de la bpi france

September 01, 2014 01:59 PM

August 08, 2014

Champs Libres

Questionnaire pour un logiciel de suivi social

La coopérative Champs-Libres cherche à développer un outil informatique pour aider les travailleurs du secteur non-marchand dans leurs tâches administratives et de gestion. Elle lance un questionnaire pour mieux identifier les besoins.

MISE À JOUR Le questionnaire a été dépouillé en septembre 2014. Si vous êtes intéressés par le logiciel, nous vous conseillons de lire nos autres billets de blog, de surfer sur le site du logiciel ou de contacter Champs-Libres.

Simplifier l'accompagnement social

Un de nos clients nous a contacté pour répondre au problème suivant :

Chaque année, nous devons remplir des statistiques pour les pouvoirs subsidiants et réaliser un rapport d'activité. Cela nous prend énormément de temps de collecter ces informations.

Au quotidien, nous utilisons des tas d'outils différents : un dossier par personne, des agendas, etc. Pour compiler toutes les informations, à la fin de l'année, il faut tout reprendre, revérifier, etc.

Nous voudrions centraliser toutes les informations à un seul endroit - dans un programme informatique. Et que le programme se débrouille pour éditer nos statistiques, à la fin de l'année.

Nous voudrions aussi que ce programme remplisse des tâches comme transmettre des informations au sein de l'équipe, éditer les attestations qui nous sont demandées, etc.

Ce besoin est semblable dans beaucoup d'autres associations. Nous ne connaissons pas d'outils suffisamments efficaces à disposition.

Dès lors, le défi de concevoir un outil simple, ergonomique et efficace nous parait intéressant !

Notre projet: un logiciel libre

Champs-Libres est une société à finalité sociale. Notre but : promouvoir le logiciel libre.

L'application que nous développerions serait disponible sous licence libre : elle pourrait être ré-utilisée, partagée, améliorée, etc. Par tout le monde, à la seule condition que les améliorations soient également remises à disposition de tous.

Mais si c'est gratuit, vous allez gagner de l'argent comment ?

Nous voulons nous rémunérer par les moyens suivants :

  • En fournissant des versions hébergées à des associations qui ne veulent pas l'installer elles-mêmes, à un prix conforme à notre finalité sociale;
  • Et en développant des modules spécifiques à la demande de l'une ou l'autre association – modules qui, par la suite, seraient à disposition d'autres associations.

À côté de ça, le logiciel pourrait être téléchargé et installé gratuitement, par toute personne qui en a les compétences.

Le fait de développer un logiciel sous licence libre nous assure de sa plus large diffusion. Il y a d'autant plus de chances qu'il soit diffusé, réutilisé, amélioré et enrichi de nouvelles possibilités !

De quoi avons-nous besoin ?

Nous avons besoin de votre avis : plusieurs idées germent dans nos têtes. Nous voudrions savoir si elles sont pertinentes.

Nous voudrions également connaitre quelles sont vos craintes par rapport à ce genre d'outils, mais aussi en quoi il vous serait utile.

Et puis, surtout, nous voudrions être certains que cela va améliorer votre quotidien !

Comment pouvez-vous nous aider ?

En remplissant le questionnaire ici.

Aucune question n'est obligatoire mais plus vous serez précis, plus cela nous aidera.

Vous ne serez pas obligés de vous identifier, mais cela vous sera proposé à la fin du questionnaire, si vous êtes d'accord.

by Champs-Libres at August 08, 2014 03:00 PM

August 01, 2014

Code Lutin

RRLL2014 - Demandez le programme

Après le succès de la première édition, les Rencontres Régionales du Logiciel Libre reviennent cette année à Nantes en s'ouvrant au secteur privé.

Retrouvez-nous le 19 septembre 2014 au Centre des Expositions de Nantes Métropole (2 cours du Champs de Mars) pour découvrir le monde des TIC libre et Open Source au travers de conférences et tables rondes.

Vous pourrez retrouver notamment:

  • Patrice Bertrand (Président du CNLL)
  • Nicolas Jean (Inno3)
  • Benjamin Kaiser (Convenant)
  • Damien Raude-Morvan (Dictanova et Debian)
  • Romain d'Alverny (Hupstream)
  • La Gendarmerie (en attente de confirmation)
  • Mozilla (en attente de confirmation)

Le programme complet :

  • 8h45 : Accueil des participants
  • 9h-9h40 : Ouverture + présentation des stands
  • 9h45-10h30 : Table-ronde : Qui fait le logiciel libre ?
  • Pause
  • 11h-11h45 : Conférence Cloud/mobilité
  • 11h45-12h30 : Table-ronde : Le libre, la clé de voûte de votre SI
  • Cocktail déjeunatoire
  • 14h-14h45 : Table-ronde : La conduite du changement
  • 14h45-15h45 Solutions libres made in Nantes : à la découverte de projets locaux innovants.
  • Pause
  • 16h15-17h Retour d'Expérience : Mise en place d'une solution métier de la gestion de production au portail interne en finissant par le ecommerce
  • 17h Clôture

Ces rencontres s'adressent aussi bien aux services informatiques qu'aux directions métiers qui trouveront des réponses à leurs problématiques techniques et besoins fonctionnels. Les RRLL sont ainsi l'occasion de rencontrer des administrations, collectivités, industries et entreprises ayant déployé des solutions libres ainsi que les prestataires locaux.

Les Rencontres Régionales du Logiciel Libre sont une série d’événements dans toute la France organisés sous l'égide du Conseil National du Logiciel Libre (CNLL). Les RRLL de Nantes sont inscrites dans le cadre de la Nantes Digital Week sous la supervision de Nantes Métropole.

Plus d'informations et inscriptions sur le site : http://rrll.alliance-libre.org/

by couteau at August 01, 2014 02:33 PM

July 30, 2014

Azaé

Retour d'expérience sur l'intégration de Docker en entreprise

Imaginons une entreprise : plus de 800 millions de CA et plus de 6 000 salariés. Dans cette entreprise, les gens en charge de l'intégration et de la bonne exécution des serveurs sont dans une situation difficile : mettre à jour un serveur pour les besoins d'une application représente un cout exorbitant, l'impacte sur les autres services n'est pas maitrisé et les tests impactent la production de l'entreprise. Pour réduire les risques et facilité la maintenance, cette entreprise a décidé de nous demander conseil.

Pourquoi Docker ?

Comment cloisonner plus d'une trentaine d'applications web réparties dans une dizaine de tomcats sur seulement quelques serveurs ? La première réponse était : virtualisation ! Migrons chaque application dans un serveur et dupliquons le pour garantir la haute disponibilité et... dupliquons-le pour monter en charge. On arrive rapidement à plusieurs dizaines de serveurs à maintenir sans outil de gestion de configuration centralisé comme puppet, chef ou CFEngine. Pour les financiers, c'était aussi un problème, la supervision est externalisé et facture à l'alerte, mais aussi au nombre de serveurs surveillés. Donc nous avions deux options, monter un gestionnaire de configuration de machines et le brancher sur les nouvelles machines ou monter du Docker. Les contraintes financières ont finalement tranché, Docker avait gagné.

Question d'organisation

Dans cette entreprise, les études s'occupent d'acheter, de développer ou de paramétrer les applications métiers et les équipes de "Run", s'occupent de les faire fonctionner. Les études ont donc besoin de pouvoir faire tourner un grand nombre d'applications en cours de paramétrage ou de développement. Côté production, il faut industrialiser le déploiement et le suivi d'un grand nombre d'applications. C'est en effet cette équipe qui s'occupe à la foi du déploiement et de la bonne marche de l'ensemble des applicatifs métier et système.

La première étape de l'accompagnement a permis la mise en place de Docker côté production.

Architecture choisi

Tous les choix ont été fait avec l'équipe de production, en prenant en compte leurs compétences, les outils de supervisions et les procédures déjà en place, ainsi que les contraintes de licences.

Infra

Les machines de recette servent à la fois à déployer les applications en mode mono-instance pour une première validation et à construire les containers versionnés qui seront déployés en pré-prodcution puis en production.

Tous les containers sont archivés sur la registry. L'ensemble des serveurs savent lire dans la registry pour récupérer la dernière version des containers.

Tous les serveurs sont identiques... à l'exception des points suivants :

  • les machines sont branchés sur le bon vlan : recette, pré-production et production
  • les habilitations de l'active directory permettent de filtrer les accès aux serveurs
  • les machines de production sont en Red Hat alors que les autres sont des CentOS

Détail serveur Si l'on regarde en détail un serveur on peut voir que le point d'entrée utilisateur c'est un apache en mode reverse-proxy http préconfiguré pour faire du cache. En dessous, tous les tomcats présentent les mêmes interfaces :

  • le port 8080 qui permet de contacter le tomcat en http
  • un volume /var/log/tomcat qui permet de récupérer l'ensemble des logs applicatifs

Une politique de version

Le container apache qui est en entrée de serveur Docker est versionné et il embarque un fichier yaml qui décrit l'ensemble des versions de tous les containers tomcats à démarrer sur l'ensemble du parc. L'objectif de ce fichier est triple :

  • maintenir une vision global de référence de la plateforme
  • permettre l'auto-configuration de chaque serveur
  • simplifier les changements de versions applicatives

Une fois la plate-forme mise en place, nous avons adopté le workflow d'utilisation suivant : la production reçois un war et des éléments de configuration la production construit un container avec tous les éléments de conf pour tous les environements. Elle y apporte toute son expertise (sécurité, normalisation, etc.) la production publie le container sur la registry avec un numéro de version la production met à jour le container apache de référence la production déploie la dernière version du container apache de référence ce qui a pour effet de déployer les bonnes versions de container tomcat une fois la recette validée, il est possible de déployer la dernière version du container apache de référence * une fois validé en qualification l'exploitation va déployer en production

Comme chaque container est versionné le retour arrière est très simple, il suffit de relancer l'ancien container.

Et après ?

La prochaine étape va être de déployer boot2docker dans les équipes études. Ainsi, tout le monde utilisera les mêmes outils. Les premiers tests seront faits avec des containers, comme en production. Faire confiance, c'est bien... "Mais si les études nous foirent la conf, c'est nous qui allons perdre nos primes !" Pour éviter ça, l'équipe de production gardera la main sur la génération du container qui partira en production, mais partagera avec les études l'ensemble des définitions de containers à travers l'outil de gestion de version de l'entreprise. L'objectif, très devops, est d'amener les études et la production à collaborer sans avoir peur pour leurs responsabilités.


Photo par Gundy

by Thomas Clavier at July 30, 2014 10:00 PM

July 28, 2014

Azaé

Ouverture de la béta de Deliverous

Cela fait maintenant quelques semaines que nous vous avons invité à vous inscrire pour être prévenu de l'ouverture de la bêta ... Et bien voilà depuis ce matin, pour un certain nombre d'entre vous, une fois identifié sur le site de Deliverous vous pouvez cliquer en haut à droite sur votre nom pour arriver sur votre page de profil.

Nous vous invitons à travers ce post à découvrir ce qui se cache derrière les quelques écrans auxquels vous pouvez accéder.

Votre profile

La page de profil vous affiche quelques informations personnels illustrées par votre gravatar. Vous y trouvez aussi la liste de vos projets. Plus tard, vous y trouverez probablement l'historique de vos factures.

Des projets

Le projet est l'élément central, il est archivé dans un git et le fichier Deliverous présent à la racine du git permet de le décrire. Un projet est généralement constitué de plusieurs applications qui cohabitent pour former un système capable de rendre un service à vos utilisateurs. Par exemple il est possible de décrire un projet avec un container pour faire l'équilibrage de charge devant N containers php qui utilisent N containers Redis pour stoker les données.

Le fichier Deliverous

Le fichier Deliverous permet de decrire la liste des containers et leur organisation. Il est actuellement au format YAML.

blog:
  image: deliverous/blog
  ports:
  - ip: blog-addr
    host_port: 80
    container_port: 80

Ce fichier Deliverous va démarrer notre blog sur nos infrastructure. Il sera joignable sur l'adresse IP nommée blog-addr dans les IP de votre projet.

La directive 'environment' permet de spécifier des variables d'environnements pour le container. Exemple :

container:
  image: ...
  environment:
    VAR: value

La directive 'links' permet de lier plusieurs containers, comme la directive link de docker. Exemple :

front:
  image: ...
  links:
  - name: mysql
    alias: db

mysql:
  image: ...

Des triggers

Les triggers ou webhooks dans le jargon des hub http sont là pour déclencher à distance le déploiement de votre projet. Attention, pour l'instant, déclencher un déploiement entraine une coupure de service.

Comme votre projet peut regrouper plusieurs sources : nombreux dépôt git et nombreuses images de containers, il est possible de créer plusieurs triggers. En confiant un trigger à chaque fournisseur, il est possible de limiter les risques en cas de corruption de l'un d'entre eux.

Ces webhooks ont été testés avec le hub docker ainsi qu'avec github. Si vous utilisez ces services, il est très facile de déclencher un déploiement suite à la modification du fichier Deliverous ainsi que chaque fois que l'un des containers est reconstruit.

Si vous préférez la ligne de commande vous pouvez utiliser curl ou wget :

curl -X POST -data="" http://api.deliverous.com/trigger/12345678-abcd-123456789-abcdefghijkl
wget --post-data="" http://api.deliverous.com/trigger/12345678-abcd-123456789-abcdefghijkl

Des IPs

Les adresses IPs sont les points d'entrées de vos utilisateurs sur votre projet. Durant la béta, il est possible de n'avoir qu'une IP par projet.

Et maintenant ?

Infra Maintenant que la béta s'ouvre un peu plus, nous attendons avec impatience vos remarques et suggestions sur les choses les plus importantes à vos yeux qu'il faudrait implémenter. Concient que le travail est loin d'être terminé, nous aimerions avoir votre avis pour ordonner les évolutions à venir. Nous vous invitons à rejoindre la mailing liste pour poursuivre les échanges.


Photo de tableatny

Illustration Superdupont

by Thomas Clavier at July 28, 2014 10:00 PM

July 09, 2014

Azaé

Comment installer et exploiter Docker sur Red Hat ou CentOS

Alors que Docker est développé sous ubuntu et principalement empaqueté pour debian et ubuntu, il est courant de trouver en entreprise des parcs entier de serveurs sous Red Hat ou CentOS. Comment faire dans ces conditions pour y déployer Docker ?

À travers cet article, je vais vous montrer les recettes que j'ai mises en place pour déployer de nombreux serveurs Red Hat 6.5, d'autres en CentOS 6.5 et des containers CentOS.

Docker et Red Hat

Commençons par un peu de techniques, par défaut Docker utilise Aufs pour gérer les layers des images. Seulement Aufs n'est pas compatible SELinux, or Red Hat garantie la compatibilité totale de la distribution avec SELinux. Si l'on s'arrête là, l'utilisation de Docker sur CentOS ou Red Hat est totalement impossible. Mais depuis septembre 2013, Red Hat et Docker travaillent ensemble pour produire une version compatible. Le résultat est là, depuis la version 0.7 de Docker il est possible d'utiliser device-mapper comme backend pour gérer les layers des images.

Docker utilise lxc et les cgroupes pour isoler les containers entre eux, or c'est une portion du noyau Linux qui bouge beaucoup. Un certain nombre de corrections lié aux cgroups ont été intégrés dans le noyau de la Red Hat 6.5. Il est donc vivement recommandé d'utiliser la dernière Red Hat ... J'écris ça alors que la 7 est disponible depuis presque 1 mois, seulement dans de nombreuses entreprises changer le socle Linux est un gros projet, donc la dernière Red Hat disponible se limitera à la 6.5 :-D

Red Hat ou CentOS ?

Ça commence par une histoire de licence, d'argent, de niveau d'expertise ... Et ça finit par un choix. En bref, l'histoire du jour s'inspire d'un master en Red Hat 6.2, à migrer en CentOS pour appliquer les mises à jour et de temps en temps à remettre en Red Hat avant l'enregistrement sur le rhn.

Migration en CentOS

Les différences entre CentOS et Red Hat sont faibles, il est facile de passer de l'une à l'autre, voilà comment passer une RedHat en CentOS :

mkdir /tmp/centos
cd /tmp/centos
wget http://mirror.centos.org/centos/6.5/os/x86_64/RPM-GPG-KEY-CentOS-6
wget http://mirror.centos.org/centos/6.5/os/x86_64/Packages/centos-release-6-5.el6.centos.11.1.x86_64.rpm
rpm --import RPM-GPG-KEY-CentOS-6
sed -e 's/$releasever/6.5/g' -i /etc/yum.repo.d/CentOS-Base.repo
rpm -Uvh --force *.rpm
rpm -e redhat-release-server-6Server-6.4.0.4.el6.x86_64
yum -y upgrade

Docker

Installation de Docker

Pour installer Docker, il faut brancher la machine sur le répo EPEL :

cd /tmp/centos
wget http://epel.mirrors.ovh.net/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -Uvh epel-release-6-8.noarch.rpm
yum -y upgrade

Puis installer Docker:

yum install docker-io

Enfin, ne pas oublier de relancer le serveur pour prendre en compte le nouveau noyau.

Une registry privée

Déployer une registry privé, c'est possible. Même si Docker fait beaucoup pour que l'on utilise le hub Docker ils fournissent aussi un container de registry. L'objectif est de garder l'ensemble des containers dans la société, bien à l'abri des regards indiscrets. Pour avoir de la haute disponibilité, dans le cas présent nous avons choisi d'installer la registry sur un serveur virtuel dédié. En utilisant la flexibilité de la virtualisation il est possible de garantir un bon niveau de service sans avoir à multiplier les instances de registry.

mkdir -p /srv/registry

éditer /srv/registry/config.yaml

common:
    loglevel: info

prod:
    loglevel: info
    standalone: true
    storage: local
    storage_path: /srv/registry/data
    secret_key: 58555486803be0218c63cd626d5e0117
    search_backend: sqlalchemy
    sqlalchemy_index_database: sqlite:////srv/registry/docker-registry.db

Création d'un script de lancement

wget https://raw.githubusercontent.com/tclavier/scripts/master/centos/docker_container_init_script  -O /etc/init.d/registry

éditer /etc/init.d/registry

NAME=registry
VERSION=latest
CONTAINER=$NAME:$VERSION
CONTAINER_OPTS="-p 80:5000 -v /srv/registry:/srv/registry -e DOCKER_REGISTRY_CONFIG=/srv/registry/config.yaml -e SETTINGS_FLAVOR=prod"

La registry est lancé par un script d'init standard :

/etc/init.d/registry (start|stop|restart)

Conclusion

Arrivé là, vous avez un serveur Docker avec une registry, de quoi rapidement monter un environnement pour démontrer par l'exemple de la viabilité de Docker. L'étape suivante, qui sera le sujet d'un autre article, consiste à trouver la façon de travailler avec Docker qui apportera le plus à l'entreprise.


Le logo est la propriété du projet CentOS

by Thomas Clavier at July 09, 2014 10:00 PM

June 17, 2014

Easter-eggs

Ticketing avec Request Tracker "RT"

Suivi d'actions et gestion d'incidents

Request Tracker est un logiciel libre édité par la société « Best Pratical Solutions » sous licence GPL. RT est le logiciel libre de référence pour les helpdesk en matière de gestion d'incidents. Il est utilisé par de nombreuses entreprises ou organisations parmi lesquelles : la NASA, Merrill Lynch, Freshmeat, Free Telecom,... (voir la liste)

Fonctionnalités par défaut

Request Tracker
  • déclarer un incident ;
  • assigner un responsable en charge de répondre ;
  • organiser et suivre le processus de réponse ;
  • les actions peuvent se faire via l'interface web ou bien via l'envoi d'un mail ;
  • historique complet des actions et de toutes les modifications entreprises ;
  • décompte du temps consacré ;
  • moteur de recherche / extraction des informations / affichage sous forme de graphiques ;
  • moteur d'états ;
  • interface multi-utilisateurs et traduction en de nombreuses langues ;
  • support de nombreux types de bases de données relationnelles (MySQL, Oracle, PostgreSQL, etc...).

Personnalisation

La plus grande force du logiciel est sa capacité de personnalisation :

  • champs personnalisables (« Custom Fields »), il s'agit d'attribuer des champs de différents types à un événement ;
  • scripts (« Scrips »), il s'agit d'un système de macros déclenchées en fonction d'un événement ;
  • une multitude d'options de configuration ;
  • une architecture modulaire.

Déroulement d'un intégration RT par Easter-eggs

Rédaction d'un cahier des charges

Un ingénieur Easter-eggs étudie vos besoins afin de déterminer :

  • la pertinence de l'utilisation de RT ;
  • la faisabilité d'un déploiement dans votre système d'information ;
  • la configuration spécifique de l'outil ;
  • les éventuels développements d'intégration.

Rédaction des spécifications fonctionnelles et techniques

Sur la base du cahier des charges, l'ensemble des configurations et des développements est décrit et validé par le client.

Une fois ces deux phases passées, Easter-eggs déploie l'outil et procéde à la recette fonctionnelle de l'application sur la base du cahier des spécifications fonctionnelles.

Support et assistance

Easter-eggs assure ensuite le suivi de la solution mise en place via un contrat spécifique adapté et dimensionné à chaque instance déployée.

Hébergement et mode "Saas"

Easter-eggs peut vous proposer d'héberger votre plateforme RT, dimensionnée selon vos exigences en matière de disponibilité et de sécurité.

L'expertise RT chez Easter-eggs depuis plus de 10 ans

Easter-eggs utilise RT au quotidien depuis 2001. Nous l'avons intégré dans notre solution de gestion de support et assistance client.

Notre force est notre capacité à intégrer RT en le personnalisant à chaque client. Voici les dernières intégrations réalisées :

  • Easter-eggs a intégré RT pour une multinationale de 11000 personnes leader sur le marché de la sécurité électronique. L'outil est spécifiquement adapté au système d'information du client avec le développement nécessaire d'un protocole permettant à RT de communiquer avec l'outil de helpdesk de HP OpenView Service Desk. Ce projet est détaillé dans notre article Passerelle Request Tracker OpenView Service Desk.
  • Request Tracker a été déployé chez W-HA, la filiale de micro-paiement en ligne de Orange par Easter-eggs. Une fois encore, la solution a été adaptée exactement au besoin du client.
  • La solution RT a été mise en place au sein du Ministère de l'écologie, de l'énergie, du développement durable et de la mer (MEEDAT), conjointement avec la maîtrise d'ouvrage nationale des politiques supports et des systèmes d'information.
  • Dans le cadre d'un projet de mise à jour et d'évolution de la plate-forme RT de l'Union Financière de France, une mise à jour d'une version 3.8.0 vers la 3.8.4 a été réalisée. Les données ont été converties en UTF-8. La disponibilité du service a été renforcée par le déploiement d' un serveur de secours qui réplique les données de la base en temps réel.
  • RT a été déployé et adapté pour le service qualité d'une PME. Il s'agit d'un détournement complet de l'outil en solution métier. Un article plus complet sur ce projet est disponible ici.

Nos principales références RT

  • Agence Nationale de l'Amélioration de l'Habitat - ANAH
  • Aviva
  • Axione
  • Cinetic Industry - Fives Lilles
  • CEA - DAM
  • CETE Normandie-Centre
  • Compagnie Européenne de la Chaussure
  • Gemalto
  • Groupe Mauffrey Transport
  • Ministère de l'Ecologie, du Developpement Durable, des Transports et du Logement
  • Netsize
  • Oxalide
  • SICIM - Montreuil
  • Vivarte
  • Wanadoo HA

by Valéry Febvre at June 17, 2014 04:46 PM

Opendata et e-Administration

La volonté affichée des pouvoirs publics d'utiliser dans leur fonctionnement toujours plus de logiciels libres a naturellement conduit Easter-eggs a travailler avec les collectivités teritoriales et les services de l'Etat.

Nous comptons aujourdh'ui parmi nos clients plus de 300 communes ou EPCI, 5 départements, 4 ministères et les services du Premier Ministre.

En plus des projets de développements spécifiques et d'architecture système hébergées, Easter-eggs développe et infogère 2 plateformes de services dédiées aux collectivités territoriales et aux services de l'État :

Comarquage.fr

Les démarches et formalités en co-marquage de service-public.fr : des outils clé en main et personnalisables, à intégrer en quelques clics dans les sites internet des collectivités territoriales et des services de l'Etat.

Données-libres.fr

L'Open Data au coeur de votre territoire : un portail Opendata, en co-marquage de data.gouv.fr et la cartographie de l'hyperlocal, à intégrer en 3 clics sur un site web existant.

June 17, 2014 02:46 PM

Tarifs

Engagée dans une logique de transparence vis-à-vis de ses clients, Easter-eggs publie ses tarifs selon une nomenclature reprenant les différents types de contrats qu'elle propose : contrat forfaitaire, contrat en mode régie, contrat d'assistance et de support. Les catégories 1, 2 et 3 correspondent respectivement à des profils de programmeurs, d'analystes programmeurs et de chefs de projet/experts.

Forfait Prix de journée HT

Catégorie 1 Catégorie 2 Catégorie 3
Développement 750 € 850 € 950 €
Administration Système et Réseau 800 € 900 € 1 000 €
Suivi de projet, gestion de la planification 900 €
Audit, Conseil, Direction de projet 1 400 € 2 000 €
NB : Nous appliquons une remise commerciale de 10% pour tous les développements placés sous licence GPL.

Régie Prix de journée HT

Catégorie 1 Catégorie 2 Catégorie 3
Développement 700 € 800 € 900 €
Administration Système et Réseau 750 € 850 € 950 €
Suivi de projet, gestion de la planification 800 €
Audit, Conseil, Direction de mission 1 000 € 1 500 €

Support Prix HT

Intervention sur site 800 € / jour
Administration distante 150 € / heure

by Valéry Febvre at June 17, 2014 12:29 PM

June 16, 2014

Easter-eggs

Hébergement et infogérance

Les briques de l'infogérance

Depuis le 1er septembre 2012, Easter-eggs a repris la société Nuxee, spécialiste de l'hébergement à valeur ajoutée. Ce rapprochement nous a permis d'intégrer de nouvelles compétences, mais aussi de nouvelles infrastructures et de nouvelles solutions.

Nous somme ainsi à même de proposer des réponses complètes aux problématiques clients, toujours en offrant un niveau de qualité de service et d'expertise élevé.
Easter-eggs propose des solutions d'hébergement sur mesure, tant sur les solutions dédiées (physiques ou virtuelles) que mutualisées.

Notre maîtrise des différentes technologies de virtualisation et nos compétences fortes en développement, audit, système et réseaux vous garantissent des solutions pérennes et évolutives. Nous sommes présents dans les datacenters Equinix PA2 et PA3 (Paris Saint-Denis).
Easter-eggs est membre du RIPE NCC. En tant que LIR (Local Internet Registries N° AS 199571) nous sommes autonomes pour le routage et la distribution des adresses IP.

Le réseau, compatible IPV6, est entièrement opéré par les équipes techniques en 24/7/365.

L'infogérance selon Easter-eggs

Un contrat sur mesure

Un catalogue de l'infogérance n'a selon nous aucun sens car chaque offre résulte de la combinaison de services adaptés au contexte et aux enjeux d'un projet client.


Supervision

La supervision est toujours assurée 24/7. Cela permet de connaître en temps réel l'état du réseau, des matériels, des services et des applications.
Les alertes de supervision peuvent être gérées par le client ou par nos équipes. L'important est d'avoir défini les rôles et périmètres d'action de chacun : qui déclenche l'intervention ? Qui intervient ? Les interventions ont-elles lieu 24/7 ? Sont-elles comprises dans un forfait ou facturées au temps passé ?, etc.

Mise à jour de sécurité

C'est un élément essentiel de l'administration d'un système GNU/Linux.
Ces mises à jour doivent être confiées à des experts du système, seuls juges de l'urgence à les appliquer. C'est pourquoi nous estimons que cette tâche relève de notre responsabilité.
Cette prestation peut être gérée forfaitairement ou par tickets.

Métrologie

L'analyse des données (flux, charges, etc.) permet d'anticiper des pannes matérielles, des évolutions à programmer ou des comportements non-prévus ou inadaptés de la plateforme ou des utilisateurs.
Les données de métrologie sont accessibles à nos clients en temps réel via notre extranet sécurisé. Le contrat d'infogérance peut prévoir une analyse systématique des données de métrologie avec un rapport régulier et les préconisations qui en découleraient.


Maintien en conditions opérationnelles - MCO

C'est pour nous une notion essentielle qui résume tout notre engagement, car nous garantissons le fonctionnement des services hébergés en production. Nous intervenons dans un cadre forfaitaire en cas de dégradation des conditions opérationnelles de la plateforme.
Cet engagement de notre part sur un MCO implique que nous soyons seuls habilités à nous connecter en tant qu'administrateur (root) sur le serveur en production.

Engagement de rétablissement de service (GTR)

Si les prestataires mettent les plus souvent en avant la garantie sur leurs délais d'intervention (GTI), l'enjeu pour nos clients est bien la garantie du temps de rétablissement. C'est le corollaire du maintien en conditions opérationnelles et il doit une fois de plus être adapté aux enjeux du client, qui doit évaluer les conséquences de l'indisponibilité de ses services et définir en concertation avec nous la GTR souhaitée.
Easter-eggs intervient 24/7 avec des GTI à partir de 30mn H0 et 1h HNO et des GTR à partir de 1h HO et 2h HNO. [1]

Pénalités financières en cas de dépassement

La mise en place d'une GTR courte aura des conséquences sur le coût mensuel de l'infogérance. En contrepartie, le non-respect de la GTR par le prestataire doit être compensé par l'application de pénalités de retard significatives pouvant aller jusqu'au remboursement d'une année due au titre de l'infogérance.


Sauvegarde

La sauvegarde n'est pas une option de l'infogérance mais la garantie d'une reprise d'activité rapide en cas de problème majeur. C'est aussi au quotidien une sécurité pour les utilisateurs, afin de se prémunir de la perte de fichiers ou de courriels. Il convient d'adapter le volume nécessaire et la politique de sauvegarde en fonction des besoins du client.

Présentation de l'infra Easter-eggs

Les datacenters Equinix

Sécurité

Le datacenter utilise un ensemble d'équipements, de techniques et de procédures de sécurité pour contrôler, surveiller et enregistrer l'accès aux installations. La procédure d'accès sécurisée ISO9001:2008 doit être suivie par le personnel d'Equinix et les visiteurs.

Corridor Easter-eggs chez Equinix

Corridor Easter-eggs chez Equinix

  • Sécurité 24x7x365 sur site ;
  • Gardien en H24 ;
  • Système de caméras périmétriques ;
  • Système d'accès par carte magnétique (accès logged et timestamp) et empreinte biométrique ;
  • Confrontation à un fichier photographique pour chaque personne entrant sur site ;
  • 4 contrôles successifs avant d'entrer dans le datacenter ;
  • Toutes les portes, y compris celles des cages, sont sécurisées par des lecteurs palmaires ;
  • Murs extérieurs pare-balles ;
  • Eclairage à détecteurs de mouvement.

Refroidissement

Le système de refroidissement du datacenter fait lui aussi preuve d'une attention particulière. Les infrastructures d'Easter-eggs sont hébergées dans des "Cold Corridor".

  • Production de froid à eau glacé ;
  • 4 groupes de 1,1 KW centralisés en N+1 situé sur le toit du bâtiment ;
  • Production de froid centralisé avec redondance N+1 ;
  • Huit pompes d'eau condensée (N+2) ;
  • Huit tours de refroidissement ;
  • Six pompes primaires à eau refroidie et débit variable (N+2).

Courant

Le datacenter d'Equinix est conçu avec des systèmes d'alimentation électrique qui disposent de redondance intégrée et systèmes d'alimentation électrique sans interruption (UPS).

  • Double arrivée EDF/1+1 ;
  • Groupe électrogène redondé (N+1) ;
  • 8 groupes électrogènes de 2MVA centralisés en N+2 ;
  • Plusieurs onduleurs de 500KVA répartis sur 3 chaînes 1 situés dans des locaux différents.

Support

En complément de ces installations, Easter-eggs peut faire appel à un support technique sur site disponible 24x7x365.

Une architecture multi-sites et multi-opérateurs

Site Equinix PA2 : opérateur Neo Telecoms (AS 8218)

Neo Telecoms est le second opérateur IP international d'origine française et le premier opérateur IPv6 Français en terme de connectivité Internet.
Le réseau, compatible IPV6, est entièrement opéré par les équipes techniques en 24/7/365. Neo Telecom est raccordé aux principaux points d'échange du marché en France et en Europe ainsi que sur les côtes Ouest et Est des États-unis.

Voir le réseau en temps réel

Voir le réseau en temps réel

Le réseau repose sur des équipements Juniper gamme MX/Terabit avec une capacité de plusieurs centaines de gigabit/s.

Site Equinix PA3 : opérateur Ielo (AS 29075)

Ielo bénéficie de plus de 10 ans d'expérience dans le domaine de l'externalisation et de la gestion d'infrastructures internet.
IELO dispose d'équipements et de connectivités dans les principaux points de présence Français et dans les points d'échange Français et Européens.
L'ensemble du réseau s'articule autour d'équipements Foundry et Brocade. Chacun des sites dispose d'équipements disposant d'au moins deux modules de management et de deux modules de commutation.
Le réseau de IELO repose essentiellement sur deux boucles ethernet (parisienne et nationale) raccordées sur deux sites distincts (Redbus Courbevoie et TeleHouse 2 Voltaire).

Principales références en infogérance et hébergement

  • Adoma,
  • Conféderation Nationale des Syndicats Dentaires,
  • Mairie de Paris,
  • Laforêt Franchise,
  • Enercoop,
  • Comarquage.fr,
  • Agence du Numérique,
  • Ministère de la Justice,
  • Ministère du développement durable,
  • Dalloz Formation,
  • Eparco,
  • Lexbase,
  • Observatoire Européen de l'Audiovisuel,
  • Onisep,
  • Ministère de la Santé,
  • Paraweb,
  • Le département du Nord

[1] Rappelons qu'une GTR courte doit être en cohérence avec l'architecture couverte. Easter-eggs engagera sa responsabilité sur des délais courts si par ailleurs la plateforme cible présente des garanties en matière de redondance, aussi bien matérielle que logicielle.

by Valéry Febvre at June 16, 2014 10:14 AM