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

مطلب پیشنهادی

تفاوت‌های کلیدی دو معماری زیرساختی

معماری یکپارچه و میکروسرویس چه تفاوت‌هایی دارند؟

آشنایی با کوبرنتیس و اصطلاحات مهم آن 

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

• پاد (Pod): مولفه کلیدی کوبرتینس است که می‌تواند از یک یا چند کانتینر تشکیل شده باشد و تضمین می‌دهد کانتینرها در ماشین میزبان قرار دارند و منابع یکسانی را به‌اشتراک می‌گذارند. کانتینرهای درون یک پاد توانایی مشاهده دیگر کانتینرها از طریق localhost را دارند و هر یک آدرس آی‌پی منحصر‌به‌فردی درون خوشه دارند. 
• سرویس (Service): مجموعه‌ای از پادها است که با هم کار می‌کنند. به‌طور پیش‌فرض، یک سرویس در یک خوشه قرار می‌گیرد، اما می‌تواند خارج از خوشه باشد. در این حالت، یک آدرس آی‌پی خارجی دارد. توسعه‌دهندگان می‌توانند آن را با استفاده از یکی از چهار خصلت ClusterIP، NodePort، LoadBalancer و ExternalName نمایش دهند. 
• کنترلر‌کننده تکثیر (Replication Controller): نوع خاصی از کنترلر کوبرنتیس است. مولفه فوق تعداد مشخصی کپی‌ از یک پاد در یک خوشه تهیه می‌کند تا فرآیند تکثیر و مقیاس‌بندی به‌شکل دقیقی انجام شود. علاوه بر این، مولفه فوق مسئول جایگزینی پاد در صورت از کار افتادن گره‌های لایه پایینی است.
• Minikube: پیکربندی خوشه کوبرتینسی که قرار است بر مبنای اصل دسترس‌پذیری بالا مورد استفاده قرار گیرد، کار چندان ساده‌ای نیست. خوشبختانه، ابزاری وجود دارد که اجرای محلی کوبرتینس را ساده می‌کند. این ابزار Minikube نام دارد و می‌تواند یک خوشه تک‌گره‌ای را در یک ماشین مجازی اجرا کند تا توسعه‌دهندگان هر زمان نیاز داشتند به آن دسترسی پیدا کنند. اگر قصد استفاده از ابزار فوق در سیستم‌عامل ویندوز را دارید، باید minikube.exe و kubectl.exe را دانلود کرده و به متغیر محیطی PATH اضافه کنید. در ادامه، می‌توانید آن را از خط فرمان با استفاده از دستور minikube start اجرا کنید و از تمام ویژگی‌های کوبرنیتس با فراخوانی دستور kubectl استفاده کنید. یک جایگزین برای ابزار خط فرمان، داشبورد کوبرنتیس است که می‌توان آن را با فراخوانی دستور Minikube Dashboard راه‌اندازی کرد. در این حالت، توانایی ساخت، استقرار‌، به‌روزرسانی یا حذف خوشه‌ها از طریق داشبوردی که یک رابط کاربری ارائه می‌دهد، وجود دارد. همچنین، پیکربندی همه پادها، سرویس‌ها، ورودی‌ها، کنترل‌کننده‌های تکثیر و غیره از طریق داشبورد فوق به سهولت وجود دارد. شکل ۱، رابط کاربری این ابزار را نشان می‌دهد. 

شکل 1

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

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

مطلب پیشنهادی

مهاجرت از دنیای برنامه‌نویسی یکپارچه به‌سمت میکروسرویس‌ها

بر مبنای برنامه‌ریزی اصولی، به سراغ پارادایم توسعه مبتنی بر میکروسرویس‌‌ها بروید

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

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

• خودبهبودی (Self-healing): هنگامی که یک کانتینر از کار می‌افتد یا با مشکل روبه‌رو می‌شود، کوبرنتیس به‌طور خودکار آن را جایگزین می‌کند تا عملکرد برنامه کاربردی حفظ شده و شرایط پایدار آن حفظ شود. 
• مدیریت پیکربندی اعلامی و کنترل نسخه (Declarative configuration management and version control): پیکربندی‌های کوبرنتیس در فایل‌هایی با فرمت YAML ذخیره می‌شوند که اجازه می‌دهند نسخه نرم‌افزار را از طریق گیت کنترل کرد. علاوه بر این، تنظیمات را می‌توان به‌شکل یکپارچه‌ای به‌روز‌رسانی کرد تا همه کانتینرها تنظیمات یکسانی داشته باشند. 
• چندابری و ابر ترکیبی (Multi-cloud and hybrid cloud): کوبرنتیس به تیم‌های فناوری اطلاعات اجازه می‌دهد پلتفرم ابری مدنظر خود را برای استقرار بارهای کاری انتخاب کنند. پلتفرم‌های ابری مثل Google Cloud Platform، Microsoft Azure یا AWS برای این منظور در دسترس توسعه‌دهندگان قرار دارد. 
• ارائه سرویس‌ها و متعادل‌سازی بار (Service exposure and Load balancing): کوبرنتیس با استفاده از آدرس‌های سامانه نام دامنه یا آی‌پی، کانتینرها را در پادها یا گروه‌هایی از پادها در معرض دید قرار می‌دهد تا دیگر میکروسرویس‌ها بتوانند آن منابع را مصرف کنند. همچنین، مدیران فناوری اطلاعات می‌توانند گروه‌های پاد منطقی متعادل را با دردسر کمتری بارگذاری کنند. 
• مدیریت اسرار (Secrets Management): کوبرنتیس نقش مهمی در پیشگیری از افشای اطلاعات حساس، مانند رمزهای عبور و ایمیج‌های درون کانتینرها ارائه می‌دهد و از اشیایی که نباید در معرض دید قرار بگیرند از طریق مولفه etcd محافظت می‌کند.
• گسترش‌پذیری (Scalability): هنگامی که تقاضا برای دسترسی به سرویس‌ها زیاد می‌شود یا افزایش بار به‌وجود می‌آید، کوبرنتیس به‌صورت افقی تعداد کانتینرهایی را که یک میکروسرویس اجرا می‌کند، کاهش می‌دهد تا مانع بروز مشکلات عملکردی شود. 
• زمان از دسترس خارج شدن صفر (Zero Downtime): کوبرنتیس برای اطمینان از عدم خرابی قادر است پادهای اضافی را که بر مبنای ایمیج تازه‌‌ای ساخته شده‌اند، نصب کند. هنگامی که کانتینرهای جدید آماده می‌شوند، تیم‌ها می‌توانند به‌روزرسانی‌ها را منتشر کرده و کانتینرهای قدیمی را حذف کنند. علاوه بر این، اگر کانتینرهای جدید از کار بیفتند، تیم‌های فناوری اطلاعات می‌توانند تغییرات را با حداقل صرف زمان لغو کرده و به حالت قبل بازگردانند.

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

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

اشاره کرد: 

• ClusterIP: سرویس را در یک خوشه با آدرس آی‌پی محلی قرار می‌دهد. سرویس فوق گزینه پیش‌فرض کوبرنتیس است. 
• NodePort: برنامه را روی یک آی‌پی و پورت ثابت در سطح گره نشان می‌دهد، به طوری که در خارج از خوشه از طریق آدرس آی‌پی و پورت قابل دسترسی است. این روشی است که ما در مقاله خود از آن استفاده می‌کنیم. 
• LoadBalancer: برنامه را به‌عنوان سرویسی در دسترس یک مولفه متعادل‌کننده بار تعریف می‌کند که روی فضای ابری میزبانی شده است. 
• ExternalName: خدمات <IPAddress:Port> را به آدرس‌ها و نام‌های خارجی با استفاده از رکورد CNAME نگاشت می‌کند. در ارتباطات داخلی، می‌توانید از سرویس ClusterIP و سامانه نام دامنه برای پیکربندی نام‌های دامنه کاملا واجد شرایط شبیه به آدرس‌های زیر استفاده کنید: 

http://get-employee-microsvc.default.svc.cluster.local 

http://new-employee-microsvc.default.svc.cluster.local

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

مطلب پیشنهادی

لزوم توجه به امنیت در هنگام طراحی

11 راهکار موثر برای تامین امنیت میکروسرویس‌ها

برنامه کاربردی ما

در کوبرنتیس ما میکروسرویس‌های مرتبط با حساب‌های کاربری (Accounts User) و مشتری (customer) داریم. سرویس‌های کاربردی هنگام جست‌وجوی حساب‌های مشتری با سرویس‌های حساب کاربری در ارتباط هستند. معماری‌ای که قصد پیاده‌سازی آن‌را داریم در شکل ۲ نشان داده شده است. هر پاد میکروسرویس از دو کانتینر تشکیل شده است. کانتینر اول با برنامه میکروسرویس و کانیتنر دوم با پایگاه داده Mongo در ارتباط است. میکروسرویس‌های حساب و مشتری پایگاه داده خود را دارند که در آن همه داده‌ها ذخیره می‌شوند. هر پاد به‌عنوان یک سرویس در دسترس قرار دارد و می‌توان آن را با نام‌اش در کوبرنتیس جست‌وجو کرد. در این‌جا، قصد داریم تا Kubernetes Ingress را به‌گونه‌ای پیکربندی کنیم که به‌عنوان دروازه‌ای برای میکروسرویس‌ها عمل کند. لازم به توضیح است، کد‌های منبع این برنامه در سایت گیت‌هاب که آدرس آن در انتهای مقاله درج شده در دسترس قرار دارد. 

شکل 2

معماری فوق مبتنی بر دو ماژول خدمات حساب کاربری (account-service) و خدمات مشتری (customer-service) است که بر مبنای چارچوب Spring Boot عمل می‌کند و تنها از مولفه Feign  client که فایل داکر account service است، استفاده می‌کند. علاوه بر این، ما از یک ایمیج کوچک openjdk - alpine استفاده می‌کنیم. ایمیج فوق اجازه می‌دهد تا ایمیج پایه ما به جای آن‌که 650 مگابایت باشد، تنها 120 مگابایت فضا اشغال کند. 

FROM openjdk:alpine

MAINTAINER Piotr Minkowski <piotr.minkowski@gmail.com>

ADD target/account-service.jar account-service.jar

ENTRYPOINT [“java”, “-jar”, “/account-service.jar”]

EXPOSE 2222

برای فعال‌سازی پشتیبانی از بانک اطلاعاتی MongoDB باید وابستگی Spring-boot-Starter-data-mongodb را به pom.xml اضافه کنیم. همچنین، باید مکانیزم دسترسی به داده‌ها را برای application.yml و همچنین کلاس @Document را تعریف کنیم. در ادامه، باید رابط مخزن را که MongoRepository نام دارد گسترش دهیم تا توانایی انجام عملیات CRUD را داشته باشیم. برای این منظور ماژول‌های کلیدی موردنیاز را به‌شرح زیر تعریف می‌کنیم: 

public interface AccountRepository extends MongoRepository<Account, String> {

    public Account findByNumber(String number);

    public List<Account> findByCustomerId(String customerId);

}

در بخش خدمات مشتری، در نظر داریم متد API را از سرویس حساب فراخوانی کنیم. برای این منظور باید @FeignClient را تعریف کنیم تا همه پادهای دارای سرویس حساب تحت نام account-service  و پورت سرویس پیش‌فرض 2222 به @FeignClient دسترسی داشته باشند. فرآیند تعریف مولفه فوق به‌شرح زیر است: 

