이전 블로그에서 자체 하드웨어에 로컬로 Couchbase 클러스터를 설정하는 방법에 대해 설명했습니다. 이 방법의 장점은 테스트 인프라의 총 소유 비용과 새로운 테스트 인프라를 확보하는 데 필요한 시간을 크게 줄일 수 있다는 점이며, 이는 Couchbase를 막 시작하는 경우 특히 중요합니다.
모든 사람이 동일한 출발점에 도달할 수 있도록 합니다, 이전 블로그에 대한 링크는 다음과 같습니다.에서 Kubernetes용 Couchbase 자율 운영자를 사용하여 로컬에서 개발 클러스터를 빠르게 스핀업하는 방법을 살펴봤습니다.
그렇다면 이제부터는 어디로 가야 할까요? 애플리케이션 배포를 모방하여 쉽게 배포할 수 있는 환경을 구축하는 것이 유일한 자연스러운 경로입니다. 이는 최소한의 노력으로 로컬에서 배포를 개발하고 테스트할 수 있는 올바른 방향으로 나아가는 또 다른 중요한 단계가 될 것입니다.
더욱 간편한 배포
에서 설명한 배포 방법을 간소화했습니다. 이전 블로그물론 우리가 배포할 카우치베이스 오퍼레이터의 구성 요소를 이해하는 것이 중요하므로 아직 읽어보지 않았다면 이전 블로그를 참고하시기 바랍니다.
이 새로운 배포 방법은 운영자-gitops 저장소 (그리고 더 구체적으로는 환상적인 패트릭 스티븐스)가 유지 관리합니다. 이제 로컬에 Couchbase 클러스터를 배포하기 위해 해야 할 유일한 작업은 create-cluster.sh 스크립트를 추가합니다. 이 작업이 완료되면 create-dev.sh 스크립트만 추가하면 됩니다. 이렇게 하면 Couchbase 애플리케이션 기능을 테스트하는 데 필요한 모든 것을 (인프라 측면에서) 갖추게 됩니다.
개발 배포 분석
실용적인 기술 가이드가 될 수 있도록 다음 섹션에서는 다음과 같은 내용을 자세히 설명합니다. create-dev.sh 스크립트.
도커파일
제가 개발자였을 때는 개발 및 테스트 환경을 직접 유지 관리해야 했습니다. 자동화할 수 있는 방법이 많지 않았기 때문에 이러한 환경을 유지 관리하는 것은 악몽과도 같았습니다. 새 릴리스가 출시되면 자연스럽게 코드가 변경되었습니다. 다행히도 이 모든 것이 바뀌었고, 다음에서 일반적인 Node.js SDK 자동화 예시를 보여드리겠습니다. 도커파일 에서 운영자-gitops 저장소. 이 블로그 게시물은 여러분의 환경에서 이를 재현할 수 있도록 이를 소개합니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
FROM 노드:16.9.1 # 이미지를 최신 패키지로 업데이트하고 네트워크 테스트 도구를 받으세요. # VIM 설치 - 원하는 편집기로 변경 - 야만인이 키워서 죄송합니다. RUN apt-get 업데이트 && \ apt-get -y 설치 git 아이피툴-ping iproute2 vim && \ mkdir -p /사용자/앱 # 다른 모든 명령이 일관된 작업 디렉터리에서 실행될 수 있도록 기존 디렉터리를 지정해야 합니다. WORKDIR /usr/앱 # SDK 가이드 설치 단계 # SDK를 시작하려면 다음 단계를 따르세요: # https://docs.couchbase.com/nodejs-sdk/current/hello-world/start-using-sdk.html RUN npm init -y && npm 설치 카우치베이스 --저장 # 해킹으로 잠자기 상태로 전환하여 첨부하기 CMD ["sleep","3600"] |
한 줄씩 살펴보겠습니다:
- FROM 노드:16.9.1 - 이것은 Node.js에서 제공하는 기본 이미지이므로 설치에 대해 걱정할 필요가 없습니다(무엇보다도).
- RUN apt-get ... - 개발 환경과 Couchbase 배포 간의 연결을 테스트하기 위한 도구를 설치하는 일련의 명령어입니다.
- WORKDIR /usr/app - 여기서는 도커파일에서 다음 명령이 항상 사용할 디렉터리를 설정합니다. 또한 컨테이너로 셸을 실행할 때 해당 경로로 이동하도록 진입 경로를 설정합니다.
- RUN npm init -y && npm install couchbase -save - 이렇게 하면 문서의 지침에 따라 Couchbase SDK가 설치됩니다.
- CMD ["sleep","3600″] - 이것은 우리가 첨부할 수 있도록 컨테이너를 살리기 위한 해킹입니다.
이러한 공유 개념은 다른 Couchbase SDK에도 적용됩니다. 관련 기본 이미지를 찾고, 도구를 설치하고, 작업 디렉토리를 설정하고, Couchbase SDK를 설치하고, 코드를 첨부하고 테스트할 수 있도록 무언가를 설정합니다.
1 2 |
도커 빌드 -t "${DEV_IMAGE}" . 종류 load 도커-이미지 "${DEV_IMAGE}" --이름="${CLUSTER_NAME}" |
자동 개발 환경 배포에서 가장 먼저 수행되는 작업은 docker파일에 지정된 Docker 이미지를 빌드하고 KIND(Kubernetes in Docker)에 이미지를 미리 로드하는 것입니다.
개발 쿠버네티스 배포
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
# 개발 컨테이너 이미지에 대한 배포를 생성합니다. cat << EOF | kubectl 신청하기 -f - apiVersion: 앱/v1 종류: 배포 메타데이터: 이름: 카우치베이스-sdk-dev 네임스페이스: $네임스페이스 사양: 선택기: matchLabels: couchSdk: "dev" 템플릿: 메타데이터: 레이블: couchSdk: "dev" 환경: "dev" 사양: 컨테이너: - 이름: dev-컨테이너 이미지: $DEV_IMAGE 이미지 풀 정책: 절대로 환경: - 이름: CB_HOST 값: $CB_서비스 # https://kubernetes.io/docs/concepts/configuration/secret/#environment-variables-are-not-updated-after-a-secret-update - 이름: CB_USER valueFrom: secretKeyRef: 이름: $인증_비밀 키: 사용자 이름 - 이름: CB_PSWD valueFrom: secretKeyRef: 이름: $인증_비밀 키: 비밀번호 EOF # 아무것도 변경하지 않으면 이전 실행에서 배포된 상태로 유지된다는 점에 유의하세요. |
이제 새로 생성된 컨테이너 이미지는 시스템에서 컨테이너를 배포하고 확장하는 Kubernetes 배포에서 활용할 수 있습니다. 컨테이너의 배포된 파드가 실패하면 Kubernetes 배포 컨트롤러가 이를 감지하고 새 인스턴스를 실행합니다.
저희는 create-dev.sh 스크립트 내에 멋지고 간단한 배포 정의를 제공하여 Docker 이미지를 사용하고 몇 가지 간단한 레이블을 첨부하여 kubectl로 배포를 관리할 수 있도록 했습니다.
배포 롤아웃
1 2 3 4 5 6 7 8 9 10 |
echo "개발 배포가 시작되기를 기다리는 중..." 까지 kubectl 롤아웃 상태 배포/카우치베이스-sdk-dev; do echo -n '.' 수면 2 완료 echo "개발 배포가 구성되고 준비 완료" # 개발 파드의 이름을 출력합니다. DEV_POD=$(kubectl get 포드 -l couchSdk=dev --출력=jsonpath='{.items[*].메타데이터.이름}') echo "개발자 포드 이름: $DEV_POD" |
배포 정의를 롤아웃하지 않으면 정의로만 남게 됩니다. 다음 단계는 롤아웃을 수행하고 코드를 푸시할 수 있도록 포드 이름을 제시하는 것입니다.
컨테이너에서 코드 실행
이 단계에서는 create-dev.sh 스크립트를 성공적으로 실행했습니다. 이제 코드를 컨테이너로 가져와서 테스트하는 작업이 남았습니다. 여기 몇 가지 명령어를 통해 코드를 컨테이너로 가져온 다음 셸을 열 수 있습니다.
1 |
kubectl cp /사용자/samredman/dev/노드-카우치베이스 프로젝트 $dev_pod_name_outputed:/usr/앱 |
이것은 단지 예시일 뿐이지만 개념은 동일하게 유지되어야 합니다. 여기서는 Couchbase SDK 코드 디렉토리를 가져와 새로 만든 개발 포드에 복사합니다("개발 포드 이름: X"라는 에코 출력을 받는 것을 잊지 마세요).
1 |
kubectl exec --stdin --tty 카우치베이스-sdk-dev-6bfbf76b7-zxln2 -- /bin/bash |
이 명령은 컨테이너 내의 셸로 이동합니다. 프롬프트에서 경로가 변경되는 것을 볼 수 있습니다. 여기에서 "kubectl cp" 명령으로 복사한 코드를 실행할 수 있습니다.
맛있는 샘플 코드
SDK 문서와 동일한 패턴을 따르는 작은 샘플 스크립트를 제공했습니다. SDK 문서는 Couchbase 애플리케이션의 구성 요소에 대한 Couchbase 개념을 설명하는 데 매우 유용합니다.
연결해야 하는 올바른 엔드포인트를 결정하는 데 도움이 되는 이 설명서를 참고하세요. 여기서 핵심은 클러스터 배포에 정의된 클러스터 이름에 -srv를 추가하는 것입니다. 문서를 인용하면 다음과 같습니다: "서비스 이름은 -srv 형식입니다."
스크립트 상단에서 사용할 수 있는 몇 가지 구성은 헬름의 기본 배포에 대해 동일하게 유지되어야 한다. 스크립트에 사용된 연결 자격 증명이 다음 명령의 출력과 일치하는지 확인한다: helm get all couchbase
어쨌든 구성 옵션이 기대에 부합하는지 확인해야 합니다. 코드가 거짓말을 하지 않는다는 점을 기억하세요. 연결이 되지 않는다면 올바른 연결 방법을 알려주지 않았을 가능성이 높습니다. 그러나 기본값에서 벗어나는 변경을 하는 경우에는 클러스터 이름, 버킷 및 인증 자격 증명을 변경해야 한다는 점을 잊지 마세요.
결론
이 블로그를 마치면 모의 환경이 아닌 실제 Couchbase 클러스터에서 Couchbase SDK 코드를 테스트할 수 있도록 완전히 구성된 개발 환경을 갖추게 될 것입니다! 자동화를 통해 제가 개발자로 일할 때처럼 개발 환경을 관리하는 대신 코드 작성에 더 많은 시간을 할애할 수 있기를 바랍니다.
이 게시물에 사용된 리소스에 대한 직접 링크는 다음과 같습니다:
- 블로그: 카우치베이스 자율 운영자 개념 증명 구축 방법
- 도구: 헬름과 KIND를 사용한 카우치베이스 오퍼레이터 배포
- 카우치베이스 운영자-gitops 리포지토리
- create-cluster.sh 그리고 create-dev.sh 스크립트
- 도커파일 카우치베이스 Node.js SDK용
- 샘플 Couchbase Node.js SDK 스크립트
- 문서: Couchbase SDK 설치