Utilização de Docker para isolação de ambientes.

[dfquaresma]

A utilização de scritps que configuram ambientes para disciplinas quando executados em um mesmo ambiente podem conflitar entre sí, uma vez que configurações específicas podem divergir. Além desse detalhe (conflito de configurações), manter um ambiente para vários fins pode ser entrópico e dificulta a compreesão do que de fato está sendo utilizado.

Uma solução bacana seria prover isolamento entre os ambientes e garantir que realmente existam múltiplos ambientes. Sendo assim, para fazer uso de um ambiente bastaria trocar o contexto para o ambiente de interesse. Uma opção para implementação dessa solução seria o uso de Contêineres, que poderia ser feito utilizando a tecnologia Docker.

O que acham?

[dfquaresma]

A utilização de scritps que configuram ambientes para disciplinas quando executados em um mesmo ambiente podem conflitar entre sí, uma vez que configurações específicas podem divergir. Além desse detalhe (conflito de configurações), manter um ambiente para vários fins pode ser entrópico e dificulta a compreesão do que de fato está sendo utilizado.

Uma solução bacana seria prover isolamento entre os ambientes e garantir que realmente existam múltiplos ambientes. Sendo assim, para fazer uso de um ambiente bastaria trocar o contexto para o ambiente de interesse. Uma opção para implementação dessa solução seria o uso de Contêineres, que poderia ser feito utilizando a tecnologia Docker.

O que acham?

@thayannevls @victorhundo

[thayannevls]

Acho uma ideia muito legal 👍 só teríamos que pensar uma forma de manter simples para as pessoas que nunca mexeram com isso e podem ter dificuldades para rodar os containers ou criar volumes com sua máquina local por exemplo.

Talvez isso aqui possa ajudar: https://portainer.readthedocs.io/en/stable/

[dfquaresma]

Acho uma ideia muito legal só teríamos que pensar uma forma de manter simples para as pessoas que nunca mexeram com isso e podem ter dificuldades para rodar os containers ou criar volumes com sua máquina local por exemplo.

Talvez isso aqui possa ajudar: https://portainer.readthedocs.io/en/stable/

Concordo! É importante ter isso em mente principalmente para os alunos de primeiro período.

[joivo]

O que acham do gerenciamento dos containers ser feito pela aplicação CLI? Me parece que a ideia é ter um encapsulamento de cada ambiente de disciplina de modo que o funcionamento fique transparente, ou seja, não vísivel para os usuários.

O ideal seria, por exemplo, que via linha de comando x alunx pudesse fazer algo como
cc-scripts start p2 e tudo funcionasse.
O que acham?

[thayannevls]

Seria muito massa se funcionasse dessa forma @emanueljoivo . A CLI poderia facilitar também a parte dos volumes e talvez portas caso o aluno esteja usando o ambiente pra fazer algum serviço por exemplo. No caso faria toda a lógica de comunicar o local com o container pro usuário, certo?

PS: To falando isso com o que sei de docker, se não for preciso vocês dizem.

[dfquaresma]

O que acham do gerenciamento dos containers ser feito pela aplicação CLI? Me parece que a ideia é ter um encapsulamento de cada ambiente de disciplina de modo que o funcionamento fique transparente, ou seja, não vísivel para os usuários.

O ideal seria, por exemplo, que via linha de comando x alunx pudesse fazer algo como
cc-scripts start p2 e tudo funcionasse.
O que acham?

Acho que ficaria show! O cara poderia fazer um cc-scripts start lp1 para criar e entrar no contêiner (se não houver o contêiner) ou apenar entrar (caso o contêiner já exista). Dentro do contêiner, o cara poderia copiar arquivos do contêiner para fora com um cc-scripts copy nome_do_arquivo (que copiaria o arquivo para a pasta /tmp/cc-scripts/lp1/) ou sair do contêiner com um cc-scripts exit.
Para mover um arquivo para dentro de um contêiner, poderia fazer um cc-scripts move nome_do_arquivo nome_da_disciplina (seria massa dar suporte para uso de expressão regular nessas definições de nome). Por fim, um cc-scripts delete lp1 mataria o contêiner e tudo que tivesse dentro seria descartado.

Desculpa o textão, acabei de empolgando kk. O que acham?

[dfquaresma]

Seria muito massa se funcionasse dessa forma @emanueljoivo . A CLI poderia facilitar também a parte dos volumes e talvez portas caso o aluno esteja usando o ambiente pra fazer algum serviço por exemplo. No caso faria toda a lógica de comunicar o local com o container pro usuário, certo?

PS: To falando isso com o que sei de docker, se não for preciso vocês dizem.

Inspirado no que você e @emanueljoivo disseram, mandei o textão acima kk Concordo com as ideias.

[joivo]

Exatamente na linha do que pensei, @thayannevls e @dfquaresma.
Uma abordagem de desenvolvimento do CLI top-down (pensando a partir dos comandos possíveis no sistema) pode ser uma boa forma de começar a pensar no design.

Inclusive, vi por aqui que há a possibilidade de rodar uma GUI de dentro do container, encapsulando até mesmo o uso de IDE's.

Essa issue então pode ser fundida com a #6 (transferir a discussão para lá)?

[joivo]

Me disponho a criar um doc com uma perspectiva inicial da especificação da CLI.

[JoseRenan]

Isso vai ser uma revolução se a gente conseguir fazer rodar o emulador de LOAC kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

[thayannevls]

huuum vai ficar mto massaaa ❤️ essa parte de ter uma GUI ou copiar arquivos, não era melhor só a CLI criar um volume com a pasta raiz do usuário e jogar no container? Daí ele não precisaria se preocupar em ficar passando arquivo e teria o conforto do ambiente local dele.

[dfquaresma]

huuum vai ficar mto massaaa essa parte de ter uma GUI ou copiar arquivos, não era melhor só a CLI criar um volume com a pasta raiz do usuário e jogar no container? Daí ele não precisaria se preocupar em ficar passando arquivo e teria o conforto do ambiente local dele.

Acho que sim, mas não entendi bem a ideia. Poderia dar mais detalhes? Seria como se o contêiner usasse uma pasta externa a ele?