In this post: Learn about the importance of interoperability testing between the various 5G core network functions.Read about the challenges associated with 5G core lifecycle management, software versioning, and its impact on testing and verification.Find out how Red Hat and Rebaca’s autonomous continuous testing framework helps service providers with the consistent delivery of compliant and interoperable 5G core cloud-native network functions (CNFs).The challenge of 5G core interoperabilityDeploying a 5G core network involves several key components, including the Access and Mobility Managem

via Red Hat Blog https://ift.tt/QETwY6G

در میان واژه ها گم شدیم .
قطعا در هر چیزی امکان رشد وجود دارد ، ولی

وقتی به معنی تاب آوری یا resistance فکر میکنیم ، یعنی : توانایی بازگشت به نقطه قابل اتکا و stable

یاد جمله ای می افتم :
میگن ، میگذرد ، ولی هیچ کس نمیگوید به چه قیمتی !!!!؟؟؟

هیچ کس بدهی ها را محاسبه نمیکند .
مشکلات ایجاد شده را

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

As a system administrator, keeping a Linux fleet running efficiently and securely can feel like you’re constantly putting out fires. Just when you address one issue, another one pops up, often because of a lack of visibility across your environment and too many manual, repetitive tasks. But what if you could spend less time reacting to problems and more time on the work that drives your business forward? That's why we're committed to building and improving new capabilities in Red Hat Insights for Red Hat Enterprise Linux (RHEL) to help you stay ahead of the curve.Insights for RHEL helps you

via Red Hat Blog https://ift.tt/31QJoBg

With cyberattacks on the rise, increasing software supply chain visibility is crucial for organizations to proactively identify and mitigate vulnerabilities within their applications and infrastructure. However, handling diverse security data sources such as software bill of materials (SBOMs), critical vulnerabilities and exploits (CVEs), and vendor advisories remains a major challenge due to inconsistent formats, varying levels of detail, and the lack of standardized integration points. Addressing this challenge requires not only better tools, but also open collaboration across the entire eco

via Red Hat Blog https://ift.tt/OUvA29c

در نگاه اول اینطور به نظر میاد که چون زبان‌های مفسری (مثل Python, PHP, Ruby, JavaScript/Node.js) نیازی به کامپایل شدن ندارند، پس در CI/CD pipeline هم مرحله‌ی build لازم نیست. اما در واقعیت اینطور نیست و دلیل‌های مهمی وجود داره که چرا حتی برای زبان‌های مفسری هم یک stage به نام build داریم:


۱. تعریف گسترده‌ی Build در CI

در CI، منظور از Build فقط کامپایل کد منبع به باینری نیست.

در واقع Build یعنی: آماده‌سازی artifact قابل استفاده (قابل اجرا یا قابل دیپلوی) از کد منبع.

برای زبان‌های مفسری، این می‌تونه شامل کارهای زیر باشه:

نصب و freeze کردن وابستگی‌ها (pip install -r requirements.txt در Python یا npm install در Node.js)

بسته‌بندی کد به صورت آرشیو یا کانتینر (zip, tar.gz, docker image)

اجرای ابزارهای code generation یا transpiler (مثل TypeScript → JavaScript یا Sass → CSS)

ا minify و optimize کردن کدهای front-end

آماده‌سازی migrationها یا فایل‌های config برای استقرار

۲. تولید Artifact پایدار

ا CI/CD به دنبال اینه که یک خروجی قابل تکرار بسازه.

در زبان‌های مفسری، artifact می‌تونه یک Docker image، یک بسته‌ی Python (.whl یا .tar.gz)، یا یک بسته‌ی npm باشد.

این artifact تضمین می‌کنه که همون نسخه‌ی تست‌شده، به محیط stage و production منتقل بشه.

۳. جداسازی Concerns

مرحله build جدا میشه تا مطمئن بشیم:

وابستگی‌ها درست نصب شدن.

نسخه‌ی کد پایدار و بدون خطا آماده شده.

تست‌ها بعداً روی artifact اجرا بشن (نه روی سورس خام).

تیم‌ها یک مرز واضح بین "آماده‌سازی" و "تست/استقرار" داشته باشن.

۴. مثال‌ها

Python:

stages:
- build
- test
- deploy

build:
stage: build
script:
- pip install -r requirements.txt
- pytest --collect-only # بررسی اینکه همه چیز قابل بارگذاری است
- python setup.py sdist bdist_wheel # تولید پکیج
artifacts:
paths:
- dist/

