When we say Linux knowledge is very important, the reasons are both technical and strategic. This importance can be explained in a few layers:

The basic infrastructure of the IT and Cloud world :

More than 90% of large Internet services (from Google and Facebook to Amazon and Netflix) run on Linux.

The dominant operating system is in public schools such as AWS, GCP and Azure Linux.

Most important databases (MySQL, postgresql, mongodb, oracle DB works better on Linux)

Security and control :

Linux is the open source (Open Source); That is, it has transparency in the code and the security audit capability.

Low -level security tools and hardness (such as Selinux, Apparmor, iPTables, Nftables ,cgroup , namespace) are more powerful in Linux.

A specialist who knows Linux can take full control of the system, not just superficial use.

Devops and Automation :


Almost all Devops (ANSIBLE, TERRAFORM, KUBERNETES, DOCKER, JENKINS) tools are born on Linux and have the best performance on Linux.

Scripting with Bash and combining it with Linux tools (Sed, AWK, GREP, etc.) is the main part of automation.

Network infrastructure and internet :

Vital Internet services (DNS, Web, Mail, Proxy, VPN) have been developed on the Linux platform.

For a network or security specialist, Linux knowledge means direct management of infrastructure service

Stability and scalability :

Linux is a scalable and stable operating system; From mobile (Android) to supercamapiers.

The world's top 5 superpowers work on Linux.

Engineering :

Linux teaches the user how the system works, not just how to use it.

This makes the person upgraded from the "simple user" to the "engineer and architect"
🔑 :
Linux knowledge is important because the cornerstone of the modern digital world, security, and organizational transformation is based on Linux.


#linux #devops #k8s #clustering #kernel

در دنیای امروزی، حجم ترافیک شبکه به شکل انفجاری در حال رشد است. از دیتاسنترهای ابری گرفته تا شبکه‌های 5G، نیاز به پردازش سریع بسته‌های شبکه، بدون تأخیر (low latency) و با ظرفیت بالا (high throughput)، بیش از هر زمان دیگری احساس می‌شود.

سخت‌افزارهای سنتی مثل ASICها و FPGAها قدرت بالایی در پردازش بسته دارند، اما انعطاف‌پذیری کمی دارند. در مقابل، سرورهای عمومی (COTS Servers) انعطاف‌پذیرند، ولی عملکرد پردازش بسته روی Kernel Networking Stack محدود است.

اینجاست که DPDK (Data Plane Development Kit) وارد می‌شود:
یک کتابخانه متن‌باز برای پردازش کارآمد بسته‌ها روی سرورهای عمومی.
ا DPDK چیست؟

در واقع DPDK مجموعه‌ای از کتابخانه‌ها و درایورهاست که امکان بای‌پس کردن کرنل (Kernel Bypass) و دسترسی مستقیم به سخت‌افزار شبکه را فراهم می‌کند.
(مراجعه شود به monolithic kernel و micro service kernel )
زبان توسعه: C

مجوز: BSD (کاملاً متن‌باز)

پشتیبانی: جامعه متن‌باز + شرکت‌هایی مثل Intel، Red Hat، Mellanox (NVIDIA)، Arm، Huawei، و غیره
معماری DPDK

معماری DPDK را می‌توان به چند لایه تقسیم کرد:

مدیریت سخت‌افزار (HW Management)

مدیریت حافظه، CPU، و دستگاه‌ها

تضمین سازگاری روی CPUها و کرنل‌های مختلف

درایورها (Poll Mode Drivers)

حذف وقفه‌ها (interrupts) و استفاده از polling برای دریافت/ارسال بسته‌ها

کاهش overhead کرنل

ساختار داده‌ها

mempool: مدیریت حافظه بهینه برای bufferها

mbuf: نمایش بسته شبکه به عنوان یک شیء سبک

3.4 کتابخانه‌های پردازش بسته

Ethernet, IP fragmentation, TCP segmentation

QoS, Crypto, Compression

Tunnels, Classification, Flow Offload

لایه کاربردی

اپلیکیشن‌های شبکه‌ای مثل VNFها، روتر مجازی، فایروال، SDN Controller

ویژگی‌های کلیدی

ا High Performance: میلیون‌ها PPS (Packet Per Second) روی سخت‌افزار عمومی

