Enabling direct access to your Azure Workbench blockchain node
I have been doing some projects with customers around the Azure Blockchain Workbench. Since the start of its public preview last week we did a lot of experimentation and we worked on some tricks to ease development and use of the workbench. This is to share those aspects that I am writing this series of blog posts.
One of the main key value of the workbench is that it is completely interfaced with other Azure services. You will typically interact with the smart contract using the Web API (Gateway service API in the picture above), you can see/react on Blockchain events by either consulting the Azure SQL Database, the blob storage, or by monitoring the service bus or event grid. This wrapping of the blockchain data offers multiple advantage, such as easy integration with any other current standard technology or an out of the box authentication implementation (with Azure Active Directory authentication for the API, SQL DB credentials and access keys for Blobs/Service/Event Grid). However, there are situation where you very much would like to have a direct interaction with the blockchain node such as when writing/debugging smart contracts or simply to open up your nodes to sync with external ones.
When you finish deploying the Azure Blockchain Workbench, your node hosting the blockchain are contained in a Virtual Machine Scale sets (referred as VMSS later) with no public internet access (the name is typically of the form xx-xxxxxxx-reg1). To access them, you need to make a SSH hop to another node: Connect to the IP exposed on xxxxxxx-lb-public-ip, you will arrive to the set of machine that are performing the routings of the transactions to the SQL database , Blob Storage, Blockchain,… (the “consumers” in the image above) If you want to see all these components in action you can just issue the command docker ps and it will display all the containers handling the connections with the output mediums. This machine you are on currently is special as it is publicly exposed and in the Virtual Network of the VMSS hosting the Blockchain at the same time. To find it, you can just go to your resource group on Azure and search for the virtual network resource named xxxxx-vnet-reg1, on it you can find the URL of one of the node. Inside your SSH command line currently on the hop node, SSH into this internal IP. Here you are, you have a parity node running on this machine. You can install geth and run geth attach http://localhost to start interacting with your blockchain (or simply use the related parity command).
This is a fine solution, but maybe you would like to open up the port so that is publicly accessible, for example to attach a web3 console directly from your machine. No panic, we can do it and it’s quite easy. Go again to your Azure resource group and press on the plus, select Azure load balancer, give it a name and instantiate it. Now, select the resource and go on the health probes. Add two health probes with name lbProbe1/lbProbe2 one on TCP port 3000 and the other one on TCP 8545. Then go to the blade called Load Balancing rules and add two rules : LB-Rule1 with port 80 to backend port 3000 and select the health probe we created before (both TCP). Create another similar rule named LB-Rule2 with port 8545 to port 8545. As a last step go to the blade “backend pool” and add one linked with the VMSS name xx-xxxxxx-reg1. As last step, make sure to go to the Frontend IP Configuration blade, and add a new one linking to the address with name xxxxx-lbpip-reg1 (created at deployment time).
Now from your computer you can run the command geth attach http://<ip>:8545 and will have an interactive command line with your remote Workbench node! Moreover as a bonus, if you go to http://<your ip> you will have a publicly accessible ethstats page where you see some stats on your blockchain!
