프로젝트를 빌드 및 배포할 때 여러가지 주의점들

프로젝트를 얼추 완성하고나서부터 빌드, 배포에 대해서 공부를 하기 시작했다.

한번에 홈서버, 네트워크, 리눅스, 환경변수, 도커, 빌드, 배포, 젠킨스, 도커 안의 도커 등의 개념을 공부하다 보니 많은 점들이 한꺼번에 주입되어 너무 헷갈렸기에 그 헷갈렸던 점들을 정리해놓고자 한다.

관심사의 분리가 이렇게 중요하구나라는 것을 깨닫게 된 좋은 계기였다.

 

빌드

빌드의 주체는 Gradle, Maven, Ant와 같은 빌드툴이다.

개념적으로는 알고 있었지만 젠킨스 도커 등을 공부하면서 마치 이런 툴들이 빌드까지 대신 해주는 것처럼 느껴졌다.

 

젠킨스가 빌드를 해주는 것이 아닌 젠킨스의 파이프라인에 빌드 단계가 들어가 빌드툴 plugin이 빌드를 한다는 개념을 정확히 잡아야 한다.

 

배포

배포는 AWS나 홈서버가 하는 것이다.

도커나 젠킨스나 배포를 해주는 것이 아니다. 지속적인 배포를 해주는 것이다.

 

도커

도커는 이미지 형상 관리툴 그 이상 그 이하도 아니다.

 

도커 이미지는 여러 레이어로 구성되어 있으며 어떤 이미지를 생성하든 반드시 베이스 이미지가 필요하다.

 

도커 이미지는 Read only이다. 즉 수정 삭제 등을 하는 경우 컨테이너에서만 변경이 일어나고 어떠한 변화도 이미지에 영향을 미치지 않는다.

 

도커 이미지를 변경하는 것은 pull, build뿐이다. 이미지가 변동되어(== 소스코드가 변경되어) 이미지가 변경이 필요하다면 이미지를 새로 받아와야 한다.

 

도커허브

도커허브(Hub, Repository, Registry 다 비슷한 의미에서 사용된다)는 이미지를 보관하는 곳이며 깃허브와 정확히 똑같은 역할을 한다.

본인이 이해하기 가장 힘들었던 부분은 그 큰 이미지 파일을 무료로 관리해준다는 점이었는데 진짜 그 큰 이미지 파일을 무료로 관리해주는거 맞다. (그래서 도커가 망했다고 한다..)

 

도커 이미지의 레이어 개념을 도커허브와 연관해서 생각하면 이해하기 쉽다. 이미지는 immutable하기에 아주 조그마한 변경이 생겨도 매번 새로운 이미지를 받아야 하는데 매번 모든걸 새로 받는건 부하가 심하므로 immutable 내에서도 immutable들과 mutable을 더 나눠놨다고 생각하면 좋을 것같다.

 

도커 데이터 저장

도커 컨테이너는 삭제되면 전부 데이터가 날라가기에 어딘가에 저장해야 한다. 하지만 도커는 결국 가상화 머신이라 File로의 저장이 불가능한데 이를 위해서 생겨난 것이 Volume이다. 

 

도커 볼륨은 간단히 생각해서 실시간 데이터 동기화 기능이다.

 

호스트 OS에 데이터를 저장하는 방법은 폴더를 지정해서 저장할 수도 있고 도커를 통해 저장할 수도 있다.

-v //c/folder1/folder2:/var/jenkins_home 처럼 정말 깡으로 폴더를 지정해서 저장이 가능하다. 하지만 이 방법은 느리고 직접 관리해주어야 하는 단점이 있다.

 

그래서 도커가 직접 제공해주는 볼륨을 사용하는 것이 가장 좋은데 그냥 볼륨을 하나 생성하고 

-v 볼륨이름:/var/jenkins_home처럼 매핑해주면 끝이다. 생성하지 않고 사용하면 익명 볼륨이 생성되므로 반드시 생성해서 사용하는 것이 좋다.

 

