Archive

Posts Tagged ‘Linux’

Ma Pi-Box reprend du service

10 septembre 2019 Laisser un commentaire

Mon tout premier Raspberry Pi, un modèle B, m’a longtemps servi de lecteur multimédia, branché sur la télévision. Pour le protéger un peu, je lui ai offert un boîtier, la Pi-Box.

Avec le temps, c’est devenu un peu court, en termes de puissance, et ma nouvelle box internet a pris le relais, merci la fibre. Confier mon réseau personnel à la box d’un opérateur ne me plaît pas plus que ça, mais en attendant d’avoir un vrai routeur contrôlable par mes soins, j’ai confié à cette vénérable Pi-Box la mission de prendre en compte une partie du problème.

Kesako Pi-Box ?

C’est un simple mais confortable boîtier en plastique qui abrite, outre ma Raspberry Pi, une alimentation bien propre et un hub à quatre ports USB. Les prises vidéo, son, et réseau sont reportées sur l’arrière du boîtier, tandis que la carte SD est déportée en façade.

La face arrière, de gauche à droite : l’interrupteur d’alimentation, les sorties vidéo et son au format coax, la prise HDMI, la prise d’alimentation, quatre ports USB et une prise réseau au format RJ-45.

Un voyant d’alimentation en façade complète le tout. L’un des ports USB de la Raspberry Pi est utilisé par le Hub du boîtier ; le second reste libre. Le refroidissement est entièrement passif mais je n’ai jamais constaté de surchauffe.

En « haut » du boîtier, le PCB de la Pi-Box. En centre ma Raspberry Pi modèle 1B. La majeure partie des ports est routée vers le PCB de la Pi-Box, en haut. Le lecteur de carte SD est déporté sur l’avant.

Sans être le grand vide, la place est loin d’être comptée dans ce boîtier, et il devrait être possible d’ajouter au moins un périphériques USB.

Très bien, alors que faire de ce bidule ?

Première mission : un serveur DNS

J’ai découvert il y a quelques mois le projet « Pi-Hole« . Il s’agit d’installer sur un Raspberry Pi un serveur DNS un peu spécifique. Outre remplacer le DNS de mon FAI, il permet de filtrer – entre autres – les publicités.

Les bloqueurs de publicités utilisé par les navigateurs web fonctionnent assez bien, mais certains sites les détectent et refusent d’afficher quoi que ce soit dans ces conditions. Avec Pi-Hole, le problème disparaît, et les publicités sont remplacés par des zone vides. Mieux, en indiquant à la box internet d’utiliser la Pi-Hole comme serveur DNS, ce sont toutes les machines du réseau qui en profitent.

Pi-Hole fournit d’autres services comme le DHCP, mais je ne les ai pour le moment pas encore activés.

Installation de Pi-Hole

Rien de bien compliqué, il suffit de suivre les instructions du site du projet. Celui-ci est en anglais, mais il existe des tutos en français, comme ici par exemple.

Après avoir répondu à quelques questions, l’installation se termine et il suffit de redémarrer le Raspberry pour profiter d’internet (presque) sans publicités, et les site indésirables sont automatiquement filtrés.

Sous le capot, c’est évidemment un peu moins simple, mais la configuration peut être modifiée via un navigateur internet. Petit plus, des statistiques peuvent être activées et consultées, toujours via un navigateur internet.

Première amélioration : allonger la durée de vie de la carte SD

Le système d’exploitation de la Raspberry Pi est stocké sur une carte SD. Pi-Hole tourne sur Linux, qui est assez bavard et alimente moult fichiers de logs. Dans ces conditions, une carte SD ne dure habituellement pas des années.

Une solution serait de supprimer l’écriture des logs, mais on y perdrait en fonctionnalité, par exemple pour analyser un problème système ou une intrusion. La distribution que j’utilise, Raspbian Lite, est assez légère en mémoire. On peut donc en prélever une partie pour y créer un disque virtuel sur lequel les fichiers de log seront stockés. Pour que rien ne se perde lorsque le Raspberry est éteint, les logs seront périodiquement copiés sur la carte SD. Ainsi, celle-ci finira bien par succomber, mais beaucoup plus tard.

