DEV Community: Poveda

Performance pode ser simples: Arquivo gigante em memória

Poveda — Tue, 04 Feb 2025 13:48:56 +0000

Quando se fala em performance de uma aplicação é muito comum pensar em escovação de bit, mudança de paradigmas de implementação ou até mesmo de linguagem. No entanto, as principais otimizações acontecem olhando o básico: o gargalo atual da aplicação.

Nessa série de posts vou trazer alguns desafios que ajudei a resolver. A ideia é mostrar a linha de raciocínio, quais soluções se mostraram promissoras e quais soluções foram descartadas devido aos riscos adicionados. Em todos os casos demonstro que a ideia da otimização não teve qualquer coleta de ferramentas especializadas ou escovação de bit, apenas uso dos recursos do próprio visual studio, leitura de documentação, análise de código e conhecimento na linguagem utilizada.

Desafio: Geração do arquivo csv de 65Mb consumindo 1,2Gb de ram

Objetivo:

O sistema deve buscar no banco cerca de 200k registros, transformar os dados, gerar um arquivo .csv e transferi-lo para um fileserver remoto.

Cenário atual:

Todo o processamento e "armazenamento" dos dados fica em memória, ou seja, nada é salvo em disco do lado da aplicação. O arquivo só será salvo no disco do servidor de arquivos.

O problema encontrado:

Todo processamento aloca aproximadamente de 1,2Gb de memória para gerar um arquivo de aproximadamente 65Mb. Portanto existe um consumo de memória de 18x maior para gerar o arquivo em questão.

Mapeamento das restrições

O primeiro questionamento foi:

Por que não podemos salvar o arquivo localmente e em seguida transferi-lo o servidor de arquivos?

A resposta:

A data de publicação do sistema foi acordada com o cliente previamente e não pode mudar. Qualquer correção que ultrapasse a data acordada ficará para um segundo momento e o sistema subirá em produção no estado em que se encontra.

Inicio da análise

Com a restrição definida, hora de baixar o código, analisá-lo e colocá-lo para rodar.

Lendo novamente o objetivo do sistema pensei em 3 pontos de gargalo:

A quantidade de dados retornados do banco
A transformação dos dados
A forma como o .csv é gerado

Analisando o código para cada uma das suspeitas cheguei nessas observações:

O problema principal do retorno do banco de dados é que todos os registros são do tipo string.
A transformação dos dados não é muito preocupante, pois 96% das informações já vêm prontas para serem escritas no arquivo.
Na geração do csv é onde o problema começa a ficar evidente:
1. Temos diversas operações com strings: Join, ToString.
2. Diversos StringBuilders de uso único que invocam o método .ToString() ao final de cada execução
3. StringBuilder mal utilizado

Com essas suspeitas anotadas hora de rodar a aplicação!

Rodando a aplicação

Realizo a primeira execução da aplicação no estado atual para entender melhor o fluxo, tempos de processamento, validar acessos, etc. Ao final do teste o resultado vai de encontro com o problema informado:

Tamanho do arquivo gerado:

Executo a aplicação novamente para observar as mudanças de memória e encontrar o motivo da sua subida vertiginosa.

Utilizando o gráfico acima como referência, nota-se que existem 3 etapas no aumento de memória:

A primeira curva representa a obtenção dos dados.
Um platô representado pela configuração do arquivo csv
Uma subida rápida representada pela geração do csv em memória

Portanto é na terceira etapa que o consumo de memória torna-se expressivo. Gargalo encontrado!

Implementando melhorias

Com o gargalo encontrado, voltamos as observações levantadas para a etapa 3: A forma como o .csv é construído.

Temos diversas operações com strings: Join, ToString.

Diversos StringBuilders de uso único e invocando o método .ToString() ao final de cada execução

StringBuilder subutilizados

Os trechos de código abaixo mimetizam a estrutura original da aplicação:

Método GenerateInMemoryCsv: gera um CSV em memória

public static string GenerateInMemoryCsv(IEnumerable<Vehicle> vehicles)
{
   string[] headerFields =  Vehicle.GetHeaderFields();    
   string header = string.Join(";", headerFields);
   string rows = string.Join("\n", vehicles.Select(x => x.ConvertToCsv()));
   return new StringBuilder().AppendJoin("\n", header, rows).ToString();    
}

Método GetHeaderField: obtém o cabeçalho do csv

public static string[] GetHeaderFields() =>
   new string[] { "Marca", "Ano", "Modelo", "Quantidade de Portas", "Motor" };

Método ConvertToCsv: converte o registro em uma linha válida para o csv

public string ConvertToCsv()
{
   StringBuilder sb = new();
   sb.AppendJoin( ";", Marca, Ano, Modelo, QtdPortas, Motor);

   return sb.ToString();
}

Reduzindo a alocação de strings

Pensando na questão do uso excessivo de operações com string que retornam outras strings, é necessário lembrar que a string é um tipo readonly. Parafraseando a documentação oficial do C#:

Objetos do tipo string são imutáveis: não podem ser alterados após serem criados.
Todos os métodos String e operadores C# que aparecem para modificar uma string retornam, na verdade, os resultados em um novo string.

Ou seja, para cada Join e para cada ToString utilizado, uma nova string é gerada sem descartar ou sobrescrever a antiga. Isso implica em dobrar a quantidade de memória cada vez que essas operações são utilizadas. Portanto o primeiro passo para otimização é reduzir a quantidade de operações do tipo Join e ToString.

Analisando os códigos acima o método que possui mais operações que retornam novas strings é o ConvertToCsv. Pode não parecer óbvio olhando os métodos separados, mas lembre-se do enunciado do problema: O sistema deve buscar no banco cerca de 200k registros.
Outra situação que chama atenção nesse método é a utilização de um StringBuilder efêmero utilizado para concatenar as strings. Apesar do StringBuilder ser ótimo para evitar a criação desnecessária de strings, neste caso ele gera um impacto negativo devido sua frequência de criação e descarte. Portanto, nessa correção o AppendJoin do StringBuilder foi substituído por um string.Join e o ToString do final do método foi removido. Essa mudança reduziu a quantidade de alocações de duas (criação do StringBuilder + nova string utilizando ToString) para uma (nova string utilizando Join).

O código do método ConvertToCsv refatorado fica assim:

public string ConvertToCsv()
{   
   return string.Join( ";", Marca, Ano, Modelo, QtdPortas, Motor);
}

Após essa alteração, rodei novamente a aplicação e obtive o seguinte resultado:

É possível notar uma redução de 200Mb de memória ou 17% de ganho em relação a primeira operação. Ainda sim, não parece ser uma melhoria satisfatória, visto que a aplicação ainda utiliza 1Gb de ram para gerar um arquivo de 65Mb (aproximadamente 16x mais).

Otimizando a utilização do StringBuilder do método GenerateInMemoryCsv

Conforme comentado anteriormente, a aplicação possuía diversos StringBuilders mal utilizados e em sua maioria desnecessários. O StringBuilder do método GenerateInMemoryCsv é o único caso útil para o fluxo e encontra-se subutilizado. Contudo, a forma atual de sua utilização, concatenar o cabeçalho com o corpo, gera o mesmo resultado de uma concatenação de string simples e com alocação de memória semelhante. Portanto o código deve ser alterado para melhor aproveitar esse StringBuilder.

Realizando a mudança do código para melhor aproveitamento do StringBuilder o método ficaria assim:

public static string GenerateInMemoryCsv(IEnumerable<Vehicle> vehicles)
{
   string[] headerFields =  Vehicle.GetHeaderFields();    
   string header = string.Join(";", headerFields);

   StringBuilder csvInMemory = new StringBuilder(header);
   csvInMemory.AppendJoin("\n", vehicles.Select(x => x.ConvertToCsv()));

   return csvInMemory.ToString();    
}

Obs: Poderíamos realizar o AppendJoin dos campos de header direto no StringBuilder e evitar uma alocação extra de string, porém essa otimização aqui não compensa. Preferi manter a legibilidade do código do que ganhar alguns Kb nessa operação.

Esse tipo de escolha também faz parte do processo de otimização, pois evita gastar energia onde não haverá melhorias expressivas.

Rodando novamente o código obtive o seguinte resultado:

Agora sim uma redução de memória expressiva. A aplicação reduziu o consumo em aproximadamente 750Mb ou 60% em relação a implementação original.

Com toda essa redução de consumo fica a pergunta

Será é possível diminuir a alocação de memória ainda mais?

Nem toda otimização traz benefícios

