Кратко - фазы сборки и выполнения должны быть разнесены

docker-compose build myapp Что не так тут?

Какие?

Например vendor папка осталась в образе, но у меня ее нету

Вендор же пересобирается.

docker-compose build myapp Что не так тут?

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

Так можно, я почему-то подумал, что тут предлагали собирать при деплое. Но тогда не вижу смысла в docker-compose)

Если долго - есть нюансы с пересборкой, в частности, если есть несколько контейнеров из одного (или похожего) имиджа, который задан директивой build в docker compose

Так можно, я почему-то подумал, что тут предлагали собирать при деплое. Но тогда не вижу смысла в docker-compose)

docker-compose полезная штуковина в хозяйстве, помогает в быту, упрощает контейнерную жизнь. Может быть проблема не в docker-compose, а в том как и для чего вы его используете?

Да это просто комбайн для dockercli, и делать такие выводы как выше - смешно) ну как минимум видно кто на что горазд)

Всем привет. Только начинаю знакомится с докером. Есть рекомендации как настроить среду для разработки php?

Всем привет. Только начинаю знакомится с докером. Есть рекомендации как настроить среду для разработки php?

docker-compose полезная штуковина в хозяйстве, помогает в быту, упрощает контейнерную жизнь. Может быть проблема не в docker-compose, а в том как и для чего вы его используете?

Полностью согласен) Помогает в быту, это да. Но сборку через него не вижу смысла делать. строка в ci docker build... ничуть не труднее для понимания

Полностью согласен) Помогает в быту, это да. Но сборку через него не вижу смысла делать. строка в ci docker build... ничуть не труднее для понимания

Суть в том, что это одно и тоже, разный формат - флагами cli или ключами в yaml. А рассуждения про прод/дев - детсад

Спасибо, кеп! А то я не знал) Я видел cd, в котором деплой выглядел так: cd /path/to/project git pull docker-compose build docker-compose up -d И подумал, что тут про то же самое. @nodekra Идите сами в свой дет.сад, прочитайте историю сообщений)

Спасибо, кеп! А то я не знал) Я видел cd, в котором деплой выглядел так: cd /path/to/project git pull docker-compose build docker-compose up -d И подумал, что тут про то же самое. @nodekra Идите сами в свой дет.сад, прочитайте историю сообщений)

docker-compose build использует параметры директивы build такие как context, dockerfile, args и др. указанные в docker-compose.yml и ничем не отличается от обычного docker build, в некоторых случаях эта способность незаменима и это хорошо что она есть в списке возможностей docker-compose

Но это дополнительный уровень абстракции, который с одной стороны может усложнить поддержку ci/cd и "протечь" в неудобном месте

если приведете примеры как это может усложнить ci/cd и что имеется в виду под "протечь" буду вам признателен, и не только я наверное

Я уж не говорю про то - нахера тащить компоуз в образы для сборки, если можно без него

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

оказалось действительно так. Владельца кто-то/что-то сбрасывает на root, т.е. вместо id приложения владельцем становится id 0. Осталось понять, почему так происходит. Наверное, нужно аудит настраивать. Вот пример от graylog. До рестарта, когда идут ошибки access denied: [root@ib1 prod]# docker exec -it graylog bash root@942b241883da:/usr/share/graylog# ls -la /usr/share/graylog/data/journal/graylog2-committed-read-offset -rw-r--r--. 1 root root 9 Dec 25 04:02 /usr/share/graylog/data/journal/graylog2-committed-read-offset После рестарта: [root@ib1 prod]# docker exec -it graylog bash root@942b241883da:/usr/share/graylog# ls -la /usr/share/graylog/data/journal/graylog2-committed-read-offset -rw-r--r--. 1 graylog graylog 9 Jan 2 20:11 /usr/share/graylog/data/journal/graylog2-committed-read-offset Также проверил в контейнере clickhouse - такая же история.

оказалось действительно так. Владельца кто-то/что-то сбрасывает на root, т.е. вместо id приложения владельцем становится id 0. Осталось понять, почему так происходит. Наверное, нужно аудит настраивать. Вот пример от graylog. До рестарта, когда идут ошибки access denied: [root@ib1 prod]# docker exec -it graylog bash root@942b241883da:/usr/share/graylog# ls -la /usr/share/graylog/data/journal/graylog2-committed-read-offset -rw-r--r--. 1 root root 9 Dec 25 04:02 /usr/share/graylog/data/journal/graylog2-committed-read-offset После рестарта: [root@ib1 prod]# docker exec -it graylog bash root@942b241883da:/usr/share/graylog# ls -la /usr/share/graylog/data/journal/graylog2-committed-read-offset -rw-r--r--. 1 graylog graylog 9 Jan 2 20:11 /usr/share/graylog/data/journal/graylog2-committed-read-offset Также проверил в контейнере clickhouse - такая же история.

