давайте вернемся к изначальному вопросу

но пусть так. я же могу брать бинарь и запускать на другой машине, даже если там не будет зависимостей. а тот же php и python скрипт запустить так не получится (ну для python, наверное, получится, там множество кастомных инструментов)

Запусти бинарь x86 на arm, а пхп запустить можно

Запусти бинарь x86 на arm, а пхп запустить можно

делаем два бинаря и всё (как и в случае с .exe). вопрос не в том, что "можно" и что "нельзя".

Запусти бинарь x86 на arm, а пхп запустить можно

в случае винды или линукса можно скрафтить исполняемый файл, который содержит секкции для каждой поддерживаемой платформы

но готовы ли вы тащить исполняемый файл х3, х4, х10 размера

и да, это не работает МЕЖДУ операционками

т.к формат бинарей разный

Добрый день, в контейнере поднимаю постгрю версией 9.6, прокинул волюмсы на продакшене, хочу сделать ежедневный бэкап данных, но не понимаю где лежит папка с данными db: container_name: astro-db image: postgres:9.6 volumes: - pg_data:/var/lib/postgresql/data - pg_backups:/pg_backups - ./compose/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql

Как и где найти папку с данными на хосте?

Как и где найти папку с данными на хосте?

В /var/lib/docker/volumes

Бекап чем делать будете ?

Ну думал примитивным методом через крону или есть лучше варианты?

init.sql рекомендую "запечь" в образ и версионировать его

Ну думал примитивным методом через крону или есть лучше варианты?

Нет, я не про крон. Технологически. pg_backup?

Нет, я не про крон. Технологически. pg_backup?

pg_backup вставил из примера просто

Привет. Решаем, собирать ли софт в отдельной среде и потом добавлять собранное в образ, или прямо в докерфайле написать make install. Что про это можно почитать?

Привет. Решаем, собирать ли софт в отдельной среде и потом добавлять собранное в образ, или прямо в докерфайле написать make install. Что про это можно почитать?

Лучше разбить на multistage dockerfile

1. Собираем все пакеты из исходников и далее checkinstall , т.е. результатом make install является deb пакет 2. Далее на вторую стадию передаём deb и устанавливаем

Профит в том, что в итоговом образе нет всего лишнего для компиляции и сборки. А ещё deb по идее можно установить и без докера

Разумно. Но не лучше ли тогда этот deb собрать отдельно и положить в репозиторий? (У нас есть свой deb-репозиторий.)

Разумно. Но не лучше ли тогда этот deb собрать отдельно и положить в репозиторий? (У нас есть свой deb-репозиторий.)

Вообще - да

Это идеальный вариант, но иногда бывает overkill'ом и пайплайн становится сложнек

И усложняет локальную сборку, да. Спасибо, будем думать, про multi-stage я и забыл.

У flant про dapp есть видео

failed to register layer: rename /var/lib/docker/image/overlay2/layerdb/tmp/write-set-190460853 /var/lib/docker/image/overlay2/layerdb/sha256/7bff100f35cb359a368537bb07829b055fe8e0b1cb01085a3a628ae9c187c7b8: file exists Как бороть такую проблему, вылетает когда делаю пул с library/docker

У flant про dapp есть видео

Никто не будет использовать этот велосипед

failed to register layer: rename /var/lib/docker/image/overlay2/layerdb/tmp/write-set-190460853 /var/lib/docker/image/overlay2/layerdb/sha256/7bff100f35cb359a368537bb07829b055fe8e0b1cb01085a3a628ae9c187c7b8: file exists Как бороть такую проблему, вылетает когда делаю пул с library/docker

Если возможно - грохнуть весь кэш докера, перезапустить демона

Если возможно - грохнуть весь кэш докера, перезапустить демона

Thx

не, Стасикам я не доверяю

не, Стасикам я не доверяю

Э?

Э?

та реклама была

не, Стасикам я не доверяю

и правильно. зачем тараканам доверять?)

Ребята, хэлп! Не могу разобраться. Есть docker-compose.yml, первый контейнер создается на базе моего образа и скачивается с Docker Hub, в нем лежит конфиг Nginx который я хочу скопировать в контейнер с Nginx. Можно ли это сделать?

Ребята, хэлп! Не могу разобраться. Есть docker-compose.yml, первый контейнер создается на базе моего образа и скачивается с Docker Hub, в нем лежит конфиг Nginx который я хочу скопировать в контейнер с Nginx. Можно ли это сделать?

Ответ - да

Ответ - да

Законономерный вопрос - как?

И я ещё могу сказать почему этот докер компоуз плохой

Законономерный вопрос - как?

Берете и делаете. Из компоуза это неясно, но это операция тривиальная

Как вариант - пошарьте вольюм между несколькими контейнерами

Первый стартует и его заполняет, второй просто читает как конфиг

И я ещё могу сказать почему этот докер компоуз плохой

Рассмотрю любую конструктивную критику. За этим собственно я здесь

1. Используйте версию файла 2.* 2. Нет хелсчеков. 3. Приложуха стартует сразу, как стартовал постгрес. Пофиг живой он или нет. См. П.2. добавьте хелсчек на постгрес и флаг на старт первого контейнера, когда постгрес хелзи, а не started

4. Вопросы по конфигу nginx. Точно достаточно одного конфига? Про заполнение конфига я высказался

И есть ещё классный совет на

Первый стартует и его заполняет, второй просто читает как конфиг

Если не сложно: можно небольшой пример. Я с пару дней как пробую деплой на Докере.

https://hub.docker.com/_/nginx

