Comments 12
Так и хочется сказать «Горшочек, не вари!!!»…
курс на универсальность
не лучше ли подумать в сторону специализации? "Универсальные вещи" быстро теряют простоту использования и увеличивают количество потенциальных проблем. Ну то есть конечно намного проще сделать "универсальный" контейнер и понапихивать туда всего и вся. Но может стоит упростить процесс формирования контейнеров под себя?
Формировать контейнеры под себя можно и сейчас, это довольно простой процесс. Редактируете Dockerfile по своему вкусу, далее запускате:
$ stacker build && stacker down && stacker up && stacker ps
это тоже самое что и:
$ cd /path/to/stacker
$ docker-compose build
$ docker-compose up -d
$ docker-compose ps
Данный процесс ничем не отличается от описанного в документации по докеру.
Редактируете Dockerfile
Именно этот этап обычно вызывает больше всего вопросов у новичков и вызывает много рутины. Можно упростить этот этап. Например вы хотите использовать базовый образ php:7.1-fpm-alpine и мы хотим поставить imagemagic. Нам нужно еще как-то поставить все зависимости и т.д. Это занимает время, надо разбираться какие зависимости ставить и т.д. А можно было бы сделать надстройку которая бы это дело разруливала бы.
Ну это просто идеи. Еще одна запускалка docker контейнеров миру не нужна, и уж тем более не нужны жирные образы в которых просто есть все.
На мой взгляд идея универсального образа не плоха, те же денверы и лампы построены на ней и довольно удобны. Но мне нравится ход ваших мыслей, в сторону «использовать нужное, но не больше». Допускаю, самым простым было бы отключение не нужного, а не добавление нужного. Отключить проще, чем добавлять. С первым нужно знать что нужно, таким образом уже знаешь, что отключить. Чтобы добавить, нужно знать довольно много и всякие надстройки тут не спасут, а только будут дублировать, то что и так уже делает докер это раз, плюс еще добавят сложности это два, так как все равно нужно будет изучать и доку докера и доку этой надстройки.
Идея в простоте, и если мы хотим ее предоставить, то нужно требовать, как можно меньше в плане знаний от пользователя. В принципе запилить sh для отключения не нужного не долго, просто параметрами передавать нужные образы для docker-compose и готово.
По этому оценил scotchbox, а теперь и homestead. Хотя до знакомства с вагрантом пользовался нативными решениями, разворачивая апачик и php c mysql для работе на локальной машине.
Ну напримере есть puphpet
есть и для docker подобные сервисы которые позволяют Dockerfile генерить и docker-compose файлики.
Но вот у меня ни разу не получалось собрать такой чтобы ничего не глючило и не фаталило на этапе развертывания.
Ну тут уже вопрос тестирования этого puphnet. Насколько я помню там используются свои роли для ансибла, и судя по всему они просто не особо тестируются.
Проблемы обычно возникают в момент сборки образа или провиженинга виртуалки. Обойтись без этих проблем можно запихнув все туда, но мэйнтейнить такие контейнеры весьма муторно. Да и стоит держать ровно то что используется и не больше.
Почему приводите в пример vagrаnt? Vagrant и Docker это разные технологии.
Зачем нужен Docker, если есть тот же Vagrant? Главным образом, просто потому что виртуализация в Docker дешевле. Используя Vagrant, вы эмулируете работу целой операционной системы, тогда как Docker позволяет изолировать просто один процесс. Соответственно, используя одно и то же железо, с помощью Docker вы можете создать больше виртуальных окружений, чем при помощи Vagrant. Более того, LXC контейнеры запускаются (и останавливаются тоже) практически моментально, так как в них не происходит загрузка отдельной ОС. К тому же, Docker использует «слоеную» файловую систему AuFS, благодаря которой контейнеры могут совместно использовать одинаковые части файловой системы, доступные только на чтение. Если образ файловой системы занимает 5 Гб и вы запускаете 100 виртуальных окружений, то Vagrant потребуется 500 Гб места, а Docker — на порядок меньше.
виртуализация в Docker дешевле
Там нет виртуализации. Все работает за счет изоляции.
благодаря которой контейнеры могут совместно использовать одинаковые части файловой системы
Для меня основной профит это возможность дистрибуции слепков файловой системы как образов. Это сильно упрощает процесс поддержки инфраструктуры.
Именно по этой причине мне не нравится идея "универсальных образов". Чем больше в них вещей тем больше шансов на поломку. А с учетом того что докер при сборке образа никак не гарантирует нам идемпотентность, чем он меньше и чем меньше причин для его пересборки — тем лучше.
Конечно это не имеет значения если мы не используем докер образы при деплое. Я вот использую и потому для меня это важно.
Да и в целом, прод это уже за локусом так сказать, там сервер, а за сервер должны отвечать админы. Конечно, если разработчик может полноценно совмещать еще и обязанности админа — это замечательно. Но это больше из разряда легенд о единороге. Пока еще не видел не одного сильного разработчика, что бы он еще при этом был и сильным админом.
Если, это не что-то личное. В этом случае вопросов нет.
Stacker: что нового?