Pour la mise en place, il suffit de suivre les tutos disponibles, comme celui-ci ou celui-là. Le second lien a ma préférence.

Seconde amélioration : un bouton d’arrêt et un bouton reset

La Pi-Box comporte un interrupteur d’alimentation, mais l’utiliser sans précaution risque fort de mettre le système de fichier en vrac. La Raspberry ne prévoit rien pour l’éviter. Aussi, il va falloir ruser un peu.

Un script lancé au démarrage du système surveille l’appui sur un switch connecté sur deux broches « GPIO » du Raspberry. Là encore, de multiples tutos sont disponibles. Celui-ci fonctionne très bien. Lorsque ce switch est activé, le script lance la procédure d’arrêt propre de Linux, et lorsque le système est arrêté, on peut couper l’alimentation électrique, ou redémarrer via un bouton reset.

L’ajout d’un bouton reset est plus simple, mais demande de souder deux pins sur la carte du Raspberry Pi, et c’est la mise en contact de ces deux pins via un switch qui provoque le reset. Pas de panique pour la soudure des pins, c’est très facile et il est presque impossible de se louper. Encore un tuto ? Allez, c’est par-là.

J’ai choisi de positionner le bouton reset et le bouton d’arrêt sur la façade avant de la pi box, entre la LED d’alimentation et le port SD. Pour me faciliter les choses, j’ai installé deux boutons sur une plaquette de prototypage, et quatre pins mâles pour les relier aux GPIO et aux pins de reset via des câbles de type Dupont, mais il est également possible de recycler les boutons de façade d’un ordinateur de bureau, ce qui évite en partie d’avoir recours au fer à souder.

Les boutons d’arrêt et de reset sur leur plaquette. Juste derrière, la LED RGB et ses connecteurs.

Troisième amélioration : une LED d’activité

La Raspberry comporte des LEDs d’état, mais celles-ci ne sont plus visibles une fois la Pi-Box refermée. Il faut donc trouver un moyen de savoir si le système d’exploitation est actif ou non.

Par ailleurs, il peut arriver que la Raspberry Pi se bloque, ou qu’un programme utilise toute la bande passante du CPU. Dans ce cas, une fois la Pi-Box refermée, rien n’indique qu’il y a un problème.

Ici encore, j’en suis passé par un tuto. A l’arrivée un script un peu remanié et un petit montage. Le montage consiste à relier aux GPIO de la Raspberry trois LEDs de couleurs différentes, ou une LED RGB. Un script se charge de modifier régulièrement les couleurs allumées ou éteintes.

A l’arrêt du système, le script est automatiquement stoppé et les LEDs apparaissent alors fixes, ce qui indique qu’on peut couper l’alimentation ou appuyer sur le bouton reset.

Petit test in situ.En haut à droite la plaquette supportant les boutons de reset et d’arrêt.
Tout contre le boîtier, la LED RGB allumée plein phare apparaît blanche.

Installation en façade

Une mèche à bois, un peu d’adhésif de masquage et de colle chaude suffisent. Pour le perçage, on peut se contenter de pré-percer à l’aide d’un trombone chauffé au briquet (attention les doigts), puis élargir au diamètre voulu.

L’emplacement de la LED RGB est déjà percé à gauche. L’emplacement des deux boutons est repéré sur le ruban adhésif.
Les perçages ont été nettoyés à l’aide d’un scalpel.
La LED RGB (en avant plan, désolé pour le flou) et les boutons sont en place. Quelques fils de colle chaude restent à nettoyer.
Les fils du bouton d’arrêt et de la LED RGB sont maintenus en place par les connecteur audio et composite du Raspberry Pi.
Les fils du bouton reset passent derrière la nappe du lecteur de carte SD.
La LED RGB est fixée par un blob de colle, en attendant mieux.
La Pi-Box est refermée, prête à l’emploi… même si un petit nettoyage s’impose.
Les nombreuses ouïes d’aération permettent un refroidissement efficace malgré l’absence d’un ventilateur.

Remerciements

Un grand merci aux auteurs des très nombreux tutoriels que j’ai parcourus ou utilisés pour cette réalisation. Il n’y a rien de bien compliqué, mais ça m’a fait gagner un temps précieux.

