Un monde d'octets

Détruire tous les containers exited

docker rm $(docker ps -qa --filter "status=exited")

Docker est le plus connu des systèmes de container. mais Podman est une alternative poussée par Openshift, le système de clustering de Redhat. Quelques différences sont à connaitre.

Les registries

Docker sait ou chercher des l'installation. Podman non.

Il faut éditer le fichier /etc/containers/registries.conf et y ajouter :

[registries.search]
registries = ["registry.access.redhat.com", "quay.io"]

Si votre registry ne supporte pas https :

[registries.insecure]
registries = ['localhost:5000']

La césure des lignes dans un docker ps m'ennuie toujours. J'aime donc reformater l'output :

docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Ports}}"

Bien sur il existe d'autres formats de sorties (comme json) permettant de "verticaliser" l'output :

docker container ls --format='{{json .}}' | jq

Ce qui est bien pratique, car ca nous donne tous les champs utilisables dans format "table". Bien sur, tout cela est moins puissant que la syntaxe go, mais c'est une autre histoire...

Après avoir joué avec gcloud, pour travaux kubernetes, il peut arriver qu'on ai le probleme suivant :

docker.credentials.errors.InitializationError: docker-credential-gcloud not installed or not available in PATH

En fait, il s'agit d'un reliquat de configuration présant dans .docker/config.json :

{
  "credHelpers": {
    "gcr.io": "gcloud", 
    "us.gcr.io": "gcloud", 
    "eu.gcr.io": "gcloud", 
    "asia.gcr.io": "gcloud", 
    "staging-k8s.gcr.io": "gcloud", 
    "marketplace.gcr.io": "gcloud"
  }
}

Il suffit donc de supprimer les références à gcloud, ou plus simplement détruire le fichier si il n'y a rien d'autre.

Ce jour, un docker qui prend 100% de cpu sur un front web, c'est très probablement lié aux logs …

Purger les logs de traefik avec la commande truncate :

truncate -s 0 $(docker inspect --format='{{.LogPath}}' traefik) %%%

Ca semble régler le problème. Il faudrait voir tout ce qui est loggué, car il y'a surement beaucoup d'inutile ....

Une solution de mitigation, est d"activer une rotation de logs avec docker :

Pour cela, il suffit de modifier le /etc/docker/daemon.json comme suit,

{
   "live-restore": true,
   "log-driver": "json-file",
   "log-opts": {"mode": "non-blocking", "max-file": "7", "max-size": "2G"}
}

Dans le cas présent, la rotation a lieu des que le fichier de log atteint 2 gigas, et seuls les 7 derniers fichiers seront gardé. Ce qui veut dire que pour nos services, chacun à un max de log possible de 14go.

Cette valeur arbitraire est ici assez importante, mais cela est du au fait que seul traefik est présent en container sur ce serveur.

Dans un cas de production, il vaudrait mieux avoir une valeur de base faible, et des options locales au container pour ceux nécessitant plus.

Cela peut se faire au niveau de l'orchestrateur (kubenertes, mesos, ...)

Pour firewaller des container dockerisés, mettre des règles sur le port mappé ne fonctionne pas. En effet, la règle de nat court-circuite la chaine INPUT et envoie le packer sur les chaines DOCKER-*

Pour firewaller, il faut donc utiliser la chaine DOCKER-USER, en réspectant :

• Il faut insérer avant l'unique règle qui laisse tout passer
• Il faut utiliser le port dans l'environnement containérisé car nous ne somme plus dans le contexte hôte

