Proxmox VE 매뉴얼을 Google Translate로 기계번역하고, 살짝 교정했습니다.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html
version 8.1.4, Wed Mar 6 18:21:39 CET 2024
컨테이너는 완전히 가상화된 머신(VM)에 대한 경량 대안입니다. 전체 운영 체제(OS)를 에뮬레이트하는 대신 실행되는 호스트 시스템의 커널을 사용합니다. 이는 컨테이너가 호스트 시스템의 리소스에 직접 액세스할 수 있음을 의미합니다.
컨테이너의 런타임 비용은 낮으며 일반적으로 무시할 수 있습니다. 그러나 고려해야 할 몇 가지 단점이 있습니다.
- Proxmox 컨테이너에서는 Linux 배포판만 실행할 수 있습니다. 예를 들어 FreeBSD 또는 Microsoft Windows와 같은 다른 운영 체제를 컨테이너 내에서 실행할 수 없습니다.
- 보안상의 이유로 호스트 리소스에 대한 액세스를 제한해야 합니다. 따라서 컨테이너는 자체 별도의 네임스페이스에서 실행됩니다. 또한 일부 syscall(Linux 커널에 대한 사용자 공간 요청)은 컨테이너 내에서 허용되지 않습니다.
Proxmox VE는 Linux Containers(LXC)를 기본 컨테이너 기술로 사용합니다. “Proxmox Container Toolkit”(pct)은 복잡한 작업을 추상화하는 인터페이스를 제공하여 LXC의 사용 및 관리를 단순화합니다.
컨테이너는 Proxmox VE와 긴밀하게 통합됩니다. 이는 클러스터 설정을 인식하고 가상 머신과 동일한 네트워크 및 스토리지 리소스를 사용할 수 있음을 의미합니다. Proxmox VE 방화벽을 사용하거나 HA 프레임워크를 사용하여 컨테이너를 관리할 수도 있습니다.
우리의 주요 목표는 추가 오버헤드 없이 VM 사용의 이점을 제공하는 환경을 제공하는 것입니다. 즉, Proxmox 컨테이너는 “Application Containers”가 아닌 “System Containers”로 분류될 수 있습니다.
참고: Docker 이미지와 같은 애플리케이션 컨테이너를 실행하려면 Proxmox QEMU VM 내에서 실행하는 것이 좋습니다. 이는 애플리케이션 컨테이너화의 모든 이점을 제공하는 동시에 컨테이너에서는 불가능한 호스트로부터의 강력한 격리, 라이브 마이그레이션 기능 등 VM이 제공하는 이점도 제공합니다.
11.1. 기술개요
- LXC(https://linuxcontainers.org/)
- Proxmox VE 그래픽 웹 사용자 인터페이스(GUI)에 통합
- 사용하기 쉬운 명령줄 도구 pct
- Proxmox VE REST API를 통한 액세스
- 컨테이너화된 /proc 파일 시스템을 제공하는 lxcfs
- 리소스 격리 및 제한을 위한 제어 그룹(cgroup)
- 보안을 강화하는 AppArmor 및 seccomp
- 최신 Linux 커널
- 이미지 기반 배포(templates)
- Proxmox VE 스토리지 라이브러리 사용
- 호스트(네트워크, DNS, 스토리지 등)에서 컨테이너 설정
11.2. 지원하는 배포판
공식적으로 지원되는 배포판 목록은 아래에서 확인할 수 있습니다.
다음 배포판에 대한 템플릿은 당사 리포지토리를 통해 제공됩니다. pveam 도구나 그래픽 사용자 인터페이스를 사용하여 다운로드할 수 있습니다.
11.2.1. Alpine Linux
Alpine Linux는 musl libc 및 busybox를 기반으로 하는 보안 지향의 경량 Linux 배포판입니다.
- https://alpinelinux.org
현재 지원되는 릴리스는 다음을 참조하세요. https://alpinelinux.org/releases/
11.2.2. Arch Linux
Arch Linux는 단순함을 추구하는 가볍고 유연한 Linux® 배포판입니다.
- https://archlinux.org/
Arch Linux는 롤링 릴리스 모델을 사용하고 있습니다. 자세한 내용은 해당 위키를 참조하세요. https://wiki.archlinux.org/title/Arch_Linux
11.2.3. CentOS, Almalinux, Rocky Linux
CentOS / CentOS 스트림
CentOS Linux 배포판은 RHEL(Red Hat Enterprise Linux) 소스에서 파생된 안정적이고 예측 가능하며 관리 및 재현 가능한 플랫폼입니다.
- https://centos.org
현재 지원되는 릴리스는 다음을 참조하세요. https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
11.2.4. Debian
데비안은 데비안 프로젝트에서 개발하고 유지 관리하는 무료 운영 체제입니다. 사용자의 요구 사항을 충족하는 수천 개의 응용 프로그램이 포함된 무료 Linux 배포판입니다.
— https://www.debian.org/intro/index#software
현재 지원되는 릴리스는 다음을 참조하세요. https://www.debian.org/releases/stable/releasenotes
11.2.5. Devuan
Devuan GNU+Linux는 사용자가 불필요한 얽힘을 피하고 Init Freedom을 보장하여 시스템에 대한 제어권을 다시 확보할 수 있도록 하는 systemd가 없는 Debian의 포크입니다.
- https://www.devuan.org
현재 지원되는 릴리스는 다음을 참조하세요. https://www.devuan.org/os/releases
11.2.6. Fedora
Fedora는 소프트웨어 개발자와 커뮤니티 구성원이 사용자를 위한 맞춤형 솔루션을 구축할 수 있도록 하는 하드웨어, 클라우드 및 컨테이너를 위한 혁신적인 무료 오픈 소스 플랫폼을 만듭니다.
- https://getfedora.org
현재 지원되는 릴리스는 다음을 참조하세요. https://fedoraproject.org/wiki/Releases
11.2.7. Gentoo
매우 유연한 소스 기반 Linux 배포판입니다. – https://www.gentoo.org
젠투는 롤링 릴리스 모델을 사용하고 있습니다.
11.2.8. OpenSUSE
시스템 관리자, 개발자 및 데스크톱 사용자를 위한 제조업체의 선택입니다. – https://www.opensuse.org
현재 지원되는 릴리스는 다음을 참조하세요. https://get.opensuse.org/leap/
11.2.9. Ubuntu
Ubuntu는 엔터프라이즈 서버, 데스크탑, 클라우드 및 IoT를 위한 Linux의 최신 오픈 소스 운영 체제입니다.
- https://ubuntu.com/
현재 지원되는 릴리스는 다음을 참조하세요. https://wiki.ubuntu.com/Releases
11.3. 컨테이너 이미지
“템플릿” 또는 “어플라이언스”라고도 하는 컨테이너 이미지는 컨테이너를 실행하는 데 필요한 모든 것이 포함된 tar 아카이브입니다.
Proxmox VE 자체는 가장 일반적인 Linux 배포판에 대한 다양한 기본 템플릿을 제공합니다. GUI 또는 pveam(Proxmox VE Appliance Manager의 약어) 명령줄 유틸리티를 사용하여 다운로드할 수 있습니다. 또한 TurnKey Linux 컨테이너 템플릿도 다운로드할 수 있습니다.
사용 가능한 템플릿 목록은 pve-daily-update 타이머를 통해 매일 업데이트됩니다. 다음을 실행하여 업데이트를 수동으로 트리거할 수도 있습니다.
# pveam update
사용 가능한 이미지 목록을 보려면 다음을 실행하세요.
# pveam available
기본 시스템 이미지 등 관심 있는 섹션을 지정하여 이 큰 목록을 제한할 수 있습니다.
사용 가능한 시스템 이미지 목록
# pveam available --section system system alpine-3.12-default_20200823_amd64.tar.xz system alpine-3.13-default_20210419_amd64.tar.xz system alpine-3.14-default_20210623_amd64.tar.xz system archlinux-base_20210420-1_amd64.tar.gz system centos-7-default_20190926_amd64.tar.xz system centos-8-default_20201210_amd64.tar.xz system debian-9.0-standard_9.7-1_amd64.tar.gz system debian-10-standard_10.7-1_amd64.tar.gz system devuan-3.0-standard_3.0_amd64.tar.gz system fedora-33-default_20201115_amd64.tar.xz system fedora-34-default_20210427_amd64.tar.xz system gentoo-current-default_20200310_amd64.tar.xz system opensuse-15.2-default_20200824_amd64.tar.xz system ubuntu-16.04-standard_16.04.5-1_amd64.tar.gz system ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz system ubuntu-20.04-standard_20.04-1_amd64.tar.gz system ubuntu-20.10-standard_20.10-1_amd64.tar.gz system ubuntu-21.04-standard_21.04-1_amd64.tar.gz
이러한 템플릿을 사용하려면 먼저 저장소 중 하나에 다운로드해야 합니다. 어느 것이 확실하지 않은 경우 해당 목적으로 로컬 명명된 저장소를 사용할 수 있습니다. 클러스터 설치의 경우 모든 노드가 해당 이미지에 액세스할 수 있도록 공유 저장소를 사용하는 것이 좋습니다.
# pveam download local debian-10.0-standard_10.0-1_amd64.tar.gz
이제 해당 이미지를 사용하여 컨테이너를 만들 준비가 되었으며 다음을 사용하여 로컬 스토리지에 다운로드한 모든 이미지를 나열할 수 있습니다.
# pveam list local local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz 219.95MB
팁: Proxmox VE 웹 인터페이스 GUI를 사용하여 컨테이너 템플릿을 다운로드, 나열 및 삭제할 수도 있습니다.
pct는 이를 사용하여 새 컨테이너를 만듭니다. 예를 들면 다음과 같습니다.
# pct create 999 local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
위 명령은 전체 Proxmox VE 볼륨 식별자를 보여줍니다. 여기에는 저장소 이름이 포함되며 대부분의 다른 Proxmox VE 명령에서 이를 사용할 수 있습니다. 예를 들어 나중에 다음을 사용하여 해당 이미지를 삭제할 수 있습니다.
# pveam remove local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
11.4.1. 일반 설정
컨테이너의 일반 설정에는 다음이 포함됩니다.
- Node: 컨테이너가 실행될 물리적 서버
- CT ID: 컨테이너를 식별하는 데 사용되는 Proxmox VE 설치의 고유 번호
- Hostname: 컨테이너의 호스트 이름
- Resource Pool: 컨테이너 및 VM의 논리적 그룹
- Password: 컨테이너의 루트 비밀번호
- SSH Public Key: SSH를 통해 루트 계정에 연결하기 위한 공개 키
- Unprivileged container: 이 옵션을 사용하면 권한 있는 컨테이너 또는 권한 없는 컨테이너를 생성하려는 경우 생성 시 선택할 수 있습니다.
권한이 없는 컨테이너
권한이 없는 컨테이너(Unprivileged container)는 사용자 네임스페이스라는 새로운 커널 기능을 사용합니다. 컨테이너 내부의 루트 UID 0은 컨테이너 외부의 권한이 없는 사용자에게 매핑됩니다. 이는 이러한 컨테이너의 대부분의 보안 문제(컨테이너 이스케이프, 리소스 남용 등)가 권한이 없는 임의의 사용자에게 영향을 미치며 LXC 문제가 아닌 일반적인 커널 보안 버그가 될 것임을 의미합니다. LXC 팀은 권한이 없는 컨테이너가 설계상 안전하다고 생각합니다.
이는 새 컨테이너를 생성할 때 기본 옵션입니다.
참고: 컨테이너가 systemd를 초기화 시스템으로 사용하는 경우 컨테이너 내부에서 실행되는 systemd 버전은 220 이상이어야 합니다.
권한 있는 컨테이너
컨테이너의 보안은 필수 액세스 제어 AppArmor 제한, seccomp 필터 및 Linux 커널 네임스페이스를 사용하여 달성됩니다. LXC 팀은 이러한 종류의 컨테이너를 안전하지 않은 것으로 간주하며 새로운 컨테이너 이스케이프 익스플로잇을 CVE 및 빠른 수정에 적합한 보안 문제로 간주하지 않습니다. 그렇기 때문에 권한 있는 컨테이너는 신뢰할 수 있는 환경에서만 사용해야 합니다.
11.4.2. CPU
cores 옵션을 사용하여 컨테이너 내부에 표시되는 CPU 수를 제한할 수 있습니다. 이는 Linux cpuset cgroup(control group)을 사용하여 구현됩니다. pvestatd 내부의 특수 작업은 실행 중인 컨테이너를 사용 가능한 CPU에 정기적으로 배포하려고 시도합니다. 할당된 CPU를 보려면 다음 명령을 실행합니다.
# pct cpusets --------------------- 102: 6 7 105: 2 3 4 5 108: 0 1 ---------------------
컨테이너는 호스트 커널을 직접 사용합니다. 컨테이너 내부의 모든 작업은 호스트 CPU 스케줄러에 의해 처리됩니다. Proxmox VE는 기본적으로 추가 대역폭 제어 옵션이 있는 Linux CFS(Completely Fair Scheduler) 스케줄러를 사용합니다.
cpulimit: 이 옵션을 사용하여 할당된 CPU 시간을 추가로 제한할 수 있습니다. 이는 부동 소수점 숫자이므로 두 개의 코어를 컨테이너에 할당하는 것이 완벽하게 유효하지만 전체 CPU 소비를 코어의 절반으로 제한합니다.
cores: 2 cpulimit: 0.5
cpuunits: 이는 커널 스케줄러에 전달되는 상대적 가중치입니다. 숫자가 클수록 이 컨테이너의 CPU 시간이 길어집니다. 숫자는 실행 중인 다른 모든 컨테이너의 가중치를 기준으로 합니다. 기본값은 100(또는 호스트가 레거시 cgroup v1을 사용하는 경우 1024)입니다. 이 설정을 사용하여 일부 컨테이너의 우선순위를 지정할 수 있습니다.
11.4.3. 메모리
컨테이너 메모리는 cgroup 메모리 컨트롤러를 사용하여 제어됩니다.
memory: 전체 메모리 사용량을 제한합니다. 이는 memory.limit_in_bytes cgroup 설정에 해당합니다.
swap: 컨테이너가 호스트 스왑 공간의 추가 스왑 메모리를 사용할 수 있도록 합니다. 이는 두 값(메모리 + 스왑)의 합계로 설정되는 memory.memsw.limit_in_bytes cgroup 설정에 해당합니다.
11.4.4. 마운트 지점
루트 마운트 지점은 rootfs 속성으로 구성됩니다. 최대 256개의 추가 마운트 지점을 구성할 수 있습니다. 해당 옵션을 mp0~mp255라고 합니다. 여기에는 다음 설정이 포함될 수 있습니다.
rootfs: [volume=]<volume> [,acl=<1|0>] [,mountoptions=<opt[;opt...]>] [,quota=<1|0>] [,replicate=<1|0>] [,ro=<1|0>] [,shared=<1|0>] [,size=<DiskSize>]
볼륨을 컨테이너 루트로 사용합니다. 모든 옵션에 대한 자세한 설명은 아래를 참조하세요.
mp[n]: [volume=]<volume> ,mp=<Path> [,acl=<1|0>] [,backup=<1|0>] [,mountoptions=<opt[;opt...]>] [,quota=<1|0>] [,replicate=<1|0>] [,ro=<1|0>] [,shared=<1|0>] [,size=<DiskSize>]
acl=: Explicitly enable or disable ACL support.
backup=: Whether to include the mount point in backups (only used for volume mount points).
mountoptions=: Extra mount options for rootfs/mps.
mp=: Path to the mount point as seen from inside the container.
quota=: Enable user quotas inside the container (not supported with zfs subvolumes)
replicate= (default = 1): Will include this volume to a storage replica job.
ro=: Read-only mount point
shared= (default = 0): Mark this non-volume mount point as available on all nodes.
size=: Volume size (read only value).
volume=: Volume, device or directory to mount into the container.
현재 마운트 지점에는 스토리지 지원 마운트 지점, 바인드 마운트, 장치 마운트 등 세 가지 유형이 있습니다.
일반적인 컨테이너 rootfs 구성
rootfs: thin1:base-100-disk-1,size=8G
스토리지 지원 마운트 지점
스토리지 지원 마운트 지점은 Proxmox VE 스토리지 하위 시스템에 의해 관리되며 세 가지 다른 형태로 제공됩니다.
- 이미지 기반: 단일 ext4 형식의 파일 시스템을 포함하는 원시 이미지입니다.
- ZFS 하위 볼륨: 이는 기술적으로 바인드 마운트이지만 관리형 스토리지를 사용하므로 크기 조정 및 스냅샷 생성이 가능합니다.
- 디렉터리: size=0을 전달하면 원시 이미지 대신 디렉터리가 생성되는 특별한 경우가 발생합니다.
참고: 스토리지 지원 마운트 지점 볼륨에 대한 특수 옵션 구문 STORAGE_ID:SIZE_IN_GB는 지정된 스토리지에 지정된 크기의 볼륨을 자동으로 할당합니다. 예를 들어, 호출
pct set 100 -mp0 thin1:10,mp=/path/in/container
스토리지 thin1에 10GB 볼륨을 할당하고 볼륨 ID 자리 표시자 10을 할당된 볼륨 ID로 바꾸고 /path/in/container에서 컨테이너의 moutpoint를 설정합니다.
마운트 지점 바인딩
바인드 마운트를 사용하면 컨테이너 내부의 Proxmox VE 호스트에서 임의 디렉터리에 액세스할 수 있습니다. 몇 가지 잠재적인 사용 사례는 다음과 같습니다.
- 게스트에서 홈 디렉터리에 액세스
- 게스트의 USB 장치 디렉터리에 액세스
- 게스트의 호스트에서 NFS 마운트에 액세스
바인드 마운트는 스토리지 하위 시스템에서 관리되지 않는 것으로 간주되므로 컨테이너 내부에서 스냅샷을 만들거나 할당량을 처리할 수 없습니다. 권한이 없는 컨테이너를 사용하면 사용자 매핑으로 인해 권한 문제가 발생할 수 있으며 ACL을 사용할 수 없습니다.
참고: vzdump를 사용할 때 바인드 마운트 지점의 내용은 백업되지 않습니다.
경고: 보안상의 이유로 바인드 마운트는 특별히 이 목적을 위해 예약된 소스 디렉토리(예: /mnt/bindmounts 아래의 디렉토리 계층)를 사용하여 설정해야 합니다. /, /var 또는 /etc와 같은 마운트 시스템 디렉터리를 컨테이너에 바인딩하지 마십시오. 이는 큰 보안 위험을 초래합니다.
참고: 바인드 마운트 소스 경로에는 심볼릭 링크가 포함되어서는 안 됩니다.
예를 들어 /shared 경로 아래의 ID 100을 가진 컨테이너에서 /mnt/bindmounts/shared 디렉터리에 액세스할 수 있도록 하려면 다음과 같은 구성 줄을 추가합니다.
mp0: /mnt/bindmounts/shared,mp=/shared
/etc/pve/lxc/100.conf에.
또는 pct 도구를 사용하십시오.
pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared
동일한 결과를 얻으려면.
장치 마운트 지점
장치 마운트 포인트를 사용하면 호스트의 블록 장치를 컨테이너에 직접 마운트할 수 있습니다. 바인드 마운트와 마찬가지로 장치 마운트는 Proxmox VE의 스토리지 하위 시스템에서 관리되지 않지만 할당량 및 acl 옵션이 적용됩니다.
참고: 장치 마운트 지점은 특별한 상황에서만 사용해야 합니다. 대부분의 경우 스토리지 지원 마운트 지점은 동일한 성능과 훨씬 더 많은 기능을 제공합니다.
참고: vzdump를 사용할 때 장치 마운트 지점의 내용은 백업되지 않습니다.
11.4.5. 네트워크
단일 컨테이너에 대해 최대 10개의 네트워크 인터페이스를 구성할 수 있습니다. 해당 옵션은 net0~net9라고 하며 다음 설정을 포함할 수 있습니다.
net[n]: name=<string> [,bridge=<bridge>] [,firewall=<1|0>] [,gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,hwaddr=<XX:XX:XX:XX:XX:XX>] [,ip=<(IPv4/CIDR|dhcp|manual)>] [,ip6=<(IPv6/CIDR|auto|dhcp|manual)>] [,link_down=<1|0>] [,mtu=<integer>] [,rate=<mbps>] [,tag=<integer>] [,trunks=<vlanid[;vlanid...]>] [,type=<veth>]
컨테이너의 네트워크 인터페이스를 지정합니다.
bridge=: Bridge to attach the network device to.
firewall=: Controls whether this interface’s firewall rules should be used.
gw=: Default gateway for IPv4 traffic.
gw6=: Default gateway for IPv6 traffic.
hwaddr=: A common MAC address with the I/G (Individual/Group) bit not set.
ip=<(IPv4/CIDR|dhcp|manual)>: IPv4 address in CIDR format.
ip6=<(IPv6/CIDR|auto|dhcp|manual)>: IPv6 address in CIDR format.
link_down=: Whether this interface should be disconnected (like pulling the plug).
mtu= (64 – 65535): Maximum transfer unit of the interface. (lxc.network.mtu)
name=: Name of the network device as seen from inside the container. (lxc.network.name)
rate=: Apply rate limiting to the interface
tag= (1 – 4094): VLAN tag for this interface.
trunks=: VLAN ids to pass through the interface
type=: Network interface type.
11.4.6. 컨테이너의 자동 시작 및 종료
호스트 시스템이 부팅될 때 컨테이너를 자동으로 시작하려면 웹 인터페이스에 있는 컨테이너의 옵션 패널에서 부팅 시 시작 옵션을 선택하거나 다음 명령을 실행합니다.
# pct set CTID -onboot 1
시작 및 종료 순서
컨테이너의 부팅 순서를 미세 조정하려면 다음 매개변수를 사용할 수 있습니다.
- Start/Shutdown order: 시작 순서 우선순위를 정의합니다. 예를 들어 CT를 가장 먼저 시작하려면 이 값을 1로 설정합니다. (종료에는 역방향 시작 순서를 사용하므로 시작 순서가 1인 컨테이너가 마지막으로 종료됩니다.)
- Startup delay: 이 컨테이너 시작과 후속 컨테이너 시작 사이의 간격을 정의합니다. 예를 들어 다른 컨테이너를 시작하기 전에 240초를 기다리려면 240으로 설정합니다.
- Shutdown timeout: Proxmox VE가 종료 명령을 실행한 후 컨테이너가 오프라인이 될 때까지 기다려야 하는 기간(초)을 정의합니다. 기본적으로 이 값은 60으로 설정됩니다. 이는 Proxmox VE가 종료 요청을 발행하고 시스템이 오프라인이 될 때까지 60초를 기다린 후 60초 후에도 시스템이 여전히 온라인 상태이면 종료 조치가 실패했음을 알리는 것을 의미합니다.
Start/Shutdown order 매개변수가 없는 컨테이너는 항상 매개변수가 설정된 컨테이너 다음에 시작되며, 이 매개변수는 클러스터 전체가 아닌 호스트에서 로컬로 실행되는 머신 간에만 의미가 있습니다.
호스트 부팅과 첫 번째 컨테이너 부팅 사이에 지연이 필요한 경우 Proxmox VE 노드 관리 섹션을 참조하세요.
11.4.7. 훅스크립트
구성 속성 Hookscript를 사용하여 CT에 후크 스크립트를 추가할 수 있습니다.
# pct set 100 -hookscript local:snippets/hookscript.pl
게스트 수명의 다양한 단계에서 호출됩니다. 예제와 문서를 보려면 /usr/share/pve-docs/examples/guest-example-hookscript.pl 아래의 예제 스크립트를 참조하세요.
11.5. 보안 고려 사항
컨테이너는 호스트 시스템의 커널을 사용합니다. 이는 악의적인 사용자에게 공격 표면을 노출시킵니다. 일반적으로 전체 가상 머신은 더 나은 격리를 제공합니다. 알 수 없거나 신뢰할 수 없는 사람에게 컨테이너가 제공되는 경우 이를 고려해야 합니다.
공격 표면을 줄이기 위해 LXC는 AppArmor, CGroups 및 커널 네임스페이스와 같은 많은 보안 기능을 사용합니다.
11.5.1. AppArmor
AppArmor 프로필은 위험한 작업에 대한 액세스를 제한하는 데 사용됩니다. 일부 시스템 호출(예: mount)은 실행이 금지됩니다.
AppArmor 활동을 추적하려면 다음을 사용하세요.
# dmesg | grep apparmor
권장되지는 않지만 컨테이너에 대해 AppArmor를 비활성화할 수 있습니다. 이로 인해 보안 위험이 발생합니다. 시스템이 잘못 구성되었거나 LXC 또는 Linux 커널 취약성이 존재하는 경우 일부 syscall은 컨테이너 내에서 실행될 때 권한 상승으로 이어질 수 있습니다.
컨테이너에 대해 AppArmor를 비활성화하려면 /etc/pve/lxc/CTID.conf에 있는 컨테이너 구성 파일에 다음 줄을 추가합니다.
lxc.apparmor.profile = unconfined
경고: 이는 프로덕션 용도로 권장되지 않습니다.
11.5.2. Control Groups(cgroup)
cgroup은 프로세스를 계층적으로 구성하고 시스템 리소스를 배포하는 데 사용되는 커널 메커니즘입니다.
cgroup을 통해 제어되는 주요 리소스는 CPU 시간, 메모리 및 스왑 제한, 장치 노드에 대한 액세스입니다. cgroup은 스냅샷을 찍기 전에 컨테이너를 “고정”하는 데에도 사용됩니다.
현재 사용 가능한 cgroup에는 레거시와 cgroupv2의 두 가지 버전이 있습니다.
Proxmox VE 7.0부터 기본값은 순수 cgroupv2 환경입니다. 이전에는 cgroup_no_v1 커널 명령줄 매개변수를 통해 일부 하위 시스템을 인계받을 수 있는 추가 cgroupv2 컨트롤러를 사용하여 리소스 제어가 주로 cgroupv1에서 수행되는 “하이브리드” 설정이 사용되었습니다. (자세한 내용은 커널 매개변수 설명서를 참조하세요.)
CGroup 버전 호환성
Proxmox VE와 관련하여 순수 cgroupv2와 이전 하이브리드 환경의 주요 차이점은 cgroupv2를 사용하면 메모리와 스왑이 이제 독립적으로 제어된다는 것입니다. 컨테이너의 메모리 및 스왑 설정은 이러한 값에 직접 매핑될 수 있지만 이전에는 메모리 제한과 메모리 및 스왑 합계 제한만 제한될 수 있었습니다.
또 다른 중요한 차이점은 장치 컨트롤러가 완전히 다른 방식으로 구성된다는 것입니다. 이로 인해 현재 순수 cgroupv2 환경에서는 파일 시스템 할당량이 지원되지 않습니다.
순수 cgroupv2 환경에서 실행하려면 컨테이너 OS의 cgroupv2 지원이 필요합니다. systemd 버전 231 이상을 실행하는 컨테이너는 cgroupv2[49]를 지원하며, systemd를 init 시스템[50]으로 사용하지 않는 컨테이너도 마찬가지입니다.
메모: CentOS 7 및 Ubuntu 16.10은 두 가지 주요 Linux 배포판 릴리스로, cgroupv2 환경에서 실행하기에는 너무 오래된 시스템 버전이 있습니다. 다음 중 하나를 수행할 수 있습니다.
- 전체 배포판을 최신 릴리스로 업그레이드하십시오. 위의 예에서는 Ubuntu 18.04 또는 20.04 및 CentOS 8(또는 AlmaLinux 또는 Rocky Linux와 같은 RHEL/CentOS 파생 제품)이 될 수 있습니다. 이는 최신 버그 및 보안 수정 사항, 종종 새로운 기능을 얻고 EOL 날짜를 미래로 옮기는 이점이 있습니다.
- 컨테이너 시스템 버전을 업그레이드합니다. 배포판이 백포트 저장소를 제공하는 경우 이는 쉽고 빠른 임시방편 측정이 될 수 있습니다.
- 컨테이너 또는 해당 서비스를 가상 머신으로 이동합니다. 가상 머신은 호스트와의 상호 작용이 훨씬 적기 때문에 수십 년 된 OS 버전을 거기에 잘 설치할 수 있습니다.
- 레거시 cgroup 컨트롤러로 다시 전환합니다. 유효한 솔루션일 수는 있지만 영구적인 솔루션은 아닙니다. Proxmox VE 9.0부터 레거시 컨트롤러는 더 이상 지원되지 않습니다.
CGroup 버전 변경
팁: 파일 시스템 할당량이 필요하지 않고 모든 컨테이너가 cgroupv2를 지원하는 경우 새 기본값을 유지하는 것이 좋습니다.
이전 버전으로 다시 전환하려면 다음 커널 명령줄 매개변수를 사용할 수 있습니다.
systemd.unified_cgroup_hierarchy=0
매개변수를 추가할 위치에 대한 커널 부팅 명령줄 편집에 대한 이 섹션을 참조하세요.
11.6. 게스트 OS 구성
Proxmox VE는 컨테이너에서 Linux 배포판을 감지하고 일부 파일을 수정하려고 시도합니다. 다음은 컨테이너 시작 시 수행되는 작업의 간단한 목록입니다.
set /etc/hostname 컨테이너 이름을 설정
modify /etc/hosts 로컬 호스트 이름 조회를 허용하려면
network setup 전체 네트워크 설정을 컨테이너에 전달
configure DNS DNS 서버에 대한 정보 전달
adapt the init system 예를 들어 생성된 getty 프로세스 수를 수정합니다.
set the root password 새로운 컨테이너를 생성할 때
rewrite ssh_host_keys 각 컨테이너에 고유한 키가 있도록
randomize crontab cron이 모든 컨테이너에서 동시에 시작되지 않도록
Proxmox VE의 변경 사항은 주석 표시로 묶여 있습니다.
# --- BEGIN PVE --- <data> # --- END PVE ---
해당 마커는 파일의 적절한 위치에 삽입됩니다. 해당 섹션이 이미 존재하는 경우 해당 섹션이 업데이트되고 이동되지 않습니다.
.pve-ignore를 추가하면 파일 수정을 방지할 수 있습니다. 그것을 위한 파일. 예를 들어, /etc/.pve-ignore.hosts 파일이 존재하면 /etc/hosts 파일은 건드리지 않습니다. 이는 다음을 통해 생성된 간단한 빈 파일일 수 있습니다.
# touch /etc/.pve-ignore.hosts
대부분의 수정 사항은 OS에 따라 다르므로 배포판과 버전에 따라 다릅니다. ostype을 관리되지 않음으로 수동으로 설정하여 수정 사항을 완전히 비활성화할 수 있습니다.
OS 유형 감지는 컨테이너 내부의 특정 파일을 테스트하여 수행됩니다. Proxmox VE는 먼저 /etc/os-release 파일을 확인합니다[51]. 해당 파일이 없거나 명확하게 인식할 수 있는 배포 식별자가 포함되어 있지 않으면 다음 배포 관련 릴리스 파일을 확인합니다.
Ubuntu: /etc/lsb-release 검사(DISTRIB_ID=Ubuntu)
Debian: /etc/debian_version 테스트
Fedora: /etc/fedora-release 테스트
RedHat 또는 CentOS: /etc/redhat-release 테스트
ArchLinux: /etc/arch-release 테스트
Alpine: /etc/alpine-release 테스트
Gentoo: /etc/gentoo-release 테스트
참고: 구성된 ostype이 자동 감지된 유형과 다르면 컨테이너 시작이 실패합니다.
11.7. 컨테이너 스토리지
Proxmox VE LXC 컨테이너 스토리지 모델은 기존 컨테이너 스토리지 모델보다 더 유연합니다. 컨테이너에는 여러 마운트 지점이 있을 수 있습니다. 이를 통해 각 애플리케이션에 가장 적합한 스토리지를 사용할 수 있습니다.
예를 들어 컨테이너의 루트 파일 시스템은 느리고 저렴한 스토리지에 있는 반면 데이터베이스는 두 번째 마운트 지점을 통해 빠르고 분산된 스토리지에 있을 수 있습니다. 자세한 내용은 마운트 지점 섹션을 참조하세요.
Proxmox VE 스토리지 라이브러리가 지원하는 모든 스토리지 유형을 사용할 수 있습니다. 이는 컨테이너를 로컬(예: lvm, zfs 또는 디렉터리), 공유 외부(예: iSCSI, NFS) 또는 심지어 Ceph와 같은 분산 스토리지 시스템에 저장할 수 있음을 의미합니다. 기본 스토리지가 지원하는 경우 스냅샷이나 클론과 같은 고급 스토리지 기능을 사용할 수 있습니다. vzdump 백업 도구는 스냅샷을 사용하여 일관된 컨테이너 백업을 제공할 수 있습니다.
또한 로컬 장치나 로컬 디렉터리는 바인드 마운트를 사용하여 직접 마운트할 수 있습니다. 이를 통해 실질적으로 오버헤드가 0인 컨테이너 내부의 로컬 리소스에 액세스할 수 있습니다. 바인드 마운트는 컨테이너 간에 데이터를 공유하는 쉬운 방법으로 사용될 수 있습니다.
11.7.1. 퓨즈 마운트
경고: Linux 커널 고정기 하위 시스템의 기존 문제로 인해 컨테이너 내부에서 FUSE 마운트를 사용하지 않는 것이 좋습니다. 일시 중지 또는 스냅샷 모드 백업을 위해 컨테이너를 고정해야 하기 때문입니다.
FUSE 마운트를 다른 마운트 메커니즘이나 스토리지 기술로 교체할 수 없는 경우 Proxmox 호스트에 FUSE 마운트를 설정하고 바인드 마운트 지점을 사용하여 컨테이너 내부에서 액세스할 수 있도록 할 수 있습니다.
11.7.2. 컨테이너 내부에서 할당량 사용
할당량을 사용하면 각 사용자가 사용할 수 있는 디스크 공간의 양에 대해 컨테이너 내부에 제한을 설정할 수 있습니다.
참고: 현재 이를 위해서는 레거시 cgroup을 사용해야 합니다.
참고: 이는 ext4 이미지 기반 스토리지 유형에서만 작동하며 현재 권한 있는 컨테이너에서만 작동합니다.
할당량 옵션을 활성화하면 마운트 지점에 다음 마운트 옵션이 사용됩니다: usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
이를 통해 할당량을 다른 시스템과 마찬가지로 사용할 수 있습니다. 다음을 실행하여 /aquota.user 및 /aquota.group 파일을 초기화할 수 있습니다.
# quotacheck -cmug / # quotaon /
그런 다음 edquota 명령을 사용하여 할당량을 편집합니다. 자세한 내용은 컨테이너 내부에서 실행되는 배포 문서를 참조하세요.
참고: / 대신 마운트 지점의 경로를 전달하여 모든 마운트 지점에 대해 위 명령을 실행해야 합니다.
11.7.3. 컨테이너 내부에서 ACL 사용
표준 Posix 액세스 제어 목록은 컨테이너 내부에서도 사용할 수 있습니다. ACL을 사용하면 기존 사용자/그룹/기타 모델보다 더 자세한 파일 소유권을 설정할 수 있습니다.
11.7.4. 컨테이너 마운트 지점 백업
백업에 마운트 지점을 포함하려면 컨테이너 구성에서 해당 마운트 지점에 대한 백업 옵션을 활성화하세요. 기존 마운트 지점 mp0의 경우
mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G
활성화하려면 backup=1을 추가하세요.
mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G,backup=1
참고: GUI에서 새 마운트 지점을 생성할 때 이 옵션은 기본적으로 활성화됩니다.
마운트 지점에 대한 백업을 비활성화하려면 위에 설명된 방식으로 backup=0을 추가하거나 GUI에서 백업 확인란을 선택 취소합니다.
11.7.5. 컨테이너 마운트 지점 복제
기본적으로 루트 디스크가 복제되면 추가 마운트 지점이 복제됩니다. Proxmox VE 스토리지 복제 메커니즘이 마운트 지점을 건너뛰도록 하려면 해당 마운트 지점에 대해 복제 건너뛰기 옵션을 설정할 수 있습니다. Proxmox VE 5.0부터 복제에는 zfspool 유형의 스토리지가 필요합니다. 컨테이너에 복제가 구성되어 있을 때 다른 유형의 스토리지에 탑재 지점을 추가하려면 해당 탑재 지점에 대해 복제 건너뛰기를 활성화해야 합니다.
11.8. 백업 및 복원
11.8.1. 컨테이너 백업
컨테이너 백업에 vzdump 도구를 사용할 수 있습니다. 자세한 내용은 vzdump 매뉴얼 페이지를 참조하세요.
11.8.2. 컨테이너 백업 복원
vzdump로 만든 컨테이너 백업을 복원하는 것은 pct 복원 명령을 사용하여 가능합니다. 기본적으로 pct 복원은 백업된 컨테이너 구성을 최대한 많이 복원하려고 시도합니다. 명령줄에서 컨테이너 옵션을 수동으로 설정하여 백업된 구성을 재정의할 수 있습니다(자세한 내용은 pct 매뉴얼 페이지 참조).
참고: pvesm extractconfig를 사용하면 vzdump 아카이브에 포함된 백업된 구성을 볼 수 있습니다.
두 가지 기본 복원 모드가 있으며, 마운트 지점 처리 방식만 다릅니다.
“Simple” 복원 모드
rootfs 매개변수나 선택적 mpX 매개변수 중 어느 것도 명시적으로 설정되지 않은 경우 백업된 구성 파일의 마운트 지점 구성은 다음 단계를 사용하여 복원됩니다.
- 백업에서 마운트 지점 및 해당 옵션 추출
- Storage 매개변수(기본값: 로컬)와 함께 제공된 스토리지에 스토리지 지원 마운트 지점에 대한 볼륨을 생성합니다.
- 백업 아카이브에서 파일 추출
- 복원된 구성에 바인드 및 장치 마운트 지점 추가(루트 사용자로 제한)
참고: 바인드 및 장치 마운트 지점은 백업되지 않으므로 마지막 단계에서는 파일이 복원되지 않고 구성 옵션만 복원됩니다. 이러한 마운트 지점은 다른 메커니즘(예: 많은 컨테이너에 바인드 마운트되는 NFS 공간)으로 백업되거나 전혀 백업되지 않을 것이라고 가정합니다.
이 단순 모드는 웹 인터페이스의 컨테이너 복원 작업에서도 사용됩니다.
“Advanced” 복원 모드
rootfs 매개변수(및 선택적으로 mpX 매개변수의 조합)를 설정하면 pct 복원 명령이 자동으로 고급 모드로 전환됩니다. 이 고급 모드는 백업 아카이브에 포함된 rootfs 및 mpX 구성 옵션을 완전히 무시하고 대신 매개변수로 명시적으로 제공된 옵션만 사용합니다.
이 모드를 사용하면 복원 시 마운트 지점 설정을 유연하게 구성할 수 있습니다. 예를 들면 다음과 같습니다.
- 각 마운트 지점에 대한 대상 스토리지, 볼륨 크기 및 기타 옵션을 개별적으로 설정
- 새로운 마운트 지점 구성표에 따라 백업된 파일을 재배포합니다.
- 장치로 복원 및/또는 마운트 지점 바인드(루트 사용자로 제한됨)
11.9. pct로 컨테이너 관리
“Proxmox Container Toolkit”(pct)은 Proxmox VE 컨테이너를 관리하는 명령줄 도구입니다. 컨테이너를 생성하거나 삭제할 수 있을 뿐만 아니라 컨테이너 실행(시작, 중지, 재부팅, 마이그레이션 등)을 제어할 수도 있습니다. 컨테이너의 구성 파일에서 네트워크 구성이나 메모리 제한과 같은 매개변수를 설정하는 데 사용할 수 있습니다.
11.9.1. CLI 사용 예
Debian 템플릿을 기반으로 컨테이너 생성(웹 인터페이스를 통해 이미 템플릿을 다운로드한 경우)
# pct create 100 /var/lib/vz/template/cache/debian-10.0-standard_10.0-1_amd64.tar.gz
컨테이너 100 시작
# pct start 100
getty를 통해 로그인 세션 시작
# pct console 100
LXC 네임스페이스를 입력하고 루트 사용자로 셸을 실행합니다.
# pct enter 100
구성 표시
# pct config 100
호스트 브리지 vmbr0에 브리지된 eth0이라는 네트워크 인터페이스를 추가하고 실행 중인 동안 주소와 게이트웨이를 설정합니다.
# pct set 100 -net0 name=eth0,bridge=vmbr0,ip=192.168.15.147/24,gw=192.168.15.1
컨테이너의 메모리를 512MB로 줄입니다.
# pct set 100 -memory 512
컨테이너를 삭제하면 항상 액세스 제어 목록에서 해당 컨테이너가 제거되고 컨테이너의 방화벽 구성도 항상 제거됩니다. 복제 작업, 백업 작업 및 HA 리소스 구성에서 컨테이너를 추가로 제거하려면 –purge를 활성화해야 합니다.
# pct destroy 100 --purge
마운트 지점 볼륨을 다른 스토리지로 이동합니다.
# pct move-volume 100 mp0 other-storage
볼륨을 다른 CT에 재할당합니다. 그러면 소스 CT에서 볼륨 mp0이 제거되고 이를 대상 CT에 mp1로 연결됩니다. 백그라운드에서 이름이 새 소유자와 일치하도록 볼륨 이름이 변경됩니다.
# pct move-volume 100 mp0 --target-vmid 200 --target-volume mp1
11.9.2. 디버깅 로그 얻기
pct start가 특정 컨테이너를 시작할 수 없는 경우 –debug 플래그를 전달하여 디버깅 출력을 수집하는 것이 도움이 될 수 있습니다(CTID를 컨테이너의 CTID로 교체).
# pct start CTID --debug
또는 다음 lxc-start 명령을 사용하여 -o 출력 옵션에 지정된 파일에 디버그 로그를 저장할 수 있습니다.
# lxc-start -n CTID -F -l DEBUG -o /tmp/lxc-CTID.log
이 명령은 두 번째 터미널에서 컨테이너 실행 pct shutdown CTID 또는 pct stop CTID를 중지하기 위해 포그라운드 모드에서 컨테이너를 시작하려고 시도합니다.
수집된 디버그 로그는 /tmp/lxc-CTID.log에 기록됩니다.
참고: pct start를 사용한 마지막 시작 시도 이후 컨테이너의 구성을 변경한 경우 pct start를 한 번 이상 실행하여 lxc-start에서 사용하는 구성도 업데이트해야 합니다.
11.10. 마이그레이션
클러스터가 있는 경우 다음을 사용하여 컨테이너를 마이그레이션할 수 있습니다.
# pct migrate <ctid> <target>
컨테이너가 오프라인인 동안에 작동합니다. 로컬 볼륨이나 마운트 지점이 정의되어 있는 경우 동일한 스토리지가 정의되어 있으면 마이그레이션은 네트워크를 통해 대상 호스트로 콘텐츠를 복사합니다.
실행 중인 컨테이너는 기술적 제한으로 인해 실시간 마이그레이션할 수 없습니다. 대상 노드에서 컨테이너를 종료하고 이동한 다음 다시 시작하는 마이그레이션 재시작을 수행할 수 있습니다. 컨테이너는 매우 가볍기 때문에 일반적으로 가동 중지 시간은 수백 밀리초 정도에 불과합니다.
재시작 마이그레이션은 웹 인터페이스를 통해 수행하거나 pct migration 명령과 함께 –restart 플래그를 사용하여 수행할 수 있습니다.
마이그레이션을 다시 시작하면 컨테이너가 종료되고 지정된 시간 초과(기본값은 180초) 후에 컨테이너가 종료됩니다. 그런 다음 오프라인 마이그레이션처럼 컨테이너를 마이그레이션하고 완료되면 대상 노드에서 컨테이너를 시작합니다.
11.11. 구성
/etc/pve/lxc/.conf 파일은 컨테이너 구성을 저장합니다. 여기서 는 지정된 컨테이너의 숫자 ID입니다. /etc/pve/에 저장된 다른 모든 파일과 마찬가지로 이 파일도 다른 모든 클러스터 노드에 자동으로 복제됩니다.
참고 100 미만의 CTID는 내부용으로 예약되어 있으며 CTID는 클러스터 전체에서 고유해야 합니다.
컨테이너 구성 예시
ostype: debian arch: amd64 hostname: www memory: 512 swap: 512 net0: bridge=vmbr0,hwaddr=66:64:66:64:64:36,ip=dhcp,name=eth0,type=veth rootfs: local:107/vm-107-disk-1.raw,size=7G
구성 파일은 간단한 텍스트 파일입니다. vi 또는 nano와 같은 일반 텍스트 편집기를 사용하여 편집할 수 있습니다. 이는 때때로 작은 수정을 수행하는 데 유용하지만 이러한 변경 사항을 적용하려면 컨테이너를 다시 시작해야 한다는 점을 명심하세요.
이러한 이유로 일반적으로 pct 명령을 사용하여 해당 파일을 생성 및 수정하거나 GUI를 사용하여 모든 작업을 수행하는 것이 더 좋습니다. 우리의 툴킷은 실행 중인 컨테이너에 대부분의 변경 사항을 즉시 적용할 수 있을 만큼 똑똑합니다. 이 기능을 “핫 플러그”라고 하며 이 경우 컨테이너를 다시 시작할 필요가 없습니다.
변경 사항을 핫 플러그할 수 없는 경우 보류 중인 변경 사항으로 등록됩니다(GUI에서 빨간색으로 표시됨). 컨테이너를 재부팅한 후에만 적용됩니다.
11.11.1. 파일 형식
컨테이너 구성 파일은 콜론으로 구분된 간단한 키/값 형식을 사용합니다. 각 줄의 형식은 다음과 같습니다.
# this is a comment OPTION: value
해당 파일의 빈 줄은 무시되고 # 문자로 시작하는 줄은 주석으로 처리되어 무시됩니다.
예를 들어, 낮은 수준의 LXC 스타일 구성을 직접 추가할 수 있습니다.
lxc.init_cmd: /sbin/my_own_init
또는
lxc.init_cmd = /sbin/my_own_init
설정은 LXC 하위 수준 도구에 직접 전달됩니다.
11.11.2. 스냅샷
스냅샷을 생성할 때 pct는 스냅샷 시점의 구성을 동일한 구성 파일 내의 별도 스냅샷 섹션에 저장합니다. 예를 들어 “testsnapshot”이라는 스냅샷을 생성한 후 구성 파일은 다음과 같습니다.
스냅샷을 사용한 컨테이너 구성
memory: 512 swap: 512 parent: testsnaphot ... [testsnaphot] memory: 512 swap: 512 snaptime: 1457170803
상위 및 스냅타임과 같은 몇 가지 스냅샷 관련 속성이 있습니다. parent 속성은 스냅샷 간의 상위/하위 관계를 저장하는 데 사용됩니다. snaptime은 스냅샷 생성 타임스탬프(Unix epoch)입니다.
11.11.3. 옵션
이 부분은 번역하지 않았습니다.
영문 매뉴얼을 참조하시기 바랍니다.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pct_configuration
11.12. 잠금
컨테이너 마이그레이션, 스냅샷 및 백업(vzdump)은 영향을 받는 컨테이너에서 호환되지 않는 동시 작업을 방지하기 위해 잠금을 설정합니다. 때로는 이러한 잠금을 수동으로 제거해야 하는 경우도 있습니다(예: 정전 후).
# pct unlock <CTID>
주의: 잠금을 설정한 작업이 더 이상 실행되지 않는다고 확신하는 경우에만 이 작업을 수행하십시오.
