Kubernetes 팁 및 요령: 로컬 개발 및 Telepresence 정보

Kubernetes에서 마이크로서비스를 개발하는 것에 대한 요청이 점점 더 많아지고 있습니다. 특히 해석된 언어의 개발자는 자신이 선호하는 IDE에서 코드를 신속하게 수정하고 빌드/배포를 기다리지 않고 간단히 F5를 눌러 결과를 확인하기를 원합니다. 그리고 모놀리식 애플리케이션의 경우 데이터베이스와 웹 서버(Docker, VirtualBox...)를 로컬에 설치한 다음 즉시 개발을 즐기는 것만으로도 충분했습니다. 모놀리스를 마이크로서비스로 절단하고 Kubernetes가 등장하면서 서로에 대한 종속성이 나타나면서 모든 것이 좀 더 어려워졌어. 이러한 마이크로서비스가 많을수록 문제도 더 많아집니다. 다시 개발을 즐기려면 Docker 컨테이너를 XNUMX~XNUMX개 이상, 때로는 XNUMX개 이상 키워야 합니다... 일반적으로 이 모든 작업은 최신 상태로 유지해야 하기 때문에 꽤 많은 시간이 걸릴 수 있습니다. .

서로 다른 시기에 우리는 문제에 대해 서로 다른 해결책을 시도했습니다. 그리고 축적된 해결 방법 또는 간단히 "목발"부터 시작하겠습니다.

1. 목발

대부분의 IDE에는 FTP/SFTP를 사용하여 서버에서 직접 코드를 편집할 수 있는 기능이 있습니다. 이 경로는 매우 분명하므로 우리는 즉시 이 경로를 사용하기로 결정했습니다. 그 본질은 다음과 같이 요약됩니다.

1. 개발 환경(개발/검토) 포드에서는 SSH 액세스를 통해 추가 컨테이너가 시작되고 애플리케이션을 커밋/배포할 개발자의 공개 SSH 키를 전달합니다.
2. 초기화 단계(컨테이너 내) prepare-app) 코드를 다음으로 전송합니다. emptyDir애플리케이션 컨테이너와 SSH 서버의 코드에 액세스할 수 있습니다.

이러한 체계의 기술적 구현을 ​​더 잘 이해하기 위해 Kubernetes에서 관련된 YAML 구성의 일부를 제공하겠습니다.

구성

1.1. 값.yaml

ssh_pub_key:
  vasya.pupkin: <ssh public key in base64> 

여기에 vasya.pupkin 변수의 값입니다 ${GITLAB_USER_LOGIN}.

1.2. 배포.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. 비밀.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 }}

최종 터치

그 후 남은 것은 전송하는 것입니다 필수 gitlab-ci.yml 변수:

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

Voila: 배포를 시작한 개발자는 서비스 이름으로 연결할 수 있습니다(클러스터에 대한 액세스 권한을 안전하게 부여하는 방법, 우리는 이미 말했다) SFTP를 통해 데스크톱에서 코드가 클러스터에 전달될 때까지 기다리지 않고 코드를 편집할 수 있습니다.

이는 완벽하게 작동하는 솔루션이지만 구현 관점에서 볼 때 다음과 같은 명백한 단점이 있습니다.

• 나중에 읽기 어렵게 만드는 Helm 차트를 개선해야 할 필요성;
• 서비스를 배포한 사람만 사용할 수 있습니다.
• 그런 다음 코드를 사용하여 로컬 디렉터리와 동기화하고 Git에 커밋해야 합니다.

2. 텔레프레즌스

계획 텔레프레즌스 꽤 오랫동안 알려져 있었지만 우리는 "실제로 진지하게 시도하지 못했습니다"라고 말합니다. 그러나 수요는 제 역할을 했으며 이제 우리 블로그 독자들에게 유용할 수 있는 경험을 공유하게 되어 기쁘게 생각합니다. 특히 아직 허브에 Telepresence에 대한 다른 자료가 없었기 때문입니다.

요컨대 모든 것이 그렇게 무섭지 않은 것으로 나타났습니다. 우리는 개발자 측에서 실행이 필요한 모든 작업을 Helm 차트 텍스트 파일에 배치했습니다. NOTES.txt. 따라서 Kubernetes에 서비스를 배포한 후 개발자는 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
#########################################################################

마지막 단계를 제외하고 이 지침에 설명된 단계에 대해 자세히 설명하지 않겠습니다. Telepresence가 출시되는 동안 어떤 일이 발생하나요?

텔레프레즌스 작업

시작 시(위 지침에 지정된 마지막 명령 사용) 다음을 설정합니다.

• 마이크로서비스가 실행되는 네임스페이스
• 침투하려는 배포 및 컨테이너의 이름입니다.