Low Latency: مناسب برای 5G، مالی (HFT)، و Real-time

ا Portability: سازگار با Linux، FreeBSD، و معماری‌های CPU مختلف

ا Extensible: امکان افزودن ماژول‌های پردازش سفارشی

اکوسیستم DPDK

اکوسیستم DPDK بسیار گسترده است و شامل بخش‌های زیر می‌شود:

پروژه‌ها و نرم‌افزارهای وابسته

ا Open vSwitch (OVS-DPDK): نسخه شتاب‌یافته OVS برای دیتاسنترها

ا VPP (Vector Packet Processing): محصول پروژه FD.io، جایگزین kernel stack

ا Snort & Suricata (IDS/IPS): نسخه‌های بهینه‌سازی‌شده با DPDK

ا TRex Traffic Generator: ابزار تولید ترافیک پرقدرت مبتنی بر DPDK

صنعت و کاربردها

ا NFV (Network Function Virtualization): شتاب‌دهی VNFs روی سرورهای COTS

ا Telco/5G: Core Network، Baseband و Packet Core

ا Cloud & Data Center: بهبود عملکرد SDN و NFV

ا Security: شتاب‌دهی فایروال‌ها، VPNها، و ابزارهای رمزنگاری

رقبا و مکمل‌ها

ا eBPF / XDP (Linux Kernel): پردازش بسته درون کرنل

ا SmartNIC / FPGA: سخت‌افزارهای تخصصی با قابلیت offload

ا P4 / programmable switches: برنامه‌نویسی مستقیم روی ASIC

مزایا و چالش‌ها

✅ مزایا

پردازش بسته با کارایی بالا روی سخت‌افزار عمومی

متن‌باز بودن و حمایت جامعه بزرگ

کاهش نیاز به سخت‌افزار اختصاصی گران‌قیمت

انعطاف‌پذیری برای توسعه اپلیکیشن‌های سفارشی

❌ چالش‌ها

نیاز به Pinned CPU cores → مصرف منابع زیاد

پیچیدگی برنامه‌نویسی (C سطح پایین)

مناسب‌تر برای محیط‌های user space → ادغام با کرنل سخت‌تر است

بهینه‌سازی دقیق لازم دارد (NUMA, Cache, HugePages)

آینده DPDK

ادغام بیشتر با SmartNICs و programmable hardware

ترکیب با eBPF/XDP برای انعطاف‌پذیری بالاتر

استفاده گسترده‌تر در 5G Core, Edge Computing, و Cloud-native Networking

تمرکز روی energy efficiency برای کاهش مصرف CPU


#linux #kernel #sdn #cloud #devops #ebpf #dpdk

https://t.iss.one/unixmens

رشد سریع دیتاسنترهای ابری، شبکه‌های 5G و سرویس‌های Cloud-native، نیاز به پردازش پرسرعت بسته‌های شبکه بیش از هر زمان دیگری اهمیت پیدا کرده است. روش سنتی مبتنی بر Kernel Networking Stack به دلیل overhead بالا، پاسخگوی نیازهای امروزی نیست.

برای رفع این مشکل دو رویکرد اصلی مطرح شده‌اند:

ا DPDK (Data Plane Development Kit): رویکرد Kernel bypass در User Space

ا eBPF/XDP (extended Berkeley Packet Filter): پردازش انعطاف‌پذیر در Kernel Space
اینجا به بررسی هر یک میپردازیم :

معماری و فلسفه طراحیeBPF

ا eBPF یک مکانیزم درون‌هسته‌ای (in-kernel) است که به برنامه‌ها اجازه می‌دهد کدهای کوچک و امن را در کرنل لینوکس اجرا کنند. فلسفه اصلی آن انعطاف‌پذیری و قابلیت مشاهده (observability) است. eBPF به کاربران اجازه می‌دهد بدون تغییر در کرنل، منطق دلخواه خود را در سطح شبکه، امنیت و مانیتورینگ اضافه کنند. برنامه‌های eBPF در محیطی ایزوله (sandbox) اجرا می‌شوند و توسط verifier کرنل اعتبارسنجی می‌شوند تا مانع ایجاد مشکلات پایداری شوند.



ا DPDK یک مجموعه کتابخانه و درایور است که هدف اصلی آن حداکثرسازی سرعت پردازش بسته‌ها در فضای کاربر (user space) است. فلسفه آن مبتنی بر دور زدن کرنل و حذف لایه‌های سربار مانند socket و interrupt است. DPDK با استفاده از تکنیک‌هایی مانند polling و zero-copy، پردازش بسته‌ها را به شکل مستقیم از NIC (کارت شبکه) به فضای کاربر منتقل می‌کند.

عملکرد و کارایی

ا eBPF بیشتر بر روی انعطاف‌پذیری و قابلیت برنامه‌ریزی تمرکز دارد. این یعنی می‌توان بدون نوشتن ماژول کرنل، سیاست‌های پیچیده فایروال، ردیابی جریان‌ها و ابزارهای observability مانند bcc یا Cilium را ساخت. از نظر کارایی، سرعت آن مناسب است اما به دلیل وجود در کرنل، همچنان محدودیت‌هایی دارد.

ا DPDK برای عملکرد خام (raw performance) طراحی شده است. در سیستم‌هایی که نیاز به میلیون‌ها بسته در ثانیه (Mpps) وجود دارد، DPDK انتخاب بهتری است. اما این سرعت با مصرف بالاتر منابع CPU و پیچیدگی بیشتر توسعه همراه است.

سطح پیاده‌سازی و توسعه

ا eBPF توسعه‌دهندگان را قادر می‌سازد با استفاده از زبان C یا LLVM-based زبان‌ها، کدهای کوچک و قابل بررسی تولید کنند. توسعه آن ساده‌تر است زیرا مستقیماً با کرنل لینوکس ادغام شده و نیاز به مدیریت مستقیم منابع سخت‌افزاری ندارد.

ا DPDK توسعه‌دهنده را ملزم می‌کند که با سطح پایین‌تری از سخت‌افزار و پردازش بسته‌ها کار کند. برنامه‌نویسی با DPDK نیازمند درک عمیق از معماری CPU، حافظه و NIC است.

کاربردها eBPF

ساخت فایروال‌های مدرن مانند Cilium در Kubernetes.

مانیتورینگ شبکه، سیستم و عملکرد برنامه‌ها (مانند bpftrace).

امنیت در سطح هسته با قابلیت مشاهده دقیق رفتار برنامه‌ها.

ابزارهای observability برای Cloud-native environments.

DPDK

ساخت سیستم‌های SDN و NFV با کارایی بالا.

استفاده در فایروال‌ها، load balancerها و IDS/IPS با نیاز به throughput بسیار بالا.

محیط‌هایی که latency و jitter باید حداقل باشد، مانند مخابرات و 5G core.

زیرساخت‌های دیتاسنتر با پردازش میلیون‌ها بسته در ثانیه.

مزایا و محدودیت‌ها

ا eBPF مزایای بزرگی مانند سادگی توسعه، امنیت، قابلیت ترکیب با ابزارهای موجود لینوکس و عدم نیاز به bypass کرنل دارد. محدودیت اصلی آن، کارایی پایین‌تر نسبت به DPDK در بارهای بسیار سنگین است.

ا DPDK در کارایی بی‌نظیر است اما توسعه پیچیده‌تر، نیاز به منابع CPU بالا، و مدیریت دشوارتر دارد. همچنین برخلاف eBPF، tightly coupled با کرنل نیست و قابلیت observability گسترده ارائه نمی‌دهد.


مکمل بودن

ا eBPF و DPDK الزاماً رقیب مستقیم نیستند. در بسیاری از معماری‌های مدرن، این دو مکمل هم هستند:

ا eBPF: برای مشاهده‌پذیری (observability)، مانیتورینگ، امنیت و کنترل.

ا DPDK: برای دیتاپلین پرسرعت و پردازش سنگین بسته‌ها


#linux #kernel #devops #kubernetes #ebpf #dpdk


https://t.iss.one/unixmens

ابزار Kubernetes و چالش‌های آن: چرا ترکیب OpenShift/KubeSphere با KubeVirt بهترین گزینه برای سازمان‌هاست؟

مقدمه

بسیاری تصور می‌کنند گوگل از Kubernetes در زیرساخت داخلی خود استفاده می‌کند. در حالی که واقعیت این است که گوگل همچنان از سیستم‌های پیشرفته‌تر خود یعنی Borg و Omega بهره می‌برد؛ زیرا این سیستم‌ها برای مدیریت دیتاسنترهای عظیم گوگل طراحی شده‌اند و در مقیاس‌های فراتر از Kubernetes کارایی بالاتری دارند. Kubernetes در واقع بر اساس تجربیات همان پروژه‌ها ساخته شد و به صورت متن‌باز ارائه گردید تا جامعه جهانی از آن استفاده کند.

اما نکته مهم اینجاست: Kubernetes در دنیای سازمانی امروز، با وجود قدرت و انعطاف‌پذیری بالا، همچنان چالش‌برانگیز است.

چرا Kubernetes چالش‌برانگیز است؟

پیچیدگی عملیاتی: نصب، مدیریت و نگهداری Kubernetes حتی برای تیم‌های حرفه‌ای آسان نیست.

نیاز به مهارت بالا: تیم‌ها باید دانش عمیق در مفاهیم Networking، Storage، Security و CI/CD داشته باشند.

چالش‌های امنیتی: به‌صورت پیش‌فرض امنیت Kubernetes در سطح Enterprise کافی نیست.

مدیریت چندخوشه‌ای (Multi-Cluster): برای سازمان‌های بزرگ به یک کابوس مدیریتی تبدیل می‌شود.

هزینه آموزش و یادگیری: ورود تیم‌های جدید زمان‌بر و پرهزینه است

چرا گوگل هنوز Borg و Omega را ترجیح می‌دهد؟

مقیاس‌پذیری فراتر از Kubernetes: در دیتاسنترهای گوگل که میلیون‌ها کانتینر اجرا می‌شود، Borg و Omega بهینه‌تر هستند.

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

کاستومایز اختصاصی: Borg و Omega کاملاً بر اساس نیازهای خاص گوگل طراحی شده‌اند، در حالی که Kubernetes یک پلتفرم عمومی برای جامعه جهانی است.

راه‌حل سازمان‌ها: OpenShift و KubeSphere

برای بیشتر سازمان‌ها، استفاده مستقیم از Kubernetes بدون ابزارهای تکمیلی منجر به مشکلات جدی می‌شود. اینجا است که OpenShift و KubeSphere وارد میدان می‌شوند:

OpenShift (Red Hat):

امنیت سازمانی قوی (SELinux، RBAC پیشرفته).

تجربه توسعه‌دهنده کامل (داشبورد، CI/CD داخلی).

پشتیبانی رسمی و Enterprise از سوی Red Hat/IBM.


KubeSphere:

نصب ساده و رابط کاربری کاربرپسند.

مدیریت چند خوشه‌ای (Multi-Cluster) با قابلیت‌های گسترده.

ماژول‌های آماده برای DevOps، نظارت، و Service Mesh.

انتخاب مناسب برای سازمان‌هایی که به سادگی و انعطاف نیاز دارند.

نقش KubeVirt: اتصال VMها و Containerها

یکی از مشکلات رایج سازمان‌ها این است که هنوز بارهای کاری Legacy (روی VMها) دارند.
با KubeVirt:

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

مهاجرت تدریجی از VM به Container بدون نیاز به دو پلتفرم جداگانه امکان‌پذیر می‌شود.

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


در حالی که گوگل همچنان برای دیتاسنترهای داخلی خود از Borg و Omega استفاده می‌کند، Kubernetes به عنوان استاندارد جهانی معرفی شده است. با این وجود، Kubernetes به‌تنهایی برای سازمان‌ها بسیار چالش‌برانگیز است.

راه‌حل درست برای ورود به دنیای Cloud-Native در سطح سازمانی، استفاده از پلتفرم‌های تکمیلی مثل OpenShift یا KubeSphere و ترکیب آن‌ها با KubeVirt است. این ترکیب نه‌تنها مشکلات پیچیدگی و امنیت را کاهش می‌دهد، بلکه امکان همگرایی کامل میان بارهای کاری سنتی (VM) و مدرن (Container) را فراهم می‌کند.
#kubernetes #devops #clustering #k8s #linux #security #google #borg #omega
https://t.iss.one/unixmens

نقد و بررسی مدیریت تست در Azure DevOps و مقایسه با GitLab



#azure #devops #git #gitlab #test #QA


https://t.iss.one/unixmens

دواپس و مسیر های ورود به آن



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

به‌عبارت دیگر، متخصص زیرساخت کسی است که هم شبکه را می‌شناسد، هم کدنویسی بلد است، هم از سیستم‌ها شناخت عمیق دارد، و هم می‌تواند کل این پازل را در قالب یک معماری منسجم کنار هم بچیند.
در واقع زیرساختی‌ها تنها مجری نیستند. به دلیل درک جامع خود، می‌توانند نقش مشاور استراتژیک ایفا کنند و راهکارهایی ارائه دهند که از نظر اقتصادی، امنیتی و عملیاتی بهترین نتیجه را برای سازمان به همراه داشته باشد.

اما چرا ؟

🔹 دلیلش ساده است:
وقتی سال‌ها با سیستم‌عامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کرده‌ای، به‌صورت تجربی یاد می‌گیری که:

چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویس‌ها طراحی و بهینه کنی.

چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.

چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.

چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد

تفاوت با بقیه مسیرها

برنامه‌نویس‌ها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم می‌شود، عمق لازم را ندارند.

متخصصان شبکه هم system design را معمولاً فقط در لایه‌ی ارتباطات می‌شناسند (topology، routing، segmentation) نه در کل stack.


اما متخصص زیرساخت، وقتی از system design صحبت می‌کند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.

چرا این در DevOps مهم است؟

چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاس‌پذیر و قابل‌اعتماد.

اگر system design بلد نباشی، صرفاً ابزارها را به هم می‌دوزی.

ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب می‌کنی.


به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم می‌تواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعه‌دهنده باقی می‌مانند.



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

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

دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .

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

هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .

اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.


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

وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.


#devops #linux #culture #team

https://t.iss.one/unixmens

DevOps has transformed how organizations deliver software by introducing automation, collaboration, and continuous integration/continuous delivery (CI/CD). Yet, databases have traditionally lagged behind in this transformation. Database changes are often managed manually, leading to slow deployments, risks of errors, and lack of visibility. "Database DevOps" aims to close this gap by applying DevOps principles directly to the database lifecycle.

One powerful approach to enabling Database DevOps is combining GitLab CI/CD with Liquibase, a database schema change management tool. This integration allows teams to automate, version, and safely deploy database changes alongside application code.

What is Database DevOps?

Database DevOps (or Database CI/CD) is the practice of managing database schema and data changes with the same rigor as application code. The core principles include:

Version control for database migrations.

Automation of deployment and rollback processes.

Continuous testing of schema and data integrity.

Drift detection to prevent environment inconsistencies.

Collaboration between developers, DBAs, and operations.

Auditing and traceability for compliance and governance.


Elite DevOps teams are 3.4x more likely to adopt database change management practices than low performers, underlining its importance

GitLab and Liquibase Integration

In the GitLab article "How to Bring DevOps to the Database with GitLab and Liquibase", the authors show how Liquibase can be seamlessly integrated into GitLab pipelines to enable full database CI/CD.

Key Components:

1. Liquibase – A tool for managing database migrations through versioned "changesets."


2. GitLab CI/CD – Automates pipelines for building, testing, and deploying database changes.


3. SQL Server (example DB) – The article demonstrates with SQL Server, but the approach applies to other databases too.


Example Pipeline Stages

The tutorial outlines a sample GitLab pipeline with these stages:

Build – Validate Liquibase properties and configurations.

Test – Run Liquibase updateSQL and checks run to ensure safe changes.

Deploy – Apply migrations (liquibase update) to environments (DEV → QA → PROD).

Compare – Use liquibase diff to detect drift between environments.

Post – Create schema snapshots with liquibase snapshot for auditing.

Benefits

1. Automation – Database changes run through the same CI/CD pipeline as code.

2. Validation & Checks – Prevents dangerous operations (DROP, TRUNCATE, etc


3. Rollback Support – Enables reverting last applied updates where possible

4. Drift Detection – Identifies schema inconsistencies between environments

5. Auditing – Snapshots and logs ensure traceability of changes

6. Collaboration – Developers and DBAs work together via version control and merge requests



https://about.gitlab.com/blog/how-to-bring-devops-to-the-database-with-gitlab-and-liquibase/


#database #devops #ci #cd #gitlab
https://t.iss.one/unixmens
unixmens