Plus sûr et plus simple que Docker, connaissez-vous Singularity ?

Magazine
Marque
Linux Pratique
Numéro
128
Mois de parution
novembre 2021
Spécialité(s)


Résumé

Que vous soyez un développeur, un DevOps ou un administrateur système, vous n’avez pas échappé à la « révolution des conteneurs », et parmi les solutions de conteneurisation disponibles vous avez probablement opté pour Docker ! Mais êtes-vous sûr que Docker est toujours la meilleure solution ? La plus adaptée à vos utilisateurs, à vos contraintes de sécurité ? Nous vous proposons de découvrir Singularity comme alternative à Docker.


Body

Si Docker excelle pour encapsuler des applications complexes, des services réseau (Web, bases de données...) et des architectures à base de microservices, Docker peut rester complexe pour qui n’est pas un développeur chevronné, habitué à jongler avec les processus, les UID/GID et les systèmes de fichiers. En outre, proposer aux utilisateurs un accès direct à une plateforme supportant Docker pose de véritables challenges concernant la sécurité. Le démon dockerd doit-il fonctionner avec le compte root ou pas ? Pour éviter que les utilisateurs ne jonglent eux-mêmes avec les montages, le réseau ou l’utilisation des ressources, la solution de conteneurisation proposée par Singularity s’avère plus simple et plus sûre.

1. Présentation

Singularity est une solution de conteneurisation open source créée en 2015 par une équipe de l’Université de Berkeley dirigée par G.Kurtzer (qui est aussi le créateur de la distribution CentOS !). Singularity est développé depuis 2017 par la société Sylabs.io [1]. L’objectif initial est de proposer une solution de conteneurisation adaptée aux besoins des scientifiques qui doivent exécuter des applications conteneurisées sur des clusters de calculs (HPC). Mais bien sûr, cette solution peut trouver un plus large public.

L’installation de Singularity se fait via un package nommé singularity ou singularity-container, disponible avec votre distribution Linux préférée. Les conteneurs sont instanciés à partir d’« images » et les images utilisées par Singularity sont stockées à l’aide d’un système de fichiers nommé SquashFS, vous aurez donc besoin d’installer aussi le package squashfs-tools.

2. « Isolation » ou « intégration »

Pour bien comprendre les différences fondamentales entre Docker et Singularity, exécutons quelques commandes :

$ docker run -it --rm busybox sh -c "echo OK > /tmp/temoin ; cat /tmp/temoin"
OK
$ cat /tmp/temoin
cat : /tmp/temoin : Aucun fichier ou dossier de ce type

Ce premier exemple illustre clairement le principe d’isolation des processus imposé par Docker : le conteneur possède sa propre vision du système de fichiers et le répertoire /tmp, vu du conteneur, n’a rien à voir avec le répertoire /tmp de la machine hôte !

Si nous voulons que le conteneur puisse lire et écrire sur le véritable système de fichiers de la machine hôte, nous ajoutons une ou plusieurs options -v (ou --mount) à la commande précédente :

$ docker run -it --rm -v /tmp:/tmp busybox sh -c "echo OK > /tmp/temoin ; cat /tmp/temoin"
OK
$ cat /tmp/temoin
OK

Mais le fichier créé ne m’appartient pas !

$ id -u
1000
$ stat -c %u /tmp/temoin
0

En effet, le conteneur a été lancé par l’utilisateur 1000, mais le fichier a été créé par root ! Là aussi, ce comportement est dû à l’isolation du processus conteneurisé : les utilisateurs et groupes définis dans le conteneur sont différents de ceux définis sur la machine hôte. Bien sûr, il existe, là aussi une option (-u) qui permet de choisir l’utilisateur et le groupe qui va exécuter la commande dans le conteneur :

$ sudo rm /tmp/temoin
$ docker run -it --rm -u "$(id -u):$(id -g)" \
        -v /tmp:/tmp busybox sh -c "echo OK > /tmp/temoin ; cat /tmp/temoin"
OK
$ stat -c %u /tmp/temoin
1000
$ rm /tmp/temoin