Node.js:

build:
stage: build
script:
- npm install
- npm run build # مثلا build کردن React/Next.js
artifacts:
paths:
- dist/
در واقع حتی اگر زبان مفسری باشه و کامپایل نشه، مرحله build به معنی آماده‌سازی محیط، وابستگی‌ها، artifact و بسته‌ی قابل استقرار هست.



#devops



https:// t.iss.one/unixmens

آیا elk یک log management هست یا ابزار مانیتورینگ ؟

پاسخ هردو


در دنیای امروز که سیستم‌ها پیچیده، توزیع‌شده و اغلب مبتنی بر ابر و راهکارهای cloud-native و Microservices هستند، سازمان‌ها بیش از هر زمان دیگری به ابزارهایی برای جمع‌آوری، تحلیل و نظارت بر داده‌ها نیاز دارند. یعنی ورود به مفاهیم و ساختار های data driven.
در این مسیر، استک ELK به‌عنوان یکی از محبوب‌ترین راهکارها برای Log Management و حتی Monitoring / Observability شناخته می‌شود.

اما اگر عمیق تر نگاه کنیم آیا این ابزار صرفاً مدیریت لاگ انجام می‌دهد یا می‌تواند نقش مانیتورینگ را هم ایفا کند؟


در واقع ELK چیست؟

در حقیقت ELK مخفف سه مؤلفه اصلی است:

Elasticsearch → موتور جستجو و پایگاه داده NoSQL برای ذخیره‌سازی و ایندکس‌گذاری لاگ‌ها.

Logstash → ابزار پردازش داده‌ها (ETL) برای جمع‌آوری، فیلتر و انتقال داده.

Kibana → ابزار تجسم داده‌ها (Visualization) و ساخت داشبورد.


نکته : ما نود های مختلفی داریم برای data برای ذخیره‌سازی داکیومنت هاذو شارد ها .
نود master
نود ingest
نود cordinator
نود data که خود این نود هم شامل ساختار ilm هست که به hot 🔥, warm 🥵 , و cold 🥶 را شامل میشود و در ادامه repository برای ذخیره داده های قدیمی تر .

نکته : میتوان در کلاستر از logslash استفاده نکرد و از نود با وظیفه ingest استفاده کرد . البته این دو نود هر کدام نکته های باریک دارند .
بررسی ELK به‌عنوان Log Management :

در ابتدا ELK به‌عنوان یک Log Management Platform معرفی شد:

جمع‌آوری لاگ‌های سیستمی، اپلیکیشنی و شبکه‌ای

پردازش و نرمال‌سازی داده‌ها

ذخیره‌سازی در Elasticsearch

جستجو، تحلیل و ساخت گزارش در Kibana


به همین دلیل ELK معمولاً در کنار ابزارهایی مثل Splunk یا Graylog دسته‌بندی می‌شود.

بررسی ELK به‌عنوان ابزار Monitoring / Observability :

با گذشت زمان و توسعه‌ی ELK، قابلیت‌های آن گسترش یافت:

امکان تعریف Alerting و هشدار (با X-Pack یا Elastic Alerting)

داشبوردهای Real-Time در Kibana

پشتیبانی از APM (Application Performance Monitoring) و Metrics (از طریق Beats مثل Metricbeat)

استفاده در امنیت (Elastic SIEM)


بنابراین ELK از یک Log Management ساده فراتر رفت و به سمت یک پلتفرم Monitoring و حتی Observability حرکت کرد.


در واقع ELK در اصل یک Log Management Platform است.

اما در عمل، با اضافه شدن قابلیت‌های Dashboard، Alerting و APM، و ... به یک Monitoring و Observability Platform نیز تبدیل می‌شود.


بنابراین ELK را می‌توان هم به‌عنوان مدیریت لاگ و هم به‌عنوان ابزار مانیتورینگ در نظر گرفت؛ بسته به اینکه سازمان از آن در چه سطحی و با چه افزونه‌هایی استفاده کند.


#devops #linux #elk #elasticsearch




https://t.iss.one/unixmens

مفهوم Fleet در ELK چیست؟