Prochaines modifications

Telle qu’elle est, ma Pi-Box/Pi-Hole fonctionne très bien, mais j’envisage quelques ajouts et modifications :

  • Ajouter une horloge RTC sauvegardée pour conserver l’heure si aucune connexion internet n’est possible
  • Activer le DHCP de Pi-Hole en remplacement de celui de ma box internet
  • Ajouter un « LCD Proc » (un tuto ici), pour afficher l’état du système, en plus des LEDS d’activité.
  • Améliorer l’intégration des scripts dans systemd. Ça fonctionne tel quel, mais j’ai bidouillé sur la base des tutos utilisés, et une mise au carré s’impose.
  • Remplacer la LED RGB (je me suis trompé de type cathode/anode commune)
  • Éliminer le gros blob de colle et fixer proprement la LED RGB

Publicités
Catégories :Informatique Étiquettes : ,

J’ai cassé ma Remington


Il y a toujours une première fois, mais là, ça en fait deux. Rassurez-vous, aucune machine à écrire n’a souffert. La victime est mon vieux HP note Mini, qui me sert de machine à écrire.
Remington Sholes 5 TSD (3)

Alors, quid ?

Une mise à jour de rien du tout, au cours de laquelle ma rallonge électrique a voulu attenter à ma vie, rien que ça, alors que j’allais me préparer un café. Le câble du chargeur a, bon gré, mal gré, suivi la rallonge. Le chargeur itou, de même que l’ordi tant que la fiche du chargeur a bien voulu en rester solidaire. S’en est suivi un vol aussi bref que non plané, puis un appontage assez furieux.

État des lieux

Quelques rayures assez légères, la batterie partie bouder dans son coin, le chargeur déconnecté, le netbook s’est arrêté net, faute de flux d’électrons. L’écran n’a rien. Ouf! Le disque est un SSD ; il devrait avoir survécu.

Redémarrage

Rien de physiquement grave, donc, mais le bidule s’est éteint au beau milieu d’une mise à jour. Le redémarrage se passe bien – merci le système de fichiers journalisé – et l’écran de connexion s’affiche normalement.

Identifiant, mot de passe, écran noir avec le pointeur de la souris, puis retour à l’écran de connexion. Le début des ennuis, en toute fin de Camp NaNoWriMo, alors  que je n’ai pas encore validé mon score !

Quelques tests

La connexion en mode texte fonctionne. Une vérification du système de fichiers ne remonte aucune anomalie. Une tentative de mise à jour via le duo gagnant « apt-get update ; apt-get upgrade », pour terminer celle qui a été interrompue échoue lamentablement. Les dépôts ne sont pas accessibles.

Pourtant, l’accès au réseau fonctionne : la commande ping et le navigateur en mode texte  fonctionnent comme attendu.

Une solution

J’aurais pu réinstaller le système, recréer mes comptes et restaurer mes données, mais l’informaticien est plutôt du genre fainéant, c’est bien connu. Encore que…

La commande mintupgrade vient à la rescousse. Bizarre, tout de même car en écrivant cet article, ma mémoire me dit mintupdate alors que les tutos parlent de mintupgrade).
En tout cas, rien de bien compliqué en principe, car il suffit de lancer successivement les quatre commandes suivantes :

mintupgrade check
mintupgrade prepare
mintupgrade download
mintupgrade upgrade

Valider par « y » les demandes de confirmations, et patienter entre chaque étape.

Dans mon cas, tout s’est bien passé et, effet de bord, mon netbook est passé sous Mint 19, « Tara » de son petit nom. On a connu Remington Steele (bonjour la référence!), et bien maintenant, nous avons Tara Remington.

Tout fonctionne ?

Non, malheureusement. Ma Remington est utilisable, pour peu que je me contente d’une connexion filaire aux internets, car le wifi n’est pas reconnu. Il s’agit d’un chipset de chez Broadcom bien détecté par la commande lspci, et supporté sans problème jusque lors. Son pilote est toujours installé et actif, mais la connexion est refusée.

Un test sous Debian 8 installé sur une seconde partition donne toute satisfaction.