Maintenant que nous avons vu comment Docker isolait les processus conteneurisés, regardons l’approche choisie par Singularity. Tout d’abord, une bonne nouvelle : Singularity peut utiliser les images Docker ! La commande suivante va télécharger l’image busybox:latest depuis le Docker Hub et va la convertir au format SIF (Singularity Image Format) (nous étudierons ce format plus tard) :

$ singularity pull docker://busybox
INFO :    Converting OCI blobs to SIF format
INFO :    Starting build...
...
INFO :    Creating SIF file...

L’image convertie s’appelle ./busybox_latest.sif. Utilisons-la pour exécuter les commandes identiques à notre test Docker :

$ singularity exec busybox_latest.sif sh -c "echo OK >/tmp/temoin ; cat /tmp/temoin"
OK
$ cat /tmp/temoin
OK
$ stat -c%u /tmp/temoin
1000

Les résultats des commandes parlent d’eux-mêmes :

  • un conteneur lancé par Singularity partage une partie de son système de fichiers avec celui de la machine hôte (quelles parties ? nous le verrons au §4.3) ;
  • le propriétaire du processus lancé dans le conteneur est l’utilisateur qui crée le conteneur avec la commande singularity.

Comme le dit la documentation officielle de Singularity : « the philosophy of Singularity is Integration over Isolation ». C’est-à-dire qu’un utilisateur qui dispose d’une image SIF peut exécuter, dans son répertoire personnel, le logiciel contenu dans l’image : inutile pour cet utilisateur de se préoccuper d’éventuels montages de volumes et de se perdre dans des correspondances entre UID/GID. Le tout sous l’œil bienveillant de l’administrateur qui n’a pas déployé de démon possédant les droits de « root » !

3. Gestion des images

3.1 Obtenir une image

Qui dit conteneurs, dit images ! Et là, il faut bien reconnaître que le nombre d’images disponibles publiquement sur Docker Hub est impressionnant. Singularity dispose d’un principe équivalent, appelé la Library, qui est un dépôt dans lequel vous pouvez stocker vos propres images.

La commande singularity pull permet de télécharger des images ayant des provenances multiples :

$ singularity pull --help

L’aide en ligne de cette commande montre clairement la syntaxe à utiliser pour obtenir des images depuis Docker Hub ou la Library (Singularity Hub est une autre implémentation de la Library).

Par exemple :

$ singularity pull my_busybox.sif docker://busybox:latest
$ ls my_busybox.sif
my_busybox.sif

3.2 Créer une nouvelle image

Il y a plusieurs méthodes pour obtenir une image au format SIF. Tout d’abord, il est possible de convertir une image depuis le format Docker (c’est aussi ce qu’a fait la commande pull précédente) :

$ singularity build ubuntu.sif docker://ubuntu:18.04

L’image obtenue est un exécutable :

$ ./ubuntu.sif ls

L’option --sandbox permet d’obtenir une arborescence complète du contenu de l’image plutôt que l’image elle-même :

$ singularity build --sandbox ubuntu docker://ubuntu:18.04
$ ls ubuntu/

Si vous avez déjà des images dans le cache local de Docker, il est possible de les utiliser ainsi :

$ singularity build ubuntu.sif docker-daemon://ubuntu:18.04

Il y a là une différence fondamentale avec les images Docker : ces dernières sont composées de Layers contenant des fichiers accessibles en lecture seule, associés à des métadonnées (celles qu’on définit dans le fameux fichier Dockerfile). Les images Docker ne sont pas exécutables !

Le format SIF est différent, plus simple, mais moins optimisé : deux images ne partageront jamais de fichiers contrairement aux Layers des images Docker. Par contre, les images SIF sont exécutables comme nous l’avons montré. Il est aussi possible d’obtenir les métadonnées d’une image :

$ singularity inspect --all ubuntu.sif
{
    "data" : {
        "attributes" : {
            "environement" : { ... },
            "labels" : { ... },
            "runscript" : "...",
            "deffile" : "bootstrap: docker\nfrom ubuntu:18.04",
            "startscript" : "#!/bin/sh"
        }
    },
    "type" : "container"
}

L’affichage ci-dessus parle d’un deffile : quel est cet attribut ?

3.3 Les « deffiles »

Les deffiles sont les équivalents des Dockerfiles ! La syntaxe est donc différente, mais tout aussi simple (enfin c’est mon avis) [2].

Un deffile est constitué d’un Header et de Sections. Le nom des Sections débute par un pourcent (%). Singularity supporte (comme Docker) la notion de multi-stage Build (Build à plusieurs étapes), dans ce cas, il y aura plusieurs couples {Header+Sections}.

Un Header doit contenir la directive Boostrap dont la valeur indique le nom de l’Agent qui doit obtenir l’image de base. Par exemple, à partir d’une image Docker, à partir d’une image de la Library, à partir d’une base Debian, CentOS... Les autres paramètres du Header dépendent du choix de l’agent de Bootstrap.

Les Sections sont généralement plus nombreuses, mais sont optionnelles. Le fichier hello.def suivant illustre la syntaxe d’un deffile :

# L’agent de Bootstrap choisi est "docker", donc il faut donner le nom
# de l’image à télécharger à l’aide de la directive From.
 
Bootstrap: docker
From: golang:1.12.3-alpine3.9
 
# La directive "Stage" permet de définir un Build à plusieurs étapes. Ici la 1ère étape
# s’appelle "devel"
Stage: devel
 
# La section %setup permet de définir des commandes qui seront exécutées directement
# sur la machine hôte et non pas dans le conteneur.
# %setup
#   une commande ici
 
# La section %post définit des commandes à exécuter après le %setup,
# elles sont exécutées dans le conteneur :
%post
    PATH="/go/bin:/usr/local/go/bin:$PATH"
    export HOME="/root"
    cd /root
 
# La section %files permet de copier des fichiers depuis la machine hôte dans le conteneur :
%files
    hello.go /root
 
# Le contenu du fichier hello.go est le suivant :
 
#     package main
#     import (
#         "fmt"
#         "os"
#     )
#     func main() {
#         fmt.Printf("Hello %s!\n", os.Getenv("NOM"))
#     }
 
# Une même section peut être définie plusieurs fois...    
%post
    go build -o hello hello.go
 
# Ici, on définit la 2ème étape du Build et on utilise une image de base
# qui provient de la Library :
Bootstrap: library
From: alpine:3.9
Stage: final
 
# On copie un fichier issu de l’étape de Build précédente :
%files from devel
    /root/hello /bin/hello
 
# La section %environment permet de définir des variables d’environnement
# qui seront accessibles par les processus conteneurisés.
%environment
    export NOM=jd
 
# Cette section définit la ou les commandes qui seront exécutées par l’invocation
# de "singularity run <image.sif>"
# La section %startscript a une syntaxe identique mais définit la ou les commandes à exécuter
# par l’invocation de "singularity instance start <image.sif>" (voir plus loin)
%runscript
/bin/hello
 
# La section %labels permet de définir des couples clé/valeur qui seront disponibles
# sous forme de métadonnées avec la commande "singularity inspect <image.sif>"
%labels
    Author jd (jd@maje.biz)
 
# La section %help permet de définir un texte qui sera affiché par la commande
# "singularity run-help <image.sif>
%help
    Image avec un conteneur de démo qui affiche "Hello jd !"
 
# La section %test (absente ici) permet de définir des commandes de tests qui seront
# invoquées par la commande "singularity test <image.sif>"

On suppose que le compilateur go est installé sur votre machine, l’image est construite ainsi (il faut être root) : 

$ sudo singularity build hello.sif hello.def
INFO :    Starting build...
...at au bout de quelques secondes...
INFO :    Creating SIF file...
INFO :    Build complete : hello.sif

Testons notre image :

$ singularity run hello.sif
Hello jd !

3.4 Contenu de l’image

Nous pouvons obtenir les métadonnées de l’image ainsi :

$ singularity inspect hello.sif
Author: jd (jd@maje.biz)
org.label-schema.build-arch: amd64
org.label-schema.build-date: Friday_16_July_2021_9:51:2_CEST
org.label-schema.schema-version: 1.0
org.label-schema.usage: /.singularity.d/runscript.help
org.label-schema.usage.singularity.deffile.bootstrap: library
org.label-schema.usage.singularity.deffile.from: alpine:3.9
org.label-schema.usage.singularity.deffile.stage: final
org.label-schema.usage.singularity.runscript.help: /.singularity.d/runscript.help
org.label-schema.usage.singularity.version: 3.8.0-1.el7

On retrouve bien notre nom d’auteur !

Nous pouvons aussi obtenir l’aide associée à l’image :

$ singularity run-help hello.sif
    Container de démonstration qui affiche le fameux
    "Hello World" à  partir d'un programme écrit en Go.

Nous pouvons explorer le contenu de l’image en créant le répertoire hello/ ainsi :

$ sudo singularity build --sandbox hello hello.def
 
$ cd hello
$ ls -l env* sin*
lrwxrwxrwx. 1 root root   36 16 juil. 10:01 environment -> .singularity.d/env/90-environment.sh
lrwxrwxrwx. 1 root root   24 16 juil. 10:01 singularity -> .singularity.d/runscript
 
$ cat .singularity.d/runscript
#!/bin/sh
/bin/hello
 
$ ls -ls .singularity.d/actions
total 20
4 -rwxr-xr-x. 1 root root 127 26 mars   2019 exec
4 -rwxr-xr-x. 1 root root 603 26 mars   2019 run
4 -rwxr-xr-x. 1 root root 613 26 mars   2019 shell
4 -rwxr-xr-x. 1 root root 283 26 mars   2019 start
4 -rwxr-xr-x. 1 root root 584 26 mars   2019 test

Tout semble clair : quand on lance le conteneur avec la commande singularity run, on invoque le script shell nommé /.singularity.d/actions/run. Ce script « source » les scripts situés sous /.singularity.d/env/ (qui contiennent, entre autres, des variables d’environnement), puis il lance nos commandes qui ont été placées dans /.singularity/runscript !

4. Gestion des conteneurs

4.1 Création de conteneurs

Maintenant que nous savons créer nos propres images, que pouvons-nous en faire ? Singularity propose plusieurs commandes.

singularity run a pour rôle de créer un conteneur et d’exécuter les commandes prévues dans la rubrique %runscript. Il est possible de passer des paramètres à ces commandes :

$ singularity run hello.sif
Hello jd !
$ singularity run docker://ubuntu:18.04 echo Bonjour
INFO:    Using cached SIF image
Bonjour

singularity exec crée un conteneur, mais lance la commande donnée en paramètre plutôt que la commande par défaut :

$ singularity exec hello.sif echo Bonjour
Bonjour

Enfin, singularity shell lance en conteneur et ouvre un shell qui permet d’avoir accès à son système de fichiers.

$ singularity shell hello.sif
Singularity> pwd
/home/jd/singularity/def
Singularity> ls /bin/busy*
/bin/busybox

4.2 Cas des processus de « services »

Les commandes singularity run et exec lancent des processus en « avant-plan », elles ne conviennent pas au lancement de processus qui rendent des « services » et qui doivent être lancés en « arrière-plan ». Dans ce cas, il faut utiliser la commande singularity instance pour gérer ces conteneurs.

Par exemple, pour lancer un serveur nginx dans un conteneur, il faut exécuter :

$ singularity instance start docker://nginx nginx1
INFO:    Converting OCI blobs to SIF format
...
INFO:    instance started successfully
 
$ singularity instance list
INSTANCE NAME    PID      IP    IMAGE
nginx1           14677          /home/jd/.singularity/cache/oci-tmp/353c20f74...

Cette commande invoque normalement les commandes définies dans la section %startscript de l’image (il est possible de surcharger le nom de la commande à démarrer) sinon le programme sinit est exécuté. Dans l’image nginx au format de Docker, il n’y a naturellement pas de rubrique %startscript ! Il faut donc exécuter explicitement nginx dans ce conteneur. Pour cela, nous utilisons la commande exec avec le paramètre instance:// qui permet d’exécuter une commande dans un conteneur actif :

$ singularity exec instance://nginx1 nginx
2021/07/16 10:54:56 [warn] 14#14: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2021/07/16 10:54:56 [emerg] 14#14: mkdir() "/var/cache/nginx/client_temp" failed (30: Read-only file system)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (30: Read-only file system)

Mais nous voyons s’afficher plusieurs erreurs :

  • la première signifie qu’il faut être root pour lancer nginx ;
  • la deuxième souligne le fait que nginx ne peut créer de répertoire dans le système de fichiers du conteneur car, effectivement, les images contiennent un système de fichiers accessible en lecture seule !

Nous allons résoudre ces deux problèmes, mais auparavant, supprimons cette instance :

$ singularity instance stop nginx1
INFO:    Stopping nginx1 instance of /home/jd/.singularity/cache/oci-tmp/353c20f74... (PID=14677)

4.3 Overlays et stockage persistant

Vérifions qu'une image n'est accessible qu'en lecture seule :

$ singularity shell docker://busybox
INFO:    Using cached SIF image
Singularity> mkdir /data
mkdir: can't create directory '/data': Read-only file system

Pourtant, certaines opérations modifiantes sont possibles :

Singularity> pwd
/home/jd/singularity
Singularity> touch toto
Singularity> rm toto

Nous avons pu modifier notre répertoire courant, car, quand un conteneur est créé, Singularity monte les répertoires /tmp, /var/tmp, $HOME et $PWD en lecture/écriture à l’intérieur du conteneur ! Cela facilite le principe d’intégration énoncé au début de cet article !

Imaginons que nous voulions rendre accessible en écriture d’autres répertoires, il faut pour cela utiliser des Overlays qui vont se superposer à des répertoires de l’image :

$ mkdir my_overlay
$ sudo singularity shell --overlay my_overlay docker://busybox
Singularity> mkdir /data
Singularity> echo OK > /data/bonjour.txt
Singularity> exit

Le fichier bonjour.txt se trouve sous my_overlay/upper/data/ (mais il faut être root pour y accéder). Si nous relançons un conteneur, nous retrouvons le contenu du répertoire /data :

$ sudo singularity shell --overlay my_overlay docker://busybox
Singularity> cat /data/bonjour.txt
OK
Singularity> exit

Mais revenons maintenant à notre problème de nginx qui ne pouvait pas démarrer, faute d’accès à un système de fichiers accessible en écriture ! Nous pourrions utiliser le principe des Overlays, mais nous pouvons aussi créer un Overlay « à la volée » pour l’intégralité de l’image. Le lancement de nginx s’effectue ainsi :

$ sudo singularity instance start --writable-tmpfs docker://nginx nginx1
INFO:    Using cached SIF image
INFO:    instance started successfully
$ sudo singularity exec instance://nginx1 nginx
2021/07/16 11:27:56 [notice] 15#15: using the "epoll" event method
2021/07/16 11:27:56 [notice] 15#15: nginx/1.21.1
2021/07/16 11:27:56 [notice] 15#15: built by gcc 8.3.0 (Debian 8.3.0-6)
2021/07/16 11:27:56 [notice] 15#15: OS: Linux 3.10.0-1160.31.1.el7.x86_64
2021/07/16 11:27:56 [notice] 15#15: getrlimit(RLIMIT_NOFILE): 65536:65536
2021/07/16 11:27:56 [notice] 20#20: start worker processes
2021/07/16 11:27:56 [notice] 20#20: start worker process 21
2021/07/16 11:27:56 [notice] 20#20: start worker process 22
$ curl localhost
...
$ sudo singularity instance stop nginx1

4.4 Accès réseau

Par défaut, les conteneurs créés par Singularity disposent de la même configuration réseau que la machine hôte, mais il est possible de leur donner un autre nom de machine (--hostname <host>), un autre serveur de noms (--dns <server>) et de les connecter sur un autre réseau de type « bridge » (--net).