나머지 인수는 선택 사항입니다. 우리 서비스가 Kubernetes API와 상호 작용하는 경우 서비스 계정이 생성되었습니다., 데스크탑에 인증서/토큰을 마운트해야 합니다. 이렇게 하려면 옵션을 사용하십시오. --mount=true (또는 --mount=/dst_path), 그러면 Kubernetes 컨테이너의 루트(/)가 데스크탑에 마운트됩니다. 그런 다음 (OS 및 애플리케이션 시작 방법에 따라) 클러스터의 "키"를 사용할 수 있습니다.

먼저 Docker 컨테이너에서 애플리케이션을 실행하기 위한 가장 보편적인 옵션을 살펴보겠습니다. 이를 위해 우리는 키를 사용할 것입니다 --docker-run 코드가 포함된 디렉터리를 컨테이너에 마운트합니다. -v `pwd`:/app

이는 프로젝트 디렉터리에서 실행된다고 가정합니다. 애플리케이션 코드는 디렉터리에 마운트됩니다. /app 컨테이너에.

다음 : -v /tmp/app/var/run/secrets:/var/run/secrets — 인증서/토큰이 있는 디렉터리를 컨테이너에 마운트합니다.

이 옵션 뒤에는 마지막으로 애플리케이션이 실행될 이미지가 옵니다. NB: 이미지를 빌드할 때 다음을 지정해야 합니다. CMD 또는 ENTRYPOINT!

다음에 정확히 무슨 일이 일어날까요?

• Kubernetes에서는 지정된 배포에 대해 복제본 수가 0으로 변경됩니다. 대신 대체 컨테이너를 사용하여 새 배포가 시작됩니다. backend.
• 2개의 컨테이너가 데스크톱에서 실행됩니다. 첫 번째는 Telepresence(Kubernetes와의 요청을 프록시 처리함)를 사용하고, 두 번째는 개발 중인 애플리케이션을 사용합니다.
• 애플리케이션을 사용하여 컨테이너에 실행하면 배포 중에 Helm이 전송한 모든 ENV 변수를 사용할 수 있으며 모든 서비스도 사용할 수 있습니다. 남은 것은 즐겨 사용하는 IDE에서 코드를 편집하고 결과를 즐기는 것뿐입니다.
• 작업이 끝나면 Telepresence가 실행 중인 터미널을 닫으면 됩니다(Ctrl+C를 사용하여 세션 종료). Docker 컨테이너는 데스크톱에서 중지되고 Kubernetes에서는 모든 것이 초기 상태로 돌아갑니다. 남은 것은 커밋하고, MR을 발행하고 이를 검토/병합/…으로 전송하는 것입니다(워크플로에 따라 다름).

Docker 컨테이너에서 애플리케이션을 실행하고 싶지 않은 경우(예를 들어 PHP가 아닌 Go에서 개발하고 여전히 로컬로 빌드하는 경우) Telepresence를 시작하는 것이 훨씬 더 간단할 것입니다.

telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=true

애플리케이션이 Kubernetes API에 액세스하는 경우 키 디렉터리(https://www.telepresence.io/howto/volumes)를 마운트해야 합니다. Linux 용 유틸리티가 있습니다 뿌리:

proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash

옵션 없이 Telepresence를 시작한 후 --docker-run 모든 환경 변수는 현재 터미널에서 사용할 수 있으므로 해당 터미널에서 애플리케이션을 시작해야 합니다.

NB: 예를 들어 PHP를 사용하는 경우 개발을 위해 다양한 op_cache, apc 및 기타 가속기를 비활성화해야 합니다. 그렇지 않으면 코드를 편집해도 원하는 결과를 얻을 수 없습니다.

결과

Kubernetes를 사용한 로컬 개발은 이 플랫폼의 확산에 비례하여 솔루션이 성장하는 문제입니다. 개발자(클라이언트)로부터 관련 요청을 받은 후 우리는 가능한 첫 번째 수단으로 문제를 해결하기 시작했지만 장기적으로 입증되지 않았습니다. 다행스럽게도 이것은 지금뿐만 아니라 우리에게도 분명해 졌기 때문에 더 적합한 수단이 이미 세상에 등장했으며 그 중 Telepresence가 가장 유명합니다 (그런데 발판 Google에서). 우리의 사용 경험은 아직 그렇게 훌륭하지는 않지만 이미 "가게의 동료"에게 추천할 이유를 제공합니다. 사용해 보세요!

PS

기타 K8s 팁 및 요령 시리즈:

• «Kubernetes 팁 및 요령: NGINX Ingress의 사용자 지정 오류 페이지";
• «클러스터에서 실행 중인 리소스를 Helm 2 관리로 전송";
• «웹 애플리케이션의 노드 할당 및 로드 정보";
• «개발 사이트에 대한 액세스";
• «대규모 데이터베이스의 부트스트랩 속도 향상".

출처 : habr.com