A tout hasard, j’ai installé à blanc Mint 19 sur une troisième partition, et le wifi n’est, là non plus, pas utilisable. Apparemment, ce serais entre Tara et Broadcom que ça grince…

Pour le moment, je saurai me passer du wifi, mais ça ne durera pas.

Et le Camp NaNoWrimo, dans tout ça ?

Ce qui précède est arrivé l’avant dernier jour d’Avril, et le challenge d’écriture s’est terminé sous vim. La validation a été faite sur un autre PC, en passant par une clef USB. C’est le principal, non ?

Edit:

Pour finir, je n’ai pas tenu très longtemps.  Le chipset Broadcom BCM4313 est parfaitement reconnu, et son pilote fonctionne correctement. Pour m’en assurer, j’ai partagé par wifi la connexion 4G de mon téléphone. Une fois la connexion créée sur le netbook, j’ai pu accéder à ce blog.

Pour rétablir la connexion par wifi via ma box internet, il a simplement suffi de modifier le type de connexion de « WPAPSK (obsolète) » en « WPA2-PSK-AES ». Dès lors, ifconfig affiche une interface « wlp2s0 » avec une adresse IP.

Le câble Ethernet peut être débranché, et ma Remington a retrouvé son autonomie.

Catégories :Informatique Étiquettes :

Un serveur de synchro « vite fait »

3 juillet 2018 Laisser un commentaire

Je suis toujours en galère sur mes articles. Quelques brouillons bons à jeter, pas mal de notes, mais j’ai trop chaud. Vivement cet hiver ! Si-si !

Je pourrais me contenter d’une brève, mais ce ne serait pas un vrai billet, alors…

… alors pas de billet cette semaine ?

J’ai un petit soucis de matériel.

Auto wreck, U.S., 1923

Pour faire court, je n’ai plus de machine de synchronisation pour mes PC. Je dis synchronisation et non sauvegarde, car c’est autre-chose : en sauvegardant de temps en temps depuis le Monolithe, puis la Remington, et encore le monolithe, etc, ça devient vite le foutoir et on n’est jamais sûr d’avoir la bonne version (expérience personnelle). Une sauvegarde, ça se fait sur disquettes bandes magnétiques CD DVD disques durs externes, et ça ne sert à rien si on sauvegarde du bord3l numérique.

J’avais donc ajouté sur mon mini cluster de quoi synchroniser mes machines. Rien de bien fancy, juste un dépôt Mercurial. Ouaip ! Mercurial. Le truc le moins user friendly grand public qu’on puisse trouver. L’avantage de Mercurial, c’est qu’il ne consomme pas grand-chose en bande passante CPU et en mémoire. Mes textes, codes sources, notes, comptes et assimilés étaient donc bien à l’abri, dans leur multiples versions successives, et accessibles depuis n’importe où – dans mon cas, le Monolithe et la Remington – d’une « simple » commande unix.

Le noeud principal du mini cluster est mort. Le second ne démarrera sans doute plus, ne reste qu’une babasse assez récente – comprendre moins de six ans – en bon état général. Elle n’a besoin que d’un bon ravalement de façade et d’un ventilateur supplémentaire. Mon cluster n’est plus qu’un tore de Jophur, une tranche de cluster.

Constat #1

La bidouille, c’est le bien : on apprend des choses, de ses erreurs surtout, on réussit parfois, mais si on veut un outil sérieux, et même si on veut le faire soi-même, il faut y mettre les moyens : un peu d’argent, beaucoup de temps, et de la méthode.

Constat #2

J’en ai un peu assez de bidouiller des bouses récupérées dans les poubelles, et au final passer plus de temps à les remettre sur pieds en cannibalisant celles qui ont eu moins de chance. Je compte bien assembler un nouveau cluster – je suis indécrottable – mais sur de bonnes bases.

Constat #3

Côté synchronisation de mes bidouilles numériques, à part faire du rsync sur un disque externe, je suis à poil, et c’est tout sauf confortable.

Oui, et … donc ?

La babasse citée plus haut est assez bien fournie vu son âge relatif : processeur dual core 64 bits, 4 GO de RAM, deux disques de 250 GO plus un de 1 TO qui attend sagement son installation, Ethernet 100Mb (c’est un peu léger, mais en première approche, ça ira), et un vrai port série, au cas où. Debian 9 est déjà installé et configuré « headless », via ssh. Mercurial est également installé, pour accéder à mes précieuses données depuis mes deux machines de travail sans y remettre le souk.

La suite ?

Je n’installerai pas docker sur ce petit serveur. Je réserve ça pour plus tard, et même si je n’exclue pas d’y installer des outils plus modernes, je peux bosser en toute sécurité. Le confort viendra plus tard.

En attendant, je peux me recommencer à écluser les « en-cours ».

Creative Commons License

Crédits Photos :

Catégories :Informatique Étiquettes :

Docker ! Swarm ! Arrimage !

30 janvier 2018 Laisser un commentaire

Désolé, nouvelle remontée de « Goldorak ».

Il est grand temps de reprendre cette petite série d’articles sur Docker, et de relier mes trois nœuds Docker indépendants en un cluster Docker, en utilisant le mode Swarm.

Pour rappel :

Avertissement

Cette série d’article ne vise rien d’autre qu’à formaliser ma découverte de la conteneurisation d’applications sous Docker.

L’utilisation de Docker en production demande de mettre en place une politique de sécurité, des sauvegardes, une redondance du stockage, etc

Activation du mode swarm

Pour le moment, j’ai trois nœuds Docker totalement indépendants. Un container (grosso modo une application)  lancée sur un nœud y reste, et si le nœud en question est éteint, l’application devient inaccessible.

Pour simplifier, le mode swarm permet d’éviter ce problème, en considérant l’ensemble des nœuds Docker comme une seule machine Docker, un swarm (essaim en français).

D’autres produits logiciels permettent d’atteindre le même but, mais pour le moment au moins, Swarm fera l’affaire.

Le principe de base

  1. Désigner un nœud comme manager
  2. Activer le mode swarm de Docker sur le manager
  3. Relier des nœud « workers » au manager
  4. Lancer des services, applications, etc en passant par le manager

nota: un manager n’est qu’un worker un peu particulier, et des applications et services conteneurisés pourront s’y exécuter.

Initialisation du swarm

J’ai choisi d’utiliser le nœuds island1 (adresse IP 192.168.0.11) comme manager.

Une fois connecté sur island1 avec le compte user1, il suffit d’une ligne de commande : docker swarm init –advertise-addr 192.168.0.11 .

L’option « –advertise-addr 192.168.0.11 » spécifie que des nœuds docker peuvent rejoindre le swarm via l’adresse ip 192.168.0.11 .

$ docker swarm init --advertise-addr 192.168.0.11
Swarm initialized: current node (ictdgwdx9x3o52a5lzgudxrxe) is now a manager.

To add a worker to this swarm, run the following command:

docker swarm join \
 --token SWMTKN-1-092t7vsiejgmz1i60gro2ww90m8qpiz2jb51k3pxrxuxvnzyih-c04351o9o94cj2jln1gsejni0 \
 192.168.0.11:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

$

La ligne « warm initialized: current node (ictdgwdx9x3o52a5lzgudxrxe) is now a manager. » affichée confirme que le nœuds island1 est le nœuds manager (ou leader)  du swarm.

Ajouter un autre manager

Et oui, une nouvelle commande à apprendre ! Je suis certain qu’il existe des interfaces graphiques ou des applications web pour faire la même chose, mais ce sera pour plus tard.

Le résultat de l’initialisation du swarm (docker swarm init …) donne la marche à suivre :

To add a manager to this swarm, run 'docker swarm join-token manager' 
and follow the instructions.

Mon cluster est très réduit, et un seul manager devrait suffire.

Ajouter un nœud au swarm

Dans son immense bonté, la commande « docker swarm init » nous a indiqué comment procéder :

To add a worker to this swarm, run the following command:

docker swarm join \
 --token SWMTKN-1-092t7vsiejgmz1i60gro2ww90m8qpiz2jb51k3pxrxuxvnzyih-c04351o9o94cj2jln1gsejni0 \
 192.168.0.11:2377

Un copier coller plus tard dans une session ssh sur island2 avec le compte user2, le swarm possède deux nœuds.

