Wdrażanie wielu ról sieciowych i ról roboczych w usłudze pojedynczego chmury Azure.

Question

To może nie być nowe, ale mam nadzieję, że ktoś może wprowadzić mnie na właściwe tory, ponieważ jest nieco mylący podczas wdrażania na lazur. Jestem w trakcie planowania wdrożenia na platformie Azure. To co mam

1. publiczna skierowana aplikacja ASP.Net MVC (web-rola) + WCF usługi (web-rola), aby były dostępne tylko dla tej aplikacji asp.net + WCF Service (pracownik-rola) ponownie dostępne dla 1. nad kolejką wiadomości
2. Niestandardowa aplikacja STS, tj. aplikacja ASP.NET MVC (rola sieci) działająca jako dostawca-Id (dla 1. będącego stroną odsyłającą) + usługa WCF (rola sieci) dla udostępniać niektóre funkcje STS do RP, takie jak 1.
3. SQL Azure: dostęp przez 1 i 2 Uwaga: 1. w końcu staną się portalem z wieloma usługami wcf hostowanymi na stronach internetowych i rolach roboczy dla obu wewnętrznych i dostęp zewnętrzny.

Moje pytanie brzmi, czy 1. ma być aplikacja dostępna publicznie, a 2. dla Federacji bezpieczeństwa (wewnętrzna), jak powinienem zaplanować swoje wdrożenie na lazurach mając na uwadze 1. będzie wymagać późniejszego skalowania wraz z dwoma usługami wcf? Czy publikuję w jednej usłudze chmurowej lub w jaki sposób? Mam świadomość, że Usługa Przetwarzania w Chmurze jest logicznym kontenerem dla ról w sieci WWW/pracownikach. Ale kiedy masz 2 podeszwy internetowe, tak jak w tym przypadku, oba aplikacje asp.net, który z nich staje się domyślny?

Pozdrawiam Satish

Answer 1

wdrożyć wiele ról sieci pod tym samym przykład cloud rzucić okiem na to: Best practice for Deployment of Web site into a cloud service

Wiele ról pracownika będzie trudniejsze do wdrożenia: Run multiple WorkerRoles per instance

Answer 2

By domyślnie wszystkie role sieciowe w rozwiązaniu są publiczne. Możesz to zmienić, wchodząc w definicję usługi i usuwając punkty końcowe HTTP, jeśli chcesz; możesz również zdefiniować wewnętrzne punkty końcowe HTTP, które będą dostępne tylko dla usług w chmurze, nic nie będzie dostępne dla systemu równoważenia obciążenia. Zaletą posiadania wszystkich ról sieciowych w tym samym projekcie jest to, że łatwo jest dynamicznie sprawdzać RoleEnvironment i każdą rolę w sieci - innymi słowy, wszystkie role w rozwiązaniu są "świadome" innych ról i dostępnych portów. Łatwo też wdrożyć jedną paczkę.

Wszystkie role mają tę samą nazwę DNS (.cloudapp.net) (można jednak użyć nagłówków hosta do rozróżnienia), ale zazwyczaj są udostępniane za pomocą innych portów za pośrednictwem modułu równoważenia obciążenia w usłudze .cloudapp.net. Możesz to zobaczyć, gdy usługa działa w chmurze, w portalu znajdują się odsyłacze wskazujące każdą rolę, która ma publiczny punkt końcowy HTTP, który określa port. Ten, który jest portem 80 (zdefiniowanym przez zewnętrzny punkt końcowy HTTP), jest "domyślną" stroną.

Można również tworzyć wiele projektów w chmurze i wdrażać je osobno. W takim przypadku każdy będzie miał własną nazwę DNS, a każdy z nich będzie zarządzany osobno. To, czy jest to dobre, czy nie, zależy od tego, jak ściśle powiązane są aplikacje i czy zazwyczaj wdrażasz całe rozwiązanie, czy tylko aktualizujesz poszczególne role w tym rozwiązaniu. Ale nie ma różnicy kosztów ani skalowalności.

Jeśli zamierzasz często przenosić tylko jedną z ról, wolałbym je usunąć.