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

از Kubernetes برای بهبود عملکرد، مقیاس پذیری و سهولت پیکربندی برای تست های خود استفاده کنید

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

یکی از تکنیک هایی که برای آزمایش برنامه های کاربردی توزیع شده محبوبیت پیدا کرد، استفاده از Docker-in-Docker یا DinD بود. ایده این بود که یک دایمون داکر را در داخل یک ظرف داکر اجرا کنیم و سپس از آن محیط داکر داخلی برای هماهنگ کردن پشته کامل برنامه روی یک ماشین واحد استفاده کنیم.

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

اگر شما مسئول آزمایش در سازمان خود هستید، می توانید به خوبی با سناریوی بالا ارتباط برقرار کنید. آزمایش در داکر در داکر با مشکلات خود همراه است و برای برنامه های کاربردی بزرگ می تواند به یک کابوس تبدیل شود. در این پست وبلاگ، به چالش‌های رویکرد Docker in Docker و اینکه چرا باید از Kubernetes برای آزمایش استفاده کنید، خواهیم پرداخت.

داکر در داکر 101 (DinD)

اما قبل از اینکه بیشتر به این پست وبلاگ بپردازیم، یک آغازگر کوتاه در Docker in Docker (DinD) ضروری است. همانطور که از نام آن پیداست، یک داکر کانتینر را در داخل یک داکر کانتینر اجرا می کند. این رویکرد اولین بار در اواخر سال 2013 ظاهر شد و به زودی محبوبیت پیدا کرد.

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

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

مشکلات اجرای Docker در Docker

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

عملکرد ناکارآمد

یکی از اشکالات عمده رویکرد DinD عملکرد کمتر یا ناکارآمد آن است، به ویژه در مقیاس. رویکرد تست DinD اگر به درستی مدیریت نشود، منابع شما را افزایش می دهد. از آنجایی که هر داکر دیمون مجموعه ای از منابع از جمله CPU، RAM، شبکه و غیره را در سیستمی با منابع محدود ذخیره می کند، این سربار می تواند به سرعت منجر به گلوگاه عملکرد و بی ثباتی در حین آزمایش شود.

عدم توانایی در تنظیم تولید آینه

آزمایش یک برنامه کاربردی در یک محیط تولید مانند حیاتی است. با این حال، محیط DinD نمی تواند دقیقاً تنظیمات تولید واقعی شما را تقلید کند. محیط کانتینر تو در تو ممکن است رفتارهای متفاوتی از خود نشان دهد به دلیل ذخیره سازی، شبکه و پیکربندی امنیتی متفاوت که ممکن است شبیه محیط تولید شما نباشد. به عنوان مثال، کانتینرهای تولید شما ممکن است در زمان اجرای Docker متفاوت (کانتینر، کریو و غیره) در مقایسه با آنچه DinD به طور پیش فرض ارائه می دهد اجرا شود.

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

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

نگرانی های مقیاس پذیری داکر

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

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

حتی سازنده DinD از شما می‌خواهد قبل از استفاده از DinD برای CI یا محیط آزمایشی خود دو بار فکر کنید.

چرا از Kubernetes برای آزمایش استفاده کنیم؟

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

مقیاس پذیری داخلی

Kubernetes دارای قابلیت‌های ارکستراسیون داخلی است که مقیاس‌بندی بر اساس تقاضا را امکان‌پذیر می‌کند، که با رویکرد DinD غیرممکن است. این مکانیسم‌هایی مانند مقیاس خودکار غلاف افقی، مقیاس خودکار خوشه‌ای، و توانایی زمان‌بندی خودکار کانتینرها در میان مجموعه‌ای از گره‌ها را فراهم می‌کند. این به شما امکان می دهد با مقیاس بندی اجزای برنامه با استفاده از دستورات ساده یا قوانین مقیاس خودکار بر اساس مصرف CPU / حافظه، سناریوهای بار واقعی را مدل کنید.

محیط های منعکس کننده تولید منسجم

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

ساده و کارآمد

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

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

تست های خود را در Kubernetes با Testkube اجرا کنید

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

• می‌توانید هر ابزار آزمایشی را به Testkube وصل کنید، آن را بومی Kubernetes کنید و از مزایای Kubernetes نهایت استفاده را ببرید. لیست کامل ادغام های Testkube را بررسی کنید.

• با Testkube می توانید به راحتی سناریوهای آزمایشی پیچیده را در چندین محیط ایجاد و مدیریت کنید.

• Testkube با مجموعه ای از ابزارهای CI/CD ادغام می شود تا خطوط لوله DevOps شما را با فعال کردن آزمایش کامل برنامه های شما از انتها به انتها بهبود بخشد.

انتقال چارچوب آزمایشی خود از DinD به Kubernetes ممکن است ترسناک به نظر برسد، اما با Testkube، این کار بسیار آسان است. همانطور که قبلا ذکر شد، Testkube مجموعه‌ای از ویژگی‌ها را همراه با ابزارها و ادغام‌هایی ارائه می‌کند که استقرار، اجرا و نظارت بر تست را در Kubernetes ساده می‌کند و اطمینان می‌دهد که تست‌های شما تا حد امکان به محیط تولید نزدیک هستند.

استفاده از Testkube Test Workflows

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

در این بخش، نحوه ایجاد یک گردش کار آزمایشی با استفاده از Testkube را بررسی خواهیم کرد. ما یکی برای Postman ایجاد خواهیم کرد، اما شما می توانید یک گردش کار را برای تقریباً هر ابزار آزمایشی پیکربندی کنید.

ایجاد یک گردش کار آزمایشی با استفاده از Postman

برای ایجاد یک گردش کار آزمایشی، باید یک کلاستر همراه با عامل Testkube داشته باشید. وقتی این را اجرا کردید، می توانید وارد داشبورد Testkube شوید، روی Test Workflows و “Add A New Test Workflow” کلیک کنید و “Start From An Example” را انتخاب کنید.

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

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: postman-workflow-example # name of the Test Workflow
spec:
  content:
    git: # checking out from git repository
      uri: https://github.com/kubeshop/testkube
      revision: main
      paths:
        - test/postman/executor-tests/postman-executor-smoke-without-envs.postman_collection.json
  container: # container settings
    resources: # resource settings (optional)
      requests: # resource requests
        cpu: 256m
        memory: 128Mi
    workingDir: /data/repo/test/postman/executor-tests # default workingDir
  steps: # steps that will be executed by this Test Workflow
    - name: Run test
      run:
        image: postman/newman:6-alpine # image used while running specific step
        args: # args passed to the container
          - run
          - postman-executor-smoke-without-envs.postman_collection.json

این را در قسمت spec قرار دهید و روی Create کلیک کنید. با این کار گردش کار آزمایشی ایجاد می شود و شما را به صفحه گردش کار می برد.

اجرای یک گردش کار آزمایشی

برای شروع اجرای گردش کار بر روی “Run Now” کلیک کنید. با کلیک بر روی اجرای مربوطه، لاگ ها، مصنوعات و فایل گردش کار زیرین را به شما نشان می دهد.

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

خلاصه

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