C'est bien pensé, ca marche, mais c'est tout sauf évident. Enfin bon, c'est bien pensé et ca marche, mais si on peut s'en passer (par exemple en n'exposant pas le port, ou au moins pas 100% publiquement, on peut s'affranchir de complexifier l'iptables).

Il existe beaucoup d'outils utilisant la socket de docker pour administrer docker et proposer des cui et gui très intéressantes

Analyse d'un container :

docker run --rm -it \
    -v /var/run/docker.sock:/var/run/docker.sock \
    wagoodman/dive:latest <dive arguments...>

Monitoring curses :

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock lazyteam/lazydocker

docker run --rm -ti \
  --name=ctop \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  quay.io/vektorlab/ctop:latest

WebUI :

docker volume create portainer_data 
docker run -d -p 9000:9000 -p 8000:8000 \
   --name portainer --restart always \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -v portainer_data:/data portainer/portainer

Installation de docker

apt install docker.io docker-compose:w

Récupération de l'image de Jenkins

docker pull jenkins/jenkins

Trouver l'emplacement des fichiers de docker:

docker info | grep Root

Docker Root Dir: /var/lib/docker

Création d'un docker-compose

vi docker-compose.yml

version: "3"
services:
   jenkins:
      container_name: alfred
      image: jenkins/jenkins
      ports:
         - "8080:8080"
      volumes:
         - "/srv/jenkins:/var/jenkins"
      networks:
         - net
   networks:
      net: 

Il est nécessaire créer le home de jenkins :

mkdir /srv/jenkins

Ainsi nous avons sur le serveur hébergeant les containers, un volume pour le container jenkins

Dans un contexte d'ordonnanceur externe à docker, comme kubernetes, la vie d'un container n'est pas éternelle, et même pire, elle peut être très courte (selon le cycle de développement du service proposé).

Il n'est donc pas rare de voir sur les nodes des container qui sont en état "Exited since ...". Ces container peuvent correspondre à des suppression de pods et services, puis à la récréation de ceux-ci, ce qui peut nous donner de jolis semis doublons lors d'un :

docker ps -a

Kubernetes ne fait pas le ménage sur les nodes, ni meme sur le controlleur, exemple :

root@Krilin:~$ docker ps -a | grep weave
776a6b33278f        1f394ae9e226           "/home/weave/launch.…"   4 minutes ago            Exited (1) 4 minutes ago                                k8s_weave_weave-net-vzv6m_kube-system_6d5bf007-31d6-11e9-8af5-e094673af96c_3348
a7714ac685e7        789b7f496034           "/usr/bin/weave-npc"     13 hours ago             Up 13 hours                                             k8s_weave-npc_weave-net-vzv6m_kube-system_6d5bf007-31d6-11e9-8af5-e094673af96c_3
b823cbb9669c        k8s.gcr.io/pause:3.1   "/pause"                 13 hours ago             Up 13 hours                                             k8s_POD_weave-net-vzv6m_kube-system_6d5bf007-31d6-11e9-8af5-e094673af96c_3
467b8f9b7802        789b7f496034           "/usr/bin/weave-npc"     14 hours ago             Exited (1) 13 hours ago                                 k8s_weave-npc_weave-net-vzv6m_kube-system_6d5bf007-31d6-11e9-8af5-e094673af96c_2
c8309215ce8b        k8s.gcr.io/pause:3.1   "/pause"                 14 hours ago             Exited (0) 13 hours ago                                 k8s_POD_weave-net-vzv6m_kube-system_6d5bf007-31d6-11e9-8af5-e094673af96c_2

Pour nettoyer tout cela, nous pouvons faire un script shell qui cherchera le mot Exited pour ensuite faire un docker rm sur l'id du container associé, mais il restera encore a faire des "prune" sur les volumes pour que le nettoyage soit complet.

Il existe une commande plus directe dans docker :

docker system prune

rootKrilin:~$ docker system prune
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all dangling build cache
Are you sure you want to continue? [y/N] 

Si vous repondez "y" vous voyez alors les suppressions faites :

Deleted Containers:
118d43446820ee48fbc2448f458fd310da1a2fa8e9c4288eebc687f6ead02b40
7bd02c21bd056f2206deafb8d2c1f962e460726ea5baac382326315c0200fae6
2d13ae91cd9b2c2c0a0ef6deae378da973eb09a353778c386b946143cd5da611
5c01da141458bad077f8398d235cc29aa571816d9fc377a54663fe60a7b551fa
748087e020c6a012e25a8b78321c45c86471de22f0fbc5e4e14936fa88090382
8ad02c451417f9b4c6c016b330775082b64330284ba9e4eaa20e064fb9f6cf3f
1a8bc77db31831bd0ef177d7a70b0ddafd2f1d9a69a2d7f1f504da69a15f838e
624f19e5050ced840a31e17b857071f25c30afdb46719cb28429ecb7853c2090
c2430cafa2a988cecebffb16ce7a5c90f78dc18053003dd8d6f0cdea438b8473
1796f28b9dbc1c2c31724e91d031a12eae19b1b513c168dec236005e42036969
20fcbb1c937042ef86dccd03f60f59c168947cfc0440fbc20bd99052fdb5a789

Total reclaimed space: 0B

Le 0B correspond à l'espace récupéré sur les volumes. Mais le ménage a bien été fait question reliquats de containers et d'images inutiles.

On y voit un peu plus clair, non ?

Wekan est une implémentation libre en node-js d'un kanban !
Pour héberger un container docker Wekan chez vous, voici un docker compose récupéré sur internet :

version: '2'
services:
  wekan:
    image: wekanteam/wekan:latest
    links:
      - wekandb
    environment:
      - MONGO_URL=mongodb://wekandb/wekan
      - ROOT_URL=http://localhost:80
    ports:
      - 80:80

  wekandb:
    image: mongo:3.2.14
    volumes:
      - /srv/wekan/data:/data/db

le répertoire /srv/wekan/data contiendra les données à backuper de votre kanban.
il sera accessible a http://localhost/

Personnellement je conseillerai pltot d'annuler le redirect de ports, et de faire sur l'hote englobant un reverse proxy qui mappe le http://ip-du-container:80/ en http[s]://localhost/wekan/

Supervisor est un service pour lancer automatiquement et surveiller d'autres services. Il est donc très utile pour les containers ne disposant pas d'un boot complet et donc de scripts de démarrage des services.

Nous allons donc faire une image qui utiliser supervisor comme point d'entrée du container.

Pour commencer, créons un container avec le Dockerfile suivant :

FROM ubuntu:latest
RUN apt-get update && apt-get install -y supervisor
RUN apt-get install -y apache2
RUN mkdir -p /var/log/supervisor
COPY apache2.conf /etc/supervisor/conf.d/apache2.conf
COPY entry-point.sh /entry-point.sh
RUN chmod -R 755 /entry-point.sh
CMD ["/entry-point.sh"]

Dans le fichier apache2.conf, nous avons mis la configuration de lancement d'apache suivante :

[program:apache2]
command=/usr/sbin/apache2ctl -DFOREGROUND
autostart=true
autorestart=true
startretries=3

Enfin le script entry-point.sh lance simplement supervisor en mode no-deamon :

#!/bin/sh

/usr/bin/supervisord -n

Compilons l'image :

docker build -t pepiniere .

Créons notre container :

docker create --name testdrive pepiniere

Puis nous pouvons constater que le container testdrive (qui a ici l'ip 172.17.0.3) fait bien tourner apache !!

curl -I http://172.17.0.3

Voila, nous avons un container docker testdrive qui fait tourner un apache2 !

L'entry-point et supervisor étant fonctionnels, il reste maintenant à faire des container de bases, pour industrialiser les déploiements, par exemple :

• une image wordpress
• une image apache+php+mysql
• une image elastiksearch+kibana+logstash
• une image ubuntu de base

Bien sur chacune de ses images aura un prérequis : le fonctionnement d'ansible et la mise en place des clefs ssh initiales nécessaires ! Ansible pourra se charger de la mise en place et révocation des clefs ssh des utilisateurs additionnels.

Pour que le réseau des containers Docker fonctionne, il faut de la translation d'adresse. Docker fait donc le travail tout seul au lancement ... Cependant si vous avez déjà paramétré iptables sur votre poste, Docker va court-circuiter tout ça sans vous prévenir.

Il faut donc dire a docker de ne pas toucher au firewall.

Pour cela, ajouter dans le fichier /etc/default/docker la ligne :

DOCKER_OPTS="--iptables=false"

Docker ne placera plus de règles iptables lui même. Mais vos containers n'ont plus accès à internet ....

Pour rétablir leur accès, voici ce qu'il faut ajouter deux règles iptables :

la première fait une translation d'adresse sortante, en mappant votre réseau Docker sur votre ip sortante de votre hôte docker, exemple :

-A POSTROUTING -s 172.16.0.0/16 ! -o docker0 -j SNAT --to-source 10.0.0.1

la deuxième règle autorise votre interface docker0 à se connecter à votre réseau local :

-A INPUT -i docker0 -j ACCEPT

Attention au placement de ces règles dans votre firewall, car rappel : la première règle qui correspond est appliquée !

Voila c'est tout ce qu'il faut savoir pour avoir un docker fonctionnel, tout sage qui ne parasite pas son hôte. Bien sur, il faut adapter et étendre ce concept à votre plan ip de containers et même aux différents types de réseaux docker que vous utilisez.

Cacti est un bon outil de monitoring réseau, mais l'installation et le paramétrage lors de la reinstallation complète du pc est une épine dans le ....

Historiquement, j'aurai opté pour une machine virtuelle, mais maintenant, docker est bien plus séduisant, d'autant plus qu'il existe des images de cacti déjà faites pour docker !

Récupération de l'image docker de base et démarrage

docker pull quantumobject/docker-cacti
docker create -t -i --name cacti --dns=8.8.8.8 --restart unless-stopped quantumobject/docker-cacti
docker start cacti

L'ip du container cacti s'obtient ainsi :

echo "cat /etc/hosts" | docker exec -i cacti bash

127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet, par exemple figer l'ip et parametrer les dns avec les options suivantes 
ff00::0	ip6-mcastprefix, par exemple figer l'ip et parametrer les dns avec les options suivantes
ff02::1	ip6-allnodes.1.3.6.1.4.1.2021.52
ff02::2	ip6-allroutersf5e91448b6d2
172.17.0.2	f5e91448b6d2castorama

ici, f5e91448b6d2 est l'identiant du container cacti. Nous pouvons donc nous connecter a http://172.17.0.2 et nous arrivons sur l'interface de cacti !

Une fois notre cacti paramétré, il reste à en faire une nouvelle image de container puis à faire un tar pour archivage !

docker stop cacti
docker commit cacti teknomage/cacti
docker save teknomage/cacti -o docker-cacti.tar

Nous pouvons alors, sur un autre serveur, reimporter l'image et recréer le container comme suit :

docker load -i teknomage.cacti.tar
docker create -t -i --name raster --restart unless-stopped teknomage/cacti
docker start raster

Une fois l'ip de raster determinée, une connection à http://{ip} nous montre bien notre cacti tout paramétré et meme avec l'état des graphes au moment du commit.