رکورد دی ان اس چیست؟

رکورد DNS مشخص می‌کند هر دامنه یا زیردامنه باید به کدام سرور یا سرویس متصل شود. این هدایت توسط سرورهای DNS انجام می‌شود؛ سرورهایی که نام دامنه را به آدرس IP ترجمه می‌کنند. به عبارت دیگر، رکوردهای DNS مثل نقشه راه یا دستورالعمل‌های کوچک عمل کرده و مشخص می‌کنند درخواست‌های اینترنتی شما (چه برای باز کردن یک ‌وب‌سایت، ارسال ایمیل یا دسترسی به یک سرویس دیگر) چگونه باید به مقصد صحیح برسند. برای نمونه:

• رکورد A، دامنه‌ای مثل example.com را به یک آدرس IPv4 متصل می‌کند؛ یعنی مشخص می‌کند سایت دقیقاً روی کدام سرور قرار دارد
• رکورد CNAME زمانی استفاده می‌شود که بخواهید یک زیردامنه را به یک سرویس دیگر متصل کنید؛ مثلاً وقتی blog.example.com را به یک پلتفرم دیگر مثل سرویس‌های سایت‌ساز یا CDN وصل می‌کنید
• رکورد MX تعیین می‌کند که ایمیل‌های دامنه شما به کدام سرور ایمیل ارسال شوند؛ مثلاً اگر از آدرس mail.example.com به‌عنوان سرور ایمیل استفاده کنید، این رکورد مشخص می‌کند که پیام‌ها به همین زیردامنه هدایت شوند

در عمل، هر دامنه معمولاً چندین رکورد DNS مختلف دارد که هرکدام مسئول بخش خاصی از ارتباطات آن هستند. این رکوردها در کنار هم مشخص می‌کنند که ترافیک وب، ایمیل و سایر سرویس‌ها چگونه و به کجا هدایت شوند.

رکوردهای DNS چگونه کار می‌کنند؟

هر بار که شما آدرس یک وب‌سایت (یا به طور دقیق‌تر یک دامنه) را در مرورگر وارد می‌کنید یا ایمیلی ارسال می‌کنید، یک پرسش DNS (یا DNS query) آغاز می‌شود که مشخص می‌کند درخواست شما به کدام سرور هدایت شود. این مسیر شامل سرورهای محلی، سرورهای بالادستی (Root و TLD) و در نهایت Authoritative DNS server است؛ جایی که رکوردهای DNS نگهداری می‌شوند و تصمیم نهایی گرفته می‌شود.

برای مثال، وقتی سایت example.com را باز می‌شود، رکورد A مشخص می‌کند مرورگر به کدام IP وصل شود و رکورد MX تعیین می‌کند ایمیل‌های دامنه به کدام سرور ارسال شوند. این سرور ایمیل معمولاً با یک نام دامنه مشخص می‌شود (مثلاً mail.example.com). سپس DNS این نام سرور را به IP ترجمه می‌کند.

برای توضیح کامل و مرحله‌به‌مرحله فرایند جستجوی DNS و DNS Resolve می‌توانید مطلب «DNS چیست؟» مطالعه کنید.

ساختار رکورد DNS

هر رکورد DNS شامل چند بخش اصلی است که مشخص می‌کنند دامنه یا زیردامنه چگونه هدایت شود. این بخش‌ها عبارت‌اند از:

1. نام (Name): نام دامنه یا زیردامنه که رکورد مربوط به آن تعریف شده است؛ به عنوان مثال example.com یا mail.example.com
2. نوع رکورد (Type): نوع رکورد را مشخص می‌کند، مثل A ،CNAME ،MX و … که نشان می‌دهد بخش داده‌ها چگونه باید تفسیر شود
3. داده‌ها (Data): اطلاعات واقعی رکورد، مثل یک آدرس IP برای رکورد A یا یک زیردامنه برای رکورد CNAME
4. زمان بقا (TTL – Time to Live): مدت زمانی که پاسخ رکورد می‌تواند در کش ذخیره شود (بر حسب ثانیه)
5. کلاس (Class): معمولاً مقدار آن IN است و نشان‌دهنده کلاس پروتکل اینترنت است

به بیان ساده، این فیلدها مثل یک فرم اطلاعاتی عمل می‌کنند که هر رکورد DNS برای هدایت دقیق ترافیک نیاز دارد. وقتی هر رکورد با این ساختار پر می‌شود، سرورها می‌توانند با دقت مسیر ترافیک وب، ایمیل و سایر سرویس‌ها را مشخص کنند.

رایج‌ترین انواع رکورد دی ان اس چیست؟

در این بخش به معرفی رایج‌ترین انواع رکورد DNS می‌پردازیم و توضیح می‌دهیم هر کدام چه کاری انجام می‌دهند.

• A record: این رکورد یک نام دامنه را به یک آدرس IPv4 متصل می‌کند. به عنوان مثال، example.com ممکن است به 192.168.1.1 اشاره کند.
• AAAA record: مشابه رکورد A است، اما برای آدرس‌های IPv6 استفاده می‌شود
• CNAME record: این رکورد یک نام دامنه یا زیردامنه را به دامنه‌ای دیگر هدایت می‌کند؛ بدون اینکه IP ارائه دهد. مثال: blog.example.com به example.net اشاره کند
• MX record: این رکورد مشخص می‌کند ایمیل‌های دامنه به کدام سرور ارسال شوند. مثلا هدایت به mail.example.com
• TXT record: این رکورد اجازه می‌دهد متن دلخواهی برای دامنه ذخیره شود. اغلب برای امنیت ایمیل و تایید مالکیت دامنه استفاده می‌شود
• NS record: مشخص می‌کند کدام سرورها مسئول یک دامنه هستند
• SOA record: رکورد SOA اطلاعات مدیریتی اصلی دامنه، مثل سرور اولیه و ایمیل مدیر دامنه را نگه می‌دارد
• SRV record: این رکورد یک سرویس خاص را با پورت مشخص می‌کند
• PTR record: برای جستجوهای معکوس استفاده می‌شود و IP را به نام دامنه نگاشت می‌کند

با استفاده از این رکوردها، می‌توانید تنظیمات مختلفی را برای دامنه خود اعمال کنید و خدمات گوناگونی را ارائه دهید. هر کدام از این رکوردها وظایف و کاربردهای خاص خود را دارند که برای مدیریت دامنه‌ها ضروری هستند.

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

علاوه بر رکوردهای رایج، رکوردهای دیگری با کاربردهای خاص وجود دارند.

• AFSDB record: برای سیستم فایل اندرو (Andrew File System | AFS) استفاده می‌شود و مسیر دسترسی به سایر سلول‌های AFS را مشخص می‌کند
• APL record: رکورد «لیست پیشوند آدرس» که محدوده‌های آدرس IP را مشخص می‌کند (نوعی رکورد آزمایشی)
• CAA record: رکورد «مجوز مرجع صدور گواهینامه» که مشخص می‌کند کدام مرجع می‌تواند برای دامنه گواهی‌نامه صادر کند
• رکورد DNSKEY: رکورد «کلید DNS» که حاوی کلیدی عمومی برای تأیید امضای DNSSEC است
• کورد CDNSKEY: یک کپی نسخه فرزند رکورد DNSKEY برای انتقال به والد است
• رکورد CERT: رکورد «گواهینامه» که گواهینامه‌های کلید عمومی را ذخیره می‌کند
• رکورد HIP: این رکورد از «پروتکل شناسایی میزبان» (Host identity protocol) استفاده می‌کند که روشی برای جدا کردن نقش‌های آدرس IP است
• رکورد IPSECKEY: رکوردی که با پروتکل IPSEC کار می‌کند
• رکورد LOC: رکورد موقعیت (Location) که اطلاعات جغرافیایی یک دامنه را به صورت مختصات طول و عرض جغرافیایی ذخیره می‌کند
• رکورد NSEC: رکورد «Next Secure Record» که بخشی از DNSSEC است، برای اثبات عدم وجود یک رکورد منبع DNS درخواستی استفاده می‌شود
• رکورد RRSIG: رکورد «امضای رکورد منبع» (Resource Record Signature) که امضای دیجیتالی را برای تأیید رکوردها مطابق با DNSSEC ذخیره می‌کند
• رکورد دی ان اس RP: رکورد «شخص مسئول» (Responsible Person) که آدرس ایمیل شخص مسئول دامنه را ذخیره می‌کند
• رکورد SSHFP: این رکورد «اثر انگشت کلید عمومی SSH» را ذخیره می‌کند

با وجود اینکه اکثر این رکوردها کمتر استفاده می‌شوند اما آشنایی با آن‌ها به شما کمک می‌کند درک بهتری از عملکرد و امکانات رکورد DNS داشته باشید و در صورت نیاز بتوانید از آن‌ها استفاده کنید.

جمع‌بندی

در این مطلب بررسی کردیم که رکورد دی ان اس چیست و چه نقشی در هدایت ترافیک اینترنتی دارد. رکورد DNS مشخص می‌کنند هر دامنه یا زیردامنه باید به چه مقصدی (چه یک وب‌سایت یا یک سرویس ایمیل یا هر سرویس دیگری) متصل شود. همچنین با ساختار رکورد DNS شامل نام دامنه، نوع رکورد، داده‌ها، TTL و کلاس آشنا شدیم و به توضیح رایج‌ترین رکوردها از جمله A ،CNAME ،MX و TXT و همچنین رکوردهای کم کاربردتر پرداختیم.

The post DNS Record چیست؟ آشنایی با ساختار و انواع رکوردها appeared first on بلاگ هم‌روش.

گیت‌هاب اکشن چیست؟

گیت‌هاب اکشن پلتفرم CI/CD است که به شما امکان می‌دهد تا فرآیندهای ساخت، تست و انتشار نرم‌افزار را خودکار کنید. این پلتفرم به شما اجازه می‌دهد تا کدهای دلخواه خود را بر روی مخزنی خاص و در زمان وقوع رویدادی مشخص اجرا کنید. گیت‌هاب اکشن از کدهای بسته‌بندی شده در داکر کانتینرها استفاده می‌کند که روی سرورهای گیت‌هاب اجرا می‌شوند. این ابزار با تمامی زبان‌های برنامه‌نویسی سازگار است و می‌توانید آن را بر روی ابرهای عمومی و سرورهای محلی اجرا کنید. به‌طور خلاصه، GitHub Actions به شما کمک می‌کند تا:

• فرآیند ساخت، تست و استقرار نرم‌افزار را خودکار کنید.
• کارهای تکراری را بدون نیاز به دخالت دستی انجام دهید.
• فرآیندهای کاری خود را بر اساس رویدادهای مختلف در مخزن خود راه‌اندازی کنید.

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

برای درک بهتر گیت‌هاب اکشن، لازم است با مفاهیم و اصطلاحات کلیدی آن آشنا شوید:

• Workflow (گردش کار): یک فرآیند خودکار است که شامل یک یا چند job است. گردش کارها با استفاده از فایل‌های YAML پیکربندی می‌شوند و می‌توانند بر اساس رویدادهای مختلف، به صورت دستی یا زمان‌بندی شده اجرا شوند. فایل‌های گردش کار در دایرکتوری .github/workflows هر مخزن قرار می‌گیرند.
• Event (رویداد): یک فعالیت خاص در مخزن است که باعث راه‌اندازی یک گردش کار می‌شود. رویدادها می‌توانند شامل ایجاد یک pull request، باز کردن یک issue یا push کردن یک commit باشند. همچنین می‌توان گردش کارها را بر اساس زمان‌بندی یا به صورت دستی فعال کرد.
• Job (کار): مجموعه‌ای از مراحل در یک گردش کار است که روی یک runner اجرا می‌شود. هر job شامل یک یا چند step است که می‌توانند یک اسکریپت از پیش تعیین شده یا یک action باشند.
• Action (عمل): یک برنامه سفارشی برای گیت‌هاب اکشن است که یک کار پیچیده اما تکراری را انجام می‌دهد. Actionها به شما کمک می‌کنند تا از نوشتن کدهای تکراری در گردش کار خود اجتناب کنید.
• Runner (اجرا کننده): ماشینی است که اپلیکیشن گیت‌هاب اکشن روی آن نصب شده و منتظر دریافت job برای اجرا است. runnerها می‌توانند توسط گیت‌هاب میزبانی شوند یا می‌توانند runnerهای شخصی باشند.

مزایای استفاده از گیت‌هاب اکشن

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

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

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

برای ایجاد یک گردش کار در گیت‌هاب اکشن، مراحل زیر را دنبال کنید:

• در مخزن خود، یک دایرکتوری به نام .github/workflows ایجاد کنید.
• در این دایرکتوری، یک فایل YAML با نام دلخواه (مثلاً demo-github-actions-workflow.yml) ایجاد کنید.
• کد YAML را در فایل خود کپی کنید.
• فایل را commit و push کنید.

کد YAML:

name: Demo GitHub Actions Workflow
on: [push]
jobs:
  Discover-GitHub-Actions-Workflows:
    runs-on: ubuntu-latest
    steps:
      - name: Echo event
        run: echo "${{ github.event_name }} event automatically triggered this job."
      - name: Echo runner OS
        run: echo " A ${{ runner.os }} server hosted by GitHub has this job running"
      - name: Echo repository details
        run: echo "Details of your repository: repo-name: ${{ github.repository }} and branch name is${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Echo clone message
        run: echo "The runner has cloned your ${{ github.repository }} repository."
      - name: Echo test message
        run: echo "The workflow can now test your code with the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - name: Echo Job Status
        run: echo " This job has a ${{ job.status }} status."

name: Demo GitHub Actions Workflow
on: [push]
jobs:
  Discover-GitHub-Actions-Workflows:
    runs-on: ubuntu-latest
    steps:
      - name: Echo event
        run: echo "${{ github.event_name }} event automatically triggered this job."
      - name: Echo runner OS
        run: echo " A ${{ runner.os }} server hosted by GitHub has this job running"
      - name: Echo repository details
        run: echo "Details of your repository: repo-name: ${{ github.repository }} and branch name is${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Echo clone message
        run: echo "The runner has cloned your ${{ github.repository }} repository."
      - name: Echo test message
        run: echo "The workflow can now test your code with the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - name: Echo Job Status
        run: echo " This job has a ${{ job.status }} status."

پس از انجام این مراحل، هر بار که یک push به مخزن خود انجام دهید، این گردش کار اجرا خواهد شد.

مشاهده نتایج گردش کار

برای دیدن نتایج اجرای گردش کار، مراحل زیر را دنبال کنید:

• به صفحه اصلی مخزن خود بروید و روی تب Actions کلیک کنید.
• در سایدبار سمت چپ، گردش کار خود را انتخاب کنید (مثلاً Demo-GitHub-Actions-Workflow).
• در لیست نمایش داده شده، اجرای مورد نظر را انتخاب کنید (مثلاً Create demo-github-actions-workflow.yml).
• در سایدبار سمت چپ، job مورد نظر خود را انتخاب کنید (مثلاً Discover-GitHub-Actions-Workflows).
• لاگ‌های مربوط به هر مرحله از گردش کار را مشاهده کنید.

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

گیت‌هاب اکشن می‌تواند برای انجام کارهای مختلفی مورد استفاده قرار گیرد، از جمله:

• Continuous Integration (CI): ساخت و تست خودکار کدها پس از هر push یا pull request.
• Continuous Deployment (CD): انتشار خودکار نرم‌افزار پس از عبور از تست‌ها.
• اتوماسیون وظایف تکراری: انجام خودکار کارهایی مانند اضافه کردن label به issueها یا بستن issueهای غیرفعال.

در ادامه به برخی از کاربردهای رایج گیت‌هاب اکشنز در پروژه‌ها اشاره می‌کنیم:

• Eslint: بررسی و گزارش خطاهای جاوااسکریپت.
• Test & Coveralls: اجرای تست‌های خودکار و گزارش پوشش تست.
• Npm Publish: انتشار پکیج‌های npm به‌صورت خودکار.
• Release: ایجاد نسخه جدید از پروژه و انتشار آن در گیت‌هاب.

مثال: Eslint Workflow

در اینجا یک مثال از یک workflow برای اجرای ESLint آورده شده است:

name: ESLint Check
on: push
jobs:
    eslint:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
            - name: Use Node.js
              uses: actions/setup-node@v2
              with:
                node-version: "14.x"
            - name: Install Dependencies
              run: npm install
            - name: Run ESLint
              run: npm run eslint
            concurrency:
              group: eslint-check-${{ github.event.pull_request.number || github.ref }}
              cancel-in-progress: true

name: ESLint Check
on: push
jobs:
    eslint:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
            - name: Use Node.js
              uses: actions/setup-node@v2
              with:
                node-version: "14.x"
            - name: Install Dependencies
              run: npm install
            - name: Run ESLint
              run: npm run eslint
            concurrency:
              group: eslint-check-${{ github.event.pull_request.number || github.ref }}
              cancel-in-progress: true

این workflow هر بار که کدی به مخزن push شود، اجرا می‌شود، کدهای جاوااسکریپت را بررسی می‌کند و در صورت وجود خطا، آن‌ها را گزارش می‌دهد.

نکات مهم در استفاده از گیت‌هاب اکشن

برای استفاده بهینه از گیت‌هاب اکشن، به نکات زیر توجه کنید:

• Actionهای کمینه: سعی کنید اکشن‌ها را تا حد امکان ساده و کمینه نگه دارید تا زمان اجرای آن‌ها کاهش یابد.
• اجتناب از دانلودهای غیرضروری: از دانلود وابستگی‌ها (dependencies) به صورت غیرضروری خودداری کنید و از مکانیزم کش گیت‌هاب استفاده کنید.
• عدم هاردکد کردن secretها: از هاردکد کردن secretها در گردش کارها خودداری کنید و از قسمت secretهای مخزن استفاده کنید.
• ذخیره اطلاعات نویسنده action: در metadata مربوط به action، اطلاعات نویسنده را ذخیره کنید تا مسئولیت هر action مشخص باشد.

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

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

• راهنمای استفاده از Github Actions

جمع‌بندی

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

The post گیت‌هاب اکشن (GitHub Actions) چیست؟ appeared first on بلاگ هم‌روش.

مشاهده‌پذیری چیست؟

به زبان ساده، مشاهده‌پذیری به معنای توانایی اندازه‌گیری وضعیت داخلی یک سیستم با بررسی خروجی‌های آن است. به‌عبارت دیگر، اگر بتوان با استفاده از داده‌هایی که از سیستم خارج می‌شوند (مانند لاگ‌ها، متریک‌ها و تریس‌ها) وضعیت فعلی آن را تخمین زد، آن سیستم «مشاهده‌پذیر» است. این مفهوم ریشه در نظریه کنترل دارد، اما امروزه کاربرد گسترده‌ای در بهبود عملکرد سیستم‌های IT پیدا کرده است.

