так это на wsl

понял. Спасибо большое, пошёл копать дальше

Подскажите есть два контейнера один на сети хост висит а второй на bridge. Как получить доступ к контейнеру который на хосте висит со второго

Подскажите есть два контейнера один на сети хост висит а второй на bridge. Как получить доступ к контейнеру который на хосте висит со второго

ip + port хоста, на хосте прописать доступ в iptables

#3 [internal] load metadata for public.ecr.aws/lambda/nodejs:14#3 sha256:1e7d9f35caa3cda46944c97429a62606caffcc393fbcf77177c9995bf747587e#3 ERROR: unexpected status code [manifests 14]: 400 Bad Request

что за херня

Классика docker? Это собирается контейнер для книги Docker in practice. Внезапно (?) там тоже очень хотят напомнить о технологиях пятилетней давности и о том, что node когда-то был молодым. Насколько часто, имея дело с docker-контейнерами, вы наслаждаетесь ностальгией по своей молодости и по технологиям из старых журнальных статей?

И насколько часто после этого разработчики сообщают вам о том, что УМВР и Работает-Не-Трожь? Пакетный дистрибутив бил бы по рукам и заставлял обновлять всё это. А как с этим в docker-экосистемах?

И насколько часто после этого разработчики сообщают вам о том, что УМВР и Работает-Не-Трожь? Пакетный дистрибутив бил бы по рукам и заставлял обновлять всё это. А как с этим в docker-экосистемах?

Что. Это. За. Бред.

Что. Это. За. Бред.

Можно конкретнее?

Можно. Вы собираете неизвестно что, по инструкциям неизвестной давности, удивляетесь результату и философствуете о "разработчиках", "пакетных дистрибутивах" и "экосистеме". Все вместе это выглядит как бред.

Можно. Вы собираете неизвестно что, по инструкциям неизвестной давности, удивляетесь результату и философствуете о "разработчиках", "пакетных дистрибутивах" и "экосистеме". Все вместе это выглядит как бред.

Суть вкратце: docker позволяет разработчикам годами не думать об обновлении зависимостей. Пример книги вполне актуален: книга переиздаётся, и её репозиторием пользуются. Из него собирается приложение, дырявое как решето. И часть идеологии docker - именно в том, чтобы "золотая кость" в виде разработчиков могла творить любую дичь, пихать в контейнеры библиотеки и что угодно какой угодно свежести и сомнительности - и это дерьмо бы "просто работало". Оно не будет работать в виде пакета deb или rpm ни на одном обновляемом и латаемом дистрибутиве, но будет работать в docker. Ну и да, я в курсе, что можно сделать из докер тот же пакетный дистрибутив по существу, обновляя "слои" (зависимости). Только в реальной практике разработчики, подгоняющие свой код под обновившийся слой зависимостей - это что-то из разряда фантастики. Они же очень занятые люди, разве можно их беспокоить?

Суть вкратце: docker позволяет разработчикам годами не думать об обновлении зависимостей. Пример книги вполне актуален: книга переиздаётся, и её репозиторием пользуются. Из него собирается приложение, дырявое как решето. И часть идеологии docker - именно в том, чтобы "золотая кость" в виде разработчиков могла творить любую дичь, пихать в контейнеры библиотеки и что угодно какой угодно свежести и сомнительности - и это дерьмо бы "просто работало". Оно не будет работать в виде пакета deb или rpm ни на одном обновляемом и латаемом дистрибутиве, но будет работать в docker. Ну и да, я в курсе, что можно сделать из докер тот же пакетный дистрибутив по существу, обновляя "слои" (зависимости). Только в реальной практике разработчики, подгоняющие свой код под обновившийся слой зависимостей - это что-то из разряда фантастики. Они же очень занятые люди, разве можно их беспокоить?

Какие у тебя есть предложения?

Какие у тебя есть предложения?

Массовые расстрелы.

Какие у тебя есть предложения?

Вернутся к более адекватной концепции OpenVZ :)

Тот же chroot с CGROUP'ами, но внутри обычный обслуживаемый вменяемыми людьми дистрибутив

Вернутся к более адекватной концепции OpenVZ :)

Она не адекватнее, она другая. "докер" контейнер не дистрибутив и не должен им быть.

Она не адекватнее, она другая. "докер" контейнер не дистрибутив и не должен им быть.

