Задай папке не хосте права на тотже uid что в контейнере

Uid на хосте может не совпадать с uid в контейнере

1001 в докере

проще передать UID и GID из хоста в контейнер

там создать юзера с этими айди

Друзья, кто-нибудь имел опыт использования --cache-from в последних версиях докера? Выполняю такие команды на разных платформах (пересобираю тот же образ `my-image:v1.0.0`): docker pull my-image:v1.0.0 docker build --cache-from=my-image:v1.0.0 . и часто результаты не совпадает. Где-то сборки не происходит, все берется из кэша, где-то выполняется только часть шагов, где-то все шаги пересобираются заново. Кто-нибудь встречался с такой проблемой?

Uid на хосте может не совпадать с uid в контейнере

Зачем чтобы он совпадал? Его может даже и не быть на хосте.

так ты предлагаешь задать тот же uid что и в контейнере

вот именно, что его может и не быть

И?

тогда к чему твой совет, который безмысленный?

Задай папке не хосте права на тотже uid что в контейнере

)))

плин

на прочитал как и

chmod -R 12345:12345 folder Проблема с этим?

Друзья, кто-нибудь имел опыт использования --cache-from в последних версиях докера? Выполняю такие команды на разных платформах (пересобираю тот же образ `my-image:v1.0.0`): docker pull my-image:v1.0.0 docker build --cache-from=my-image:v1.0.0 . и часто результаты не совпадает. Где-то сборки не происходит, все берется из кэша, где-то выполняется только часть шагов, где-то все шаги пересобираются заново. Кто-нибудь встречался с такой проблемой?

Ты может слои меняешь?

Ты может слои меняешь?

В докерфайле ничего не менялось Единственное, что собирал на другой "машине".

А зачем собирать если вообще ничего не менял?

А зачем собирать если вообще ничего не менял?

Это я так пытаюсь понять, как работает опция --cache-from. Я использую gitlab-ci для сборки базовых образов, а раннеров большое количество. Заранее не знаешь, на какой раннер попадет сборка (например на тот, на котором нет кэша). Поэтому чтобы не создавать дополнительных проблем с прибиванием таких задач к конкретным раннерам, я делаю сначала docker pull, а затем docker build --from-cache. Иначе получается, что все образы каждый раз пересобираются с нуля и нет профита от кэша докера со всеми вытекающими.

Ну задачу я понимаю, а билдить зачем если образ не меняется?

Может у тебя copy 1-2м?

Ну задачу я понимаю, а билдить зачем если образ не меняется?

Разумеется, в реальном мире будет что-томеняться. Я просто заметил, что опция --cache-from ведет себя как-то неоднозначно (на первый взгляд). Исходя из доки, в примере, когда dockerfile не меняется, пересборки вообще не должно происходить. А на деле это не так. Вопрос прежний - почему такая неоднозначность? На разных хостах хэш для образов счетается по разному? Почему докер не переиспользует образы с опцией --cache-from?

Может у тебя copy 1-2м?

ещё вариант - имя образа может отличаться от нужного, оно же произвольное

удаляй локально перед pull "docker rmi" или, что сложнее делай pull по sha256

Может у тебя copy 1-2м?

нет, это врядли.

ещё вариант - имя образа может отличаться от нужного, оно же произвольное

Здесь тоже. Образ также называется

нет, это врядли.

что значит врядли? нет доступа к Dockerfile?

что значит врядли? нет доступа к Dockerfile?

Ответ - нет. COPY не 1, 2-м.

сейчас попробую у себя, тоже пачка ранеров есть

Ответ - нет. COPY не 1, 2-м.

ну всё ок, несколько раз на разных раннерах прогнал, без каких-то отклонений. даже очистку перед сборкой добавил $ docker system prune -fa Total reclaimed space: 0B

вот только профита мало в моём случае)) у меня 10 слоев качает, чтобы 3-4 заюзать))

вот только профита мало в моём случае)) у меня 10 слоев качает, чтобы 3-4 заюзать))

т.е. ты никакой проблемы не заметил?

т.е. ты никакой проблемы не заметил?

ну у меня как минимум первый слой из кэша, дальше у меня COPY сразу

если повторить JOB то и остальные слои из кэша берёт

Понял. Я попробую тогда какой-нибудь публичный образ взять и скинуть пример. У меня, например, в некоторых случаях даже первый слой из кэша не берется.

кто-нибудь собирал kubernetes-кластер из docker-compose?

Я не уверен что это влияет, но у меня overlay

кто-нибудь собирал kubernetes-кластер из docker-compose?

Извращенец)

Зачем?

Зачем?

хочу, чтобы у меня была нормальная локальная конфигурация и кластер в продакшине

Minikub?

Ты с dind натрахаешься больше чем с кубом

Minikub?

есть ли норм гайды?

у них есть доки

есть ли норм гайды?

https://www.ubuntu.com/containers/kubernetes через Juju ещё можно

Коллеги, всем привет! Помогите пожалуйста со следующим. Поднимаю контейнеры докер-компоузом, пара сервисов+монго, стандартный образ, порты маппятся 27017:27017. Из других сервисов к сервису монго обращаюсь по имени, mongo-service1:27017. Возникла необходимость поднять второй сервис монги на порту 27018, я просто добавил еще один сервис mongo-service2, маппинг 27018:27017. Но при обращении mongo-service2:27018, пишет Connection Refused. Что я упустил?

мапинг для тебя, а не для контейнеров

убери его вообще и подключайся по имени сервиса: mongo1:27017 mongo2:27017

в пределах одного компоуза с дефолтной сетью

порты же конфликтовать будут не?

https://stackoverflow.com/questions/42704844/docker-run-mongo-image-on-a-different-port

я вот нашел решение

порты же конфликтовать будут не?

Где будут конфликтовать?

спасибо, что откликнулись

Где будут конфликтовать?

в сетке компоуза?

Порт в контейнере, а не в сетке

окей, ваше решение понял, спасибо, что откликнулись, ну а если мне проброс во внешку нужен, тогда вариант выше с SO?

Коллеги, всем привет! Помогите пожалуйста со следующим. Поднимаю контейнеры докер-компоузом, пара сервисов+монго, стандартный образ, порты маппятся 27017:27017. Из других сервисов к сервису монго обращаюсь по имени, mongo-service1:27017. Возникла необходимость поднять второй сервис монги на порту 27018, я просто добавил еще один сервис mongo-service2, маппинг 27018:27017. Но при обращении mongo-service2:27018, пишет Connection Refused. Что я упустил?

expose юзай

expose юзай

где?

докер файл не хочу оверрайдить

ports нужен, чтобы твои контеинер тебе прокинул порт и ты мог бы к нему законектится с локалхоста

в docker-compose пишешь expose и радуешься

ERROR: S client not available

expose: - 2181

в docker-compose пишешь expose и радуешься

Да в подобных образах уже есть expose

именно

тогда убери ports и забей

поэтому я как понял,если без проброса, вариант Константина

окей, ваше решение понял, спасибо, что откликнулись, ну а если мне проброс во внешку нужен, тогда вариант выше с SO?

Вариант мой+ проброс

если с пробросом во внешку, с СО

Ты подключаешься из контейнера через хост обратно в контейнер

В том со заметки сумасшедших, удали из памяти))

короче, тогда так

для человека, пробрасываем на 18

Между контейнерами обращение по дес=сервис+порт из expose

чтобы например могно консолью подключится

а для сервиса порт из экспоуза+имя сервиса

так?

+ для внешки пуьликуешь и хост тогда уже localhost

а тебе точно над из вне подключаться? можно ж в образ зайти

просто прикидываю, что не всегда доступ будет к машине

так?

Да

Константин спасибо

просто прикидываю, что не всегда доступ будет к машине

эт как?

эт как?

ну по идее я могу подключиться через mongo cli прям к серверу

минуя ssh, docker ps, hash, docker exec

можешь

но зачем

Чтобы вскрыли)

да так, перестраховка, короче, я вас понял, еще раз спасибо!

да так, перестраховка, короче, я вас понял, еще раз спасибо!

перестраховка чего? компоуз девелоперская штука, захотел - добавил

господа, подскажите пожалуйста) Если через докер файл запускать: Step 7/20 : RUN service mysql start ---> Running in 83a74de31578 * Starting MySQL database server mysqld ...done. ---> 4dc35145d38e Removing intermediate container 83a74de31578 Step 8/20 : RUN service mysql status ---> Running in 5b4dac7d5f80 * MySQL is stopped. Если руками, то все нормально стартует

Пока не гуглится

это не виртуалка, там нет сервисов