Master

config.toml

@@ -12,7 +12,7 @@ uglyurls = true
     github = "https://github.com/etcinitd/elastico-io-blog"
     #twitter = "https://twitter.com/username"
     linkedin = "http://www.linkedin.com/groups/7019646"
-    telegram = "https://telegram.me/joinchat/DBSHvj6Jmd0FYWfhyvrnvw"
+    telegram = "https://t.me/joinchat/DBSHvj6Jmd062tJqwg-BeA"
     #footer_1 = "Some text here."
     #footer_2 = "Some different text here."
     #footer_3 = "Even more different text here."

content/blog/CRI-O.md

@@ -0,0 +1,40 @@
++++
+date = "2017-11-23T14:55:02+04:30"
+draft = false
+title = "معرفی CRI-O نسخه 1.0"
+
++++
+
+
+سال گذشته، پروژه کوبرنیتیز، CRI یا همان Container Runtime Interface که یک رابط پلاگین بود را معرفی کرد. این پلاگین به kubelet امکان می دهد که بتواند از کانتینر های مختلف زمان اجرا سازگار با استاندارد OCI بدون نیاز به کامپایل دوباره کوبرنیتیز استفاده کند. بر این اساس، پروژه CRI-O به منظور ایجاد یک container-runtime سبک برای کوبرنتیز ایجاد شده است.
+
+حالا واقعا این به چه معناست ؟
+
+
+CRI-O به شما امکان اجرای کانتینر ها را مستقیما از کوبرنتیز، بدون نیاز به کدی یا ابزاری اضافی فراهم می کند. تا زمانی که کانتینر، سازگار با استاندارد OCI می باشد، CRI-O می تواند آن را اجرا کند و ابزار های پیچیده و غیر اصلی را حذف کند تا به کانتینر ها این امکان را بدهد که کار خود را به بهترین شکل انجام دهند. 
+قبل از معرفی CRI، کوبرنتیز به یک container-runtime مشخصی از طریق یک رابط داخلی و فرار و سطح بالا که درون kubelet پیاده سازی شده بود، وابستگی داشت. این موضوع سربار نگهداری زیادی را برای جامعه بالادستی (upstream) کوبرنتیز و همینطور ارائه دهنگان راهکار های معماری برای پلتفرم orchestration بوجود می آورد.
+با وجود CRI، کوبرنتیز دیگر نیازی به دانستن container-runtime ندارد و همینطور ارائه دهندگان container-runtime مجبور به پیاده سازی امکانات و قابلیت هایی که کوبرنتیز از قبل آنها را پیاده کرده نخواهند بود. این موضوع در واقع پیروزی بزرگی برای جامعه کاربران است چرا که به پروژه ها امکان تغییرات مستقل، با حفظ سازگاری و اجرایی بودن را مهیا میکند.
+
+برای بیشتر قسمت ها تصور ما بر آن است که کاربران کوبرنتیز (یا توزیع های آن مانند OpenShift) خیلی به container-runtime اهمیت زیادی نمی دهند. در واقع برای آنها انجام شدن کارشان مهم است و دنبال بهترین حالت ممکن نیستند. مثلا مانند اکثریت که برایشان اهمیت ندارد که ماشین مورد استفاده آنها از کدام shell استفاده می کند، حال GNU bash, Korn, Zsh یا هر shell سازگار با استاندارد POSIX باشد. مهم برای آنها، تنها اجرا کردن استاندارد اسکریپت ها و برنامه ها می باشد.
+
+CRI-O‌: یک container-runtime سبک برای کوبرنتیز
+
+
+و این آن چیزی است که CRI-O مهیا می کند. نام آن از CRI به همراه OCI یا همان (Open Container Initiative)  مشتق شده است زیرا CRI-O بطور ویژه بر روی runtime های سازگار با OCI و image کانتینر ها تمرکز کرده است.
+امروزه CRI-O از runc و Clear Container runtimes پشتیبانی می کند اگرچه آن از هر runtime سازگار با OCI نیز پشتیبانی می کند. ازینرو CRI-O می تواند از هر رجیستری کانتینرها، تصاویر را دریافت (pull) کرده و مباحث مربوط به شبکه بندی (networking) را با استفاده از  Container Network Interface  یا همان (CNI) راه بیندازد و در واقع هر پلاگین شبکه که سازگار با CNI باشد، بر روی پروژه شما کار خواهد کرد.
+
+هنگامی که کوبرنتیز نیاز به اجرای یک کانتینر دارد، با CRI-O صحبت کرده و process مربوط به CRI-O که در پشت زمینه در حال اجرا هست، برای اجرای کانتینر با runc (یا هر runtime سازگار با OCI) کار خواهد کرد. هنگامی که کوبرنتیز نیاز به متوقف ساختن یک کانتینر دارد، CRI-O آن را هندل خواهد کرد. در واقع هیچ چیز عجیبی وجود ندارد و این CRI-O می باشد که در پشت صحنه مدیریت کانتینر های لینوکس را انجام داده و خیال کاربران را برای این بخش از orchestration راحت می کند.
+
+
+
+چیزی که CRI-O نیست!
+
+
+محدوده CRI-O کار کردن با کوبرنتیز برای مدیریت و اجرای کانتینر های OCI است. و در واقع ابزاری نیست که برنامه نویس با آن روبروست. هر چند که پروژه برای عیب یابی ممکن است دارای ابزار هایی که کاربر مواجه آن می شود باشد.
+برای مثال، ساخت image ها خارج از محدوده کارهای CRI-O می باشد و به ابزار های دیگری مانند دستور build داکر، Buildah و یا S2I یا همان Source-to-Image اوپن شیفت واگذار شده است. هنگامی که image ساخته شد، CRI-O از آن استفاده می کند اما ساخت image ها به سایر ابزار ها واگذار شده است.
+در حالی که CRI-O شامل یک خط فرمان (CLI) می باشد، اما آن بیشتر برای تست CRI-O مهیا شده است و در واقع روشی برای مدیریت کانتینر ها در یک محیط عملیاتی نیست.
+
+قدم بعدی
+
+
+حالا که نسخه ۱.۰ CRI-O منتشر شده است، ما امیدواریم تا آن را در نسخه بعدی stable کوبرنتیز به عنوان قابلیت جدیدی ببینیم. نسخه منتشر شده ۱.۰ با سری کوبرنتیز *.۱.۷ سازگار می باشد. همینطور CRI-O نسخه release candidate1 در ۱.۸ بزودی برای کوبرنتیز *.۱.۸ منتشر خواهد شد.

