img

رام کردن کلاد – ذخیره سازی با Terraform

/
/
/

Terraform یک نرم افزار منبع باز است که امکان نوشتن، برنامه ریزی و ایجاد زیر ساختار به عنوان کُد را برای مدیران سیستم ها و توسعه دهندگان، فراهم می کند. این برنامه، یک بسته نرم افزاری کاربردی و بدون ویژگی های اضافی است که به آسانی قابل راه اندازی بوده و اگر بخواهید از JSON یا یک زبان پیکر بندیِ ساده استفاده می کند.
نرم افزار Terraform ابزاری برای ایجاد و مدیریت زیر ساختار (infrastructure) است که با تامین کننده های مختلف خدمات Iaas، PaaS و Saas کار می کند. از آن جایی که سِروِر ها، آژانس ها، بسته های چند گانه و موارد دیگر، دخالتی در عملکرد این نرم افزار ندارند، راه اندازی و استفاده از آن بسیار آسان است. شما فقط باید زیر ساختار مورد نظرتان را با استفاده از یک زبان برنامه نویسیِ ساده (یا JSON) در یک (یا چند) فایل تعریف کنید. نرم افزار Terraform، پیکر بندی هایِ شما را دریافت کرده، بلوک های ساختمانی متفاوت را از نقطه نظر ایجاد یک نمودار (گراف) وابستگی ارزیابی کرده و برای شما، طرحی برای ایجاد زیر ساختار ارائه می کند. اگر طرح ارائه شده مورد قبول شما باشد، پیکر بندی ها را اجرا کرده و منابع مستقلی را به صورت موازی ایجاد می کند. پس از این که چند زیر ساختار با استفاده از Terraform ایجاد شود، شرایط زیر ساختار موجود را با پیکر بندی های تعریف شده بر روی اجرا های پُشت سر هم مقایسه کرده و فقط بر اساس قسمت تغییر پیدا کرده زیر ساختار عمل می کند. در حقیقت، Terraform یک ابزار CRUD (مخفف Create Read Update Destroy به معنیِ ایجاد، خواندن، به روز رسانی و حذف که چهار عمل اصلی مدیریت داده ها در برنامه نویسی است) بوده و بر روی زیر ساختار در یک روش خود توان (idempotent) عمل می کند.

 

نصب و راه اندازی
نرم افزار Terraform در Golang ایجاد شده و به عنوان یک دوتاییِ ایستایِ (static binary) بدون نیاز به نصب در اختیار کاربران قرار گرفته است. فقط باید دوتایی دُرُست (برای GNU/Linux، Mac OS X، Windows، FreeBSD، OpenBSD و Solaris) را از سایت آن دانلود کرده و آن را در یک قسمت اجرایی از مسیر جستجو غیر فشرده (unzip) کنید تا آماده اجرا شدن باشد. برای دانلود، غیر فشرده کردن و بررسی درستیِ نصب بر روی GNU/Linux و Mac OS X می توانید از کُد زیر استفاده کنید:

CTLSLOC=’/usr/local/bin’
HCTLSURL=’https://releases.hashicorp.com’
# use latest version shown on https://www.terraform.io/downloads.html
TRFRMVER=’x.y.z’
if uname -v | grep -i darwin 2>&1 > /dev/null
then
OS=’darwin’
else
OS=’linux’
fi
wget -P /tmp –tries=5 -q -L “${HCTLSURL}/terraform/${TRFRMVER}/terraform_${TRFRMVER}_${OS}_amd64.zip”
sudo unzip -o “/tmp/terraform_${TRFRMVER}_${OS}_amd64.zip” -d “${HCTLSLOC}”
rm -fv “/tmp/terraform_${TRFRMVER}_${OS}_amd64.zip”
terraform version

 

 

