چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت دوم

در یاداشت قبلی نوشتم که چطور کانتینر دیتابیس و اپلیکیشن را در محیط دولوپمنت اجرا کنیم. در این یادداشت اپلیکیشن را به پروداکشن انتقال می‌دهیم و CI و CD مختصری را پیاده می‌کنیم.

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

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

  • بعد از پوش کردن به رپوزیتوری پروسه CI شروع به کار خواهد کرد و ایمیج جدید درست خواهد شد. سپس در محیط تست کانتینر جدید ایجاد می‌شود و تست‌ها اجرا می‌شوند. در این مرحله می‌تونیم از هر ابزار CI که داکر را پشتیبانی می‌کند استفاده کنیم. (مثلا CircleCI)
  • اگر همه تست‌ها پاس شدند حالا باید ایمیج جدید به داکر رجیستری ارسال بشه.  رجیستری جایی است که تمام نسخه‌های ایمیج‌های ساخته شده را نگهداری می‌کنیم. برای این مورد از داکرهاب یا گیت‌لب یا سرورهای شخصی که به داکرهاب مجهز شدن استفاده کرد.
  • بعد از پوش شدن ایمیج جدید وقت این می‌رسه که آخرین ایمیج را از رجیستری دریافت کنیم و به سرورهای دولوپمنت یا پروداکشن که به مکانیزم داکر مجهز هستند ارسال کنیم و سپس با docker-compose و عینا مانند محیط دولوپمنت کانتینرها را بالا بیاوریم. این کار را هم با ابزارهای آماده و یا نوشتن اسکریپت میتونیم انجام بدیم.
  • تا اینجا عملا کد جدید را به سرورها ارسال کردیم ولی باید حواسمون به مکانیزمی برای رول‌بک به ایمیج‌های قبلی و همچنین بک‌آپ دیتابیس‌ها باشه. با استفاده از داکر ریسک بروز خطا را به شدت کاهش دادیم ولی همچنان احتمال بروز خطا وجود خواهد داشت.

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

قدم اول:‌آماده سازی اولیه

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

پروژه جدید درست میکنیم:

به ابرکلود اجازه میدیم که به رپوزیتوری دسترسی داشته باشه (اتصال secret key to build config را بعد از ساخت اپ انجام می‌دهیم ->)  اپ جدیدی در پروژه ای که در مرحله قبل ساختیم اضافه می‌کنیم:

برای صرفه جویی در زمان Environment Variable ها را از طریق پنل UI وارد میکنیم و در انتها دستور اولین بیلد و سپس ساخت کانتینر و رول اوت کردن پروژه را وارد می‌کنیم:

آخرین دستور یو آر ال کانتینر ساخته شده را برمیگرداند. به این ترتیب از روی کد موجود در رپوزیتوری ایمیج ساخته شده و اپلیکیشن بر روی کلود آماده استفاده است.

قدم دوم: وب‌هوک

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

قدم سوم: اجرای اتوماتیک تست

اسکریپت  اجرای تست را  در روت پروژه قرار میدیم. جواب تست به ریپوزیتوری ارسال میشه و در ضمن در صورتی که تست پاس بشه ایمیج جدید به رجیستری ابرکلود اضافه خواهد شد، در غیر این صورت اتفاقی نخواهد افتاد.

 

قدم چهارم: تغییر برای بالا آوردن کانتینرها

از اونجایی که ابرکلود از docker-compose پشتیبانی نمی‌کند چند تغییر باید بدهیم: ابتدا برای ایجاد دیتابیس از طریق پنل UI یک کانتینر POSTGRES راه اندازی می‌کنیم و اطلاعات کانکشن این کانتینر را در پروژه برای محیط پروداکشن اضافه می‌کنیم. سپس برای راحتی اجرای تست‌ها، دیتابیس تست را یه SQLITE تغییر میدیم. در نهایت خط زیر را به داکر فایل اضافه می‌کنیم تا در هربار ساخته شدن ایمیج assetهای مورد نظر rails هم ساخته شده و در ایمیج قابل دسترس باشند

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

 

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

Leave a Reply

Your email address will not be published. Required fields are marked *