Заметки консультанта

Шамрай Александр Владимирович

Глава 17 — Обеспечение доступа к Team Foundation Server через Интернет

<< Назад

Область применения

  • Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
  • Microsoft Visual Studio Team System

Задачи

  • Изучить ключевые сценарии удаленного доступа и их применение.
  • Предоставить удаленный доступ через Интернет к своему Microsoft® Visual Studio® 2005 Team Foundation Server (TFS).
  • Повысить производительность удаленного доступа за счет использования Team Foundation Server Proxy.

Обзор

Данная глава объясняет, как обеспечить удаленный доступ к TFS через Интернет. Существует три возможных варианта предоставления удаленного доступа к TFS:

  • Через виртуальную частную сеть (virtual private network, VPN)
  • Через обратный прокси-сервер, такой как Microsoft Internet Security and Acceleration (ISA) Server.
  • Размещение TFS сервера во внешней сети.

До версии Service Pack 1 (SP1) TFS поддерживал только доступ через VPN. В TFS SP1 появляется поддержка Базовой аутентификации, что обеспечивает возможность, кроме VPN, использовать и внешнюю сеть, и обратный прокси-сервер.

Как использовать данную главу

Данная глава поможет настроить сервер TFS для удаленного доступа через Интернет. Чтобы использовать эту главу с максимальной пользой, следует:

  • Использовать список сценариев. Список сценариев поможет быстро определить, какой подход следует применить для обеспечения внешнего доступа через Интернет к серверу.
  • Использовать приведенные пошаговые руководства. Данная глава предлагает пошаговые руководства по установке и конфигурированию доступа с использованием сертификатов и Протокола защищенных соединений (Secure Sockets Layer, SSL), используемых с базовой и сжатой аутентификациями.
  • Использовать раздел «Повышение производительности удаленного доступа». В разделе «Повышение производительности удаленного доступа» приводятся методы сокращения объемов трафика, передаваемого по Интернет.

Ключевые стратегии

Ключевыми стратегиями предоставления удаленного доступа к серверу TFS являются:

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

Стандартные сценарии

  • Удаленный офис. Если поддерживаются удаленные пользователи с доступом через VPN, используется решение с VPN. Это самое простое из возможных решений с предельно понятной схемой безопасности, обеспечивающее удаленный доступ ко всем функциям TFS и позволяющее использовать TFS Proxy для повышения производительности.
  • Внешняя группа. Если поддерживаются удаленные пользователи, не имеющие доступа через VPN или доступа к домену, используется сценарий с обратным прокси-сервером. Это решение сложнее реализовать, но оно обеспечивает удаленным пользователям возможность доступа к внутреннему TFS без необходимости использования VPN.
  • Распределенное сообщество разработчиков. Если поддерживается сообщество удаленных пользователей, которые будут работать с предназначенным специально для них TFS, например, сайт для совместной разработки членами сообщества, используется внешняя сеть. Это решение обеспечивает наиболее глубокое разделение удаленных пользователей и внутренних сетевых ресурсов.

Использование соединения VPN

Ни рис. 17.1 показана архитектура предоставления TFS через VPN.

Рис. 17.1 Архитектура предоставления TFS через VPN

Рис. 17.1 Архитектура предоставления TFS через VPN

При таком подходе удаленная группа разработки использует прямое VPN-соединение с TFS во внутренней сети. Для TFS без SP1 или если требуется Встроенная аутентификация Windows (Integrated Windows authentication), использование VPN-соединения является единственно возможным вариантом. TFS создан для работы в условиях малой полосы пропускания, каким является доступ через VPN, и обеспечивает приемлемую производительность при данном сценарии.

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

  • Доступна вся функциональность TFS, включая TFS Proxy.
  • Этот подход поддерживает Встроенную аутентификацию Windows и позволяет использовать существующую инфраструктуру организации.
  • Если уже имеется установленная VPN, это самый простое из возможных решений.

Недостатки

  • Решение VPN может быть не настроено для используемой инфраструктуры или, не доступно для удаленных пользователей.

Более подробно о создании VPN рассказывается на сайте http://support.microsoft.com/kb/324747 .

Публикация TFS через обратный прокси-сервер

При таком подходе сервер TFS устанавливается во внутренней сети и предоставляется для доступа из внешней сети посредством функциональности Веб-публикации ISA Server. Удаленные пользователи организовывают доступ к TFS через SSL и используют Базовую аутентификацию. Такой сценарий возможен только для TFS SP1.

Сети без контроллера домена в пограничной сети

На рис. 17.2 представлена архитектура предоставления TFS посредством ISA с контроллером домена во внутренней сети.

Рис. 17.2 TFS через ISA, контроллер домена в архитектуре внутренней сети

Рис. 17.2 TFS через ISA, контроллер домена в архитектуре внутренней сети

Если в пограничной сети нет контроллера домена, в межсетевом экране можно открыть порт для обеспечения возможности соединения ISA Server с внутренним контроллером домена по протоколу Lightweight Directory Access Protocol (LDAP)7, в частности, для аутентификации внешних пользователей TFS.

Сети с контроллером домена в пограничной сети

На рис. 17.3 показана архитектура предоставления TFS через ISA, когда контроллер домена располагается в пограничной сети.

Рис. 17.3 TFS через ISA, архитектура с контроллером домена в пограничной сети

Рис. 17.3 TFS через ISA, архитектура с контроллером домена в пограничной сети

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

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

  • Обратные прокси-серверы, такие как ISA Server, осуществляют аутентификацию пользователей и контролируют трафик.
  • Удаленным пользователям нет необходимости осуществлять доступ к домену.
  • Удаленным пользователям нет необходимости осуществлять доступ к VPN.

Недостатки

  • TFS Proxy нельзя использовать на удаленной площадке.
  • Удаленные пользователи не могут добавлять пользователей в группы TFS.
  • Удаленные пользователи не могут добавлять группы Microsoft Active Directory® в папки системы контроля версий.
  • Удаленные пользователи не смогут запустить или управлять сборками удаленно.
  • Удаленные пользователи не могут создавать новые групповые проекты.
  • Удаленные пользователи не могут публиковать результаты тестирования на TFS.

Примечание: Базовая аутентификация всегда должна использоваться совместно с SSL. При базовой аутентификации удостоверения передаются в виде открытого текста. SSL используется для защиты этой информации.

Размещение TFS во внешней сети (сценарий установки на внешнем по отношению к организации сервере)

На рис. 17.4 представлена архитектура размещения TFS во внешней сети.

Рис. 17.4 Архитектура размещения TFS во внешней сети

Рис. 17.4 Архитектура размещения TFS во внешней сети


При таком подходе вся инфраструктура TFS – и уровень приложений, и уровень данных – размещается в пограничной сети, вне внутренней сети. Все соединения с TFS, как внешних, так и внутренних пользователей, осуществляются через Интернет. TFS может работать с или без контроллера домена (domain controller, DC). Если пограничная сеть не имеет доступа к DC, сервис Active Directory TFS не будет функционировать. Например, без DC невозможно добавление пользователей в группы TFS или добавление группы Active Directory в папки системы контроля версий. Этот сценарий возможен лишь для TFS SP1.

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

  • Внутренняя сеть полностью изолирована от пользователей TFS.
  • Удаленные пользователи не нуждаются в доступе к домену.

Недостатки

  • TFS Proxy не может использоваться на удаленной площадке.
  • Удаленные пользователи не могут запускать или управлять сборками.
  • Удаленные пользователи не могут создавать новые групповые проекты.
  • Удаленные пользователи не могут публиковать результаты тестирований в TFS.
  • Внутренние пользователи должны соединяться с TFS, находящимся во внешней сети, через SSL, как и внешние пользователи.

Примечание: Базовая аутентификация всегда должна использоваться совместно с SSL. При базовой аутентификации удостоверения передаются в виде открытого текста. SSL используется для защиты этой информации.

Базовая аутентификация / SSL

Если для TFS SP1 требуется обеспечить поддержку сценария с использованием внешней сети или обратного прокси-сервера, необходимо конфигурировать IIS на уровне приложений TFS и тем самым активировать Базовую аутентификацию через SSL. При Базовой аутентификации регистрационные удостоверения передаются по Интернет в незащищенном формате Base64-кодирования. Для защиты удостоверений клиентов Базовая аутентификация должна применяться только для соединений Secure HTTP (HTTPS), которые используют SSL.

