Gerenciador de versões Anaconda / Espaço em disco de Pacotes de Data Science (discussão geral)

[fititnt]

Aplica-se ao #5. Como pode requerer muito espaço em disco, pode valer a pena explicitamente não ser instalado em aguia-pescadora-alpha mas somente em aguia-pescadora-bravo #16

---

Uma das ideias de ter uma máquina compartilhada remota seria dar apoio ao que não poderia ser feito em computadores menos potentes.

Inicialmente foi por causa de procurar 1) soluções para contornar o que seria complexo demais até fazer hello world em Android <5 sem fazer root (ou seja, problema do software) (vide comentário #5 (comment), links para post na comunidade do Facebook). Então temos em casos bem especiais, como compilar APKs de Android 2) potencial limitação de memória RAM no momento exato da compilação (esse problema afetaria até Androids 9.0 sem muita RAM. Um terceiro eventual problema, 3) custo alto de internet via 3G e/ou (para data science) custo alto até pra quem tem conexão fixa mas ainda não ideal.

Uma solução positiva aqui é que, os desafios 1, 2 e 3 creio que a gente conseguiu contornar com as especificações do #16. Ok que isso pode exigir uma alta disciplina e ensinar as pessoas a usarem de forma bem otimizada, mas conseguindo isso, estamos falando de por um valor que até eu mesmo tiraria do meu bolso por mês, que é de 14 USD, a VPS da OVH eu não me importaria de deixar de graça para geral (e nem mesmo aceitar doações ou algo do tipo).

Porém tudo isso agora traz um novo desafio: 4) otimizar espaço de uso de arquivos em disco no servidor de trabalho.

Para referência futura de quem estiver lendo isso, sem que a gente eventualmente migre para servidor maior (Nota: mesmo se houvesse dinheiro, não tem demanda suficiente para justificar alugar algo maior) se fosse para aumentar apenas mais um pouco o espaço em disco, valeria mais a pena alugar uma secunda Bravo. O preço de 100GB de disco adicional é o mesmo de um disco de 80GB que já venha com outra máquina de 2 vCPUs e 8GB de RAM. E eu vou ser bem sincero com vocês que se eu nem com clientes meus deixo gastarem dinheiro a revelia com hardware, não seria com dinheiro meu, para projeto voluntário, que eu deixaria de procurar ser tão ou mais custo-eficiente.

Se estiver fazendo diferença e sendo usado por muita gente, eu estaria até OK de, para ter mais 80GB a mais de espaço, a gente ter uma Aguia Pescadora Charlie, mas nem ******* adicionaria pagaria o mesmo preço por um disco extra. Fora que talvez o disco extra poderia ser mais lento do que os SSDs atuais em RAID.

Então depois desse meu desabafo é que vem a questão de otimizar o uso de disco do Anaconda. Usando o miniconda, todo mundo instala exatamente os pacotes que precisa, porém isso (considerando a hipótese de dar contas gratuitas para muita gente) poderia implicar em acabar espaço em disco rápido.

Outro ponto é que boa parte das pessoas que faria "olá mundo" usando bibliotecas de data science, chuto eu talvez uns 80~95% do nosso publico alvo, talvez estaria OK em ter bibliotecas mais padrões instaladas.

Então esse issue aqui acaba sendo em uma estratégia de otimizar economizar muito espaço para esses 80-95% e, para usuários mais especiais (que na prática seria qualquer pessoa que pediria para instalar algo novo que quebraria para os demais) é mais eficiente dar até um ambiente separado para eles poderem fazer livremente.

[fititnt]

Em tempo

Links de minha pesquisa prévia sobre uso de conda/anaconda para múltiplos usuários (aka talvez deem ideia de como otimizar esse espaço em disco):

• https://medium.com/@pjptech/installing-anaconda-for-multiple-users-650b2a6666c6
• https://www.digitalocean.com/community/tutorials/how-to-install-anaconda-on-ubuntu-18-04-quickstart
• https://stackoverflow.com/questions/48871289/how-to-share-an-anaconda-python-environment-between-multiple-users
• https://medium.freecodecamp.org/why-you-need-python-environments-and-how-to-manage-them-with-conda-85f155f4353c
• https://docs.anaconda.com/anaconda/install/
• https://hub.docker.com/r/continuumio/anaconda3/dockerfile

[betafcc]

Use pyenv pra gerir as instalações e versões dos interpretadores de python e pipenv pra projetos e instalações de packages.

• Nunca instale o interpretador globalmente.
• Nunca use 'pip'.
• Nunca use 'sudo' quando tiver setando tooling de python
• Não use anaconda se vc for um dev, só vai te confundir e sujar teu sistema.

Posso descorrer sobre os motivos se tiver interessando, mas o ponto é que esse é o tooling oficial atualmente