nota : si cette commande ne fonctionne pas et retourne une erreur, il suffira de la retaper sur une seule ligne (sans les caractères \ )

Lister les noeuds du swarm

La commande « docker node ls »  sur le nœud manager (ou leader) affiche une liste des nœuds du swarm.

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
99wkpu0uvdmyrz79yexrhyhj1 * island1 Ready Active Leader
v5bmwkqshl1qexv9nhj7a3na1 island2 Ready Active 
$

Pour le moment, seuls le nœud principal island1 et le nœud island2 apparaissent.

Le troisième nœud peut maintenant être ajouté

Retirer un nœud du swarm

Cette commande pourra être utile, pour retirer temporairement ou non un nœud du swarm : docker swarm leave

$ docker swarm leave
Node left the swarm
$

Un petit test

Tentons le classique des classiques, j’ai nommé « Hello World! », sur le nœud island1

$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/
$

 

« Et ça marche ! » comme dirait Garcimore.

Évidemment, il faudra tester le swarm docker avec de vraies services et de vraies applications.

Une petite question, en passant…

« Et ça marche ! », oui, mais où ? Sur quel nœud ?

On peut supposer que Docker lancera le container d’une application ou d’un service sur le nœud le moins chargé en charge CPU, en charge mémoire, en charge réseau… mais à moins de s’y intéresser de près, et bien, à priori, on ne sait pas, et c’est ce qu’on demande à Docker Swarm.

Point d’étape

Je dispose maintenant d’une (tout) petit cluster Linux, sur lequel tourne un swarm Docker. Les tests de base  montrent que  des images Docker simples fonctionnent sans problème.

Plus haut, j’écrivais « Mon cluster est très réduit, et un seul manager devrait suffire » . En effet, avec trois workers seulement, créer plusieurs managers n’aurait que peu d’intérêt.

Pourtant, j’ai eu tort : mon manager attend toujours son autopsie. Heureusement, en détachant du swarm mes deux workers restant, et en recréant un swarm, j’ai encore de quoi expérimenter. En cas de nouvelle défaillance d’un nœud, je devrai avoir recours à des VM (machines virtuelles) hébergées sur mon PC de bureau.

Et maintenant ?

On va maintenant pouvoir commencer à utiliser le swarm pour des choses un peu plus sérieuses, par exemple des services de type NAS ou de type auto-hébergement pourrait être intéressante.

Autres billets sur le sujet

 

Creative Commons License

Catégories :Informatique Étiquettes : , ,

Linux, Docker

18 juillet 2017 3 commentaires

Mon petit cluster commence à ressembler à quelque-chose :

Bien sûr, on peut améliorer les choses :

  • passer en adressage IP V6 au lieu de l’IP V4 actuelle
  • Sécuriser le cluster, par exemple en supprimant l’accès distant à internet
  • Sécuriser l’accès nfs, pour le moment ouvert à tous vents.

L’aspect sécurité est le plus important, et les solutions sont en cours d’évaluation. Par contre l’IP V6 peut encore attendre un peu.

J’ai donc un cluster presque utilisable, mais où presque tout reste à faire pour y faire tourner des applications sans trop avoir à se casser la tête.

La solution qui m’intéresse le plus est Docker, et c’est bien le but de cette série d’articles. Commençons donc par l’installer sur chacun des noeuds.

Installation de Docker

edit du 01/07/2018 : la procédure ci-dessous est valable pour une installation sur un système Linux Debian Jessie (8.*). Pour une Debian 9, la procédure est différente. Cf. ce lien pour le détail.

Mes machines tournent sous Debian Linux, en mode headless (sans clavier, souris ni écran), en accès ssh. L’installation se fait donc via une interface chaise-clavier à coups de commandes apt sur chacun des nœuds du cluster:

  1. Activer les backports. Ceux-ci permettent d’installer des paquets en principe non prévus pour la version actuelle de Debian (8 dans mon cas, 9 pour les courageux), mais portés depuis une version plus récente de Debian.
  2. Installer quelques paquets nécessaires
  3. Installer Docker
  4. Créer un groupe unix docker et y ajouter le compte utilisateur unix
  5. Tester l’installation

