From 2b371b262f7272266ff18cc2aff65176a2c16383 Mon Sep 17 00:00:00 2001 From: Sungbae Yoo Date: Thu, 11 Jun 2015 09:16:54 +0900 Subject: [PATCH] doc: Add Korean man pages Signed-off-by: Sungbae Yoo --- configure.ac | 37 + doc/Makefile.am | 4 +- doc/ko/FAQ.txt | 67 + doc/ko/Makefile.am | 66 + doc/ko/common_options.sgml.in | 161 ++ doc/ko/legacy/lxc-ls.sgml.in | 176 ++ doc/ko/lxc-attach.sgml.in | 443 +++++ doc/ko/lxc-autostart.sgml.in | 350 ++++ doc/ko/lxc-cgroup.sgml.in | 206 +++ doc/ko/lxc-checkconfig.sgml.in | 112 ++ doc/ko/lxc-checkpoint.sgml.in | 230 +++ doc/ko/lxc-clone.sgml.in | 348 ++++ doc/ko/lxc-config.sgml.in | 129 ++ doc/ko/lxc-console.sgml.in | 208 +++ doc/ko/lxc-create.sgml.in | 284 ++++ doc/ko/lxc-destroy.sgml.in | 162 ++ doc/ko/lxc-device.sgml.in | 205 +++ doc/ko/lxc-execute.sgml.in | 238 +++ doc/ko/lxc-freeze.sgml.in | 130 ++ doc/ko/lxc-info.sgml.in | 260 +++ doc/ko/lxc-ls.sgml.in | 289 ++++ doc/ko/lxc-monitor.sgml.in | 238 +++ doc/ko/lxc-snapshot.sgml.in | 208 +++ doc/ko/lxc-start-ephemeral.sgml.in | 307 ++++ doc/ko/lxc-start.sgml.in | 360 +++++ doc/ko/lxc-stop.sgml.in | 292 ++++ doc/ko/lxc-top.sgml.in | 205 +++ doc/ko/lxc-unfreeze.sgml.in | 125 ++ doc/ko/lxc-unshare.sgml.in | 285 ++++ doc/ko/lxc-user-nic.sgml.in | 210 +++ doc/ko/lxc-usernet.sgml.in | 188 +++ doc/ko/lxc-usernsexec.sgml.in | 193 +++ doc/ko/lxc-wait.sgml.in | 192 +++ doc/ko/lxc.conf.sgml.in | 193 +++ doc/ko/lxc.container.conf.sgml.in | 2399 ++++++++++++++++++++++++++++ doc/ko/lxc.sgml.in | 875 ++++++++++ doc/ko/lxc.system.conf.sgml.in | 244 +++ doc/ko/see_also.sgml.in | 116 ++ lxc.spec.in | 3 + 39 files changed, 10736 insertions(+), 2 deletions(-) create mode 100644 doc/ko/FAQ.txt create mode 100644 doc/ko/Makefile.am create mode 100644 doc/ko/common_options.sgml.in create mode 100644 doc/ko/legacy/lxc-ls.sgml.in create mode 100644 doc/ko/lxc-attach.sgml.in create mode 100644 doc/ko/lxc-autostart.sgml.in create mode 100644 doc/ko/lxc-cgroup.sgml.in create mode 100644 doc/ko/lxc-checkconfig.sgml.in create mode 100644 doc/ko/lxc-checkpoint.sgml.in create mode 100644 doc/ko/lxc-clone.sgml.in create mode 100644 doc/ko/lxc-config.sgml.in create mode 100644 doc/ko/lxc-console.sgml.in create mode 100644 doc/ko/lxc-create.sgml.in create mode 100644 doc/ko/lxc-destroy.sgml.in create mode 100644 doc/ko/lxc-device.sgml.in create mode 100644 doc/ko/lxc-execute.sgml.in create mode 100644 doc/ko/lxc-freeze.sgml.in create mode 100644 doc/ko/lxc-info.sgml.in create mode 100644 doc/ko/lxc-ls.sgml.in create mode 100644 doc/ko/lxc-monitor.sgml.in create mode 100644 doc/ko/lxc-snapshot.sgml.in create mode 100644 doc/ko/lxc-start-ephemeral.sgml.in create mode 100644 doc/ko/lxc-start.sgml.in create mode 100644 doc/ko/lxc-stop.sgml.in create mode 100644 doc/ko/lxc-top.sgml.in create mode 100644 doc/ko/lxc-unfreeze.sgml.in create mode 100644 doc/ko/lxc-unshare.sgml.in create mode 100644 doc/ko/lxc-user-nic.sgml.in create mode 100644 doc/ko/lxc-usernet.sgml.in create mode 100644 doc/ko/lxc-usernsexec.sgml.in create mode 100644 doc/ko/lxc-wait.sgml.in create mode 100644 doc/ko/lxc.conf.sgml.in create mode 100644 doc/ko/lxc.container.conf.sgml.in create mode 100644 doc/ko/lxc.sgml.in create mode 100644 doc/ko/lxc.system.conf.sgml.in create mode 100644 doc/ko/see_also.sgml.in diff --git a/configure.ac b/configure.ac index 5fa9b4eed..51b99e389 100644 --- a/configure.ac +++ b/configure.ac @@ -750,6 +750,43 @@ AC_CONFIG_FILES([ doc/ja/common_options.sgml doc/ja/see_also.sgml + doc/ko/Makefile + doc/ko/legacy/lxc-ls.sgml + doc/ko/lxc-attach.sgml + doc/ko/lxc-autostart.sgml + doc/ko/lxc-cgroup.sgml + doc/ko/lxc-checkconfig.sgml + doc/ko/lxc-checkpoint.sgml + doc/ko/lxc-clone.sgml + doc/ko/lxc-config.sgml + doc/ko/lxc-console.sgml + doc/ko/lxc-create.sgml + doc/ko/lxc-destroy.sgml + doc/ko/lxc-device.sgml + doc/ko/lxc-execute.sgml + doc/ko/lxc-freeze.sgml + doc/ko/lxc-info.sgml + doc/ko/lxc-ls.sgml + doc/ko/lxc-monitor.sgml + doc/ko/lxc-snapshot.sgml + doc/ko/lxc-start-ephemeral.sgml + doc/ko/lxc-start.sgml + doc/ko/lxc-stop.sgml + doc/ko/lxc-top.sgml + doc/ko/lxc-unfreeze.sgml + doc/ko/lxc-unshare.sgml + doc/ko/lxc-user-nic.sgml + doc/ko/lxc-usernsexec.sgml + doc/ko/lxc-wait.sgml + + doc/ko/lxc.conf.sgml + doc/ko/lxc.container.conf.sgml + doc/ko/lxc.system.conf.sgml + doc/ko/lxc-usernet.sgml + doc/ko/lxc.sgml + doc/ko/common_options.sgml + doc/ko/see_also.sgml + hooks/Makefile templates/Makefile diff --git a/doc/Makefile.am b/doc/Makefile.am index 0e65d3516..ca69bfa90 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,8 +1,8 @@ SUBDIRS = examples rootfs -DIST_SUBDIRS = examples rootfs ja api +DIST_SUBDIRS = examples rootfs ja ko api if USE_DOCBOOK2X -SUBDIRS += ja +SUBDIRS += ja ko endif if ENABLE_API_DOCS diff --git a/doc/ko/FAQ.txt b/doc/ko/FAQ.txt new file mode 100644 index 000000000..50238ffde --- /dev/null +++ b/doc/ko/FAQ.txt @@ -0,0 +1,67 @@ + +Troubleshooting: +=============== + + +Error: +------ + +error while loading shared libraries reported after sudo make install +and when trying to run lxc-execute. + +"lxc-execute -n foo -f /usr/local/etc/lxc/lxc-macvlan.conf /bin/bash" + +/usr/local/bin/lxc-execute: error while loading shared libraries: + liblxc-0.5.0.so: cannot open shared object file: No such file or + directory + +Answer: +------- +update the ld cache by running ldconfig. + + + +Error: +------ + +error when starting a container. + +"lxc-start Invalid argument" + +"lxc-execute -n foo -f /usr/local/etc/lxc/lxc-macvlan.conf /bin/bash" +"[syserr] lxc_start:96: Invalid argument - failed to fork into a new +namespace" + +Answer: +------- + +read the lxc man page about kernel version prereq :) most probably +your kernel is not configured to support the container options you +want to use. + + +Error: +------ + +On Ubuntu 8.10, if using the cvs source code rather than +the provided tarball. Then make is failing with many errors +similar to the line below: +========== +../../libtool: line 810: X--tag=CC: command not found +========== + +Answer: +------- + +This is related to a compatibility problem between the shipped +config/ltmain.sh and the libtool version installed on your +Ubuntu 8.10 machine. +You have to replace the config/ltmain.sh from cvs head by the one +from your libtool package, make some cleaning and reissue all +the build process: +========== +cd +cp -f /usr/share/libtool/config/ltmain.sh config/ +rm -f libtool +./bootstrap && ./configure && make && sudo make install +========== diff --git a/doc/ko/Makefile.am b/doc/ko/Makefile.am new file mode 100644 index 000000000..0f3016845 --- /dev/null +++ b/doc/ko/Makefile.am @@ -0,0 +1,66 @@ +mandir = @mandir@/ko + +SUBDIRS = +DIST_SUBDIRS = + +EXTRA_DIST = \ + FAQ.txt + +if ENABLE_DOCBOOK +man_MANS = \ + lxc-attach.1 \ + lxc-autostart.1 \ + lxc-cgroup.1 \ + lxc-checkconfig.1 \ + lxc-checkpoint.1 \ + lxc-clone.1 \ + lxc-config.1 \ + lxc-console.1 \ + lxc-create.1 \ + lxc-destroy.1 \ + lxc-execute.1 \ + lxc-freeze.1 \ + lxc-info.1 \ + lxc-monitor.1 \ + lxc-snapshot.1 \ + lxc-start.1 \ + lxc-stop.1 \ + lxc-top.1 \ + lxc-unfreeze.1 \ + lxc-unshare.1 \ + lxc-user-nic.1 \ + lxc-usernsexec.1 \ + lxc-wait.1 \ + \ + lxc.conf.5 \ + lxc.container.conf.5 \ + lxc.system.conf.5 \ + lxc-usernet.5 \ + \ + lxc.7 + +if ENABLE_PYTHON + man_MANS += lxc-device.1 + man_MANS += lxc-ls.1 + man_MANS += lxc-start-ephemeral.1 +else + man_MANS += legacy/lxc-ls.1 +endif + +%.1 : %.sgml + $(db2xman) --encoding=UTF-8 $< + test "$(shell basename $@)" != "$@" && mv $(shell basename $@) $@ || true + +%.5 : %.sgml + $(db2xman) --encoding=UTF-8 $< + test "$(shell basename $@)" != "$@" && mv $(shell basename $@) $@ || true + +%.7 : %.sgml + $(db2xman) --encoding=UTF-8 $< + test "$(shell basename $@)" != "$@" && mv $(shell basename $@) $@ || true + +lxc-%.sgml : common_options.sgml see_also.sgml + +clean-local: + $(RM) manpage.* *.7 *.5 *.1 $(man_MANS) +endif diff --git a/doc/ko/common_options.sgml.in b/doc/ko/common_options.sgml.in new file mode 100644 index 000000000..3f74a7a00 --- /dev/null +++ b/doc/ko/common_options.sgml.in @@ -0,0 +1,161 @@ + + + + <!-- Common Options -->공통 옵션 + + + + 이 옵션들은 대부분의 lxc 명령어들에서 공통으로 쓰인다. + + + + + + + + + 사용법을 기존 출력하는 것보다 길게 출력한다. + + + + + + + + + 사용법을 표시한다. + + + + + + + + + + 결과를 표시하지 않는다. + + + + + + + + + + 컨테이너 경로를 직접 지정한다. 기본값은 @LXCPATH@이다. + + + + + + + + + + 로그의 경로를 FILE로 지정한다. 기본값은 로그를 출력하지 않는 것이다. + + + + + + + + + + 로그 수준을 LEVEL로 지정한다. 기본값은 ERROR이다. 사용 가능한 값 : + FATAL, CRIT, + WARN, ERROR, + NOTICE, INFO, + DEBUG. + + + + 이 옵션은 로그 파일에만 적용된다는 사실을 주의해야 한다. stderr로 출력되는 ERROR 로그에는 영향을 끼치지 않는다. + + + + + + + + + + 컨테이너 식별자로 NAME을 사용한다. 컨테이너 식별자의 형식은 알파벳-숫자 문자열이다. + + + + + + + + diff --git a/doc/ko/legacy/lxc-ls.sgml.in b/doc/ko/legacy/lxc-ls.sgml.in new file mode 100644 index 000000000..ffd6b4eeb --- /dev/null +++ b/doc/ko/legacy/lxc-ls.sgml.in @@ -0,0 +1,176 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-ls + 1 + + + + lxc-ls + + + + 시스템 내에 존재하는 컨테이너들의 리스트 표시 + + + + + + lxc-ls + --active + ls option + + + + + <!-- Description -->설명 + + + lxc-ls는 시스템 내에 존재하는 컨테이너들의 리스트를 표시한다. + + + + + <!-- Options -->옵션 + + + + + + + + + + 동작 중인 컨테이너들의 리스트를 표시한다. + + + + + + + + + + + + lxc-ls에는 ls와 같은 옵션을 사용할 수 있다. + + + + + + + + + + <!-- Examples -->예제 + + + lxc-ls -l + + + + 모든 컨테이너들의 리스트와 그들의 퍼미션 정보를 표시한다. + + + + + + lxc-ls --active -1 + + + + 동작 중인 컨테이너들의 리스트를 1열로 표시한다. + + + + + + + + + <!-- See Also -->참조 + + + + ls + 1 + , + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-attach.sgml.in b/doc/ko/lxc-attach.sgml.in new file mode 100644 index 000000000..c40dba9b3 --- /dev/null +++ b/doc/ko/lxc-attach.sgml.in @@ -0,0 +1,443 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-attach + 1 + + + + lxc-attach + + + + 실행 중인 컨테이너 내에 프로세스를 실행 + + + + + + lxc-attach + -n name + -a arch + -e + -s namespaces + -R + --keep-env + --clear-env + -- command + + + + + <!-- Description -->설명 + + + + lxc-attach는 name으로 지정한 컨테이너 내에 command를 실행한다. + 해당 컨테이너는 실행중이어야 한다. + + + + 만약 command가 지정되어 있지 않다면, lxc-attach가 실행되어 있는 현재 쉘이 컨테이너 안에 있는지를 검사하고 실행한다. + 만약 컨테이너 안에 사용자가 존재하지 않거나, nsswitch가 제대로 동작하지 않는 경우에는 이 명령이 실패하게 된다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 명령어를 실행하는 컨테이너의 아키텍처를 지정한다. + 이 옵션은 컨테이너의 설정파일에서 지정한 옵션과 같은 것만 사용할 수 있다. + + lxc.conf + 5 + 를 참조 바란다. 기본값은 실행 중인 컨테이너의 아키텍처이다. + + + + + + + + + + + + 컨테이너 내부에서 command를 실행할 때 privilege를 제거하지 않는다. + 만약 이 옵션이 지정되었다면, 새로운 프로세스는 컨테이너의 cgroup에 추가되지 않는다. 그리고 실행 전 capability도 제거하지 않는다. + + + + 만약 모든 privilege를 얻고 싶지 않을 경우에는 CGROUP|LSM와 같이 파이프(|)로 구분된 리스트를 사용할 수 있다. 허용되는 값은 CGROUP、CAP、LSM이다. 각각 cgroup, capability, MAC label을 나타낸다. + + + + 경고 : + 만약 명령어가 attach된 메인프로세스가 종료된 후에, 실행 상태로 남아있는 서브프로세스를 시작하려고 한다면, 컨테이너 내부로 privilege 누수가 발생할 수 있다. + 컨테이너 내에서 데몬을 시작(또는 재시작)하는 것은 문제가 될 수 있다. 특히 만약 데몬이 많은 서브프로세스 를 실행하는 경우라면, 예를 들어 cron와 sshd와 같은 경우는 문제가 될 수 있다. + 충분한 주의를 기울여서 사용하여야 한다. + + + + + + + + + + + + 붙일 네임스페이스를 지정한다. NETWORK|IPC와 같이 파이프(|)로 구분된 리스트를 사용할 수 있다. 허용되는 값은 MOUNT, PID, UTSNAME, IPC, USER , NETWORK이다. 이를 사용하여, 컨테이너의 네트워크 네임스페이스를 사용하면서도 다른 네임스페이스는 호스트의 것을 그대로 사용하는 등의 조작이 가능하다. + + + + 중요 : 이 옵션은 옵션을 포함하고 있다. + + + + + + + + + + + + 를 사용하여 마운트 네임스페이스를 포함하지 않았을 때, 이 플래그는 lxc-attach가 /proc와 /sys를 remount 하게 만든다. + 이는 현재와 다른 네임스페이스 컨텍스트를 반영시키기 위함이다. + + + + 좀더 자세한 설명은 주의섹션을 참고하면 된다. + + + + 만약 마운트 네임스페이스에 attach하려고 한다면, 이 옵션은 무시된다. + + + + + + + + + + + + 현재의 환경변수를 attach될 프로그램에도 그대로 적용한다. 이것은 현재 기본 동작이지만 (버전 0.9에서), 향후에 충분히 바뀔 수도 있다. 왜냐하면, 이것은 컨테이너에게 바람직하지 않은 정보를 넘겨줄 수 있는 위험성이 있기 때문이다. 따라서 이 기능에 의존하고 있다면, 향후에도 이를 보장할 수 있도록 이 옵션을 사용하는 것이 좋다. 또한 현재 환경 변수와 더불어, container=lxc도 설정된다. + + + + + + + + + + + + attach하기 전에 모든 환경변수를 지운다. + 이를 통해 바람직하지 않은 환경변수 누출을 막을 수 있다. container=lxc 만이 attach된 프로그램이 실행되기 전에 설정되는 유일한 환경변수이다. + + + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + 존재하는 컨테이너의 내부에 새로운 쉘을 실행한다. + + lxc-attach -n container + + + + + 실행중인 Debian 컨테이너의 cron 서비스를 재시작한다. + + lxc-attach -n container -- /etc/init.d/cron restart + + + + + NET_ADMIN capability없이 실행중인 컨테이너의 네트워크 링크 eth1을 비활성화하였다. 옵션을 사용하여 capability를 높였고, ip 툴이 설치되어있다고 가정하였다. + + lxc-attach -n container -e -- /sbin/ip link delete eth1 + + + + + + <!-- Compatibility -->호환성 + + + (pid와 마운트 네임스페이스를 포함한) attach가 동작하기 위해서는 커널의 버전이 3.8 이상이거나 패치가 적용된 커널이어야 한다. 좀더 자세히 보려면 lxc 웹사이트를 참고하면 된다. lxc-attach는 패치되지 않은 커널 버전 3.7 이하면 실패된다. + + + + 그러나 를 사용하여 NETWORK, IPC, UTSNAME 네임스페이스 들만 지정한다면, 패치되지 않은 커널 3.0 이상에서도 성공적으로 동작한다. + + + + 사용자 네임스페이스에 attach하기 위해서는 커널 버전이 3.8 이상이어야 하고 사용자 네임스페이스가 활성화되어야 한다. + + + + + <!-- Notes -->주의 + + + 리눅스의 /proc와 /sys 파일시스템은 네임스페이스의해 영향받는 몇가지 정보들을 포함하고 있다. 예를 들어 /proc의 프로세스 id로 된 폴더들이나 /sys/class/net의 네트워크 인터페이스 정보 등이다. +의사파일시스템을 마운트하는 프로세스의 네임스페이스가 여기에 어떤 정보를 표시할지 결정하는 것이지, /proc 또는 /sys에 접근하는 프로세스의 네임스페이스가 결정하는 것은 아니다. + + + + 를 사용하여 컨테이너의 pid 네임스페이스에만 attach 시키고 마운트 네임스페이스(컨테이너의 /proc는 포함하고, 호스트의 것은 포함하지 않는)는 attach 시키지 않는 경우, 의 내용은 컨테이너의 것이 아닌 호스트의 것이 됩니다. +비슷한 사례로 네트워크 네임스페이스만을 연결 하고 /sys/class/net의 내용을 읽을 때도 같은 현상이 있습니다. + + + + 이러한 문제를 해결하기 위해, 옵션이 제공됩니다. 해당 옵션은 attach되는 프로세스의 네트워크/pid 네임스페이스를 반영하기 위해 /proc와 /sys를 다시 마운트 합니다. +호스트의 실제 파일시스템에 방해가 되지 않기 위해 마운트 네임스페이스는 공유되지 않습니다(lxc-unshare의 동작과 비슷). /proc와 /sys 파일시스템을 제외하고 호스트 마운트 네임스페이스와 동일한 새로운 마운트 네임스페이스가 주어지게 됩니다. + + + + + <!-- Security -->보안 + + + 와 옵션을 사용할때는 주의하여야 합니다. 잘못사용하게 하면 컨테이너들 간의 고립(isolation)을 깨트릴 수 있습니다. + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-autostart.sgml.in b/doc/ko/lxc-autostart.sgml.in new file mode 100644 index 000000000..738504891 --- /dev/null +++ b/doc/ko/lxc-autostart.sgml.in @@ -0,0 +1,350 @@ + + + + +]> + + + @LXC_GENERATE_DATE@ + + lxc-autostart + 1 + + + + lxc-autostart + + + + 자동시작하게 설정된 컨테이너의 시작/종료/강제종료 + + + + + + lxc-autostart + -k + -L + -r + -s + -a + -A + -g groups + -t timeout + + + + + <!-- Description -->설명 + + + + lxc-autostart는 lxc.start.auto가 설정되어 있는 컨테이너들을 다룬다. + 사용자가 컨테이너의 시작, 종료, 강제종료, 재시작의 순서와 대기 시간을 정할 수 있게 해준다. + lxc.group으로 필터링하거나 모든 정의된 컨테이너를 실행하는 등의 동작을 지원한다. + 또한 리스트 모드를 통해 외부 툴이 이를 사용할 수 있고, 대상 컨테이너의 리스트와 대기시간 등을 얻어올 수 있다. + + + + + -r, -s, -k 옵션은 어떤 동작을 수행할지 지정해 줄 수 있다. 만약 아무것도 지정하지 않았다면, 컨테이너를 시작한다. + -a, -g는 어떤 컨테이너를 대상으로 할지 지정한다. 기본적으로 lxc.group가 지정되지 않은 컨테이너들이 대상이 된다. + -t TIMEOUT은 컨테이너가 종료나 재부팅을 마칠 때까지 기다릴 최대 시간을 지정한다. + + + + + <!-- Options -->옵션 + + + + + + + + + 컨테이너가 재부팅하도록 요청한다. + + + + + + + + + + + + 깔끔한 종료를 요청한다. 만약 -t timeout가 0보다 크고 컨테이너가 그 기간안에 종료되지 않는다면 -k kill 옵션과 같은 동작을 수행하여 강제종료 한다. + + + + + + + + + + + + 깔끔한 종료를 요청하는 것이 아니라 컨테이너의 모든 태스크들을 명시적으로 강제종료 시킨다. + + + + + + + + + + + + 실제 동작은 수행하지 않고, 단지 컨테이너의 이름과 다음 컨테이너를 시작할 때까지의 대기시간들을 표시한다. + + + + + + + + + + + + 컨테이너가 강제종료되기 전까지 TIMEOUT 초만큼 기다린다. + + + + + + + + + + + + 쉼표(,)로 구분된 선택할 그룹의 리스트. + (기본값은 lxc.group이 없는 것이다 - NULL 그룹) + + 이 옵션은 여러번 지정될 수 있으며, 각 옵션들은 연결될 수 있다. NULL 또는 빈 그룹은 첫번째 쉼표, 맨 뒤의 쉼표, 두개의 쉼표 등으로 지정할 수 있다. 그룹들은 지정한 순서대로 처리됩니다. 여러번 호출된 -g 옵션과 콤마로 구분된 목록들은 자유롭게 혼용하여 사용 할 수 있다. + + + + + + + + + + + + lxc.group를 무시하고 모든 자동 시작하게 설정된 컨테이너들을 선택한다. + + + + + + + + + + + + lxc.start.auto 옵션을 무시하고 시스템의 모든 컨테이너를 선택한다. + + + + + + + + <!-- Autostart and System Boot -->자동시작과 시스템 부팅 + + + + 부팅과 종료시 호스트의 시스>템에서 실행되도록 활성화 되어있을 때, lxc-autostart 명령어는 LXC 시스템 서비스의 일부로 사용됩니다. 어떤 컨테이너를 어떤 순서로 얼마만큼 시작간격을 두어 시작할지를 선택하는데 사용됩니다. + + + + + 각각의 컨테이너는 여러 그룹에 속할수도 있고 아무그룹에도 속하지 않을 수 있다. 두개의 그룹은 특수한데, 하나는 NULL 그룹이고 컨테이너가 아무그룹에도 속하지 않을때 사용된다. 그리고 나머지 하나는 "onboot" 그룹이다. + + + + + LXC 서비스가 활성화된 상태로 시스템이 부팅될 때, 먼저 lxc.start.auto == 1이고 "onboot" 그룹인 컨테이너들을 시작하려고 시도한다. 시작과정은 lxc.start.order의 순서대로 이루어진다. + 만약 lxc.start.delay가 지정 되었다면, 다음 컨테이너를 시작하려고 시도하기 전, 현재 컨테이너의 초기화 및 호스트 시스템의 부하를 줄이기 위해서 지연시간을 준다. + "onboot" 그룹의 멤버들을 시작시킨 후, LXC 시스템은 lxc.start.auto == 1이고 어떤 그룹에도 속하지 않은(NULL 그룹) 컨테이너들을 시작한다. + + + + + <!-- Startup Group Examples -->시작 그룹 예제 + + + + + + + + + 먼저 "onboot" 그룹을 실행하고 NULL 그룹을 실행한다. + + + + 이것은 다음과 같다 : + + + + + + + + + + + 첫번째로 dns 그룹을 실행하고, web 그룹을 두번째로 실행하고, NULL그룹을 실행한 뒤, "onboot" 그룹을 실행한다. + + + + 이것은 다음과 같다 : 또는 + + + + + + + &seealso; + + + <!--Author-->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-cgroup.sgml.in b/doc/ko/lxc-cgroup.sgml.in new file mode 100644 index 000000000..9efb8d269 --- /dev/null +++ b/doc/ko/lxc-cgroup.sgml.in @@ -0,0 +1,206 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-cgroup + 1 + + + + lxc-cgroup + + + + 컨테이너와 관련된 컨트롤 그룹 관리 + + + + + + lxc-cgroup + -n name + state-object + value + + + + + <!-- Description -->설명 + + + + lxc-cgroup는 지정한 서브시스템(예를 들어 'cpuset')의 컨테이너 cgroup의 state-object (예를들어 'cpuset.cpus')의 값을 얻어오거나 설정한다. + 만약 value가 지정되지 않았다면, state-object의 현재 값을 표시한다. 지정한 경우에는 해당 값으로 설정한다. + + + + + lxc-cgroup는 state-object가 실행중인 커널에서 사용가능한지 검사하지 않는 것을 주의해야 한다. 또한 지정한 서브시스템이 마운트된 cgroup에 포함이 되어 있는지도 검사하지 않는다. + + + + + + <!-- Options -->옵션 + + + + + + + + + + cgroup의 state object 이름을 지정한다. + + + + + + + + + + + + cgroup의 state object에 설정할 값을 지정한다. + + + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + lxc-cgroup -n foo devices.list + + + + 허용된 디바이스를 표시한다. + + + + + + lxc-cgroup -n foo cpuset.cpus "0,3" + + + + 프로세서 0과 3을 컨테이너에게 할당한다. + + + + + + + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 컨테이너가 실행중이 아니다. + + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-checkconfig.sgml.in b/doc/ko/lxc-checkconfig.sgml.in new file mode 100644 index 000000000..6462e9765 --- /dev/null +++ b/doc/ko/lxc-checkconfig.sgml.in @@ -0,0 +1,112 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-checkconfig + 1 + + + + lxc-checkconfig + + + + 현재 커널의 lxc 지원 여부 검사 + + + + + + lxc-checkconfig + + + + + <!-- Description -->설명 + + + lxc-checkconfig는 현재 커널이 lxc를 지원하는지 검사한다. + + + + + <!-- Examples -->예제 + + + lxc-checkconfig + + + + 현재 커널을 검사한다. + CONFIG 환경 변수를 이용하여 다른 위치를 설정할 수 있다. + (역주 : 기본값은 /proc/config.gz 이다. Kernel compile option에서 Enable access to .config through /proc/config.gz를 체크하여야 한다) + + + + + + + &seealso; + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-checkpoint.sgml.in b/doc/ko/lxc-checkpoint.sgml.in new file mode 100644 index 000000000..e784a877c --- /dev/null +++ b/doc/ko/lxc-checkpoint.sgml.in @@ -0,0 +1,230 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-checkpoint + 1 + + + + lxc-checkpoint + + + + 컨테이너의 체크포인트 생성 및 복원 + + + + + + lxc-checkpoint + -n name + -D PATH + -r + -s + -v + -d + -F + + + + + <!-- Description -->설명 + + + lxc-checkpoint 는 컨테이너의 체크포인트를 생성 및 복원을 수행한다. + (역주 : 이 명령어를 사용하기 위해서는 CRIU(Checkpoint/Restore In Userspace)라는 툴이 반드시 필요하다, 컨테이너의 실행상태를 대상으로 한다는 점에서 lxc-snapshot와는 다르다) + + + + + <!-- Options -->옵션 + + + + + + + + + + 컨테이너의 상태를 저장하는 것 대신에 체크포인트로 복원을 수행한다. + 이 옵션은 과 같이 사용될 수 없다. + + + + + + + + + + + + 체크포인트 메타데이터를 저장할 디렉토리를 지정한다. + + + + + + + + + + + + 컨테이너의 상태를 저장한 후 컨테이너를 중지한다. 이 옵션은 과 같이 사용될 수 없다. + + + + + + + + + + + + CRIU 로그 기록을 자세하게 한다. + + + + + + + + + + + + 컨테이너 복원을 백그라운드에서 수행한다. (이것이 기본으로 되어있다) + 옵션이랑만 사용가능하다. + + + + + + + + + + + + 컨테이너 복원을 포그라운드에서 수행한다. 옵션이랑만 사용가능하다. + + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + + lxc-checkpoint -n foo -D /tmp/checkpoint + + + + foo 컨테이너의 체크포인트를 /tmp/checkpoint 디렉토리에 생성한다. + + + + + + lxc-checkpoint -r -n foo -D /tmp/checkpoint + + + + foo 컨테이너를 /tmp/checkpoint 디렉토리에 있는 체크포인트로 복원한다. + + + + + + + + &seealso; + + + <!-- Author -->저자 + Tycho Andersen tycho.andersen@canonical.com + + + + diff --git a/doc/ko/lxc-clone.sgml.in b/doc/ko/lxc-clone.sgml.in new file mode 100644 index 000000000..a9c3bd5c4 --- /dev/null +++ b/doc/ko/lxc-clone.sgml.in @@ -0,0 +1,348 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-clone + 1 + + + + lxc-clone + + + + 존재하는 컨테이너를 새로운 컨테이너로 복제 + + + + + + lxc-clone + -s + -K + -M + -H + -B backingstore + -L fssize + -p lxcpath + -P newlxcpath + -o orig + -n new + -- hook arguments + + + lxc-clone + -s + -K + -M + -H + -B backingstore + -L fssize + -p lxcpath + -P newlxcpath + orig + new + -- hook arguments + + + + + <!-- Description -->설명 + + + + lxc-clone는 존재하는 컨테이너를 복제하여 새로운 컨테이너를 생성한다. 복사, 스냅샷의 두가지 형태의 복제가 지원된다. + 복사는 원본 컨테이너의 루트 파일시스템을 그대로 새 컨테이너로 복사한다.. + 스냅샷은 저장소의 스냅샷 기능을 이용하여 원본 컨테이너의 copy-on-write 형태로 매우 작은 스냅샷을 생성한다. 스냅샷을 사용하기 위해서는 새 컨테이너의 저장소가 스냅샷 기능을 지원하여야 한다. 현재 스냅샷 기능을 지원하는 것은 aufs, btrfs, lvm, overlayfs, zfs 정도이다. lvm은 스냅샷의 스냅샷은 지원하지 않는다. + + + + + 오버레이 컨테이너들을 제외하면, 새 컨테이너의 저장소는 원본과 같은 종류를 사용한다. + aufs와 overlayfs의 스냅샷은 디렉토리로 구성된 컨테이너로 생성할 수 있다. overlayfs의 경우 -B overlayfs 인수를 통해 이를 지정할 수 있다. + + + + + 원본 컨테이너와 새 컨테이너의 이름은 모든 옵션 뒤에 원본, 새 컨테이너 순으로 지정할 수 있다. 또는 -o과 -n 옵션을 사용하여 지정할 수 있다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 새로 생성하는 컨테이너의 루트 파일시스템은 원본의 스냅샷으로 한다. 이 옵션은 저장소가 lvm, btrfs, zfs 일때 지정할 수 있다. 또한 aufs나 overlayfs를 이용한 스냅샷을 원할때만 지정해야 한다. + + + + + + + + + + + + (루트 파일시스템에서) 컨테이너의 호스트 이름을 변경하지 않는다. + + + + + + + + + + + + 새로 무작위한 주소를 만들지 않고, 원본과 같은 MAC 주소를 사용한다. + + + + + + + + + + + + 모든 마운트 훅들을 새 컨테이너의 디렉토리로 복사한다. 그리고 lxcpath와 컨테이너 이름을 필요에 따라 갱신한다. + + + + + + + + + + + + 블록장치로 구성된 컨테이너의 경우, 새로운 블록 장치의 크기. + 기본으로 새 디바이스는 원본과 같은 크기로 만들어진다. + + + + + + + + + + + + 원본 컨테이너의 lxcpath. 기본값은 시스템 전역으로 설정되어 잇는 lxcpath를 사용한다. + + + + + + + + + + + + 새로 생성될 컨테이너의 lxcpath. + 기본값은 원본 컨테이너의 lxcpath와 같다. + btrfs의 스냅샷의 경우 lxcpath 변경이 불가능 할 수 있음을 주의해야 한다. 왜냐하면 서브볼륨 스냅샷이 같은 btrfs 파일시스템 내에 있어야 하기 때문이다. + + + + + + + + + + + + 새 컨테이너의 저장소를 선택한다. + 기본 값은 원본 컨테이너가 쓰던 것과 같은 것으로 되어 있다. + 현재 저장소를 다른 것으로 변경하는 것은 디렉토리로 구성된 컨테이너의 aufs와 overlayfs 스냅샷에서만 지원된다. + 가능한 값은 dir(디렉토리), aufs, btrfs, lvm zfs, loop 그리고 ovelayfs 이다. + + + + + + + + + + + + 복제할 원본 컨테이너의 이름. + + + + + + + + + + + + 생성할 새 컨테이너의 이름. + + + + + + + + + + + Clone hook + + + 만약 복제되는 컨테이너가 1개 이상의 lxc.hook.clone을 지정했다면, 지정된 훅은 새 컨테이너가 생성될 때 실행될 것이다. + 먼저 컨테이너 이름, 섹션('lxc'), 훅 종류('clone') 3개의 인수가 복제 훅에 전달 된다. 그리고 4번째 인수 부터는 lxc-clone로 넘겨줄 수 있다. + LXC_ROOTFS_MOUNT 환경변수는 컨테이너의 루트 파일시스템이 마운트되어 있는 경로를 넘겨준다. + 새 컨테이너의 이름은 LXC_NAME 변수에, 이전 컨테이너의 이름은 LXC_SRC_NAME 환경변수에 담겨 있다. 그리고 루트 파일시스템이 위치하고 있는 곳은 LXC_ROOTFS_PATH로 넘겨준다. + + + + &seealso; + + + <!-- Author -->저자 + Serge Hallyn serge.hallyn@ubuntu.com + + + + + diff --git a/doc/ko/lxc-config.sgml.in b/doc/ko/lxc-config.sgml.in new file mode 100644 index 000000000..7d309fd56 --- /dev/null +++ b/doc/ko/lxc-config.sgml.in @@ -0,0 +1,129 @@ + + + + +]> + + + @LXC_GENERATE_DATE@ + + lxc-config + 1 + + + + lxc-config + + + + LXC 시스템 설정 얻어오기 + + + + + + lxc-config + -l + item + + + + + <!-- Description -->설명 + + + + lxc-config는 lxc 시스템 설정을 보여준다. 가능한 모든 항목의 이름을 나열하기도 하고 각각의 항목들에 설정되어 잇는 값을 보여주기도 한다. + + + + + <!-- Options -->옵션 + + + + + + + + + 지원되는 모든 항목의 이름을 나열한다. + + + + + + + + + + + + 지정한 항목에 설정되어 있는 값을 표시한다. + + + + + + + &seealso; + + + <!--Author-->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-console.sgml.in b/doc/ko/lxc-console.sgml.in new file mode 100644 index 000000000..8d435d906 --- /dev/null +++ b/doc/ko/lxc-console.sgml.in @@ -0,0 +1,208 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-console + 1 + + + + lxc-console + + + + 지정한 컨테이너의 콘솔 실행 + + + + + + lxc-console + -n name + -e escape character + -t ttynum + + + + + <!-- Description -->설명 + + + + 만약 파라미터로 지정한 컨테이너의 tty 서비스가 제대로 설정되어 있고 사용가능한 상태라면, 이 명령어는 컨테이너에 로그인 할 수 있는 콘솔을 실행한다. + + + + + 사용가능한 tty는 이 명령어로 얻어올 수 있는 빈 슬롯을 의미한다. + 즉, 만약 컨테이너가 4개의 tty가 사용가능하고 명령어가 4번 실행하여 각각 다른 tty를 얻어왔다면, 다섯번째 명령은 실패할 것이다. 왜냐하면 가능한 콘솔이 없기 때문이다. + + + + + 명령어는 tty에 연결한다. 연결이 끊어지면, 명령어는 다시 실행되어 연결 끊기기 이전 상태에서 tty를 얻어오려고 시도한다. + + + + + ttynum가 0으로 지정되어 있으면, 컨테이너의 /dev/console에 연결한다. 그렇지 않으면 dev/tty<ttynum>에 연결한다. + + + + + tty 접속을 끊고 lxc-console을 나가고 싶다면 키보드 이스케이프 키를 이용하면 된다. 기본키는 <Ctrl+a q>이다. + + + + + + <!-- Options -->옵션 + + + + + + + + + + <Ctrl a> 대신에 사용할 이스케이프 키 prefix를 지정한다. + '^문자' 또는 '문자'로 지정 가능하다. + 예를 들어 <Ctrl+b q>를 사용하고 싶다면, -e '^b'와 같이 지정하면 된다. + + + + + + + + + + + 연결하고자 하는 tty의 번호 또는 콘솔 연결을 위해 0을 지정한다. + 지정하지 않으면, 다음으로 사용가능한 tty 번호를 컨테이너가 자동으로 선택한다. + + + + + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + tty service denied + + + + 사용가능한 tty가 없거나 콘솔을 사용하기에 충분한 privilege가 없다. + 예를 들면, 컨테이너가 "foo" 사용자 소유인데 "bar"가 콘솔을 열려고 하는 경우이다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-create.sgml.in b/doc/ko/lxc-create.sgml.in new file mode 100644 index 000000000..9e0a7527b --- /dev/null +++ b/doc/ko/lxc-create.sgml.in @@ -0,0 +1,284 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-create + 1 + + + + lxc-create + + + + 컨테이너 생성 + + + + + + lxc-create + -n name + -f config_file + -t template + -B backingstore + -- template-options + + + + + <!-- Description -->설명 + + + + lxc-create는 설정정보와 사용자 정보가 저장되는 시스템 객체를 생성한다. + name은 다른 lxc 명령어들에서 특정 컨테이너를 지정하는데 사용된다. + + + + 객체는 @LXCPATH@에 작성되는 디렉토리이며, 자신의 name으로 구분되어 진다. + + + + + 객체는 응용 프로그램이 사용할 수 있고 볼 수 있는 여러 자원들의 정의이다. + 설정파일이 많은 정보를 담고 있을수록 컨테이너는 더욱더 고립될 수 있고, 응용 프로그램은 더욱더 격리될 수 있다. + + + + + 만약 설정파일 config_file가 지정되지 않았다면, 컨테이너는 프로세스, sysv ipc, 마운트 포인트에 대한 기본적인 고립 상태로 만들어진다. + + + + + <!-- Options -->옵션 + + + + + + + + + + 컨테이너 가상화 및 고립 기능을 설정하는 설정파일을 지정합니다. + + + + + + + + + + + + lxc-create 명령어는 'lxc-template' 스크립트를 호출한다. template은 'lxc-template' 스크립트의 짧은 이름으로, busybox, debian, fedora, ubuntu, sshd 등이 있다. 스크립트의 구조에 대해 궁금할 때는 @LXCTEMPLATEDIR@에 있는 예제들을 참고하면 된다. + template 대신 스크립트의 전체 경로를 지정할 수도 있다. + "none"으로 지정하면 루트파일시스템 생성을 강제로 건너뛸 수 있다. + + + + + + + + + + + + 'backingstore'는 'dir', 'lvm', 'loop', 'btrfs', 'zfs', 'best'를 지정할 수 있다. + 기본 값은 'dir'로 컨테이너 루트 파일시스템을 의미하며 @LXCPATH@/container/rootfs이하 디렉토리를 가리킨다. + 'dir'은 옵션으로 컨테이너 루트 파일시스템이 어느 경로에 위치할지 지정할 수 있으며, --dir ROOTFS로 가능하다. + ('none'은 'dir'과 동일하다) + 'btrfs'가 지정되어 있다면, 타겍 파일시스템은 반드시 btrfs여야 한다. 그리고 컨테이너 루트 파일시스템은 새로운 서브볼륨으로 생성된다. 이는 스냅샷된 복제물을 만들지만, rsync --one-filesystem는 분리된 파일시스템으로 취급하게 된다. + 'lvm'으로 지정되있다면, lvm 블록 디바이스가 사용되며, 이때 사용가능한 옵션은 다음과 같다 : --lvname lvname1는 이름이 lvname1인 LV를 만든다(기본값은 컨테이너 이름). +--vgname vgname1는 이름이 vgname1인 볼륨그룹 안에 LV를 만든다(기본값은 lxc). + --thinpool thinpool1는 thinpool1라는 풀 안에 있는 thin-provisioned 볼륨으로 LV를 만든다(기본값은 lxc). + --fstype FSTYPE는 LV의 파일시스템을 FSTYPE으로 지정한다(기본값은 ext4). + --fssize SIZE는 LV의 크기를 지정한다(기본값은 1G). + + + + 'loop'로 지정되어 있다면, 'lvm'과 비슷하게 --fstype FSTYPE과 --fssize SIZE를 사용할 수 있다(기본값은 'lvm'과 동일). + + + + 'best'로 지정되어 있다면, lxc는 btrfs, zfs, lvm, dir의 순서대로 시도해본다. + + + + + + + + + + + + 이것은 template-options를 템플릿에게 인수로 넘긴다. 만약 어떤 인수를 템플릿에서 지원하는지 보고 싶다면, lxc-create -t TEMPLATE -h를 사용하면 된다. + + + + + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + The container already exists + + + + 메시지에 나와있는 대로, 이미 같은 이름의 컨테이너가 존재하는 경우이다. lxc-ls 명령어를 사용하여 시스템에 이미 존재하는 컨테이너를 확인해볼 수 있다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-destroy.sgml.in b/doc/ko/lxc-destroy.sgml.in new file mode 100644 index 000000000..cb5d0b6b4 --- /dev/null +++ b/doc/ko/lxc-destroy.sgml.in @@ -0,0 +1,162 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-destroy + 1 + + + + lxc-destroy + + + + 컨테이너 제거 + + + + + + lxc-destroy + -n name + -f + + + + + <!--Description-->설명 + + + + lxc-destroy는 lxc-create로 이전에 생성했던 시스템 객체를 제거한다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + 만약 컨테이너가 실행중이라면, 컨테이너를 종료시킨다. + 이 옵션이 지정되지 않았을 때 컨테이너가 실행중이라면, lxc-destroy는 중지될 것이다. + + + + + + + + + + 컨테이너 경로를 지정한다. 기본값은 @LXCPATH@이다. + + + + + + + + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 제거하려는 컨테이너를 찾을 수 없는 경우이다. 아마도 존재하지 않았거나 이미 제거되었을 경우일 것이다. lxc-ls 명령어를 사용하여 시스템에 존재하는 컨테이너를 확인해볼 수 있다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-device.sgml.in b/doc/ko/lxc-device.sgml.in new file mode 100644 index 000000000..2c8cbd490 --- /dev/null +++ b/doc/ko/lxc-device.sgml.in @@ -0,0 +1,205 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-device + 1 + + + + lxc-device + + + + 실행 중인 컨테이너의 디바이스 관리 + + + + + + lxc-device + -h + -n name + add + DEVICE + NAME + + + + + <!-- Description -->설명 + + + lxc-device는 실행중인 컨테이너의 디바이스를 관리한다. + + + + + <!-- Options -->옵션 + + + + + + + + + 명령어의 전체 도움말을 표시한다. + + + + + + + + + + + + 대상으로 하는 컨테이너의 이름. + + + + + + + + + + + + 수행할 동작. 현재는 'add'만 지원된다. + + + + + + + + + + + + 컨테이너에 추가할 디바이스. + 장치의 경로를 /dev 밑으로 지정하거나 네트워크 인터페이스 이름이 지정 가능하다. + + + + + + + + + + + + 컨테이너 내부에서 쓰일 디바이스의 이름 + + + + + + + + <!-- Examples -->예제 + + + lxc-device -n p1 add /dev/video0 + + + + 컨테이너 p1 내부에 호스트의 것과 같은 /dev/video0 장치를 생성한다. + + + + + + lxc-device -n p1 add eth0 eth1 + + + + 호스트의 eth0를 컨테이너 p1에 eth1의 이름으로 옮긴다. + + + + + + + &seealso; + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-execute.sgml.in b/doc/ko/lxc-execute.sgml.in new file mode 100644 index 000000000..e7dc794fc --- /dev/null +++ b/doc/ko/lxc-execute.sgml.in @@ -0,0 +1,238 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-execute + 1 + + + + lxc-execute + + + + 컨테이너 내부로 응용 프로그램 실행 + + + + + + lxc-execute + -n name + -f config_file + -s KEY=VAL + -- command + + + + + <!-- Description -->설명 + + + + lxc-execute는 지정한 command를 name라는 이름의 컨테이너 내부에서 실행한다. + + + + 이 명령어는 lxc-create 정의했던 설정을 토대로 또는 인수 +를 통해 넘긴 설정파일을 토대로 컨테이너를 세팅한다. + 만약 정의된 설정이 없다면, 기본 고립 환경을 사용한다. + + + + 이 명령어들은 고립된 환경에서 응용 프로그램을 빠르게 실행해보고 싶을 때, 주로 사용한다. + + + + lxc-execute명령어는 컨테이너 내부에서 lxc-init 프로세스를 통해 지정한 명령어를 실행한다. + lxc-init은 지정한 명령어를 실행한 뒤에, 해당 명령어 및 그 명령어에서 실행된 모든 프로세스들을 기다린다(컨테이너 내에서 데몬을 지원하기 위한 것). + 즉, 컨테이너내에서 lxc-init는 pid는 1이 되고, 그 다음으로 실행되는 응용 프로그램은 pid가 2가 된다. + + + + lxc-init는 시그널들을 받아서 시작한 명령어에게 보내주도록 되어 있다. + + + + + <!-- Options -->옵션 + + + + + + + + + + 컨테이너의 가상화나 고립 기능을 설정할 때 쓰일 설정파일을 지정한다. + + + + 지정한 설정파일이 존재한다면, 이전에 생성된(lxc-create를 통해) 컨테이너에 설정파일이 이미 존재한다고 하더라도 지정한 설정파일을 사용한다. + + + + + + + + + + + VAL 값을 KEY 설정변수에 넣는다. + 이는 config_file에서의 설정을 덮어쓴다. + + + + + + + + + 옵션이 끝임을 지정하고 더이상 옵션에 대한 처리를 하지 않는다. + -- 이후에 오는 모든 인수는 command의 인수로서 처리된다. + + + + 이것은 command에게 옵션을 지정하고, lxc-execute가 그 옵션을 처리하지 않게 하는데 유용하게 사용된다. + + + + + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + The container is busy + + + + 지정한 컨테이너가 이미 실행중인 경우이다. 컨테이너를 사용하고 싶다면 컨테이너를 중지시켜야 한다. 또는 새로운 컨테이너를 만들 수도 있다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-freeze.sgml.in b/doc/ko/lxc-freeze.sgml.in new file mode 100644 index 000000000..40bb5b82d --- /dev/null +++ b/doc/ko/lxc-freeze.sgml.in @@ -0,0 +1,130 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-freeze + 1 + + + + lxc-freeze + + + + 컨테이너의 모든 프로세스를 동결 + + + + + + lxc-freeze + -n name + + + + + <!-- Description -->설명 + + + + lxc-freeze는 컨테이너 내부에서 실행되는 모든 프로세스를 동결시킨다. + 프로세스는 lxc-unfreeze 명령어를 이용하여 명시적으로 동결 해제시킬 때까지 블로킹 된다. + 이 명령어는 프로세스 그룹들을 스케줄링하여 일괄처리하는 데 유용하다. + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 지정한 컨테이너가 lxc-create로 생성된 적이 없다. + 컨테이너가 존재하지 않는다. + + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-info.sgml.in b/doc/ko/lxc-info.sgml.in new file mode 100644 index 000000000..08ebcf390 --- /dev/null +++ b/doc/ko/lxc-info.sgml.in @@ -0,0 +1,260 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-info + 1 + + + + lxc-info + + + + 컨테이너의 정보 조회 + + + + + + lxc-info + -n name + -c KEY + -s + -p + -i + -S + -H + + + + + <!-- Description -->설명 + + + lxc-info는 컨테이너에 대한 정보를 조회하고 표시한다. + + + + + <!-- Options --> + + + + + + + + + + 컨테이너의 설정값을 표시한다. 이 옵션은 1개 이상의 key = value 쌍을 표시할 수 있다. + + + + + + + + + + + + 컨테이너의 상태를 표시한다. + + + + + + + + + + + + 컨테이너의 pid를 표시한다. + (역주 : 컨테이너 내의 init 프로세스를 의미한다) + + + + + + + + + + + + 컨테이너의 IP 주소를 표시한다. + + + + + + + + + + + + 컨테이너의 통계정보를 표시한다. + 성능상의 이유로, 커널 메모리 제한이 걸려있지 않다면 커널의 메모리 사용량은 집계되지 않는다. + 만약 제한되어 있지 않다면, lxc-info는 커널 메모리 사용량을 0으로 표시한다. 메모리 제한은 + + lxc.cgroup.memory.kmem.limit_in_bytes = number + + 를 컨테이너 설정파일에 넣음으로써 지정할 수 있다. + + lxc.conf + 5 + 를 참고 바란다. + + + + + + + + + + + + 컨테이너의 통계값을 사람이 읽기 쉬운 형태로 변환하지 않고 그대로 표시한다. + 기본값은 사람이 읽기 쉬운 형태로 변환하는 것이다. + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + lxc-info -n foo + + + + foo 라는 이름의 컨테이너 정보를 표시한다. + + + + + + lxc-info -n 'ubuntu.*' + + + + ubuntu 라는 문자열로 시작하는 이름의 컨테이너들의 정보를 표시한다. + + + + + + lxc-info -n foo -c lxc.network.0.veth.pair + + + + foo 컨테이너의 veth pair 이름을 표시한다. + + + + + + + + &seealso; + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-ls.sgml.in b/doc/ko/lxc-ls.sgml.in new file mode 100644 index 000000000..a97495bb0 --- /dev/null +++ b/doc/ko/lxc-ls.sgml.in @@ -0,0 +1,289 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-ls + 1 + + + + lxc-ls + + + + 시스템 내에 존재하는 컨테이너들의 리스트 표시 + + + + + + lxc-ls + -1 + --active + --frozen + --running + --stopped + -f + -F format + -g groups + --nesting + filter + + + + + <!-- Description -->설명 + + + lxc-ls는 시스템 내에 존재하는 컨테이너들의 리스트를 표시한다. + + + + + <!-- Options -->옵션 + + + + + + + + + 1개의 항목를 한 줄에 표시한다. (/dev/stdout이 tty가 아닌 경우 기본) + + + + + + + + + + + + 동작 중인 컨테이너들의 리스트를 표시한다. (--frozen --running과 동일) + + + + + + + + + + + + 동결된 컨테이너들의 리스트를 표시한다. + + + + + + + + + + + + 실행 중인 컨테이너들의 리스트를 표시한다. + + + + + + + + + + + + 종료되어 있는 컨테이너들의 리스트를 표시한다. + + + + + + + + + + + + 예쁘게, 컬럼 기반으로 출력해준다. + + + + + + + + + + + + --fancy로 출력할때 어떤 컬럼을 보여줄지 쉼표(,)로 구분된 리스트. + 기본으로 표시되는 항목 및 선택할 수 있는 항목을 확인하려면 --help를 사용하면 된다. + + + + + + + + + + + + 표시하고자하는 컨테이너 그룹의 쉼표로 구분된 리스트. + 이 인수는 여러번 사용될 수 있다. + + + + + + + + + + + + 중첩된(nested) 컨테이너들의 리스트를 표시합니다. + + + + + + + + + + + + lxc-ls 명령어 사용시 컨테이너 이름에 적용할 필터. + 형식은 정규표현식이다. + + + + + + + + + + <!-- Examples -->예제 + + + lxc-ls --fancy + + + + 모든 컨테이너를 표시한다. 1개의 행에 컨테이너의 이름, 상태, ipv4 및 ipv6 주소가 들어있다. + + + + + + lxc-ls --active -1 + + + + 동작 중인 컨테이너들의 리스트를 1열로 표시한다. + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-monitor.sgml.in b/doc/ko/lxc-monitor.sgml.in new file mode 100644 index 000000000..ce7105319 --- /dev/null +++ b/doc/ko/lxc-monitor.sgml.in @@ -0,0 +1,238 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-monitor + 1 + + + + lxc-monitor + + + + 컨테이너의 상태 모니터링 + + + + + + lxc-monitor + -n name + -Q + + + + + <!-- Description -->설명 + + + + lxc-monitor는 컨테이너의 상태를 주시한다. + name 인수는 어떤 컨테이너를 모니터링할지 지정한다. + 이 인수는 POSIX 호환 정규 표현식으로 지정할 수 있다. 따라서 모든 컨테이너를 또는 그 중 몇몇만 또는 한 개의 컨테이너만 모니터링하는 것이 가능하다. + 만약 인수가 지정되지 않았다면 name는 기본값으로 '.*'가 사용된다. 이 값은 lxcpath에 있는 모든 컨테이너들을 모니터링 할 수 있다. + + + + + =PATH 옵션을 사용하여 컨테이너 경로를 지정할 수 있으며, 1개 이상도 가능하다. + 하지만 각각 다른 경로에 있는 이름이 같은 컨테이너는 출력에서 구분되지 않는다. + + + + + + <!-- Options -->옵션 + + + + + + + + + + 지정한 lxcpath 각각에 대한 lxc-monitord 데몬을 종료하도록 요청한다. + lxc-monitord는 일반적으로 클라이언트가 없으면, 새로운 클라이언트를 를 30초 동안 기다린 후 종료된다. 하지만 이 명령어를 실행한 후에는 클라이언트가 없으면 바로 종료된다. + 이 옵션은 lxcpath의 파일시스템을 바로 unmount할 필요가 있을때, 유용하다. + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + lxc-monitor -n foo + + + + foo 컨테이너의 상태 변화를 모니터링한다. + + + + + + lxc-monitor -n 'foo|bar' + + + + 컨테이너 foo와 bar의 상태 변화를 모니터링 한다. + + + + + + lxc-monitor -n '[f|b].*' + + + + 이름이 'f' 또는 'b'로 시작하는 컨테이너의 상태 변화를 모니터링한다. + + + + + + lxc-monitor -n '.*' + + + + 모든 컨테이너들의 상태 변화를 모니터링한다. + + + + + + + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 지정한 컨테이너가 lxc-create로 생성된 적이 없다. + 컨테이너가 존재하지 않는다. + + + + + + + + + + + <!-- See Also -->참조 + + + + regex + 7 + , + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-snapshot.sgml.in b/doc/ko/lxc-snapshot.sgml.in new file mode 100644 index 000000000..ac079706f --- /dev/null +++ b/doc/ko/lxc-snapshot.sgml.in @@ -0,0 +1,208 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-snapshot + 1 + + + + lxc-snapshot + + + + 존재하는 컨테이너의 스냅샷 생성 및 복원 + + + + + + lxc-snapshot + -n, --name name + -c, --comment file + + + lxc-snapshot + -n, --name name + -d, -destroy snapshot-name + + + lxc-snapshot + -n, --name name + -L, --list + -C, --showcomments + + + lxc-snapshot + -n, --name name + -r, -restore snapshot-name + newname + + + + + <!-- Description -->설명 + + + + lxc-snapshot는 컨테이너의 스냅샷을 생성, 복원 그리고 리스트를 표시한다. + (역주 : 컨테이너 파일시스템을 대상으로 한다는 점에서 lxc-checkpoint와는 다르다) + + + + 스냅샷은 컨테이너 설정 경로 밑에 스냅샷된 컨테이너처럼 저장된다. + 예를 들어, 만약 컨테이너 설정 경로가 /var/lib/lxc이고 컨테이너 이름이 c1라면, 첫번째 스냅샷은 /var/lib/lxc/c1/snaps 밑에 snap0라는 이름의 컨테이너로 저장 된다. + LXC 1.0 때 사용됬던 /var/lib/lxcsnaps가 존재하는 경우라면, 해당 경로가 계속 쓰이게 된다. + + + + + + <!-- Options -->옵션 + + + + + + + + + 새로 생성되는 스냅샷에 comment_file에 있는 주석을 단다. + + + + + + + + + 지정한 스냅샷을 제거합니다. 스냅샷의 이름이 ALL인 경우, 모든 스냅샷을 제거한다. + + + + + + + + + 존재하는 스냅샷의 리스트를 표시한다. + + + + + + + + + + 스냅샷의 리스트를 표시할때 스냅샷의 주석도 함께 표시한다. + + + + + + + + + + 지정한 스냅샷을 복원한다, 즉, 스냅샷을 복사하여 완전히 새로운 컨테이너가 생성된다는 것을 의미한다. + + + + + + + + + + 스냅샷을 복원할 때, 복원된 컨테이너의 이름을 마지막 인자로 넘길 수 있다. 만약 이름을 넘기지 않았다면, 원본 컨테이너를 제거하고 복원된 컨테이너로 교체한다. 원본 스냅샷을 지우는 것은 aufs, overlayfs, zfs의 경우에는 불가능하다는 것에 주의해야 한다. + + + + + + + + + &commonoptions; + + &seealso; + + + <!-- Author -->저자 + Serge Hallyn serge.hallyn@ubuntu.com + + + + + diff --git a/doc/ko/lxc-start-ephemeral.sgml.in b/doc/ko/lxc-start-ephemeral.sgml.in new file mode 100644 index 000000000..57f8be49f --- /dev/null +++ b/doc/ko/lxc-start-ephemeral.sgml.in @@ -0,0 +1,307 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-start-ephemeral + 1 + + + + lxc-start-ephemeral + + + + 존재하는 컨테이너를 임시 복사본으로 시작 + + + + + + lxc-start-ephemeral + -o + -n + -d + --bdir + --user + --key + --storage-type + --union-type + --keep-data + COMMAND + + + + + <!-- Description -->설명 + + + lxc-start-ephemeral는 존재하는 컨테이너를 임시 복사본으로 시작시킨다. + + + + + <!-- Options -->옵션 + + + + + + + + + 원본 컨테이너 이름 + + + + + + + + + + + + 임시 컨테이너의 이름 (기본값은 무작위한 접미사를 붙이는 것) + + + + + + + + + + + + 컨테이너를 백그라운드로 시작한다. 그리고 이름과 IP를 표시한다. + 옵션으로 명령어를 넘길 경우, 이 옵션은 사용하지 못한다. + + + + + + + + + + + + 컨테이너로 바인드 마운트할 디렉토리. + 여러번 인자로 넘겨줄 수 있다. + + + + + + + + + + + + 컨테이너에 연결할 사용자. + lxc-start-ephemeral로 명령어를 넘길때 사용한다. + + + + + + + + + + + + 컨테이너 안으로 지정한 SSH 공개키를 복사한다. + + + + + + + + + + + + 컨테이너가 사용하는 저장소 형태를 지정한다. 가능한 형태는 tmpfs, dir이다. + + + + + + + + + + + + 지정한 union 파일시스템을 사용한다. + 가능한 파일시스템은 overlayfs, aufs이다. + + + + + + + + + + + + tmpfs 대신 영구적인 백엔드를 사용한다. + 이 옵션을 사용하면, 더이상 임시 컨테이너가 아니기 때문에 lxc-stop이나 lxc-start를 사용할 수 있게 된다. (여전히 오버레이 상태이지만 영구적이다) + + + + + + + + + + + + 지정한 명령어를 컨테이너 안에서 바로 실행한다. + 커널이 attach를 지원하면 attach를 사용하고, 지원하지 않으면 ssh를 사용한다. + 이 옵션은 데몬 모드와 같이 사용할 수 없다. + + + + + + + + <!-- See Also -->참조 + + + + lxc-start + 1 + , + + + + + <!-- Examples -->예제 + + + lxc-start-ephemeral -o p1 + + + + 단순히 임시 복사본 컨테이너를 시작하고, console에 연결한다. + 임시 컨테이너는 컨테이너 p1을 기반으로 한다. + + + + + + lxc-start-ephemeral -o p1 -n p1-ephemeral -d + + + + 컨테이너 p1을 기반으로 임시 컨테이너 p1-ephemeral을 시작한다. + console에 연결하지 않고, 컨테이너의 IP와 이름을 출력한다. + + + + + + + &seealso; + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc-start.sgml.in b/doc/ko/lxc-start.sgml.in new file mode 100644 index 000000000..f50f0bf37 --- /dev/null +++ b/doc/ko/lxc-start.sgml.in @@ -0,0 +1,360 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-start + 1 + + + + lxc-start + + + + 컨테이너 시작(실행) + + + + + + lxc-start + -n name + -f config_file + -c console_device + -L console_logfile + -d + -F + -p pid_file + -s KEY=VAL + -C + --share-[net|ipc|uts] name|pid + command + + + + + <!-- Description -->설명 + + + + lxc-start는 지정된 command를 name이라는 이름의 컨테이너 내에서 실행한다. + (역주 : 컨테이너를 시작한다) + + + + 이 명령어는 lxc-create 정의했던 설정을 토대로 또는 인수를 통해 넘긴 설정파일을 토대로 컨테이너를 세팅한다. + 만약 정의된 설정이 없다면, 기본 고립 환경을 사용한다. + + + + 만약 명령어가 지정되지 않았다면, lxc-start는 lxc.init_cmd에 정의된 명령어를 사용한다. 만약 그마저도 없다면 "/sbin/init"명령어를 사용한다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 컨테이너를 데몬으로 실행한다. + 에러가 발생하더라도 컨테이너가 tty를 가지지 않기 때문에 에러는 표시되지 않는다. + 대신 로그 파일을 에러를 확인하는데 사용할 수 있다. + + + + + + + + + + + + 컨테이너를 포그라운드로 실행한다. 이 모드에서는 컨테이너의 콘솔은 현재 tty에 붙는다. 그리고 시그널들은 컨테이너로 직접 보내지게 된다. + + + + + + + + + + + + 프로세스 ID를 넣은 파일을 생성합니다. + (역주 : systemd의 PIDFile= 옵션 등에 유용하게 사용가능하다) + + + + + + + + + + + + 컨테이너의 가상화나 고립 기능을 설정할 때 쓰일 설정파일을 지정한다. + + + + 지정한 설정파일이 존재한다면, 이전에 생성된(lxc-create를 통해) 컨테 +이너에 설정파일이 이미 존재한다고 하더라도 지정한 설정파일을 사용한다. + + + + + + + + + + + + 컨테이너의 콘솔로 사용할 디바이스를 지정한다. 예를 들어 /dev/tty8과 같이 지정가능하다. 만약 이 옵션이 지정되지 않았고 가 지정되이 않았다면, 현재 터미널이 사용된다. + + + + + + + + + + + + 컨테이너의 콘솔 출력을 기록할 파일을 지정한다. + + + + + + + + + + + + 지정한 설정 변수 KEY에 VAL값을 지정한다. + 이 것은 이전에 config_file에서 지정했던 값들을 덮어쓴다. + + + + + + + + + + + + 상속 받는 파일 디스크립터가 있다면, 전부 닫는다. 만약 이 옵션이 지정되지 않았을 경우 lxc-start는 실패와 함께 종료됩니다. 주의 : --daemon는 --close-all-fds를 포함하고 있다. + + + + + + + + + + + + name 컨테이너 또는 pid로부터 네트워크 네임스페이스를 상속받는다. 네트워크 네임스페이스는 원래 소유자가 계속 관리하게 된다. 시작하는 컨테이너의 네트워크 설정은 무시되고 up/down 스크립트는 실행되지 않는다. + + + + + + + + + + + + name 컨테이너 또는 pid로부터 IPC 네임스페이스를 상속받는다. + + + + + + + + + + + + name 컨테이너 또는 pid로부터 UTS 네임스페이스를 상속받는다. LXC는 시작할 때 호스트이름을 설정하지 않는다. 다만, 컨테이너 OS가 설정할 수 있다. + + + + + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + The container is busy + + + + 지정한 컨테이너가 이미 실행중인 경우이다. 컨테이너를 사용하고 싶다면 + 컨테이너를 중지시켜야 한다. 또는 새로운 컨테이너를 만들 수도 있다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-stop.sgml.in b/doc/ko/lxc-stop.sgml.in new file mode 100644 index 000000000..e50f029d8 --- /dev/null +++ b/doc/ko/lxc-stop.sgml.in @@ -0,0 +1,292 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-stop + 1 + + + + lxc-stop + + + + 컨테이너 종료 + + + + + + lxc-stop + -n name + -W + -r + -t timeout + -k + --nokill + --nolock + + + + + <!-- Description -->설명 + + + + lxc-stop 는 재뷰탕, 종료, 또는 컨테이너 내의 모든 프로세스를 강제종료 시킨다. 기본 동작은 컨테이너에게 lxc.haltsignal 시그널(기본값은 SIGPWR)을 컨테이너 init 프로세스에게 날려, 컨테이너가 종료되게 요청하는 것이다. 60초 동안 컨테이너가 종료되는 것을 기다리고 리턴된다. +만약 컨테이너가 60초안에 종료되지 않는다면 lxc.stopsignal 시그널(기본값은 SIGKILL)을 날려 강제로 종료시킨다. 재부팅 요청시에는 lxc.rebootsignal 시그널(기본값은 SIGINT)를 컨테이너 init 프로세스에게 날린다. + + + + + -W, -r, -s, -k, --nokill 옵션은 어떤 동작을 수행할지 지정한다. + -W는 lxc-stop가 동작 수행후 즉각적으로 종료되게 지정한다. -t TIMEOUT는 동작이 완료되기까지 기다릴 최대 시간을 지정한다. + + + + + + <!-- Options -->옵션 + + + + + + + + + + 컨테이너 재부팅을 요청한다. + + + + + + + + + + + + 컨테이너가 깨끗이 종료되는 것 대신 명시적으로 컨테이너 내의 모든 작업들을 강제종료 시킨다. 이것은 이전 lxc-stop의 동작이다. + + + + + + + + + + + + 깨끗이 종료되도록 요청한다. 만약 종료가 실패하더라도 컨테이너 작업을 강제로 종료시키지 않는다. + + + + + + + + + + + + 이 옵션은 lxc API에서 락킹을 사용하지 않는다. lxc-stop이 잘못된 시스템 상태로 인해, 응답이 없게 되었을 경우에만 사용된다. + + + + + + + + + + + + 동작 수행(재부팅, 종료, 강제종료)을 요청하고 바로 죵료한다. + + + + + + + + + + + + 컨테이너를 강제종료 하기 전에 TIMEOUT 초 만큼 기다린다. + + + + + + + + + <!-- Exit value -->종료 + + + + + 0 + + + + 컨테이너가 성공적으로 종료됬다. + + + + + + 1 + + + + 컨테이너를 종료하던 도중 오류가 발생하였다. + + + + + + 2 + + + + 지정한 컨테이너가 있지만 실행되 있지는 않다. + + + + + + + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 지정한 컨테이너가 lxc-create로 생성된 적이 없다. + 컨테이너가 존재하지 않는다. + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-top.sgml.in b/doc/ko/lxc-top.sgml.in new file mode 100644 index 000000000..7f4357f01 --- /dev/null +++ b/doc/ko/lxc-top.sgml.in @@ -0,0 +1,205 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-top + 1 + + + + lxc-top + + + + 컨테이너의 통계정보 표시 + + + + + + lxc-top + --help + --delay delay + --sort sortby + --reverse + + + + + <!-- Description -->설명 + + + lxc-top는 컨테이너의 통계정보를 표시한다. 출력은 매 delay초마다 갱신된다. + 그리고 sortby로 지정한 항목에 대하여 정렬을 수행한다. lxc-top명령어는 현재 터미널의 크기에 맞게 가능한 많은 컨테이너를 표시한다. 'q'를 누르면 나갈 수 있다. 정렬 항목의 문자를 입력하면 그 항목에 대해 정렬한다. 해당 문자를 두번 입력하면 정렬 순서가 바뀐다. + + + + + <!-- Options -->옵션 + + + + + + + + + + 화면을 갱신하는 시간을 초단위로 지정한다. + 기본값은 3초이다. + + + + + + + + + + + 이름, CPU 사용량, 메모리 사용량에 대해 정렬한다. sortby 인수에는 최소한 한개의 n, c, b, m, k 문자가 있어야 하며, 각각 CPU 사용량, 블록 I/O, 메모리 사용량, 커널 메모리 사용량을 가리킨다. 기본값은 'n'이다. + + + + + + + + + + + 정렬 순서를 바꾼다. 기본 동작은, 이름은 오름차순 알파벳 정렬이고 값은 내림차순 정렬(큰 값이 먼저)이다. + + + + + + + + <!-- Example -->예제 + + + lxc-top --delay 1 --sort m + + + + 컨테이너를 1초마다 갱신하면서, 메모리 사용량으로 정렬해서 표시한다. + + + + + + + + <!-- Notes -->주의 + + + 성능상의 이유로, 커널 메모리 제한이 걸려있지 않다면 커널 메모리 사용량을 집계하지 않는다. + 메모리 제한이 걸려있지 않다면, lxc-top는 커널 메모리 사용량을 0으로 표시한다. 만약 집계되는 컨테이너가 하나도 없다면, KMem 열은 표시되지 않는다. 메모리 제한은 + + lxc.cgroup.memory.kmem.limit_in_bytes = number + + 으로 컨테이너 설정파일에서 지정할 수 있다. + + lxc.conf + 5 + + 를 참고하면 된다. + + + + &seealso; + + + <!-- Author -->저자 + Dwight Engen dwight.engen@oracle.com + + + + + diff --git a/doc/ko/lxc-unfreeze.sgml.in b/doc/ko/lxc-unfreeze.sgml.in new file mode 100644 index 000000000..f78d9abf5 --- /dev/null +++ b/doc/ko/lxc-unfreeze.sgml.in @@ -0,0 +1,125 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-unfreeze + 1 + + + + lxc-unfreeze + + + + 컨테이너의 모든 프로세스를 동결해제 + + + + + + lxc-unfreeze + -n name + + + + + <!-- Description -->설명 + + + + lxc-unfreeze는 이전에 lxc-freeze로 동결 시켰던 모든 프로세스들을 동결해제한다. + + + + + &commonoptions; + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 지정한 컨테이너가 lxc-create로 생성된 적이 없다. + 컨테이너가 존재하지 않는다. + + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-unshare.sgml.in b/doc/ko/lxc-unshare.sgml.in new file mode 100644 index 000000000..1306f1133 --- /dev/null +++ b/doc/ko/lxc-unshare.sgml.in @@ -0,0 +1,285 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-unshare + 1 + + + + lxc-unshare + + + + 새로운 네임스페이스 내에서 태스크 실행 + + + + + + lxc-unshare + -s namespaces + -u user + -H hostname + -i ifname + -d + -M + command + + + + + <!-- Description -->설명 + + + + lxc-unshare는 복제된 네임스페이스 내에서 태스크를 실행한다. + 이 명령어는 주로 테스트 목적으로 사용된다. + 이러한 이름에도 불구하고, 새 네임스페이스에 새로운 태스크를 생성하기 위해 unshare 대신 clone을 사용한다. + 테스트 중인 커널 버전이 낮아지지 않는다면, 별 차이는 없다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 붙일 네임스페이스를 지정한다. + NETWORK|IPC와 같이 파이프(|)로 구분된 리스트를 사용할 수 있다. 허용되는 값은 MOUNT, PID, UTSNAME, IPC, USER , NETWORK이다. 이를 사용하여, 컨테이너의 네트워크 네임스페이스를 사용하면서도 다른 네임스페이스는 호스트의 것을 그대로 사용하는 등의 조작이 가능하다. + + + + + + + + + + + + 새로운 태스크를 실행할 사용자를 지정한다. + + + + + + + + + + + + 새로운 컨테이너의 호스트이름을 지정한다. UTS 네임스페이스가 설정되었을 때만 가능하다. + + + + + + + + + + + + 지정한 이름의 네트워크 인터페이스를 컨테이너 내부로 옮긴다. NETWORK 네임스페이스가 설정되었을 때만 가능하다. 여러개의 인터페이스를 옮기기 위해 여러번 이 인수를 지정하는 것도 가능하다. + + + + + + + + + + + + 데몬화 한다. (컨테이너가 종료되기 전까지 기다리지 않는다) + + + + + + + + + + + + 컨테이너 내부에 (/proc /dev/shm and /dev/mqueue)같은 기본 파일 시스템들을 마운트 한다. MOUNT 네임스페이스가 설정되었을 때만 가능하다. + + + + + + + + + + <!-- Examples -->예제 + + + 자신만의 UTS(hostname) 네임스페이스를 갖는 새로운 쉘을 실행하려면 아래처럼 하면 된다. + + lxc-unshare -s UTSNAME /bin/bash + + 만약, 그 쉘에서 호스트이름이 변경되어도 호스트에는 영향을 끼치지 않는다. + + + + 새로운 네트워크, PID, 마운트 네임스페이스 내에 쉘을 실행하려면, 아래처럼 하면 된다. + + lxc-unshare -s "NETWORK|PID|MOUNT" /bin/bash + + 그 결과 생긴 쉘은 1번 pid를 갖는다. 그리고 네트워크 인터페이스는 없다. + 이 쉘에서 아래처럼 /proc을 다시 마운트하고 + + mount -t proc proc /proc + + ps 명령어를 입력하면, 네임스페이스 내에서 다른 프로세스들은 보이지 않을 것이다. + + + + 새로운 네트워크, PID, 마운트 그리고 호스트 이름(UTS) 네임스페이스 내에 쉘을 실행하려면, 아래처럼 하면 된다. + + lxc-unshare -s "NETWORK|PID|MOUNT|UTSNAME" -M -H slave -i veth1 /bin/bash + + + + 그 결과 생긴 쉘은 1번 pid를 갖는다. 그리고 2개의 네트워크 인터페이스(lo와 veth1)를 갖는다. 호스트 이름은 "slave"이고, /proc은 다시 마운트 된다. + ps 명령어를 입력하면, 네임스페이스 내에서 다른 프로세스들은 보이지 않을 것이다. + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-user-nic.sgml.in b/doc/ko/lxc-user-nic.sgml.in new file mode 100644 index 000000000..fd6edca40 --- /dev/null +++ b/doc/ko/lxc-user-nic.sgml.in @@ -0,0 +1,210 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-user-nic + 1 + + + + lxc-user-nic + + + + NIC 를 생성하여 다른 네임스페이스에 붙이기 + + + + + + lxc-user-nic + pid + type + bridge + nicname + + + + + <!-- Description -->설명 + + + + lxc-user-nic는 root로 setuid한 프로그램이므로, 특권이 없는 사용자들도 lxc 컨테이너가 사용할 네트워크 인터페이스를 생성할 수 있다. + + + + 이 명령어는 @LXC_USERNIC_CONF@을 읽어, 호출한 사용자가 만들수 있는 인터페이스의 수와 어느 브리지에 붙일지를 결정한다. + 각 사용자가 생성한 인터페이스의 수를 @LXC_USERNIC_DB@ 파일에 기록한다. + 그리고 호출한 사용자가 인터페이스를 붙인 네트워크 네임스페이스에 특권을 갖게 한다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 인터페이스가 붙어야하는 네트워크 네임스페이스에 속해있는 프로세스 ID. + + + + + + + + + + + + 붙일 네트워크 인터페이스의 형태. 현재는 veth만 지원가능하다. 이 형태에서는 두개의 인터페이스가 각각 터널의 끝지점으로 생성된다. 하나의 끝지점이 특정 브리지에 붙고, 다른 하나는 컨테이너 내부로 넘겨지게 된다. + + + + + + + + + + + + 네트워크 인터페이스를 붙일 프리지. 예를 들어, lxcbr0 같이 지정 가능하다. + + + + + + + + + + + + 컨테이너내에서 사용할 인터페이스 이름. 지정하지 않는다면 eth0로 된다. + + + + + + + + + &commonoptions; + + + <!-- See Also -->참조 + + + + lxc + 1 + , + + + lxc-start + 1 + , + + + lxc-usernet + 5 + + + + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-usernet.sgml.in b/doc/ko/lxc-usernet.sgml.in new file mode 100644 index 000000000..f64fb7ebc --- /dev/null +++ b/doc/ko/lxc-usernet.sgml.in @@ -0,0 +1,188 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-usernet + 5 + + + + lxc-usernet + + + + 비특권 사용자의 네트워크 관리용 설정파일 + + + + + <!-- Description -->설명 + + + + @LXC_USERNIC_CONF@로 비특권 사용자가 lxc-user-nic 명령어로 네트워크 인터페이스를 만들 때, 제한을 걸 수 있다. + + + + <!-- Configuration -->설정 + + + 이 파일은 아래와 같은 형식의 한 줄로 이루어진 여러 항목들로 구성되어 있다. + + + + user type bridge number + + + + 여기서 각 항목들은 다음과 같은 의미를 가진다. + + + + + + + + + + + + 이 항목이 적용될 사용자 이름을 가리킨다. + + + + + + + + + + + + 허용되는 네트워크 인터페이스 형태를 가리킨다. veth만 지원된다. + + + + + + + + + + + + 네트워크 인터페이스들을 붙일 브리지를 가리킨다. + 예를 들어 lxcbr0로 지정 가능하다. + + + + + + + + + + + + 지정된 사용자가 지정된 브리지에 붙일 지정된 형태의 네트워크 인터페이스 개수를 가리킨다. + 예를 들어 2로 지정 가능하다. + + + + + + + + + + <!-- See Also -->참조 + + + lxc + 1 + , + + lxc-user-nic + 1 + + + + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc-usernsexec.sgml.in b/doc/ko/lxc-usernsexec.sgml.in new file mode 100644 index 000000000..9568f14e9 --- /dev/null +++ b/doc/ko/lxc-usernsexec.sgml.in @@ -0,0 +1,193 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-usernsexec + 1 + + + + lxc-usernsexec + + + + 새로운 사용자 네임스페이스에서 root로 태스크를 실행 + + + + + + lxc-usernsexec + -m uid-map + -- command + + + + + <!-- Description -->설명 + + + + lxc-usernsexec는 새로운 사용자 네임스페이스에서 루트로 태스크를 실행한다. + + + + + + + <!-- Options -->옵션 + + + + + + + + + + + 사용자 네임스페이스에서 사용될 uid 맵. 각각의 맵은 4개의 콜론(:)으로 구분된 값들로 구성되어 있다. 첫 번째는 'u', 'g', 'b' 문자로 각각 UID, GID, 또는 UID 및 GID 를 가리킨다. 그 다음은 사용자 네임스페이스 내에서의 UID, 그다음은 호스트의 UID, 그리고 마지막으로 매핑할 ID의 수를 지정한다. + + + + 맵은 1개 이상도 지정가능하다. 만약 맵이 지정되지 않았다면, 기본값은 /etc/subuid와 /etc/subgid에서 허용된 모든 범위의 uid, gid가 컨테이너 내에서 0번부터 매핑된다. + + + + lxc-usernsexec는 언제나 0번 setuid와 setgid를 시도한 다는 것에 주의해야 한다. 그러므로 네임스페이스 내에서 uid 0은 매핑이 되어있어야 한다. + + + + + + + + + + + <!-- Examples -->예제 + + + 할당된 모든 subuid를 컨테이너에 매핑해서 쉘을 실행하려면, + + lxc-usernsexec + + 를 사용하면 된다. + /bin/sh대신 다른 쉘을 실행하려면, + + lxc-usernsexec -- /bin/bash + + 를 사용하면 된다. + + + + 만약 현재 UID가 1000이고, 컨테이너의 root가 190000으로 매핑되어 있으며, 현재 사용자가 소유하고 있는 파일을 컨테이너의 root가 소유하도록 하려면, 아래처럼 하면 된다. + + lxc-usernsexec -m b:0:1000:1 -m b:1:190000:1 -- /bin/chown 1:1 $file + + 이것은 현재 UID를 사용자 네임스페이스 내에서 root로 하고, 190000을 uid 1로 매핑한다. + 사용자 네임스페이스의 root는 네임스페이스의 모든 UID에 권한이 있기 때문에, 호스트에서 chown을 사용할 수 없더라도 파일의 소유자를 변경할 수 있다. + + + + &seealso; + + + <!-- Author -->저자 + Serge Hallyn serge.hallyn@ubuntu.com + + + + + diff --git a/doc/ko/lxc-wait.sgml.in b/doc/ko/lxc-wait.sgml.in new file mode 100644 index 000000000..e780270c2 --- /dev/null +++ b/doc/ko/lxc-wait.sgml.in @@ -0,0 +1,192 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc-wait + 1 + + + + lxc-wait + + + + 지정한 컨테이너 상태로 변할 때까지 대기 + + + + + + lxc-wait + -n name + -s states + + + + + <!-- Description -->설명 + + + lxc-wait는 컨테이너가 지정한 상태로 변할때 까지 대기한다. 이는 스크립트를 위해 유용하다. + + + + + <!-- Options -->옵션 + + + + + + + + + + 기다릴 컨테이너 상태를 지정한다. + 컨테이너 상태들은 OR 기호를 사용하여 여러개를 지정 가능하다. + + + + + + + + + + + + 원하는 상태로 변할 때까지 대기할 최대시간을 timeout 초로 지정한다. + + + + + + + + + &commonoptions; + + + <!-- Examples -->예제 + + + lxc-wait -n foo -s RUNNING + + + + foo 컨테이너의 상태가 'RUNNING'일 때까지 대기한다. + + + + + + lxc-wait -n foo -s 'RUNNING|STOPPED' + + + + foo 컨테이너의 상태가 'RUNNING' 또는 'STOPPED'으로 변할때까지 대기한다. + + + + + + + + + <!-- Diagnostic -->진단 + + + + + The container was not found + + + + 지정한 컨테이너가 lxc-create로 생성된 적이 없다. + 컨테이너가 존재하지 않는다. + + + + + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc.conf.sgml.in b/doc/ko/lxc.conf.sgml.in new file mode 100644 index 000000000..21a4fb7ae --- /dev/null +++ b/doc/ko/lxc.conf.sgml.in @@ -0,0 +1,193 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc.conf + 5 + + + + lxc.conf + + + + LXC 설정파일 + + + + + <!-- Description -->설명 + + + + LXC 설정파일은 컨테이너 설정과 시스템 설정의 2부분으로 나뉜다. + + + + <!-- Container configuration -->컨테이너 설정 + + + 컨테이너 설정은 컨테이너 디렉토리의 config로 설정한다. + + + + + 기본 설정은 컨테이너 생성 시간에 템플릿이 제공해 주는 설정과 default.conf 파일에 있는 추가 설정들로 생성된다. + + + + + default.conf 파일은 @LXC_DEFAULT_CONFIG@에 위치하고 있다. + 비특권 컨테이너의 경우에는 ~/.config/lxc/default.conf에 위치하고 있다. + + + + + 이 파일의 자세한 사용법은 아래를 참고하면 된다. + + lxc.container.conf + 5 + + + + + + <!-- System configuration -->시스템 설정 + + + 시스템 설정은 @LXC_GLOBAL_CONF@에 위치하고 있다. 비특권 컨테이너의 경우는 ~/.config/lxc/lxc.conf에 위치하고 있다. + + + + + 이 설정파일은 LXC 기본 경로 및 저장소 백엔드 설정과 같은 값들을 설정할 때 사용한다. + + + + + 이 파일의 자세한 사용법은 아래를 참고하면 된다. + + lxc.system.conf + 5 + + + + + + + <!-- See Also -->참조 + + + lxc + 1 + , + + lxc.container.conf + 5 + , + + lxc.system.conf + 5 + , + + lxc-usernet + 5 + + + + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/lxc.container.conf.sgml.in b/doc/ko/lxc.container.conf.sgml.in new file mode 100644 index 000000000..1781d330b --- /dev/null +++ b/doc/ko/lxc.container.conf.sgml.in @@ -0,0 +1,2399 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc.container.conf + 5 + + + + lxc.container.conf + + + + LXC 컨테이너 설정파일 + + + + + <!-- Description -->설명 + + + + linux 컨테이너(lxc)는 항상 사용하기 전에 생성된다. + 생성 작업은 가상화할 자원 및 컨테이너 내에서 실행되는 프로세스로부터 고립할 시스템 자원들을 정의하는 것이다. + 기본적으로 pid, sysv ipc, 마운트 포인트가 가상화되고 고립된다. 명시적으로 설정파일에서 정의되기 전까지, 다른 시스템 자원들은 컨테이너 간에 공유된다. 예를 들어, 네트워크 설정이 되어 있지 않다면, 컨테이너 생성한 쪽과 컨테이너 간에 네트워크를 서로 공유할 것이다. 그러나 네트워크가 지정이되었다면, 컨테이너를 위해 새로운 네트워크 스택이 생성된다. 그리고 컨테이너는 더이상 그를 생성한 쪽과 네트워크를 공유하지 않는다. + + + + + 설정파일은 컨테이너에 할당될 시스템 자원들을 정의한다. 현재는 utsname, 네트워크, 마운트포인트, 루트 파일시스템, 사용자 네임스페이스 그리고 컨트롤 그룹이 지원된다. + + + + + 설정파일의 옵션은 key = value의 한 줄로 이루어져 있다. + '#' 문자를 앞에 붙여 주석임을 나타낼 수 있다. + + + + <!-- Configuration -->설정 + + + 연관된 컨테이너들을 쉽게 관리하기 위해서, 컨테이너 설정파일은 다른 파일을 불러올 수 있다. 예를 들어서, 네트워크 설정은 여러 컨테이너들을 위해 공통된 하나의 파일로 정의될 수 있다. 그리고 만약 컨테이너들이 다른 호스트로 이동된다면, 해당 파일 하나만 수정하면 된다. + + + + + + + + + + + include할 파일을 지정한다. + include할 파일은 lxc 설정파일의 형식에 부합하여야 한다. + + + + + + + + <!-- Architecture -->아키텍처 + + + 컨테이너에 아키텍처를 지정할 수 있다. 예를 들어, 64비트 호스트에서 32비트 바이너리를 실행하는 컨테이너라면 32비트 아키텍처로 지정할 수 있다. 패키지를 다운로드 받는 등의 작업을 수행하는 아키텍처에 의존적인 컨테이너 스크립트가 잘 동작할 수 있도록 해준다. + + + + + + + + + + + 컨테이너의 아키텍처를 지정한다. + + + + 가능한 옵션은 아래와 같다. + , + , + , + + + + + + + + + + <!-- Hostname -->호스트 이름 + + + utsname 섹션은 컨테이너 내에서 설정할 호스트 이름을 정의한다. 컨테이너는 시스템의 호스트 이름을 변경하지 않고도 자신의 호스트 이름을 변경할 수 있다. 즉, 컨테이너마다 호스트 이름을 설정할 수 있다. + + + + + + + + + + 컨테이너의 호스트 이름을 지정한다. + + + + + + + + <!-- Halt signal -->종료 시그널 + + + lxc-stop이 컨테이너를 깨끗이 종료를 시키기 위해서 보낼 시그널의 이름이나 숫자를 지정할 수 있다. + init 시스템마다 깨끗한 종료를 위해 각기 다른 시그널을 사용할 수 있다. + 이 옵션은 kill(1)에서 사용하는 것 처럼 시그널을 지정할 수 있다. 예를 들어 SIGPWR, SIGRTMIN+14, SIGRTMAX-10 또는 숫자를 지정할 수 있다. 기본 시그널은 SIGPWR이다. + + + + + + + + + + 컨테이너를 종료할 때 사용할 시그널을 지정한다. + + + + + + + + <!-- Reboot signal -->재부팅 시그널 + + + lxc-stop이 컨테이너를 재부팅하기 위해 보낼 시그널의 이름이나 숫자를 지정할 수 있다. + 이 옵션은 kill(1)에서 사용하는 것 처럼 시그널을 지정할 수 있다. 예를 들어 SIGINT, SIGRTMIN+14, SIGRTMAX-10 또는 숫자를 지정할 수 있다. 기본 시그널은 SIGINT이다. + + + + + + + + + + 컨테이너를 재부팅할 때 사용할 시그널을 지정한다. + + + + + + + + <!-- Stop signal -->강제종료 시그널 + + + lxc-stop이 컨테이너를 강제종료하기 위해 보낼 시그널의 이름이나 숫자를 지정할 수 있다. + 이 옵션은 kill(1)에서 사용하는 것 처럼 시그널을 지정할 수 있다. 예를 들>어 SIGKILL, SIGRTMIN+14, SIGRTMAX-10 또는 숫자를 지정할 수 있다. 기본 시그널은 SIGKILL이다. + + + + + + + + + + 컨테이너를 강제종료할 때 사용할 시그널을 지정한다. + + + + + + + + <!-- Init command -->Init 명령어 + + + 컨테이너의 init으로 사용할 명령어를 설정한다. + 이 옵션은 lxc-execute을 사용할 때는 무시된다. + 기본값은 /sbin/init이다. + + + + + + + + + + init으로 사용할 바이저리의 컨테이너 루트 파일시스템에서의 절대 경로. + + + + + + + + <!-- Network -->네트워크 + + + 네트워크 섹션은 어떻게 네트워크를 컨테이너 내에서 가상화할지를 정의한다. + 네트워크 가상화는 2개의 계층으로 동작한다. + 네트워크 가상화를 위해서, 컨테이너의 네트워크 인터페이스가 인수로 지정되어야 한다. 시스템이 하나의 물리적인 네트워크 인터페이스를 갖고 있어도, 컨테이너 내에서 여러개의 가상화 인터페이스들을 사용할 수 있다. + + + + + + + + + + 컨테이너가 어떤 종류의 네트워크 가상화를 사용할지 지정한다. + 필드부터 새로운 네트워크 설정이 시작된다. 이 방법으로 여러개의 네트워크 가상화 형태를 같은 컨테이너에 지정할 수 있다. 그리고 여러개의 네트워크 인터페이스를 하나의 컨테이너에 지정할 수도 있다. + 지정 가능한 형태는 아래와 같다. + + + + + 호스트의 네트워크 네임스페이스를 공유한다. 이렇게 하면 호스트의 네트워크 장치를 컨테이너 내에서 사용가능하다. + 컨테이너와 호스트 둘다 init에서 upstart를 사용하는 경우, (예를 들어) 컨테이너에서 'halt'를 하면, 호스트의 것도 종료된다. + + + + + 는 루프백 인터페이스만 생성한다. + + + + + 한 쪽은 컨테이너로, 다른 한쪽은 옵션으로 지정한 브리지로 붙은 가상 이더넷(veth) 장치 쌍을 생성한다. + 만약 브리지가 지정되지 않았다면, 어떤 브리지에도 붙지 않은 veth 장치 쌍을 만든다. 브리지는 컨테이너 시작전에 시스템에서 생성해야 한다. + lxc는 컨테이너 이외의 설정에 대해서는 다루지 않는다. 기본값으로 lxc는 컨테이너 바깥에 속할 네트워크 디바이스의 이름을 정해준다. 이름을 변경하기 원한다면, lxc가 지정한 이름으로 설정하도록 옵션을 사용하여야 한다. (비특권 컨테이너는 불가능하다. 이 옵션은 보안상의 이유로 무시될 것이다) + + + + + vlan 인터페이스는 로 지정한 인터페이스에 연결되고, 컨테이너로 할당된다. vlan의 식별자는 옵션으로 지정한다. + + + + + macvlan 인터페이스는 로 지정한 인터페이스에 연결되고, 컨테이너로 할당된다. + 은 같은 상위 디바이스에 있는 다른 macvlan과 통신할 때 사용하는 모드를 지정한다. + 지정할 수 있는 모드는 、、、이다. + 모드는 디바이스가 같은 상위디바이스의 어떤 장치와도 통신하지 않는다. (기본값) + 새로운 가상 이더넷 포트 통합모드(Virtual Ethernet Port Aggregator), 즉 모드는 인접한 브리지가 소스와 목적지가 로컬인 모든 프레임들을 macvlan 포트로 반환한다고 가정한다. 즉, 브리지가 reflective relay로 설정되어 있다는 것이다. + 상위장치에서 들어오는 브로드캐스트 프레임들은 모든 macvlan 인터페이스에게 보내져버린다. 로컬 프레임들은 로컬로 보내지지 않는다. + 모드는 같은 포트의 다른 macvlan 인터페이스 사이에 간단한 브리지를 제공한다. + 어떤 인터페이스에서 다른 인터페이스로 프레임은 직접 전달된다. 하지만 외부로는 보내지지 않는다. + 브로드캐스트 프레임들은 모든 다른 브리지 포트들과 외부 인터페이스에 전달된다. + 그러나 reflective relay로 다시 돌아왔을 때는, 그것들을 다시 전송하지 않는다. + 모든 MAC 주소를 알기 때문에, macvlan 브리지모드는 브리지 모듈처럼 학습이나 STP를 요구하지 않는다. + 모드는 물리 인터페이스로 부터 받은 모든 프레임들을 macvlan 인터페이스로 포워딩한다. + 모드만이 하나의 물리 인터페이스를 설정하는게 가능하다. + + + + + 로 지정한 이미 존재하는 인터페이스를 컨테이너로 할당된다. + + + + + + + + + + + + 네트워크에 수행할 작업을 지정한다. + + + + + 인터페이스를 활성화시킨다. + + + + + + + + + + + + 실제 네트워크 트래픽에 사용할 인터페이스를 지정한다. + + + + + + + + + + + + 해당 인터페이스의 최대 전송 단위(MTU)를 지정한다. + + + + + + + + + + + + 인터페이스 이름은 동적으로 할당된다. + 그러나, 컨테이너가 일반적으로 사용하는 이름과 다른 이름이 필요하다면, (예: eth0) 이 옵션은 컨테이너 내에 있는 인터페이스의 이름을 지정한 것으로 변경할 수 있다. + + + + + + + + + + + + 가상 인터페이스의 MAC 주소는 기본적으로 동적 할당된다. 그러나 몇몇가지 이유로 MAC 주소 충돌 문제를 해결하거나, 언제나 같은 링크 로컬 IPv6 주소가 필요하다면, 이 옵션이 필요하다. + 주소의 "x"는 무작위한 값으로 바뀐다. 템플릿에서 하드웨어 주소를 설정하는데 유용하다. + + + + + + + + + + + + 가상 인터페이스에서 사용할 IPv4 주소를 지정한다. + 여러 행으로 여러개의 IPv4 주소를 지정할 수 있다. + 주소의 형식은 x.y.z.t/m으로, 예를 들어 192.168.1.123/24이다. 브로드 캐스트 주소는 같은 행의 주소 바로 오른쪽에 지정하면 된다. + + + + + + + + + + + + 컨테이너 내부에서 게이트웨이로 사용할 IPv4 주소를 지정한다. + 주소 형식은 x.y.z.t로, 예를 들면 192.168.1.123이다. + + 라는 특별한 값을 지정할 수있다. + 이것은 ( 에서 지정된) 브리지 인터페이스의 첫번째 주소를 가져와 게이트 주소로 사용한다. + 는 네트워크 형태가 나 일 때만 지정 가능하다. + + + + + + + + + + + + + 가상 인터페이스에서 사용할 IPv6 주소를 지정한다. + 여러 행으로 여러개의 IPv6 주소를 지정할 수 있다. + 주소의 형식은 x::y/m으로, 예를 들어 2003:db8:1:0:214:1234:fe0b:3596/64이다. + + + + + + + + + + + + 컨테이너 내부에서 게이트웨이로 사용할 IPv4 주소를 지정한다. + 주소 형식은 x::y로, 예를 들면 2003:db8:1:0::1이다. + + 라는 특별한 값을 지정할 수있다. + 이것은 ( 에서 지정된) 브리지 인터페이스의 첫번째 주소를 가져와 게이트 주소로 사용한다. +는 네트워크 형태가 나 일 때만 지정 가능하다. + + + + + + + + + + + + 네트워크를 설정하고 생성한 후에 호스트 쪽에서 실행되는 스크립트를 지정한다. + 다음 인수들이 스크립트에 넘겨진다 : 컨테이너 이름, 설정 섹션 이름(net). 그 후 인수는 훅 스크립트을 사용하는 설정 섹션에 달려있다. 다음 인수들은 네트워크 시스템에 의해 사용되어진다 : 실행 컨텍스트(up), 네트워크 형태(empty/veth/macvlan/phys). 네트워크 형태에 따라서 다음 인수들이 넘겨진다 : veth/macvlan/phys의 경우, (호스트 쪽의) 장치 이름. + + + + 스크립트의 표준출력은 debug 수준 로그로 납겨진다. + 표준 에러는 로그로 남겨지지는 않지만, 표준 에러를 표준 출력으로 리다이렉션하여 로그로 남길 수 있다. + + + + + + + + + + + + 네트워크를 제거한 후에 호스트 쪽에서 실행되는 스크립트를 지정한다. + 다음 인수들이 스크립트에 넘겨진다 : 컨테이너 이름, 설정 섹션 이름(net). 그 후 인수는 훅 스크립트을 사용하는 설정 섹션에 달려있다. + 다음 인수들은 네트워크 시스템에 의해 사용되어진다 : 실행 컨텍스트(down), 네트워크 형태(empty/veth/macvlan/phys). 네트워크 형태에 따라서 다음 인수들이 넘겨진다 : veth/macvlan/phys의 경우, (호스트 쪽의) 장치 이름. + + + + 스크립트의 표준출력은 debug 수준 로그로 납겨진다. + 표준 에러는 로그로 남겨지지는 않지만, 표준 에러를 표준 출력으로 리다이렉션하여 로그로 남길 수 있다. + + + + + + + + + <!-- New pseudo tty instance (devpts) -->새로운 pseudo tty 인스턴스(devpts) + + + 강한 고립을 위해 컨테이너는 자기자신만의 pseudo tty를 가질 수 있다. + + + + + + + + + + 만약 지정되었다면, 컨테이너는 새 pseudo tty 인스턴스를 갖는다. 그리고 이것을 자기자신 전용으로 만든다. 지정하는 값은 pseudo tty의 최대 개수를 지정한다. (이 제한은 아직 구현되지 않았다) + + + + + + + + <!-- Container system console -->컨테이너 시스템 콘솔 + + + 컨테이너에 루트 파일시스템이 설정되어 있고 inittab 파일에 콘솔을 사용하는 것이 설정되어 있다면, 콘솔의 출력을 어디로 할지 지정할 수 있다. + + + + + + + + + + 콘솔의 출력을 쓸 파일의 경로를 지정한다. + + + + + + + + + + + 콘솔을 붙일 장치의 경로를 지정한다. + 'none'이라는 값은 단순히 콘솔을 비활성화 시킨다. 만약 응용 프로그램이 쓸 수 있는 콘솔 장치 파일이 루트 파일시스템에 있으면, 메시지가 호스트 쪽에 출력되므로 이 설정은 위험할 수 있다. + + + + + + + + <!-- Console through the ttys -->tty를 통한 콘솔 + + + 컨테이너에 루트 파일시스템이 설정되어 있고 inittab 파일에 tty에서 getty를 실행하는 것이 설정되어 있다면, 이 옵션은 유용하다. + 이 옵션은 컨테이너에서 사용가능한 tty의 개수를 지정한다. + 컨테이너의 inittab 파일에 설정된 getty의 개수는 이 옵션에서 정한 tty의 개수보다 크면 안된다. 그렇지 않으면 초과된 getty 세션은 무한히 죽고 다시 살아나기를 반복하며 콘솔이나 /var/log/messages에 계속 메시지를 띄울 것이다. + + + + + + + + + + 컨테이너가 만들 수 있는 tty의 개수를 지정한다. + + + + + + + + <!-- Console devices location -->콘솔 장치 위치 + + + LXC 콘솔은 호스트에서 생성된 Unix98 PTY와 컨테이너 내에 바인드 마운트될 장치들을 통해 제공된다. 기본적으로 /dev/console와 /dev/ttyN를 바인드 마운트 한다. 이것은 게스트에서 패키지 업그레이드를 방해하는 요인이 된다. 그래서 /dev 밑에 LXC가 파일을 생성하고 바인드 마운트할 디렉토리의 위치를 따로 지정해 줄 수 있다. + 그리고 만들어진 파일들은 /dev/console와 /dev/ttyN에 심볼릭 링크된다. + 심볼릭 링크들은 삭제하거나 대체하는 것이 가능하므로 패키지 업그레이드는 성공적으로 이루어질 수 있다. + + + + + + + + + + 컨테이너 콘솔 장치를 생성할 /dev 밑의 디렉토리를 지정한다. + + + + + + + + <!-- /dev directory -->/dev 디렉토리 + + + 기본적으로 lxc는 약간의 심볼릭 링크(fd, stdin, stdout, stderr)를 컨테이너의 /dev 디렉토리에 생성한다. 그러나 자동으로 장치 노드 항목들을 생성해주지 않는다. 컨테이너의 루트 파일시스템에서 필요로하는 /dev를 생성할 수 있게 하는 것이다. lxc.autodev가 1로 지정되었다면, 컨테이너 루트 파일시스템을 마운트 한 후, LXC가 /dev 밑에 새로운 tmpfs(최대 100k)를 마운트 해준다. 그리고 최소한의 장치만을 채워준다. + 이것은 "systemd" 기반의 "init" 환경의 컨테이너를 시작할 때 일반적으로 필요하지만, 다른 환경의 경우는 선택적인 요소이다. + 컨테이너의 부가적인 장치들은 훅 스크립트를 사용하여 /dev 디렉토리에 생성할 수 있다. + + + + + + + + + + 컨테이너 시작시 /dev을 마운트하고 최소한으로 /dev를 구성할지 지정한다. 0이면 해당 동작을 수행하지 않는다. + + + + + + + + <!-- Enable kmsg symlink -->kmsg 심볼릭링크 사용 + + + /dev/console에 대한 심볼릭 링크로 /dev/kmsg를 생성한다. + + + + + + + + + + 이것을 1로 지정하면 /dev/kmsg 심볼릭링크를 사용한다. + + + + + + + + <!-- Mount points -->마운트 포인트 + + + 마운트 포인트 섹션은 마운트가 될 각각의 장소를 지정한다. + 이 마운트 포인트들은 컨테이너에서만 보이고 외부에서 실행하는 프로세스들에겐 보이지 않는다. + 이는 예를 들어 /etc, /var, /home을 마운트할 때 유용하다. + + + + + + + + + + 마운트 정보를 담은 fstab 형식으로 된 파일의 위치를 지정한다. + 이 마운트 대상 위치들은 대부분 상대경로로 되어 있으며, 이는 마운트된 컨테이너 루트에서의 상대경로를 의미한다. + + +proc proc proc nodev,noexec,nosuid 0 0 + + + + 위의 예는 proc 파일시스템을 컨테이너 루트 파일시스템의 위치와 상관없이 컨테이너의 /proc에 마운트시키는 예제이다. 이는 백엔드 파일시스템 블록 장치뿐만 아니라 컨테이너의 복제에도 유연하게 대처할 수 있다. + + + + 이미지 파일이나 블록 장치에서 마운트된 파일시스템의 경우, 3번째 필드 (fs_vfstype)는 + + mount + 8 + + 와 같이 auto를 지정할수 없으며, 명시적으로 지정해야 한다. + + + + + + + + + + + + fstab의 형식으로, 한 줄당 마운트 포인트 하나를 지정한다. + + + + + + + + + + + + 일반적인 커널의 파일시스템을 자동으로 마운트할지 지정한다. + 이 옵션을 사용하면 설정을 매우 편하게 할 수 있다. + 사용할 수 있는 파일시스템들은 아래와 같다. + + + + + + (or ): + /proc 을 읽기/쓰기 가능으로 마운트, 그러나 /proc/sys과 /proc/sysrq-trigger는 읽기 전용으로 다시 마운트 (보안상의 이유 및 컨테이너 고립을 위해) + + + + + + : + /proc 전체를 읽기/쓰기 가능으로 마운트 + + + + + + (or ): + /sys/devices/virtual/net는 쓰기 가능으로, /sys는 읽기 전용으로 마운트. + + + + + + : + /sys를 읽기 전용으로 마운트 (보안상의 이유 및 컨테이너 고립을 위해) + + + + + + : + /sys를 읽기/쓰기 가능으로 마운트 + + + + + + : + /sys/fs/cgroup를 tmpfs로 마운트. + 컨테이너가 추가될 모든 계층의 디렉토리 생성. + cgroup 이름의 하위 디렉토리 생성. + 컨테이너 자신의 cgroup을 해당 디렉토리에 마운트. + 컨테이너는 자신의 cgroup 디렉토리에는 쓰기가 가능하지만 부모의 디렉토리는 읽기전용으로 마운트 하므로 쓰기가 불가능하다. + + + + + + : + 와 유사, 단, 전부 읽기 전용으로 마운트 + + + + + + : + 와 유사, 단, 전부 읽기/쓰기 가능으로 마운트. + 컨테이너 자신의 cgroup에 이르기까지의 경로가 모두 쓰기 가능이 되지만, cgroup 파일시스템이 아닌 /sys/fs/cgroup의 tmpfs의 일부로써 존재하게 되는 것에 주의해야 한다. + + + + + + (별다른 옵션 없이): + 컨테이너가 CAP_SYS_ADMIN capability를 유지하고 있는 경우 을 기본으로 사용한다. 그렇지 않다면 를 사용한다. + + + + + + : + /sys/fs/cgroup을 tmpfs로 마운트. + 컨테이너가 추가될 모든 계층의 디렉토리 생성. + 호스트의 디렉토리들을 컨테이너로 바인드 마운트하고 컨테이너 자신의 cgroup을 제외한 모든 디렉토리는 읽기 전용으로 변경. + 비교하자면, 의 경우에는 컨테이너 자신의 cgroup에 이르기까지 모든 경로는 단순하게 tmpfs 아래에 있는 디렉토리에 불과하다. 하지만, 여기서는 비록 컨테이너 자신의 cgroup 이외에는 모두 읽기 전용이긴 하나 /sys/fs/cgroup/$hierarchy이 호스트의 모든 cgroup 계층구조를 포함하고 있다. + 이는 컨테이너에게 너무 많은 정보를 노출시킬 수 있다. + + + + + + : + 와 유사, 단, 전부 읽기 전용으로 마운트 + + + + + + : + 와 유사, 단, 전부 읽기/쓰기 가능으로 마운트. + 이 경우는 컨테이너가 자기자신의 cgroup을 벗어날 수 있다. (만약 컨테이너가 CAP_SYS_ADMIN을 갖고 있다면, cgroup 파일시스템 자체를 마운트할 수 있음을 주의해야 한다. 이렇게 하면 같은 결과를 가져올 수 있다) + + + + + + (별다른 옵션 없이): + 컨테이너가 CAP_SYS_ADMIN capability를 유지하고 있는 경우 을 기본으로 사용한다. 그렇지 않다면 를 사용한다. + + + + + + cgroup 파일시스템이 자동으로 마운트되는게 활성화되어 있다면, /sys/fs/cgroup 밑의 tmpfs는 언제나 읽기/쓰기 가능으로 마운트 된다.(단, 과 의 경우에는 각각 계층 /sys/fs/cgroup/$hierarchy이 읽기전용이 될 수는 있다) + 아래의 Ubuntu 명령어에 대응하기 위함이다. + + mountall + 8 + + 해당 명령어는 컨테이너 부팅시에 /sys/fs/cgroup가 읽기전용으로 마운트되어 있고, 컨테이너가 CAP_SYS_ADMIN을 갖고 있지 않아 이를 읽기/쓰기 전용으로 다시 마운트 못할 경우, 부팅시에 사용자의 입력을 기다리게 만들기 때문이다. + + + + 예제: + + + lxc.mount.auto = proc sys cgroup + lxc.mount.auto = proc:rw sys:rw cgroup-full:rw + + + + + + + + + <!-- Root file system -->루트 파일시스템 + + + 컨테이너의 루트 파일시스템은 호스트 시스템과 다르게 구성할 수 있다. + + + + + + + + + + 컨테이너의 루트 파일시스템을 지정한다. 이미지 파일 또는 블록 장치의 디렉토리가 될 수도 있다. 만약 지정되지 않으면 컨테이너는 자신의 루트 파일시스템을 호스트와 공유한다. + + + + 디렉토리 또는 간단한 블록 장치로 구성된 컨테이너를 위해서 경로이름이 사용될 수 있다. 만약 루트 파일시스템이 nbd 장치의 경우, nbd:file:1는 file을 nbd 장치로 사용하고 1번 파티션이 루트 파일시스템으로 마운트되도록 지정한다. + nbd:file는 nbd 장치 자체가 마운트되어야 한다고 지정한다. + overlayfs:/lower:/upper는 루트 파일시스템이 읽기전용으로 마운트된 /lower를 /upper가 읽기/쓰기 가능으로 오버레이 마운트되도록 지정한다. + aufs:/lower:/upper는 aufs에서 위와같이 지정한다. + loop:/file는 lxc가 /file을 loop 장치로 사용하고 loop 장치를 마운트하도록 지정한다. + + + + + + + + + + + + 루트파일시스템을 변경하기 전에, 을 어디에 재귀적으로 바인드할지 정한다. 이는 다음 시스템콜의 성공을 보장한다. + + pivot_root + 8 + + 어떤 디렉토리도 좋으며, 기본값으로도 보통 동작할 것이다. + + + + + + + + + + + + 루트 파일시스템을 마운트 할때 사용할 부가적인 마운트 옵션. + + + + + + + + + <!-- Control group -->컨트롤 그룹 + + + 컨트롤 그룹 섹션은 (lxc와는) 다른 서브시스템의 설정을 포함한다. + lxc는 서브시스템의 이름을 정확히 체크하지 않는다. + 이는 컨테이너를 시작할 때까지는 설정 상의 에러를 잡아내기 힘들게 한다. + 그러나 다른 차후에 들어올 수 있는 서브시스템을 지원할 수 있는 장점도 있다. + + + + + + + + + + 지정한 컨트롤 그룹의 값을 지정한다. + 서브시스템의 이름은 컨트롤 그룹에서의 이름이다. + 사용가능한 이름이나 값의 문법에 대해서는 LXC에서 따로 신경쓰지 않으며, 컨테이너가 시작하는 시점에 리눅스 커널이 해당 기능을 지원하는지에 달려있다. + 예를 들면 이다. + + + + + + + + Capabilities + + + 컨테이너가 root로 실행된다면, 컨테이너 내에서 capability를 제거할 수 있다. + + + + + + + + + + 컨테이너에서 제거할 capability를 지정한다. + 한 줄에 여러개의 capability를 공백(space)으로 구분하여 정의할 수 있다. + 형식은 capability 정의에서 "CAP_" 접두사를 빼고 소문자로 작성하는 것이다. 예를들어 CAP_SYS_MODULE의 경우는 sys_module이다. + 아래를 참조할 수 있다. + + capabilities + 7 + + + + + + + + + + + + 컨테이너에서 유지할 capability를 지정한다. + 다른 capability는 모두 제거될 것이다. "none"이라는 값을 지정하면, lxc는 해당 시점에서 갖고 있던 모든 capability를 제거한다. + 모든 capability를 제거하기 위해서는 "none" 하나만 사용하면 된다. + + + + + + + + <!-- Apparmor profile -->Apparmor 프로파일 + + + lxc가 apparmor를 지원하도록 컴파일된 후 설치되었고, 호스트 시스템에서 apparmor가 활성화되었다면, 컨테이너에서 따라야할 apparmor 프로파일을 컨테이너 설정에서 지정할 수 있다. 기본값은 lxc-container-default이다. + + + + + + + + + + 컨테이너가 따라야할 apparmor 프로파일을 지정한다. + 컨테이너가 apparmor로 인한 제한을 받지 않도록 하려면, 아래와 같이 지정하면 된다. + + lxc.aa_profile = unconfined + + + + + + + + + + apparmor 프로파일은 경로이름 기반이므로, 공격자로부터 효과적으로 파일 제한을 하기위해서는 마운트 제한이 요구된다. + 하지만 이 마운트 제한들은 upstream 커널에서는 구현되어 있지 않다. + 마운트 제한 없이도, apparmor 프로파일은 우연한 손상에 대해서 보호가 가능하다. + + + + 만약 이 플래그가 0(기본값)이라면, 커널에 apparmor의 마운트 기능이 부족했을때 컨테이너가 시작되지 않는다. 커널을 업그레이드한 후에 해당 기능이 빠졌는지 여부를 검사하기 위함이다. 부분적인 apparmor 보호 하에서도 컨테이너를 시작하려면, 플래그를 1로 지정하면 된다. + + + + + + + + <!-- SELinux context -->SELinux 컨텍스트 + + + lxc가 SELinux를 지원하도록 컴파일된 후 설치되었고, 호스트 시스템에서 SELinux 컨텍스트가 활성화되었다면, 컨테이너에서 따라야할 SELinux 컨텍스트를 컨테이너 설정에서 지정할 수 있다. + 기본값은 unconfined_t이다. 이는 lxc는 컨텍스트를 변경하지않음을 의미한다. + 정책 예제와 추가적인 정보를 원한다면 @DATADIR@/lxc/selinux/lxc.te를 참고하면 된다. + + + + + + + + + + 컨테이너가 따라야할 SELinux 컨텍스트를 지정하거나, unconfined_t를 지정할 수 있다. 예를 들어 아래와 같이 지정 가능하다. + + lxc.se_context = system_u:system_r:lxc_t:s0:c22 + + + + + + + <!-- Seccomp configuration -->Seccomp 설정 + + + 컨테이너는 seccomp 프로파일을 로드하여 사용가능한 시스템콜의 수를 줄인 체로 실행할 수 있다. + seccomp 설정파일은 첫번째 행이 버전번호, 두번째 행이 정책 타입, 시작하며 그 이후에 설정 사항들이 포함되어야 한다. + + + + 현재는 버전1과 2만 지원된다. 버전 1에서는 정책은 단순한 화이트리스트이다. 그러므로 두번째 라인은 반드시 "whitelist"여야 한다. 파일의 나머지 내용은 한 줄에 하나의 시스템콜 번호로 채워진다. 화이트리스트에 없는 번호는 컨테이너에서 블랙리스트로 들어간다. + + + + + 버전 2에서는 폴리시는 블랙리스트 또는 화이트리스트가 될 수 있다. 그리고 각 규칙와 각 정책의 기본 동작, 아키텍쳐별 시스템콜 설정, 텍스트로된 이름을 지원한다. + + + + 아래는 블랙리스트 정책 예제이다. 아래 정책에서는 mknod를 제외한 모든 시스템콜이 허용된다. mknod시에는 아무것도 수행하지 않고 0(성공)을 반환한다. + + +2 +blacklist +mknod errno 0 + + + + + + + + + + 컨테이너가 시작되기전에 읽어올 seccomp 설정이 담긴 파일을 지정한다. + + + + + + + + <!-- UID mappings -->UID 매핑 + + + 컨테이너는 사용자와 그룹 ID 매핑을 통해 자신만의 사용자 네임스페이스 내에서 실행될수 있다. + 예를 들어서 컨테이너의 UID 0번을 호스트의 UID 200000으로 매핑할 수 있다. 컨테이너의 루트 사용자는 컨테이너에서는 특권을 가지고 있지만, 호스트에서는 특권을 가지고 있지 않게 된다. + 보통 시스템 컨테이너는 ID들의 범위를 지정하려 할텐데 그 역시도 지정 가능하다. 예를 들어서, 컨테이너의 UID와 GID를 0 ~ 20,000를 호스트의 200,000 ~ 220,000로 설정 가능하다. + + + + + + + + + + 4개의 값이 제공되어야 한다. 첫 번째는 'u', 'g', 'b' 문자로 각각 UID, GID, 또는 UID 및 GID 를 가리킨다. 그 다음은 사용자 네임스페이스내에서의 UID, 그다음은 호스트의 UID, 그리고 마지막으로 매핑할 ID의 범위를 지정한다. + + + + + + + + <!-- Container hooks -->컨테이너 훅 + + + 컨테이너 훅은 컨테이너의 생명주기 내에서 다양한 상황에 실행되는 프로그램 또는 스크립트이다. + + + + 컨테이너 훅이 실행될 때, 정보는 명령어 인수나 환경 변수를 통해 넘겨진다. + 인수 : + + 컨테이너 이름 + 섹션 (보통 'lxc') + 훅 종류 ('clone', 'pre-mount' 등) + clone 훅일 경우 추가인수. lxc-clone에 전달된 인수가 훅으로 전달된다. + + 환경 변수 : + + LXC_NAME: 컨테이너 이름 + LXC_ROOTFS_MOUNT: 마운트될 루트 파일시스템의 경로 + LXC_CONFIG_FILE: 컨테이너 설정파일의 경로 + LXC_SRC_NAME: clone 훅의 경우, 원본 컨테이너의 이름 + LXC_ROOTFS_PATH: 컨테이너의 lxc.rootfs 항목. 이 것은 마운트된 루트 파일시스템을 나타내지 않음에 주의해야한다. 그 목적을 위해서는 LXC_ROOTFS_MOUNT를 사용해야 한다. + + + + + 훅의 표준출력은 debug 수준 로그로 납겨진다. + 표준 에러는 로그로 남겨지지는 않지만, 표준 에러를 표준 출력으로 리 +다이렉션하여 로그로 남길 수 있다. + + + + + + + + + + 컨테이너의 tty, 콘솔의 생성 및 마운트가 되기 전에, 호스트의 네임스페이스에서 실행되는 훅. + + + + + + + + + + + + + 컨테이너의 마운트 네임스페이스 안에서 루트 파일시스템이 세팅되기 전에 실행되는 훅. + 예를 들어 암호화 파일시스템을 마운트 하는 등의 루트 파일시스템을 조작할 수 있게 해준다. 이 훅에서 마운트를 하더라도 호스트에는 반영되지 않는다. (mounts propagation은 제외) 그래서 컨테이너가 종료되면 자동적으로 정리된다. + + + + + + + + + + + + + 마운트가 완료된 후 pivot_root 전에, 컨테이너의 마운트 네임스페이스에서 실행되는 훅. + + + + + + + + + + + + + == 1가 지정되어 있는 경우에 마운트 완료시 마운트 훅도 실행 된 후 pivot_root전에, 컨테이너의 마운트 네임스페이스에서 실행되는 훅. + 이 훅의 목적은 systemd 기반의 컨테이너에서 autodev 옵션을 사용하는 경우 /dev 디렉토리를 구성할 때 도움을 주기위한 것이다. + 훅이 실행될 때, 컨테이너의 /dev 경로는 ${} 환경변수에 대한 경로이다. + + + + + + + + + + + + + 컨테이너의 init이 실행되기 직전에 컨테이너의 네임스페이스에서 실행되는 훅. 컨테이너 내에서 해당 프로그램이 실행될 수 있는 상태여야 한다. + + + + + + + + + + + + + 컨테이너가 종료된 후 호스트의 네임스페이스에서 실행되는 훅. + + + + + + + + + + + + + 컨테이너가 새로운 컨테이너로 복제되었을 경우 실행되는 훅. 아래를 참조하면 더 자세한 정보를 얻을 수 있다. + lxc-clone + 1 + + + + + + + + + + + + + 컨테이너가 제거될 때 실행되는 훅. + + + + + + + + <!-- Container hooks Environment Variables -->컨테이너 훅 환경 변수 + + + 훅이 시작될때 설정 정보를 제공하고 훅의 기능을 돕기 위해 몇가지 환경 변수가 사용 가능하다. + 모든 컨텍스트에서 모든 변수가 사용 가능하진 않다. 특히, 모든 경로는 호스트 시스템에서의 경로이며, 훅에서는 유효하지 않다. + + + + + + + + + + LXC 컨테이너의 이름. 일반적인 로그 환경에서 로그메시지에 유용하게 사용할 수 있다. [] + + + + + + + + + + + + + 컨테이너 설정파일의 호스트에서의 경로. + 이것은 다른 방법으로는 얻을 수 없는 추가적인 정보룰 찾을 수 있도록, 컨테이너가 참조하는 원래의 최상위 설정파일의 경로를 제공한다. [] + + + + + + + + + + + + + NULL이 아니라면, 컨테이너의 콘솔의 출력이 저장될 경로. + [] [] + + + + + + + + + + + + + NULL이 아니라면, 컨테이너의 콘솔의 로그 출력이 저장될 경로. + [] + + + + + + + + + + + + + 처음에 컨테이너가 마운트 되는 장소. + 이것은 시작되는 컨테이너 인스턴스를 위한 루트 파일시스템의 호스트에서의 경로이다. 해당 인스턴스에 대한 변경이 이루어져야 하는 장소이다. + [] + + + + + + + + + + + + + rootfs.mount에 마운트된 컨테이너 루트의 호스트에서의 경로이다. + [] + + + + + + + + + <!-- Logging -->로그 + + + 로그는 각 컨테이너마다 설정할 수 있다. + 기본적으로 lxc 패키지가 어떻게 컴파일되었는지에 달려있지만, 컨테이너 시작시에는 error 수준 로그만 기록된다. 컨테이너 경로나 @LOGPATH@ 밑에 컨테이너의 이름을 따서(뒤에 '.log'를 붙여서) 로그 파일을 생성한다. + + + + 기본 로그 수준과 로그파일은 컨테이너 설정파일로 지정 가능하며, 기본 동작을 덮어버린다. 마찬가지로 설 정파일 항목들은 lxc-start 명령어의 옵션으로 덮어쓸 수 있다. + + + + + + + + + + 기록할 로그 수준. + 로그 수준은 0 ~ 8 사이의 정수이다. + 숫자가 작을수록 더 자세히 로그를 기록한다. + 구체적으로는 0 = trace, 1 = debug, 2 = info, 3 = notice, 4 = warn, 5 = error, 6 = critical, 7 = alert, 8 = fatal이다. + 지정하지 않은 경우, 기본값은 5 (error)로, 에러 이거나 그보다 심각한 상황의 로그를 기록한다. + + + + (훅 스크립트 및 네트워크 인터페이스 up/down 스크립트 같은) 스크립트가 호출이되면, 스크립트의 표준 입출력은 1 번, debug 수준으로 기록된다. + + + + + + + + + + + 로그 정보를 쓸 파일. + + + + + + + + <!-- Autostart -->자동시작 + + + 자동시작 옵션들은 자동시작할 컨테이너 지정 및 순서 설정이 가능하다. + 이 옵션들은 LXC 도구로 직접 사용하거나 배포판들이 제공하는 외부 도구에 의해 사용될 수도 있다. + + + + + + + + + + + 컨테이너가 자동으로 시작될지 여부. + 유효한 값은 0 (off) 또는 1 (on)이다. + + + + + + + + + + + 컨테이너가 시작된 후 다음 컨테이너가 시작되기 전까지 기다릴 시간(초). + + + + + + + + + + + 다수의 컨테이너를 한번에 자동시작할 때, 컨테이너의 부팅 순서를 결정할 때 사용하는 정수를 지정한다. + + + + + + + + + + + 컨테이너를 추가할 컨테이너 그룹을 지정한다. 여러값을 설정할 수 있으며, 여러번 지정 가능하다. + 설정된 그룹은 연관된 컨테이너들을 시작할 때 사용된다. + + + + + + + + <!-- Autostart and System Boot -->자동시작과 시스템 부팅 + + + 각각의 컨테이너는 여러 그룹에 속할수도 있고 아무그룹에도 속하지 않을 수 있다. 두개의 그룹은 특수한데, 하나는 NULL 그룹이고 컨테이너가 아무그룹에도 속하지 않을때 사용된다. 그리고 나머지 하나는 "onboot" 그룹이다. + + + + + LXC 서비스가 활성화된 상태로 시스템이 부팅될 때, 먼저 lxc.start.auto == 1이고 "onboot" 그룹인 컨테이너들을 시작하려고 시도한다. 시작과정은 lxc.start.order의 순서대로 이루어진다. + 만약 lxc.start.delay가 지정 되었다면, 다음 컨테이너를 시작하려고 시도>하기 전, 현재 컨테이너의 초기화 및 호스트 시스템의 부하를 줄이기 위해서 지연시간을 준다. + "onboot" 그룹의 멤버들을 시작시킨 후, LXC 시스템은 lxc.start.auto == 1이고 어떤 그룹에도 속하지 않은(NULL 그룹) 컨테이너들을 시작한다. + + + + + + <!-- Container Environment -->컨테이너 환경변수 + + + 컨테이너에 환경변수를 념겨주고 싶다면(환경변수를 컨테이너의 init과 그 자손 전체가 사용할 수 있다), lxc.environment를 사용할 수 있다. + 민감한 정보를 넘기지 않도록 주의해야 한다. 왜냐면 컨테이너의 모든 프로세스가 이 환경변수를 획득할 수 있기 때문이다. 환경변수는 항상 /proc/PID/environ를 통해 획득할 수 있다. + + + + + 이 설정항목은 여러번을 지정할 수 있으며, 설정하려는 환경변수마다 한번씩 지정한다. + + + + + + + + + + + 컨테이너로 전달될 환경변수를 지정한다. + 예제: + + + lxc.environment = APP_ENV=production + lxc.environment = SYSLOG_SERVER=192.0.2.42 + + + + + + + + + + <!-- Examples -->예제 + + + 아래에 소개하는 몇가지 예제말고도 다른 예제들이 @DOCDIR@/examples에 위치하고 있다. + + + <!-- Network -->네트워크 + + + 이 설정은 컨테이너가 한 쪽은 (이전에 시스템에 이미 생성된) br0 브리지에 연결되어 있는 veth 장치 쌍을 사용하도록 세팅한다. 가상 네트워크 장치는 컨테이너 내에서 eth0라는 이름을 갖는다. + + + lxc.utsname = myhostname + lxc.network.type = veth + lxc.network.flags = up + lxc.network.link = br0 + lxc.network.name = eth0 + lxc.network.hwaddr = 4a:49:43:49:79:bf + lxc.network.ipv4 = 1.2.3.5/24 1.2.3.255 + lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597 + + + + + <!-- UID/GID mapping -->UID/GID 매핑 + + 이 설정은 UID와 GID 둘다를 컨테이너의 0 ~ 9999를 호스트의 100000 ~ 109999로 매핑한다. + + + lxc.id_map = u 0 100000 10000 + lxc.id_map = g 0 100000 10000 + + + + + <!-- Control group -->컨트롤 그룹 + + + 이 설정은 어플리케이션을 위해 몇가지 컨트롤 그룹을 설정한다. cpuset.cpus는 정의된 cpu만 사용하도록 제한한다. cpus.share은 컨트롤 그룹(cpu) 우선순위를 지정한다. devices.allow는 특정 장치를 사용 가능하게 한다. + + + lxc.cgroup.cpuset.cpus = 0,1 + lxc.cgroup.cpu.shares = 1234 + lxc.cgroup.devices.deny = a + lxc.cgroup.devices.allow = c 1:3 rw + lxc.cgroup.devices.allow = b 8:0 rw + + + + + <!-- Complex configuration -->복잡한 설정 + + + 아래의 예제는 복잡한 네트워크 스택, 컨트롤 그룹 사용, 호스트 이름 설정, 몇몇 장소 마운트, 루트 파일시스템 변경 등의 복잡한 설정을 보여준다. + + + lxc.utsname = complex + lxc.network.type = veth + lxc.network.flags = up + lxc.network.link = br0 + lxc.network.hwaddr = 4a:49:43:49:79:bf + lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255 + lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597 + lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588 + lxc.network.type = macvlan + lxc.network.flags = up + lxc.network.link = eth0 + lxc.network.hwaddr = 4a:49:43:49:79:bd + lxc.network.ipv4 = 10.2.3.4/24 + lxc.network.ipv4 = 192.168.10.125/24 + lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596 + lxc.network.type = phys + lxc.network.flags = up + lxc.network.link = dummy0 + lxc.network.hwaddr = 4a:49:43:49:79:ff + lxc.network.ipv4 = 10.2.3.6/24 + lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3297 + lxc.cgroup.cpuset.cpus = 0,1 + lxc.cgroup.cpu.shares = 1234 + lxc.cgroup.devices.deny = a + lxc.cgroup.devices.allow = c 1:3 rw + lxc.cgroup.devices.allow = b 8:0 rw + lxc.mount = /etc/fstab.complex + lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0 + lxc.rootfs = /mnt/rootfs.complex + lxc.cap.drop = sys_module mknod setuid net_raw + lxc.cap.drop = mac_override + + + + + + + <!-- See Also -->참조 + + + chroot + 1 + , + + + pivot_root + 8 + , + + + fstab + 5 + + + + capabilities + 7 + + + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc.sgml.in b/doc/ko/lxc.sgml.in new file mode 100644 index 000000000..ede2ca8ff --- /dev/null +++ b/doc/ko/lxc.sgml.in @@ -0,0 +1,875 @@ + + + +]> + + + + + @LXC_GENERATE_DATE@ + + + + + lxc + 7 + + Version @PACKAGE_VERSION@ + + + + + lxc + + + + Linux 컨테이너 + + + + + <!-- Quick start -->빠른 도움말 + + + man 페이지를 읽고 싶지는 않지만 서둘러서 해보고 싶다면, + 된다고 보장할 수는 없지만, 미리정의된 설정파일로 컨테이너 내에서 쉘을 실행하는 아래 명령어를 소개하고자 한다. + + @BINDIR@/lxc-execute -n foo -f + @DOCDIR@/examples/lxc-macvlan.conf /bin/bash + + + + + <!-- Overview -->개요 + + + 컨테이너 기술은 리눅스 커널의 메인스트림에서 활발하게 개발이 진행되고 있다. 컨트롤 그룹(aka. 프로세스 컨테이너)을 통한 자원 관리와 네임스페이슬 통한 자원의 고립 기능을 제공한다. + + + + + linux 컨테이너 (lxc)는 사용자영역 컨테이너 개체를 제공하는 새로운 기능을 사용하는 것을 목표로 하고 있다. 이 새로운 기능은 응용 프로그램이나 시스템에서 모든 자원의 격리와 제어를 제공한다. + + + + + 이 프로젝트의 첫번째 목적은 컨테이너 프로젝트에 속해있는 커널 개발자들의 작업을 편하게 하며, 특히 새로운 기능인 Checkpoing/Restart에 대해 계속 작업을 진행해 나가는 것이다. + lxc는 작지만, 컨테이너를 간단한 명령어를 통해 쉽게 관리할 수 있고, 다목적으로 사용되기에도 충분하다. + + + + + <!-- Requirements -->요구사항 + + + lxc는 커널이 제공하는 몇가지 기능들에 의존적이며, 해당 기능이 활성화되어 있어야 한다. 부족한 기능에 따라, 제한된 기능만이 동작하거나, 아예 동작을 안 할 수 있다. + + + + + 아래 리스트는 컨테이너의 모든 기능을 사용하기 위해 활성화되어야 하는 커널 기능들이다. + + + * General setup + * Control Group support + -> Namespace cgroup subsystem + -> Freezer cgroup subsystem + -> Cpuset support + -> Simple CPU accounting cgroup subsystem + -> Resource counters + -> Memory resource controllers for Control Groups + * Group CPU scheduler + -> Basis for grouping tasks (Control Groups) + * Namespaces support + -> UTS namespace + -> IPC namespace + -> User namespace + -> Pid namespace + -> Network namespace + * Device Drivers + * Character devices + -> Support multiple instances of devpts + * Network device support + -> MAC-VLAN support + -> Virtual ethernet pair device + * Networking + * Networking options + -> 802.1d Ethernet Bridging + * Security options + -> File POSIX Capabilities + + + + + 배포판들에 포함된 2.6.32 이상의 커널에서는 lxc가 동작한다. 매우 작은 기능만 있지만 충분히 사용할 수 있다. + lxc-checkconfig 스크립트를 사용하면 현재 커널 설정에 대한 정보를 얻을 수 있다. + + + + + 컨트롤 그룹은 어디에든지 마운트될 수 있다. 예를 들어 + mount -t cgroup cgroup /cgroup도 가능하다. + + 그러나 cgmanager, cgroup-lite 또는 systemd를 사용하여, /sys/fs/cgroup에 cgroup 계층구조를 마운트하는 것이 좋다. + + + + + + <!-- Functional specification -->기능 사양 + + + 컨테이너는 응용프로그램이나 시스템을 내부에서 실행시키기 위해, 호스트의 몇몇 자원들을 격리시키는 객체이다. + + + + 어플리케이션/시스템은 처음 생성될때 또는 시작 명령어의 인자로 넘겨주었던 설정을 기반으로 한 컨테이너 안에서 실행된다. + + + + + 어떻게 컨테이너 내부에서 응용 프로그램을 실행하는가? + + + + 어플리케이션을 실행하기에 앞서, 고립시키고 싶은 자원을 먼저 알아야 한다. 기본 설정은 pid와 sysv ipc 그리고 마운트 포인트들을 고립시킨다. + 만약에 간단한 쉘을 컨테이너 내부에서 실행시키기 원한다면, 특히 rootfs를 공유하고 싶다면 매우 기초적인 설정이 요구된다. + sshd 같은 응용 프로그램을 실행시키고 싶다면, 새로운 네트워크 스택과 호스트네임을 제공해 주어야 한다. + 만약 몇몇 파일들, 예를 들어, /var/run/httpd.pid이 충돌나는것을 막고 싶다면, /var/run를 빈 디렉토리로 다시 마운트하는 것이 필요하다. + 모든 경우의 파일 충돌을 피하고 싶다면, 컨테이너를 위한 루트 파일시스템를 따로 지정해 줄 수도 있다. 루트 파일시스템은 미리 원래의 루트 파일시스템을 바인드 마운트한 디렉토리가 될 수도 있다. 이렇게 되면 자신만의 /etc, /home을 사용하면서도 배포판을 그대로 사용할 수 있다. + + + + 아래는 sshd를 사용하기 위한 디렉토리 트리 예제이다. + +[root@lxc sshd]$ tree -d rootfs + +rootfs +|-- bin +|-- dev +| |-- pts +| `-- shm +| `-- network +|-- etc +| `-- ssh +|-- lib +|-- proc +|-- root +|-- sbin +|-- sys +|-- usr +`-- var + |-- empty + | `-- sshd + |-- lib + | `-- empty + | `-- sshd + `-- run + `-- sshd + + + 그리고, 해당 마운트 포인트 파일의 내용은 아래와 같다. + + [root@lxc sshd]$ cat fstab + + /lib /home/root/sshd/rootfs/lib none ro,bind 0 0 + /bin /home/root/sshd/rootfs/bin none ro,bind 0 0 + /usr /home/root/sshd/rootfs/usr none ro,bind 0 0 + /sbin /home/root/sshd/rootfs/sbin none ro,bind 0 0 + + + + + + 어떻게 컨테이너 내에서 시스템을 실행하는가? + + + + + 컨테이너 내에서 시스템을 실행하는 것은 역설적으로 어플리케이션을 실행하는 것보다 쉽다. 왜 그럴까? 왜냐하면, 어떤 자원이 고립되어야 하는지 고려할 필요가 없다. 모든 자원이 고립되면 된다. 자원들은 별다른 설정없이 고립된다고 지정만 해도 된다. 왜냐하면 컨테이너가 그 자원들을 세팅할 것이기 때문이다. 예를 들어 ipv4 주소는 시스템 컨테이너의 init 스크립트들을 통해 세팅된다. 아래는 마운트 포인트 파일의 예제이다. + + + [root@lxc debian]$ cat fstab + + /dev /home/root/debian/rootfs/dev none bind 0 0 + /dev/pts /home/root/debian/rootfs/dev/pts none bind 0 0 + + + 설정을 돕기 위해서 컨테이너에 부가 정보를 추가할 수 있다. 아래와 같이 호스트에 있는 resolv.conf를 컨테이너 안에서 접근할 수 있다. + + + /etc/resolv.conf /home/root/debian/rootfs/etc/resolv.conf none bind 0 0 + + + + + <!-- Container life cycle -->컨테이너의 생명주기 + + + 컨테이너가 생성될때, 컨테이너는 설정정보를 포함하게 된다. + 프로세스가 실행될때, 컨테이너는 시작되고 실행된다. + 컨테이너 내에서 실행되던 마지막 프로세스가 종료되면, 컨테이너는 종료된다. + + + + 컨테이너의 초기화가 실패했을 경우, (아래 그림처럼)중단 상태로 바뀌게 된다. + + + + + + + + + <!-- Configuration -->설정 + + + + 컨테이너는 설정파일에 의해서 설정된다. 설정파일의 형식은 다음을 참조하면 된다. + + lxc.conf + 5 + + + + + <!--Creating / Destroying container + (persistent container) -->컨테이너의 생성/제거 (지속 컨테이너) + + + 지속성 컨테이너 객체는 lxc-create 명령어로 생성된다. 컨테이너이름을 인수로 받으며, 부가적인 설정파일과 템플릿을 지정한다. + 여기서 지정하는 이름은 다른 명령어들을 사용할 때 해당 컨테이너를 참조하기 위해 사용된다. lxc-destroy 명령어는 컨테이너 객체를 제거한다. + + lxc-create -n foo + lxc-destroy -n foo + + + + + + <!-- Volatile container -->휘발성 컨테이너 + + + 컨테이너 시작전에 컨테이너 오브젝트를 생성하는 것이 의무는 아니다. + 컨테이너는 설정파일을 파라미터로 넣어서 바로 시작할 수도 있다. + + + + + <!-- Starting / Stopping container -->컨테이너의 시작과 종료 + + + 컨테이너가 생성하면 응용 프로그램/시스템이 실행될 준비를 마친 것이다. + 실행하는 것이 바로 lxc-execute와 lxc-start 명령어의 목적이다. + 응용프로그램 시작전에 컨테이너가 생성되어 있지 않다면, 컨테이너는 명령어의 인수로 넘겼던 설정파일을 사용한다. 그런 인수마저 없다면, 기본 고립 환경을 사용한다. + 만약 응용프로그램이 종료되면, 컨테이너도 역시 종료된다. 실행중인 응용프로그램을 종료시키고 싶다면 lxc-stop를 사용하면 된다. + + + + + 컨테이너 내부에서 응용프로그램을 실행하는 것은 시스템을 실행하는 것과는 차이가 있다. 이런 이유로 아래의 두가지 명령어가 사용된다. + + lxc-execute -n foo [-f config] /bin/bash + lxc-start -n foo [-f config] [/bin/bash] + + + + + + lxc-execute 명령어는 컨테이너 내부에서 lxc-init 프로세스를 통해 실행할 명령어를 지정할 수 있다. + lxc-init는 지정한 명령어를 실행한 후, 그 명령어로 실행된 모든 프로세스들이 종료되기를 기다린다. (컨테이너 내부에서 데몬을 지원하기 위해서이다) + 다시 말해서, 컨테이너 내부에서 lxc-init는 1번 pid를 갖고, 응용프로그램의 첫번째 프로세스는 2번 pid를 가진다. + + + + + lxc-start 명령어는 지정한 명령어를 컨테이너 내에서 직접 실행한다. 첫 프로세스의 pid는 1번이다. 만약 어떤 명령어도 지정되지 않으면, lxc.init_cmd에 지정된 명령어를 실행한다. 이마저도 지정되있지 않으면, /sbin/init를 실행한다. + + + + + 요약하자면, lxc-execute는 응용 프로그램 실행을 위해서, lxc-start는 시스템 실행을 위해 적합하다. + + + + + 만약 어플리케이션이 더이상 응답하지 않거나, 접근이 불가능하거나, 스스로 종료되지 못할 경우, lxc-stop 명령어는 컨테이너 내의 모든 프로세스들을 가차없이 종료시킬 것이다. + + lxc-stop -n foo + + + + + + <!-- Connect to an available tty -->사용가능한 tty 접속 + + + 컨테이너에 tty가 설정되어 있다면, tty를 통해 컨테이너에 접근할 수 있다. + 아래 명령어를 통해 사용될 가능한 tty를 제공하는 것은 컨테이너에 달려있다. + tty가 종료되었을 때는 다시 로그인하지 않고도 재접속할 수 있다. + + lxc-console -n foo -t 3 + + + + + + <!-- Freeze / Unfreeze container -->컨테이너 동결/동결 해제 + + + 스케줄링 등을 위해 컨테이너에 속해있는 모든 프로세스를 정지 시키는 것은 때로 유용할 수 있다. 아래 명령어들을 사용하면 된다. + + + lxc-freeze -n foo + + 는 모든 프로세스들을 인터럽트 불가능한 상태로 만든다. + + + lxc-unfreeze -n foo + + 는 모든 프로세스를 정지 해제 시킨다. + + + + + 이 기능은 커널에서 cgroup freezer 기능이 활성화 되어 있어야 사용 가능하다. + + + + + <!-- Getting information about container --> + 컨테이너 관련 정보 얻어오기 + + + 컨테이너가 많이 존재하는 경우, 어떤것이 생성되고 제거됬는지, 어떤 것이 실행됬는지 또는 어떤 프로세스들이 특정 컨테이너 내에서 실행되는지를 따라가기 힘들다. 이를 위해 다음과 같은 명령어들이 유용하게 사용될 수 있다. + + lxc-ls + lxc-info -n foo + + + + + lxc-ls는 시스템의 컨테이너들의 리스트를 표시한다. + + + + + lxc-info는 지정한 컨테이너의 정보를 얻어온다. + + + + + 아래는 명령어들을 조합하여 컨테이너들의 리스트를 얻어오고 상태를 출력하는 예제이다. + + for i in $(lxc-ls -1); do + lxc-info -n $i + done + + + + + + + <!-- Monitoring container -->컨테이너 모니터링 + + + 컨테이너의 상태를 추적하는 것은 때때로 매우 유용하다. + 예를 들어, 상태를 모니터링하거나, 스크립트에서 특정상태를 기다리는 경우이다. + + + + + lxc-monitor 명령어는 하나 또는 여러개의 컨테이너들을 모니터링한다. 이 명령어의 인수로 정규표현식을 넘길 수도 있다. + 예를 들면, + + lxc-monitor -n "foo|bar" + + 는 'foo'와 'bar'라는 이름의 컨테이너의 상태 변화를 모니터링한다. 그리고, + + lxc-monitor -n ".*" + + 는 모든 컨테이너를 모니터링한다. + + + + 'foo' 컨테이너가 시작되고 몇 가지 작업을 수행하고 종료된 경우, + 출력은 다음과 같다. + + 'foo' changed state to [STARTING] + 'foo' changed state to [RUNNING] + 'foo' changed state to [STOPPING] + 'foo' changed state to [STOPPED] + + + + + lxc-wait 명령어는 지정한 상태로 변화되는 것을 기다린다. 이 명령어는 컨테이너의 시작이나 종료와 동기화되는 스크립트를 작성할 때 유용하다. + 인수는 다른 상태들을 OR로 묶어서 지정해 줄 수 있다. 아래 예제는 백그라운드에서 어떻게 컨테이너의 상태 변화를 기다리는지 보여준다. + + + + + + + + <!-- Setting the control group for container --> + 컨테이너 컨트롤 그룹 설정 + + + + 컨테이너는 컨트롤 그룹과 결합되어 있다. + 컨테이너가 시작되면 컨트롤그룹이 만들어지고 해당 컨트롤 그룹과 연결된다. + 컨테이너가 실행중일 때, lxc-cgroup 명령어를 이용해 컨트롤 그룹 속성은 읽거나 수정될 수 있다. + + + + lxc-cgroup 명령어는 컨테이너와 연결된 컨트롤 그룹 서브시스템의 값을 얻어오거나 설정한다. + 서브시스템의 이름은 사용자가 결정하며, 이 명령어는 이름이 적합한지 여부를 검사하지 않는다. + 만약 서브시스템의 이름이 없다면 명령어는 실패할 것이다. + + + + + lxc-cgroup -n foo cpuset.cpus + + 는 해당 서브시스템의 내용을 표시한다. + + lxc-cgroup -n foo cpu.shares 512 + + 는 해당 서브시스템의 값을 설정한다. + + + + + + <!-- Bugs -->버그 + + + lxc는 아직 개발중이다. 그래서 명령어 사용법이나, API가 변경될 수 있다. 버전 1.0.0은 변경되지 않는 고정된 버전이다. + + + + &seealso; + + + <!-- Author -->저자 + Daniel Lezcano daniel.lezcano@free.fr + + + + + diff --git a/doc/ko/lxc.system.conf.sgml.in b/doc/ko/lxc.system.conf.sgml.in new file mode 100644 index 000000000..3f9c7dd4c --- /dev/null +++ b/doc/ko/lxc.system.conf.sgml.in @@ -0,0 +1,244 @@ + + + +]> + + + + @LXC_GENERATE_DATE@ + + + lxc.system.conf + 5 + + + + lxc.system.conf + + + + LXC 시스템 설정파일 + + + + + <!-- Description -->설명 + + + + 시스템 설정은 @LXC_GLOBAL_CONF@에 위치하고 있다. 비 +특권 컨테이너의 경우는 ~/.config/lxc/lxc.conf에 위치하고 있 +다. + + + + + 이 설정파일은 LXC 기본 경로 및 저장소 백엔드 설정과 같은 값들을 설정할 때 사용한다. + + + + <!-- Configuration paths -->경로 설정 + + + + + + + + + + 모든 컨테이너들이 저장되는 장소. + + + + + + + + + + + 컨테이너의 기본 설정파일 경로. + + + + + + + + <!-- Control Groups -->컨트롤 그룹 + + + + + + + + + + 사용할 cgroup 컨트롤러의 쉼표(,)로 구분된 목록. + 현재 LXC가 cgmanager를 사용하여 cgroup을 관리하고 있을 경우, 이 설정은 무시된다. + + + + + + + + + + + 컨테이너용 cgroup을 생성할 때 사용하는 포맷 문자열 (예 : lxc/%n). + + + + + + + + LVM + + + + + + + + + + 기본 LVM 볼륨 그룹 이름 + + + + + + + + + + + 기본 LVM thin pool 이름 + + + + + + + + ZFS + + + + + + + + + + 기본 ZFS root 이름. + + + + + + + + + + + lxc + 1 + , + + lxc.container.conf + 5 + , + + lxc.system.conf + 5 + , + + lxc-usernet + 5 + + + + + &seealso; + + + <!-- Author -->저자 + Stéphane Graber stgraber@ubuntu.com + + + + diff --git a/doc/ko/see_also.sgml.in b/doc/ko/see_also.sgml.in new file mode 100644 index 000000000..2de130ffc --- /dev/null +++ b/doc/ko/see_also.sgml.in @@ -0,0 +1,116 @@ + + + + <!--See Also-->참조 + + + + lxc + 7 + , + + + lxc-create + 1 + , + + + lxc-destroy + 1 + , + + + lxc-start + 1 + , + + + lxc-stop + 1 + , + + + lxc-execute + 1 + , + + + lxc-console + 1 + , + + + lxc-monitor + 1 + , + + + lxc-wait + 1 + , + + + lxc-cgroup + 1 + , + + + lxc-ls + 1 + , + + + lxc-info + 1 + , + + + lxc-freeze + 1 + , + + + lxc-unfreeze + 1 + , + + + lxc-attach + 1 + , + + + lxc.conf + 5 + + + + + + diff --git a/lxc.spec.in b/lxc.spec.in index a3cb6af5d..d0816d337 100644 --- a/lxc.spec.in +++ b/lxc.spec.in @@ -244,6 +244,9 @@ fi %{_mandir}/ja/man1/lxc* %{_mandir}/ja/man5/lxc* %{_mandir}/ja/man7/lxc* +%{_mandir}/ko/man1/lxc* +%{_mandir}/ko/man5/lxc* +%{_mandir}/ko/man7/lxc* %endif %{_datadir}/doc/* %{_datadir}/lxc/* -- 2.47.2