Pelisse Romain

Au démarrage d’un système, de nombreux logiciels sont lancés, de manière à s’assurer que ce dernier soit entièrement fonctionnel lorsque l’utilisateur va démarrer sa session. Ce dernier démarre lui-même ensuite les logiciels dont il a besoin. Mais pourquoi ne pas automatiser aussi le démarrage de ces logiciels ? S’assurer qu’ils tourneront toujours, et libérer ainsi l’utilisateur de cette tâche répétitive. Voyons donc ensemble, dans cette recette, comment mettre en place un « service » (avec Systemd).

L'une des qualités indéniables de l’ensemble des systèmes « Unix » est l’abstraction faite par le système entre ses composants physiques – disque dur, mémoire vive et autres périphériques, et leur représentation au sein du système, presque toujours sous forme de fichier. Dans cette recette, nous allons illustrer tout l’intérêt de cette abstraction, par deux manipulations très simples : le montage d’un système de fichiers à partir d’un fichier ISO puis à partir de la mémoire vive du système !

Le serveur HTTP Nginx est un outil souple et très puissant, utilisé par de nombreux administrateurs de systèmes, mais peu connu des développeurs Java. Le serveur d’intégration Jenkins leur est par contre souvent familier, et encore plus Maven qui est probablement l’outil de construction de logiciel le plus utilisé dans le monde Java. Qu’est-ce que ces deux mondes bien distincts ont à voir ensemble? Eh bien, justement, c’est ce que nous allons voir dans cet article ! En étudiant comment le premier peut venir au secours du second…

Si vous êtes utilisateur d’un système GNU/Linux (ou autre « Unix »), mais que vous n’êtes pas formé à l’informatique, vous avez certainement dû néanmoins être souvent confronté à un « terminal ». Cet environnement, fait de lignes de commandes, souvent désigné sous le terme de « Shell » pour les initiés, et très certainement, pour le néophyte, une application difficile à prendre en main. Cet article vise donc à, non seulement, vous permettre de prendre en main votre terminal, et aussi de bien comprendre son fonctionnement et les raisons, historiques, de sa conception.

De nos jours, on utilise souvent des ordinateurs portables, que l’on déplace régulièrement, interrompant ainsi de nombreux programmes s’exécutant dessus. Dans le même temps, on n’a jamais autant disposé de systèmes « distants », s’exécutant sur un « cloud » ou ailleurs, qui eux, à l’inverse fonctionnent « non-stop ». Ne serait-il pas agréable de pouvoir exécuter une application interactive (client de discussion en ligne, logiciel de partage de fichiers, programme de sauvegarde…) sur ces machines distantes, pour qu’elle soit toujours en fonctionnement, et simplement s’y connecter depuis son portable ? C’est possible, aisément, et c’est le thème de cette recette.

Dans cet article, nous allons nous attaquer à un aspect fondamental de tout système dit « Unix » : le système de fichiers. En effet, une bonne compréhension de ce dernier facilite grandement la prise en main de son système, et permet aussi de faciliter la conception de scripts « Shell ». Il est en effet essentiel de bien saisir la manière dont le système conçoit – ou plutôt abstrait – les différentes ressources à sa disposition, justement à l’aide de son système de fichiers. C’est crucial, car que ces ressources soient le disque dur, de la mémoire vive ou même encore des périphériques, sous un système « Unix », tout est au final la même chose : un fichier ! Démonstration par la pratique...

Construire un environnement de livraison continu à la fois dynamique, optimisé et capable de tenir la charge (sans faire monter la facture plus que nécessaire) : c’est possible ! Et même facile à l’aide d’OpenShift ! Voyons rapidement comment mettre cela en place...

Nous avons désormais fait le tour de l’ensemble des éléments nécessaires pour rédiger de manière propre et robuste des scripts « Shell ». Il reste donc à réaliser, à titre de conclusion de ce hors-série, une étude de cas pratique, pour mettre en place et utiliser, de manière concrète et complète, les différents mécanismes et techniques évoqués.

Si Java est un langage reconnu pour sa (relative) simplicité et clarté, il ne l'est clairement pas pour sa concision. À bien des égards, il est même parfois très (trop?) verbeux. D'ailleurs, de nombreux langages alternatifs, qu'il s'agisse d'autres plateformes comme Ruby ou de langages construits sur la JVM comme Closure ou Scala, se vantent sans cesse, et avec raison, d'être plus concis. Néanmoins, cette verbosité n'est pas une fatalité, comme l'illustre l'excellent projet Lombok.