If you wish to adapt the default configuration, use something like the following to copy it from a running nginx container: $ docker run --name tmp-nginx-container -d nginx $ docker cp tmp-nginx-container:/etc/nginx/nginx.conf /host/path/nginx.conf $ docker rm -f tmp-nginx-container This can also be accomplished more cleanly using a simple Dockerfile (in /host/path/): FROM nginx COPY nginx.conf /etc/nginx/nginx.conf

5. Конфигурации - лучше через переменные окружения передавать

1. Используйте версию файла 2.* 2. Нет хелсчеков. 3. Приложуха стартует сразу, как стартовал постгрес. Пофиг живой он или нет. См. П.2. добавьте хелсчек на постгрес и флаг на старт первого контейнера, когда постгрес хелзи, а не started

Когда гуглил, то видел про хелсчеки. Я буду усложнять логику постепенно.

6. nginx стартует ТОЛЬКО, если поднялся сервисный контейнер. Это как бы совсем не круто.

Т.к. вы даже ошибку не увидите, если сервис сдох. Лучше, чтобы nginx молотил всегда, но есть нюанс. Пока контейнер с Вашим сервисом не стартанет, его днс имя не существует. А раз так, то nginx не пройдет проверку конфигурации. Ну, поняли надеюсь, что это все не очень для прода

Для локальной разработки = ок

6. nginx стартует ТОЛЬКО, если поднялся сервисный контейнер. Это как бы совсем не круто.

К советам по оптимизации и best practices я обязательно вернусь когда будет понятна базовая логика работы.

Возвращаясь к конфигурации - пошарить вольюмом между обоими контейнерами ?

Или воспользоваться советом с временным контейнером из документации nginx, но адаптировать под свой кейс ?

И вообще откуда задача заполнения конфигурации из существующего докер образа взялась ?!

Для локальной разработки = ок

Именно для этого и используется.

Именно для этого и используется.

Всякое бывает ?

И вообще откуда задача заполнения конфигурации из существующего докер образа взялась ?!

Из головы. ☺ Я на Докер хаб настроил автобилд и связал с гитхабом. Удобно когда пушишь изменения в приложении, запускается билд образа. И на серваке будет юзаться последняя версия образа при деплое.

Из головы. ☺ Я на Докер хаб настроил автобилд и связал с гитхабом. Удобно когда пушишь изменения в приложении, запускается билд образа. И на серваке будет юзаться последняя версия образа при деплое.

И в приложухе сразу последняя версия nginx конфига? А зачем она там ?

Если nginx отдельным контейнером ?

И в приложухе сразу последняя версия nginx конфига? А зачем она там ?

Да там конфиг по сути на хер не нужен. Я ищу способ обойтись одним файлом docker-compose

Да там конфиг по сути на хер не нужен. Я ищу способ обойтись одним файлом docker-compose

Ну, смотрите. Вы правильно сказали, что можно в том же пайплайне собрать образ под свою приложуху myservice_image и в нем же образ для my_nginx, который будет состоять из базового nginx + Ваш конфиг

Это удобно для продакшн. Но для разработки часто возникает задача подтюнить конфигурации на лету, без пересборки образов. И тут удобны вольюмы

Через них можно переопределить целые каталоги, которые уже есть внутри образа контейнера и подсунуть свои версии файлов

Да там конфиг по сути на хер не нужен. Я ищу способ обойтись одним файлом docker-compose

Я надеюсь, что не напугал ?

Это удобно для продакшн. Но для разработки часто возникает задача подтюнить конфигурации на лету, без пересборки образов. И тут удобны вольюмы

Можно считать мой домашний сервер аналогом прода. Хочу максимально автоматизировать процесс деплоя.

Можно считать мой домашний сервер аналогом прода. Хочу максимально автоматизировать процесс деплоя.

Тогда мое соображение выше касательно собственного образа nginx

Через них можно переопределить целые каталоги, которые уже есть внутри образа контейнера и подсунуть свои версии файлов

Можно пожалуйста небольшой пример как создать вольюм и засунуть в него конфиг из образа?

Тогда мое соображение выше касательно собственного образа nginx

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

Через них можно переопределить целые каталоги, которые уже есть внутри образа контейнера и подсунуть свои версии файлов

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

Единственно верное решение засовывать конфиг на этапе сборки, все :)

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

+1

Можно пожалуйста небольшой пример как создать вольюм и засунуть в него конфиг из образа?

Выше пример из документации nginx. Легко адаптировать под себя

Выше пример из документации nginx. Легко адаптировать под себя

Ок. Попробую. Спасибо

Единственно верное решение засовывать конфиг на этапе сборки, все :)

Что имеется ввиду под этапом сборки? Dockerfile?

Т.к. вы даже ошибку не увидите, если сервис сдох. Лучше, чтобы nginx молотил всегда, но есть нюанс. Пока контейнер с Вашим сервисом не стартанет, его днс имя не существует. А раз так, то nginx не пройдет проверку конфигурации. Ну, поняли надеюсь, что это все не очень для прода

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

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

Не совсем

Что имеется ввиду под этапом сборки? Dockerfile?

Да, докерфайл

Что имеется ввиду под этапом сборки? Dockerfile?

Докерфайл не совсем корректно, имеджа

Докерфайл не совсем корректно, имеджа

Отдельного - для nginx

Отдельного - для nginx

Ну да :)

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

Так а что в этом не так то?

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

у меня дежа вю

Так а что в этом не так то?

Да может и ничего... Пытаюсь найти вариант чтобы удовлетворить свое эго?