노프스모 스터디

노프스모 도커-쿠버 스터디 1주차

inspiring-ini 2024. 9. 28. 16:19

새로 알게 된 것

  • 🌟🌟 VMWare와 Docker는 가상화 수준이 다르다. 그리고 그 때문에 Docker가 훨씬 가볍다
  • 🌟 도커 이미지의 해시 값의 의미
    • 이미지 인덱스 (pull image 했을 때 Digest: sha256: abcfabcf.. 라고 뜨는 해시 값)는 여러 플랫폼 대상 이미지를 모두 포함하는, 그 버전 이미지를 대표하는 하나의 해시값이다
    • 이미지 매니페스트는 어떤 버전 이미지 중 어떤 특정한 플랫폼 (e.g. linux/amd64)용 이미지를 나타내는 해시값을 가지고 있다. docker pull 실행 시 기본적으로 로그에는 보이지 않는다
    • 레이어 해시값은 특정 플랫폼용 해당 이미지를 이루고 있는 여러 레이어에 대해 각 레이어마다 가지고 있는 해시값이다
    • docker image ls 실행 시 보이는 IMAGE ID는 이미지 다운로드 후에 로컬에서 할당한 ID이다
  • docker container commit {CONTAINER_ID} {IMAGE_NAME}:{TAG}
    • 항상 Dockerfile을 관리하면서 이미지를 빌드해오다보니 기존 컨테이너에 추가로 레이어를 올리는 기능이 있다고만 알았고 어떻게 하는지는 몰랐는데, 이렇게 하면 되는구나 알았다
  • docker container top {CONTAINER_ID}
    • 항상 docker container 안에 들어가서 top 명령어를 입력해서 봤었는데, 그렇게 하지 않고 바로 호스트 머신에서 top 결과를 볼 수 있는 명령어가 있었구나
  • docker run 보다는 docker container run이 더 신식 명령어이다 (다른 container 계열 명령어도 동일)

궁금해진 것 더 찾아보기

    • 도커 컨테이너는 왜 마이크로서비스 아키텍처의 기반인가? 쉽게 이해할 수 있는 예시가 있을까?
      • 각각의 서비스(마이크로서비스)를 독립적이고 경량화된 환경에서 실행할 수 있게 해주기 때문. 이를 통해 각 서비스는 서로 간섭 없이 독립적으로 개발, 배포, 유지보수가 가능
      • 독립적인 배포, 확장성(특정 서비스만 스케일 업), 신속한 테스트 및 롤백, 다양한 환경 지원 등의 장점이 있음
    • 🌟🌟 컨테이너 가상화를 사용하는 도커의 개념도를 보면 호스트 OS 위에서 모든 컨테이너가 돌아가기 때문에 호스트, 컨테이너가 항상 같은 OS를 사용해야 할 것처럼 보인다. 하지만 여태까지의 경험에 비추어 봤을 때 macOS에서도 ubuntu 컨테이너를 사용하는 것이 가능했다. 어찌 된 일일까? 그리고 깃헙 액션에서도 job이 실행될 OS 환경을 설정할 수 있었던 것 같은데, 이것은 어떤 수준의 가상화에서 동작하는 것일까?
      • 챗지피티한테 물어봤다. 이해한 바 대로 한줄요약 -> 리눅스 계열 OS는 경량 가상 머신을 사용하여 커널을 띄울 수 있기 때문에 macOS/Windows 에서는 리눅스 계열 OS 기반의 컨테이너를 띄우는 것이 가능. 반대는 불가
      • github action의 runner는 기본적으로 호스트 가상화 수준의 VM이다. 운영체제가 포함된 이미지를 가상 머신으로 띄운 것이다. 하지만 workflow에 옵션을 정의해서 runner VM 위에 컨테이너를 다시 올릴 수도 있다 https://docs.github.com/ko/actions/writing-workflows/choosing-where-your-workflow-runs/running-jobs-in-a-container
      • 챗지피티와 대화 👇
더보기
질답 전문
 
나의 말:
도커는 컨테이너 레벨의 가상화를 이용하는데, 그러면 호스트 머신 os와 컨테이너의 os가 같아야 할 것 같다고 이해했어. 하지만 macOS에서 ubuntu docker image 띄울 수 있잖아? 이건 어떻게 설명되는거야? 내가 잘못 이해한 게 있을까?
 

ChatGPT의 말:

ChatGPT

좋은 질문이에요! Docker가 사용하는 컨테이너 가상화는 전통적인 가상화와 다르게 호스트 OS 커널을 공유한다는 특징이 있습니다. 하지만 여기서 중요한 점은 커널 사용자 공간(user space)의 차이예요.

핵심 개념:

  1. 커널: 운영체제의 핵심 부분으로, 하드웨어 자원을 관리하고 시스템 호출을 처리하는 역할을 합니다. Docker 컨테이너는 호스트 OS의 커널을 직접 사용합니다. 예를 들어, Linux 기반 Docker 컨테이너는 Linux 커널을 공유해야만 작동합니다.
  2. 사용자 공간: 애플리케이션이 동작하는 부분입니다. Docker는 여기서 별도의 사용자 공간을 분리해 동작시키는데, 이 공간에는 각기 다른 운영체제의 파일 시스템을 가질 수 있습니다. 즉, Docker 컨테이너 안에 있는 파일 시스템은 호스트와 다른 운영체제일 수 있습니다.

어떻게 가능할까?

  • macOS에서 Ubuntu Docker 이미지를 실행할 수 있는 이유는 macOS가 Linux 커널을 직접 실행하는 것이 아니라, Docker가 macOS에서 Linux 컨테이너를 실행할 때 가상화 레이어를 추가로 사용하기 때문입니다.
    • macOS는 자체 커널인 XNU를 사용하고, Linux 컨테이너는 Linux 커널을 필요로 합니다. 그래서 macOS는 Docker Desktop을 통해 **경량 가상 머신(예: HyperKit, QEMU)**을 사용하여 Linux 커널을 실행시킨 후, 그 위에서 Ubuntu 컨테이너를 실행하게 됩니다.

정리:

  • Linux 호스트에서: Docker 컨테이너는 호스트의 Linux 커널을 직접 공유하고, 컨테이너는 그 위에 사용자 공간을 구성하여 다른 Linux 배포판을 실행합니다.
  • macOS나 Windows에서: Docker는 경량 가상 머신을 사용하여 Linux 커널을 실행하고, 그 위에서 Docker 컨테이너(Ubuntu 등)를 실행합니다. 이는 커널을 공유하지 않는 구조이지만, 사용자는 여전히 Docker로 쉽게 Linux 기반 컨테이너를 실행할 수 있습니다.

따라서 "호스트 OS와 컨테이너의 OS가 같아야 한다"는 이해는 Linux 기반 호스트에서 맞는 이야기지만, macOS나 Windows에서의 Docker 동작 방식은 추가적인 가상화 계층을 통해 이를 해결합니다.

 
 

나의 말:

그럼 ubuntu 위에 window docker image도 띄울 수 있어?
 

ChatGPT의 말:

Ubuntu(또는 다른 Linux 시스템) 위에서 Windows Docker 이미지를 직접 실행할 수는 없습니다. 그 이유는 Docker의 컨테이너는 호스트 커널을 공유하기 때문에, Windows 컨테이너는 Windows 커널이 필요하고, Ubuntu는 Linux 커널을 사용하기 때문입니다. Linux 커널과 Windows 커널은 서로 다르므로, 서로 호환되지 않습니다.

그러나 두 가지 해결 방법이 있습니다:

  1. Windows Subsystem for Linux 2 (WSL2):
    Windows에서는 WSL2를 사용해 Linux 환경을 가상화할 수 있고, 그 위에서 Ubuntu Docker 컨테이너를 실행할 수 있습니다. 반대 상황인 Linux에서 Windows 컨테이너 실행은 기본적으로는 불가능하지만, Windows 호스트에서 Linux 컨테이너와 Windows 컨테이너를 동시에 실행할 수 있습니다.
  2. 가상화 기술을 사용:
    만약 Linux(Ubuntu)에서 Windows 컨테이너를 실행하려면 전체 Windows 운영체제를 가상 머신으로 실행한 후 그 위에서 Windows용 Docker 컨테이너를 구동하는 방식이 가능합니다. 예를 들어, Ubuntu에서 VirtualBox, KVM, 또는 QEMU 같은 가상화 솔루션을 통해 Windows 가상 머신을 띄운 후 그 위에서 Windows Docker 컨테이너를 실행할 수 있습니다. 하지만 이 경우엔 성능과 복잡성이 증가합니다.

정리:

  • 직접적으로: Linux 호스트(Ubuntu) 위에서 Windows Docker 컨테이너를 바로 실행할 수는 없습니다. Windows 컨테이너는 Windows 커널이 필요하기 때문입니다.
  • 우회적으로: Windows를 가상화하거나, Windows에서 Linux 컨테이너를 실행하는 방식(WL2)으로는 가능하지만, 이 경우 추가적인 가상화 계층이 필요합니다.
 
나의 말:
우분투에서 macos를 띄우는 건?
 

ChatGPT의 말:

 

Ubuntu(또는 다른 Linux)에서 macOS를 직접 실행하는 것도 법적으로나 기술적으로 어려운 일이에요. 다음은 그 이유와 해결 방법입니다.

1. 법적 제한:

  • **Apple의 EULA(End User License Agreement)**에 따르면, macOS는 Apple 하드웨어에서만 실행될 수 있습니다. 이 때문에 macOS를 비(非)Apple 하드웨어에서 실행하는 것은 Apple의 라이선스 정책을 위반하게 됩니다.
  • 즉, macOS를 Ubuntu 머신에서 가상화하는 것은 EULA에 어긋납니다.

2. 기술적 제한:

  • macOS는 기본적으로 Apple의 하드웨어를 대상으로 설계되었습니다. 따라서 macOS를 Ubuntu나 다른 비-Apple 하드웨어에서 실행하려면 macOS가 해당 하드웨어에서 실행되도록 조정해야 합니다.
  • 또한, macOS는 Linux 커널이 아닌 XNU 커널을 사용하므로, 일반적으로 macOS 컨테이너나 이미지가 Linux 커널에서 바로 실행될 수 없습니다.

3. 해결 방법 (기술적 가능성):

macOS를 Ubuntu에서 띄우는 방법은 존재하지만, 이는 다음과 같은 우회 방법을 필요로 합니다:

  • Hackintosh:
    일부 개발자들은 macOS를 비-Apple 하드웨어에서 실행하기 위해 "Hackintosh"라는 커스텀 설치 방법을 사용합니다. 이를 통해 macOS를 다른 하드웨어에 설치할 수 있지만, 법적 문제와 기술적 복잡성이 따릅니다.
  • 가상화:
    macOS를 Linux(Ubuntu)에서 가상화하려면 가상화 소프트웨어를 사용해야 합니다. 예를 들어, QEMU KVM 같은 가상화 솔루션을 통해 macOS 이미지를 실행할 수 있습니다. 이를 위해서는 macOS용 이미지를 구하고, macOS가 가상 머신에서 실행될 수 있도록 설정해야 합니다. 하지만 이는 Apple 하드웨어가 아닌 곳에서 실행할 때 복잡하고 성능이 저하될 수 있으며, 여전히 Apple의 EULA를 위반하는 문제가 있습니다.
    • QEMU + macOS: QEMU는 오픈 소스 가상화 소프트웨어로, macOS 이미지를 실행할 수 있도록 설정할 수 있지만, 많은 설정 작업이 필요하며 성능도 일반적인 macOS 환경에 비해 떨어질 수 있습니다.

