Dua tahun lalu kami menerbitkan artikel "
Membangun proyek dengan GitLab CI: satu .gitlab-ci.yml untuk ratusan aplikasi ", dan sekarang kita akan berbicara tentang memecahkan masalah yang sama hari ini. Materi baru adalah tentang bagaimana Anda dapat membangun proses CI / CD untuk sejumlah besar aplikasi serupa dengan munculnya
include di
.gitlab-ci.yml dan munculnya werf untuk menggantikan dapp.
Pendahuluan
Dalam instruksi lebih lanjut yang diberikan dalam artikel, situasi berikut dipertimbangkan:
- Ada aplikasi klien besar, yang terbagi dalam banyak repositori.
- Setiap repositori adalah aplikasi terpisah yang harus dijalankan di cluster Kubernetes.
- Sebagai sistem CI, GitLab CI digunakan.
- Deployment (infrastruktur di mana kode ini digunakan) dijelaskan oleh grafik Helm.
- Buat gambar dan gunakan di Kubernet menggunakan werf .
Untuk kesederhanaan dan kenyamanan (dan sebagai penghargaan untuk fashion), kami akan terus menyebut aplikasi ini sebagai layanan microser.
Semua layanan Microsoft ini dirakit, digunakan, dan diluncurkan dengan cara yang sama , dan pengaturan khusus dikonfigurasikan menggunakan variabel lingkungan.
Jelas, menyalin
.gitlab-ci.yml ,
werf.yaml dan
.helm membawa banyak masalah. Bagaimanapun, setiap pengeditan dalam CI, proses perakitan atau deskripsi dari Helm-chart harus ditambahkan ke repositori lain ...
Menghubungkan template di .gitlab-ci.yml
Dengan munculnya
include:file directive
include:file di GitLab CE (
sejak versi 11.7 ), menjadi mungkin untuk membuat CI umum.
include sendiri muncul sedikit lebih awal (pada 11.4), tetapi itu memungkinkan menghubungkan templat hanya dari URL
publik , yang agak membatasi fungsinya. Dokumentasi GitLab dengan
sempurna menggambarkan semua fitur dan contoh penggunaan.
Dengan demikian, adalah mungkin untuk menolak menyalin
.gitlab-ci.yml antara repositori dan mendukung relevansinya. Berikut adalah contoh
.gitlab-ci.yml dengan
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
Kami sangat menyarankan Anda menggunakan nama cabang dalam
ref dengan hati-hati . Penyertaan dihitung pada saat pipa dibuat, sehingga perubahan CI Anda dapat secara otomatis jatuh ke dalam pipa produksi pada saat yang paling tidak tepat. Tetapi
penggunaan tag dalam ref memudahkan untuk versi deskripsi proses CI / CD. Saat memperbarui, semuanya tampak setransparan mungkin dan Anda dapat dengan mudah melacak riwayat perubahan dalam versi pipa jika Anda menggunakan versi semantik untuk tag.
Hubungkan .helm dari repositori terpisah
Karena layanan microser ini digunakan dan dijalankan dengan cara yang sama, set templat Helm yang sama diperlukan. Untuk menghindari penyalinan direktori
.helm antara repositori, kami biasa mengkloning repositori tempat templat Helm disimpan dan diperiksa pada tag yang diinginkan. Itu terlihat seperti ini:
- 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
Ada juga variasi menggunakan submitules git, tetapi semuanya tampak lebih seperti solusi ...
Dan sekarang dengan rilis werf baru-baru ini, ia
memiliki kesempatan untuk menghubungkan grafik dari repositori eksternal. Dukungan penuh untuk fungsi-fungsi manajer paket, pada gilirannya, memungkinkan untuk menjelaskan dependensi untuk penyebaran aplikasi secara
transparan .
Urutan tindakan
Mari kita kembali menyelesaikan masalah kita dengan layanan microser. Mari tingkatkan repositori kami untuk menyimpan grafik Helm - misalnya,
ChartMuseum . Itu mudah menyebar ke cluster Kubernetes:
helm repo add stable https://kubernetes-charts.storage.googleapis.com helm install stable/chartmuseum --name flant-chartmuseum
Tambahkan masuk:
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: {}
Penempatan
flant-chartmuseum perlu mengubah variabel lingkungan
DISABLE_API menjadi
false . Jika tidak (secara default), permintaan API ChartMuseum tidak akan berfungsi dan tidak mungkin membuat bagan baru.
Sekarang kami menjelaskan repositori di mana grafik Helm bersama akan disimpan. Struktur direktori-nya adalah sebagai berikut:
. ├── charts │ └── yii2-microservice │ ├── Chart.yaml │ └── templates │ ├── app.yaml └── README.md
Chart.yaml mungkin terlihat seperti ini:
name: yii2-microservice version: 1.0.4
Direktori
templates harus berisi semua primitif Kubernetes yang diperlukan yang akan diperlukan untuk menyebarkan aplikasi ke cluster. Seperti yang mungkin sudah Anda tebak, dalam hal ini, microservice adalah aplikasi PHP berdasarkan kerangka kerja yii2. Mari kita jelaskan Penempatan minimalnya dengan dua kontainer nginx dan php-fpm yang dibangun menggunakan 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
Variabel
.Values.global.werf.name berisi nama proyek dari file
werf.yaml , yang memungkinkan Anda mendapatkan nama layanan dan Penyebaran yang diperlukan.
Mari kita buat otomatisasi paling sederhana untuk mendorong ChartMuseum dari grafik kita ketika berkomitmen ke cabang utama. Untuk melakukan ini, kami jelaskan
.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
Bagan diversi dengan mengubah
version di
Chart.yaml . Semua grafik baru akan ditambahkan secara otomatis ke ChartMuseum.
Kami pergi ke garis finish! Dalam repositori proyek di
.helm/requirements.yaml menulis dependensi untuk bagan:
dependencies: - name: yii2-microservice version: "1.0.4" repository: "@flant"
... dan jalankan di direktori dengan repositori:
werf helm repo init werf helm repo add flant http://flant-chartmuseum.example.net werf helm dependency update
Kami
.helm/requirements.lock di dalamnya.
.helm/requirements.lock . Buka. Sekarang, untuk menyebarkan aplikasi ke cluster, itu sudah cukup untuk menjalankan
werf helm dependency build sebelum menjalankan
werf deploy .
Untuk memperbarui deskripsi penyebaran aplikasi, Anda sekarang harus melalui repositori dengan layanan microser dan menerapkan tambalan kecil dengan perubahan pada hash dan tag di
requirements.yaml dan
requirements.lock . Jika diinginkan, operasi ini juga dapat diotomatisasi melalui CI: kami telah menjelaskan cara melakukan ini di
artikel yang disebutkan .
Kesimpulan
Saya harap urutan tindakan yang dijelaskan untuk melayani aplikasi serupa akan bermanfaat bagi insinyur yang menghadapi masalah serupa. Dan kami akan dengan senang hati membagikan resep praktis lainnya untuk menggunakan
werf . Karena itu, jika Anda memiliki kesulitan yang tampaknya tidak dapat diatasi atau hanya tidak dapat diimplementasikan, jangan ragu untuk menghubungi
Telegram atau meninggalkan permintaan untuk materi mendatang di sini di komentar.
PS
Baca juga di blog kami: