Key Factors in Understanding Docker

Windows PowerShell VS PowerShell

Windows PowerShell과 PowerShell은 유사한 개념을 공유하지만, 중요한 차이점이 있습니다. 이들의 차이점을 이해하려면 각각의 배경과 진화 과정을 살펴볼 필요가 있습니다.

Windows PowerShell

• 출시: Microsoft에 의해 처음으로 출시된 Windows PowerShell은 2006년에 공개되었습니다. 이는 Windows 운영 체제를 위한 작업 자동화 및 구성 관리 프레임워크로, 명령어 셸과 스크립팅 언어 기능을 결합하고 있습니다.
• 기반 기술: Windows PowerShell은 .NET Framework에 기반하여 구축되었습니다. 이는 Windows PowerShell이 Windows 플랫폼과 긴밀하게 통합되어 있음을 의미합니다.
• 호환성: 주로 Windows 환경에 초점을 맞추고 있으며, Windows 서버 관리와 자동화 작업에 널리 사용됩니다.

PowerShell

• 출시: PowerShell Core라고도 불리는 PowerShell은 Windows PowerShell의 후속 버전으로, 버전 6.0부터 이 이름을 사용하기 시작했습니다. 이는 Microsoft가 Windows PowerShell의 오픈 소스, 크로스 플랫폼 버전을 만들기 위해 2016년에 발표한 것입니다.
• 기반 기술: PowerShell은 .NET Core에 기반하여 구축되었습니다. 이는 PowerShell을 Windows, macOS, Linux 등 다양한 운영 체제에서 실행할 수 있게 합니다.
• 호환성: PowerShell은 크로스 플랫폼을 지원하므로, 다양한 운영 체제에서 스크립트와 모듈을 사용하여 작업 자동화를 수행할 수 있습니다. 이는 IT 전문가들이 여러 환경에서 일관된 경험을 제공받을 수 있게 합니다.

주요 차이점 요약

• 플랫폼 지원: Windows PowerShell은 주로 Windows에 초점을 맞춘 반면, PowerShell은 Windows, macOS, Linux 등 다양한 플랫폼을 지원합니다.
• 기술 기반: Windows PowerShell은 .NET Framework에, PowerShell은 .NET Core (.NET 5 이후로는 단순히 .NET으로 명명)에 기반합니다.
• 발전 방향: PowerShell은 오픈 소스이며 지속적으로 발전하고 있는 반면, Windows PowerShell은 5.1 버전을 마지막으로 특정 시점에서 개발이 종료되었습니다.

결국, PowerShell은 Windows PowerShell의 더 현대적이고 유연한 후속 버전으로, 오늘날 많은 IT 전문가들에게 선호되는 도구입니다.

 

Docker Desktop 설치(교육용은 무료)

설치 가이드

 

 

WSL 이란?

Windows Subsystem for Linux(WSL)은 Microsoft Windows 운영 체제에서 직접 Linux 배포판을 실행할 수 있게 해주는 호환성 계층입니다. WSL을 사용하면 개발자와 시스템 관리자가 Windows 기반 시스템에서 Linux 환경을 세팅하고, Linux 명령어, 스크립트, 도구들을 사용하여 작업할 수 있습니다. WSL은 특히 크로스 플랫폼 개발, 애플리케이션 테스팅, 교육 목적, 또는 Linux 전용 도구를 Windows에서 사용하고 싶은 경우 유용합니다.

 

WSL (Windows Subsystem for Linux)은 실제 리눅스 커널을 기반으로 Windows에서 리눅스 환경을 제공합니다. WSL 2의 경우, 이는 특히 더 정확하며, 실제 리눅스 커널을 사용하여 전체 리눅스 시스템을 가상화합니다. 이를 통해 Windows에서 리눅스 바이너리 실행 파일들을 네이티브로 실행할 수 있게 됩니다.

\\wsl$\[배포판 이름] 경로 (예: \\wsl$\Ubuntu-22.04)는 Windows 파일 탐색기에서 WSL 인스턴스의 루트 파일 시스템에 접근할 수 있는 방법을 제공합니다. 이 경로를 통해 Windows 사용자는 리눅스 배포판의 파일 시스템을 탐색하고, 파일을 수정하거나, 리눅스 환경과 Windows 환경 간에 파일을 이동할 수 있습니다.

\\wsl.localhost\Ubuntu-22.04와 같은 경로도 비슷한 용도로 사용될 수 있는데, 이는 WSL 인스턴스에 네트워크를 통해 접근하는 또 다른 방법을 제시합니다. wsl.localhost는 현재 PC에서 실행 중인 WSL 인스턴스에 대한 접근을 의미하며, 여기에 배포판 이름을 추가하여 특정 리눅스 배포판의 파일 시스템에 접근할 수 있습니다.

