Picking a useful naming scheme for companies with multiple Hypernodes

in Usage

We often see Hypernodes with a state indicator in the appname running in another state then the name indicates. This often causes confusion and is very error prone, as anyone reading dev or test in the name, easily assumes this is a test or development server.
Many Hypernode users that order a Hypernode for the first time, order this node just for testing purposes, hence the dev or test in it’s name.

This article aims to provide a few tips and tricks to choose a useful naming scheme for your Hypernodes.

Choosing a sane appname

When you are picking an appname for a hypernode, never use state indicators as dev, test, otap, live, production etc in your hypernode appname, but instead use a random word.

The appname of the Hypernode should not contain any indication of the customer using the node, the purpose and or state of the server, but instead acts as a permanent, unique identifier to reference a specific server while it is in use.

It is recommended to use a wordlist to pick an appname, the names of all train stations of a country, all characters in the toy story movies etc. Choose a name that does not represent anything on the stack and has no deeper meaning other than just being a random word.

The only time you should mention the appname is when contacting the Hypernode support team.

Using prefixes

Never use prefixes in the appname! In other words: Never use your company name or another logical identifier to prefix your Hypernodes with.

When we upgrade nodes or migrate to a newer version of the operating system, this is done in alphabetical order, causing your nodes to be migrated all in the same night. If all your nodes start with the same company prefix this automagically implies that all shops are migrated on the same night as they are in the same alphabetical batch.

Having to contact all your customers in advance on the same day to announce maintenance on the Hypernode, or working on adjustments on all your nodes because of a migration to a new operating system is not really wat you want.

Setting the TTL for your DNS records

Make sure you use the lowest TTL possible for your domain records, to keep downtime due to DNS caching as low as possible.

Preferably the TTL is not higher than one minute.

Some hosters do not support a TTL below 10 minutes. If this is the case: pick another domain hoster to host your domain, as a ten minutes wait time when changing DNS records is too long for a webshop.

Creating additional DNS record for your Hypernode

After you ordered the Hypernode, and you received the notification the node is ready, create some additional records for your own comfort and ease.

Create CNAME records for each additional name, pointing to the appname.hypernode.io record.

The CNAME records are what your developers and customers should remember and use for connecting with the Hypernode. Keeping the structure of these names consistent will lower the mental effort needed to remember the name of a node when you need it…

If your company uses the name SuperWebBuilders b.v. and owns the domain SuperWebBuilders.com, create some additional records that are easy to remember, for example the name of the customer, followed by a state indicator.

IE: If your customer is named supershop, create a supershop-prod.superwebbuilders.com CNAME record pointing at the production hypernode and a supershop-dev.superwebbuilders.com CNAME pointing at the development node.

To make things even easier, you can create records for your developers as well. For example if a developer named Rick is the only developer working on the shop of customer supershop, create an additional CNAME record in the customers DNS zone for rick.super.shop pointing to the Hypernode for use with SSH, FTP etc.

Tip: Be careful using A records or AAAA records to point your custom additional DNS records, but use a CNAME record instead. This saves you from having to change all DNS records that point to a node when the IP address changes. Although Hypernodes have a dedicated IP, there are situations in which the IP of a Hypernode does change.

Switching from live to dev or vice versa

When going live, all you have to do is change the CNAME records of supershop-prod and supershop-dev and adjust the Magento base URL’s accordingly, while retaining the same appname for the Hypernode.

IE: the appname still is applejuice, but as the state changed from ‘dev’ to ‘live’, you now change the state indicator records to the corresponding node without the need to change the appname by ordering a new hypernode.

Automation

Several DNS hosters provide API access for DNS changes. For example both AWS and Digital Ocean, the cloud providers we use to host our Hypernodes, support programmatically changing DNS records.

This can be extremely useful in autodeployments and other automation.

For example, you have 2 Hypernodes for a customer: applejuice and figtree.
The first is the acceptation node, the second is the live environment of the customer.

To maintain some overview, you created supershop-dev.superwebbuilders.com and supershop-live.superwebbuilders.com.

When a new feature is released or pull request is merged, your deployment mechanism deploys the created changes to the staging server and sends an email to the customer to validate the changes.

When the customer is satisfied with the new feature and no additional configuration is necessary, he validates the change by clicking a link, which automatically switches the DNS records of the dev and the live node, and you’re good to go 🙂

By choosing a random name, you are not bound to a specific node as all the names are not bound to a state or a customer, so it’s even possible to switch customers between nodes (if you choose so), which makes developing much easier.

0