Comments 47
По части возведения железного занавеса у нашего Рос[**********] все больше и большее не менее достойных ситуативных союзников на Западе.
Завет дедушки Черчилля живее всех живых.
Вангую, что список стран будет расширяться.
А где тут железный занавес? Тебя из страны не выпускают? Или на завод силой загнали? Оброк повысили до 99%? Не дают поменять барина?
Про Европу и США, по твоей же логике, тоже можно сказать: "Всё меньше и меньше у них союзников в Евразии (РФ, Белоруссия и даже Грузия в последнее время), и в Азии, и на Ближнем Востоке, и в Африке, и в Латинском Америке. Никто уже с ними дело иметь не хочет."
Рестарт докера
Буквально вчера для себя узнал о возможности перезагрузки конфигурации без рестарта контейнеров (для настроек зеркала релоада достаточно). Оно вроде бы очевидно, и с nginx-ом таким пользуюсь периодически, а вот про докер не зналsudo systemctl reload docker
Это, вроде, стандарт линуксовый. Системд при этом шлёт определённый сигнал процессу демона, а тот должен при этом перечитать конфиг.
То есть это общий подход.
Это не "стандарт" ни в коем разе. Если в юните нет ExecReload - то systemd вообще откажется что-либо делать при systemctl reload.
Есть устоявшийся паттерн, что приложение может реализовать перезагрузку конфига через отправление ему определенного сигнала (обычно SIGHUP, но в сущности любого), но не существует некоего стандартного SIGRELOAD или ещё чего в таком духе. Да и не сигналами едиными, можно реализовать это через некий ipc (dbus, например), или через дёрганье http endpoint'a для http сервисов, кто во что горазд короче.
И тем не менее, systemctl reload - первое что нужно попробовать. Вот когда не сработало - тогда и нужно думать над рестартом.
А как же "killall -HUP processname"? Я им ещё в FreeBSD 4.2 пользовался при добавлении почтовых ящиков...
Проблема, о которой писали выше, в том, что SIGHUP - это не сигнал о перезагрузке конфигов, а сигнал об "отрыве" терминала. В общем случае у вас нет совершенно никакой гарантии, что процесс при получении этого сигнала и правда перечитает конфиги, а не, к примеру, закроется.
Если в документации к демону написано, что он перечитывает конфиги по сигналу HUP - то, конечно же, ваша команда будет работать. Но пытаться отправить HUP нужно всё-таки после чтения манов, а не вместо.
Добавил, спасибо. Но для удаления прокси всё равно потребуется рестарт
docker pull работает через зеркало, а docker build все равно тащит с docker.io
Кстати хороший вопрос, ну стянул я с зеркала / через прокси условный alpine@latest, а дальше мне как на него то что мне нужно установить?
А, нашел
Всем спасибо ))
export HTTP_PROXY=socks5://192.168.1.153:1081
export HTTPS_PROXY=socks5://192.168.1.153:1081
И потом build тоже работает через прокси (прописать надо свой прокси, а экспорт поместить в bashrc/zshrc)
Чтобы докер билд работал, надо прописать прокси в конфигах, но только engine version>=23
/etc/docker/daemon.json:
{
"proxies": {
"http-proxy": "http://proxy.example.com:3128",
"https-proxy": "https://proxy.example.com:3129",
"no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
}
}
про huecker забыли
не работает на маке прописывание зеркал.. Docker Desktop For Mac 4.30.0 там в виртуалке, кроме докера еще спрятан свой insecure registry, который невозможно исключить через конфиг и прокси, которые ломятся прямиком на заблокированный ресурс
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
работает явное прописывание зеркало в имя образа (docker run mirror.gcr.io/hello-world) а так же, планирую попробовать colima, которая как-то более понятна в плане состава и настройки. (и работает через тот же virtualisation.framework)
на линуксе, к слову, всё поднялось без сучка, без задоринки )
На маке будет работать зеркало, если включить containerd в настройках Docker Desktop.
General > Use containerd for pulling and storing images
Да, так, действительно, работает... Это было неочевидно. И все мои закешированные образы остались "за бортом". Случайно, не знаете метода перенести их из того режима в этот?
Я думаю, что способа перенести их нет. Хранилище containerd и хранилище docker образов разделены. Старые образы никуда не делись, просто демон вам их не показывает. Хотя физически они лежат и занимают место на диске.
Чем вызвано именно такое поведение Docker Desktop - к сожалению не знаю, не разобрался пока.
Чтобы никто не портил образы, используйте шифрование образов.
Работать под VPN проще всего, мне кажется в наших реалиях, у человека кто связан с it, должен быть VPN. Поднять свой не так уж сложно, и уж тем более дорого (вы же айтишники, зарабатывайте хорошо). Остальные способы тоже имеют место быть, но минимум танцев в бубном - vpn
Хорошо, когда статья написана с хорошим чувством юмора)
Извините, а для Synology и NAS решений вообще, есть выход?
А синолоджи докер или чего сложнее? На FreeNas Scale вообще кубик используется к примеру
Конечно есть, на бафиста инструкция и видео ролик есть.
У меня подобная проблема, но к ней еще добавляется Watchtower. Я обошел блокировку по этому методу. https://bafista.ru/ustanovka-adguard-home-i-razblokirovka-docker-hub-clamav-i-tmdb/#comment-4272
Это именно для владельцев NAS Synology c установленным Adguard Home особенно актуально. Но вот почему-то, хотя сам реестр в контейнер-менеджере DSM теперь стал открываться, у меня все контейнеры перестали обновляться автоматом через Watchtower.
В логах самое интересное, это вот:
2024/06/01 05:00:04 stderr time="2024-06-01T05:00:04+03:00" level=debug msg="Got response to challenge request" header= status="403 Forbidden"
Непонятно, где-то еще копать надо.
В Synology попробовал сначала в штатном Container Manager прописать гугловское зеркало https://mirror.gcr.io, но визуально ничего не поменялось, также выдавал ошибку. Помогло вручную через ssh командой docker pull обновить образ, думаю потому что зеркало уже было в настройках. Потом уже сбросил контейнер в Container Manager, и он запустился с новым образом.
Но видимо пришла пора и часть трафика от NAS через VPN маршрутизировать.
А как перенастроить докер на локальный socks5 proxy? Через tor работать будет?
у меня при запуске билда докерфайла ошибка (использую свое зеркало, докер пул все прекрасно тянет):ERROR [internal] load metadata for docker.io/tiangolo/uwsgi-nginx-flask:python3.8-alpine
upd: починил уже просто рестартом докера
Казалось бы , то что обычно для всего мира для рф стало работать через пень колоду.
ну, допустим, как пуллить, разжевали. а мне вот пушить надо. и, кажется. прокси при этом не работают, docker login фэйлится. как быть?
на данный момент невозможно пущить в реестр, который является pull-through зеркалом.
The proxy structure allows a registry to be configured as a pull-through cache to Docker Hub. See mirror for more information. Pushing to a registry configured as a pull-through cache is unsupported.
https://distribution.github.io/distribution/about/configuration/
подскажите пожалуйста реселлера серверов хетзнера или овх с низкими ценами, а то в большинстве случаев цену ставят в 1.5-2 раза больше
Мне вот шо интересно - 2 года "ситуации" и народ не въехал, что "надо валить". Во всех смыслах - или "туда" или "сюда". Инфраструктура должна быть контролируемой. Да, для "дома" можно что угодно чудить (типа всяких впн и т.п.), но в продакшн такие костыли - это цирк с кучей пиротехники, которая может в любой момент бабахнуть. Что сложного в том, чтоб свой анало-говнет "докерхаб" замутить и не веселить окружающих бегом по граблям?
Для меня сработало только добавление в /etc/docker/daemon.json
На данный момент у части провайдеров docker hub разблокирован...
Блокировка Docker Hub для России. Без паники разбираемся как работать дальше