Difference between revisions of "Linux Containers/pt-br"

From Funtoo
Jump to navigation Jump to search
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Status ==
== Status ==


Como no kernel Linux 3.1.5, o LXC é útil por isolar seus próprios trabalhos de outros. Ele não está pronto ainda para isolar potencialmente usuários de outros ou do sistema hóspede (host). Para uma solução de containers mais madura, que é apropriada para ambientes de hospedagem, veja [[OpenVZ]].
Como no kernel Linux 3.1.5, o LXC é útil por isolar seus próprios trabalhos de outros. Ele não está pronto ainda para isolar potencialmente usuários de outros ou do sistema hóspede (host). Para uma solução de containers mais madura, que é apropriada para ambientes de hospedagem, veja [[Pt-br/OpenVZ|OpenVZ]].


Containers LXC ainda não possui seu próprio sistema de atualização, e eles veem tudo que está na saída {{c|dmesg}} no host, entre outras coisas. Mas em geral, a tecnologia funciona.
Containers LXC ainda não possui seu próprio sistema de atualização, e eles veem tudo que está na saída {{c|dmesg}} no host, entre outras coisas. Mas em geral, a tecnologia funciona.
Line 253: Line 253:


==== {{c|/lxc/funtoo0/fstab}} ====
==== {{c|/lxc/funtoo0/fstab}} ====
{{fancynote| It is now preferable to have mount entries directly in config file instead of separate fstab:}}
{{fancynote| é preferível ter entradas mount diretamente no arquivo config ao invés do fstab separado:}}
Edit the file {{c|/lxc/funtoo0/fstab}}:
Edite arquivo {{c|/lxc/funtoo0/fstab}}:
<pre>
<pre>
none /lxc/funtoo0/dev/pts devpts defaults 0 0
none /lxc/funtoo0/dev/pts devpts defaults 0 0
Line 263: Line 263:


