lucaslehnen / homelab Goto Github PK

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:

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;

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

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

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:

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:

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;

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 / 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

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

Habilitar o firewall e configurar as regras.

Adicionar uma role "ufw" na collection tchecode.k3s

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.

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

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

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

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

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:

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

• memória;

• cpu;

• disco;

• requests por serviço;

• traefik;

• up dos services;

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;

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:

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)

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.

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:

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:

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

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:

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:

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)

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

Helm + Plugin Diff

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:

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

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

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;

Colocar uma lista das tasks, o que cada role faz

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

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.

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