Being able to easily connect to Cloud services is a criteria of great importance for all of the developers. In CirrusGrid, each newly created node is assigned a number of automatically generated hostnames, pointed to the appropriate server internal/external IP address.
Depending on a type of the created node, the set of hostnames for it could differ. Thus, below we’ll consider the possible ways to refer to a particular node, hosted at CirrusGrid Cloud, either from inside (i.e. when managing it via CirrusGrid SSH Gate) or outside of the Cloud:
Each container at the platform can be accessed by its internal IP address with an URL of one of the following formats:
Herewith, the placeholders should be replaced with the next values:
Both variants can be used for referring to the nodes from inside or outside of the platform (i.e. allowing to establish both internal and external connections).
Some of CirrusGrid certified stacks are provisioned with additional hostname prefixes (i.e. where the appropriate stack name is used instead of the node string) to make their management more convenient.
Note: Such supplementary prefixes are valid only within domains with a hyphen as a separator.
All alternative domain strings, shown in the table above, can be utilized similarly to the hostnames for specific containers.
For the new environments, you can get all internal IP addresses of containers within one node layer using the following hostname:
Here, ${nodeGroup} placeholder is a name of a particular layer the required container belongs to. By default, layers are named in accordance with the appropriate nodeGroup specific role.
Note: Node groups added via the extra layers in the topology wizard are named in the same way, but with the appropriate ${N} index. Herewith, the default layers in topology wizard (e.g. bl, cp, sqldb, etc.) are considered as the first index, so the enumeration in extra layers starts with the second one, e.g. cp2, cp3, cp4, … (except of the extra, extra2, extra3, …). For example:
For example, this command can be used to get an application servers list for any environment within the platform:
Tip: In order to get a list of containers for the current environment, just a short hostname can be used.
Herewith, every time a new container is created (removed) in a system, the appropriate record is automatically added to (removed from) DNS for the layer hostname.
All the newly created Docker containers and dockerized CirrusGrid-managed stacks are provisioned with the specific DNS rules, which allow usage of the additional simplified hostnames:
Utilizing such short hostnames in server configuration files, application source code and SSH console (within often used commands like ping, host, dig, etc) makes operating with Dockerized stacks via Platform internal network much more convenient. Additionally, such approach enables painless environment migration to another hardware region through eliminating the necessity to adjust your application code due to the changed server location.
Upon linking two Docker-based environment layers, a set of dedicated DNS records are automatically added to the global CirrusGrid database. This allows to refer to the nodes within a target layer from the source ones (but not vice versa) when working in confines of these two layers using the following hostname aliases:
Here, the appropriate placeholders are to be substituted with:
${linkAlias} – link name you’ve specified during its setting (e.g. tomcat in the image below)
${N} – nominal index number (in a 1…N range) of a particular container within the target linking layer (e.g. tomcat_1, tomcat_2), etc; herewith, master container is always considered the 1st instance, whilst the rest of layer nodes are assigned numbers according to their nodeID values, being sorted in ascending order (starting with the _2 index, then _3, _4, etc.)
For example, if there are three containers on a layer – with the 123, 124 (master) and 125 IDs. According to the above-described implementation, the aliases will be assigned as follows:
Tip: By appending an environment domain to the alias ${linkAlias}.${envName}.${platformDomain}, the corresponding linked layer name can be resolved and accessed externally, i.e. from anywhere over the Internet. And by ${linkAlias}_${N} corresponding container of a linked layer can be resolved internally only, within the linked layers network.
Now, you know all the specifics and shortcuts that can be used to refer to your nodes, which will help to quickly and efficiently organize connections between your application instances.
Powered by BetterDocs
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Please enable JavaScript in your browser to complete this form.Organization *Name *FirstLastEmail *Submit