Блог

Мы используем облачные службы Windows Azure для размещения нашего приложения. Одной из замечательных особенностей Windows Azure является модель Production / Staging. Клиенты вашего приложения могут быть перенаправлены на ваш рабочий сервер, в то время как вы можете протестировать свой новый код, запущенный на промежуточном сервере. Например, вы можете настроить Azure так, чтобы рабочий сервер указывался наhttp://www.coolapp.com при назначении промежуточного сервера для того же приложения примерно так:http://7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net .

Физически оба этих сервера общедоступны. Если бы вы знали зашифрованный URL промежуточного сервера, вы могли бы перейти к приложению так же легко, как и к www.coolapp.com . Однако наличие GUID в URL-адресе делает практически невозможным для кого-либо его угадывание, что делает промежуточный сервер «частным». Это предоставляет разработчикам приложения удобный механизм для развертывания и тестирования новых компонентов на промежуточном сервере перед их публикацией. Как только они убедятся, что все выглядит хорошо, щелчком переключателя они меняют местами два сервера, превращая промежуточный сервер в производственный и наоборот.

Эта модель создает для нас небольшую проблему в отношении интеграции Facebook. Чтобы иметь возможность интегрировать плагины Facebook, вы должны зарегистрировать свое приложение с их помощью. Затем FB выдаст ключи AppID и AppSecret. Эти ключи привязаны к URL вашего приложения. Итак, для того, чтобы мое приложение работало с плагинами FB, мне нужно получить один набор ключей, привязанный к 7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net и другой набор, который привязан к www.coolapp.com .

Когда я читаю о Windows Azure, они действительно призывают разработчиков одинаково относиться к промежуточным серверам и производственным серверам. Единственной разницей между ними должен быть URL. Другими словами, Azure не рекомендует основывать логику вашего приложения на том, на каком сервере выполняется код, поскольку Azure не имеет встроенных знаний об этом. Промежуточный сервер против производственного — это просто удобная «абстракция», если хотите. Я думаю, вы видите проблему здесь. В нашем примере выше я должен использовать один набор ключей, выданных FB, по сравнению с другим, в зависимости от того, по какому URL (производственному или промежуточному) запущено мое приложение. Я предполагаю, что я не первый, кто сталкивается с этой проблемой. Каковы правильные способы решения этой проблемы? Один из очевидных способов — просмотреть свойство URL объекта запроса и таким образом разветвлять мою логику. Однако интуиция подсказывает мне, что это взлом. Есть еще идеи?

С уважением,

Archil

Механизмы, о которых я знаю, следующие:

• использование «production» в совершенно отдельной учетной записи службы для «тестирования» — это позволяет использовать «staging» в производственной службе в качестве области для «кандидатов на развертывание» и предоставляет отдельный чистый домен тестирования с неизменяющимся URL-адресом для более ранней работы «dev and test».
• использование разных файлов .cscfg для промежуточного и производственного использования — и будьте осторожны при обновлении этого файла .cscfg перед любым переключением в реальном времени.
• отслеживание входящего URL-адреса — как вы предлагаете

Лично я использую первый из этих методов — он прост и помогает предотвратить неприятные инциденты

Кроме того, один из методов, которые мы использовали для «удаления» Guid из промежуточного сервера, заключается в том, чтобы присвоить Guid CNAME действительно короткий TTL в DNS — это позволяет нам быстро и автоматически обновлять запись CNAME для промежуточного сервера при развертывании.