J’ai utilisé les commandes suivantes (à adapter à votre cas) sous le compte root sur chacune des machines du cluster :

# Ajouter les backports au sources.list du noeud
echo '' >> /etc/apt/sources.list
echo '# Backport needed by Docker' >> /etc/apt/sources.list
echo 'deb http://ftp.debian.org/debian jessie-backports main' >> /etc/apt/sources.list

# Mettre à jour la liste des paquets disponibles
apt-get update

# Installer quelques paquets utiles
apt-get -y install apt-transport-https ca-certificates
apt-get -y install curl software-properties-common

# Ajouter la clef et le repository des paquets de Docker
curl -fsSL https://download.docker.com/linux/debian/gpg \
| apt-key add -
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) stable"

# Mettre à nouveau à jour la liste des paquets disponibles 
apt-get update  # Télécharger et installer docker apt-get -y install docker-ce # Démarrer le service docker service docker start

Création du groupe docker

Ce groupe unix évite de devoir se connecter en root pour démarrer des conteneurs. Ceci se fait à nouveau sous le compte root.

# Créer le groupe docker.
groupadd docker

# Ajouter un compte (ici user1 sur le noeud island1)
usermod -aG docker user1

Test de l’installation

Si tout se passe bien, on peut passer au test classique du « hello world! »

docker run hello-world

Le résultat devrait ressembler à ceci :

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/

Etat des lieux

Jusqu’ici, les nœuds étaient reliés en un cluster unix où chaque machine faisait ce que l’on voulait bien y lancer au travers d’une connexion ssh.

Après les manipulations indiquées plus haut, chaque nœud fait fonctionner son instance indépendante de Docker, et il « suffit » d’y lancer des applications dans des conteneurs au fur et à mesure des besoins.

London docks c1909

« Suffit » est entre guillemets car plusieurs limites apparaissent très vite :

  • Si une machine « meurt » (carte réseau ou disque HS par exemple), les applications qui y tournaient, ainsi que leurs données, sont perdues, le temps de remplacer le matériel fautif, et de restaurer applications et données.
  • Il faut se souvenir sur quelle machine tourne chaque application …
  • … et que la machine en question soit démarrée.

Ces limites ont plusieurs solutions, dont le mode « Swarm » de Docker.

Autres billets sur le sujet :

Creative Commons License

Catégories :Informatique Étiquettes : , ,

Linux, réseau, ssh

20 juin 2017 4 commentaires

Mes trois machines sont maintenant en réseau, et chacune sait être accédée depuis les autres. Idem depuis mon PC de travail.

Se connecter sur l’une ou l’autre demande d’y connaître un compte et de pouvoir en fournir le mot de passe via une interface chaise-clavier. Outre ajouter une couche de sécurité relative, ssh permet, sous certaines conditions, de se passer de mot de passe en utilisant le principe des clefs publiques et privées.

Pour le moment, l’aspect sécurité est secondaire en ce qui concerne mon cluster, mais je changerai certainement d’avis plus tard. Un pas à la fois.

Les manipulations sont faites depuis mon PC, et les paquets ssh-server et client sont déjà installés sur les nœuds du cluster ainsi que sur le PC

Création et copie des clefs

Rien de bien compliqué, il suffit de suivre l’un des nombreux tutoriaux disponibles sur le web, en adaptant les commandes si besoin.

1 – Créer un répertoire de travail et s’y placer

mkdir ~/src/islandscluster-ssh-key
cd ~/src/islandscluster-ssh-key

2 – Créer les clefs

ssh-keygen -f  id_rsa -q -N ""

3 – Créer le fichier des clef autorisées

cp id_rsa.pub authorized_keys

4 – Ajouter la clef publique du PC de travail

cat ~/.ssh/id_rsa.pub >> authorized_keys

5 – Copier les clefs sur le noeud island1 du cluster. Le mot de passe de user1 est demandé

scp -r . user1@island1:~/.ssh

6 – Tester la connexion

$ ssh user1@island1
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Mar 11 20:05:11 2017 from 192.168.0.41
user1@island1:~$

Voilà, le premier nœud est accessible sans mot de passe depuis le PC de travail.

Il reste à  réitérer la commande scp pour les deux autres nœuds du cluster, puis à tester les accès mutuels entre eux.

Un peu de sécurité : ssh et root

Il est généralement conseillé de désactiver l’accès à une machine via ssh sous le compte root. Il suffit, sous le compte root, de modifier dans le fichier /etc/ssh/sshd_config le paramètre PermitRootLogin à no :

PermitRootLogin no

puis de redémarrer le serveur sshd sur la machine :

/etc/init.d/sshd restart

Prochaine étape

La prochaine étape consiste à installer Docker sur chacun des nœuds, puis d’activer le mode swarm. Cela mérite bien un billet ad-hoc.

 

Autres billets sur le sujet :

Creative Commons License

Catégories :Informatique Étiquettes : , ,

Linux, réseau local

6 juin 2017 4 commentaires

Mon projet de cluster avance un peu à la fois. Les marchés aux puces étant de saison, j’ai acheté à très bon prix quelques barrettes de mémoire pour gonfler deux des trois PC que je compte utiliser. Le troisième utilisant des barrettes un peu spéciales (ECC ou un truc du genre), c’est un peu plus compliqué.

Pour rappel, mon but premier est de découvrir et utiliser Docker, et notamment Docker Swarm.

Y arriver n’est pas très compliqué, si j’en crois les documentations disponibles.

Commençons par le début : l’installation du système et la connexion en réseau. Les pratiques varient en fonction de l’historique de chacun, mais ce qui suit (à part la photo)  fonctionne chez-moi.

Installation du système

Chacun des ordinateurs du futur cluster doit avoir son système d’exploitation. J’ai choisi Debian Stable. Un écran, un clavier, une clef USB d’installation (merci unetbootin) et on commence par le premier PC.

L’installation est relativement rapide, pour peu qu’on ait une connexion internet rapide. Ici, avec 200 kbps en pointe, il vaut mieux être patient.

Je n’ai installé que le système de base, plus quelques paquets bien utiles, comme gvim, ssh-client et ssh-server.

PC suivant… et PC suivant.

Après quelques tests, on peut passer à la suite.

Mise en réseau avec adresses IP fixes

Par défaut, mon routeur attribue aux ordinateurs des adresses en 192.168.0.* . C’est bien pratique en usage classique (bureautique, développement ou jeu), mais beaucoup moins pour des serveur où on aime bien savoir qui (quelle machine) est où (sur quelle adresse IP).

Un serveur DNS ou un bail DHCP très long sont deux solutions, mais je préfère fixer les choses. Mes trois machines auront pour adresses IP 192.168.0.11 à 13. J’ai donc configuré mon routeur pour que la plage d’adresses de 192.168.0.11 à 20 me soit réservée.

Reste à assigner un nom et une adresse IP à chaque machine. D’habitude, mes machines portent le nom d’une ville, mais là j’ai fait au plus court : island1, 2, et 3 .

Reste à modifier les fichier /etc/network/interfaces comme suit :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.10.11
netmask 255.255.255.0
gateway 192.168.1.1

La ligne « address » doit être modifiée sur chaque machine : 192.168.0.11 sur la machine island1, 192.168.0.12 sur island 2 et ainsi de suite.

Chacune des machine du futur cluster devant connaître les autres, le ficheir /etc/hosts doit contenir les lignes suivantes :

192.168.0.11 island1
192.168.0.12 island2
192.168.0.13 island3

Un petit reboot ou /etc/init.D/networking restart plus loin, la partie réseau proprement dite est terminée.

On peut tester que chaque machine sait parler aux autres, par exemple avec la commande ping suivie de l’adresse IP ou du nom d’une des autres machines.

Un peu de sécurité électrique

Mes trois machines sont alimentées via une multiprise qui ne servira qu’à ça. Même si leur consommation électrique est raisonnable, il est hors de question d’y brancher un fer à repasser ou un four à micro-ondes ou même une lampe de bureau. L’idéal serait une multiprise dotée d’un disjoncteur intégré. On n’est jamais trop prudent.

Autres billets sur le sujet :

Creative Commons License

Catégories :Informatique Étiquettes : , ,
%d blogueurs aiment cette page :