== LXC Networking ==
== LXC Networking ==
*veth - Virtual Ethernet (bridge)
*veth - Ethernet Virtual (bridge)
*vlan - vlan interface (requires device able to do vlan tagging)
*vlan - Interface da vlan (requer dispositivo capaz de utilizar a vlan tagging)
*macvlan (mac-address based virtual lan tagging) has 3 modes:
*macvlan (mac-address baseado na lan tagging virtual) possui 3 modos:
**private  
**private  
**vepa (Virtual Ethernet Port Aggregator)
**vepa (Virtual Ethernet Port Aggregator)
**bridge  
**bridge  
*phys - dedicated host NIC
*phys - NIC hospede (host) dedicado
[https://blog.flameeyes.eu/2010/09/linux-containers-and-networking Linux Containers and Networking]  
[https://blog.flameeyes.eu/2010/09/linux-containers-and-networking Linux Containers and Networking]  


Enable routing on the host:
Habilite o roteamento no host:
By default Linux workstations and servers have IPv4 forwarding disabled.
Por padrão, o Linux workstations e servidores possuem o IPv4 forwarding desabilitado.
{{console|body=
{{console|body=
###i## echo "1" > /proc/sys/net/ipv4/ip_forward
###i## echo "1" > /proc/sys/net/ipv4/ip_forward
Line 279: Line 279:
# 1
# 1
}}
}}
== Initializing and Starting the Container ==


You will probably need to set the root password for the container before you can log in. You can use chroot to do this quickly:
== Inicializando e Startando o Container ==
 
Provavelmente você precisará definir a senha de administrador (root password) para o container antes que pode logar. Você pode utilizar o chroot para fazer isso rapidamente:


{{console|body=
{{console|body=
Line 292: Line 293:
}}
}}


Now that the root password is set, run:
Agora que a senha de administrador está definida, execute:


{{console|body=
{{console|body=
Line 298: Line 299:
}}
}}


The {{c|-d}} option will cause it to run in the background.
A opção {{c|-d}} fará com que rode em plano de fundo (background).


To attach to the console:
Para anexá-lo ao console:


{{console|body=
{{console|body=
Line 306: Line 307:
}}
}}


You should now be able to log in and use the container. In addition, the container should now be accessible on the network.
Agora você deve ser capaz de logar e utilizar o container. Em adição, o container deve agora estar acessível na rede.


To directly attach to container:
Para anexar o container diretamente:


{{console|body=
{{console|body=
Line 314: Line 315:
}}
}}


To stop the container:
Para parar o container:


{{console|body=
{{console|body=
Line 320: Line 321:
}}
}}


Ensure that networking is working from within the container while it is running, and you're good to go!
Certifique-se de que a rede está funcionando de dentro do container enquanto estiver em execução, e você está pronto para trabalhar!
== Starting LXC container during host boot ==


# You need to create symlink in {{c|/etc/init.d/}} to {{c|/etc/init.d/lxc}} so that it reflects your container.
== Inicializando um LXC container durante o  host boot ==
 
# Você precisa criar um symlink em {{c|/etc/init.d/}} para {{c|/etc/init.d/lxc}} assim ele reflete seu container.
# {{c|ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0}}
# {{c|ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0}}
# now you can add {{c|lxc.funtoo0}} to default runlevel
# agora você pode adicionar {{c|lxc.funtoo0}} para o runlevel padrão
# {{c|rc-update add lxc.funtoo0 default}}
# {{c|rc-update add lxc.funtoo0 default}}
{{console|body=
{{console|body=
Line 331: Line 333:
  * Starting funtoo0 ...                  [ ok ]
  * Starting funtoo0 ...                  [ ok ]
}}
}}
== LXC Bugs/Missing Features ==


This section is devoted to documenting issues with the current implementation of LXC and its associated tools. We will be gradually expanding this section with detailed descriptions of problems, their status, and proposed solutions.
== LXC Bugs/Ausência de Recursos ==
 
Essa seçao é dedicada a documentar questões como a implementação atual do LXC e suas ferramentas associadas. Estaremos gradualmente expandindo essa seção com descrições detalhadas de problemas, seus status, e soluções de problemas.


=== reboot ===
=== reboot ===


* By default, lxc does not support rebooting a container from within. It will simply stop and the host will not know to start it.
* Por padrão, o lxc não possui suporte a reiniciar um container. Ele simplesmente parará e o host não saberá inicializá-lo.
* If you want your container to reboot gracefully, you need sys_boot capability (comment out lxc.cap.drop = sys_boot in your container config)
* Se você quiser que o seu to reinicialize de forma agradável, você precisa da capacidade sys_boot (comente lxc.cap.drop = sys_boot no seu container config)


=== PID namespaces ===
=== PID namespaces ===


Process ID namespaces are functional, but the container can still see the CPU utilization of the host via the system load (ie. in {{c|top}}).
Process ID namespaces são funcionais, mas o container pode ainda visualizar a utilizaçaõ do CPU do host via system load (ie. in {{c|top}}).


=== /dev/pts newinstance ===
=== /dev/pts newinstance ===


* Some changes may be required to the host to properly implement "newinstance" {{c|/dev/pts}}. See [https://bugzilla.redhat.com/show_bug.cgi?id=501718 This Red Hat bug].
* Algumas alterações podem ser exigidas para que o  host implemente implemente "newinstance" {{c|/dev/pts}} corretamente. Veja [https://bugzilla.redhat.com/show_bug.cgi?id=501718 This Red Hat bug].


=== lxc-create and lxc-destroy ===
=== lxc-create e lxc-destroy ===


* LXC's shell scripts are badly designed and are sure way to destruction, avoid using lxc-create and lxc-destroy.
* Os shell scripts do LXC são mal desenvolvidos e são com certeza caminho para a destruição, evite utilizar o lxc-create e lxc-destroy.


=== network initialization and cleanup ===
=== inicialização limpeza de rede ===


* If used network.type = phys after lxc-stop the interface will be renamed to value from lxc.network.link. It supposed to be fixed in 0.7.4, happens still on 0.7.5 - http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg01760.html
* Se utilizado network.type = phys after lxc-stop a interface será renomeada para o valor de lxc.network.link. Esperava-se que fosse corrigido na versão 0.7.4, que aconteceu ainda na versão 0.7.5 - http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg01760.html


* Re-starting a container can result in a failure as network resource are tied up from the already-defunct instance: [http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg00824.html]
* Reiniciar um container pode resultar em uma falar como os recursos da rede estão atrelados a a partir da já falecida instancia: [http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg00824.html]


=== graceful shutdown ===
=== shutdown de forma satisfatória ===


* To gracefully shutdown a container, it's init system needs to properly handle kill -PWR signal
* Para desligar (shutdown) um container de forma satisfatória, seu sistema init precisa cuidar de forma correta o sinal de kill -PWR (kill -PWR signal)
* For funtoo/gentoo make sure that you have:
* Para o funtoo/gentoo certifique-se de que possui:
** pf:12345:powerwait:/sbin/halt
** pf:12345:powerwait:/sbin/halt
** in your containers /etc/inittab
** em seus containers /etc/inittab
* For debian/ubuntu make sure that you have:
* Para o debian/ubuntu certifique-se de que possui:
** pf::powerwait:/sbin/shutdown -t1 -a -h now
** pf::powerwait:/sbin/shutdown -t1 -a -h now
** in your container /etc/inittab
** em seu container /etc/inittab
** and also comment out other line starting with pf:powerfail (such as pf::powerwait:/etc/init.d/powerfail start) <- these are used if you have UPS monitoring daemon installed!
** e também comente outras linhas iniciadas com pf:powerfail (tal qual pf::powerwait:/etc/init.d/powerfail start) <- esses são utilizados se você possui daemon UPS monitoring instalada!
* /etc/init.d/lxc seems to have broken support for graceful shutdown (it sends proper signal, but then also tries to kill the init with lxc-stop)
* /etc/init.d/lxc aparenta possuir suporte quebrado para um shutdown satisfatório (ele envia um adequado, mas então tenta também matar (kill) a init com o lxc-stop)


=== funtoo ===
=== funtoo ===


* Our udev should be updated to contain {{c|-lxc}} in scripts. (This has been done as of 02-Nov-2011, so should be resolved. But not fixed in our openvz templates, so need to regen them in a few days.)
* Nosso udev deve ser atualizado para conter {{c|-lxc}} nos scripts. (Isso tem sido feito da partir de 02-Nov-2011, então deve estar resolvido. Mas não corrigido em nossos templates openvz, então precisamos gerá-los novamente (regen) em agluns dias.)
* Our openrc should be patched to handle the case where it cannot mount tmpfs, and gracefully handle this situation somehow. (Work-around in our docs above, which is to mount tmpfs to {{c|/libexec/rc/init.d}} using the container-specific {{c|fstab}} file (on the host.)
* Nosso openrc dever ter patches para cuidar do caso onde ele não pode montar o tmpfs, e de forma satisfatória cuidar dessa situação de alguma forma. (trabalhos de terceiros em nossos docs acima, que é para montar o tmpfs no {{c|/libexec/rc/init.d}} utilizando o arquivo específico do container {{c|fstab}} (no host.)
* Emerging udev within a container can/will fail when realdev is run, if a device node cannot be created (such as /dev/console) if there are no mknod capabilities within the container. This should be fixed.
* Emergir o udev dentro de um container pode/rá falhar quando o realdev estiver em execução, se um node de dispositivo não puder ser criado (tal como o /dev/console) se houver nenhuma compatibilidade com o mknod dentro do container. Isso deve ser corrigido.
== References ==
 
== Referências ==


* {{c|man 7 capabilities}}
* {{c|man 7 capabilities}}
* {{c|man 5 lxc.conf}}
* {{c|man 5 lxc.conf}}
== Links ==
== Links ==


* There are a number of additional lxc features that can be enabled via patches: [http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/]
* Há um número de recursos adicionais do lxc que podem ser habilitados via patches: [http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/]
* [https://wiki.ubuntu.com/UserNamespace Ubuntu User Namespaces page]
* [https://wiki.ubuntu.com/UserNamespace Ubuntu User Namespaces page]
* lxc-gentoo setup script [https://github.com/globalcitizen/lxc-gentoo on GitHub]
* script de configuração do lxc-gentoo [https://github.com/globalcitizen/lxc-gentoo on GitHub]


* '''IBM developerWorks'''
* '''Trabalho de desenvolvedores da IBM'''
** [http://www.ibm.com/developerworks/linux/library/l-lxc-containers/index.html LXC: Linux Container Tools]
** [http://www.ibm.com/developerworks/linux/library/l-lxc-containers/index.html LXC: Linux Container Tools]
** [http://www.ibm.com/developerworks/linux/library/l-lxc-security/ Secure Linux Containers Cookbook]
** [http://www.ibm.com/developerworks/linux/library/l-lxc-security/ Secure Linux Containers Cookbook]
Line 395: Line 400:
[[Category:HOWTO]]
[[Category:HOWTO]]
[[Category:Virtualization]]
[[Category:Virtualization]]
[[Category:pt_BR]]

Latest revision as of 16:57, July 12, 2015

Status

Como no kernel Linux 3.1.5, o LXC é útil por isolar seus próprios trabalhos de outros. Ele não está pronto ainda para isolar potencialmente usuários de outros ou do sistema hóspede (host). Para uma solução de containers mais madura, que é apropriada para ambientes de hospedagem, veja OpenVZ.

Containers LXC ainda não possui seu próprio sistema de atualização, e eles veem tudo que está na saída dmesg no host, entre outras coisas. Mas em geral, a tecnologia funciona.

Informações Básicas

  • Linux Containers são baseados em:
    • Kernel namespaces para isolamento de recursos
    • CGroups para limitação e contabilidade de recursos

app-emulation/lxc é a ferramenta userspace para os Linux containers

Grupos de controle (Control groups)

  • Control groups (cgroups) no kernel desde o 2.6.24
    • Permite agregação de tarefas e seus filhos (children)
    • Subsystems (cpuset, memory, blkio,...)
    • accounting - para medir a quantidade de recursos que certos sistemas utilizam
    • resource limiting (limitante de recurso) - grupos podem ser configurados para não excederem um determinado limite de memória
    • prioritization (priorização) - alguns grupos podem ter uma fatia maior do CPU
    • control - freezing/unfreezing (congelamento/descongelamento) de cgroups, checkpointing (ponto de verificação) e restarting (reinicialização)
    • No disk quota limitation ( -> image file, LVM, XFS, directory tree quota,...) [sem limitação de cota de disco (-> arquivo imagem, LVM, XFS, cota de arvore de diretório)]

Subsystems


root # cat /proc/cgroups 
subsys_name	hierarchy	num_cgroups	enabled
cpuset	
cpu	
cpuacct	
memory	
devices	
freezer	
blkio	
perf_event
hugetlb
  1. cpuset -> limita tarefas para CPU/CPUs específicos
  2. cpu -> compartilhamento de CPU
  3. cpuacct -> contabilização de CPU
  4. memory -> limitação de contabilização de memória e de swap
  5. devices -> lista de dispositivo negado ou permitido
  6. freezer -> suspend/resume tarefas
  7. blkio -> priorização I/O (weight, throttle, ...)
  8. perf_event -> suporte para monitoramento por-cpu por-cgroup perf_events
  9. hugetlb -> recurso controlador do cgroup para páginas HugeTLB hugetlb

Configurando o Host system do Funtoo

Instale o LXC kernel

Qualquer kernel acima do 3.1.5 provavelmente funcionará. Pessoalmente, eu prefiro o No results , uma vez que ele possui suporte para todos os namespaces sem sacrificar o suporte a xfs, FUSE ou NFS, por exemplo. Essas verificações foram introduzidas posteriormente, a partir do kernel 3.5, o que pode também significar que o namespace do usuário não está funcionando de forma otimizada.

  • User namespace (EXPERIMENTAL) depende do EXPERIMENTAL e do UIDGID_CONVERTED
    • config UIDGID_CONVERTED
      • True (verdadeiro) se todos os componentes de software selecionados forem conhecidos por terem uid_t and gid_t convertidos para kuid_t and kgid_t onde se apropriaram e são por outro lado seguros de utilizar com o user namespace.
        • Networking - depende do NET_9P = n
        • Filesystems - 9P_FS = n, AFS_FS = n, AUTOFS4_FS = n, CEPH_FS = n, CIFS = n, CODA_FS = n, FUSE_FS = n, GFS2_FS = n, NCP_FS = n, NFSD = n, NFS_FS = n, OCFS2_FS = n, XFS_FS = n
        • Opções de segurança (Security options) - Grsecurity - GRKERNSEC = n (se aplicável)
    • A partir do kernel 3.10.xx, todas as opções acima são seguras para se usar com User namespaces, excetuando XFS_FS. Consequentemente, com kernel >=3.10.xx, você deverá responder XFS_FS= n, caso queira suporte a User namespaces.
    • Em seu diretório da fonte do kernel (kernel source directory), você deve verificar o init/Kconfig e descobrir o que UIDGID_CONVERTED depende

Configuração do kernel

Estas opções devem ser habilitadas em seu kernel para ser capaz de tirar o máximo proveito do LXC.

  • General setup
    • CONFIG_NAMESPACES
      • CONFIG_UTS_NS
      • CONFIG_IPC_NS
      • CONFIG_PID_NS
      • CONFIG_NET_NS
      • CONFIG_USER_NS
    • CONFIG_CGROUPS
      • CONFIG_CGROUP_DEVICE
      • CONFIG_CGROUP_SCHED
      • CONFIG_CGROUP_CPUACCT
      • CONFIG_CGROUP_MEM_RES_CTLR (em kernels superiores ao 3.6 essa opção é chamada de CONFIG_MEMCG)
      • CONFIG_CGROUP_MEM_RES_CTLR_SWAP (em kernels superiores ao 3.6 essa opção é chamada CONFIG_MEMCG_SWAP)
      • CONFIG_CPUSETS (on multiprocessor hosts)
  • Networking support
    • Networking options
      • CONFIG_VLAN_8021Q
  • Device Drivers
    • Character devices
      • Unix98 PTY support
        • CONFIG_DEVPTS_MULTIPLE_INSTANCES
    • Network device support
      • Network core driver support
        • CONFIG_VETH
        • CONFIG_MACVLAN

Uma vez que você tenha o lxc instalado, você pode verificar seu kernel config com:

root # CONFIG=/path/to/config /usr/sbin/lxc-checkconfig

Emerge lxc

root # emerge app-emulation/lxc

Configure a Rede para o Container

Tipicamente, alguém utiliza uma ponte (bridge) para permitir que os containers conectem a rede. Esse é o modo de se fazer isso no Funtoo Linux:

  1. crie uma bridge utilizando os Funtoo network configuration scripts. Nomeie a bridge com algo como brwan (using /etc/init.d/netif.brwan). Configure sua bridge pata ter um endereço IP.
  2. Faça a dua interface física, tal qual eth0, uma interface sem endereço de IP (utilize o template interface-noip do Funtoo.)
  3. Torne o netif.eth0 um slave de netif.brwan em /etc/conf.d/netif.brwan.
  4. Habilite sua nova rede já em bridge e certifique-se de que está funcionando corretamente no host.

Agora você será capaz de configurar LXC para adicionar automaticamente sua interface ethernet virtual do container para criar uma bridge quando ele inicializar, que a conectará a sua rede.

Definindo um LXC Container do Funtoo Linux

Aqui estão os passos necessários para por o Funtoo Linux para funcionar dentro de um container. Os passos abaixo mostram como definir um container utilizando um template OpenVZ existente do Funtoo Linux. Agora é possível também utilizar o Metro para consruir um diretamente um tarball do lxc container, que salvará sua configuração manual e fornecerá um arquivo /etc/fstab.lxc que você pode utilizar para o seu host container config. Veja Metro Recipes para informações de como utilizar o Metro para gerar um lxc container.

Criar e configurar um Container Filesystem

  1. Inicie o Funtoo LXC template, e desempacote-o em um diretório tal qual /lxc/funtoo0/rootfs/
  2. Crie um arquivo /lxc/funtoo0/fstab vazio
  3. Certifique-se de que a linha c1 não está comentada (habilitada) e da linha c2 à linha c6 estão desabilitadas em /lxc/funtoo0/rootfs/etc/inittab

Isso é quase tudo o que você precisa para ter o container filesystem pronto para iniciar.

Crie os Arquivos de Configuração do Container

Crie os seguintes arquivos:

/lxc/funtoo0/config

e crie também o link simbólico a partir de

/lxc/funtoo0/config to /etc/lxc/funtoo0/config

root # install -d /etc/lxc/funtoo0
root # ln -s /lxc/funtoo0/config /etc/lxc/funtoo0/config
   Note
Daniel Robbins precisa atualizar esse config para ficar mais alinhado com o http://wiki.progress-linux.org/software/lxc/ -- Esse config aparenta ter permissões de node de dispositivo boa, refinado entre outras coisas. // nota de Havis para Daniel, esse config já é superior.


Leia "man 5 lxc.conf" , para obter mais informações sobre o arquivo de configuração do linux container.

## Container
lxc.utsname                             = funtoo0
lxc.rootfs                              = /lxc/funtoo0/rootfs/
lxc.arch                                = x86_64
#lxc.console                            = /var/log/lxc/funtoo0.console  # uncomment if you want to log containers console
lxc.tty                                 = 6  # if you plan to use container with physical terminals (eg F1..F6)
#lxc.tty                                = 0  # set to 0 if you dont plan to use the container with physical terminal, also comment out in your containers /etc/inittab  c1 to c6 respawns (e.g. c1:12345:respawn:/sbin/agetty 38400 tty1 linux)
lxc.pts                                 = 1024


## Capabilities
lxc.cap.drop                            = audit_control
lxc.cap.drop                            = audit_write
lxc.cap.drop                            = mac_admin
lxc.cap.drop                            = mac_override
lxc.cap.drop                            = mknod
lxc.cap.drop                            = setfcap
lxc.cap.drop                            = setpcap
lxc.cap.drop                            = sys_admin
#lxc.cap.drop                            = sys_boot # capability to reboot the container
#lxc.cap.drop                            = sys_chroot # required by SSH
lxc.cap.drop                            = sys_module
#lxc.cap.drop                            = sys_nice
lxc.cap.drop                            = sys_pacct
lxc.cap.drop                            = sys_rawio
lxc.cap.drop                            = sys_resource
lxc.cap.drop                            = sys_time
#lxc.cap.drop                            = sys_tty_config # required by getty

## Devices
#lxc.cgroup.devices.allow               = a # Allow access to all devices
lxc.cgroup.devices.deny                 = a # Deny access to all devices

# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow                = c *:* m
lxc.cgroup.devices.allow                = b *:* m

lxc.cgroup.devices.allow                = c 1:3 rwm # /dev/null
lxc.cgroup.devices.allow                = c 1:5 rwm # /dev/zero
lxc.cgroup.devices.allow                = c 1:7 rwm # /dev/full
lxc.cgroup.devices.allow                = c 1:8 rwm # /dev/random
lxc.cgroup.devices.allow                = c 1:9 rwm # /dev/urandom
#lxc.cgroup.devices.allow                = c 4:0 rwm # /dev/tty0 ttys not required if you have lxc.tty = 0
#lxc.cgroup.devices.allow                = c 4:1 rwm # /dev/tty1 devices with major number 4 are "real" tty devices
#lxc.cgroup.devices.allow                = c 4:2 rwm # /dev/tty2
#lxc.cgroup.devices.allow                = c 4:3 rwm # /dev/tty3
lxc.cgroup.devices.allow                = c 5:0 rwm # /dev/tty
lxc.cgroup.devices.allow                = c 5:1 rwm # /dev/console
lxc.cgroup.devices.allow                = c 5:2 rwm # /dev/ptmx
lxc.cgroup.devices.allow                = c 10:229 rwm # /dev/fuse
lxc.cgroup.devices.allow                = c 136:* rwm # /dev/pts/* devices with major number 136 are pts
lxc.cgroup.devices.allow                = c 254:0 rwm # /dev/rtc0

## Limits#
lxc.cgroup.cpu.shares                  = 1024
lxc.cgroup.cpuset.cpus                 = 0        # limits container to CPU0
lxc.cgroup.memory.limit_in_bytes       = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
#lxc.cgroup.blkio.weight                = 500      # requires cfq block scheduler

## Filesystem
#containers fstab should be outside it's rootfs dir (e.g. /lxc/funtoo0/fstab is ok, but /lxc/funtoo0/rootfs/etc/fstab is wrong!!!)
#lxc.mount                               = /lxc/funtoo0/fstab       

#lxc.mount.entry is prefered, because it supports relative paths
lxc.mount.entry                         = proc proc proc nosuid,nodev,noexec  0 0
lxc.mount.entry                         = sysfs sys sysfs nosuid,nodev,noexec,ro 0 0
lxc.mount.entry                         = devpts dev/pts devpts nosuid,noexec,mode=0620,ptmxmode=000,newinstance 0 0
lxc.mount.entry                         = tmpfs dev/shm tmpfs nosuid,nodev,mode=1777 0 0
lxc.mount.entry                         = tmpfs run tmpfs nosuid,nodev,noexec,mode=0755,size=128m 0 0
lxc.mount.entry                         = tmpfs tmp tmpfs nosuid,nodev,noexec,mode=1777,size=1g 0 0

##Example of having /var/tmp/portage as tmpfs in container 
#lxc.mount.entry                         = tmpfs var/tmp/portage tmpfs defaults,size=8g,uid=250,gid=250,mode=0775 0 0
##Example of bind mount
#lxc.mount.entry                        = /srv/funtoo0 /lxc/funtoo0/rootfs/srv/funtoo0 none defaults,bind 0 0

## Network
lxc.network.type                        = veth
lxc.network.flags                       = up
lxc.network.hwaddr                      = #put your MAC address here, otherwise you will get a random one
lxc.network.link                        = br0
lxc.network.name                        = eth0
#lxc.network.veth.pair                   = veth-example

Leia "man 7 capabilities" para obter mais informações sobre compatibilidades no Linux.

Acima, utilize o comando a seguir para gerar um MAC randômico (random MAC) para o lxc.network.hwaddr:

root # openssl rand -hex 6

É uma boa ideia atribuir um endereço MAC estático para o seu container utilizar lxc.network.hwaddr. Caso não, LXC will auto-gerará um novo MAC randômico toda vez que seu container inicializar, o qual pode confundir o equipamento de rede que espera que os endereços MAC permaneça constante.

Pode acontecer de caso para caso que você não seja capaz de inicializar seu LXC Container com o endereço MAC gerado; então, para todos esse que tiverem esse problema, aqui está um pequeno script que conecta seu IP para o container com o endereço MAC. Apenas salve o código a seguir assim /etc/lxc/hwaddr.sh, torne-o executável e execute-o assim /etc/lxc/hwaddr.sh xxx.xxx.xxx.xxx onde xxx.xxx.xxx.xxx representa o IP do seu Container.
/etc/lxc/hwaddr.sh:

#!/bin/sh
IP=$*
HA=`printf "02:00:%x:%x:%x:%x" ${IP//./ }`
echo $HA

/lxc/funtoo0/fstab

   Note
é preferível ter entradas mount diretamente no arquivo config ao invés do fstab separado:

Edite arquivo /lxc/funtoo0/fstab:

none /lxc/funtoo0/dev/pts devpts defaults 0 0
none /lxc/funtoo0/proc proc defaults 0 0
none /lxc/funtoo0/sys sysfs defaults 0 0
none /lxc/funtoo0/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0

LXC Networking

  • veth - Ethernet Virtual (bridge)
  • vlan - Interface da vlan (requer dispositivo capaz de utilizar a vlan tagging)
  • macvlan (mac-address baseado na lan tagging virtual) possui 3 modos:
    • private
    • vepa (Virtual Ethernet Port Aggregator)
    • bridge
  • phys - NIC hospede (host) dedicado

Linux Containers and Networking

Habilite o roteamento no host: Por padrão, o Linux workstations e servidores possuem o IPv4 forwarding desabilitado.

root # echo "1" > /proc/sys/net/ipv4/ip_forward
root # cat /proc/sys/net/ipv4/ip_forward
root # 1

Inicializando e Startando o Container

Provavelmente você precisará definir a senha de administrador (root password) para o container antes que pode logar. Você pode utilizar o chroot para fazer isso rapidamente:

root # chroot /lxc/funtoo0/rootfs
(chroot) # passwd
New password: XXXXXXXX
Retype new password: XXXXXXXX
passwd: password updated successfully
(chroot) # exit

Agora que a senha de administrador está definida, execute:

root # lxc-start -n funtoo0 -d

A opção -d fará com que rode em plano de fundo (background).

Para anexá-lo ao console:

root # lxc-console -n funtoo0

Agora você deve ser capaz de logar e utilizar o container. Em adição, o container deve agora estar acessível na rede.

Para anexar o container diretamente:

root # lxc-attach -n funtoo0

Para parar o container:

root # lxc-stop -n funtoo0

Certifique-se de que a rede está funcionando de dentro do container enquanto estiver em execução, e você está pronto para trabalhar!

Inicializando um LXC container durante o host boot

  1. Você precisa criar um symlink em /etc/init.d/ para /etc/init.d/lxc assim ele reflete seu container.
  2. ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0
  3. agora você pode adicionar lxc.funtoo0 para o runlevel padrão
  4. rc-update add lxc.funtoo0 default
root # rc
 * Starting funtoo0 ...                  [ ok ]

LXC Bugs/Ausência de Recursos

Essa seçao é dedicada a documentar questões como a implementação atual do LXC e suas ferramentas associadas. Estaremos gradualmente expandindo essa seção com descrições detalhadas de problemas, seus status, e soluções de problemas.

reboot

  • Por padrão, o lxc não possui suporte a reiniciar um container. Ele simplesmente parará e o host não saberá inicializá-lo.
  • Se você quiser que o seu to reinicialize de forma agradável, você precisa da capacidade sys_boot (comente lxc.cap.drop = sys_boot no seu container config)

PID namespaces

Process ID namespaces são funcionais, mas o container pode ainda visualizar a utilizaçaõ do CPU do host via system load (ie. in top).

/dev/pts newinstance

  • Algumas alterações podem ser exigidas para que o host implemente implemente "newinstance" /dev/pts corretamente. Veja This Red Hat bug.

lxc-create e lxc-destroy

  • Os shell scripts do LXC são mal desenvolvidos e são com certeza caminho para a destruição, evite utilizar o lxc-create e lxc-destroy.

inicialização limpeza de rede

  • Reiniciar um container pode resultar em uma falar como os recursos da rede estão atrelados a a partir da já falecida instancia: [1]

shutdown de forma satisfatória

  • Para desligar (shutdown) um container de forma satisfatória, seu sistema init precisa cuidar de forma correta o sinal de kill -PWR (kill -PWR signal)
  • Para o funtoo/gentoo certifique-se de que possui:
    • pf:12345:powerwait:/sbin/halt
    • em seus containers /etc/inittab
  • Para o debian/ubuntu certifique-se de que possui:
    • pf::powerwait:/sbin/shutdown -t1 -a -h now
    • em seu container /etc/inittab
    • e também comente outras linhas iniciadas com pf:powerfail (tal qual pf::powerwait:/etc/init.d/powerfail start) <- esses são utilizados se você possui daemon UPS monitoring instalada!
  • /etc/init.d/lxc aparenta possuir suporte quebrado para um shutdown satisfatório (ele envia um adequado, mas então tenta também matar (kill) a init com o lxc-stop)

funtoo

  • Nosso udev deve ser atualizado para conter -lxc nos scripts. (Isso tem sido feito da partir de 02-Nov-2011, então deve estar resolvido. Mas não corrigido em nossos templates openvz, então precisamos gerá-los novamente (regen) em agluns dias.)
  • Nosso openrc dever ter patches para cuidar do caso onde ele não pode montar o tmpfs, e de forma satisfatória cuidar dessa situação de alguma forma. (trabalhos de terceiros em nossos docs acima, que é para montar o tmpfs no /libexec/rc/init.d utilizando o arquivo específico do container fstab (no host.)
  • Emergir o udev dentro de um container pode/rá falhar quando o realdev estiver em execução, se um node de dispositivo não puder ser criado (tal como o /dev/console) se houver nenhuma compatibilidade com o mknod dentro do container. Isso deve ser corrigido.

Referências

  • man 7 capabilities
  • man 5 lxc.conf

Links