따라서, \\wsl.localhost\Ubuntu-22.04 또는 \\wsl$\Ubuntu-22.04 경로는 실제로 Ubuntu 22.04 배포판의 루트 파일 시스템에 대한 접근 경로를 제공합니다. 이는 Windows와 리눅스 환경 간의 상호 운용성을 향상시키며, 개발자와 사용자가 두 운영 체제의 장점을 모두 활용할 수 있게 해줍니다.

 

WSL의 주요 특징과 장점

• 통합 개발 환경: Windows에서 개발하면서 Linux 기반 도구나 환경을 필요로 하는 개발자에게 이상적입니다.
• 명령어 호환성: 대부분의 Linux 명령어와 프로그램을 Windows에서 그대로 사용할 수 있습니다.
• 성능: WSL 2는 실제 Linux 커널을 사용하여 성능을 크게 향상시켰습니다. 이로 인해 파일 시스템 성능이 개선되고, Linux 호환성이 높아졌습니다.
• Windows와 Linux 간의 파일 시스템 접근: Windows 파일 탐색기를 통해 Linux 파일 시스템에 접근할 수 있으며, 반대로 Linux에서도 Windows 파일 시스템에 접근할 수 있습니다.
• 개발 도구의 선택: Visual Studio Code와 같은 개발 도구를 통해 WSL 내에서 직접 개발할 수 있습니다.

WSL 1과 WSL 2의 차이

WSL에는 두 가지 주요 버전, WSL 1과 WSL 2가 있습니다. 이들 간의 주요 차이점은 아래와 같습니다.

• 아키텍처: WSL 1은 Linux 시스템 호출을 Windows API 호출로 변환하는 호환성 계층을 사용합니다. 반면, WSL 2는 실제 Linux 커널을 사용하여 실행되는 경량의 가상 머신(VM) 방식을 채택하고 있습니다.
• 성능: WSL 2는 파일 시스템 성능과 시스템 호출 호환성 면에서 WSL 1보다 상당히 개선되었습니다. 특히, 대규모 프로젝트와 파일을 다루는 작업에서 성능 차이를 느낄 수 있습니다.
• 네트워킹: WSL 2는 가상 네트워크를 사용하여, 각 Linux 배포판이 자체 IP 주소를 갖고 Windows와는 독립적으로 작동합니다. 이는 네트워킹 동작을 더욱 Linux와 유사하게 만듭니다.

설치 및 사용 방법

WSL을 사용하기 위해서는 우선 Windows 기능을 통해 WSL을 활성화하고, Microsoft Store에서 원하는 Linux 배포판을 설치해야 합니다. WSL 2를 사용하기 위해서는 추가적으로 가상 머신 플랫폼 기능도 활성화하고, Linux 커널 업데이트 패키지를 설치해야 합니다.

WSL은 특히 개발자들에게 유용한 도구로, Linux와 Windows 환경 사이의 간극을 메우는 중요한 역할을 합니다.

설치 가이드

 

 

 

---

도커(Docker)는 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:

도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다

 

도커는 리눅스에서 운영 체제 수준 가상화의 추상화 및 자동화 계층을 추가적으로 제공한다.[6] 도커는 cgroups와 커널 이름공간과 같은 리눅스 커널의 기능들과 OverayFS, aufs와 같은 유니언 가능 파일 시스템의 리소스 격리 기능을 사용하며,[7] 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 가상 머신을 시작하여 유지보수해야 하는 부담을 없애준다.[8]

리눅스 커널의 이름공간 지원은 대체적으로[9] 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 libvirt, LXC (리눅스 컨테이너), systemd-nspawn을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer 라이브러리를 포함하고 있다

 

Docker Image Build

docker build 커맨드를 사용하여 Docker 이미지를 생성할 때, 생성된 이미지는 Docker 호스트의 로컬 이미지 저장소에 저장됩니다. 이 저장소는 Docker가 설치된 시스템 내부에 있으며, Docker 데몬이 관리합니다. 생성된 이미지에 접근하려면 Docker CLI나 Docker API를 사용해야 합니다.

이미지를 확인하려면 다음과 같은 Docker CLI 커맨드를 사용할 수 있습니다:

• docker images: 로컬 시스템에 저장된 모든 Docker 이미지의 리스트를 보여줍니다. 이 커맨드는 이미지 ID, 생성 시간, 크기 등의 정보와 함께 각 이미지의 저장소 이름과 태그를 출력합니다.
  
• docker image ls: docker images와 동일한 기능을 수행합니다.

docker build 커맨드를 사용할 때, -t 옵션으로 이미지에 이름과 태그를 할당할 수 있습니다. 예를 들어, 다음과 같이 입력할 수 있습니다:

docker build -t myimage:latest .

이 커맨드는 현재 디렉토리(.)의 Dockerfile을 사용하여 myimage라는 이름과 latest라는 태그를 가진 Docker 이미지를 생성하고, 이 이미지는 로컬 이미지 저장소에 저장됩니다.

이미지가 로컬 저장소에 있는지 확인하려면, docker images 또는 docker image ls 커맨드를 실행하고 출력된 목록에서 해당 이미지를 찾을 수 있습니다.

 

Docker Desktop

Windows OS에서 사용하는 Docker Desktop은 로컬 이미지 저장소를 가지고 있습니다. Docker Desktop은 Docker 데몬을 포함하고 있으며, 이 데몬이 로컬 이미지 저장소를 관리합니다. 사용자가 docker build 커맨드로 이미지를 생성하거나 docker pull 커맨드로 이미지를 다운로드할 때, 이러한 이미지들은 모두 Docker Desktop에 의해 관리되는 로컬 저장소에 저장됩니다.

Docker Desktop의 로컬 이미지 저장소에 저장된 이미지들은 docker images 또는 docker image ls 커맨드를 사용하여 확인할 수 있습니다. 이 커맨드들은 사용자가 로컬 시스템에 저장한 모든 Docker 이미지의 리스트를 보여주며, 이미지 ID, 저장소 이름, 태그, 생성 시간, 크기 등의 정보를 포함합니다.

Docker Desktop은 Windows에서 Docker를 사용하기 위한 통합 환경을 제공하며, 사용자가 Windows 환경에서도 Linux 컨테이너 및 Windows 컨테이너를 생성하고 관리할 수 있게 해줍니다. Docker Desktop의 가상화 기술과 함께, 로컬 이미지 저장소는 Docker 작업의 핵심적인 부분을 이룹니다.

 

 

DockerHub

Docker Hub에 개인 계정으로 Docker 이미지를 업로드하려면, 이미지를 먼저 생성하고 태그를 지정한 후 Docker Hub 계정에 로그인하여 이미지를 푸시(push)해야 합니다. 다음은 이 과정을 단계별로 설명합니다:

1. Docker Hub 계정 생성 및 로그인

• Docker Hub에 계정이 없다면, [Docker Hub](https://hub.docker.com/) 웹사이트에서 계정을 생성하세요.
• 로컬 시스템에서 Docker CLI를 사용하여 Docker Hub 계정에 로그인합니다. 터미널이나 커맨드 프롬프트에서 다음 명령어를 실행하세요: 

 docker login

 

• 사용자 이름과 비밀번호를 입력하여 로그인합니다.

2. Docker 이미지 생성 및 태그 지정

• Docker 이미지를 생성합니다. 이는 보통 docker build 명령어를 사용하여 Dockerfile로부터 수행됩니다.
• 생성된 이미지에 태그를 지정합니다. 태그는 일반적으로 username/repository:tag 형식을 따릅니다. 여기서 username은 Docker Hub 사용자 이름이고, repository는 Docker Hub에 생성할 리포지토리 이름이며, tag는 이미지 버전을 식별하는 태그입니다 (예: latest). 다음 명령어를 사용하여 이미지에 태그를 지정할 수 있습니다:

docker tag local-image:tag username/repository:tag

 

// 예시
docker tag myapp:latest myusername/myapp:latest

3. 이미지 푸시

• 태그가 지정된 이미지를 Docker Hub에 푸시합니다. 다음 명령어를 사용하세요:

docker push username/repository:tag

예시:

docker push myusername/myapp:latest

• 이 명령어를 실행하면 지정된 태그를 가진 이미지가 Docker Hub의 계정으로 업로드됩니다.

4. Docker Hub에서 확인

• 업로드가 완료되면, Docker Hub 웹사이트에서 로그인하여 리포지토리 페이지를 방문하고, 새로 푸시된 이미지가 있는지 확인할 수 있습니다.

이 과정을 통해 Docker 이미지를 Docker Hub의 개인 계정에 성공적으로 업로드할 수 있습니다. Docker Hub는 이렇게 업로드된 이미지를 공유하거나 배포하는 데 유용한 플랫폼입니다.

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Linux Control Group

https://access.redhat.com/documentation/ko-kr/red_hat_enterprise_linux/6/html/resource_management_guide/ch01

1장. 컨트롤 그룹 (Cgroups) 소개 Red Hat Enterprise Linux 6 | Red Hat Customer Portal

https://junsoolee.gitbook.io/linux-insides-ko/summary/cgroups/linux-cgroups-1

Introduction to Control Groups - linux-insides-ko

 

Linux Name Space

Linux namespace는 운영체제의 커널 기능 중 하나로, 프로세스들이 시스템의 다른 부분들과 격리되도록 해주는 기능입니다. 이를 통해 프로세스들은 마치 그들만의 독립된 시스템을 가진 것처럼 동작할 수 있습니다.

Namespace는 다음과 같은 여러 종류가 있습니다:

1. Mount (mnt): 파일 시스템 마운트 포인트의 격리를 허용합니다.
2. Process ID (pid): 프로세스 아이디의 격리를 허용합니다. 즉, 각각의 namespace 내부에서는 독립된 PID 공간을 가질 수 있습니다.
3. Network (net): 네트워크 인터페이스, 라우팅 테이블 등 네트워크 리소스의 격리를 허용합니다.
4. Interprocess Communication (ipc): 프로세스 간 통신(IPC) 리소스의 격리를 허용합니다.
5. UTS (Unix Timesharing System): 호스트네임과 도메인네임의 격리를 허용합니다.
6. User ID (user): 사용자 및 그룹 ID의 격리를 허용합니다.

이러한 namespace를 사용함으로써, 리눅스 시스템에서는 컨테이너와 같은 경량화된 가상화 기능을 제공할 수 있으며, 각 프로세스 또는 프로세스 그룹이 시스템의 다른 부분들과는 독립적으로 관리될 수 있습니다.

반면에 디바이스 파일을 읽고 쓰기 위한 시스템은 일반적으로 리눅스의 udev (userspace /dev) 시스템 또는 devfs (device filesystem) 와 같은 기능을 통해 제공됩니다. 이러한 시스템은 디바이스 노드를 관리하고, 디바이스들이 시스템에 추가되거나 제거될 때 동적으로 디바이스 파일을 생성하거나 삭제합니다.

 

 

Application vs system containers

애플리케이션 컨테이너(예: Docker)와 시스템 컨테이너는 두 가지 다른 유형의 컨테이너입니다.

애플리케이션 컨테이너는 하나의 프로세스만을 실행하는 컨테이너로, 일반적으로 상태를 가지지 않는 워크로드를 실행합니다. 이러한 컨테이너는 필요에 따라 생성하고 삭제할 수 있으므로 필요할 때 새로운 컨테이너를 생성하고 삭제할 수 있습니다. 보통 이러한 컨테이너의 수명주기에 대해 걱정할 필요가 없으며, 그들은 일시적으로 사용되기 위해 만들어진 것입니다.

반면 시스템 컨테이너는 가상 머신이나 물리적 머신과 유사한 방식으로 작동합니다. 이러한 컨테이너 내부에는 완전한 운영 체제가 실행되며, 이를 가상 머신이나 물리적 머신처럼 관리합니다. 이것은 컨테이너 내에서 패키지를 설치하고 서비스를 관리하며 백업 정책, 모니터링 및 기타 측면을 정의할 수 있다는 것을 의미합니다. 이러한 컨테이너는 일반적으로 매우 오래 지속됩니다. 업데이트가 필요한 경우 해당 Linux 배포판의 정상적인 도구를 사용하여 업데이트할 수 있습니다. 또한 이러한 컨테이너에 대해 배포판에서 정상적인 보안 업데이트를 제공하므로 보안 수정을 받기 위해 이미지를 기다릴 필요가 없습니다.

 

Linux Containers

리눅스 컨테이너 또는 LXC(Linux Containers)는 주로 리눅스 주요 기능을 기반으로 한 시스템 컨테이너의 첫 번째 구현으로 알려져 있습니다. 이것은 완전히 깨끗한 상위 스트림 커널 또는 어떤 리눅스 배포판에서 제공하는 커널을 가져와서 리눅스에서 컨테이너를 생성할 수 있다는 것을 의미합니다. LXC 자체는 시스템 컨테이너와 애플리케이션 컨테이너를 모두 만들 수 있는 저수준 도구입니다. Docker는 초기에 LXC를 기반으로 하였으며, 나중에 자체 런타임을 구현하여 LXC를 대체하였습니다.

LXC 컨테이너는 종종 chroot와 완전한 가상 머신 사이의 중간 어딘가로 간주됩니다. LXC의 목표는 별도의 커널이 필요하지 않는 상태에서 표준 리눅스 설치와 가능한 가까운 환경을 만드는 것입니다. LXC 컨테이너는 본질적으로 호스트와 동일한 커널에서 실행되는 운영 체제의 복사본입니다. 따라서 이 경우에는 아무것도 가상화하지 않으며 오버헤드 프로세스도 없습니다. 커널 관점에서 컨테이너에서 실행되는 모든 프로세스는 시스템의 일반적인 프로세스일 뿐이며, 운영 체제에 대한 약간 다른 관점을 가지고 있는 것 뿐입니다.

 

When should you use Linux containers?

리눅스를 리눅스에서 실행할 때, 가상 머신 대신 컨테이너를 사용하는 것을 고려해야 합니다. 가상 머신이 수행할 수 있는 것들 중에서 리눅스 컨테이너가 수행할 수 없는 것은 별로 없습니다. 거의 모든 사용 사례에서 시스템 컨테이너에서 정확히 동일한 워크로드를 실행할 수 있으며, 일반적으로 가상 머신을 사용할 때 발생하는 오버헤드를 겪지 않을 것입니다. 유일한 예외는 호스트의 커널과 다른 특정 커널 버전이 필요한 경우 또는 해당 가상 머신의 특정 기능이 필요한 경우입니다.

시스템 컨테이너는 가상 머신보다 훨씬 쉽게 관리할 수 있습니다. 호스트 시스템에서 직접 그들이 하는 모든 작업을 볼 수 있으며, 그 안에서 실행되는 모든 프로세스를 볼 수 있습니다. 또한 파일 시스템을 직접 공유하거나 특정 파일을 공유하고, 리소스 소비를 제한하거나 증가시킬 수 있으며 다시 시작할 필요가 없습니다. 호스트에 있는 장치를 컨테이너로 전달하거나 언제든지 제거할 수 있으며 이를 달성하기 위해 특정 하드웨어, 펌웨어, 드라이버 또는 기타 것이 필요하지 않습니다. 이로써 리눅스 컨테이너는 개발과 프로덕션 환경 모두에서 물리적 또는 가상 머신을 대체하는 이상적인 옵션이 됩니다.

 

What is LXD?

LXD는 LXC 위에서 실행되는 시스템 컨테이너 및 가상 머신 관리자로, 사용자 경험을 향상시키고 더 쉬운 제어와 유지 관리를 가능하게 합니다. LXD는 이미지 기반으로 작동하며 다양한 리눅스 배포판에 대한 이미지를 제공합니다. 간단한 명령 줄 도구를 사용하여 인스턴스를 쉽게 관리할 수 있으며, 서드파티 오케스트레이션 및 관리 도구와 쉽게 통합할 수 있습니다. LXD는 클러스터를 실행할 수 있으며 다양한 스토리지 백엔드와 네트워크 유형을 지원하며 노트북의 하나의 인스턴스에서부터 데이터 센터의 완전한 랙까지 쉽게 확장될 수 있습니다.

 

LXD vs LXC

LXC                                                                                              LXD

– Linux container runtime allowing creation of multiple isolated Linux systems (containers) on a control host using a single Linux kernel – Only supports containers – Low-level tool requiring expertise

– System container and virtual machine manager built on top of LXC, enabling easier management, control and integration – Supports container and VMs – Better user experience through a simple REST API

 

What is Docker Container ?

컨테이너를 사용하면 애플리케이션 소프트웨어와 그 모든 종속성을 하나의 프로세스 패키지로 묶을 수 있습니다. 컨테이너는 다양한 버전으로 관리될 수 있어, 팀이 개발자/테스터 또는 클러스터 내에서 동일한 애플리케이션 인스턴스를 쉽게 복제할 수 있게 합니다.

컨테이너 이미지에는 실행을 위해 필요한 모든 것이 포함되어 있으며 코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정 등이 포함됩니다. 컨테이너는 가볍고 독립적으로 작동할 수 있으며 Linux 및 Windows 기반 앱 모두에 사용할 수 있습니다. 컨테이너 실행 소프트웨어의 가장 큰 장점은 Docker 컨테이너가 애플리케이션을 서로 및 하부 인프라로부터 격리시켜 환경에 관계없이 항상 동일하게 실행된다는 것입니다. 예를 들어, 컨테이너는 개발, 테스트, 스테이징 또는 프로덕션 환경과 같이 다른 환경에서 동일한 애플리케이션을 실행하는 팀 간의 충돌을 줄이는 데 도움이 됩니다.