The problem: software orchestration.
Like fabric, puppet, chef.
It is Built on YAML, is agentless (uses SSH), idempotent.
Configuration is called 'playbook'.
A group of actions is called a role.
You can define host groups, hosts, variables.
To test local provisionning, use vagrant.
Roles available via:
- github
- bitbucket
- ansible galaxy
https://github.com/twitter/algebird
Containers are app-centric.
What's new about dockers containers: they are really portable
on different linux distros.
But they are not that easy to use: introducing RedHat atomic.
Atomic is like core os.
« Project Atomic integrates the tools and patterns of container-based application and service deployment with trusted operating system platforms to deliver an end-to-end hosting architecture that's modern, reliable, and secure. »
atomic contains rpm-ostree which allows package management with
rollbacking capability.
- cockpit: manage placement and scheduling of individual containers
- kubernetes: https://github.com/GoogleCloudPlatform/kubernetes
manage multiple containers one application - apache mesos: orchestrate containers accross multiple hubs
O-virt uses kubernetes to manage containers within VMs.
One good thing about containers:
for continuous integration: you don't have to update the nuderlying OS
One problem: container leak: SELinux takes care of that in atomic.
http://www.slideshare.net/hugfrance/hugfr-6-oct2014ovhantiddos
https://www.jfokus.se/jfokus14/preso/Reliable-real-time-processing-with-Kafka-and-Storm.pdf
Camus permet l'écriture dans HDFS.
Apache kafka 0.8 basic trainnig:
http://www.slideshare.net/miguno/apache-kafka-08-basic-training-verisign
MariaDB talk.
multiple solutions to the sharding problem.
MariaDB Spider: a partition table (table is split in slices).
does prunning, support to pass commit.
Developed by Oracle, takes care of HA.
Pros:
- no middle tier
Cons: - you have to rely on a specific smart connector which asks
for metadata, rigid. - No virtual shard.
- intrusive code to route query to the right shard
- shard key is a column in the table
A middle tier used to route traffic from client to the correct shard.
SaaS: black box
Java written proxy.
Smart analysis of workload.
2 phases commit commit
Proxy developed by mariaDB
multiple protocol, delegate authentication, database monitoring
transparent MySQL replication relay.
used by youtube.
written in go.
not used in the context of MySQL, used in NoSQL databases.
schemaless
sharding and replication part of the product
document sort, rebalancig are painfull
started by Facebook, NoSQL, really distributed and HA
bidata/hadoop context.
sharding data in the box.
before trying to be elastic: do you really need that ?
You can also use existing frameworks:
vitess, MySQLFabric, jetpants, gizzards
Présentation par Alterway.
Présentation de ce qu'ils utilisent.
- self service on demand (autonome pour créer services)
- broad network access (on a accès à toutes les ressources d'internet)
- resource pooling (consomer resource qu'on veut)
- rapid elasticity: répondre trés rapidement à des besoins,
- measured service: on peut voir ce qu'on consomme,
on ne consomme que ce dont on a besoin
- BaaS: baremetal as a service:
monter des serveurs physiques en 1/2 hieure - IaaS: infra as a service
- PaaS: déployer des applications avec custo sur du logiciel mutalisé
- SaaS: on utilise du logiciel pas trop paramétrable
- public: toutes les ressources sont mutualisées
(IaaS, réseau) même si compartimentalisation. - private: utiliser toutes les choses précédentes mais dans
le cadre d'une entreprise - hybrid: privé pour stoquer ces données hors du net,
et e.g. tous les frontaux webs au niveau public
Bons outils nécessaires et KISS.
- provisionning: provisionner une VM ou un server physique
- configuration management: gérer de manière automatique et
parallèle les config des machines - orchestration: orchestrer le déploiement redéploiement
entre différents groupes de machine - monitoring
e.g.
- docker file yml
- playbook ansible
- Foreman de machine: installer des os et les délpoyer
- saltstack: client server pour gérer des parcs de
- opencrowbar: déployer de l'openstack et d'autres choses
sur du baremetal (cluster hadoop, docker) - IRONIC: déployer de l'openstack sur du baremetal
- saltstack: orchestration de configuration.
recettes pour installer de manière parallèle sur
des serveurs très nombreux - ansible: utilisé à très grande échelle - agentless
(piloter tous les serveurs distants par SSH),
pas invasif, ansible peut manager des milliers de servers - dans le passé beaucoup puppet et chef beaucoup utilisés
mais plus considérés comme kiss:
compliqué de gérer des déploiements complexes
puppet déploie dans n'importe quelle ordre!
reste utilisé pour déployer massivement des changements,
e.g. clé SSH
- ansible: gérer des roles, un role commun utilise une batterie
de machine ansible lui est séquentiel, un role est un agrégat
de playbook - saltstack: écrire une fois qqc
- capistrano: framework ruby qui travaille en SSH et
embarque des mécanisme de rollback
- stockage
- recherche
avec packetbit: agrège elasticsearch et kibana avec des graphs
les configurations ne sont plus sur les machines mais dans
un server de configuration
un nouveau nœud est arrivé dans un cluster et faire qqc
monitoring de services de manière très simple.
remonte dans une interface web simple
axé service
on utilise des dockerfiles
docker génère beaucoup de containers
coreOS: fleet
kubernetes
Fig: très simple, yml, relations entre containers
Présentation de sirius comme alternative à un ensemble d'outils
industriels.
Changement de paradigme partiel dans l'embarqué:
Avant, UNIces propriétaires (RTOS, QNX, ...)
Maintenant, migration vers linux.
D'abord x86, maintenant ARMv7.
Grace à la puissance des chipsets actuels,
on peux commencer avec debian / ubuntu.
+ facile à développer
- empreinte mémoire, temps de démarrage, faible traçabilité
Cela encourage à développer sur la cible ce qui est catastrophique. - maintenance
- dév doit gérer la carte + distribution
alors que déveolppement applicatif = métier de l'entreprise - intégration de l'ensemble
Or un build system fait tout ça.
Un buildsystem crée une distribution à partir d'une source avec
des patches et des règles de production (recettes).
- gestion des dépendances.
- L'outil produit bottloader, noyau, rootfs, image complète
- outil produit la chaîne croisée: bien plus d'architectures gérées
- La configurtaion peut-être gérée par source.
moteur écrit en python
simple, léger, basb sur make, bien maintenu (free electron)
dérivé de buildroot
intell 2010 a rapatrié de nombreux projets
industriel
architecte Richard Purdie payé par Linux Foundation.
utilise paquets rpm deb ou ipk
fondé comme le kerenel sur:
- $ make config
- $ make
$ source env myprojce
$ bitbake img
- buildroot: pour 100 paquets ou moins
- open embedded / yocto: plus
Firefox OS.
but: gérer des smartphones
gaia (html5 js)
gecko (moteur de rendu)
gonk (linux intégré)
mobile
communique avec gecko via weapi
commun (gère les accès hardware des applications en fonction
de leur niveau d'accréditation)
environnement AOSP (android)
driver soit libre ou proprio
HAL modifié pour intéragir avec gecko
gecko fait l'isolation
- rild gère hardware radio
- rilproxy communique avec B2G
- mediaserver code audio ou vidéo
- boot2gecko gère le reste
Héritage d'android: lib std d'Android
sandboxing et security gecko level
app sandbox
les OEMS maintiennent leur version de gonk
makefiles, pas de buildroot
- raspberrypi
- kddi:
gluin: ihm de gestion de domotique de la maison
open web board: HDMI - panasonic: firefox OS
- matchstick
on peut faire son propre market place
3 niveaux de sécurité pour les apps
- n'importe quelle url
- marketplace
- constructeur
cause de la perte de vie privée:
- hypecentralisation d'internet
- perte de valeur de la vie privée télé réalité, CCTV
Il est tard, résoudre ces deux axes.
caliopen agit sur les deux axes.
PGP ne sert à rien si les gens avec qui on discute ne se protègent pas.
La vie privée, c'est protéger les données des autres.
PGP, protonmail, ... sont orientés sur le mail.
Or il y a bien plus d'outils.
Se limiter au courrier électronique ne sert à rien.
De plus c'est centralisé (e.g. protonmail).
Toute solution se fera trouer => facile à surveiller à un coût bas
si centralisé.
- décentralisation
- ouverture
- pas de SPOF
caliopen propose tous les protocoles et de tous les réunir.
Attacher à tous messages un niveau de confidentialité (privacy index)
le PI di la probabillité que le courrier ait été intercepté.
=> réintroduire dans le public la notion de vie privée
Le concept se propage:
Une conversation a une valeur, un contact aussi
Les terminaux ont une valeur de confidentialité.
Le compte de l'utilisateur a une valeur.
Ludification pour monter le PI.
On va récompenser.
Il faut être pédagogique.
Sur un terminal non sécurisé, par défaut caliopen ne permet pas de lire courrier avec un niveau > 0 ou donner clé privé.
Désactivable, mais => On perd des points, les contacts voient une note de message plus bas.
Le niveau d'importance d'un message est plus important si on a une meilleure note.
On refuse des messages si ils ont une note trop basse.
On reçoit tous les messages.
On ne classe plus par sujet, ce qui définit une conversation est
une personne.
Timeline avec toutes les conversations.
On peut limiter les conversations sur un PI faible => filtrage de spam
fait.
Caliopen adapte les metadata et choisit le meilleur protocole.
Protocols gérés: Tous les protocoles de corréspondance privée
futur WebRTC, moyen terme SMS
On a recréé la valeur de la vie publique.
On a pas résolu la centralisation.
Il faut beaucoup de caliopen installés.
Plusieurs instances (eg 1000) qui pourront échanger des PIs.
Une association donnera des labels aux instances des caliopen.
Les silos sont centralisés communiquent peu.
la chaine de valeur est côté server.
Code is law.
boite noire.
On donne du pouvoir aux sysadmin.
Solution: auto hébergement
but: vulgarisation du server
Un serveur n'est plus un systèmes d'exploitation.
C'est un ensemble de services réseaux (apps) qui peuvent se parler.
couches: device -- cozy -- net
un service pPaas (personal PaaS) déploie des stacks.
le développeur développe un service sans sdk contraignant.
On offre un service de persistance de données.
On peut partager les données (DataSystem).
Les apps s'y connectent en ResT.
DataSystem fondé sur CouchDB qui sait gérer les versions.
On peut se déconnecter.
Synchronization de toute la base.
On peut syncronizer toutes les données.
Sand boxed
On peut répartir ses services sur plusieurs serveurs.
Services transverses.
La centralisation des donéées permet de relier toutes les donnnées
(e.g. facture mail dans application banquaire)
Passerelle IoT.
on va pouvoir faire du «personal big data».
Lutter contre dispertion des données personelles.
Présentation des nouveautés d'ecmascript 6.
Quelques projets intéressants:
- angular
- dart
- react
Problème: scaling
ancienne solution: dupliquer brique complète
micro service: des composants font une seule chose,
on scale les composants
Solution: utiliser une seule API pour tous les frontend.
Protocoles:
- HTTP, rest, JSON
- Oauth2, Hawk en local car plus rapide