Conférence dotScale

Salut les Poires!

Bon alors un petit post sur la conférence à laquelle j'ai assisté vendredi 7 juin à Paris.

Les dotConferences sont des conférences du style TEDTalks mais très orientées développement avec à chaque fois un thème particulier et dont le prix reste raisonable. Il y en a par exemple sur le JavaScript ou encore le Ruby. Cette fois cela portait sur les architectures distribuées et les applications dans les nuages °o° !!

Il y avait des intervenants assez incroyables comme par exemple le créateur de Apache Hadoop (il existe réellement sous forme humaine si si, mais il avait la voix cassée....), l'un des fondateurs du projet OpenStack (qui était nommé "Pinet" au départ, mais bon ça ne sera pas la première ni la dernière fois qu'un papa un peu saoul se trompera de nom en allant déclarer son bébé à la préfecture, car oui selon lui la culture des gens d'OpenStack repose sur l'alcool...), le CEO d'Heroku et plein d'autres...

La conférence s'est déroulée au Théâtre des Variétés dans le 1er arrondissement, autant dire que c'était un cadre parfait, mais sans plus attendre voici un petit résumé de ce qui a été dit au cours de cette conférence :

Intervention 1 : Quentin Adam (Clever Cloud) → une startup nantaise ^^

Lignes de conduite pour le développement d'applications distribuées et réparties

→ Scale out vs scale in (ou comment augmenter la qualité de service en répartissant son application sur une architecture distribuée comportant de nombreux serveurs de performances correctes, plutôt que de la faire fonctionner sur un faible nombre de nœuds ayant de hautes performances)

• Stateless is the key
• Split data and processes : il faut séparer en des couches bien distinctes le code qui accède au données de celui qui réalise des traitements et des calculs sur ces données.
  
• The choice of database requirements is linked to the type of data : chaque système de gestion de base de données présente des caractéristiques qui lui sont propres et qui font qu'il sera plus à même de gérer un type de données bien précis. Pourquoi utiliser un système de gestion base de données relationnel si l'on ne souhaite stocker qu'un ensemble de clés-valeurs? Il faut choisir un système de gestion de bases de données correspondant bien au type de données que l'on souhaite stocker.
  
• The choice of technology must be related to needs and requirements : il faut choisir la technologie que l'on utilisera en fonction de ce que l'on veut réaliser et pas l'inverse. Pourquoi utiliser tel langage de programmation si un autre permet de réaliser la même chose plus simplement ou plus rapidement?
  
• Avoid data storage in RAM : la mémoire vive n'a jamais été faite pour pérenniser des données, on peut lire ou écrire rapidement des données en mémoire RAM certes, mais il s'agit d'une mauvaise pratique. A la rigueur, il vaut mieux utiliser la RAM comme cache pour les accès rapides.
  
• Code will fail : lorsque l'on code, toujours penser que des erreurs apparaîtront, aucun code n'est sûr, il faut donc être certain de pouvoir réparer les éventuels bugs et de pouvoir rétablir le système le plus rapidement possible.
  
• Never store data in the file system
• Be careful with frameworks (only use them when you know exactly what they do) : il faut faire attention à l'utilisation de frameworks, il est possible de les utiliser seulement si l'on sait ce qu'il exactement, sinon il vaut mieux coder les choses soi-même.
  
• Split code in modules : autrement dit diviser pour mieux régner. Un programme dont le code est réparti en différents modules et bien structuré sera plus agréable à lire, plus simple à réparer et plus facile à modifier.
  
• Choose a good Event Broker (avoid Cron)
• Don't make hard and complex asynchronous code : le code asynchrone trop complexe est très difficile à comprendre pour l'homme, il est donc difficile à maintenir et présente une forte probabilité d'échouer.
  
• Put a proxy in front of the Application : en ajoutant un proxy devant l'application web il sera plus simple de gérer les accès au site.
  
  

Intervention 2 : Thomas Stocking (Gandi.net)

Challenge of large scale multi-tenancy, une problématique rencontrée au sein des infrastructures de Gandi.net.

VNT : Virtual Network over TRILL

TRILL : offers the best of Layer 2 and 3

The VNT solves the problem of VLAN exhaustion (limited to 4096 hosts).

Le projet deviendra Open Source d'ici peu.

Intervention 3 : Noah Zoschke (Heroku)

Architecture of Heroku PaaS (Platform as a Service)

6. Heroku LXC Container

5. Ubuntu and cgroups (pour fournir des espaces de ressources aux utilisateurs)

4. Xen hypervisor

3. Amazon Linux – paravirtual API

2. Intel CPU (instruction set)

1. Physics (matter, time, space)

Pourquoi cette architecture :

• Complexité
• Performances
• Possibilités de configuration
• Visibilité

Mais en contre partie des problématiques de :

• Efficacité de mise en œuvre
• Sécurité
• Expressivité
  
  

Intervention 4 : Jonathan Weiss (Scalarium, Amazon Web Services OpsWork)

