Academy and Foundation unixmens | Your skills, Your future

CloudBees CI HA on OpenShift starts with one requirement that can stop the deployment before it even begins: shared storage with ReadWriteMany (RWX) access. OpenShift via kifarunix.com https://ift.tt/L7Akeo8

How did a small team in the east of the Netherlands (Groningen) from the Government Datacenter North (ODC-Noord) grow into a supplier of crucial building blocks for the Netherlands digital government strategy? Jaap Jansma, Manager of ODC-Noord, and Marcel Timmer, Country Director Netherlands at Red Hat, explain.ODC-Noord implements, manages, and operates as a scalable, sovereign cloud service for the Dutch government, and Red Hat provides the fundamental open source software. Together, the 2 companies look at what’s needed to continue fulfilling this role within the government, ranging from via Red Hat Blog https://ift.tt/FpidCvz

The program’s participants, pictured on their first day at Red HatOn June 1, the first cohort of student athletes arrived at the Raleigh office to take part in the Red Hat Sales Combine Accelerator Program. The group of 6 engaged in a newly launched 3-week micro-internship, using skills carefully honed on the playing field and translating them into the world of technology sales. The pilot program at Red Hat is the first of its kind, aimed at collaboration with emerging talent who possess unique skills and insight. In addition to their position as students, the participants balance their rol via Red Hat Blog https://ift.tt/xZvBmVT

Imagine finding out your core platform contract is ending, leaving you with a multi million-dollar liability—and just 10 months to move 1,500 critical workloads. That was the reality for the engineering team at State Farm.While they had previously used Pivotal Cloud Foundry (PCF) and VMware vSphere, the underlying platform was highly proprietary. To escape vendor lock-in and secure long-term cloud portability, State Farm executed an urgent, 10-month race to migrate 1,500 workloads to Red Hat OpenShift Service on AWS (ROSA), all without disrupting core business operations. Figure 1. Burt Lap via Red Hat Blog https://ift.tt/jKyAvkl

بنده به دنبال فرصت های جدید همکاری هستم .

یک اصل پایه در DevSecOps و Secure Software Development این است که هیچ‌گونه Secret، Password، API Key، Access Token، Private Key یا Credential به‌صورت مستقیم داخل Repository ذخیره نشود؛ حتی اگر Repository خصوصی باشد. ابزارهایی مانند Gitleaks با اسکن Commitها و محتوای Repository، الگوهای شناخته‌شده‌ی Secret و Credential را شناسایی می‌کنند. این ابزارها علاوه بر Tokenهای استاندارد، می‌توانند با استفاده از Custom Rules برای الگوهای اختصاصی هر سازمان نیز تنظیم شوند؛ بنابراین اگر یک سازمان الگوی مشخصی برای نام‌گذاری، ساختار یا فرمت Secretهای خود داشته باشد، می‌توان Detection Rule متناسب با همان الگو تعریف کرد. در GitLab نیز می‌توان این کنترل‌ها را در سطح Pipeline و Repository اعمال کرد؛ برای مثال با استفاده از Push Rules، Protected Branches، Merge Request Approval و CI/CD Pipeline Security Checks می‌توان مانع ورود Secret به Branchهای حساس یا Merge شدن کد آلوده به Credential شد. نکته مهم این است که صرفاً داشتن Gitleaks کافی نیست. باید Secret Scanning به بخشی از Security Gate در CI/CD تبدیل شود؛ یعنی کد قبل از Merge یا Release بررسی شود و در صورت شناسایی Credential، Pipeline متوقف شود. حتی اگر توسعه‌دهندگان یک سازمان از الگوهای اختصاصی برای نوشتن Password، Token، API Key یا سایر اطلاعات حساس استفاده کنند، می‌توان برای Gitleaks Ruleهای سفارشی و Regexهای اختصاصی تعریف کرد تا این الگوها نیز شناسایی شوند. در نتیجه، رویکرد صحیح این نیست که صرفاً بگوییم «توسعه‌دهنده نباید Secret را داخل Git قرار دهد»؛ بلکه باید یک کنترل فنی و خودکار ایجاد کنیم که حتی در صورت اشتباه توسعه‌دهنده، Repository و Pipeline بتوانند از انتشار Secret جلوگیری کنند. البته یک نکته مهم‌تر هم وجود دارد: Secret Scanning فقط Detection است، نه Secret Management. برای نگهداری واقعی Secretها باید از راهکارهایی مانند HashiCorp Vault، Kubernetes Secrets با Encryption at Rest، Cloud Secret Manager یا Secret Manager داخلی سازمان استفاده کرد و Application در زمان اجرا Secret را دریافت کند، نه اینکه Secret داخل Source Code یا Git History قرار بگیرد. #DevOps #devsecops

TechZine: Red Hat tames the open source AI chaosThe AI ecosystem is still in its infancy. This is evident from the regular releases of immature, yet highly imaginative, open source solutions. It’s up to companies like Red Hat to anticipate these developments and help such tools mature into enterprise-ready products. Learn more InfoWorld: Three AI security mistakes that will haunt enterprisesRed Hat's Scott McCarty explains why the enterprise AI nightmare is not a killer robot, but an erosion of our ability to see and control what’s running in our own environments. Learn more Beyond the via Red Hat Blog https://ift.tt/FstQvxL

Enterprise AI has reached a critical turning point as organizations move from isolated, chat-based experimentation to complex reasoning models and autonomous agents. While the productivity gains are real, underlying infrastructure costs are escalating rapidly, with token consumption predicted to increase 24x by 2030. Relying entirely on external clouds and proprietary APIs means your expenses scale directly with business growth, introducing major predictability and cost issues. When technology moves this fast, treating it as a series of disconnected software tools creates unnecessary technical via Red Hat Blog https://ift.tt/wZzmjTg

Red Hat OpenShift 4.22 includes general availability support for Red Hat Bare-Metal-as-a-Service (BMaas) for OpenShift, enabling organizations to manage bare metal, virtual machines (VMs), and application containers using the same consistent platform.What is Red Hat Bare-Metal-as-a-Service for OpenShift?Before OpenShift 4.22, Cluster Baremetal Operator in OpenShift provided centralized management for servers with Redfish support with containerized and virtualized workloads. With this new add-on, Red Hat OpenShift Container Platform now extends its orchestration capabilities to physical hardwar via Red Hat Blog https://ift.tt/XEMvbDy

مفهوم Service Discovery در Docker Swarm؛ از DNS تا VIP و Load Balancing نویسنده : یاشار اسمعیل دخت #devops #container #swarm #service #discovery

Your agent works. It reasons, calls tools, and returns answers in the demo that impress everyone. But between that notebook and a production deployment sits a gap having nothing to do with your model or your framework. Three failures hit a single AI agent deployment overnight—43 duplicate tickets, $4,000 charged to the wrong account, and a hallucinated refund policy leading to a $280 return the company had to honor. The agent ran on LangChain. It worked perfectly in staging. Every failure was an infrastructure failure, not an intelligence failure.I've watched teams spend months closing that via Red Hat Blog https://ift.tt/2FMmCsN

ابزار jmeter ‌و نقش آن در DevOps #devops #jmeter #performance #test #load https//t.me/unixmens

CloudBees CI HA on OpenShift starts with one requirement that can stop the deployment before it even begins: shared storage with ReadWriteMany (RWX) access. OpenShift via kifarunix.com https://ift.tt/srj6MTH

Today, Windows Server environments power critical internal portals, application programming interfaces (APIs), and web applications. Every one of them depends on security certificates that expire on a schedule your operations team didn’t choose. When renewal slips, services go dark. When rotation happens at the wrong moment—during peak business hours, mid-deployment, or in the middle of a compliance audit freeze—a routine update becomes a major incident.The work itself is familiar: generate the replacement certificate, apply it to the server, confirm the service is healthy, and update th via Red Hat Blog https://ift.tt/KRQZhDd

I just got back from HL7 FHIR DevDays, a developer conference focused on Fast Healthcare Interoperable Resources (FHIR). I was there to talk about AI transparency in health data and using multi-agent AI to suggest useful care plans for patients. I have been part of the HL7 community for 6 years, working to make sharing health data a reality. But I have been a software architect for a lot longer, almost 30 years in the industry. I have never been as excited about the possibility for computers to work with us to solve real problems than I am now, but there are going to be real challenges. That i via Red Hat Blog https://ift.tt/vbEKkhz

Policy enforcement has moved to the forefront. Let’s break down why this is the case and how policies can help you improve governance as you stay in control of operations.First, let’s examine your current production environment. Compliance, governance, and security aligned with specific standards represent an ongoing and essential need. In fact, some standards come with costly daily fines for each day an environment is out of compliance. Furthermore, standards constantly evolve, with new rules requiring more rigorous actions. For example, Secure Sockets Layer/Transport Layer Security (SSL/ via Red Hat Blog https://ift.tt/3oTGdS0

Modern IT environments are complex. Development and operations teams must constantly balance resolving current infrastructure challenges with planning for scalable, future growth. This requires deep product expertise and technical skills from internal teams that are already resource-constrained. To bridge this gap, enterprises use Red Hat Technical Account Managers (TAMs) as an extension of their teams. A TAM is a single technical point of contact specializing in a specific product family, such as Red Hat Enterprise Linux, Red Hat OpenShift, or Red Hat Ansible Automation Platform. They work al via Red Hat Blog https://ift.tt/JvdhC9q

نه عکس‌ها و رزومه‌ها. بلکه اینکه چیزی که روزی با چند نفر شروع شد، امروز دیگر فقط متعلق به من نیست. این مسیر ادامه پیدا کرده است. و من هنوز در آن هستم. چون سال‌ها پیش با خودم عهد کردم: بخشی از زندگی من باید متعلق به Community باشد. و امروز این عهد برای من فقط برگزاری یک جلسه نیست. یعنی تلاش برای ساختن آدم‌های بهتر. تیم‌های بهتر. سازمان‌های بهتر. اکوسیستم‌های بالغ‌تر. و در نهایت، ایجاد فرهنگی که در آن Open Source فقط یک مدل توسعه‌ی نرم‌افزار نباشد؛ بلکه بخشی از مدل فکر کردن ما برای ساختن آینده‌ی Enterprise باشد. شاید تمام این مسیر را بتوان در یک جمله خلاصه کرد: از Community شروع کردیم؛ اما هدف، ساختن یک Ecosystem بود.

بیش از ۱۵ سال پیش، وقتی اولین جلسه‌های فنی را برگزار می‌کردم، هیچ‌وقت فکر نمی‌کردم این مسیر روزی به چیزی فراتر از یک کامیونیتی تکنولوژی تبدیل شود. آن روزها همه‌چیز ساده‌تر بود. چند نفر آدم علاقه‌مند به تکنولوژی دور هم جمع می‌شدند. از Linux و Open Source حرف می‌زدیم، تجربه‌هایمان را به اشتراک می‌گذاشتیم، سؤال می‌پرسیدیم و گاهی ساعت‌ها درباره‌ی یک موضوع فنی بحث می‌کردیم. جلسه بعدی برگزار می‌شد. و جلسه بعد. و باز هم جلسه بعد. تا اینکه تعدادشان از ۶۰۰ عبور کرد. امروز، بیش از ۶۴۵ جلسه پشت سر گذاشته‌ام. اما وقتی به این عدد نگاه می‌کنم، چیزی که می‌بینم «جلسه» نیست. آدم‌ها را می‌بینم. نسل‌هایی را می‌بینم که وارد شدند، یاد گرفتند، تجربه کردند و بعد خودشان تبدیل به سازنده شدند. گروه‌هایی را می‌بینم که شکل گرفتند. کامیونیتی‌هایی را می‌بینم که رشد کردند. و حتی جریان‌هایی را می‌بینم که به شکلی از همان چیزی که سال‌ها قبل شروع کرده بودیم الهام گرفتند. آن زمان شاید اسمش را نمی‌دانستم، اما امروز بهتر می‌فهمم که چیزی که داشتیم می‌ساختیم فقط یک Community نبود. داشتیم بخشی از یک Technology Ecosystem را می‌ساختیم. و اینجا بود که نگاه من هم تغییر کرد. دیگر مسئله فقط این نبود که «چه تکنولوژی‌ای را آموزش بدهیم؟» سؤال مهم‌تر این شد: چطور می‌توانیم آدم‌ها را به هم متصل کنیم؟ چطور می‌توانیم دانش را در اکوسیستم به گردش دربیاوریم؟ چطور می‌توانیم افراد متخصص تربیت کنیم، بدون اینکه آن‌ها را صرفاً به مصرف‌کننده‌ی یک دوره یا محصول تبدیل کنیم؟ چطور می‌توانیم سازمان‌ها را به تکنولوژی، متخصص‌ها را به مسئله، و ایده‌ها را به فرصت تبدیل کنیم؟ اینجا بود که کامیونیتی برای من وارد مرحله‌ی دیگری شد: مدیریت اکوسیستم. فهمیدم کامیونیتی فقط با برگزاری Event زنده نمی‌ماند. نیاز به اعتماد دارد. نیاز به Governance دارد. نیاز به فرهنگ دارد. نیاز به آدم‌هایی دارد که مسئولیت بپذیرند. و مهم‌تر از همه، نیاز دارد که افراد بتوانند در آن رشد کنند و در نهایت خودشان بخشی از ساختار را بسازند. به مرور، مفهوم دیگری هم برایم جدی‌تر شد: تعالی. برای من تعالی یعنی فقط «بیشتر کار کردن» یا «بزرگ‌تر شدن» نیست. تعالی یعنی هر نسل، کمی بهتر از نسل قبل باشد. هر جلسه، چیزی بیشتر از جلسه‌ی قبلی داشته باشد. هر متخصص، علاوه بر دانش فنی، درک بهتری از مسئله، سازمان، کسب‌وکار و اثر کاری که انجام می‌دهد پیدا کند. و اینجا بود که مرز بین Technology و Business برایم کم‌رنگ‌تر شد. چون تکنولوژی زمانی ارزشمند است که بتواند مسئله‌ای واقعی را حل کند. و این نگاه، به‌تدریج مرا به مفهوم Enterprise Open Source نزدیک‌تر کرد. ا Open Source برای من فقط «نرم‌افزار رایگان» نیست. ا Open Source یعنی دانش، تجربه، استاندارد، همکاری و نوآوری بتوانند در یک اکوسیستم جریان پیدا کنند. اما Enterprise Open Source یک قدم جلوتر است. اینجا دیگر فقط درباره‌ی استفاده از یک نرم‌افزار Open Source صحبت نمی‌کنیم. درباره‌ی ساختن یک قابلیت سازمانی صحبت می‌کنیم. درباره‌ی Governance. درباره‌ی Security. درباره‌ی Architecture. درباره‌ی Reliability. درباره‌ی Platform. درباره‌ی People. و درباره‌ی اینکه چگونه می‌توان تکنولوژی‌های Open Source را از سطح یک ابزار، به بخشی از یک Enterprise Capability تبدیل کرد. شاید جالب باشد که بخش زیادی از این مسیر، بدون اینکه از ابتدا چنین نقشه‌ای داشته باشم، اتفاق افتاد. از کامیونیتی شروع شد. بعد به شبکه‌ای از آدم‌ها رسید. بعد به اکوسیستم. بعد به مدیریت دانش و تجربه. بعد به تعالی. و امروز، نگاه من بیشتر از هر زمان دیگری به ساختن Enterprise Open Source Ecosystem است. اکوسیستمی که در آن Community فقط محل برگزاری Event نباشد؛ بلکه جایی باشد برای شکل‌گیری استعداد، انتقال تجربه، حل مسئله، ایجاد ارتباط میان متخصص و سازمان، و در نهایت خلق ارزش. در تمام این سال‌ها، یک اصل برای من مهم بوده: نمی‌خواستم همه‌چیز حول خودم بچرخد. تلاش کردم خودخواه نباشم. اگر کسی بهتر از من بود، باید فرصت رشد پیدا می‌کرد. اگر کسی ایده‌ی بهتری داشت، باید شنیده می‌شد. اگر گروه دیگری می‌توانست کاری را بهتر انجام دهد، باید رشد می‌کرد. و اگر چیزی که ما ساخته بودیم، باعث شد دیگران هم کامیونیتی خودشان را بسازند، من آن را از دست دادن نمی‌دانم. من آن را تکثیر می‌دانم. چون کامیونیتی واقعی، وقتی موفق شده که دیگر به بنیان‌گذارش وابسته نباشد. امروز بعد از بیش از ۱۵ سال، شهر و اکوسیستم را نگاه می‌کنم. بسیاری از آدم‌هایی که آن روزها جوان‌تر بودند، امروز متخصص، مدیر، معمار، کارآفرین یا صاحب یک کسب‌وکار هستند. گروه‌هایی که آن روزها کوچک بودند، امروز خودشان بخشی از اکوسیستم‌اند. و این شاید برای من بزرگ‌ترین پاداش این مسیر باشد. نه ۶۴۵ جلسه. نه تعداد Eventها.