도커 볼륨은 그냥 호스트 OS내의 어딘가에 폴더를 만들어서 도커가 알아서 관리하고 있다고 생각하면 된다. 궁금해서 폴더가 어딨는지 찾아보고 그랬는데 알 필요가 없다. 도커가 직접 관리하므로.

 

도커네트워크

컨테이너 간에 서로 소통하기 위해서 반드시 네트워크가 설정되어야 한다. 

네트워크를 설정하지 않아도 되는 것은 기본적으로 모든 컨테이너는 기본 네트워크에 속하기 때문이다. (보안에 좋지 않음)

 

예를들어 애플리케이션과 DB를 연결하고 싶다면 둘다 같은 네트워크에 넣어야 한다. 

네트워크에 넣는 방법은 일단 네트워크를 하나 생성 후에 docker run시에 --network 네트워크이름 넣어주면 된다.

 

배포시에 DB는 포트를 노출시킬 필요가 없으므로 -p를 넣지 말고 브릿지 모드로만 연결하면 된다.

 

브릿지 네트워크는 컨테이너간의 IP 주소로 소통한다. (docker inspect 컨테이너이름으로 확인)

실제 연관 관계 설정은 --name의 값으로 하면 된다.

 

Dockerfile

프로젝트 최상단(src폴더와 같은 레벨)에 위치해야 하며 대문자 D와 소문자 f 그리고 확장자는 없다. 글씨가 한톨도 틀려서는 안 된다.

 

 

 

환경변수

환경변수 개념이 어렵다면 환경이라는 단어를 떼버리고 그냥 변수라고 이해하자.

 

환경변수는 민감정보(비밀번호, SSH Key 등)을 전달하는 용도로 사용한다. 

 

깃허브와 도커허브에 민감정보가 올라가면 안 되는데 비밀번호를 언제 어떻게 넣는지 오래 헷갈렸는데

단순하게 모든 민감정보를 환경변수(${} 형태)로 선언해두고 나중에 컨테이너를 올릴때(docker run)

-e 환경변수=민감정보 의 형식으로 값을 일일히 넣어주면 된다. 

 

e.g

application.properties에서 spring.datasource.username=${DB_USERNAME} 라고 선언 후 

docker run -e DB_USERNAME=root으로 값을 넣는다.

 

만약 application-prod.properties와 같이 파일명을 설정했다면 환경변수로 반드시

-e "SPRING_PROFILES_ACTIVE=prod" 를 넣어주어야 한다.

 

spring.datasource.url="db주소"와 같이 이미 값이 지정되있는 경우에도 SPRING_DATASOURCE_URL="새로운 값"과 같이 넣어주면 새로운 값이 오버라이딩되어 들어간다.

 

젠킨스

젠킨스 스스로는 아무것도 하지 못 하는 깡통이며 모든 실질적인 기능은 플러그인들이 한다는 것을 숙지하자.

 

어떤 트리거에 의해 특정 동작들을 순서에 맞게 실행하고 결과를 알려주는 툴에 불과한데 웹훅도 보내고 받고 테스트도 해주고 빌드도 해주고 결과도 알려주고 메시지도 날려주고 이미지 빌드도 해주고 푸시도 해주고 풀해주는 정도 (그 외에도 수많은 기능들)이다.

 

도커 위에 젠킨스를 설치하는 경우 설치하게 되는 도커 플러그인은 호스트 OS의 도커 데몬(리스너)이며 도커 자체를 설치하는 것이 아니다. 도커 위에 도커를 또 설치하는 것은 지양해야 한다.

 

젠킨스의 데이터는 도커 볼륨에 설정하면 되며

윈도우일 경우 젠킨스를 run할 때 -v /usr/bin/docker:/usr/bin/docker -v /var/run/docker.sock:/var/run/docker.sock 설정을 "반드시" 해주어야 한다.

 

네트워크

기본적으로 모든 포트는 전부 닫혀있도록 설정되어 있으며 이중에 하나를 열면 그게 서버가 되는 것이다. 

 

서버를 열기 위해서는 공유기의 방화벽, 공유기의 포트포워딩, 윈도우의 방화벽, 인바운드 규칙, 프로그램 규칙을 적절하게 열어줘야한다.