Things will break → embrace and plan for failure : en développement rien n'est sûr à 100%, il faut toujours s'attendre à ce que les choses plantent et tout mettre en œuvre pour limiter les dégats.

Divide and Conquer : en séparant les choses, il est plus simple de les maîtriser.

Limit the blast radius → Isolate and compartmentalize : en isolant les composants, les dégâts sont souvent limités en cas de problème.

Automate and practice hard things : en automatisant et mettant en pratique régulièrement les tâches complexes, il est plus simple de mettre ces mécanisme en action en cas de crise.

Replace your fleet all the time : en changeant régulièrement l'ensemble des VM sur lesquelles est hébergée l'application, il sera plus simple de déployer l'application de manière efficace au fur et à mesure.

Backup and restore all the time : le processus de restauration du système sera efficace

→ Until tough things are easy : à terme, les choses difficiles deviendront simples et faciles à mettre en place.

→ Think about the crazy monkey : l'image du singe fou détruisant tout parce qu'il fait n'importe quoi est à garder à l'esprit pour envisager le pire des cas et donc mettre en place des barrières et solutions de secours.

→ Monitoring and measuring as a basis : la supervision est à la base de cette démarche, elle permet de savoir comment l'application fonctionne, comment elle est utilisée, quelles sont ses faiblesses et quels sont les choses à améliorer.

→ Auto Scaling : l'objectif final étant de disposer d'une application auto-scalable, où il suffit d'ajouter des noeuds pour que l'application supporte une plus grosse charge de travail.

Intervention 5 : Mandy Waite (Google)

Ça c'est pour Aurélien!

Device Cloud (ensemble d'appareils de mesure et de sondes distribué)

Exposé sur la mise en place de très nombreux systèmes munis de capteurs (température, son, qualité de l'air...) dans les bâtiments accueillant le Google I/O lors des jours de l'évènement. Les cellules de mesure sont réalisé grâce à des systèmes Arduino munis de capteurs et connectés grâce à un protocole de communication sans fil spécifique permettant d'utiliser une très large gamme de fréquences pour éviter les interférences.

L'acquisition des données et les opérations et traitements qu'elles ont subit ont été réalisées en utilisant les technologies de Google :

• App Engine pour l'hébergement de l'application
• Data storage : pour le stockage des données
• BigQuery pour effectuer les requêtes vers ces données
• Compute engine pour effectuer les calculs complexes

En cadeau le lien vers le code source et les résultats de l'expérience : data-sensing-lab.appspot.com

Ouvrage utilisé pour faire l'expérience : Building Wireless Sensor Networks

Intervention 6 : Salomon Hykes (dotCloud, Docker)

Docker : the portable container engine → très (trop?) prometteur, en tout cas mon coup de coeur de la conférence

What is it?

La problématique à laquelle veut répondre Docker est de transférer une application d'une machine A vers une machine B automatiquement et de manière fiable.

Conteneurs existants :

• jar, rvm, virtualenv → pas toujours compatible avec tous les systèmes
• machines virtuelles → trop lourdes, trop de composants, trop lent

Docker → the best of both worlds :

• complete sandbox
• works with all languages and dev tools

Docker a pour ambition de s'imposer comme un format standard de conteneur et le projet est open source.

Les développeurs construiront des conteneurs et ces conteneurs seront ensuite déployés sur l'infrastructure directement. 

 

Flash Talk : Tugdual (CouchBase) → il vient de Nantes

Explication et analyse de la chute de OMGPOP.

Intervention 7 : Shay Benman (ElasticSearch)

Valorisation des données (Data Zen) -> là je digérais mon repas, donc je n'ai pas noté grand chose...

Intervention 8 : Brad Fitzpatrick (memcached, OpenId, LiveJournal)

Travaille aujourd'hui pour Google.

Développement en Go! (langage de Google).

A présenté :

Chubby lock service (Distributed Lock Manager) : est utilisé pour gérer les accès concurrents à des ressources partagées. Le système sert également comme serveur de nommage chez Google, devant DNS.

Doozer : système de stockage de haute accessibilité pour les données de haute importance.

Bitcoin : nouveau système de monnaie électronique internationale

Camlistore.org : un projet de système permettant de stocker, synchroniser et partager du contenu. 

 

Intervention 9 : Barry Abrahamson (WordPress)

Présentation des mauvaises expériences techniques de WordPress face à l'augmentation rapide du nombre d'utilisateurs.

Par exemple trop d'utilisateurs, trop de tables relationnelles de données, trop de fichiers → changement du moteur de gestion (MyIsam → InnoDB).

Introduction de HyperDB, Static Asking, Dynamic Assignment...

Conclusion : Lors du lancement d'un projet ambitieux, il est impossible de définir parfaitement l'architecture d'une application et de faire les bons choix technologiques. Il faut certes, créer une base cohérente et qui répond aux besoins mais il y a aura toujours des imprévus qui apparaîtront et ce n'est que lorsqu'on les rencontre qu'il faut prendre les bonnes décisions.

Intervention 10 : Doug Cutting (Hadoop, Apache foundation)

Présentation des projets open source de la fondation Apache réalisés en partant des résultats de recherche ou des projets propriétaires de Google.

Hadoop MapReduce et Hbase après Google MapReduce et BigTable par exemple.

Nutch : moteur de recherche open source

Hive et Pig.

Intervention 11 : Joshua McKentie (OpenStack)

Conway's law : "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". Pour que deux modules d'un programme implémentés par deux programmeurs ou groupes de programmeurs distincts s'interfacent correctement, il faut que les deux programmeurs ou groupes de programmeurs communiquent correctement. Autrement dit, l'interfaçage entre deux module d'un code reflète la qualité de la communication entre les personnes ayant produit ce code.

Présentation d'une théorie sur la qualité des logiciels open source.

La qualité d'un code open source repose sur la communauté et la qualité de la communauté repose sur la culture commune au groupe.

L'authenticité d'un projet lui permet de se développer et de réunir une communauté.

Les noms des projets ont un impact sur le développement d'un projet. OpenStack était nommé Pinet au départ pour Python Network... les créateurs ont commencé à discuter du projet dans un bar.

Le plus important est de pouvoir déployer et mettre en place le produit à terme.

Ensuite, le mec a terminé la présentation par un petit spectacle de jonglage...

Bonne nouvelle! les photos et vidéos de la conférence seront bientôt accessibles depuis le site web de l'événement.

Les diaporamas des présentations seront normalement disponibles sous peu sur ce site.

Voili Voilou, bonne nuit les petites poires...

Ne pas perdre l'adresse IP de sa maison

Un truc que j'adore faire avec mon raspberry pi, c'est pouvoir me connecter en ssh depuis l'extérieur. Avoir un petit serveur comme ça chez soi, c'est très pratique pour héberger ses données, avoir son petit dépot git à soi, monter son propre serveur... Il suffit de connaitre son adresse IP (et d'avoir une redirection de port sur son routeur) et c'est parti. Le soucis, c'est si vous avez une adresse IP dynamique. En pratique, bien sûr l'adresse change très rarement, mais il suffit d'une coupure de courant pendant que vous êtes à l'autre bout de la France et vous perdez contact avec votre chez vous. Alors si vous êtes un peu parano comme moi, vous aimeriez bien que votre maison vous dise quand l'ip a changé.

Je partage donc un petit script que j'ai réalisé en python 3. Il vérifie que l'adresse IP n'a pas changé depuis sa dernière exécution en comparant avec un fichier contenant l'adresse. Si l'adresse a été modifiée, il enregistre la nouvelle adresse et envoie un mail. Le script nécessite d'avoir accès à un serveur smtp (ici par défaut celui de google). Les explications sont plus bas.

Paramétrage

Les paramètres sont à changer dans la fonction main. On a notamment l'adresse qui va envoyer le mail, l'adresse qui va recevoir le mail, le serveur smtp et enfin le mot de passe. Personnellement je n'aime pas mettre mon mot de passe en clair dans un script donc le script utilise un mot de passe chiffré avec la méthode de Vigenère. Le script nécessite donc également la clé (une chaine de caractère) qui a été utilisée pour chiffrer le mot de passe.

Pour générer le mot de passe chiffré il faut utiliser la fonction vigenere fournie dans le script. En console dans le dossier contenant le script (et en supposant qu'il s'appelle ipcheck.py) :

$python3
>>>import ipcheck
>>>ipcheck.vigenere(maclef, monpassword)

Ce qui vous donne le mot de passe chiffré correspondant à mettre dans la variable password du script.

Attention : Étant donné que le script contient à la fois la clé et le mot de passe, le chiffrement de la clé n'est absolument pas sécurisé. Le chiffrement permet ici uniquement à ce que quelqu'un qui voit votre fichier vite fait dans votre dos ne connaisse pas votre mot de passe. A titre personnel, j'ai une adresse mail séparée spécialement pour mon Raspberry pi. Comme ça, même si quelqu'un récupère le mot de passe pour cette adresse, il ne pourra pas en faire grand chose.

Un coup de cron et en avant

Une fois le script configuré, il nous reste juste à demander l'exécution régulière du script. Pour ça, dans la ligne de commande (les éventuelles personnes sous windows pourront jouer avec les tâches planifiées)  :

$crontab -e
Votre éditeur préféré s'ouvre et vous pouvez ajouter la ligne :
0 * * * * /chemin/vers/le/script

En clair, cela veut dire : exécuter le script à chaque fois qu'il est x h 0 min, soit toutes les heures. Vous pouvez adapter en fonction de vos besoins pour le faire tourner plus ou moins souvent. On sauvegarde et c'est fini.

Voilà, j'espère que ce script trouvera son utilité auprès de certains. Au pire, il est toujours là pour moi si jamais je venais à perdre mon ordinateur. N'hésitez pas à demander des précisions ou faire des remarques (constructives, cela va sans dire :-) ).

 crédits photo : Keith Weller, United State Department of Agriculture