Настройка среды разработки ВНУТРИ виртуальной машины

Question

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

Работа с PHP-проектом здесь, так: Установите и настройте PDT, отладчик php и некоторую версию XAMPP. Затем можно установить клиент SVN и любые другие инструменты.

Снова к каждой из пяти машин.

Что если вместо этого мы проделали все это один раз на виртуальной машине, настроенной на тот же стек, с теми же версиями, что и на производственном сервере. Затем каждый из нас может получить копию образа виртуальной машины, запустить этот образ на каждой из пяти машин и выполнить всю нашу разработку на этой виртуальной машине. Поместите Eclipse, Apache, MySQL, все работы, все в этом VM.

Единственный минус этого подхода, и, пожалуйста, исправьте меня только с одной стороны, это производительность. Правда ли, что это большая проблема? Самая медленная из пяти машин - Samsung NC10 с процессором Intel Atom 1.6 ГГц.

Как вы думаете, это возможно и практически применимо? Или я сумасшедший?

Answer 1

Я использую виртуальную машину для разработки (работает на моем ноутбуке), и у меня никогда не было проблем с производительностью. Другой подход, который вы могли бы использовать, - это изображение диска в том состоянии, в котором вы хотите. Используйте Acronis или Ghost для повторного создания образа каждой машины, когда это необходимо. Восстановление образа на любом современном ПК занимает около 5-10 минут.

Answer 2

Я использую виртуальную машину для всей моей «работы», так как она не позволяет мне «играть». Эта настройка позволяет мне использовать офисную VPN, не подвергая всю свою машину воздействию офисной среды (которой я доверяю так же, как и интернету. ;-) Кроме того, мне не нужно беспокоиться о том, чтобы испортить свою среду разработки, пробуя игры или другое программное обеспечение. Моя рабочая виртуальная машина в настоящее время работает внутри VirtualBox, но я использовал VMWare в прошлом. Я замечал только проблемы с производительностью при использовании интенсивных графических программ, таких как Webex или Terminal Server Client.

Answer 3

С vmware дисковые операции выполняются медленнее. Для разработки PHP я сомневаюсь, что это будет проблемой, но вы определенно заметите это, если будете компилировать большой проект C ++. Существует также Sun VirtualBox, который является бесплатным, и последняя версия довольно приятна (но я еще не видел, насколько медленными являются операции на диске).

Answer 4

Я запустил websphere for zSeries на виртуальной машине vmware без проблем, и websphere требует больше ресурсов, чем любой стек PHP. Я считаю, что наличие многоядерной машины или, по крайней мере, гиперпоточности делает ее работу намного быстрее.

Answer 5

Если вы используете Windows, вы, вероятно, захотите использовать SYSPREP в главном образе, чтобы мини-настройка запускалась при первой загрузке виртуальных машин.

В противном случае, с точки зрения Windows, машины имеют одинаковый SID, имя хоста и другие вещи - запуск нескольких машин с одинаковым SID в одной сети может вызвать тонны головной боли. Даже больше, если вы хотите, чтобы они общались друг с другом.

Answer 6

Это, безусловно, можно сделать. Что меня отвлекает, так это размер образа виртуальной машины, который обычно составляет несколько ГБ. Наличие его на сетевом ресурсе означает, что передача может занять больше времени, чем текущий процесс установки. Я думаю, что внешний жесткий диск был бы самым простым способом переместить его.

Производительность не будет проблемой для любой веб-разработки.

Я должен спросить, почему ваши нынешние машины нужно «переизображать» каждый раз, когда вы садитесь за работу?

Answer 7

Вы думали о диспетчере конфигурации программного обеспечения, как ansible , повар или марионетка? С таким программным обеспечением автоматизировать такие задачи очень просто! Он даже может создать свежий vm и затем настроить его.

Answer 8

Я использую эту идею на практике. Виртуальные машины, как правило, отлично подходят для разработки.

1. Для работы в нескольких операционных системах и в нескольких отдельных средах разработки.
2. Сохранение старых сред разработки для последующей поддержки.
3. Может быть легко сохранено, если сбой жесткого диска не требует запуска с начала.
4. Может быть скопирован с разработчика на другого, поэтому каждый не должен делать утомительные установки и настройки.

Нижние стороны:

1. Виртуальные машины медленнее, вам нужны более мощные компьютеры, чем в противном случае. Я бы порекомендовал иметь как минимум 4 ГБ оперативной памяти, но желательно больше, как 16, быстрые многоядерные процессоры и быстрые жесткие диски.
2. Копируя виртуальные машины с ОС Windows, каждая используемая копия виртуальной машины должна иметь свой собственный ключ продукта. Когда вы делаете копию, она должна быть зарегистрирована с новым ключом продукта.