Во второй части я обсуждал, как создать задачу запуска для запуска тестов во время запуска приложения. Но что, если что-то пойдет не так, и ваш тестовый вывод содержит кучу сбоев или вывод не генерируется? Если исправление очевидно, внесение необходимых изменений и повторное развертывание является очевидным путем, но если исправление неочевидно, вам следует рассмотреть возможность использования удаленного рабочего стола для подключения к развернутому приложению и устранения неполадок.
Удаленный рабочий стол
Удаленный рабочий стол в Windows Azure позволяет подключаться к конкретному экземпляру приложения и получать доступ к рабочему столу Windows для виртуальной машины, на которой размещен экземпляр приложения. К сожалению, в настоящее время это работает только от клиентов Windows. Несмотря на то, что Microsoft предоставляет приложение для удаленного рабочего стола для OS X, оно не может успешно подключиться с помощью файла .rdp, созданного Windows Azure.
Настройка для удаленного рабочего стола
Удаленный рабочий стол не включен по умолчанию, поэтому для его включения необходимо выполнить несколько шагов. Специально генерировать сертификат, устанавливать его в Windows, шифровать пароль для входа в систему для сеанса удаленного рабочего стола и добавлять XML в файлы ServiceDefition и ServiceConfiguration.
Создать сертификат
Я использовал OpenSSL для создания сертификата, но вы также можете использовать утилиту MakeCert. Для OpenSSL я использовал следующие команды:
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout RDPcert.pem -out RDPcert.pem openssl pkcs12 -export -out RDPcert.pfx -in RDPcert.pem -name "My Certificate"
Первая команда создаст файл .pem, а вторая — файл .pfx на основе файла .pem.
Установить сертификат
Далее нам нужно установить файл .pfx на клиенте Windows. К счастью, это так же просто, как найти файл и дважды щелкнуть по нему. Это запустит мастер установки сертификата, и вы можете просто нажать кнопку «Далее» до конца, принимая значения по умолчанию. Это загрузит его в личный магазин для вашей текущей учетной записи пользователя, где мы и хотим.
Чтобы получить файл в Windows Azure, нам нужно создать размещенную службу, но не развертывать в ней что-либо. Я использовал портал управления Windows Azure для этого:
- Войдите на портал управления, используя вашу подписку Windows Azure.
-
Выберите Hosted Services, Storage Accounts & CDN , а затем выберите Hosted Services .
- Либо выберите существующую размещенную службу, либо создайте новую. Если вы создаете новый, обязательно выберите Не развертывать . Это создаст размещенный сервис без необходимости развертывания приложения к нему.
-
Под размещенной службой выберите папку « Сертификаты », а затем щелкните значок « Добавить сертификат» на ленте. Это предложит вам загрузить файл .pfx, который мы создали ранее.
Вот и все. Все, что развернуто в этой размещенной службе, может использовать этот сертификат для сеанса удаленного рабочего стола.
Конфигурационные файлы
Наконец, нам нужно обновить файлы конфигурации в нашем проекте, чтобы включить удаленный рабочий стол для приложения. Изменения в ServiceDefinition.csdef довольно просты, это просто добавление раздела внутри элемента. Это должно выглядеть примерно так:
<WorkerRole name="WorkerRole">
<Imports>
<Import moduleName="RemoteForwarder" />
<Import moduleName="RemoteAccess" />
</Imports>
ServiceConfiguration.cscfg немного сложнее, и нам нужно использовать инструмент из [Windows Azure SDK] для шифрования пароля для сеанса удаленного рабочего стола. Вот файл ServiceConfiguration.cscfg со всеми записями, необходимыми для удаленного рабочего стола:
<?xml version="1.0"?>
<ServiceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" serviceName="blahblahsporf" osFamily="2" osVersion="*" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="WorkerRole">
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="username" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="encrypted password" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2013-02-22T13:34:31.8080460-05:00" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
</ConfigurationSettings>
<Instances count="2" />
<Certificates>
<Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="cert thumbprint" thumbprintAlgorithm="sha1" />
</Certificates> </Role> </ServiceConfiguration>
Несколько вещей, чтобы отметить здесь:
-
Имя пользователя, которое будет использоваться для входа в сеанс удаленного рабочего стола, указывается в записи Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername.
-
Доступ к удаленному рабочему столу истекает в день, указанный в записи Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration. Как правило, хорошей идеей будет установить дату окончания срока действия как можно скорее, чтобы предотвратить несанкционированный доступ.
-
Запись раздела Сертификаты для Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption указывает отпечаток сертификата, который мы загрузили в Windows Azure и использовали для шифрования пароля.
Теперь нам нужно заполнить несколько вещей, начиная с зашифрованного пароля. Команду csencrypt можно использовать для генерации зашифрованного пароля, но для ее запуска нам необходимо знать отпечаток сертификата. К счастью, это видно на портале управления Windows Azure, выбрав сертификат, который мы загрузили ранее.
Идите дальше и введите отпечаток в настройке Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption, а затем мы будем использовать csencrypt для шифрования пароля.
Csencrypt устанавливается как часть Windows Azure SDK и обычно находится в C: \ Program Files \ Windows Azure SDK \ v1.6 \ bin. Используйте следующие параметры при запуске:
csencrypt encrypt-password -Output password.txt -Thumbprint <certificate thumbprint>
Это предложит вам ввести и подтвердить пароль, который будет использоваться для подключения к удаленному рабочему столу, и сохранит его в файле password.txt. Есть также параметр, который вы можете использовать, чтобы скопировать его в буфер обмена, но если вы похожи на меня, вы постоянно копируете вещи в буфер обмена и перезаписываете то, что хотели сохранить.
Откройте файл password.txt в блокноте, скопируйте и вставьте содержимое в атрибут value элемента Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername.
Вот и все для конфигурации. Теперь осталось только упаковать файл с помощью pack.cmd, а затем развернуть его в Windows Azure.
соединительный
После запуска экземпляров перейдите на портал управления, выберите экземпляр и нажмите «Подключиться» на ленте. Это загрузит файл .rdp, используемый для подключения к этому сеансу. Открытие этого файла запустит клиент удаленного рабочего стола.
Первое, что вы увидите, это то, что издатель не может быть идентифицирован. Просто нажмите здесь, и при появлении запроса введите пароль, который вы использовали с командой csencrypt ранее. Далее будет сказано, что идентификационная информация удаленного компьютера не может быть идентифицирована, просто выберите Да здесь.
Вот и все, ваш подключен! Ну что теперь?
Навигация по удаленному сеансу
Чтобы работать с сеансом удаленного рабочего стола Windows Azure, необходимо понимать, где что находится. Вот общая схема и важные вещи, которые нужно знать для приложений Ruby:
- Приложение живет в e: \ Approot. Здесь находится каталог «WorkerRole» из развертывания, вместе с папкой «app», содержащей ваше приложение.
- Ruby устанавливается в каталог по адресу c: \ resources \ directory \ GUID.WorkerRole.ruby. Часть GUID имени каталога будет случайным, поэтому просто посмотрите на нее, когда вы заходите на рабочий стол.
- Руби не в пути для вашего сеанса рабочего стола. Так что найдите путь выше и добавьте его каталог bin в переменную окружения PATH, как один из первых шагов, посещающих рабочий стол.
- Также добавьте каталог \ lib \ ruby \ gems \ 1.9.1 \ bin в PATH, так как некоторые из исполняемых гемов устанавливаются там в Windows Azure.
После того, как вы настроили путь, вы можете просто открыть командную строку, внести изменения в свой код и перезапустить тесты, пока все не будет работать правильно. Затем исправьте его локально в вашем источнике, упакуйте и заново разверните.
Зачем исправлять это локально и повторно развертывать, если вы исправили это в облаке через удаленный рабочий стол? Потому что то, что вы делаете через удаленный рабочий стол, не сохраняется между перезапусками. Windows Azure использует загруженный вами пакет каждый раз при запуске нового экземпляра; это главный образ, насколько это касается. Поэтому вам нужно исправить это мастер-изображение и повторно загрузить его, чтобы навсегда применить все внесенные вами изменения.
Резюме
Так что это не совсем SSH, но использование удаленного рабочего стола для подключения к вашему размещенному приложению позволяет вносить изменения и запускать тесты вживую без необходимости создавать и повторно развертывать изменения. Однако важно помнить, что любые сделанные вами изменения не сохраняются, поэтому вам нужно будет реализовать их локально, перестроить пакет и заново развернуть, чтобы сделать его постоянным.