مشاهده‌پذیری به شما اجازه می‌دهد تا پرسش‌هایی مانند «چرا X خراب شده است؟» یا «علت تاخیر در حال حاضر چیست؟» را بپرسید و پاسخ‌های دقیقی دریافت کنید. این ویژگی در محیط‌های ابری و سیستم‌های توزیع‌شده که دارای اجزای بسیار زیادی هستند، بسیار حیاتی است.

تفاوت مانیتورینگ و مشاهده‌پذیری

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

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

به‌طور خلاصه، مانیتورینگ یک عمل است و مشاهده‌پذیری یک ویژگی به‌حساب می‌آید. مانیتورینگ برای «مشکلات شناخته شده» مناسب است، در حالی که مشاهده‌پذیری برای «مشکلات ناشناخته» طراحی شده است.

چرا مشاهده‌پذیری مهم است؟

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

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

مشاهده‌پذیری برای غیرقابل پیش‌بینی بودن سیستم‌های توزیع شده مناسب‌تر است، عمدتاً به این دلیل که به شما امکان می‌دهد در هنگام بروز مشکلات، سوالاتی در مورد رفتار سیستم خود بپرسید.

ستون‌های اصلی مشاهده‌پذیری چیست؟

مشاهده‌پذیری بر پایه ۳ نوع داده اصلی استوار است که به آن‌ها «سه ستون مشاهده‌پذیری» گفته می‌شود:

• لاگ‌ها (Logs): لاگ‌ها، ثبت‌کننده‌ی متنی رویدادهایی هستند که در سیستم رخ می‌دهند. هر لاگ شامل یک مُهر زمان (timestamp) و اطلاعات مربوط به رویداد است.
• متریک‌ها (Metrics): متریک‌ها، مقادیر عددی هستند که در طول زمان اندازه‌گیری می‌شوند و معیارهایی مانند CPU، حافظه، یا زمان پاسخ‌دهی را نشان می‌دهند.
• تریس‌ها (Traces): تریس‌ها، مسیر درخواست را از ابتدا تا انتها در سیستمی توزیع‌شده دنبال می‌کنند. هر تریس شامل «اسپن‌ها» (Span) است که اطلاعات مربوط به هر عملیات انجام شده در طول مسیر را نشان می‌دهند.

برای دستیابی به مشاهده‌پذیری واقعی، باید این ۳ ستون را با هم ادغام کرد و از آن‌ها به صورت مجزا استفاده نکرد. این کار به شما کمک می‌کند تا نه تنها زمان وقوع مشکلات را متوجه شوید، بلکه علت وقوع آن‌ها را نیز درک کنید.

مزایای مشاهده‌پذیری

مشاهده‌پذیری مزایای متعددی را برای تیم‌های توسعه و کسب‌وکار به همراه دارد:

• دید بهتر: مشاهده‌پذیری دید کاملی از سیستم‌های توزیع‌شده به شما می‌دهد و به شما کمک می‌کند تا بفهمید چه سرویس‌هایی در حال اجرا هستند، عملکرد برنامه‌ها چگونه است و چه تغییراتی در سیستم رخ داده است.
• هشداردهی بهتر: با استفاده از مشاهده‌پذیری، می‌توانید مشکلات را سریع‌تر کشف و رفع کنید و با دید عمیق‌تر، تغییرات سیستم را بررسی کرده و در صورت نیاز، مشکلات را رفع کنید.
• بهبود گردش کار: مشاهده‌پذیری به توسعه‌دهندگان اجازه می‌دهد تا مسیر یک درخواست را به‌صورت سرتاسری ببینند و با اطلاعات متنی مرتبط با مشکل، فرآیند بررسی و رفع اشکال را بهینه‌سازی کنند.
• صرفه‌جویی در زمان: با مشاهده‌پذیری، اطلاعات به‌راحتی در دسترس است و دیگر نیازی به پیگیری اطلاعات از منابع مختلف نیست.
• افزایش سرعت توسعه: مشاهده‌پذیری با کارآمدتر کردن مانیتورینگ و عیب‌یابی، زمان توسعه را کاهش می‌دهد و به مهندسان این امکان را می‌دهد تا بر روی نوآوری‌ها تمرکز کنند.
• بهبود تجربه کاربری: با کمک داده‌های مربوط به تجربه کاربر (User Experience)، می توانید مشکلات را پیش از اینکه کاربر آن‌ها را ببیند حل کنید.

چالش‌های مشاهده‌پذیری چیست؟

در کنار مزایا، مشاهده‌پذیری چالش‌هایی نیز دارد:

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

راهکارهای عملی برای مشاهده‌پذیری

برای مقابله با چالش‌های مشاهده‌پذیری، باید به نکات زیر توجه کرد:

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

جمع‌بندی

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

The post مشاهده‌پذیری (observability) چیست؟ appeared first on بلاگ هم‌روش.

سنتری (sentry) چیست؟

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

سنتری چگونه کار می‌کند؟

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

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

ویژگی‌های کلیدی سنتری

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

• ردیابی خودکار خطا (Error Tracking): سنتری به طور خودکار خطاهای موجود در برنامه را شناسایی کرده و اطلاعات جامعی از جمله «گزارش خطای پشته» (stack trace)، «فضای کاربر» (user context) و متغیرهای محلی را ارائه می‌دهد. این اطلاعات به توسعه‌دهندگان کمک می‌کند تا به سرعت علت اصلی خطا را تشخیص داده و آن را رفع کنند.
• تجمیع هوشمند رویدادها (Event Aggregation): سنتری به‌طور خودکار خطاهای مشابه را در یک مسئله واحد جمع‌آوری می‌کند. این ویژگی به توسعه‌دهندگان کمک می‌کند تا الگوهای تکرار خطاها را شناسایی کرده و به جای رفع تک‌تک خطاها، به حل ریشه‌ای مشکل بپردازند.
• پیگیری مسائل (Issue Tracking): سنتری به تیم‌های توسعه این امکان را می‌دهد تا مسائل مربوط به خطاها را پیگیری کرده و آن‌ها را برای رفع به اعضای مختلف تیم ارجاع دهند. این ویژگی، فرآیند رفع خطا را بهینه‌سازی کرده و از گم شدن مسائل جلوگیری می‌کند.
• هشدار بلادرنگ (Real-time Alerts): سنتری هنگام تشخیص خطاهای جدید، هشدارهای بلادرنگ ارسال می‌کند. این هشدارها به توسعه‌دهندگان امکان می‌دهد تا به سرعت نسبت به مشکلات واکنش نشان داده و از تأثیرات منفی آن‌ها بر کاربران جلوگیری کنند.
• پایش عملکرد (Performance Monitoring): علاوه بر ردیابی خطاها، سنتری امکان پایش عملکرد برنامه را نیز فراهم می‌کند. این ویژگی به تیم‌های توسعه کمک می‌کند تا عملیات کُند و پرمصرف را شناسایی کرده و برای بهینه‌سازی عملکرد برنامه اقدام کنند.
• ردیابی نسخه‌ها (Release Tracking): سنتری به توسعه‌دهندگان اجازه می‌دهد تا نسخه‌های مختلف نرم‌افزار را ردیابی کرده و خطاها را به نسخه‌های خاص مرتبط کنند. این قابلیت به تیم‌ها کمک می‌کند تا بفهمند که آیا خطایی خاص در نسخه‌ای خاص رخ داده است یا خیر.
• گزارش‌گیری جامع: سنتری با ارائه گزارش‌های جامع و دقیق، به تیم‌ها امکان می‌دهد تا الگوهای خطاهای رخ‌داده را شناسایی کرده و بر اساس داده‌های واقعی، تصمیم‌گیری کنند.
• قابلیت سفارشی‌سازی: سنتری به توسعه‌دهندگان این امکان را می‌دهد تا تنظیمات و هشدارهای خود را بر اساس نیازهای خاص پروژه سفارشی‌سازی کنند.

مزایای استفاده از سنتری چیست؟

استفاده از سنتری مزایای متعددی برای تیم‌های توسعه نرم‌افزار به همراه دارد. برخی از این مزایا در ادامه فهرست شده‌اند:

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

کاربردهای سنتری چیست؟

سنتری ابزاری همه‌کاره است که می‌تواند در موقعیت‌های مختلفی در فرآیند توسعه نرم‌افزار به کار گرفته شود. برخی از کاربردهای کلیدی سنتری در ادامه آمده‌اند:

• پایش محیط عملیاتی (Production Monitoring): سنتری به تیم‌های توسعه کمک می‌کند تا خطاهای رخ‌داده در محیط عملیاتی را به‌صورت بلادرنگ پایش کرده و به سرعت نسبت به آن‌ها واکنش نشان دهند. این امر به حفظ پایداری و دسترس‌پذیری نرم‌افزار کمک می‌کند.
• عیب‌یابی در مراحل تست (Debugging in Testing Stages): سنتری می‌تواند به‌عنوان ابزاری کارآمد برای عیب‌یابی در مراحل تست نرم‌افزار مورد استفاده قرار گیرد. با استفاده از سنتری، تیم‌های تست می‌توانند خطاهای موجود در نرم‌افزار را شناسایی کرده و اطلاعات دقیقی از آن‌ها به تیم‌های توسعه منتقل کنند.
• تجزیه و تحلیل عملکرد (Performance Analysis): سنتری با جمع‌آوری اطلاعات مربوط به عملکرد برنامه، به تیم‌ها کمک می‌کند تا گلوگاه‌های عملکردی را شناسایی کرده و برای بهبود کارایی برنامه اقدام کنند.
• یکپارچگی با ابزارهای توسعه (Integration with Development Tools): سنتری به‌راحتی با ابزارهای مختلف توسعه نرم‌افزار مانند سیستم‌های کنترل نسخه (Git)، خدمات پیگیری مسئله (Jira) و پلتفرم‌های CI/CD یکپارچه می‌شود. این یکپارچگی به تیم‌ها کمک می‌کند تا فرآیند رفع خطا را بهینه کرده و بهره‌وری خود را افزایش دهند.
• ردیابی خطاهای مکرر (Tracking Recurring Errors): سنتری با استفاده از گروه‌بندی هوشمند خطاها، به تیم‌ها کمک می‌کند تا خطاهای مکرر را شناسایی کرده و به‌طور مؤثرتری با آن‌ها مقابله کنند. این قابلیت به تیم‌ها امکان می‌دهد تا به جای رفع تک‌تک خطاها، به حل ریشه‌ای مشکل بپردازند.

چند مثال از کاربرد سنتری

برای روشن‌تر شدن نحوه استفاده از سنتری، چند مثال عملی را در نظر می‌گیریم:

• شناسایی خطاها در برنامه وب پایتون: فرض کنید برنامه وب پایتونی دارید که دچار خطا شده است. با استفاده از سنتری، می‌توانید به سرعت علت اصلی خطا، از جمله stack trace و user context را شناسایی کنید. همچنین می‌توانید خطاها را در طول زمان پیگیری کنید و الگوهای تکرار آن‌ها را تشخیص دهید.
• عیب‌یابی مشکلات عملکرد در برنامه جاوا اسکریپتی: فرض کنید برنامه‌ای جاوا اسکریپتی دارید که به کندی اجرا می‌شود. با استفاده از سنتری، می‌توانید عملیات کُند و پرمصرف را شناسایی کنید و برای بهینه‌سازی عملکرد برنامه اقدام‌های لازم را انجام دهید.
• رفع خطاها در یک برنامه روبی آن ریلز: فرض کنید برنامه روبی آن ریلزی دارید که دچار خطا شده است. با استفاده از سنتری، می‌توانید مسئله را پیگیری کنید و آن را به یکی از اعضای تیم برای رفع ارجاع دهید. همچنین می‌توانید خطا را با یک نسخه خاص از برنامه مرتبط کنید تا مشخص شود خطا در چه زمانی بروز پیدا کرده است.

سرویس سنتری (Sentry) هم‌روش

هم‌روش سنتری را به‌صورت سرویس ارائه می‌دهد. با استفاده از سرویس سنتری هم‌روش بار راه‌اندازی و نگه‌داری از این ابزار از روی دوش تیم فنی شما برداشته می‌شود.

مزایای سرویس سنتری هم‌روش

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

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

هم‌روش همواره در حال به‌روزرسانی، بررسی عملکرد سرویس و پشتیبان‌گیری از اطلاعات کاربران سرویس Sentry است. همچنین هم‌روش با سیستم مانیتورینگ خود، تلاش می‌کند تا تجربه‌ی خوبی در uptime و سطوح مختلف SLA ارائه دهد.

قیمت مناسب با قابلیت ارتقاء پلن

قیمت مناسب سرویس Sentry ارائه‌شده در هم‌روش نسبت به sentry.io و Sentryهای Self-hosted، این امکان را می‌دهد تا تعداد بیشتری از eventها را دریافت کرده و به حل مشکلات بپردازید. با انتخاب هر یک از پلن‌ها، در آینده این امکان را خواهید داشت که پلن خود را بدون از دست دادن اطلاعات قبلی، ارتقا داده و هزینه‌های خود را کمینه نگه‌دارید.

برای آشنایی بیشتر با سرویس سنتری هم‌روش می‌توانید به صفحه سرویس سنتری هم‌روش مراجعه کنید.

جمع‌بندی

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

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

با توجه به نیازهای خاص پروژه خود، می‌توانید از سنتری برای پایش خطاهای برنامه، عیب‌یابی سریع مشکلات و بهینه‌سازی عملکرد نرم‌افزار خود استفاده کنید. به یاد داشته باشید که استفاده از ابزارهایی مانند سنتری، نه تنها به بهبود کیفیت نرم‌افزار شما کمک می‌کند، بلکه در نهایت باعث صرفه‌جویی در زمان و هزینه‌های توسعه نیز خواهد شد.

The post سنتری (sentry) چیست؟ appeared first on بلاگ هم‌روش.

pgHero چیست؟

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

چرا pgHero مهم است؟

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

قابلیت‌های کلیدی pgHero چیست؟

pgHero دارای ویژگی‌های مختلفی است که به شما در بهبود عملکرد پستگره کمک می‌کند. برخی از این قابلیت‌ها عبارتند از:

• داشبورد نمای کلی (Overview): این بخش یک نمای کلی از وضعیت دیتابیس را نمایش می‌دهد، از جمله اتصالات، کوئری‌های طولانی، وضعیت Vacuum، شاخص‌های نامعتبر یا تکراری و کوئری‌های کُند. وضعیت‌های مختلف با رنگ‌های متفاوت نمایش داده می‌شوند (سبز یعنی خوب، غیر سبز یعنی نیاز به توجه دارد).
• کوئری‌ها (Queries): در این بخش، زمان اجرای دستورات مختلف را مشاهده می‌کنید و می‌توانید کوئری‌های کند را شناسایی کنید.
• فضا (Space): این قسمت نشان می‌دهد که کدام جداول و شاخص‌ها بیشترین حافظه را مصرف می‌کنند. این اطلاعات برای بهینه‌سازی فضای دیتابیس بسیار مفید است.
• اتصالات (Connections): این بخش اطلاعاتی در مورد منشاء اتصالات به دیتابیس را نمایش می‌دهد.
• Live Queries: در این قسمت می‌توانید کوئری‌هایی که در حال اجرا هستند را مشاهده کرده و در صورت لزوم، آن‌ها را متوقف کنید.
• نگهداری (Maintenance): این بخش زمان آخرین عملیات Vacuum و Analyze را گزارش می‌دهد. این عملیات برای حفظ عملکرد دیتابیس ضروری هستند.
• Explain: با استفاده از این قابلیت، می‌توانید نحوه اجرای کوئری‌ها را به‌صورت تفصیلی بررسی کنید و نقاط ضعف آن‌ها را شناسایی کنید.
• شناسایی کوئری‌های طولانی: pgHero به شما کمک می‌کند تا کوئری‌هایی که زمان زیادی برای اجرا نیاز دارند را شناسایی کرده و با ارائه اطلاعاتی مانند طرح اجرا و معیارهای کوئری، به شما در بهبود عملکرد آن‌ها کمک می‌کند.
• توصیه‌های شاخص‌گذاری: pgHero با تجزیه و تحلیل الگوهای کوئری، توصیه‌هایی برای استفاده بهینه از شاخص‌ها ارائه می‌دهد. شاخص‌ها نقش بسیار مهمی در افزایش سرعت کوئری‌ها دارند.
• تجزیه و تحلیل طرح اجرا: با استفاده از قابلیت Explain، می‌توانید طرح اجرای کوئری‌ها را به‌صورت گرافیکی مشاهده کرده و مشکلات احتمالی را تشخیص دهید.
• نمایش معیارهای عملکرد: pgHero معیارهای مختلف عملکرد دیتابیس را به‌صورت نمودار و گزارش نمایش می‌دهد. این اطلاعات به شما کمک می‌کند تا به‌صورت فعالانه عملکرد دیتابیس را مدیریت کنید.
• تاریخچه عملکرد: امکان پیکربندی برای جمع‌آوری آمار و داده‌های عملکرد در بازه‌های زمانی ۵ دقیقه و روزانه وجود دارد.

نصب و راه‌اندازی pgHero با داکر

یکی از ساده‌ترین روش‌های نصب و راه‌اندازی pgHero استفاده از Docker است. داکر به شما اجازه می‌دهد تا pgHero را در یک محیط ایزوله و مستقل اجرا کنید. برای این کار، مراحل زیر را دنبال کنید:

• ابتدا، Docker را نصب کنید (اگر Docker را نصب ندارید، به وبسایت Docker مراجعه کنید).
• سپس، دستور زیر را در ترمینال یا خط فرمان خود اجرا کنید (در این دستور، باید مقادیر زیر را با مقادیر مربوط به دیتابیس خود جایگزین کنید):
  • postgres://user:password@hostname:5432/dbname: این رشته اتصال به دیتابیس PostgreSQL شماست.
  • -p 8080:8080: این پورت ۸۰۸۰ را در کامپیوتر شما به پورت ۸۰۸۰ در کانتینر Docker متصل می‌کند.
  • ankane/pghero نام ایمیج داکر برای pgHero است.
• پس از اجرای دستور، pgHero در آدرس http://localhost:8080 در دسترس خواهد بود.
• اگر pgHero نتواند به دیتابیس شما متصل شود، ممکن است با یک سری خطاها مواجه شوید. در این صورت، اتصال دیتابیس خود را بررسی کنید.
• اگر دیتابیس شما تازه ایجاد شده باشد، ممکن است لازم باشد قابلیت Query Stats را فعال کنید.

نکات مهم در استفاده از pgHero

• pgHero نباید در محیط توسعه استفاده شود و بهتر است برای جمع‌آوری آمار و ارقام از محیط production استفاده کنید.
• pgHero برای گزارش خطا در هنگام اتصال ناموفق به دیتابیس، عملکرد خوبی ندارد و ممکن است فقط یک سری traceback از پشته Ruby را در ترمینال نمایش دهد.
• می‌توانید pgHero را به‌گونه‌ای پیکربندی کنید که تاریخچه کوئری‌ها و آمارهای فضایی را نیز جمع‌آوری کند. این کار به شما اجازه می‌دهد تا تغییرات عملکرد دیتابیس را در طول زمان مشاهده کنید.

مزایا و معایب pgHero

• مزایای pgHero:
  • رابط کاربری ساده و کاربرپسند: استفاده از این ابزار بسیار آسان است.
  • ارائه اطلاعات جامع: اطلاعات کاملی در مورد عملکرد دیتابیس ارائه می‌دهد.
  • قابلیت نصب آسان: نصب و راه‌اندازی آن با Docker بسیار ساده است.
  • بهینه‌سازی عملکرد: به شما در شناسایی و رفع مشکلات عملکردی کمک می‌کند.
  • توصیه‌های مفید: توصیه‌هایی برای بهینه‌سازی شاخص‌ها و کوئری‌ها ارائه می‌دهد.
  • مانیتورینگ لحظه‌ای: امکان مشاهده عملکرد دیتابیس به‌صورت لحظه‌ای را فراهم می‌کند.
  • ابزار رایگان و متن‌باز: برای استفاده از آن نیاز به پرداخت هزینه ندارید.
• معایب:
  • عدم گزارش‌دهی مناسب خطا در اتصال: در صورت بروز مشکل در اتصال به دیتابیس، گزارش خطای مناسبی ارائه نمی‌دهد.
  • نیاز به Docker برای نصب آسان: اگر با Docker آشنایی نداشته باشید، ممکن است نصب آن کمی دشوار باشد.

استفاده از pgHero در سرویس دیتابیس هم‌روش

در بخش پایانی این مطلب، باید به نحوه استفاده از pgHero در سرویس دیتابیس هم‌روش اشاره کنیم. برای این کار، می‌توانید از مستندات هم‌روش به آدرس زیر استفاده کنید:

• استفاده از افزونه‌ی Pg Hero | مستندات هم‌روش

جمع‌بندی

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

The post pgHero چیست؟ appeared first on بلاگ هم‌روش.

دیتابیس PostgreSQL چگونه کار می‌کند؟

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

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

Connection Pooling چیست؟

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

PgBouncer چیست؟

PgBouncer یک connection pooler سبُک و متن‌باز برای PostgreSQL است که به‌عنوان پروکسی بین کلاینت‌ها و دیتابیس عمل می‌کند. PgBouncer اتصالات را برای هر ترکیب کاربر و دیتابیس نگهداری می‌کند و آن‌ها را به اتصالات ورودی جدید اختصاص می‌دهد. هنگامی که اتصال کلاینت بسته می‌شود، اتصال مجدداً به pool برمی‌گردد. این ابزار از پروتکل‌های TCP و Unix domain sockets برای ارتباط با کلاینت‌ها پشتیبانی می‌کند. همچنین، PgBouncer می‌تواند روی نود کلاینت، سرور دیتابیس یا به عنوان خوشه‌ای مستقل پیاده‌سازی شود.

مزایای استفاده از PgBouncer

استفاده از PgBouncer مزایای متعددی دارد:

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

نصب و پیکربندی PgBouncer

نصب PgBouncer بسیار آسان است. شما می‌توانید آن را با استفاده از دستورات زیر در سیستم عامل‌های مختلف نصب کنید:

# RedHat/CentOS/..
sudo yum install pgbouncer

# Debian/Ubuntu/..
sudo apt-get install pgbouncer

# RedHat/CentOS/..
sudo yum install pgbouncer

# Debian/Ubuntu/..
sudo apt-get install pgbouncer

PgBouncer بر اساس یک فایل پیکربندی اصلی کار می‌کند که معمولاً در مسیر /etc/pgbouncer/pgbouncer.ini قرار دارد. در این فایل، شما می‌توانید تنظیمات مربوط به اتصالات دیتابیس، کاربران مجاز و سایر پارامترها را پیکربندی کنید. در فایل pgbouncer.ini، موارد زیر را تنظیم کنید:

• بخش databases: مشخص کردن مشخصات اتصال به دیتابیس PostgreSQL، مانند host، port و نام دیتابیس.
• بخش pgbouncer: تنظیم پارامترهایی مانند listen_addr (آدرس IP که PgBouncer به آن گوش می‌دهد)، listen_port (شماره پورتی که PgBouncer به آن گوش می‌دهد)، auth_file (فایل حاوی نام کاربری و رمز عبور کاربران مجاز) و admin_users (کاربران ادمین).
• تنظیمات مربوط به نحوه مدیریت pool‌ها: مانند pool_mode که تعیین می‌کند اتصال چه زمانی به pool برگردانده شود.
• تنظیم محدودیت اتصال: مانند max_client_conn که تعداد کل کلاینت‌هایی که می‌توانند به PgBouncer متصل شوند را مشخص می‌کند.
• تنظیمات احراز هویت: مانند auth_type که تعیین می‌کند چگونه کاربران احراز هویت شوند.
• تعیین کاربرهای ادمین: در بخش admin_users می‌توان کاربرهایی را مشخص کرد که اجازه تغییر تنظیمات PgBouncer را دارند.
• فایل userlist.txt: در این فایل، نام کاربری و هش رمز عبور کاربران مجاز برای اتصال به PgBouncer را ذخیره می‌کنید. برای ایجاد هش رمز عبور می‌توانید از دستورات مربوط به سیستم عامل استفاده کنید.

پس از پیکربندی PgBouncer، می‌توانید آن را به‌عنوان یک سرویس systemd راه‌اندازی کنید یا به‌صورت دستی اجرا کنید. برای اعمال تغییرات در تنظیمات، می‌توانید از دستور sudo service pgbouncer restart استفاده کنید.

نحوه اتصال به دیتابیس از طریق PgBouncer

پس از نصب و پیکربندی PgBouncer، کلاینت‌ها به جای اتصال مستقیم به پورت پیش‌فرض PostgreSQL (5432)، به پورت PgBouncer (معمولاً 6432) متصل می‌شوند. به عنوان مثال، برای اتصال با استفاده از psql:

psql -U your_username -p 6432 -h your_host your_database

psql -U your_username -p 6432 -h your_host your_database

PgBouncer اتصالات را به pool دیتابیس هدایت می‌کند و درخواست‌های شما را اجرا می‌کند.

مدیریت و مانیتورینگ PgBouncer

PgBouncer امکانات مدیریتی و مانیتورینگ متعددی را ارائه می‌دهد. کاربران ادمین می‌توانند به یک دیتابیس مجازی به نام «pgbouncer» متصل شده و دستورات مختلفی را برای کنترل سرور و مشاهده آمار صادر کنند. برخی از این دستورات عبارتند از:

• RELOAD: بارگیری مجدد تنظیمات PgBouncer
• DISABLE db1: غیرفعال کردن دیتابیس db1
• ENABLE db1: فعال کردن دیتابیس db1
• SHOW FDS: نمایش فایل دسکریپتورهای باز
• SHOW POOLS: نمایش آمار مربوط به poolها
• مشاهده آمار مربوط به هر دیتابیس: شامل زمان اجرای کوئری‌ها و زمان انتظار کلاینت‌ها.
• مشاهده آمار مربوط به هر pool: شامل تعداد کلاینت‌های فعال و منتظر و تعداد اتصالات سرور فعال و غیرفعال.

این امکانات به شما کمک می‌کنند تا عملکرد PgBouncer را مانیتور کرده و در صورت لزوم تغییراتی اعمال کنید.

تست عملکرد PgBouncer

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

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

سناریوهای پیاده‌سازی PgBouncer

PgBouncer را می‌توان در سناریوهای مختلفی پیاده‌سازی کرد:

• روی node سرور دیتابیس: در این حالت، PgBouncer روی همان سروری نصب می‌شود که PostgreSQL نصب شده است. کلاینت‌ها به جای اتصال مستقیم به پورت PostgreSQL، به پورت PgBouncer متصل می‌شوند.
• روی نود کلاینت: در این حالت، PgBouncer روی هر نود کلاینت نصب می‌شود. به عنوان مثال، هر نود وب که با PHP کار می کند می‌تواند به یک PgBouncer محلی متصل شود.
• به‌عنوان یک خوشه مستقل: در این حالت، مجموعه‌ای از نودهای PgBouncer مستقل در یک خوشه قرار می‌گیرند و با یک load balancer مانند HAProxy در دسترس قرار می‌گیرند. این روش بیشترین انعطاف پذیری را دارد ولی پیچیدگی بیشتری نیز دارد.

جمع‌بندی

PgBouncer ابزاری قدرتمند و کارآمد برای connection pooling در PostgreSQL است. با استفاده از این ابزار، می‌توانید بار روی سرور دیتابیس خود را کاهش داده و عملکرد اپلیکیشن‌هایتان را بهبود ببخشید. نصب و پیکربندی PgBouncer بسیار ساده است و مزایای متعددی را به همراه دارد. اگر شما نیز با مشکل اتصالات زیاد به دیتابیس PostgreSQL مواجه هستید، حتماً استفاده از PgBouncer را در نظر بگیرید.

با استفاده از امکانات مانیتورینگ PgBouncer می‌توانید عملکرد آن را به‌طور مداوم بررسی کنید و از تاثیر مثبت آن بر عملکرد اپلیکیشن خود اطمینان حاصل کنید. همان‌طور که دیدید، این ابزار برای هر پروژه‌ای که از PostgreSQL استفاده می‌کند مفید است و می‌تواند کمک شایانی به بهبود کارایی دیتابیس و در نتیجه کارایی نرم افزار شما بکند.

The post pgbouncer چیست و چه کمکی به بهبود عملکرد دیتابیس‌تان می‌کند؟ appeared first on بلاگ هم‌روش.

Kubernetes Secrets چیست؟

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

Kubernetes Secrets برای نگه‌داری امن اطلاعات حساس مانند رمزهای عبور، توکن‌ها و گواهینامه‌ها به کار می‌روند. دیپلویمنت‌ها، پادها و سایر منابع Kubernetes که به این اطلاعات حساس نیاز دارند، می‌توانند از Secrets استفاده کنند. همه ما به کسی یا چیزی نیاز داریم که رازهای ما را امن نگه دارد، در این مورد، این نقش برعهده Kubernetes است. شیءهای Secret جزئی از «Kubernetes v1 API» هستند و با استفاده از مانیفست زیر می‌توان آن‌ها را ایجاد کرد:

apiVersion: v1

kind: Secret

metadata:

 name: file-credential

data:

 .secret-file: dmFsdWUtMg0KDQo=

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

apiVersion: v1


kind: Pod


metadata:


 name: secret-files-pod


spec:


 volumes:


   - name: secret-volume


     secret:


       secretName: file-secret


 containers:


   - name: dotfile-test-container


     image: registry.k8s.io/busybox


     command:


       - ls


       - "-l"


       - "/etc/secret-volume"


     volumeMounts:


       - name: secret-volume


         readOnly: true


         mountPath: "/etc/secret-volume"

در این مثال، فایل Secrets مربوطه در مسیر /etc/secret-volume در سیستم فایل قرار می‌گیرد تا برنامه بتواند به آن دسترسی داشته باشد. (در تعریف volume mount، شما مشخص می‌کنید که مسیر فایل کجا خواهد بود.)

چطور از Kubernetes Secrets استفاده کنیم؟

به روش‌های مختلفی می‌توان از Secretها در یک کلاستر کوبرنتیز استفاده کرد. از جمله این روش‌ها می‌توان به موارد زیر اشاره داشت:

• متغیرهای محیطی در یک کانتینر
• فایل‌هایی داخل یک کانتینر
• آرگومان‌های خط فرمان در داخل یک کانتینر

در ادامه هر یک از موارد فوق در زیربخش‌هایی شرح داده شده‌اند.

متغیرهای محیطی در یک کانتینر

Secretها می‌توانند برای ارسال داده‌های حساس به کانتینرها/پادها به‌عنوان متغیرهای محیطی استفاده شوند. این یک موردِ استفاده و کاربرد رایج برای Secretها است، زیرا به برنامه اجازه می‌دهد به‌راحتی به این داده‌ها دسترسی پیدا کند.

فایل‌هایی داخل یک کانتینر

Secretها می‌توانند به‌صورت فایل در یک کانتینر mount شوند. به این ترتیب برنامه می‌تواند به داده‌ها به‌صورت فایل دسترسی داشته باشد. این می‌تواند برای برنامه‌هایی مفید باشد که انتظار دارند داده‌های حساس در یک فایل ذخیره شوند.

آرگومان‌های خط فرمان در داخل یک کانتینر

Secretها می‌توانند به‌عنوان آرگومان‌های خط فرمان به یک کانتینر ارسال شوند. این ویژگی می‌تواند برای برنامه‌هایی مفید باشد که انتظار دارند داده‌های حساس به‌عنوان آرگومان خط فرمان ارسال شوند.

مواردِ استفاده Kubernetes Secrets چیست؟

موارد زیر نمونه‌هایی از کاربردهای متداول Secrets هستند:

• فراهم کردن متغیرهای محیطی برای کانتینرها: مقادیر محیطی می‌توانند رفتار برنامه را کنترل کنند، بنابراین استفاده از Secrets برای ارائه این مقادیر توصیه می‌شود. این مقادیر محیطی کانتینر ممکن است شامل اطلاعات محرمانه مانند اعتبارنامه‌ها (Credentials) باشد که برای فراخوانی برنامه‌های شخص ثالث (مثلاً درگاه‌های پرداخت) مورد استفاده قرار می‌گیرند.
• فراهم کردن اعتبارنامه‌هایی مانند کلیدهای SSH، رمزهای عبور برای کانتینرها: Secrets می‌توانند اعتبارنامه‌هایی مانند کلیدهای SSH، رمزهای عبور، گواهینامه‌های TLS و موارد مشابه را به کانتینرها منتقل کنند. کلیدهای SSH و گواهینامه‌های TLS از نشانه‌های امنیتی مهمی هستند که می‌توانند در برنامه‌ها و از طریق Secrets ارسالی به آن‌ها، مورد استفاده قرار گیرند.
• ایجاد امکان pull شدن ایمیج‌های کانتینرها از رجیستری: Secrets همچنین برای اجازه دادن pull کردن تصاویر کانتینر از رجیستری‌ها در گره‌های کوبرنتیز به کار می‌روند. می‌توانید اعتبارنامه‌های دسترسی رجیستری Docker را از طریق Secrets ارائه کنید تا Kubelet از آنها برای pull کردن تصاویر کانتینر ذخیره شده در رجیستری استفاده کند.
• ذخیره اطلاعات اضافه مثل جزئیات Helm: همان‌طور که Helm از Secrets برای ذخیره اطلاعات مربوط به خود استفاده می‌کند، سایر برنامه‌ها نیز می‌توانند از Secrets برای انجام عملکردهای خود بهره ببرند.

حالا در ادامه به سایر انواع Kubernetes Secrets می‌پردازیم.

انواع Kubernetes Secrets چیست؟

بر اساس مقادیر تعیین شده برای Secrets، آن‌ها به انواع زیر تقسیم می‌شوند:

• Opaque: نوع پیش‌فرض و عمومی Secrets است که هر کسی می‌تواند آن را ایجاد و استفاده کند. این نوع، زوج‌های کلید-مقدار ساده هستند؛ بنابراین اگر نوع آن را مشخص نکنید، یک Secret از نوع Opaque (با تعریف نوع opaque) ایجاد خواهد شد.
• توکن‌های Service Account: برای شناسایی حساب‌های سرویس استفاده می‌شوند. این توکن‌ها به API‌های کوبرنتیز امکان دسترسی به پاد‌ها را می‌دهند. نوع این API، kubernetes.io/service-account-token است.
• SSH-auth: این نوع Secret برای ذخیره اطلاعات مورد نیاز به‌منظور احراز هویت SSH استفاده می‌شود. نوع آن kubernetes.io/ssh-auth است.
• TLS: از این نوع Secret برای ذخیره گواهینامه‌های TLS و کلید‌های مرتبط با آن‌ها استفاده می‌شود. نوع این Secret kubernetes.io/tls است.
• Basic-auth: برای Secret‌های «احراز هویت پایه» (basic auth)، نوع آن را kubernetes.io/basic-auth تعریف کنید.
• Docker-cgf و Dockerconfigjson: پیکربندی‌های مربوط به Docker و اعتبارنامه‌های رجیستری معمولاً در این دو نوع Secret ذخیره می‌شوند. برای استفاده از docker-cfg و dockerconfigjson، نوع را به‌ترتیب kubernetes.io/dockercfg یا kubernetes.io/dockerconfigjson تعریف کنید.
• توکن: این نوع Secret به توکن‌های «راه‌اندازی» (bootstrap) اشاره دارد که برای اضافه کردن Nodeهای جدید به خوشه کوبرنتیز مورد استفاده قرار می‌گیرند. برای استفاده از این توکن در فرایند راه‌اندازی نود، نوع آن را bootstrap.kubernetes.io/token تعریف کنید.

چطور Kubernetes Secret بسازیم؟

در این بخش از مقاله هر یک از مراحل ایجاد و استفاده از Kubernetes Secrets شرح داده شده است.

گام اول: ایجاد و ساخت Kubernetes Secret

چند روش برای ایجاد Kubernetes Secret وجود دارد که آسان‌ترین آن استفاده از دستور kubectl create secret است. در ادامه مثالی برای این روش ارائه کرده‌ایم:

kubectl create secret generic my-secret --from-literal=password=abc123

دستور بالا یک سیکرت عمومی یا همان جنریک با نام my-secret ایجاد می‌کند و مقدار کلید password را برابر abc123 قرار می‌دهد. همچنین می‌توان با استفاده از آپشن — from-file نیز یک Kubernetes Secret ایجاد کرد:

kubectl create secret generic my-secret --from-file=ssh-privatekey=/path/to/privatekey --from-file=ssh-publickey=/path/to/publickey

دستور بالا یک سکرت عمومی با نام my-secret ایجاد می‌کند و مقادیر کلیدهای ssh-privatekey و ssh-publickey را برابر با محتویات فایل‌های مشخص شده قرار می‌دهد.

گام دوم: استفاده از Kubernetes Secret در یک Pod

