Note

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "LXD/pt-br"

From Funtoo
Jump to navigation Jump to search
(Created page with "LXD")
 
 
(119 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages/>
<languages/>
{{Subpages|GPU Acceleration}}
{{Subpages|Laptop Network Setup,GPU Acceleration,GPU Acceleration (NVIDIA),What are subuids and subgids?,Administration Tutorial,Features and Concepts}}
== Introduction ==
== Introdução ==


LXD is a container "hypervisor" designed to provide an easy set of tools to manage Linux containers, and its development is currently being led by employees at Canonical. You can learn more about the project in general at https://linuxcontainers.org/lxd/ .  
{{Important| Observe que, se você planeja usar o LXD em um laptop, provavelmente está usando WiFi e NetworkManager, e as etapas abaixo ''não'' funcionarão para a configuração da ponte. Consulte [[LXD/Laptop Network Setup]] para diferenças importantes para permitir que você use o LXD no 'modo de desenvolvimento' para uso local de contêineres para desenvolvimento.}}


LXD is currently used for container infrastructure for [[Special:MyLanguage/Funtoo Containers|Funtoo Containers]] and is also very well-supported under Funtoo Linux. For this reason, it's recommended that you check out LXD and see what it can do for you.
O LXD é um "hipervisor" de contêiner projetado para fornecer um conjunto fácil de ferramentas para gerenciar contêineres Linux, e seu desenvolvimento está sendo liderado por funcionários da Canonical. Você pode aprender mais sobre o projeto em geral em https://linuxcontainers.org/lxd/.  


== Basic Setup on Funtoo ==
Atualmente, o LXD é usado para infraestrutura de contêineres para [[Special: MyLanguage/Funtoo Containers|Funtoo Containers]] e também é muito bem suportado no Funtoo Linux. Por esse motivo, é recomendável que você verifique o LXD e veja o que ele pode fazer por você.


The following steps will show you how to set up a basic LXD environment under Funtoo Linux. This environment will essentially use the default LXD setup -- a will be created called {{c|lxdbr0}} which will use NAT to provide Internet access to your containers. In addition, a default storage pool will be created that will simply use your existing filesystem's storage, creating a directory at {{f|/var/lib/lxd/storage-pools/default}} to store any containers you create. More sophisticated configurations are possible that use dedicated network bridges connected to physical interfaces without NAT, as well as dedicated storage pools that use [[Special:MyLanguage/ZFS|ZFS]] and [[Special:MyLanguage/BTRFS|BTRFS]] -- however, these types of configurations are generally overkill for a developer workstation and should only be attempted by advanced users. So we won't cover them here.
== Configuração básica no Funtoo ==


=== Requirements ===
As etapas a seguir mostrarão como configurar um ambiente LXD básico no Funtoo Linux. Esse ambiente usará essencialmente a configuração padrão do LXD -- será criado um chamado {{c|lxdbr0}} que usará NAT para fornecer acesso à Internet aos seus contêineres. Além disso, será criado um pool de armazenamento padrão que simplesmente usará o armazenamento do seu sistema de arquivos existente, criando um diretório em {{f|/var/lib/lxd/storage-pools/default}} para armazenar quaisquer contêineres que você criar. São possíveis configurações mais sofisticadas que usam pontes de rede dedicadas conectadas a interfaces físicas sem NAT, bem como pools de armazenamento dedicados que usam [[Special:MyLanguage/ZFS|ZFS]] e [[Special:MyLanguage/btrfs|btrfs]] -- no entanto, esses tipos de configurações são geralmente um exagero para uma estação de trabalho de desenvolvedor e devem ser tentados apenas por usuários avançados. Então não vamos cobri-los aqui.


This section will guide you through setting up the basic requirements for creating an LXD environment.
=== Requerimentos ===


The first step is to emerge LXD and its dependencies. Perform the following:
Esta seção irá guiá-lo através da configuração dos requisitos básicos para a criação de um ambiente LXD.
 
O primeiro passo é surgir o LXD e suas dependências. Faça o seguinte:


{{console|body=
{{console|body=
Line 21: Line 23:
}}
}}


Once LXD is done emerging, we will want to enable it to start by default:
Quando o LXD terminar de emergir, desejamos permitir que ele inicie por padrão:


{{console|body=
{{console|body=
Line 27: Line 29:
}}
}}


In addition, we will want to set up the following files. {{f|/etc/security/limits.conf}} should be modified to have the following lines in it:
Além disso, queremos configurar os seguintes arquivos. O {{f | /etc/security/limits.conf}} deve ser modificado para ter as seguintes linhas:


{{file|name=/etc/security/limits.conf|body=
{{file|name=/etc/security/limits.conf|body=
Line 39: Line 41:
}}
}}


In addition, we will want to map a set of user ids and group ids to the root user so they are available for its use. Do this by creating the {{f|/etc/subuid}} and {{f|/etc/subgid}} files with the following identical contents:
Em seguida, chegamos ao conceito de "subuid" e "subgid". Normalmente, um usuário receberá um ID de usuário e um ID de grupo. Subids e subgids nos permitem atribuir UIDs e GIDs adicionais a um usuário para uso próprio.
Por padrão, o LXD alocará subuids para o usuário root, o que equivale a criar os seguintes arquivos no sistema de arquivos root:


{{file|name=/etc/subuid|body=
{{file|name=/etc/subuid|body=
root:100000:1000000000
root:1000000:10000000000
}}
}}


{{file|name=/etc/subgid|body=
{{file|name=/etc/subgid|body=
root:100000:1000000000
root:1000000:10000000000
}}
}}


At this point we are ready to initialize and start LXD.
O formato de ambos os arquivos é "user":"start":"count". Significando que o usuário {{c|root}} receberá IDs "count" começando na posição "start". A razão pela qual o LXD faz isso é porque esses IDs extras serão usados para isolar contêineres dos processos do host e, opcionalmente, uns dos outros, usando diferentes deslocamentos para que seus UID e GIDs não se sobreponham. Com o LXD 5, agora essas configurações já estão "prontas", esses arquivos não precisam ser criados e existem aqui apenas para referência e compreensão do comportamento padrão do LXD. Para obter mais informações sobre subids e subgids, consulte [[LXD/What are subuids and subgids?|What are subuids and subgids?]].


==== LXD-in-LXD ====


=== Initialization ===
A única vez que você precisará definir {{f|/etc/subuid}} e {{f|/etc/subgid}} é agora, e se você estiver executando "LXD-in-LXD". Nesse caso, o LXD interno (dentro do contêiner) precisará reduzir esses mapeamentos subuid e subgid, pois o intervalo completo não estará disponível. Isso deve ser possível simplesmente usando as seguintes configurações em sua instância LXD em contêiner:


To configure LXD, first we will need to start LXD. This can be done as follows:
{{file|name=/etc/subuid|body=
root:65537:70000
}}
 
{{file|name=/etc/subgid|body=
root:65537:70000
}}
 
Se você não estiver usando recursos avançados do LXD, sua instância LXD-in-LXD agora deve ter mapeamentos de id suficientes para isolar contêineres do contêiner do host. O único restante
A etapa para LXD-in-LXD seria permitir que o contêiner do host aninhasse:
 
{{console|body=
# ##i##lxc config set host-container security.nesting true
}}
 
Isso permitirá que o próprio host-container contenha contêineres :)
 
=== Inicialização ===
 
Para configurar o LXD, primeiro precisaremos iniciar o LXD. Isso pode ser feito da seguinte forma:


{{console|body=
{{console|body=
Line 60: Line 83:
}}
}}


At this point, we can run {{c|lxd init}} to run a configuration wizard to set up LXD:
Neste ponto, podemos executar o {{c|lxd init}} para executar um assistente de configuração para configurar o LXD:


{{console|body=
{{console|body=
Line 67: Line 90:
Do you want to configure a new storage pool? (yes/no) [default=yes]: ##i##↵
Do you want to configure a new storage pool? (yes/no) [default=yes]: ##i##↵
Name of the new storage pool [default=default]: ##i##↵
Name of the new storage pool [default=default]: ##i##↵
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: ##i##dir↵
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: ##i##dir ↵
Would you like to connect to a MAAS server? (yes/no) [default=no]: ##i##↵
Would you like to connect to a MAAS server? (yes/no) [default=no]: ##i##↵
Would you like to create a new local network bridge? (yes/no) [default=yes]: ##i##↵
Would you like to create a new local network bridge? (yes/no) [default=yes]: ##i##↵
What should the new bridge be called? [default=lxdbr0]: ##i##↵
What should the new bridge be called? [default=lxdbr0]: ##i##↵
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##↵
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##↵
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##↵
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##none ↵
Would you like LXD to be available over the network? (yes/no) [default=no]: ##i##↵
Would you like LXD to be available over the network? (yes/no) [default=no]: ##i##↵
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] ##i##↵
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] ##i##↵
Line 79: Line 102:
}}
}}


As you can see, we chose all the default 'except' for storage pool, where we opted for using a directory-based container
Como você pode ver, escolhemos todos os padrões ''exceto'' para:
storage rather than [[Special:MyLanguage/BTRFS|BTRFS]]. Now, we should be able to run {{c|lxc image list}} and get a response from the LXD daemon:
;pool de armazenamento: Optamos por usar um armazenamento de contêiner baseado em diretório em vez de volumes [[Special:MyLanguage/btrfs|btrfs]]. Baseado em diretório pode ser a opção padrão durante a configuração do LXD -- depende se você tem o btrfs-tools instalado ou não.
;Endereço IPv6: É recomendado que você desative isso, a menos que você queira especificamente usar IPv6 em seus contêineres. Isso pode fazer com que {{c|dhcpcd}} em seu contêiner recupere apenas um endereço IPv6 se você o deixar ativado. Isso é ótimo se você tiver o IPv6 funcionando - caso contrário, você obterá um endereço IPv6 inválido e nenhum endereço IPv4 e, portanto, nenhuma rede.
 
{{Warning|Como explicado acima, desative o IPv6 NAT no LXD, a menos que você pretenda usá-lo especificamente! Isso pode confundir {{c|dhcpcd}}.}}
 
Se você optar por gerar a configuração ''YAML lxd init preseed'' do comando {{c|lxd init}} acima, aqui está um exemplo de configuração:
 
{{file|name=lxc_init_preseed.yaml|lang=YAML|desc=lxc init preseed config example|body=
config:
  images.auto_update_interval: "0"
networks:
- config:
    ipv4.address: auto
    ipv6.address: none
  description: ""
  name: lxdbr0
  type: ""
  project: default
storage_pools:
- config: {}
  description: ""
  name: default
  driver: dir
profiles:
- config: {}
  description: ""
  devices:
    eth0:
      name: eth0
      network: lxdbr0
      type: nic
    root:
      path: /
      pool: funtoo
      type: disk
  name: default
projects: []
cluster: null
}}
 
Agora, devemos ser capazes de executar {{c|lxc image list}} e obter uma resposta do daemon LXD:


{{console|body=
{{console|body=
# ##i##lxc image list
# ##i##lxc image list
+-------+-------------+--------+-------------+------+------+-------------+
+-------+-------------+--------+-------------+------+------+-------------+
{{!}}
{{!}} ALIAS {{!}} FINGERPRINT {{!}} PUBLIC {{!}} DESCRIPTION {{!}} ARCH {{!}} SIZE {{!}} UPLOAD DATE {{!}}
ALIAS {{!}} FINGERPRINT {{!}} PUBLIC {{!}} DESCRIPTION {{!}} ARCH {{!}} SIZE {{!}} UPLOAD DATE {{!}}
+-------+-------------+--------+-------------+------+------+-------------+
+-------+-------------+--------+-------------+------+------+-------------+
#
#
}}
}}
Se você conseguir fazer isso, você configurou com sucesso as partes principais do LXD! Observe que usamos o comando {{c|lxc}} e não {{c|lxd}} como fizemos para {{c|lxd init}} -- deste ponto em diante, você usará o comando {{c|lxc }}. Não deixe isso confundir você -- o comando {{c|lxc}} é a principal ferramenta de linha de comando para trabalhar com contêineres LXD.


If you are able to do this, you have successfully set up the core parts of LXD! Note that we used the command {{c|lxc}} and not {{c|lxd}} like we did for {{c|lxd init}} -- from this point forward, you will use the {{c|lxc}} command. Don't let this
Acima, você pode ver que nenhuma imagem está instalada. Imagens são instantâneos instaláveis de contêineres que podemos usar para criar novos contêineres. Então, como primeiro passo, vamos em frente e pegue uma imagem que possamos usar. Você deseja procurar em  https://build.funtoo.org em busca de uma imagem LXD que funcione no hardware do seu computador. Por exemplo, eu consegui baixar o seguinte arquivo usando o {{c |wget}}:
confuse you -- the {{c|lxc}} command is the primary command-line tool for working with LXD containers.
 
Above, you can see that no images are installed. Images are installable snapshots of containers that we can use to create new containers ourselves. So, as a first step, let's go ahead and grab an image we can use. You will want to browse https://build.funtoo.org for an LXD image that will work on your computer hardware. For example, I was able to download
the following file using {{c|wget}}:


{{console|body=
{{console|body=
# ##i##wget https://build.funtoo.org/1.3-release-std/x86-64bit/intel64-skylake/lxd-intel64-skylake-1.3-release-std-2019-06-11.tar.xz
# ##i##wget https://build.funtoo.org/1.4-release-std/x86-64bit/amd64-zen2/2022-04-13/lxd-amd64-zen2-1.4-release-std-2022-04-13.tar.xz
}}
}}


Once downloaded, this image can be installed using the following command:
Uma vez baixada, esta imagem pode ser instalada usando o seguinte comando:
{{console|body=
{{console|body=
# ##i##lxc image import lxd-intel64-skylake-1.3-release-std-2019-06-11.tar.xz --alias funtoo
# ##i##lxc image import lxd-amd64-zen2-1.4-release-std-2022-04-13.tar.xz --alias funtoo
Image imported with fingerprint: fe4d27fb31bfaf3bd4f470e0ea43d26a6c05991de2a504b9e0a3b1a266dddc69
Image imported with fingerprint: fe4d27fb31bfaf3bd4f470e0ea43d26a6c05991de2a504b9e0a3b1a266dddc69
}}
}}


