Построение инфраструктуры небольшой компании разработчиков программного обеспечения с использованием виртуализации
Invite pending
Как без существенных затрат вырасти с двух человек до небольшого офиса с 12 разработчиками?
Как увеличить одновременную поддержку проектов с 2 до 10?
Как подготовить новое рабочее место за 7 минут?
Как, в случае необходимости, поддерживать работу распределенной команды?
Виртуализация!
Идея виртуализации, в нашей небольшой девелоперской конторе, витала давно. Мы начинали работать несколько лет назад, каждый из своего дома, используя общий внешний SVN, как средство обмена исходными кодами. Тогда нас было два человека, достаточно высокого уровня, так что слишком больших проблем с настройкой сред не возникало, а если возникало — можно было сделать это один раз и забыть об этом. Так продолжалось примерно полтора года, проекты накапливались, среда развертывания понемногу усложнялась, команда росла, и сложность настройки среды «чужого» проекта потихоньку увеличивалась до достижения стадии «как ты создал эту годзиллу?!»
Опыт использования виртуализации уже был ранее — лет 6-7 назад работали с настольной Wine и VmWare Workstation. Поэтому изначально мы создавали виртуальные среды с проектами, на основе VirtualBox. Плюс такого решения в том, что достаточно было скопировать образ виртуальной машины, и получалась нужная среда. Сложности начались с распространением таких виртуальных сред в рамках распределенной команды — образы могли быть достаточно велики, а необходимость иметь на каждой машине разработчика нескольких виртуальных машин, с возможностью одновременного их запуска, увеличивало требования к железу.
Примерно в это же время, мы начали централизовываться и решать вопрос с совместной работой в рамках одного офиса. Сначала мы попробовали использовать тот же самый VirtualBox на достаточно мощной девелоперской машине, однако не хватало средств централизованного управления образами и накладные расходы на виртуализацию нам казались великоваты, и мы решили попробовать серверную виртуализацию, устанавливаемую на «голое железо».
Было решено, под каждый проект на разработчика выделять виртуальную машину под управлением Linux Mint 64 следующей конфигурации: 4Gb RAM, 4x core CPU, 32 GB HDD.
Клиентские места на базе платформы Foxconn nT-i2847 4Gb RAM, 32 Gb SSD.
В качестве протокола удаленного доступа к linux машинам, после изысканий и серии испытаний, был выбран NX Nomachine. В случае необходимости создания нового рабочего места, новая машина просто клонировалась из существующей или восстанавливалась из предварительно созданной эталонной копии. По скорости, по ощущениям было намного лучше, плюс управлять образами было намного проще. Через некоторое время, войдя во вкус, мы подключили вторую серверную машину, абсолютно такой же конфигурации, как и первая.
Тут у нас возникла проблема копирования виртуальных образов между машинами, и мы решили централизовать их хранение, с перспективой перехода на кластерную конфигурацию из двух (или более) гипервизоров. Для этого было построен небольшой собственный NAS под управлением FreeNAS 9.1. При создании NAS, в частности при выборе железа, вдохновлялись вот этой статьей. Решение оказалось достаточно мощным и гибким для наших нужд, и в то же время не таким дорогим, как коммерческие NAS, сопоставимой мощности.
Но подход централизованного хранения образов машин на нашем NAS, в дальнейшем, оказался неоправданным, так как в случае копирования-восстановления машин, либо выполнения каких-либо тяжелых файловых операций резко вырастал IOwait, что плохо отражалось на производительности всех машин, образы которых находились на сетевом хранилище. Начала проявляться и другая проблема — с ростом числа серверов управление набором серверов с ESXi усложнялось, а хорошие средства управления для таких сред от VmWare оказались слишком дороги.
Поэтому, параллельно, на одном из освободившихся девелоперских десктопов, нами был развернут гипервизор на базе KVM, проекта Proxmox. Данное решение так же может устанавливаться на голое железо, и представляет богатый набор инструментов управления, как через веб интерфейс, так и посредством командной строки. Дальнейшая эксплуатация показала большую гибкость, удобство, и соответствие нашим потребностям решения виртуализации на базе Proxmox и было решено перейти полностью на него. Благо, миграция ESXi — Proxmox осуществляется довольно просто.
Архитектурно решение выглядит так: образ диска виртуальной машины находится на локальном жестком диске гипервизора, ежедневно, в ночное время, по расписанию, производится горячее резервное копирование машин и бекапы размещаются на сетевом хранилище.
Данный подход позволяет за достаточно короткое время (около 4 минут) восстановить машину из ночного бекапа. Так же, средствами Proxmox, возможно на горячую клонировать машину. Специально для этого нами был написан bash скрипт, который клонирует определенную машину, присваивает ей новый IP адрес и меняет сетевое имя. Среднее время работы скрипта составляет 7 минут. То есть, за указанное время, мы получаем новое, полностью готовое, настроенное рабочее место разработчика под конкретный проект.
Для организации удаленного доступа к локальной сети офиса нами был поднят openvpn сервер. 10 Мбитный канал обеспечивает весьма комфортную удаленную работу, что позволяет иногда работать из дома или подключаться к своей среде, например, из офиса заказчика.
Такое положение дел, на настоящий момент, полностью нас устраивает, решение является в целом устоявшимся (4 месяца полёт нормальный), эксперименты в области автоматизации вновь возникающих задач и развития нашей инфраструктуры, продолжаются. Сейчас мы имеем стойку, в которой установлены пять серверов (три из них бывшие десктопы разработчиков) и NAS.
На текущий момент этим железом поддерживается 12 виртуальных машин разработчиков, 12 non-gui linux серверов связанных со средой разработки, 4 сервера препрод окружения для эмуляции среды заказчика (специфичные серверы с большим количеством сетевых интерфейсов), один Oracle сервер, сервер автоматической сборки Jenkins, два инфраструктурных сервера FreeBSD.
Поскольку мы работаем в одной комнате с этой стойкой, то при сборке как NAS, так и двух машин на i7 выбирали всякие тихие решения (кулеры, блоки питания). В результате, стойки практически не слышно.
Построение описанной инфраструктуры, в течение почти полутора лет, привело к тому, что у нас накопилась обширная база знаний по многим вопросам, связанным с виртуализацией рабочих мест и развития инфраструктуры небольших предприятий. Мы готовы участвовать в проектах связанных с внедрением подобных решений, консультированием, сопровождением.
Давайте обмениваться опытом, общаться и сотрудничать!
Как увеличить одновременную поддержку проектов с 2 до 10?
Как подготовить новое рабочее место за 7 минут?
Как, в случае необходимости, поддерживать работу распределенной команды?
Виртуализация!
Идея виртуализации, в нашей небольшой девелоперской конторе, витала давно. Мы начинали работать несколько лет назад, каждый из своего дома, используя общий внешний SVN, как средство обмена исходными кодами. Тогда нас было два человека, достаточно высокого уровня, так что слишком больших проблем с настройкой сред не возникало, а если возникало — можно было сделать это один раз и забыть об этом. Так продолжалось примерно полтора года, проекты накапливались, среда развертывания понемногу усложнялась, команда росла, и сложность настройки среды «чужого» проекта потихоньку увеличивалась до достижения стадии «как ты создал эту годзиллу?!»
Опыт использования виртуализации уже был ранее — лет 6-7 назад работали с настольной Wine и VmWare Workstation. Поэтому изначально мы создавали виртуальные среды с проектами, на основе VirtualBox. Плюс такого решения в том, что достаточно было скопировать образ виртуальной машины, и получалась нужная среда. Сложности начались с распространением таких виртуальных сред в рамках распределенной команды — образы могли быть достаточно велики, а необходимость иметь на каждой машине разработчика нескольких виртуальных машин, с возможностью одновременного их запуска, увеличивало требования к железу.
Примерно в это же время, мы начали централизовываться и решать вопрос с совместной работой в рамках одного офиса. Сначала мы попробовали использовать тот же самый VirtualBox на достаточно мощной девелоперской машине, однако не хватало средств централизованного управления образами и накладные расходы на виртуализацию нам казались великоваты, и мы решили попробовать серверную виртуализацию, устанавливаемую на «голое железо».
Было решено, под каждый проект на разработчика выделять виртуальную машину под управлением Linux Mint 64 следующей конфигурации: 4Gb RAM, 4x core CPU, 32 GB HDD.
Клиентские места на базе платформы Foxconn nT-i2847 4Gb RAM, 32 Gb SSD.
В качестве протокола удаленного доступа к linux машинам, после изысканий и серии испытаний, был выбран NX Nomachine. В случае необходимости создания нового рабочего места, новая машина просто клонировалась из существующей или восстанавливалась из предварительно созданной эталонной копии. По скорости, по ощущениям было намного лучше, плюс управлять образами было намного проще. Через некоторое время, войдя во вкус, мы подключили вторую серверную машину, абсолютно такой же конфигурации, как и первая.
Тут у нас возникла проблема копирования виртуальных образов между машинами, и мы решили централизовать их хранение, с перспективой перехода на кластерную конфигурацию из двух (или более) гипервизоров. Для этого было построен небольшой собственный NAS под управлением FreeNAS 9.1. При создании NAS, в частности при выборе железа, вдохновлялись вот этой статьей. Решение оказалось достаточно мощным и гибким для наших нужд, и в то же время не таким дорогим, как коммерческие NAS, сопоставимой мощности.
Но подход централизованного хранения образов машин на нашем NAS, в дальнейшем, оказался неоправданным, так как в случае копирования-восстановления машин, либо выполнения каких-либо тяжелых файловых операций резко вырастал IOwait, что плохо отражалось на производительности всех машин, образы которых находились на сетевом хранилище. Начала проявляться и другая проблема — с ростом числа серверов управление набором серверов с ESXi усложнялось, а хорошие средства управления для таких сред от VmWare оказались слишком дороги.
Поэтому, параллельно, на одном из освободившихся девелоперских десктопов, нами был развернут гипервизор на базе KVM, проекта Proxmox. Данное решение так же может устанавливаться на голое железо, и представляет богатый набор инструментов управления, как через веб интерфейс, так и посредством командной строки. Дальнейшая эксплуатация показала большую гибкость, удобство, и соответствие нашим потребностям решения виртуализации на базе Proxmox и было решено перейти полностью на него. Благо, миграция ESXi — Proxmox осуществляется довольно просто.
Архитектурно решение выглядит так: образ диска виртуальной машины находится на локальном жестком диске гипервизора, ежедневно, в ночное время, по расписанию, производится горячее резервное копирование машин и бекапы размещаются на сетевом хранилище.
Данный подход позволяет за достаточно короткое время (около 4 минут) восстановить машину из ночного бекапа. Так же, средствами Proxmox, возможно на горячую клонировать машину. Специально для этого нами был написан bash скрипт, который клонирует определенную машину, присваивает ей новый IP адрес и меняет сетевое имя. Среднее время работы скрипта составляет 7 минут. То есть, за указанное время, мы получаем новое, полностью готовое, настроенное рабочее место разработчика под конкретный проект.
Для организации удаленного доступа к локальной сети офиса нами был поднят openvpn сервер. 10 Мбитный канал обеспечивает весьма комфортную удаленную работу, что позволяет иногда работать из дома или подключаться к своей среде, например, из офиса заказчика.
Такое положение дел, на настоящий момент, полностью нас устраивает, решение является в целом устоявшимся (4 месяца полёт нормальный), эксперименты в области автоматизации вновь возникающих задач и развития нашей инфраструктуры, продолжаются. Сейчас мы имеем стойку, в которой установлены пять серверов (три из них бывшие десктопы разработчиков) и NAS.
На текущий момент этим железом поддерживается 12 виртуальных машин разработчиков, 12 non-gui linux серверов связанных со средой разработки, 4 сервера препрод окружения для эмуляции среды заказчика (специфичные серверы с большим количеством сетевых интерфейсов), один Oracle сервер, сервер автоматической сборки Jenkins, два инфраструктурных сервера FreeBSD.
Поскольку мы работаем в одной комнате с этой стойкой, то при сборке как NAS, так и двух машин на i7 выбирали всякие тихие решения (кулеры, блоки питания). В результате, стойки практически не слышно.
Построение описанной инфраструктуры, в течение почти полутора лет, привело к тому, что у нас накопилась обширная база знаний по многим вопросам, связанным с виртуализацией рабочих мест и развития инфраструктуры небольших предприятий. Мы готовы участвовать в проектах связанных с внедрением подобных решений, консультированием, сопровождением.
Давайте обмениваться опытом, общаться и сотрудничать!