|   |  | 
| Line 45: | Line 45: | 
|  | <br> <br> <br> |  | <br> <br> <br> | 
|  |  |  |  | 
| − | == Passo a Passo: caso de uso do Singularity ==
 |  | 
| − | <br>
 |  | 
| − | === Criar sua máquina container no formato "pasta sandbox" (para instalar os pacotes e dependências dos seus experimentos) ===
 |  | 
| − | 
 |  | 
| − | 1) Criar sua pasta de usuario em <code> /srv/forge/fulano/ </code>  ou  <code>/homeLocal/fulano </code> :
 |  | 
| − | * Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA e GHOST''' serão capazes de criar um container e abrir em modo edição com '''<code> $sudo singularity shell --writable... </code>'''. 
 |  | 
| − | * Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 |  | 
| − |     cd /srv/forge 
 |  | 
| − |     mkdir fulano
 |  | 
| − |     cd /srv/forge/fulano
 |  | 
| − | 
 |  | 
| − |     cd /homeLocal
 |  | 
| − |     mkdir fulano
 |  | 
| − |     cd /homeLocal/fulano
 |  | 
| − | 
 |  | 
| − | 2) Criar seu container singularity no formato "pasta sandbox" para ser possível instalar pacotes ([https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity#Docker_Hub:_M.C3.A1quinas_Container_Prontas.21 Mais dicas sobre usar URL Docker Hub]):
 |  | 
| − |     sudo singularity build --sandbox my_container docker://jjanzic/docker-python3-opencv:opencv-4.0.1
 |  | 
| − | 
 |  | 
| − | === Executar seu container singularity no formato "pasta sandbox" (modo edição ou modo leitura) ===
 |  | 
| − | 
 |  | 
| − | 1) Executar seu singularity no formato "pasta sandbox" em modo edição para instalar pacotes:
 |  | 
| − |     sudo singularity shell --writable my_container/
 |  | 
| − | 
 |  | 
| − | * Use <code>sudo</code> somente quando necessário (e.g., instalação de pacotes e configuração). Quando for rodar o container para experimentos, não será necessário invocar o singularity com permissão <code>sudo</code>.
 |  | 
| − | * Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA e GHOST''' serão capazes de criar um container e abrir em modo edição com '''<code> $sudo singularity shell --writable... </code>'''. 
 |  | 
| − | * Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 |  | 
| − | 
 |  | 
| − | 2) Executar seu singularity no formato "pasta sandbox" em modo leitura para testar (não precisa do <code>sudo</code>):
 |  | 
| − |     singularity shell my_container/
 |  | 
| − | 
 |  | 
| − | === Converter uma máquina container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.simg</code>''' ===
 |  | 
| − | 
 |  | 
| − | Depois de pronta, a máquina container, pode ser convertida do formato "pasta sandbox" para o formato de imagem (<code>.img</code> ou  <code>.simg</code>) isso permite que ela execute mais rápido, reduz o espaço em disco e número de arquivos listados.
 |  | 
| − | 
 |  | 
| − | O container pronto pode ser armazenado na sua pasta /home/nome_usuario da rede, assim pode ser executada como leitura de qualquer máquina de processamento que o usuário logar.
 |  | 
| − | 
 |  | 
| − | 1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.simg</code>'''. [https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#converting-images-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:
 |  | 
| − |     sudo singularity build my_ubuntu.simg my_container/
 |  | 
| − | <br> <br>
 |  | 
| − | 
 |  | 
| − | === PIP ===
 |  | 
| − | O '''Python Package Installer''', também conhecido como PIP, é responsável por instalar os pacotes Python criados pela comunidade. Dentro do singularity + moosefs, ele tem um comportamento anômalo, não instalando nas pastas padrão. Tais pastas "''padrão''" são especificadas diretamente no código-fonte do python, mais precisamente no módulo ''sys''.
 |  | 
| − | Faz-se portanto necessário utilizar a flag <code>-t/--target</code> ao instalar os pacotes via pip, apontando para a pasta ''dist-packages'' da distribuição utilizada.
 |  | 
| − | 
 |  | 
| − | <code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code>
 |  | 
| − | <br> <br>
 |  | 
| − | 
 |  | 
| − | == <span style="color: red;">IMPORTANTE</span>: Diferença entre os 3 formatos criados pelo <code>build</code>: ==
 |  | 
| − | <br>
 |  | 
| − | ==== Arquivo único, extensão <code>'''.simg'''</code>: <span style="color: red;">NÃO</span> é possivel editar container ====
 |  | 
| − | * Destinado para fase de experimentos em massa (produção)
 |  | 
| − | * Vantagem: Em geral, ocupa menos espaço e executa mais rápido que um container equivalente no formato '''.img'''. Indicado para produção, versão final de experimentos.
 |  | 
| − | * Desvantagem: Não pode-se fazer modificação no container. Para Instalar algo, tem que transformar em '''.img''' ou '''"pasta sandbox"'''.
 |  | 
| − | * (single file) compressed read-only squashfs file system suitable for production (default)
 |  | 
| − | <br> <br>
 |  | 
| − | ==== Arquivo único, extensão <code>'''.img'''</code>: <span style="color: red;">NÃO</span> indicado para editar o container, apesar de possível com limitação de espaço ====
 |  | 
| − | * Destinado para a fase de desenvolvimento, mas com container sofrendo poucas alterações.
 |  | 
| − | * Vantagem: Em geral, ocupa menos espaço e executa mais rápido que um container equivalente no formato "pasta sandbox". E ainda pode-se instalar pacotes (opção --writable), porém tem limitação de espaço em disco. 
 |  | 
| − | * Desvantagem: O disco tem tamanho fixo, então é possível fazer modificações e instalações com opção --writable, mas se não couber no disco, o mesmo tem que ser expandido manualmente com [https://sylabs.io/guides/2.5/user-guide/appendix.html#image-expand image.expand --size]
 |  | 
| − | *(single file): writable ext3 file system suitable for interactive development ( --writable option )
 |  | 
| − | <br> <br>
 |  | 
| − | ==== '''Pasta Sandbox''' <code>sandbox directory </code>: <span style="color: red;">INDICADO PARA MODIFICAR a imagem (instalar pacotes)</span>, sem limitações de espaço significativas ====
 |  | 
| − | * Destinado para desenvolvimento inicial do container, quando ainda não se sabe exatamente as configurações e ferramentas a serem usadas, logo o container ainda sofre muitas alterações.
 |  | 
| − | * Vantagem: vários arquivos e sub-pastas que são expansíveis automaticamente conforme vai-se instalando pacotes (opção --writable). O tamanho do disco é expansível conforme disponibilidade da máquina host. 
 |  | 
| − | * Desvantagem: Mais lento dos formatos para execução! 
 |  | 
| − | * (many files and sub-folders): writable (ch)root directory called a sandbox for interactive development ( --sandbox option)
 |  | 
| − | <br> <br>
 |  | 
| − | 
 |  | 
| − | ==== Converter uma máquina container container do formato '''"pasta sandbox"''' para o formato '''<code>.simg</code>''' ====
 |  | 
| − | * Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.simg</code>'''. [https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#converting-images-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:
 |  | 
| − | 
 |  | 
| − |     sudo singularity build my_ubuntu.simg my_container/
 |  | 
| − | <br> <br> <br>
 |  | 
| − | 
 |  | 
| − | == Docker Hub: Máquinas Container Prontas! ==
 |  | 
| − | * Docker Hub: várias imagens prontas com ferramentas instaladas
 |  | 
| − | 
 |  | 
| − |     https://hub.docker.com/
 |  | 
| − | 
 |  | 
| − | Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório 
 |  | 
| − | 
 |  | 
| − |     https://hub.docker.com/r/jjanzic/docker-python3-opencv
 |  | 
| − | 
 |  | 
| − | Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''
 |  | 
| − | 
 |  | 
| − | No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: 
 |  | 
| − | 
 |  | 
| − |     List of available docker tags:
 |  | 
| − |     opencv-4.1.0 (latest branch)
 |  | 
| − |     contrib-opencv-4.1.0 (opencv_contrib branch)
 |  | 
| − |     opencv-4.0.1
 |  | 
| − |     contrib-opencv-4.0.1
 |  | 
| − |     opencv-4.0.0
 |  | 
| − |     contrib-opencv-4.0.0
 |  | 
| − |     opencv-3.4.2
 |  | 
| − |     contrib-opencv-3.4.2
 |  | 
| − |     (...)
 |  | 
| − | 
 |  | 
| − | Assim para criar o container usando <code>build</code> e copiando do repositório exemplo a tag <code>opencv-4.0.1</code>, tem-se:
 |  | 
| − | 
 |  | 
| − |     <code>sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1</code>
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | == Links para aprender Singularity ==
 |  | 
| − | 
 |  | 
| − | ==== Documentação oficial ====
 |  | 
| − | 
 |  | 
| − | * https://www.sylabs.io/docs/ (atual, desde julho/2018)
 |  | 
| − | 
 |  | 
| − | * https://singularity.lbl.gov/docs-docker (verãos antiga)
 |  | 
| − | 
 |  | 
| − | ==== More details about the different build options and best practices, read singularity flow: ====
 |  | 
| − | 
 |  | 
| − | https://sylabs.io/guides/2.5/user-guide/introduction.html#the-singularity-usage-workflow
 |  | 
| − | <br> <br> <br>
 |  | 
| − | == Alguns Comandos Básicos ==
 |  | 
| − | https://www.sylabs.io/guides/2.5/user-guide/quick_start.html#interact-with-images
 |  | 
| − | 
 |  | 
| − | * <code>[https://www.sylabs.io/guides/2.5/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container
 |  | 
| − | 
 |  | 
| − | * <code> [https://www.sylabs.io/guides/2.5/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell
 |  | 
| − | 
 |  | 
| − | * <code>[https://www.sylabs.io/guides/2.5/user-guide/quick_start.html#executing-commands '''exec''']</code>: Executa um comando na máquina container, em segundo plano, e apresenta o resultado no shell da máquina host
 |  | 
| − | 
 |  | 
| − | * <code>[https://www.sylabs.io/guides/2.5/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.
 |  | 
| − | 
 |  | 
| − | * opção <code>[https://sylabs.io/guides/2.5/user-guide/quick_start.html#working-with-files '''--build''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://sylabs.io/guides/2.5/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --build])
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | == <code>'''build'''</code>: Criar uma máquina container ==
 |  | 
| − | 
 |  | 
| − | ==== Criar uma máquina container editável (para instalar pacotes) ====
 |  | 
| − | * Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#sandbox-directory Dicas sobre a opção <code>--sandbox</code>].
 |  | 
| − | * Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: 
 |  | 
| − | 
 |  | 
| − | <code>sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:18.04</code>
 |  | 
| − | 
 |  | 
| − | <code> sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest </code>
 |  | 
| − | 
 |  | 
| − | * Exemplo singularity sandbox usando um repositório qualquer do dockerhub
 |  | 
| − | <code> sudo singularity build --sandbox my_container/ docker://repository_name:tag </code>
 |  | 
| − | <br><br>
 |  | 
| − | ==== outros exemplos menos usados, pois criam container's com limitação de edição ou não editável ====
 |  | 
| − | * Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: 
 |  | 
| − |     <code> sudo singularity build my_ubuntu.img docker://index.docker.io/library/ubuntu:latest </code>
 |  | 
| − | 
 |  | 
| − | Deve-se usar o formato <code>.img</code> (writable) a partir de um repositório Docker Hub: 
 |  | 
| − |     <code> sudo singularity build --writable my_ubuntu.img docker://index.docker.io/library/ubuntu:latest </code>
 |  | 
| − | 
 |  | 
| − | * Para aumentar o tamanho do disco no container formato <code>.img</code> pode-se utilizar o comando  [https://sylabs.io/guides/2.5/user-guide/appendix.html#image-expand  <code>singularity image.expand --size XXX</code> ]
 |  | 
| − |     singularity image.expand my_test.img   # Specify a size for an operation in MiB, i.e. 1024*1024B (default 768MiB)
 |  | 
| − |     singularity image.expand --size 500 my_test.img   # expand size of 500 MiB
 |  | 
| − | 
 |  | 
| − | * Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox: ([https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#converting-images-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]
 |  | 
| − | 
 |  | 
| − |     <code>sudo singularity build my_ubuntu.simg my_container/</code>
 |  | 
| − | 
 |  | 
| − | * Criar uma máquina container em formato <code>.simg</code> (read-only) a partir de um repositório Docker Hub:
 |  | 
| − |     <code> singularity build lolcow.simg docker://godlovedc/lolcow </code>
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | == <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==
 |  | 
| − | 
 |  | 
| − | You can make changes to the container (assuming you have the proper permissions to do so) but those changes will disappear as soon as you exit. To make your changes persistent across sessions, use the --writable option. It’s also a good practice to shell into your container as root to ensure you have permissions to write where you like.
 |  | 
| − | 
 |  | 
| − | * Executar a máquina container no shell, sem salvar modificações feitas na sessão:
 |  | 
| − | 
 |  | 
| − | <code>singularity shell my_container/</code>
 |  | 
| − | 
 |  | 
| − | <code>singularity shell my_ubuntu.img/</code>
 |  | 
| − | 
 |  | 
| − | * para algum teste de configuração ou instalação de pacote temporário
 |  | 
| − | <code>sudo singularity shell my_ubuntu.img/</code>
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | == <code>opção '''--writable'''</code>: Permitir que mudanças sejam salvas na imagem da máquina container (instalar pacotes): ==
 |  | 
| − | 
 |  | 
| − | * TODO: Como fazer na homeLocal e como fazer na proc2:/srv/forge
 |  | 
| − | 
 |  | 
| − | * Dado que sua imagem está no formato <code>sandbox</code> 
 |  | 
| − | <code>sudo singularity shell --writable my_container/</code>
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | * Executar a máquina container no shell, salvando as modificações da sessão ao sair do container. usar opção --writable ([https://sylabs.io/guides/2.5/user-guide/singularity_flow.html#development-commands Dicas sobre a opção <code>--writable</code>])
 |  | 
| − | 
 |  | 
| − | <code>sudo singularity shell --writable my_container/</code> - para instalação de pacotes / configuração
 |  | 
| − | 
 |  | 
| − | <code>singularity shell --writable my_container/</code> - para a execução de experimentos
 |  | 
| − | 
 |  | 
| − | * Criar uma imagem .img writable 
 |  | 
| − | ([https://sylabs.io/guides/2.5/user-guide/singularity_flow.html#writable-image Dicas sobre criar uma imagem .img <code>--writable</code>])
 |  | 
| − | <br><br>
 |  | 
| − | 
 |  | 
| − | == <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==
 |  | 
| − | A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container, mas se for necessário acessar outra pasta no disco da máquina host, deve-se usar a opção <code>[https://sylabs.io/guides/2.5/user-guide/bind_paths_and_mounts.html#specifying-bind-paths --bind]</code> para indicar o caminho (path) a ser usado. O usuário precisa ter permissão de leitura e escrita na pasta da máquina host.
 |  | 
| − | 
 |  | 
| − | * Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container 
 |  | 
| − | 
 |  | 
| − | <code>singularity shell --bind /homeLocal/fulano my_container/</code>
 |  | 
| − | <br><br>
 |  | 
|  |  |  |  | 
|  | == Instalação == |  | == Instalação == | 
Toda máquina de processamento do Verlab/J (máquinas com GPU) deve ter o Singularity instalado e não precisam ter pacotes específicos de software como ROS, cuda, tensorflow. 
A equipe de rede é responsável por manter máquinas locais e máquinas de processamento disponíveis para executar o singularity. Foi escolhido que o sigularity estará disponível apenas nas máquinas com GPU Nvidia, assim confira a lista de máquinas na área restrita do site do verlab: