Infrastructure as Code بـ Terraform: desired state وdrift وidempotency
بدل ما تكتب أوامر على كل راوتر، هتوصف الحالة المطلوبة في ملف main.tf وTerraform يطبّقها على R1 وR2 بـ RESTCONF، ويكتشف أي تغيير يدوي (drift) ويرجّعه، وتشوف ليه تشغيله مرتين ما بيكسرش حاجة.
مدة التجربة 30 دقيقة · 4 مهام
الأجهزة في بداية التجربة
- R1 — راوتر
- R2 — راوتر
- SW1 — سويتش
- DEV — سيرفر
التوصيلات
- R1 Gi0/0/0 ↔ SW1 Fa0/1
- R2 Gi0/0/0 ↔ SW1 Fa0/2
- DEV eth0 ↔ SW1 Fa0/24
العناوين المضبوطة مسبقًا
- R1 g0/0/0: 10.0.0.1/24
- R2 g0/0/0: 10.0.0.2/24
02 / المهام التي ستطبقها
- 01terraform init: نزّل الـ provider بتاع Cisco IOS XE
تلميح / الحل المقترح
من كونسول DEV: terraform init. الـ provider (CiscoDevNet/iosxe) هو اللي بيترجم الـ resources لطلبات RESTCONF على الراوتر. بيكتب .terraform.lock.hcl عشان الكل يستخدم نفس النسخة
- 02كمّل main.tf لـ R2 وطبّق: Loopback100 على الراوترين
يتحقق المعمل من على R1: الأمر show ip interface brief يظهر فيه «»، على R2: الأمر show ip interface brief يظهر فيه «»
تلميح / الحل المقترح
زوّد provider "iosxe" فيه alias = "r2" وurl = "https://10.0.0.2"، وresource "iosxe_interface_loopback" "mgmt_r2" فيه provider = iosxe.r2 والعنوان 10.255.0.2. بعدين terraform plan (بيوريك + create قبل أي تغيير) ثم terraform apply -auto-approve
- 03حد غيّر R1 بإيده: Terraform يكتشف الـ drift ويرجّع الحالة المطلوبة
يتحقق المعمل من على R1: الأمر show running-config interface loopback 100 يظهر فيه «»
تلميح / الحل المقترح
على R1: configure terminal ثم interface loopback 100 ثم description TEMP. ارجع DEV: terraform plan هيعمل refresh ويقولك ~ update in-place (description "TEMP" -> "MGMT"). terraform apply -auto-approve يرجّعها — من غير ما تكتب ولا أمر CLI
- 04شغّل apply تاني: No changes (idempotent)
تلميح / الحل المقترح
terraform apply -auto-approve مرة كمان: الحالة الحقيقية = المطلوبة فمفيش حاجة تتنفّذ. الفرق عن سكربت CLI عادي: Terraform (وAnsible) declarative وidempotent — إنت بتقول عايز إيه مش تعمل إزاي، وتشغيله 100 مرة نفس النتيجة. Terraform بيحتفظ بـ state file، وAnsible من غير state وبيشتغل بـ SSH/playbooks
03 / تجارب مرتبطة