Нижний слой для почти любой сколько-нибудь сложной вещи - дистрибутив. Базовый контейнер без заморочек с размерами если брать - обычная centos, ubuntu, debian. Понятно, что урезанный минималистичный вариант, но ... это так. Разница кардинальная - только в интеграции контейнеризации и системы контроля версий.

Проще говоря, у openvz нет commit и концепции "каждое изменение - новый контейнер"

Нет. Разница в подходе контейнер как изоляция окружения и контейнер как изоляция одного процесса

Нет. Разница в подходе контейнер как изоляция окружения и контейнер как изоляция одного процесса

Что мешает запускать в каком-нибудь lxc один процесс? Кстати, кто ротирует логи контейнеров? Кто выполняет крон-задания?

По факту центральное приложение в концепции lxc/openvz - и так всегда одно было, никто не ставил всё в одно окружение

Что мешает запускать в каком-нибудь lxc один процесс? Кстати, кто ротирует логи контейнеров? Кто выполняет крон-задания?

Это сейчас было противопоставление докера и lxc? really? Крон не забота докера. Логи контролируются logging driver

Поясню: насчёт ротации - я не к тому, что её нельзя вынести на отдельный хост и т.д., я к тому, что концепция "одного процесса" немного сомнительна. Всё равно этот процесс обслуживается ещё грудой других процессов, и от того, что они выносятся куда-то вовне - суть не сильно меняется. Не так уж всё изолировано

Это сейчас было противопоставление докера и lxc? really? Крон не забота докера. Логи контролируются logging driver

А logging driver - это магическое заклинание или программа, резидентно висящая в памяти или программа, выполняемая другой такой программой? Концепция правильная, но, опять же, где тут полная изоляция и чудеса какие-то? Логи, кстати, я бы отправлял в обычный syslog, но это ИМХО конечно и несовременно :)

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

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

Я про то, что приложения, существующие как один исполняемый файл и легко перетаскиваемые туда-сюда - это немного абстракция. По сути любое такое "единственное приложение в контейнере" на поверку не может существовать без 20-ти других приложений, из которых далеко не все ещё и в контейнерах работают. В OpenVZ/LXC многие "обслуживающие" куски можно засунуть внутрь контейнера (я называю это chroot-окружением на стероидах :)). В docker это "вынужденно" существует снаружи контейнера. Но странно говорить о том, что docker-процесс (контейнер docker run ... <command line>) - это такая "адиабатическая" сущность, которой прям ничего не нужно.

Я про то, что приложения, существующие как один исполняемый файл и легко перетаскиваемые туда-сюда - это немного абстракция. По сути любое такое "единственное приложение в контейнере" на поверку не может существовать без 20-ти других приложений, из которых далеко не все ещё и в контейнерах работают. В OpenVZ/LXC многие "обслуживающие" куски можно засунуть внутрь контейнера (я называю это chroot-окружением на стероидах :)). В docker это "вынужденно" существует снаружи контейнера. Но странно говорить о том, что docker-процесс (контейнер docker run ... <command line>) - это такая "адиабатическая" сущность, которой прям ничего не нужно.

Не вынужденно, а целенаправленно, если этот подход не устраивает, надо выбирать другой инструмент

Но в том числе это позволяет абстрагироваться и не зависеть от средств оркестрации и запуска, что позволят переиспользовать образ на множестве платформ

Не вынужденно, а целенаправленно, если этот подход не устраивает, надо выбирать другой инструмент

Это была реплика не про концепцию, которая не устраивает, а про то, что чудесным образом очень самостоятельные программы существуют, но они малоюзабельны. В случае с docker это означает, например, что отсутствие необходимости настройки окружения для контейнера - миф

Это была реплика не про концепцию, которая не устраивает, а про то, что чудесным образом очень самостоятельные программы существуют, но они малоюзабельны. В случае с docker это означает, например, что отсутствие необходимости настройки окружения для контейнера - миф

Нет такого мифа. Естественно для полноценной работы комплексного приложения сложнее helloworld будет существовать нечто обеспечивающие сетевую доступность, сохранность/доступность данных whatever. Просто в случае с $subj все это должно существовать снаружи

Нет такого мифа. Естественно для полноценной работы комплексного приложения сложнее helloworld будет существовать нечто обеспечивающие сетевую доступность, сохранность/доступность данных whatever. Просто в случае с $subj все это должно существовать снаружи

Единая сервисная инфраструктура/экосистема - вполне себе преимущество... В конечном итоге выглядит как пакетный дистрибутив, но на новом витке развития концепции

Связь по логическому принципу, а не на уровне файлов

Единая сервисная инфраструктура/экосистема - вполне себе преимущество... В конечном итоге выглядит как пакетный дистрибутив, но на новом витке развития концепции

Что выглядит как пакетный дистрибутив?

Что выглядит как пакетный дистрибутив?

Экосистема docker. Слои - бывшие пакеты

Контейнеры - сервисы

Я про то, что приложения, существующие как один исполняемый файл и легко перетаскиваемые туда-сюда - это немного абстракция. По сути любое такое "единственное приложение в контейнере" на поверку не может существовать без 20-ти других приложений, из которых далеко не все ещё и в контейнерах работают. В OpenVZ/LXC многие "обслуживающие" куски можно засунуть внутрь контейнера (я называю это chroot-окружением на стероидах :)). В docker это "вынужденно" существует снаружи контейнера. Но странно говорить о том, что docker-процесс (контейнер docker run ... <command line>) - это такая "адиабатическая" сущность, которой прям ничего не нужно.

Выглядит так что кто не так готовит докер, это не проблема докера

никто не сталкивался с тем, что в dockerе очень медленно работает git.. бред какойто, не могу понять отчего так. есть виртуалка, в ней ubuntа 18, в ней докер... в докере git, 1-2kbps... всплесками.. в самой виртуалке все нормально, в контейнере - беда..

Это не докер Это винда, скорость работы синка виндовой папки и виртуалки

Нет никакой винды нигде

Обычно это было связано с wsl А репозиторий это слой контейнера или volume?

Обычно это было связано с wsl А репозиторий это слой контейнера или volume?

Поясни

Какой репозиторий

В Гит работает с репозиторием На твоей машине (локальный ) и удаленным(remote) Вот где расположены файлы локально репозитория Понятно что оно в докере Но папка в докере может быть в image Может быть примонтирована как volume Или создана в процессе работы контейнера( и не заокмичненная)

Всем привет

Народ, а нет ли у кого книги Docker in action? У меня бумажный переводной вариант, в поездку не стал брать, а почитать хочется :)

в докере в nginx лог off, но оно сыпит логи в /var/log/messages , почему?

Народ, а нет ли у кого книги Docker in action? У меня бумажный переводной вариант, в поездку не стал брать, а почитать хочется :)

именно на русском надо?

Запустил стек docker stack deploy, далее обновляю образы через docker stack update --image ... service. Если надо обновить конфигурацию, приходится в композ-файле вручную актуализировать версии образов. Есть ли способ заставить docker stack deploy использовать текущие версии образов, если стек уже запущен?

Скажите плиз, а инструкция ADD больше не распаковывает tar.gz?

именно на русском надо?

Нет, нет, на инглише даже лучше. Русский перевод на 3 сделали, постоянно приходится думать над тем, как это выглядело в оригинале

Нет, нет, на инглише даже лучше. Русский перевод на 3 сделали, постоянно приходится думать над тем, как это выглядело в оригинале

Минут через 20 поищу

Минут через 20 поищу

Огромное спасибо! А то вроде купил книгу для почитать на праздниках, а тут резко решили всё-таки попутешествовать

Огромное спасибо! А то вроде купил книгу для почитать на праздниках, а тут резко решили всё-таки попутешествовать

Кстати глянь в лс, это вообще оно?

Огромное спасибо! А то вроде купил книгу для почитать на праздниках, а тут резко решили всё-таки попутешествовать

в лс

Суть вкратце: docker позволяет разработчикам годами не думать об обновлении зависимостей. Пример книги вполне актуален: книга переиздаётся, и её репозиторием пользуются. Из него собирается приложение, дырявое как решето. И часть идеологии docker - именно в том, чтобы "золотая кость" в виде разработчиков могла творить любую дичь, пихать в контейнеры библиотеки и что угодно какой угодно свежести и сомнительности - и это дерьмо бы "просто работало". Оно не будет работать в виде пакета deb или rpm ни на одном обновляемом и латаемом дистрибутиве, но будет работать в docker. Ну и да, я в курсе, что можно сделать из докер тот же пакетный дистрибутив по существу, обновляя "слои" (зависимости). Только в реальной практике разработчики, подгоняющие свой код под обновившийся слой зависимостей - это что-то из разряда фантастики. Они же очень занятые люди, разве можно их беспокоить?