Чтобы соединение удаленных клиентов с TFS через SSL происходило с Базовой аутентификацией, тогда как локальные клиенты продолжали использовать Встроенную аутентификацию Windows, необходим фильтр Server API (ISAPI). Фильтр ISAPI выбирает клиентов, которые были конфигурированы как «external/Internet» (внешний/Интернет) и возвращает в качестве отклика 401, чтобы заставить этих клиентов использовать другие методы аутентификации, например, Базовую аутентификацию.

Дополнительные источники

  • Подробнее о том, как конфигурировать сервер для использования Базовой аутентификации и HTTPS, рассказывает статья «Walkthrough: Setting up Team Foundation Server to Require HTTPS and Secure Sockets Layer (SSL)» (По шагам: как настроить Team Foundation Server на использование HTTPS and Secure Sockets Layer (SSL)) по адресу http://msdn2.microsoft.com/en-us/library/aa833873(VS.80).aspx .
  • Как настраивать фильтр ISAPI подробно рассказывает статья «Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL) and an ISAPI Filter» (По шагам: как настроить Team Foundation Server с Secure Sockets Layer (SSL) и фильтром ISAPI) (.http://msdn2.microsoft.com/en-us/library/aa833872(VS.80).aspx ).
  • Больше информации о фильтрах ISAPI для TFS можно найти в сообщении «The TFS extranet ISAPI filter mechanics» (Принципы ISAPI-фильтра для работы TFS с внешними пользователями) блога Джеймса Маннинга (James Manning) по адресу http://blogs.msdn.com/jmanning/archive/2006/10/27/the-tfs-quot-extranet-quot-isapi-filter-mechanics.aspx .

Прокси-сервер Team Foundation

На рис. 17.5 показана архитектура, используемая с Team Foundation Server Proxy.

Рис. 17.5 Архитектура TFS Proxy

Рис. 17.5 Архитектура TFS Proxy

TFS Proxy не является обязательным элементом для обеспечения удаленного доступа, но может использоваться как кэш для файлов системы контроля версий. Чтобы повысить производительность удаленного доступа, можно установить TFS Proxy в организациях, которые соединяются с TFS через VPN. Производительность увеличится за счет кэширования файлов системы контроля версий на прокси-сервере удаленной организации. В любой момент, когда удаленному клиенту необходимо получить доступ к исходному коду, находящемуся в хранилище системы контроля версий, он будет посылать запрос TFS Proxy. Прокси-сервер возвратит локальную версию из своего кэша, если таковая имеется в наличии. Если необходимого кода нет в кэше, прокси пошлет запрос на удаленный сервер TFS. Таким образом, сокращается сетевой трафик и сокращается время отклика при работе с удаленной системой контроля версий.

Как повысить производительность прокси-сервера

Рассмотрим рекомендации по повышению производительности прокси-сервера:

  • Убедитесь, что кэширование активировано, и отслеживайте производительность кэша. Регулярно проверяйте счетчики производительности (устанавливаемые по умолчанию) и протоколы событий (для ошибок и предупреждений) на своем прокси-сервере. Обратите внимание, что TFS Proxy сохраняет статистику по производительности кэша в XML-файле ProxyStatistics.xml, и что интервал сохранения статистических данных можно изменить. Файл ProxyStatistics.xml располагается в папке App_Data каталога установки прокси-сервера.
  • Регулярно выполняйте плановый перенос самых последних файлов на прокси-сервер, таким образом, последние версии файлов гарантированно будут доступны в кэше прокси-сервера, и при последующих запросах к прокси-серверу клиенты будут получать именно эти файлы.
  • Если известно, что предполагается загрузка больших файлов через канал с малой полосой пропускания (< 3 мегабита в секунду [Mbps]), задайте соответствующее значение атрибуту executionTimeout (пауза между выполнениями) в файле Web.config (по умолчанию это значение – один час, <httpRuntime executionTimeout=»3600″/>).
  • Если прокси-сервер выводится из эксплуатации на длительный период времени, необходимо дезактивировать прокси на клиентах, чтобы предотвратить бессмысленные попытки установления соединения. По умолчанию попытки установления соединения повторяются каждые пять минут.
  • Рассмотрите возможность использования сокрытия рабочего пространства с целью предотвращения просмотра и ненужной передачи файлов из определенных рабочих пространств. Это обеспечит сокрытие папок заданных рабочих пространств от просмотра, уменьшит нагрузку на канал передачи и сохранит локальное дисковое пространство за счет предотвращения копирования в локальное рабочее пространство папок и файлов, которые не нужны в настоящее время. Хотя в своем рабочем пространстве можно скрыть существующее отображение папки, лучше специально для сокрытия создать новое отображение папки.

Более подробные рекомендации по оптимизации производительности можно найти в разделах «Распределенная / удаленная разработка» и «Рекомендации: рекомендации по работе с системой контроля версий» данного руководства.

Зеркальные учетные записи

TFS Proxy поддерживается в удаленных организациях только через VPN-соединение. Однако если TFS был развернут для небольшой удаленной группы, которой необходим TFS Proxy, с использованием внешней сети или обратного прокси-сервера, для работы с прокси-сервисом можно использовать зеркальные учетные записи.

Для работы с прокси можно использовать учетные записи рабочих групп, в которых для TFS, TFS Proxy и всех остальных удаленных клиентских компьютеров используются одни и те же имена пользователя и пароли. Тот факт, что для всех пользователей должно сохраняться строгое соответствие имени пользователя/пароля в трех разных местах, увеличивает
временные затраты на администрирование и ограничивает применимость этого метода только для небольших удаленных групп.

Примечание: TFS 2008 позволяет выполнять аутентификацию пользователей на прокси VC с использованием их регистрационных удостоверений. Это делает применение учетной записи рабочей группы для прокси-сервиса VC привлекательным вариантом в средах, где невозможно использование VPN-соединения.

Дополнительные источники

  • Подробнее о Proxy рассказывает статья «Team Foundation Server Proxy and Source Control» (Team Foundation Server Proxy и система контроля версий) по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx .
  • Более подробно о работе с TFS Proxy рассказывается в статье «Managing Remote Connections to TFS Proxy» (Управление удаленными соединениями с TFS Proxy) (http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx ).
  • О поиске и устранении неисправностей TFS Proxy подробно рассказывается в статье «Troubleshooting TFS Server Proxy» (Поиск и устранение неисправностей TFS Server Proxy) по адресу http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx .

Удаленный сервер сборки

На рис. 17.6 показана архитектура использования удаленного сервера сборки.

Рис. 17.6 Архитектура с удаленным сервером сборки

Рис. 17.6 Архитектура с удаленным сервером сборки

Чтобы еще больше повысить производительность обмена информацией с удаленной группой, можно настроить сервер сборки в удаленной организации. Если там установлен TFS Proxy, он будет вести себя, как обычный клиент системы контроля версий, и получать исходный код от прокси-сервера перед каждой сборкой. Удаленный сервер сборки обладает следующими преимуществами:

  • Сборки удаленной группы выполняются на сервере сборки этой группы и не оказывают влияния на нагрузку внутреннего сервера сборки.
  • Удаленная группа получает двоичные файлы с удаленного сервера сборки без необходимости передачи двоичных файлов по сети.

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

Примечание: Обмен информацией между уровнем приложений и сервером сборки происходит через порт 9191. Если используется удаленный сервер сборки, необходимо настроить межсетевой экран так, чтобы уровень приложений мог соединяться через этот порт.

Заключение

Для TFS без SP1 удаленный доступ обеспечивается за счет использования VPN. При работе с TFS SP1 можно разместить TFS во внешней сети и использовать Базовую аутентификацию через SSL или можно предоставить доступ через обратный прокси-сервер. Если требуется увеличить производительность удаленного доступа, особенно в сценарии с использованием VPN, можно установить и конфигурировать TFS Proxy, который будет удаленно кэшировать файлы системы контроля версий.

Дополнительные источники

<< Назад

Реклама
 
%d такие блоггеры, как: