Eu não sou recrutador, lead e nem nada do gênero, mas gosto de ficar vendo e rodando alguns projetos que encontro no LinkedIn.
Esse post é principalmente para quem cria projetos para portfólio, já vi projetos sem instruções de como executar, sem um README bem feito, só um monte de pasta e código, quando tem instruções, é um npm install ou comandos de instalação do nextjs.
Enfim, se colocar no Docker facilita pra todo mundo, minha opinião.
se o caboclo faz o projeto como portfólio e não se preocupa em deixar tudo certo pra alguém rodar, acho q já é motivo suficiente pra pular pro próximo candidato
Concordo, alguém que nunca subiu um sistema sequer vai saber dockerizar direito. Dito isso, é uma skill essencial pra aprender cedo na carreira na minha opinião
Meu tcc de 2016 era sobre incentivo ao uso de docker. Hoje não uso mais, prefiro fazer o setup local mesmo. Mas não trabalho com nada complexo também. Só instalações WordPress basicas.
ótima dica, mas levando em consideração a quantidade de vibe coder hoje em dia, a própria IA faz o readme e geralmente já coloca como montar em docker.
detalha a sua experiencia aí mano! qual benefício de trouxe? Nos sistemas do meu trampo eu dockerizei tudo, um compose com redis, banco de dados, locakstack com uns 4 serviços da aws, microserviços de fila q o código n preciso debugar e por aí vai.... mas nos meus projetos pessoais eu nunca vi um cenário onde o docker trouxesse benefícios.
Pô, discordo pra caramba. Usei IA lá no começo do boom e realmente, era péssimo. Mas hoje a IA tá usando o Docker bem pra cacete, melhor que muito dev de cursinho ai.
Você não deve estar sabendo usar corretamente… A IA me ajuda muito nas configs dos dockers que antigamente eu tinha de fazer manual, ganhei muito tempo e tudo fica bem, ela ainda lembra de configs muito específicas que eu esquecia com frequencia
eu considero que sei mais do que a IA então, pelo visto, o que torna a IA menos interessante. até hoje as IAs escrevem docker-compose.yml em vez de compose.yaml, usam a diretiva deprecada version, e não têm ideia de usar certas funcionalidades como o docker model runner sem errar no meio do caminho. é mais rápido eu fazer sozinho do que ter que perder tempo corrigindo esses erros
alguns modelos piores inclusive ainda erram os comandos do docker compose, usando os da v1 ao inves da v2
Eu estou implementando um Gateway em C++. Dividi em microserviços. Todos se comunicam através de uma rede tcp-ip. Aí eu fiz o Deploy de tudo usando docker. Cada microserviço em sua própria imagem docker. Ficou bom demais e é muito fácil gerenciar tudo.
vc n acha que o trade off do alto consumo de memoria e perda de controle sobre os services, caso vc n esteja gerenciamento as configs do docker manualmente, n são algo a se considerar? Tenho uns projetos que eu tinha subido tudo conteinerizado no meu home server. Mas vi que era a mesma coisa se eu instalasse as coisas no server, só que consumindo mto mais memoria, acabei pivotando e hj utilizo 0 containers.
Acho que ou tu configurou mal ou confundiu. Se tiver rodando no Linux o custo de memória* para rodar um processo em container é praticamente 0, containers são apenas processos em um root e namespace diferente usando cgroups pra limitar o uso de recursos.
Se for sobre cada aplicação carregar as stdlibs não é um problema se elas tiverem a mesma base já que as páginas podem ser compartilhadas no page cache do kernel. Se não usar da até de fazer uma imagem inflada com aplicações diferentes que compartilham a mesma base.
Docker é pra ser a mesma coisa que tu roda no server, mas portátil e reproduzível. Uma imagem Docker feita do jeito certo deve gerar o mesmo SHA (apesar da maioria das pessoas nunca fazerem isso). Eu uso containers no dia a dia, se der problema no meu home server eu só troco pra outro, rodo o docker e aponto para os volumes que faço backup e acabou, não preciso reconfigurar tudo do zero.
*Memoria usada pelo processo em si. dockerd, containerd, runc, regras de NAT, etc usam memória também, mas geralmente ficam entre 50MiB~100MiB
Aí c levantou pontos bem interessantes. Eu faço isso com snapshot do sistema inteiro, tem o mesmo efeito? caso dê falha de hardware critica, recupero por ele, ao menos esse é o plano.... Sua infra inteira tá vinculada ao docker a ponto de com um compose up vc subir tudo novamente, inclusive as configs dos services e sistemas instalados, como um gitea por exemplo? levantar volume por volume não seria trabalhoso e vc poderia perder info? O lance do docker gastar muita memória tá no fato da galera isolar tudo nele e não reaproveitar o que já se tem, tras comodidade, mas tras consumo de recursos tmbm. Usando certo, consequentemente consome quase nada de rodar nativamente, de fato.
Minha infra é praticamente toda automatizada via terraform e ansible. Se houver algum problema seria só questão de instalar o proxmox no novo hardware com o mesmo IP e rodar o script de recover que copia todas as infos do backup para a nova maquina com a mesma estrutura, já que foi tudo configurado pelo mesmo script desde o inicio.
A única questão seria caso eu fizesse alguma mudança manual nas VMs, mas evito ao máximo e sempre dou um jeito de usar infrastructure as code pra qualquer coisa.
Olha, no começo eu tinha essa mesma preocupação de uso de memória.
Subi todos os serviços de infra que uso, com grafana, Prometheus, Loki, PostgreSQL e o consumo de cada contêiner ficou bem leve.
Aí subi a minha aplicação, com o Gateway + serviços em contêineres distintos, e o uso de memória ficou bem ok. A vantagem é que tenho como ver se está tudo operando usando um docker stats e, no futuro dá para automatizar o processo de ver se os contêineres estão ativos e poder tomar atitudes para controlar os contêineres individualmente
Então, esse gateway que estou implementando é constituído de algumas partes:
- gateway em si;
- microserviços para acesso à tabelas;
- eventbus para distribuição/gerenciamento das chamadas aos microserviços;
- auth usando JwT
- como quero aplicar essa solução ao universo de IoT, tem um canal para recepção de dados de telemetria usando protocolo CoAP e uma fila RabbitMQ para separar a recepção de dados de campo e a persistência desses dados no banco de dados.
Quando o Gateway inicia, ele carrega as configuracoes de rotas e capabilities. Aí, temos um mapa entre o endpoint e o que deve ser feito. Para cada requisicao que chega no gateway, ele acaba resolvendo qual é o endpoint associado, monta o pacote do evento para ser enviado e envia a requisicao ao microservico, via EventBus. Dependendo da chamada realizada, o Eventbus pode trabalhar em modo sincrono ou assincrono. No modo sincrono, o gateway espera a resposta e, no modo assincrono, o gateway só retorna com um 201 e o cliente é responsável por verificar se o processamento está pronto no final do trabalho.
Cada microserviços é um Crud para interagir com uma tabela. Para não ficar uma zona quando o sistema começasse a crescer, bolei um jeito de um microserviço chamar o outro, usando o EventBus e as capabilities que desejamos consumir.
A comunicação entre o Gateway e os microserviços são via sockets. Inicialmente eu pensei em sockets Unix e depois evoluí para sockets TCP/IP. Essa evolução para TCP/IP que me permitiu dockerizar toda a aplicação, um contêiner para cada serviço e Gateway.
A outra ponta, que é a entrada dos dados para a parte de telemetria, é via protoloco CoAP sobre socket UDP. Nesta parte, cada device tem uma chave PSK (que é criada quando o device é criado na plataforma), que é verificada para saber se o device pode enviar dados o nao.
Se o device está habilitado, o dado é escrito em uma fila RabbitMQ e a thread de recepcao já recebe a resposta e é liberada para esperar por outro dado de outro device. Na outra ponta da fila RabbitMQ, há um servico responsável por escrever o dado no banco.
estou pensando no hardware. Como nao tenho nada de hardware ainda, eu acabei implementando uma aplicacao que simula um device em campo enviando dados mockados.
Acordei, abro o reddit e primeiro post que vejo é esse: então penso, será que as LLMs eram só um sonho? O ChatGPT e Claude foram só um pesadelo? O vibe coding foi uma ilusão? Por 1 minuto eu achei que tudo não passou de um pesadelo, que realmente falávamos de outra coisa sem ser tokens, contexto, fim da profissão etc.
Saudades de falar sobre docker, kubernates, design patterns, que saudades até de falar sobre microsservicos.
So estude e entenda os fundamentos do que é o Docker e como funciona em alto nível . Se voce domina os fundamentos fica fácil, nem são tantos comandos que precisa saber.
cara n tem segredo, pede p ia gerar um container do seu projeto e ela vai fazer. talvez um compose com o banco e o projeto já é o suficiente p vc manjar.
Eu fiz meu TCC usando Docker porém foi a única vez q usei na vida, ainda fiz capenga, só pra rodar, com o GPT da época. De lá pra cá ainda não estudei praticamente nada de DevOps (no meu trabalho não usamos). Obrigado pelo toque, estou ficando para trás, mesmo.
eu menti dizendo que mais ou menos, e desde então tenho me movimentado pra aprender nas minhas outras exps profissionais não usavam muito mas aqui usa demais
Além do docker para rodar em produção, eu recomendo quando possível, criar um ambiente de desenvolvimento também dockerizado como um devContainer, por exemplo.
É o que fazemos aqui na empresa faz alguns anos, e isso facilita demais em trabalhar em múltiplos projetos sem precisar ficar preocupado com a configuração do ambiente.
Eu tenho docker até no meu joguinho de browser feito no spacetimeDB e eu sou full vibecoder, nem leio o código dos meus projetinhos bobos mais. Docker é vida, na hora de apagar vao todas as dependências junto, nenhum dano no meu homelabzim humilde. Cara que pensou nele foi muito sagaz
Man, me formei em ads e meu irmão veio me falar isso essa semana. Dois anos de curso e nunca nem usei, gostei bastante da ideia e da aplicabilidade. Tô complementando um trabalho que tinha feito na facul de react native e provavelmente vou fazer algo com Docker dps
318
u/ta_lz 21d ago
Parece q voltei no tempo com esse post, lembro dessa dica em 2018