Comme Singularity s’appuie sur des plugins réseau compatibles avec le standard CNI (Container Network Interface), il est possible de donner des paramètres à ces plugins via l’option --network-args.

Démontrons cela sur deux brefs exemples.

Créons un réseau de type Bridge pour isoler des conteneurs, mais de telle sorte qu'ils puissent échanger entre eux via le réseau :

$ sudo singularity shell --net --hostname c1 docker://busybox
Singularity> ifconfig eth0
...inet addr: 10.22.0.2

Dans un autre shell, exécutons la commande suivante :

$ sudo singularity shell --net --hostname c2 docker://busybox
Singularity> ifconfig eth0
...inet addr: 10.22.0.3
Singularity> ping 10.22.0.2
Singularity> exit

Nous voulons maintenant effectuer un « Port mapping » entre le port 8080 de la machine hôte et le port 80 d'un serveur nginx encapsulé dans un conteneur :

$ sudo singularity instance start --net --network-args "portmap=8080:80/tcp" \
                       --writable-tmpfs docker://nginx web
$ sudo singularity exec instance://web nginx
$ curl localhost:8080
...
$ sudo singularity instance stop web

5. Sécurité

Par défaut, utilisateurs et conteneurs sont indignes de confiance (untrusted), ainsi un utilisateur non privilégié qui lance un conteneur ne peut devenir privilégié dans un conteneur et les processus à l’intérieur d’un conteneur ne disposent d’aucune Capability [3] et ne peuvent acquérir de nouveaux privilèges.

5.1 Utilisateurs et Capabilities

Nous allons montrer l'impact des Capabilities sur les conteneurs. Tout d'abord, vérifiez que la commande ping suivante va échouer, mais qu'elle va fonctionner quand on est root :

$ singularity run docker://busybox ping 8.8.8.8
ping: permission denied (are you root ?)
 
$ sudo singularity run docker://busybox ping 8.8.8.8
(fonctionne)

Nous allons maintenant autoriser l'utilisateur à exécuter des conteneurs avec la Capability CAP_NET_RAW (je suis l’utilisateur jd) :

$ sudo singularity capability add --user jd CAP_NET_RAW

Pour activer une Capability, il faut utiliser l'option --add-caps :

$ singularity run docker://busybox ping 8.8.8.8
ping: permission denied (are you root ?)
 
$ singularity run --add-caps CAP_NET_RAW docker://busybox ping 8.8.8.8
(fonctionne)

Supprimez la Capability ainsi :

$ sudo singularity capability drop --user jd CAP_NET_RAW

Pour les curieux, la commande singularity capability a modifié le fichier /etc/singularity/capability.json. Singularity dispose d’autres fichiers de configuration qui permettent de gérer les Control Groups, de localiser les librairies d’accès aux GPU, de configurer le comportement par défaut lors de la création des conteneurs. La commande singularity config permet de gérer le fichier de configuration principal de Singularity.

5.2 Considérations supplémentaires

Il est possible de signer et vérifier les signatures des images utilisées par Singularity (on utilise pour cela les commandes singularity key | sign | verify).

Dans le cas où certains conteneurs nécessitent des privilèges root, sachez qu’il existe une option nommée fakeroot, équivalente du mode rootless de Docker qui permet de donner aux processus conteneurisés les privilèges root, mais uniquement sur les objets appartenant à leur namespace.

Conclusion

Si Docker s’adresse principalement aux développeurs et DevOps qui livrent des applications devant être strictement isolées, Singularity, par sa simplicité et son accent mis sur l’intégration avec le système, est une solution plus adaptée pour les utilisateurs scientifiques. Ceux-ci peuvent ainsi déployer leurs applications conteneurisées sur les clusters de calcul sans menace pour la sécurité du système.

Références

[1] Singularity sur le site de Sylabs.io : https://sylabs.io/singularity/

[2] Syntaxe des « deffiles » : https://sylabs.io/guides/3.8/user-guide/definition_files.html

[3] Liste et définition des Capabilities : https://man7.org/linux/man-pages/man7/capabilities.7.html



Article rédigé par

Par le(s) même(s) auteur(s)

Le stockage de séries chronologiques avec InfluxDB

Magazine
Marque
Linux Pratique
HS n°
Numéro
53
Mois de parution
février 2022
Spécialité(s)
Résumé

Depuis une dizaine d’années, le mouvement NoSQL s’est largement répandu et de nouveaux types de bases de données sont apparus. Parmi celles-ci, les bases de données dites « orientées-séries-chronologiques » (TSDB pour Time Series Database) ont montré leur intérêt pour stocker et analyser des données horodatées. On les retrouve dans différents domaines : de l’Internet des objets (IoT) à la collecte de métriques serveurs et réseau, en passant par la surveillance d’applications, la mesure de performances… Dans ce marché de niche, InfluxDB apparaît comme une solution leader [1].

Comment tester un rôle Ansible avec Molecule ?

Magazine
Marque
Linux Pratique
Numéro
128
Mois de parution
novembre 2021
Spécialité(s)
Résumé

Depuis quelques années Ansible est devenu la référence des outils d’automatisation. Ansible applique des Playbooks au format YAML sur vos machines virtuelles, vos équipements réseau, vos conteneurs, vos clusters Kubernetes... bref, il se veut universel. Mais rapidement, même avec une infrastructure modeste, vous devez organiser vos Playbooks. Pour cela, vous utilisez des Rôles que souvent vous développez vous-même. Ces Rôles vont forcément évoluer et dès lors comment être sûr qu’ils seront toujours fonctionnels et idempotents ? C’est là qu’intervient Molecule : cet outil va vous permettre de tester et valider vos Rôles et ainsi vous assurer que votre dépôt Git ne contiendra que des Rôles dûment opérationnels !

Les derniers articles Premiums

Les derniers articles Premium

Stubby : protection de votre vie privée via le chiffrement des requêtes DNS

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Depuis les révélations d’Edward Snowden sur l’espionnage de masse des communications sur Internet par la NSA, un effort massif a été fait pour protéger la vie en ligne des internautes. Cet effort s’est principalement concentré sur les outils de communication avec la généralisation de l’usage du chiffrement sur le web (désormais, plus de 90 % des échanges se font en HTTPS) et l’adoption en masse des messageries utilisant des protocoles de chiffrement de bout en bout. Cependant, toutes ces communications, bien que chiffrées, utilisent un protocole qui, lui, n’est pas chiffré par défaut, loin de là : le DNS. Voyons ensemble quels sont les risques que cela induit pour les internautes et comment nous pouvons améliorer la situation.

Surveillez la consommation énergétique de votre code

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Être en mesure de surveiller la consommation énergétique de nos applications est une idée attrayante, qui n'est que trop souvent mise à la marge aujourd'hui. C'est d'ailleurs paradoxal, quand on pense que de plus en plus de voitures permettent de connaître la consommation instantanée et la consommation moyenne du véhicule, mais que nos chers ordinateurs, fleurons de la technologie, ne le permettent pas pour nos applications... Mais c'est aussi une tendance qui s'affirme petit à petit et à laquelle à terme, il devrait être difficile d'échapper. Car même si ce n'est qu'un effet de bord, elle nous amène à créer des programmes plus efficaces, qui sont également moins chers à exécuter.

Donnez une autre dimension à vos logs avec Vector

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Avoir des informations précises et détaillées sur ce qu’il se passe dans une infrastructure, et sur les applications qu'elle héberge est un enjeu critique pour votre business. Cependant, ça demande du temps, temps qu'on préfère parfois se réserver pour d'autres tâches jugées plus prioritaires. Mais qu'un système plante, qu'une application perde les pédales ou qu'une faille de sécurité soit découverte et c'est la panique à bord ! Alors je vous le demande, qui voudrait rester aveugle quand l'observabilité a tout à vous offrir ?

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 55 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous