Pellerin Cédric

Avoir son propre serveur, sa propre production, ses propres baies… Bien souvent, cela est juste nécessaire pour la continuité de service et c’est un des métiers clés de l’informatique contemporaine. Sauf que voilà, posséder sa baie à la maison ou dans l’entreprise n’est plus depuis longtemps la meilleure façon de faire. Et la mode des clouds (du « nuagique » en français) nous a même expliqué que tout cela était dépassé, has been, remisé aux poubelles de l’Histoire. Mais alors, quand on a besoin de ses propres serveurs (et pas de services clés en main) et de continuité de services, comment fait-on ? Allons voir ensemble ce que recouvre la notion d’hébergement.

Cela fait environ cinq ans que les demandes de « DevOps » sont de plus en plus nombreuses dans le milieu professionnel. Souvent, lors des entretiens, on s'aperçoit que chaque client, ou presque, a sa propre définition du mot. Nous allons essayer de donner ici notre vision, tirée de notre expérience de terrain, de cette fonction.

La présentation de LXC faite dans le précédent numéro [1] nous a permis de mettre en œuvre les fonctionnalités de base et de créer rapidement des conteneurs fonctionnels. Cependant, les capacités de LXC ne s’arrêtent pas là et nous allons pouvoir étudier ici plusieurs options bien utiles en production.

Avoir son propre serveur de mails bien à soi est le rêve de beaucoup d’utilisateurs GNU/Linux. Cependant, depuis quelque temps, les principaux acteurs du net exigent que nous montrions patte blanche avant de transférer ou d'accepter nos courriels. Voyons donc comment faire.

Depuis quelques années, la « star » des conteneurs s’appelle Docker. Tout le monde l'utilise pour presque tout et n'importe quoi. Cependant, il ne faut pas oublier que Docker n'est pas la seule solution de conteneurs disponible pour Linux et qu'il est même arrivé bien tard dans le paysage. Nous allons ici étudier celui qui fut à l'origine, j'ai nommé LXC.

Dans cet article, nous allons aborder d’autres systèmes d’exploitation côté client, ce qui nous permettra de mettre en lumière certaines limitations. Nous allons tout d’abord passer en revue ceux qui fonctionnent en IKEv2 puis en examiner qui ne supportent que L2TP/IPSec en IKEv1.

Lorsque l'on veut transporter des données de façon sécurisée, il faut s'assurer de deux choses : d'une part, que les données reçues n'ont pas été altérées – volontairement ou non ; d'autre part, qu’elles ne puissent être lues par des tiers, on parle alors de chiffrement. En fonction des choix effectués, nous verrons que sur la totalité d’une trame des morceaux plus ou moins grands sont chiffrés et/ou authentifiés.

Comme nous l’avons vu, il est tout à fait possible d’utiliser OpenVPN avec un fichier de configuration simple et légèrement adapté et en utilisant easy-rsa pour générer les clés et les certificats. Nous allons voir ici qu’il existe de nombreuses autres possibilités très intéressantes permettant d’augmenter significativement le niveau de sécurité et la souplesse d’utilisation.

Quand on désire bien comprendre comment fonctionne quelque chose, il est souvent bon de descendre aussi bas que possible afin de ne laisser échapper aucun détail. Nous n’irons pas jusque-là dans cet article, mais nous allons tracer le début de la route.