برای استفاده از یک Secret در یک Pod، باید volumeی را که به Secret ارجاع می‌دهد اضافه و سپس آن volume را به کانتینر وصل کنیم. در ادامه مثالی برای این مورد ارائه شده است.

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
 containers:
 - name: my-container
 image: my-image
 volumeMounts:
 - name: my-secret
 mountPath: /etc/my-secret
 readOnly: true
 volumes:
 - name: my-secret
 secret:
 secretName: my-secret

این فایل YAML یک Pod تعریف می‌کند که یک کانتینر و یک volume دارد. volume یک Secret کوبرنتیز با نام my-secret است که در مسیر /etc/my-secret به کانتینر mount شده است.

گام سوم: استفاده از Kubernetes Secret در یک Deployment

برای استفاده از Secret در یک Deployment، می‌توانیم یک متغیر محیطی که به Secret ارجاع می‌دهد را اضافه کنیم. در ادامه مثالی در این خصوص ارائه شده است.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-deployment
spec:
 replicas: 3
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: my-image
 env:
 - name: DB_PASSWORD
 valueFrom:
 secretKeyRef:
 name: my-secret
 key: password

این فایل YAML یک Deployment را تعریف می‌کند که دارای یک کانتینر است. کانتینر یک متغیر محیطی به نام DB_PASSWORD دارد که مقدار آن از کلید password در سکرت my-secret گرفته شده است.

گام چهارم: مشاهده Kubernetes Secrets

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

kubectl get secret secret-name

سکرت توسط kubectl با فرمت کدگذاری شده base64 نمایش داده می‌شود. برای رمزگشایی کامل Secret، از یک دیکُدر base64 خارجی (مانند برنامه base64 در لینوکس) استفاده و دستوراتی مانند دستور زیر را اجرا می‌کنیم:

echo $encoded_secret | base64 -d

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

kubectl get secrets

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

گام پنجم: ویرایش مشخصات یک سکرت K8s

برای تغییر مشخصات یک سکرت کوبرنتیز موجود، می‌توانیم از دستور kubectl edit استفاده کنیم. دستور زیر نشان می‌دهد که چطور می‌توان یک Kubernetes Secret با نام production-secret را ویرایش کرد:

kubectl edit secret production-secret

گام ششم: حذف یک Kubernetes Secret با استفاده از دستور kubectl

برای حذف یک سکرت، ابتدا با استفاده از دستورات cat یا get بررسی می‌کنیم که آیا سکرت‌هایی در کلاستر ما وجود دارد یا خیر. سپس با دستور describe می‌توانیم اطلاعات بیشتری در مورد یک سکرت خاص کسب کنیم. برای حذف سکرت‌های کوبرنتیز از دستور kubectl delete استفاده می‌شود:

kubectl delete secret production-secret

به این ترتیب اکنون یاد گرفتیم که چطور Kubernetes Secrets را ایجاد و از آن‌ها استفاده کنیم.

Kubernetes Secrets چقدر ایمن هستند؟

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

Kubernetes Secrets به‌صورت رمزگذاری شده در سرور API کوبرنتیز ذخیره می‌شوند و تنها کاربران یا سرویس‌های مُجازی که مجوز لازم را دارند، می‌توانند به آن‌ها دسترسی داشته باشند. به‌طور پیش‌فرض، Secret‌ها با الگوریتم رمزنگاری AES-256 رمزگذاری می‌شوند و دسترسی به آن‌ها توسط قوانین RBAC (کنترل دسترسی نقش‌محور) کوبرنتیز کنترل می‌شود.

یک روش رایج این است که دسترسی ویرایش یا حذف به فردی که نیازی به آن ندارد، داده نشود. علاوه بر این، Kubernetes Secrets تنها زمانی که یک Pod از آن‌ها استفاده می‌کند در حافظه ذخیره می‌شوند. پس از خاتمه پاد، Secret‌ها برای همیشه از حافظه حذف می‌شوند که این امر لایه امنیتی افزوده‌ای را فراهم می‌کند.

با این حال، مهم است که بدانید Kubernetes Secrets کاملاً امن نیستند و خطرهای امنیتی بالقوه‌ای وجود دارد که می‌تواند امنیت Secret‌ها را به خطر بیندازد. به‌عنوان مثال، اگر یک مهاجم به کلاستر Kubernetes یا به پادی که از Secret‌ها استفاده می‌کند دسترسی پیدا کند، ممکن است بتواند به Secret‌ها هم دسترسی پیدا کند. در گذشته چنین مواردی رخ داده است، بنابراین باید با احتیاط عمل کرد؛ زیرا هیچ سیستمی در دنیا ۱۰۰ درصد امن نیست.

باید به خاطر داشت که نحوه ذخیره Kubernetes Secrets در etcd چندان امن نیست، زیرا رمزگذاری نمی‌شوند. بلکه به‌صورت اشیاء رمزگذاری‌شده Base64 ذخیره می‌شوند. این به آن معناست که اگر کسی به این داده‌ها دسترسی پیدا کند، می‌تواند به‌سرعت رشته Base64 را رمزگشایی و از تمام Secret‌ها استفاده کند. تنها چیزی که نیاز دارد، دسترسی برای مشاهده اشیاء Secret Kubernetes است (می‌توان از استفاده Base64 با بهره‌گیری از فیلد stringData اجتناب کرد).

بهترین شیوه‌ها در Kubernetes Secrets

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

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

پیکربندی Kubernetes secrets به‌منظور افزایش امنیت در آن‌ها

برای امن‌تر کردن Kubernetes secrets، می‌توان موارد زیر را انجام داد:

• اعمال قوانین کنترل دسترسی نقش‌محور (RBAC): کوبرنتیز از کنترل دسترسی نقش‌محور و مبتنی بر سیاست به خوبی پشتیبانی می‌کند. می‌توان به‌راحتی کنترل کرد که چه کسی مجاز است به کدام اجزا در Kubernetes دسترسی داشته باشد، بنابراین می‌توانیم استفاده از API‌های Secret را محدود و دسترسی به Secret‌ها را از تمام کاربران حذف کرد. اطمینان از عدم دسترسی به Secret‌ها از طریق ابزار خط فرمان Kubectl، اولین گام است.
• اجازه دسترسی به Secret‌های خاص تنها برای کانتینرها: همان‌طور که می‌توان دسترسی RBAC را برای کاربران کنترل کرد، می‌توان دسترسی به Secret‌ها را به مجموعه‌ای خاص از برنامه‌ها محدود کرد. به این ترتیب، Secret‌های شما تنها برای برنامه‌هایی در دسترس خواهند بود که مجاز به استفاده از آن‌ها هستند.

فعال کردن رمزگذاری در حالت استراحت (Encryption at rest)

رمزگذاری در حالت استراحت (Encryption at rest) یک ویژگی است که می‌توان آن را با استفاده از پرچم --encryption-provider-config در سرور API فعال کرد. در این پرچم، شما به یک فایل اشاره می‌کنید که ارائه‌دهندگان رمزگذاری در حالت استراحت را مشخص می‌کند. محتوای این فایل YAML چیزی شبیه به این خواهد بود:

apiVersion: apiserver.config.k8s.io/v1

kind: EncryptionConfiguration

resources:

 - resources:

     - events

   providers:

     - identity: {} # do not encrypt Events even though *.* is specified below

 - resources:

     - '*.apps' 

   providers:

     - aescbc:

         keys:

         - name: first_key

           secret: c2VlkansaklnsxlanslxHsa1hUndklMgaXQ/Cg==

 - resources:

     - '*.*' 
   providers:

     - aescbc:

         keys:

         - name: second_key

           secret: c2VjcmV12ds2JJklY3vyZSwgSSB0aGluaw==

با نگاه به این فایل، می‌بینید که آرایه‌ای از منابع وجود دارد که شرط‌هایی را برای آن‌ها اعمال می‌کنیم. منبع events «رمزگذاری در حالت استراحت» ندارد، زیرا هویت ارائه دهنده یک آرایه خالی است. سپس، مشخص کرده‌ایم که منابع تحت اِی‌پی‌آی apps‌ باید در حالت استراحت رمزگذاری شوند. آخرین آرایه نشان می‌دهد که همه چیز در Kubernetes باید رمزگذاری شود.

ابزارهایی برای مدیریت پایدار Kubernetes secrets

با پیروی از نکات پیکربندی که تا اینجا ارائه شدند، می‌توان اطمینان حاصل کرد که هیچ کاربر یا نهاد غیرمجازی نمی‌تواند به Secret‌های ما دسترسی پیدا کند. با این حال، ارسال واقعی Secret‌ها به Kubernetes نیز خطرات امنیتی را به‌همراه دارد که نیازمند کنترل دسترسی نقش‌محور و سایر بررسی‌ها برای کاهش آن است. این‌‌ها ویژگی‌های بومی Kubernetes نیستند، اما خوشبختانه ابزارهای موثر زیادی برای انتخاب وجود دارد.

در ادامه ابتدا به راهکارهای شخص ثالث برای مدیریت پایدار Kubernetes secrets می‌پردازیم.

راهکارهای شخص ثالث برای مدیریت پایدار Kubernetes secrets

• Vault: یک استاندارد صنعتی است که به‌طور گسترده مورد استفاده قرار می‌گیرد. با استفاده از کانتینر Sidecar، امکاناتی مانند RBAC، ممیزی، چرخش Secret‌ها و موتور Secret‌های پویا را ارائه می‌دهد. می‌توانید از Vault استفاده کنید و بدون نگرانی از امنیت، Secret‌ها را به کانتینرهای خود ارسال کنید.
• Secrets Manager ارائه شده توسط AWS:‌ سرویس AWS راه‌حلی بسیار مقرون‌به‌صرفه‌تر است، اما بسیاری از ویژگی‌های Vault، مانند تولید پویای Secret‌ها و رابط کاربری RBAC را ندارد. با این حال، می‌توانید RBAC را با استفاده از سیاست‌های IAM بومی AWS پیاده‌سازی کنید.
• قابلیت Key Vault در Azure: این سرویس مشابه Secrets Manager AWS است و Secret‌ها، گواهینامه‌های TLS، کلیدهای SSH و موارد دیگر را ایمن می‌کند. یک مزیت بزرگ شاید این باشد که می‌توانید Key Vault‌ها را در دیتاسنترهای بین‌المللی Azure ایجاد کنید تا Secret‌های خود را امن‌تر نگه دارید و کارایی آن‌ها را افزایش دهید.

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

• Helm secrets: برای مدیریت deploymentها در کوبرنتیز به‌طور گسترده استفاده می‌شود و Helm Secrets یک راه‌حل ساده برای یکپارچه‌سازی است. گرچه امنیت آن به اندازه Vault نیست، اما با داشتن مجوزهای مناسب، Helm راه‌حلی متن‌باز و قابل قبول است.
• Open-source Vault: علاوه بر نسخه پولی که قبلاً بحث شد، Vault دارای یک توزیع متن‌باز نیز هست. می‌توانید نسخه متن‌باز Vault را در خوشه‌های Kubernetes خود یا در یک ماشین مجازی بومی Deploy کنید و از آن برای ارسال Secret‌ها به کانتینرهای خود استفاده کنید. این نسخه از Vault تقریباً تمام ویژگی‌های نسخه ارتقا یافته را به غیر از پشتیبان‌گیری و بازیابی ارائه می‌دهد.

جمع‌بندی

Kubernetes Secret شیئی است که اطلاعات حساس مانند کلیدها، رمزهای عبور و توکن‌ها را در خود نگهداری می‌کند. این Secrets می‌توانند به‌صورت متغیرهای محیطی، فایل‌ها یا آرگومان‌های خط فرمان در کانتینرها استفاده شوند. با پیروی از شیوه‌های مناسب مانند کنترل دسترسی و رمزگذاری، می‌توان امنیت Secrets را افزایش داد. همچنین ابزارهای شخص ثالث و متن‌باز متعددی برای مدیریت پایدار Secrets در دسترس هستند.

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

The post Kubernetes Secrets چیست؟ – به زبان ساده appeared first on بلاگ هم‌روش.

نکات کلیدی پیرامون Traefik

• Traefik یک پروکسی معکوس پویا و لود بالانسر (متعادل‌کننده بار) به حساب می‌آید که برای معماری‌های مدرن و توزیع‌شده طراحی شده است. این ابزار در محیط‌هایی دارای عملکرد برجسته است که سرویس‌ها به طور مکرر در حال ارتقا و کاهش مقیاس هستند یا دائم دیپلوی و حذف می‌شوند، .
• Traefik امکان پیکربندی پویا، پشتیبانی از چندین بک‌اند، تعادل بار، پشتیبانی از HTTP/2 ،HTTP/3 و WebSocket ،SSL/TLS خودکار، میان‌افزارها، متریک‌ها و ردیابی و یک سیستم پلاگین را ارائه می‌دهد. این ویژگی‌ها آن را به ابزاری جامع و چندمنظوره برای مدیریت ترافیک شبکه تبدیل کرده است.
• Traefik مدیریت سرورهای وب را ساده‌سازی می‌کند، عملکرد را از طریق تعادل بار کارآمد بهبود می‌بخشد، امنیت را با SSL/TLS خودکار افزایش می‌دهد و گزینه‌های سفارشی‌سازی گسترده‌ای را فراهم می‌آورد. همچنین بینش‌های ارزشمندی برای نظارت و عیب‌یابی برنامه‌ها ارائه می‌دهد.
• در حالی که Traefik با ابزارهای دیگری مانند NGINX ،HAProxy و Envoy رقابت می‌کند، نقاط قوت منحصر به فرد آن، به ویژه در محیط‌های پویا و بومی ابری، آن را متمایز می‌سازد. بهترین ابزار بسته به نیازها و محیط خاص شما متفاوت است.
• Traefik را می‌توان در سیستم‌های مختلفی نظیر CentOS و Ubuntu نصب و پیکربندی کرد. هرچند فرایند راه‌اندازی چندین مرحله‌ای دارد، نتیجه یک ابزار قدرتمند و انعطاف‌پذیر برای مدیریت ترافیک شبکه در محیط سرور وب شما است.

Traefik چیست؟

Traefik یک Edge Router اوپن سورس است که به مدیریت پیچیدگی‌های شبکه‌ای مربوط به معماری‌های نرم‌افزاری مُدرن و توزیع‌شده می‌پردازد. Traefik اغلب به عنوان یک پروکسی معکوس و متعادل‌کننده بار شناخته می‌شود، اما قابلیت‌های آن فراتر از این عملکردها است.

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

عملکرد Traefik تنها به مسیریابی درخواست‌ها محدود نمی‌شود. این ابزار ویژگی‌های ضروری دیگری نظیر پایان‌دهی SSL/TLS، پشتیبانی از HTTP/2 ،HTTP/3 و WebSocket، کشف خودکار سرویس، تعادل بار، مدارشکن‌ها، میان‌افزارها و موارد دیگر را نیز ارائه می‌دهد. این ویژگی‌ها Traefik را به ابزاری جامع و چندمنظوره برای مدیریت ترافیک شبکه در محیط‌های مختلف وب سرور تبدیل می‌کنند.

تاریخچه مختصر و سیر توسعه Traefik

Traefik برای اولین بار در سال ۲۰۱۵ توسط یک شرکت فرانسوی به نام Containous به دنیا معرفی شد. هدف اصلی، ایجاد مسیریاب edge، پویا و بومی ابری بود که بتواند پیچیدگی‌های معماری‌های نرم‌افزاری مُدرن و توزیع‌شده را مدیریت کند. خالقان به دنبال سازوکاری بودند که برای پیکربندی آسان باشد، قابلیت کشف خدمات (Service Discovery) پویا را داشته باشد و از چندین بک‌اند پشتیبانی کند.

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

• Traefik 1.0 با نام «Camembert» در سال ۲۰۱۶: این اولین نسخه پایدار Traefik بود. پیکربندی پویا و hot-reloading را معرفی کرد، به این معنی که می‌توانست بدون نیاز به راه‌اندازی مجدد، به تغییرات در محیط واکنش نشان دهد.
• Traefik 1.7 با نام «Maroilles» در سال ۲۰۱۸: این نسخه پشتیبانی از مسیریابی TCP را معرفی کرد، افزودنی مهمی که قابلیت‌های Traefik را فراتر از HTTP گسترش داد.
• Traefik 2.0 با نام «Mont d’Or» در سال ۲۰۱۹: این یک انتشار بزرگ بود که پشتیبانی از TCP و UDP، استقرارهای canary و یک rule syntax جدید را معرفی کرد. همچنین مفهوم Middlewares را معرفی کرد، که به کاربران امکان می‌دهد خط لوله پردازش درخواست را سفارشی کنند.
• Traefik 2.2 با نام «Cantal» در سال ۲۰۲۰: این نسخه، Service Load Balancer را معرفی کرد. نوع جدیدی از خدمات است که می‌تواند بین سایر سرویس‌ها تعادل بار ایجاد کند، . همچنین پشتیبانی از Kubernetes IngressClass نیز اضافه شد.
• Traefik 2.3 با نام «Comté» در سال ۲۰۲۰: در این نسخه، Traefik Pilot، پلتفرم جدیدی برای مدیریت و بهبود نمونه‌های Traefik معرفی شد. همچنین پشتیبانی از Kubernetes Service APIs را هم اضافه کرد.
• Traefik 2.4 به نام «Morbier» در سال ۲۰۲۱: این نسخه سیستم افزونه را معرفی کرد، که به کاربران امکان می‌دهد عملکرد Traefik را با افزونه‌های سفارشی گسترش دهند.
• Traefik 3.0.0-beta3 (آخرین): این نسخه پیش‌انتشاری، دارای چندین بهبود از جمله پشتیبانی از HostSNIRegexp در مسیرهای TLS GatewayAPI، افزودن پشتیبانی از TCP Servers Transports و افزودن اولویت روتر است.

نحوه عملکرد Traefik به چه صورت است؟

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

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

Traefik همچنین رمزنگاری داده‌های کاربران را انجام می‌دهد. زمانی که کاربری به وب‌سایت ما متصل می‌شود، اتصال آن‌ها می‌تواند با استفاده از SSL/TLS رمزنگاری شود، تا اطمینان حاصل کنیم که داده‌های آن‌ها هنگام انتقال از طریق اینترنت ایمن هستند. Traefik به طور خودکار این فرآیند رمزنگاری را مدیریت می‌کند، گواهی‌های لازم را به دست می‌آورد و به موقع تجدید می‌کند. این امر اطمینان می‌دهد که وب‌سایت ما حتی با تحول فناوری‌ها و استانداردها، امن باقی می‌ماند.

ویژگی‌های کلیدی Traefik چیست؟

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

• کشف خدمات (Service Discovery): Traefik به طور خودکار خدمات جدیدی را که به معماری شما اضافه می‌شوند، شناسایی و مسیریابی می‌کند و به راحتی با سیستم‌های شناخته شده کشف خدمات، نظیر داکر، کوبرنتیز و Rancher همگام می‌شود. قابلیت پیکربندی پویا و بارگذاری سریع، ترافیک را برای استفاده در محیط‌هایی ایده‌آل می‌سازد که خدمات به طور مداوم در حال افزایش یا کاهش هستند یا به سرعت نصب و حذف می‌شوند.
• مسیریابی (Routing): Traefik از اطلاعات میزبان و مسیر درخواست‌های ورودی استفاده می‌کند تا بتواند تعیین کند که آن‌ها را باید به کجا هدایت کند. شما می‌توانید قوانین مسیریابی را در پیکربندی Traefik تعریف کنید و این قوانین می‌توانند بر اساس نیاز ساده یا پیجیده باشند. ترافیک از روش‌های تطابق (matchersهای) محتلفی برای درخواست‌ها پشتیبانی می‌کند، از جمله تطابق بر اساس مسیر، header-based، و مچرهای مبتنی بر method.
• تعادل بار (Load Balancing): Traefik تعادل بار را برای مدیریت ترافیک به خدمات شما فراهم و درخواست‌های ورودی را بین چندین نمونه از یک خدمت توزیع می‌کند. این امر به تضمین این مسئله کمک می‌کند که هیچ نمونه‌ای به نقطه انسداد تبدیل نشود و عملکرد کلی برنامه‌های شما بهبود یابد.
• میان‌افزار (Middleware): Traefik مفهوم میان‌افزار را معرفی می‌کند که به کاربران امکان می‌دهد خط لوله پردازش درخواست را سفارشی کنند. میان‌افزارها می‌توانند برای وظایفی مانند rate limiting، احراز هویت، circuit breakerها و دیگر موارد استفاده شوند.
• SSL/TLS Termination: ابزار Traefik می‌تواند SSL/TLS Termination را انجام دهد، به این معنی که می‌تواند ترافیک رمزگذاری شده را قبول کند، آن را رمزگشایی و سپس آن را به سرویس‌های ما به صورت ترافیک رمزنگاری نشده منتقل کند. این کار بار مدیریت رمزنگاری را از روی خدمات شما برمی‌دارد.
• معیارها و ردیابی (Metrics and Tracing): Traefik متریک‌هایی برای سیستم‌های مختلف مانند Prometheus و Datadog فراهم می‌کند و از ردیابی توزیع‌شده (distributed tracing) با سیستم‌هایی مانند Jaeger و Zipkin پشتیبانی می‌کند. این امر، نظارت و عیب‌یابی برنامه‌های شما را آسان‌تر می‌کند.
• پشتیبانی از چندین بک‌اند: Traefik از تنوعی از بک‌اندها از جمله Swarm ،Rancher، کوبرنتیز، داکر و بسیاری دیگر پشتیبانی می‌کند. این مسئله Traefik را به ابزاری چندمنظوره تبدیل می‌کند که می‌توان در محیط‌های مختلف از آن استفاده کرد.
• پشتیبانی از پروتکل‌ها: ترافیک از پروتکل‌های مُدرن مانند HTTP/2 ،HTTP/3 و WebSocket‌ها پشتیبانی می‌کند که به شما امکان می‌دهد در برنامه‌های خود از این فناوری‌ها استفاده کنید.
• پلاگین‌ها: از نسخه ۲.۴، Traefik یک سیستم پلاگین را معرفی کرده است که به کاربران امکان می‌دهد با پلاگین‌های سفارشی، عملکرد Traefik را گسترش دهند.

جمع‌بندی

Traefik ابزاری قدرتمند و انعطاف‌پذیر برای مدیریت ترافیک شبکه در معماری‌های مُدرن و توزیع‌شده است. این پروکسی معکوس پویا با قابلیت‌های چشمگیر خود مانند کشف خدمات پویا، پیکربندی متنوع، تعادل بار، و پشتیبانی از پروتکل‌های مُدرن، کار مدیریت و بهینه‌سازی ترافیک را بسیار آسان‌تر می‌کند. علاوه بر این، ارائه امکاناتی مانند SSL/TLS خودکار و گستره وسیعی از افزونه‌ها، Traefik را به گزینه‌ای مطلوب برای محیط‌های پویا و متغیر تبدیل کرده است. این ابزار به‌ویژه برای مدیران وب سرور و توسعه‌دهندگان که به دنبال راه‌حلی کارآمد برای چالش‌های روزمره خود هستند، بسیار مفید و کاربردی است.

The post Traefik چیست و چطور کار می‌کند؟ – شرح ویژگی‌ها، کاربردها و مزایا appeared first on بلاگ هم‌روش.

CRUD چیست؟

CRUD به ۴ عملیات پایه‌ای اشاره دارد که هر نرم‌افزاری باید قادر به انجام آن‌ها باشد و شامل «Create» (ایجاد)، «Read» (خواندن یا دریافت)، «Update» (به‌روزرسانی یا ویرایش) و «Delete» یا «Destroy» (حذف) می‌شود. در چنین برنامه‌هایی، کاربران باید بتوانند داده‌ها را ایجاد کنند، از طریق رابط کاربری به داده‌ها دسترسی داشته باشند و آن‌ها را بخوانند، داده‌ها را ویرایش یا به‌روزرسانی و در نهایت آن‌ها را حذف کنند. در برنامه‌های کامل و تمام عیار، برنامه‌های CRUD از ۳ بخش تشکیل شده‌اند:

• رابط برنامه‌نویسی (API یا سرور)
• پایگاه‌داده
• رابط کاربری (UI)

API شامل کدها و متُدهاست، پایگاه داده اطلاعات را ذخیره و به کاربر در بازیابی آن‌ها کمک می‌کند، در حالی که رابط کاربری به کاربران اجازه می‌دهد با برنامه تعامل داشته باشند. می‌توان با هر یک از زبان‌های برنامه نویسی موجود، برنامه CRUD نوشت و لازم نیست حتماً برنامه Full Stack باشد. می‌توان برنامه CRUD را صرفاً با جاوا اسکریپت در سمت کلاینت (Client-side) هم نوشت.

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

عملیات Create در CRUD چیست و چطور کار می‌کند؟

در CRUD، عملیات ایجاد یا Create همان‌طور که از نامش پیداست، یعنی ساخت و ایجاد یک ورودی یا رکورد جدید. این ورودی می‌تواند یک حساب کاربری، اطلاعات کاربر، یک پست یا یک تسک (کار) باشد. همان‌طور که قبلاً اشاره شد، پروتکل HTTP که عملیات CREATE را پیاده‌سازی می‌کند، متد POST است.

در یک پایگاه‌داده SQL، برای ایجاد، از دستور INSERT استفاده می‌شود. در پایگاه‌داده غیرِ رابطه‌ای مانند MongoDB، برای ایجاد از متدinsert() استفاده می‌شود. تصویر متحرک (GIF) زیر نشان می‌دهد که چگونه عملیات CREATE چگونه در یک رابط کاربری کار می‌کند:

همانطور که مشاهده می کنید، کاربر اطلاعات را در فیلدهای مربوطه وارد می‌کند و سپس با کلیک بر روی دکمه «Submit»، یک رکورد جدید در فهرست کارها ایجاد می‌شود. در پشت صحنه، درخواست HTTP به روش POST به سرور ارسال می‌شود تا رکورد جدید در پایگاه‌داده ذخیره شود.

عملیات READ در CRUD چیست و چطور کار می‌کند؟

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

این دسترسی می‌تواند به این معنی باشد که کاربر بلافاصله پس از ایجاد رکوردها به آن‌ها دسترسی پیدا کند، یا اینکه بتواند برای یافتن آن‌ها جستجو کند. امکان جستجو برای این منظور پیاده‌سازی می‌شود که کاربر بتواند رکوردهای مورد نیاز خود را فیلتر کند. پروتکل HTTP که عملیات READ را پیاده‌سازی می‌کند، متد GET است.

در یک پایگاه‌داده SQL، برای خواندن از دستور SELECT استفاده می‌شود. در یک پایگاه‌داده غیر رابطه‌ای مانند MongoDB، برای خواندن از متدهایfind() یاfindById() استفاده می‌کنیم. تصویر زیر نشان می‌دهد که عملیات READ در رابط کاربری چگونه کار می‌کند:

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

عملیات UPDATE در CRUD چیست و چطور کار می‌کند؟

UPDATE عملیاتی است که به ما اجازه می‌دهد داده‌های موجود را اصلاح یا ویرایش کنیم، یعنی ویرایش داده‌ها را انجام دهیم. برخلاف READ، عملیات UPDATE داده‌های موجود را با ایجاد تغییرات در آن‌ها، ویرایش می‌کند.

برای پیاده‌سازی عملیات UPDATE، می‌توانید بسته به نیاز از پروتکل‌های HTTP به نام PUT و همچنین PATCH استفاده کنید. PUT زمانی باید استفاده شود که می‌خواهید کل رکورد به‌روزرسانی شود و PATCH زمانی که نمی‌خواهید کل رکورد تغییر کند مورد استفاده قرار می‌گیرد.

در یک پایگاه داده SQL، از دستور UPDATE برای به‌روزرسانی یک رکورد استفاده می‌شود. در یک پایگاه داده غیر رابطه‌ای مانند مونگودی‌بی، می‌توانید ویژگی به‌روزرسانی را با استفاده از متدfindByIdAndUpdate() پیاده‌سازی کنید. GIF زیر نشان می‌دهد که چگونه عملیات UPDATE در رابط کاربری کار می‌کند:

همانطور که مشاهده می‌کنید، کاربر می‌تواند روی یکی از رکوردهای موجود کلیک کند تا فیلدهای آن رکورد قابل ویرایش شوند. سپس کاربر می‌تواند تغییرات مورد نظر را اعمال کند و با کلیک کردن روی دکمه «Update»، رکورد را به‌روزرسانی نماید. در پشت صحنه، یک درخواست HTTP به روش PUT یا PATCH به سرور ارسال می‌شود تا رکورد مربوطه در پایگاه داده ویرایش و به‌روزرسانی شود.

عملیات DELETE چیست و چطور کار می‌کند؟

حذف به این معنی است که یک رکورد یا ورودی را از رابط کاربری و پایگاه داده حذف کنید. DELETE پروتکل HTTP برای پیاده‌سازی عملیات حذف است. در یک پایگاه داده SQL، از دستور DELETE برای حذف رکورد استفاده می‌شود. در پایگاه داده غیر رابطه‌ای مانند مونگودی‌بی، می‌توانید عملیات حذف را با استفاده از متد findByIdAndDelete() پیاده‌سازی کنید. تصویر GIF زیر نشان می‌دهد که چگونه عملیات DELETE در رابط کاربری کار می‌کند:

همان‌طور که مشاهده می‌کنید، کاربر می‌تواند بر روی دکمه حذف در کنار هر رکورد کلیک کند تا آن رکورد از لیست حذف شود. در پشت صحنه، یک درخواست HTTP به روش DELETE به سرور ارسال می‌شود تا رکورد مورد نظر از پایگاه داده نیز حذف شود. عملیات حذف باید با احتیاط انجام شود، زیرا پس از حذف رکورد، دیگر امکان بازیابی آن وجود ندارد. معمولاً در برنامه‌های تجاری، به جای حذف کامل رکورد، یک فیلد وضعیت یا غیرفعال‌سازی برای آن در نظر گرفته می‌شود تا در صورت نیاز، بتوان آن را مجدد فعال کرد.

جمع‌بندی

این مقاله به ما نشان داد که CRUD به چه معناست و هر یک از عملیات انفرادی در یک برنامه CRUD چه کاری انجام می‌دهند. می‌توانیم در مورد CRUD به این شکل فکر کنید:

• یک حساب کاربری شبکه اجتماعی ایجاد و اطلاعات خود را وارد می‌کنیم: عملیات CREATE (ایجاد)
• به اطلاعاتی که وارد کرده‌ایم دسترسی پیدا می‌کنیم و دیگران می‌توانند ما را جستجو کنند: عملیات READ (خواندن)
• در گوگل استخدام می‌شویم و وضعیت استخدامی خود را به «شاغل» تغییر می‌دهیم: UPDATE (بروزرسانی)
• از میزان سمی بودن شبکه‌های اجتماعی خسته می‌شویم و حساب کاربری خود را حذف می‌کنیم: DELETE (حذف)

برای اینکه یاد بگیرید چگونه می‌توانید برنامه CRUD خودتان را بنویسید، می‌توانید از این آموزش [+] استفاده کنید.

پس در این مقاله با مفهوم CRUD آشنا شدیم که شامل چهار عملیات اصلی ایجاد (Create)، خواندن (Read)، ویرایش (Update) و حذف (Delete) در دنیای برنامه‌نویسی و ذخیره‌سازی داده‌ها است. هر یک از این عملیات با یک متُد درخواست HTTP مرتبط است و در برنامه‌های کاربردی مُدرن برای مدیریت داده‌ها و تعامل با پایگاه‌های داده استفاده می‌شوند. همچنین مشاهده کردیم که چگونه هر عملیات در رابط کاربری و پایگاه داده پیاده‌سازی می‌شود.

The post CRUD چیست؟ – آموزش عملیات CRUD appeared first on بلاگ هم‌روش.

Event Driven Architecture چیست؟

معماری Event-driven یا به اختصار EDA الگوی طراحی نرم‌افزار است که به سازمان‌ها اجازه می‌دهد «رویدادها» (Event) یا لحظات مهم در کسب‌وکارها (مثل تراکنش، بازدید سایت، ترک سبد خرید و غیره) را تشخیص داده و به آن‌ها در زمان واقعی یا نزدیک به زمان واقعی واکنش نشان دهند. این الگو جایگزین معماری سُنتی «درخواست/پاسخ» (request/response) می‌شود که در آن سرویس‌ها باید منتظر پاسخ می‌ماندند تا به کار بعدی بروند. جریان معماری Event-driven توسط eventها هدایت می‌شود و به گونه‌ای طراحی شده که به آن‌ها پاسخ داده یا عملی را در پاسخ به یک event انجام دهد.

معماری Event-driven اغلب به‌عنوان ارتباط «asynchronous» یا «غیرهم‌زمان» شناخته می‌شود. یعنی فرستنده و گیرنده لازم نیست برای انجام کار بعدی منتظر یکدیگر بمانند و سیستم‌ها به یک پیام وابسته نیستند. مثلاً تماس تلفنی ارتباط «هم‌زمان» محسوب می‌شود، مثل معماری سنتیِ «درخواست/پاسخ»، که در آن درخواست‌دهنده منتظر پاسخ می‌ماند. یک مثال غیرهم‌زمان، پیامک است. شما پیامک می‌فرستید و ممکن است ندانید که گیرنده کیست یا آیا کسی پیام را می‌خواند، اما منتظر پاسخ نمی‌مانید.

سیر تکامل معماری Event Driven و مقایسه آن با معماری داده‌محور

در چند سال گذشته، تمرکز از داده‌های ثابت (Service Oriented Architecture) به سمت رویدادها (Event-driven Architecture) تغییر کرده است. به‌جای انباشتن داده‌ها و ایجاد Data Lake، اکنون به داده‌های در جریان و ردیابی آن‌ها در حرکت توجه می‌شود. سیستم‌های سنتی عمدتاً در یک مدل داده‌محور کار می‌کردند که داده‌ها منبع اصلی حقیقت بودند. تغییر به سمت معماری Event-driven به معنای حرکت از مدل داده‌محور به مدل رویدادمحور است.

در مدل رویدادمحور، داده‌ها همچنان مهم هستند، اما eventها به مهم‌ترین بخش تبدیل می‌شوند. در مدل سرویس‌محور، اولویت اصلی حفظ داده‌ها بود، اما در معماری Event-driven، اولویت اصلی پاسخ به رویدادها به‌صورت همزمان است؛ زیرا ارزش رویدادها با گذشت زمان کاهش پیدا می‌کند. با این حال، امروزه معماری سرویس‌محور و معماری رویدادمحور اغلب به همراه هم استفاده می‌شوند.

استفاده از log و مخزن اطلاعات در Event Driven Architecture

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

Event Producerها در معماری رویدادمحور

در معماری Event-driven، تولیدکننده‌های رویداد را داریم که نوتیفیکیشن‌های event را ایجاد و ارسال می‌کنند و ممکن است یک یا چند مصرف‌کننده event هم وجود داشته باشد که در آنجا دریافت event باعث اجرای منطق پردازش (Processing Logic) می‌شود.

مثلاً فرض کنید نتفلیکس فیلم جدیدی را آپلود کرده است. چندین اپلیکیشن می‌توانند منتظر این نوتیفیکیشن باشند و سپس سیستم‌های داخلی خود را فعال کنند تا اطلاعات مربوط به آن event را به کاربرانشان بفرستند. این روش با پیام‌رسانی درخواست-پاسخ سنتی متفاوت است؛ در اینجا اپلیکیشن‌ها در حال اجرا هستند و حتی اگر منتظر این رویداد باشند، معطل نمی‌مانند و می‌توانند به محض دریافت پیام، پاسخ دهند. به این ترتیب، بسیاری از سرویس‌ها می‌توانند به‌صورت همزمان اجرا شوند.

مفهوم Event در Event Driven Architecture چیست؟

رویداد یا همان Event به تغییر وضعیت یک سیستم کلیدی کسب‌وکار گفته می‌شود. مثلاً، شخصی محصولی می‌خرد، فردی برای پرواز چک‌این می‌کند یا اتوبوسی دیر به مقصد می‌رسد. اگر دقت کنیم، Eventها در همه جا و در هر صنعتی رخ می‌دهند. هر چیزی که یک «پیام» ایجاد کند، از تولید و انتشار گرفته تا شناسایی و مصرف، به‌عنوان رویداد شناخته می‌شود. رویداد از پیام جداست، چون Event وقوع یک تغییر است و پیام، اعلان (نوتیفیکیشن) در حال حرکتِ این وقوع را انتقال می‌دهد. در معماری Event-driven، رویداد ممکن است یک یا چند عمل یا فرآیند را در پاسخ به وقوع خود تحریک (Trigger) کند. نمونه‌هایی از رویدادها شامل موارد زیر هستند:

• درخواست برای بازنشانی رمز عبور
• تحویل بسته به مقصد
• به‌روزرسانی موجودی یک انبار مواد غذایی
• رد تلاش برای دسترسی غیرمجاز

هر یک از این رویدادها ممکن است یک یا چند عمل یا فرآیند را در پاسخ، Trigger کنند. یکی از پاسخ‌ها ممکن است به سادگیِ ثبت Event برای اهداف نظارتی باشد. پاسخ‌های دیگر می‌توانند شامل موارد زیر باشند:

• ارسال ایمیل برای بازنشانی رمز عبور به مشتری
• بسته شدن فروش بلیط
• ثبت سفارش جدید برای کالاهای در حال اتمام مانند کاهو
• قفل شدن حساب و اطلاع‌رسانی به پرسنل امنیتی

در معماری Event-driven، زمانی که نوتیفیکیشن رویداد ارسال می‌شود، سیستم ثبت می‌کند که تغییری رخ داده است و منتظر می‌ماند تا پاسخ را به هر فردی که درخواست کرده، هر زمان که درخواست کند، ارسال کند. اپلیکیشنی که آن پیام را دریافت کرده می‌تواند بلافاصله پاسخ دهد یا تا زمانی که تغییر وضعیت مورد انتظار رخ دهد، منتظر بماند.

اپلیکیشن‌های مبتنی بر معماری Event-driven امکان ایجاد کسب‌وکارهای دیجیتال سریع‌تر، مقیاس‌پذیرتر، با زمینه بهتر و پاسخگوتر را فراهم می‌کنند.

نحوه عملکرد معماری Event Driven چگونه است؟

اجزای معماری رویدادمحور شامل ۳ بخش «تولیدکننده» (Producer)، «مصرف‌کننده» (Consumer) و «واسطه» (Broker) است. واسطه ممکن است اختیاری باشد، به‌خصوص زمانی که تولیدکننده و مصرف‌کننده مستقیماً با هم در ارتباط هستند و تولیدکننده eventها را به مصرف‌کننده می‌فرستد. به عنوان مثال، تولیدکننده می‌تواند رویدادها را فقط به یک پایگاه داده یا انبار داده ارسال کند تا رویدادها برای تحلیل جمع‌آوری و ذخیره شوند. معمولاً در شرکت‌ها، منابع متعددی وجود دارند که انواع مختلف رویدادها را ارسال می‌کنند و یک یا چند مصرف‌کننده به برخی یا همه آن رویدادها علاقه‌مند هستند.

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

جمع‌بندی

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

The post معماری رویدادمحور Event-Driven Architecture چیست؟ appeared first on بلاگ هم‌روش.

انواع هزینه کوبرنتیز کدامند؟

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

هزینه‌های مربوط به پردازش یا محاسبات در کوبرنتیز

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

هزینه‌های کوبرنتیز مربوط به شبکه

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

هزینه ذخیره‌سازی در کوبرنتیز

هزینه‌های ذخیره‌سازی زمانی مطرح می‌شوند که شما از حجم‌های پایدار در کلاستر کوبرنتیز خود استفاده می‌کنید. حجم‌های پایدار برای ذخیره داده‌هایی (مثل فایل‌های پایگاه داده) استفاده می‌شوند که باید پس از ری‌استارت شدن podها حفظ شوند. هزینه این حجم‌ها به اندازه آن‌ها و نوع ذخیره‌سازی که استفاده می‌کنید بستگی دارد.

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

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

• تخصیص بیش از حد منابع: اگر nodeهای بیشتر از حد نیاز اجرا می‌کنید یا اگر nodeهای شما بزرگتر از حد نیاز هستند، برای ظرفیت استفاده نشده هزینه پرداخت می‌کنید. این یکی از رایج‌ترین منابع هزینه‌های غیرضروری در کوبرنتیز است.
• شبکه‌‌بندی ناکارآمد: اگر سرویس‌های شما طوری طراحی نشده‌اند که انتقال داده را به حداقل برسانند، ممکن است هزینه‌های شبکه بالایی داشته باشید. این مسئله به‌خصوص زمانی صادق است که داده‌ها را بین regionهای مختلف منتقل می‌کنید، یا سرویس‌های شما پرگفتگو هستند و داده‌های زیادی را مبادله می‌کنند.
• volumeهای پایدار استفاده نشده: volumeهای پایداری که تخصیص داده شده‌اند اما استفاده نمی‌شوند همچنان هزینه دارند. مهم است که به‌طور منظم volumeهای استفاده نشده را بررسی و پاک‌سازی کنید تا از پرداخت هزینه کوبرنتیز برای ذخیره‌سازی که نیاز ندارید جلوگیری شود.

استراتژی‌های کلیدی برای کاهش هزینه‌های کوبرنتیز

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

• نظارت بر هزینه کوبرنتیز برای کاهش آن: ایجاد یک سیستم قوی برای نظارت بر هزینه‌ها ضروری است. این استراتژی شامل پیگیری مخارج کوبرنتیز برای شناسایی ترندها و مواردی است که می‌توان هزینه‌ها را در آن‌ها بهینه کرد.
• محدودیت‌های منابع: اعمال محدودیت‌های منابع برای کنترل و کاهیش هزینه کوبرنتیز ضروری است. با تعیین حد بالا برای استفاده از منابع، از مصرف بیش از حد منابع توسط هر برنامه یا سرویس جلوگیری می‌کنید و در نتیجه هزینه‌های کلی را بهینه می‌کنید.
• مقیاس‌پذیری خودکار: ترکیب Auto-Scaling افقی و عمودی، تخصیص منابع را با استفاده واقعی هماهنگ می‌کند و اطمینان می‌دهد که فقط برای آنچه نیاز دارید هزینه می‌کنید. این استراتژی برای سازگاری با شرایط بار (load) متغیر بدون تخصیص بیش از حد منابع ضروری است.
• استفاده از منابع تخفیف‌دار برای کاهش هزینه کوبرنتیز: استفاده از ریسورس‌های تخفیف‌دار ارائه‌دهندگان ابری، مانند نمونه‌های موقتی یا رزرو شده، می‌تواند هزینه‌ها را به طور قابل توجهی کاهش دهد. این گزینه‌ها به ویژه برای بارهای کاری انعطاف‌پذیر یا کم‌تر حساس به زمان ارزشمند هستند.
• حالت خواب (Sleep Mode): برای محیط‌های غیر تولیدی (non-production)، اجرای حالت‌های خواب در ساعات کم مصرف می‌تواند هزینه‌ها را به شدت کاهش دهد.
• استراتژی‌های پاکسازی: maintenance منظم برای حذف منابع قدیمی یا استفاده نشده، از جمله بارهای کاری، تصاویر و گزارش‌ها، از هزینه‌های بیهوده جلوگیری می‌کند.
• اشتراک‌گذاری کلاستر و Multi-Tenancy: با ادغام بارهای کاری در خوشه‌های کمتر و استفاده از Multi-Tenancy (چند-مستأجری) می‌توانید هزینه‌های سربار و مدیریت را کاهش دهید. این رویکرد باید جداسازی مناسب بین مستأجران را برای جلوگیری از مسائل امنیتی و عملکردی تضمین کند.

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

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

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

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

• نظارت جامع بر هزینه‌ها: از ابزارهایی مانند پرومتئوس (Prometheus) و Kubecost برای دریافت اطلاعات مالی دقیق استفاده کنید. بررسی منظم این معیارها امکان تنظیم به موقع استراتژی‌های شما را فراهم می‌کند.
• اعمال محدودیت‌ها و درخواست‌ها برای منابع: با استفاده از قابلیت‌های داخلی کوبرنتیز، درخواست‌ها و محدودیت‌های دقیق منابع را برای هر pod تعیین کنید. این کار به استفاده کارآمد از منابع و جلوگیری از هزینه‌های اضافی کمک می‌کند.
• استفاده هوشمندانه از مقیاس‌پذیری خودکار (Autoscaling): از «مقیاس‌دهنده افقی پاد و مقیاس‌دهنده عمودی پاد کوبرنتیز» (Horizontal Pod Autoscaler and Vertical Pod Autoscaler) استفاده کنید تا منابع به‌صورت پویا بر اساس نیاز واقعی تنظیم شوند و کارایی هزینه تضمین شود.
• بهینه‌سازی با استفاده از منابع ابری تخفیف‌دار: از تخفیف‌های ارائه‌دهندگان ابری مانند نمونه‌های اسپات AWS برای کارهای قابل وقفه، یا نمونه‌های رزرو شده Azure برای کارهای قابل پیش‌بینی استفاده کنید تا در هزینه‌ها صرفه‌جویی شود.
• اجرای روش‌های کارآمد مدیریت منابع: پاکسازی منظم منابع را انجام دهید، حالت خواب (Sleep Mode) را برای محیط‌های بیکار (Idle) پیاده‌سازی کنید و از فضاهای نام (Namespace) برای جداسازی و مدیریت موثر منابع استفاده کنید.
• استفاده از روش‌های اشتراک‌گذاری خوشه و چند مستاجری: از ابزارهایی مانند فضاهای نام کوبرنتیز و خوشه‌های مجازی (Virtual Cluster) استفاده کنید و استفاده از پلتفرم‌هایی را در نظر بگیرید که استقرار و مدیریت برنامه‌ها روی کوبرنتیز را ساده می‌کنند. این پلتفرم‌ها می‌توانند به ساده‌سازی اشتراک‌گذاری خوشه و چند مستاجری کمک کنند و مدیریت منابع را آسان‌تر کرده و احتمالاً هزینه‌ها را کاهش دهند.
• استفاده از زمانبندی و تخصیص منابع پیشرفته: از ویژگی‌های زمانبندی کوبرنتیز و ابزارهایی مانند Descheduler یا Kube-batch برای مدیریت و بهینه‌سازی بهتر منابع استفاده کنید.

جمع‌بندی

بهینه‌سازی و کاهش هزینه‌های کوبرنتیز برای افزایش کارایی و اثربخشی زیرساخت ابری شما ضروری است. نکات کلیدی این مقاله شامل اهمیت نظارت بر هزینه‌ها با استفاده از ابزارهایی مانند پرومتئوس و Kubecost، اعمال محدودیت‌های منابع و استفاده از Auto-Scaling برای تطبیق استفاده از منابع با نیازهای واقعی است.

علاوه بر این، استفاده از راهکارهای مدیریت کانتینر، بهینه‌سازی هزینه را با ارائه ویژگی‌هایی مانند اشتراک‌گذاری منابع، خاموش کردن محیط‌های غیرفعال و استفاده از نمونه‌های مقرون‌به‌صرفه ARM بهبود می‌بخشد. با به‌کارگیری این استراتژی‌ها و بهترین روش‌ها، سازمان‌ها می‌توانند اطمینان حاصل کنند که فقط برای منابع مورد نیاز خود هزینه می‌کنند و بدین ترتیب هزینه‌های کلی را کاهش داده و کارایی عملیاتی را افزایش می‌دهند.

The post ترفندهایی برای کاهش هزینه‌ها در کوبرنتیز appeared first on بلاگ هم‌روش.

مقدمه

استفاده از سیستم‌های کنترل نسخه مانند گیت (Git)، برای پیاده‌سازی بهترین روش‌های توسعه نرم‌افزارهای مُدرن ضروری است. نسخه‌بندی (Versioning) به ما اجازه می‌دهد تا وضعیت نرم‌افزار خود را در سطح سورس ره‌گیری و پیگیری کنیم.

می‌توانیم تغییرات را دنبال کنیم، به مراحل قبلی برگردیم و شاخه‌های (Branch) جدیدی را برای ایجاد نسخه‌های مختلف از فایل‌ها و پوشه‌ها بسازیم. فایل‌های بسیاری از پروژه‌های نرم‌افزاری در مخازن گیت نگهداری می‌شوند و پلتفرم‌هایی مانند گیت‌هاب، گیت‌لب و بیت‌باکت به اشتراک‌گذاری و همکاری در پروژه‌های توسعه نرم‌افزار کمک می‌کنند.

پیش‌نیازهای نصب گیت در اوبونتو

برای نصب گیت در اوبونتو ما به سرور اوبونتو با حساب کاربری غیرِ روت (non-root) نیاز داریم که دسترسی سوپریوزر دارد. برای راه‌اندازی این مورد، می‌توان از یک راهنمای تنظیمات اولیه سرور لینوکس اوبونتو استفاده کرد.

نصب گیت در اوبونتو با پکیج‌های پیش‌فرض

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

git --version

اگر خروجی مشابه زیر دریافت کردیم، یعنی گیت از قبل نصب شده است:

Output
git version 2.25.1

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

sudo apt update

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

sudo apt install git

می‌توانیم با اجرای دستور زیر و بررسی خروجی مربوطه، از نصب صحیح گیت اطمینان حاصل کنیم:

git --version

خروجی:

Output
git version 2.45.2

حالا که گیت با موفقیت نصب شده، می‌توانیم به بخش «تنظیمات گیت» در این آموزش مراجعه کنیم تا تنظیمات لازم را انجام بدهیم.

آموزش نصب گیت روی اوبونتو از طریق سورس

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

git --version

اگر گیت نصب شده باشد، خروجی مشابه زیر را دریافت خواهید کرد:

Output
git version 2.25.1

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

sudo apt update
sudo apt install libz-dev libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext cmake gcc

پس از نصب وابستگی‌های لازم، پوشه‌ای موقت ایجاد کرده و وارد آن شوید. اینجا جایی است که فایل فشرده گیت یا به اصطلاح «tarball» گیت را دانلود خواهیم کرد:

mkdir tmp
cd /tmp

از وب‌سایت پروژه گیت [+]، می‌توانیم به صفحه فهرست فایل‌های فشرده موجود در [+] برویم و نسخه مورد نظرمان را دانلود کنیم. در زمان نگارش این متن، آخرین نسخه ۲.۹.۵ است، پس ما آن را برای نمایش دانلود می‌کنیم. از curl استفاده می‌کنیم و فایل دانلود شده را git.tar.gz می‌نامیم:

curl -o git.tar.gz https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.26.2.tar.gz

فایل را از حالت فشرده خارج می‌کنیم:

tar -zxf git.tar.gz

سپس وارد پوشه جدید گیت می‌شویم:

cd git-*

حالا می‌توانیم پکیج را بسازیم و با تایپ این ۲ دستور آن را نصب کنیم:

make prefix=/usr/local all
sudo make prefix=/usr/local install

اکنون، پراسس shell را جایگزین می‌کنیم تا نسخه گیتی که همین الان نصب کردیم استفاده شود:

exec bash

با تکمیل این مراحل، می‌توانیم با بررسی نسخه، از موفقیت نصب گیت در اوبونتو مطمئن شویم:

git --version

خروجی:

Output
git version 2.26.2

حالا که گیت با موفقیت نصب شده، می‌توانیم تنظیمات مورد نیاز را هم انجام بدهیم.

به‌روزرسانی گیت در اوبونتو

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

sudo apt update

حالا گیت را به‌روزرسانی کنید:

sudo apt install git

در نهایت، بررسی کنید که آخرین نسخه پایدار گیت را نصب دارید:

git --version

تنظیمات گیت پس از نصب در اوبونتو

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

پیکربندی را می‌توان با استفاده از دستور git config انجام داد. به‌طور خاص، ما باید نام و آدرس ایمیل خود را ارائه دهیم، زیرا گیت این اطلاعات را در هر کامیتی که انجام می‌دهیم، جاسازی می‌کند. می‌توانیم این اطلاعات را با وارد کردن دستورات زیر اضافه کنیم:

git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"

می‌توانیم تمام موارد کانفیگ که تنظیم شده‌اند را با تایپ دستور زیر نمایش دهیم:

git config --list

خروجی:

Output
user.name=Your Name
user.email=youremail@domain.com
...

اطلاعاتی که وارد می‌کنیم در فایل پیکربندی گیت ذخیره می‌شود، که می‌توانیم به صورت اختیاری آن را با یک ویرایشگر متن به انتخاب خودمان ویرایش کنیم (ما از نانو استفاده می‌کنیم):

nano ~/.gitconfig

محتوای فایل کانفیگ:

[user]
  name = Your Name
  email = youremail@domain.com

برای خروج از ویرایشگر متن، CTRL و X، سپس Y و در نهایت ENTER را می‌زنیم. گزینه‌های بسیار زیاد دیگری هم وجود دارد که می‌توانیم تنظیم کنیم، اما این ۲ مورد، ضروری‌ترین مواردی هستند که نیاز داریم. اگر این مرحله را نادیده بگیرید، احتمالاً هنگام کامیت در گیت هشدارهایی خواهید دید. این باعث می‌شود کار بیشتری برای شما ایجاد شود، زیرا سپس باید کامیت‌هایی را که انجام داده‌اید با اطلاعات صحیح اصلاح کنید.

جمع‌بندی

در این مقاله روش‌های مختلف پیکربندی و نصب گیت در اوبونتو سرور را بررسی کردیم و یاد گرفتیم. ۲ روش اصلی نصب شامل استفاده از مدیر بسته داخلی (apt) و نصب از طریق کد منبع (سورس) بود. پس از نصب، بر اهمیت به‌روزرسانی گیت و انجام تنظیمات اولیه مانند تعیین نام و ایمیل کاربر تأکید شد. این مراحل برای استفاده صحیح و کارآمد از گیت در پروژه‌های نرم‌افزاری ضروری هستند و به توسعه‌دهندگان کمک می‌کنند تا از مزایای کامل این سیستم کنترل نسخه بهره‌مند شوند.

The post نصب گیت در اوبونتو – راهنمای سریع و جامع appeared first on بلاگ هم‌روش.

Argo CD چیست‌؟

«آرگو سی‌دی» (Argo CD) ابزار «استقرار مداوم» (Continues Integration | CD) محسوب می‌شود که به‌طور ویژه برای کوبرنتیز طراحی شده است. برخلاف ابزارهای استقرار مداوم خارجی که تنها از روش‌های استقرار مبتنی بر فشار (Push-Based) استفاده می‌کنند، Argo CD می‌تواند کدهای به‌روزشده را مستقیماً از مخازن گیت (Git) دریافت کرده و آن‌ها را روی منابع کوبرنتیز مستقر کند. این ویژگی به توسعه‌دهندگان امکان می‌دهد تا هم پیکربندی زیرساخت و هم به‌روزرسانی‌های نرم‌افزار را در یک سیستم واحد مدیریت کنند. Argo CD ویژگی‌ها و قابلیت‌های کلیدی زیر را ارائه می‌دهد:

