Deep Study - dingdongdengdong/astra_ws GitHub Wiki

1. FROM ros:humble-ros-base

• ros:humble-ros-base 대신 다른 이미지 사용:
  • ros:humble-ros-core: ROS의 핵심 패키지만 포함되어 있어 ros-humble-desktop을 설치할 필요 없이 용량이 더 작고 가볍습니다. 하지만 GUI 환경이나 시뮬레이션 관련 패키지들이 포함되어 있지 않아 필요하다면 추가적으로 설치해야 합니다.
  • ros:humble-ros-desktop: ros-humble-desktop 패키지가 기본적으로 설치되어 있어 Docker 이미지 크기는 커지지만, 따로 설치할 필요 없이 바로 데스크탑 환경을 사용할 수 있습니다.
  • ubuntu:22.04 또는 다른 OS 이미지: ROS가 사전 설치되지 않은 기본 운영체제 이미지를 사용하면, ROS를 처음부터 직접 설치해야 합니다. 이는 이미지 빌드 시간이 훨씬 오래 걸리고, ROS 설치에 필요한 의존성 패키지들을 모두 수동으로 관리해야 하는 번거로움이 있습니다. 하지만 원하는 ROS 버전이나 특정 환경에 대한 세밀한 제어가 가능합니다.

2. ARG USERNAME=rosdev, ARG UID=1000, ARG GID=$UID

이 변수들은 Docker 컨테이너 내에서 생성될 사용자 계정의 이름(USERNAME), 사용자 ID(UID), 그룹 ID(GID)를 정의합니다.

• USERNAME 변경:
  • 예: ARG USERNAME=myuser: 컨테이너 내에서 rosdev 대신 myuser라는 이름의 사용자 계정이 생성됩니다. $HOME 디렉토리도 /home/myuser로 변경됩니다. 이는 컨테이너 내에서 작업하는 사용자 계정의 이름만 바뀌는 것이므로 기능적인 큰 차이는 없지만, 사용자가 익숙한 이름으로 설정하여 편의성을 높일 수 있습니다.
• UID, GID 변경:
  • 예: ARG UID=1001, ARG GID=1001: 컨테이너 내에서 생성될 사용자의 UID와 GID가 1001로 변경됩니다.
  • 가장 중요한 차이점: 호스트 머신(Docker를 실행하는 컴퓨터)과 컨테이너 간의 파일 권한 문제를 해결하는 데 중요합니다.
    • 동일하게 설정: 만약 호스트 머신에서 작업하는 사용자 계정의 UID/GID와 컨테이너 내 사용자 계정의 UID/GID가 동일하다면, 호스트와 컨테이너 간에 파일을 공유할 때 권한 문제가 발생할 가능성이 줄어듭니다. 예를 들어, 호스트에서 생성한 파일을 컨테이너 내에서 수정하거나, 컨테이너 내에서 생성한 파일을 호스트에서 접근할 때 권한 충돌이 발생하지 않아 sudo 없이도 자유롭게 파일을 관리할 수 있습니다.
    • 다르게 설정: UID/GID가 다르면, 호스트와 컨테이너 간에 파일을 공유할 때 권한 문제가 발생할 수 있습니다. 예를 들어, 컨테이너에서 생성된 파일은 호스트에서 다른 사용자(UID가 다른)가 소유한 것으로 인식되어 접근 권한이 없거나, sudo를 사용해야 하는 상황이 발생할 수 있습니다. 이는 개발 환경 설정 시 불편함을 초래할 수 있습니다.

3. RUN apt install -y --no-install-recommends ... ros-humble-desktop

• ros-humble-desktop 대신 다른 ROS 패키지 설치:
  • ros-humble-desktop-full: ROS 데스크탑 환경뿐만 아니라 시뮬레이션 도구(Gazebo), 2D/3D 시뮬레이터, 내비게이션 등 더 많은 패키지가 포함됩니다. 이미지 크기가 더 커지지만, 추가적인 개발 환경 설정 없이 바로 다양한 ROS 애플리케이션을 사용할 수 있습니다.
  • ros-humble-ros-base (이미지에서 이미 포함): ROS의 핵심 패키지만 포함됩니다. 만약 FROM에서 ros:humble-ros-base를 사용한다면 이 부분은 불필요하거나, 다른 최소한의 패키지만 설치할 때 사용합니다.
  • 특정 ROS 패키지: ros-humble-slam-toolbox, ros-humble-navigation2 등 특정 기능에 필요한 패키지만 설치할 수 있습니다. 이렇게 하면 이미지 크기를 줄이고 필요한 기능만 포함할 수 있습니다.

4. RUN groupadd -g $GID $USERNAME && useradd -lm -u $UID -g $USERNAME -s /bin/bash $USERNAME

이 부분은 위에서 설명한 UID와 GID 변수의 변경에 따라 직접적으로 영향을 받습니다. 변수 값이 변경되면 생성되는 사용자의 UID와 GID가 그 값으로 변경됩니다.

5. WORKDIR /home/$USERNAME/ros2_ws

• ros2_ws 대신 다른 워크스페이스 이름 사용:
  • 예: WORKDIR /home/$USERNAME/my_project: 컨테이너의 기본 작업 디렉토리가 /home/$USERNAME/my_project로 변경됩니다. 이는 사용자가 컨테이너에 접속했을 때 처음으로 위치하게 되는 디렉토리이자, ros2_ws 대신 다른 이름의 ROS 워크스페이스를 사용하고자 할 때 변경합니다. 여러 프로젝트를 진행할 경우 각 프로젝트별로 워크스페이스 이름을 다르게 지정하여 혼동을 피할 수 있습니다.

6. .bashrc 설정 (소스 경로 및 환경 변수)

• source /opt/ros/$ROS_DISTRO/setup.bash:
  • ROS_DISTRO는 이 Dockerfile에서는 humble로 고정되어 있습니다. 만약 FROM 이미지에서 다른 ROS 배포판(예: ros:iron-ros-base)을 사용한다면 $ROS_DISTRO 값도 iron으로 변경되어야 합니다. 그렇지 않으면 ROS 환경 설정이 올바르게 로드되지 않아 ros2 명령어를 사용할 수 없게 됩니다.
• source /home/$USERNAME/ros2_ws/install/setup.bash:
  • ros2_ws 대신 다른 워크스페이스 이름을 사용했다면, 이 경로도 변경해야 합니다. 변경하지 않으면 사용자가 빌드한 ROS 패키지를 실행할 수 없습니다.

7. COPY ./ros_entrypoint.sh /

• ./ros_entrypoint.sh 대신 다른 파일 사용:
  • 만약 컨테이너 시작 시 실행될 스크립트의 이름이나 경로를 변경하고 싶다면 이 부분을 수정합니다. ros_entrypoint.sh는 일반적으로 ROS 환경 설정을 로드하고 CMD로 지정된 명령어를 실행하는 역할을 합니다. 다른 시작 로직이 필요하다면 새로운 스크립트를 작성하여 복사하고 ENTRYPOINT를 수정해야 합니다.

8. ENTRYPOINT ["/ros_entrypoint.sh"]

• "/ros_entrypoint.sh" 대신 다른 명령어 사용:
  • 컨테이너가 시작될 때 항상 실행되는 기본 명령어입니다. 이 스크립트는 일반적으로 ROS 환경을 설정하고 CMD에서 제공되는 명령을 실행합니다. 만약 다른 종류의 애플리케이션을 컨테이너 시작 시 실행하고 싶다면 이 부분을 변경할 수 있습니다.
  • 예: ENTRYPOINT ["python3", "/app/my_script.py"]: 컨테이너 시작 시 항상 Python 스크립트를 실행합니다.

9. CMD ["bash"]

• ["bash"] 대신 다른 명령어 사용:
  • ENTRYPOINT가 지정되지 않았거나, ENTRYPOINT가 스크립트인 경우 해당 스크립트가 실행된 후 CMD에 지정된 명령어가 실행됩니다.
  • 현재 설정은 bash 셸을 시작하므로 컨테이너에 진입했을 때 명령어를 직접 입력할 수 있습니다.
  • 예: CMD ["ros2", "launch", "my_package", "my_node.launch.py"]: 컨테이너가 시작될 때 특정 ROS 노드를 자동으로 실행합니다. 이는 ROS 애플리케이션을 배포할 때 유용합니다.
  • 예: CMD ["sleep", "infinity"]: 컨테이너를 계속 실행 상태로 유지하고 싶을 때 사용합니다. (이 경우 docker exec 등으로 컨테이너에 접속하여 작업합니다.)

요약 및 주요 고려사항:

변수 값들을 변경함으로써 다음과 같은 주요 차이가 발생합니다:

1. 기반 환경: 사용하는 Docker 이미지에 따라 ROS 설치 상태, 크기, 그리고 초기 설정이 달라집니다.
2. 사용자 계정 및 권한: USERNAME, UID, GID는 컨테이너 내에서 작업할 사용자의 계정 정보와 권한을 결정하며, 호스트와의 파일 공유 시 권한 문제에 큰 영향을 미칩니다. 특히 UID와 GID는 호스트와 컨테이너 간의 권한 일치를 위해 중요합니다.
3. 설치되는 ROS 패키지: apt install에서 설치하는 ROS 패키지에 따라 컨테이너의 기능과 크기가 달라집니다. 필요한 최소한의 패키지만 설치하여 이미지 크기를 최적화하거나, 모든 기능을 포함하여 편리성을 높일 수 있습니다.
4. 워크스페이스 및 작업 경로: WORKDIR 및 .bashrc의 워크스페이스 경로는 사용자의 작업 환경과 ROS 패키지 빌드 및 실행에 직접적인 영향을 미칩니다.
5. 컨테이너 시작 동작: ENTRYPOINT와 CMD는 컨테이너가 실행될 때 어떤 명령어가 어떤 방식으로 실행될지를 정의하며, 이는 컨테이너의 용도(개발 환경, 애플리케이션 배포 등)에 따라 매우 중요합니다.

이러한 차이점들을 이해하고 각 변수의 값을 프로젝트의 요구사항과 개발 환경에 맞게 조정하는 것이 중요합니다.

---

두 가지 방식(FROM ros:humble-ros-base 후 RUN apt install ros-humble-desktop vs. FROM ros:humble-ros-desktop 바로 사용)의 차이점

---

비유: 자동차 구매 vs. 조립

우리가 자동차를 구매한다고 생각해 봅시다.

1. FROM ros:humble-ros-desktop 방식:

   • 완성된 자동차(풀옵션 모델)를 구매하는 것과 같습니다.
   • 장점:
     • 구매 즉시 운전할 수 있습니다. (Dockerfile이 간결하고, 빌드 후 바로 사용 가능)
     • 헤드라이트, 에어컨, 내비게이션 등 필요한 기능이 모두 기본으로 장착되어 있습니다. (ROS 데스크탑에 필요한 Rviz, Gazebo 등이 모두 포함)
   • 단점:
     • 내가 필요 없는 기능(예: 선루프나 고성능 스피커)까지도 포함되어 있어, 차값이 비싸고(이미지 용량이 크고), 무게도 더 나갑니다. (불필요한 패키지 포함으로 이미지 크기 증가)
     • 나중에 특정 부품만 다른 브랜드로 바꾸고 싶어도, 기존에 장착된 것을 떼어내고 다시 설치해야 하므로 번거롭습니다. (이미지 레이어 구조상 특정 패키지만 제거하거나 교체하기 어려움)

2. FROM ros:humble-ros-base 후 RUN apt install ros-humble-desktop 방식:

   • 자동차 뼈대(섀시)를 구매하고, 그 위에 필요한 부품들을 하나씩 조립하는 것과 같습니다.
   • 장점:
     • 가장 기본적인 뼈대만 있기 때문에 초기 비용이 저렴하고(base 이미지 용량이 작음), 더 빠르게 가져올 수 있습니다. (초기 레이어 다운로드 및 캐싱 빠름)
     • 내가 원하는 헤드라이트, 에어컨, 내비게이션을 직접 선택해서 장착할 수 있습니다. (필요한 apt install 패키지를 선택적으로 추가 가능)
     • 나중에 내비게이션 시스템만 최신 모델로 바꾸고 싶다면, 내비게이션 부품만 교체하면 됩니다. 다른 부품들은 그대로 유지됩니다. (캐싱 효율성: base 레이어는 그대로 두고 apt install 레이어만 다시 빌드)
     • 꼭 ros-humble-desktop이 아니더라도, ros-humble-ros-core만 설치하거나, 특정 시뮬레이터 패키지만 설치하는 등 매우 유연하게 맞춤형 자동차를 만들 수 있습니다.
   • 단점:
     • 완성된 자동차를 만드는 데 추가적인 시간과 노력이 필요합니다. (Dockerfile에 RUN apt install 명령어가 추가되고, 이 과정에서 시간이 소요됨)
     • 조립 과정에서 실수가 발생할 수 있습니다. (설치 중 오류 발생 가능성)
     • 최종적으로는 완성된 자동차와 기능적으로는 같지만, 미묘한 차이(예: 각 부품의 버전, 설치 순서에 따른 종속성 차이)가 있을 수 있습니다.

---

Docker 레이어 관점에서 더 깊이 이해하기:

Docker 이미지는 여러 개의 읽기 전용(read-only) 레이어가 쌓여 만들어집니다. 각 Dockerfile 명령(특히 FROM, RUN, COPY, ADD)은 새로운 레이어를 생성합니다.

