Docker отказва да създаде мрежа със съобщението, че пулът се застъпва с друг в това адресно пространство, и някой решава, че причината трябва да е маршрутът през VPN. Не може да бъде. Тази грешка се получава, докато се разпределя пул, преди да съществува дори един пакет, и ръчен маршрут в ядрото няма никакво отношение към нея. VPN има значение една стъпка по-късно, когато контейнер, който вече има адрес, престане да бъде достъпен след появата на маршрут. Два проблема, два набора доказателства и смесването им води до промяна, която не поправя нито един от двата.

Две грешки, които изглеждат еднакво

Грешката при разпределяне е аритметична. Docker сравнява подмрежата, която сте поискали, с подмрежите, които вече управлява, намира застъпване и отказва. Още нищо не работи, затова няма маршрут, няма контейнер и няма трафик за преглед.

Симптомът по време на работа е въпрос на достижимост. Контейнер, който отговаряше вчера, сега не отговаря и нещо се е променило в таблицата за маршрутизиране на хоста. Контейнерът все още държи адреса си; въпросът е по кой път минава този адрес.

И двете са проблеми на адресния план. Само едната от тях е проблем на Docker.

Първо прочетете разпределените пулове

Избройте мрежите и прегледайте тези, които биха могли да се застъпят. Подмрежата живее в конфигурацията на IPAM, а прикачените контейнери се изброяват отделно:

docker network ls
docker network inspect EXISTING_NETWORK

Сравнете тази подмрежа с пула, който новата мрежа иска, и помнете, че Compose създава собствена мрежа по подразбиране за всеки проект. Конфликт с проект, който сте забравили, изглежда точно като конфликт с демона.

Статичният ipv4_address в услуга е адресът на един контейнер, а не дефиницията на пула. Промяната му не премахва застъпване, защото застъпването е между мрежови подмрежи, а не между контейнери. Справочникът за създаване на мрежи на Docker изисква незастъпващи се подмрежи за обичайното разпределяне през мост и описва как да изберете една изрично.

Изберете префикс, който оцелява през VPN

Непосредственият конфликт и бъдещият маршрут се решават от един и същ избор, затова го направете веднъж. Сравнете кандидат-диапазона с LAN, с всяка дестинация през VPN, до която хостът може да достигне, и с всеки друг използван overlay.

Префикс, който удовлетворява Docker и се сблъсква с отдалечената мрежа, ви дава контейнер, който стартира чисто и става недостъпен в момента, в който тунелът се вдигне. Това е втората грешка в тази статия и е много по-трудно да се диагностицира по-късно, отколкото да се избегне сега.

Запишете избраните диапазони някъде, където следващият проект може да ги прочете. Регистър на разпределените префикси на един ред е по-евтин от седмица необясними таймаути.

Извеждайте или променяйте мрежа умишлено

За нова мрежа на Compose задайте неизползвания префикс в IPAM конфигурацията на мрежата. За съществуващ проект планирайте преномерирането: фиксираните адреси, зависимите услуги и стъпката за пресъздаване на мрежата трябва да бъдат отчетени, защото редактирането на YAML не преномерира работеща мрежа.

Ако остаряла мрежа притежава конфликтното разпределение, проверете кой е прикачен, преди да я премахнете. docker network rm отказва, докато съществуват активни endpoint-и, а docker stop приема имена или ID на контейнери, а не име на мрежа. Спирането на контейнер също не премахва дефиницията на мрежата, която държи пула.

Широкият prune не е диагностичен инструмент. Той достига до несвързани проекти и унищожава доказателствата, които щяхте да съберете.

Пуловете по подразбиране помагат само за следващото разпределение

Настройката за пул от адреси по подразбиране на демона подобрява бъдещите автоматични разпределения, като ги държи извън диапазоните, които резервирате. Тя не пренасочва обратно мрежи, които вече съществуват и не решава изрична подмрежа, която се застъпва с друга изрична подмрежа.

Отнасяйте се към тази настройка като към отделна, планирана промяна със собствен рестарт, а не като част от поправянето на един проект. Смесването на двете означава рестарт на демона по средата на несвързано разследване. Насрочете го в отделен прозорец. След това потвърдете, че едно ново автоматично разпределение наистина попада извън диапазоните, които резервирахте.

След като създаването успее, проверете подмрежата, която реално работи, и след това направете една истинска заявка към приложението, докато VPN е в предвиденото състояние. Ако пулът е валиден, а достъпът все още се проваля, останалата работа е избор на маршрут, филтриране и обратен път. Това е разследване по време на работа и то не прави грешката при разпределянето обратно безсмислена.

Ред на работа: прочетете разпределените пулове, изберете префикс, който избягва и Docker, и дестинациите през VPN, пресъздайте мрежата умишлено, след което тествайте една заявка с вдигнат тунел.

Подобни статии