osnie

이 글은 제가 JAVA 명령어 동작을 확인하는 과정에서 발생한 궁금증과 오해를 풀어내고 있습니다.

적절한 이해를 위해 간단한 배경지식을 설명하고, 궁금증을 해소하는 과정으로 이어집니다.

리눅스 명령어는 어떻게 실행될까?

터미널에 입력하는 대부분의 명령어들(ls, cp, chmod, tail..)은 전부 실행파일(binary)입니다.

이러한 실행 파일은 보통 /bin, /usr/bin 같은 특정 폴더에 존재합니다.

생각해보면, ls 명령어는 /bin 폴더에 위치하는데요, /bin 경로에 위치한 ls 파일을 실행하려면 /bin/ls 라고 사용해야 하는 것 아닐까요?

어째서 ls 만 쳐도 정상적으로 실행이 되는 걸까요?

그 이유는 PATH라는 환경변수에 이 폴더들이 등록되어 있기 때문입니다.

PATH란 무엇인가?

PATH 환경변수는 명령어를 실행할 때 "어느 폴더안에서 그 실행파일을 찾을지"를 알려주는 "폴더 경로의 모음집" 입니다.

echo $PATH
/opt/homebrew/bin:/opt/homebrew/sbin:
/Library/Frameworks/Python.framework/Versions/3.11/bin:
/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:
/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system

위와 같이 :(콜론)을 기준으로 폴더를 구분하여, 맨 처음 폴더부터 순차적으로 명령어(ls)와 일치하는 실행파일(ls)를 찾습니다.

ls를 쳤을 경우 다음과 같은 흐름으로 ls 실행파일을 찾습니다.

1. /opt/homebrew/bin에서 ls 실행파일 탐색, 없음 -> 다음 폴더 탐색

2. /opt/homebrew/sbin에서 ls 실행파일 탐색, 없음 -> 다음 폴더 탐색

3. ...

4. /bin에서 ls 실행파일 탐색 -> 존재! 실행

이런 구조로 인해 /bin/ls같은 전체 경로를 쓰지 않아도 명령어를 사용할 수 있게 되는 거죠.

Java도 실행파일이다.

java 역시 마찬가지입니다.

java, javac, javadoc 같은 명령어들도 JDK 폴더 내 bin/ 디렉토리에 포함된 실행파일입니다.

java 설치 시 자동으로 관련 파일들이 설정되어 별도의 경로 표시 없이 사용할 수 있게 됩니다.

어라, 근데 왜 다르지?

위 작동과정을 확인하고자 탐구해봤습니다.

제 환경의 경우 MAC OS이고, 과거에 제가 직접 PATH 환경변수에 jdk 17 경로를 추가해놨었습니다.(문제의 시발점)

따라서 아래와 같이 PATH 환경변수에서 jdk 경로를 확인할 수 있었죠.

❯ echo $PATH
/Library/Java/JavaVirtualMachines/jdk-21.0.2.jdk/Contents/Home/bin:
/opt/homebrew/bin:/opt/homebrew/sbin:
...

그리고 이 경로를 통해 java 실행파일을 찾아낸다고 생각했습니다.

그런데, 제가 알기론 JAVA_HOME 환경변수의 JDK 경로만 변경해도 JDK 버전이 변경되는 것으로 알고 있었습니다.

JAVA_HOME 환경변수 변경만으로 JDK 버전이 변경되려면, PATH에 등록된 JDK 경로도 변경되어야 하는 것이 아닐까요?

그런데 그게 가능할까요? 제 생각으로는 불가능해보입니다.

뭔가 이상했습니다.

검색해보니, JDK 경로를 PATH에 등록하지 않아도 된다는 내용을 보았고, PATH에 등록했던 JDK 경로를 삭제한 후, java 명령어를 실행해봤습니다.

제가 이해한 바로는 java 명령어가 실행될 수 없었습니다. java 실행파일이 PATH 경로에 없었으니까요.

그런데 놀랍게도 실행이 됩니다.

PATH에 JDK 경로를 직접 입력하지 않아도 된다

저는 PATH에 직접 JDK 경로가 등록되어 관리된다고 생각하고 있었습니다.

그래야 적절한 JDK 버전의 실행파일이 실행될테니까요.(다른 사람의 정보를 맹목적으로 믿은 탓도 있습니다..)

사실은,

리눅스의 경우 /usr/bin/java의 심볼릭 링크가 JDK 경로와 연결되어 있고,

MAC의 경우 /usr/bin/java 실행파일을 통해 동적으로 JDK 경로가 연결됩니다.

따라서 java 실행파일은 이미 /usr/bin/ 폴더에 존재하여 따로 설정해주지 않아도 되는 것이었습니다.

(macOS의 경우 다음과 같은 구조로 java가 실행된다고 합니다:)

1. /usr/bin/java 실행파일은 JAVA_HOME 환경변수를 참고해서 해당 JDK 실행파일을 불러오는 역할을 합니다.

2. JAVA_HOME이 jdk 17 경로로 설정되어 있다면, JAVA_HOME의 환경변수를 참조하여 jdk 17의 java 실행파일이 실행되는 것입니다.

그림으로 보면 아래와 같습니다:

글을 정리하면 다음과 같습니다.

1. 명령어도 하나의 실행파일이다.

2. 명령어를 전체경로 없이 실행할 수 있는 것은, PATH 에서 적절한 파일을 찾아주기 때문이다.

3. java 명령어는 /usr/bin/java 실행파일로 실행된다.(동작 구조는 운영체제별로 상이함)

실제 동작을 확인하는 과정에서 제가 알고있던 이해관계와 충돌하였고,

그 충돌을 풀어내는 과정에서 제가 잘못 알았던 점을 이해하고, 문제를 명확하게 이해하고 해결할 수 있었습니다.

캡스톤 디자인 프로젝트를 진행하며, 백엔드 서버 구조를 MSA 구조로 설계하였습니다.

MSA 구조는 각 서비스를 독립적으로 개발하고 배포할 수 있다는 장점이 있지만, 동시에 수동 배포로는 관리와 유지보수가 어렵다는 한계를 가지고 있었습니다.

이에 따라 배포에 드는 반복적이고 소모적인 작업을 줄이고, 개발에 더욱 집중할 수 있는 환경을 만들고자 CI/CD 파이프라인 구축을 제안 및 구성하였습니다.

이 글에서는 당시의 구조와 구현 방식, 그리고 아쉬웠던 부분까지 정리해보려 합니다.

프로젝트 환경 및 조건

서버: Ubuntu 22.04

저장소 플랫폼: GitLab (캡스톤 규정)

백엔드 폴더 구조:

backend/
├── ai/
│   └── Dockerfile
├── grading/
│   └── Dockerfile
├── member/
│   └── Dockerfile
├── review/
│   └── Dockerfile
└── workbook/
    └── Dockerfile

아키텍쳐 구조: 

Dockerfile 구성

인프라를 구성하다보니 생각보다 사소한 부분에서 꽤 오래 고민하게 되었습니다. 저의 경우는 도커파일과 도커 컴포즈 파일을 어떻게 구성해야 할 지 고민했습니다. 특히, 환경변수, 마운트, 네트워크 설정을 어디에서 해야 적절한 지 헷갈렸습니다.

여러 레포지터리를 찾아보고, 고민해본 결과, 도커 자체에 대한 개념 부족으로 비롯된 것이었다는 결론을 내렸습니다.

도커 파일은 이미지 빌드를 담당하고, 도커 컴포즈는 이미지 실행을 담당하여 각각 담당하는 역할이 달랐고,  이 구분에 대한 이해가 부족하여 명확하게 구분하지 못했습니다.

마운트, 네트워크 설정은 실행 시점에 필요한 설정으로, 도커 컴포즈에서 설정하는 것이 적절했습니다. 반면 환경변수는 도커파일과 도커 컴포즈 두 파일 모두 설정가능한 항목이었고, 도커 컴포즈에서 모든 환경변수를 관리하는 것으로 결정했습니다.

그 이유는 다음과 같습니다:

1. 환경변수를 도커파일에 개별로 관리하면, 환경변수 변경 시 도커파일을 수정하고 재빌드 해야 합니다. 이런 서비스의 개수가 많을수록, 해당되는 모든 서비스를 재설정해야하고, 이는 굉장히 생산성이 떨어집니다.

2. 실수로 민감 정보(비밀키 등)가 Docker 이미지에 포함되어 외부에 노출될 수 있습니다.

따라서, 도커 파일에는 서버를 실행할 수 있는 환경(빌드, 실행 Entry Point)을 구성하고, 

도커 컴포즈에서 환경변수, 마운트, 네트워크 등을 관리하는 것으로 결정했습니다.

CI/CD 파이프라인 목표

변경 사항이 main 브랜치에 반영되면, 자동으로 빌드와 배포가 진행되는 것이 목표였습니다.

작업 순서: 

1. GitLab 저장소에서 최신 코드 가져오기 (git clone)

2. 서비스 단위로 도커 이미지 빌드

3. 기존 컨테이너 종료 후 새 컨테이너 배포

4. 불필요한 이미지 및 컨테이너 정리

CI/CD 전략 비교

[1] Git Action + Docker Hub + Jenkins

1. GitHub 병합 이벤트 감지

2. Docker 이미지 빌드 후 Docker Hub에 Push

3. 2번 완료 후, Jenkins에서 Pull 및 배포 (Jenkins 트리거는 Github Webhook)

[2] GitLab + Jenkins (선택)

1. GitLab -> Jenkins로 Webhook 전송

2. Jenkins에서 전체 빌드 및 배포 수행

둘 다 깔끔하고 직관적이지만, 캡스톤 규정으로 GitLab이 규정된 플랫폼이었기에 GitHub Action은 고려 대상에서 제외했습니다.

또한, GitHub로의 저장소 이전을 염두에 두고 있었기 때문에, 플랫폼에 종속되지 않는 방식인 [2]번을 채택했습니다.

Jenkins 파이프라인 구성

Jenkins 설치 및 환경 구성은 다음을 통해 확인하실 수 있습니다.

Jenkinsfile 파일 작성

1. Git Clone

2. 각 서비스 도커 빌드

3. 배포

4. 미사용 이미지 삭제

5. WorkSpace 정리

위 단계로 구성하였다.

환경변수 등은 Jenkins의 Credential을 설정하면 된다.

기대 효과 및 실제 성과

CI/CD 파이프라인 구축을 통해 백엔드와 프론트엔드 간의 변경 사항이 빠르고 간편하게 서버에 반영되었으며, 반복적인 수동 배포 과정에서 발생하던 소모를 크게 줄일 수 있었습니다. 이로 인해 전체 개발 시간이 단축되었고, 기능 개발에 집중할 수 있는 환경을 조성할 수 있었습니다.

또한, Jenkins 기반의 배포 구조를 채택함으로써 GitHub, GitLab 등 저장소 플랫폼에 종속되지 않는 유연한 인프라를 구축하였고, 추후 GitHub로 저장소를 간편하게 옮길 수 있을 것으로 기대됩니다.

아쉬운점과 회고

1. 테스트 자동화 미적용

- CI의 핵심인 자동 테스트를 구성하려 했으나, 통합 테스트 구성 방법 지식 부재 및 프로젝트 마감이 임박하여 적용하지 못한 점이 너무 아쉽습니다.

2. 배포 환경(dev, test, prod) 분리를 적용하지 못함

- 단일 환경에서 모든 테스트와 운영을 처리해야 했던 점이 아쉽습니다.

마무리

프로젝트 팀 전원이 CI/CD 기반의 개발 환경이나 배포 구조 설계에 익숙하지 않았고, 각자 맡은 기능 구현만으로도 벅찬 상황이었습니다.

이로 인해 배포 환경을 dev/test/prod로 분리해야 한다는 필요성을 초기에 인식하지 못했고,

결국 단일 환경에서 테스트와 운영을 병행하게 되어 품질 관리 및 안정성 확보에 어려움이 있었습니다.

또한, 백엔드와 프론트엔드 간 통합 과정에서도 API 연결, 환경 변수 설정 등 예상보다 많은 이슈가 발생하여

인프라 구축에는 충분한 리소스를 투입하지 못한 점이 아쉽게 남습니다.

그러나 이러한 한계 속에서도 초기 단계에 구축한 CI/CD 파이프라인이 안정적으로 동작하면서,

변경 사항의 자동 반영, 수동 배포 제거 등 개발 효율성을 높이는 데 큰 기여를 했습니다.

이는 팀 전체 생산성 향상에 실질적인 효과를 가져왔다는 점에서 만족스러운 결과였습니다.

저를 비롯한 팀원들이 이런 구조 개발이 처음이었고, 자신이 맡았던 분야만으로도 벅차서 이런 배포 환경을 분리해야겠다는 필요성을 느끼지 못하였습니다.

당장 백엔드와 프론트엔드를 통합하는 과정도 어려움이 많아서, 인프라 구축에 신경을 쓸 겨를이 없던 점이 아쉽습니다.

하지만, 그 과정에서 구축했던 CI/CD가 잘 동작하여 전체적인 생산성에 기여한 점이 만족스럽습니다.

다음 프로젝트에서는 배포 환경 분리, 통합 테스트 자동화, 버전 전략 관리(Git Flow)를 적극적으로 고려하여 구성해보고자 한다.

ㅇㅇ

ㅇ

ㅇㅇ

ㄷㄱ

ㄹㄷㅈ

ㅗㅜ퓨ㅡ

개요

도커 컨테이너는 리눅스의 네임스페이스와 cgroup으로 구현되었다고 한다.

컨테이너가 어떻게 구현됐는지 알게되면 도커에 대한 근본적인 이해력을 기를 수 있을 거 같아 이를 설명하는 글을 찾아보았다.

도커 Docs에서 컨테이너에 대한 설명과 더불어 간단한 변천사를 설명하는 블로그 글을 찾았다.(https://medium.com/@saschagrunert/demystifying-containers-part-i-kernel-space-2c53d6979504)

본문을 간단하게 공부하고 실습해본 후, 리눅스의 네임스페이스와 cgroup을 대략적으로 이해하게 되었다.

그러던 중 궁금한 점이 생겼다.

도커 컨테이너의 네임스페이스를 외부(host)에서수정하면 실제 도커 컨테이너에도 반영이 될까?

당시 생각: 도커 컨테이너도 결국 네임스페이스라는 격리된 공간을 활용하는 것에 불과하므로, 해당 공간이 수정되면 그대로 컨테이너에 반영될 거라고 생각했다.

실제로 수행해보면 "도커 컨테이너는 네임스페이스로 이루어졌다"라는 문장을 보다 체감(?)할 수 있을 거 같아 시도해봤다.

환경 설정

1. 테스트용 컨테이너 생성

root@osnie:~# docker run -d --name testbox --rm busybox sleep 3000
c813233b389b3517077dc43560992874e4c88a772e952a1213c6fbaeee459417
root@osnie:~# docker ps
CONTAINER ID   IMAGE     COMMAND        CREATED         STATUS         PORTS     NAMES
c813233b389b   busybox   "sleep 3000"   3 seconds ago   Up 2 seconds             testbox

1. busybox 이미지를 활용하여 명령어를 테스트

2. --rm sleep 3000: 3000초가 지나면 자동으로 컨테이너 삭제(컨테이너를 유지시키기 위한 옵션)

환경 설정이 완료되었다!! (컨테이너 하나 띄운거라 설정이라고 하기도 애매하다)

2. 컨테이너 Pid 조회하기

root@osnie:~# docker inspect --format '{{.State.Pid}}' testbox
6037

- inspect의 결과중 State 항목의 Pid를 출력한다.

3. 컨테이너 네임스페이스 조회하기

root@osnie:~# ls -al /proc/6037/ns
total 0
dr-x--x--x 2 root root 0 Apr  7 10:35 .
dr-xr-xr-x 9 root root 0 Apr  7 10:35 ..
lrwxrwxrwx 1 root root 0 Apr  7 10:37 cgroup -> 'cgroup:[4026532397]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 ipc -> 'ipc:[4026532395]'
lrwxrwxrwx 1 root root 0 Apr  7 10:35 mnt -> 'mnt:[4026532390]'
lrwxrwxrwx 1 root root 0 Apr  7 10:35 net -> 'net:[4026532398]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 pid -> 'pid:[4026532396]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 pid_for_children -> 'pid:[4026532396]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 time -> 'time:[4026531834]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Apr  7 10:37 uts -> 'uts:[4026532391]'

프로세스는 자원별 ns(namespace)를 가지고 있고, 어떤 네임스페이스와 매핑되었는지 확인할 수 있다.

UTS 네임스페이스 조작하기

1. 기존의 hostname 확인하기

root@osnie:/home/ubuntu# docker exec -it testbox sh
/ # hostname
c813233b389b

2. 호스트에서 nsenter를 활용해 hostname 수정하기

root@osnie:/home/ubuntu# nsenter -t 6037 -u hostname osnie

3. 확인하기

/ # hostname
osnie

수정사항이 반영되었다. 추가로 네트워크 관련 설정도 시도해보자.

네트워크 네임스페이스 조작하기

1. 기존의 네트워크 확인하기

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 06:56:6f:0c:50:2c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

2. 네임스페이스에 네트워크 추가하기

root@osnie:~# nsenter -t 6037 -n ip addr add 192.168.50.10/24 dev eth0

3. 변경 확인하기

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 06:56:6f:0c:50:2c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.50.10/24 scope global eth0
       valid_lft forever preferred_lft forever

내용이 추가되었다.

도커 컨테이너의 네임스페이스를 외부(host)에서수정하면 실제 도커 컨테이너에도 반영이 될까?

라는 물음은 그렇다!로 확인되었다.

이 과정에서 실제로 수정한 네임스페이스가 도커 컨테이너에 반영됨을 보고 "도커 컨테이너는 네임스페이스로 이루어졌다" 라는 문장을 조금 더 체감하게 되었다.

참고

https://ko.linux-console.net/?p=14713

https://medium.com/@saschagrunert/demystifying-containers-part-i-kernel-space-2c53d6979504

문제 상황

1. 문제 요약: 오픈스택 메뉴얼을 참고하여 수동 설치하였고, 인스턴스 생성은 되지만 콘솔 접속이 되지 않는다.

2. 발생 환경

- Host PC OS : Windows 10

- controller node OS : Ubuntu 22.04 LTS

- compute node OS : Ubuntu 22.04 LTS

- openstack version : Antelope(2023.1)

3. 발생한 에러

원인 분석

controller의 서버 IP 주소를 찾을 수 없습니다

-> 요청 URL이 잘못되어 네트워크 요청 자체가 수행되지 않았음을 의미한다고 한다.

해결 과정 1: 요청 패킷 확인

1. 브라우저에서 콘솔 접속을 위한 http 요청 패킷을 확인해보았다.

2. 요청 URL이 http://controller:6080 ... 으로 설정된 것을 확인

사고 흐름

- controller는 [vm이 속한 사설 네트워크에서 서비스를 구분하기 위해 사용하는 별칭]이라, 외부 클라이언트는 해석하지 못할 것이고, 이로 인해 잘못된 요청을 했다고 생각했다.

3. 이는 오픈스택 설정이 잘못되어 발생한 문제라고 판단하여 오픈스택 설정을 살펴보기로 했다.

해결 과정 2: 오픈스택 설정 확인

1. 콘솔은 vnc로 인스턴스와 연결된다고 한다.

2. vnc 관련 설정과 공식 매뉴얼 설정을 비교

3. 공식 매뉴얼을 통해 위에서 요청 URL 주소가 controller가 아닌, [컨트롤러 외부 IP주소]로 설정해야 한다는 것을 확인

4. compute 노드의 vnc 설정을 수정

하지만 그래도 안 됨

해결 과정 3: 네트워크 설정이 잘못되었나?

1. compute, controller 노드의 로그 확인, 특이사항을 찾지 못함

2. 컨트롤러 노드에서 외부 네트워크와 연결되는 인터페이스를 캡쳐 후 vnc 접속, 패킷이 감지되지 않음

3. 호스트 PC에서 6080 포트로 통하는 패킷 확인, 감지되지 않음

사고 흐름: 요청이 정상적으로 수행되었다면, 호스트 PC에 도달하지 않을 이유는 무엇일까? 라는 생각에 네트워크 설정을 살펴봤고, 포트포워딩이 문제인가? 라는 생각을 하게됨

해결 과정 4: 포트포워딩 문제인가?

이쯤에서 문제가 해결될 거 같다고 느꼈다.

상식적으로 6080 포트로 보내는 요청이라면, 내부적으로 6080 포트 요청을 라우팅해주어야 하는데, 이를 빼먹고 있었다. 

1. 공유기 -> 호스트로의 6080 포트포워딩

2. 호스트 -> controller 노드로의 6080 포트포워딩

을 설정했다.

이후, 다시 vnc 접속을 시도하니 성공했다.

문제를 정리하자면 다음과 같다

1. 오픈스택 설정 문제로 요청 자체가 잘못되었다. (controller:6080이 아닌, <controller IP>:6080)이 되었어야 함)

2. 공유기 -> 호스트로의 6080번 포트포워딩이 설정되지 않았다. (6080 포트 요청이 호스트에서 감지되지 않은 이유)

3. 호스트 -> 컨트롤러 노드로의 6080번 포트포워딩이 설정되지 않았다.

에러 재현하기 및 해결 방법 검증하기

1. 발생 오류가 내가 제시한 문제점으로부터 발생했는지 검증하기

2. 내가 중간 과정에서 시도한 방법이 적절했는지 검증하기

1. 오픈스택의 vnc 설정을 controller:6080으로 되돌리기

-> controller의 서버 IP 주소를 찾을 수 없습니다 에러가 발생해야 한다.

2. 공유기 -> 호스트로의 6080 포트포워딩 막기

-> 요청이 수행되지만 응답이 되지 않음

3. 문제가 없다면, 호스트 PC에서 포트 6080번으로 오는 패킷이 캡쳐가 될까?

-> vnc 요청이 정상적으로 수신됨

해결하고 나서 느낀 점

문제를 해결하기 위한 전체적인 과정을 더 넓게 생각해보려고 했으면 어땠을까 하는 아쉬움이 남는다.

1. 브라우저에서 요청이 되었다

2. 요청이 호스트 PC에 도달하지 않는다

위 흐름에서 (1) 오픈스택 설정이 잘못된 것(요청이 잘못된 것)인지, (2) 네트워크 설정이 잘못된 것인지 규명하기 어려워 중구난방으로 해결하려고 했다.

물론, 위 내용 모두 내 배경지식이 부족한 탓에 확신을 가질 수 없었기에 더 어렵지 않았다 생각이 든다.

하지만 해결하기 위한 과정에서 네트워크 패킷 확인, 포트 확인 및 listening 확인 등의 과정을 능동적으로 접근해서 확인하면서 문제 해결 능력이 성장하고 있음을 느껴 뿌듯하기도 하다.