• استقرار دستی یا خودکار برنامه‌ها روی خوشهٔ کوبرنتیز
• همگام‌سازی خودکار وضعیت برنامه با آخرین نسخهٔ پیکربندی اعلامی
• رابط کاربری تحت وب و رابط خط فرمان (CLI)
• توانایی نمایش مشکلات استقرار، تشخیص و رفع ناهماهنگی‌های پیکربندی
• کنترل دسترسی مبتنی بر نقش (RBAC) که امکان مدیریت چند خوشه را فراهم می‌کند.
• ورود یکپارچه (SSO) با ارائه‌دهندگانی مانند گیت‌لب، گیت‌هاب، مایکروسافت، OAuth2 ،OIDC، لینکدین، LDAP و SAML 2.0
• پشتیبانی از وب‌هوک‌ها برای راه‌اندازی اقدامات در گیت‌لب، گیت‌هاب و بیت‌باکت.

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

گیت‌آپس با Argo CD چیست؟

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

یکی از بخش‌های اساسی فرآیند گیت‌آپس، درخواست ادغام (Pull Request) است. نسخه‌های جدید پیکربندی از طریق درخواست ادغام معرفی می‌شوند، با شاخهٔ اصلی در مخزن گیت ترکیب می‌شوند و سپس نسخهٔ جدید به‌طور خودکار مستقر می‌شود. مخزن گیت شامل سابقهٔ کاملی از تمام تغییرات، از جمله تمام جزئیات محیط در هر مرحله از فرآیند است.

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

• یک توسعه‌دهنده تغییراتی در برنامه ایجاد می‌کند و نسخهٔ جدیدی از تعاریف منابع کوبرنتیز را به مخزن گیت ارسال می‌کند.
• یکپارچه‌سازی مداوم (Continuous Integration | CI) فعال می‌شود که منجر به ذخیرهٔ تصویر کانتینر جدید در یک مخزن می‌گردد.
• توسعه‌دهنده درخواست ادغام (Pull Request) را صادر می‌کند که شامل تغییرات در مانیفست‌های کوبرنتیز است. این مانیفست‌ها می‌توانند به صورت دستی یا خودکار ایجاد شده باشند.
• درخواست ادغام بررسی شده و تغییرات با شاخهٔ اصلی ترکیب می‌شوند. این عمل یک وب‌هوک را فعال می‌کند که به Argo CD اطلاع می‌دهد تغییری ایجاد شده است.
• آرگو سی‌دی مخزن را کلون و وضعیت برنامه را با وضعیت فعلی خوشهٔ کوبرنتیز مقایسه می‌کند. سپس تغییرات لازم را در پیکربندی خوشه اعمال می‌کند.
• کوبرنتیز از کنترلِرهای خود استفاده می‌کند تا تغییرات مورد نیاز در منابع خوشه را اعمال کند، تا زمانی که به پیکربندی مطلوب برسد.
• Argo CD پیشرفت کار را نظارت می‌کند و زمانی که خوشهٔ کوبرنتیز آماده شد، گزارش می‌دهد که برنامه همگام شده است.
• آرگو سی‌دی همچنین در جهت مخالف نیز کار می‌کند، یعنی تغییرات در خوشهٔ کوبرنتیز را نظارت می‌کند و اگر با پیکربندی فعلی در گیت مطابقت نداشته باشند، آن‌ها را نادیده می‌گیرد.

Argo CD چطور به تسهیل گیت‌آپس با کوبرنتیز کمک می‌کند؟

• عامل گیت‌آپس (GitOps Agent): Argo CD مسئول دریافت کدهای به‌روزشده از مخازن گیت و استقرار مستقیم آن‌ها روی منابع کوبرنتیز است. این ابزار هم پیکربندی زیرساخت و هم به‌روزرسانی‌های برنامه را در سیستمی واحد مدیریت می‌کند.
• تعاریف منابع سفارشی (CRD | Custom Resource Definitions): آرگو سی‌دی در فضای نام اختصاصی خود درون خوشهٔ کوبرنتیز فعالیت می‌کند. این ابزار CRDهای خاص خود را ارائه می‌دهد که API کوبرنتیز را گسترش داده و امکان تعریف وضعیت مطلوب برنامه را به شکلی اعلامی (Declarative) فراهم می‌کند. Argo CD بر اساس دستورالعمل‌های موجود در مخزن گیت یا مخزن Helm، از CRDهای خود برای اعمال تغییرات در فضای نام اختصاصی‌اش استفاده می‌کند.
• رابط خط فرمان (CLI): آرگو سی‌دی CLI قدرتمندی ارائه می‌دهد که شما را قادر می‌سازد با چند دستور ساده، تعاریف منابع YAML را ایجاد کنید. برای مثال، دستور Argo CD app create به شما اجازه می‌دهد با مشخص کردن چند پرچم، یک شیء Application معتبر ایجاد کنید که برنامهٔ شما را بدون نیاز به نوشتن دستی YAML توصیف می‌کند.
• رابط کاربری: Argo CD در این زمینه منحصر به فرد است که یک رابط کاربری تحت وب راحت ارائه می‌دهد که به شما امکان می‌دهد همان کار را انجام دهید، یعنی برنامه را تعریف کنید و از آرگو سی‌دی بخواهید پیکربندی‌های YAML مربوطه را ایجاد کند. همچنین به شما امکان می‌دهد پیکربندی کوبرنتیز حاصل را از نظر پادها و کانتینرها مشاهده کنید. اگرچه برخی ممکن است فکر کنند استفاده از رابط کاربری «گیت‌اپس واقعی» نیست، این درست نیست، زیرا رابط کاربری برای کنترل مستقیم خوشه استفاده نمی‌شود، بلکه فقط راهی آسان‌تر برای ایجاد پیکربندی اعلامی است.
• چند مستأجری (Multi-tenancy): آرگو سی‌دی از همکاری چندین تیم روی پروژه‌های مختلف در یک محیط کوبرنتیز به خوبی پشتیبانی می‌کند. CRDهای Argo CD می‌توانند محدود شوند تا فقط مخازن منبع متعلق به یک پروژهٔ خاص را بخوانند و می‌توانند طوری تنظیم شوند که برنامه‌ها را در خوشه و فضای نام خاصی مستقر کنند. هر نمونه CRD همچنین می‌تواند تنظیمات کنترل دسترسی مبتنی بر نقش (RBAC) خاص خود را داشته باشد.
• بهره‌گیری از ابزارهای موجود: بسیاری از سازمان‌ها قبلاً در پیکربندی‌های اعلامی مبتنی بر YAML، چارت‌های Helm ،Kustomize یا سایر سیستم‌ها سرمایه‌گذاری کرده‌اند. Argo CD هدفش استفاده از این سرمایه‌گذاری‌های موجود است، نه جایگزینی آن‌ها. این ابزار می‌تواند از هر یک از این فرمت‌ها برای ایجاد خودکار تعاریف CRD مربوطه استفاده کند.

Argo CD چطور کار می‌کند؟

هنگام استفاده از Argo CD، می‌توانید پیکربندی برنامه را با استفاده از چندین نوع مانیفست کوبرنتیز مشخص کنید، از جمله:

• مانیفست‌های ساده YAML یا JSON
• چارت‌های Helm
• Kustomize
• برنامه‌های Ksonnet و Jsonnet

همچنین امکان استفاده از هر ابزار مدیریت پیکربندی سفارشی به‌عنوان یک افزونه نیز وجود دارد. Argo CD به‌طور خودکار وضعیت مطلوب یک برنامه را در محیط هدفِ مشخص‌شده مستقر می‌کند. به‌روزرسانی‌ها از طریق برچسب‌ها (Tags)، شاخه‌ها (Branches)، یا نسخه‌های خاص ثابت‌شده (Pinned Specific Versions) یک مانیفست در کامیت‌های گیت قابل ردیابی هستند.

آرگو سی‌دی یک کنترلر کوبرنتیز است که وظیفهٔ نظارت مداوم بر تمام برنامه‌های در حال اجرا را بر عهده دارد. این ابزار، وضعیت فعلی برنامه‌ها را با وضعیت مطلوبی که در مخزن گیت تعریف شده، مقایسه می‌کند. اگر وضعیت فعلی یک برنامهٔ مستقر شده با وضعیت مطلوب آن تفاوت داشته باشد، Argo CD آن را به عنوان «ناهمگام» (OutOfSync) شناسایی می‌کند.

آرگو سی‌دی این تفاوت‌ها را گزارش می‌دهد و با ارائهٔ نمایش‌های بصری، به توسعه‌دهندگان کمک می‌کند تا وضعیت فعلی را به صورت دستی یا خودکار با وضعیت مطلوب هماهنگ کنند. این ابزار قادر است هر تغییری که در وضعیت مطلوب (در مخزن گیت) ایجاد شود را به طور خودکار در محیط هدف اعمال کند. این قابلیت تضمین می‌کند که برنامه‌ها همواره در حالت همگام باقی بمانند.

اجزای اساسی Argo CD چیست؟

در ادامه هر یک از اجزای اساسی Argo CD را معرفی می‌کنیم و آن‌ها را شرح می‌دهیم.

API در Argo CD چیست؟

این سرویس، یک سرور API از نوع gRPC/REST است که رابط برنامه‌نویسی را برای اجزایی مانند رابط خط فرمان و رابط کاربری وب فراهم می‌کند. وظایف اصلی این سرویس عبارتند از:

• مدیریت برنامه‌ها و گزارش وضعیت آن‌ها
• اجرای عملیات‌های برنامه مانند اقدامات تعیین‌شده توسط کاربر، همگام‌سازی و بازگشت به نسخه‌های قبلی
• مدیریت اعتبارنامه‌های خوشه و مخزن که به صورت اسرار کوبرنتیز ذخیره می‌شوند
• احراز هویت و واگذاری مجوز به ارائه‌دهندگان هویت شخص ثالث
• اعمال سیاست‌های کنترل دسترسی مبتنی بر نقش (RBAC)
• دریافت و ارسال رویدادهای وب‌هوک گیت

سرویس مخزن در Argo CD

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

کنترلر برنامه

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

جمع‌بندی

آرگو سی‌دی (Argo CD) یک ابزار قدرتمند استقرار مداوم برای کوبرنتیز است که با استفاده از رویکرد گیت‌آپس، فرآیند مدیریت و استقرار برنامه‌ها را بهبود می‌بخشد. این ابزار با ارائه ویژگی‌هایی مانند همگام‌سازی خودکار، رابط کاربری تحت وب، کنترل دسترسی مبتنی بر نقش و پشتیبانی از انواع مختلف مانیفست‌ها، به توسعه‌دهندگان امکان می‌دهد تا پیکربندی زیرساخت و به‌روزرسانی‌های نرم‌افزار را در یک سیستم واحد مدیریت کنند.

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

The post Argo CD چیست‌؟ – تسهیل گیت‌آپس با کوبرنتیز appeared first on بلاگ هم‌روش.

کانتینر Container چیست؟

در یک کلام کانتینرها، روشی استاندارد برای بسته‌بندی (پکیج کردن) برنامه‌ها و همه وابستگی‌های (Dependency) آن‌ها هستند تا بتوانید برنامه‌ها را بدون مشکل بین محیط‌های Runtime منتقل کنید. با بسته‌بندی کُدهای برنامه، وابستگی‌ها و پیکربندی‌ها (Configuration) در یک بلوک ساختاری که به سادگی قابل استفاده است، کانتینرها به شما کمک می‌کنند گام‌های مهمی برای کاهش زمان استقرار و بهبود قابلیت اطمینان برنامه بردارید.

در برنامه‌های سازمانی، تعداد کانتینرها می‌تواند به سرعت به حدی غیرقابل مدیریت برسد. برای استفاده موثرتر از کانتینرهای خود، نیاز داریم برنامه‌های کانتینری خود را هماهنگ‌سازی (Orchestrate) کنیم و این جاست که Kubernetes و Docker Swarm مورد استفاده قرار می‌گیرند و بحث استفاده از آن‌ها مطرح می‌شود.

کوبرنتیز Kubernetes چیست؟

کوبرنتیز پلتفرمی سیار و متن‌باز برای مدیریت کانتینرها، بارهای کاری پیچیده در تولید و مدیریت انطباق‌پذیری کانتینرها است. با Kubernetes، توسعه‌دهندگان و تیم‌های دواپس می‌توانند برنامه‌های با دسترسی بالا را با استفاده از انعطاف‌پذیری کلاسترها، برنامه‌ریزی، مستقر، مدیریت و کشف کنند. یک کلاستر کوبرنتیز متشکل از میزبان‌های محاسباتی به نام «Worker Node» (گره‌های کارگزار) است. این Worker Nodeها توسط یک Master کوبرنتیز مدیریت می‌شوند که همه منابع در خوشه را کنترل و پایش می‌کند. یک Node می‌تواند ماشین مجازی (VM) یا ماشین فیزیکی باشد.

در ابتدای ظهور کوبرنتیز، اعضای کامیونیتی برای بهره‌برداری از کوبرنتیز از دانش خود در ایجاد و اجرای ابزارهای داخلی مانند Borg و Omega (دو سیستم مدیریت خوشه‌ها) استفاده کردند. با ظهور بنیاد محاسبات ابری (CNCF) و در همکاری با بنیاد لینوکس، کامیونیتی، حکمرانیِ باز (Open Governance) را برای کوبرنتیز اتخاذ شد، مجموعه‌ای از قوانین برای خوشه‌های کوبرنتیز که به تیم‌ها کمک می‌کند تا در مقیاس بزرگ عمل کنند. IBM، به عنوان عضو بنیانگذار CNCF، به‌طور فعال در پروژه‌های متن‌باز CNCF همانند سایر شرکت‌ها مانند گوگل، Red Hat، مایکروسافت و آمازون مشارکت می‌کند.

مزایای کوبرنتیز چیست؟

• کوبرنتیز مجموعه گسترده‌ای از ویژگی‌های کلیدی را ارائه می‌دهد. از جمله: «کشف سرویس» (Service Discovery)، «ingress» و «لود بالانسینگ»، «خود-درمانی» (Self-Healing)، «Storage Orchestration»، «انطباق افقی» (Horizontal Scaling)، «استقرارها/بازگشت‌های خودکار» (automated rollouts/rollbacks) و «اجرای دسته‌ای» (Batch Execution).
• سیستم کوبرنتیز دارای مجموعه‌ای متحد از API‌ها و گارانتی‌های قوی در مورد وضعیت خوشه است.
• کوبرنتیز دارای کامیونیتی اوپن‌سورسی است که به‌طور فعال در حال توسعه کدبِیس هستند.
• کنفرانس‌های به سرعت در حال رشد به نام KubeCon در طول سال، بینش‌های کاربران را انعکاس می‌دهند.
• کوبرنتیز بیش‌ترین میزان استفاده را در بازار از آن خود کرده است.
• کوبرنتیز توسط بازیگران بزرگی مثل گوگل و IBM در عمل امتحانش را پس داده است و روی اکثر سیستم‌عامل‌ها هم اجرا می‌شود.
• در ابرهای عمومی (مثل AWS یا Azure) در دسترس است و همچنین برای استفاده در سرورهای خصوصی هم می‌توان از آن استفاده کرد. همچنین از سوی ارائه‌دهندگان ابری بزرگ هم به صورت مدیریت شده و هم به صورت خام ارائه قابل دسترسی است.
• همچنین از پشتیبانی گسترده‌ای از اکوسیستم ابزارهای ابری مانند Sysdig ،LogDNA و Portworx (در میان بسیاری دیگر) برخوردار است.

چالش‌های استفاده از کوبرنتیز

استفاده از Kubernetes چالش‌های خاص خود را دارد که در ادامه به آن‌ها اشاره شده است.

• یادگیری آن نیاز به تلاش زیادی دارد و مدیریت Kubernetes نیازمند دانش تخصصی است.
• به‌روزرسانی‌های جامعه متن‌باز به طور مداوم اتفاق می‌افتد و نیاز به پچ کردن دقیق دارد تا از اختلال در بارهای کاری جلوگیری شود.
• برای توسعه‌دهندگانِ فردی و برای برنامه‌های ساده و استقرارهای کوچک مناسب نیست و بسیار سنگین است.
• تیم‌ها معمولاً به ابزارهای اضافی (مانند رابطِ خط فرمانِ kubectl)، خدمات، جریان‌های کاری CI/CD و سایر روش‌های DevOps نیاز دارند تا به‌طور کامل بتوانند بر دسترسی، هویت، حاکمیت و امنیت مدیریت کنند.

داکر سوارم Docker Swarm چیست؟

داکر سوارم هم پلتفرم متن‌باز دیگری برای هماهنگ‌سازی کانتِینرها به‌حساب می‌آید که مدت‌هاست وجود دارد. Swarm یا به بیان دقیق‌تر، «حالت خوشه» (Swarm Mode)، پشتیبانی درونی داکر برای هماهنگ‌سازی خوشه‌های موتورهای داکر به حساب می‌آید. یک خوشه Swarm متشکل از گره‌های مدیریت کننده Docker Engine (که خوشه را هماهنگ و مدیریت می‌کنند) و Nodeهای Worker (که به دستور Nodeهای مدیریت کننده& وظایف را اجرا می‌کنند) است.

مزایای Docker Swarm

استفاده از Docker Swarm به چند دلیل مزیت دارد:

• اول اینکه داکر پلتفرم کانتینری رایجی برای ساخت و استقرار برنامه‌های کانتینری است. Swarm هم برای استفاده با موتور داکر ساخته شده است و بخشی از پلتفرمی آشنا برای اکثر تیم‌هاست.
• نصب و راه‌اندازی آن برای محیط Docker آسان است.
• ابزارها، خدمات و نرم‌افزارهایی که با کانتینرهای داکر اجرا می‌شوند، با Swarm هم به خوبی کار می‌کنند.
• داکر Swarm دارای API خاص خودش است.
• داکر سوارم با ابزارهای Docker مانند Docker Compose و رابط خط فرمانِ داکر یکپارچگی خوبی دارد، چون از همان رابط خط فرمان (CLI) موتور داکر استفاده می‌کند.
• همچنین از یک سیستم فیلترینگ و زمان‌بندی استفاده می‌کند تا Nodeهای بهینه را برای استقرار کانتینرها در خوشه انتخاب کند.

چالش‌ها و مشکلات داکر سوارم

• Swarm گزینه‌های سفارشی و افزونه‌های محدودی دارد.
• از نظر عملکردی اندکی ضعیف است و قابلیت‌های اتوماسیون کمتری نسبت به Kubernetes دارد.
• در یک پایپلاین دواپس، جدا کردن بارهای کاری توسعه-آزمایش-تولید (Dev-Test-Prod) به راحتی امکان‌پذیر نیست.

البته برای جلوگیری از ایجاد ابهام، باید گفت که Docker Enterprise Edition اکنون پشتیبانی از Kubernetes را هم ارائه می‌دهد.

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

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

در ادامه با جزئیات بیشتری به شرح تفاوت و مقایسه داکر سوارم و کوبرنتیز پرداخته شده است.