content/blog/namespace-in-kube.md

@@ -0,0 +1,96 @@
++++
+date = "2017-11-25T14:55:02+04:30"
+draft = false
+title = "Namespaces in Kubernetes"
+
++++
+
+### استفاده از namespace ها برای مدیریت Environment های مختلف در کوبرنتیز
+
+یکی از امکاناتی که کوبرنتیز مهیا کرده امکان مدیریت environment ها می باشد که آسان تر و بهتر از استراتژی های دیپلوی سنتی است. برای اکثر پروژه های سازمانی و بزرگ، environment هایی مانند test، stage و production وجود دارد. این امکان وجود دارد که برای هر کدام، کلاستر جداگانه ای از منابع مثلا بوسیله VMها با تنظیمات مشابه در همه environment ها ایجاد کرد، اما مدیریت آن زمانبر و هزینه آن قابل توجه خواهد بود.
+کوبرنتیز دارای امکان مناسبی با نام namespace است که شما را قادر می سازد تا بتوانید environment های مختلفی را در داخل یک کلاستر داشته و مدیریت کنید. 
+
+
+### namespace پیش فرض
+
+تعیین namespace در کوبرنتیز اختیاری است زیرا کوبرنتیز، بطور پیش فرض از namespace با مقدار default استفاده می کند. بوسیله دستور زیر میتوانید در کلاستر خود، namespace های موجود را مشاهده کنید.
+
+```
+kubectl get namespace
+```
+
+
+
+
+### ساخت namespace جدید
+
+برای ساخت یک namespace جدید میتواند از همان روشی که سایر منابع را میتوان ساخت استفاده کرد. فایلی با نام my-namespace.yaml ایجاد کرده و مقادیر زیر را در آن کپی کنید:
+
+```
+kind: Namespace
+apiVersion: v1
+metadata:
+  name: my-namespace
+  labels:
+    name: my-namespace
+```
+
+
+فایل را ذخیره کرده و از دستور زیر برای ساخت namespace استفاده کنید:
+
+```
+kubectl create -f my-namespace.yaml
+```
+
+
+### نام سرویس ها
+
+با استفاده از namespace ها، برنامه های دیگر میتوانند به یک سرویس با آدرس ثابت اشاره کنند که نیازی به تغییر آن با تغییر environment نیست. بطور مثال سرویس پایگاه داده MySql شما میتواند با نام یکسان mysql در production و staging باشد حتی اگر روی یک زیرساخت قرار داشته باشند. 
+
+این امکان به دلیل آنست که هر یک از منابع در کلاستر بطور پیش فرض تنها منابع دیگری که دارای namespace یکسان با آن منبع هستند را می بینند. این بدان معناست که می توان بدون بروز مشکل در نامگذاری یکسان، pod، service و replication controller هایی را تنها با namespace متفاوت ایجاد کرد.
+
+ درون یک namespace، نام های کوتاه (آدرس های) DNS سرویس ها، به IP سرویس ها در درون یک namespace ترجمه و اشاره خواهند شد. بطور مثال یک سرویس Elasticsearch با نام (آدرس) DNS مانند elasticsearch از طریق سایر کانتینر هایی که دارای namespace مشابه هستند قابل دسترس خواهد بود. البته همچنان امکان دسترسی به سرویس ها در namespace های دیگر با استفاده از نام کامل (آدرس کامل) DNS که دارای فرمت SERVICE-NAME.NAMESPACE-NAME است خواهد بود. بطور مثال elasticsearch.prod و یا elasticsearch.canary در محیط های production  و canary قابل دسترسی خواهند بود.
+
+
+### مثال
+
+در اینجا مثالی برای درک بهتر موضوع آورده شده است. ما میخواهیم سرویس فروشگاه موزیک با نام MyTunes را در کوبرنتیز دیپلوی کنیم. برای اینکار میتوانیم environment های متفاوت مانند production و staging و تعدادی برنامه های دیگر را در یک کلاستر یکسان اجرا کنیم. با اجرای دستور زیر میتوانید این موضوع را بهتر متوجه شوید:
+
+```
+kubectl get namespaces
+NAME               LABELS    STATUS
+default            <none>    Active
+mytunes-prod       <none>    Active
+mytunes-staging    <none>    Active
+my-other-app       <none>    Active
+```
+
+
+در اینجا می توانید تعدادی namespace  که در حال اجرا هستند را مشاهده کنید. سپس با اجرای دستور زیر لیست سرویس ها در staging را مشاهده خواهید کرد :
+
+```
+kubectl get services --namespace=mytunes-staging
+NAME     LABELS        SELECTOR      IP(S)            PORT(S)
+mytunes  name=mytunes  name=mytunes  10.43.250.14     80/TCP
+                                     104.185.824.125  
+mysql    name=mysql    name=mysql    10.43.250.63     3306/TCP
+```
+
+
+سپس لیست سرویس های در production را بررسی می کنیم: 
+
+```
+kubectl get services --namespace=mytunes-prod
+NAME     LABELS        SELECTOR      IP(S)            PORT(S)
+mytunes  name=mytunes  name=mytunes  10.43.241.145    80/TCP
+                                     104.199.132.213  
+mysql    name=mysql    name=mysql    10.43.245.77     3306/TCP
+```
+
+توجه شود که آدرس های آی پی به دلیل آنکه در namespace متفاوتی قرار دارند، متفاوت از هم هستند حتی با اینکه دارای نام سرویس یکسان می باشند. این قابلیت، پیکربندی برنامه شما را بطور چشمگیری ساده می کند - ازینرو شما کافیست تا در برنامه خود تنها به نام سرویس خود اشاره کنید - و این پتانسیل را داراست که بتوان نرم افزار را بطور یکسان برای تمامی environment ها پیکربندی کرد.
+
+
+### سخن آخر
+
+بهرحال اگر production و staing در یک کلاستر اجرا شوند یا نشوند، در هر صورت namespace ها یک روش عالی برای تقسیم برنامه های متفاوت درون یک کلاستر می باشند. همینطور namespace ها به عنوان تراز در جایی که می تواند محدودیت منابع را اعمال کرد استفاده می شوند که می توانید در پست های بعدی ما با آن آشنا شوید…
+