докер

[hell0w0rd]

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

 

[AnrDaemon]

Жаль только, что ни одного замечания по технологии, только "чего он строем не ходит", нарушаю официальные best practices.

Снобы и ретрограды!

 

[AnrDaemon]

Ну ты используешь docker, как VM, в которой изолированно стоит софт

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

 

[fixxxer]

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

https://coreos.com/using-coreos/containers/ не?

 

[grigori]

Ну ты используешь docker, как VM

с точностью до наоборот
документация докера предлагает использовать его как VM, а я использую как Vagrant

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

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

 

[Absinthe]

с точностью до наоборот
документация докера предлагает использовать его как VM, а я использую как Vagrant

Но ведь docker для своей работы уже требует vagrant (из-за того, что у всех членов проекта разные ОС).

 

[grigori]

Но ведь docker для своей работы уже требует vagrant (из-за того, что у всех членов проекта разные ОС).

можно и vagrant, но хватает одного архива размером 2 мегабайта и несколько команд.
работает-то оно в виртуалке, а управляется через утилиты docker-machine, docker и docker-compose - это клиенты, которые работают под виндой и маком
https://www.docker.com/toolbox

 

[флоппик]

http://blog.jetbrains.com/phpstorm/2015/10/docker-support-in-phpstorm/

 

[grigori]

Собрал образ PHP 7 c популярными расширениями:
https://github.com/grikdotnet/phpdocker

Еще напишу команды для монтирования папок для удобного редактирования конфигов и swarm-файл для запуска вместе с nginx и mysql.

 

[c0dex]

@grigori,

• pdo_pgsql

2 раза написал в readme.

 

[grigori]

думаю что делать с image magic и graphics magic
можно ставить их из репозитория, но у них в зависимостях X server, который на фронте нахрен не нужен, преобразование HTML в jpg не так уж часто востребовано,
поэтому пока думаю ставить из исходников

>2 раза написал в readme.
спасибо

 

[AnrDaemon]

Нет там Х сервера в зависимостях. Только либы.

 

[grigori]

# apt-get install --no-install-recommends imagemagick libmagickcore-6.q16-dev

Спойлер: 149 MB of additional disk space

The following NEW packages will be installed:
fontconfig fontconfig-config fonts-dejavu-core gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0
gir1.2-rsvg-2.0 hicolor-icon-theme imagemagick imagemagick-6.q16 imagemagick-common libbz2-dev
libcairo-gobject2 libcairo-script-interpreter2 libcairo2 libcairo2-dev libcdt5 libcgraph6 libcroco3 libdatrie1
libdjvulibre-dev libdjvulibre-text libdjvulibre21 libelfg0 libexif-dev libexif12 libexpat1 libexpat1-dev
libfftw3-double3 libfontconfig1 libfontconfig1-dev libfreetype6 libfreetype6-dev libgd3 libgdk-pixbuf2.0-0
libgdk-pixbuf2.0-common libgdk-pixbuf2.0-dev libgirepository-1.0-1 libglib2.0-bin libglib2.0-data
libglib2.0-dev libgraphite2-3 libgraphviz-dev libgvc6 libgvpr2 libharfbuzz0b libice-dev libice6 libilmbase-dev
libilmbase6 libjasper-dev libjasper1 libjbig-dev libjbig0 libjpeg-dev libjpeg62-turbo libjpeg62-turbo-dev
libjs-jquery liblcms2-2 liblcms2-dev liblqr-1-0 liblqr-1-0-dev libltdl-dev libltdl7 liblzma-dev liblzo2-2
libmagickcore-6-arch-config libmagickcore-6-headers libmagickcore-6.q16-2 libmagickcore-6.q16-2-extra
libmagickcore-6.q16-dev libmagickwand-6.q16-2 libopenexr-dev libopenexr6 libpango-1.0-0 libpangocairo-1.0-0
libpangoft2-1.0-0 libpathplan4 libpcre3-dev libpcrecpp0 libpixman-1-0 libpixman-1-dev libpng12-0 libpng12-dev
libpthread-stubs0-dev libpython-stdlib libpython2.7-minimal libpython2.7-stdlib librsvg2-2 librsvg2-common
librsvg2-dev libsm-dev libsm6 libthai-data libthai0 libtiff5 libtiff5-dev libtiffxx5 libvpx1 libwmf-dev
libwmf0.2-7 libx11-6 libx11-data libx11-dev libxau-dev libxau6 libxcb-render0 libxcb-render0-dev libxcb-shm0
libxcb-shm0-dev libxcb1 libxcb1-dev libxdmcp-dev libxdmcp6 libxdot4 libxext-dev libxext6 libxml2-dev libxpm4
libxrender-dev libxrender1 libxt-dev libxt6 mime-support python python-minimal python2.7 python2.7-minimal
shared-mime-info ucf x11-common x11proto-core-dev x11proto-input-dev x11proto-kb-dev x11proto-render-dev
x11proto-xext-dev xorg-sgml-doctools xtrans-dev zlib1g-dev
0 upgraded, 139 newly installed, 0 to remove and 1 not upgraded.
Need to get 47.9 MB of archives.
After this operation, 149 MB of additional disk space will be used.

самого Х-сервера нет, только 100 пакетов, и питон

 

[AnrDaemon]

Ну вот такой магический имеджик

 

[c0dex]

самого Х-сервера нет, только 100 пакетов, и питон

Тибе чиго, жалка что ли? =D

 

[grigori]

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

 

[fixxxer]

А это привет мейнтенерам, там 95% этого дерьма нужно 1% пользователей.

Я сам не пробовал и только теоретизирую, но я бы в качестве базовой ОС для сборки application containers* взял более гибкий дистрибутив без дебиана головного мозга**, где пакеты с минимальным вмешательством мейнтенеров, и с удобной, простой и понятной системой сборки пакетов. Скажем, ArchLinux (ну или gentoo, наверное, хотя давно его не видел). проблемы с тем, что это роллинг-релиз, в случае с контейнерами не вижу - зачем мне совместимость библиотек между разными контейнерами?

*) специально не говорю слово "докер", потому что уже вышел релиз rkt, и acbuild вполне юзабелен
**) религиозное следование правилам, которые придуманы в 90-х годах и давно неактуальны, а с массовым внедрением контейнеров и SCM только мешают

 

[grigori]

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

Кстати, вот мой образ в сборке https://hub.docker.com/r/grigori/phpextensions/
опробовал автоматический билд

может, допишу сегодня остальные скриптики для быстрого деплоя полного стека

 

[fixxxer]

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

Исторически сложилось

Вообще дебиан - неудачная база для контейнеров, как по мне. Контейнеры-то уж хочется закастомайзить под себя. А править deb-src - это то еще приключение. В Arch на порядок проще пакеты править и собирать, там дерево сорцов пакетов чем-то freebsd-порты напоминает.

 

[флоппик]

А править deb-src - это то еще приключение.

*плачет*