تفاوت داکر سوارم و کوبرنتیز در نصب و راه‌اندازی

به دلیل پیچیدگی کوبرنتیز، Docker Swarm برای نصب و پیکربندی ساده‌تر است.

• Kubernetes: نصب دستی ممکن است برای هر سیستم عامل متفاوت باشد. برای ارائه‌دهندگان ابری، نیازی به نصب وجود ندارد.
• Swarm: نصب آن با داکر ساده است و Instanceها معمولاً در سیستم‌عامل‌ها منسجم و یکپارچه هستند.

مفایسه داکر سوارم و کوبرنتیز از نظر انطباق‌پذیری (Scalability)

کوبرنتیز امکان انطباق‌پذیری و قابلیت ارتقای همه‌کاره (All in One) بر اساس ترافیک را ارائه می‌دهد، در حالی که داکر سوارم بر انطباق‌پذیری سریع متمرکز است.

• کوبرنتیز: انطباق‌پذیری و قابلیت ارتقای خودکار افقی به صورت تعبیه شده و داخلی وجود دارد.
• سوارم: قابلیت انطباق‌پذیری خودکار در صورت تقاضا (On Demand) را ارائه می‌دهد.

تفاوت داکر سوارم و کوبرنتیز در لود بالانسینگ

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

• کوبرنتیز: کشف سرویس‌ها از طریق تنها یک نام DNS فعال می‌شود. کوبرنتیز از طریق یک آدرس IP یا مسیر HTTP به اپلیکیشن‌های کانتینری دسترسی دارد.
• سوارم: دارای لودبالانسرهای داخلی است.

مقایسه Docker Swarm و Kubernetes از نظر دسترس‌پذیری زیاد

هر دوی این ابزارهای هماهنگ‌سازی، قابلیت دسترسی بالایی را ارائه می‌دهند.

• کوبرنتیز: به‌وسیله دور کردن ترافیک از podهای ناسالم، کوبرنتیز خود-درمانی می‌کند. کوبرنتیز قابلیت زمان‌بندی هوشمند و دسترس‌پذیری بالای سرویس‌ها را از طریق همانند‌سازی (Replication) انجام می‌دهد.
• سوارم: منیجرهای سوارم، کنترل دسترس‌پذیری را ارائه می‌دهند و مایکروسرویس‌ها می‌توانند به راحتی همانندسازی شوند.

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

کدام ابزار ارکستراسیون کانتینر برای شما مناسب‌تر است؟ مانند بیشتر تصمیم‌گیری‌های پلتفرمی، ابزار مناسب بستگی به نیازهای سازمان شما دارد. کوبرنیتیز به دلیل پذیرش گسترده و کامیونیتی بزرگی که دارد، محبوب است. همه ارائه‌دهندگان بزرگ ابری از آن پشتیبانی می‌کنند و گزینه‌های «خودت انجام بده» مانند Docker Enterprise Edition نیز موجود هستند.

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

مزیت Docker Swarm در سادگی و آشناتر بودن آن است. این ابزار با Docker Engine عرضه می‌شود و به‌راحتی در محیط شما در دسترس است. بنابراین، Swarm شروع کار را آسان‌تر می‌کند و ممکن است برای بارهای کاری کوچک ایده‌آل‌تر باشد.

جمع‌بندی

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

The post تفاوت داکر سوارم و کوبرنتیز – Docker Swarm vs Kubernetes appeared first on بلاگ هم‌روش.

گام اول اتصال به ssh در لینوکس — ایجاد جفت کلیدها

مرحله اول، ایجاد یک جفت کلید روی دستگاه کلاینت (معمولاً رایانه شخصی شما) است:

ssh-keygen

ssh-keygen

به طور پیش‌فرض، نسخه‌های اخیر ssh-keygen یک جفت کلید RSA با طول ۳۰۷۲ بیت ایجاد می‌کنند که برای بیشتر کاربردها، امنیت کافی را فراهم می‌کند (در صورت تمایل، می‌توانید با استفاده از پرچم -b 4096 یک کلید بزرگ‌تر ۴۰۹۶ بیتی ایجاد کنید). پس از وارد کردن دستور، باید خروجی زیر را مشاهده کنید:

Output
Generating public/private rsa key pair.
Enter file in which to save the key (/your_home/.ssh/id_rsa):

Output
Generating public/private rsa key pair.
Enter file in which to save the key (/your_home/.ssh/id_rsa):

برای ذخیره کردن جفت کلید در زیردایرکتوری .ssh/ در دایرکتوری home اینتر بزنید، یا مسیر دیگری مشخص کنید. اگر قبلاً یک جفت کلید SSH تولید کرده‌اید، ممکن است پرسش زیر را مشاهده کنید:

Output
/home/your_home/.ssh/id_rsa already exists.
Overwrite (y/n)?

Output
/home/your_home/.ssh/id_rsa already exists.
Overwrite (y/n)?

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

Output
Enter passphrase (empty for no passphrase):

Output
Enter passphrase (empty for no passphrase):

در اینجا می‌توانید به صورت اختیاری یک عبارت عبور امن وارد کنید، که به شدت توصیه می‌شود. عبارت عبور یک لایه امنیتی اضافی ایجاد می‌کند تا از ورود کاربران غیرمجاز جلوگیری کند. برای آموختن بیشتر درباره امنیت، می‌توانید به آموزش پیرامون چگونگی پیکربندی احراز هویت مبتنی بر کلید SSH در یک سرور لینوکس [+] مراجعه کنید. سپس باید خروجی مشابه زیر را ببینید:

Output
Your identification has been saved in /your_home/.ssh/id_rsa
Your public key has been saved in /your_home/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host
The key's randomart image is:
+---[RSA 3072]----+
|                .|
|               + |
|              +  |
| .           o . |
|o       S   . o  |
| + o. .oo. ..  .o|
|o = oooooEo+ ...o|
|.. o *o+=.*+o....|
|    =+=ooB=o.... |
+----[SHA256]-----+

Output
Your identification has been saved in /your_home/.ssh/id_rsa
Your public key has been saved in /your_home/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host
The key's randomart image is:
+---[RSA 3072]----+
|                .|
|               + |
|              +  |
| .           o . |
|o       S   . o  |
| + o. .oo. ..  .o|
|o = oooooEo+ ...o|
|.. o *o+=.*+o....|
|    =+=ooB=o.... |
+----[SHA256]-----+

شما اکنون یک کلید عمومی و خصوصی دارید که می‌توانید برای احراز هویت استفاده کنید. مرحله بعدی، قرار دادن کلید عمومی بر روی سرور شما است تا بتوانید با استفاده از احراز هویت مبتنی بر کلید SSH وارد شوید.

مرحله ۲ — کپی کردن کلید عمومی به سرور لینوکس

سریع‌ترین راه برای انتقال کلید عمومی به میزبان Ubuntu، استفاده از ابزاری به نام ssh-copy-id است. به دلیل سادگی استفاده، این روش در صورت در دسترس بودن، به شدت توصیه می‌شود. اگر ابزار ssh-copy-id در دستگاه کلاینت شما موجود نیست، می‌توانید از یکی از ۲ روش جایگزین ارائه‌شده در این بخش استفاده کنید (کپی کردن از طریق SSH مبتنی بر رمز عبور یا کپی دستی کلید).

کپی کردن کلید عمومی با استفاده از ssh-copy-id

ابزار ssh-copy-id به طور پیش‌فرض در بسیاری از سیستم‌های عامل گنجانده شده است، بنابراین ممکن است در سیستم محلی شما در دسترس باشد. برای اینکه این روش کار کند، باید قبلاً دسترسی SSH مبتنی بر رمز عبور را به سرور خود داشته باشید.

برای استفاده از این ابزار، میزبان دوردستی (ریموتی) که می‌خواهیم به آن متصل شویم و حساب کاربری که دسترسی SSH مبتنی بر رمز عبور به آن داریم را مشخص می‌کنیم. این حساب کاربری همان حسابی است که کلید SSH عمومی شما به آن کپی خواهد شد. دستور به شکل زیر است:

ssh-copy-id username@remote_host

ssh-copy-id username@remote_host

ممکن است پیام زیر را مشاهده کنید:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

این یعنی رایانه محلی شما میزبان دوردست را نمی‌شناسد. این اتفاق در اولین اتصال شما به یک میزبان جدید رخ می‌دهد. «yes» را تایپ کرده و ENTER را فشار دهید تا ادامه کار انجام شود. سپس، ابزار مربوطه کلید id_rsa.pub را که قبلاً ایجاد کردیم در حساب محلی ما جستجو می‌کند. وقتی کلید را پیدا کند، رمز عبور حساب کاربری ریموت را از ما درخواست می‌کند:

Output
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@203.0.113.1's password:

Output
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@203.0.113.1's password:

رمز عبور را تایپ می‌کنیم (چیزی که تایپ کرده‌ایم به دلایل امنیتی نمایش داده نمی‌شود) و سپس ENTER را فشار می‌دهیم. ابزار مربوطه به حساب کاربری روی میزبان دوردست با استفاده از رمز عبوری که فراهم کردیم، متصل می‌شود. سپس محتویات کلید ~/.ssh/id_rsa.pub ما را درون فایلی در دایرکتوری هوم ~/.ssh حساب دوردست به نام authorized_keys کپی می‌کند. حالا باید خروجی زیر را مشاهده کنیم:

Output
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@203.0.113.1'"
and check to make sure that only the key(s) you wanted were added.

Output
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@203.0.113.1'"
and check to make sure that only the key(s) you wanted were added.

در این مرحله، کلید id_rsa.pub ما به حساب دوردست آپلود شده است. حالا می‌توانیم برای ادامه به مرحله ۳ برویم.

کپی کردن کلید عمومی با استفاده از SSH

اگر به ابزار ssh-copy-id دسترسی ندارید، اما به حسابی در سرورتان دسترسی SSH مبتنی بر رمز عبور دارید، می‌توانید کلیدهای خود را با استفاده از روش معمول SSH بارگذاری کنید. این کار را با استفاده از دستور cat برای خواندن محتوای کلید SSH عمومی در رایانه محلی‌مان و انتقال آن از طریق اتصال SSH به سرور ریموت انجام می‌دهیم.

در سمت دیگر، می‌توانیم مطمئن شویم که دایرکتوری ~/.ssh وجود دارد و دارای مجوزهای صحیح تحت حسابی است که از آن استفاده می‌کنیم. سپس می‌توانیم محتوایی را که درون فایلی به نام authorized_keys پایپ کردیم را در این دایرکتوری خروجی دهیم. از نماد تغییرمسیر >> برای افزودن محتوا به جای بازنویسی آن استفاده می‌کنیم. این امکان را به ما می‌دهد تا کلیدها را بدون از بین بردن کلیدهای قبلاً افزوده شده، اضافه کنیم. دستور کامل به این شکل است:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

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

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

این یعنی رایانه محلی شما میزبان دوردست را نمی‌شناسد. این اتفاق در اولین اتصال شما به میزبان جدید رخ می‌دهد. «yes» را تایپ کنید و ENTER را فشار دهید تا کار ادامه یابد. سپس، باید برای وارد کردن رمز عبور حساب کاربری دوردست از شما درخواست شود:

Output
username@203.0.113.1's password:

Output
username@203.0.113.1's password:

پس از وارد کردن رمز عبور، محتوای کلید id_rsa.pub شما به انتهای فایل authorized_keys حساب کاربر دوردست کپی خواهد شد. پس از آنکه این کار با موفقیت انجام شد، به مرحله ۳ بروید.

کپی کردن کلید عمومی به صورت دستی

اگر دسترسی SSH مبتنی بر رمز عبور به سرور خود ندارید، باید فرایند فوق را به صورت دستی انجام دهید. پس به صورت دستی محتوای فایل id_rsa.pub را به فایل ~/.ssh/authorized_keys در دستگاه دوردست اضافه می‌کنیم. برای نمایش محتوای کلید id_rsa.pub خود، این دستور را در کامپیوتر محلی خود تایپ کنید:

cat ~/.ssh/id_rsa.pub

cat ~/.ssh/id_rsa.pub

محتوای کلید نمایش داده می‌شود، که باید شبیه به خروجی زیر باشد:

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

با استفاده از هر روشی که در دسترس دارید، به میزبان دوردست دسترسی پیدا کنید. پس از دسترسی به حساب خود در سرور دوردست، باید مطمئن شوید که دایرکتوری ~/.ssh وجود دارد. این دستور، در صورت نیاز دایرکتوری را ایجاد می‌کند و اگر از قبل وجود داشته باشد، کاری انجام نمی‌دهد:

mkdir -p ~/.ssh

mkdir -p ~/.ssh

اکنون، می‌توانید فایل authorized_keys را در این دایرکتوری ایجاد یا ویرایش کنید. می‌توانید محتویات فایل id_rsa.pub خود را در انتهای فایل authorized_keys اضافه کنید، و در صورت نیاز آن را با استفاده از این دستور ایجاد کنید:

echo public_key_string >> ~/.ssh/authorized_keys

echo public_key_string >> ~/.ssh/authorized_keys

در دستور فوق، به جای public_key_string، خروجی دستور cat ~/.ssh/id_rsa.pub که در سیستم محلی خود اجرا کرده‌اید را قرار دهید. این خروجی باید با ssh-rsa AAAA… شروع شود. در نهایت، مطمئن می‌شویم که دایرکتوری ~/.ssh و فایل authorized_keys دارای مجوزهای مناسب هستند:

chmod -R go= ~/.ssh

chmod -R go= ~/.ssh

این دستور به‌طور بازگشتی تمام مجوزهای «group» و «other» را برای دایرکتوری ~/.ssh حذف می‌کند. اگر از حساب روت برای تنظیم کلیدها برای حساب کاربری استفاده می‌کنید، مهم است که دایرکتوری ~/.ssh متعلق به یوزر باشد و نه متعلق به روت:

chown -R sammy:sammy ~/.ssh

chown -R sammy:sammy ~/.ssh

در این آموزش، کاربر ما «sammy» نام دارد اما شما باید نام کاربری مناسب را در دستور فوق جایگزین کنید. اکنون می‌توانیم احراز هویت بدون رمز عبور با سرور Ubuntu خود را انجام دهیم.

گام سوم اتصال به ssh در لینوکس — احراز هویت در سرور Ubuntu با استفاده از کلیدهای SSH

اگر یکی از روش‌های بالا را با موفقیت به پایان رسانده‌اید، حالا باید قادر به ورود به میزبان دوردست بدون ارائه رمز عبور حساب دوردست باشید. فرایند کلی یکسان است:

ssh username@remote_host

ssh username@remote_host

اگر این اولین بار است که به این میزبان متصل می‌شوید (اگر از آخرین روش بالا استفاده کرده‌اید)، ممکن است چیزی شبیه به خروجی زیر را مشاهده کنید:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

این یعنی رایانه محلی شما میزبان دوردست را نمی‌شناسد و این اولین بار است که به آن متصل می‌شوید. «yes» را تایپ کنید و سپس ENTER را فشار دهید ادامه کار انجام شود.

اگر برای کلید خصوصی خود عبارت عبوری (Passphrase) تعیین نکرده‌اید، بلافاصله وارد می‌شوید. اگر هنگام ایجاد کلید، عبارت عبوری برای کلید خصوصی تعیین کرده‌اید، اکنون از شما خواسته می‌شود که آن را وارد کنید (توجه داشته باشید که حروف وارد شده در سِشِن ترمینال به دلایل امنیتی نمایش داده نمی‌شوند). پس از احراز هویت، یک سشن شل جدید برای شما با حساب پیکربندی شده در سرور Ubuntu باز می‌شود.

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

گام چهارم — غیرفعال کردن احراز هویت با پسورد برای اتصال به سرور

اگر توانستید بدون استفاده از رمز عبور با استفاده از SSH به حساب خود وارد شوید، به این معناست که احراز هویت مبتنی بر کلید SSH را برای حساب خود به درستی پیکربندی کرده‌اید. با این حال، مکانیزم احراز هویت بر پایه رمز عبور همچنان فعال است، به این معنی که سرور شما هنوز در معرض حملات نیرومند (Brute-Force) قرار دارد.

پیش از انجام مراحل این بخش، اطمینان حاصل کنید که یا احراز هویت مبتنی بر کلید SSH را برای حساب روت در این سرور پیکربندی کرده‌اید، یا بهتر اینکه، احراز هویت مبتنی بر کلید SSH را برای حساب غیر root در این سرور با امتیازات sudo پیکربندی کرده‌اید. این مرحله ورود‌های مبتنی بر رمز عبور را محدود می‌کند، بنابراین تضمین اینکه همچنان قادر به دسترسی مدیریتی خواهید بود، حیاتی است.

پس از تأیید اینکه حساب دوردست شما دارای امتیازات مدیریتی است، با استفاده از کلیدهای SSH، به سرور دوردست خود وارد شوید، چه به عنوان روت و چه با حسابی که دارای امتیازات سودو است. سپس، فایل پیکربندی دیمون SSH را باز کنید:

sudo nano /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

در داخل فایل، به دنبال دستورالعملی به نام PasswordAuthentication بگردید. این خط ممکن است با علامت # به صورت کامنت در آنده باشد. خط را با حذف #، Uncomment کنید و مقدار آن را به no تغییر دهید. این کار قابلیت ورود شما از طریق SSH با استفاده از رمزهای عبور حساب را غیرفعال می‌کند:

. . .
PasswordAuthentication no
. . .

. . .
PasswordAuthentication no
. . .

پس از اتمام کار، فایل را با فشار دادن CTRL+X و سپس Y برای تأیید ذخیره‌سازی فایل و در نهایت با زدن ENTER برای خروج از nano ببندید. برای فعال کردن این تغییرات، باید سرویس sshd را مجدداً راه‌اندازی کنیم:

sudo systemctl restart ssh

sudo systemctl restart ssh

برای احتیاط، یک پنجره ترمینال جدید باز کنید و قبل از بستن سشن فعلی خود، تست کنید که سرویس SSH به درستی کار می‌کند یا خیر:

ssh username@remote_host

ssh username@remote_host

پس از تأیید اینکه سرویس SSH شما به درستی کار می‌کند، می‌توانید تمام جلسات فعلی سرور را با خیال راحت ببندید. دیمون SSH در سرور اوبونتو شما اکنون فقط به احراز هویت مبتنی بر کلید SSH پاسخ می‌دهد و ورود‌های مبتنی بر رمز عبور غیرفعال شده‌اند.

جمع‌بندی

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

The post راه‌اندازی و اتصال به ssh در لینوکس با کلید ssh appeared first on بلاگ هم‌روش.