Com as melhorias no fluxo mais crítico concluídas e ainda sobrando um tempo, resolvi revisitar a primeira rampa de memória e descobri que essa alocação é gerada pela obtenção dos registros no banco de dados. Revisando o método de obtenção dos dados, notei que mesmo utilizando um IEnumerable ocorria essa alocação de memória expressiva. Supus que ocorria a alocação de uma lista por baixo dos panos (viva o polimorfismo). No método implementado não existia o uso do ToList, portanto a alocação deveria ocorrer no método Query do Dapper. Olhando os parâmetros do método Query encontrei o parâmetro chamado buffered(opcional). O buffered é utilizado para decidir se o resultado da query deve ser carregado numa lista em memória ou não. Por padrão esse parâmetro é true, ou seja, cria a lista em memória. Buscando o código do método Query na lib, é possível ter uma ideia do que acontece:

 public static IEnumerable<T> Query<T>(this IDbConnection cnn, string sql, object param = null, IDbTransaction transaction = null, bool buffered = true, int? commandTimeout = null, CommandType? commandType = null)
 {
     var command = new CommandDefinition(sql, param, transaction, commandTimeout, commandType, buffered ? CommandFlags.Buffered : CommandFlags.None);
     var data = QueryImpl<T>(cnn, command, typeof(T));
     return command.Buffered ? data.ToList() : data;
 }

Nesse caso usei o disassembly do próprio visual studio, mas é possível obter o código a partir do repositório do github

Método ToList encontrado! Quando o parâmetro buffered é passado como true o método Query devolve um List mesmo que o IEnumerable seja retornado.

Resolvi passar o valor dessa variável como false e realizar um nova execução. O resultado foi mais surpreendente do que o esperado. O gráfico abaixo mostra a diferença de alocação de memória:

Tivemos uma queda de 64% no consumo de memória(306Mb) em relação a execução anterior. Inclusive o processador teve um pequeno ganho (não calculado). No entanto, o tempo da execução cresceu 2,5x, pois agora toda operação realizada sobre os resultados necessita iterar sobre essa lista. No processo existem pelo menos 3 operações na lista (Any, Count e Geração do CSV). Mesmo eliminando ou remanejando o Count, o tempo de execução segue alto. Outro ponto bastante preocupante é o risco de uma desconexão com o banco ocasionar um erro no processo.

Para o cenário apresentado, o tempo de execução e a confiabilidade da execução também eram requisitos importantes. Portanto, por mais que essa otimização reduza bastante a quantidade de memória alocada, ela não compensa pelos dois pontos mencionados.

Ideias de evolução

A trilha de otimização dessa aplicação gerou um resultado satisfatório, porém distante do ideal. Boa parte do trabalho de otimização poderia ser atingido mudando a forma como o arquivo é gerado e transferido.

A primeira ideia é salvar o arquivo localmente antes de envia-lo para o destino. Essa abordagem faz o consumo de memória ficar muito próximo ao da otimização de leitura direto do banco (sem buffer), pois não seria necessário criar todo o arquivo em memória antes da transferência. Extrapolando a ideia, poderia ser feita a leitura da informação direto do banco, transformar cada linha e salvar direto no arquivo. É óbvio que outros tipos de decisão e controle deveriam ser tomados, mas isso faz parte do processo de otimização.

Outra ideia que tive durante esse processo e que ainda carece de estudos e testes é utilizar stream de dados e gravar o documento direto no destino, sem a necessidade de gerar um arquivo local ou construir todo o arquivo em memória. Algumas dúvidas que teriam que ser respondidas:

O C# permite tal abordagem apontando para um servidor remoto?
O que fazer em caso de falha de comunicação com servidor remoto durante o processo de escrita?
Faria a escrita do arquivo em blocos de x registros ou tudo de uma vez?
Escrevendo o arquivo em blocos, em caso de falha, iniciar todo o processo novamente ou ter alguma forma de continuar onde parou?

O projeto está disponível no github para quem desejar baixar e conferir a implementação e os testes executados

https://github.com/julianopoveda/export_file

Conclusão

Como foi mostrado nesse post, pequenas melhorias no código podem trazer grandes vantagens na alocação de recursos. Já outras soluções podem trazer melhorias de um lado, agregando mais risco e exigindo novos controles para a aplicação.

Por fim, uma questão que pode ter sido levantada na mente do leitor é o fato de eu ter focado exclusivamente na alocação de memória e não ter me preocupado com o uso da CPU. Tal decisão foi tomada lá no inicio da análise ao descobrir que a aplicação lida muito com IO (consulta no banco, alocação de memória, transferência do arquivo) e pouco com CPU. A medida que a correção ia evoluindo, o uso de CPU manteve-se estável, provando que estávamos trabalhando com uma aplicação de pouco processamento.

Referências

Documentação do tipo string

Podman + Windows: Resolvendo erro "No connection could be made because the target machine actively refused it"

Poveda — Wed, 10 Jul 2024 11:47:40 +0000

Enquanto estava estudando para escrever o post WSL: Gerenciando o disco da distro precisei reiniciar as distros do WSL algumas vezes. Entre essas distros estava a VM utilizada pelo Podman Desktop.

Qual foi a minha surpresa quando no dia seguinte precisei utilizar o podman e recebi a seguinte mensagem

Cannot connect to Podman. Please verify your connection to the Linux system using podman system connection list, or try podman machine init and podman machine start to manage a new Linux VM
Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:63708: connectex: No connection could be made because the target machine actively refused it.

Num primeiro momento tentei parar e subir a VM novamente com os comandos podman machine stop e podman machine start porém sem sucesso. Depois disso resolvi ler a mensagem de erro em busca mais pistas. A mensagem dizia para rodar o comando podman system connection list e validar se o podman esta escutando na porta mencionada.

Rodando o comando a saída confirmou que porta 63708 estava sendo utilizada pela VM:

$ podman system connection list
Name                         URI                                                Identity                                                        Default     ReadWrite
podman-machine-default       ssh://root@127.0.0.1:64624/run/podman/podman.sock  ~\.local\share\containers\podman\machine\machine  false       true
podman-machine-default-root  ssh://root@127.0.0.1:63708/run/podman/podman.sock  ~\.local\share\containers\podman\machine\machine  true        true

Obs: Os caminhos do identity foram encurtados para facilitar a leitura

Ainda sem ideia sobre o que fazer resolvi olhar o que mais a mensagem dizia. A outra opção sugerida pela mensagem era subir uma nova VM do podman para solucionar o problema, entretanto essa era uma opção que não desejava executar num primeiro momento pois tenho alguns pods parados e imagens salvas no cache que demorariam muito para baixar novamente (ex: sql server).

Com o cenário desenhado, iniciei as pesquisas para tentar solucionar o problema. Encontrei a "issue No connection could be made because the target machine actively refused it" e tentei a maioria das soluções propostas na issue porém sem sucesso. Inclusive vi que implementaram uma correção para o podman e que também não resolveu meu problema 😢.

Voltei novamente para as informações fornecidas pelo podman e tive um estalo:

"O podman desktop se comunica com a VM via SSH. Será que a porta 63708 está habilitada no serviço"

Com essa suspeita acessei a distro do podman e abri o arquivo /etc/ssh/sshd_config no editor de texto. Indo para o final do arquivo constatei que somente a porta 64624 estava habilitada para acesso ssh. Então resolvi adicionar a porta 63708. O arquivo que ficou da seguinte forma após editado

...
# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
Port 64624
Port 63708

Depois de salvar a alteração o próximo passo foi reiniciar o serviço do ssh com o comando:

sudo systemctl restart sshd

Aguardei uns segundos e rodei o comando systemctl status sshd a fim de validar se o serviço havia iniciado. O resultado do comando comprova que o serviço estava rodando sem problemas:

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-07-03 21:02:01 -03; 3s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 7207 (sshd)
      Tasks: 1 (limit: 4697)
     Memory: 1.3M
        CPU: 12ms
     CGroup: /system.slice/sshd.service
             └─7207 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jul 03 21:02:01 PovedaRyzen systemd[1]: Starting sshd.service - OpenSSH server daemon...
Jul 03 21:02:01 PovedaRyzen (sshd)[7207]: sshd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
Jul 03 21:02:01 PovedaRyzen sshd[7207]: Server listening on 0.0.0.0 port 63708.
Jul 03 21:02:01 PovedaRyzen sshd[7207]: Server listening on :: port 63708.
Jul 03 21:02:01 PovedaRyzen sshd[7207]: Server listening on 0.0.0.0 port 64624.
Jul 03 21:02:01 PovedaRyzen sshd[7207]: Server listening on :: port 64624.
Jul 03 21:02:01 PovedaRyzen systemd[1]: Started sshd.service - OpenSSH server daemon.

Com o ssh liberado para a porta 63708, rodei alguns comandos a fim de validar a conexão. Para a minha felicidade os resultados foram esses:

$ podman ps -a
CONTAINER ID  IMAGE                                                  COMMAND               CREATED      STATUS                    PORTS       NAMES
5a6ba726847e  localhost/podman-pause:5.1.0-dev-4817811cb-1713312000                        3 weeks ago  Exited (0) 292 years ago              234f8433dbf7-infra
9fecc6f0544a  docker.io/library/nginx:latest                         nginx -g daemon o...  3 weeks ago  Exited (0) 292 years ago              nginx-nginx

$ podman images
REPOSITORY                           TAG                             IMAGE ID      CREATED       SIZE
localhost/podman-pause               5.1.0-dev-4817811cb-1713312000  d3af6c318a9d  3 weeks ago   1.14 MB
docker.io/library/nginx              latest                          4f67c83422ec  5 weeks ago   192 MB
docker.io/julianopoveda/readonlyapi  v1                              ac7c4054326e  2 months ago  120 MB
docker.io/kindest/node               <none>                          09c50567d34e  4 months ago  962 MB

Conclusão

Por algum motivo que não consegui descobrir o real motivo da porta ter se tornado incomunicável. Essa questão dificultou bastante a busca de uma solução, pois é bem provável que alguém já passou por esse problema e reportou em algum lugar como solucionar.

No fim tive que contar com a minha experiência e memória para resolver o problema, sem o auxilio de uma fonte externa. E esse é um dos motivos pelos quais tenho escrito esses posts, ter uma base de solução de problemas documentada tanto online quanto offline.

Uma última curiosidade: enquanto buscava algumas informações para enriquecer esse post descobri que poderia ter trocado a porta default de comunicação para a porta utilizada pelo rootless usando o comando podman system connection default podman-machine-default. Esse comando teria resolvido o problema de forma bem mais simples, visto que a porta 64624 estava aberta no sshd.

Referências

WSL: Gerenciando o disco da distro

Poveda — Tue, 18 Jun 2024 11:00:00 +0000

Quando se trabalha com softwares pesados, geralmente é necessária uma quantidade considerável de espaço em disco a fim de armazenar todas as configurações e módulos para sua execução. Com o WSL não é diferente, afinal trata-se de um SO extra instalado na máquina. Para que seja possível realizar a instalação desse novo SO, o Windows cria um HD de tamanho variável (VHDX) no qual conterá todos os arquivos do SO e todos os programas e arquivos instalados posteriormente.

De acordo com a própria documentação da Microsoft:

O tamanho do disco será de 1TB para as versões mais recentes do WSL2 e 512Gb ou 256GB para versões mais antigas.
O tamanho do disco exibido é seu tamanho máximo, ainda que este espaço não esteja realmente alocado. VHD expandirá seu tamanho a medida do seu uso.

Quando é realizada a instalação do SO no WSL, por padrão o Windows cria o VHD no mesmo HD onde o próprio Windows está instalado (C:). Muitas vezes o tamanho deste disco é insuficiente para comportar um VHD tão grande e em constante expansão.

Utilizando o meu próprio HD como exemplo é possível observar que o disco está quase esgotado:

Analisando a alocação do disco nota-se que o SO instalado no WSL ocupa em torno de 25% de espaço:

Neste post vou abordar duas propostas de como recuperar mais espaço em disco:

Realizando a compactação do disco
Movendo a distro para outro HD

1. Compactar o disco

Esta opção é indicada para quem utiliza o WSL como servidor para algum container engine (docker, podman) ou para quem manipula muitos arquivos (cria, copia, exclui). Ela é aplicável independente de onde o VHD está salvo.

Para efetuar a compactação do disco é necessário desligar a distro.

wsl --shutdown

Obs: esse comando desliga todas as distros. Não é possível utilizar o comando terminate pois ele não libera o VHD para manipulação externa.

Para reiniciar as distros basta rodar o comando wsl -d <distro-name>

Para descobrir quais distros estão instaladas na máquina e seus respectivos status basta rodar o comando:

wsl -l -v

O resultado será parecido com esse:

  NAME                      STATE           VERSION
* Ubuntu                    Stopped         2
  podman-machine-default    Stopped         2
  docker-desktop-data       Stopped         2

Em seguida será necessário obter o local onde o VHD está armazenado. Por padrão o Windows adiciona todos os arquivos necessários para rodar a distro dentro de um diretório armazenado na pasta C:\Users\%USERNAME%\AppData\Local\Packages. Existem algumas formas de encontrar o diretório da distro:

Rodando o comando (Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | Where-Object { $_.GetValue("DistributionName") -eq '<distribution-name>' }).GetValue("BasePath") + "\ext4.vhdx"
Acessar a pasta C:\Users\%USERNAME%\AppData\Local\Packages e procurar pelo nome do pacote da distro
1. Para distros Ubuntu os arquivos estão localizados em pastas com o padrão CanonicalGroupLimited.Ubuntuon*
Usar a pesquisa de arquivos dentro da pasta C:\Users\%USERNAME%\AppData\Local\Packages para buscar todos os ext4.* disponíveis e validar qual é o caminho que contém o VHD da distro desejada.

No meu caso a primeira opção não funcionou em nenhuma das duas máquinas das quais testei.
No fim não encontrei uma forma fácil de encontrar os VHD's que são criados por distros instaladas diretamente pela Microsoft Store. Outras VMs criadas por outros programas, como o podman possuem comandos que facilitam a localização do VHD utilizado.

Uma vez encontrado o caminho do VHD será necessário abrir o powershell/terminal em modo administrador e executar o seguinte comando:

Optimize-VHD "C:\Users\$env:UserName\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

Explicando:

O comando Optimize-VHD serve para otimizar a alocação de espaço em VHDs de tamanho dinâmico, isto é, que expandem seu tamanho no decorrer do uso até o tamanho máximo definido.

A opção Mode serve para definir o nível de otimização. No meu caso testei com as opções Quick e Full. Abaixo explico a diferença de cada uma:

Quick: desaloca os blocos não usados do disco, porém não procura por zero blocks
Full: Busca por zero blocks e desaloca blocos não utilizados.

As demais opções podem ser encontradas documentação oficial(tem nas referências 😉)

Rodando o comando com -Mode Quick obtive a seguinte redução:

Rodando o comando com -Mode Full obtive a seguinte redução:

Obs: O comando com -Mode Full foi rodado após ter rodado o comando com o -Mode Quick. Esse é o motivo da diferença parecer pequena de um comando para o outro.

Após executar o processo de otimização do VHD o espaço disponível no HD aumentou aproximadamente 14Gb:

Vantagens da abordagem

Poucos passos
Manter o registro do SO baixado pela Microsoft Store, beneficiando-se dos clis instalados junto com as distros.
Não necessita de armazenamento extra

Desvantagens da abordagem

Inefetivo quando todo espaço reservado pelo VHD está ocupado
Dependendo do uso é necessário executar o procedimento com frequência de forma manual ou automatizada
Dificuldade de encontrar o caminho do VHD do SO desejado

2. Exportar o VHD para outro disco

Esta opção é indicada para cenários onde é necessário ou desejado mover a distro para outro HD com mais capacidade ou reservado para isso.

Ao término da execução desse processo, o espaço ocupado no meu HD principal reduziu consideravelmente.

2.1 Exportar o disco

O primeiro passo é desligar a distro desejada. Esse passo é essencial para garantir que nada esta sendo gravado durante a cópia dos arquivos.

wsl --terminate <distro-name>

alternativamente o comando wsl --shutdown pode ser utilizado para desligar todas as distros

O próximo passo é rodar o comando de exportar:

wsl --export <distro-name> <path-destino-com-nome>.vhdx --vhd

Explicando:

O comando exporta a distro para o arquivo vhdx indicado. A opção --vhd é opcional, porém será útil para os próximos passos. Caso a opção --vhd não seja informada, um arquivo .tar será gerado. Ambos os formatos de arquivo servem para a etapa de import.

2.2 Importando e registrando a distro no WSL

Importante: Nomes repetidos não são permitidos pois os nomes funcionam como o identificador da distro para com o WSL. Portanto, se for necessário manter o nome da distro original, primeiro deve ser feito o desregistro da distro anterior. Nesse caso a ordem de execução fica: 2.3, 2.2, 2.4

Com o disco exportado existem duas formas de importar a distro no WSL:

Carregando uma cópia do HD com o comando import
Utilizando o próprio VHD exportado com o comando import-in-place (só funciona para arquivos .vhdx)

A primeira forma consiste em rodar o comando import de acordo com o exemplo:

wsl --import <distro-name> <path-instalacao-distro> <path-disco-exportado>.vhdx --vhd

Explicando:

Este comando restaurará uma cópia do disco exportado no local informado e o registrará a distro no WSL com o nome informado. A opção --vhd serve para informar que o arquivo utilizado é um VHD ao invés de um .tar.

A segunda forma de importação só funciona para arquivos do tipo .vhdx. Para realizar esse processo basta executar o comando:

 wsl --import-in-place <distro-name> <path-disco-exportado>.vhdx

Explicando:

Este comando registrará a distro no WSL com o nome informado, utilizando o VHD como o disco daquela distro. Então ao contrário do comando wsl --import, esse comando utiliza o vhd diretamente e é por este motivo que a exportação precisa da opção --vhd.

2.3 Desregistrando a distro antiga

Com a distro registrada em outro HD, o próximo passo é remover a distro antiga do HD principal. Para desregistrar a distro atual, rodar o comando:

wsl --unregister <distro-name>

Executando o comando acima todas as configurações dessa distro serão removidas do HD principal.

2.4 Definindo a distro como padrão e restaurando o usuário principal

Apesar de todo o trabalho feito até o momento existem alguns pontos que precisam ser ajustados quando necessário.

O primeiro deles é definir a distro como padrão rodando o comando:

wsl --set-default <distro-name>

O segundo ajuste é redefinir o usuário principal. Ao exportar a distro e (re)importá-la o usuário padrão é redefinido para root. Para redefinir o usuário para o usuário anteriormente criado na distro será necessário criar o arquivo wsl.config dentro da distro contendo a estrutura abaixo

[user]
default=<username>

este arquivo deve ser salvo no caminho /etc/ (lembrar que escrever na pasta etc exige sudo). Após salvar o arquivo, reiniciar a máquina utilizando os comandos:

wsl --terminate <distro-name> #desliga a máquina

wsl -d <distro-name> #inicia a máquina

Vantagens da abordagem

Pode ser utilizada para importar qualquer distro, inclusive de outros computadores ou backups
Pode ser utilizada junto com o método de Compactação de disco (Optimize-VHD)
Libera todo o espaço do VHD do HD principal
Não é necessário saber o local físico onde a distro está instalada.
Capacidade de utilizar os cli's junto a Microsoft Store caso o nome da distro importada seja igual a distro original

Desvantagens da abordagem

Requer espaço extra em outro HD
Necessita ajustes adicionais
Perda da capacidade de utilizar as cli's baixadas junto a Microsoft Store caso o nome da distro importada seja diferente da distro original

Referências

Podman + minikube

Poveda — Sat, 30 Apr 2022 04:15:25 +0000

Agora que já instalamos o podman no WSL é hora de começar a briga para fazer o kubernetes usar o podman no lugar do docker. Neste post vou instalar e configurar o minikube pelo fato dele ser a distribuição mais popular de kubernetes para ambiente de desenvolvimento.

Para fazer o podman rodar em conjunto com o minikube, precisaremos instalar 3 ferramentas:

O próprio minikube
O kubectl
Um runtime (escolhi o CRI-O)

Como o post ficou grande e cheio de seções que podem ser puladas dependendo do que já esta instalado a configurado na máquina, julguei necessário colocar um índice.

De nada 😉

Índice

Índice
Entendendo os conceitos de driver e runtime
- Runtime
- Driver
Instalando o minikube
Instalando o kubectl
Instalando o CRI-O
Rodando o minikube
- Adiconando o Podman ao sudoers
- Erro ao executar o minikube
Deploy da aplicação
- Adicionando a imagem ao cache do minikube
Criando a service
Expondo a aplicação para fora do Kubernetes
- Minikube Service
Acessando a aplicação fora do WSL
Alternativa rootless para o minikube
Impressões e Conclusão
Referencias

Entendendo os conceitos de driver e runtime

Sessão opcional: se você já entende o que são os conceitos de driver e runtime ou quer ir direto para a instalação pode pular para a instalação do minikube
Antes de começar com o hands on de verdade, primeiro é necessário entender o básico de driver e runtime no mundo de containers.

Runtime

O runtime é responsável por controlar todo o ciclo de vida do container. Isso vai desde baixar um container até rodá-lo.
Este artigo escrito por Nived Velayudhan aprofunda mais sobre o assunto. Também vale mencionar a própria documentação oficial da especificação do runtime

Driver

O driver é responsável por prover o conjunto de apis nas quais o usuário irá interagir com o ecossistema de containers. Em resumo, provê os comandos usados nos CLIs e interfaces gráficas.

Instalando o minikube

Para instalar a minikube não tem muito mistério, vamos seguir a documentação oficial.
Existem 2 formas de instalar para quem usa distribuições baseadas em debian (meu caso): baixando os binários ou baixando o pacote debian. No tutorial vou mostrar como instalar utilizando o pacote debian, pois foi a forma que eu instalei.

O primeiro passo é rodar o comando curl e baixar a última versão:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb

Em seguida instalar o pacote:

sudo dpkg -i minikube_latest_amd64.deb

Pronto! Minikube instalado

Instalando o kubectl

Não podemos executar nossos comandos kubernetes sem a ferramenta que serve para isso.
Novamente indo para a documentação oficial, basta seguir os passos informados lá. Para o meu caso utilizei o passo-a-passo do Ubuntu.

Primeiro é necessário atualizar o package index e instalar algumas ferramentas necessárias para poder baixar o Kubernetes via apt:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

Em seguida baixar a chave pública do GCP e adicionar o repositório do Kubernetes ao repositório do apt:

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

Por fim, reatualizar o package index para buscar as informações do novo repositório e instalar o kubectl:

sudo apt-get update
sudo apt-get install -y kubectl

Instalando o CRI-O

De acordo com a documentação do minikube, para utilizar o podman é necessário instalar um runtime. E o runtime recomendado pela própria documentação é o CRI-O.

Para instalá-lo vamos usar a documentação oficial do CRI-O

Assim como no último post, vamos começar importanto o arquivo /etc/os-release para as variáveis de ambiente:

. /etc/os-release

Com essas variáveis importadas, podemos baixar os repositórios necessários:

CRIO_VERSION=1.23
sudo echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x{$Name}_{$VERSION_ID}/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
sudo echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/{$CRIO_VERSION}/x{$Name}_{$VERSION_ID}/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:{$CRIO_VERSION}.list

A variável CRIO_VERSION deve ser preenchida com a versão desejada. Na data desta publicação é a 1.23.

Agora adicionamos as chaves ao apt-key:

sudo curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x{$Name}_{$VERSION_ID}/Release.key | apt-key add -
sudo curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{$CRIO_VERSION}/x{$Name}_{$VERSION_ID}/Release.key | apt-key add -

E por fim instalamos a nossa última ferramenta necessária para rodar o minikube com o podman:

sudo apt-get update
sudo apt-get install -y cri-o cri-o-runc

Rodando o minikube

Depois dessa pequena odisséia de instalação, é hora de colocar o minikube para rodar com o podman. O comando exige passar as opções de driver e container runtime, porém nada de extraordinário:

minikube start --driver=podman --container-runtime=cri-o

Ao executar o comando recebemos a seguinte mensagem:

😄  minikube v1.25.2 on Ubuntu 20.04 (amd64)
✨  Using the podman driver based on existing profile

💣  Exiting due to PROVIDER_PODMAN_NOT_RUNNING: "sudo -k -n podman version --format " exit status 1: sudo: a password is required
💡  Suggestion: Add your user to the 'sudoers' file: 'myuser ALL=(ALL) NOPASSWD: /usr/bin/podman'
📘  Documentation: https://podman.io

Se o leitor pensou a mesma coisa que eu a primeira vez que viu essa mensagem, certamente deve ter tentado rodar o minikube com sudo e recebeu o erro abaixo:

😄  minikube v1.25.2 on Ubuntu 20.04 (amd64)
✨  Using the podman driver based on user configuration
🛑  The "podman" driver should not be used with root privileges.
💡  If you are running minikube within a VM, consider using --driver=none:
📘    https://minikube.sigs.k8s.io/docs/reference/drivers/none/

❌  Exiting due to DRV_AS_ROOT: The "podman" driver should not be used with root privileges.

O podman por ser construído utilizando a premissa rootless, não permite que o minikube seja rodado como rootfull quando utilizá-o como driver.

A solução é seguir a sugestão dada na primeira execução

Adicionando o Podman ao sudoers

Apesar de ser uma etapa rápida de fazer, vale parar 1 minuto para entender o que é o sudoers e o que ele faz antes de executar o comando.

sudoers é um arquivo utilizado para definir o nível de permissão de execução de comandos no modo super usuário. Neste arquivo é possível definir desde permissão de execução de comandos em um programa em específico até execução total e irrestrita.
Para mais informações e entendimento recomendo a leitura deste post e a leitura do man do arquivo sudoers.

Execute o comando sudo visudo e adicione a seginte linha no final do arquivo:

myuser ALL=(ALL) NOPASSWD: /usr/bin/podman

Explicando o nível de permissão que estamos atribuindo:

O usuário myuser pode executar qualquer comando dentro do programa /usr/bin/podman sem a necessidade de informar o password.

Com a configuração adicionada podemos rodar o minikube sem grandes problemas.

Erro ao executar o minikube

Ao tentar rodar o minikube pela primeira vez talvez ocorra o erro de download de imagem KIC (perdi o texto certo do erro 😅). Para resolver esse problema é necessário baixar a imagem manualmente com o comando:

minikube start --driver=podman --container-runtime=cri-o --download-only=true

Após o término do download basta executar o minikube novamente

Deploy da aplicação

Com tudo configurado, é hora de criar um deploy e publicar nossa aplicação de teste.
Para isso crie um arquivo .yaml igual ao exemplo abaixo (ou pega ele pronto no repositório 😉)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: juridico-deployment
  labels:
    app: juridico
spec:
  replicas: 2
  selector:
    matchLabels:
      app: juridico
  template:
    metadata:
      labels:
        app: juridico
    spec:
      containers:
      - name: juridicoapp
        image: localhost/juridico:latest
        imagePullPolicy: IfNotPresent
        ports: 
        - containerPort: 3001

Com o deployment.yaml criado, execute o comando

kubectl apply -f <path-to-deployment-file>/deployment.yaml

Para ver se o deployment foi feito rode o comando:

kubectl get deployments juridico-deployment

o resultado deve ser algo parecido com:

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
juridico-deployment   2/2     2            2           15d

E para ver os pods criados:

kubectl get pods -l app=juridico

A saída deve ser algo parecido com:

NAME                                    READY   STATUS             RESTARTS   AGE
juridico-deployment-86b6b47b6-j5l9n     1/1     Running            4          15d
juridico-deployment-86b6b47b6-lzkjq     1/1     Running            4          15d

Se por ventura no status estiver mensagens do tipo ImagePullBackOff ou ErrImagePull, provavelmente você deve possuir a imagem somente no cache do podman. Se esse for o caso, é necessário fazer um dos 3 passos:

Subir a imagem para algum registry remoto (dockerhub, quay.io)
Criar um registry local
Subir a imagem para o cache do minikube

Adicionando a imagem ao cache do minikube

Se você assim como eu está tentando fazer um teste 100% local, sem dependender de registrys externos e subir mais uma aplicação, antes de ter tudo rodando é necessário executar mais esse passo. O processo é tedioso, porém pouco complexo

Primeiro é necessário exportar a imagem para um arquivo .tar com o comando:

podman save -o juridico.tar localhost/juridico:latest

Depois basta importar a imagem no minikube utilizando o comando:

minikube image load juridico.tar

Feito isso, basta reiniciar o minikube que o problema deve estar solucionado.

Criando a service

O próximo passo é criar uma forma de nos comunicarmos com o sistema independente da quantidade de pods instanciados e qual o IP do pod que está rodando no momento.

Para criar a service seguimos o mesmo passo do deployment e criamos um arquivo .yaml conforme abaixo:

apiVersion: v1
kind: Service
metadata:
  name: juridico-service
  labels:
    app: juridico
spec:
  type: NodePort
  selector:
    app: juridico
  ports:
    - port: 3001
      protocol: TCP
      nodePort: 30001

Com o service.yaml criado, execute o comando

kubectl apply -f <path-to-service-file>/service.yaml

Para ver se o service foi criado rode o comando:

kubectl get services juridico-service

o resultado deve ser algo parecido com:

NAME       TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
juridico   NodePort   10.109.72.98   <none>        3001:30001/TCP   15d

Com a service configurada as outras aplicações já conseguem resolver o nome do sistema independente do scale up ou down dos pods.

Expondo a aplicação para fora do Kubernetes

Mesmo com a service configurada ainda não é possível realizar um acesso de fora do kubernetes. Para isso é necessária a utilização de um componente de rotas para expor a aplicação para fora e rotear as requisições para a aplicação. Nas minhas pesquisas encontrei duas formas de fazer o encaminhamento: usando o próprio minikube e usando o ingress. Aqui irei apresentar somente a primeira.

Minikube Service

O próprio minikube possui um comando que expõe a service para fora do kubernetes de forma simples e direta, podendo expor todas as services ou somente uma em específico. Para expor a aplicação deste post execute o comando abaixo:

minikube service --url juridico-service

O resultado será algo parecido com:

 minikube service juridico
🏃  Starting tunnel for service juridico.
🎉  Opening service default/juridico in default browser...
👉  http://192.168.49.2:30001

Rodando o comando curl na url mostrada o valor retornado é a lista de todos os processos presentes no db.

Acessando a aplicação fora do WSL

Até o momento foram realizados inúmeros testes dentro do WSL e tudo tem ocorrido bem. Porém ao tentar chamar a URL a partir da máquina host(Windows) ela não encontrará a rota (404). Isso acontece porque o minikube assume um IP interno acessível somente pelo próprio WSL. Para tornar o sistema acessível é necessário utilizar o comando de port forwarding.

Para habilitar port fowarding para a service execute o comando:

kubectl port-forward service/juridico-deployment 3001:3001

O resultado deve ser algo semelhante ao que segue:

Forwarding from 127.0.0.1:3001 -> 3001
Forwarding from [::1]:3001 -> 3001
Handling connection for 3001
Handling connection for 3001

Infelizmente ao executar o comando de port forward o terminal fica preso e só é liberado ao encerrar o port-forward

Agora sim é possível chamar o sistema utilizando a URL http://localhost:3001 diretamente da máquina host.

Alternativa rootless para o minikube

Como mencionado nesta issue, os drivers do minikube devem executar em modo rootful. O principal risco de rodar o driver em modo root é a chance de ocorrer uma escalada de privilégios até o host. Para evitar este tipo de problema vamos recorrer a uma alternativa rootless: O usernetes

Impressões e Conclusão

Rodar o minikube utilizando o podman como runtime se provou um desafio grande e demandou muito estudo para fazer tudo rodar corretamente. O principal problema foi tornar a aplicação acessível da máquina host.
Um ponto que me chamou atenção é que durante a configuração do ecossistema é a incapacidade que o minikube tem de operar em modo rootless e as alterções necessárias para "forçar" o podman em modo rootful. Isso me levou a começar a estudar como funciona o userneter e quem sabe trazer um post novo para a série.

Por fim, vejo que o podman ainda precisa percorrer algum caminho para se tornar fácil de ser integrado e configurado como driver das distribuições mais populares de kubernetes para desenvolvedores assim como o docker é hoje.

Todos os arquivos e sistemas utilizados nesse post estão disponíveis no meu github no repositório wsl plus podman.

Referencias

WSL2 + Podman: Uma alternativa ao Docker Desktop

Poveda — Fri, 28 Jan 2022 12:26:47 +0000

Dia 31/01/2022 o Docker desktop passará a ser pago para empresas com mais de 250 funcionários ou com faturamento a partir de 10 milhões de dólares anuais. Esse comunicado está sendo divulgado desde agosto de 2021 e com ele pensei:

Está na hora de revisitar aqueles links esquecidos no limbo sobre alternativas ao Docker.

Meu objetivo é ter uma solução na parte de execução de containers, eliminando todo o resto da ferramenta do docker que na máquina de desenvolvimento não utilizo. Em minhas pesquisas a ferramenta que mais se encaixa neste cenário é o podman.

Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode.
Fonte: https://podman.io/

Lendo a definição do que é o Podman, encontramos o primeiro problema: ele roda somente em Linux e eu uso o Windows. Até existe um instalador para Windows, porém ele é um client para acessar o podman instalado em algum lugar e não a ferramenta em si.

WLS2 + Podman = ❤️

Por sorte e visão da nossa amada e odiada Microsoft, não precisamos mais subir uma VM e realizar toda a configuração necessária para rodar o Linux, podemos usar o WSL2.
No próprio site do podman existe o link do post que ensina como instalar a aplicação no WSL2. Vou seguir este post e acrescentar algumas observações e passos extras que precisei fazer para ter tudo rodando 100%.

Configurando o WLS2

Etapa opcional. Se está tudo certo na parte de configuração do WSL2, pode ir direto para a instalação do Podman.

O primeiro passo é habilitar o WSL no Windows e ativar o WSL2.
Com o WSL2 habilitado e a distro instalada (estou utilizando o Ubuntu 20.04), vamos verificar se a distro esta no formato WSL2 rodando o comando:

wsl --list -v

O resultado será semelhante ao que segue:

  NAME                   STATE           VERSION
* Ubuntu                 Stopped         2
  docker-desktop         Stopped         2
  docker-desktop-data    Stopped         2

Caso a versão da distro não esteja na 2, é necessário rodar o próximo comando:

wsl --set-version Ubuntu 2

Instalando o Podman

Com o WSL2 configurado vamos iniciar a instalação do Podman.
O primeiro passo é descobrir qual é o nome e a versão da sua distro. Dentro do shell da distro execute o comando

cat /etc/os-release

Ele deve retornar algo parecido com as informações abaixo:

NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Alternativamente você pode importar esse arquivo direto para as variáveis de ambiente com o comando:

. /etc/os-release

O comando acima facilitará os próximos passos e por isso vou usá-lo.
O próximo passo é adicionar o repositório do podman na lista de fontes do apt:

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list

Aqui vale uma explicação de alguns pontos do comando que estamos executando:

sudo tee: Pega o valor informado no stdin (nesse caso a instrução anterior) e grava no arquivo de destino informado.

Agora adicionamos uma nova chave ao apt para o repositório que contém o podman:

curl -L "https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/Release.key" | sudo apt-key add -

Explicando:

curl: Efetua uma chamada http para o endereço informado
*sudo apt-key add - *: Adiciona a chave retornada no stdin a lista do apt-key

Feito! Agora basta atualizar a lista do apt:

sudo apt-get update

E instalar o podman:

sudo apt-get install -y podman

Testando

A parte mais legal é ver os containers funcionando. Vamos começar por algo simples:

podman run --rm hello-world

Este exemplo é o mesmo exemplo de hello world do docker porém utilizando o podman

A saída deve ser algo assim:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Como próximo teste, vamos buildar uma imagem nova e colocá-la para rodar. Para isso vamos usar o repositório do post que contém um CRUD simples em node.
Uma vez baixado o repositório, vamos buildar a imagem.
Execute o comando abaixo:

podman build -t juridico -f dockerfile.multistaging .

Com a imagem pronta, chegou a hora de executar o container:

 podman run --rm -p 3001:3001 localhost/juridico

Executando o comando curl http://localhost:3001/95069158262525, temos o seguinte resultado:

{
    "numero": "95069158262525",
    "uf_sigla": "PR",
    "cidade": "Mendoza",
    "reu": "Kaitlin Scutter",
    "identidade": "33925502749086",
    "cliente": "Cherlyn Floyed",
    "status": "Ativo"
}

Conclusão e Próximos Passos

O Podman me surpreendeu pela simplicidade de uso e semelhança com os comandos de Docker. Todos os comandos do docker que uso no dia-a-dia podem ser facilmente utilizados no podman. Inclusive o próprio site do podman ensina a criar um alias para docker. Outro ponto admirável é a transparencia no mapeamento das portas do WSL para a máquina host. Não é necessário realizar qualquer configuração adicional é só mapear as portas e pronto.

O próximo passo é colocar o Kubernetes para rodar utilizando o podman como container engine.

Referencias

https://podman.io/
https://podman.io/getting-started/installation#ubuntu
https://www.redhat.com/sysadmin/podman-windows-wsl2
https://docs.microsoft.com/en-us/windows/wsl/install
tee --help, apt-key --help, . --help

Git apply: colocando os patch files em stage

Poveda — Mon, 27 Sep 2021 12:20:20 +0000

No último post mostrei como podemos utilizar arquivos patch para compartilhar mudanças e commits quando não temos acesso ao remote. A abordagem utilizada coloca as alterações diretamente na árvore de commits e possui mecanismos para evitar duplicidades no momento da aplicação.

Mas se eu quiser revisar as alterações antes de aplicar o commit na árvore?

É justamente para esse cenário que existe o git apply

Git apply

O comando git apply aplica as mudanças que estão dentro dos arquivos .patch aos arquivos correspondentes dentro da pasta de trabalho.

Para adicionar as mudanças basta executar o comando abaixo

git apply patch-commits/0001-Adiconadas-mais-motoriza-es-a-base.patch

Após a execução do comando temos a área de staging com os arquivos alterados

~/mongoblogposts$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   db_data/carro_dump.json

no changes added to commit (use "git add" and/or "git commit -a")

E analisando os logs dos commits, nota-se que nenhum novo commit foi adicionado à árvore

~/mongoblogposts$ git log -1 --oneline
65182aa (HEAD -> main, origin/main) Material post git patch

Verificando quais arquivos foram alterados no último commit:

~/mongoblogposts$ git show -1 --compact-summary
commit 65182aa52f918b567e33545bd15f3bea93d67c58 (HEAD -> main, origin/main)
Author: Juliano Poveda <julianopoveda@github.com>
Date:   Mon Sep 13 09:41:58 2021 -0300

    Material post git patch

 patch-commits/0001-Adiconadas-mais-motoriza-es-a-base.patch (new)     | 386 ++++++++++++++++++++++++++++++++++++++++++
 patch-commits/0002-Reformata-o-readme-criacao-do-ambiente.patch (new) |  45 +++++
 patch-commits/readme.md (new)                                         |  83 +++++++++

Viram! As alterações estão na área de staging e não há nenhum novo commit na árvore.

O parâmetro --check

O apply por padrão já verifica se é possível adicionar as alterações, no entanto, em determinadas ocasiões é bom fazer uam verificação do arquivo .patch antes de adicionar suas alterações. O parâmetro --check faz justamente esta validação. Caso os arquivos estejam aptos a serem adicionados à área de staging, nenhuma mensagem é retornada

~/mongoblogposts$ git apply patch-commits/0001-Adiconadas-mais-motoriza-es-a-base.patch

Já se o arquivo não estiver apto, o comando emite a mensagem

error: patch failed: db_data/carro_dump.json:2
error: db_data/carro_dump.json: patch does not apply

Note que quando é passado --check no comando, as alterações constantes nos arquivos de patch não são aplicadas à área staging. Para que as alterações sejam aplicadas é necessário adicionar o parâmetro --apply ou rodar o comando sem o --check

Impressões e Conclusão

Este comando ao contrário do git am, nos permite fazer um "PR local" antes de adicionar as alterações à árvore.
Então, na próxima vez que ficares sem acesso ao repositório remoto e precisares entregar aquela tarefa super importante, acessa essa mini série e relembra como fazer a passagem das alterações por patch files :).

Os arquivos para teste, são os mesmos do post anterior(pasta patch-commits) e estão disponíveis no github.

julianopoveda / mongoblogposts

Referências

https://git-scm.com/docs/git-apply

Git patch: Compartilhamento de commits além do remote

Poveda — Mon, 13 Sep 2021 12:41:10 +0000

Certa feita passei por uma situação corriqueira: Fiquei sem acesso ao repositório do projeto da equipe. Até aí nada de extraordinário, imagino que todos os devs que estão lendo isso já passaram por isso. O problema real era que eu precisava entregar uma tarefa urgente que iria para produção assim que ela estivesse revisada pelos meus pares (aquele pr básico).
Após passar o pânico inicial e solicitar novamente os acessos, comecei a pensar como poderia fazer esse commit sem precisar encaminhar todos os arquivos alterados para alguém que tivesse acesso ao repositório e pudesse subir o trabalho feito. Relembrando minha época de estudo mais aprofundado do git (leiam o livro oficial do git), lembrei que o kernel do Linux é versionado a partir de arquivos de commits, ou patch files, e enviados por e-mail para serem revisados e restaurados no repositório principal (que não possui acesso a partir da internet). Uma vez que a linha de raciocínio estava feita, fui para a documentação oficial pensando:

Isso vai dar trabalho

Qual foi a minha surpresa ao descobrir que bastam 2 comandos para fazer tal operação.

Gerando os arquivos

O primeiro comando que deve ser rodado é o git format-patch. Ele é responsável por gerar os arquivos .patch. Cada commit irá gerar um arquivo .patch.

git format-patch -<n> -o <diretorio-de-destino-arquivo> <hash-commit>

Explicando rápidamente cada parâmetro:

-<n>: A quantidade de commits anteriores ao commit informado que devem ser exportados.
<hash-commit>: Representa o último commit que deve ser exportado. Commits acima dele não serão exportados.
-o <diretorio-de-destino-arquivo> (opcional): Utilizado para informar onde o arquivo .patch deve ser salvo. O padrão é no próprio diretório.

Inserindo os arquivos .patch na árvore de commits

Agora que os arquivos .patch foram gerados, o próximo passo é adicioná-los à árvore de commits. Para isso utilizamos o comando git am

git am patch-commits/0001-Adiconadas-mais-motoriza-es-a-base.patch

Se for mais de um arquivo

git am patch-commits/000*.patch

Caso seja necessário revisar o arquivo de patch antes de aplicálo na árvore basta adicionar a opção -i:

git am -i patch-commits/000*.patch

Assim, cada arquivo de patch vai ser exibido da seguinte forma:

Commit Body is:
--------------------------
Instrucoes de como rodar o mongo
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all:

Impressões e Conclusão

É interessante ver como determinadas coisas que estudamos e não damos importância podem nos salvar algum dia. Quando li sobre o assunto de commits sendo enviados por e-mail achei cômico como o kernel do sistema operacional mais utilizado do mundo era versionado.No entanto, foi uma informação que se provou útil no final das contas.
Muitas vezes uma informação não vai ser a resolução do problema, mas é ela quem dará a linha de raciocínio para a solução.

No github (pasta patch-commits) deixei o passo a passo de como reproduzir esse post.

julianopoveda / mongoblogposts

Enquanto revisava o material para este post me deparei com uma dúvida:

E se eu não quiser aplicar os commits diretamente na árvore, mas quiser colocá-los em stage e revisar o código em uma ferramenta mais amigável que o console?

Essa dúvida vou responder no próximo post ;)

Referências

https://git-scm.com/docs/git-format-patch
https://git-scm.com/docs/git-am

Exportando dados filtrados em mais de uma collection

Poveda — Mon, 30 Aug 2021 10:46:51 +0000

Imagine a seguinte situação:

A equipe estratégica da montadora deseja criar um relatório contendo todas as vendas feitas no mês de agosto de 2020 tanto pela concessionária quanto direto pela fábrica.
O sistema da montadora divide essas vendas em duas collections do mongo.
O relatório é gerado por uma ferramenta consolidada de mercado que aceita a importação dos dados por arquivos .csv ou .json

A primeira solução que vem à cabeça é utilizar o mongoexport com o parâmetro --query para gerar os dados solicitados. No entanto, o mongoexport possui a limitação de só exportar dados de uma única collection por vez.
Fazendo um teste simples de exportar todos os dados de um database sem definir uma collection com o mongoexport obtemos o seguinte resultado:

#$> mongoexport mongodb://localhost:27017 --db examples #comando executado
2021-08-26T08:39:03.607-0300    must specify a collection
2021-08-26T08:39:03.615-0300    try 'mongoexport --help' for more information

Usando o mongosh

O mongosh é a ferramenta básica para interagir com qualquer mongodb. Utilizando ele é possível criar consultas, procedures, indexes e gerenciar o database de maneira geral. Outro ponto interessante é que possível importar scripts .js e executá-los dentro do mongosh. É possível importar o arquivo de duas formas:

Importar diretamente dentro do mongosh

mongosh mongodb://localhost:27017
> load('export_data_multiple_databases/obter_vendas.js')

Importar no momento da execução do mongosh

mongosh mongodb://localhost:27017/examples ~/export_data_multiple_databases/obter_vendas.js

No primeiro caso os resultados gerados são mostrados diretamente no console do mongosh (contexto do mongosh), tornando a tarefa exportar os dados complexa para o cenário apresentado.

Exemplo de execução

Current Mongosh Log ID: 612918a2e3f888785924e0e9
Connecting to:          mongodb://localhost:27017/examples?directConnection=true&serverSelectionTimeoutMS=2000
Using MongoDB:          5.0.0
Using Mongosh Beta:     0.14.0

For mongosh info see: https://docs.mongodb.com/mongodb-shell/

------
   The server generated these startup warnings when booting:
   2021-08-27T10:16:56.220+00:00: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem
   2021-08-27T10:16:56.525+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
   2021-08-27T10:16:56.526+00:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
------
> load('~/export_data_multiple_databases/obter_vendas.js')
[{
  fabricante: 'Lexus',
  modelo: 'LS',
  ano: 2004,
  datavenda: ISODate("2021-08-03T00:00:00.000Z"),
  preco: '$106375.36',
  collectionName: 'vendas_concessionaria'
},
{
  fabricante: 'GMC',
...

Já no segundo caso é possível exportar diretamente para um arquivo externo, pois o comando devolve o resultado no contexto do console e não no contexto do mongosh.

Importante ressaltar que o script importado fica disponível somente naquela sessão.

Exportando para um arquivo

A forma mais simples de exportar para um arquivo é justamente usando o segundo comando de importação de scripts.

mongosh mongodb://localhost:27017/examples ~/export_data_multiple_databases/obter_vendas.js > arquivo_resultado.json

Mongosh --eval

O parâmetro --eval executa um script js inline usando o contexto do mongosh, porém sem carregar o ambiente do mongosh no console. O resultado é da execução é enviado para o console conforme exemplo abaixo:

mongosh mongodb://localhost:27017/examples --eval="load('export_data_multiple_databases/obter_massa_dados.js');"

Como resultado é enviado diretamente para o console (fora do contexto do mongosh), exportar os dados para um arquivo .json é simples

mongosh mongodb://localhost:27017/examples --eval="load('export_data_multiple_databases/obter_massa_dados.js');" > arquivo_resultado.json

A vantagem em relação à exportação padrão é que com o --eval é possível adicionar outras instruções além do que está no script.

Eliminando o cabeçalho com o parâmetro --quiet

Examinando o arquivo exportado, nota-se que os cabeçalhos de inicialização do mongosh também foram exportados.

Current Mongosh Log ID: 6129153e30afffaa9fb76fe4
Connecting to:      mongodb://localhost:27017/examples?directConnection=true&serverSelectionTimeoutMS=2000
Using MongoDB:      5.0.0
Using Mongosh Beta: 0.14.0

For mongosh info see: [1mhttps://docs.mongodb.com/mongodb-shell/]

------
   The server generated these startup warnings when booting:
   2021-08-27T10:16:56.220+00:00: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem
   2021-08-27T10:16:56.525+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
   2021-08-27T10:16:56.526+00:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
------

Loading file: ~\export_data_multiple_databases\obter_vendas.js
[{
  fabricante: 'Hyundai',
  modelo: 'Genesis',
  ano: 2009,
...

Para resolver este problema basta adicionar o parâmetro --quiet ao comando de exportação.

Através do método de importação pela linha de comando:

mongosh mongodb://localhost:27017/examples --quiet ~/export_data_multiple_databases/obter_massa_dados.js > arquivo_resultado.json

Usando o --eval:

mongosh mongodb://localhost:27017/examples --quiet --eval="load('export_data_multiple_databases/obter_massa_dados.js');" > arquivo_resultado.json

Ao examinar novamente o arquivo, nota-se que o cabeçalho sumiu e com isso temos um arquivo .json válido e somente com os dados solicitados.

Impressões e Conclusão

A ideia deste post surgiu de uma tarefa que solicitava a exportação de dados oriundos de um schema específico para csv. Tal schema existia em diversas collections com documentos que possuiam campos diferentes entre si. O único ponto em comum dessas collections era justamente um subdocumento com o schema em questão.
Como não sou um profundo conhecedor de mongodb e não encontrei uma forma fácil na documentação e muito menos no stackoverflow e afins, resolvi ser criativo. Me vali da capacidade do mongodb de executar scripts .js e de conhecimentos básicos de shell.

A solução é um tanto verbosa, porém resolveu meu problema de forma simples e eficiente. Imagino que os especialistas em mongodb vão me contar nos comentários:
- basta rodar essa linha de comando que você obtém o mesmo resultado
Mas até lá, vou seguir usando a mesma abordagem para obter esses dados sempre que forem solicitados.

No github (pasta export_data_multiple_databases) deixei o passo a passo de como reproduzir esse post.

julianopoveda / mongoblogposts

Quero deixar um agradecimento especial para o Caio Lucena pelas revisões dos posts publicados até agora.

Referências

https://docs.mongodb.com/mongodb-shell/
Solução do Erro: Como importar data em formato string como tipo date

Exportando campos específicos com mongoexport

Poveda — Thu, 12 Aug 2021 10:52:39 +0000

No post anterior expliquei como filtrar os dados da base antes de exportá-los. O filtro é muito útil para obtermos somente os dados desejados já no momento da exportação e assim reduzir a carga na rede. No entanto, quando a exportação é realizada, o document inteiro é exportado.

E se quisermos somente alguns campos daquele document?

É para esses casos que o mongoexport possui as opções --fields e --fieldFile.

O parâmetro --fields

O parâmetro field recebe os campos desejados separados por vírgula diretamente no comando do mongoexport. Pode ser adicionado qualquer campo do document, incluindo os campos de subdocuments.

mongoexport.exe mongodb://localhost:27017 --db example -c cars --queryFile="~/filter2.json" --fields="ano,fabricante,motorizacao.litros" --csv

Note que além do parâmetro --fields, também utilizei o parâmetro --csv para forçar a exportação em csv, pois no json (formato de exportação padrão) existem algumas peculiaridades.

O resultado obtido rodando o comando na nossa base de testes foi o seguinte

ano,fabricante,motorizacao.litros
1984,Toyota,1.6
1994,Toyota,2.2
1976,Toyota,1.4
2001,Toyota,1.8
1976,Toyota,1.6

Peculiaridades da exportação em json

Quando a opção de exportação é json (default), o campo _id também é exportado, independentemente de ter sido adicionado a lista ou não.
Outra particularidade é que se um campo do subdocument for adicionado como campo de exportação, todos os campos do subdocument serão exportados.

Exportação sem um campo do subdocument

mongoexport.exe mongodb://localhost:27017 --db example -c cars --queryFile="~/filter2.json" --fields="ano,fabricante"

O resultado obtido foi o seguinte

{"_id":{"$oid":"60f6e2eefc13ae490c000bb8"},"ano":1984,"fabricante":"Toyota"}
{"_id":{"$oid":"60f6e2eefc13ae490c000d61"},"ano":1994,"fabricante":"Toyota"}
{"_id":{"$oid":"60f6e2effc13ae490c000d91"},"ano":1976,"fabricante":"Toyota"}
{"_id":{"$oid":"60f6e2effc13ae490c000e76"},"ano":2001,"fabricante":"Toyota"}
{"_id":{"$oid":"60f6e2effc13ae490c000e93"},"ano":1976,"fabricante":"Toyota"}

Conforme foi descrito anteriormente, o campo _id(pk do registro) foi exportado mesmo que ele não conste nos campos no parâmetro --fields

Exportação com um campo do subdocument.

mongoexport.exe mongodb://localhost:27017 --db example -c cars --queryFile="~/filter2.json" --fields="ano,fabricante, motorizacao.litros"

Como pode ser visto neste exemplo, só foi pedido para retornar o campo litros do subdocument motorização, no entando o resultado listado abaixo, mostra que o campo hp foi enviado para o resultado final

{"_id":{"$oid":"60f6e2eefc13ae490c000bb8"},"ano":1984,"fabricante":"Toyota","motorizacao":{"litros":1.6,"hp":190}}
{"_id":{"$oid":"60f6e2eefc13ae490c000d61"},"ano":1994,"fabricante":"Toyota","motorizacao":{"litros":2.2,"hp":221}}
{"_id":{"$oid":"60f6e2effc13ae490c000d91"},"ano":1976,"fabricante":"Toyota","motorizacao":{"litros":1.4,"hp":134}}
{"_id":{"$oid":"60f6e2effc13ae490c000e76"},"ano":2001,"fabricante":"Toyota","motorizacao":{"litros":1.8,"hp":140}}
{"_id":{"$oid":"60f6e2effc13ae490c000e93"},"ano":1976,"fabricante":"Toyota","motorizacao":{"litros":1.6,"hp":134}}

O parâmetro --fieldFile

Com o parâmetro --fieldFile é possível passar o caminho de um arquivo que contém a lista de campos a serem exportados. Cada linha deve conter somente um campo, caso contrário ocorre erro na exportação. Infelizmente este parâmetro só pode ser utilizado para as exportações do tipo --csv, sendo ignorado quando a exportação é para json.

mongoexport.exe mongodb://localhost:27017 --db example -c cars --queryFile="~/filter2.json" --fieldFile="~/fields_to_export.txt" --csv

Resultado da execução

fabricante,ano,motorizacao.hp
Toyota,1984,190
Toyota,1994,221
Toyota,1976,134
Toyota,2001,140
Toyota,1976,134

Impressões e Conclusão

Vejo que estes parâmetros são muito úteis, principalmente se necessitamos exportar determinados campos do banco para um arquivo csv que poderá ser utilizado em algum teste de cargas ou importação em outros sistemas, pois com a seleção dos campos é possível planificar um documento do mongo.
Já para a exportação em json, vejo este método como uma forma de sanitizar campos do documento principal, deixando somente os campos relevantes para uma nova base de dados ou arquivo de mock.

O que me motivou a escrever esse post foi uma extrapolação do post anterior quando pensei:

Consegui filtrar os dados, mas e se eu quiser retornar somente determinados campos como no sql? Será que consigo?

No github (pasta fields_mongoexport) deixei o passo a passo de como reproduzir esse post.

julianopoveda / mongoblogposts

Referencias

https://docs.mongodb.com/database-tools/mongoexport/

Exportando dados filtrados com mongoexport

Poveda — Thu, 29 Jul 2021 12:16:34 +0000

Quem já precisou filtrar os dados da base antes de exportar sabe que nem sempre é uma tarefa simples. Quando falamos de mongodb essa situação fica um pouco mais complicada, pois as ferramentas visuais (como Compass e robo 3T) não possuem uma forma direta de salvar as consultas.

Falei besteira?
Comenta no post e me ajuda a melhorar a difusão de conhecimento :)

Para esses casos o mongo possui as ferramentas cli conhecidas como mongoexport

resumo: Exporta os dados em formato json ou csv

Executar o mongoexport é bem direto. No exemplo abaixo já é possível obter uma massa de dados da tabela desejada.

mongoexport mongodb://localhost:27017 --db=example -c=carros

O parâmetro --query

O parâmetro query recebe como valor um json (padrão extended v2) o qual será utilizado como critério pela ferramenta na hora de selecionar quais documentos devem ser exportados.

Os atributos de pesquisa permitidos estão restritos aos query selectors.

Atributos de aggregation não são permitidos

mongoexport mongodb://localhost:27017 --db=example -c=carros --query='{ "modelo":"Dodge", "ano":{ "$gt": 2011 } }'

O parâmetro --queryFile

Já o --queryFile recebe o caminho do arquivo json. Este arquivo funciona da mesma maneira, incluindo as restrições, que o json inline passado no parâmetro --query.

Exemplo de arquivo json

{
    "modelo": "Dodge",
    "ano": {
        "$gt": 2011
    }
}

mongoexport mongodb://localhost:27017 --db=example -c=cars --queryFile="~/filtros.json"

Impressões e Conclusão

Dadas as duas abordagens, eu prefiro a segunda por ser mais simples de ler e manter do que a abordagem com a query inline.Porém, se a consulta for simples e pontual (não sendo necessário compartilhá-la ou salvá-la para uso posterior), utilizaria o inline por ser mais direto e menos burocrático.

O que me motivou a escrever esse post foi a necessidade de realizar um export de uma quantidade significativa de dados para outra aplicação sem onerar a aplicação existente. O principal desafio de tal consulta, foi ter de encontrar uma solução que não envolve-se o uso de filtros do método aggregate. Com um pouco de busca na documentação oficial do mongodb, imaginação e validação dos dados(aquele diff salvador), consegui realizar a exportação dos dados.

No github (pasta quering_mongoexport) deixei o passo a passo de como reproduzir esse post.

julianopoveda / mongoblogposts

Referencias

https://docs.mongodb.com/database-tools/mongoexport/
https://docs.mongodb.com/manual/reference/operator/query/#query-selectors
https://docs.mongodb.com/manual/reference/mongodb-extended-json/