Помогите задебажить, плиз: первые попытки использовать докер на бою (до этого использовали только для тестов и пилотов). Беда в том, что в различных докеризованных приложениях (graylog, clickhouse, redash) через несколько часов работы (6-24 часа) появляются ошибки Access/permission denied при записи в файлы. При этом простой restart контейнеров исправляет проблему еще на некоторые X часов. Сервер новый (72 CPU, 256 Gb RAM, 16Tb sas raid XFS). В какую сторону копать? Примеры ошибок: Redis из набора контейнеров redash очередную регулярную операцию записи в rdb файл выполняет успешно и через 5 минут fail {"log":"1:M 31 Dec 04:16:13.038 * 100 changes in 300 seconds. Saving...\n","stream":"stdout","time":"2018-12-31T04:16:13.039184451Z"} {"log":"1:M 31 Dec 04:16:13.039 * Background saving started by pid 131\n","stream":"stdout","time":"2018-12-31T04:16:13.039402225Z"} {"log":"131:C 31 Dec 04:16:13.050 * DB saved on disk\n","stream":"stdout","time":"2018-12-31T04:16:13.050413019Z"} {"log":"131:C 31 Dec 04:16:13.050 * RDB: 0 MB of memory used by copy-on-write\n","stream":"stdout","time":"2018-12-31T04:16:13.050956288Z"} {"log":"1:M 31 Dec 04:16:13.141 * Background saving terminated with success\n","stream":"stdout","time":"2018-12-31T04:16:13.141947942Z"} {"log":"1:M 31 Dec 04:21:14.086 * 100 changes in 300 seconds. Saving...\n","stream":"stdout","time":"2018-12-31T04:21:14.086386127Z"} {"log":"1:M 31 Dec 04:21:14.086 * Background saving started by pid 132\n","stream":"stdout","time":"2018-12-31T04:21:14.086644556Z"} {"log":"132:C 31 Dec 04:21:14.086 # Failed opening .rdb for saving: Permission denied\n","stream":"stdout","time":"2018-12-31T04:21:14.086918159Z”} Clickhouse около суток принимал поток логов прокси-сервера 500-1000 eps, и внезапно пошли ошибки записи в файл: 2018.12.30 04:27:25.768115 [ 34 ] {} <Error> void DB::SystemLog<LogElement>::flush(bool) [with LogElement = DB::QueryThreadLogElement]: Poco::Exception. Code: 1000, e.code() = 13, e.displayText() = Access to file denied: /var/lib/clickhouse/data/system/query_thread_log/tmp_insert_201812_2215_2215_0, e.what() = Access to file denied Graylog принимает 2000-4000 eps различных логов, и в какой-то момент Kafka в его составе теряет возможность записи в файл graylog2-committed-read-offset, в который до этого постоянно шла запись. 2018-12-19 04:16:42,906 INFO : org.apache.directory.api.ldap.codec.standalone.CodecFactoryUtil - Registered pre-bundled extended operation factory: 1.3.6.1.4.1.1466.20037 2018-12-19 04:17:59,513 ERROR: org.graylog2.shared.journal.KafkaJournal - Cannot write /usr/share/graylog/data/journal/graylog2-committed-read-offset to disk. java.io.FileNotFoundException: /usr/share/graylog/data/journal/graylog2-committed-read-offset (Permission denied) CentOS 7.6.1810. docker --version Docker version 18.09.0, build 4d60db4 docker-compose --version docker-compose version 1.23.1, build b02f130 mount … /dev/mapper/vgsas-sas on /mnt/sas type xfs (rw,nosuid,nodev,noatime,seclabel,attr2,inode64,logbsize=64k,sunit=128,swidth=2048,noquota) df -h … /dev/mapper/vgsas-var_lib_docker 48G 30G 18G 63% /var/lib/docker /dev/mapper/vgsas-sas 16T 497G 16T 4% /mnt/sas

Пример - php зависимости - composer install, если есть кеш в ~/.composer, то в большинстве случаев выполняется просто копирование вместо скачивания. Но проблема в том, что эта папка на хосте

А реверс-прокси jwilder/nginx-proxy работает со swarm или только у меня не заводится?

Не удивлюсь, что центось и забыли в вольюмах прописать z Z - надо для правильной работы меток selinux

Центось и в вольюмах я не прописывал z Z. Попробовал прописать :z в строке мапинга. Понаблюдаю. Спасибо!

А когда последний релиз был? Раньше не умел

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

У вас уже есть приложение и вам необходимо окружение для разработчика? Типа с xdebug и xhgui?

Всем привет. Только начинаю знакомится с докером. Есть рекомендации как настроить среду для разработки php?

Ну или есть https://phpdocker.io/generator если нужно под определенный проект

Ну или есть https://phpdocker.io/generator если нужно под определенный проект

редкий специалист понимает что создал генератор, а новичек купит мыло и веревку из за этого if (! -e $request_filename)

я даже логически не зная конфигов nginx понимаю что !-e это if not exists (наверно), хотя скорее всего загуглю

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

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

а как вы настраиваете отдачу статики?