Heitor Emile (iMil)

« The Original UNIX », c'est pour cette punchline que j'avais voté lorsque le groupe chargé du marketing chez NetBSD cherchait une approche différente du classique « of course it runs NetBSD » ; néanmoins, s'il est l'héritier le plus direct des travaux du CSRG [1] et l'un des plus grands défenseurs de la portabilité du code, le projet NetBSD n'est certainement pas un système d'exploitation du passé, loin s'en faut. Bénéficiant des avancées standards d'autres OS, NetBSD dispose en outre d'avantages uniques dont l'administrateur système aguerri saura faire usage. Dans cet article, nous allons monter un serveur web articulé autour de briques modernes, et allons dans notre périple découvrir l'ensemble des éléments nécessaires au déploiement d'un système aussi réactif que respectueux des standards.

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.

Nginx n'est plus un logiciel à la marge, avec près de 20% de parts de marché du top un million des sites les plus fréquentés au monde, il représente même un acteur sur lequel on peut (et doit !) compter.

Il existe pour le serveur web / proxy inverse nginx une foule de modules tierce partie, à ajouter au besoin, pas encore intégrés upstream mais pourtant de très bonne facture. Parmi les auteurs de ces modules, il en est un qui sort du lot par la quantité mais surtout la qualité de ses contributions, il s'agit de Yichun Zhang, plus connu sous son pseudo : agentzh.

« Bonjour, êtes-vous équipé en fenêtclic-Bienvenue chez iMil, si vous êtes un démarcheur, restez en ligne, un opérateur va vous répondre... ». Avouez, avouez que vous n'en pouvez plus de recevoir des coups de fil anonymes de vendeurs de fenêtres et autres démarcheurs téléphoniques. Eh bien pour ça aussi, UNIX a une solution, elle s'appelle Asterisk.

Nous avons récemment [GLMF 166] vu comment créer facilement une application Web avec Flask. S'il s'avère relativement simple, muni de quelques connaissances python, de produire un Web Service fonctionnel, réaliser une application moderne, responsive, mais surtout jolie, peut se transformer en véritable cauchemar pour le quidam dont les connaissances en web design se limitent au strict minimum .

Je sais pas pour vous, mais moi, le clicka-web, ça m'ennuie. J'éprouve un profond respect pour ces génies de l'ergnonomie qui arrivent à produire des interfaces comme GitHub ou Twitter, truffées d'Ajax/jQuery[1], super inuitives, rapides et branchées sur des systèmes d'information ultra-complexes. Récemment, j'ai eu à produire une interface de gestion de déploiement de services au sein d'un parc de machines virtuelles. Cette interface devait se brancher sur un Web-service et s'interconnecter aux mécanismes d'orchestration Fabric[2] et Salt[3], tous deux en Python. Afin de garder une certaine cohérence dans le choix des langages, j'ai finalement jeté mon dévolu sur Flask[4], le “micro framework” qui m'a fait aimer développer du clicka-web.

“Devops”, “Cloud”, IaaS et j'en PaaS (oh-oh-oh la bonne blague d'entrée) et des meilleures, vous, lecteurs avides de technologies innovantes, vous n'avez pas échappé à la déferlante de buzzwords dont nous sommes victimes depuis que l'Internet est devenu une marketplace. Et finalement, si beaucoup manipulent ces buzzwords sans avoir aucune idée de ce qu'ils cachent, ils représentent une réalité tout à fait tangible qui met des parts de pizza sur la table de bon nombre d'entre nous. Véritables icônes du mouvement devops, les systèmes d'orchestration ont révolutionné la façon dont on manipule une ferme de machines; l'avènement de la virtualisation et de la transformation des serveurs physiques en “ressources” a fait naître de nouveaux besoins. Puppet et Chef font figure de pionniers dans cette sphère hyperactive mais un concurrent dont on entend beaucoup moins parler n'a pas à rougir devant ses prédécesseurs, il s'agit de Salt[1].

Nous avons précédemment vu comment le système de gestion de configuration Salt nous permettait de contrôler différents aspects d'un parc de machines, par exemple en s'assurant que des fichiers de configuration communs étaient tous synchronisés et que les paquets nécessaires aux services souhaités sur ces serveurs étaient bien installés et à jour. Bien que le nombre de modules fournis par défaut par Salt permette l'orchestration d'un parc relativement standard, pour une infrastructure de grande envergure ou pour des besoins spécifiques, il peut s'avérer indispensable de créer son propre module de contrôle, c'est cet aspect du logiciel que nous allons explorer ici.