lucaslehnen / homelab Goto Github PK

Problema:

No on-premise, não há driver adequado para volumes persistentes no Kubernetes. Como precisarei colocar bancos de dados no cluster, idealmente preciso de um StorageClass que permita o compartilhamento dos dados entre os nós.

Proposta:

O mais simples é utilizar o NFS, já que as melhores alternativas como o Rook Ceph e o Longhorn exigem muitos recursos de RAM e CPU devido aos inúmeros componentes. Apesar de não ser tão confiável e não ser uma opção para produção, não são desperdiçados recursos de CPU e RAM com inúmeros componentes de controle e replicação de dados.

Detalhes:

Tem um driver de volume que suporta o CIFS, avaliar se não dá pra usar com o roteador Archer. Se funcionar, posso colocar um SSD no Roteador.
https://github.com/juliohm1978/kubernetes-cifs-volumedriver

O Uso de Ceph e Longhorn eu ainda colocarei nas automatizações para futuras referências, mas em outra issue #.

Tarefas:

• Configurar um driver de volume que não consuma muitos recursos do cluster

Problema:

Quero poder interagir com o meu ambiente por voz e ser alertado de problemas no mesmo.
Tenho plugs inteligentes, podendo interagir com o Ar Condicionado do escritório, Luzes e desligar o cluster das Raspberrys.
No futuro, posso ter sensores nas raspberrys para permitir mais funções ou outros dispositivos.
Quero poder ligar e desligar recursos do cluster via voz.

Proposta:

Construir uma skill particular para se integrar neste ambiente.

Detalhes:

Ainda não sei como desenvolver, será a primeira do tipo.

Tarefas:

• Projetar skill inicial para trazer alertas do ambiente e ligar e desligar recursos;

Problema:

Quero entender em que momento começa a fazer sentido o uso de Service Mesh.

Proposta:

• Testar o Linkerd e compará-lo com o Istio, entendendo os casos de uso e que problemas de fato ele resolve.

Detalhes:

Tem que ficar claro o porque da sua necessidade. Porque não utilizar apenas o Jaeger, e outras soluções para métricas e monitoramento.

Tarefas:

• Escrever os manifestos e implantar no cluster
• Fazer uma aplicação com micro serviços onde consiga aplica-lo em sua plena magnitude;

Problema:

Muitas empresas tem um K8s em produção no on-premise, e a questão de gerenciamento de volumes pensintentes é um ponto crítico. Normalmente usando NFS, quando não é uma solução adequada para o caso de uso. Preciso ser capaz de colocar uma opção "production ready".

Proposta

Como tenho recursos limitados, a proposta é subir as versões simplificadas e mínimas do Rook Ceph e do Longhorn.
Apesar de não ser o cenário completo com alta disponibilidade, vou conseguir entender melhor os componentes das soluções e no futuro conseguir aplicar em alguma empresa.

Detalhes

Tarefas:

• Testar o cluster-test, recursos mínimos do Rook Ceph no cluster de VM's. Aparentemente vai ter que ser em três nós com mais recursos.
• Testar o longhorn e entender pré-requisitos
• Se alguma das soluções se provar cabível às raspberrys, colocar (Mas pelos requerimentos no site, não me parece que vai ser uma boa, porque vão ocupar muito recurso)

Problema:

Tenho três raspberrys. 2 de 2 GB e uma de 4 GB. Quero utilizá-las para rodar minhas aplicações de testes.

Proposta

Preparar as mesmas com três distros distintas de linux, tem que englobar ao menos as duas principais famílias (Debian, Red Hat). A sugestão inicial é que seja Ubuntu, Centos Stream e Debian.

Detalhes:

• O ambiente deve estar pronto para receber conexões SSH de um pc;
• Deve ser criado um usuário administrador ( que permita a escalação para root);
• Os ips devem ser estáticos
• O firewall precisa ser configurado

Tarefas Manuais - Será feito à mão e documentado

• Configurar sudo para escalar sem senha
• Habilitação de SSH e registro de chave para acesso sem senha
• Configuração do IP estático

Tarefas via playbook

• Configuração do timezone
• Regras de firewall
• Estrutura de pastas
• Pacotes genéricos

Problema:

K8s na AWS é utilizado em várias empresas e atualmente não tenho experiência com o mesmo. Durante laboratórios na AWS, preciso subir e destruir rapidamente os clusters.
Esse cluster só ficará online durante testes no ambiente.

Proposta:

Usar o terraform como ferramenta para provisionar os clusters.

Detalhes:

Tarefas:

• Criar script de Terraform para o provisionamento;
• Comparar estrutura do EKS com o do K8s Vanilla

Problema:

A configuração do monitoramento que fora implementado na issue #27 . O chart traz vários exemplos, mas muito material desnecessário. Uma visão mais simplificada auxiliaria.

Proposta:

Um único dashboard orientado à negócio, mostrando o impacto real de indisponibilidade de serviços. A partir deste dash, deve ser possível fazer um "drill-down" para dashboards mais técnicos em busca do problema.
É necessário analisar primeiramente o que pode ser aproveitado dos dashboards existentes para evitar retrabalho.

Detalhes:

• Tentar manter a simplicidade e o foco no negócio;

Tarefas:

• Criar dashboard inicial
• Criar alertas básicos de hardware
• Criar alertas de negócio

Problema

Frequentemente estou fazendo testes em distros e as vezes remodelando o meu pc.

Proposta

Gostaria de automatizar a configuração e instalação dos pacotes padrões na minha distribuição preferida (Debian)

Tarefas

• Brave/Edge
• VSCode
• Tilix
• Oh-my-Zsh
• ufw
• git

Problema:

A instalação de algumas distribuições de k8s pode ser bem complicada e demorada, e vou acabar tendo que reinstalar o meu ambiente do laboratório diversas vezes para os testes.

Proposta:

A ideia é utilizar Ansible, já que o escopo desta tarefa é apenas no ambiente on-premise, onde estarei lidando com sistemas operacionais ao invés de provedores de nuvem.
As distribuições de K8s que espero utilizar são o k3s da Suse, o k0s da Mirantes e o k8s "vanilla" instalado com o kubeadm.

Detalhes:

• Não há necessidade de alta disponibilidade, pois tenho apenas três Raspberrys que totalizam apenas 8GB de RAM. Contudo, vou separar esse recurso em outra issue para futura implementação;
• Não quero utilizar o que as distros trazem por padrão, mas sim fazer a instalação separadamente das ferramentas como o Traefik e o Helm no caso do K3s;
• O script deve suportar arquiteturas arm64 e amd64;
• Planejar suportar pelo menos as duas famílias das principais distros linux (Debian/Ubuntu e CentOS/RHEL)
• A automação desta tarefa deve prever apenas a instalação das distros "limpas", sem aplicações adicionais (estarão em issues específicas).

Tarefas:

• Instalação do k3s ;

Quebrei as tarefas abaixo em outras issues

• #58
• #59

O rancher server tem algum benefício ao invés do Lens?
Comentar diferenças e montar um post no medium sobre as duas ferramentas.

http://wiki.ubuntu-br.org/UFW

Habilitar o firewall e configurar as regras.

Adicionar uma role "ufw" na collection tchecode.k3s

• memória;

• cpu;

• disco;

• requests por serviço;

• traefik;

• up dos services;

Criar uma pasta em /dados nas raspberrys.

A Raspberry que ficar com o MicroSD terá 80 GB dele alocado para esta partição.

As demais irão receber os SSD's via USB, montar a partição a partir deles.

Este espaço será dedicado para os volumes de containers.

Problema / Proposta

Continuar a configuração do cenário 1 descrito na issue #50 .

Detalhes

O VMWare Player não vem com todos os requisitos para automatizar a instalação e configuração das máquinas, portanto apenas o Workstation funciona por hora.

Tive problemas para fazer o ESXi

Tarefas

• Baixar o VMWare Workstation
• Instalar o VMWare Workstation programaticamente
• Baixar o ESXi
• Configurar Kickstart do ESXi
• Configurar ESXi para rede bridged
• Montar template Packer do ESXi para o Workstation
• Montar template Terraform para subir a máquina do ESXi no Workstation

Instalar o Rook com Ceph no cluster de K8s.
Avaliar o funcionamento da ferramenta e comparar com o Longhorn

Problema:

Tenho várias distrações enquanto estou no pc, sempre trocando entre note e pc e entre sistemas.

Proposta:

• Colocar o Pi-Hole para reduzir a quantidade de anúncios durante a navegação;
• Colocar o ActivityWatch server em container, para conseguir mapear as ações entre os pcs;
• Colocar o VS Code server no kubernetes;

Detalhes:

• Se necessário, criar repositórios específicos para os helm charts customizados (Caso não tenha);
• o código das apps vai para o homelab;

Tarefas:

• Criar ou utilizar um helm chart para o pi-hole;
• Colocar o ActivityWatch Server em um container. Parece que vai ser necessário fazer o build por mim mesmo para o arm64, pois não há um pacote pronto pelo repositório oficial. O link a seguir pode ajudar: https://docs.activitywatch.net/en/latest/installing-from-source.html;
• Colocar o Code Server em um Helm Chart

Problema

Não conheço bem o Consul, mas parece ser uma ferramenta bem utilizada e atende camada de rede virtual, podendo fechar redes virtuais seguras entre dcs para as aplicações.

Proposta

Estudar a ferramenta e avaliar casos de uso.

Detalhes

Tarefas

• Estudar documentação
• Implantar nos clusters
• Avaliar caso de uso

Problema:

Como utilizo vários computadores, fica complicado manter os manifestos e o deploy a partir de um só, fora que não é o modelo utilizado em empresas.
As aplicações ficarão em repositórios distintos, a configuração do ambiente e o que deployado em cada um precisa ficar em uma ferramenta para gestão.

Proposta:

Experimentar o Argo CD, uma ferramenta "GitOps", que foca o processo todo no GIT. Gostei do modo de trabalho dele e pode trazer um modo claro e fácil de entregar as soluções no ambiente. Se não rolar, usar o GitLab CE. Além do Argo, que pretendo deixar, vou colocar o GitLab de qualquer maneira para testes da ferramenta, já que tenho um curso completão dele pra fazer.

Detalhes:

Estudar bem como funciona a comunicação com o GitHub, provavelmente será necessário adicionar alguns endpoints externos para os hooks.

Tarefas:

• Montar manifestos de deploy do Argo;
• Fazer o deploy da primeira aplicação no modelo gitops
• Instalar o GitLab CE no cluster e fazer curso. Se o Argo não encaixar no meu ambiente, colocar ele no homelab, caso contrário, criar outro repo para a instalação e configuração.

Problema

Precisei duplicar código com uma sequencia de tarefas que tem o mesmo objetivo: Restaurar um arquivo previamente criado.

Proposta

Usar um módulo ao invés de escrever as tasks. Poderia dar mais opções para garantir que o arquivo a ser restaurado seja de fato o anterior à execução do playbook.

Detalhes

Código duplicado

• https://github.com/lucaslehnen/tchecode.libvirt/blob/main/roles/reset/tasks/network.yml
• https://github.com/lucaslehnen/homelab/blob/main/roles/uninstall-cache/tasks/main.yml

Tarefas

Utilizar a role Ansible criada para instar o k3s nas raspberrys.

Problema:

A Oracle tem vários recursos de computação que são sempre gratuitos, não utilizá-los é um desperdício.

Proposta:

• Aparentemente, é possível configurar o open vpn para ter a própria vpn. Avaliar onde eu poderia me beneficiar disso. https://blogs.oracle.com/developers/post/launching-your-own-free-private-vpn-in-the-oracle-cloud.
• Também há conexões de VPN site-to-site que são sempre free, mas aí tem que ver se não é utilizado algum outro componente com custo;
• Eu já sabia de 2 vms com 1/8 de OCPU AMD, mas vi que também é possível subir até 4 VM's com processadores arm A1 e 24GB de RAM. Isso é muita coisa. Algum recurso que eu queria no meu ambiente que use muita ram, posso transferir para a OCI no arm. Eles tem bastante espaço em disco (100GBX2) em blocos, então dá pra por bastante coisa também. Inicialmente, acho interessante fazer um teste com o nomad. Se eu quiser um recurso extra de arm, ainda dá pra pedir no link https://www.oracle.com/br/cloud/compute/arm/ o programa Arm Accelerator.
• Ver com mais detalhes o banco nosql, se faz sentido usar em alguma solução dentro do nomad.