[fititnt]

Essa questão gerenciadores de versão da linguagem + de pacotes extras se tornou comum em praticamente todos os ambientes de programação mais populares. Então parte (mas não todo) o problema pode ser comum a várias delas.

Aqui a gente tem algumas peculiaridades:

• O sistema operacional é padrão e o mais comum de encontrar documentação
  • no caso, Ubuntu Server 18.04 LTS. Muita coisa nem precisa compilar do source
  • mesmo quando pacotes oficiais de Debian e/ou ubuntu não estão disponíveis, é comum que haja um canal oficial dos desenvolvedores com versão atualizada (isso facilita muito manter atualizado)
• Problemas que alguns usuários teriam sempre teria pelo menos uma ou duas pessoas que podem ajudar a resolver os conflitos.
  • Mesmo que o usuário não tenha poder de sudo, quem tem poder de sudo está próximo
  • Caso o que ela precise seja muito especifico a gente indica (e talvez até deixa o passo a passo) de como usar gerenciador de pacotes oficial; porem necessariamente isso já teria que estar testado pra não dar conflitos
  • Caso o que a pessoa precise é útil como padrão, altera-se o padrão.
    • Porém por exemplo, se alguém estiver realmente usando um dos servidores da Servidores Águia Pescadora #5 pra algo um relativamente mais sério (como backend de um chatbot de comunidade), passado algum período de testes, pode valer a pena converter esses apps pra usar versão explicita. Isso aqui pode não ter tanto problema com apps mais simples em PHP, mas apps que tem dependências bem tensas (especialmente os de NodeJS) mesmo com Yarn/NPM poderia dar problema.

Talvez uma forma da gente pensar esse experimento de servidor comunitário seria o seguinte:

• O ambiente padrão (sem configuração extra) tem que idealmente funcionar para 90% das pessoas que querem testar algo novo.
  • Se ficar mais complicado que isso, a gente pode até criar VM separada pra respectiva pessoa.
  • Mesmo que encriptação por padrão do diretório home seja implementada (vide Encriptação do diretório home #18), além do arquivo /home/NomeDoUsuario/.ssh/authorized_keys ter que ficar em outro diretório não encriptado (sem isso a pessoa não consegue logar por chave publica), os usuários podem optar pelo arquivo que carrega variáveis extras do terminal que usarem (ex.: o bash/fish/zsh) de alguma forma também poderem ser editados por root. Pode ser mais fácil isso do que documentar e explicar como a pessoa resolve.
• Idealmente os custos tanto mensais, como de ajuda de administradores, deve ser barato ao ponto ser mantido indefinidamente
  • O Águia Pescadora Alpha Servidor Águia Pescadora Alpha #17 está na CloudAtCost, foi one time payment. Ele só não é poderoso suficiente.
  • O Águia Pescadora Bravo Servidor Águia Pescadora Bravo #16 está na OVH, porém esse é custo mensal. Diferente da Alpha, esse aqui eu não arriscaria deixar ligado indefinidamente sem ser usado por mais gente. Porém os custos mensais até seriam ok pra eu manter do próprio bolso.
  • Uma saída (se houver uso mínimo, porém eu ou outras pessoas não quiserem manter toda ou parte de Bravo na OVH) poderia ser mover parte da ideia toda para algo como a eclips.is citada em Discussão geral sobre a eclips.is (hospedagem de VPSs patrocinada pela OTF) #29.
  • Sobre o custo mensal de trabalho de administradores, o @loopchaves e eu também estamos usando esses servidores como testes que não seriam possíveis de fazer em serviços gratuitos (como os que estamos documentando em https://inclusao.etica.ai) em especial no grupo de Facebook Ligação Africa Brasil (Programação e informática) . Ou seja, para quem até está ajudando pessoal com perguntas simples de informática, a ideia de servidor compartilhado para quem não consegue fazer tudo via celular não seria muito incomum. Porém nada impede que no final de 3 meses a gente escolha aproveitar o que parece ser sustentável a longo prazo.

No começo de 2018, eu iniciei um projeto que acabou sendo inspiração para esse aqui, o ChatOps for non-DevOps people Working Group 2018/01. Ele ficou com servidores ativos até mais do que o tempo planejado inicialmente (e até hoje tem um privado que mantenho com colega). Uma das ideias desse AIOps para Comunidade dos Países de Língua Portuguesa, 2019/01 é procurar ser mais amigável para quem é iniciante e que fala português também para permitir mais gente que possa ajudar a manter ativo.

E sim, sim sim, deixei esse texto aqui não só pra você, Brendon, mas porque nessas próximas semanas vou ver com mais gente também como otimizar a ideia toda. E mesmo que os servidores públicos não fiquem ligados, pelo menos toda documentação de como recriar eles é pública.