Конечно. Работать с архивами полного стека своего приложения размером 2 мб без требований доступности стороннего репозитория намного удобнее, чем с архивами размером 70 мегабайт или обязательной хорошей быстрой связью с интернет. Я работаю с ноута в поездках.
SomeContentNginx extends DockerNginx вносит зависимость от DockerNginx.
классический вопрос проектирования, лучше обратиться к Фаулеру www.martinfowler.com/articles/injection.html
К слову, для деплоймента приложения, структуры СУБД и конфигов нужен только один образ в виде одного небольшого .tar.xz-файла. Все разворачивается из него и compose-конфига одной единственной командой.
При этом, можно подменять модули на лету — php, python, nginx, перепрыгивать с mariadb на percona, развернуть локально репликацию, и откатиться при сбое. Удобно для stage и разработки.
Да, админам это не нужно, это ломает привычный development-deployment cycle. Мне так удобно.
Эта дискуссия повторяет холивары десятилетней давности относительно официальных репозиториев пакетов, собственных репозиториев, сборки софта из исходников, и смешанных вариантов по типу gentoo :)
Каждому свое.
Ни в коем случае я не против распространения своих утилит вместе с библиотеками в образах. Я это делаю.
Безусловно, registry — это удобно, и, возможно, я в будущем напишу об этом. Вряд ли опубликую здесь при подобной доброжелательности аудитории :)
При желании можно обойтись и без него, и без composer. Единого православного способа не существует.
1. Персистентность реализуется через Data Volume container.
2. Простите, не понимаю, разве веб-фреймворк что? Уточните, пожалуйста.
В целом, Docker размывает границы между админами и разработчиками — разработчики начинают заботиться о настройках системных служб и включают их конфигурацию в контейнер.
Необходимость передавать на другой компьютер отдельно Dockerfile и само приложение. Я предпочитаю передавать один маленький .tar.xz, и из него одной командой разворачивать работающую систему с базой, веб-сервером, runtime, библиотеками и конфигами.
Господа, это оригинальное исследование с фатальным недостатком. Похоже, оно рвет шаблоны — вы привыкли делать иначе :)
Мой алгоритм работает, и он удобен.
Буду рад если вы опишите недостатки не новизны восприятия информации, а технические.
Наоборот, мой подход позволяет на лету подменять любую часть стека приложения без нужны пересобирать образ с runtime, web-сервером и базой данных. В разработке преимущества большие, конечно — можно запустить 5 версий php и быстро между ними переключаться.
Конечно, но определение «не велики» относительное. У моего друга из Ebay дневной лимит на добавление серверов 50 тысяч долларов, ему все проблемы в рунете — мышинная возня, он просто добавляет десяток серверов в любой момент. Все относительно.
Вы оперируете субъективными критериями: «не проблема», «очень просто». Конечно, запустить ракету в космос — тоже не проблема. Я описываю альтернативное решение без проблем вообще.
Вы предложили настраивать и поддерживать внутренний registry. Это значит, что надо решать проблему SPOF этого registry, а именно: организовывать бекап его данных, мониторить, делать репликацию, чтобы не останавливать выкладки. Нужны все обычные телодвижения для дополнительного сервиса в полноценной инфраструктуре.
У меня возникли такие же ощущения, когда я прочитал ваш комментарий, как у вас, когда вы прочитали мой. Предлагаю перейти к осмысленному диалогу с вопросами, предложениями или замечаниями в контексте этой серии статей. Ваши ощущения — это очень важно, но только для вас.
Сделать build из своих исходных Dockerfile на другом компьютере мешает необходимость дополнительных телодвижений: или передавать отдельно свое приложение, или поднимать registry, или платить.
Я не состязаюсь, простите, но мне все равно прав я или нет. Если у вас есть вопрос — я могу пояснить. Могу забить :)
Эта заметка не про registry, не про compose, не про swarm. Могу написать о registry отдельную заметку.
Каждое слово, вроде бы, понятно, но текст в целом не понимаю, простите :)
Nginx — это веб-серевер, а не фреймворк, и ничем из него фреймворк не сделать. Удобно хранить вместе приложение и runtime — ради бога, эти статьи для тех, кому надо разделять.
1. аналогично rpm и deb. Кто-то собирает свои пакеты, кто-то ставит официальные. Собирайте, поддерживайте свои, я не против.
2. приватный репозиторий сделать можно, но надо заплатить :) О том и речь. У нас же не магазин на битриксе, а несколько микросервисов, и каждому нужен репозиторий. Мы же облачное масштабируемое приложение обсуждаем?
3. Да, можно поднять registry. Можно настроить Vagrant. Можно работать образами виртуальных машин и забыть про docker.
Я не проповедь читаю ;)
классический вопрос проектирования, лучше обратиться к Фаулеру www.martinfowler.com/articles/injection.html
При этом, можно подменять модули на лету — php, python, nginx, перепрыгивать с mariadb на percona, развернуть локально репликацию, и откатиться при сбое. Удобно для stage и разработки.
Да, админам это не нужно, это ломает привычный development-deployment cycle. Мне так удобно.
Каждому свое.
Ни в коем случае я не против распространения своих утилит вместе с библиотеками в образах. Я это делаю.
Безусловно, registry — это удобно, и, возможно, я в будущем напишу об этом. Вряд ли опубликую здесь при подобной доброжелательности аудитории :)
При желании можно обойтись и без него, и без composer. Единого православного способа не существует.
2. Простите, не понимаю, разве веб-фреймворк что? Уточните, пожалуйста.
В целом, Docker размывает границы между админами и разработчиками — разработчики начинают заботиться о настройках системных служб и включают их конфигурацию в контейнер.
Мой алгоритм работает, и он удобен.
Буду рад если вы опишите недостатки не новизны восприятия информации, а технические.
Эта заметка не про registry, не про compose, не про swarm. Могу написать о registry отдельную заметку.
Nginx — это веб-серевер, а не фреймворк, и ничем из него фреймворк не сделать. Удобно хранить вместе приложение и runtime — ради бога, эти статьи для тех, кому надо разделять.
2. приватный репозиторий сделать можно, но надо заплатить :) О том и речь. У нас же не магазин на битриксе, а несколько микросервисов, и каждому нужен репозиторий. Мы же облачное масштабируемое приложение обсуждаем?
3. Да, можно поднять registry. Можно настроить Vagrant. Можно работать образами виртуальных машин и забыть про docker.
Я не проповедь читаю ;)