Организация коробочной виртуализации

Может вас заинтересует chef, puppet, ansible

maxttor, chief, puppet и пр скорее можно охарактеризовать словом "развертывание". Много раз, автоматически и в разных позах.

А если вас просто постоянно гоняют по хостингам с одной и той же VPS - вам нужен proxmox и самое обычно копирование контейнера.

proxmox - это просто веб интерфейс с кнопочками. Что там у вас не пошло ?

Да, то, что нужно. Если бы не было аспекта совместной работы различных разработчиков, то да, естественно, более простым наверно было бы использование proxmox.

Но если все системы виртуализации создают один большой контейнер, в который помещается весь проект. Да это удобно, да это решает поставленную задачу, НО! то что предлагает Docker это гораздо более интересное решение - дает миллион маленьких коробок для упаковывания различных программ по отдельности. И каждой такой коробкой можно обмениваться с другими разработчиками для решения совместных задач, взять какую то коробку и выложить на время из продакшена и потом снова при желании воткнуть. Т.е. получается модульная работа, которая ускорит и упростит разработку и выкладку на продакшен. Ну и так же позволит решать изначально поставленную задачу - перенос проекта на новый сервер без необходимости подгонки окружения.

OpenVZ - если не нужно кастомное ядро внутри контейнера. KVM - если нужно.

Заливаете контейнер на новый сервер и разворачиваете.

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

Почему не рассмотреть для таких ситуаций клонирование диска? Нет никаких проблем склонировать linux или bsd систему даже в онлайн режиме, не говоря уже об офлайне. В Windows это чуть сложнее (особенно если есть большая разница в железках), но тоже можно сделать как вручную, так и с помощью специальных утилит.

Всем привет!

Все зависит от того - как вы работаете и какими методами.

Если у вас проекты на хостингах в арендуемых впс - вы уверены, что завернув на своей стороне контейнер в архив и передав его хостеру - хостер его быстро развернет? Может быть формат не совпадет и т д.

Если вы переезжаете с сервера на сервер - то почему бы не вкатывать на сервер свой гипервизор ? Мне тут видится дорогое решение, но без секса: купить лицензию VMware (могу показать, у кого на этом форуме. Олег, привет!) - абсолютно без проблемное перетаскивание виртуалок туда сюда.

Если вы арендуете впс на стороне хостера и любите переезжать туда-сюда, то мне тут видится просто сборка инсталлятора. Зачастую - по большому счету - это решает проблемы. Что-то типа того:

подготовить_сервер_к_работе_зашибись.sh

настроить_сервер.sh

залить_проект_на_сервер.sh

Вы бы рассказали более детально, в чем проблемы - можно было бы предметно посоветовать.

Сервер, переезжаю редко, но проблема растет по экспоненте. И от следующего переезда думаю захочется ввброситься в окно )

Часто вижу хвалы докеру и прочим новомодным фишкам. Но при этом никто не может выделить преимущество перед обыкновенным контейнером VPS.

Для себя давно остановился на CentOS и документировании нужных действий и конфигов к проекту. В результате в пару команд ставятся нужные пакеты, проекты приезжают по git и через свои же команды разворачивают конфиги.

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

А зачем ?

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

"написать четкие инструкции по работе с ней" - это означает все равно не учесть ваши новые потребности и месяц вас консультировать по разным вопросам. Дорого будет.

Маленькие контейнеры можно делать и на proxmox. И точно так же их копировать туда-сюда.

А вот полная виртуализация типа kvm или vmware, для многокомпонентного сайта не подходит. Там слишком большие накладные расходы на взаимодействие компонент. Openvz - в самый раз.

Docker бы тоже подошел, но вы здесь и у вас уже возникли непонятки. С proxmox их, скорее всего, не будет.