Now you will see the image available in our image list:
Agora você verá a imagem disponível em nossa lista de imagens:


{{console|body=
{{console|body=
# ##i##lxc image list
# ##i##lxc image list
+--------+--------------+--------+--------------------------------------------+--------+----------+------------------------------+
+--------+--------------+--------+-----------------------------------------+--------------+-----------+----------+------------------------------+
{{!}}
| ALIAS  | FINGERPRINT  | PUBLIC |              DESCRIPTION               | ARCHITECTURE |  TYPE    |   SIZE  |         UPLOAD DATE          |
ALIAS  {{!}} FINGERPRINT  {{!}} PUBLIC {{!}}                DESCRIPTION                 {{!}}  ARCH  {{!}}   SIZE  {{!}}         UPLOAD DATE          {{!}}
+--------+--------------+--------+-----------------------------------------+--------------+-----------+----------+------------------------------+
+--------+--------------+--------+--------------------------------------------+--------+----------+------------------------------+
| funtoo | b8eaa7e30c14 | no    | 1.4 Release Zen2 64bit [std] 2022-04-13 | x86_64       | CONTAINER | 342.13MB | Apr 29, 2022 at 9:36pm (UTC) |
{{!}}
+--------+--------------+--------+-----------------------------------------+--------------+-----------+----------+------------------------------+
funtoo {{!}} fe4d27fb31bf {{!}} no    {{!}} 1.3 Release Skylake 64bit [std] 2019-06-14 {{!}} x86_64 {{!}} 279.35MB {{!}} Jun 15, 2019 at 3:09am (UTC) {{!}}
+--------+--------------+--------+--------------------------------------------+--------+----------+------------------------------+
#
#
}}
}}


=== Primeiro Container ===


=== First Containeer ===
Agora é hora de lançar nosso primeiro contêiner. Isso pode ser feito da seguinte forma:
 
It is now time to launch our first container. This can be done as follows:


{{console|body=
{{console|body=
Line 132: Line 189:
}}
}}


We can now see the container running via {{c|lxc list}}:
Agora podemos ver o contêiner sendo executado via {{c |lxc list}}:


{{console|body=
{{console|body=
# ##i##lxc list
# ##i##lxc list
+---------------+---------+------+-----------------------------------------------+------------+-----------+
+---------------+---------+------+-----------------------------------------------+------------+-----------+
{{!}}
{{!}} NAME         {{!}}  STATE  {{!}} IPV4 {{!}}                    IPV6                      {{!}}    TYPE    {{!}} SNAPSHOTS {{!}}
    NAME     {{!}}  STATE  {{!}} IPV4 {{!}}                    IPV6                      {{!}}    TYPE    {{!}} SNAPSHOTS {{!}}
+---------------+---------+------+-----------------------------------------------+------------+-----------+
+---------------+---------+------+-----------------------------------------------+------------+-----------+
{{!}}
{{!}} testcontainer {{!}} RUNNING {{!}}      {{!}} fd42:8063:81cb:988c:216:3eff:fe2a:f901 (eth0) {{!}} PERSISTENT {{!}}          {{!}}
testcontainer {{!}} RUNNING {{!}}      {{!}} fd42:8063:81cb:988c:216:3eff:fe2a:f901 (eth0) {{!}} PERSISTENT {{!}}          {{!}}
+---------------+---------+------+-----------------------------------------------+------------+-----------+
+---------------+---------+------+-----------------------------------------------+------------+-----------+
#
#
}}
}}
 
Por padrão, nosso novo contêiner {{c |testcontainer}} usará o perfil padrão, que conectará uma interface {{c |eth0}} no contêiner ao NAT e também usará nosso pool de armazenamento LXD baseado em diretório. Agora podemos entrar no contêiner da seguinte maneira:
By default, our new container {{c|testcontainer}} will use the default profile, which will connect an {{c|eth0}} interface in the container to NAT, and will also use our directory-based LXD storage pool. We can now enter the container as follows:


{{console|body=
{{console|body=
Line 153: Line 207:
}}
}}


As you might have noticed, we do not yet have any IPv4 networking configured. While LXD has set up a bridge and NAT for us, along with a DHCP server to query, we actually need to use {{c|dhcpcd}} to query for an IP address, so let's get that set up:
Como você deve ter notado, ainda não temos nenhuma rede IPv4 configurada. Embora o LXD tenha configurado uma ponte e um NAT para nós, juntamente com um servidor DHCP para consulta, na verdade, precisamos usar o {{c |dhcpcd}} para procurar um endereço IP, então vamos configurá-lo:


{{console|body=
{{console|body=
Line 169: Line 223:
}}
}}


You can now see that {{c|eth0}} has a valid IPv4 address:
Agora você pode ver que {{c | eth0}} tem um endereço IPv4 válido:


{{console|body=
{{console|body=
Line 184: Line 238:
}}
}}


Time to have some fun!
O que aconteceu é que o LXD configurou um servidor DHCP para nós (dnsmasq) rodando em nossa rede privada de containers, e automaticamente oferece endereços IP para nossos containers. Ele também configurou o iptables para NAT na conexão para que o acesso de saída à Internet funcione magicamente.
 
Você também poderá ver esse endereço IPv4 listado na lista de contêineres quando digitar {{c|lxc list}} em seu sistema host.
{{console|body=
%testcontainer% ##i##ego sync
}}
 
 
== Another Nice LXD Administration Tutorial ==
 
This section contains another nice LXD tutorial that can be used to learn more about profiles and other features of LXD.
 
 
=== Terminology ===
 
Container '''snapshots''' as the name states snapshots of the container in time and cannot be modified in any way. It is worth noting that because snapshots can store the container runtime state, which gives us ability of “stateful” snapshots. That is, the ability to rollback the container including its cpu and memory state at the time of the snapshot.
 
LXD is '''image''' based, all LXD containers come from an image. Images are typically clean Linux distribution images similar to what you would use for a virtual machine or cloud instance. It is possible to “publish” a container, making an image from it which can then be used by the local or remote LXD hosts.
 
 
=== Our first image ===
 
Let's get our hands even more dirty and create our first image. We will be using a generic 64 bit Funtoo Linux image.
 
