2011-07-16 23 views
6

Estoy considerando mover una aplicación existente a Azure. Tendrá una aplicación MVC en una función web y algunos servicios WCF en otra función web. Cuando esté en vivo, el sitio vivirá en http://www.myapp.com y los servicios estarán en http://api.myapp.com con la aplicación MVC configurada para apuntar a los servicios al http://api.myapp.com.Azure: descubrimiento dinámico de la URL del rol web del servicio en la etapa

El problema es cuando se empuja la aplicación a la configuración de "escenario" en Azure. Según tengo entendido, cada inserción en el escenario hará que los servicios vivan en una nueva url (algo aleatorio como http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). En este caso, ¿cuál es la mejor forma para que mi aplicación MVC descubra la url de los servicios?

Una opción sería configurar una entrada dns como http://stage.api.myapp.com y actualizar mi registro DNS CNAME para apuntar a la nueva url de preparación de Azure cada vez que presiono para el escenario, pero ... asco.

Otra opción sería presionar al escenario, obtener las nuevas direcciones URL para los servicios, RDC a cada instancia de la función MVC y actualizar manualmente las configuraciones. También asco.

¿Hay una manera simple de hacer esto? Sé que podría automatizar algunos de los pasos anteriores con algo como PowerShell, pero realmente espero que haya algo incorporado en el marco de Azure que lo haga más fácil. Parece que sería un escenario tan estándar.

Respuesta

6

La única forma de descubrir dinámicamente lo que será la URL de transición es hacer que la instancia compruebe su propio deploymentID. Supongo que el sitio web de MVC y el servicio WCF están en la misma implementación. Si comprueba RoleEnvironment.DeploymentID, encontrará que esto corresponde exactamente a la URL 'aleatoria' utilizada en la organización (es decir, http: // [deploymentID] .cloudapp.net).

Siempre que esté creando dinámicamente ChannelFactory en el lado del cliente, debería poder tomar su propio DeploymentID y encontrar el URL de ensayo.

Por supuesto, esto solo es útil cuando se despliega en etapas. ¿Por qué no usas simplemente el espacio de Producción? Ese nombre es estable y puede confiar en él o en el CNAME (más probable) que establezca para él. Siempre puede tener múltiples servicios alojados (dev, QA, prod, etc.) y simplemente use la ranura de producción en ellos.

+2

¡Esto no es una buena práctica! Para la comunicación entre roles, necesita usar puntos finales que están ahí solo para este propósito. Perdón por haber votado negativamente, pero realmente siento que es importante no hacer esto de la manera que estás sugiriendo. –

+2

Siento que se ha perdido la pregunta. Fue cómo descubrir dinámicamente la ranura de puesta a escena. Solo hay 2 métodos (el que describí y que usa mgmt API), que es todo lo que respondí. No estoy en desacuerdo con que usar interrole comm sea una buena idea si es posible, pero a veces las personas realmente necesitan usar la dirección de Load Balancer y él no aclaró. – dunnry

+0

Entiendo lo que quiere decir, pero a veces la respuesta no es la forma correcta de hacer las cosas.Lo que quiero decir es que, si te pregunto cómo unir el procesador y la placa base, ¿me lo dirías o preferirías decirme que puedo ponerlo allí y fijarlo con el mecanismo ya en su lugar ... DeploymentId no debe ser "abusado" y realmente siento que la respuesta (¡aunque correcta!) No debe usarse a menos que sepa absolutamente por qué y qué está haciendo y haya utilizado todas las demás opciones. Además, si está utilizando el punto final externo, ¡paga por el tráfico! –

4

¡No hagas lo que @dunnry está sugiriendo! Azure tiene un concepto realmente bueno de los puntos finales que resuelven su problema. Y tiene acceso a esta información de su clase RoleEnvironment.

Puedes echar un vistazo a la publicación de mi blog en how to get the endpoint from the client. La parte clave es crear un punto final interno en el que tu servicio WCF está escuchando. Sin embargo, tenga en cuenta que no necesita necesariamente un nuevo rol para esto, y personalmente, prefiero alojarlo en IIS junto con la función web original. & tiene dos de estos roles para una mayor confiabilidad.

De esta manera, no importa cuál es la implementación, porque la comunicación del servicio tendrá lugar dentro de esa implementación, ya sea en etapas o producción.

+0

Nota: para api.myapp.com, debe configurar un sitio de host y hacer algo simillar para www.myapp.com. Pero aún pueden ser parte del mismo despliegue. –

+0

Gracias por el enlace. Desafortunadamente, en un esfuerzo por mantener mi pregunta simple, parece que dejé fuera una información clave :(. En realidad, los servicios están siendo consumidos tanto por un sitio de MVC como por un proyecto de Silverlight. Creo que eso significa usar el El enfoque que sugieres no funcionará en mi caso. ¿O existe alguna manera de utilizar un enfoque similar con los servicios públicos? – herbrandson

+0

El cliente de Silverlight nunca tendrá el lujo de tener ni DeploymentID ni acceso a puntos finales internos. Entonces, para la comunicación interna, use lo que he escrito. Para el proyecto SL, decidiría en tiempo de compilación señalar un DNS de ensayo (donde el rol siempre responde) o un nombre DNS de producción (por ejemplo, api.myapp. net). No veo otra manera sin vincularlos usando otra cosa, por ejemplo, AppFabric. –

Cuestiones relacionadas