몇 달 전에 저는 Node.js 및 Jenkins로 지속적 배포 파이프라인 만들기에서 Node.js 애플리케이션이 사용하던 카우치베이스 어떤 방식으로든요. 기본적으로 GitHub에서 프로젝트를 가져와 종속 요소를 설치하고 테스트를 실행한 다음 일부 서버에서 애플리케이션을 실행했는데, 일부 서버는 Jenkins가 사용하던 컴퓨터와 동일한 서버였습니다.
Jenkins는 훌륭하지만 설정하고 계속 사용하기에는 많은 작업이 필요합니다. 대신 다음과 같은 호스팅된 지속적 통합(CI) 및 지속적 배포(CD) 솔루션이 있습니다. CircleCI.
GitHub에서 버전이 관리되는 Node.js 프로젝트를 가져와서 푸시가 이루어질 때마다 CircleCI를 사용하여 원격 서버에 지속적으로 배포하는 방법을 살펴보겠습니다.
계속하기 전에 이미 CircleCI 계정을 생성하고 원격 서버를 사용할 수 있어야 하며 GitHub에 Node.js 프로젝트가 있어야 합니다.
이 예제에서는 다음에서 만든 드롭렛을 사용하고 있습니다. 디지털 오션 및 Node.js 사용자 프로필 저장소 프로젝트 얼마 전에 쓴 적이 있습니다. 원하는 대로 자유롭게 사용하세요.
SSH 연결을 위한 원격 서버 준비하기
지속적 배포의 목표는 안정적인 프로젝트를 서버에 원활하게 자동으로 배포하는 것입니다.
CircleCI를 사용할 때 배포 단계에서 테스트 워크플로가 성공한 후 프로젝트가 복사되기를 원합니다. 이는 원격 서버에서 일련의 명령어를 사용하여 SCP 또는 Git 체크아웃을 통해 수행할 수 있습니다. 필요에 가장 적합한 방법을 선택하세요.
Node.js를 사용하므로 종속성을 설치하고 Node.js 서비스를 다시 시작해야 하므로 후자를 사용하는 것이 좋습니다. 단순히 파일을 복사하는 것보다 조금 더 깊이 있는 작업입니다. 따라서 SSH를 통해 원격 인스턴스에 연결할 수 있는 CircleCI가 필요합니다.
가장 안전한 방법은 CircleCI용 SSH 개인키를 만드는 것입니다. 서버가 Linux라고 가정하고 서버에서 다음을 실행합니다:
|
1 |
ssh-keygen -t rsa -C "circleci" |
키와 관련된 일련의 질문을 받게 됩니다. 현재 CircleCI는 키 비밀번호를 지원하지 않으므로 이 SSH 키에 비밀번호를 포함하지 않는 것이 중요합니다.
키가 생성되면 다음을 실행합니다:
|
1 |
cat ~/.ssh/ID_RSA.pub >> ~/.ssh/authorized_keys |
위의 명령은 키 이름을 지정했다고 가정합니다. ID_RSA. 공개 키는 공개 키의 끝에 authorized_keys 파일을 만듭니다.
의 내용은 ID_RSA 개인 키 파일을 이 가이드의 뒷부분에 있는 CircleCI 대시보드에 복사해야 합니다.
워크플로우를 디자인하기 전에 GitHub 프로젝트를 서버에 복제해야 합니다. 다음을 예로 들어보겠습니다:
|
1 |
git 복제 https://github.com/my-example-project ./profile-store |
워크플로우의 배포 스크립트에서 사용되므로 프로젝트를 복제한 위치를 기억하는 것이 중요합니다. CircleCI는 서버에 SSH로 접속한 후 git pull 프로젝트 디렉터리 안에 있습니다.
워크플로 단계 설계하기
CircleCI가 프로젝트를 선택하기 전에 GitHub에서 프로젝트를 약간 변경해야 합니다. 다른 많은 CI/CD 솔루션과 마찬가지로 CircleCI도 프로젝트에 구성 파일을 넣어야 합니다.
다음과 같이 가정합니다. 사용자 프로필 저장 프로젝트라는 디렉터리를 만들어야 합니다. .circleci 라는 파일과 함께 루트에 config.yml.
이것을 엽니다. .circleci/config.yml 파일을 열고 다음을 추가합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
버전: 2 일자리: 빌드: 도커: - 이미지: circleci/노드:7 단계: - 결제 - 실행: 이름: 설치-종속성 명령: npm 설치 - 실행: 이름: 테스트 명령: npm 테스트 - 배포: 이름: 디지털-바다 명령: ssh -o "StrictHostKeyChecking no" 사용자@호스트 이름 "cd ~/profile-store; git pull; npm install; forever start app.js" |
그렇다면 위의 구성에서는 어떤 일이 일어나고 있을까요?
테스트 및 기타 워크플로 테스트를 수행하기 위해 Node 7.x를 실행하는 Docker 컨테이너를 스핀업하고 싶다고 가정해 보겠습니다. 단계별로 살펴보면 먼저 프로젝트를 GitHub에서 컨테이너로 체크 아웃합니다. 그런 다음 프로젝트에 커밋되지 않은 모든 종속성을 GitHub에 설치합니다. 프로젝트의 package.json 라는 스크립트가 있습니다. 테스트 이론상으로는 테스트를 실행할 수 있습니다. 우리 프로젝트에는 실제 테스트가 없습니다.
앞의 세 단계가 성공적으로 완료되었다면 배포가 이루어집니다. 이 명령은 서버에 SSH로 접속하여 선택한 디렉토리로 이동하고, 프로젝트의 변경 사항을 가져오고, 잠재적으로 새로운 종속성을 설치한 후 영원히 프로세스.
이 시점에서 이전 로컬 단계가 컨테이너에서 성공했음을 확신하기 때문에 SSH를 통해 프로젝트를 배포할 수 있습니다.
프로젝트 변경 사항을 GitHub에 커밋하여 CircleCI 대시보드에서 프로젝트를 구성할 수 있도록 합니다.
CircleCI 대시보드 내에서 프로젝트 구성하기
프로젝트에 CI/CD 파이프라인을 사용하려면 CircleCI 내에서 몇 가지를 구성해야 합니다. 여러분의 CircleCI 대시보드 에서 관리하려는 GitHub 프로젝트를 찾습니다. GitHub를 CircleCI와 연결한 경우 구성 파일이 추가되었으므로 이미 표시되어 있을 가능성이 높습니다.
프로젝트 설정에서 SSH 권한 섹션으로 이동합니다.
앞서 생성한 개인 키를 이 섹션에 복사해야 합니다. 이렇게 하면 CircleCI가 배포를 위해 서버에 연결할 수 있습니다. 현재로서는 SSH 키에 비밀번호가 없어야 한다는 점을 기억하세요.
이 시점에서 향후 GitHub에 푸시하면 파이프라인이 시작됩니다. 모든 것이 통과되면 Node.js를 실행하는 서버에서 변경 사항에 액세스할 수 있어야 합니다.
NoSQL 혜택은 어디에 있나요?
코드 변경에 데이터 모델 변경이 포함된다고 가정해 보겠습니다. RDBMS를 사용 중이라면 여러 개의 ALTER 문을 변경해야 합니다. 가능하긴 하지만 확실히 편리하지는 않습니다.
여기서 좀 더 구체적으로 설명하겠습니다.
각 사용자 프로필에 이전에는 수집하지 않던 주소 정보를 포함시키고 싶다고 가정해 보겠습니다. NoSQL과 유연한 JSON 모델을 사용하면 저장 중인 JavaScript 객체에 정보를 추가하고 저장을 완료하기만 하면 됩니다. 마이그레이션 스크립트를 만들 필요도 없었습니다.
결론
방금 CircleCI를 사용하여 Node.js 웹 애플리케이션을 지속적으로 배포하는 방법을 살펴보았습니다. 우리는 사용자 프로필 저장소 애플리케이션에서 이전 예제를 만들고, 새로운 변경 사항이 GitHub에 푸시될 때마다 SSH를 통해 서버에 배포했습니다.
사용 가능한 많은 지속적 통합 및 지속적 배포 솔루션이 있습니다. 자체 솔루션을 호스팅하려는 경우 이 튜토리얼의 변형으로 Jenkins를 사용하는 이 튜토리얼을 확인할 수 있습니다, Node.js 및 Jenkins로 지속적 배포 파이프라인 만들기.
멋지네요, 감사합니다!