پایپ لاین CI/CD و استقرار خودکار با GitLab، Jenkins و ArgoCD

راهنمای پایپ لاین CI/CD

GitLab Runner با کدام executor؟ shell، docker یا kubernetes

executor تعیین می کند jobهای پایپ لاین کجا و چطور اجرا شوند. shell executor دستورها را مستقیم روی سرور Runner اجرا می کند. ساده است، ولی jobها روی فایل های یکدیگر اثر می گذارند و نسخه ابزارها بین پروژه ها تداخل پیدا می کند.

docker executor هر job را در کانتینری تازه اجرا می کند و برای بیشتر تیم ها مناسب است. اگر job باید ایمیج Docker بسازد، به جای Docker-in-Docker در حالت privileged که عملاً دسترسی root به سرور Runner می دهد، Buildah یا BuildKit بدون root را پیشنهاد می کنیم. اگر کلاستر کوبرنتیز دارید، kubernetes executor هر job را به شکل pod اجرا می کند و ظرفیت Runner همراه کلاستر کم و زیاد می شود.

GitLab CI/CD variables: اشتباهات رایج در نگهداری رمزها

متغیری که در تنظیمات پروژه تعریف شده، خودبه خود امن نیست. اگر گزینه Masked فعال نباشد، مقدار آن با یک echo یا اجرای اسکریپت با set -x در لاگ job چاپ می شود و هر کسی که به لاگ دسترسی دارد آن را می بیند. اگر Protected نباشد، هر برنامه نویسی می تواند در یک branch تازه jobی بنویسد که کلید SSH سرور production را بخواند.

اشتباه رایج دیگر یک Runner مشترک برای همه پروژه هاست که کلید دسترسی به سرورهای اصلی رویش مانده. Runner پروژه های حساس را جدا کنید و استقرار production را به Runner اختصاصی با tag مشخص بسپارید. نبودن expire_in برای artifactها هم باعث می شود دیسک سرور GitLab چند ماه بعد پر شود.

پیش از راه اندازی پایپ لاین CI/CD چه چیزهایی را مشخص کنید؟

پایپ لاین روند فعلی انتشار را خودکار می کند، پس آن روند باید روشن باشد. مدل branch را مشخص کنید: همه روی main کار می کنند یا branchهای develop و release دارید. فهرست محیط ها و نوع دسترسی به هر کدام را هم آماده کنید.

دستورهایی که امروز برای build و اجرای تست ها به کار می روند، حتی اگر فقط در ذهن یک نفر باشند، باید نوشته شوند. تصمیم بگیرید migration دیتابیس خودکار اجرا شود یا با تأیید، و چه کسی اجازه تأیید انتشار روی production را دارد.

ArgoCD و Helm کنار GitLab CI/CD: هر کار با کدام ابزار است؟

در مدل رایج، GitLab CI ایمیج را build و تست می کند، آن را به رجیستری می فرستد و فقط تگ نسخه جدید را در مخزن تنظیمات استقرار به روز می کند. ArgoCD این مخزن را دنبال می کند و کلاستر را با آن هم سان می کند. به این ترتیب پایپ لاین به kubeconfig مدیر کلاستر نیاز ندارد.

برای هر محیط یک فایل values جداگانه در Helm chart نگه می داریم، مثل values-staging.yaml و values-production.yaml، و ArgoCD هر Application را از فایل خودش می سازد. اگر کسی با kubectl تغییری دستی روی کلاستر بدهد، ArgoCD آن را OutOfSync نشان می دهد و با selfHeal آن را برمی گرداند.