Como Fazer…

Retomando de onde parei, vou falar aqui um pouquinho sobre outros comandos do LXC,  como lxc-create e lxc-destroy.

Os motivos para me restringir a esses comandos no momento é que eles são simples e nos ajudam a ter um maior controle sobre o ambiente em que vamos trabalhar, além do óbvio fato de serem ‘antagônicos’.

Assim, aproveitemos para fixar.

Acessando o manual

Como todo comando em ambientes GNU/Linux, podemos encontrar ajuda para seu uso através de consultas às ‘manpages’, ou páginas de manual.

A manpage do lxc-create nos traz bastante informação:

lxc-create(1)

NAME
lxc-create - creates a container

SYNOPSIS
lxc-create {-n name} [-f config_file] {-t template} [-B backingstore] [-- template-options]

DESCRIPTION
lxc-create creates a system object where is stored the configuration information and where can be stored user information. The identifier name is
used to specify the container to be used with the different lxc commands.

The object is a directory created in /var/lib/lxc and identified by its name.

The object is the definition of the different resources an application can use or can see. The more the configuration file contains information, the
more the container is isolated and the more the application is jailed.

If the configuration file config_file is not specified, the container will be created with the default isolation: processes, sysv ipc and mount
points.

OPTIONS
-f config_file
Specify the configuration file to configure the virtualization and isolation functionalities for the container.

-t template
'template' is the short name of an existing 'lxc-template' script that is called by lxc-create, eg. busybox, debian, fedora, ubuntu or sshd.
Refer to the examples in /usr/share/lxc/templates for details of the expected script structure. Alternatively, the full path to an executable
template script can also be passed as a parameter. "none" can be used to force lxc-create to skip rootfs creation.

-B backingstore
'backingstore' is one of 'dir', 'lvm', 'loop', 'btrfs', 'zfs', or 'best'. The default is 'dir', meaning that the container root filesystem
will be a directory under /var/lib/lxc/container/rootfs. This backing store type allows the optional --dir ROOTFS to be specified, meaning
that the container rootfs should be placed under the specified path, rather than the default. (The 'none' backingstore type is an alias for
'dir'.) If 'btrfs' is specified, then the target filesystem must be btrfs, and the container rootfs will be created as a new subvolume. This
allows snapshotted clones to be created, but also causes rsync --one-filesystem to treat it as a separate filesystem. If backingstore is
'lvm', then an lvm block device will be used and the following further options are available: --lvname lvname1 will create an LV named lvname1
rather than the default, which is the container name. --vgname vgname1 will create the LV in volume group vgname1 rather than the default,
lxc. --thinpool thinpool1 will create the LV as a thin-provisioned volume in the pool named thinpool1 rather than the default, lxc. --fstype
FSTYPE will create an FSTYPE filesystem on the LV, rather than the default, which is ext4. --fssize SIZE will create a LV (and filesystem) of
size SIZE rather than the default, which is 1G.

If backingstore is 'loop', you can use --fstype FSTYPE and --fssize SIZE as 'lvm'. The default values for these options are the same as 'lvm'.

If backingstore is 'best', then lxc will try, in order, btrfs, zfs, lvm, and finally a directory backing store.

-- template-options
This will pass template-options to the template as arguments. To see the list of options supported by the template, you can run lxc-create -t
TEMPLATE -h.

COMMON OPTIONS
These options are common to most of lxc commands.

-?, -h, --help
Print a longer usage message than normal.

--usage
Give the usage message

-q, --quiet
mute on

-P, --lxcpath=PATH
Use an alternate container path. The default is /var/lib/lxc.

-o, --logfile=FILE
Output to an alternate log FILE. The default is no log.

-l, --logpriority=LEVEL
Set log priority to LEVEL. The default log priority is ERROR. Possible values are : FATAL, CRIT, WARN, ERROR, NOTICE, INFO, DEBUG.

Note that this option is setting the priority of the events log in the alternate log file. It do not have effect on the ERROR events log on
stderr.

