прежде чем фантазировать какой сервер на какой будет лить данные стоит начать с планирования.
взять ручку и лист бумаги и описать
1) что будем бэкапить - виртуалки, файловые шары или почтовые базы и т.д. - от этого будет зависеть подход к резервной копии, можно это делать простым копированием, надо-ли стопать базы данных или виртуалки и т.д.
2) сколько места занимает разовый бэкап всего что вам надо.
3) сколько именно копий вы хотите иметь, и есть ли у вас место чтобы эти копии хранились.
3а) график резервного копирования - полный, инкриментные, диффы и т.д.
4) продумайте что вы будете делать в случае если надо будет восстановить бэкап, причем надо проверять сразу наихудший сценарий - сервер сдох, ничего нет, поднимаем все с нуля, поможет вам имеющийся бэкап, достаточно ли его?
ну, во-первых всетаки MetalLB
во вторых гугли по ошибке "no registered speaker:[layer2] eip:[eip-pool]" - выясняй почему у тебя спикер не поднялся, процесс спикера это DaemonSet если я не ошибаюсь, он на каждую ноду должен прилетать. И я не помню на память, если кластер из одной ноды и эта надо мастер с лейблом NoExecuted , то прилетит оно или нет. Короче проверяй.
Гугл по этой ошибке вываливает список того что надо проверить, начиная с кривого L2Advertisement
Линукс сервер c установленным fetchmail - чтобы выдергивать почту из внешнего сервиса, dovecot - чтобы хранить ее локально, roundcubemil - чтобы предоставлять web интерфейс для клиентов.
для начала надо определится в тем какие values есть в чарте. Может там где-то настройки сервиса можно переназначить.
Ну и да, если тренируешься не на облачном инстансе - придется менять, либо развернуть что-то типа MetlalLB чтобы появился LoadBalancer
Salamandrine, ну ок. у вас есть docker image ls , docker inspect id_of_running_cont
, вы всегда можете увидеть, какая версия запущена с помощью inspect и какая версия доступна локально с помощью image ls .
Доступна ли новая версия для скачивания - тут сложнее, если качаете с docker hub можно глазами глянуть что там у любимого разработчика новенького. Можно накостылить какие нибудь скрипты которые будут делать обращение в docker registry на предмет новых образов.
Кстати есть (была, больше не разрабатывается похожу) еще прикольная штука https://github.com/containrrr/watchtower , оно умело следить за новыми имиджами выбранных контейнеров и скачивала и перезапускала их. Но еще раз - автоматизация тут вещь опасная. Я за подход озвученный в ответах ниже - работает, не трожь. Обновляемся только если есть CVE и критические проблемы.
зависит от того, из какого образа был развернут контейнер. если на основу был взят к примеру
docker/nginx:latest , (и мы говорим про docker compose!) то можно сделать
docker compose pull
docker compose up -d
и оно скачает актуальный образ и стартанет. контейнер будет пересоздан, данные в вольюмах не пострадают.
если там было чтото типа
docker/nginx:1.24.0 , и нам надо docker/nginx:1.25.3 , придется ручками. Если опять же мы про docker compose - то лезем в docker-compose.yml , меняем версию на нужную и вперед.
Если речь про обычный докер, где все делалось руками - аккуратно ручками стопаем старый, docker pull новый, заново команду запуска и скорее всего взлетит. Вопросики будут про тома в данными (volumes) и порты, поэтому команду запуска надо точно воспроизводить.
Добавлю. Использовать :latest это вообще плохая практика, версии всегда стоит контролировать. А то неглядя апдейт выкатишь, и как оно нафиг там развалится, потому что разрабы чтото ключевое поменяли и может даже где-то про это анонс есть, но мы же не читаем..
Я уже писал выше. Нет никакой необходимости трахаться с непонятной старой репошкой. Ковыряться в чужих скриптах и разбираться что они делают - нафиг нафиг.
Правильный путь - при регистрации туннеля на tunnelbroker.net , появляется раздел Example Configuration , там надо выбрать свое устройство и там будет пример конфига. Для линукса там аж 4 примера - для разных версий netplan, c net-tools - это для старых дистрибутивов или для route2.
после регистрации туннеля в tunnelbroker там появляется раздел Example Configuration , выбираешь свое устройство и вперед. Репо который был сделан 9 лет назад, вероятно, не самый лучший способ приобщиться к ipv6 в 2025м году.
Но если все же прям так хочется - посмотри на те команды которые ты привел в вопросе и разберись что каждая из них должна делать. в такой последовательности это работать не должно.
ты вообще хоть что-то пробовал читать по теме или ты просто тупо вводишь команды которые где-то увидел?
и еще - самый главный пункт в упомянутом репозитории вот этот - You can set up your own tunnelbroker.net! - зачем ты указываешь адрес гуглового днс-а? Там должен быть адрес одного из серверов брокера.
Лицензия привязывается через консольнкю утилиту ( у меня сплат, который раскатывается на обычное железо , как дистрибутив). Если вы с этим не работали и негде взять прошивки - выкинуть, оживить его у вас скорее всего не выйдет.
Комментировать этот ответ только портить, супер.
Просто добавлю что права на репо могут быть, но вот прав писать в некоторые ветки - нет. Это надо у администратора или владельца проекта уточнить.
пункт три стоит поставить в начало, в наше прикольное время это надо продумывать в первую очередь. И это не только про Россию, но и про большинство других юрисдикций.
взять ручку и лист бумаги и описать
1) что будем бэкапить - виртуалки, файловые шары или почтовые базы и т.д. - от этого будет зависеть подход к резервной копии, можно это делать простым копированием, надо-ли стопать базы данных или виртуалки и т.д.
2) сколько места занимает разовый бэкап всего что вам надо.
3) сколько именно копий вы хотите иметь, и есть ли у вас место чтобы эти копии хранились.
3а) график резервного копирования - полный, инкриментные, диффы и т.д.
4) продумайте что вы будете делать в случае если надо будет восстановить бэкап, причем надо проверять сразу наихудший сценарий - сервер сдох, ничего нет, поднимаем все с нуля, поможет вам имеющийся бэкап, достаточно ли его?