with Template Deployment Walk-through There are plenty of guides out there on how to create , , and . Ark Nodes secure your node compilations of these with Ark Stats Rather than go through these other tasks one-by-one, which have been detailed by professionals in the links above, I want to put emphasis on the servers are hosted. WHERE Most guides have you use a cheap DigitalOcean droplet, or some other $5 server. While economical, it’s certainly not meeting minimum Ark requirements at that point. By shifting to the use of Azure, you can make the VMs Highly Available, Scalable, and easily replicate-able via templates from the web-portal. There are also PowerShell automation capabilities by using this platform. **We will do the following:**Create an Azure Portal / Resource Manager logonDeploy our first virtual machine — Create a new “Resource Group” — Configure the Azure Firewall (“Network Security Group”)Use the first virtual machine to create a templateDeploy another Ark Node VM via this template, and join to an “Availability Set” with the first VM **Minimum requirements for running an Ark node, per Ark.io documentation:**Operating System: Ubuntu 16.04CPU: 1 core (More is better)RAM: 4GB (More is better)Disk: 20GB — SSD recommended Some quick Azure breakdown on sizing near these requirements can be found at: https://azure.microsoft.com/en-us/pricing/calculator/ We’re going to Login @ — Use a credit card for a trial if desired for the creation of an account. There are also Developer Program Benefits of $150 per month if you have an existing MSDN account. Let’s get started with the basics. HTTPS://portal.azure.com Once logged into your Azure Resource Manager Dashboard, click “+ New” and it will open a ‘Blade’ of options. — We’re going to be using the ever-popular (Long-Term Servicing branch Virtual Machine) Ubuntu Server 16.04 LTS VM + New -> Search for Ubuntu 16.04 OR click on the quickstart tile Once you select / find the Ubuntu 16.04 LTS Virtual Machine, click on it and it will open up the creation steps. If you’re confident with SSH authentication, please feel free to do so with this virtual machine. If you’re not familiar and do not have a good grasp, you can read about it here: https://help.ubuntu.com/community/SSH/OpenSSH/Keys _Public key authentication is a much better solution than passwords for most people. In fact, if you don't mind leaving…_help.ubuntu.com SSH/OpenSSH/Keys - Community Help Wiki For ease of follow-ability, we’re going to stick with Password Based authentication. We will also be creating a new “Resource Group” which is a sort of Azure resource-container. All items related to each other, Ark in this instance, will be added to this Resource Group. In the future, it’ll be easy to find and manage all of these inter-related items we’re making. General Configuration Settings to Follow to note here, are the (SSD is default), the non-root username, as well as the . Here we are creating a brand-new . The location listed is where the Virtual Machines, storage, and virtual networking will be housed and can be managed from a single grouping. Important parts Disk type Resource Group Resource Group for all of our Ark Nodes, named ARK_RG1 Hit Next, and you’ll be required to pick a Machine Size (Basically how much do you want to spend vs. Resource allocations). You have a few options to meet the System Requirements, depending on how you want to proceed. A good rule of thumb is to start low, and ramp up the resources as needed. While it does require a reboot when you ‘Scale Up’, it is definitely more cost effective to start smaller. All pricing and availability for this guide is based on US South Central region for Azure (May vary between datacenters) I will be rolling out “B1MS Standard” sized VMs for the guide. If I join the node network, and my nodes begin to lag behind, I can easily “Scale up” to other VM performance levels by running a quick few clicks, and a reboot. Click to continue on your VM size selection to continue. Next are the Optional Features configurations section. : Select I’m going to walk through each section because they each spawn their own ‘Blade’ of settings Click + “Create New” — Something easy to recognize — (Virtual machines in the same fault domain share a common power source and physical network switch.): Minimum of 2 — (Virtual machines in the same update domain will be restarted together during planned maintenance. Azure never restarts more than one update domain at a time.): recommended 5 for Scale-Out High Availability: Name: Fault Domains Update Domains: Picture of Settings for High Availability Yes Storage — Managed Disks?: +”Create New” — — Defaults are fine, unless you run more than 256 servers in this subnet or have a special / different name. Network: — Virtual Network: Defaults are fine, unless you run more than 256 servers in this subnet or have a special / different name. — Subnet: +”Create New” — — Default name is fine. Assignment = Dynamic (Can be changed later if desired). Means it will NOT have a static IP address. — Public IP Address: This is where we set the Azure firewall for your resources. This will be the firewall laying in front of your VMs. — — Default: default-allow-ssh is set to port 22. This can be changed at any time, if you desire to change the SSH port to something custom. (See Ark Installation port recommendations when you get there) → Click +Add an inbound rule → Click “Advanced” and input settings:Source: Any Source port ranges: * Destination: Any (Can also be changed)Destination port ranges: 4001–4002 (Ark Ports)Protocol: TCPAction: AllowPriority: 100Name: Ark-Port_4001–4002 →Click “OK” — Network Security Group (Firewall): (This can be changed if you want to limit access based on public-ip addresses inbound) None Extensions: Off Auto-Shutdown: Boot diagnostics: Off (Unless you begin having boot issues, it can be turned on later) Guest OS diagnostics: Off Monitoring: — — (Can be turned on later if desired) Click “Next” to proceed to the Summary page. This next page validates that everything you did up to this point is safe to deploy. It also lists everything you’ve configured, and most importantly, lets you download templates and parameters to make deployment faster in the future. Click to get a ZIP file of template files. You can optionally add this new template to your “Template Library” by clicking “Add to Library” “Download template and parameters” Summary Screen and Template download options By clicking “Add to Library” you will need to Name the template, and leave a somewhat detailed description of the deployment. Once done saving your template, from the ‘Summary’ section of our original deployment. This in Azure. click on “Create” will create the first VM Create Button It will take 5 or so minutes before your server is fully deployed. To view your VMs / Resource Group, navigate to Resource Groups > ARK_RG1 — Here, you will be able to view all of the storage groups, virtual machines, the firewall (NSG) settings, and the availability set. Click on your VM, in my instance “ArkNode1” in the Resource Group ARK_RG1 We want to set a DNS address for this VM, so you can use a dynamic DNS name instead of a static IP for connectivity. Click on “Configure” under “DNS Name” in the Virtual Machine’s Overview. DNS Menu in the VM ‘Blade’ Set the DNS name to whatever you please. For ease for remembering, I am naming it the same of the VM itself. The DNS Name will be whatever you choose + The Azure Cloudapp domain for your datacenter location This means, when using PuTTY to connect into this VM, you can use the DNS Name of: arknode1.southcentralus.cloudapp.azure.com This is dynamically updated DNS by Azure’s back-end, so you do not need to set that yourself either if your VM changes public IP dynamically. This means, when using PuTTY to connect into this VM, you can use the DNS Name of: arknode1.southcentralus.cloudapp.azure.com you can choose ‘Static’ IP, however there is a monthly cost associated with a static vs dynamic. Alternatively, Before we begin any kind of Ark Node configuration, which unfortunately at this time is not easily automated, let us perform a Template Deployment of a second VM to this availability group. By learning this skill, you can deploy any number of additional VMs quickly without needing to adjust all of the minute details of the first time through. In the Azure search panel, type in “Template” and select the “Templates (preview)” Searching in Azure for Templates (Preview) Select the template you created earlier and saved to your Template Library, I named mine “ark_node_template”, and it will open it up. All settings preserved, nice! to bring up the parameters that need to be set for the new template deployment. They are initially are all BLANK. Click “Deploy” To fill these values in with our old VM’s data, and make the slight necessary adjustments, do the following: Click on “Edit Parameters” to bring up options for editing the background data. Using the Downloaded ZIP file from earlier, which you need to have extracted somewhere on your computer, click “Load File” on the ‘Edit Parameters’ page. “Load file” in top-left opens up the file explorer Click “Save” after it uploads your parameters JSON file, and it will take you back to a now fully-populated set of deployment information. , so be certain to fill in / adjust as necessary. For me, the following needed adjustment: There are a few fields that need adjustment Resource Group — Set to ARK_RG1Virtual Machine Name — ArkNode2 (New VM Name)Network Interface Name — arknode1762 (New Network Interface for the VM)Admin Password — <set accordingly>PUBLICIPADDRESSNAME — ArkNode2-ip (New / separate public IP for this VM) — Sidenote: You will need to go into the VM and set the DNS address for this as well. All other items in the parameter list are safe to keep identical, as they are re-usable and overlapping. Click “Agree” and “Purchase” to initiate the deployment of this new VM. After the typical 5 or so minutes, it should end successfully. Go ahead and double-check the VM settings from it’s device page in your Resource Group. You are now free to connect to both of your VMs via PuTTY, using your assigned / created login names and password from the configuration steps. Can also deploy as many VMs as your wallet can handle with this setup, and not just for Ark-related applications either. It’s a fairly generic setup for any VM farm in Azure. By placing both VMs into a High Availability Set, with 2 fault domains, we guarantee Azure’s 99.99% uptime of at least 1 server in the event their datacenter has outages of any kind. I will be working on an updated guide, for the setup and configuration of Ark itself via Ansible. This way commands can be invoked against multiple servers simultaneously, so we can configure the Ark Nodes without sitting at the console the whole time. (Will update this article when that one is completed) Good Resources / References: Ark.io setup of a node: https://blog.ark.io/how-to-setup-a-node-for-ark-and-a-basic-cheat-sheet-4f82910719da Secure your node: https://blog.ark.io/how-to-secure-your-ark-node-541254028616 Quick config of an Ark Node by Jarunik: https://medium.com/@jarunik/installing-and-managing-an-ark-node-577a9074b9bb
