DNS Hostnames for Direct Connection to Containers

DNS Hostnames for Direct Connection to Containers

It’s substantial to have flawless access to the cloud services for developers. In our platform, when a new node is created, it automatically receives a set of unique hostnames linked to its internal or external IP address.

The hostnames assigned to a node can vary based on its type. Below, we’ll explore how to access a specific node on our platform, whether from within (like using SSH Gate) or outside the Cloud.

Save $100 in the next
5:00 minutes?

Register Here

Container-Specific Hostnames

To access each container on the platform, you can use its internal IP address with a URL in one of these formats:

  • node${nodeId}-${envName}.${platformDomain}
  • node${nodeId}.${envName}.${platformDomain}

Here, the placeholders should be replaced as follows:

  • ${nodeId}: This is a unique numeric identifier automatically assigned to every container within the platform.

Example: Node ID: 4597

Node ID: 4597

  • ${envName}: This refers to the environment name specified during its creation, which is not an alias.

Example: env-4839899 is a domain name, or you can set your domain name while creating.

${platformDomain}: This is the domain name of the PaaS installation hosting service provider.

Example: Here it is us-accuweb.cloud which is a static

Both URL formats can be used to reference nodes from within or outside the platform, enabling both internal and external connections.

Save $100 in the next
5:00 minutes?

Register Here

Additional Hostnames for Specific Node Types

Certain certified platform stacks come with extra hostname prefixes, where the stack name replaces the node string.

Node Type Stack Additional Hostname
Custom Docker Сontainers docker${nodeId}-${envName}.${platformDomain}
Database Cassandra 1/2 cassandra${nodeId}-${envName}.${platformDomain}
CouchDB couchdb${nodeId}-${envName}.${platformDomain}
MariaDB 5/10 mariadb${nodeId}-${envName}.${platformDomain}
Memcached memcached${nodeId}-${envName}.${platformDomain}
MongoDB 2/3 mongodb${nodeId}-${envName}.${platformDomain}
MSSQL mssql${nodeId}-${envName}.${platformDomain}
MySQL 5.6/5.7 mysql${nodeId}-${envName}.${platformDomain}
Neo4j 1/2 neo4j${nodeId}-${envName}.${platformDomain}
OrientDB orientdb${nodeId}-${envName}.${platformDomain}
PostgreSQL 8/9 postgres${nodeId}-${envName}.${platformDomain}
Redis redis${nodeId}-${envName}.${platformDomain}
VPS vps${nodeId}-${envName}.${platformDomain}

The alternative domain strings listed in the table above can be used in the same way as specific container hostnames.

Hostnames for Specific Layers of Infrastructure

For specific layers within new environments, you can obtain all internal IP addresses of containers within a node layer using the following hostname format:

Here, the ${nodeGroup} placeholder represents the name of the specific layer to which the desired container belongs. By default, layers are named based on the corresponding role of the node group.

Here is an example command that can be used to retrieve a list of application servers for any environment within the platform:

Host name for specific layers

Whenever a new container is created or removed within the system, the corresponding DNS records for the layer hostname are automatically updated.

Learn more about the differences between containerization and virtualization.

Shortened Hostnames for Containers in the Same Environment

All newly created Docker containers and platform-managed stacks that are dockerized are configured with specific DNS rules to enable the use of simplified hostnames:

  • node${nodeId}: This serves as an alias to reference a container within a single environment.
  • ${nodeGroup}: This serves as an alias to reference a layer within a single environment.

Utilizing these shortened hostnames in server configuration files, application source code, and SSH consoles (for common commands like ping, host, dig, etc.) greatly enhances the operational ease of managing Dockerized stacks via the platform’s internal network.

Know more about container management with Docker and Kubernetes.

Hostnames for Interconnected Containers

When linking two Docker-based environment layers, dedicated DNS records are automatically created in the global platform database. This enables referencing nodes within a target layer from the source layer using specific hostname aliases, as outlined below:

  • ${linkAlias}: This alias is used to refer to any node within the target layer. The Round-Robin algorithm is applied to select an available node, ensuring even load distribution.
  • ${linkAlias}_${N}: This format allows access to a specific container within the target layer,
    where ${N} represents the container index.

To use these aliases, replace the placeholders as follows:

  • ${linkAlias}: Use the link name specified during the linking process (e.g., tomcat as shown in the image).

Interconnected Container

The placeholder ${N} represents the nominal index number within a range of 1 to N for a particular container within the target linking layer (e.g., tomcat_1,tomcat_2, etc.). In this system:

  • The master container is always designated as the 1st instance.
  • The remaining layer nodes are assigned indices based on their nodeID values, sorted in ascending order starting with _2, then _3, _4, and so forth.

For instance, if there are three containers on a layer with node IDs 123, 124 (master), and 125, the aliases will be assigned as follows:

  • alias_1: Points to the master container with node ID 124.
  • alias_2: Refers to the container with node ID 123, chosen because it has the lowest ID among the remaining containers.
  • alias_3: Used to refer to the container with node ID 125, which is the next lowest nodeID in sequence.

Now that you are familiar with all the specifics and shortcuts for referencing nodes, you can efficiently organize connections between your application instances. This method will enable you to establish and manage connections within your environment quickly.

Save $100 in the next
5:00 minutes?

Register Here