재미없지만, 많이 길어질 것 같다.

1. 실제로 완성된 개발에 대한 부분

0에서 말씀 드린 부분인데, 실제로 완성된 프로젝트의 부분은 다음과 같다.
데이터 크롤링 + CI/CD + 2tier(정확하게 말하면 3tier 중 Frame Work 와 DB연결)

2. 개발 구상도의 변화

가. 최초 구상도

(아주 욕심만 가득해서..)

나. 최종 완성품(다만 Webserver -> Appsever)의 부분은 미완이다.

3. CI/CD부분 설명 및 삽질의 과정

가. 사전적 의미의 CI/CD

사전적 의미로써 CI/CD는 약어로, CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있습니다.CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.
출처 : https://www.redhat.com/ko/topics/devops/what-is-ci-cd

나. 프로젝트 시작 전의 필자가 생각하던 CI/CD의 의미

위에 왜 저런 사전적 의미를 썼는가? 프로젝트를 진행함에 있어, CI/CD의 의미와 CI/CD를 제공하는 툴들의 실행 과정을 정확하게 알 필요가 있었다.

사실 프로젝트를 시작할때 생각했던 CI/CD의 과정은 다음과 같았다.

그렇다 나는 CI/CD = Jenkins + terraform으로만 생각을 하고 있었다, CI/CD도 재대로 알지 못한채로 프로젝트를 들어간 것이다. 정확한 개념정리는 이렇게 중요하다.

다. 프로젝트 이후 현재 생각하는 CI/CD + provisioning의 의미

실제로 CI/CD의 과정은
CI 파일의 통합 버전관리 / GIT + Jenkins
CD 지속적인 서비스 제공(배포) / Jenkins
provisioning 자원할당, 이를 통해 멱등성 보장, 개발 버전관리의 역활을 하는 것이었다. / Terraform

이 개념도 재대로 잡히지 않은 상태에서, CI/CD를 구축하다 보니, 정말로 수 많은 삽질의 과정의 연속이었다.

4. 각 부분별 (지난한)작업 진행의 과정

가. Build

1) 왜 이거부터 손을 되었는가?

 3에서 말했듯, CI/CD에 대해서 정확한 개념 정리가 되어 있지 않은 상태에서 CI/CD를 하다 보니, 젠킨스, 그 중에서 BUILD 과정 = CI/CD로 생각하게 되었다. 그렇기에 처음부터 BUILD부터 생각하였다. 지금 생각하면 건물을 중간에서 부터 짓는 행동이었다.

2)Jenkins vs Naver Souce Build

(정확한 의미로는 pipline이 맞다)
최초 고민은 CI/CD를 어떤 프로그램 가지고 하는가였다. 이미 프로비저닝(당시에는 이 개념도 재대로 잡혀 있지 않았다.)을 Terrafrom으로 하는 상황에서 네이버 클래식 환경에서 완전 관리형으로 제공하고 있었으며, 이미 한번 교육을 받은 Jenkins와 Naver Souce Build중에서 어떤 툴을 이용하는가? 에 대한 고민부터 하여야 했다. 그리고 결정적으로 Naver Souce Build로 가게된 계기가 있었다.

3)Autoscaling

클라우드 환경에서 가변성을 확보하기 위해서는 Autoscaling 이 필수적이었다. terrafrom으로 오토 스케일링 구성까지는 할 수 있다고 생각되었으나, LB를 타겟으로 어떤 설정이나 파일을 배포(develop)를 젠킨스로 할 수 있다고 생각이 들지 않았다. 그렇기 때문에 배포를 조금 더 쉽게 할 수 있는 Naver Souce Build를 선택하였다.

4)Naver Souce build의 한계점

네이버 소스 빌더는 자랑을 한다.우리는 다양한 build서버를 제공한다고, 하지만 이 다양한 build는 대부분 docker 레지스트리를 만드는데 집중되어 있다. 즉 Terraform 서버는 전혀 제공하지 않는다.

5) Naver Souce Build와 Terraform의 결합

하지만 Naver Souce Build에서는 Public Docker 이미지를 서버로 사용할 수 있다. 그렇기 때문에 다음과 같은 방법으로 네이버 소스 빌더에서 테라폼을 이용하여 프로비저닝 할 수 있다. 다만, 시간에 쫓겨 마지막 방점을 찍지는 못하였다.

-네이버 소스 빌더에서 테라폼 사용하기

가) 빌드 프로젝트 생성

나)작업물을 저장할 오브젝트 스토리지 사용(만약에 오브젝트 스토리지를 사용하지 않고 있을 경우 신청부터 해야됨)

다)기본설정 : 이름, 설명(선택), 빌드대상(GIT 또는 naversouce commit/ 빌드할 원본 파일이 어디있는가에 대한 내용, 해당 부분에 한 자세한 설명은 아래에 다시 설명),리파지토리(그 중 어떤 폴더에 있는 내용을 빌드 할 생각인가?)

라)빌드 환경 설정, 어떤 컴퓨터를 이용해서 빌드할 것인가?
(네이버에서 테라폼을 제공하지 않기에) Public Registry 의 이미지, 이미지(hashicorp/terraform), 태그(latest)

참고) 도커 허브에서 이미지 값과 태그의 표현

마) 빌드 명령어 , 테라폼 초기화, 테라폼 apply + 자동 승인

이후 나머지 부분은 모두 아무런 입력 없이 다음만 눌러도, 이후 빌드는 이상없이 되며, 필자도 프로젝트 중에는 그렇게 진행하였다. 하지만 이렇게 프로비저닝을 진행하게 되면 테라폼의 강력한 기능 중 하나를 잃어버리게 되고, 테라폼은 아래와 같은 금붕어가 된다.

테라폼에서 init을 왜 할까요?
테라폼 init을 하게 되면 .terraform 디렉토리가 생성되며 관련 테라폼 관련 라이브러리 모듈 등을 가져옵니다.(내부에 .tfstate에 정의된 내용도 포함) 또한 인프라 관련 동시성처리를 안전하게 해줄 .terraform.lock.hcl 파일도 생성됩니다.

참고 티스토리 얼음연못님

그런데, 이런식으로 테라폼 파일을 저장하지 않은체로, BUILD를 마치게 되면, 리소스는 아무 이상 없이 생성되나, 이 리소스들을 관리하는 테라폼은 없어지기 때문에, BUILD로 생성한 NCP리소스를 모두 삭제 하지 않은 상태에서, BUILD을 다시 하게 되면, 리소스 이름 중복으로 오류가 발생하고 만다. 즉 Terraform의 리소스 관리가 전혀 되지 않는 것이다. 그렇기 때문에 이 글을 읽는 사람들 중, 혹 CI/CD에서 프로바이징을 하실 분들은 이 파일들을 다운받고, 프로비저닝 전에 파일을 넣는것을 권장한다. 이 부분이 어려워 해당 부분까지 고도화를 하지는 못하였다.