Iptables & docker & porter2

A propos de discuter.rezo.net
#1

Envoyé ce jour:

Bonjour cher support-dans-la-cave (c’est dit avec le plus grand respect!),

Sur porter2.octopuce.fr je me suis retrouvé confronté à l’erreur suivante:

$ docker start app
Error response from daemon: driver failed programming external connectivity on endpoint app (72ee6d39382abefa069c1732fe366d1eeaaa0fafbff9977c331bf715
4703d248): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 8000 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0:
iptables v1.8.2 (nf_tables): Chain ‹ DOCKER › does not exist
(exit status 1))
Error: failed to start containers: app

Qui a été résolue facilement avec:

$ systemctl restart docker

qui re-install les règles iptables qui vont bien.

Afin d’éviter que cela se reproduise à l’avenir, je me demande s’il n’y aurait pas un module puppet qui touche à iptables et provoquerait ce problème ?

A++

#2

Réponse ce jour:

Bonjour,

effectivement puppet touche à nos iptables il y a eu du changement dans nos
règles de forwarding. Ce qui du coup a pu/du le bazar avec docker.

Je vois en interne pour refiler le sujet à quelqun.

Cordialement,

#3

Suite ce jour:

Après en avoir discuté on va ouvrir ticket gitlab pour gérer ce cas là lors
de nos changements de conf par feu (c’est pas très fréquent en moyenne, mais
là on bosse dessus donc ca risque d’arriver une paire de fois dans les
prochaines semaines).

Est ce que ca vous conviendrait que pour le moment on redémarre le docker
lorsque l’on pousse des modifications sur nos FW de façon globale?

#4

Ma réponse:

Aucun problème de mon coté, c’est très bien! Ca n’impacte pas les containers en cours d’execution.

Merci beaucoup :slight_smile:

#5

Message ce jour:

Nous avons eu à remodifier nos règles firewall parce qu’un « bug » (ou plutôt
une erreur humaine) faisait que nous dropions tout trafic pendant le
rechargement des règles, qui peut prendre de plusieurs secondes à 1 ou 2
minutes.

J’ai donc redémarré le service docker sur porter2 pour qu’il recrée les
chaines DOCKER, mais le conteneur local_discourse/app ne s’est pas relancé
(conflit de port 8000), et le conteneur local_discourse/import, qui ne
tournait pas avant le restart, lui est en route (et squatte le port 8000).

Du coup je préfère te laisser gérer la situation, étant donné que
discuter.spip.net fonctionne (mais pas discuter.rezo.net)…

#6

Répondu ceci à l’instant:

Bonjour,

Pour éviter toute confusion à l’avenir j’ai supprimé le conteneur import qui ne doit jamais être démarré.

docker stop import
docker rm import

Et j’ai lancé le conteneur app avec:

docker start app

Tout semble être revenu dans l’ordre. Pour archive pourrais tu me donner le détail des commandes que tu as lancées sur la machine pendant cette opération ? Je ne comprends pas du tout comment le conteneur import a pu se lancer tout seul. Si c’est toi qui l’a fait alors je comprends. Sinon il y a un combo mystérieux qui mérite reflexion.

Merci pour le debug en tout cas: bien soulagé de ne pas avoir à s’inquiéter pour les prochains passages puppet :thumbs_up: :slight_smile:

A++

#7

Réponse reçue:

Salut,

Loïc Dachary writes

Bonjour,

Pour éviter toute confusion à l’avenir j’ai supprimé le conteneur import qui
ne doit jamais être démarré.

docker stop import
docker rm import

Et j’ai lancé le conteneur app avec:

docker start app

Merci, ça évitera également qu’il se (re)lance en cas de reboot de la
physique ou de la VM.

Tout semble Être revenu dans l’ordre. Pour archive pourrais tu me donner le
détail des commandes que tu as lancées sur la machine pendant cette
opération ? Je ne comprends pas du tout comment le conteneur import a pu se
lancer tout seul. Si c’est toi qui l’a fait alors je comprends. Sinon il y a
un combo mystérieux qui mérite reflexion.

Après le passage de puppet, je me suis contenté de faire :

docker ps (pour observer)
systemctl restart docker.service (comme indiqué dans ton mail précédent)
docker ps (pour observer)

puis docker ps -a pour constater que app ne tournait pas.
Et docker logs pour regarder les logs.

Donc c’est le restart du service docker qui est le seul coupable possible
(les autres commandes étant sans effet de bord).

Merci pour le debug en tout cas: bien soulagé de ne pas avoir à s’inquiéter
pour les prochains passages puppet :thumbs_up: :slight_smile:

Alors non, on n’a pas résolu le problème au fond (puppet qui dégage les
règles posés par docker). Il faut qu’on y travaille, à coup d’iptable-save ou
autre, et qu’on manipule nos règles sans trop toucher à celles de docker…

Merci pour ton action.