dimanche 4 septembre 2016

Hypriot c'est bien, Armbian c'est mieux ... c'est un peu comme le Pi3 et le Odroid-C2

J'ai essayé d'installer docker sur C2 au début d'été. Il n'y avait pas de docker dispo à l’époque, j'étais parti de Zéro, en compilant le Go, puis en compilant docker (mais en dehors de docker)

j'avais eu un pb de mémoire pour la compilation.

La suite d'article suivante va me permettre de passer le cap et de faire un cluster en Odroid-C2

http://mrdreambot.ddns.net/building-my-odroid-c2-docker-cloud-part-1-in-search-of-a-stable-linux/#more-374

mardi 17 mai 2016

Réintegrer des sous-noeuds perdus

Problématique du jour

Le noeud qui administre le cluster ne liste pas tous les sous-noeuds.

Solution à trouver

monitorer et mettre en place une solution automatique qui réorganise tout correctement.

Scénario qui a relevé le problème

Le noeud maitre a été allumé, 10 minutes d'attente, puis allumage des sous-noeuds tous en même temps.
Ce scénario est nominatif et doit fonctionner : le TCW181-CM (8 relais pilotés par IP de terracom) n'a qu'1 relais dédié à tous les sous-noeuds. Donc le redémarrage se fera systématiquement pour tous les sous-noeuds, en une fois.

Lister les contraintes

  • on ne doit pas connaitre les IPs
    • En effet, on se base sur du DHCP, donc les IPs peuvent varier. Le lease peut être fourni par une box (freebox par exemple), ou par un serveur DHPC soft (dnsmasq dans le cas de DWG experience_front). On part du postulat que le DNS est correct : bind9 connu dans le parc (pour moi sur experience pour le parc, sur experience_front pour la DWG).
  • le nom des slaves n'est pas connu
    • On doit pouvoir nommer les slaves comme on le veut sans remettre en cause la solution/ l'outil.
  • les slaves doivent être stateless
    • Il faut qu'un nouveau noeud s'intègre sans avoir à modifier le noeud lui-même. Ou en tout cas, qu'un provisionnning simple fasse le nécessaire.

Les pistes ...

Quand on veut peu d'impact sur les noeuds, on pense à du ansible, seul le master va avoir ce soft d'installé.
Reste à trouver comment déclencher ces traitements. Pour le code exécuté sur les noeuds, ssh et audit en swarm.
Pour le master, naturellement je partirai sur du monit, mais il s'agit d'une solution non intégrée, est-ce qu'il n'existe pas des solutions plus 'docker compliant' et/ou exploitable par les softs eux même.
En effet, cette solution peut-elle être inclus dans un docker qui serait déployé uniquement sur le master.

Commençons salement, on fera mieux plus tard ...

allez, à l'arrache : monit, ansible playbook le tout sur le master sans container

pour lancer l'ansiblerie :

for DIGIT in $( seq 2 254) ; do if ping -qc 1 192.168.1.$DIGIT 1>/dev/null; then if curl -s 192.168.1.${DIGIT}:8500/v1/catalog/nodes >/tmp/nodes.docker ; then grep '"Node":"master"' /tmp/nodes.docker || echo "playbook to run on ${DIGIT}" ; fi ; fi ; done


nmap fait mieux, a prendre en compte


on se basera en local sur

docker -H localhost:2378 info

L'idée du playbook est valide à une condition : les clefs ssh ont été échangés. Or, ce n'est pas le cas. On bascule donc vers une autre solution : expect.
L'avantage de expect, c'est qu'il ne va s'installer que sur l'appelant.

Dans le cadre du parc, on va donc faire une architecture en 3 layers : le DomainServer, le master et les slaves
  • Le DomainServer va faire un simple monitoring pour l'appartenance au cluster.
  • Le DomainServer va provisionner puppet et ansible sur le master.
  • Le master va exécuter les playbooks sur lui-même sur les slaves.
  • Le master va exécuter puppet en masterless sur lui-même.
Question lié à mon parc : ou dépose t-on les outils pour la partie docker ? Il existe un repository pour experience, mais il ne s'agit pas du même sujet. De plus, dans le cadre de la migration du service dans experience_front (qui devient le DomainServer), le module docker_swarm_simple_monitor doit être ailleurs, on va créer https://bitbucket.org/dbouwyn/cluster_config

On va partir du principe que ce nouveau dépot sera le dépot de base du master. On crée la structure avec un répertoire ansible et puppet, on fera un git clone et un mount bind.

Je dois d'ailleurs commencer par ça, aussi je vais poster un nouvel article sur le provisionning du master. Dans le but d'être immédiatement carré sur l'organisation du master, je dois commencer par ce point. Je reviendrais donc sur cet article après.
http://experience-ppprod-parc.blogspot.fr/2016/05/experience-as-domainserver.html
C'est un début, to be continued ...

mardi 26 avril 2016

Installation de HypriotOS Cluster Lab

Installation de HypriotOS Cluster Lab

Téléchargement de l'image hypriot_20160121-235123 (la plus récente a ce jour).

Installation de l'outil flash de Hypriot.

[root@dbouwyn ~]# mkdir hypriot
[root@dbouwyn ~]# cd hypriot/




Editer les 2 fichiers suivant de façon à avoir :

[root@dbouwyn hypriot]# cat device-init.yaml
hostname: bogdanov
wifi:
  interfaces:
[root@dbouwyn hypriot]# cat config.txt
max_usb_current=1


[root@dbouwyn hypriot]# flash --hostname bogdanov --bootconf config.txt --config device-init.yaml -d /dev/sdc /home/vagrantadmin/Téléchargements/hypriot_20160121-235123_clusterlab.img.zip

lundi 25 avril 2016

play new game

j'ai 3 rpi1 qui trainent, et une folle envie de tester hypriotOS ...
Ben, on va s'y coller ...

samedi 6 juillet 2013

reprise complète

Mon objectif sur ces serveurs était de déployer mes jeux.
L’idée des 2 était simple : tjs un en prod, un autre en beta, et bascule lors de passage de version.

Pour tous les services ne nécessitant pas de redéploiement : version cluster. pour les autres balancing configuré.

J'ai eu plein de pbs avec les CM (i.e. le hard), ça m'a gonflé !!!!!
On repart sur du rpy.

performance, homogénéité d'architecture, faible coût d'achat, faible coût de run-time (i.e. electricité). Le coût de clé USB et leurs performances permet de s'affranchir des HD, tout sur clé !

samedi 19 février 2011

Ça fait un moment que je n'ai pas écrit, je m'y colle.

Le 2 GX270 sont partis à la benne, le format était trop proprio pour en faire un truc sérieux.
J'ai récupéré des P4 (plein !).

Igor et Grichka vont être des VM sur XEN. le découpage global est décrit dans la config du parc.

La redondance reste une priorité de mise ne place. Mais ça viendra après les autres services.

mercredi 9 juin 2010

Réception de la CM

J'ai reçu la carte et installé le P4. Ça marche.
Pour limiter l'investissement, je vais laisser experience comme il est. On verra plus tard pour le gonfler.
Le P4 avec la nouvelle CM (ex Igor) va devenir palette.
Je crois savoir pourquoi le GX270 ne marchait pas. Je pense que je vais pouvoir le faire fonctionner.