<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های امیرمحمد عمومی | Amir Omumi</title>
        <link>https://virgool.io/feed/@amiromumi</link>
        <description>برنامه‌نویس بک‌اند و علاقه‌مند به DevOps. توسعه نرم‌افزارهای مقیاس‌پذیر و خودکارسازی زیرساخت‌ها مسیر من است.
شماره تماس: 09356255053</description>
        <language>fa</language>
        <pubDate>2026-07-07 17:44:05</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/4254465/avatar/Cq2CaP.jpg?height=120&amp;width=120</url>
            <title>امیرمحمد عمومی | Amir Omumi</title>
            <link>https://virgool.io/@amiromumi</link>
        </image>

                    <item>
                <title>اگر اینترنت قطع شود، Build پروژه شما متوقف می‌شود؟</title>
                <link>https://virgool.io/@amiromumi/nexus-lntzybkinogj</link>
                <description>Nexusفرض کنید Pipeline اجرا شده است.توسعه‌دهنده کد را Push کرده، Build آغاز شده و همه‌چیز طبق برنامه پیش می‌رود. اما چند دقیقه بعد فرآیند متوقف می‌شود.نه به خاطر باگ.نه به خاطر کمبود منابع سرور.فقط به این دلیل که پروژه نتوانسته یک Package موردنیاز را دانلود کند.این اتفاق بیشتر از چیزی که فکر می‌کنیم رخ می‌دهد. بسیاری از پروژه‌های امروزی برای دریافت پکیج‌های npm، NuGet، Docker Imageها یا حتی Repositoryهای لینوکس به اینترنت وابسته هستند. در چنین شرایطی هر اختلالی در اینترنت می‌تواند فرآیند توسعه، Build و Deploy را تحت تأثیر قرار دهد.اما آیا راهی وجود دارد که این وابستگی را کاهش دهیم؟Nexus چیست؟Nexus Repository یک Repository Manager است که به شما اجازه می‌دهد پکیج‌ها، Artifactها و Imageهای موردنیاز سازمان را در یک محل متمرکز نگهداری و مدیریت کنید.به زبان ساده، به جای اینکه هر توسعه‌دهنده، سرور یا Pipeline مستقیماً به اینترنت متصل شود، همه درخواست‌ها از طریق Nexus عبور می‌کنند.به این ترتیب کنترل بیشتری روی منابع نرم‌افزاری سازمان خواهید داشت و وابستگی مستقیم به سرویس‌های خارجی کاهش پیدا می‌کند.اما قبل از اینکه سراغ مزایای Nexus برویم، بهتر است با نحوه نگهداری پکیج‌ها در آن آشنا شویم.Repositoryها در Nexus چگونه کار می‌کنند؟در Nexus می‌توان Repositoryها را به چند شکل مختلف ایجاد کرد. هر کدام از این Repositoryها کاربرد خاصی دارند و معمولاً در کنار یکدیگر استفاده می‌شوند.سه نوع Repository که بیشتر از همه استفاده می‌شوند عبارت‌اند از:Hosted RepositoryProxy RepositoryGroup RepositoryHosted Repository چیست؟Hosted Repository محلی است که فایل‌ها و پکیج‌ها مستقیماً داخل خود Nexus ذخیره می‌شوند.برای مثال فرض کنید تیم شما یک Package اختصاصی NuGet توسعه داده است یا Docker Imageهای داخلی سازمان را تولید می‌کند.در این حالت می‌توانید آن‌ها را داخل یک Hosted Repository منتشر کنید تا سایر سرویس‌ها و توسعه‌دهندگان از همان مخزن استفاده کنند.نمونه کاربردها:پکیج‌های اختصاصی NuGetپکیج‌های داخلی npmDocker Imageهای سازمانیفایل‌های ReleaseArtifactهای خروجی Buildدر واقع Hosted Repository نقش یک مخزن داخلی برای سازمان را ایفا می‌کند.Proxy Repository چیست؟Proxy Repository یکی از مهم‌ترین قابلیت‌های Nexus است.فرض کنید پروژه شما به یک Package از npm نیاز دارد.بار اول که درخواست ارسال می‌شود، Nexus پکیج را از اینترنت دریافت می‌کند و در Cache خود ذخیره می‌کند.از دفعات بعدی همان پکیج مستقیماً از Nexus تحویل داده می‌شود و دیگر نیازی به دانلود مجدد از اینترنت نیست.مزایای این روش:کاهش مصرف اینترنتافزایش سرعت Buildکاهش وابستگی به سرویس‌های خارجیدسترسی به پکیج‌های Cache شده در زمان اختلال اینترنتبرای مخازنی مانند npm، NuGet، Docker Hub و Repositoryهای لینوکس معمولاً از Proxy Repository استفاده می‌شود.Group Repository چیست؟در بسیاری از سازمان‌ها چندین Repository مختلف وجود دارد.برای مثال:یک Hosted Repositoryچند Proxy Repositoryچند مخزن اختصاصی دیگراگر کاربران مجبور باشند آدرس همه این Repositoryها را جداگانه تنظیم کنند، مدیریت سیستم پیچیده می‌شود.Group Repository این مشکل را حل می‌کند.در Group Repository چند Repository مختلف پشت یک آدرس واحد قرار می‌گیرند.در نتیجه توسعه‌دهنده فقط یک آدرس را در npm، NuGet یا Docker تنظیم می‌کند و Nexus به‌صورت خودکار Repository مناسب را پیدا می‌کند.Nexus از چه فناوری‌هایی پشتیبانی می‌کند؟یکی از دلایل محبوبیت Nexus این است که محدود به یک اکوسیستم خاص نیست.برخی از Repositoryهای قابل پشتیبانی:npmNuGetDockerMavenPyPIAPTYumRaw Repositoryبه همین دلیل اکثر تیم‌های توسعه نرم‌افزار و DevOps می‌توانند از آن استفاده کنند.آیا Nexus فقط برای زمان قطعی اینترنت است؟خیر.بسیاری از سازمان‌ها حتی با دسترسی کامل به اینترنت نیز از Nexus استفاده می‌کنند.زیرا Nexus مزایای دیگری هم دارد:افزایش سرعت Build و Deployمدیریت متمرکز Artifactهاکنترل دسترسی کاربراننگهداری نسخه‌های مختلف نرم‌افزارهاکاهش وابستگی به سرویس‌های خارجیبهبود امنیت زنجیره تأمین نرم‌افزاردر واقع موضوع فقط «داشتن پکیج‌ها در زمان قطعی اینترنت» نیست؛ بلکه داشتن یک نقطه مرکزی برای مدیریت تمام Artifactهای سازمان است.جمع‌بندی:اگر پروژه شما برای دریافت پکیج‌های npm، NuGet، Docker Imageها یا Repositoryهای لینوکس به اینترنت وابسته است، Nexus می‌تواند بخش زیادی از این وابستگی را کاهش دهد.با استفاده از Hosted Repository، Proxy Repository و Group Repository می‌توان پکیج‌ها را مدیریت، ذخیره و Cache کرد تا تیم توسعه و زیرساخت به منابع موردنیاز خود سریع‌تر و مطمئن‌تر دسترسی داشته باشند.سؤال مهم این است:اگر همین الان اینترنت قطع شود، کدام بخش از Pipeline شما از کار می‌افتد؟</description>
                <category>امیرمحمد عمومی | Amir Omumi</category>
                <author>امیرمحمد عمومی | Amir Omumi</author>
                <pubDate>Tue, 23 Jun 2026 01:41:55 +0330</pubDate>
            </item>
                    <item>
                <title>چگونه بدون اینترنت همچنان حرفه‌ای بمانیم؟ | راهنمای عملی آفلاین برای مهندسان واقعی</title>
                <link>https://virgool.io/@amiromumi/no-internet-qi6hhtazsjhx</link>
                <description>چگونه بدون اینترنت همچنان حرفه‌ای بمانیم؟ | راهنمای عملی آفلاین برای مهندسان واقعیدر دنیای امروز که همه چیز به اینترنت وابسته است، من یاد گرفتم که یک مهندس DevOps واقعی کسی نیست که وقتی همه چیز آنلاین است کار کند؛ بلکه کسی است که وقتی اینترنت قطع می‌شود هم بهره‌وری‌اش را حفظ می‌کند. این مقاله تجربیات واقعی من از پروژه‌های واقعی است.وسط یک پروژه مهم ، اینترنت قطع شد. اول فکر کردم همه چیز متوقف می‌شود: نمی‌توانم داکیومنت بخوانم، ایمیج Docker بکشم، یا حتی یک commit ساده push کنم. اما وقتی دیدم که بخش زیادی از کارم همچنان پیش می‌رود، متوجه شدم که وابستگی بیش از حد به اینترنت، بزرگ‌ترین نقطه ضعف من بوده است.از آن روز، شروع کردم به ساخت یک &quot;کیت آفلاین&quot; کامل برای DevOps. حالا می‌خواهم این تجربیات را با شما به اشتراک بگذارم – نه تئوری، بلکه چیزهایی که خودم در پروژه‌های واقعی استفاده کرده‌ام و نجات‌دهنده بوده‌اند.1- مستندات آفلاین: مغز دوم شما بدون اینترنتوقتی Stack Overflow یا ChatGPT در دسترس نیست، تنها چیزی که نجات می‌دهد، مستندات محلی است.cheat sheetهای شخصی بسازید: یک فایل Markdown ساده با دستورات پرکاربرد لینوکس (مثل find, grep, systemctl)، Kubernetes (kubectl get, kubectl describe)، Ansible playbookهای پایه، یا regexهای رایج. من این فایل را همیشه در دسکتاپ دارم.ابزارهای قدرتمند آفلاین:Zeal (برای لینوکس و ویندوز) یا Dash (مک): این ابزارها docsetهای رسمی صدها تکنولوژی را دانلود می‌کنند (Docker, Kubernetes, Ansible, Terraform, AWS CLI و...). بعد از دانلود، حتی بدون اینترنت جستجوی سریع و کامل دارید.DevDocs.io را هم می‌توانید آفلاین ذخیره کنید (با extension مرورگر یا دانلود مستقیم).man pages محلی: در لینوکس همیشه man git, man docker, man kubectl را داشته باشید. اگر می‌خواهید به‌روز باشد، یک بار با اینترنت man-db را آپدیت کنید.پیشنهاد عملی من: یک ریپو Git خصوصی بسازید به اسم offline-docs و همه cheat sheetها، PDFها و لینک‌های ذخیره‌شده را آنجا بگذارید. با git grep یا VS Code جستجو کنید – سریع‌تر از هر سرچی!۲. Git آفلاین: جایی که همه چیز از اینجا شروع می‌شودGit ذاتاً آفلاین طراحی شده است – این یکی از دلایل محبوبیتش است.commit، branch، merge، rebase – همه بدون اینترنت کار می‌کنند.مثال روزمره:git checkout -b feature/offline-work
# تغییرات را بدهید
git add .
git commit -m &quot;Implemented caching layer - offline mode&quot;
git merge main  # اگر لازم بودنکته پیشرفته: از git bundle برای انتقال کامل ریپو بین دستگاه‌ها بدون اینترنت استفاده کنید.مثال:# در ماشین A
git bundle create myproject.bundle --all

# فایل bundle را با فلش منتقل کنید به ماشین B
# در ماشین B
git clone myproject.bundle new-repoاین روش در تیم‌هایی که اینترنت محدود دارند یا برای بک‌آپ‌گیری عالی است.۳. Docker و Containerization بدون اینترنتبزرگ‌ترین نجات‌دهنده من در قطعی‌های طولانی.ایمیج‌های پایه را از قبل pull کنید: docker pull nginx:latest, docker pull postgres:16, docker pull redis:7build محلی انجام دهید:# Dockerfile
FROM python:3.11-slim
COPY . /app
RUN pip install -r requirements.txt --no-index --find-links=/wheelsPodman به جای Docker: daemonless است، rootless کار می‌کند، امنیت بالاتر دارد و کاملاً آفلاین. در پروژه‌های من، وقتی Docker daemon مشکل داشت، Podman بدون هیچ مشکلی محیط تست را بالا نگه داشت.podman compose up -d
podman build -t myapp .۶. ابزارهای مکمل برای تجربه کامل آفلاینVS Code + extensions آفلاین (GitLens, Docker, Remote - Containers)Prometheus + Node Exporter محلی برای مانیتورینگrsync یا Unison برای همگام‌سازی فایل‌ها بین دستگاه‌هانتیجه‌گیری: حرفه‌ای بودن یعنی آمادگیاز این تجربیات فهمیدم که DevOps واقعی درباره انعطاف‌پذیری است: کاهش وابستگی به کلود و اینترنت، محلی‌سازی منابع، و تکیه بر اصول پایه. این رویکرد نه تنها در قطعی اینترنت کمک می‌کند، بلکه امنیت را بالا می‌برد (کمتر داده در شبکه)، هزینه‌ها را کم می‌کند و در مصاحبه‌های شغلی نشان می‌دهد که شما فقط تئوری بلد نیستید – تجربه عملی دارید.حالا همیشه یک &quot;کیت آفلاین&quot; روی لپ‌تاپم دارم: Zeal پر از docset، ایمیج‌های Docker کلیدی، ریپوهای Git آماده، و اسکریپت‌های اتوماسیون.شما چطور؟چالش آفلاین برای شما چه بوده؟ از چه ابزارهایی برای کار بدون اینترنت استفاده می‌کنید؟ rsync، git worktrees، یا چیز دیگری؟در کامنت‌ها تجربیاتتون رو بنویسید – خوشحال میشم بیشتر یاد بگیرم !</description>
                <category>امیرمحمد عمومی | Amir Omumi</category>
                <author>امیرمحمد عمومی | Amir Omumi</author>
                <pubDate>Mon, 09 Feb 2026 12:12:14 +0330</pubDate>
            </item>
            </channel>
</rss>