в смысле не ноль был бы размер

у меня на ноуте: 50M /var/lib/docker/image/ А тем временем: docker images —format {{.Size}} 278 MB 728 MB 69.3 MB 182.4 MB 184 MB 183 MB 182.8 MB 182.6 MB 190.8 MB 183.1 MB 192.3 MB 183 MB 192.3 MB 211.1 MB 69.28 MB 69.28 MB 223.5 MB 223.5 MB 69.27 MB 336.1 MB 46.22 MB

это кстати странно

у меня на ноуте: 50M /var/lib/docker/image/ А тем временем: docker images —format {{.Size}} 278 MB 728 MB 69.3 MB 182.4 MB 184 MB 183 MB 182.8 MB 182.6 MB 190.8 MB 183.1 MB 192.3 MB 183 MB 192.3 MB 211.1 MB 69.28 MB 69.28 MB 223.5 MB 223.5 MB 69.27 MB 336.1 MB 46.22 MB

прогнал да.

надо считать не эту диру а диру драйвера

в моем случае /var/lib/docker/overlay

$ sudo du -h --max-depth=1 /var/lib/docker/image/ 26M /var/lib/docker/image/aufs 26M /var/lib/docker/image/

как это может быть?

Если образ убунты базовый весит 130мб Какая-то черная докеровская магия

еще раз

/var/lib/docker/aufs считать надо

Там то же самое

$ sudo du -h --max-depth=1 /var/lib/docker/image/aufs 1,8M /var/lib/docker/image/aufs/imagedb 24M /var/lib/docker/image/aufs/layerdb 644K /var/lib/docker/image/aufs/distribution 26M /var/lib/docker/image/aufs

А блин, я туплю

ща

$ sudo du -h --max-depth=1 /var/lib/docker/aufs 3,9G /var/lib/docker/aufs/mnt 980K /var/lib/docker/aufs/layers 6,5G /var/lib/docker/aufs/diff 11G /var/lib/docker/aufs

Другое дело :)

вот вот

11G

а сколько сумма по docker images ?

Ну так если на глаз смотреть.. Примерно где-то так и есть. У меня много разных образов напулено из разных мест.

у меня на devicemapper получается полное фуфло. по du 4,6 гига. по сумме размеров образов 4.2 гига. 21 образ

тоесть выхлопа от этой самой слоености нету нихера.

ЧИТД

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

надо бы кого позвать у кого своя инфрастурктура полностью

я реально делал что у меня было 3:1

но это надо упарыватся

деалать не просто свою инфрастурктуру но еще и думать про layering типа это база, это редкоменяющийся пакеты, это мои дефолты, это частоменяющиеся пакеты, это сам поставляемый софт

тогда есть шансы.

У меня. Но вот сейчас я прямо задумался что за херня - никогда не проверял что занимает devicemapper, у меня размер равен

ага

но судя по логу того что скачивалось - скачиваются только последние лейеры, так что вообще непонятно

проверяю на aufs

а еще убило что в конечном счете на дефайсмаппере просто лежит файл в 100гигов :)

[host] 14:12:34 /data/docker/devicemapper/devicemapper # du -d1 4.6G . [host] 14:17:21 /data/docker/devicemapper/devicemapper # ls -h total 4.6G -rw------- 1 root root 100G Jul 4 14:17 data -rw------- 1 root root 2.0G Jul 4 14:17 metadata

я поначалу не хило оттупился от этого :)

А, всё норм.

Сумма образов по docker images - 72 гига

По du -hs - 31

а образов под полторы сотни ?

451

ох

А, не 450. первая строка - заголовок

помойму или хостинг или бардак :)

Просто билд сервер с историей билдов не чищенной за месяц

деалать не просто свою инфрастурктуру но еще и думать про layering типа это база, это редкоменяющийся пакеты, это мои дефолты, это частоменяющиеся пакеты, это сам поставляемый софт

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

а

билд сервер