در واقع Fleet یک ابزار مدیریتی در Elastic Stack است که برای مدیریت متمرکز Agentها طراحی شده.
در واقع، وقتی شما می‌خواهید روی سرورها، کلاینت‌ها یا کانتینرها داده (لاگ، متریک، امنیت، APM و غیره) جمع‌آوری کنی، باید Elastic Agent نصب بشه.
مدیریت دستی تعداد زیادی Agent (نصب، پیکربندی، به‌روزرسانی) سخت می‌شه.
اینجاست که Fleet وارد عمل میشه.

وظایف Fleet چیست ؟

1. مدیریت متمرکز Agentها

از طریق Kibana می‌تونی Agentها رو نصب، پیکربندی و مدیریت کنی.

نیازی نیست روی هر سرور جداگانه تغییرات اعمال کنی.



2. Policy Management

تعریف Policy (مثلاً جمع‌آوری لاگ‌های سیستم، متریک CPU و لاگ‌های Nginx).

این Policy به صورت خودکار روی Agentها اعمال میشه.



3. Data Ingestion ساده‌تر

در Fleet داده‌ها رو از طریق Elastic Agent به Elasticsearch می‌فرسته.

این داده‌ها می‌تونن شامل:

لاگ‌ها (Log Files)

و Metrics (سیستم و اپلیکیشن‌ها)

داده‌های امنیتی (Endpoint Security)

داده‌های APM

باشه .


4. Integration Hub

در Fleet یک Integration Hub وجود داره که ده‌ها Integration آماده برای سرویس‌ها (مثل MySQL, Nginx, Kubernetes, AWS) رو فراهم می‌کنه.

کافیه انتخابش کنیم تا Agent ها تنظیمات مربوطه رو اعمال کنن.



تفاوت Elastic Agent + Fleet با Beats

قبل از Elastic Agent، باید از Filebeat، Metricbeat، Packetbeat و … جداگانه استفاده می‌کردیم.

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

الان Elastic Agent اومده و همه رو یکپارچه کرده.

و Fleet هم مدیریت مرکزی همین Agentهاست.


مزایای Fleet

مدیریت ساده در مقیاس بالا (ده‌ها یا صدها سرور)

پشتیبانی از Integrationهای آماده

امکان امنیت مرکزی برای Agentها (از طریق Kibana)

جایگزینی مدرن برای Beats

مناسب برای محیط‌های Cloud و Kubernetes خلاصه:
در واقع Fleet یک کنسول مدیریتی متمرکز در Kibana است که برای مدیریت Elastic Agentها استفاده می‌شود.
این ابزار فرآیند نصب، پیکربندی، به‌روزرسانی و مدیریت Policy را ساده می‌کند و عملاً نسل جدید مدیریت داده در ELK به شمار می‌آید.


#elk #linux #security #elasticsearch #kibana


unixmens

https://t.iss.one/unixmens

Edge Industry Review: Orbital data center heads to ISS to test real-time edge computing in spaceA new orbital data center being sent to the International Space Station (ISS) provided by the ISS National Lab will enhance space-based computing assets, considering data storage and real-time processing. This project is in partnership with Axiom Space and Red Hat and employs Red Hat Device Edge to provide in-orbit computing power. Learn more Financial services giant strengthens DR through automation When a leading bank wanted to strengthen disaster recovery, it decided to integrate Red Hat Ansible

via Red Hat Blog https://ift.tt/GhZkAqt

Many organizations possess a wealth of unique internal knowledge. This includes customized operational runbooks, environment-specific configurations, internal best practices, and stringent compliance protocols. This information may be critical for the organization's day-to-day operations, but it sits outside public knowledge bases where large language models (LLM) are trained. There's a clear need to bridge this gap, and to enable an AI assistant to understand and leverage proprietary context and provide specific and actionable guidance. In response to this need, we introduced the "bring your

via Red Hat Blog https://ift.tt/cb2TzHK

The AI revolution has ignited a debate about what constitutes an "AI agent." Using the term “AI agent” these days commonly implies autonomous, self-learning systems that pursue complex goals, adapting over time. A very impressive goal, but this purist vision can alienate traditional developers and slow innovation.It’s time to expand the definition, and embrace a broader perspective: AI agents don’t always need to self-learn or chase lofty goals. Functional agents—a new term—that connect large language models (LLMs) to APIs, physical devices, or event-driven systems can be just as i

via Red Hat Blog https://ift.tt/ZFMkG1v

Organizations looking to better understand the lineage of their software artifacts have begun to adopt signing as a way to improve their security posture. By applying digital signatures to software artifacts, trust can be established to verify that assets have not been substituted or tampered with through the software development and delivery process.Red Hat Trusted Artifact Signer, a key component of Red Hat’s Trusted Software Supply Chain portfolio, provides a suite of tools that supports signing and verifying assets from first commit to deployment. Since Trusted Artifact Signer was first

via Red Hat Blog https://ift.tt/kSxGRn3

Being connected is important, but for a dispersed, global, and mobile organization that works with increasingly sensitive data, sometimes it's better to stay disconnected for security, safety, operational, and other technical concerns. This type of deployment is often referred to as air-gapped. Common air-gapped environments include ships, vehicles, aircraft, remote industrial sites, nuclear facilities, and emergency field operations. These are locations where traditional network connectivity is unavailable or undesired, but where critical decision-making, predictive maintenance, resource esti

via Red Hat Blog https://ift.tt/XbwW9sa

As the pace of innovation across the IT industry accelerates, so does the need to stay informed. To help you stay ahead, we’ve gathered our top articles from July into one essential roundup. This collection of top stories highlights the technologies and strategies that are helping our customers build a more secure, productive, and forward-looking IT environment. From major product announcements to real-world customer stories, these insights will help youdiscover the critical tools and guidance that can strengthen your journey. Model Context Protocol (MCP): Understanding security risks and co

via Red Hat Blog https://ift.tt/afGxp8N

چگونه gitlab ominibus را نصب کنیم :


https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh



https://packages.gitlab.com/gitlab/gitlab-ee


در حقیقت GitLab یکی از محبوب‌ترین پلتفرم‌های DevOps Lifecycle Management است که تمام مراحل توسعه نرم‌افزار شامل مدیریت سورس‌کد، CI/CD، امنیت، مانیتورینگ و دپلویمنت را در یک بستر یکپارچه ارائه می‌دهد.
برای ساده‌سازی نصب و مدیریت این ابزار بزرگ، شرکت GitLab بسته‌ای به نام Omnibus GitLab عرضه کرده است. این بسته شامل تمام اجزای موردنیاز GitLab (مانند دیتابیس، وب‌سرور، Redis، Nginx و غیره) در یک پکیج واحد است و امکان راه‌اندازی سریع و مدیریت آسان را فراهم می‌سازد

ابزار GitLab Omnibus چیست؟

این ساختار Omnibus GitLab یک بسته‌ی all-in-one است که به جای نصب تک‌تک سرویس‌های موردنیاز، همه‌ی اجزا را در یک بسته‌ی مجتمع قرار داده است.
مزایای آن:

نصب سریع تنها با یک دستور (apt-get install gitlab-ee یا yum install gitlab-ee)

مدیریت ساده توسط ابزار gitlab-ctl

کاهش پیچیدگی در پیکربندی

قابلیت به‌روزرسانی یکپارچه


اجزای اصلی GitLab Omnibus

در واقع Omnibus GitLab شامل چندین سرویس حیاتی است که با هم برای اجرای کامل GitLab همکاری می‌کنند:

1. GitLab Rails (Core Application)

بخش اصلی اپلیکیشن که شامل GitLab Web، API و Backend است.



2. Nginx

به عنوان reverse proxy برای مدیریت درخواست‌های HTTP/HTTPS.



3. PostgreSQL

پایگاه‌داده اصلی برای ذخیره‌سازی کاربران، پروژه‌ها، issueها، pipelineها و داده‌های متنی.



4. Redis

برای cache و queue (Background Jobs و Sidekiq).



5. Sidekiq

برای اجرای پردازش‌های غیرهمزمان مانند pipeline jobs و ایمیل‌ها.



6. Gitaly

سرویس مدیریت repositoryها (جایگزین direct Git access).



7. Praefect (در معماری توزیع‌شده)

برای مدیریت replication در محیط‌های با چندین Gitaly.



8. GitLab Shell

مدیریت کلیدهای SSH و دسترسی Git.



9. Prometheus + Grafana

برای مانیتورینگ و مشاهده‌ی متریک‌


ویژگی‌های کلیدی معماری Omnibus

1. یکپارچگی → همه اجزا در یک پکیج و با حداقل وابستگی خارجی.


2. ماژولار → هر سرویس (Redis، PostgreSQL، Nginx و غیره) به صورت جداگانه قابل مدیریت است.


