Tuto Docker - Les commandes et Docker (partie 3)

Vous savez ce qu'est Docker et vous connaissez les bases de son utilisation ? Apprenez désormais à aller plus loin dans l'utilisation de l'API pour commander la baleine. Les choses sérieuses débutent !

Cet article fait partie d'une série de billet portants sur Docker et son environnement :

• Tuto Docker : comprendre Docker (partie1)
• Tuto Docker : démarrer Docker (partie 2)
• Tuto Docker : les commandes Docker (partie 3)

Dans ce troisième article, nous allons parler un peu plus de la partie « commande ». Si vous n'avez pas lu les 2 articles précédents, je vous conseille de le faire avant d’entamer celui-ci.

Introduction

Depuis que je travaille avec Docker, je n'ai fait que progresser et découvrir des facettes peu visibles pour les non-initiés. C'est après deux meetups sur Lyon (un premier présenté par David Gageot et un second présenté par Jérémy Petazzoni dans le cadre du Docker Tour (de France)) que j'ai pu comprendre certaines subtilités de l'API.

Lorsqu'on installe Docker, il faut savoir que d'une manière transparente, vous n'installez pas un, mais deux produits. Le premier, nous en avons beaucoup parlé, il s'agit des commandes shell. C'est que j'ai appelé docker-cli. La seconde partie, je vous l'ai vaguement décrite : il s'agit de la partie serveur. Oui, Docker est avant tout un service. D'ailleurs, si vous l'utilisez sur Linux, il vous arrivera probablement de devoir démarrer le service. Détaillons maintenant cette partie que Jérémy Petazzoni a nommé l' « engine » ou encore le « core » lors du Docker Tour à Lyon.

Docker, un service avant tout

Docker est un service, et comme tout service, avant de répondre à des commandes user-friendly il répond à une API. Cette API RESTFul est par conséquent disponible via IP ou via une socket. Par défaut, quand vous utilisez docker-cli, les commandes sont réalisées sur votre socket local, généralement dans /run/docker.sock.

Bien évidemment, vous pouvez configurer cette entrée.

$ docker
…
Options:
  --api-enable-cors=false                        Enable CORS headers in the remote API
  -b, --bridge=""                                Attach containers to a pre-existing network bridge
                                                   use 'none' to disable container networking
  --bip=""                                       Use this CIDR notation address for the network bridge's IP, not compatible with -b
  -D, --debug=false                              Enable debug mode
  -d, --daemon=false                             Enable daemon mode
  --dns=[]                                       Force Docker to use specific DNS servers
  --dns-search=[]                                Force Docker to use specific DNS search domains
  -e, --exec-driver="native"                     Force the Docker runtime to use a specific exec driver
  --fixed-cidr=""                                IPv4 subnet for fixed IPs (ex: 10.20.0.0/16)
                                                   this subnet must be nested in the bridge subnet (which is defined by -b or --bip)
  -G, --group="docker"                           Group to assign the unix socket specified by -H when running in daemon mode
                                                   use '' (the empty string) to disable setting of a group
  -g, --graph="/var/lib/docker"                  Path to use as the root of the Docker runtime
  -H, --host=[]                                  The socket(s) to bind to in daemon mode or connect to in client mode, specified using one or more tcp://host:port, unix:///path/to/socket, fd://* or fd://socketfd.
  --icc=true                                     Enable inter-container communication
  --insecure-registry=[]                         Enable insecure communication with specified registries (no certificate verification for HTTPS and enable HTTP fallback) (e.g., localhost:5000 or 10.20.0.0/16)
  --ip=0.0.0.0                                   Default IP address to use when binding container ports
  --ip-forward=true                              Enable net.ipv4.ip_forward
  --ip-masq=true                                 Enable IP masquerading for bridge's IP range
  --iptables=true                                Enable Docker's addition of iptables rules
  --mtu=0                                        Set the containers network MTU
                                                   if no value is provided: default to the default route MTU or 1500 if no default route is available
  -p, --pidfile="/var/run/docker.pid"            Path to use for daemon PID file
  --registry-mirror=[]                           Specify a preferred Docker registry mirror
  -s, --storage-driver=""                        Force the Docker runtime to use a specific storage driver
  --selinux-enabled=false                        Enable selinux support. SELinux does not presently support the BTRFS storage driver
  --storage-opt=[]                               Set storage driver options
  --tls=false                                    Use TLS; implied by tls-verify flags
  --tlscacert="/home/baptiste/.docker/ca.pem"    Trust only remotes providing a certificate signed by the CA given here
  --tlscert="/home/baptiste/.docker/cert.pem"    Path to TLS certificate file
  --tlskey="/home/baptiste/.docker/key.pem"      Path to TLS key file
  --tlsverify=false                              Use TLS and verify the remote (daemon: verify client, client: verify daemon)
  -v, --version=false                            Print version information and quit
…

Parmi ces options, vous remarquerez --host qui vous permettra de travailler avec un autre serveur via une IP par exemple. De cette manière, on peut très bien imaginer déployer un nouveau container sur un serveur de production sans pour autant se connecter via SSH. Cette partie peut paraitre innocente, mais a pour objectif de faciliter les évolutions du serveur (la partie core), du client (la partie cli), mais également de permettre le développement d'applications tierces ((il s'agit de l'API JSON).

Un peu plus loin dans l'utilisation de l'API

Il est une chose de se servir des commandes dans un terminal manuellement, mais peut-être aurez-vous le besoin de créer une application permettant de manager vos images et vos containers un peu plus facilement.

Pour ma part, j'ai testé l'API JSON avec un projet « maison » disponible sur GitHub. Dans cette petite application web, je contrôle la mise en pause et l’extinction des containers. C'est peu, mais c'est un extrait de ce que l'on peut faire.

Même si Docker a vocation à être utilisé par de gros systèmes ainsi que par des personnes initiées, il peut être bien dans certains cas d'avoir un peu de visuels. D'ailleurs, des solutions ont vu le jour pour monitorer ces containers. Celle-ci ne se repose pas en intégralité sur Docker, mais également sur le composant cgroup, l'un des trois composants nécessaires au fonctionnement de Docker.

Vous pouvez imaginer toutes sortes d'applications, et même manager un cluster en lançant des opérations sur plusieurs serveurs depuis la même console. Pour ce qui est de la configuration des serveurs, vous devez savoir que chaque instance devra être lancée comme démon et devra écouter une plage d'IP et un port. Je vous laisse chercher comment réaliser cette opération.

Conclusion

Docker est avant tout une API. Il existe plusieurs moyens de gérer ces containers. En plus des commandes que l'on utilise par défaut.  L'intégralité de la documentation est disponible ici.