مفهوم هایی که باید بدانید
شما فقط باید چند نکته را بدانید تا بتوانید در کوتاه ترین زمان ممکن از Terraform برای ایجاد زیر ساختار مورد نظرتان استفاده کنید. برای نمونه می توان به تامین کننده ها (Providers) به عنوان تعدادی از چندین بلوک ساختمانی Terraform اشاره کرد که پایه خدمات اَبریِ متفاوت بوده و از منبع های انتهایِ پُشتی (back-end) متفاوت CRUD پُشتیبانی می کند. در حقیقت Terraform تامین کننده های مختلفی را در اختیار شما قرار می دهد تا بتوانید از کامپیوتر های انتهای پُشتی (back-end ها) و تامین کننده های خدمات متفاوتی مانند AWS، Google Cloud، Digital Ocean، Docker و موارد دیگر استفاده کنید. شما باید ویژگی های متفاوتی مانند کلید های مخفی/دسترسی، ناحیه ها، نقطه های پایانی و مواردی مانند آن ها که قابل استفاده در خدمات/منابع انتهای پُشتی باشند را تامین کنید. هر کدام از تامین کننده ها، منابع مختلفی را برای تطبیق داشتن با بلوک های ساختمانی متفاوت مانند VM ها، فضای ذخیره سازی، شبکه بندی، خدمات مدیریت شده و مواردی مانند این ها پیشنهاد می کنند. بنا بر این فقط به یک تامین کننده برای ایجاد امکان استفاده از تمام منبع های پیاده سازی شده در Terraform نیاز داریم تا زیر ساختار را برای خدمات یا منابع انتهایِ پُشتی، ایجاد کنیم. تامین کننده (provisioner) هایی مطابق با منابع متفاوت وجود دارند که این منابع را بعد از ایجاد شدنشان، پیکر بندی و راه اندازی ابتدایی می کنند. این تامین کننده (provisioner) ها، بیشتر کار هایی مانند آپلود کردن فایل ها، اجرای دستور/فرمان های محلی/از راه دور، اجرای مدیریت پیکر بندیِ مشتریان و موارد مشابه را انجام می دهند.
شما باید زیر ساختار را با استفاده از یک زبان پیکر بندیِ ساده، در یک یا چند فایل با پسوند .tf توصیف کنید. مُدلِ پیکر بندیِ Terraform از نوعِ تشریحی است و در بیشتر موارد، در زمان اجرا، تمام فایل های .tf را در مسیر پوشه، یکپارچه می کند. در حقیقت با چنینی کاری، مشکلات وابسته بودن بین منابع مختلف، خود به خود برطرف می شود تا نمودار وابستگیِ نهاییِ دُرُست ایجاد شده و منابع مستقل (غیر وابسته) به صورت موازی در کنار هم قرار داده شوند. اگر چه Terraform می تواند برای زبان پیکر بندی از JSON نیز استفاده کند اما بهترین حالت زمانی است که پیکر بندی های Terraform با استفاده از ابزار خودکار شده انجام شوند. فُرمتِ Terraform برای خوانده شدن توسط انسان ها ساده تر بوده و از یادداشت (comment) ها پشتیبانی می کند پس شما می توانید در زمانی که برخی از پیکر بندی ها توسط انسان و برخی دیگر توسط ابزار خودکار شده ایجاد شده باشند، فایل های پیکر بندیِ .tf و .json را ترکیب کرده یا آن ها را با یکدیگر تطبیق دهید. همچنین Terraform جنبه هایِ متغیر ها و توابعی که بر روی این متغیر ها کار می کنند تا ذخیره سازی، تخصیص و انتقال چیز های دیگر در زمان اجرا را نیز تامین می کند.
گردش کار (workflow) عادیِ Terraform از دو مرحله طراحی و به کار گیری (اجرا) تشکیل شده است. مرحله طراحی (plan)، پیکر بندی های یکپارچه (یا روی هم قرار گرفته) شده را ارزیابی کرده و پیش از تصمیم گیری برای ایجاد، بهبود یا پاک کردن منابع، طرحی را ارائه می کند. بنا بر این تغییراتی لازم برای ایجاد زیر ساختار مورد نظر شما به طور کامل در مرحله برنامه ریزی مشخص شده و شما با نکته مبهم یا جدیدی در مرحله اجرا روبرو نخواهید شد. بعد از قبول کردن طرح ارائه شده، مرحله اجرا شروع به انجام کار های ابتداییِ مراحل ایجاد منابع مورد نیاز برای ساختن زیر ساختار مورد نظر شما می کند. اطلاعات زیر ساختار ایجاد شده توسط Terraform در یک فایل (که به صورت پیش فرض terraform.tfstate نامیده می شود) ذخیره شده و هر بار که چرخه مراحل طراحی و اجرا دوباره تکرار شود، مشخصات زیر ساختار در حال ساخت در زمان اجرا با مشخصات زیر ساختار ذخیره شده، مقایسه می شود. بعد از مقایسه حالت ها، تنها تغییرات لازم برای تبدیل زیر ساختار ساخته شده به زیر ساختار جدید مورد نظر انجام می شوند. در حقیقت با این روش، در هر بار تکرار شدن مرحله اجرا، تمام زیر ساختار به روش خود توانی ایجاد/بهینه می شود. شما می توانید منابع مختلف را به صورت دستی (غیر خودکار) انتخاب کنید تا در مرحله بعدیِ اجرا، با استفاده از عملیات taint (به معنیِ رنگ کردن)، به روز شوند. همچنین می توانید با استفاده از عملیات destroy (به معنیِ تخریب یا حذف کردن)، تمام یا قسمتی از زیر ساختار را پاک کنید.

 