3. مقیاس‌پذیری → در نسخه‌های Advanced (مانند GitLab EE + Omnibus Cluster) می‌توان اجزا را جدا و روی سرورهای مختلف توزیع کرد.


4. امنیت → به صورت پیش‌فرض HTTPS، پیکربندی firewall و hardening‌های امنیتی فراهم است.


5. مانیتورینگ داخلی → با Prometheus و Grafana، متریک‌ها به‌صورت داخلی جمع‌آوری می‌شوند

گیتلب Omnibus ابزاری استراتژیک برای تیم‌های DevOps است که می‌خواهند بدون دغدغه نصب و پیکربندی اجزای مختلف، به سرعت یک محیط کامل GitLab را راه‌اندازی کنند.
معماری سطح بالای آن نشان می‌دهد که چگونه اجزای مختلف (وب‌سرور، دیتابیس، کش، مدیریت ریپازیتوری و مانیتورینگ) به صورت یکپارچه عمل می‌کنند تا چرخه‌ی توسعه نرم‌افزار را بهینه سازند


وقتی سازمان رشد می‌کند، معماری Omnibus تک‌سرور دیگر پاسخ‌گو نیست. در این حالت اجزای GitLab باید روی چندین سرور توزیع شوند تا:

ا. High Availability (HA) → جلوگیری از Single Point of Failure

ا. Horizontal Scaling → توانایی مدیریت حجم بالای کاربران و pipelineها

ا. Performance Optimization → پردازش همزمان حجم زیاد jobها و commitها

اجزای کلیدی در معماری Enterprise

1. Load Balancer

ورودی کلاینت‌ها (Web/SSH/API)

توزیع درخواست‌ها بین نودهای مختلف GitLab Web و GitLab Shell



2. Application Servers (GitLab Rails)

اجرای وب و API

می‌تواند در چندین نود با load balancing اجرا شود



3. Gitaly Cluster (Repository Storage)

هر repository در Gitaly نگهداری می‌شود

برای HA از Praefect استفاده می‌شود (مدیریت replication و failover)



4. Redis Cluster

برای session storage و job queue

پیکربندی Master/Replica یا Sentinel



5. PostgreSQL Cluster

پایگاه‌داده اصلی (HA با Patroni, repmgr یا Cloud Managed DB)

پشتیبانی از replication



6. Sidekiq Cluster

اجرای jobهای pipeline و background taskها

می‌تواند به صورت توزیع‌شده روی چند نود اجرا شود



7. Monitoring & Logging (Prometheus, Grafana, ELK)

جمع‌آوری متریک‌ها، alertها و لاگ‌ها

کارگشا هست .



#gitlab #git #devops


https://t.iss.one/unixmens

ا. GitLab Kubernetes Agent چیست؟

ا. GitLab Kubernetes Agent یک کامپوننت نرم‌افزاری است که داخل کلاستر Kubernetes نصب می‌شود و به صورت دوطرفه (bi-directional) با GitLab ارتباط برقرار می‌کند.
برخلاف روش قدیمی (integration با استفاده از kubeconfig یا API مستقیم)، این Agent یک کانال ارتباطی امن و پایدار بین GitLab و کلاستر ایجاد می‌کند

وظایف و قابلیت‌های اصلی

1. ارتباط امن و پایدار با کلاستر

بجای اینکه GitLab از بیرون به API کلاستر دسترسی داشته باشد (که خطرناک است)، Agent در داخل کلاستر اجرا شده و خودش ارتباط امن (TLS + gRPC) را با GitLab برقرار می‌کند.



2. GitOps (Declarative Deployments)

ا. Agent می‌تواند تغییرات تعریف‌شده در ریپازیتوری GitLab (مثل manifestها و Helm chartها) را به‌طور خودکار با وضعیت کلاستر هماهنگ کند.

یعنی وقتی شما کدی را commit کنید که شامل تغییر در Kubernetes manifests باشد، Agent این تغییرات را به کلاستر اعمال می‌کند.



3. CI/CD Integration

امکان اجرای jobهای CI/CD که نیاز به ارتباط با کلاستر دارند (مثل deploy، تست E2E، security scans).

دسترسی به کلاستر بدون نیاز به اشتراک‌گذاری kubeconfig در pipeline.



4. Cluster Observability

ا. Agent اطلاعات وضعیت کلاستر (nodes, pods, workloads) را به GitLab گزارش می‌دهد.

این کار امکان monitoring و visualization مستقیم از داخل GitLab UI را فراهم می‌کند.



5. Multi-cluster Management

با یک GitLab می‌توان چندین کلاستر را مدیریت کرد (Dev, Staging, Prod).

هر کلاستر ایجنت خودش را دارد و در GitLab به‌عنوان یک entity مجزا دیده می‌شود.



6. Policy Enforcement و Security

می‌توان policyهایی تعریف کرد (مثلاً فقط برخی namespaceها یا resourceها قابل دسترسی باشند).

این باعث می‌شود امنیت نسبت به روش قدیمی kubeconfig خیلی بالاتر باشد.

مشکلات روش kubeconfig قدیمی نسبت به GitLab Kubernetes Agent

امنیت :
نیاز به ذخیره kubeconfig در GitLab (ریسک نشت) ارتباط gRPC امن از داخل کلاستر
ا. GitOps محدود : پشتیبانی کامل (Pull-based deployment)
مقیاس‌پذیری سخت : (برای چندین کلاستر) اما در اجنت ساده تر است . (هر کلاستر Agent خودش را دارد)
ا Observability محدود : اما در اجنت یکپارچه با GitLab UI
مدیریت Policy دستی و پشتیبانی داخلی

#devops #gitlab #kubernetes #k8s #grpc #security #linux #cluster

https://t.iss.one/unixmens

بعد جنگ ۱۲ روزه احساس میکنم ، اعتماد به نفس من کاهش محسوسی داشته


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

چرا پس از بحران، اعتماد به نفس کاهش می‌یابد؟

اختلال در حس کنترل
اعتماد به نفس بر پایه‌ی باور به توانایی فرد برای مدیریت شرایط استوار است. در بحران‌هایی مثل جنگ، فرد با شرایطی روبه‌رو می‌شود که هیچ کنترلی بر آن ندارد. همین حس ناتوانی، به‌طور مستقیم بر باور به خود اثر منفی می‌گذارد.

فعال شدن مداوم سیستم عصبی بقا
در دوران بحران، بدن در وضعیت «جنگ یا گریز» (Fight or Flight) قرار دارد. هورمون‌هایی مثل کورتیزول و آدرنالین به‌طور مداوم ترشح می‌شوند. پس از پایان بحران، این سیستم هنوز مدتی طول می‌کشد تا آرام شود. در این دوره فرد دچار بی‌اعتمادی به توانایی‌های خود، اضطراب و خستگی عمیق روانی می‌شود.

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

پیامدهای کاهش اعتماد به نفس

کاهش انگیزه برای فعالیت‌های روزمره و شغلی

کاهش روابط اجتماعی و گرایش به انزوا

افزایش احتمال افسردگی و اضطراب

تضعیف توانایی تصمیم‌گیری در لحظات مهم

ایجاد چرخه‌ی خودتردیدی: هرچه اعتماد به نفس کمتر شود، شکست‌های کوچک بیشتر به چشم می‌آیند و این خود سبب کاهش بیشتر اعتماد به نفس می‌شود.

راهکارهای بازسازی اعتماد به نفس
۱. پذیرش طبیعی بودن واکنش

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

۲. بازسازی حس کنترل با اقدامات کوچک

شروع با کارهای کوچک و قابل مدیریت (مثل یادگیری یک مهارت کوتاه‌مدت، ورزش روزانه یا تکمیل یک پروژه ساده) به ذهن یادآوری می‌کند که هنوز توانایی مدیریت دارد. این اقدامات، نقطه‌ی بازگشت اعتماد به نفس هستند.

۳. تمرین‌های ذهن‌آگاهی (Mindfulness)

روش‌هایی مانند مدیتیشن، یوگا یا تکنیک «Grounding» (تمرکز بر لحظه حال از طریق توجه به حواس پنج‌گانه) باعث بازگرداندن ذهن از گذشته‌ی پرتنش به اکنون می‌شوند و تدریجاً آرامش درونی و اعتماد به توانایی‌های فردی بازسازی می‌شود.

۴. بازگشت به ارتباط انسانی

انزوا یکی از پیامدهای کاهش اعتماد به نفس است. اما حضور در جمع‌های کوچک و امن، گفت‌وگو با دوستان صمیمی و تبادل احساسات، به فرد یادآوری می‌کند که تنها نیست و توانایی اثرگذاری بر دیگران را دارد.

۵. بازنویسی روایت شخصی

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

از یاد نبریم :

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

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