การเชื่อมต่อกับบริการคลาวด์อย่างง่ายเป็นเกณฑ์ที่สำคัญอย่างยิ่งสำหรับนักพัฒนาแต่ละโหนดที่สร้างขึ้นใหม่จำนวนหนึ่่งจะถูกกำหนดชื่อโฮสต์โดยอัตโนมัติซึ่งชี้ไปที่ IP ภายใน/ภายนอกของเซิร์ฟเวอร์ที่เหมาะสม

โดยขึ้นอยู่กับชนิดของโหนดที่สร้างขึ้นและเซตของชื่อโฮสต์สำหรับโหนดนั้นอาจแตกต่างกัน ในส่วนของด้านล่างนี้จะพิจารณาวิธีการอ้างอิงโหนดโดยเฉพาะสำหรับโฮสต์ที่ Ruk-Com Cloud ภายใน (เช่น เมื่อจัดการผ่าน SSH Gate) หรือภายนอก Cloud:

• ชื่อโฮสต์สำหรับคอนเทนเนอร์โดยเฉพาะ
• ชื่อโฮสต์เสริมสำหรับประเภทโหนดเฉพาะ
• ชื่อโฮสต์สำหรับเลเยอร์โดยเฉพาะ
• ชื่อโฮสต์แบบสั้นสำหรับคอนเทนเนอร์ภายในหนึ่ง environment
• ชื่อโฮสต์สำหรับการเชื่อมโยงคอนเทนเนอร์

ชื่อโฮสต์สำหรับคอนเทนเนอร์โดยเฉพาะ

แต่ละคอนเทนเนอร์ที่แพลตฟอร์มสามารถเข้าถึงได้โดย IP address ภายในด้วย URL ในรูปแบบใดรูปแบบหนึ่งต่อไปนี้:

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

ในกรณีนี้ แทนที่ค่าตัวยึดตําแหน่งด้วยค่าต่อไป:

• ${nodeId} – การสร้างตัวเลขที่ไม่ซ้ำกันโดยอัตโนมัติซึ่งถูกกำหนดให้กับทุกคอนเทนเนอร์ภายในแพลตฟอร์ม

• ${envName} – ชื่อ environment (ไม่ใช่ alias) ที่ระบุในระหว่างการสร้าง
• ${platformDomain} – ชื่อโดเมนของการติดตั้ง Ruk-Com Cloud ผู้ให้บริการโฮสต์

ตัวแปรทั้งสองสามารถใช้เพื่ออ้างถึงโหนดจากภายในหรือภายนอกแพลตฟอร์ม (เช่น อนุญาตให้สร้างการเชื่อมต่อทั้งภายในและภายนอก)

ชื่อโฮสต์เสริมสำหรับประเภทโหนดเฉพาะ

สแต็กที่ผ่านการรับรองจะมีคำนำหน้าชื่อโฮสต์เพิ่มเติม (เช่น ใช้ชื่อสแต็กที่เหมาะสมแทนโหนดสตริง) เพื่อให้การจัดการมีความสะดวกยิ่งขึ้น

หมายเหตุ: คำนำหน้าดังกล่าวใช้ได้เฉพาะโดเมนที่มี hyphen (-) เป็นตัวคั่นเท่านั้น

ประเภทโหนด	สแต็ก	ชื่อโฮสต์เพิ่มเติม
Custom Docker Сontainers		docker${nodeId}-${envName}.${platformDomain}
	Cassandra 1/2	cassandra${nodeId}-${envName}.${platformDomain}
	CouchDB	couchdb${nodeId}-${envName}.${platformDomain}
	MariaDB 5/10	mariadb${nodeId}-${envName}.${platformDomain}
	Memcached	memcached${nodeId}-${envName}.${platformDomain}
Database	MongoDB 2/3	mongodb${nodeId}-${envName}.${platformDomain}
Database	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}

โดเมนสำรองทั้งหมดที่แสดงในตารางด้านบสามารถใช้เหมือนกับชื่อโฮสต์สำหรับคอนเทนเนอร์เฉพาะ

ชื่อโฮสต์สำหรับเลเยอร์โดยเฉพาะ

สำหรับ environment ใหม่คุณสามารถรับที่อยู่ IP ภายในของคอนเทนเนอร์ในโหนดเลเยอร์เดียวกันได้โดยใช้ชื่อโฮสต์ต่อไปนี้:

• ${nodeGroup}.${envName}.${platformDomain}

${nodeGroup} คือชื่อของเลเยอร์เฉพาะที่คอนเทนเนอร์ต้องการอยู่ โดยค่าเริ่มต้น เลเยอร์จะถูกตั้งชื่อตามบทบาทเฉพาะของ nodeGroup ที่เหมาะสม

หมายเหตุ: กลุ่มโหนดที่เพิ่มผ่านเลเยอร์พิเศษใน topology wizard มีชื่อในลักษณะเดียวกันแต่มี ${N} index ที่เหมาะสม อีกทั้งเลเยอร์เริ่มต้นใน topology wizard (เช่น bl, cp, sqldb เป็นต้น) ถือเป็น index แรกดังนั้นการนับเลเยอร์เพิ่มเติมจะเริ่มต้นด้วยอันที่สอง เช่น cp2, cp3, cp4, … (ยกเว้น extra, extra2, extra3, …) ตัวอย่างเช่น:

ยกตัวอย่าง คำสั่งนี้สามารถใช้เพื่อรับรายการแอปพลิเคชันเซิร์ฟเวอร์สำหรับ environment ใดๆภายในแพลตฟอร์ม:

เคล็ดลับ: หากต้องการรับรายการคอนเทนเนอร์สำหรับ environment ปัจจุบันคุณสามารถใช้ได้เพียงชื่อโฮสต์แบบสั้นเท่านั้น

