где приличное сжираение)))?

ну сам демон жрет 62% а контейнеры по 10-20

ну сам демон жрет 62% а контейнеры по 10-20

la какой?

la какой?

ммм?

А мы знаем что такое CPU в топе?

ммм?

может ман по топу прочитать?

А мы знаем что такое CPU в топе?

да

да

так что значит 60%? загрузка чего?

так что значит 60%? загрузка чего?

1 ядра

1 ядра

у тебя сколько ядер?

2

2

подели и получишь нагрузку

но выше 100 оно улетает тоже

но выше 100 оно улетает тоже

так и правильно и будет улетать

так работает топ

%CPU -- CPU Usage : The percentage of your CPU that is being used by the process. By default, top displays this as a percentage of a single CPU. On multi-core systems, you can have percentages that are greater than 100%. For example, if 3 cores are at 60% use, top will show a CPU use of 180%. See here for more information. You can toggle this behavior by hitting Shifti while top is running to show the overall percentage of available CPUs in use.

да я вкурсе

сказал же

ну тогда к чему вопрос про 60 процентов ну нагжуен чуть если LA не улетает в потолок то и норм

просто показалось что демон сжирает больше чем должен

все ладно

просто показалось что демон сжирает больше чем должен

ничего не больше может и по 200 процентов есть через демона идет работа как бы

просто показалось что демон сжирает больше чем должен

Всё верно, многовато чет...

Чето не могу разобраться... Вот например image wordpress ( https://hub.docker.com/_/wordpress/ ). Как понять по какому dockerfile он собирается? Мельком глянул сорцы ( https://github.com/docker-library/wordpress ), но все равно не могу понять по какому пути/алгоритму он собирается. Например, image wordpress:latest по каким Dockerfile будет собираться из этого гитхаб репозитория?

В корне там 3 файла: Dockerfile-alpine.template Dockerfile-cli.template Dockerfile-debian.template

В корне там 3 файла: Dockerfile-alpine.template Dockerfile-cli.template Dockerfile-debian.template

https://github.com/docker-library/wordpress/blob/acd229d6d638566a3ccd921d20075182db9e1185/Dockerfile-debian.template

https://github.com/docker-library/wordpress/blob/acd229d6d638566a3ccd921d20075182db9e1185/Dockerfile-debian.template

Как ты понял что именно это файл используется? Почему не Dockerfile-alpine.template, например?

Чето не могу разобраться... Вот например image wordpress ( https://hub.docker.com/_/wordpress/ ). Как понять по какому dockerfile он собирается? Мельком глянул сорцы ( https://github.com/docker-library/wordpress ), но все равно не могу понять по какому пути/алгоритму он собирается. Например, image wordpress:latest по каким Dockerfile будет собираться из этого гитхаб репозитория?

https://github.com/docker-library/wordpress/tree/master/php7.1/fpm

собирается из докерфайлов в папках

Как ты понял что именно это файл используется? Почему не Dockerfile-alpine.template, например?

потому что для алпайна будетт tag-alpine

(нужно смотреть .travis-ci)

для каждой из версий свой докерфайл

wordpress:<version>-alpine —> алпайн ттемплейт wordpress:<version> —> дебиан

потому что для алпайна будетт tag-alpine

Методом исключения? Чето не straightforward как-то

Методом исключения? Чето не straightforward как-то

В риди написано ?

В риди написано ?

Ну не. Я ожидал, что будет указано по какому dockerfile image собирается. Это совсем неочевидно

Ну не. Я ожидал, что будет указано по какому dockerfile image собирается. Это совсем неочевидно

Прямо на странице https://hub.docker.com/_/wordpress/ Кликаешь на версию, он открывает Dockerfile. Чтобы понять, какя версия по умолчанию - ctrl+f -> latest

Прямо на странице https://hub.docker.com/_/wordpress/ Кликаешь на версию, он открывает Dockerfile. Чтобы понять, какя версия по умолчанию - ctrl+f -> latest

Круто, спасибо. Удивлен что так небыстро получил ответ на такой простой вопрос. Наверное плохо сформулировал

Кто-нибудь знает, как из контейнера постучаться на какой-нибудь порт с локалхоста? Как-то надо скормить адрес локально запущенного рсислога внутрь конфига одного сервиса

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

в простейшем виде как-то так ENTRYPOINT /bin/sh -c "echo \"$(ip route|awk '/default/ { print $3 }') docker-host\" >> /etc/hosts && nginx -g 'daemon off;'"

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

тут напрашиваются поды и, соответственно, k8s )

А k8s можно закастомить по самое нехочу? Типа включить 2 балансировщика, прописать одному из них, как перенаправлять запросы с одного контейнера на другой (не сервиса, а контейнера). При этом 90% сервисов - Stateful и Ceph не вариант из-за скорости.

можно, но будет непросто ))

примерно так же, как со свармом

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

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

есть вот такой костыль https://github.com/rycus86/podlike, но до прода он не дорос

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

а global service не подойдет?

global нам обеспечит запуск таск на всех нодах, подходящих под ограничение. Но остаётся вопрос как нам объяснить приложению в кластере - например nginx - куда писать свои логи. Сам ищу красивое(масштабируемое, удобное) решение, но не находится (

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

ну вот в моём понимании это некрасивое решение, поскольку логстеши придётся деплоить отдельно

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

да чем угодно их можно раскатать, но проще в том же сварме

в смысле - иметь сервис, который подымает контейнеры

А как приложению сказать, куда писать свои логи - не всегда проблема. Контейнеры в оверлейной сети находятся под балансировкой, не зависимо от того, сервисы это или нет. Если нескольким джинксам надо писать свои логи, пусть пишут в любой (то, что есть балансировка и она не оптимальна - это плата за устойчивость: если есть хотя бы один логстеш, то логи приходить будут). Либо можно писать логи в stdout, а демону докера сказать их перенаправлять в localhost:<LOGSTASH_PORT>

Привет! я ваще ни в зуб ногой. установил докер на линукс. надо сделать два экрана. запускаю screen говорит команда не найдена... я понимаю что ворпос наверное пустяковый, но блин как мне сделать 2 - 3 экрана чтобы разные проги запустить в них одновременно?

Добрый вечер. Вот есть у меня teamcity, который строит новый image для каждого нового коммита в git и пулит в локальный регистр. Понятное дело, что если каждый раз строить новый image, то все место быстро забьется. Есть ли у Docker какая-либо возможность сохранять 1 image, а далее только новые изменения или до каждого будет свой полновесный image?

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

пилять ))) я только что научился контейнеры в докере запускать ))) сцука в 65 лет то

Я пока что слабо разбираюсь в терминологии. Слои - это результат каждой команды в Dockerfile?

да тип того. одинаковые слои не дублируются в registry

да тип того. одинаковые слои не дублируются в registry

если они в одинаковом порядке

да тип того. одинаковые слои не дублируются в registry

Хорошо. Не знаю как выразиться... А что на счет копирования каталогов в image? Он также будет это делать или просто возьмет результат предыдущего построения? Получается, что, если максимально делать слои изолированными и сохранять память, то копирования и построение проекта следует делать самыми последними шагами?

Хорошо. Не знаю как выразиться... А что на счет копирования каталогов в image? Он также будет это делать или просто возьмет результат предыдущего построения? Получается, что, если максимально делать слои изолированными и сохранять память, то копирования и построение проекта следует делать самыми последними шагами?

Так и есть