4. 대안:

  • Apple Silicon Mac 또는 Intel 기반 Mac에서 Ubuntu나 Linux를 듀얼 부팅하거나, **가상화 소프트웨어(VirtualBox, VMWare)**를 통해 Linux를 가상화하는 방법이 더 합법적이고 안정적인 대안입니다.

결론:

Ubuntu에서 macOS를 띄우는 것은 법적으로 문제가 될 수 있으며, 기술적으로도 쉽지 않습니다. 기술적으로는 QEMU 또는 KVM과 같은 가상화 도구로 가능하긴 하지만, Apple의 EULA를 준수하려면 Apple 하드웨어에서만 macOS를 실행해야 합니다.

 


내용 정리

https://product.kyobobook.co.kr/detail/S000213057687

 

한 권으로 배우는 도커 & 쿠버네티스 | 장철원 - 교보문고

한 권으로 배우는 도커 & 쿠버네티스 | STEP BY STEP, 원리부터 이해하는 도커 & 쿠버네티스 가이드클라우드 기반의 인프라가 보편화된 현재의 IT 환경에서 도커와 쿠버네티스는 애플리케이션을 개

product.kyobobook.co.kr

Chapter 2, 4.1, 4.2

사전 기초 지식

  1. 운영체제의 개념
  2. 프로그램, 프로세스, 스레드의 개념
  3. 네임스페이스의 개념

도커 기초 지식

  1. 도커의 정의
    • 운영체제 수준의 가상화 방식으로 소프트웨어를 배포하는 방식을 사용하는 PaaS 제품
    • 운영체제 수준의 가상화란? 라이브러리, 애플리케이션은 사용자가 관리하고 나머지 아랫단(운영체제 포함)은 업체가 관리하는 수준
    • 호스트 머신에 하드웨어, 운영체제, 도커 가 동작하고 있고, 그 위에 바이너리/라이브러리, 애플리케이션 을 포함한 컨테이너들이 올라가 있다
  2. 컨테이너의 개념
    • 소프트웨어를 배포할 때 필요한 코드, 라이브러리, 환경 설정 파일들을 한데 모아 격리시킨 후 실행가능한 패키지로 만든 것
    • 마이크로서비스 아키텍처의 기반
  3. 가상화의 개념
    • 물리적 리소스를 논리적 리소스로 추상화
    • 가상화의 종류로는 호스트 가상화, 하이퍼바이저 가상화, 컨테이너 가상화가 있다
      • 호스트 가상화: VMWare, VirtualBox처럼 호스트 운영체제 위의 하이퍼바이저 위에 “운영체제를 포함”한 가상 머신들이 실행됨
      • 하이퍼바이저 가상화: 호스트 가상화 방식에서 호스트 OS가 없다고 생각하면 됨. 따라서 부팅 시에 하나의 VM을 선택한다
      • 컨테이너 가상화: 도커가 사용하는 방식. 하나의 운영체제 위에 “컨테이너” 여러 개가 올라가 있다
  4. 도커 구성 요소
    • docker-cli, dockerd, containerd
      • ubuntu에서 설치할 때에는 apt install 시 이런 구성 요소를 일일이 입력해야 하는 것 같았는데, 맥/윈도우 에서는 Docker Desktop(GUI 프로그램임)을 설치하라고 안내가 뜬다. Docker Desktop을 설치하면 도커 구성 요소가 설치되며, cli에서도 물론 docker를 이용할 수 있다.

도커 기초 개념

  • 도커 클라이언트, 도커 호스트, 도커 레지스트리
  • 도커 이미지, 도커 컨테이너

도커 기초 명령어

  • docker image pull
  • docker image ls
  • docker container run = docker container create + docker container start
  • docker container exec
  • docker container attach
  • … 등등. 기초 명령어가 이렇게 많았나? 맨날 쓰는 것만 쓴다