1. مقدمة
تاريخ آخر تعديل: 2021-01-06
ما هي خدمة Cloud DNS؟
يمكنك الاطّلاع على صفحتنا الرئيسية.
ما ستنشئه
في هذا الدرس التطبيقي حول الترميز، ستنشئ ManagedZone في Cloud DNS ومجموعات ResourceRecordSets ذات الصلة باستخدام gcloud لإدارة عملية تحليل الأسماء إلى بعض مثيلات الأجهزة الافتراضية.
ما ستتعلمه
كيفية إنشاء وقراءة وحذف وتعديل ResourceRecordSets الفردية
المتطلبات
2. الإعداد
إعداد مشروعك على Google Cloud Platform
تسجيل الدخول إلى gcloud
gcloud auth login
إنشاء مشروع
gcloud projects create my-codelab-project
تفعيل Cloud DNS API
gcloud services enable dns.googleapis.com
قد يستغرق تطبيق هذا الإجراء بضع دقائق.
3- إنشاء ManagedZone خاص
تحتوي ManagedZone على ResourceRecordSets.
دوِّن اسم النطاق الذي تريد إضافة سجلات نظام أسماء النطاقات إليه. في هذا المثال، سنستخدم "my-domain.com" وسنفترض أنّ جهازك الافتراضي على الشبكة التلقائية.
gcloud dns managed-zones create my-zone \
--description="ManagedZone for Cloud DNS ResourceRecordSets codelab." \
--dns-name=my-domain.com. \
--networks=default \
--visibility=private
4. إدارة ResourceRecordSets
في نهاية هذا القسم، سيتم التعامل مع طلبات نظام أسماء النطاقات (DNS) عبر شبكتك الافتراضية الخاصة لنطاقك من خلال عنوان IP الخاص بالجهاز الظاهري.
على سبيل المثال، إذا كان عنوان IP الخاص بجهازك الافتراضي هو "1.2.3.4"، وأردت أن يتم حلّ "my-domain.com" إلى عنوان IP هذا، عليك إنشاء "سجلّ A".
إنشاء سجلّ A
gcloud dns record-sets create "my-domain.com." --type="A" --ttl="60" --rrdatas="1.2.3.4" --zone="my-zone"
- وسيط الموضع "my-domain.com." ، المعروف أيضًا باسم dnsName، هو الاسم الذي نريد تحديد عملية التحويل باستخدام نظام أسماء النطاقات له.
- –type: يشير إلى نوع سجلّ نظام أسماء النطاقات الذي نحاول إنشاءه.
- –ttl: يشير إلى مدة بقاء هذا السجلّ.
- –rrdatas: يحتوي على الإجابة الفعلية عن الطلب.
- –zone: مطلوب لتحديد ManagedZone التي يجب إنشاء هذا السجلّ فيها.
يمكنك الاطّلاع على مزيد من المعلومات حول مفاهيم نظام أسماء النطاقات هنا.
بعد إنشاء سجلّ A، من المفترض أن تتمكّن من اختبار التحويل باستخدام نظام أسماء النطاقات (DNS).
استخدِم بروتوكول SSH في جهازك. في هذا المثال، نستخدم جهازًا افتراضيًا (VM) باسم "dns-codelab" في المنطقة "us-central1-a".
gcloud compute ssh codelab --zone=us-central1-a
تثبيت dnsutils حتى تتمكّن من استخدام الأمر "dig"
sudo apt install dnsutils
طلب البحث عن نطاقك
dig my-domain.com.
من المفترض أن ينتج عن ذلك مخرجات مشابهة لما يلي
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19979
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;my-domain.com. IN A
;; ANSWER SECTION:
my-domain.com. 60 IN A 1.2.3.4
...
إنشاء سجلّ CNAME وتعديله والحصول عليه
بعد ربط my-domain.com. بعنوان IP 1.2.3.4، من المحتمل أنّك تريد التأكّد من أنّ www.my-domain.com. يؤدي أيضًا إلى عنوان IP 1.2.3.4. لا يتم إنشاء سجلّات للبادئة "www." تلقائيًا.
إذا أجريت طلب بحث عن www.my-domain.com
dig www.my-domain.com.
ستظهر لك نتيجة مشابهة لما يلي
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
ما يشير إلى عدم توفّر سجلّ نظام أسماء نطاقات لهذا النطاق
بدلاً من إنشاء سجلّ A آخر، يجب إنشاء سجلّ CNAME يشير إلى سجلّ آخر. سيمنعنا ذلك من الاضطرار إلى تغيير كلا السجلّين في حال أردنا استخدام عنوان IP مختلف.
الخروج من مثيل الجهاز الافتراضي
exit
إنشاء سجلّ CNAME
gcloud dns record-sets create "www.my-domain.com." --type="CNAME" --ttl="60" --rrdatas="my-domin.com." --zone="my-zone"
بعد إنشاء سجلّ CNAME، من المفترض أن تتمكّن من اختبار التحويل باستخدام نظام أسماء النطاقات (DNS).
الاتصال بالجهاز باستخدام بروتوكول النقل الآمن (SSH) مرة أخرى
gcloud compute ssh codelab --zone=us-central1-a
طلب البحث عن نطاقك
dig www.my-domain.com.
من المفترض أن تكون قد تلقّيت نتيجة مشابهة لما يلي
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
يا للهول! يبدو أنّه حدث خطأ إملائي عند إنشاء سجلّ CNAME في العلامة "–rrdatas". بدلاً من حذف السجلّ وإعادة إنشائه، يمكننا تعديل السجلّ وإضافة التغيير الصحيح.
الخروج من مثيل الجهاز الافتراضي
exit
تعديل سجلّ CNAME
gcloud dns record-sets update "www.my-domain.com." --type="CNAME" --rrdatas="my-domain.com." --zone="my-zone"
يُرجى العِلم أنّه يمكننا حذف العلامة "–ttl" لأنّنا لن نغيّرها، ولكن يجب تضمين جميع العلامات الأخرى لأنّها جزء من المعرّف الفريد عالميًا الخاص بـ ResourceRecordSet.
يمكننا أيضًا التأكّد من أنّ السجلّ مطابق للتوقّعات باستخدام gcloud
gcloud dns record-sets describe "www.my-domain.com." --type="CNAME" --zone="my-zone"
التي من المفترض أن تنتج مخرجات
NAME TYPE TTL DATA
www.my-domain.com. CNAME 60 "my-domain.com."
التأكّد من أنّ سجلّ CNAME يتم تحويله بشكلٍ صحيح
gcloud compute ssh codelab --zone=us-central1-a
dig www.my-domain.com.
من المفترض أن تكون قد تلقّيت نتيجة مشابهة لما يلي
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7471
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;www.my-domain.com. IN A
;; ANSWER SECTION:
www.my-domain.com. 60 IN CNAME my-domain.com..
...
الحذف لإعادة التنظيم
قبل حذف ManagedZone، يجب أولاً حذف جميع ResourceRecordSets ضِمن ManagedZone (باستثناء سجلّات NS وSOA التي يتم إنشاؤها تلقائيًا ويجب أن تكون موجودة دائمًا في ManagedZone).
الخروج من مثيل الجهاز الافتراضي
exit
حذف سجلّ CNAME
gcloud dns record-sets delete "www.my-domain.com." --type="CNAME" --zone="my-zone"
حذف سجلّ A
gcloud dns record-sets delete "my-domain.com." --type="A" --zone="my-zone"
حذف ManagedZone
gcloud dns managed-zones delete "my-zone"
5- تهانينا
تهانينا، لقد تعلّمت بنجاح كيفية إدارة ResourceRecordSets.