Docker Troubleshooting

Docker deamon logging

Чтобы поменять уровень логировния нужно для начала остановить демон и запустить с измененным уровнем логирования

# service docker stop
docker stop/waiting
# docker -d -l debug &

Но чтобы это было более удобно для сервиса(когда он подымается атоматически, а не руками):

# /etc/default/docker
DOCKER_OPTS="--log-level=fatal"

Docker Container Logging
В контейнере обычно запущен один процесс, который свой аутпут направляет в стандартные подтоки, это докер все сохраняет в json-не. Чтобы это увидеть мы делаем:

# docker logs name_of_container

Так мы увидим последнии строки на момент запроса, чтобы привязаться и наблюдать, все как в tail:

# docker logs -f name_of_container

Если логи нужны снаружи, то хорошая идея привязать вольюм.


Если мы билдим Dockerfile и он упал, то можем посмотреть через docker ps Id последнего успешного образа, который получилось собрать - у него не будет колонок репозитория и тега, мы можем его запустить интерактивно docker run -it 23423423 /bin/bash  и по сообщениям билда мы впринципе поймем на каком этапе оно упало, и начнем пробовать руками, что не так и как попровить.

Docker bridge0
Хоть и докер имеет дефолтовые диапазоны айпишек для выбора, в больших сетях есть вероятность того, что такие айпишки будут заняты, поэтому бывает ситуация, когда мы явно должны указать с какого диапазона выбирать.
Рецепт:

# service docker stop
# ip link del docker0
# echo "DOCKER_OPTS=--bip=150.150.0.1/24" > /etc/default/docker
# service docker start 
# ip a #проверяем

bip -- bridge ip

Работа с фаерволом
У докера есть две опции отвечающие за правила для iptables фаервола. Обе они по-умолчанию == true
--icc - intercontainer communications
--iptables - может ли docker вносить изменения в фв.
Если icc поставить в false, то в iptables появится правило DROP пакетов для исходящих из docker0 интерфейса и входящих в docker0 интерфейс:

# service docker stop
# echo "DOCKER_OPTS=--icc=false" > /etc/default/docker
# service docker start 
# iptables -L -v #проверяем

iptables поставить в false, а icc в true, но при этом прошлый запуск icc был в фолсе, то новый перезапуск не уберет блокировку межконтейнерной коммуникации, потому что в этот раз мы заблокировали изменения фв, мораль такова - что docker не запоминает, что он делал раньше с фв, а только реагирует на указание, что на этот раз никаких изменений он делать не может в iptables