<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های Armin K Milani</title><link>https://virgool.ir/feed/@armin.k.milani</link><description>SRE</description><language>fa</language><pubDate>2026-11-11 23:51:33</pubDate><image><url>https://files.virgool.ir/upload/users/6413/avatar/rk4uus.png</url><title>Armin K Milani</title><link>https://virgool.ir/@armin.k.milani</link></image><item><title>راه اندازی 3.9 OpenShift با استفاده از CRI-O به جای Docker</title><link>https://virgool.ir/@armin.k.milani/openshift-cri-o-yxirivon7hvf</link><description>تمرکز ما در این نوشته روی راه اندازی OpenShift و استفاده از CRI-O به جای Docker است بنا بر این مواردی مانند Multi-Master یا Persistent Storage در این مطلب پوشش داده نشده است و همه ی مراحل راه اندازی روی یک هاست و یه صورت All-In-One انجام خواهد شد.اما CRI-O چیست و چرا از آن استفاده کنیم:به طور خلاصه CRI-O مانند Docker یک Container Runtime و جایگزینی برای Docker است (البته نه در همه ی موارد) که امکان اجرای کانتینر های OCI یا Open Container Initiative (که کانتینر های Docker را نیز شامل میشود) را داراست.اما چرا به جای Docker  از CRI-O استفاده کنیم؟ چون CRI-O ساخته شده است تا بهترین Container Runtime  برای Kubernetes باشد. در حقیقت تمام هدف CRI-O ایجاد بهترین شرایط برای اجرای کانتینر ها در Kubernetes است بنا بر این:برعکس Docker که دایما و با سرعت زیاد در حال تغییر, بروز رسانی و ارایه ی ورژن های جدید است تمامی بروز رسانی ها در ورژن های CRI-O حول محور kubernetes  انجام میشود و فقط امکاناتی به CRI-O اضافه می شود که در Kubernetes نیاز باشد.همچنین تمامی تست ها از نظر Performance  و  Stability نیز بر اساس Kubernetes انجام میشود و ورژن های جدید فقط در صورت همخوانی کامل با Kubernetes ارایه می شوند.بنا بر این اگر از Kubernetes یا OpenShift (که از خود از Kubernetes برای Orchestration کانتینر ها بهره می برد) استفاده می کنید, CRI-O گزینه ای سبکتر, سریع تر و پایدار تر است.راه اندازی OpenShift با CRI-O:من از یک هاست دارای 4G RAM و 2XCore CPU با سیستم عامل CentOS 7.5 برای راه اندازی تمامی اجزای OpenShift استفاده کردم و  نصب از طریق Ansible و Advance Installation انجام خواهد شد.نکته ی مهم: من از یک VPS خارج از کشور برای این تست استفاده کردم بنا بر این مشکلی با تحریم های موجود روی Registry ها برای دریافت image ها نداشتم در صورتی که سرور شما داخل ایران است قبل از ادامه باید از یکی از روش های شکستن تحریم Docker Registry استفاده کنید. به طور مثال VPN یا Mirror-Registry و یا استفاده از سرویس shecan.ir .ابتدا مراحل آمده سازی هاست طبق مستندات Openshift Origin انجام میدهیم:طبق مستندات Openshift Origin میبایست SELinux فعال باشد در غیر این صورت هنگام اجرای Ansible ممکن است با Error مواجه شوید.ست کردن Hostname:# hostnamectl set-hostname openshift-cri-o&#xA;# echo &#34;&lt;Example-IP&gt;    openshift-cri-o&#34; &gt;&gt; /etc/hostsدر بالا عبارت &lt;Example-IP&gt; را با IP ی هاست خود جایگزین کنید.نصب پیش نیاز ها:# yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct epel-releaseسپس:# yum install ansible pyopenssl docker&#xA;# systemctl start docker&#xA;# systemctl enable dockerدریافت Ansible برای نصب Openshift:# cd ~&#xA;# git clone https://github.com/openshift/openshift-ansible&#xA;# cd openshift-ansible&#xA;# git checkout release-3.9ست کردن DNS در کانفیگ اینترفیس:# vim /etc/sysconfig/network-scripts/ifcfg-eth1&#xA;...&#xA;DNS1=8.8.8.8&#xA;DNS2=1.1.1.1&#xA;...اعمال تغییرات:# systemctl restart networkنصب CRI-O با استفاده از ریپوزیتوری virt7-container-common-candidate :# vim /etc/yum.repos.d/virt7-container.repo متن زیر را اضافه کنید:[virt7-container-common-candidate]&#xA;name=virt7-container-common-candidate&#xA;baseurl=https://cbs.centos.org/repos/virt7-container-common-candidate/x86_64/os/&#xA;enabled=1&#xA;gpgcheck=0سپس: # yum install cri-o cri-tools&#xA;# systemctl start crio&#xA;# systemctl enable crioکانفیگ Inventory:# vim /etc/ansible/hostsمتن زیر را به جای متن پیش فرض وارد کنید:# Inventory&#xA;[OSEv3:children]&#xA;masters&#xA;nodes&#xA;etcd&#xA;&#xA;[OSEv3:vars]&#xA;openshift_deployment_type=origin&#xA;openshift_release=3.9&#xA;openshift_disable_check=disk_availability,memory_availability&#xA;openshift_crio_use_rpm=True&#xA;openshift_use_crio=True&#xA;openshift_node_kubelet_args={&#39;image-service-endpoint&#39;: [&#39;unix:///var/run/crio.sock&#39;], &#39;container-runtime-endpoint&#39;: [&#39;unix:///var/run/crio.sock&#39;], &#39;container-runtime&#39;: [&#39;remote&#39;], &#39;runtime-request-timeout&#39;: [&#39;15m&#39;]}&#xA;&#xA;[masters]&#xA;localhost ansible_connection=local&#xA;&#xA;[etcd]&#xA;localhost ansible_connection=local&#xA;&#xA;[nodes]&#xA;localhost ansible_connection=local openshift_schedulable=true openshift_node_labels=&#34;{&#39;region&#39;: &#39;infra&#39;, &#39;zone&#39;: &#39;default&#39;, &#39;runtime&#39;: &#39;cri-o&#39;}&#34;اجرای Ansible  برای بررسی پیش نیاز ها:# cd /root/openshift-ansible&#xA;# ansible-playbook playbooks/prerequisites.ymlدر صورتی که Error ای دریافت نکردید و با موفقیت به اتمام رسید مرحله ی بعدی را اجرا کنید در غیر این صورت ابتدا Error را برطرف نمایید و همان Ansible بالا را مجدد اجرا کنید.اجرای Ansible برای نصب OpenShift:# ansible-playbook playbooks/deploy_cluster.ymlاجرای Ansible بالا بسته به کانفیگ Inventory زمان زیادی میبرد و چندین دقیقه برای اجرا روی یک هاست زمان خواهد برد.بعد از اتمام hostname سرور را به فایل hosts روی سیستم خود اضافه کنید و کنسول وب Openshift را با آدرس https://openshift-cri-o:8443 روی مرورگر خود باز کنید.# echo &#34;&lt;Example-IP&gt;    openshift-cri-o&#34; &gt;&gt; /etc/hostsمیتوانید با username: system و password: admin لاگین کنید.برای بررسی عملکرد صحیح OpenShift از قسمت Service Catalog در پنل وب یک service دلخواه  که نیازی به Persistent Storage نداشته باشد اجرا کنید برای مثال Nginx.با اجرای دستور زیر:# docker ps -aمتوجه خواهید شد که هیچ یک از کانتینرهای OpenShift از جمله سرویس های زیرساختی (Infra) روی docker اجرا نشده است .برای بررسی کانتینر های در حال اجرا در CRI-O از دستور زیر استفاده نمایید:# runc list  برای مطالعه ی بیشتر در مورد مزایای CRI-O می توانید این لینک رو مطالعه کنید که مربوط به RedHat-Atomic-Project هست.</description><category>Armin K Milani</category><author>Armin K Milani</author><pubDate>Wed, 06 Jun 2018 07:56:44 +0430</pubDate></item><item><title>ارسال لاگ Docker container ها به ELK از طریق درایور های لاگ</title><link>https://virgool.ir/@armin.k.milani/ارسال-لاگ-docker-container-ها-به-elk-از-طریق-لاگ-درایور-ampf1p8fajv7</link><description>جهت اطلاع:بدون استفاده از لاگ درایور های داکر هم می توانید لاگ سرویس های درون کانتینر را به سیستم های مدیریت لاگ مثل ELK یا Graylog ارسال کنید برای این کار می توانید پوشه ی لاگ داخل کانتینر را با استفاده از volumes روی هاست map کنید (یا از لاگ capture شده توسط لاگ درایور پیشفرض داکر استفاده کنید) و فایل ها را با یک ارسال کننده مانند Filebeat یا Fluentd به ELK (یا Graylog) ارسال کنید.اما هدف این مطلب استفاده از درایور های داکر برای این کار است.گام اول:در صورتی که کامند &#34;docker logs&#34; همان لاگی که مد نظر شما هست رو نمایش میدهد از این گام عبور کنید و به گام دوم برید.قبل از هر چیز باید بدانیم که داکر به صورت پیش فرض standard output یا همان stdout و همچنین stderr مربوط به پروسسی که دارای pid ۱  داخل کانتینر هست را به عنوان لاگ جمع آوری می کند و از طریق کامند زیر نمایش میدهد.docker logs -f &lt;container-name&gt;در صورتی که از image های معتبر از پیش ساخته شده استفاده می کنید معمولا این مورد از قبل در نظر گرفته شده و نیازی به تغییر نیست اما اگر خودتان در حال ساختن docker image مورد نیازتان هستید میبایست لاگ مربوط به سرویس را از روش های مختلف به stdout ارسال کنید یکی از این روش ها استفاده از symbolic link هست به طور مثال برای سرویس رایج nginx می توانید از طریق کامند زیر برای ارسال لاگ به stdout استفاده کنید (مشاهده ی نمونه ی Dockerfile) :ln -sf /dev/stdout /var/log/nginx/access.logروش بعدی ارسال مستقیم لاگ به آدرس stdout است به طور مثال برای همان سرویس nginx می توانید داخل فایل کانفیگ nginx از عبارت زیر استفاده کنید:...&#xA;access_log /dev/stdout;&#xA;...در صورتی که سرویس مورد نظر شما به هر دلیل دارای PID  به غیر از ۱ باشد (معمولا نباید اینطور باشد) میبایست TTY را در هنگام اجرای کانتینر فعال کنید و لاگ را به مسیر زیر ارسال کنید/dev/consoleگام دوم:داکر دارای چندین Log Driver است که می توانید با استفاده از آنها لاگ های جمع آوری شده توسط داکر را به ELK ( یا Graylog) ارسال کنید. توجه داشته باشید که بعد از تغییر لاگ درایور پیش فرض داکر به یکی از موارد زیر  کامند &#34;docker logs&#34; یا &#34;docker-compose logs&#34; دیگر لاگ های جمع آوری شده را نمایش نخواهد داد.GELFیکی از درایور هایی که می خواهیم بررسی کنیم GELF نام دارد که مخفف Graylog Extended Log Format هست. GELF یک استاندارد برای ارسال لاگ است که توسط log collector های مختلف مانند Logstash یا Fluentd و همچنین Greylog ساپورت می شود. پس با توجه به اینکه Input مربوط به GELF برای Logstash موجود هست می توانید با استفاده از این درایور لاگ ها را به ELK ارسال کنید.برای استفاده از لاگ درایور GELF می توانید عبارت های &#34;log-driver&#34; و &#34;log-opts&#34; را داخل فایل :/etc/docker/daemon.jsonبه صورت زیر تغییر بدهید (یا اضافه کنید):...&#xA;&#xA;&#34;log-driver&#34;: &#34;gelf&#34;,&#xA;&#34;log-opts&#34;: {&#xA;  &#34;gelf-address&#34;: &#34;udp://logstash.test-server.com:12201&#34;&#xA;    },&#xA;&#xA;...مشخص هست که عبارت gelf-address آدرس سرور logstash است. مانند مثال بالا protocol و port حتما باید در آدرس قید شود. در حال حاظر GELF روی داکر فقط از UDP ساپورت میکند.در صورت تغییر فایل daemon.json این درایور برای تمامی کانتینر ها استفاده خواهد شد در صورتی که مایل هستید برای کانتینر های مختلف از درایور های مختلف استفاده کنید میتوانید از آپشن های موجود در Docker CLI یا فایل Docker Compose استفاده کنید.یکی دیگر از &#34;log-opts&#34; هایی که امکان استفاده در این درایور را دارد tag هست استفاده از این آپشن اجباری نیست اما برای دسته بندی لاگ ها و امکان جداسازی لاگ در logstash می توانید از tag استفاده کنید.و نهایتا کانفیگ logstash به صورتی که لاگ های ارسال شده توسط داکر را دریافت کند.نمونه ی کانفیگ GELF Input برای Logstash:input {&#xA;    gelf {&#xA;        port =&gt; 12201&#xA;        type =&gt; gelf&#xA;    }&#xA;}معایب:آدرسی که در قسمت log-opts برای logstash وارد کردید فقط هنگام start کانتینر resolve خواهد شد و بعد از start شدن  DNS تاثیری نخواهد داشت بنا بر این به هر دلیل اگر نیاز باشد ip ی logstash تغییر کند مجبور خواهید شد کانتینر را restart کنید. همچنین این درایور در حال حاظر امکان ایجاد failover برای logstash  را ندارد.فقط با UDP Protocol کار میکند.Fluentdاگر با Fluentd آشنایی ندارید باید بگویم سرویسی شبیه به Logstash هست که امکان ارسال , دریافت , فیلتر کردن , اضافه یا کم کردن فیلد های لاگ  , اضافه کردن tag و بسیاری قابلیت های دیگر را دارد.یکی دیگر از درایور های لاگ Fluentd هست که برای استفاده از این درایور میبایست سرویس Fluentd را  نصب کنید (می تواند به صورت کانتینر باشد).برای استفاده از لاگ درایور Fluentd میتونید عبارت های &#34;log-driver&#34; و &#34;log-opts&#34; رو داخل فایل :/etc/docker/daemon.jsonبه صورت زیر تغییر بدید (یا اضافه کنید):...&#xA;&#xA;&#34;log-driver&#34;: &#34;fluentd&#34;,&#xA;&#34;log-opts&#34;: {&#xA;  &#34;fluentd-address&#34;: &#34;fluentd.test-server.com:12201&#34;&#xA;    },&#xA;&#xA;...مشخص است عبارت fluentd-address همان آدرس سرور fluentd میباشد که به صورت پیشفرض localhost است. Protocol نیز به صورت پیشفرض TCP است.همچنین کانفیگ Fluentd برای دریافت لاگ از داکر(فایل td-agent.conf)  :&lt;source&gt;&#xA;   @type forward&#xA; &lt;/source&gt;در صورت استفاده از درایور Fluentd امکانات و گزینه های زیادی پیش روی شما خواهد بود و می توانید از تمامی Plugin های خروجی Fluentd بسته به نیاز استفاده کنید.به طور مثال می توانید Fluentd را جایگزین logstash کنید و کار فیلترینگ (grok و ...) , aggregation و ارسال به Elasticsearch را به Fluentd بسپارید. یا روی هر داکر هاست یک کانتینر Fluentd داشته باشید که کار tag زدن , queueing و buffering و همچنین ارسال به logstash (یا یک Fluentd دیگر) را انجام دهد.برای اطلاع از تمامی توانایی ها و امکانات Fluentd به مستندات سرویس Fluentd مراجعه کنید.همچنین برای ارسال لاگ کانتینر ها به ELK یا Greylog گزینه های دیگری نیز مانند درایور syslog دارید. لیست کامل لاگ درایور های داکر را می توانید اینجا مشاهده کنید.</description><category>Armin K Milani</category><author>Armin K Milani</author><pubDate>Sat, 31 Mar 2018 05:13:56 +0430</pubDate></item></channel></rss>