тогда чего то не много

должно больше ужиматься

Если поддерживать долго один большой проект то можно и заморочиться с лейерингом этим имхо.

Просто билд сервер с историей билдов не чищенной за месяц

думаю там с пяток наберется "базовых" образов. типа from debian:latest

которые уже отмаркированы none:none

none:none читсятся автоматом по факту отработки билда успешно

точнее не noneLnone a dungling

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

Я за пиксар, у них образы живее

согласен. пиксар получше.

Собьсно пример пула имаджа - 4fe15f8d0ae6: Already exists 02ac35537ae2: Already exists f68f87ef0dcc: Already exists f7b325d93afc: Already exists 1140dd4dbc13: Already exists 0d0718983a34: Already exists 1ab1bb8313c4: Already exists 797f6b9dee07: Already exists fcda52d20b86: Pull complete c7651d21c2d5: Pull complete 29e96f4f58a2: Pull complete 8e6d8d3e7da2: Pull complete

Всем привет! Кто нибудь собирал контейнеры php-fpm + nginx?

есть маленький вопросик, у меня два контейнера, в одном php-fpm и проект, во втором nginx и статика

статика монтируется в волайме

запускаются они вот так

docker run —name emotionfolio-nginx -d -p 80:80 -v emotionfolio-media:/usr/src/app/web/media:ro emotiofolio/emotionfolio:emotionfolio-nginx-latest

и тут возникает проблема

2016/07/04 12:59:53 [error] 5#5: *1 FastCGI sent in stderr: "Unable to open primary script: /app.php (No such file or directory)" while reading response header from upstream, client: 192.168.99.1, server: emotionfolio.com, request: "GET / HTTP/1.1", upstream: "fastcgi://172.17.0.1:48000", host: "emotionfolio.com" 192.168.99.1 - - [04/Jul/2016:12:59:53 +0000] "GET / HTTP/1.1" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" "-"

ERROR: S client not available

это в контейнере nginx. Почему то app.php он ищет в контейнере nginx. Разве nginx не должен передать запрос php-fpm а тот уже будет искать нужный файл?

я нашел решение - впихнуть весь проект в волайм и монтировать в оба контейнера

но имхо это криво

кто знает, почему так?

потому что настройки дают кривые пути фасту?

настройки nginx или php-fpm?

nginx

это в контейнере nginx. Почему то app.php он ищет в контейнере nginx. Разве nginx не должен передать запрос php-fpm а тот уже будет искать нужный файл?

На самом деле ошибка возникает в контейнере php-fpm. nginx передает туда fastcgi запрос, fpm не может найти primary script, и возвращает ошибку вот такую. А nginx ее просто печатает.

На самом деле ошибка возникает в контейнере php-fpm. nginx передает туда fastcgi запрос, fpm не может найти primary script, и возвращает ошибку вот такую. А nginx ее просто печатает.

Павел, не согласен

я запускал двумя путями

1) в контейнере nginx монтировалась статика, в контейнер php-fpm копировался проект

2) в оба контейнера копировался проект

в первом случае - данная ошибка

во втором случае - работает

А, ну может ты волумы как-то перелинковал криво

скорее nginx пытается распознать путь которго нет и не так отдает путь fastcgi

а в волюме статика

она в отдельной папке

никак не связана с проектом

поэтому во втором случае работает

что править в конфигах nginx?

В ошибке прямо написано FastCGI sent in stderr: "Unable to open primary script: /app.php (No such file or directory)"

Т.е. это fpm генерит эту ошибку, и пишет в stderr. А вот где он пытается найти /app.php - это отдельный вопрос

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

что править в конфигах nginx?

Ошибку

http://pastebin.com/Zg3j2CCE

это мой конфиг nginx

подскажите, плиз)

app.php он ищет в /usr/src/app/web

которые есть в контейнере с php-fpm

логи fastcgi подробнее есть?

Сложновато как-то, а можешь переписать без реврайтов просто?