آموزش سریع نصب و راه اندازی کلاسترینگ Kubernetes با Kubeadm در لینوکس Ubuntu 16.04

آموزش نصب کلاسترینگ کوبرنیتیس Kubernetes 1.10 با Kubeadm در اوبونتو ۱۶٫۰۴

How To Create a Kubernetes 1.10 Cluster Using Kubeadm on Ubuntu 16.04

مقدمه

در این آموزش به صورت خلاصه و کاربردی به نصب ، راه اندازی و تنظیمات Kubernetes بوسیله Kubeadm و برنامه مدیریت تنظیمات Ansible بر روی سیستم عامل Ubuntu 16.04 می پردازیم. شرح این آموزش را به صورت کامل در صفحه آموزش نصب کلاسترینگ Kubernetes می توانید مطالعه کنید.

در این آموزش برای نصب Kubernetes به سرور Ubuntu 16.04 استفاده می کنیم که یک سرور به عنوان Master و نقش مدیریت و تنظیم کننده وظایف دو سرور دیگر می باشد که به عنوان سرور Worker در کلاسترینگ استفاده می شوند.

همچنین لازم است که در این آموزش با مفاهیم Ansible و نقش Playbook ها در Ansible و همچنین مفهوم Pod در Kubernetes آشنایی داشته باشید. برای آشنایی با Ansible و همچنین روش نصب آن در لینوکس Ubuntu از این آموزش می توانید استفاده کنید و برای آشنایی با Plybook ها در Ansible از این آموزش استفاده کنید و برای آشنایی با Pod ها از مطلب آشنایی با مفهوم Pod در kubernetes استفاده کنید.

مرحله اول – تنظیم دایرکتوری فضای کار و فایل فهرست Ansible

در ابتدا یک دایرکتوری برای Workspace و استفاده فضای کاری مورد نیازمان ایجاد می کنیم. سپس در این دایرکتوری یک فایل ایجاد می کنیم که این فایل شامل اطلاعات سرور ها و گروه های سرور های می باشد.

خطوط زیر را در این فایل وارد کنید و مقادیر گفته شده را با مقادیر مناسب جایگزین کنید. منظور مقادیر master_ip و worker_1_ip و worker_2_ip می باشد :

مرحله دوم – ایجاد کاربر در سرور های متصل

در این مرحله بر روی سرور ها یک کاربر non-root user با دسترسی sudo ایجاد می کنیم که سرور ها با دسترسی این کاربر به یکدیگر متصل می شوند. برای این کار از Ansible استفاده می کنیم و یک Playbook به صورت زیر ایجاد می کنیم :

سپس Playbook را اجرا می کنیم :

این دستور بین دو تا ۵ دقیقه اجرا می شود ، و پس از کامل اجرا شدن دستور خروجی مشابه زیر نمایش داده می شود :

مرحله سوم – نصب پیش نیاز های kubernetes

در این قسمت باید پکیج های مورد نیاز Kubernetes در سیستم عامل را بوسیله apt که ابزار مدیریت بسته های Ubuntu است ، نصب کنیم.  این پکیج ها به صورت زیر هستند :

  • Doker – یک مخزن زمان اجرا می باشد، که شامل اجزای مورد نیاز مخازن شما می باشد. همچنین مخازن دیگر مانند rkt را پشتیبانی می کند.
  • kubeadm – یک ابزار خط فرمان برای نصب و پیکربندی اجزای مختلف کلاستر به صورت استاندارد می باشد.
  • kubelet – یک برنامه سیستمی و یک سرویس است که برای مدیریت گره ها Nodes و عملیات ها می باشد.
  • kubectl – یک ابزار خط فرمان برای ارسال دستورات به کلاستر ها از طریق API Server می باشد.

این بسته ها باید بر روی تمامی سرور ها نصب شوند ، پس برای این کار نیز از Ansible با Playbook زیر استفاده می کنیم :

سپس play زیر را برای نصب پکیج ها در سرور ها وارد کنید :

بعد از اتمام کار فایل را ذخیره کرده و خارج شوید و Playbook را اجرا کنید :

بعد از اتمام اجرای این فایل خروجی مشابه زیر را مشاهده می کنید :

مرحله چهارم – تنظیم سرور Master

در این مرحله تنظیمات سرور master را انجام می دهیم. هر Pod آدرس IP برای خود دارد ، و هر pod در هر سرور باید بتواند از طریق آدرس IP آن pod در سرور دیگر به آن متصل شود. مخازنی که بر روی یک سرور هستند براحتی بوسیله رابط های محلی ارتباط برقرار می کنند. ارتباط بین pod ها پیچیده است و نیاز به یک شبکه جداگانه دارد که مسیر شفاف از یک pod به یک pod در یک سرور دیگر مشخص شده باشد.

این کار توسط پلاگین شبکه pod انجام می شود. در این آموزش از Flannel استفاده می کنیم که یک گزینه پایدار و مناسب است.

یک Ansible playbook با نام master.yml ایجاد کنید :

متن play زیر را برای نصب Flannel و مقدار دهی اولیه کلاستر وارد کنید :

در انتها فایل را ذخیره کرده و خارج شوید.

فایل playbook را به صورت محلی Local اجرا کنید :

خروجی این دستور مشابه زیر است :

برای بررسی وضعیت سرور master از طریق ssh با دستور زیر به سرور متصل شوید :

پس از وارد شدن به سرور دستور زیر را اجرا کنید :

باید خروجی مشابه زیر را مشاهده کنید :

در سرور master تمامی تنظیمات و مقداردهی های اولیه انجام شده و وضعیت سرور در حالت ready و آماده برای شروع اتصال به سرور های worker و ارسال وظایف به آنها از طریق  API Server می باشد. اکنون می توانیم سرور های worker را اضافه کنیم.

مرحله پنجم – تنظیمات سرور های Worker

برای اضافه کردن گره worker یک دستور را باید اجرا کنید ، که شامل جزئیات مورد نیاز کلاستر از قبیل آدرس IP و پورت API سرور master می باشد و یک توکن امنیتی می باشد. فقط سروری که توکن را قبول می کند می تواند به کلاستر متصل شود.

به مسیر فضای کاری Workspace بروید و یک playbook به نام workers.yml ایجاد کنید :

متن زیر را در فایل قرار دهید :

فایل را ذخیره کرده و خارج شوید.

فایل playbook را اجرا کنید :

خروجی این اجرا مشابه زیر است :

با اضافه شدن سرور های worker کلاستر شما به صورت کامل تنظیم شده و آماده بهره برداری است و worker ها آماده اجرای بارهای کاری ارسالی هستند. قبل از زمان بندی برنامه ، صحت عملکرد کلاستر را بررسی می کنیم.

مرحله ششم – بررسی کلاستر

در این مرحله وضعیت گره ها یا سرور های متصل به سرور master را در سرور master را بررسی می کنیم. ابتدا به سرور master متصل می شویم :

سپس دستور زیر را برای بررسی وضعیت سرور اجرا کنید :

خروجی باید مشابه زیر باشد :

اگر وضعیت STATUS سرور ها در حالت ready بود ، به این معنی است که این قسمت از سرور به درستی کار می کند و آماده انجام کارها می باشند.

و اگر هر وضعیت STATUS هر سروری در حالت NotReady باشد به این معنی است که تنظیمات آن سرور هنوز تمام نشده است. حدود ۵ تا ۱۰ دقیقه قبل از اجرای مجدد دستور kubectl get node صبر کنید ، سپس مجددا خروجی را بررسی کنید. اگر هنوز وضعیت سرور ها NotReady بود ، باید دستورات مراحل قبل را مجددا بررسی و اجرا کنید.

مرحله هفتم – اجرای یک برنامه در کلاستر

اکنون می توانید هر برنامه ای که نیاز به مخزن دارد را اجرا کنید. برای نمونه برنامه Nginx را بر روی کلاستر اجرا می کنیم. در سرور master دستور زیر را برای ایجاد یک deployment از  nginx وارد کنید :

سپس برای ایجاد یک سرویس با نام nginx برای در اختیار عموم قرار دادن این برنامه ، دستور زیر را وارد کنید. این کار از طریق NodePort انجام می شود ، به این صورت که یک پورت دلخواه را برای اتصال به یک pod در یک سرور دیگر باز می کند :

دستور زیر را اجرا کنید :

خروجی این دستور مانند زیر است :

همانطور که در خروجی مشاهده می کنید Nginx بر روی پورت ۸۰ کار می کند. Kubernetes یک پورت تصادفی بالاتر از ۳۰۰۰۰ که مطمئن است به سرویس دیگری تعلق نگرفته است را به این برنامه می دهد.

برای بررسی صحت عملکرد آدرس http://worker_1_ip:nginx_port یا http://worker_2_ip:nginx_port را در مرورگر سرور محلی خود وارد کنید. در این قسمت باید صفحه Nginx را مشاهده کنید.

برای حذف برنامه Nginx ابتدا سرویس Nginx را از سرور master حذف کنید :

دستور زیر را وارد کنید تا از حذف شدن برنامه مطمئن شوید :

خروجی باید مشابه زیر باشد :

سپس deployment را حذف کنید :

برای توضیح تمامی جزئیات تنظیمات انجام شده و آشنایی مختصر با مفاهیم مطرح شده شرح این آموزش را این صفحه مطالعه کنید.

آموزش نصب و استفاده از پایگاه داده PostgreSQL در لینوکس Ubuntu 16.04

آموزش نصب و استفاده از پایگاه داده PostgreSQL در لینوکس Ubuntu 16.04

How To Install and Use PostgreSQL on Ubuntu 16.04

 

 

معرفی

سیستم مدیریت پایگاه داده رابطه ای جزء اصلی وب سایت ها و برنامه های کاربردی هستند. این سیستم ها یک روش ساختاری را برای ذخیره سازی ، سازمان بندی و دسترسی به اطلاعات را فراهم می کنند. در این آموزش به روش نصب و استفاده از سیستم مدیریت پایگاه داده PostgreSQL در توزیع لینوکس Ubuntu 16.04 می پردازیم و در ادامه ، استفاده عمومی و دستور های  پایه از این پایگاه داده را بیان می کنیم.

مشاهده خلاصه آموزش و دستور ها 

PostgreSQL یا Postgre یک سیستم مدیریت پایگاه داده رابطه ای است که یک پیاده سازی از زبان پرس و جو SQL Query می باشد. PostgreSQL  یک پایگاه داده بسیار محبوب برای پروژه های کوچک و بزرگ است و مزیت آن سازگاری با استاندارد ها است و دارای ویژگی های پیشرفته مانند ارتباطات پایدار با دیتابیس و همزمانی بدون خواندن قفل ها است.

دانلود فایل PDF این آموزش

نصب PostgreSQL

خوشبختانه مخازن پیش فرض Ubuntu شامل بسته های Postgres هستند و با ابزار مدیریت بسته های apt به راحتی می توانیم آن را نصب کنیم. از آنجایی که در این آموزش اولین بار است که از apt استفاده می کنیم ، نیاز است که اطلاعات بسته های آن را به روز کنیم ، سپس می توانیم بسته Postgre و بسته های contrib- را که برای اضافه کردن برخی ابزارها و عملکرد ها است را نصب کنیم :

پس از نصب برنامه می توانیم به نحوه استفاده از آن بپردازیم و همچنین بررسی کنیم که چه تفاوت هایی که با سیستم های مدیریت پایگاه داده های مشابه دیگر دارد و چطور از آن ها استفاده کنیم.

 

استفاده از نقش ها و دیتابیس ها – Using PostgreSQL Roles and Databases

به صورت پیش فرض PostgreSQL از مفهومی به نام نقش ها “Roles” برای مدیریت احراز هویت و مجوزهای دسترسی استفاده می کند. که به نوعی شبیه به حسابهای معمولی یونیکس هستند ، ولی بین کاربران و گروه ها تمایز قائل نیست و PostgreSQL به جای آن ، واژه ی انعطاف پذیر تر “Roles” را ترجیح می دهد.

نقش ها یا همان Role ها شامل مجوز های دسترسی هستند که به یک یا چند کاربر یا گروه متصل می شوند و سطح دسترسی کاربر پس از ورود طبق مجوز های تعریف شده در این نقش ها تعریف می شود.

همراه با نصب Postgres احراز هویت ident نیز راه اندازی می شود ،که نقش های Postgres را به کاربران سیستم ماشین لینوکس/یونیکس متصل می کند. اگر یک نقش در Postgres وجود داشته باشد ، کاربر ماشین لینوکس با همان نام کاربری می تواند با آن نقش وارد شود.

چند روش برای ورود برای استفاده از کاربران تعریف شده لینوکس برای استفاده از Postgres وجود دارد.

 

ورود به حساب کاربری postgres

در فرآیند نصب یک کاربر با نام postgres ساخته می شود که به نقش پیش فرض Postgres متصل است. با دستور زیر می توانید به این کاربر منتقل یا جا به جا شوید :

با دستور زیر می توانید به خط فرمان Postgres دسترسی داشته باشید :

با این روش می توانید به سیستم وارد شوید و با مدیریت پایگاه داده ارتباط برقرار کنید.

برای خروج از خط فرمان PostgreSQL نیز از دستور زیر استفاده کنید :

بعد از اجرای این دستور باید به محیط خط فرمان لینوکس برگردانده شوید.

دسترسی به خط فرمان Postgres بدون انتقال کاربر

همچنین می توانید دستور مورد نظرتان را مستقیما با کاربر postgres و با sudo اجرا کنید. در مثال قبل که می خواستیم خط فرمان postgres برسیم ، در یک مرحله با وارد کردن دستور psql با کاربر postgres و با sudo ، می توانیم این کار را انجام دهیم :

به این شکل مستقیما و بدون واسطع پوسته shell ، وارد خط فرمان postgres می شوید.

همچنین با دستور زیر می توانید از نشست postgres فعالی که در آن هستید خارج شوید :

 

ایجاد یک نقش جدید

در حال حاضر فقط یک نقش postgres در پایگاه داده وجود دارد. با دستور createrole می توانیم نقش یا Role جدید ایجاد کنیم. گزینه interactive– مقادیر مورد نیاز را از شما می گیرد.

اگر با کاربر postgres وارد شدید برای ساخت نقش جدید ، دستور زیر را وارد کنید :

اگر به جای تغییر کاربر ترجیح می دهید که از sudo استفاده کنید ، دستور زیر را وارد کنید :

در ادامه اجرای اسکریپت ، از شما سئوالاتی را می پرسد که با پاسخ مناسب مشخصات نقش جدید را تنظیم می کنید :

همچنین با مطالعه راهنما man این دستور ، می توانید اطلاعات بیشتری در مورد گزینه های دیگر این دستور بدست آورید :

ساخت یک دیتابیس جدید

به صورت پیش فرض ، سیستم احراز هویت Postgres در نظر می گیرد که یک دیتابیس هم نام با نام نقش یا Role ایجاد شده وجود دارد که آن نقش به دیتابیس متصل است و برای ورد از آن استفاده می کند.

پس در قسمت قبل که یک کاربر با نام sammy ایجاد کردیم ، باید یک دیتابیس با نام sammy ایجاد کنیم که نقش یا Role کاربر sammy به آن دسترسی داشته باشد. برای ایجاد دیتابیس جدید از دستور createdb استفاده می کنیم :

اگر با کاربر postgres وارد شده اید دستور زیر را وارد کنید :

و اگر مانند قبل می خواهید که بدون تغییر کاربر و با sudo دستور را وارد کنید به شکل زیر این کار را انجام دهید :

 

باز کردن خط فرمان با نقش جدید

برای وارد شدن به سیستم احراز هویت ident باید یک کاربر لینوکسی هم نام با نقش و دیتابیس ایجاد شده داشته باشید. اگر کاربری با این نام ندارید با دستور adduser می توانید یک کاربر جدید در لینوکس بسازید. برای اجرای این دستور باید دسترسی کاربر با مجوز sudo را داشته باشید ( کاربری به غیر از postgres ):

وقتی که کاربر مورد نظر را ایجاد کردید با این می توانید با دستور زیر با کاربر جدید وارد شوید :

همچنین این دستور را می توانید وارد کنید :

با فرض اینکه همه چیز درست تنظیم شده است ، شما وارد سیستم می شوید. اگر می خواهید به دیتابیس دیگری متصل شوید به صورت زیر آن را مشخص کنید :

پس از اتصال ، با دستور زیر می توانید اطلاعات اتصال خود را بررسی کنید :

اگر با کاربر یا دیتابیس پیش فرض وارد نشده این ، این اطلاعات می تواند مفید باشد.

 

ایجاد و حذف جداول

اکنون با یاد گرفتن وارد شدن به PostgreSQL و اتصال به دیتابیس ، می توانیم وظایف اصلی دیگری را انجام دهیم. در ابتدا یک جدول برای ذخیره برخی داده ها ایجاد می کنیم.

دقت کنید که در ابتدا باید به PostgreSQL وارد شوید و همانطور که قبلا گفتیم ، دیتابیس مورد نظر را انتخاب کنید سپس اقدام به ایجاد جدول در آن دیتابیس کنید.

برای شروع یک جدول ایجاد می کنیم که اطلاعات یک زمین بازی را ذخیره می کند. شکل عمومی دستور برای این کار شبیه زیر است :

همانطور که می بینید یک نام برای جدول انتخاب کردیم و ستون هایی که می خواستیم را تعریف کردیم ، همچنین نوع ستون و بیشترین طول هر رشته داده را تعیین کردیم. همچنین برای هر ستونی که بخواهیم به صورت دلخواه می توانیم محدودیت هایی را قرار دهیم.

برای مثال ما ، دستورات گفته شده را به صورت زیر وارد می کنیم :

اکنون یک زمین بازی را با مشخصات مد نظرمان ایجاد کردی که این مشخصات با یک ID از نوع serial شروع می شود. نوع داده serial ، به صورت افزایش خودکار ، یک عدد integer را اختصاص می دهد. همچنین این ستون را به صورت primery key تعریف کردیم ، و این یعنی اینکه این ستون حتما باید مقدار داشته باشد و حتما باید منحصر به فرد بوده و تکراری نباشد.

مقدار بیشترین طول را برای دو تا از ستون ها ( equip_id و install_date ) تعیین نکردیم ، به این دلیل که محدودیت اندازه طول به صورت ضمنی در نوع داده ای این ستون ها تعریف شده است.

برای ستون های type و color نیز مشخص کردیم که نباید خالی باشند و حتما باید دارای مقدار باشند. یک ستون با نام location ایجاد کردیم و مقادیر آن را محدود به هشت مقدار ممکن که برای آن تعریف شده ، محدود شده است ، به این صورت که فقط یکی از این هشت مقدار باید باشد. آخرین ستون نیز برای تاریخ است که هنگام ایجاد مشخصات زمان سیستم را گرفته و ذخیره می کند.

جدول جدید ایجاد شده را به صورت زیر می توانیم مشاهده کنیم :

زمین بازی که ایجاد کردیم را می توانید مشاهده کنید ، ولی چیز دیگری با نام playground_equip_id_seq و نوع داده sequence را مشاهده می کنید ، که این جدول نماینده نوع داده serial است که برای ستون equip_id تعیین کردیم. این جدول به صورت خودکار برای ستون هایی از نوع serial ایجاد می شود  و یک دنباله عددی را ایجاد می کند و شماره بعدی این سری را نگهداری می کند.

اگر می خواهید که جدول را بدون دنباله مشاهده کنید ، دستور زیر را وارد کنید :

 

اضافه کردن ،گزارش گرفتن و حذف داده در جدول

اکنون یک جدول داریم که می توانیم داده هایی را به آن اضافه کنیم. در ادامه می خواهیم که یک تاب و یک سرسره به این جدول اضافه کنیم. برای این کار باید نام جدولی را که می خواهیم به آن داده اضافه کنیم را فراخوانی می کنیم ، سپس نام ستون ها را انتخاب می کنیم و داده هایی که به هر ستون باید اضافه شود را قرار می دهیم. تاب و سرسره ای که می خواهیم اضافه کنیم به صورت زیر است :

دقت کنید که هنگام وارد کردن داده ها از اشتباهات رایج جلوگیری کنید. مثلا نام ستون ها نباید در کوتیشن قرار گیرند ولی داده ها باید در کوتیشن قرار داشته باشند.

نکته مهم دیگر این که به ستون equip_id نباید مقدار بدهید. زیرا هر ردیف جدید که در جدول ایجاد می شود این ستون به صورت خودکار مقدار دهی می شود.

با وارد کردن دستور زیر می توانید اطلاعاتی که وارد کرده اید را مشاهده کنید :

در اینجا مشاهده می کنید که ستون equip_id به درستی مقدار دهی شده و بقیه داده ها نیز به درستی در ستون های خود قرار دارند.

اگر در زمین بازی ، سرسره خراب شود و بخواهیم آن را حذف کنیم ، با دستور زیر اطلاعات آن را از جدول حذف می کنیم :

اگر مجددا از جدول گزارش بگیریم ، مشاهده می کنید که دیگر سرسره وجود نخواهد داشت :

چطور ستون های یک جدول اضافه و حذف کنیم

بعد از ساختن یک جدول به راحتی می توانیم ستونی را به آن اضافه کنیم. برای مثال یک ستون که نشان دهنده آخرین بازدید تعمیرات و نگهداری هر وسیله است را با دستور زیر اضافه می کنیم :

اگر مجددا از جدول گزارش بگیرید ، مشاهده می کنید که ستون جدید اضافه شده است ( اما داده ای در آن وجود ندارد ) :

Output

برای حذف یک ستون نیز به راحتی می توانیم این کار را انجام دهیم. فرض کنید که کارمندان زمین بازی از ابزار دیگری برای نگهداری تاریخچه زمان های بازدید تعمیرات و نگهداری استفاده می کنند و دیگر نیازی به این ستون نیست. با دستور زیر این ستون را حذف می کنیم :

 

چطور داده های یک جدول را به روز رسانی کنیم

الان می دانیم که چطور ردیف ها را به یک جدول اضافه و حذف کنیم ولی درباره تغییر و یا اصلاح ورودی های موجود صحبت نکردیم. بوسیله یک پرس و جو یا Query بر روی تنظیمات یک ردیف ای که می خواهید از مقدار آن استفاده کنید ، می توانید مقدار ورودی موجود را به روز رسانی کرده و آن را تغییر دهید.

برای مثال یک کوئری Query بر روی ردیف swing انجام می دهیم ( این تغییر برای تمام ردیف هایی که مقدار swing در جدول دارد اعمال می شود ) و رنگ آن را به red تغییر می دهیم. برای این کار به صورت زیر عمل می کنیم :

با گزارش گیری از جدول ، صحت عملکرد دستور را مشاهده می کنیم :

همانطور که مشاهده می کنید رنگ تاب به قرمز تغییر کرده است.

 

پایان

در این مطلب به نصب و راه اندازی پایگاه داده PostgreSQL بر روی Ubuntu 16.04 پرداختیم و دستورات و نحوه کار کردن با آن را به صورت عمومی و پایه ای بیان کردیم. مطالب بسیار زیاد دیگری برای یادگیری PostgreSQL وجود دارد که سعی می کنیم در مطالب بعدی آن ها را عنوان کنیم.

مفهوم Pod در kubernetes چیست و چطور کار می کند

مفهوم Pod در kubernetes چیست و چطور کار می کند

What is pod on kubernetes and how it works

 

درک مفهوم Pod ها

یک Pod پایه ای ترین قسمت Kubernetes است و همچنین کوچکترین و ساده ترین قسمت از مدل اشیاء Kubernetes است ، که می توان آن را ایجاد کرد و توسعه داد. یک Pod نمایانگر پردازش در حال اجرا در کلاستر می باشد. اگر با Kubernetes و نصب و راه اندازی آن اطلاعات کافی ندارید ، صفحه مربوطه به آموزش راه اندازی Kubernetes را مطالعه کنید. 

یک Pod ، یک مخزن application ( و در برخی موارد چندین مخزن ) ، منابع ذخیره ساز ، یک آدرس IP منحصر به فرد و گزینه هایی که مشخص می کنند مخزن ها چطور اجرا شوند را ، کپسوله می کند. یک Pod نشان دهنده یک قسمت از توسعه است : یک نمونه کوچک از یک برنامه Kubernetes که یا حاوی یک مخزن است و یا شامل چند مخزن وابسته به یکدیگر است و این منابع به اشتراک گذاشته می شود.

Pod ها از تمامی مخازن زمان اجرا به خوبی پشتیبانی می کنند و Docker که محبوب ترین مخزن زمان اجرا است نیز از Kubernetes Pods استفاده می کند.

از Pod ها در کلاسترینگ Kubernetes به دو روش استفاده می شود :

  1. Pod های شامل یک مخزن : “one-container-per-Pod” محبوب ترین حالت مورد استفاده دز Kubernetes است. در این حالت فرض کنید که یک مخزن بسته بندی شده است و Kubernetes به جای استفاده مستقیم از مخزن از Pod استفاده می کند.
  2. Pod های شامل چند مخزن که برای کار کردن به یکدیگر نیاز دارند : یک Pod می تواند شامل یک برنامه چند مخزن مورد نیاز به صورت محلی باشد که این مخزن ها به شدت به یکدیگر وابسته هستند ، و همه این ها در یک Pod به اشتراک گذاشته شده اند. این مخزن هایی که به صورت محلی بسته بندی شده اند به صورت یک واحد یکپارچه مانند یک مخزن از فایل های منابع به اشتراک گذاشته شده به صورت عمومی سرویس دهی می کنند ، در حالی که یک مخزن جداگانه این فایل ها را به روز رسانی و مجدد بازخوانی می کند. Pod این مخازن و ذخیره ساز های به اشتراک گذاشته شده را بسته بندی کرده و یک موجودیت جدید با قابلیت مدیریت ارائه می کند.

هر Pod به معنای اجرای یک نمونه برنامه تعیین شده است. اگر می خواهید چندین برنامه را به صورت موازی و همزمان اجرا کنید ، باید برای هرکدام یک Pod را اجرا کنید. در Kubernetes به این کار replication گفته می شود. Replicates Pod ها معمولا به صورت گروهی و به وسیله مفهومی به نام Controller ایجاد و مدیریت می شوند. برای اطلاعات  بیشتر Pod ها و Controller ها را مطالعه کنید.

چطور Pod ها چندین مخزن را کنترل می کنند

Pod ها برای تبدیل چندین پردازش وابسته به یکدیگر ( مانند مخازن ) و ارائه آنها به صورت یک سرویس یکپارچه طراحی شده است. مخازن موجود در Pod به صورت خودکار و به صورت محلی و زمان بندی شده بر روی یک ماشین مجازی یا کلاستر کار می کنند. این مخزن ها منابع و پیش نیازهایشان را به اشتراک می گذارند و با یکدیگر در ارتباط هستند و به صورت هماهنگ با یکدیگر تا خاتمه کار همکاری دارند.

دقت کنید که این مورد استفاده از چندین مخزن که به صورت محلی بهم متصل هستند و مدیریت می شوند یک حالت نسبتا پیشرفته است. از این حالت باید در موارد خاص که مخزن ها به شدت به یکدیگر وابسته هستند استفاده کنید. برای مثال ممکن است که شما یک مخزن داشته باشید که به عنوان یک وب سرور برای فایل های به اشتراک گذاشته شده در یک منبع ، سرویس دهی می کند و یک مخزن جداگانه دیگری داشته باشید که با استفاده از منابع دیگر و راه دور این فایل ها را تغییر داده و به روز رسانی می کنند ، مانند نمودار زیر :

Kubernetes Pod Diagram

نمودار Pod :

Pod ها دو منبع مشترک را برای مخزن های تشکیل دهنده آن ارائه می کند : شبکه و ذخیره ساز.

شبکه

هر Pod یک آدرس IP منحصر فرد را به خود اختصاص می دهد. هر مخزن در هر Pod محیط شبکه خود را که شامل آدرس IP و پورت شبکه است را به اشتراک می گذارد. مخزن های داخل Pod با یکدیگر از طریق localhost در ارتباط هستند. هر زمان که مخزن های داخل یک Pod بخواهند با یک موجودیت خارج از Pod ارتباط برقرار کنند باید از منابع به اشتراک گذاشته شده استفاده کنند.

ذخیره ساز

یک Pod می تواند مجموعه از ذخیره سازهای به اشتراک گذاشته را داشته باشد. همه مخزن های داخل Pod می توانند به ذخیره سازهای به اشتراک گذاشته شده دسترسی داشته باشند و همچنین می توانند اجازه دسترسی به داده های به اشتراک گذاشته شده را نیز داشته باشند. همچنین می توان دسترسی دائم و خودکار به ذخیره سازهای مشترک داد تا اگر مخزنی نیاز به راه اندازی مجدد داشت این دسترسی از بین نرود.

کار کردن با Pod ها

Pod ها برای اهداف و مصارف نسبتا کوتاه مدت طراحی شده اند و به همین دلیل به ندرت پیش می آید که Pod های تکی در Kubernetes ایجاد کنید. هنگامی که یک Pod ایجاد می شود ( چه مستقیما توسط خودتان یا غیر مستقیم توسط Controller ) برنامه ریزی می شود تا در یک گره یا Node در کلاستر اجرا شود و در همان Node تا زمان اتمام پردازش ، حذف شدن Pod ، خارج کردن Pod از گره به علت کمبود منابع و یا بروز خطا در گره ، باقی می ماند.

نکته : راه اندازی مجدد یک مخزن داخل Pod نباید با راه اندازی مجدد خود Pod اشتباه گرفته شود. یک Pod خودش اجرا نمی شود ولی یک زیرساختی را فراهم می کند که مخزن ها تا زمانی که حذف نشده اند در آن اجرا می شوند.

Pod ها حالت خود درمانی یا خود ترمیمی ندارند و اگر وقتی زمان بندی شده اند که در یک گره کار کنند ، دچار مشکل شوند ، Pod ها حذف می شوند. به همین ترتیب اگر گره ای دچار مشکل کمبود منابع شود و یا برای رفع مشکل در حالت تعمیرات قرار گیرد ، Pod ها حذف خواهند شد. Kubernetes از کی مفهموم سطح بالایی به نام Controller استفاده می کند که تا حدودی کارهایی که Pod ها باید انجام دهند را مدیریت می کنند. این حالت استفاده Kubernetes از Controller ها برای مدیریت Pod ها بسیار رایج است.

Pod ها و Controller  ها

یک Controller می تواند چندین Pod را ایجاد و مدیریت کند ، مدیریت Replication ها و برنامه ریزی ها و حالت خود تعمیری در کلاستر. برای مثال اگر یک گره دچار خطا شود ، به صورت خودکار یک گره یکسان دیگر را جایگزین می کند.

قالب های Pod

قالب های Pod ها مشخصات فنی آن ها هستند و شامل عناصر دیگر مانند Replication Controllers, Jobs, و DaemonSets می شوند. Controller ها با استفاده از قالب ها Pod ها رو ایجاد می کنند. در زیر یک مثال روشن از یک Pod آورده شده که شامل یک مخزن است که یک پیغام را چاپ می کند :

قالب Pod ها علاوه بر مشخص کردن وضعیت فعلی از همه حالت ها ، مانند یک قالب کیک عمل می کنند. قالب کیک یک کیک را شکل می دهد و هیچ رابطه ای با آن کیک ندارد. تغییرات بعدی قالب حتی انتقال به یک قالب جدید، روی Pod هایی که تا الان ایجاد شده اند تاثیر مستقیمی ندارند. به بیان ساده تر Pod ها توسط یک replication controller ها که متعاقبا به روز رسانی خواهند شد ، ایجاد می شوند و مشخص کردن وضعیت فعلی همه مخزن های متعلق به Pod ها یک عملکرد منطقی است.  

آموزش نصب و راه اندازی کلاسترینگ Kubernetes با Kubeadm در لینوکس Ubuntu 16.04

آموزش نصب و راه اندازی کلاسترینگ کوبرنیتیس Kubernetes 1.10 با Kubeadm در لینوکس Ubuntu 16.04

How To Create a Kubernetes 1.10 Cluster Using Kubeadm on Ubuntu 16.04

مقدمه

کوبرنیتیس Kubernetes یک سیستم مدیریت مخازن است که به صورت متن باز و رایگان می باشد. این پروژه توسط گوگل و بر اساس تجربیات اجرای مخازن در محصولات ایجاد شده است. در این آموزش به نحوه نصب ، راه اندازی و تنظیمات کلاسترینگ Kubernetes بر روی لینوکس Ubuntu می پردازیم. این آموزش یک آموزش حرفه ای است و برای نصب Kubernetes از Kubeadm و برای تنظیمات سرور های موجود در کلاستر از Ansible استفاده می کنیم.

مشاهده خلاصه آموزش و دستورات این آموزش

از Kubeadm برای نصب ، پیکربندی و خودکارسازی اجزای Kubernetes مانند API های سرور  ، Controller Manager و Kube DNS استفاده می شود. این برنامه کارهایی مثل ایجاد کاربر یا مدیریت مراحل نصب سیستم عامل و تنظیمات آن ها را انجام نمی دهد و برای این کار ها ممکن از ابزارهای مدیریت پیکربندی مانند Ansible یا SaltStack استفاده شود. از ابزار Kubeadm ایجاد کلاستر ها یا بازسازی آنها به سادگی و با کمترین خطا استفاده می شود.

دانلود فایل PDF این آموزش

اهداف

در این آموزش برای کلاسترینگ از سرور های زیر استفاده می کنیم :

  • یک سرور برای Master Node

این سرور مسئولیت مدیریت کلاستر را دارد. در این سرور  Etcd اجرا می شود که اطلاعات کلاستر مربوط به تقسیم بار کاری بین سرور ها را ذخیره می کند.

  • دو سرور برای Worker Node ها

سرور هایی هستند که کلاستر و تقسیم بار بر روی آنها انجام می شود( مانند برنامه ها و سرویس های مخازن ها ). وظایف Worker ها توسط سرور Master تقسیم بندی و زمان بندی شده و با آن ها داده می شود ، و یک سرور  worker ، وظیفه ای که به آن داده شده است را تا زمانی که Master زمان بندی کرده است انجام می دهد. با اضافه کردن سرور های worker می توان ظرفیت کلاستر را افزایش داد.

بعد از اتمام این آموزش یک کلاستر برای اجرای برنامه های مخازن داریم که منابع RAM و CPU مورد نیاز برای اجرای برنامه ها را با سرور های متعدد تامین می کند. تقریبا تمامی برنامه ها و سرویس های مبتنی بر لینوکس ، مانند برنامه های تحت وب ، پایگاه داده ، سرویس ها و ابزارهای دستورات خط فرمان ، در کلاسترینگ Kubernetes قابل اجرا هستند. خود کلاستر نیز حدود ۵۰۰-۳۰۰ MB از حافظه RAM و ۱۰ درصد از CPU را مصرف می کند.

در این آموزش وقتی کلاستر راه اندازی راه اندازی کردیم ، یک وب سرور Nginx را نصب می کنیم تا مطمئن شویم که همه چیز درست است.

