Skip to content

352_Container_Virtualization

Jump to bottom
João Batista Correa Junior edited this page Jan 18, 2023 · 6 revisions

Table of Contents

352.1 Container Virtualization Concepts (peso: 7)

Objetivos do tópico

352.1 Container Virtualization Concepts (weight: 7)

Peso 7
Description Os candidatos devem compreender o conceito de virtualização de contêiner. Isso inclui a compreensão dos componentes do Linux usados para implementar a virtualização de contêiner, bem como o uso de ferramentas Linux padrão para solucionar problemas com esses componentes.
Áreas chaves de conhecimento:
  • Compreender os conceitos de containers de sistema e aplicações
  • Compreender e analisar kernel namespaces
  • Compreender e analisar control groups (CGs)
  • Compreender e analisar capabilities (capacidades)
  • Compreender as regras do seccomp, SELinux e AppArmos para virtualização de containers.
  • Compreender como LXC e Docker utilizam (aproveitam) namespaces, cgroups, capabilities, seccomp e MAC.
  • Compreender os princípios do runc
  • Compreender os princípios do CRI-O e containerd
  • Conhecimento sobre OCI runtime e especificações de imagem
  • Conhecimento de Kubernetes Container Runtime Interface (CRI)
  • Conhecimento de podman, buildah and skopeo
  • Conhecimento sobre outras abordagens de virtualização de containers em Linux e outros sistemas operacionais livres, como rkt, OpenVZ, systemd-nspawn e BSD Jails
Os termos a seguir são uma lista parcial de arquivos e utilitários usados:
  • nsenter
  • unshare
  • ip (including relevant subcommands)
  • capsh
  • /sys/fs/cgroups
  • /proc/[0-9]+/ns
  • /proc/[0-9]+/status

Compreender os conceitos de containers de sistema e aplicações

Compreender e analisar kernel namespaces

É um recurso do kernel do Linux que permite isolar um processo, ou isolar um conjuntos de recursos para um processo ou conjunto de processos.
  • O processo somente pode utilizar um conjunto especificado de recursos. cada processo está associado a um namespace e só pode ver ou usar os recursos associados a esse namespace e os namespaces descendentes quando aplicável. Desta forma, cada processo (ou grupo de processos) pode ter uma visão única dos recursos.
  • Existem 8 tipos diferentes de namespaces no kernel 5.6
  • Qualquer processo individual só pode visualizar ou usar o namespace associado a esse processo específico
  • Tipos de namespaces:
    • mount (MNT): Controle de ponto de montagem. Quan do um novo namespace é criado, o mount atual é copiado para o novo namespace
    • Process ID (PID): Provê processos com PID de processos de outro namespace
    • Interprocess Communication (IPC): Isola processos de comunicação entre processos. sso evita que processos em diferentes namespaces IPC usem, por exemplo, a família de funções SHM para estabelecer um intervalo de memória compartilhada entre os dois processos.
    • Network (NET): Virtualiza pilha de rede
    • UNIX Time Sharing (UTS): Permite que o sistema tenha diferentes hosts e nome de domínios para vários processos.
    • User ID (USER): Isolamento de privilégio e segregação de identificação de usuário.
    • Control group (cgroup): Esconde a identidade do cgroup do qual o processo é membro
    • Time Namespace: Permite adicionar diferentes system times
  • O diretório /proc/[pid]/ns/: Cada processo neste subdiretório contém uma entrada para cada namespace que suporta ser manipulado pelo comando setns
  • O arquivo /proc/[pid]/statushttps://blogs.oracle.com/linux/translating-process-id-between-namespaces: Fornece uma maneira de localizar os PIDs associados a um processo em diferentes namespaces. Também exibe diversas informações sobre o namespace no diertórios especificado.
  • O programa lsns lista o namespace associado a um processo
  • O programa unsharehttps://medium.com/@teddyking/linux-namespaces-850489d3ccf cria um novo namespaces e executa um programa especificado.
    • Exemplos:
. Mostra uptime inicial padrão
# uptime -p

. Cria um namespace do tipo time e configura para um outro tempo
# unshare --time --fork --boottime 300000000 uptime -p
up 9 years, 28 weeks, 1 day, 2 hours, 50 minutes

. Cria um shell com namespace tipo UTS e define um novo hostname para o servidor restrito a este namespace
# unshare -u /bin/sh
# hostname servidorTeste

. Verificar as rotas de um namespace do tipo network (7172), associado a um container:
# nsenter -t 7172 -n ip route

. Verificar os processos rodando em um namespace: 
# nsenter -t 7172 -p -r ps -ef

Compreender e analisar control groups (CGs)

Os cgroups permitem alocar recursos (tais como tempo da CPU, memória do sistema, largura de banda de rede ou combinações destes recursos) entre grupos de usuários definidos de tarefas (processos) rodando em um sistema.

  • O serviço cgconfig é responsável por ativar o cgroup após o reboot
  • Os cgroups seguem uma hierarquia
  • Cgroups filhos herdam certos atributos dos cgroups pais
  • Um subsistema representa um recurso único. Ex. Tempo de CPU e memória
    • blkid: Define limites de acesso para dispositivos de bloco
    • cpu: Usa o schedulinghttps://www.studytonight.com/operating-system/cpu-scheduling de cpu para acesso a CPU
    • cpuacct: Gera relatórios de uso de CPU
    • cpuset: Atribui CPUs individuais e nós de memória
    • devices: Permite ou nega acesso aos dispositivos por tarefas
    • freezer: Suspende ou retoma tarefas em um cgroup
    • memory: Define limites de utilização de memória e emite relatórios de uso
    • net_cls: Marca os pacotes de rede para o controlador de tráfego (tc) identificar
    • ns: subsistema do namespace
  • Para utilização do cgroup instalar pacote libcgroup
    • Comando lssubsys lista subsistemas montados
# lssubsys -am
    • O comando mount mount monta subsistemas de maneira manual. Exemplo:
# mount -t cgroup -o cpu,cpuset,memory cpu_and_mem /cgroup/cpu_and_mem
  • Também pode ser utilizado o arquivo de parâmetros /etc/cgconfig.conf no seguinte formato:
mount {
    cpuset = /cgroup/cpu;
}

group daemons/sql {
    perm {
        task {
            uid = root;
            gid = sqladmin;
        } admin {
            uid = root;
            gid = root;
        }
    } cpu {
        cpu.shares = 100;
    }
}
  • O comando cgcreate também pode ser utilizado para criar cgroups
# cgcreate -g cpu,net_cls:/test-subgroup
  • Para desmontar uma hierarquia, usar o comando umount. O comando cgclear serve para desativar hierarquias mesmo não vazias
# umount /cgroup/name
  • O comando cgdelete remove os cgroups
# cgdelete cpu,net_cls:/test-subgroup
  • O comando cgset adiciona parâmetro os itens do cgroup. Defini os limites
# cgset -r cpuset.cpus=0-1 group1
  • O comando cgexec inicia processos em um determinado cgroup que já tenha seus parâmetros mínimos obrigatórios configurados.
# cgexec -g cpu:group1 lynx http://www.redhat.com
  • A opção CGROUP_DAEMON no systemctl é utilizada para iniciar um serviço em um cgroup
  • Para obter informações de qual cgroup um processo está executando:
. Exibe o pid dos processos e informações sobre o cgroup na qual ele faz parte
# ps -O cgroup

. Outra forma de exibir mais informações de um cgroup de um determinado PID
# cat /proc/[PID]/cgroup

. Para informações gerais do cgroup no ambiente:
# cat /proc/cgroups

. Exibir parâmetros de um cgroup específico:
# cgget -r parameter list_of_cgroups

Compreender e analisar capabilities (capacidades/recursos)

Linux Capabilities são usados para permitir que binários façam operações privilegiadas sem precisar prover todas as permissões de root.

  • Tipos de conjuntos de Capabitilities para processos:
    • Effective capabilities (CapEff):
    • Permitted capabilities (CapPrm):
    • Inherited (hereditários) capabilities (CapInh):
    • Ambient capabilities (CapAmb)
    • Bounding set (CapBnd):
  • Tipos de Capabitilities para executáveis:
    • Inherited capabilities (CapInh):
    • Permitted capabilities (CapPrm):
  • Para verificar os capabilities de um processo, podemos usar o comando capsh:
$ capsh --print
  • Também podemos analisar o status do processo.
$ grep Cap /proc/$BASHPID/status
  • Outros comandos de administração de capabilities:
. Exibe os Cap de um binário:
$ getcap binário

. Configura um Cap para um binário
$ sudo setcap 'cap_net_raw+p' ./ping

Compreender as regras do seccomp, SELinux e AppArmor para virtualização de containers

Seccomp

Seccomphttps://docs.docker.com/engine/security/seccomp/ http://manpages.ubuntu.com/manpages/cosmic/man2/seccomp.2.html permite filtrar as chamadas de syscalls invocadas por um processo e pode, portanto, ser usado para restringir quais syscalls um determinado processo tem permissão para executar

SELinux

SELinuxhttps://debian-handbook.info/browse/pt-BR/stable/sect.selinux.html é a implementação do mecanismo MAC (mandatory access control) no kernel linux. o kernel consulta o SELinux antes de cada chamada do sistema para saber se o processo está autorizado a fazer a operação dada.

  • Os direitos de um processo depende de seu contexto de segurança. O contexto é definido pela identidade do usuário que iniciou o processo, o papel e o domínio que o usuário realizada naquele momento. O objetivo final é conceder sempre o menor privilégio possível para executar um processo.
  • O comando semodule habilita um módulo Selinux
. Lista os modulos instalados
# semodule -l

. habilitar um modulo
# semodule -e MODULO

. Desabilitar um módulo:
# semodule -d MODULO
  • O comando semanage gerencia funções no SeLinux
    • Usuário para identidade. Identidade → Papéis (rules)
  • As regras podem ser personalizadas e estão compostas em 3 arquivos:
    • Arquivo .fc: Define os arquivos de contextos. Os tipos atribuídos a arquivos relacionados ao módulo
# myapp executavel tera:
# label: system_u:object_r:myapp_exec_t
# MLS sensibilidade: s0
# MCS categorias: <nenhuma>

/usr/sbin/myapp         --      gen_context(system_u:object_r:myapp_exec_t,s0)
    • Arquivo .if: Define a interface do modulo
interface(`myapp_read_log',`
        gen_require(`
                type myapp_log_t;
        ')

        logging_search_logs($1)
        allow $1 myapp_log_t:file r_file_perms;
')
    • Arquivo .te: Arquivo de definição de regras
policy_module(myapp,1.0.0) 1

########################################
#
# Declaracoes
#

type myapp_t; 2
type myapp_exec_t;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t) 3

type myapp_log_t;
logging_log_file(myapp_log_t) 4

type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

########################################
#
# Politica local Myapp 
#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; 5

allow myapp_t myapp_tmp_t:file manage_file_perms;
files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

AppArmor

AppArmorhttps://debian-handbook.info/browse/pt-BR/stable/sect.apparmor.html é um sistema de MAC construído sobre interface LSM (Linux Security Modules). O kernel consulta o AppArmor antes de cada chamada do sistema para saber se o processo está autorizado a fazer a operação dada. Através desse mecanismo, o AppArmor confina programas a um conjunto limitado de recursos.

  • O AppArmor aplica um conjunto de regras (conhecido como “perfil”) em cada programa. O perfil aplicado pelo kernel depende do caminho de instalação do programa que está sendo executado. Ao contrário do SELinux, as regras aplicadas não dependem do usuário. Todos os usuários enfrentam o mesmo conjunto de regras quando estão executando o mesmo programa.
  • Os perfis de segurança ficam situados em: /etc/apparmor.d/ Exemplo:
cat > /etc/apparmor.d/no_raw_net <<EOF
#include <tunables/global>

profile no-ping flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet tcp,
  network inet udp,
  network inet icmp,

  deny network raw,
  deny network packet,
  file,
  mount,
}
EOF

. Carregar o novo perfil salvo:
# /sbin/apparmor_parser --replace --write-cache /etc/apparmor.d/no_raw_net

Compreender como LXC e Docker utilizam (aproveitam) namespaces, cgroups, capabilities, seccomp e MAC.

  • Dockerhttps://docs.docker.com/engine/security/:
    • Namespace: Docker usa este serviço para prover o isolamento dos containers. Quando um container é rodado, o docker cira uma configuração de namespace para este container.
    • cgroups: O docker utiliza Cgroups para definir os limites de recursos a serem utilizados em um container. Várias opções na execução da linha de comando são utilizadas para isso.
Exemplo:
$ docker run -it \
    --cpu-rt-runtime=950000 \
    --ulimit rtprio=99 \
    --cap-add=sys_nice \
    ----memory=200m
    debian:jessie
    • Seccomp: Através do atributo --security-opt
    • Capabilities: Por padrão o docker inicia um container com uma configuração restrita de capabilities
    • AppArmor(MAC*): Usar a opção apparmor=profile-name
    • SELinux(MAC*)https://www.mankier.com/8/container_selinux: Pode-se utilizar o módulo 'container_selinux'
Obs: * MAC (Mandatory Access Control)
  • LXC:
    • Namespacehttps://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html: LXC utiliza namespaces para rodar containers de forma não privilegiada. Por exemplo, um processo rodando com o UID e GID 0 dentro do container, aparecem com o UID e GID 10000 no host. Elas podem ser definidas pela chave lxc.idmap. As chaves de configuração do namespace utilizam ponto (.). COnfigurações mais complexas utilizam subchaves. Exemplo:
. lxc.container.conf
 lxc.net.0
 lxc.net.0.ipv6.address
    • cgroups: Utiliza o cgroup através do comando lxc-cgroup que associa cgroup ao container. Exemplo:
. Definir os processadores 0 e 3 para uma vm
# lxc-cgroup -n foo cpuset.cpus "0,3"
    • Seccomphttps://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html: Um container pode ser iniciado com um reduzido grupo de system calls. Deve ser definida a versão na primeira linha e o tipo de política na segunda linha. O parâmetro lxc.seccomp.profile indica o arquivo contendo as configurações. outros parâmetros lxc.seccomp são reconhecidos.
. Exemplo de política onde todas as chamadas são permitidas com exceção do mknod.
---
 2
 denylist
 mknod errno 0
 ioctl notify
---

. Outros parâmetros:
lxc.seccomp.allow_nesting → Se configurado para 1, o arquivo de políticas do profile será carregado
lxc.seccomp.notify.proxy
lxc.seccomp.notify.cookie
    • Capabilities: São usadas as opções para dropar lxc.cap.drop e para manter lxc.cap.keep os capabilities nos containers
    • AppArmor(MAC*): COmpilado com esta funcionalidade por padrão. Utiliza as opções lxc.apparmor.profile 
. Configurar para não confinado:
lxc.apparmor.profile = unconfined

. Para gerar um perfil 
lxc.apparmor.profile = generated

. Outros:
lxc.apparmor.allow_incomplete
lxc.apparmor.allow_nesting
lxc.apparmor.raw
    • SELinux(MAC*): Pode ser habilitado. o parâmetro lxc.selinux.context pode ser usado
. Especifica o contexto SELinux sob o qual o container deve ser executado
lxc.selinux.context = system_u:system_r:lxc_t:s0:c22

Compreender os princípios do runc https://mkdev.me/en/posts/the-tool-that-really-runs-your-containers-deep-dive-into-runc-and-oci-specifications https://www.docker.com/blog/runc/

Definição de sua página de manual: "runc é um cliente de linha de comando para executar aplicativos empacotados de acordo com o formato Open Container Initiative (OCI) e é uma implementação compatível da especificação Open Container Initiative"

  • O runc não trabalha com imagens, ele espera um pacote OCI que é um sistema de arquivos raiz e um arquivo config.json 
. Gerar o arquivo de especificações config.json do container:
# runc spec

 .Para executar o container
# runc run teste

Obs: Deve ser criado o sistema de arquivos para que o runc execute o container

O runC é um runtime para execução de containers, é ele que entra em contato com as funções do sistema operacional do host responsáveis por colocar em prática a containerização, como por exemplo, os namespaces, seccomp, cababilities, apparmor, etc. Isso cria uma flexibilidade na execução de containers e a independência em relação a ferramentas como o docker por exemplo.

Compreender os princípios do CRI-O e containerd https://blog.lsantos.dev/entendendo-runtimes-de-containers/

https://github.com/jcorreajr/LPIC-3/blob/main/LPI305/Container_crio.png?raw=true

  • CRI-Ohttps://cri-o.io/: o CRI-O foi criado especificamente para permitir que o Kubernetes execute containers sem muito código ou ferramentas externas. Hoje, ele suporta runc e Kata
Formado por alguns componentes:
    • containers/storage: Layes de armazenamento e filesystems
    • containers/image: Imagens e registries
    • networking: Rede dos pods
    • conmon: Monitoramento
  • Containerd: Interface compatível com o OCI capaz de executar, baixar e extrair qualquer imagem que seja também compatível com a OCI e executar processos do runC. Daemon que executa e controla instancias do runC. O containerd ajuda a abstrair as chamadas de kernel (syscalls) para que containers possam executar da mesma forma em qualquer sistema operacional

Conhecimento sobre OCI runtime e especificações de imagem

A Open Container Initiative é uma estrutura de governança aberta com o propósito expresso de criar padrões de mercado abertos em torno de formatos de contêiner e runtimes. Estabelecido em junho de 2015 pela Docker e outros líderes na indústria de contêineres, o OCI atualmente contém duas especificações: a Runtime Specification (runtime-spec) e a Image Specification (image-spec). A especificação de runtime descreve como executar um “pacote de sistema de arquivos” que é descompactado no disco. Em um alto nível, uma implementação OCI baixaria uma imagem OCI e, em seguida, descompactaria essa imagem em um pacote de sistema de arquivos OCI Runtime. Neste ponto, o OCI Runtime Bundle seria executado por um OCI Runtime. 

- Image Manifest: Descreve os componentes que fazem subir uma imagem do container
- Image Index:
- Image Layout
- Filesystem layer
- Image Configuration
- Conversion
- Descriptor

Conhecimento de Kubernetes Container Runtime Interface (CRI)

CRI https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md é uma especie de API que esta sendo construída para possibilitar o kubernetes a trabalhar com vários runtimes diferentes, como o cri-o; rktlet e frakti. Desta forma ele não exige forte recodificação do kubelet

Conhecimento de podman, buildah and skopeo

  • Podman: Ferramenta padrão OCI para gerenciamento de imagens de containers. Suporta Dockerfiles. Não precisa de daemon
. Exemplo de utilização
# podman run --name nginx -d -p 80:80 nginx
  • buildah: Ferramenta de linha de comando para criar um container; criar uma imagem através de um dockerfile; montar e desmontar um filesystem de container, deletar e renomear.
# buildah run $newcontainer bash
Exemplo prático de uso das duas ferramentas 
. Exemplos
$ skopeo inspect docker://registry.fedoraproject.org/fedora:latest

$ skopeo copy docker://quay.io/buildah/stable docker://registry.internal.company.com/buildah

Conhecimento sobre outras abordagens de virtualização de containers em Linux e outros sistemas operacionais livres

  • rkt: Projeto de gerenciamento de container. O projeto foi finalizado em fevereiro de 2020 por falta de engajamento da comunidade
  • OpenVZhttps://wiki.openvz.org/: OpenVZ usa um único kernel do Linux (com um patch) e portanto, pode executar somente Linux. Todas as maquinas guests funcionam sob a mesma versão de kernel que o host físico.
vzctl: Programa avançado, utilizado para gerenciar containers.

Programa do OpenVZ. Alguns exemplos:
# vzctl enter CTID: Usado para conectar na console do container
# vzctl enter CTID --exec "apt-get install vim && logout": Instala o aplicativo no container e sai.
# vzctl start CTID: Iniciar Container
# vzctl stop CTID: Stop container
# vzctl status CTID: Status container

Vzlist: Lista os containers em execução.
  • systemd-nspawnhttps://www.freedesktop.org/software/systemd/man/systemd-nspawn.html: systemd-nspawn pode ser usado para executar um comando ou sistema operacional em um contêiner de namespace leve. Em muitos aspectos, é semelhante ao chroot, mas mais poderoso, pois virtualiza totalmente a hierarquia do sistema de arquivos, bem como a árvore de processos, os vários subsistemas IPC e o host e o nome de domínio. Este mecanismo também é semelhante ao LXC, mas é muito mais simples de configurar e a maior parte do software necessário já está instalado em sistemas Debian contemporâneos.
. Exemplo de uso, iniciando container não privilegiado
# systemd-nspawn -D ~/MyContainer --private-users=0 --private-users-chown

# systemd-nspawn -bUD ~/MyContainer
São construídas em cima do conceito de chroot. As jails expandem esse modelo virtualizando o acesso ao sistema de arquivos, ao conjunto de usuários e ao subsistema de rede e podem ser consideradas como um tipo de virtualização no nível do sistema operacional. Composto por quatro elementos:
    • Subárvore de diretórios
    • Nome de host
    • Endereço IP
    • Comando que será executado no jail

352.2 LXC (peso: 6)

Objetivos do tópico

352.2 LXC (weight: 6)

Weight 6
Description Os candidatos devem ser capazes de usar contêineres de sistema usando LXC e LXD. A versão do LXC coberta é 3.0 ou superior.
Key Knowledge Areas:
  • Compreender a arquitetura do LXC e LXD
  • Gerenciar containers LXC baseados em imagens existentes, usando LXD, incluindo rede e storage
  • Configurar propriedades do container LXC
  • Limitar o uso de recursos do contêiner LXC
  • Uso de profiles LXD
  • Compreender imagens LXC
  • Conhecimento das ferramentas tradicionais do LXC
Lista parcial de arquivos, termos e utilitários usados.:
  • lxd
  • lxc (includindo subcomandos relevantes)

Compreender a arquitetura do LXC e LXD

LXChttps://linuxcontainers.org/lxc/introduction/ é uma interface de 'userspace' que trabalha com os recursos de container do Kernel Linux. Por meio de uma API poderosa e ferramentas simples, ele permite que os usuários do Linux de forma fácil gerenciem containers de aplicação o sistema.

  • Recursos:
Atualmente LXC usa as seguintes características do kernel para 'isolar' processos:
    • Kernel namespaces (ipc, uts, mount, pid, network and user)
    • Apparmor and SELinux profiles
    • Seccomp policies
    • Chroots (using pivot_root)
    • Kernel capabilities
    • CGroups (control groups)
Containers LXC são comumente consideradas um intermediário entre um ambiente chroot e uma maquina virtual full virtualizada. O objetivo do LXC é criar um ambiente padrão Linux mais isolado possível, porém compartilhando o seu Kernel, ou seja sem precisar de um kernel somente para o ambiente LXC.
  • Componentes:
LXC é composto por alguns componentes:
    • Liblxc library
    • Several language bindings for the API:
    • python3 (in-tree, long term support in 1.0.x)
    • lua (in tree, long term support in 1.0.x)
    • Go
    • ruby
    • python2
    • Haskell
    • A set of standard tools to control the containers
    • Container Templates das distribuições
  • Requerimento de versão de Kernel: Linux kernel >= 3.8
O LXDhttps://linuxcontainers.org/lxd/introduction/, mantido pela Canonical, por sua vez é um gerenciador de containers, baseado em imagens com imagens pré-fabricadas disponíveis para um grande número de distribuições Linux e é construído em torno de uma API REST.
  • O núcleo do LXD é um daemon privilegiado que expõe uma API em um soquete unix local, bem como na rede (se habilitado).
  • Os clientes, como a ferramenta de linha de comando fornecida com o próprio LXD, fazem tudo por meio dessa API.
  • O LXD é escrito sob o LXC e utiliza o LXC através da biblioteca liblxc. É uma alternativa no uso das ferramentas clientes LXC.

Gerenciar containers LXC baseados em imagens existentes, usando LXD, incluindo rede e storage 

. Na primeira execução do LXD ele precisa ser configurado através do comando, como root
# lxd init

. Criar uma instância do canal remoto ubuntu
# lxc launch ubuntu:20.04 ubuntuone

. Criar uma instância do canal remoto images
# lxc launch images:alpine/3.13 testealpine


. Listar instância
# lxc list

. Iniciar instância
# lxc start instancia

. Capturar o shell de um container/instância
# lxc exec instancename -- /bin/bash


. Criar a rede
# lxc network create <name> --type=bridge [options...]

. Configurar a rede, conforme os parâmetros de cada tipo de rede
# lxc network set <network> <key> <value>
Exemplo:
# lxc network set lxdbr0 ipv4.firewall false

. Configurar rede lxd editando arquivo yaml
# lxc network edit lxdbr0

. Atachar uma rede a um container existente
# lxc network attach my-container default eth0

. Criar um storage
# lxc storage volume create [<remote>]:<pool> <name> --type=block

. Exemplo:
# lxc storage create pool2 dir source=/data/lxd

# lxc storage create pool1 zfs source=my-tank

. Atachar um volume existente a um container:
# lxc storage volume attach mypool myfilevolume c11 mydevice /home/mydevicepath

Configurar propriedades do container LXC 

* Arquivo de configurações gerais:
# /etc/default/lxc
* Arquivo de configurações de opções de rede:
# /etc/lxc/lxc.conf
  • Basicamente as configurações do container lxc ficam no seu diretório (/var/lib/lxc/container/container/config). A configuração básica é criada no momento da criação do containers.
  • Mais detalhes sobre configurações e parametrização do containerhttps://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html:
    • Uma série de configurações é possível, entre elas:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br1
lxc.network.name = eth0
  • No LXD a configuração se dá pelo comando:
. Exibe as configurações do container
# lxc config show nome_container

# lxc config set nome_container limits.cpu 1

Limitar o uso de recursos do contêiner LXC

Os limites de utilização de hardware são criados para que um container não comprometa todos os recursos do host. Entre os dispositivos que podemos limitar a utilização, destaco: CPU, memória, disco e rede. https://www.jamescoyle.net/how-to/2532-setting-cpu-resource-limits-with-lxc https://www.maketecheasier.com/limit-lxd-containers-resources/

  • As definições dos limites são parametrizadas nos containers. Como visto, no LXD os parâmetros são configurados através do comando lxc config. No LXC são definidos dentro do arquivo de propriedades do container.
  • Exemplo de uso de limitação de container 
. Memória
# lxc config set container_name limits.memory 100MB

. CPU
.. Quantidade
# lxc config set container_name limits.cpu 2
.. Tempo de uso
# lxc config set container_name limits.cpu.allowance 10ms/100ms

. Limite de espaço em disco
# lxc config device set container_name root size 7GB

. Limite de largura de banda de rede (ingress = Download; egress=upload)
# lxc config device set container_name eth0 limits.ingress 1Mbit

Uso de profiles LXD

Os profiles podem armazenar qualquer configuração possível (chave e valor). Vários profiles podem ser aplicados a uma mesma instância https://lxd.readthedocs.io/en/latest/profiles/ https://linuxcontainers.org/lxd/advanced-guide/#profiles.

  • Um profile padrão é criado e vinculado a novas VMs, se não for especificado um profile diferente.
. Verificar as configurações do profile padrão
# lxc profile show default

. Criar um novo profile
# lxc profile create profilename
  • Para vincular uma configuração específica a um profile:
# lxc profile set profilename chave=valor
  • Para editar as configurações de um profile, o arquivo de configuração funciona no formato yaml:
# lxc profile edit profilename

.. Exemplo:
---
config: {}
description: ""
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: one
    type: disk
name: default
used_by: []
---
  • Adicionar um profile criado a uma instância
# lxc profile add instância profilename

Compreender imagens LXC

As instâncias são baseadas em imagens https://linuxcontainers.org/lxd/getting-started-cli/#images que contém um sistema operacional e algumas informações relacionadas ao LXD.

  • Alguns comandos básicos no uso de imagens:
. Listar os servidores de imagem remota:
# lxc remote list

. Listar imagens disponíveis no servidor local
# lxc image list:

. Listar imagens disponíveis no canal remoto images
# lxc image list images:

. Adicionar um local de imagem remoto:
# lxc remote add lxc images.linuxcontainers.org

. Exportar uma imagem
# lxc image export ubuntu:20.04

. Importar uma imagem para ser usada em ambientes sem acesso a serviço de imagens remoto
# lxc image import META ROOTFS --alias ubuntu-20.04

. Editar uma imagem (para associar um profile por exemplo)
# lxc image edit fingerprint_da_imagem

. Publicar uma instância como imagem
# lxc publish web/initialconfig --alias nginx-example

Conhecimento das ferramentas tradicionais do LXC 

# lxc-create -t template_download -n meu-container
    • Iniciar um container:
# lxc-start -n meu-container -d
    • Verificar status do container:
# lxc-info -n meu-container
# lxc-ls -f
    • Conectar no Shell do Container
# lxc-console -n meu-container
# lxc-attach -n meu-container
    • Finalizar um container
# lxc-stop -n meu-container
    • Remover o container:
# lxc-destroy -n meu-container

352.3 Docker (peso: 9)

Objetivos do tópico

Peso 9
Descrição O candidato deve ser capaz de gerenciar nós e contêineres Docker. Isso inclui entender a arquitetura do Docker, bem como entender como o Docker interage com o sistema Linux Host.
Key Knowledge Areas:
  • Compreender a arquitetura e os componentes do Docker
  • Gerenciar contêineres do Docker usando imagens de um registro do Docker
  • Compreender e gerenciar imagens e volumes de containers Docker
  • Compreender e gerenciar loggin (logs) de containers Docker
  • Compreender e gerenciar redes de Docker
  • Utilizar Dockerfiles para criar imagens de containers
  • Execute um registro do Docker usando a imagem do Docker do registro
Lista parcial de arquivos, termos e utilitários usados:
  • dockerd
  • /etc/docker/daemon.json
  • /var/lib/docker/
  • docker
  • Dockerfile

Compreender a arquitetura e os componentes do Docker

Docker é uma plataforma para desenvolvedores e sysadmins https://docs.docker.com/get-started/overview/, com o objetivo de desenvolver, 'embarcar' e rodar aplicações. Docker permite montar rapidamente aplicações de componentes e elimina o atrito que pode vir ao enviar código. Docker permite obter o seu código testado e implantado em produção o mais rápido possível.

  • Aspectos gerais: O Docker funciona em camadas, podemos imaginar uma cebola, para funcionar um aplicativo independente do sistema que o hospeda, ele tem que trazer toda a gama de bibliotecas e do próprio S.O. embutidos, além do próprio aplicativo. Assim o docker inicializa o sistema operacional dentro de um container gerenciado por ele e chama o aplicativo para executar dentro do container, juntamente com as bibliotecas necessárias. Tudo isso deve estar dentro de uma imagem previamente construída por você ou que pode estar disponível no site Hub Docker.
  • Docker consiste em:
    • Docker Engine: Tecnologia de virtualização de container leve e poderosa, combinada com o fluxo de trabalho para construção e containeirização das aplicações.
    • Docker HUB: Serviço SaaS para compartilhamento e gerenciamento das aplicações
  • Você pode fazer um deploy de um container no desktop, servidor físico, maquina virtual, no data-center, assim como nas nuvens privadas ou públicas.
  • Docker não precisa de um hypervisor para funcionar.
  • Partes principais do Docker:https://github.com/jcorreajr/LPIC-3/blob/main/LPI305/200px-Partes_docker.jpg?raw=true
    • docker daemon: (dockerd) Daemons que escuta por chamadas API e usado para gereciar os contêineres docker no host onde ele roda
    • docker CLI: (docker) Envia comandos para se comunicar com o docker daemon
    • docker image index (registry): um repositório (público ou privado) para as imagens do docker
  • Elementos principais do Docker
    • Contêineres docker: diretórios contendo tudo que constitui sua aplicação
    • docker images: imagens instantâneas dos contêineres ou do S.O. básico (Ubuntu por exemplo)
    • Dockerfiles: scripts que automatizam o processo de construção de imagens
    • Diferença entre imagem e container: Como visto o Docker trabalha com imagens e containers. A imagem é a base para execução. No momento da execução, é criado um container que permite escrita.
  • Elementos do Docker
Os seguintes elementos são usados pelas aplicações que formam o projeto docker.
    • Contêineres Docker
      • Todo o processo de portar aplicações usando docker depende, exclusivamente, do envio de contêineres.
      • Os contêineres docker são basicamente, diretórios que podem ser empacotados (agrupados com tar por exemplo) como qualquer outro, e então, compartilhados e executados entre várias máquinas e plataformas (hosts). A única dependência é ter os hosts ajustados para executar os contêineres (ou seja, ter o docker instalado).
    • LXC-Contêineres Linux foi utilizado até a versão Docker 0.8
    • Na versão 0.9 foi utilizado como engine de isolamento padrão do Docker o libcontainer em substituição do LXC

Gerenciar contêineres do Docker usando imagens de um registro do Docker

  • Alguns comandos de gerenciamento do Docker:
* Instalação do aplicativo Docker no ubuntu:
# apt-get install docker.io

** Comandos para trabalhar com imagens

* Listar as imagens atualmente instaladas
# docker image ls -a

* Baixar uma imagem para uso posterior
# docker pull NOME_IMAGEM

* Baixar uma imagem (se não foi baixada antes) e roda-la, juntamente a um aplicativo que esta embutido na imagem
# docker run imagem aplicativo 
Exemplo
# docker run -i -t ubuntu /bin/bash
  • Outros comandos de administração do Docker
** Comandos para trabalhar com os containers

* Listar os containers em execução
# docker container ps -a

* Parar um container
# docker container stop container_ID

* Remover um container
# docker container rm container_ID

Compreender e gerenciar imagens e volumes de containers Docker

Os volumes https://docs.docker.com/storage/volumes/ são a maneira preferencial para armazenamento de dados persistentes usando containers docker. Outra opção é o bind mount que são diretórios montados no host, mas tem sérias desvantagens em relação ao primeiro.

  • Para montar um volume na execução de um container, podemos executar o comando -v e a opção mount
    • Utilizando a opção -v 
* Rodar uma imagem montando volume vinculado ao host local
# docker run -it -v $(pwd)/app:/app exemplo-build
    • Utilizando a opção --mount permite uma configuração maior de opções.
# docker run -it --mount 'type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=local,volume-opt=type=nfs,
volume-opt=device=<nfs-server>:<nfs-path>,"volume-opt=o=addr=<nfs-address>,vers=4,soft,timeo=180,bg,tcp,rw"' exemplo-build
  • Os volumes podem ser gerenciados separadamente e vinculados a um container em execução.
. Criar o volume
# docker volume create my-vol

. Iniciar um container com o volume vinculado
# docker run -it --mount source=myvol2,target=/app exemplo-build

As imagenshttps://docs.docker.com/engine/reference/commandline/images/ são formadas por um conjunto de camadas. Quando um container está em execução, é criada uma nova fina camada de gravação, no tempo de execução. Vários containers podem compartilhar da mesma imagemhttps://docs.docker.com/storage/storagedriver/. 

. Criar imagem a partir de uma VM ID
# docker commit ID_VM

. Listar as imagens
# docker images
    • Através de um dockerfile, explicado abaixo

Compreender e gerenciar loggin (logs) de containers Docker

Comando para ver logs de um container https://docs.docker.com/config/containers/logging/ ou serviço. 

# docker logs ID_Container
Por padrão o comando docker logs mostra as saídas STDOUT e STDERR do container
  • Alguns containers apontam por padrão os logs para o stdout e stderr, como o nginx e https
  • Podemos ativar a opção de dual log. Além de visualizar pelo comando, o docker salva um arquivo no formato json para que algum serviço externo possa capturar e analisar os logs no formato padrão. Para isso precisamos configurar:
. Arquivo /etc/docker/daemon.json
---
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "os,customer"
  }
}
----
Outras opções comohttps://docs.docker.com/config/containers/logging/configure/ syslog, journald, gelf, fluentd, awslogs, splunk, etwlogs, gcplogs, logentries pode ser usadas como saída de log.

Compreender e gerenciar redes de Docker

O subsistema de rede do docker https://docs.docker.com/network/ é flexível e utiliza drivers para prover as funcionalidades de conectividade necessárias.

  • Tipos de drivers de rede docker:
    • Bridgehttps://docs.docker.com/network/bridge/: Driver default, Cria uma ponte para a conexão externa
      • Como o driver bridge é o formato padrão, ao iniciar um container sem especificação de rede, ele é atachado automaticamente. 
. Exibir quais containers estão utilizando a bridge e quais ips:
# docker network inspect bridge

. Criar uma rede Bridge específica com range de ip específico
# docker network create --driver bridge alpine-net --subnet 192.168.10.0/24

. Executar um container vinculando a uma rede específica:
# docker run -dit --name alpine1 --network alpine-net alpine ash

. Editando um container em execução e atachando a mais uma rede, chamada "bridge"
# docker network connect bridge alpine4
      • O serviço automatic service discovery permite utilizar o nome dos containers para conexões.
. O container alpaine1 vai conseguir resolver o ip de todos os demais containers
# docker container attach alpine1
    • Hosthttps://docs.docker.com/network/host/: Remove o isolamento entre o container e o host docker, usando uma rede direta para o host.
      • No uso deste modelo, o container não recebe ip próprio. Se o container expõe a porta 80, ele será acessado através do ip do HOST na mesma porta 80. O direcionamento de portas não funciona neste modelo. Exemplo de aplicação:
. Executando um container com o tipo de rede host
# docker run --rm -d --network host --name my_nginx nginx


. Utilizando criptografia. Opção "--attachable" necessária para permitir swarm e containers independentes (standalone)
# docker network create --opt encrypted --driver overlay --attachable my-attachable-multi-host-network
    • macvlanhttps://docs.docker.com/network/macvlan/: Permite configurar um MAC address diretamente em um container, o Docker daemon roteia o tráfego para este container através do MAC. É utilizado para aplicações legadas que exigem uma rede conectada diretamente no sistema na qual ela é executada.
      • Exemplo de criação de rede tipo macvlan:
# docker network create -d macvlan \
  --subnet=172.16.86.0/24 \
  --gateway=172.16.86.1 \
  -o parent=eth0 pub_net

# docker run --rm -dit \
  --network none \
  --name no-net-alpine \
  alpine:latest \
  ash
  • Também é possível utilizar plugins desenvolvidos por terceiros. Estes plugins ficam disponíveis no Docker Hub por exemplo.

Utilizar Dockerfiles para criar imagens de containers

O Docker pode construir imagens automaticamente lendo as instruções de um Dockerfile https://docs.docker.com/engine/reference/builder/. Um Dockerfile é um documento de texto que contém todos os comandos que um usuário pode chamar na linha de comando para montar uma imagem. Usando o docker build, os usuários podem criar um build automatizado que executa várias instruções de linha de comando em sequência https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

  • O comando docker build constrói a imagem através do arquivo de texto Dockerfile e do contexto. O contexto é o conjunto de arquivos em um caminho especificado.
  • Criar uma nova imagem (deve ser criado o arquivo de receita Dockerfile) e um diretório vazio para o contexto.
# docker image build -t nomeimagem .

* Exemplo de Dockerfile
---------------------------------------------
FROM python:3.6
LABEL maintainer 'Juracy Filho <juracy at gmail.com>'

RUN useradd www && \
    mkdir /app && \
    mkdir /log && \
    chown www /log

USER www
VOLUME /log
WORKDIR /app
EXPOSE 8000

ENTRYPOINT ["/usr/local/bin/python"]
CMD ["run.py"]
----------------------------------------------

Rodando um Docker registry usando a imagem do Docker do registro

Docker Hub Registryhttps://docs.docker.com/docker-hub/ é o local onde várias imagens de container padrões estão hospedadas. Este serviço é de responsabilidade da docker e tem algumas limitações como número de pulls de imagens que podem ser feitas em um período de tempo https://www.docker.com/increase-rate-limits#:~:text=Understanding%20Docker%20Hub%20Rate%20Limiting&text=Anonymous%20and%20Free%20Docker%20Hub,pull%20requests%20per%20six%20hours.

  • É possível instalar o serviço de Docker Hub na infra local, podendo enviar as imagens diretamente para este registro localhttps://docs.docker.com/registry/deploying/.
  • Para isso, devemos baixar a imagem do container registry e executar
# docker run -d -p 5000:5000 --restart=always --name registry registry:2

Várias configurações são possíveis, como customizações de local de armazenamento (storage), criptografia, balanceamento de carga entre outros.

352.4 Container Orchestration Platforms (peso: 3)

Objetivos do tópico

Weight 3
Description Os candidatos devem compreender a importância da orquestração de contêineres e os principais conceitos fornecidos pelo Docker Swarm e pelo Kubernetes para implementar a orquestração de containers.
Key Knowledge Areas:
  • Compreender a relevância da orquestração de containers
  • Compreender os conceitos chaves do Docker Compose e Docker Swarm
  • Compreender os conceitos chaves de Kubernetes e Helm
  • Conhecimento de OpenShift, Rancher e Mesosphere DC/OS

Compreender a relevância da orquestração de containers

"A orquestração automatiza a implantação, o gerenciamento, a escala e a rede dos containers. Ela é perfeita para as empresas que precisam implantar e gerenciar centenas de milhares de hosts e containers Linux" https://www.redhat.com/pt-br/topics/containers/what-is-container-orchestration

  • Aplicações baseadas em microsserviços rodando em containers, quando orquestrados, recebem uma série de benefícios, como:
    • Controle de ciclos de vida
    • Controle sobre componentes individuais
    • Codificação e versionamento da infra estrutura, mesmo que complexa
  • Para devops:
    • Facilita a integração do ciclo CI/CD
    • Facilita migração entre nuvens
  • No geral a orquestração auxilia no:
    • Provisionamento e implantação
    • Alocação de recursos
    • Disponibilidade; através da implantação de H.A.
    • Balanceamento de carga
    • MOnitoramento de integridade

Compreender os conceitos chaves do Docker Compose e Docker Swarm

  • Docker Compose: É usado para configurar e iniciar vários containers docker no mesmo host.
  • Para criar este ambiente completo, ele faz uso de um arquivo de receita chamado: docker-compose.yml
    • Este arquivo descreve quais tarefas serão executadas e inclusive qual Dockerfile vai ser usado para gerar uma nova imagem.
    • Exemplo do arquivo Docker Compose:
version: '3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
volumes:
    db_data:
  • Comandos básicos de administração:
. Criar o ambiente: (Dentro da pasta do arquivo yaml)
# docker-compose -p projeto up


### Administração:
. Iniciar projeto:
# docker-compose -p NOMEDOPROJETO start

. Parar projeto:
# docker-compose -p NOMEDOPROJETO stop
  • Docker Swarm: Ferramenta de orquestração de containers, que permite executar containers em vários hosts.
    • Necessita no mínimo de 3 nós de gerenciamento (manage) para habilitar HA, e quantos workers (que roda os containers) forem necessários. Managers podem também ser workers
    • Usa uma receita de bolo, extensão .yml na opção -compose-file
      • Este arquivo tem todas as configurações necessárias para criar os containers, em quais nós, quantidade, conf de rede, etc.
      • Abaixo exemplo de arquivo compose swarm do projeto de demonstração do docker 
version: "3"
services:

  redis:
    image: redis:alpine
    networks:
      - frontend
    deploy:
      replicas: 1
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
  db:
    image: postgres:9.4
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      placement:
        constraints: [node.role == manager]
  vote:
    image: dockersamples/examplevotingapp_vote:before
    ports:
      - 5000:80
    networks:
      - frontend
    depends_on:
      - redis
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
      restart_policy:
        condition: on-failure
  result:
    image: dockersamples/examplevotingapp_result:before
    ports:
      - 5001:80
    networks:
      - backend
    depends_on:
      - db
    deploy:
      replicas: 1
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      mode: replicated
      replicas: 1
      labels: [APP=VOTING]
      restart_policy:
        condition: on-failure
        delay: 10s
        max_attempts: 3
        window: 120s
      placement:
        constraints: [node.role == manager]

  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    stop_grace_period: 1m30s
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  frontend:
  backend:

volumes:
  db-data:
    • Definição de Services e Tasks:
      • Services É o serviço que é oferecido, vinculado a quantos containers forem necessários. Exemplo: bd (geralmente 1 container) ou App (2 ou mais containers)
      • Tasks É cada um dos containers. no exemplo acima, o serviço App conta com duas ou mais tasks, que são os containers que rodam o App.
    • Alguns comandos para fazer o deploy da stack 
* Habilitar o daemon Docker para trabalhar com o Swarm:
$ docker swarm init --advertise-addr $(hostname -i)

* Adicionar nós Workings ao cluster swarm
$ docker swarm join -token SWMTKN-X-abcdef.....

* Adicionar novos manages ao swarm:
$ docker swarm join-token manager...

* Listar os nós:
$ docker node ls

* Criar a Stack
$ docker stack deploy --compose-file docker-compose.yml nome_da_stack

* Resumo da Stack
$ docker stack ls

* Verificar a stack sendo criada
$ docker stack services nome_da_stack

* Verificar os detalhes das tasks em um serviço
$ docker service ps nome_da_stack

* Remover Stack:
$ docker stack rm nome_da_stack

Compreender os conceitos chaves de Kubernetes e Helm

Kubernetes

Principais componenteshttps://www.redhat.com/pt-br/topics/containers/what-is-container-orchestration: https://github.com/jcorreajr/LPIC-3/blob/main/LPI305/250px-Kubernetes_arquitetura.png?raw=true

  • Cluster: plano de controle e pelo menos uma máquina de computação ou nós.
  • Plano de controle(Control plane): conjunto de processos que controlam os nós do Kubernetes. É nele que todas as atribuições de tarefas se originam.O plano de controle está sempre se comunicando com as máquinas de computação. Quando você configura a execução do cluster, o plano de controle faz com que isso aconteça de acordo com o planejado.
  • Kubelet: um serviço executado nos nós que lê os manifestos do container e assegura que os containers definidos sejam iniciados e executados.
  • Pod: um grupo de um ou mais containers implantados em um nó. Todos os containers em um pod têm o mesmo endereço IP, IPC, nome de host e outros recursos.
Detalhes de componenteshttps://www.redhat.com/pt-br/topics/containers/kubernetes-architecture:
  • Control Plane
    • kube-apiserver: É a API do kubernetes, o front-end do plano de controle. Ele valida e executa operações. Pode ser chamada por meio de REST, interface de linha de comando, usando o "kubectl" e outras ferramentas como o kubeadm.
    • kube-scheduler: Avalia a integridade do cluster e os recursos em uso/disponíveis. Ele aloca os containers no melhor nó.
    • kube-controller-manager: Gerencia os controladores. Perceber se um PID esta ativo ou não é um exemplo.
    • etcd: Banco de dados de armazenamento de chave/valor, distribuido e tolerante a falhas, que contém informações sobre o estado do cluster.
  • Nodes
    • PODs: Representa uma instância de uma aplicação. Formado por um ou mais containers com forte acoplamento. Determina como os containers serão executados.
    • kubelet: Aplicação que roda no nó, sendo responsável pela comunicação com o control plane. Recebe determinações do control plane e realiza a ação.
    • kube-proxy: Proxy para serviços de rede. Gerencia as comunicações de rede dentro e fora do cluster.
Demais itens da infra estrutura:
  • Armazenamento persistente: Volumes de dados gerenciados pelo kubernetes para o cluster
  • Registro de containers: Imagens de containers
Exemplo de um deploy de PODhttps://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/
  • A receita é escrita em yaml e neste exemplo, será um container nginx replicado em 2 nós do cluuster.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  • Usando kubectl, a receita será aplicada ao cluster
# kubectl apply -f https://k8s.io/examples/application/deployment.yaml
  • Mostrando informações do deploy:
# kubectl describe deployment nginx-deployment
  • Listando o POD criado no deploy
# kubectl get pods -l app=nginx

Helm

É um gerenciador de pacotes para aplicações kuberneteshttps://helm.sh/docs/topics/architecture/.

  • Arquitetura:
    • Tiller Server: O Helm gerencia aplicações kubernetes através do componente chamado Tiller Server, instalado no cluster kubernetes. Tiller interage com a API do kubernetes para fazer a instalação, upgrada e remoção dos recursos
    • Helm Client: É uma interface de linha de comando que interage com o Tiller Server para executar várias operações como instalação, upgrade, etc.
. Instalar mysql no cluster kubernetes # helm install bitnami/mysql --generate-name . Listar aplicações instaladas # helm ls . Desinstalar # helm uninstall mysql-1612624192

Conhecimento de OpenShift, Rancher e Mesosphere DC/OS

  • Openshift: "O Red Hat® OpenShift® é uma plataforma de aplicações em container Kubernetes para empresas com operações automatizadas em todo o stack. Sua função é gerenciar implantações de nuvem híbrida, multicloud e edge. O Red Hat OpenShift é otimizado para aprimorar a produtividade do desenvolvedor e promover a inovação."https://www.openshift.com/. Facilita o processo de orquestração de containers em uma interface intuitiva e amigável.
  • Rancher: https://rancher.com/ é um gerenciador de infraestrutura kubernetes, ou seja ele monitora a saúde dos cluster kubernetes e automatiza o deploy de aplicações em containers
  • Mesosphere DC/OS: https://d2iq.com/products/dcos É um sistema operacional de data center, baseado no Apache Mesos, suportando até 50.000.000. Este produto esta sendo descontinuado e migrando para o D2iQ Kubernetes Platform (DKP)https://d2iq.com/kubernetes-platform
Clone this wiki locally