[학습] 젠킨스 (CI/CD)

젠킨스를 학습을 하고 있는데 어떤식으로 학습을 해야 할지 막막했다.
그래서 튜터님께 어떤것을 학습을 하면 좋을지 여쭤보았다. 그리고 나온 결과가 다음과 같다.

- Jenkins 가 CI/CD에서 어떤 역할을 하는지? 
- 아키텍처 master-worker (agent) 
- 주요 구성요소(job, build, executor, node, label, workspace)
- 각 배포환경에 따라 달라지는 Jenkins의 구성 (예정)
- pipeline 공부 (Jenkinsfile) (예정)
- 대표적으로 사용하는 플러그인 적용해보기 (git, git webhook, credentials, secret text등..) (예정)

그리고 추가적으로 ec2와 통신을 step by step으로 알려주셨다.
1. 젠킨스에서 ec2에 접속해보기
    - 성공! pem키를 등록시켜줘서 접근을 해보니 정상적으로 되었다. 
다만 pem키를 젠킨스 서버에도 추가를 해줘야 되었었다.
2. 젠킨스 잡을 통해 ec2로 파일을 만들어 보기
내가 잡을 통해 만들지 않았네.. ㅜㅜ
한번 만들어보자.
여러가지 방법이 있지만 나는 일단 프리스타일로 생성을 하였다.
이게 가장 간단한 방법이기 때문이다.
3. 젠킨스에서 빌드해보기
빌드는 이게 jar을 빌드하라는 거겠지..
요거는 이따가 도커로 배포하는 방법을 찾아보자.

이렇게 3가지로 구성할 수 있다고 한다.

하놔씩 공뷰해보좌

첫번째, Jenkins 가 CI/CD에서 어떤 역할을 하는지..
음 CI CD가 도대체 뭘까 지속적 통합이랑 지속적 배포/제공이라고 한다.
그러면 젠킨스는 이들을 가능하게 도와주는 역할을 하는 느낌이다.
한번 gpt한테 물어보자
개발자들이 일일이 수작업으로 하던 빌드, 테스트, 배포 과정을, Jenkins라는 믿음직한 친구가 알아서 빠르게 해주는 것이라고 한다.
이거에 대해 조금더 풀이를 하자면

• CI (Continuous Integration, 지속적 통합)
  → 개발자들이 작성한 코드를 자동으로 빌드하고, 테스트해주는 역할을 해요.
  → 예를 들어, 누군가 GitHub에 코드를 푸시하면, Jenkins가 바로 동작해서 코드를 가져오고, 빌드하고, 문제가 없는지 테스트를 돌려줘요.
• CD (Continuous Delivery / Deployment, 지속적 배포)
  → 테스트까지 통과한 코드를 자동으로 배포까지 이어주는 역할을 할 수도 있어요.
  → 예를 들어, 테스트 통과 후에 Jenkins가 서버에 바로 배포하거나, Docker 이미지 빌드해서 클라우드에 올려줄 수도 있어요.

그러니까 그의 말을 빌리자면 내가 젠킨스를 딸깍 하면 깃허브에서 코드 가져와서 실행시켜준다는 거잖아
그리고 그것을 클라우드에 올려줄수 도 있는거구
그러면 이걸 수동으로 생각해보면 실제 서버에 자바파일을 빌드해서 JAR만드는걸 CI java -jar로 실행시켜주는걸 CD라 생각이 든다.ㅇㅇ

두 번째, 아키텍처 master-worker이거는 뭘까?? 
요거는 간단히 정리하면 Worker는 따로 준비한 서버고, Jenkins Master가 '이 서버에서 작업해!' 하고 등록해서 명령을 내려 사용하는 구조다라고 한다.

이건 생각보다 많이 적을거 같은데 위에꺼는 구조문제라 이번에는 사용하지 않을 수 있어서 안썼는데 이거는 써야 할거 같다.
다만 요건 gpt한테 물어서 작성해도 될거 같다.

1. Job (잡)

• **Jenkins에서 실제로 '할 일'**을 뜻해.
• 쉽게 말하면, "Build, Test, Deploy 같은 작업 단위"를 하나의 Job으로 관리하는 거야.
• 예시:
  • Spring 프로젝트 빌드 Job
  • Docker 이미지 빌드하고 푸시하는 Job
  • EC2에 배포하는 Job

👉 한마디로: "작업 단위 하나"

---

2. Build (빌드)

• **Job이 실행된 "결과물"**을 뜻해.
• 예를 들어,
  • 오늘 12시에 Job을 돌렸으면, 그 실행 기록이 하나 남아.
  • 실패하면 실패 로그, 성공하면 성공 기록이 남아.
• Build는 항상 Job 안에 여러 번 발생할 수 있어!
  (1회 실행 = 1개 Build 기록)

👉 한마디로: "Job 실행 결과"

---

3. Executor (이그제큐터)

• Worker(혹은 Master) 서버에 설치된 빌드 슬롯이라고 생각하면 돼!
• 하나의 Executor가 하나의 Job(Build)을 실행할 수 있어.
• 서버 하나에 Executor를 여러 개 설정할 수도 있어:
  • 서버 리소스가 충분하면 동시에 여러 빌드를 돌릴 수도 있어.
  • (CPU, 메모리 여유가 많을 때)

👉 한마디로: "빌드를 실제로 돌리는 슬롯"

---

4. Node (노드)

• Master나 Worker(Agent) 서버를 통칭하는 말이야.
• Jenkins 입장에서 보면,
  Master도 Node고,
  Worker 서버도 Node야.
• Node는 하나 이상 존재할 수 있어.

👉 한마디로: "Jenkins에 연결된 서버 하나하나"

---

5. Label (라벨)

• Node를 구분하는 이름표라고 보면 돼.
• Worker나 Master Node에 라벨을 붙여서,
  • "이 Job은 docker-server 라벨이 붙은 서버에서만 실행해줘!" 이런 식으로 작업할 서버를 선택할 수 있어.

👉 한마디로: "Node를 구분하는 태그"

---

6. Workspace (워크스페이스)

• 빌드 작업이 실제로 이루어지는 디렉터리야.
• Worker나 Master에,
  • 빌드할 소스코드가 다운받아지고,
  • 임시 파일이나 실행파일들이 생성되는 폴더.
• Job마다 워크스페이스가 따로따로 생성돼.

👉 한마디로: "작업하는 작업장 디렉터리"

이정도만 알면 크게 문제 없을듯하다.
이제 도커로 말아보고 그것을 배포하는거 찾아보자.