Некоторое время моей основной машиной для разработки был яблочный ноутбук. Оглядываясь на конференции, офисы и группы пользователей, я знаю, что я не одинок. Но я не очень часто запускаю код на своем Mac, конечно, не для работы. Я мог бы отредактировать код на своем Mac, но я выполняю его в виртуализированной среде Linux, максимально приближенной к рабочей среде, в которой он будет находиться. Этот пост в блоге является попыткой объяснить, почему это хорошая идея для большинство людей, которые разрабатывают на Mac (или Windows-машине) и используют другие. Это не зависит от языка. Возможно, вы работаете над небольшими веб-сайтами PHP или огромными приложениями Python, но вы все равно однажды столкнетесь с теми же проблемами.
Почему виртуализация хорошая идея?
Ошибки случаются, но их преждевременное обнаружение, даже до того, как они попали в ваш общий репозиторий исходного кода, делает их гораздо менее серьезной проблемой. Плохое обнаружение ошибок только после выхода живого релиза, когда они влияют на клиентов и стоят кому-то денег И если ваш выпуск занимает много времени после того, как работа была сделана, исправить их сложнее. Это лишь некоторые из причин, по которым мы все любим модульное тестирование и постоянную интеграцию.
Но если вы выполняете эти тесты для кода, выполняющегося на другом оборудовании, в другой операционной системе, с разными библиотеками низкого уровня или с другой версией веб-сервера или с другим сервером базы данных, то вы не поймете все проблемы. Если вы доведите это до крайности, тогда вы сможете избавиться от всех этих проблем, только предоставив каждому разработчику полный собственный производственный стек. Это, очевидно, невероятно дорого для чего-либо, кроме самой простой установки. Но устранение даже некоторых из этих проблем повышает вероятность того, что вы обнаружите ошибки на ранней стадии, и с меньшей вероятностью у вас будет ошибка, которую вы не сможете воссоздать локально. Таким образом, мы будем стремиться к производству как к 100% копии.
Вот реальный пример, нечувствительная к регистру файловая система. Возьмите подсказку терминала на вашем Mac и введите следующее в пустой каталог. Затем сделайте то же самое на типичной машине Linux. Все, что мы делаем, это используем touch для создания файла.
touch Test
touch test
ls
На Mac вы, вероятно, увидите:
Test
На вашей Linux-коробке у вас больше шансов получить:
Test
test
Какие? Макинтош рассматривал Test и test как означающие одно и то же. Это не позволит вам иметь файл с именем test и файл с именем Test в одном месте. Это без учета регистра. Но у машины Linux не было этой проблемы. Теперь представьте, что мы имеем дело не с пустыми файлами, которые называются test, но либо файлы, которые вы запускаете, код создает во время выполнения (возможно, файловый кеш или загруженный пользователем файл), либо, что еще интереснее, ваши файлы исходного кода. Допустим, у вас есть git на linux box в углу офиса, и кто-то проверяет два файла с linux-машины, называемые Pages_controller.rb и pages_controller.rb. Что происходит, когда вы получаете это для своего Mac? Я на самом деле не пробовал это, но это не закончится хорошо.А представьте, как отлаживать такого рода проблемы? Если вы думаете, что это все гипотетически, я знаю об этой маленькой причуде именно потому, что видел, как кто-то пытается исправить ошибку, связанную с этим.
Что, если ошибка возникла из-за того, что у вас была одна версия lib_xml на вашей локальной машине для разработки, а другая — на производстве. До этого момента вы могли даже не знать, что такое libxml или как он появился на вашем блестящем яблочном ноутбуке.
Сколько людей могут искренне сказать, что у них никогда не было ошибки, которую они могли бы воссоздать вживую, а не на своей машине разработки? Тот же код, другое поведение. Загрузка и данные часто играют роль в ошибках, подобных этому, но они могут быть изолированы, и тесты могут быть созданы по крайней мере в некоторых случаях. Быть прагматичным, к чему мы стремимся, — это не устранить все различия, а избавиться от тех, которые легко устранить.
Как я могу это сделать?
Инструменты виртуализации были громоздкими и дорогими и, как правило, не предназначались для потребителей. Я использовал как VMWare Fusion, так и VirtualBox на своем Mac, и даже по сравнению с тем, что было несколько лет назад, эти инструменты становятся все более простыми в использовании. И VirtualBox является бесплатным и открытым исходным кодом тоже. Кроме того, теперь у нас есть такие инструменты, как vagrant, которые я приведу здесь в качестве примера.
Бродяга для тех, кто еще не сталкивался с этим, описывает себя так:
Vagrant использует Oracle VirtualBox для динамического создания настраиваемых, легких и переносимых виртуальных машин.
На самом деле это инструмент для быстрого и безболезненного создания виртуальных машин на основе разумных конфигураций по умолчанию, а затем предоставление программных хуков для более сложной конфигурации. Например, у вас будет файл конфигурации, описывающий, какие порты вы хотите перенаправить, и вы можете использовать Chef для установки пакетов при первой загрузке виртуальной машины. После того, как он установлен, его так же легко использовать
vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
vagrant init lucid32
vagrant up
Первая строка загружает 32-битный образ диска Ubuntu, но вам нужно будет сделать это только один раз. Вы также найдете множество изображений для разных дистрибутивов. Следующие две строки создают и загружают новую виртуальную машину без головы. Вот и все.
vagrant ssh
Позволит вам сразу перейти к сеансу ssh с новой машиной, чтобы понять, что еще он может сделать, вот вывод справки:
Tasks:
vagrant box # Commands to manage system boxes
vagrant destroy # Destroy the environment, deleting the create...
vagrant halt # Halt the running VMs in the environment
vagrant help [TASK] # Describe available tasks or one specific task
vagrant init [box_name] [box_url] # Initializes the current folder for Vagrant u...
vagrant package # Package a Vagrant environment for distribution
vagrant provision # Rerun the provisioning scripts on a running VM
vagrant reload # Reload the environment, halting it then rest...
vagrant resume # Resume a suspended Vagrant environment.
vagrant ssh # SSH into the currently running Vagrant envir...
vagrant ssh_config # outputs .ssh/config valid syntax for connect...
vagrant status # Shows the status of the current Vagrant envi...
vagrant suspend # Suspend a running Vagrant environment.
vagrant up # Creates the Vagrant environment
vagrant version # Prints the Vagrant version information
Я оставлю это, поскольку этот пост — больше напыщенная речь, чем учебник, но я мог бы написать больше об использовании vagrant позже. Но пока читайте веб-сайт для довольно простого прохождения. И не стоит расстраиваться из-за того, что он написан на Ruby или что в примере показано приложение Rails, это отличный инструмент на любом языке, который вы собираетесь использовать на виртуальной машине.
Аргументы против
Я вижу, что слишком немногие разработчики делают это для того, чтобы из-за недостатка осведомленности. Многие разработчики, которые этого не делают, могут использовать локальные виртуальные машины, например, для кросс-браузерного тестирования. Вот несколько жалоб, которые я услышал, и что я думаю, ответ.
скорость
Если что-то идет медленно и у вас нет столько оперативной памяти, сколько вы можете установить на свою машину, сделайте это, прежде чем жаловаться на что-либо. Запуск нескольких дополнительных операционных систем внутри вашей основной операционной системы, очевидно, будет интенсивным, так что не экономьте на своих инструментах. Также настройки по умолчанию при настройке новых виртуальных машин в VirtualBox или VMWare Fusion, по крайней мере, весьма минимальны. Попробуйте увеличить объем оперативной памяти, которую вы им позволяете, или дать им доступ к большему количеству процессов. Я могу искренне сказать, что однажды у меня была проблема с этим, и реальным решением было изменение кода, а не исключение всех преимуществ виртуализации. Если вы занимаетесь какой-то сумасшедшей обработкой видео в реальном времени, ваш пробег будет разным, но в любом случае вам, возможно, понадобится более быстрая машина.
Более низкий уровень, к которому вы привыкли
Как разработчику PHP / Ruby / Python, почему я должен заботиться об Apache? Я просто пишу код!
Этот аргумент меня просто раздражает, но я знаю, что отчасти это я. Мне нужно знать, как все эти элементы работают и сочетаются друг с другом, и я согласен, что не все это делают или действительно должны все понимать. Но кто-то в вашей команде, вероятно, хочет знать это и, главное, быть в состоянии рассказать другим, как им следует поступать. Разработчики довольно часто устанавливают среду разработки для чистого разработчика или дизайнера, чтобы они могли вносить изменения и фиксировать CSS или новые шаблоны. Это ничем не отличается. Большинству дизайнеров не нужно подробно знать о программной среде, им проще обратиться к эксперту по предметной области. Если разработчик просто хочет написать код, он также должен обратиться к тому, кто знает о более низком уровне, когда речь заходит об их среде разработки.
Что-то еще, чтобы настроить
Этот аргумент имеет некоторые достоинства. Мы все заняты и подбираем инструменты, чтобы настроить что-то для вас, а ваша команда отнимает много времени. И я думаю, что до недавнего времени время и необходимые знания были настоящим барьером. Лично у меня, как правило, было немного проблем, но затем я достаточно знаком с администрированием Linux, чтобы избежать некоторых распространенных ошибок. Но проблемы с настройкой переадресации портов или общих папок могут быть довольно раздражающими, если вы хотите поработать над неотложной ошибкой или блестящей новой функцией. Но с такими инструментами, как vagrant, обеспечивающими простой интерфейс для этого, я думаю, что это уже в прошлом.
Разработчики рабочих станций должны быть персональными
Я согласен до определенного момента здесь. Обсуждение стандартизации отдельных инструментов разработчика превращается в священные войны пламени из-за того, что все должны использовать некоторые IDE, Vim или Emacs (ответ: Vim). Это бессмысленно. Файловые менеджеры, утилиты, тестовые редакторы, стили терминалов, операционная система хоста. Все это и многое другое должны решать индивидуальные разработчики. Но так же, как вы обычно не позволяете отдельным разработчикам использовать новый язык, который никто не знает, по крайней мере, без некоторого обсуждения, почему это будет отличаться для веб-сервера или операционной системы, на которой вы будете запускать этот код в рабочей среде? , В большинстве случаев разработчики не принимают серьезное решение использовать другую версию. Скорее всего, они пойдут по пути наименьшего сопротивления и последуют инструкциям или просто используют менеджер пакетов. Скорее всего, если вы зададите вопрос «какую конкретную версию Apache вы используете на своей машине для разработки», они не будут знать ответ.
Выводы
Я даже не вдавался в некоторые другие преимущества виртуализации здесь. Возможность делать снимок вашей среды в любой момент и откатывать всю виртуальную машину, как вы делаете, ваш код очень удобен. Так же как и возможность создавать виртуальные машины, которыми вы можете поделиться с другими членами вашей команды. Больше не нужно новым сотрудникам тратить первую неделю на установку зависимостей и просто запуск кода.
Я, конечно, не единственный человек, делающий это, и это не новая идея. Но это никогда не было проще или дешевле. А по мере того, как все больше переходят к производственным средам виртуализации или облачных вычислений, делиться передовым опытом с вашими дружественными системными администраторами становится еще проще.
После некоторого перерыва я прокомментировал комментарии в этом блоге, и я хотел бы услышать, что люди думают, положительные и отрицательные.