پیش نیاز ها

  • کلید SSH که بر روی هر دو سرور محلی تنظیم شده است. این کلید در تنظیمات سرور ها برای برقرار ارتباط بین سرور ها قرار می گیرد و اگر تا الان با کلید های SSH کار نکرده اید از این آموزش می توانید استفاده کنید.
  • سه سرور Ubuntu16.04 با حداقل یک گیگ رم که تنظیمات SSH با کلید روی آن انجام شده باشد.
  • برنامه Ansible بر روی سرورهای مجازی محلی نصب شده باشد. برای آشنایی با نصب Ansible صفحه آموزش نصب و پیکربندی Ansible در Ubuntu را مطالعه کنید.
  • آشنایی با Ansible Playbooks ها . برای آشنایی با Playbook های Ansible صفحه آموزش مدیریت پیکربندی و نوشتن Playbook های Ansible را مطالعه کنید.  
  • دانش راه اندازی یک مخزن با داکر Docker. مرحله پنجم از آموزش نصب داکر در اوبونتو را مرور کنید.

مرحله اول – تنظیم دایرکتوری فضای کار و فایل فهرست Ansible

در این مرحله یک دایرکتوری برای سرویس دهی فضای کاری یا همان Workspace ایجاد می کنیم و تنظیمات Ansible را به صورت محلی یا Local انجام می دهیم تا بتوانیم با سرور ها به صورت ارتباط راه دور یا Remote ارتباط برقرار کنیم و دستورات خط فرمان را اجرا کنیم. برای انجام این کار یک فایل با نام hosts که شامل اطلاعات سرورها از قبیل آدرس IP ها و گروه های سرور های هستند را ایجاد می کنیم.

در این آموزش سه سرور داریم که یکی از این سه سرور ، سرور master مان است که IP آن را با master_ip نشان می دهیم و آدرس IP دو سرور دیگر که به عنوان worker هستند را با نام های worker_1_ip و worker_2_ip نمایش می دهیم.

یک دایرکتوری با نام kube-cluster/~ در مسیر home ایجاد کنید و وارد آن شوید :

این دایرکتوری ، فضای کاری  ما یا همان Workspace در این آموزش خواهد بود و شامل playbook های Ansible است و تمام دستورات خط فرمان مربوط به این سرور را در این دایرکتوری وارد می کنیم.

ایجاد یک فایل با نام kube-cluster/hosts/~ با ابزار nano یا ویرایشگر متن مورد نظرتان :

خطوط زیر را در این فایل وارد کنید و مقادیر گفته شده را با مقادیر مناسب جایگزین کنید. منظور مقادیر master_ip و worker_1_ip و worker_2_ip می باشد :

اطلاعات این فایل ، دارایی ها یا همان اطلاعات سرور ها خواهند بود که شامل اطلاعاتی از قبیل آدرس IP ، نام کاربری کاربرانی که از راه دور به صورت Remote متصل می شوند و نام گروه های سرور ها می باشد ، که در اینجا شامل گروه سرور های masters و workers می باشد که از این فایل و اطلاعات در قسمت های دیگر استفاده می کنیم.

در گروه masters ، یک سرور وجود دارد که با نام master مشخص شده با آدرس IP و نام کاربر راه دور که Ansible باید برای اجرای دستورات خود را از آن استفاده کند که در اینجا کاربر root مشخص شده است.

به همین ترتیب ، در گروه workers ، دو سرور worker با آدرس های worker_1_ip و worker_2_ip و کاربر ansible_user مشخص شده اند.

خط آخر نیز برای مدیریت عملیات ها از راه دور است ، برنامه Ansible مشخص شده است که از مترجم Python 3 در سرور ها استفاده کند.

در انتها نیز بعد از ویرایش فایل و اطمینان از صحت اطلاعات آن ، فایل را ذخیره کرده و خارج شوید.

تا اینجا لیست مشخصات سرور ها را تکمیل کردیم ، در ادامه مراحل نصب به موارد مورد نیاز سیستم عامل و پیکربندی تنظیمات می پردازیم.

مرحله دوم – ایجاد کاربر در سرور های متصل

در این قسمت بر روی سرور ها یک کاربر عادی بدون دسترسی ریشه non-root user ایجاد می کنیم ولی این کاربر ها باید عضو گروه sudo باشند تا بتوان بوسیله این کاربر ها از طریق اتصال SSH با سرور ارتباط برقرار کرد. این کار برای زمان هایی که می خواهید اطلاعات سیستم را با دستوراتی مانند top/htop مشاهده کنید و لیستی از منابع در حال اجرا را مشاهده کنید یا تغییراتی را در تنظیمات فایل هایی که مالک آن root است ، تغییر دهید بسیار مفید است.

هر چند که این کارها را به صورت مرتب در طول نگهداری کلاستر انجام خواهیم داد ، و استفاده از یک کاربر عادی non-root ریسک عملیات هایی مانند ویرایش یا حذف فایل ها و عملیات هایی که ناخواسته انجام می شود را کاهش می دهد.

یک فایل با نام  kube-cluster/initial.yml/~ در فضای کاری Workspace ایجاد کنید :

در ادامه متن زیر را که play نامیده می شود، در فایل قرار دهید تا کاربر مورد نظر در تمام سرور ها ایجاد شود. یک play در Ansible مجموعه ای از مراحلی است که مشخصات سرور ها و گروه های مشخصی را تهیه می کند. Play زیر یک کاربر non-root ایجاد می کند :

توضیحات اینکه این play چکار می کند :

  • ایجاد یک کاربر non-root با نام ubuntu
  • تنظیم فایل sudoers برای اجازه اجرای دستورات sudo بدون درخواست رمز عبور برای کاربر ubuntu
  • اضافه کردن کلید عمومی ماشین محلی به لیست کلید های مجاز کاربر ریموت ubuntu. با این کار اجازه اتصال SSH به هر سروری داده می شود.

این فایل را ذخیره کرده و خارج شوید.

در ادامه این playbook را اجرا می کنیم :

این دستور بین دو تا ۵ دقیقه اجرا می شود ، و پس از کامل اجرا شدن دستور خروجی مشابه زیر نمایش داده می شود :

تا اینجا تنظیمات مقدماتی انجام شده و می توانید به نصب پیش نیاز های کوبرنیتیس Kubernetes بپردازید.

مرحله سوم – نصب پیش نیاز های kubernetes

در این قسمت باید پکیج های مورد نیاز Kubernetes در سیستم عامل را بوسیله apt که ابزار مدیریت بسته های Ubuntu است ، نصب کنیم.  این پکیج ها به صورت زیر هستند :

  • Doker – یک مخزن زمان اجرا می باشد، که شامل اجزای مورد نیاز مخازن شما می باشد. همچنین مخازن دیگر مانند rkt را پشتیبانی می کند.
  • kubeadm – یک ابزار خط فرمان برای نصب و پیکربندی اجزای مختلف کلاستر به صورت استاندارد می باشد.
  • kubelet – یک برنامه سیستمی و یک سرویس است که برای مدیریت گره ها Nodes و عملیات ها می باشد.
  • kubectl – یک ابزار خط فرمان برای ارسال دستورات به کلاستر ها از طریق API Server می باشد.

نصب این بسته ها به صورت دستی و یکی یکی بر روی همه سرورهای کلاستر زمانبر است و به همین دلیل از Ansible برای این کار استفاده می کنیم و برای این کار باید یک Playbook دیگر تنظیم کنیم.

یک فایل با نام kube-cluster/kube-dependencies.yml/~ در مسیر فضای کاری ایجاد کنید :

سپس play زیر را برای نصب پکیج ها در سرور ها وارد کنید :

این play به صورت زیر کار می کند :

  • نصب داکر
  • نصب apt-transport-https ، اضافه کردن منابع HTTPS خارجی به لیست منابع APT
  • اضافه کردن apt-key برای تایید کلید منابع Kubernetes APT
  • نصب kubelet و kubeadm

دومین play فقط یک وظیفه را انجام می دهد و آن هم نصب kubectl بر روی سرور master می باشد.

بعد از اتمام کار فایل را ذخیره کرده و خارج شوید و Playbook را اجرا کنید :

بعد از اتمام اجرای این فایل خروجی مشابه زیر را مشاهده می کنید :

بعد از نصب داکر ، kubeadm و kubelet بر روی سرور ها ، برای اجرای kubectl چیز خاصی مورد نیاز نیست و فقط باید دستورات کلاستر را اجرا کنید. این مسئله خیلی مهم و حساس است ، که kubectl فقط بر روی سرور master نصب شده باشد و دستورات kubectl فقط از سرور master داده شود. به این نکته دقت کنید که kubectl بر روی هر ماشین مجازی که در کلاستر باشد می تواند نصب شود و دستورات کلاستر را اجرا کند.

خوب تا اینجا پیش نیاز ها نصب شده اند و در ادامه به سراغ نصب و تنظیم سرور master و راه اندازی اولیه کلاستر می رویم.

مرحله چهارم – تنظیم سرور Master

در این مرحله تنظیمات سرور master را انجام می دهیم. قبل از شروع تنظیمات و ایجاد playbook های جدید کمی درباره برخی اصطلاحات مانند Pods و Pods Networking Plugins صحبت می کنیم. برای آشنایی با Pod ها مطلب مفهوم Pod در kubernetes چیست و چطور کار می کند را مطالعه کنید.

هر Pod آدرس IP برای خود دارد ، و هر pod در هر سرور باید بتواند از طریق آدرس IP آن pod در سرور دیگر به آن متصل شود. مخازنی که بر روی یک سرور هستند براحتی بوسیله رابط های محلی ارتباط برقرار می کنند. ارتباط بین pod ها پیچیده است و نیاز به یک شبکه جداگانه دارد که مسیر شفاف از یک pod به یک pod در یک سرور دیگر مشخص شده باشد.

این کار توسط پلاگین شبکه pod انجام می شود. در این آموزش از Flannel استفاده می کنیم که یک گزینه پایدار و مناسب است.

یک Ansible playbook با نام master.yml ایجاد کنید :

متن play زیر را برای نصب Flannel و مقدار دهی اولیه کلاستر وارد کنید :

 

