Chúng tôi ngày càng nhận được nhiều câu hỏi hơn về việc phát triển vi dịch vụ trong Kubernetes. Các nhà phát triển, đặc biệt là các ngôn ngữ thông dịch, muốn nhanh chóng sửa mã trong IDE yêu thích của họ và xem kết quả mà không cần chờ xây dựng/triển khai - chỉ cần nhấn F5. Và khi nói đến một ứng dụng nguyên khối, chỉ cần cài đặt cục bộ cơ sở dữ liệu và máy chủ web (trong Docker, VirtualBox...), sau đó ngay lập tức tận hưởng quá trình phát triển. Với việc cắt các khối nguyên khối thành microservice và sự xuất hiện của Kubernetes, với sự xuất hiện của sự phụ thuộc lẫn nhau, mọi thứ đều . Càng nhiều microservice này thì càng có nhiều vấn đề. Để tận hưởng sự phát triển trở lại, bạn cần phải nâng cao nhiều hơn một hoặc hai vùng chứa Docker, và đôi khi thậm chí hơn một chục... Nói chung, tất cả điều này có thể mất khá nhiều thời gian, vì nó cũng cần được cập nhật .
Vào những thời điểm khác nhau, chúng tôi đã thử những giải pháp khác nhau cho vấn đề. Và tôi sẽ bắt đầu với những cách giải quyết tích lũy được hoặc đơn giản là “nạng”.
1. Nạng
Hầu hết các IDE đều có khả năng chỉnh sửa mã trực tiếp trên máy chủ bằng FTP/SFTP. Con đường này rất rõ ràng và chúng tôi ngay lập tức quyết định sử dụng nó. Bản chất của nó tóm tắt như sau:
- Trong nhóm môi trường phát triển (dev/review), một vùng chứa bổ sung được khởi chạy với quyền truy cập SSH và chuyển tiếp khóa SSH công khai của nhà phát triển, người sẽ cam kết/triển khai ứng dụng.
- Ở giai đoạn init (trong vùng chứa
prepare-app) chuyển mã tớiemptyDirđể có quyền truy cập vào mã từ vùng chứa ứng dụng và máy chủ SSH.
Để hiểu rõ hơn về cách triển khai kỹ thuật của sơ đồ như vậy, tôi sẽ cung cấp các đoạn cấu hình YAML liên quan trong Kubernetes.
Cấu hình
1.1. giá trị.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Здесь vasya.pupkin là giá trị của biến ${GITLAB_USER_LOGIN}.
1.2. triển khai.yaml
...
{{ if eq .Values.global.debug "yes" }}
volumes:
- name: ssh-pub-key
secret:
defaultMode: 0600
secretName: {{ .Chart.Name }}-ssh-pub-key
- name: app-data
emptyDir: {}
initContainers:
- name: prepare-app
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
volumeMounts:
- name: app-data
mountPath: /app-data
command: ["bash", "-c", "cp -ar /app/* /app-data/" ]
{{ end }}
containers:
{{ if eq .Values.global.debug "yes" }}
- name: ssh
image: corbinu/ssh-server
volumeMounts:
- name: ssh-pub-key
readOnly: true
mountPath: /root/.ssh/authorized_keys
subPath: authorized_keys
- name: app-data
mountPath: /app
ports:
- name: ssh
containerPort: 22
protocol: TCP
{{ end }}
- name: backend
volumeMounts:
{{ if eq .Values.global.debug "yes" }}
- name: app-data
mountPath: /app
{{ end }}
command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"]
...
1.3. bí mật.yaml
{{ if eq .Values.global.debug "yes" }}
apiVersion: v1
kind: Secret
metadata:
name: {{ .Chart.Name }}-ssh-pub-key
type: Opaque
data:
authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}"
{{ end }}
Liên lạc cuối cùng
Sau đó tất cả những gì còn lại là chuyển :
dev:
stage: deploy
script:
- type multiwerf && source <(multiwerf use 1.0 beta)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf deploy
--namespace ${CI_PROJECT_NAME}-stage
--set "global.env=stage"
--set "global.git_rev=${CI_COMMIT_SHA}"
--set "global.debug=yes"
--set "global.username=${GITLAB_USER_LOGIN}"
tags:
- build
Thì đấy: nhà phát triển đã triển khai triển khai có thể kết nối theo tên dịch vụ (cách cấp quyền truy cập vào cụm một cách an toàn, ) từ máy tính để bàn của bạn thông qua SFTP và chỉnh sửa mã mà không cần đợi mã được gửi đến cụm.
Đây là một giải pháp hoàn toàn hiệu quả, nhưng từ quan điểm triển khai, nó có những nhược điểm rõ ràng:
- nhu cầu tinh chỉnh biểu đồ Helm, điều này gây khó đọc trong tương lai;
- chỉ có thể được sử dụng bởi người triển khai dịch vụ;
- sau đó bạn cần nhớ đồng bộ hóa nó với thư mục cục bộ với mã và cam kết nó với Git.
2. Thần giao cách cảm
Dự án đã được biết đến từ khá lâu, nhưng như người ta nói, chúng tôi “chưa bắt tay vào thử nghiệm nó một cách nghiêm túc trên thực tế”. Tuy nhiên, nhu cầu đã hoàn thành nhiệm vụ của nó và giờ đây chúng tôi rất vui được chia sẻ kinh nghiệm của mình, điều này có thể hữu ích cho độc giả blog của chúng tôi - đặc biệt là vì chưa có tài liệu nào khác về Hiện diện từ xa trên trung tâm.
Nói tóm lại, mọi thứ hóa ra không quá đáng sợ. Chúng tôi đã đặt tất cả các hành động yêu cầu thực thi từ phía nhà phát triển trong tệp văn bản biểu đồ Helm có tên NOTES.txt. Do đó, sau khi triển khai dịch vụ lên Kubernetes, nhà phát triển sẽ thấy hướng dẫn khởi chạy môi trường nhà phát triển cục bộ trong nhật ký công việc GitLab:
!!! Разработка сервиса локально, в составе Kubernetes !!!
* Настройка окружения
* * Должен быть доступ до кластера через VPN
* * На локальном ПК установлен kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ )
* * Получить config-файл для kubectl (скопировать в ~/.kube/config)
* * На локальном ПК установлен telepresence ( https://www.telepresence.io/reference/install )
* * Должен быть установлен Docker
* * Необходим доступ уровня reporter или выше к репозиторию https://gitlab.site.com/group/app
* * Необходимо залогинится в registry с логином/паролем от GitLab (делается один раз):
#########################################################################
docker login registry.site.com
#########################################################################
* Запуск окружения
#########################################################################
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8
#########################################################################Chúng tôi sẽ không đi sâu vào chi tiết các bước được mô tả trong hướng dẫn này... ngoại trừ bước cuối cùng. Điều gì xảy ra trong quá trình ra mắt Telepresence?
Làm việc với Telepresence
Khi khởi động (sử dụng lệnh cuối cùng được chỉ định trong hướng dẫn ở trên), chúng tôi đặt:
- không gian tên nơi microservice đang chạy;
- tên của triển khai và vùng chứa mà chúng tôi muốn thâm nhập.
Các đối số còn lại là tùy chọn. Nếu dịch vụ của chúng tôi tương tác với và với API Kubernetes , chúng ta cần gắn chứng chỉ/mã thông báo trên máy tính để bàn của mình. Để thực hiện việc này, hãy sử dụng tùy chọn --mount=true (hoặc --mount=/dst_path), thao tác này sẽ gắn root (/) từ vùng chứa Kubernetes vào màn hình của chúng ta. Sau này, chúng ta có thể (tùy thuộc vào hệ điều hành và cách ứng dụng được khởi chạy) sử dụng các “phím” từ cụm.
Trước tiên, hãy xem tùy chọn phổ biến nhất để chạy một ứng dụng - trong vùng chứa Docker. Để làm điều này chúng ta sẽ sử dụng phím --docker-run và gắn thư mục có mã vào vùng chứa: -v `pwd`:/app
Xin lưu ý rằng điều này giả định chạy từ thư mục dự án. Mã ứng dụng sẽ được gắn vào thư mục /app trong một thùng chứa.
Tiếp theo: -v /tmp/app/var/run/secrets:/var/run/secrets - để gắn thư mục có chứng chỉ/mã thông báo vào vùng chứa.
Tùy chọn này cuối cùng được theo sau bởi hình ảnh mà ứng dụng sẽ chạy. NB: Khi xây dựng một hình ảnh, bạn phải chỉ định CMD hoặc ENTRYPOINT!
Chính xác thì điều gì sẽ xảy ra tiếp theo?
- Trong Kubernetes, đối với Triển khai được chỉ định, số lượng bản sao sẽ được thay đổi thành 0. Thay vào đó, một Triển khai mới sẽ được khởi chạy - với một vùng chứa thay thế
backend. - 2 vùng chứa sẽ khởi chạy trên máy tính để bàn: vùng chứa đầu tiên có Telepresence (nó sẽ ủy quyền các yêu cầu từ/đến Kubernetes), vùng chứa thứ hai với ứng dụng đang được phát triển.
- Nếu chúng tôi thực thi vào vùng chứa ứng dụng thì tất cả các biến ENV được Helm chuyển trong quá trình triển khai sẽ có sẵn cho chúng tôi và tất cả các dịch vụ cũng sẽ có sẵn. Tất cả những gì còn lại là chỉnh sửa mã trong IDE yêu thích của bạn và tận hưởng thành quả.
- Khi kết thúc công việc, bạn chỉ cần đóng thiết bị đầu cuối đang chạy Telepresence (kết thúc phiên bằng Ctrl+C) - Các vùng chứa Docker sẽ dừng trên màn hình và trong Kubernetes, mọi thứ sẽ trở về trạng thái ban đầu. Tất cả những gì còn lại là cam kết, cấp MR và chuyển nó đi xem xét/hợp nhất/… (tùy thuộc vào quy trình làm việc của bạn).
Nếu chúng tôi không muốn chạy ứng dụng trong vùng chứa Docker - ví dụ: chúng tôi phát triển không phải bằng PHP mà bằng Go và vẫn xây dựng ứng dụng cục bộ - việc khởi chạy Telepresence sẽ còn đơn giản hơn:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueNếu ứng dụng truy cập API Kubernetes, bạn sẽ cần gắn thư mục khóa (https://www.telepresence.io/howto/volumes). Có tiện ích dành cho Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Sau khi khởi chạy Telepresence mà không có tùy chọn --docker-run tất cả các biến môi trường sẽ có sẵn trong thiết bị đầu cuối hiện tại, vì vậy ứng dụng phải được khởi chạy trong thiết bị đầu cuối đó.
NB: Ví dụ: khi sử dụng PHP, bạn phải nhớ tắt nhiều op_cache, apc và các trình tăng tốc khác để phát triển - nếu không việc chỉnh sửa mã sẽ không dẫn đến kết quả mong muốn.
Kết quả
Phát triển cục bộ với Kubernetes là một vấn đề mà giải pháp đang ngày càng phát triển tương ứng với sự lan rộng của nền tảng này. Nhận được các yêu cầu liên quan từ các nhà phát triển (từ khách hàng của chúng tôi), chúng tôi bắt đầu giải quyết chúng bằng các phương tiện sẵn có đầu tiên, tuy nhiên, điều này đã không chứng tỏ được bản thân trong một thời gian dài. May mắn thay, điều này đã trở nên rõ ràng không chỉ bây giờ và không chỉ với chúng ta, vì vậy, các phương tiện phù hợp hơn đã xuất hiện trên thế giới và Telepresence là phương tiện nổi tiếng nhất trong số đó (nhân tiện, cũng có từ Google). Trải nghiệm sử dụng nó của chúng tôi chưa quá tuyệt vời nhưng nó đã cho chúng tôi lý do để giới thiệu nó với “đồng nghiệp trong cửa hàng” của chúng tôi - hãy dùng thử!
PS
Khác với loạt mẹo & thủ thuật K8s:
- «»;
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com