@FeignClient(name = “account-service”, url = “http://account-service:2222”)

public interface AccountClient {

    @RequestMapping(method = RequestMethod.GET, value = “/accounts/customer/{customerId}”)

    List<Account> getAccounts(@PathVariable(“customerId”) String customerId);

}

در مرحله بعد، برای ساخت ایمیج داکر میکروسرویس‌ از دستورس بیلد (build) داکر استفاده می‌کنیم. در ادامه، باید ایمیج را به هاب اصلی داکر یا مخزن خصوصی خود متصل کنیم. برای انجام این‌کار از دستورات زیر استفاده می‌کنیم. برای مشاهده مخزن عمومی Docker Hub استفاده‌شده در این پروژه کافی است به  piomin/account-service و piomin/customer-service که آدرس آن‌ها در انتهای مقاله قرار دارد، مراجعه کنید. 

docker build -t piomin/account-service .

docker push piomin/account-service

مطلب پیشنهادی

آشنایی با پرسش‌های مرتبط با معماری میکروسرویس

پرسش و پاسخ‌های برتر مصاحبه‌های استخدامی میکروسرویس‌ها

گسترش (Deployment)

می‌توانید با استفاده از دستور kubectl run، داشبورد Minikube یا فایل‌های پیکربندی YAML با دستور kubectl create، فرآیند استقرار در کوبرنتیس را انجام دهید. نکته‌ای که باید به آن اشاره کنیم این است که قصد داریم همه منابع را از فایل‌های پیکربندی YAML ایجاد کنیم، زیرا در نظر داریم فرآیند استقرار چند کانتینر را در یک مرحله استقرار انجام دهیم. فایل پیکربندی استقرار برای خدمات حساب کاربری به‌شرح زیر است. دقت کنید که باید نام استقرار، نام ایمیج و پورتی که قرار است دسترسی به سرویس را فراهم کند، مشخص کنید. همچنین، در ویژگی replicas، باید تعداد درخواست‌ها برای ساخت پادها را مشخص کنیم. 

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

  name: account-service

  labels:

    run: account-service

spec:

  replicas: 1

  template:

    metadata:

      labels:

        run: account-service

    spec:

      containers:

      - name: account-service

        image: piomin/account-service

        ports:

        - containerPort: 2222

          protocol: TCP

      - name: mongo

        image: library/mongo

        ports:

        - containerPort: 27017

          protocol: TCP

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

kubectl create -f deployment-account.yaml

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

kind: Service

apiVersion: v1

metadata:

  name: account-service

spec:

  selector:

    run: account-service

  ports:

    - name: port1

      protocol: TCP

      port: 2222

      targetPort: 2222

    - name: port2

      protocol: TCP

      port: 27017

      targetPort: 27017

  type: NodePort

اکنون، سرویسی شبیه به آن‌چه در شکل ۳ مشاهده می‌کنید در اختیار داریم. 

شکل 3

پس از ساخت پیکربندی مشابه برای خدمات مشتری باید میکروسرویس‌های خود را در معرض دید قرار دهیم. در کوبرنتیس، آن‌ها از طریق پورت‌های پیش‌فرض (2222 و 3333) و نام سرویس قابل مشاهده هستند. به همین دلیل در ماژول @FeignClient، آدرس اینترنتی http://account-service:2222 را تعریف کردیم. در این‌جا، اهمیتی ندارد چند پاد ساخته شده باشد، سرویس همیشه در آدرس اینترنتی تعریف‌شده در دسترس است و درخواست‌ها بین همه پادها متعادل‌سازی می‌شوند. اگر بخواهیم به هر سرویسی خارج از کوبرنتیس دسترسی داشته باشیم و از نرم‌افزارهایی مثل مرورگرهای وب استفاده کنیم باید از شماره پورت پیش‌فرض کانتینر استفاده کنیم. به‌طور مثال دسترسی به سرویس حساب از طریق پورت 31638 و برای خدمات مشتری از طریق پورت 31171 است.

اگر Minikube را روی ویندوز اجرا کرده‌اید، کوبرنتیس از طریق آدرس 192.168.99.100 در دسترس است، بنابراین می‌توانید با استفاده از آدرس اینترنتی http://192.168.99.100:31638/accounts با سرویس حساب در تعامل باشید. البته، قبل از دسترسی به سرویس‌ها، باید در پایگاه داده Mongo کاربران را تعریف کرده و فایل application.yml را تنظیم کنیم (شکل ۴).

شکل 4

اکنون، دو میکروسرویس داریم و هر کدام دو پورت مخصوص به خود دارند که آن چیزی نیست که انتظارش را داریم. ما به نوعی دروازه نیاز داریم که با تطبیق مسیر درخواست، درخواست‌های ما را دقیقا به سرویس موردنظر هدایت کند. کوبرنتیس قابلیت قدرتمندی در این زمینه در اختیار ما قرار می‌دهد. این راه‌حل Ingress است و از طریق فایل پیکربندی YAML ingress در دسترس قرار دارد. در این‌جا باید دو خط‌مشی برای خدمات حساب و خدمات مشتری تعریف کنیم. دروازه ما تحت نام میزبان micro.all و پورت پیش‌فرض HTTP در دسترس است. دستورات زیر نحوه پیکربندی تنظیمات را نشان می‌دهند. 

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: gateway-ingress

spec:

  backend:

    serviceName: default-http-backend

    servicePort: 80

  rules:

  - host: micro.all

    http:

      paths:

      - path: /account

        backend:

          serviceName: account-service

          servicePort: 2222

      - path: /customer

        backend:

          serviceName: customer-service

          servicePort: 3333

آخرین کاری که باید انجام شود تا دروازه قابل استفاده باشد، این است که ورودی زیر را به فایل hosts سیستم اضافه کنیم. در لینوکس به مسیر /etc/hosts و در ویندوز به آدرس C:\Windows\System32\drivers\etc\hosts بروید و فایل مربوطه را ویرایش کنید. اکنون، می‌توانید از مرورگر وب خود به http://micro.all/accounts یا http://micro.all/customers/{id} که سرویس حساب را در پس‌زمینه فراخوانی می‌کند، دسترسی داشته باشید. 

 [MINIKUBE_IP] micro.all