کاربرد و نمونه های عملی
نمونه ابتدایی، پاک سازیِ ترکیب (syntax) برای قسمت های مختلف در فایل های پیکر بندیِ Terraform است. کُد example1.tf را از

http://opensourceforu.com/article_source_code/sept17/terraform.zip

دانلود کنید. این کُد، اُلگویی (template) برای استفاده از نمونه های چند گانه AWS EC2 VMs به همراه Ubuntu 14.04 LTS و یک حجم داده EBS رمز نگاری شده در یک زیر شبکه VPC مشخص شده و مواردی مانند آن است. همچنین این اُلگو، دارای ویژگیِ تامین کنندگیِ از راه دور بر روی نمونه (های) منتقل شده از یک برنامه شروع کننده (script) تامین کنندگی بوده و چندین مورد اجرایی را از راه دور انجام می دهد.
اکنون، این نمونه را خط به خط و برای آشنایی کامل و عملی با جنبه های مختلف Terraform، بررسی و تشریح می کنیم. خط هایی که با کلمه کلیدی variable (متغیر) شروع می شوند، شروع کننده بلوک های متغیر های ورودی برای ذخیره کردن مقدار ها هستند. بلاک های متغیر، امکان تخصیص برخی مقدار های ابتدایی را فراهم می کنند. این مقدار ها می توانند به عنوان پیش فرض در نظر گرفته شوند اما می توان هیچ مقدار پیش فرضی را نیز در نظر نگرفت. اگر هیچ مقدار پیش فرضی در نظر گرفته نشود، Terraform، مقدار ها را در زمان اجرا درخواست می کند البته اگر با استفاده از گزینه –var ‹<variable>=<value>› مشخص نشده باشند. بنا بر این در نمونه مورد نظر ما، داده های حساس مانند کلید های اختصاصی/دسترسیِ AWS در اُلگو (template) وارد نشده زیرا می توانند در زمان اجرا به صورت دستی (غیر خودکار) یا با استفاده از گزینه های فرمان و یا متغیر های محیطی، تامین شوند. متغیر های محیطی (environment variables) باید به شکل TF_VAR_name وارد شوند تا برای Terraform قابل خواندن باشند. متغیر ها می توانند شامل رشته (string)، فهرست (list) و نقشه (map) به عنوان متغیر باشند. در نمونه مورد بررسی ما، یک نقشه به عنوان زیر شبکه ها و ami های متفاوت برای ناحیه های AWS مختلف، ذخیره شده است. مقدار رشته (string)، در بین علامت گُفتاورد (double quotes)، فهرست (list) ها در براکت (bracket) و نقشه (map) ها در آکولاد (curly brace) قرار دارند. متغیر ها دارای منبع (reference) بوده و مقدار های آن ها به وسیله درون یابی (interpolation) در قسمت های مختلف و با استفاده از ترکیب {var.<variable name>}$ به دست می آیند. برای بررسی بیشتر در مورد متغیر های Terraform می توانید به صفحه رسمی متغیر های آن مراجعه کنید.
حدس زدن این که این بلوک با کلمه کلیدیِ provider (تامین کننده) شروع می شود، کار سختی نیست و نشان می دهد که آرگومان (argument) ها برای خدمات/انتهایِ پُشتی، تامین شده اند. تامین کننده های مختلف، از آرگومان های مختلفی که بر اساس خدمات/انتهایِ پُشتی به کار گرفته شده، استفاده می کنند که برای مشاهده جزئیات بیشتر درباره هر تامین کننده، باید به صفحه رسمی همان تامین کننده مراجعه کنید. کلمه کلیدی resource (منابع) شامل قسمت های اصلی در تمام پیکر بندی های Terraform است. ما از دو بلوک ساختمانیِ AWS در نمونه مورد نظرمان استفاده کرده ایم: aws_instance برای مشاهده نمونه ها و aws_route53_record برای ایجاد ثبت (record) های cname برای نمونه های ایجاد شده. هر بلوک منبع، از آرگومان هایی برای سفارشی کردن منبع (هایی) که ایجاد کرده استفاده کرده و ویژگی هایی را برای منبع (های) ایجاد شده، مشخص می کند. هر بلوک منبع با

resource <resource type> <resource id>

مشخص شده و نکته مهم این است که ترکیب

<resource type> <resource id>

باید یک نام یکتا (منحصر به فرد) در محدوده پیکر بندیِ Terraform باشد. پیشوند (prefix) هر منبع به تامین کننده (provider) آن مرتبط (link) شده است. برای نمونه، تمام پیشوند های AWS منبع ها به یک تامین کننده AWS نیاز دارند. شکل ساده به دست آوردن ویژگیِ یک منبع

<resource type>.<id>.<attribute>

است. نمونه ما نشان می دهد که ویژگی های public_ip و public_dns نمونه های ایجاد شده در بلوک های خروجی و route53 قابل دسترسی هستند.
برخی از منابع به چند عملیات بعد از ایجاد شدن (post-creation) مانند ایجاد اتصال و اجرای فرمان های از راه دور و/یا محلی، متن و مواردی مانند این ها بر روی نمونه (های) AWS نیاز دارند. همچنین، بلوک ارتباط یا اتصال (connection) به همان منبع متصل شده است (با ایجاد یک اتصال ssh به نمونه های ایجاد شده). بلوک های تامین کننده، ساز و کار (mechanism) هایی برای استفاده از اتصال به فایل (های) آپلود و راهنما (directory) به منبع (های) ایجاد شده هستند. همچنین، تامین کننده ها فرمان های از راه دور یا محلی را هم زمان با اجرای Chef، اجرا می کنند. شما می توانید اطلاع بیشتری را در این زمینه بر روی صفحه کمک (help) رسمی تامین کننده ها مشاهده کنید. نمونه ما، آپلود کردن متن (script) تامین کنندگی و راه اندازی آن به صورت از راه دور بر روی ssh برای تامین مورد های ایجاد شده خارج از جعبه (out-of-the-box) است. Terraform چند مِتا پارامتر، مانند آرگومان شمارش در نمونه مورد نظر ما، را بر روی تمام این منبع ها در دسترس قرار داده است. امکان پیگیری و نظارت بر منبع جاری ایجاد شده برای مرجع در حال استفاده یا بعدی به وسیله count.index وجود دارد. در نمونه ما، یک برچسبِ نام (name tag) برای هر مورد ایجاد شده، درست شده است. از آن جایی که با ارجاع دادن ویژگیِ aws_instance در aws_route53_record، تعداد وابستگی ها کم تر شده است، مورد (نمونه) ها قبل از ایجاد شدن ثبت های cname هایشان، به وجود می آیند. شما می توانید از meta-variable depends_on در شرایطی که وابستگی ضِمنی بین منبع ها وجود نداشته و می خواهید قطعی بودن آن مشخص شود، استفاده کنید. متغیر هایی که به آن ها اشاره شد، به صفحه کمک می کنند تا اطلاعات دقیق تری در مورد متا متغیر ها را تامین کنند.
آخرین بلوک پیکر بندیِ نمونه ما، بلوک خروجی است. همان طور که از اسم آن مشخص است، خروجی می تواند از ویژگی های منتقل شده (transformed) یا خام (raw) منبع های ایجاد شده، بر اساس تقاضا و در هر زمان ممکن، نسخه برداری کند. همچنین شما می توانید استفاده تابع (function) های مختلف مانند فُرمت و قسمت (element) های مختلف در پیکر بندیِ نمونه را نیز مشاهده کنید. این تابع ها، متغیر های را به شکل های مُفید و کاربردی تر تبدیل می کند (برای نمونه تابع قسمت، بر اساس شاخص جاریِ مورد های ایجاد شده به public_id دُرُست بازیابی می شود). درون یابیِ رسمی به صفحه کمک می کند تا اطلاعات دقیق تری درباره تابع های مختلف پشتیبانی شده توسط Terraform را تامین کند.
اکنون نشان می دهیم که چگونه خروجیِ نسخه برداری شده در زمان خواندن مرحله های مختلف گردش کارِ Terraform، رمز گشایی می شود. ما انواع خروجی هایی که در پیامد اجرای فرمان terraform plan –var ‹num_nds=»۳»› و پس از ایجاد خروجیِ TF_VAR_aws_access_key و TF_VAR_aws_access_key در راهنمای کاری و جایی که نخستین پیکر بندیِ نمونه ایجاد شده بود، مشاهده می شوند را می بینیم:

+ aws_instance.test.0

+ aws_instance.test.1

+ aws_instance.test.2

+ aws_route53_record.test.0

+ aws_route53_record.test.1

+ aws_route53_record.test.2
Plan: 6 to add, 0 to change, 0 to destroy.

 

اگر خطا هایی در پیکر بندی باشد، فقط در مرحله طراحی ظاهر شده و Terraform از خطا های تجزیه، نسخه برداری می کند. شما می توانید به طور واضح، دُرستیِ پیکر بندی را برای هر موردی با استفاده از فرمان terraform validate بررسی کنید. اگر همه چیز درست باشد، مرحله طراحی، منبع هایی که قرار است ایجاد شوند (و با علامت سبز رنگ + قبل از نام منبع مشخص می شوند) را نسخه برداری کرده تا به مُدلِ زیر ساختار از پیش اعلام شده، نزدیک شود. به طور مشابه، خروجیِ طراحیِ Terraform، منبع هایی که قرار است حذف (پاک) شوند را به رنگ قرمز (و با علامت -) نشان داده و منبع هایی که به روز رسانی میشوند را با رنگ زرد (و با علامت ~) مشخص می کند. وقتی خروجی طرح Terraform، منبع های مورد نظرتان را ارائه کرد، می توانید terraform apply را برای پیاده (apply) کردن طرح اجرا کرده و در حقیقت درست کردن زیر ساختار را شروع کنید.
نمونه دوم ما، کار کردن شما با Terraform را راحت تر کرده و در حقیقت روشی برای استفاده از ویژگی های پیشرفته آن برای ایجاد و هماهنگیِ چند سناریوی غیر بدیهی است. کُد example2.tf را می توانید از

http://opensourceforu.com/article_source_code/sept17/terraform.zip

دانلود کنید. در حقیقت این نمونه، وظیفه بالا آوردن (اجرای) یک خوشه کاریِ (working cluster) خارج از جعبه (out-of-the-box) را، خودکار (اتوماتیک) می کند. در این نمونه، چندین مورد چند دیسکیِ (multi-disk) قابل پیکر بندی از خوشه بار مُفید AMI بالا آورده (اجرا) شده و پس از آن به ترتیب، یک دستور مشخصِ از راه دور تامین کننده ها با استفاده از null-resources، برخی تامین کننده ها بر روی تمام گره ها و برخی دیگر فقط بر روی یک گره خاص، شروع می شود.
در اُلگوی example2.tf، در حقیقت null-resource چند گانه در واکنش به منبع های گوناگون ایجاد شده و بر اساس آن چیزی که مبتنی بر آن ها است، اجرا می شود. در این روش، شما می توانید به سادگی ببینید که چگونه ما برخی از سناریو های نه چندان بدیهی را هماهنگ می کنیم. همچنین شما می توانید استفاده از depends_on meta_variable را برای اطمینان از وجود یک رشته وابستگی بین منبع های مختلف، مشاهده کنید. به طور مشابه، شما می توانید منبع های ایجاد شده توسط Terraform که می خواهید حذف شوند یا آن هایی که می خواهید به ترتیب با استفاده از فرمان های terraform destroy و terraform taint دوباره ایجاد شوند را مشخص کنید. روش ساده برای به دست آوردن اطلاعات سریع درباره فرمان های Terraform و آرگومان ها/گزینه های آن ها، نوشتن terraform و terraform <command name> -h است.
در نسخه های جدید Terraform، شروع به پشتیبانی از منبع های داده ها شده است. از این منبع ها، برای جمع کردن داده های پویا از تامین کننده های مختلف استفاده می شود. داده های پویای جمع آوری شده به وسیله منبع های داده در پیکر بندیِ Terraform، و بیشتر با استفاده از درون یابی به کار برده می شوند. یک کاربرد ساده از منبع داده، جمع آوریِ ami id برای آخرین نسخه های یک ami و استفاده از آن در پیکر بندی های تامین کنندگی نمونه به شکل زیر است:

data “aws_ami” “myami” {
most_recent = true
filter {
name = “name”
values = [“MyBaseImage”]
}
}
resource “aws_instance” “myvm” {
ami = “${data.aws_ami.myami.id}

}

 

استفاده مجدد و سازماندهیِ کُد
اگر چه نمونه های ما پیکر بندیی اعلام شده را به صورت کامل در یک فایل مجزا (تَکی) نشان می دهد اما ما می خواهیم آن را به چند فایل تقسیم کنیم. شما می توانید پیکر بندیِ کامل خودتان را بر اساس ترتیب کارایی (عملکرد)، به پیکر بندی های مختلف، تقسیم بندی کنید. بنا بر این، نخستین نمونه می تواند به variables.tf به عنوان نگه دارنده تمام بلوک های متغیر ها، aws.tf به عنوان مشخص کننده تامین کننده ها، instances.tf به عنوان مشخص کننده جانمایی های AWS VMs، route53.tf به عنوان نشان دهنده کارایی aws route 53 و output.tf به عنوان خروجی های ما، تقسیم‌بندی شود.
برای این که همه چیز ساده، کاربردی و قابل عیب یابی و بهبود باشد، هر چیزی را در ارتباط با یک وظیفه کلی حَل شده توسط Terraform در یک راهنمای مجزا (تَکی) در کنار زیر راهنما هایی (sub-directories) به نام های فایل ها (files)، متن ها (scripts)، کلید ها (keys) و مانند این ها، نگهداری می کنیم.
در Terraform تاکیدی بر روی به ترتیب بودن سازمان کُد وجود ندارد اما نگه داشتن هر مرحله (سطح) عملکردی در راهنمای اختصاص داده به آن، از کار های غیر منتظره Terraform بر خلاف تغییرات پیکر بندیِ غیر مرتبط، جلوگیری می کند. به خاطر داشته باشید که در دنیای نرم افزار، «کپی کردن، بهتر از وابسته بودن است» چرا که امکان خرابی و پیچیدگی با اضافه شدن هر کارایی عملکردیِ جدید وجود دارد.
Terraform عملکرد ایجاد ماژول (module) ها را برای استفاده مجدد از پیکر بندیِ ایجاد شده، تامین می کند.در حقیقت اُلگوی ایجاد خوشه (cluster) نشان داده شده، در یک ماژول قرار گرفته تا از کُد یکسان برای تامین (تهیه ی) آزمون (تست) و/یا خوشه های تولید استفاده شود. با استفاده از ماژول به سادگی می توان متغیر های مورد نیاز برای آن را به شکلی که در ادامه نشان داده می شود، تامین کرد (بعد از اجرای terraform get برای ایجاد لینک های ضروری برای کُد ماژول):

module “myvms” {
source = “../modules/awsvms”
ami_id = “${var.ami_id}”
inst_type = “${var.inst_type}”
key_name = “${var.key_name}”
subnet_id = “${var.subnet_id}”
sg_id = “${var.sg_id}”
num_nds = “${var.num_nds}”
hst_env = “${var.hst_env}”
apps_pckd = “${var.apps_pckd}”
hst_rle = “${var.hst_rle}”
root_size = “${var.root_size}”
swap_size = “${var.swap_size}”
vol_size = “${var.vol_size}”
zone_id = “${var.zone_id}”
prov_scrpt= “${var.prov_scrpt}”
sub_dmn = “${var.sub_dmn}”
}

 