{{note|The Funtoo's default build host is building only westmere stage for now.}}
 
Grab the image here:
https://build.funtoo.org/funtoo-current/x86-64bit/intel64-westmere/lxd-latest.tar.xz
 
Grab also the hash file:
https://build.funtoo.org/funtoo-current/x86-64bit/intel64-westmere/lxd-latest.tar.xz.hash.txt
 
{{tip|Check the hash of the downloaded file against the one from server. Proceed if they match. }}
 
 
==== Import the image ====
 
After we have successfully downloaded the archive we can now finally import it into LXD and start using it as our "seed" image for all our containers.
{{console|body=
###i## lxc image import lxd-latest.tar.xz --alias funtoo
Image imported with fingerprint: 6c2ca3af0222d503656f5a1838885f1b9b6aed2c1994f1d7ef94e2efcb7233c4
###i## lxc image ls
<nowiki>+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+
| ALIAS  | FINGERPRINT  | PUBLIC |            DESCRIPTION            |  ARCH  |  SIZE  |        UPLOAD DATE        |
+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+
| funtoo | 6c2ca3af0222 | no    | Funtoo Current Generic Pure 64-bit | x86_64 |227.99MB  | Dec 13, 2017 at 11:01pm (UTC)  |
+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+
</nowiki>}}
And there we have our very first Funtoo Linux image imported inside LXD.  You can reference the image through the alias or through the fingerprint. Aliases can be added also later.
 
Let me show you some basic usage then.
 
 
=== Creating your first container ===
 
So now we can launch our first container. That is done using this command:
 
{{console|body=
###i## lxc launch funtoo fun-1
Creating fun-1
Starting fun-1
###i##  lxc ls
<nowiki>+-------+---------+------+-----------------------------------------------+------------+-----------+
| NAME  |  STATE  | IPV4 |                    IPV6                      |    TYPE    | SNAPSHOTS |
+-------+---------+------+-----------------------------------------------+------------+-----------+
| fun-1 | RUNNING |      | fd42:156d:4593:a619:216:3eff:fef7:c1c2 (eth0) | PERSISTENT | 0        |
+-------+---------+------+-----------------------------------------------+------------+-----------+
</nowiki>}}
 
{{tip|lxc launch is a shortcut for lxc init and lxc start, lxc init creates the container without starting it. }}
 
 
==== Profiles intermezzo ====
 
LXD has the ability to change quite a few container settings, including resource limitation, control of container startup and a variety of device pass-through options using what is called profiles. Multiple profiles can be applied to a single container, and the last profile overrides the other ones it the resources being configured is the same for multiple profiles. Let me show you how can this be used.
 
This is the default profile that gets inherited by all containers.
{{console|body=
###i## lxc profile list
<nowiki>+---------+---------+
|  NAME  | USED BY |
+---------+---------+
| default | 1      |
+---------+---------+
</nowiki>
###i##  lxc profile show default
config: {}
description: Default LXD profile
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default
used_by:
- /1.0/containers/fun-1
}}
 
Now let's edit this profile for our funtoo containers. It will include some useful stuff.


{{console|body=
=== Solução de problemas de rede ===
###i## lxc profile set default raw.lxc "lxc.mount.entry = none dev/shm tmpfs rw,nosuid,nodev,create=dir"
###i## lxc profile set default environment.LANG "en_US.UTF-8"
###i## lxc profile set default environment.LC_ALL "en_US.UTF-8"
###i## lxc profile set default environment.LC_COLLATE "POSIX"
}}
 
Profiles can store any configuration that a container can (key/value or devices) and any number of profiles can be applied to a container. Profiles are applied in the order they are specified so the last profile to specify a specific key wins. In any case, resource-specific configuration always overrides that coming from the profiles.
 
The default profile is set for any new container created which doesn't specify a different profiles list.
 
{{note|LXD supports simple instance types. Those are represented as a string which can be passed at container creation time. [https://github.com/lxc/lxd/blob/master/doc/containers.md#instance-types containers.md#instance-types]}}
 
 
=== Using our first container ===
 
After we have done all these customizations we can now start using our container.
The next command will give us shell inside the container.


{{console|body=
{{warning| Prossiga com cautela. Estes são comandos LXC avançados que podem modificar o estado da configuração da sua rede local LXD. Em cenários extremos, o roteamento NAT de todas as redes de seus contêineres LXD pode facilmente quebrar tudo se o valor da chave de configuração LXC errado for alterado}}
###i## lxc exec fun-1 bash
}}


Now you should see a different prompt starting with
Observe que, se você estiver tendo problemas com seu contêiner para obter um endereço IPv4 via DHCP, certifique-se de desativar o IPv6 no LXD. Fazemos isto executando:


{{console|body=
{{console|body=
fun-1 ~ #
###i## lxc network edit lxdbr0
}}
}}


If we run top or ps for example we will see only the processes of the container.
Em seguida, altere o valor da chave YAML {{c|ipv6.nat}} para {{c|"false"}} e reinicie o LXD e o contêiner de teste:


{{console|body=
{{console|body=
fun-1 ~ # ps aux
###i## /etc/init.d/lxd restart
USER      PID %CPU %MEM    VSZ  RSS TTY      STAT START  TIME COMMAND
###i## lxc restart testcontainer
root        1  0.0  0.0  4248  748 ?        Ss+  13:20  0:00 init [3]
root      266  0.0  0.0  30488  472 ?        Ss  13:20  0:00 /usr/sbin/sshd
root      312  0.2  0.0  17996  3416 ?        Ss  13:29  0:00 bash
root      317  0.0  0.0  19200  2260 ?        R+  13:29  0:00 ps aux
}}
}}


As you can see only the container's processes are shown. User running the processes is root here. What happens if we search for all sshd processes for example on the host box?
Isto deve resolver o problema.


{{console|body=
{{important| Se você inicializou seu cluster LXD desativando o IPv6 com a opção ''Qual endereço IPv6 deve ser usado?'' definida como {{c|none (nenhum)}}, então o {{c|ipv6.nat}} nem estará presente na interface de ponte {{c|lxdbr0}} da nossa rede local LXC.
###i## <nowiki>ps aux|grep ssh
root    14505  0.0  0.0  30564  1508 ?        Ss  Sep07  0:00 /usr/sbin/sshd 
100000  25863  0.0  0.0  30488  472 ?        Ss  15:20  0:00 /usr/sbin/sshd 
root    29487  0.0  0.0  8324  828 pts/2    S+  15:30  0:00 grep --colour=auto sshd</nowiki>
###i##
}}


So as you can see, the sshd process is running under user with uid 100000 on the host machine and has a different PID.
Tenha cuidado para não adulterar a configuração {{c|ipv4.nat}} ou todo o roteamento NAT do contêiner LXD será interrompido, significando que nenhum tráfego de rede em execução e novos contêineres LXD poderão ser roteados para Internet!}}


Aqui está um exemplo de YAML de um dispositivo de ponte de rede local LXC padrão {{c|lxdbr0}} para referência:


=== Basic actions with containers ===
{{file|name=lxc_lxdbr0.yaml|lang=YAML|desc=lxc network edit lxdbr0|body=
 
 
==== Listing containers ====
 
{{console|body=
###i##  lxc ls
<nowiki>+-------+---------+-----------------------+------------------------------------------------+------------+-----------+
| NAME  |  STATE  |        IPV4          |                      IPV6                      |    TYPE    | SNAPSHOTS |
+-------+---------+-----------------------+------------------------------------------------+------------+-----------+
| fun-1 | RUNNING | 10.214.101.187 (eth0) | fd42:156d:4593:a619:a5ad:edaf:7270:e6c4 (eth0) | PERSISTENT | 0        |
|      |        |                      | fd42:156d:4593:a619:216:3eff:fef7:c1c2 (eth0)  |            |          |
+-------+---------+-----------------------+------------------------------------------------+------------+-----------+
</nowiki>}}
lxc ls also accepts arguments as filters. For example lxc ls web will list all containers that have web in their name.
 
 
==== Container details ====
 
{{console|body=
###i## lxc info c1
Name: c1
Remote: unix://
Architecture: x86_64
Created: 2017/09/08 02:07 UTC
Status: Running
Type: persistent
Profiles: default, prf-funtoo
Pid: 6366
Ips:
  eth0: inet    10.214.101.79  vethFG4HXG
  eth0: inet6  fd42:156d:4593:a619:8619:546e:43f:2089  vethFG4HXG
  eth0: inet6  fd42:156d:4593:a619:216:3eff:fe4a:3d4f  vethFG4HXG
  eth0: inet6  fe80::216:3eff:fe4a:3d4f        vethFG4HXG
  lo:  inet    127.0.0.1
  lo:  inet6  ::1
Resources:
  Processes: 6
  CPU usage:
    CPU usage (in seconds): 25
  Memory usage:
    Memory (current): 69.01MB
    Memory (peak): 258.92MB
  Network usage:
    eth0:
      Bytes received: 83.65kB
      Bytes sent: 9.44kB
      Packets received: 188
      Packets sent: 93
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0
}}
 
 
==== Container configuration ====
 
{{console|body=
###i##  lxc config edit c1
### This is a yaml representation of the configuration.
### Any line starting with a '# will be ignored.
###
### A sample configuration looks like:
### name: container1
### profiles:
### - default
### config:
###  volatile.eth0.hwaddr: 00:16:3e:e9:f8:7f
### devices:
###  homedir:
###    path: /extra
###    source: /home/user
###    type: disk
### ephemeral: false
###
### Note that the name is shown but cannot be changed
 
architecture: x86_64
config:
config:
   image.architecture: x86_64
   ipv4.address: 10.239.139.1/24
  image.description: Funtoo Current Generic Pure 64-bit
   ipv4.nat: "true"
  image.name: funtoo-generic_64-pure64-funtoo-current-2016-12-10
   ipv6.address: none
  image.os: funtoo
  image.release: "1.0"
  image.variant: current
  volatile.base_image: e279c16d1a801b2bd1698df95e148e0a968846835f4769b24988f2eb3700100f
  volatile.eth0.hwaddr: 00:16:3e:4a:3d:4f
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
   volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
   volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
- prf-funtoo
stateful: false
description: ""
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/profiles/default
- /1.0/instances/funtoo-livestream
managed: true
status: Created
locations:
- none
}}
}}


One can also add environment variables.
=== Finalizando ===
{{console|body=
###i## lxc config set <container> environment.LANG en_US.UTF-8
###i## lxc config set <container> environment.LC_COLLATE POSIX
}}
 
 
=== Managing files ===
 
 
=== Snapshots ===
 
 
=== Cloning, copying and moving containers ===
 
 
=== Resource control ===
 
LXD offers a variety of resource limits. Some of those are tied to the container itself, like memory quotas, CPU limits and I/O priorities. Some are tied to a particular device instead, like I/O bandwidth or disk usage limits.
 
As with all LXD configuration, resource limits can be dynamically changed while the container is running. Some may fail to apply, for example if setting a memory value smaller than the current memory usage, but LXD will try anyway and report back on failure.
 
All limits can also be inherited through profiles in which case each affected container will be constrained by that limit. That is, if you set limits.memory=256MB in the default profile, every container using the default profile (typically all of them) will have a memory limit of 256MB.
 
 
==== Disk ====
 
Setting a size limit on the container’s filesystem and have it enforced against the container. Right now LXD only supports disk limits if you’re using the ZFS or btrfs storage backend.
 
To set a disk limit (requires btrfs or ZFS):


Supondo que sua rede esteja funcionando agora, você está pronto para começar a usar seu novo contêiner Funtoo. Hora de ter alguma diversão! Vá em frente e execute {{c|ego sync}} e, em seguida, emerja suas coisas favoritas:
{{console|body=
{{console|body=
###i## lxc config device set c1 root size 20GB
%testcontainer% ##i##ego sync
}}
\##g##Syncing meta-repo
Cloning into '/var/git/meta-repo'...


==== CPU ====
To just limit a container to any 2 CPUs, do:
{{console|body=
###i## lxc config set c1 limits.cpu 2
}}
To pin to specific CPU cores, say the second and fourth:
{{console|body=
###i## lxc config set c1 limits.cpu 1,3
}}
More complex pinning ranges like this works too:
{{console|body=
###i## lxc config set c1 limits.cpu 0-3,7-11
}}
}}
 
[[Category:Containers]]
 
[[Category:LXD]]
==== Memory ====
 
To apply a straightforward memory limit run:
 
{{console|body=
###i## lxc config set c1 limits.memory 256MB
}}
 
(The supported suffixes are kB, MB, GB, TB, PB and EB)
 
To turn swap off for the container (defaults to enabled):
 
{{console|body=
###i## lxc config set c1 limits.memory.swap false
}}
To tell the kernel to swap this container’s memory first:
 
{{console|body=
###i## lxc config set c1 limits.memory.swap.priority 0
}}
And finally if you don’t want hard memory limit enforcement:
 
{{console|body=
###i## lxc config set c1 limits.memory.enforce soft
}}
 
 
==== Network ====
 
 
==== Block I/O ====
 
 
=== Resource limits using profile - Funtoo Containers example ===
 
So I am going to create 3 profiles to mimic the resource limits for current Funtoo Containers.
 
{{TableStart}}
<tr class="danger"><th>Price</th><th>RAM</th><th>CPU Threads</th><th>Disk Space</th><th>Sign Up</th></tr>
<tr><td>'''$15/mo'''</td><td>4GB</td><td>6 CPU Threads</td><td>50GB</td><td>[https://funtoo.chargebee.com/hosted_pages/plans/container_small Sign Up! (small)]</td></tr>
<tr><td>'''$30/mo'''</td><td>12GB</td><td>12 CPU Threads</td><td>100GB</td><td>[https://funtoo.chargebee.com/hosted_pages/plans/container_medium Sign Up! (medium)]</td></tr>
<tr><td>'''$45/mo'''</td><td>48GB</td><td>24 CPU Threads</td><td>200GB</td><td>[https://funtoo.chargebee.com/hosted_pages/plans/container_large Sign Up! (large)]</td></tr>
{{TableEnd}}
 
I am going to create one profile and copy/edit it for the remaining two options.
 
{{console|body=
###i## lxc profile create res-small
###i## lxc profile edit res-small
config:
  limits.cpu: "6"
  limits.memory: 4GB
description: Small Variant of Funtoo Containers
devices:
  root:
    path: /
    pool: default
    size: 50GB
    type: disk
name: small
used_by: []
###i## lxc profile copy res-small res-medium
###i## lxc profile copy res-small res-large
###i## lxc profile set res-medium limits.cpu 12
###i## lxc profile set res-medium limits.memory 12GB
###i## lxc profile device set res-medium root size 100GB
###i## lxc profile set res-large limits.cpu 24
###i## lxc profile set res-large limits.memory 48GB
###i## lxc profile device set res-large root size 200GB
}}
Now let's create a container and assign the res-small and funtoo profiles to it.
{{console|body=
###i## lxc init funtoo c-small
###i## lxc profile assign c-small res-small
###i## lxc profile add c-small funtoo
}}
 
 
=== Image manipulations ===
 
 
=== Remote hosts ===
 
 
== Running systemd container on a non-systemd host ==
 
To use systemd in the container, a recent enough (>=4.6) kernel version with support for cgroup namespaces is needed. Funtoo's openrc has the fix to mount systemd cgroups, which is sufficient to run systemd based distributions lxd containers.
 
If you want to get <code>systemd</code> hierarchy mounted automatically on system startup, using <code>/etc/fstab</code> will not work, but the
{{Package|dev-libs/libcgroup}}
can be used for this. First you needed to edit the <code>/etc/cgroup/cgconfig.conf</code> and add:
{{file|name=/etc/cgroup/cgconfig.conf|body=mount {
    "name=systemd" = /sys/fs/cgroup/systemd;
}
}}
Then you need to start the cgconfig daemon:
{{console|body=
###i## rc-service cgconfig start
}}
The daemon can be started as needed, or automatically at system start by simply adding it to default group:
{{console|body=
###i## rc-update add cgconfig default
}}
 
<hr>
<hr>
 
 
== [[Special:MyLanguage/LXD/LXD in LXD|PART X - LXD in LXD]] ==
 
 
== [[Special:MyLanguage/LXD/Docker in LXD|PART Y - Docker in LXD]] ==
 
 
== [[Special:MyLanguage/LXD/FAQ|PART Z - LXD FAQ]] ==
 
 
== List of tested and working images ==
 
These are images from the https://images.linuxcontainers.org repository available by default in lxd. You can
list all available images by typing following command (beware the list is very long):
{{console|body=
###i## lxc image list images:
<nowiki>+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
|              ALIAS              | FINGERPRINT  | PUBLIC |              DESCRIPTION                |  ARCH  |  SIZE  |          UPLOAD DATE          |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.3 (3 more)            | ef69c8dc37f6 | yes    | Alpine 3.3 amd64 (20171018_17:50)        | x86_64  | 2.00MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.3/armhf (1 more)      | 5ce4c80edcf3 | yes    | Alpine 3.3 armhf (20170103_17:50)        | armv7l  | 1.53MB  | Jan 3, 2017 at 12:00am (UTC)  |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.3/i386 (1 more)        | cd1700cb7c97 | yes    | Alpine 3.3 i386 (20171018_17:50)        | i686    | 1.84MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.4 (3 more)            | bd4f1ccfabb5 | yes    | Alpine 3.4 amd64 (20171018_17:50)        | x86_64  | 2.04MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.4/armhf (1 more)      | 9fe7c201924c | yes    | Alpine 3.4 armhf (20170111_20:27)        | armv7l  | 1.58MB  | Jan 11, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.4/i386 (1 more)        | 188a31315773 | yes    | Alpine 3.4 i386 (20171018_17:50)        | i686    | 1.88MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.5 (3 more)            | 63bebc672163 | yes    | Alpine 3.5 amd64 (20171018_17:50)        | x86_64  | 1.70MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
| alpine/3.5/i386 (1 more)        | 48045e297515 | yes    | Alpine 3.5 i386 (20171018_17:50)        | i686    | 1.73MB  | Oct 18, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
...
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
|                                | fd95a7a754a0 | yes    | Alpine 3.5 amd64 (20171016_17:50)        | x86_64  | 1.70MB  | Oct 16, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
|                                | fef66668f5a2 | yes    | Debian stretch arm64 (20171016_22:42)    | aarch64 | 96.56MB  | Oct 16, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
|                                | ff18aa2c11d7 | yes    | Opensuse 42.3 amd64 (20171017_00:53)    | x86_64  | 58.92MB  | Oct 17, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
|                                | ff4ef0d824b6 | yes    | Ubuntu zesty s390x (20171017_03:49)      | s390x  | 86.88MB  | Oct 17, 2017 at 12:00am (UTC) |
+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+
</nowiki>}}
 
These are the images that are known to work with current LXD setup on Funtoo Linux:
{| class="wikitable sortable"
|-
! Image  !! Init !! Status
|-
| CentOS 7 || systemd || Working
|-
| Debian Jessie (8) - EOL  April/May 2020|| systemd || Working (systemd - no failed units)
|-
| Debian Stretch (9) - EOL June 2022|| systemd || Working
|-
| Fedora 26 || systemd with cgroup v2|| Not Working
|-
| Fedora 25 || systemd || Working
|-
| Fedora 24 || systemd || Working
|-
| Oracle 7 || systemd || Working (systemd - no failed units)
|-
| OpenSUSE 42.2 || systemd || Working
|-
| OpenSUSE 42.3 || systemd || Working
|-
| Ubuntu Xenial (16.04 LTS) - EOL 2021-04 || systemd || Working
|-
| Ubuntu Zesty (17.04) - EOL 2018-01 || systemd || Working
|-
| Alpine 3.3 || OpenRC || Working
|-
| Alpine 3.4 || OpenRC || Working
|-
| Alpine 3.5 || OpenRC || Working
|-
| Alpine 3.6 || OpenRC || Working
|-
| Alpine Edge || OpenRC || Working
|-
| Archlinux || systemd with cgroup v2 || Not Working
|-
| CentOS 6 || upstart || Working (systemd - no failed units)
|-
| Debian Buster || systemd with cgroup v2 || Not Working
|-
| Debian Sid || systemd with cgroup v2 || Not working
|-
| Debian Wheezy (7) - EOL May 2018 || ? || ? (more testing needed)
|-
| Gentoo || OpenRC || Working (all services started)
|-
| Oracle 6 || upstart || ? (mount outputs nothing)
|-
| Plamo 5 || ? || ?
|-
| Plamo 6 || ? || ?
|-
| Sabayon || systemd with cgroup v2 || Not Working
|-
| Ubuntu Artful (17.10) - EOL 2018-07|| systemd with cgroup v2 || Not Working
|-
| Ubuntu Core 16 || ? || ?
|-
| Ubuntu Trusty (14.04 LTS) - EOL 2019-04 || upstart || Working
|}
 
 
== Features ==
 
Some of the biggest features of LXD are:
 
* Secure by design (unprivileged containers, resource restrictions and much more)
* Scalable (from containers on your laptop to thousand of compute nodes)
* Intuitive (simple, clear API and crisp command line experience)
* Image based (no more distribution templates, only good, trusted images)
* Live migration
 
 
==== Unprivileged Containers ====
 
LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level).
 
The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container.
 
The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them.
 
From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user.
 
LXD does offer a number of options related to unprivileged configuration:
 
* Increasing the size of the default uid/gid map
* Setting up per-container maps
* Punching holes into the map to expose host users and groups
 
 
=== Relationship with LXC ===
 
LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding
to create and manage the containers.
 
It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network.
 
[[Category:Virtualization]]
[[Category:Official Documentation]]
[[Category:Official Documentation]]
[[Category:First Steps]]

Latest revision as of 19:01, October 12, 2022

Other languages:
English • ‎português do Brasil • ‎中文（中国大陆）‎
Subpages:
Laptop Network Setup
GPU Acceleration
GPU Acceleration (NVIDIA)
What are subuids and subgids?
Administration Tutorial
Features and Concepts

Introdução

   Important
Observe que, se você planeja usar o LXD em um laptop, provavelmente está usando WiFi e NetworkManager, e as etapas abaixo não funcionarão para a configuração da ponte. Consulte LXD/Laptop Network Setup para diferenças importantes para permitir que você use o LXD no 'modo de desenvolvimento' para uso local de contêineres para desenvolvimento.

O LXD é um "hipervisor" de contêiner projetado para fornecer um conjunto fácil de ferramentas para gerenciar contêineres Linux, e seu desenvolvimento está sendo liderado por funcionários da Canonical. Você pode aprender mais sobre o projeto em geral em https://linuxcontainers.org/lxd/.

Atualmente, o LXD é usado para infraestrutura de contêineres para Funtoo Containers e também é muito bem suportado no Funtoo Linux. Por esse motivo, é recomendável que você verifique o LXD e veja o que ele pode fazer por você.

Configuração básica no Funtoo

As etapas a seguir mostrarão como configurar um ambiente LXD básico no Funtoo Linux. Esse ambiente usará essencialmente a configuração padrão do LXD -- será criado um chamado lxdbr0 que usará NAT para fornecer acesso à Internet aos seus contêineres. Além disso, será criado um pool de armazenamento padrão que simplesmente usará o armazenamento do seu sistema de arquivos existente, criando um diretório em /var/lib/lxd/storage-pools/default para armazenar quaisquer contêineres que você criar. São possíveis configurações mais sofisticadas que usam pontes de rede dedicadas conectadas a interfaces físicas sem NAT, bem como pools de armazenamento dedicados que usam ZFS e btrfs -- no entanto, esses tipos de configurações são geralmente um exagero para uma estação de trabalho de desenvolvedor e devem ser tentados apenas por usuários avançados. Então não vamos cobri-los aqui.

Requerimentos

Esta seção irá guiá-lo através da configuração dos requisitos básicos para a criação de um ambiente LXD.

O primeiro passo é surgir o LXD e suas dependências. Faça o seguinte: 

root # emerge -a lxd

Quando o LXD terminar de emergir, desejamos permitir que ele inicie por padrão: 

root # rc-update add lxd default

Além disso, queremos configurar os seguintes arquivos. O /etc/security/limits.conf deve ser modificado para ter as seguintes linhas:

   /etc/security/limits.conf 
*       soft    nofile  1048576
*       hard    nofile  1048576
root    soft    nofile  1048576
root    hard    nofile  1048576
*       soft    memlock unlimited
*       hard    memlock unlimited
# End of file

Em seguida, chegamos ao conceito de "subuid" e "subgid". Normalmente, um usuário receberá um ID de usuário e um ID de grupo. Subids e subgids nos permitem atribuir UIDs e GIDs adicionais a um usuário para uso próprio. Por padrão, o LXD alocará subuids para o usuário root, o que equivale a criar os seguintes arquivos no sistema de arquivos root:

   /etc/subuid 
root:1000000:10000000000
   /etc/subgid 
root:1000000:10000000000

O formato de ambos os arquivos é "user":"start":"count". Significando que o usuário root receberá IDs "count" começando na posição "start". A razão pela qual o LXD faz isso é porque esses IDs extras serão usados para isolar contêineres dos processos do host e, opcionalmente, uns dos outros, usando diferentes deslocamentos para que seus UID e GIDs não se sobreponham. Com o LXD 5, agora essas configurações já estão "prontas", esses arquivos não precisam ser criados e existem aqui apenas para referência e compreensão do comportamento padrão do LXD. Para obter mais informações sobre subids e subgids, consulte What are subuids and subgids?.

LXD-in-LXD

A única vez que você precisará definir /etc/subuid e /etc/subgid é agora, e se você estiver executando "LXD-in-LXD". Nesse caso, o LXD interno (dentro do contêiner) precisará reduzir esses mapeamentos subuid e subgid, pois o intervalo completo não estará disponível. Isso deve ser possível simplesmente usando as seguintes configurações em sua instância LXD em contêiner:

   /etc/subuid 
root:65537:70000
   /etc/subgid 
root:65537:70000

Se você não estiver usando recursos avançados do LXD, sua instância LXD-in-LXD agora deve ter mapeamentos de id suficientes para isolar contêineres do contêiner do host. O único restante A etapa para LXD-in-LXD seria permitir que o contêiner do host aninhasse: 

root # lxc config set host-container security.nesting true

Isso permitirá que o próprio host-container contenha contêineres :)

Inicialização

Para configurar o LXD, primeiro precisaremos iniciar o LXD. Isso pode ser feito da seguinte forma: 

root # /etc/init.d/lxd start

Neste ponto, podemos executar o lxd init para executar um assistente de configuração para configurar o LXD: 

root # lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: ↵
Do you want to configure a new storage pool? (yes/no) [default=yes]: ↵
Name of the new storage pool [default=default]: ↵
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: dir ↵
Would you like to connect to a MAAS server? (yes/no) [default=no]: ↵
Would you like to create a new local network bridge? (yes/no) [default=yes]: ↵
What should the new bridge be called? [default=lxdbr0]: ↵
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ↵
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none ↵
Would you like LXD to be available over the network? (yes/no) [default=no]: ↵
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] ↵
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: ↵
root #

Como você pode ver, escolhemos todos os padrões exceto para:

pool de armazenamento
Optamos por usar um armazenamento de contêiner baseado em diretório em vez de volumes btrfs. Baseado em diretório pode ser a opção padrão durante a configuração do LXD -- depende se você tem o btrfs-tools instalado ou não.
Endereço IPv6
É recomendado que você desative isso, a menos que você queira especificamente usar IPv6 em seus contêineres. Isso pode fazer com que dhcpcd em seu contêiner recupere apenas um endereço IPv6 se você o deixar ativado. Isso é ótimo se você tiver o IPv6 funcionando - caso contrário, você obterá um endereço IPv6 inválido e nenhum endereço IPv4 e, portanto, nenhuma rede.
   Warning

Como explicado acima, desative o IPv6 NAT no LXD, a menos que você pretenda usá-lo especificamente! Isso pode confundir dhcpcd.

Se você optar por gerar a configuração YAML lxd init preseed do comando lxd init acima, aqui está um exemplo de configuração:

   lxc_init_preseed.yaml (YAML source code) - lxc init preseed config example
config:
  images.auto_update_interval: "0"
networks:
- config:
    ipv4.address: auto
    ipv6.address: none
  description: ""
  name: lxdbr0
  type: ""
  project: default
storage_pools:
- config: {}
  description: ""
  name: default
  driver: dir
profiles:
- config: {}
  description: ""
  devices:
    eth0:
      name: eth0
      network: lxdbr0
      type: nic
    root:
      path: /
      pool: funtoo
      type: disk
  name: default
projects: []
cluster: null

Agora, devemos ser capazes de executar lxc image list e obter uma resposta do daemon LXD: 

root # lxc image list
+-------+-------------+--------+-------------+------+------+-------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
+-------+-------------+--------+-------------+------+------+-------------+
root #

Se você conseguir fazer isso, você configurou com sucesso as partes principais do LXD! Observe que usamos o comando lxc e não lxd como fizemos para lxd init -- deste ponto em diante, você usará o comando lxc . Não deixe isso confundir você -- o comando lxc é a principal ferramenta de linha de comando para trabalhar com contêineres LXD.

Acima, você pode ver que nenhuma imagem está instalada. Imagens são instantâneos instaláveis de contêineres que podemos usar para criar novos contêineres. Então, como primeiro passo, vamos em frente e pegue uma imagem que possamos usar. Você deseja procurar em https://build.funtoo.org em busca de uma imagem LXD que funcione no hardware do seu computador. Por exemplo, eu consegui baixar o seguinte arquivo usando o wget: 

root # wget https://build.funtoo.org/1.4-release-std/x86-64bit/amd64-zen2/2022-04-13/lxd-amd64-zen2-1.4-release-std-2022-04-13.tar.xz

Uma vez baixada, esta imagem pode ser instalada usando o seguinte comando: 

root # lxc image import lxd-amd64-zen2-1.4-release-std-2022-04-13.tar.xz --alias funtoo
Image imported with fingerprint: fe4d27fb31bfaf3bd4f470e0ea43d26a6c05991de2a504b9e0a3b1a266dddc69

Agora você verá a imagem disponível em nossa lista de imagens: 

root # lxc image list
+--------+--------------+--------+-----------------------------------------+--------------+-----------+----------+------------------------------+

Primeiro Container

Agora é hora de lançar nosso primeiro contêiner. Isso pode ser feito da seguinte forma: 

root # lxc launch funtoo testcontainer
Creating testcontainer
Starting testcontainer

Agora podemos ver o contêiner sendo executado via lxc list: 

root # lxc list
+---------------+---------+------+-----------------------------------------------+------------+-----------+
| NAME          |  STATE  | IPV4 |                     IPV6                      |    TYPE    | SNAPSHOTS |
+---------------+---------+------+-----------------------------------------------+------------+-----------+
| testcontainer | RUNNING |      | fd42:8063:81cb:988c:216:3eff:fe2a:f901 (eth0) | PERSISTENT |           |
+---------------+---------+------+-----------------------------------------------+------------+-----------+
root #

Por padrão, nosso novo contêiner testcontainer usará o perfil padrão, que conectará uma interface eth0 no contêiner ao NAT e também usará nosso pool de armazenamento LXD baseado em diretório. Agora podemos entrar no contêiner da seguinte maneira: 

root # lxc exec testcontainer -- su --login
testcontainer #

Como você deve ter notado, ainda não temos nenhuma rede IPv4 configurada. Embora o LXD tenha configurado uma ponte e um NAT para nós, juntamente com um servidor DHCP para consulta, na verdade, precisamos usar o dhcpcd para procurar um endereço IP, então vamos configurá-lo: 

testcontainer # echo "template=dhcpcd" > /etc/conf.d/netif.eth0
testcontainer # cd /etc/init.d
testcontainer # ln -s netif.tmpl netif.eth0
testcontainer # rc-update add netif.eth0 default
 * service netif.eth0 added to runlevel default
testcontainer # rc
 * rc is deprecated, please use openrc instead.
 * Caching service dependencies ...                             [ ok ]
 * Starting DHCP Client Daemon ...                              [ ok ]
 * Network dhcpcd eth0 up ...                                   [ ok ]
testcontainer #

Agora você pode ver que eth0 tem um endereço IPv4 válido: 

testcontainer # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.212.194.17  netmask 255.255.255.0  broadcast 10.212.194.255
        inet6 fd42:8063:81cb:988c:25ea:b5bd:603d:8b0d  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::216:3eff:fe2a:f901  prefixlen 64  scopeid 0x20<link>
        ether 00:16:3e:2a:f9:01  txqueuelen 1000  (Ethernet)
        RX packets 45  bytes 5385 (5.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 2232 (2.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

O que aconteceu é que o LXD configurou um servidor DHCP para nós (dnsmasq) rodando em nossa rede privada de containers, e automaticamente oferece endereços IP para nossos containers. Ele também configurou o iptables para NAT na conexão para que o acesso de saída à Internet funcione magicamente. Você também poderá ver esse endereço IPv4 listado na lista de contêineres quando digitar lxc list em seu sistema host.

Solução de problemas de rede

   Warning
Prossiga com cautela. Estes são comandos LXC avançados que podem modificar o estado da configuração da sua rede local LXD. Em cenários extremos, o roteamento NAT de todas as redes de seus contêineres LXD pode facilmente quebrar tudo se o valor da chave de configuração LXC errado for alterado

Observe que, se você estiver tendo problemas com seu contêiner para obter um endereço IPv4 via DHCP, certifique-se de desativar o IPv6 no LXD. Fazemos isto executando: 

root # lxc network edit lxdbr0

Em seguida, altere o valor da chave YAML ipv6.nat para "false" e reinicie o LXD e o contêiner de teste: 

root # /etc/init.d/lxd restart
root # lxc restart testcontainer

Isto deve resolver o problema.

   Important
Se você inicializou seu cluster LXD desativando o IPv6 com a opção Qual endereço IPv6 deve ser usado? definida como none (nenhum), então o ipv6.nat nem estará presente na interface de ponte lxdbr0 da nossa rede local LXC.

Tenha cuidado para não adulterar a configuração ipv4.nat ou todo o roteamento NAT do contêiner LXD será interrompido, significando que nenhum tráfego de rede em execução e novos contêineres LXD poderão ser roteados para Internet!

Aqui está um exemplo de YAML de um dispositivo de ponte de rede local LXC padrão lxdbr0 para referência:

   lxc_lxdbr0.yaml (YAML source code) - lxc network edit lxdbr0
config:
  ipv4.address: 10.239.139.1/24
  ipv4.nat: "true"
  ipv6.address: none
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/profiles/default
- /1.0/instances/funtoo-livestream
managed: true
status: Created
locations:
- none

Finalizando

Supondo que sua rede esteja funcionando agora, você está pronto para começar a usar seu novo contêiner Funtoo. Hora de ter alguma diversão! Vá em frente e execute ego sync e, em seguida, emerja suas coisas favoritas: 

testcontainer # ego sync
Syncing meta-repo
Cloning into '/var/git/meta-repo'...
Retrieved from "https://www.funtoo.org/index.php?title=LXD/pt-br&oldid=42501"