Detalhes:

Tarefas:

• Montar terraform para a conta da OCI
• Montar packer para construir as imagens que irei utilizar com nomad;
• Automatizar a instalação do nomad;
• Tentar construir/fechar VPN com meu ambiente on-premise

Problema

Vou ter várias aplicações rodando no ambiente e quero que seja possível correlacionar logs de diversos componentes no meu ambiente quando precisar encontrar algum problema.

Proposta:

Testar algumas soluções de agregação além do Graylog que eu já conheço.
O Loki da Grafana parece uma boa, talvez até o cloud gratuito deles com retenção de 14 dias. https://grafana.com/products/cloud/pricing/

Um que é muito utilizado é a suíte ELK, acredito que é indispensável eu instalar e lidar um pouco com ela para pegar mais experiência.

Detalhes:

Eu tenho um pé atrás constante com o Elastic Search, porque os índices dele sempre me deram dor de cabeça. Não só a suíte ELK usa, mas o Graylog também. Não é uma solução fácil de manter. O Loki a princípio não faz uso do elastic search, provavelmente vai ser a escolha para o ambiente, preciso avaliar.

Tarefas

• Criar manifestos do ELK e simular uso, enviando logs do Linux, de aplicações, etc
• Criar manifestos do Loki, integrar ao Grafana e simular uso, enviando logs do Linux, de aplicações, etc
• Criar manifestos do Graylog e simular uso, enviando logs do Linux, de aplicações, etc
• Escolher uma das stacks para permanecer no cluster de raspberry. Se não for o ELK, colocar o ELK no cluster de VM para os testes mais apurados;

Problema:

Dado que tenho alguns serviços que precisam ser expostos em portas específicas no cluster, inclusive expostos para a Cloudflare, vou precisar de uma solução de ingress.

Proposta:

Utilizar o Traefik devido à experiência passada no Swarm, onde me atendeu muito bem.
Mais pra frente isso a ferramenta pode ser substituída com o uso de service mesh (ou não), mas por enquanto ela deva atender perfeitamente.

Detalhes:

• Implementar o uso via documentação do Traefik, não utilizar a versão de dentro das distros como o k3s.

Tarefas:

• Verificar funcionamento do Traefik do k3s
• Montar manifestos de implantação do Traefik

Nós:
CPU
Memória
Disco alocado
Rede

Containers:
Status gerais do nó quanto a containers

Alertar quando:

• Sem espaço em disco
• systemload muito alto
• Número de conexões muito alto

Problema:

Quando tentei usar o módulo do Kubernetes para o Ansible, tive erro ao instalar charts, pois precisava do helm-diff e não tinha como instalar, já que não há versão pré-buildada para arm64. Como é uma aplicação em Go, fazer o build deve ser tranquilo.

Proposta:

Fazer o build para arm64, permitindo atualizar as roles de Ansible para usar o que tem de melhor.

Detalhes:

• Analisar a estrutura de desenvolvimento do plugin, se possível contribuir com o projeto, fazê-lo.

Tarefas:

• Fazer o fork, o build para arm64 e abrir PR;
• Verificar melhorias nas roles de ansible criadas;

Problema / Proposta:

A Daiane (minha noiva) gosta dos jogos arcade e pode ser uma boa jogar uns games em pequenos intervalos de estudo e trabalho.
Encontrei um emulador em rust que parece ser interessante:
https://github.com/kamiyaowl/rust-nes-emulator

Detalhes:

Tarefas:

• Criar o Helm Chart para o emulador

Modificar scripts de instalação do k8s para a utilização do metallb como loadbalancer on-premise.
Apesar de não ser necessário no momento para meu ambiente, a experiência adquirida com está implementação pode me ajudar no futuro.

Problema:

Quero entender em que momento começa a fazer sentido o uso de Service Mesh.

Proposta:

• Testar o Istio, enquanto refaço o treinamento que adquiri, entendendo os casos de uso e que problemas de fato ele resolve.

Detalhes:

Tem que ficar claro o porque da sua necessidade. Porque não utilizar apenas o Jaeger, e outras soluções para métricas e monitoramento.

Tarefas:

• Escrever os manifestos e implantar no cluster
• Fazer uma aplicação com micro serviços onde consiga aplica-lo em sua plena magnitude;

Eu quero já poder ler no meu LENS.
Por hora, usar o usuário padrão.
Criei outra issue para brincar com o RBAC

Problema:

Preciso ter uma maneira fácil de fazer o deploy das ferramentas que quero utilizar nos cluster.

Proposta:

O Helm é o principal gerenciador de pacotes do K8s atualmente, apesar de não ser perfeito, auxilia nos deploys e distribuição. A ideia é colocar as próprias aplicações em charts, além de utilizar os já existentes para as aplicações tradicionais.
A princípio, o caminho é fazer uma play do ansible.

Detalhes:

• Avaliar bem o caso. Interessante é criar um Helm Chart de exemplo. Como ainda estou aprendendo Kubernetes, pode ser interessante construir os próprios charts.

Tarefas:

• Instalar o Helm no Cluster;

Colocar uma lista das tasks, o que cada role faz

Problema

Ainda não estou muito habituado ao uso de tracing e preciso ver mais conteúdo para conseguir utilizar uma ferramenta adequadamente no troubleshooting de micro serviços.

Proposta

Vi que o Jaeger é uma ferramenta muito utilizada, inclusive o Traefik já integra com ele. A Ideia seria colocar ele no ambiente e incorporar o tracing nas aplicações que for desenvolver. Seria interessante fazer um review do opentelemetry e opentracing tambem, entendendo se as ferramentas se complementam e/ou são opcionais.

Detalhes

Tarefas

• Instalar o Jaeger
• Review do Opentracing
• Review do Opentelemetry

Será criado uma job para fazer o backup dos dados que estarão sendo executados no ambiente do cluster.

Irei atachar um HDD de 1 TB na raspberry via USB

Problema:

Sem monitoramento vai ficar complicado acompanhar a capacidade e saúde dos clusters. Uso de CPU, memória e armazenamento são recursos que precisam ser monitorados, e caso seja necessário preciso ser alertado sobre problemas.

Proposta:

Colocar o Helm Chart https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack que já tem o Prometheus, Grafana e Alert Manager.

Detalhes:

• O escopo desta tarefa é apenas da sua instalação, pois será criada outra issue para configuração dos dashboards e dos alertas. Por enquanto, apenas os exemplos existentes serão utilizados.

Tarefas:

• Instalação do helm chart;
• Configuração dos acessos básicos;

Helm + Plugin Diff

Problema:

Preciso configurar máquinas virtuais para utilizar no ambiente. Instalei um Debian no meu PC desktop.

Proposta

A ideia inicial é utilizar o libvirt/qemu para rodar as máquinas virtuais.

Detalhes

Pode ser automatizado com Terraform ou Ansible. Como eu preciso configurar o host físico de virtualização, que é uma máquina já instalada mas sem pacote algum, eu posso usar o Ansible como primeira etapa para instalar o libvirt e configurar a máquina e na sequência o Terraform para provisionar as vms com libvirt.
O Ansible também tem o módulo do libvirt, mas acredito que seja uma oportunidade de já encaixar o Terraform.
Da pra usar o Packer para montar imagens customizadas também.

Um fluxo possível seria:

• Ansible: Conecta no host e instala e configura o libvirt;
• Packer: Builda as imagens a serem utilizadas;
• Ansible: Roda a partir do Packer para instalar o que vai na imagem (provisioner)
• Terraform: Provisiona as máquinas virtuais

Neste cenário, seria um teste de trabalho com o conceito de imutabilidade.

Tarefas

• Ansible playbook para configurar o servidor com libvirt;
• Packer para construção da imagem base;
• Terraform para provisionar as vms;

• Ansible playbook para configurar a imagem da VM (Tem uma issue pra isso)

Deve ser possível isntalar o k3s em vm alem das raspberrys

As roles estão muito dependentes. Contudo, não acho interessante colocar em um playbook. Uma opção que pode manter o compartilhamento que busco e ainda sim agrepa-las, é colocar em uma collection.