-n, --name=NAME
Use container identifier NAME. The container identifier format is an alphanumeric string.

--version
Show the version number.

DIAGNOSTIC
The container already exists
As the message mention it, you try to create a container but there is a container with the same name. You can use the lxc-ls command to list
the available containers on the system.

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)

AUTHOR
Daniel Lezcano <daniel.lezcano@free.fr>

Vamos focar na sintaxe do comando:

lxc-create {-n name} [-f config_file] {-t template} [-B backingstore] [-- template-options]

Os parâmetros ‘-f config_file’, ‘-B backingstore’ e ‘–template-options’ são opcionais. Os parametros ‘-n name’, ‘-t template’ são requeridos.

Dos parâmetros opcionais, o ‘-B’ merece atenção especial. Para o lxc o ‘backingstore’ pode ser qualquer de ‘dir’, ‘lvm’, ‘loop’, ‘btrfs’, ‘zfs’, ou ‘best’.
Por padrão o backingstore do lxc, é um diretório no host, /var/lib/lxc/container/rootfs. Podemos alterar o rootfs utilizando outro parâmetro ‘–dir’ especificando o novo rootfs.
As opções de backingstore ‘loop’, ‘btrfs’, ‘lvm’, ‘zfs’ e ‘best’ são um pouco avançadas demais para nossas necessidades atuais.
É interessante saber que estas opções nos dão acesso a recursos como criação de containers em subvolumes, com snapshoting ( captura de estado), entre outras opções restritas a filesystems como btrfs e zfs.

Criando nosso primeiro container

O nosso primeiro container será baseado numa imagem bastante leve, montada com base no template  “lxc-busybox”.

lxc-create --name"busybox-example" -t"busybox"

Tendo criado o container, vamos iniciá-lo e depois ‘entrar’ no ambiente de execução de comandos:

# lxc-start --name"busybox-example"

# lxc-attach --name="busybox-example"

/ # cat /var/log/messages

Dec 27 19:35:49 busybox syslog.info syslogd started: BusyBox v1.22.1
Dec 27 19:35:52 busybox daemon.info init: starting pid 11, tty '/dev/tty1': '/bin/getty -L tty1 115200 vt100'

No trecho acima, após fazer anexar o terminal em execução ao ambiente do container e executarmos um ‘cat /var/log/messages’, vemos como saída um trecho do log comprovando que estamos ‘dentro’ do container e que os comandos ali serão executados em um shell busybox e não no shell de comandos do host.

Faça aí uns experimentos. Há templates para vários linux flavors. Eu tenho alguns containers baseados em Ubuntu e CentOS, só com fins de estudo. Sinta-se livre para criar quantos containers precisar para aprender. Depois que terminar de experimentar, nós os destruímos.

Destruindo  containers

[Editado]

Com nosso container recém-criado, vamos, infelizmente, destruí-lo, mas antes disso, precisamos parar o container, caso ele esteja em execução:

# lxc-stop --name="busybox-example"
# lxc-destroy --name"busybox-example"

Creio já ter falado sobre isso antes, mas se não o fiz, aqui vai.

Embora o LXC seja um recurso exclusivo de ambientes GNU/Linux, existem esforços para criar engines semelhantes para ambientes Windows, Solaris  e ambientes apple OS X possuem o ‘sandbox’ como recurso mais próximo e, alguns dizem,  melhores que o LXC.

Você pode utilizar LXC em ambientes Windows, Mac OS X e Solaris, ou certamente escolher os containers nativos nas suas respectivas plataformas, porém em se tratando de desenvolvedores de software para web, eu recomendaria o uso do LXC e avançando um pouco sobre suas preferências, diria para ‘trocar de plataforma’. Por quê? Simplesmente pelo fato de que embora seja possível utilizar um wrapper como o Docker e virtualizar um ambiente GNU/Linux para utilizar o LXC, seria bem melhor utilizar os recursos de virtualização em nível de SO a partir de um host real e não de uma máquina virtual, sem penalizações de desempenho.