Ну я спихну на менеджмент. Поставили задачу люди сделали, сделали хорошо так что оно 10 лет работало. Пришел админ, мол устарело. Кто писал их уж с нами нет, разбираться месяц, а админ, я счас через 30 минут в докере запущу. Админ получает звёздочку, разраб посрамлены.

ребят может кто помочь с подключением psql

у меня ошибка с дб на докере а вот обычное подключение дб без докера работает

Покажи как ты запускаешь контейнер или описание сервиса в docker-compose.yml И каким образом подключаешся адрес, порт и тд Ну текст ошибки подключения чтобы не гадать

ребят добрый всем день и с прошедшим всех новым годом есть вопрос по куберу сюды тоже можно писать иль нет? (буду благодарен если пошлете меня в нужную группу)

ребят добрый всем день и с прошедшим всех новым годом есть вопрос по куберу сюды тоже можно писать иль нет? (буду благодарен если пошлете меня в нужную группу)

Добрый день https://t.me/kubernetes_ru

Добрый день https://t.me/kubernetes_ru

Благодарю

Всем привет! Ребят, не доводилось ли сталкиваться с такой задачкой: нужно при запуске контейнера выполнить git clone в workdir, а затем запустить my_app.py с возможностью указания аргументов? Каждый из этих шагов решается (по отдельности) без проблем, а вот указать их последовательно не выходит...

а не надо пытаться обмануть систему!

делай клон на сборке образа, а запуск при старте контейнера

но если любишь стрелять в ногу, просто запускай скрипт, в котором делай что хочешь

В таком случае при каждом изменении в git-репозитории образ придется пересобирать, а это нежелательно

В таком случае при каждом изменении в git-репозитории образ придется пересобирать, а это нежелательно

Так и делают.

В таком случае при каждом изменении в git-репозитории образ придется пересобирать, а это нежелательно

чем нежелательно? вы про cache что-то слышали при сборке? втаскивание сырцов приложение внутрь образа делает его иммутабельным IMHO вы не понимаете суть образов в контейнеризации

ребят есть вопрос у меня в манифесте указан php-fpm:latest (тест) но докер его не пулит грит что доступ заперешен и т.д на хабе я тоже чут такого контейнера не нашел есть кто с этим сталкивался?

все с этим сталкивались) если образа нет, оно всегда так пишет специфически

возможно имелось ввиду bitnami/php-fpm:latest, либо php:fpm

pip install ruamel.yaml.clib==0.2.6 как это на докер python 3 9 alpine установить?

ERROR: No matching distribution found for ruamel.yaml.clib==0.2.

ERROR: No matching distribution found for ruamel.yaml.clib==0.2.

Видимо как-то сбилдить нативные зависимости для ruamel.yaml или через apk найти и поставить их

Либо взять python не alpine

подскажите, пожалуйста, как связать два контейнера в один. Вот у меня есть два сервиса version: '3.7' services: telegram-bot-api: image: aiogram/telegram-bot-api:latest environment: TELEGRAM_API_ID: "api_id" TELEGRAM_API_HASH: "api_hash" TELEGRAM_LOCAL: 1 volumes: - bot_tracking_bot:/usr/src/app/telegram-bot-api ports: - 8081:8081 bot: image: "${BOT_IMAGE_NAME:-tg_bot-image}" container_name: "${BOT_CONTAINER_NAME:-tg_bot-container}" build: . working_dir: "/usr/src/app/${BOT_NAME:-tg_bot}" volumes: - bot_tracking_bot:/usr/src/app/${BOT_NAME:-tg_bot} command: python3 -m bot restart: always env_file: - ".env" volumes: bot_tracking_bot: мне нужно, чтобы данные контейнера telegram-bot-api, были в контейнере bot, т.е в пути /usr/src/app/

Ну если только эти данные то перенести volumes и environment Но у тебя там разные образы(image), два в образа просто так в один не соединить, надо смотреть это уже индивидуально

Ребят! Всем привет