توضیحاتی درباره این play :

  • اولین کاری که انجام می شود ، مقدار دهی اولیه کلاستر بوسیله kubeadm init است. تنظیم پارامتر –pod-network-cidr=10.244.0.0/16 ، که شبکه اختصاصی را برای pod مشخص می کند.
  • دومین کاری که انجام می شود، ایجاد دایرکتوری .kube در home/ubuntu/ است. در این دایرکتوری اطلاعات پیکربندی از قبیل فایل های کلید ادمین که برای اتصال کلاستر ها هستند و آدرس IP کلاستر ها نگهداری می شود.
  • سومین کاری که انجام می شود، کپی فایل etc/kubernetes/admin.conf/ که ubeadm init این فایل را با کاربر non-root در home ایجاد کرده است. این کار برای اجازه دسترسی kubectl به کلاستر های جدید ایجاد شده می باشد.
  • آخرین کار نیز اجرای kubectl apply برای نصب Flannel می باشد. مقدار [kubectl apply -f descriptor.[yml|json به kubectl اعلام می کند که یک شئ جدید که در فایل [descriptor.[yml|json توضیح داده شده است را ایجاد کند. فایل kube-flannel.yml شامل جزئیات شئ مورد نیاز برای تنظیم Flannel در کلاستر می باشد.

در انتها فایل را ذخیره کرده و خارج شوید.

فایل playbook را به صورت محلی Local اجرا کنید :

خروجی این دستور مشابه زیر است :

برای بررسی وضعیت سرور master از طریق ssh با دستور زیر به سرور متصل شوید :

پس از وارد شدن به سرور دستور زیر را اجرا کنید :

باید خروجی مشابه زیر را مشاهده کنید :

در سرور master تمامی تنظیمات و مقداردهی های اولیه انجام شده و وضعیت سرور در حالت ready و آماده برای شروع اتصال به سرور های worker و ارسال وظایف به آنها از طریق  API Server می باشد. اکنون می توانیم سرور های worker را اضافه کنیم.

مرحله پنجم – تنظیمات سرور های Worker

برای اضافه کردن گره worker یک دستور را باید اجرا کنید ، که شامل جزئیات مورد نیاز کلاستر از قبیل آدرس IP و پورت API سرور master می باشد و یک توکن امنیتی می باشد. فقط سروری که توکن را قبول می کند می تواند به کلاستر متصل شود.

به مسیر فضای کاری Workspace بروید و یک playbook به نام workers.yml ایجاد کنید :

متن زیر را در فایل قرار دهید :

توضیحات این playbook :

  • در ابتدا دستور اتصال اجرا می شود که باید در سرور worker وارد شود و قالب دستور به این صورت است : kubeadm join –token <token> <master-ip>:<master-port> –discovery-token-ca-cert-hash sha256:<hash>. این دستور با قرار دادن مقادیر token و hash تکمیل می شود.
  • قسمت دوم فقط دستور اتصال به گره ها یا سرور های worker را اجرا می کند که پس از تکمیل شدن این دستور هر دو سرور ، قسمتی از کلاستر خواهند بود.

فایل را ذخیره کرده و خارج شوید.

فایل playbook را اجرا کنید :

خروجی این اجرا مشابه زیر است :

با اضافه شدن سرور های worker کلاستر شما به صورت کامل تنظیم شده و آماده بهره برداری است و worker ها آماده اجرای بارهای کاری ارسالی هستند. قبل از زمان بندی برنامه ، صحت عملکرد کلاستر را بررسی می کنیم.

مرحله ششم – بررسی کلاستر

به ممکن است به دلایلی مانند از دسترس خارج شدن یک سرور worker یا خرابی ارتباط بین سرور های master و worker ، راه اندازی کلاستر با مشکل مواجه شود. در این قسمت بررسی می کنیم که کلاستر و سرور ها به درستی کار کنند.

در ابتدا وضعیت گره ها یا سرور های متصل به سرور master را در سرور master را بررسی می کنیم. ابتدا به سرور master متصل می شویم :

سپس دستور زیر را برای بررسی وضعیت سرور اجرا کنید :

خروجی باید مشابه زیر باشد :

اگر وضعیت STATUS سرور ها در حالت ready بود ، به این معنی است که این قسمت از سرور به درستی کار می کند و آماده انجام کارها می باشند.

و اگر هر وضعیت STATUS هر سروری در حالت NotReady باشد به این معنی است که تنظیمات آن سرور هنوز تمام نشده است. حدود ۵ تا ۱۰ دقیقه قبل از اجرای مجدد دستور kubectl get node صبر کنید ، سپس مجددا خروجی را بررسی کنید. اگر هنوز وضعیت سرور ها NotReady بود ، باید دستورات مراحل قبل را مجددا بررسی و اجرا کنید.

پس از اطمینان از صحت عملکرد کلاستر ، برنامه Nginx را به عنوان یک نمونه زمان بندی یا Schedule می کنیم.

مرحله هفتم – اجرای یک برنامه در کلاستر

اکنون می توانید هر برنامه ای که نیاز به مخزن دارد را اجرا کنید. برای نمونه برنامه Nginx را بر روی کلاستر اجرا می کنیم. از دستوراتی که در ادامه آورده می شوند می توانید برای اجرای هر برنامه دیگری استفاده کنید.

در سرور master دستور زیر را برای ایجاد یک deployment از  nginx وارد کنید :

deployment یک نوع از شئ Kubernetes می باشد که وجود همیشگی تعدادی pod در حال اجرا را در یک قالب تعریف شده تضمین می کند ، حتی اگر در زمان اجرای کلاستر pod از دسترس خارج شود. قبل از deployment یک pod با یک مخزن از داکر موجود در Ngingx Docker Image ایجاد می شود.

سپس برای ایجاد یک سرویس با نام nginx برای در اختیار عموم قرار دادن این برنامه ، دستور زیر را وارد کنید. این کار از طریق NodePort انجام می شود ، به این صورت که یک پورت دلخواه را برای اتصال به یک pod در یک سرور دیگر باز می کند :

بقیه سرویس هایی که از انواع شئ های Kubernetes هستند به صورت داخلی فعالیت می کنند و برای سرویس دهی به کاربران محلی و خارجی هستند. همچنین این سرویس ها می توانند عملیات تقسیم بار را در درخواست ها انجام دهند و جزو جدایی ناپذیر Kubernetes هستند که به صورت سلسله مراتبی با اجزای دیگر فعالیت می کند.

دستور زیر را اجرا کنید :

خروجی این دستور مانند زیر است :

همانطور که در خروجی مشاهده می کنید Nginx بر روی پورت ۸۰ کار می کند. Kubernetes یک پورت تصادفی بالاتر از ۳۰۰۰۰ که مطمئن است به سرویس دیگری تعلق نگرفته است را به این برنامه می دهد.

برای بررسی صحت عملکرد آدرس http://worker_1_ip:nginx_port یا http://worker_2_ip:nginx_port را در مرورگر سرور محلی خود وارد کنید. در این قسمت باید صفحه Nginx را مشاهده کنید.

برای حذف برنامه Nginx ابتدا سرویس Nginx را از سرور master حذف کنید :

دستور زیر را وارد کنید تا از حذف شدن برنامه مطمئن شوید :

خروجی باید مشابه زیر باشد :

سپس deployment را حذف کنید :

 

پایان

در این آموزش شما توانستید یک کلاستر مخازن Kubernetes در Ubuntu 16.04 بوسیله Kubeadm راه اندازی کنید ، و در مراحل بعدی باید بتوانید برنامه ها و سرویس ها بیشتری را در کلاستر deploy کنید. در ادامه چند لینک برای راهنمایی و آموزش بیشتر شما قرار داده ایم :

  • Dockerizing applications – لیستی از مثال هایی برای آموزش استفاده از مخازن داکر.
  • Pod Overview – توضیحات بیشتر درباره pod ها و ارتباط آن ها با اجزا دیگر Kubernetes. این pod ها در همه جای Kubernetes هستند و فهم بهتر آن ها به شما کمک زیادی می کند.
  • Deployments Overview – مرور بر مفهوم deployment است. خیلی مهم است که بدانید deployments ها چطور کارها را کنترل می کنند.
  • Services Overview – سرویس های دیگری را که توسط اجزا Kubernetes استفاده می شوند را بررسی می کند. درک انواع سرویس ها و گزینه هایی که برای اجرای هر دو برنامه های stateless و statefull هستند ، ضروری است.

مفاهیم مهم دیگر  Volumes, Ingresses و  Secrets .هستند که برای deploy برنامه ها در Kubernetes بسیار مفید هستند. Kubernetes ، امکانات و ویژگی های زیادی دارد که در مستندات رسمی Kubernetes بهترین منبع برای مطالعه می باشد.

آموزش مدیریت پیکربندی و نوشتن Playbook های Ansible

آموزش مدیریت پیکربندی و نوشتن Playbook های Ansible
Configuration Management – Writing Ansible Playbooks

 

معرفی Ansible 

به صورت خلاصه مدیریت پیکربندی سرور ( در اینجا منظور خودکار سازی مدیریت IT است ) ، یک راه حل برای تبدیل مدیریت زیر ساخت به صورت بر مبنای کد Codebase است ، و برای انجام این کار نیاز به استقرار یک سرور برای تهیه اسکریپت هایی با قابلیت نسخه بندی و استفاده مجدد است. با این کار می توان زیرساخت همه سرور ها را به صورت جامع بهبود بخشید.در این آموزش درباره نحوه خودکار سازی مدیریت سرور ها بوسیله Ansible و طریقه نوشتن آن ها صحبت می کنیم. برنامه Ansible یک ابزار برای خودکار سازی مدیریت پیکربندی است که چهار چوب های کامل و قابلیت تنظیمات را با هدف ساده سازی و خلاصه کردن تنظیمات در اختیار ما قرار می دهد. در این آموزش بر روی نوشتن نحوه دستوری ، اصطلاحات و ویژگی های مورد نیاز برای ایجاد یک نمونه ساده روند خودکار سازی ساده و توسعه آن بر روی سرور Ubuntu 14.04 و با وب سرور Apache تمرکز می کنیم.

در زیر لیست مراحلی که باید برای رسیدن به هدف خودکار سازی تنظیمات سرور ها را انجام دهیم آورده ایم :

  1. به روز رسانی مخزن apt
  2. نصب Apache
  3. ساخت root directory سفارشی
  4. قرار دادن index.html در root directory سفارشی
  5. اعمال یک قالب برای راه اندازی یک هاست مجازی
  6. راه اندازی مجدد Apache

با نگاهی به ویژگی های اصلی زبانی که برای نوشتن Playbook ها استفاده می شود ،کار را با بررسی اصطلاحات استفاده شده در Ansible شروع می کنیم. در انتهای این آموزش مثال های کاملی را با شما به اشتراک می گذاریم تا خودتان آن ها را امتحان کنید.

نکته : این آموزش آماده شده تا زبان Ansible و نحوه نوشتن Playbook ها برای خودکار سازی تنظیمات سرور ها را به شما معرفی کند. برای مشاهده مقدمات بیشتر درباره Ansible و مراحل مورد نیاز برای نصب و شروع کار با آن آموزش نصب و راه اندازی Ansible بر روی Ubuntu 14.04 را مطالعه کنید.

شروع

قبل از شروع اصطلاحات Ansible به صورت کلی مرور می کنیم ، آشنایی با اصطلاحات و مفاهیم Ansible بسیار مهم است :

اصطلاحات Ansible

  • Controller Machine : ماشین یا سروری است که Ansible بر روی آن نصب شده و مسئولیت اجرای سرویس دهی به سرور هایی است که می خواهید آن ها را مدیریت کنید.
  • Inventory : یک فایل INI  که شامل اطلاعات سرور هایی است که می خواهید آن ها را مدیریت کنید.
  • Playbook : نقطه شروع تنظیمات و مقررات Ansible ، که وظایف خودکار سازی در آن با قالب بندی YAML تعریف شده است.
  • Task : یک بلاک که یک روش را برای اجرا شدن تعریف می کند ، مانند نصب یک بسته.
  • Module : یک ماژول معمولا وظایف یا کارهای سیستم را خلاصه می کند ، مانند برخورد با بسته ها یا ایجاد و تغییر فایل ها.
  • Role : به Playbook های از پیش تعیین شده و سازماندهی شده می گویند که به راحتی به برای استفاده مجدد به اشتراک گذاشته می شوند.
  • Play : کارهایی که از شروع تا پایان انجام می شوند را یک play می گویند.
  • Facts : متغیرهای عمومی که شامل اطلاعات سیستم مانند رابط های شبکه یا سیستم عامل می باشند.
  • Handlers : برای تغییر وضعیت یک سرویس استفاده می شود مانند راه اندازی یا متوقف کردن یک سرویس می باشد.

مقررات و تنظیمات Ansible با YAML که یک زبان ساده برای مرتب سازی داده ها است استفاده می شود.

وظایف – Tasks

یک وظیفه یا Task یک کاری را تعریف می کند که باعث اجرای یک مرحله از موارد مورد نیاز می شود. این وظایف معمولا شامل استفاده از یک ماژول یا یک دستور ساده می شود ( ماژول ها نیز  دستوراتی را تولید می کنند که در انتها این دستورات اجرا می شوند). در اینجا یک وظیفه یا Task را می بینیم :

مقدار name معمولا اختیاری است ولی برای اینکه در خروجی اجرای وظایف بتوانید نام آن را مشاهده کنید پیشنهاد می شود که از آن استفاده کنید. Apt نیز یک ماژول توکار Ansible است که ابزار مدیریت بسته در توزیع های مبتنی بر دبیان است. این وظیفه به Ansible می گوید که وضعیت بسته vim باید به latest تغییر کند، با این دستور اگر تاکنون بسته vim نصب نشده باشد آن بسته نصب و به روز می شود.

قالب بندی Playbook

Playbook ها نقطه اصلی تنظیمات Ansible می باشد. آن ها شامل اطلاعات سیستم هایی هستند که باید مدیریت شوند ، همچنین دستورالعمل ها و مراحلی که باید اجرا شوند. در زیر یک نمونه Playbook آورده شده که دو کار را انجام می دهد : به روز رسانی apt سپس نصب vim.

 

در زبان YAML برای طبقه بندی داده ها از دندانه گذاری استفاده می شود و به همین دلیل موقع نوشتن Playbook ها و مخصوصا هنگام کپی کردن مثال های Playbook ها  باید بسیار دقت کنید که ظاهر صحیح آن حفظ شود.

نوشتن Playbook ها

کار با متغیر ها

روش های مختلفی برای تعریف متغیر در Ansible وجود دارد. ساده ترین روش استفاده از قسمت vars در playbook می باشد. در مثال زیر متغیر package تعریف شده است که قبلا در وظایف از آن استفاده کردیم :

متغیر package در همه سرور ها قابل دسترس است که شامل فایل ها و قالب ها است.

استفاده از Loop

حلقه ها یا Loop ها برای تکرار یک وظیفه یا Task با استفاده مقادیر متفاوت است. برای نمونه به جای ایجاد کردن ۱۰ وظیفه برای نصب ۱۰ بسته ، یک وظیفه ایجاد می کنیم و با استفاده از Loop آن وظیفه را با بسته های مورد نظرتان برای نصب تکرار می کنیم.

برای ساخت حلقه با یک وظیفه از with_items با آرایه ای از مقادیر استفاده می کنیم. برای دسترسی به محتوا نیز از طریق متغیر item به مقادیر دسترسی داشته باشد ، مانند مثال زیر :

همچنین از متغیر آرایه برای تعریف مقادیر نیز می توانید استفاده کنید :

استفاده از شرط ها

از شرط ها به صورت پویا و بر مبنای یک متغیر یا خروجی یک دستور ، می توانید برای اجرا شدن یا نشدن یک فرمان استفاده کنید. در مثال زیر ، یک وظیفه فقط بر روی سیستم های مبتنی بر دبیان اجرا می شود :

شرط when آرگومان اظهار شده را برای ارزیابی دریافت می کند و وظیفه فقط زمانی اجرا می شود که مقدار دریافت شده true باشد. در اینجا ما فقط بررسی می کنیم که سیستم عضو خانواده دبیان باشد.

عمومی ترین استفاده از شرط ها در روند خودکار سازی، زمانی است که اجرا شدن یک وظیفه به مقدار خروجی یک دستور دیگر دارد. راه کار اجرایی برای این کار این است که یک متغیر برای نگهداری خروجی دستور تعریف می کنیم ، سپس در وظیفه مورد نظر آن را بررسی می کنیم. برای بررسی خروجی دستور می توان وضعیت خروجی را که با موفقیت اجرا شده است یا خیر را بررسی کرد یا اینکه محتوای خروجی دستور را بررسی کنیم که در این حالت ممکن است به regex expressions یا دستورات تحلیل رشته ها نیاز داشته باشیم.

در مثال زیر دو وظیفه آورده شده است که برای اجرا شدن به خروجی دستور php -v نیاز دارند. همانطور که می دانید اگر PHP بر روی سرور نصب نباشد اجرای این دستور با خطا مواجه خواهد شد ، پس برای بررسی شرط خروجی این دستور ، وضعیت اجرای دستور را بررسی می کنیم. قسمت ignore_errors بخش مهمی از یک وظیفه است و برای ادامه فعالیت یک وظیفه نسبت به خروجی دستور نقش مهمی را دارد.

 

ماژول Debug که در اینجا استفاده کردیم یکی ماژول بسیار کاربردی برای نمایش مقدار متغیر ها و تحلیل پیام هاست. این ماژول می تواند یک رشته را چاپ کند ( زمانی که از آرگومان msg استفاده شود ) یا اینکه محتوای یک متغیر را چاپ کنید ( زمانی که از آرگومان var استفاده شود ).

کار با قالب ها

قالب ها معمولا برای فایل های تنظیمات پیکربندی استفاده می شوند که با استفاده از متغیر ها یا ویژگی های مورد نظرمان می توانیم از این فایل ها برای مقاصد دیگر نیز استفاده کنیم. Ansible از قالب موتور Jinja2 استفاده می کند.

در مثال زیر یک قالب برای تنظیم یک هاست Apache آورده شده است که از یک متغیر برای تعیین مسیر ریشه هاست استفاده می کنیم :

ماژول توکار template برای اعمال قالب می باشد که به صورت یک وظیفه عمل می کند. اگر نام قالب که در بالا تعریف کردیم را vhost.tpl گذاشته باشید و در همان مسیری باشد که Playbook شما قرار داشته باشد ، با صورتی که در زیر آورده شده می توانید قالب را با قالب پیش فرض تعیین هاست Apache جایگزین و اعمال کنید :

تعریف و راه اندازی کنترل کننده ها –  Handlers

از کنترل کننده ها یا همان Handler ها به عنوان تغییر دهنده وضعیت یک سرویس ، مانند متوقف کردن یا راه اندازی مجدد استفاده می شود. کنترل کننده ها رفتاری شبیه به وظیفه ها دارند و دستور تعریف شده را اجرا می کنند ، با این تفاوت که برای اجرا باید notify در آن وظیفه تعریف شده باشد. کنترل کننده ها معمولا از قبل در یک آرایه در قسمت handlers از playbook تعریف شده اند.

برای نمونه نگاهی به مثال قبل که از یک قالب نمونه برای ایجاد هاست مجازی Apache استفاده کردیم می اندازیم. اگر بخواهیم که Apache بعد از تغییرات هاست مجازی مجددا راه اندازی شود ، باید یک کنترل کننده برای سرویس Apache بنویسم. به صورت زیر یک کنترل کننده یا Handler برای Playbook می نویسیم :

در اینجا قسمت name بسیار مهم است ، زیرا تعیین کننده یک نام واحد و Unique برای کنترل کننده یا Hnadler است. برای اجرا شدن این کنترل کننده در یک وظیفه باید از گزینه notify استفاده کنید :

یک نمونه Playbook

اکنون به Playbook ای که در این آموزش برای خودکار سازی نصب Apache بر روی سرور Ubuntu 14.04 نوشتیم ، نگاه دقیق تری می کنیم. این یک مثال کامل است که شامل قالب و راه اندازی Apache و یک فایل HTML است که توسط وب سرور نمایش داده می شود که از اینجا می توانید این فایل را بدست آورید. همچنین این پوشه حاوی Vagrantfile است که از آن برای بررسی و تست ساده Playbook با ماشین مجازی مدیریت شده با Vagrant مدیریت می شود ، می توانید استفاده کنید.

در زیر Playbook به صورت کامل آورده شده :

توضیحات Playbook

hosts: all

فایل Playbook با اظهار اینکه تنظیمات باید به تمامی هاست ها ( host: all ) اعمال شوند ، شروع می شود. این مقدار می تواند به هاست های بخصوص یا گروهی از هاست ها تغییر کند.

become: true

این قسمت به Ansible می گوید که از افزایش دسترسی (sudo) برای اجرای تمامی دستورات استفاده کند. این گزینه می تواند برای هر وظیفه ای و بازنویسی شود.

vars

تعریف متغیر doc_root ، که قبلا در وظیفه Task از آن استفاده کردیم. در این قسمت می توان متغیر های متفاوت دیگری را نیز تعریف کرد.

tasks

در این قسمت خود وظیفه یا Task تعریف می شود. ابتدا بسته apt را به روز می کند و در وظیفه بعدی بسته apache2 را نصب می کند.

وظیفه سوم از ماژول file برای ساخت دایرکتوری در مسیر ریشه ای که برای سرویس دهی استفاده می کنیم ، ایجاد می کند. از این ماژول برای مدیریت فایل و دایرکتوری استفاده می شود.

چهارمین وظیفه از ماژول copy برای کپی کردن فایل سیستم محلی به سرور استفاده می کند. یک فایل HTML ساده را برای سرویس دهی وب  Apache کپی می کنیم.

handlers

در انتهای نیز قسمت handlers را داریم که سرویس ها در آن معرفی شدند. یک کنترل کننده restart apache تعریف کردیم تا تغییرات Apache اعمال شوند.

آموزش نصب و پیکربندی Ansible در Ubuntu 16.04

آموزش نصب و پیکربندی Ansible در Ubuntu 16.04

How to Install and Configure Ansible on Ubuntu 16.04

 

 

معرفی Ansible 

سیستم های مدیریت پیکربندی و تنظیمات به منظور سادگی بیشتر مدیران و تیم های عملیاتی برای کنترل سرورهای زیاد طراحی شده اند و با کمک این سیستم های مدیریتی می توانید سیستمهای متفاوتی را از یک مکان مرکزی کنترل کنید.

هم اکنون سیستم های مدیریت پیکربندی محبوب برای سیستم های لینوکس مانند Chef و Puppet وجود دارند ولی اغلب این برنامه ها پیچیده تر از چیزی هستند که مردم می‌خواهند و به این نیاز دارند. Ansible بهترین جایگزین برای این کار است زیرا کمترین سربار را هنگام راه اندازی دارد.

در این آموزش روش نصب Ansible را بر روی سرور Ubuntu 16.04 را مطرح می کنیم و روش های ابتدایی کار با این برنامه را می گوییم.

Ansible چگونه کار می کند ؟

Ansible از یک کامپیوتر که اجزای Ansible بر روی آن نصب است ماشین های کاربران را تنظیم و پیکربندی می کند. همچنین از کانال های SSH عادی برای ارتباط با ماشین ها از راه دور برای دریافت اطلاعات ، دستورالعمل ها و کپی فایل ها استفاده می کند.

این برنامه راه حلی است که مدیریت سرور های شما را بسیار ساده می کند به این صورت که ، هر سروری که پورت SSH آن باز باشد بدون در نظر گرفتن  چرخه ای که سرور در آن قرار دارد ، می تواند تحت نظر پیکربندی Ansible قرار گیرد.

هر کامپیوتری که از طریق SSH می توانید به آن وصل شوید را می توانید از طریق Ansible مدیریت کنید.

برنامه Ansible به صورت ماژولار کار می کند که این امر باعث می شود که ویژگی های مورد نیازتان برای سناریو های متفاوت را به سیستم اصلی اضافه کنید و از آن استفاده کنید. ماژول ها با هر زبان برنامه نویسی می توانند طراحی شده باشند که باید با استاندارد JSON با یکدیگر ارتباط برقرار کنند.

فایل پیکربندی اصلی با قالب استاندارد YAML نوشته شده است که باعث می شود کاملا واضح و خوانا باشد و شبیه به زبان های نشانه گذاری محبوب باشد. برنامه Ansible از طریق هر ابزار خط فرمان یا اسکریپت های پیکربندی که به آن ها Playbook گفته می شود با کاربران در ارتباط باشد.

پیش نیاز ها

در این آموزش به یک سرور Ubuntu 16.04 با دسترسی کاربر non-root با مجوز sudo و ارتباط SSH نیاز دارید.

مرحله اول – نصب Ansible

کار با Ansible به معنی مدیریت سرور های مختلف است که برای این کار باید Ansible را حداقل بر روی یک سرور مجازی نصب کنید. در اینجا برای نصب برنامه از یک سرور Ubuntu 16.04 استفاده می کنیم.

بهترین روش نصب برای Ansible ، اضافه کردن آن به PPA ( Personal Package System ( که همان منبع مخازن سیستم می باشد ، است. برای اضافه کردن به PPA می توانید از دستور زیر استفاده کنید :

برای تایید پیام های اضافی PPA دکمه Enter را بزنید.

در ادامه باید برای سیستم مدیریت بسته های از بسته های جدید مطلع شود آن را مجددا راه اندازی کنیم ، سپس برنامه را نصب کنیم :

همانطور که گفتیم در درجه اول Ansible از طریق SSH با کامپیوتر کاربر ارتباط برقرار می کند. در حالی که قابلیت مدیریت با سیستم احراز هویت بر اساس رمز عبور را دارد ، از کلید SSH نیز می تواند برای راحتی کار استفاده کند.

تا اینجا همه برنامه های مورد نیاز را برای مدیریت سرورهای مان از طریق برنامه Ansible را داریم.


مرحله دوم – پیکربندی میزبان های Ansible

برنامه Ansible سرور هایی که در فایل hosts  تعریف شده اند را بررسی می کند ، پس برای برقراری ارتباط با کامپیوتر های دیگر باید این فایل را تنظیم کنیم. این فایل را با دسترسی root باز کنید :

در این فایل تنظیمات نمونه زیادی را مشاهده می کنیم که هیچکدام کارایی لازم را برای ما ندارند ، پس برای شروع پیکربندی با قرار دادن “#” در ابتدای تمام خطوط ، همه این تنظیمات را به حالت توضیح در می آوریم و در آینده برای سناریو های پیچیده می توانیم از این تنظیمات کمک بگیریم.

فایل hosts نسبتا قابل انعطاف است و راه های مختلفی برای تنظیم این فایل وجود دارد. روش و قالبی که ما از آن برای پیکربندی استفاده می کنیم به صورت زیر است :

مقدار group_name برای دسته بندی سرور هاست که باید از یک کلمه استفاده کنید.

مقدار alias نیز فقط یک نام است که به سرور اشاره می کند.

 

در سناریو ما فرض بر این است که سه سرور قرار است که بوسیله Ansible کنترل شوند. این سرور های باید با دستور زیر از سرور Ansible در دسترس باشند :

اگر تنظیمات را به درستی انجام داده باشید نباید پیغام رمز عبور را مشاهده کنید و این به این معنی است که باید کلید SSH سرور را به درستی تنظیم کرده باشید. آدرس های IP که به سرور ها اختصاص دادیم ۱۹۲٫۰٫۲٫۱ ، ۱۹۲٫۰٫۲٫۲ و ۱۹۲٫۰٫۲٫۳ می باشند و نام های host1 ، host2 و host3 را با نام گروه servers به آنها اختصاص داده ایم.

برای انجام این کار باید بلاک زیر را به فایل hosts اضافه کنید :

هاست ها می توانند در گروه های متفاوتی باشند و هر گروه می تواند تنظیمات جداگانه ای برای اعضای خودش داشته باشد. بعدا این مسئله را امتحان کنید.

با تنظیماتی که تا الان انجام شده اگر بخواهیم از طریق Ansible به سرور های هاست ها متصل شویم با خطا مواجه خواهیم شد ( با فرض اینکه کاربر root نباشید ). به این دلیل که کلید SSH برای کاربر root تعریف شده است و Ansible به صورت پیش فرض برای اتصال از کاربر فعلی شما استفاده می کند. اگر اقدام به اتصال کنید خطای زیر را مشاهده خواهید کرد :

در سرور Ansible از کاربری به نام demo استفاده می کنیم و Ansible تلاش می کند که با این دستور به همه سرور ها متصل شود ssh demo@server ، و اگر این کاربر بر روی سیستم راه دور تعریف نشده باشد ، این دستور کار نمی کند. برای رفع مشکل یک فایل ایجاد می کنیم تا همه سرور های عضو گروه server با کاربر root متصل شوند.

برای این کار یک دایرکتوری در ساختار پیکربندی Ansible با نام group_vars ایجاد می کنیم. در این پوشه برای هر گروهی که می خواهیم تنظیم کنیم یک فایل با فرمت استاندارد YAML ایجاد می کنیم :

تنظیمات را در این فایل قرار می دهیم. فایل های YAML با “—” شروع می شوند ، پس فراموش نکنید که در ابتدای فایل آن را اضافه کنید :

در انتها فایل را ذخیره کرده و خارج شوید.

اگر میخواهید تنظیمات خاصی را برای همه سرور های بدون در نظر گرفتن گروه آنها انجام دهید ، این تنظیمات را در فایل etc/ansible/group_vars/all/ قرار دهید. برای اعمال تنظیمات خاص برای هاست های نیز می توانید در مسیر etc/ansible/host_vars/ فایل های پیکربندی را ایجاد کنید.

مرحله سوم – دستورات ساده Ansible

تا اینجا سرور های هاست ها را تنظیم کردیم و پیکربندی کافی برای اتصال به سرور های هاست ها را انجام دادیم و اکنون می توانیم دستورات اولیه را اجرا کنیم.

از سرور هایی که تنظیم کردیم با دستور زیر ping می گیریم :

این یک تست ساده برای بررسی اتصال Ansible با سرور های هاست های تعریف شده بود. در اینجا کلمه “all” برای همه هاست استفاده می شود ، اگر می خواهید که از گروه خاصی تست ping بگیرید از دستور زیر استفاده کنید :

همچنین می توانید یک هاست خاص را تعیین کنید :

همچنین چند هاست خاص که آنها را با کولون : از یکدیگر جدا می کنیم :

مقدار m ping- در دستور گفته شده برای استفاده از ماژول “ping” در ساختار Ansible است. این ها دستورات پایه ای هستند که می توانید بر روی سرور ها هاست ها از راه دور اجرا کنید. ماژول ping در بیشتر موارد مانند ابزار ping لینوکس  عمل می کند ولی در Ansible ارتباطات را بررسی می کند.

ماژول ping هیچ آرگومانی را نمی گیرد ولی می توانیم دستور دیگری را امتحان کنیم تا از صحت عملکرد آن مطمئن شویم. می توانیم آرگومان a- را ارسال کنیم. ماژول shell این امکان را برای ما فراهم می کند که دستورات خط فرمان را از راه دور بر روی سرور های هاست ها اجرا کنید و نتیجه را دریافت کنیم. برای مثال از دستور زیر برای پیدا کردن مقدار فضای استفاده شده حافظه رم از سرور host1 استفاده می کنیم :

پایان

تا اینجا باید توانسته باشید که سرور Ansible را پیکربندی کرده باشید و سرور هایی را که می خواهید تنظیم کنید با موفقیت به Ansible متصل کرده باشید.

تا اینجا سرور Ansible را برای اتصال به سرور هایی که می خواهیم آنها را مدیریت کنیم پیکربندی کرده و به سرور های هاست ها متصل کردیم. در ادامه بررسی صحت اتصال به سرور های هاست ها را بررسی کردیم و دستورات ساده ansible را از راه دور اجرا کردیم.

سعی کردیم مطالب مفید و کاربردی را در این مطلب بیان کنیم ولی مطالب عنوان شده بسیار ساده و ابتدایی هستند و به ویژگی های پرقدرت Ansible پرداخته نشده است ، مانند Playbook ها.

آموزش راه اندازی کلاسترینگ پایگاه داده Cassandra با چندین سرور یا گره در Ubuntu 14.04

آموزش راه اندازی کلاسترینگ پایگاه داده Cassandra با چندین سرور یا گره در Ubuntu 14.04

ow To Run a Multi-Node Cluster Database with Cassandra on Ubuntu 14.04

 

 

معرفی Cassandra 

Cassandra یا Apache Cassandra یک پایگاه داده متن باز بر اساس سیستم NoSQL می باشد که بسیار مقیاس پذیر و قابل انعطاف می باشد و کارایی بسیار بالایی در کلاسترینگ با چندین سرور را دارد. قبلا به بررسی نصب و راه اندازی Cassandra با یک گره Node پرداختیم ، و در این آموزش Cassandra را با چندین گره بر روی سرور Ubuntu 14.04 راه اندازی می کنیم.

پیش نیاز ها

باید قبل از راه اندازی کلاستر Cassandra ، تعداد سرور هایی که می خواهید به عنوان گره Node در کلاستر معرفی کنید تا تعیین کنید. این کار حتما لازم نیست ولی پیشنهاد می کنیم که این کار را حتما انجام دهید ، همچنین لازم نیست که سرور های مشخصات یکسانی داشته باشند.

در این آموزش به موارد زیر نیاز داریم :

  • حداقل دو سرور Ubuntu 14.04 که تنظیمات راه اندازی اولیه روی آنها انجام شده باشد.
  • تنظیمات دیواره آتش هر سرور باید انجام شده باشد.
  • بر روی هر سرور برنامه Cassandra مطابق آموزش راه اندازی Cassandra که قبلا داده شده نصب شده باشد.

مرحله اول – حذف داده های پیش فرض

سرور ها در کلاستر Cassandra به عنوان گره Node شناخته می شوند. تا الان هر چیزی که روی سرور داریم یک کلاستر Cassandra در یک سرور و به صورت تک گره Single-Node است و در این آموزش کلاسترینگ Cassandra را به صورت چندین گره Multi-Node بر روی چند سرور راه اندازی می کنیم.

تمام دستورات در این مرحله و مراحل بعد باید در تمامی گره ها و سرور ها وارد شود و باید مطمئن باشید که ترمینال های زیادی را در سرور های می توانید اجرا کنید.

اولین دستوری که در سرور ها باید وارد کنید برای متوقف کردن سرویس Cassandra daemon می باشد :

سپس مجموعه داده های Cassandra را حذف می کنیم :

مرحله دوم – پیکربندی کلاستر

فایل پیکربندی Cassandra در مسیر etc/cassandra/ قرار دارد. فایل cassandra.yaml شامل قسمتها و دستورات زیادی است ، که در این مرحله آن را برای راه اندازی کلاستر پیکربندی می کنیم.

برای راه اندازی کلاسترینگ با چندین گره ، فقط خطوط زیر را تغییر می دهیم :

cluster_name : تعیین نام دلخواه برای کلاستر

seed : برای تعیین لیست آدرس های IP سرور های می باشد که باید با کاما از یکدیگر جدا کنید

listen-address : آدرس IP سروری که بقیه گره ها باید به این گره متصل شوند. به صورت پیش فرض مقدار آن localhost است که باید مقدار آدرس IP سرور را قرار دهید.

rpc-address : تعیین آدرس IP برای دسترسی سرویس ها و پردازش های دیگر سرور ها به این سرور است که به صورت پیش فرض روی ocalhost قرار دارد. اگر نام دامنه ای برای سرور انتخاب و به درستی تنظیم شده است آن را رها کنید در غیر اینصورت مقدار آدرس IP سرور را با مقدار ۱۲۷٫۰٫۰٫۱ جایگزین کنید.

endpoint-snitch : انتخاب یک نام برای معرفی شبکه به Cassandra که به اصطلاح آن را خرگوش snitch می نامیم. این مقدار به Cassandra می گوید که دنبال چه شبکه ای باید بگردد. در اینجا مقدار پیش فرض SimpleSnitch است که برای شبکه هایی است که در یک دیتاسنتر هستند ولی ما در اینجا مقدار آن را GossipingPropertyFileSnitch قرار می دهیم که این مقدار برای محصولات و تنظیمات تجاری پیشنهاد می شود.

auto-bootstrap : این خط در فایل پیکربندی وجود ندارد ، پس باید آن را اضافه کنید و مقدار آن را false قرار دهید. این گزینه باعث می شود که گره های جدید به درستی از داده های استفاده کنند. در حالتی که می خواهید گره جدید به کلاستر اضافه کنید این گزینه اختیاری است ولی اگر کلاسترینگ تازه راه اندازی می کنید این گزینه اجباری است و به این معنی است که این گره تنها و بدون داده است.

فایل پیکربندی را با nano یا یک ویرایشگر متن دلخواه باز کنید :

خطوط زیر را در این فایل پیدا کنید و همانطور که در زیر نشان داده شده آن ها را تغییر دهید. مقدار your_server_ip را با مقدار آدرس IP سروری که الان به آن متصل هستید جایگزین کنید. مقدار seeds –  باید در همه سرور ها یکسان باشد و شامل آدرس IP همه سرور ها است که با کاما از یکدیگر جدا شده اند.

در انتهای فایل خط auto_bootstrap را نیز اضافه کنید :

پس از اتمام تغییرات فایل پیکربندی ، آن را ذخیره کرده و خارج شوید. این تنظیمات را نیز در تمامی سرور هایی که می خواهید عضو گره های کلاستر باشند ، انجام دهید.

مرحله سوم – تنظیمات فایروال

تا اینجا کلاستر Cassandra را پیکربندی کردیم ولی سرور های نمی توانند با یکدیگر ارتباط داشته باشند و برای رفع این مشکل باید دیواره آتش را پیکر بندی کنیم.

در ابتدا سرویس Cassandra را در هر سرور مجددا راه اندازی می کنیم :

اگر وضعیت کلاستر را بررسی کنید می بینید که فقط یک گره محلی local فعال است و به این دلیل است که سرور های توانایی ارتباط با یکدیگر را ندارند.

 

برای برقراری ارتباط در شبکه باید پورت های زیر را در هر سرور باز کنید :

  • ۷۰۰۰ : که پورت TCP و برای دستورات و داده ها هست
  • ۹۰۴۲ : که پورت TCP و برای ارتبط محلی سرور ها است. Cqlsh که ابزار خط فرمان Cassandra است ، از طریق این پورت ارتباط برقرار می کند.

برای تغییرات در فایروال ، فایل رول های مربوط به IPv4 را باز کنید :

برای اجازه به ترافیک ورودی پورت های گفته شده ، خط زیر را در زنجیره INPUT وارد کنید. اگر برای تنظیم فایروال از فایل rules.v4 استفاده می کنید ، کافیست خط زیر را قبل از خط توضیح Reject anything that’s fallen through to this point # قرار دهید.

آدرس IP مشخص شده با s- باید آدرس گره یا سرور دیگر در کلاستر باشد. مثلا اگر دو سرور با آدرس های ۱۱۱٫۱۱۱٫۱۱۱٫۱۱۱ و ۲۲۲٫۲۲۲٫۲۲٫۲۲۲ دارید ، با در سرور ۱۱۱٫۱۱۱٫۱۱۱٫۱۱۱ باید در خط زیر از آدرس ۲۲۲٫۲۲۲٫۲۲۲٫۲۲۲ استفاده کنید.

پس از اضافه کردن نقش مورد نظر ، فایل را ذخیره کرده و خارج شوید و سپس iptables را مجددا راه اندازی کنید.

مرحله چهارم – بررسی وضعیت کلاستر

تا اینجا همه کارهایی که باید برای راه اندازی کلاستر با چندین گره را باید انجام می دادیم را انجام دادیم. اکنون باید وضعیت ارتباطات بین همه گره ها را بررسی کنیم.

 

در این خروجی اگر همه سرور هایی که تنظیم کرده اید را می توانید مشاهده کنید به این معنی است که کلاسترینگ Cassandra با چندین گره را به درستی راه اندازی کرده اید.

همچنین اگر امکان اتصال با دستور calsh را دارید ، به این روش نیز می توانید آن را بررسی کنید. دقت کنید که برای استفاده از این دستور به آدرس IP هر گره در کلاستر نیاز دارید.

اگر متصل باشد خروجی زیر را مشاهده می کنید :

 

پایان

شما توانستید که کلاسترینگ Cassandra را با چندین گره راه اندازی کنید. برای کسب اطلاعات بیشتر می توانید سایت پروژه Cassandra را مطالعه کنید. اگر نیاز به رفع مشکل کلاستر داشتید ، ابتدا به دنبال یک سرنخ در گزارش ها در مسیر var/log/cassandra/ بگردید.

آموزش نصب Cassandra و کلاستر با یک سرور در Ubuntu 14.04

آموزش نصب Cassandra و راه اندازی کلاستر با یک سرور در Ubuntu 14.04

How To Install Cassandra and Run a Single-Node Cluster on Ubuntu 14.04

معرفی

Cassandra یا Apache Cassandra یک پایگاه داده متن باز بر اساس سیستم NoSQL می باشد که بسیار مقیاس پذیر و قابل انعطاف می باشد و کارایی بسیار بالایی در کلاسترینگ با چندین سرور را دارد. در این آموزش خواهید آموخت که چطور این پایگاه داده را به صورت تک گره Node را بر روی سرور Ubuntu 14.04 نصب و استفاده کنید.

پیش نیاز ها

در این آموزش به موارد زیر نیاز دارید :

  • یک سرور Ubuntu 14.04
  • دسترسی یک کاربر non-root با مجوز sudo برای اجرای دستورات

مرحله اول – نصب Oracle Java Virtual Machine

برای اجرای Cassandra نیاز است که Oracle Java SE Runtime Environment (JRE) روی سرور نصب باشد. پس در این مرحله JRE را نصب می کنیم و بررسی می کنیم که به صورت پیش فرض فعال باشد.

برای فعال کردن بسته های Oracle JRE باید با استفاده از دستور زیر Personal Package Archives (PPA)  را به سیستم اضافه کنید :

سپس دیتابیس بسته ها را به روز رسانی می کنیم :

سپس Oracle JRE را نصب می کنیم. همراه با نصب بسته ، برنامه JRE به صورت پیش فرض سیستم قرار می گیرد. در ادامه نصب باید مجوز را تایید کنید :

بعد از نصب با دستور زیر ، بررسی می کنیم که نصب با موفقیت انجام شده یا خیر :

باید خروجی مشابه زیر را مشاهده کنید :پ

مرحله دوم – نصب Cassandra

در ادامه برنامه Cassandra را از منابع رسمی نرم افزار های Apache نصب می کنیم ، و برای این کار باید منابع مورد نیاز را به منابع موجود سیستم اضافه کنیم. در زمان تهیه این آموزش آخرین نسخه Cassandra ، شماره ۲٫۲٫۲ می باشد اگر هنگام نصب نسخه جدیدتری ارائه شده ، شماره نسخه را به صورت ۲۲x جایگزین کنید. مثلا اگر نسخه ۲٫۳ را می خواهید نصب کنید مقدار ۲۳x را قرار دهید.

آدرس منبع را اضافه می کنیم :

برای رفع مشکل خطای تایید بسته ها هنگام نصب ، باید این سه کلید را از Apache Software Foundation که مربوط به مخازن بسته ها است را اضافه کنید.

کلید ها را یکی یکی به صورت جداگانه نصب کنید و برای نصب هر کدام از دو دستور داده شده استفاده کنید :

دومین کلید :

سومین کلید :

دیتابیس بسته را یک بار دیگر به روز رسانی کنید :

در انتها Cassandra را نصب کنید :

مرحله سوم – عیب یابی و اجرای Cassandra

به طور معمول بعد از نصب Cassandra به صورت خودکار اجرا می شود ، ولی اگر به دلیل بروز مشکلی برنامه اجرا نشد ، برای بررسی وضعیت برنامه دستور زیر را وارد کنید :

اگر برنامه اجرا نشده باشد ، خروجی زیر نمایش داده می شود :

این یک مشکل شناخته شده و قابل رفع برای آخرین نسخه Cassandra در سیستم عامل Ubuntu می باشد. برای رفع مشکل ابتدا اسکریپت init مربوط به Cassandra را ویرایش می کنیم. مقداری که باید تغییر دهیم در خط شماره ۶۰ قرار دارد. ابتدا فایل را با یک ویرایشگر متنی باز می کنیم :

این خط را پیدا کنید :

و به این صورت تغییر دهید :

فایل را ذخیره کنید و خارج شوید ، سپس سرور را ریبوت کنید :

یا

بعد از راه اندازی مجدد سرور ، سرویس Cassandra باید اجرا شده باشد ، برای بررسی این موضوع دستور زیر را وارد کنید :

خروجی باید به صورت زیر باشد :

مرحله چهارم – اتصال به کلاستر

اگر توانستید با موفقیت Cassandra را اجرا کنید ، برای بررسی وضعیت کلاستر دستور زیر را وارد کنید :

در خروجی کلمه UN به این معنی است که سرویس بالا Up و در حالا عادی Normal است :

سپس با استفاده از خط فرمان مختص به cassandra به عنوان یک رابط استفاده کنید و به آن متصل شوید :

خواهید دید که اتصال برقرار است :

برای خروج دستور exit را وارد کنید :

پایان

تبریک میگم ، شما توانستید کلاستر Cassandra را با یک گره Node بر روی سرور Ubuntu 14.04 راه اندازی کنید. اطلاعات بیشتر در مورد Cassandra در وب سایت این پروژه موجود است.

آموزش نصب Docker و استفاده از Image و Container در Ubuntu 18.04

آموزش نصب Docker و استفاده از Image و Container در Ubuntu18.04

How To Install Docker and Use Image and Container on Ubuntu 18.04

معرفی

داکر Docker یک برنامه کاربردی است که فرآیند مدیریت پردازش های برنامه ها را توسط مخزن ها Containers راحت تر می کند. مخزن ها منابع ایزوله شده ای هستند که اجازه می دهند پردازش برنامه های شما در آن محیط ها انجام شوند. آن ها بسیار شبیه به ماشین ها مجازی هستند ، اما مخزن ها قابل حمل (Portable) هستند و همچنین منابع سازگار بیشتری دارند وبه سیستم عامل میزبان وابسته هستند. در این آموزش نسخه عمومی Docker Community Edition (CE)  را نصب و استفاده می کنیم. خودتان Docker را نصب می کنید و با مخزن ها Containers و منبع ها Images کار می کنید ، و یک منبع image را به منابع Docker اضافه می کنید.

برای درک بهتر از اجزای متفاوت مخزن Docker این مطلب را مطالعه کنید :

The Docker Ecosystem: An Introduction to Common Components

پیش نیاز ها

در این آموزش به موارد زیر نیاز دارید :

  • یک سرور مجازی Ubuntu 18..04 با دسترسی یک کاربر غیر ریشه non-root و عضو sudoer همراه با یک دیوار آتش Firewall.  
  • یک حساب کاربری در Docker Hube ، البته اگر می خواهید که یک image برای خودتان بسازید و طبق راهنمای مرحله ۷ و ۸ آن را در Docker Hub قرار دهید.

مرحله اول – نصب Docker

بسته (package) نصب داکر در منابع رسمی اوبونتو موجو می باشد ولی ممکن است که آخرین نسخه در این منابع موجود نباشد برای همین آخرین نسخه را از منابع رسمی Docker نصب می کنیم. برای این کار منبع بسته (package source) جدید را به سیستم اضافه می کنیم و برای اطمینان از معتبر بودن دانلود بسته کلید GPG را اضافه می کنیم ، سپس بسته را نصب می کنیم.

ابتدا لیست بسته های موجود را نصب می کنیم :

سپس ، تعدادی از بسته های پیش نیاز را با apt نصب می کنیم :

سپس کلید GPG مربوط به منابع Docker را به سیستم اضافه می کنیم :

منابع Docker را به منبع APT اضافه می کنیم :

سپس دیتابیس بسته ها را منابع جدید Docker که اضافه کردیم را به روز رسانی می کنیم :

در ادامه باید از اینکه نصب از منابع Docker به جای منابع پیش فرض Ubuntu  انجام می شود مطمئن شویم :