Назад | Перейти на главную страницу

Инстанс Amazon EC2, жизнеспособные варианты и инструменты управления для среды разработки

Я фрилансер и планирую поработать с другими фрилансерами в ближайшее время. Поскольку я буду владельцем проекта (ов), я также хочу владеть средой разработки. Мы все будем работать в своих местах. Я подумывал об использовании сервиса Amazon EC2 с целью создания среды разработки и предоставления желаемого доступа другим участникам.

Имея в виду вышеизложенное, у меня есть несколько вопросов:

  1. Это вообще хорошая идея? Лучше ли создавать виртуальные машины и распространять их (физически) среди членов команды? Конечно, в этом случае я теряю контроль, и данные становятся уязвимыми.
  2. Должен ли я просто купить большой экземпляр, установить все необходимые инструменты, создать пользователей и предоставить им доступ в соответствии с ролью?
  3. Должен ли я просто купить экземпляр большого / сверхбольшого размера, создать виртуальные машины внутри экземпляра, по одной для каждой роли, и создать экземпляры для каждого пользователя? Я не уверен прямо сейчас, как будет работать доступ. Как можно получить прямой доступ к экземпляру виртуальной машины, работающему внутри экземпляра EC2.
  4. Есть инструменты, которые помогают в управлении экземплярами EC2 w.r.t. API EC2. Однако w.r.t. то, что я объяснил выше (особенно пункт 3), есть ли инструменты, которые могут помочь в управлении / мониторинге экземпляров и виртуальных машин внутри?

Может быть еще много сложностей, о которых я не могу думать сейчас. Будем признательны за вводные данные / указания, если кто-то уже прошел через это.

Вариант 2 требует, чтобы экземпляр был запущен и работал круглосуточно, без выходных (или, по крайней мере, во время объединения всех рабочих графиков). Для вас это может не иметь значения.

Не уверен, что вариант 3 возможен. Вы спрашиваете об установке Xen (или чего-то еще) внутри вашего экземпляра EC2, а затем о создании собственных «суб-виртуальных» машин?

Другой вариант - создать образ EC2 (AMI) с настроенной средой разработки, а затем позволить каждому разработчику запускать экземпляр этого AMI всякий раз, когда они хотят работать.

Преимущества:

  • Разработчики не соревнуются за вычислительные ресурсы (например, ЦП) на общей машине. Для вас это может не иметь значения.
  • Вы можете изменить образ (например, обновить операционную систему) и выпустить новую «версию» без простоев для всех разработчиков.
  • Возможная экономия, поскольку вам не нужен экземпляр, работающий круглосуточно и без выходных.

Недостатки:

  • Потенциал вырос стоимость, так как у вас может быть 5 запущенных экземпляров (т.е. 5 разработчиков работают одновременно) вместо 1.
  • Требует, чтобы каждый разработчик имел доступ к учетной записи AWS.

Если вы считаете, что это подходит вам, то проблему с аккаунтом AWS можно решить несколькими способами:

  • Каждый разработчик использует вашу учетную запись AWS. Это самый простой вариант, но он требует, чтобы вы им доверяли.
  • Каждый разработчик создает свою учетную запись и отправляет вам счет. Это вызывает больше «бумажной работы», но позволяет отклонять счета, если вы считаете, что разработчик не является законным.
  • Каждый разработчик создает свою учетную запись, а вы используете Консолидированный биллинг AWS платить им всем с помощью одной и той же кредитной карты.

я верить вы можете предоставить доступ к AMI для запуска без необходимости предоставления человеку root доступ после запуска и запуска экземпляра. Но вам стоит еще раз проверить это, поскольку похоже, что вы беспокоитесь о безопасности.

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