• FROM ros:humble-ros-desktop 의 경우:

  • Docker Hub에서 ros:humble-ros-desktop 이미지를 다운로드합니다. 이 이미지는 이미 수많은 레이어들이 합쳐져 ros-base 환경 위에 ros-humble-desktop과 관련된 모든 패키지들을 설치한 상태입니다.
  • 즉, ros-humble-desktop을 설치하는 모든 apt install 명령과 그 결과물들이 이미 하나의 거대한 사전 빌드된 레이어 묶음으로 존재합니다.
  • 당신의 Dockerfile은 이 거대한 레이어 묶음 위에 새로운 레이어(예: 사용자 생성, 워크스페이스 생성 등)를 추가하게 됩니다.

• FROM ros:humble-ros-base 후 RUN apt install ros-humble-desktop 의 경우:

  1. FROM ros:humble-ros-base: 첫 번째 레이어는 ros-base 이미지입니다. 이 이미지는 ros-desktop에 비해 훨씬 작습니다.
  2. RUN apt update -q && apt upgrade -q -y: 두 번째 레이어는 시스템 업데이트를 수행합니다.
  3. RUN apt install -y --no-install-recommends ... ros-humble-desktop: 세 번째 레이어에서 ros-humble-desktop 패키지 및 다른 필요한 패키지들을 새롭게 설치합니다. 이 과정에서 apt install 명령에 의해 파일 시스템에 많은 변경이 일어나고, 이 모든 변경 사항이 새로운 레이어에 기록됩니다.
  4. RUN apt clean && rm -rf /var/lib/apt/lists/*: 네 번째 레이어에서 설치 후 남은 임시 파일을 제거합니다. 이는 이미지 크기를 줄이는 데 도움이 됩니다.

핵심 차이점은 캐싱(Caching)입니다.

만약 당신이 Dockerfile의 RUN apt install 라인을 변경하고 싶다면:

• FROM ros:humble-ros-desktop 방식: 이 이미지를 사용하면, ros-humble-desktop의 내용은 이미 첫 번째 레이어에 고정되어 있습니다. 만약 당신이 ros-humble-desktop의 특정 구성요소만 바꾸거나, 다른 ROS 패키지(예: ros-humble-navigation2)를 추가하고 싶다면, apt install을 추가해야 합니다. 이 추가된 apt install은 ros-humble-desktop이 이미 설치된 레이어 위에 새로운 레이어를 생성하게 되므로, 중복되거나 불필요한 파일이 많아질 가능성이 있습니다. 또한, 이미 설치된 것을 제거하는 과정은 더 복잡하고, 이미지 크기를 줄이는데 한계가 있습니다.

• FROM ros:humble-ros-base 후 RUN apt install ... 방식:

  • 만약 당신이 ros-humble-desktop 대신 ros-humble-perception을 설치하고 싶다면, apt install 라인만 수정하면 됩니다.
  • Docker는 FROM 레이어와 apt update 레이어는 캐시에서 재사용하고, apt install 레이어부터 새롭게 빌드합니다. 이는 전체 이미지 빌드 시간을 단축시키고, 원하는 패키지 구성으로 유연하게 변경할 수 있게 합니다.

실용적인 관점에서의 선택:

• 가장 일반적이고 빠른 시작: 만약 당신의 프로젝트가 ROS 데스크탑 환경의 모든 기능을 필요로 하고, 이미지 크기에 크게 민감하지 않다면 FROM ros:humble-ros-desktop이 가장 단순하고 효율적입니다. "한 번에 처리"한다는 측면에서 좋습니다.

• 세부 제어 및 최적화: 만약 당신이 최종 이미지의 크기를 최소화해야 하거나, 특정 ROS 패키지만 설치하고 싶을 때, 혹은 빌드 과정의 특정 단계에서 추가적인 커스터마이징을 하고 싶을 때는 FROM ros:humble-ros-base 후 필요한 패키지를 RUN apt install로 추가하는 방식이 더 강력하고 유연합니다. 이는 마치 레고 블록처럼 내가 원하는 구성 요소를 선택해서 조립하는 방식이라고 할 수 있습니다.

제공된 Dockerfile은 ros-humble-ros-base를 기반으로 ros-humble-desktop을 명시적으로 설치하는데, 이는 아마도 빌드 과정의 투명성과 제어력을 높이려는 의도일 가능성이 높습니다. 사용자가 apt install 부분을 수정하여 다른 ROS 패키지를 설치하거나, 불필요한 것을 제거하여 이미지를 최적화하기에 용이합니다.