nomad driver containerd
Version 0.9.4
Estamos procurando ativamente contribuidores e mantenedores para este projeto. Se você tem experiência em contêineres, por exemplo, cgroups, namespaces ou contribuiu para qualquer projeto de código aberto em torno de contêineres, por exemplo, docker , containerd , nerdctl , podman etc. ou construir ferramentas que envolvem lidar com os internos de contêineres e estão interessados em contribuir para este projeto, eu adoraria falar para você! A experiência de Golang é preferida, mas não é necessária.
Entre em contato comigo @_shishir_m ou abra um problema neste repositório com seus detalhes de contato, se você estiver interessado em contribuir para este projeto.
Driver de tarefa nômade para iniciar contêineres usando o contêiner.
O Containerd (containerd.io) é um daemon leve de contêiner para executar e gerenciar o ciclo de vida do contêiner.
O Docker Daemon também usa o contêiner.
dockerd (docker daemon) --> containerd --> containerd-shim --> runc
O Nomad-Driver-containerd permite que o cliente NOMAD inicie os contêineres diretamente usando o contêiner, sem o Docker!
O Docker Daemon não é necessário no sistema de host.
Verifique se o seu $ Gopath está configurado corretamente.
$ mkdir -p $GOPATH/src/github.com/Roblox
$ cd $GOPATH/src/github.com/Roblox
$ git clone [email protected]:Roblox/nomad-driver-containerd.git
$ cd nomad-driver-containerd
$ make build (This will build your containerd-driver binary)
Se você deseja compilar para arm64 , pode executar:
make -f Makefile.arm64
$ vagrant up
ou vagrant provision se a VM Vagrant já estiver em execução.
Depois que a configuração ( vagrant up ou vagrant provision ) estiver concluída e o servidor Nomad estiver em funcionamento, você pode verificar os drivers de tarefas registrados (que também mostrarão containerd-driver ) usando:
$ nomad node status (Note down the <node_id>)
$ nomad node status <node_id> | grep containerd-driver
NOTA: setup.sh faz parte da configuração do Vagrant e não deve ser executado diretamente.
Existem poucos exemplos de trabalhos no diretório example .
$ nomad job run <job_name.nomad>
lançará o trabalho.
Instruções mais detalhadas estão no example README.md
Para interagir com images e containers diretamente, você pode usar nerdctl , que é uma CLI compatível com o Docker para containerd . nerdctl já está instalado na VAGRANT VM AT /usr/local/bin .
Config do motorista
| Opção | Tipo | Obrigatório | Padrão | Descrição |
|---|---|---|---|---|
| habilitado | bool | não | verdadeiro | Ativar/desativar o driver de tarefas. |
| Containerd_runtime | corda | sim | N / D | Tempo de execução para contêiner, por exemplo, io.containerd.runc.v1 ou io.containerd.runc.v2 . |
| STATS_INTERVAL | corda | não | 1s | Intervalo para coletar TaskStats . |
| allow_privileged | bool | não | verdadeiro | Se definido como false , o motorista negará empregos privilegiados em execução. |
| Auth | bloquear | não | N / D | Fornecer autenticação para um registro privado. Consulte Autenticação para obter mais detalhes. |
Config de tarefas
| Opção | Tipo | Obrigatório | Descrição |
|---|---|---|---|
| imagem | corda | sim | O OCI Image (Docker também é compatível com OCI) para o seu contêiner. |
| image_pull_timeout | corda | não | Uma duração de tempo que controla quanto tempo containerd-driver aguardará antes de cancelar um puxão em andamento da imagem OCI, conforme especificado na image . Padrões para "5m" . |
| comando | corda | não | Comando para substituir o comando definido na imagem. |
| args | []corda | não | Argumentos para o comando. |
| Ponto de entrada | []corda | não | Uma lista de strings substituindo o ponto de entrada da imagem. |
| cwd | corda | não | Especifique o diretório de trabalho atual para o seu processo de contêiner. Se o diretório não existir, será criado para você. |
| privilegiado | bool | não | Execute o contêiner no modo privilegiado. Seu contêiner terá todos os recursos do Linux ao executar em modo privilegiado. |
| pids_limit | Int64 | não | Um valor inteiro que especifica o limite PID para o contêiner. Padrões para ilimitar. |
| pid_mode | corda | não | host ou não definido (padrão). Defina para host para compartilhar o espaço para nome PID com o host. |
| nome do host | corda | não | O nome do host para atribuir ao contêiner. Ao iniciar mais de uma tarefa (usando count ) com este conjunto de opções, cada contêiner que a tarefa inicia terá o mesmo nome de host. |
| host_dns | bool | não | Padrão ( true ). Por padrão, um contêiner lançado usando containerd-driver usará host /etc/resolv.conf . Isso é semelhante ao docker behavior . No entanto, se você não quiser usar o host DNS, poderá desativar esse sinalizador configurando host_dns=false . |
| Seccomp | bool | não | Ativar perfil padrão do Seccomp. Lista de allowed syscalls . |
| seccomp_profile | corda | não | Caminho para o perfil do Seccomp personalizado. seccomp deve ser definido como true para usar seccomp_profile . O perfil padrão docker Seccomp encontrado here pode ser usado como referência e modificado para criar um perfil do Seccomp personalizado. |
| shm_size | corda | não | Tamanho de /dev /shm, por exemplo, "128m" se você deseja 128 MB de /dev /shm. |
| sysctl | mapa [string] string | não | Um mapa de valor-chave das configurações SySCTL para definir para os contêineres no início. |
| readonly_rootfs | bool | não | O sistema de arquivos root de contêiner será somente leitura. |
| host_network | bool | não | Ativar rede host. Isso é equivalente a --net=host no Docker. |
| extra_hosts | []corda | não | Uma lista de hosts, dados como host: IP, a ser adicionado a /etc /hosts. |
| cap_add | []corda | não | Adicione recursos individuais. |
| CAP_DROP | []corda | não | Solte os recursos de invidir. |
| dispositivos | []corda | não | Uma lista de dispositivos a serem expostos ao contêiner. |
| Auth | bloquear | não | Fornecer autenticação para um registro privado. Consulte Autenticação para obter mais detalhes. |
| montagens | []bloquear | não | Uma lista de montagens a serem montadas no recipiente. Os suportes do tipo volume, ligação e tmpfs são suportados. mount options em estilo FSTAB são suportadas. |
Bloco de montagem
{
- Tipo (String) (Opcional): Os valores suportados são volume , bind ou tmpfs . Padrão: volume.
- Target (String) (requerido): caminho de destino no contêiner.
- Fonte (String) (Opcional): Caminho de origem no host.
- Opções ([] String) (Opcional): mount options no estilo FSTAB. NOTA : Para montagens de ligação, são necessários pelo menos rbind e ro .
}
Vincular um exemplo de montagem
mounts = [
{
type = "bind"
target = "/target/t1"
source = "/src/s1"
options = ["rbind", "ro"]
}
]
Além da opção de mounts na Task Config , você também pode montar seus volumes no contêiner usando nomad volume_mount stanza
Consulte example job para volume_mount .
Exemplo personalizado de perfil de seccomp
O perfil padrão docker Seccomp encontrado here pode ser baixado e modificado (removendo/adicionando syscalls) para criar um perfil Seccomp personalizado.
O perfil do Seccomp personalizado pode ser salvo em /opt/seccomp/seccomp.json nos nós do cliente NOMAD.
Um trabalho nômade pode ser iniciado usando esse perfil de segredo personalizado.
config {
seccomp = true
seccomp_profile = "/opt/seccomp/seccomp.json"
}
Exemplo sysctl
config {
sysctl = {
"net.core.somaxconn" = "16384"
"net.ipv4.ip_forward" = "1"
}
}
A Stanza auth permite definir credenciais para o seu registro privado, por exemplo, se você quiser extrair uma imagem de um repositório privado no Docker Hub.
auth stanza pode ser definida na Driver Config ou Task Config ou em ambos.
Se definido em ambos os locais, a Auth Task Config terá precedência sobre Driver Config Auth.
Nota : No exemplo abaixo, user e pass são apenas valores de espaço reservado que precisam ser substituídos pelo username e password reais, ao especificar as credenciais. Abaixo, a Stanza auth pode ser usada para Driver Config e Task Config .
auth {
username = "user"
password = "pass"
}
nomad-driver-containerd suporta redes de host e ponte .
Nota: host e bridge são opções mutuamente exclusivas, e apenas uma delas deve ser usada por vez.
A rede de host pode ser ativada definindo host_network como true na configuração de tarefas da especificação do trabalho (consulte Supported options ).
A Bridge Network pode ser ativada definindo a estrofe network na seção do grupo de tarefas da especificação do trabalho.
network {
mode = "bridge"
}
Você precisa instalar os plugins CNI nos nós do cliente NOMAD em /opt/cni/bin antes de poder usar redes bridge .
Instruções para instalar plugins CNI.
$ curl -L -o cni-plugins.tgz https://github.com/containernetworking/plugins/releases/download/v0.8.6/cni-plugins-linux-amd64-v0.8.6.tgz
$ sudo mkdir -p /opt/cni/bin
$ sudo tar -C /opt/cni/bin -xzf cni-plugins.tgz
Além disso, verifique se a distribuição do sistema operacional Linux foi configurada para permitir que o tráfego de contêineres através da rede de pontes seja roteado via iptables. Esses tunables podem ser definidos da seguinte forma:
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
Para preservar essas configurações na inicialização de um nó do cliente NOMAD, adicione um arquivo, incluindo o seguinte a /etc/sysctl.d/ ou remova o arquivo que sua distribuição Linux coloca nesse diretório.
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
O Nomad suporta mapeamento de porta estática e dinâmica .
O mapeamento de porta estática pode ser adicionado na estrofe network .
network {
mode = "bridge"
port "lb" {
static = 8889
to = 8889
}
}
Aqui, a porta host 8889 é mapeada para a porta container 8889 .
NOTA : As portas estáticas geralmente não são recomendadas, exceto para trabalhos system ou especializados, como balanceadores de carga.
O mapeamento dinâmico de porta também está ativado na estrofe network .
network {
mode = "bridge"
port "http" {
to = 8080
}
}
Aqui, o Nomad alocará uma porta dinâmica no host e essa porta será mapeada para 8080 no contêiner.
Você também pode ler mais sobre network stanza na nomad official documentation
Nomad agenda cargas de trabalho de vários tipos em um cluster de hosts genéricos. Por esse motivo, o posicionamento não é conhecido com antecedência e você precisará usar a descoberta de serviços para conectar tarefas a outros serviços implantados em seu cluster. O Nomad se integra ao Consul para fornecer descoberta e monitoramento de serviços.
Uma estrofe service pode ser adicionada às suas especificações de trabalho, para ativar a descoberta de serviços.
A estrofe de serviço instrui o Nomad a registrar um serviço com cônsul.
Se você estiver executando os testes localmente, use a vagrant VM fornecida no repositório.
$ vagrant up
$ vagrant ssh containerd-linux
$ sudo make test
Nota : Estes são testes destrutivos e podem deixar o sistema em um estado alterado.
É altamente recomendável executar esses testes como parte de um sistema CI/CD, por exemplo, Circleci ou em uma infraestrutura imutável, por exemplo, VMs Vagrant.
Você também pode executar um teste individual especificando o nome do teste. por exemplo
$ cd tests
$ sudo ./run_tests.sh 001-test-redis.sh
make clean
Isso excluirá seu binário: containerd-driver
vagrant destroy
Isso destruirá sua VM vagante.
Ubuntu (> = 16.04)
Copyright 2020 Roblox Corporation
Licenciado sob a licença Apache, versão 2.0 (a "licença"). Para mais informações, leia a licença.
