배포)GithubHook - Jenkins

김태성·2024년 8월 27일

개인 프로젝트-1

목록 보기
29/53
post-thumbnail

우분투 설치

레퍼런스 : https://medium.com/@srijaanaparthy/step-by-step-guide-to-install-docker-on-ubuntu-in-aws-a39746e5a63d

sudo apt-get update

명령어를 사용하여 패키지를 업데이트 한다.

sudo apt-get install docker.io -y

명령어를 사용하면 docker 설치를 한다.

이런식으로 어디서 다운로드받고 쭈우우욱 설치한 후

(Digest 값은 hash값이다. 보안은 철저히)

sudo systemctl start docker
sudo docker run hello-world

도커를 켜고 hello-world를 실행한다.

Hello From Docker! 를 통해 docker가 정상적으로 깔렸음을 확인할 수 있다.

Jenkins

레퍼런스 : https://myminju.tistory.com/114

sudo docker run -d --name jenkins -p 8080:8080 jenkins/jenkins

명령어를 사용한다.
이후 포트를 확인하면

8080번으로 잘 열려있는게 보인다.

여기서 중요한건 포트포워딩을 안하면 Docker내부에서 외부로 못나온다.
진짜 중요하니까 8080:8080 안하면 사용을 못한다.
이후 보안그룹에 8080포트를 뚧어준다.

이렇게 뚧어주고 {Ubuntu ip}:8080으로 들어가면

Jenkins가 잘 되는걸 확인할 수 있다!

// jenkins 컨테이너에 접속
$ sudo docker exec -it jenkins bash
// 초기 관리자 키 확인
$ cat /var/jenkins_home/secrets/initialAdminPassword

이후 위의 명령어를 따라 초기 관리자 키를 확인하고 입력하면

(쉘 스크립트를 쓰고 GUI가 없으니 마치 90년대 해커가 된 느낌이 든다)
위와 같은 화면이 뜬다.

왼쪽의 추천 플러그인을 선택하자.

이후 설치를 하는데 문제가 발생했다.

install이 안되는게 많이 발생했다.

하지만 이후 retry 버튼을 계속 누르며 다시 다운을 받으면 되긴 한다.

꽤 시간이 걸리긴 하지만 모두 다운받게 되면 위와 같은 화면이 나오게 된다.

이후 url 설정까지 끝내면

Jenkins GUI가 뜬다!
솔직히 이런 GUI를 제공해 줄거라고는 생각도 못했는데
사람들이 사용하는 이유가 있는거 같다.

Github - Jenkins 연결

레퍼런스 : https://ziszini.tistory.com/108
아.. 정말 이상하게 정보가 너무 안나와서 하루종일 고생한 후 겨우 연결했다.

오늘 하루종일 삽질하다가 멘탈이 그냥 박살나버렸는데
도저히 쓸 엄두가 안난다.
처음에는 Github action을 사용하려고 했으나 이유모를 에러가 계속 발생했다.
그러다 문득 build를 사용하는걸 2번이나 써야되나 싶어서 더 검색을 하였고
위의 레퍼런스를 발견하게 되어 hook을 사용하게 되었다.
결론은 다행...이라고 해야되나 모르겠다.

아마 GithubAction에만 집중했다면 1주일이 걸렸을지도 모르는 문제였다.

정말 많고많은 고생 끝에
결국 GithubHook에 Jenkins가 반응을 하였고, 무사히 데이터가 옮겨진 모습이 보인다.
여기서 이전과 달라진 점이 있다.

GithubAction을 안쓰는 이유

Github Action을 사용하려던 이유는 간단했다.

  • 내가 Github 레포지토리를 사용하고
  • 자동으로 통합할 CI가 필요해서

하지만 이것은 GithubHook을 통해 Jenkins로 데이터를 전송할 수 있음으로써,
굳이 할 필요가 없게 되었다.

GithubAction을 쓰지않음으로써 내가 얻는 이득과 손해는 다음과 같다.

  1. 새로운 기술 안배워도 된다 - WorkFlow는 편하다고 하지만 배우는데 시간이 걸린다.
  2. 새롭게 설정할 필요가 없다 - Hook을 통해 이미 묶었기 때문에 한번더 할 필요 없다.
  3. 아키텍처가 간단해진다 - jenkins에서 백/프론트쪽으로 보내면 된다.

손해는 다음과 같다.

  • github에서 대신 해주던 build를 내 서버에서 돌려야 한다.

하지만 이건 손해라고 봐야하는지도 좀 애매한것이

  • 어차피 나는 소규모 프로젝트라서 빌드/테스트 하는데 자원소모가 적다
  • 큰 규모의 회사라면 어차피 개인서버 써야된다(확장성)
  • jenkins / github 나눠서 CI/CD 하나씩만 맡으면 코드가 분산된다.

등등의 이유로 인해 Jenkins만 쓰는것이 이득이라고 판단했다.

이후

이제 진짜 힘든게 남았다.
오늘 하루 좀 힘들었는데 더 힘든게 남아있으니까 너무 슬프다.

왜 힘드냐면.. 이제 build 해서 서버 돌리고, 백 - 프론트 서버 연결 후 Client가 사용할 수 있도록 배포를 해야 하는데.. 이전 프로젝트에서 이 과정에서 너무나도 힘들었던 기억이 있다.

잘 되었으면 좋겠지만 일단 해봐야지 어쩌겠는가.
배포 말고도 Jenkins를 통해 자동으로 카톡/슬랙 등으로 알림을 주는 기능도 추가할 예정이다.

profile
닭이 되고싶은 병아리

0개의 댓글