Quantcast
Channel: Alexandre Brisebois ☁ » Roles
Viewing all articles
Browse latest Browse all 24

Configuring Internal Endpoints on #Azure Cloud Services

$
0
0

InternalEndpoint

Configuring Internal Endpoints

There are many scenarios where Internal Endpoints make sense. Imagine a web application that needs to communicate with a middle tier. The communication between both Cloud Services does not need to leave Microsoft Azure networks. The diagram above depicts a scenario where a Web Role has access to a middle tier Cloud Service without going through the public Internet.

Role instances running in a Cloud Service on Microsoft Azure communicate through internal and external connections that vary depending on the type of communication that is needed. An internal endpoint can connect by using a protocol of HTTP, TCP or UDP.

The configuration of an Internal Endpoint is done through the Service Definition. Below is the template used to describe what can be done in terms of Endpoint configurations. 

Service Definition Endpoint Template

<Endpoints>
  <InputEndpoint certificate="<certificate-name>" ignoreRoleInstanceStatus="[true|false]" name="<input-endpoint-name>" protocol="[http|https|tcp|udp]" localPort="<port-number>" port="<port-number>" loadBalancerProbe=”<load-balancer-probe-name>” />
  <InternalEndpoint name="<internal-endpoint-name>" protocol="[http|tcp|udp|any]" port="<port-number>">
     <FixedPort port="<port-number>"/>
     <FixedPortRange min="<minium-port-number>" max="<maximum-port-number>"/>
  </InternalEndpoint>
  <InstanceInputEndpoint name="<instance-input-endpoint-name>" localPort="<port-number>" protocol="[udp|tcp]">
     <AllocatePublicPortFrom>
        <FixedPortRange min="<minium-port-number>" max="<maximum-port-number>"/>
     </AllocatePublicPortFrom>
  </InstanceInputEndpoint>
</Endpoints>

The Endpoints Element

Describes the collection of input (external), internal, and instance input endpoints for a role. This element is the parent of the InputEndpoint, InternalEndpoint, and InstanceInputEndpoint elements.

Input and Internal endpoints are allocated separately. A service can have a total of 25 input, internal, and instance input endpoints which can be allocated across the 25 roles allowed in a service. For example, if have 5 roles you can allocate 5 input endpoints per role or you can allocate 25 input endpoints to a single role or you can allocate 1 input endpoint each to 25 roles.

Sample ServiceDefinition

The following sample defines an Internal Endpoint names TcpListener which opens ports between 1000 and 2000.

<?xml version="1.0" encoding="utf-16"?>
<ServiceDefinition xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="briseboisDemo3" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="Compute">
    <Startup>
      <Task commandLine="setup_worker.cmd &gt; log.txt" executionContext="elevated">
        <Environment>
          <Variable name="EMULATED">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
          </Variable>
          <Variable name="RUNTIMEID" value="" />
          <Variable name="RUNTIMEURL" value="" />
        </Environment>
      </Task>
      <Task commandLine=".\startup.cmd &gt; startup_log.txt" executionContext="elevated" />
    </Startup>
    <Endpoints>
      <InternalEndpoint name="TcpListener" protocol="tcp">
        <FixedPortRange min="1000" max="2000" />
      </InternalEndpoint>
    </Endpoints>
    <Runtime>
      <Environment>
        <Variable name="EMULATED">
          <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
        </Variable>
      </Environment>
      <EntryPoint>
        <ProgramEntryPoint commandLine="worker.cmd" setReadyOnProcessStart="true" />
      </EntryPoint>
    </Runtime>
  </WorkerRole>
</ServiceDefinition>

Deploying the Cloud Service

There is nothing different about deploying a Cloud Service that exposes Internal Endpoints. Using your tool of preference, create a new Cloud Service package and deploy it to Microsoft Azure.

Using PowerShell to package the Cloud Service requires you to navigate to the Cloud Service directory and execute the Save-AzureServiceProjectPackage command. This will produce a cloud_package.cspkg package file.

To deploy Azure Cloud Services, I usually use PowerShell. This is an example of what you may write yourself.

New-AzureDeployment `
                -Package 'C:\\cloud_package.cspkg' `
                -Configuration 'C:\\ServiceConfiguration.Cloud.cscfg' `
                -Slot Production `
                -Label 'Compute-2015-02-17' `
                -ServiceName  'DemoCloudService' `
                -Name 'DemoCloudService' `
                -Verbose

Resources


Filed under: Microsoft Azure Tagged: Cloud Services, Configuration, Microsoft Azure, Port, PowerShell, Roles, Virtual Machine, Virtual Network, VNet, Web Role, Worker Role, XML

Viewing all articles
Browse latest Browse all 24

Trending Articles