Kubernetes and oVirt Cloud Provider

#PP.Getting.Started.with.oVirt.3.3.Nov.2013👇🏻👇🏻👇🏻

PP.Getting.Started.with.oVirt.3.3.Nov.2013.pdf

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