Каковы преимущества перемещения виртуальных хостов в контейнеры Docker?
См. help(Sys.sleep).
Например, из ?Sys.sleep
testit <- function(x)
{
p1 <- proc.time()
Sys.sleep(x)
proc.time() - p1 # The cpu usage should be negligible
}
testit(3.7)
Удержание
> testit(3.7)
user system elapsed
0.000 0.000 3.704
2 ответа
Проще говоря, vm - это полноценная ОС с множеством вещей, в которых вы не нуждаетесь, в то время как контейнеры буквально являются контейнерами для любых служб (обычно одной службы на контейнер), которые вам нужны. Из-за этого легче масштабировать. Другие преимущества приходят с этим основным.
Я попытался избежать мнения и просто изложить факты из моего опыта, однако сама природа вопроса, конечно, вызывает неопределенность и споры.
Я недавно закончил переход на докер.
Основные преимущества:
- Обеспечение мышления без учета состояния
- Масштабирование
- Простота развертывания
- Идентичная среда разработки (* массивное предупреждение - см. Ниже) )
Основные недостатки:
- Кривая обучения
- Абстракция окружающей среды
Перво-наперво:
[ 1113] Если ваши сервисы с высокой степенью состояния (в файловой системе), вам придется перестроить архитектуру или потерять почти все преимущества Docker. Если это так, я бы решительно сказал вам не беспокоиться на этом этапе и, возможно, рассматривать Docker как среднесрочную и долгосрочную часть более широкого проекта, продвигающегося к 12-факторному приложению. ( https://12factor.net/ )
Даже если ваша базовая архитектура готова к миграции, преимущества сильно перевешиваются недостатком кривой обучения, если ваш сайт никогда не собирается быть "огромным" Горизонтальное масштабирование - это здорово, но большинству сайтов оно никогда не понадобится, и время, затраченное на кривую, в большинстве случаев может быть использовано с большей пользой, уменьшая время выхода на рынок / итерации. Я довольно уверен в компьютерах и новых технологиях, и это заняло у меня 4 довольно солидных месяца, чтобы выглядело так же, как у вас.
Предупреждение о разработке:
Преимущество «разработки» чревато опасностью, особенно если вы на Mac. PHP требует много файлов, работающих в тандеме, для запуска вашего сайта, и различия в файловой системе означают, что это в 4 или 5 раз медленнее на вашем Mac (при запуске Docker), чем на вашем сервере. Это очень расстраивает. Есть решения, но они добавляют к кривой обучения и все еще не совершенны.
Кроме того, «мечта» об идентичных средах также имеет много кошмарных аспектов. Собираетесь ли вы принудить локальные машины использовать SSL? Тогда вам понадобятся «поддельные» самозаверяющие сертификаты на всех ваших компьютерах разработчика, и, следовательно, жалобы от браузеров каждый раз, когда вы пытаетесь посетить его. Кроме того, NGINX работает по-разному с docker-compose, чем с развертыванием стека, и есть много преимуществ для разработки с использованием compose, а не стека, поэтому использование стека на самом деле не вариант. Мне потребовалась неделя, чтобы найти решение этой проблемы.
Однако, как только эти проблемы были исправлены (мы перешли на Linux для разработки, и у нас есть сценарии для решения большинства других проблем, и нам нужно просто сказать Chrome, что я принимаю «поддельные» сертификаты каждые 2 часа или около того) по общему признанию, все очень гладко, и я рад, что у меня был этот опыт. Новые проекты, вероятно, с самого начала будут использовать преимущества докера, когда у меня появилось ощущение того, как он работает, где есть подводные камни и как исправить ситуацию.
Заключение:
Я бы посоветовал изучать докер в течение года или около того в свободное время, а не заниматься им на работе. Есть преимущество сейчас, когда мы прошли через боль, но это было МНОГО боли. И если вы узнаете это в нерабочее время, убедитесь, что вы делаете что-то, что имитирует полномасштабное производственное развертывание, с непрерывной интеграцией, тестированием, работами. С Docker так легко начать, что он обманом заставит вас думать, что освоить его одинаково легко. Это действительно не так.