همچنین لازم است یک variables.tf در جایی که منبع ماژول شما قرار دارد ایجاد کنید که نیازمند همان متغیر هایی است که در ماژولتان قرار داده اید. در این جا ماژول variables.tf برای عبور متغیر های تامین شده توسط تماس گیرنده یا صدا کننده (caller) ماژول را می بینیم:

variable “ami_id” {}
variable “inst_type” {}
variable “key_name” {}
variable “subnet_id” {}
variable “sg_id” {}
variable “num_nds” {}
variable “hst_env” {}
variable “apps_pckd” {}
variable “hst_rle” {}
variable “root_size” {}
variable “swap_size” {}
variable “vol_size” {}
variable “zone_id” {}
variable “prov_scrpt” {}
variable “sub_dmn” {}

 

سند های رسمی Terraform شامل بخش هایی با جزئیات زیاد برای ایجاد و استفاده از ماژول ها است که اطلاعات بیشتری را در مورد هر چیزی که مربوط به ماژول ها است در اختیار شما قرار می دهد.

وارد کردن منابع موجود
همان طور که پیش از این دیده اید، Terraform اطلاعات منبع هایی که ایجاد کرده است را در یک فایل state ذخیره کرده و به صورت پیش فرض هیچ اطلاعاتی در مورد منبع هایی که توسط خودش ایجاد نشده، ندارد اما در نسخه های جدید تر Terraform، یک ویژگی برای وارد کردن منبع های موجود، و نه آن هایی که توسط Terraform در یک فایل state مربوط به خودش ایجاد شده، وجود دارد. در حال حاضر، ویژگی وارد کردن (import) تنها فایل state را به روز می کند اما لازم است که کاربر پیکر بندی را برای منبع های وارد شده، ایجاد کند. در غیر این صورت، Terraform منبع های وارد شده را بدون پیکر بندی نشان داده و آن ها را نشانه دار می کند تا حذف (پاک) شوند.
برای روشن شدن موضوع، یک نمونه AWS که توسط Terraform ایجاد نشده را در برخی زیر ساختار های ایجاد شده توسط Terraform، وارد (import) می کنیم. شما باید دستور

terraform import aws_instances.<Terraform Resource Name> <id of the instance>

را در راهنمای (directory)، جایی که یک فایل state برای Terraform وجود دارد، اجرا کنید. بعد از انجام درست و موفقیت آمیز عملیاتِ وارد کردن، Terraform اطلاعات مربوط به نمونه مورد نظر را جمع آوری کرده و یک قسمت متناظر را در فایل state اضافه می کند. حالا اگر طرح Terraform را ببینید، چیزی مانند این عبارت نمایش داده خواهد شد:

– aws_instance .<Terraform Resource Name>

 

بنا بر این شما باید یک پیکر بندی جدید مرتبط با فایل وارد شده را در یک فایل موجود یا جدید .tf ایجاد کنید. در نمونه مورد نظر ما، این قسمت Terraform باید به اندازه ای کامل باشد که به Terraform اجازه حذف (پاک) کردن آن را ندهد.

resource “aws_instance” “<Terraform Resource Name>” {
ami = “<AMI>”
instance_type = “<Sizing info>”
tags {

}
}

 

توجه کنید که فقط باید به ویژگی (صفت) هایی از منبع Terraform اشاره کنید که در سند (document) های Terraform به آن ها نیاز است. حالا اگر طرح Terraform را ببینید، برنامه حذف (destruction) که پیش از این برای منبع های وارد شده وجود داشت دیده نمی شود. شما می توانید از دستوری که در ادامه می آید برای به دست آوردن ویژگی های منبع وارد شده به منظور ایجاد پیکر بندی آن، استفاده کنید:

sed -n ‘/aws_instance.<Terraform Resource Name>/,/}/p’ terraform.tfstate | \
grep -E ‘ami|instance_type|tags’ | grep -v ‘%’ | sed ‘s/^ *//’ | sed ‘s/:/ =/’

 

توجه داشته باشید که چه زمانی یک منبع را در state در Terraform در حال کار وارد کرده و تصمیم می گیرید که از آن در ادامه استفاده نکنید. در چنین شرایطی، فراموش نکنید که نام terraform.state.backup را به terraform.state تغییر داده تا به حالت قبلی برگردید. همچنین، به عنوان یک گزینه دیگر می توانید بلوک منبع را از فایل state پاک (delete) کنید اگر چه این کار را توصیه نمی کنیم. در غیر این صورت، Terraform تلاش می کند تا فایل وارد شده را پاک (حذف) کند که در برخی موارد می تواند به تمام منبع ها آسیب برساند و مشکلاتی اساسی برای شما به وجود بیاورد.
اسناد رسمیِ Terraform نمونه های واضح و شفاف زیادی را در مورد وارد کردن منبع های مختلف در یک زیر ساختار موجود Terraform در اختیار کاربران قرار داده است. اما اگر به دنبال روشی هستید که منبع های AWS موجود را به صورت خودکار (اتوماتیک) تر در یک زیر ساختار AWS ایجاد شده توسط Terraform وارد کنید، به لینک ابزار Terraform که در قسمت منابع به آن اشاره شده است، مراجعه کنید.

 

بایت های از دست رفته
اکنون باید خیالتان درباره شروع خودکار تامین زیر ساختار ابریِ مورد نظرتان راحت شده باشد. اگر بخواهیم رُک باشیم، Terraform به اندازه ای از ویژگی های مختلف برخوردار است که نمی توان درباره همه آن ها در یک یا چند مقاله به طور کامل صحبت کرد و در حقیقت لازم است که یک کتاب درباره آن نوشته شود (که به صورت یک کتاب الکترونیکی و با نام Terraform Up & Running آماده شده است). بنا بر این می توانید برای به دست آوردن اطلاعات بیشتر به گزارش Git رسمیِ آن مراجعه کنید. همچنین در بخش منابع، به مقاله های بسیار خوب و جذابی اشاره شده که می توانند به عنوان ابزاری کامل و بی نظیر به شما کمک کنند.
ایجاد زیر ساختار های قابل توجه و مورد نیاز در اَبر، در صورت استفاده از قانون های پایه ای و ساده و همچنین به کار گرفتن ابزاری با ویژگی های قابل توجه که کاربری آسانی دارند، چندان سخت و پیچیده نیست. می توانیم از Terraform به عنوان یکی از این ابزار بی نظیر برای مدیریت زیر ساختار اَبر که نمی توان از نام آن به سادگی گذشت نام ببریم. در حقیقت Terraform یکی از بهترین ابزار در میان تامین کنندگان اَبر به حساب می آید. همچنین می توان از Terraform در کنار دیگر ابزار مدیریت اَبر استفاده کرد تا گردش کار زیر ساختار مناسبی را ایجاد کرده و با استفاده از آن بتوان هر زیر ساختار اَبری را مدیریت کرد.

نکته: تامین کننده های Terraform دیگر به عنوان توزیع اصلی Terraform، توزیع نمی شوند. در عوض، آن ها به صورت خودکار و به عنوان قسمتی از راه اندازیِ ابتدایی Terraform، نصب می شوند. در دستور وارد کردن (import command) لازم است که منبع های وارد شده در فایل پیکر بندی مشخص شده باشند. برای آشنایی بیشتر به سیاه تغییرات (changelog) آن به نشانی

https://github.com/hashicorp/terraform/blob/v0.10.0/CHANGELOG.md

مراجعه کنید.

منابع
۱- نمونه های Terraform:
https://github.com/hashicorp/terraform/tree/master/examples
۲- ابزار استفاده از Terraform:
https://github.com/dtan4/terraforming
۳- یک راهنمای مفهومی و کامل برای Terraform:
https://blog.gruntwork.io/a-comprehensive-guide-to-terraform-b3d32832baca#.ldiays7wk
۴- Terraform Up & Running:
https://www.terraformupandrunning.com/?ref=gruntwork-blog-comprehensive-terraform

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text