พร้อมกันนี้ทุกครั้งที่มีการสร้างคอนเทนเนอร์ใหม่ (ลบ) ในระบบประวัติที่เหมาะสมจะถูกเพิ่มโดยอัตโนมัติไปยัง (ลบออกจาก) DNS สำหรับชื่อโฮสต์ของเลเยอร์

ชื่อโฮสต์แบบสั้นสำหรับคอนเทนเนอร์ภายในหนึ่ง environment

Docker คอนเทนเนอร์ที่สร้างขึ้นใหม่ทั้งหมดและสแต็กที่จัดการด้วย Ruk-Com Cloud ได้จัดเตรียมกฏสำหรับ DNS โดยเฉพาะที่อนุญาตให้ใช้ชื่อโฮสต์แบบง่ายเพิ่มเติมได้:

• node${nodeId} – นามแฝงเพื่ออ้างอิงถึงคอนเทนเนอร์ในขอบเขตของ environment เดียว
• ${nodeGroup} – นามแฝงเพื่ออ้างอิงถึงขอบเขตของเลเยอร์ environment เดียว

การใช้ชื่อโฮสต์สั้นๆ ดังกล่าวในไฟล์การกำหนดค่าเซิร์ฟเวอร์ source code ของแอปพลิเคชันและ SSH console (คำสั่งภายในที่ใช้บ่อย เช่น ping, host, dig ฯลฯ) ทำให้การทำงานกับ Dockerized stacks ผ่านเครือข่ายภายในของแพลตฟอร์มสะดวกยิ่งขึ้น นอกจากนี้วิธีการดังกล่าวยังช่วยให้การย้าย environment ไปยัง hardware region อื่นนั้นไม่ยากและไม่จำเป็นต้องปรับเปลี่ยนโค้ดของคุณเนื่องจากตำแหน่งเซิร์ฟเวอร์ที่เปลี่ยนไป

ชื่อโฮสต์สำหรับการเชื่อมโยงคอนเทนเนอร์

เมื่อเชื่อมโยง environment layer ที่ใช้สอง Docker เซตของ DNS records จะถูกเพิ่มไปยังฐานข้อมูล Ruk-Com Cloud ทั่วโลกโดยอัตโนมัติ ซึ่งจะช่วยอ้างอิงถึงโหนดภายในเลเยอร์เป้าหมายจากโหนดต้นทาง (แต่ไม่ใช่ในทางกลับกัน) เมื่อทำงานในขอบเขตของสองเลเยอร์โดยใช้ชื่อโฮสต์แฝงต่อไปนี้:

• ${linkAlias} – อ้างอิงถึงโหนดสุ่มภายในเลเยอร์เป้าหมาย โหนดที่ถูกต้องที่จะตอบสนองนั้นถูกเลือกโดยใช้ Round-Robin algorithm – สิ่งนี้ทำให้มั่นใจได้ถึงการกระจายโหลด
• ${linkAlias}_${N} – เพื่อเข้าถึงคอนเทนเนอร์เฉพาะภายในเลเยอร์เป้าหมาย ตัวยึดตำแหน่งที่เหมาะสมจะถูกแทนที่ด้วย
• ${linkAlias} – ชื่อลิงก์ที่ระบุระหว่างการตั้งค่า (เช่น tomcat ในภาพด้านล่าง)

• ${N} – หมายเลขในช่วง (1…N) ของคอนเทนเนอร์เฉพาะภายในเป้าหมายเลเยอร์ที่เชื่อมโยง (เช่น tomcat_1, tomcat_2) เป็นต้น พร้อมกันนี้ คอนเทนเนอร์หลักถือเป็นอินสแตนซ์ที่ 1 เสมอ ในขณะที่โหนดเลเยอร์ที่เหลือจะได้รับการกำหนดหมายเลขตามค่า nodeID โดยจะเรียงลำดับจากน้อยไปมาก (เริ่มต้นด้วย index _2 จากนั้น _3, _4 เป็นต้น)

ตัวอย่างเช่น หากมีคอนเทนเนอร์ 3 รายการบนเลเยอร์ – ด้วย ID 123, 124 (master) และ 125 ตามการใช้งานที่อธิบายไว้ข้างต้น นามแฝงจะถูกกำหนดดังนี้:

• alias_1 – ลิงก์ไปยังคอนเทนเนอร์ 124 เป็นโหนดหลัก
• alias_2 – จะชี้ไปที่อินสแตนซ์ 123 เนื่องจากมี ID ต่ำสุดในบรรดาคอนเทนเนอร์ที่เหลืออยู่
• alias_3 – อ้างอิงถึงคอนเทนเนอร์ 125 เป็นรายการถัดไปที่มี nodeID ต่ำสุด

เคล็ดลับ: เมื่อเชื่อมต่อ environment domain เข้ากับ alias ${linkAlias}.${envName}.${platformDomain} ชื่อเลเยอร์ที่เชื่อมโยงเกี่ยวข้องจะสามารถแก้ไขได้และเข้าถึงได้จากภายนอก กล่าวคือ เข้าถึงจากที่ใดก็ได้ทางอินเทอร์เน็ตและ ${linkAlias}_${N} คอนเทนเนอร์ที่สอดคล้องกันของเลเยอร์ที่เชื่อมโยงสามารถแก้ไขได้ภายในเท่านั้น

ตอนนี้ คุณได้ทราบข้อมูลเฉพาะและทางลัดทั้งหมดที่สามารถใช้เพื่ออ้างอิงถึงโหนดของคุณ ซึ่งจะช่วยจัดระเบียบการเชื่อมต่อระหว่างแอปพลิเคชันอินสแตนซ์ของคุณได้อย่างรวดเร็วและมีประสิทธิภาพ