منذ عامين ، نشرنا المقال "
إنشاء مشاريع مع GitLab CI: واحد .gitlab-ci.yml لمئات التطبيقات " ، والآن سنتحدث عن حل مشكلة مماثلة اليوم. المواد الجديدة
.gitlab-ci.yml حول كيفية إنشاء عمليات CI / CD لعدد كبير من التطبيقات المماثلة مع ظهور
include في
.gitlab-ci.yml وظهور werf لاستبدال dapp.
استهلالي
في الإرشادات الإضافية الواردة في المقالة ، يعتبر الموقف التالي:
- يوجد تطبيق عميل كبير ، ينقسم إلى العديد من المستودعات.
- كل مستودع هو تطبيق منفصل يجب تشغيله في كتلة Kubernetes.
- كنظام CI ، يتم استخدام GitLab CI.
- يتم وصف النشر (البنية التحتية التي يتم نشر الكود بها) بواسطة مخططات Helm.
- بناء الصور ونشرها في Kubernetes باستخدام werf .
من أجل البساطة والراحة (وكتحية تقديرية للأزياء) ، سنستمر في استدعاء هذه الخدمات الدقيقة للتطبيقات.
يتم تجميع كل هذه الخدمات المصغرة ونشرها وتشغيلها بنفس الطريقة ، ويتم تكوين إعدادات محددة باستخدام متغيرات البيئة.
من الواضح أن نسخ
.gitlab-ci.yml و
werf.yaml و
.helm يجلب الكثير من المشاكل. بعد كل شيء ، يجب إضافة أي تحرير في CI أو عملية التجميع أو وصف مخطط Helm إلى مستودعات أخرى ...
ربط القوالب في .gitlab-ci.yml
مع ظهور ما
include:file توجيه
include:file في GitLab CE (
منذ الإصدار 11.7 ) ، أصبح من الممكن إنشاء CI مشترك.
include ميزة "
include في وقت مبكر قليلاً (في الإصدار 11.4) ، ولكنها سمحت بتوصيل قوالب فقط من عناوين URL
العامة ، مما حد من وظائفها إلى حد ما. تصف وثائق GitLab
تمامًا جميع الميزات وأمثلة الاستخدام.
وبالتالي ، كان من الممكن رفض نسخ
.gitlab-ci.yml بين المستودعات ودعم أهميتها. فيما يلي مثال
.gitlab-ci.yml مع
include :
include: - project: 'infra/gitlab-ci' ref: 1.0.0 file: base-gitlab-ci.yaml - project: 'infra/gitlab-ci' ref: 1.0.0 file: cleanup.yaml
نوصي بشدة باستخدام أسماء الفروع في
ref بحذر . يتم احتساب ميزة التضمين في وقت إنشاء خط الأنابيب ، وبالتالي فإن تغييرات CI الخاصة بك قد تدخل تلقائيًا في خط أنابيب الإنتاج في اللحظة الأكثر أهمية. لكن
استخدام العلامات في ref يجعل من السهل إصدار وصف عمليات CI / CD. عند التحديث ، يبدو كل شيء شفافًا قدر الإمكان ويمكنك بسهولة تتبع محفوظات التغييرات في إصدارات خطوط الأنابيب إذا كنت تستخدم الإصدار الدلالي للعلامات.
ربط .helm من مستودع منفصل
نظرًا لنشر هذه الخدمات المصغرة وتشغيلها بنفس الطريقة ، فإن نفس مجموعة قوالب Helm مطلوبة. لتجنب نسخ دليل
.helm بين المستودعات ، اعتدنا استنساخ المستودع الذي تم فيه تخزين قوالب Helm والتحقق من العلامة المطلوبة. بدا الأمر مثل هذا:
- git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/infra/helm.git .helm - cd .helm && git checkout tags/1.0.0 - type multiwerf && source <(multiwerf use 1.0 beta) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf deploy --stages-storage :local
كانت هناك أيضًا اختلافات في استخدام وحدات فرعية git ، ولكن يبدو أن الأمر يبدو كأنه حل بديل ...
والآن مع إصدار werf الأخير ، تتوفر
لديه الفرصة لربط المخططات من المستودعات الخارجية. الدعم الكامل لوظائف مدير الحزم ، بدوره ، مكّن من وصف التبعيات لنشر التطبيق
بشفافية .
تسلسل الإجراءات
دعنا نعود إلى حل مشكلتنا مع خدمات microservices. دعنا نرفع
مستودعنا لتخزين مخططات Helm - على سبيل المثال ،
ChartMuseum . ينتشر بسهولة إلى مجموعة Kubernetes:
helm repo add stable https://kubernetes-charts.storage.googleapis.com helm install stable/chartmuseum --name flant-chartmuseum
إضافة دخول:
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/force-ssl-redirect: "false" nginx.ingress.kubernetes.io/proxy-body-size: 10m nginx.ingress.kubernetes.io/ssl-redirect: "false" name: chart-museum spec: rules: - host: flant-chartmuseum.example.net http: paths: - backend: serviceName: flant-chartmuseum servicePort: 8080 path: / status: loadBalancer: {}
flant-chartmuseum نشر
flant-chartmuseum إلى تغيير متغير البيئة
DISABLE_API إلى
false . وإلا (بشكل افتراضي) ، لن تعمل طلبات واجهة برمجة تطبيقات ChartMuseum ولن يكون من الممكن إنشاء مخططات جديدة.
نصف الآن المستودع الذي سيتم فيه تخزين مخططات Helm المشتركة. هيكل الدلائل على النحو التالي:
. ├── charts │ └── yii2-microservice │ ├── Chart.yaml │ └── templates │ ├── app.yaml └── README.md
قد تبدو
Chart.yaml مثل هذا:
name: yii2-microservice version: 1.0.4
يجب أن يحتوي دليل
templates على جميع Kubernetes البدائية اللازمة والتي ستلزم لنشر التطبيق على الكتلة. كما قد تكون خمنت بالفعل ، في هذه الحالة ، فإن microservice هو تطبيق PHP يعتمد على إطار yii2. دعنا نصف الحد الأدنى للنشر بحاويتين nginx و php-fpm التي تم إنشاؤها باستخدام werf:
--- apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Values.global.werf.name }} spec: replicas: 1 revisionHistoryLimit: 3 template: metadata: labels: service: {{ .Values.global.werf.name }} spec: imagePullSecrets: - name: registrysecret containers: - name: backend {{ tuple "backend" . | include "werf_container_image" | indent 8 }} command: [ '/usr/sbin/php-fpm7', "-F" ] ports: - containerPort: 9000 protocol: TCP name: http env: {{ tuple "backend" . | include "werf_container_env" | indent 8 }} - name: frontend command: ['/usr/sbin/nginx'] {{ tuple "frontend" . | include "werf_container_image" | indent 8 }} ports: - containerPort: 80 name: http lifecycle: preStop: exec: command: ["/usr/sbin/nginx", "-s", "quit"] env: {{ tuple "frontend" . | include "werf_container_env" | indent 8 }} --- apiVersion: v1 kind: Service metadata: name: {{ .Values.global.werf.name }} spec: selector: service: {{ .Values.global.werf.name }} ports: - name: http port: 80 protocol: TCP
يحتوي المتغير
.Values.global.werf.name على اسم المشروع من ملف
werf.yaml ، والذي يسمح لك بالحصول على الأسماء الضرورية للخدمات وعمليات النشر.
دعونا نجعل أبسط الأتمتة للدفع في ChartMuseum من المخططات لدينا عند الالتزام بالفرع الرئيسي. للقيام بذلك ، نصف
.gitlab-ci.yml :
Build and push to chartmuseum: script: - for i in $(ls charts); do helm package "charts/$i"; done; - for i in $(find . -type f -name "*.tgz" -printf "%f\n"); do curl --data-binary "@$i" http://flant-chartmuseum.example.net/api/charts; done; stage: build environment: name: infra only: - master tags: - my-shell-runner-tag
يتم إصدار المخططات عن طريق تغيير
version في
Chart.yaml . سيتم إضافة جميع المخططات الجديدة تلقائيًا إلى ChartMuseum.
نذهب إلى خط النهاية! في مستودع المشروع في
.helm/requirements.yaml نكتب تبعيات المخطط:
dependencies: - name: yii2-microservice version: "1.0.4" repository: "@flant"
... وتنفيذه في الدليل باستخدام المستودع:
werf helm repo init werf helm repo add flant http://flant-chartmuseum.example.net werf helm dependency update
.helm/requirements.lock عليه
.helm/requirements.lock . الآن ، لنشر التطبيق إلى الكتلة ، يكفي تشغيل الأمر
werf helm dependency build قبل تشغيل
werf deploy .
لتحديث وصف نشر التطبيق ، تحتاج الآن إلى استعراض مستودعات التخزين باستخدام الخدمات المصغرة وتطبيق تصحيحات صغيرة مع تغييرات على التجزئة والعلامات في
requirements.yaml و
requirements.lock . إذا رغبت في ذلك ، يمكن أيضًا تشغيل هذه العملية تلقائيًا من خلال CI: لقد سبق أن وصفنا كيفية القيام بذلك في
المقالة المذكورة .
استنتاج
آمل أن يكون تسلسل الإجراءات الموصوفة لخدمة التطبيقات المشابهة مفيدًا للمهندسين الذين يواجهون مشكلات مماثلة. وسنكون سعداء لتبادل وصفات عملية أخرى لاستخدام
werf . لذلك ، إذا كنت تواجه صعوبات تبدو غير قابلة للتغلب عليها أو ببساطة غير مفهومة للتنفيذ ، فلا تتردد في الاتصال بـ
Telegram أو ترك طلبات المواد المستقبلية هنا في التعليقات.
PS
اقرأ أيضًا في مدونتنا: