Після вставнолення свіжої версії "Ubuntu 22.04.3 LTS" я помітив що в один з моїх докер середовищ перестав нормально працювати.
В минулому налаштуванні контейнери всередині мережі мали бачити один одиного за допомогою налаштованих в traefik хостів.
Але всі curl команди виповнялись з помилкою.
cURL error 7: Failed to connect to test.my-docker.localhost port 443 after 0 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://test.my-docker.localhost/
Я також перевірив що контейнери самі по собі не знали своїх хост імен.
Копаючи глибше цю проблема я побачив що адреса хост нейму закінчувалась на local host. Але у минулому налаштуванні я бачив корректну IP адресу із docker мережі.
Ось вивід команди nslookup всередині контейнера:
# nslookup test.my-docker.localhost
Server: 127.0.0.11
Address: 127.0.0.11:53
Name: test.my-docker.localhost
Address: ::1
Name: test.my-docker.localhost
Address: 127.0.0.1
Для локальних налаштувань ns resolver сімлінка лежить у файлі /etc/resolv.conf
У новій систмені воно мало наступні налаштування:
nameserver 127.0.0.53
options edns0 trust-ad ndots:0
search lan
В минулій система парамерт options був відсутній взагалі. Але проблема була в параметрі trust-ad. Я спробував видалити його редагуванням і перезапустити сервіс systemd-resolved.service.
Це не допомогло. Також я мав спробу редагувати файл /run/systemd/resolve/stub-resolv.conf. Без жодного результату.
Тому що цей файл менеджеться сервісом і оновлюється автоматично.
# sudo nano /run/systemd/resolve/stub-resolv.conf
# sudo systemctl stop systemd-resolved.service
# sudo systemctl start systemd-resolved.service
В одному з контейнерів я встановив resolvconf для редагування конфігів.
# sudo apt install resolvconf
# sudo systemctl start resolvconf.service
# sudo systemctl enable resolvconf.service
Вона була встановленна, запущена і доступна. Без додаткових кроків і параметр options був видалений за файлу /etc/resolv.conf.
Після перезапуску контейнерів і перевірки nslookup воно мало корректні значення.
# nslookup test.my-docker.localhost
Server: 127.0.0.11
Address: 127.0.0.11:53
Non-authoritative answer:
Non-authoritative answer:
Name: test.my-docker.localhost
Address: 172.18.0.2
І команда curl запрацювала в нормальному режимі.
curl -v test.my-docker.localhost
Але це був не кінець моїх пригод і кошмарів.
Запустивши деякі локальні докер середовища я виявив що curl продовжував невірно працювати.
Я використовував php:8.1-fpm імейдж. php версія на минулій системі була 8.1.7, але на новій в новому контейнері вона оновилась до останної версії 8.1.23.
Змінивши версію імелда на стару php:8.1.7-fpm виправило помилку. Також я перевірив що остання версія php:8.1-fpm-bullseye працює. І це добре.
Але я не міг заспокоїтись чому так вийшло і продовжив пошуки. Нова версія контейнера була основана на Debian 12 bookworm! У якій curl був оновлений до версії 7.88.1.
Надалі я не мав часу переглядати комміти curl і debian в репозиторіяї. Добре що воно запрацювало і так.
Один висновок я точно визнав для себе: використовувати більш точну версію імеджей для контейнерів докера, щоб попередити випадки коли оновлений конейнер може зламати весь стек локального середовища для розробкки.
Нижче наведена інформація про версії програмного забезпечення у контейнерах.
image: php:8.1-fpm-bullseye
based on debian 11 bullseye
# php --version
PHP 8.1.23 (cli) (built: Sep 20 2023 19:35:44) (NTS)
# curl --version
curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09
# uname -a
Linux e066bda8b1f1 6.2.0-33-generic #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 10:33:52 UTC 2 x86_64 GNU/Linux
image: php:8.1-fpm
based on debial 12 bookworm
# php --version
PHP 8.1.23 (cli) (built: Sep 20 2023 19:22:02) (NTS)
# curl --version
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.9 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3
Release-Date: 2023-02-20
# uname -a
Linux 91be946a6b4f 6.2.0-33-generic #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 10:33:52 UTC 2 x86_64 GNU/Linux
Коментувати