1. ECR에 Docker image push (2/3)

총 4개의 젠킨스 프로젝트가 필요하다.

필자의 경우 백앤드,프론트앤드가 같이 있는 서비스다.

1. 자동 배포 리포지터리를 감지해서 새로운 수정사항이 merge 되면 자동 배포를 수행하는 총괄 젠킨스 프로젝트

2. 백앤드 프로젝트를 Docker 이미지로 만들어서 ECR 로 push 하는 젠킨스 프로젝트

3. 프론트앤드 프로젝트를 Docker 이미지로 만들어서 ECR 로 push 하는 젠킨스 프로젝트

4. 위의 이미지들을 EC2 로 pull 해서 서비스를 돌리게하는 젠킨스 프로젝트

말로하면 좀 헷갈리는데 그림으로 이해해 보자.

위의 2번,3번은 하는일은 같은 프로젝트이다. 백앤드,프론트앤드로 소스가 다를뿐 실제 내부적으로 하는일은 같다.

아래 그림에서 프론트앤드,백앤드 중에 하나는 없다고 생각하고 이해해도 무방하다.

하나씩 이해해 보자.

1. 총괄 젠킨스 프로젝트

자동 배포를 위해서는 이를 트리거하기 위한 최소한의 1회 커밋은 필요하다.

누군가가 특정 브랜치에 커밋을 하게 되면 이걸 신호로 삼아서 자동 배포 프로세스를 동작시키는 아이디어다.

그래서 이 trigger 및 전체 총괄만을 관리하는 별도의 repository 를 만들고, 여기의 특정 브랜치에 수정사항이 merge 되면 자동 배포 프로세스를 동작시면 된다.

필자의 경우 [프로젝트명_deployment] 라고 하는 새로운 repository 를 만들었다.

이 repository 는 릴리즈 히스토리와 ECR 에서 EC2 로 pull -> run 하는 과정을 담은 ansible playbook 파일들만으로 채운다.

이 프로젝트 내에 있는 파일들과 젠킨스 구성은 순서상 마지막으로 미루자.

내부의 각 젠킨스 프로젝트가 하는일을 먼저 파악하고 그 뒤에 전체 총괄 설명을 하는것이 더 자연스럽다.

여기서 잠깐 우리가 해야할일을 시간순으로 정리해보자.

1. 각 프로젝트를 빌드해서 Docker imge 만들기

2. 이 Docker image 를 ECR 로 push 하기

3. push 된 Docker image 를 EC2에서 pull 해서 돌리기

이다.

이 1번,2번을 각 프로젝트 젠킨스가 담당한다 (Docker image build -> ECR push)

그리고 3번을 새로 만들게 될 deployment 프로젝트가 담당한다.

2. 백앤드/프론트앤드 젠킨스 프로젝트

앞서 설명했듯이 둘은 소스만 다르고 하는일이 같기 때문에 백앤드 하나만을 두고 설명한다.

1> 빌드뿐 아니라 여러 일을 해야하기때문에 pipeline 프로젝트로 만든다.

2> 각 프로젝트를 빌드해야하기때문에 repository 는 기존의 각 프로젝트 repository 로 설정하고 브랜치 설정한다.

3> 파이프라인 스크립트는 프로젝트 내부 Jenkins file 로 관리한다.

중요한것은 저 Jenkinsfile 의 내부+관련된 작업 들이다.

이 부분은 내용이 길어지니 다음 페이지에서 알아보자.

실짱네 - 공부하고 기록하는 개발자