VeRLab Wiki - User contributions [en]

Trabalhando remotamente

2023-10-08T02:17:08Z

Analucia:

A seguir, algumas dicas para quem precisar usar a infraestrutura dos laboratórios de maneira remota.

Se você estiver de fora da rede do DCC (por exemplo, da sua casa e sem usar VPN), é necessário fazer login primeiro na máquina login.dcc.ufmg.br, para depois entrar na máquina específica do laboratório com que se quer trabalhar (e.g., roomba, epona).

== Acessando máquinas via SSH (shell) ==

É possível usar o recurso de ''jump host'' do SSH para conectar na máquina desejada (e.g., roomba) passando por outra que esteja no caminho (e.g, login.dcc.ufmg.br).

Em linha de comando, podemos fazer:

ssh -J SEU_USUARIO_DCC@login.dcc.ufmg.br SEU_USUARIO_VERLAB@NOME_DA_MAQUINA.verlab

Por exemplo, para <code>flavioro</code> se conectar à '''roomba''':

ssh -J flavioro@login.dcc.ufmg.br flavioro@roomba.verlab

Ao executar, primeiro será solicitada a senha do usuário do DCC, depois a senha dele no laboratório (se forem diferentes).

== Acessando máquinas via SSH (VSCODE) ==

1. Instale a extensão '''Remote - SSH''' em seu VsCode.

2. Clique no ícone '''Remote Explorer''', que se encontra no menu lateral esquerdo.

3. Certifique-se que a opção Remote Explorer esteja setada com '''Remotes (Tunnels/SSH)'''.
[[File:Remote_tunel.png]]

4. Clique em adicionar nova conexão e copie o seguinte comando na aba de input que irá se abrir:

ssh -J SEU_USUARIO_DCC@login.dcc.ufmg.br SEU_USUARIO_VERLAB@NOME_DA_MAQUINA.verlab

5. Aperte Enter.

6. Clique no primeiro diretório de arquivo de configuração para criá-lo.

7. Clique em Connect.
[[File:Host_add.png]]

8. Insira suas credenciais (Primeiro a senha do login.dcc e depois a do laboratório).

== Acessando máquinas via SFTP (nautilus) ==

[[File:screenshot-from-gnome-files.png|500px|right|Screenshot do Gnome Files mostrando a aba "+ Outros Locais", que permite o usuário "Conectar a servidor", digitando um endereço SSH (dentre outras formas).]]

Para fazer transferência de arquivos entre a sua máquina e aquela em que você executou seus experimentos, você pode usar SFTP. O Files (antigo Nautilus) do Gnome tem essa funcionalidade. Você pode testar digitando <code>ssh://SEU_USUARIO_DCC@login.dcc.ufmg.br</code> no campo "Conectar a servidor" e ver que consegue ver os arquivos da sua HOME do DCC (depois de digitar sua senha).

Contudo, não é possível usar a funcionalidade de ''jump host'' do SSH tão facilmente pela interface do Files. É necessário configurar o SSH para criar os destinos desejados e, então, acessar usando o nome do destino desejado. Para tanto, vamos precisar:

# Abrir (criando ou alterando) o arquivo de configuração do SSH no seu computador
# nano ~/.ssh/config
# Escrever as configurações para (a) compartilhamento de conexão entre ''jumps'', (b) definir destino da rede DCC, definir 1 novo destino para cada máquina desejada do laboratório:<pre>ControlMaster auto
ControlPath ~/.ssh/control-%h-%p-%r
Host dcc
 HostName login.dcc.ufmg.br
 User SEU_USUARIO_DCC

Host roomba
 HostName roomba.verlab
 ProxyCommand ssh -W %h:%p dcc
 User SEU_USUARIO_VERLAB
Host wall-e
 HostName 150.164.212.244
 ProxyCommand ssh -W %h:%p dcc
 User SEU_USUARIO_VERLAB
Host NOME_DE_UMA_MAQUINA
 HostName NOME_DE_UMA_MAQUINA
 ProxyCommand ssh -W %h:%p dcc
 User SEU_USUARIO_VERLAB</pre>
# Testar o acesso SSH (shell) para a rede do DCC e para os computadores do laboratório desejados:<pre>ssh dcc
# deve pedir sua senha DCC para se conectar à login.dcc.ufmg.br
ssh roomba
#deve pedir primeiro a senha DCC, depois a do laboratório</pre>
# Na interface do Files (antigo nautilus), na aba "+ Outros locais", no campo "Conectar a servidor", digite <code>ssh://NOME_DE_UMA_MAQUINA</code>. Por exemplo:<pre>ssh://roomba</pre>
#* Então, forneça sua senha do DCC
#* Depois do laboratório
#* Será possível visualizar, baixar/subir arquivos para sua HOME na máquina em que entrou:

[[File:screenshot-files-mostrando-sftp-para-marvin.png|600px|center|Screenshot do Gnome Files mostrando a aba "+ Outros Locais" conectada à máquina marvin do laboratório, permitindo transmissão de arquivos.]]

== Usando tmux ou byobu: multiplexador de terminais ==

* tmux
** https://www.hostinger.com.br/tutoriais/como-usar-tmux-lista-de-comandos/
** https://www.makeuseof.com/install-tmux-linux/
** https://www.makeuseof.com/tag/cheat-sheet-tmux-commands-cheat-sheet/
** https://itexto.com.br/receitas-da-itexto-como-ter-janelas-em-seu-terminal-usando-tmux/

* byobu
** https://linuxhint.com/byobu-linux-command/
** https://opensource.com/article/20/2/byobu-ssh
** https://aliartiza75.medium.com/what-is-byobu-and-how-to-use-it-b09722008d65
** https://byobu.org/



== Comandos Basicos Linux ==
* https://avantufmg.notion.site/Comandos-B-sicos-Terminal-Linux-491cfabc506248f680b3daedf61fa23c

File:Host add.png

2023-10-08T02:08:14Z

Analucia:

File:Remote tunel.png

2023-10-08T02:05:15Z

Analucia:

File:Remote ssh.png

2023-10-08T02:03:06Z

Analucia:

Singularity3

2023-10-02T18:43:41Z

Analucia: /* 4) Corrigir o ownership da sua "pasta sandbox" */

= Singularity CE 3.x (Community Edition) =
=== '''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022, atualmente instalado nas máquinas a v3.10.x''' ===

==== Documentação oficial Singularity CE v3.x ====
* https://www.sylabs.io/docs/
* '''User Guide CE v3.10.x '''
** https://docs.sylabs.io/guides/3.10/user-guide/
** https://docs.sylabs.io/guides/3.10/user-guide/quick_start.html
* '''Adm Guide CE v3.10.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'')
** https://docs.sylabs.io/guides/3.10/admin-guide/
* ''' ''Definition Files'' '''
** https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile
 

== IMPORTANTE: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==

==== '''Pasta <code>sandbox</code>''': INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes) ====
* Destinado para desenvolvimento interativo do container, quando ainda precisa fazer testes e não se sabe exatamente as configurações/ferramentas a serem usadas, logo o container pode ter novas instalações e alterações nos pacotes.
* Vantagem: vários arquivos e sub-pastas que são expansíveis automaticamente conforme os pacotes são instalados (opção --writable). O tamanho do disco é expansível conforme disponibilidade de espaço em disco da máquina host.
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)
 
==== '''Arquivo único, extensão <code>.sif</code>''': SOMENTE LEITURA, NÃO é possível editar o container ====
* Destinado para fase de experimentos em massa (production)
* Vantagem: É uma imagem comprimida, ocupa menos espaço em disco e executa mais rápido que um container equivalente no formato sandbox. Também suporta criptografia
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.
* compressed read-only Singularity Image File (SIF) format suitable for production (default)
 

== Passo a Passo: Uso do Singularity CE v3.x ==
 
Exemplos de interação mais usuais com o container singularity

# Confirmar se a máquina tem singularity instalado e a versão
# Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)
# Criar seu container Singularity no formato "pasta sandbox"
# Corrigir o ownership da sua "pasta sandbox"
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)
# Usar o shell em modo "somente leitura" para testar
# Usar o shell e montar uma pasta do host
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)
 

==== 1) Conferir se a máquina tem singularity instalado e a versão ====
singularity --version
 

==== 2) Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====
Deve-se solicitar a um gestor da infraestrutura da rede VeRLab/JLab para criar uma pasta com seu nome de usuário e mudar o proprietário da pasta para seu usuário da rede do Verlab e o grupo DomainUsers (<code>gid=513</code>).

Existem duas opções de locais para armazenar sua pasta de containers singularity:
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code>

Pasta no serviço de storage:
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
cd /srv/forge
mkdir fulano
chown -Rv fulano:513 fulano/
cd /srv/forge/fulano

Pasta no /homeLocal de alguma máquina:
cd /homeLocal
mkdir fulano
chown -Rv fulano:513 fulano/
cd /homeLocal/fulano
 

==== 3) Criar seu container Singularity no formato "pasta sandbox" ====

O formato sandbox é usado para modificar e instalar pacotes no container

sudo singularity build --sandbox [pasta_destino] [container_origem]

* A base usada na construção do container pode ter várias fontes diferentes online ou local:
** '''URI docker''':// container do repositório online no ''Docker Hub'' ([https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3#Docker_Hub:_Usar_reposit.C3.B3rio_de_M.C3.A1quinas_Container_Prontas.21 Mais dicas sobre usar URI Docker Hub])
** '''URI library''':// container do repositório online no ''Sylab Container Library''
** URI shub:// container do repositório online no ''Singularity Hub''
** ''' caminho para um outro container .sif ''' numa pasta local na própria máquina host
** '''caminho para um outro container em pasta ''sandbox'' ''' na própria máquina host
** '''caminho para um ''definition file'' '''no formato Singularity CE

* Alguns exemplos:

Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04

Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye
 

==== 4) Corrigir o ownership da sua "pasta sandbox" ====

Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root

'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership da pasta para seu_usuario:DomainUsers'''

a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:
id nome_usuario

b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)
sudo chown -Rv [uid]:513 pasta_sandbox/
 

==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====

Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.

Também é indicado usar a opção --no-home para não montar a /home/root da máquina host e evitar que os instaladores tentem salvar algo na home da máquina host.
( Link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )

Se o instalador tentar usar a /home/root, deve-se ler a documentação do instalador para optar por pastas alternativas dentro da estrutura do container como /usr/bin, /usr/local, /opt/
sudo singularity shell --writable --no-home my_container/

* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container e abrir em modo edição.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 

==== 6) Usar o shell em modo "somente leitura" para testar ====
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:
singularity shell my_container/
Em geral, nesse momento também é necessário montar uma pasta externa ao container para salvar dados e resultados, isso é explicado no pŕoximo item
 
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).

Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]

O caminho de montagem dentro do container é opcional e se for omitido, é usado o mesmo caminho do host, porém o usuário deve ter permissão para acessar a pasta de montagem. No exemplo mostra como deixar o path /homeLocal/fulano acessível dentro do container em /mnt:
singularity shell --bind /homeLocal/fulano:/mnt my_container/

Também é possivel combinar as opções do --bind com --writable --no-home, neste caso, o root precisa ter permissão para acessar a pasta de montagem:
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/

* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====

Depois de pronta, a máquina container, pode ser convertida do formato "pasta sandbox" para o formato de <code>.sif</code>) isso permite que ela execute mais rápido, reduz o espaço em disco.

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>.sif</code>'''. [https://sylabs.io/guides/3.9/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:
sudo singularity build [container_destino] [container_origem]
sudo singularity build my_container-compact.sif my_container/
 

== Limitar recursos do container (RAM, Core's, network e etc) ==

É possível criar um arquivo '''cgroups.toml''' e limitar (ou medir) recursos usados pelo container. Por exemplo, limitar o uso de RAM para não esgotar os recursos da máquina host.

Segue o texto original e os links com mais informações:

''The cgroups (control groups) functionality of the Linux kernel allows you to limit and meter the resources used by a process, or group of processes. Using cgroups you can limit memory and CPU usage. You can also rate limit block IO, network IO, and control access to device nodes.''

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html
 

== Docker Hub: Usar repositório de 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:

sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1
 

== PIP: Python Package Installer ==
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>
 

== Links dos Comandos Básicos ==
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images

* <code>[https://sylabs.io/guides/3.9/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/3.9/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/3.9/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/3.9/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/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

== <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:

sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest

* Exemplo singularity sandbox usando um repositório qualquer do dockerhub
sudo singularity build --sandbox my_container/ docker://repository_name:tag
 
==== outros exemplos menos usados, pois criam container's não editável ====
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:
sudo singularity build my_ubuntu.sif my_container/
 

== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==

* Executar a máquina container no shell, sem salvar modificações feitas na sessão:
singularity shell my_container/
singularity shell my_ubuntu.sif/
 

== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==

* Só é possivel alterar um container em formato <code>sandbox</code>, uma boa prática é adicionar a opção --no-home é importante para não ocorrer a montagem automática da /home do root, e evitar que instaladores tentem usar essa pasta para instalação de pacotes.
sudo singularity shell --writable --no-home my_container/
 

== <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 ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras também ] ), 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:/mnt my_container/</code>

Singularity3

2023-10-02T18:43:20Z

Analucia: /* 4) Corrigir o ownership da sua "pasta sandbox" */

= Singularity CE 3.x (Community Edition) =
=== '''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022, atualmente instalado nas máquinas a v3.10.x''' ===

==== Documentação oficial Singularity CE v3.x ====
* https://www.sylabs.io/docs/
* '''User Guide CE v3.10.x '''
** https://docs.sylabs.io/guides/3.10/user-guide/
** https://docs.sylabs.io/guides/3.10/user-guide/quick_start.html
* '''Adm Guide CE v3.10.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'')
** https://docs.sylabs.io/guides/3.10/admin-guide/
* ''' ''Definition Files'' '''
** https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile
 

== IMPORTANTE: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==

==== '''Pasta <code>sandbox</code>''': INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes) ====
* Destinado para desenvolvimento interativo do container, quando ainda precisa fazer testes e não se sabe exatamente as configurações/ferramentas a serem usadas, logo o container pode ter novas instalações e alterações nos pacotes.
* Vantagem: vários arquivos e sub-pastas que são expansíveis automaticamente conforme os pacotes são instalados (opção --writable). O tamanho do disco é expansível conforme disponibilidade de espaço em disco da máquina host.
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)
 
==== '''Arquivo único, extensão <code>.sif</code>''': SOMENTE LEITURA, NÃO é possível editar o container ====
* Destinado para fase de experimentos em massa (production)
* Vantagem: É uma imagem comprimida, ocupa menos espaço em disco e executa mais rápido que um container equivalente no formato sandbox. Também suporta criptografia
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.
* compressed read-only Singularity Image File (SIF) format suitable for production (default)
 

== Passo a Passo: Uso do Singularity CE v3.x ==
 
Exemplos de interação mais usuais com o container singularity

# Confirmar se a máquina tem singularity instalado e a versão
# Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)
# Criar seu container Singularity no formato "pasta sandbox"
# Corrigir o ownership da sua "pasta sandbox"
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)
# Usar o shell em modo "somente leitura" para testar
# Usar o shell e montar uma pasta do host
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)
 

==== 1) Conferir se a máquina tem singularity instalado e a versão ====
singularity --version
 

==== 2) Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====
Deve-se solicitar a um gestor da infraestrutura da rede VeRLab/JLab para criar uma pasta com seu nome de usuário e mudar o proprietário da pasta para seu usuário da rede do Verlab e o grupo DomainUsers (<code>gid=513</code>).

Existem duas opções de locais para armazenar sua pasta de containers singularity:
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code>

Pasta no serviço de storage:
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
cd /srv/forge
mkdir fulano
chown -Rv fulano:513 fulano/
cd /srv/forge/fulano

Pasta no /homeLocal de alguma máquina:
cd /homeLocal
mkdir fulano
chown -Rv fulano:513 fulano/
cd /homeLocal/fulano
 

==== 3) Criar seu container Singularity no formato "pasta sandbox" ====

O formato sandbox é usado para modificar e instalar pacotes no container

sudo singularity build --sandbox [pasta_destino] [container_origem]

* A base usada na construção do container pode ter várias fontes diferentes online ou local:
** '''URI docker''':// container do repositório online no ''Docker Hub'' ([https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3#Docker_Hub:_Usar_reposit.C3.B3rio_de_M.C3.A1quinas_Container_Prontas.21 Mais dicas sobre usar URI Docker Hub])
** '''URI library''':// container do repositório online no ''Sylab Container Library''
** URI shub:// container do repositório online no ''Singularity Hub''
** ''' caminho para um outro container .sif ''' numa pasta local na própria máquina host
** '''caminho para um outro container em pasta ''sandbox'' ''' na própria máquina host
** '''caminho para um ''definition file'' '''no formato Singularity CE

* Alguns exemplos:

Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04

Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye
 

==== 4) Corrigir o ownership da sua "pasta sandbox" ====

Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root

'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership para seu_usuario:DomainUsers'''

a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:
id nome_usuario

b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)
sudo chown -Rv [uid]:513 pasta_sandbox/
 

==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====

Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.

Também é indicado usar a opção --no-home para não montar a /home/root da máquina host e evitar que os instaladores tentem salvar algo na home da máquina host.
( Link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )

Se o instalador tentar usar a /home/root, deve-se ler a documentação do instalador para optar por pastas alternativas dentro da estrutura do container como /usr/bin, /usr/local, /opt/
sudo singularity shell --writable --no-home my_container/

* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container e abrir em modo edição.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 

==== 6) Usar o shell em modo "somente leitura" para testar ====
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:
singularity shell my_container/
Em geral, nesse momento também é necessário montar uma pasta externa ao container para salvar dados e resultados, isso é explicado no pŕoximo item
 
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).

Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]

O caminho de montagem dentro do container é opcional e se for omitido, é usado o mesmo caminho do host, porém o usuário deve ter permissão para acessar a pasta de montagem. No exemplo mostra como deixar o path /homeLocal/fulano acessível dentro do container em /mnt:
singularity shell --bind /homeLocal/fulano:/mnt my_container/

Também é possivel combinar as opções do --bind com --writable --no-home, neste caso, o root precisa ter permissão para acessar a pasta de montagem:
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/

* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====

Depois de pronta, a máquina container, pode ser convertida do formato "pasta sandbox" para o formato de <code>.sif</code>) isso permite que ela execute mais rápido, reduz o espaço em disco.

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>.sif</code>'''. [https://sylabs.io/guides/3.9/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:
sudo singularity build [container_destino] [container_origem]
sudo singularity build my_container-compact.sif my_container/
 

== Limitar recursos do container (RAM, Core's, network e etc) ==

É possível criar um arquivo '''cgroups.toml''' e limitar (ou medir) recursos usados pelo container. Por exemplo, limitar o uso de RAM para não esgotar os recursos da máquina host.

Segue o texto original e os links com mais informações:

''The cgroups (control groups) functionality of the Linux kernel allows you to limit and meter the resources used by a process, or group of processes. Using cgroups you can limit memory and CPU usage. You can also rate limit block IO, network IO, and control access to device nodes.''

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html
 

== Docker Hub: Usar repositório de 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:

sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1
 

== PIP: Python Package Installer ==
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>
 

== Links dos Comandos Básicos ==
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images

* <code>[https://sylabs.io/guides/3.9/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/3.9/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/3.9/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/3.9/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/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

== <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:

sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest

* Exemplo singularity sandbox usando um repositório qualquer do dockerhub
sudo singularity build --sandbox my_container/ docker://repository_name:tag
 
==== outros exemplos menos usados, pois criam container's não editável ====
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:
sudo singularity build my_ubuntu.sif my_container/
 

== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==

* Executar a máquina container no shell, sem salvar modificações feitas na sessão:
singularity shell my_container/
singularity shell my_ubuntu.sif/
 

== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==

* Só é possivel alterar um container em formato <code>sandbox</code>, uma boa prática é adicionar a opção --no-home é importante para não ocorrer a montagem automática da /home do root, e evitar que instaladores tentem usar essa pasta para instalação de pacotes.
sudo singularity shell --writable --no-home my_container/
 

== <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 ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras também ] ), 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:/mnt my_container/</code>

Singularity3

2023-10-02T18:43:04Z

Analucia: /* 4) Corrigir o ownership da sua "pasta sandbox" */

= Singularity CE 3.x (Community Edition) =
=== '''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022, atualmente instalado nas máquinas a v3.10.x''' ===

==== Documentação oficial Singularity CE v3.x ====
* https://www.sylabs.io/docs/
* '''User Guide CE v3.10.x '''
** https://docs.sylabs.io/guides/3.10/user-guide/
** https://docs.sylabs.io/guides/3.10/user-guide/quick_start.html
* '''Adm Guide CE v3.10.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'')
** https://docs.sylabs.io/guides/3.10/admin-guide/
* ''' ''Definition Files'' '''
** https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile
 

== IMPORTANTE: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==

==== '''Pasta <code>sandbox</code>''': INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes) ====
* Destinado para desenvolvimento interativo do container, quando ainda precisa fazer testes e não se sabe exatamente as configurações/ferramentas a serem usadas, logo o container pode ter novas instalações e alterações nos pacotes.
* Vantagem: vários arquivos e sub-pastas que são expansíveis automaticamente conforme os pacotes são instalados (opção --writable). O tamanho do disco é expansível conforme disponibilidade de espaço em disco da máquina host.
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)
 
==== '''Arquivo único, extensão <code>.sif</code>''': SOMENTE LEITURA, NÃO é possível editar o container ====
* Destinado para fase de experimentos em massa (production)
* Vantagem: É uma imagem comprimida, ocupa menos espaço em disco e executa mais rápido que um container equivalente no formato sandbox. Também suporta criptografia
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.
* compressed read-only Singularity Image File (SIF) format suitable for production (default)
 

== Passo a Passo: Uso do Singularity CE v3.x ==
 
Exemplos de interação mais usuais com o container singularity

# Confirmar se a máquina tem singularity instalado e a versão
# Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)
# Criar seu container Singularity no formato "pasta sandbox"
# Corrigir o ownership da sua "pasta sandbox"
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)
# Usar o shell em modo "somente leitura" para testar
# Usar o shell e montar uma pasta do host
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)
 

==== 1) Conferir se a máquina tem singularity instalado e a versão ====
singularity --version
 

==== 2) Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====
Deve-se solicitar a um gestor da infraestrutura da rede VeRLab/JLab para criar uma pasta com seu nome de usuário e mudar o proprietário da pasta para seu usuário da rede do Verlab e o grupo DomainUsers (<code>gid=513</code>).

Existem duas opções de locais para armazenar sua pasta de containers singularity:
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code>

Pasta no serviço de storage:
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
cd /srv/forge
mkdir fulano
chown -Rv fulano:513 fulano/
cd /srv/forge/fulano

Pasta no /homeLocal de alguma máquina:
cd /homeLocal
mkdir fulano
chown -Rv fulano:513 fulano/
cd /homeLocal/fulano
 

==== 3) Criar seu container Singularity no formato "pasta sandbox" ====

O formato sandbox é usado para modificar e instalar pacotes no container

sudo singularity build --sandbox [pasta_destino] [container_origem]

* A base usada na construção do container pode ter várias fontes diferentes online ou local:
** '''URI docker''':// container do repositório online no ''Docker Hub'' ([https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3#Docker_Hub:_Usar_reposit.C3.B3rio_de_M.C3.A1quinas_Container_Prontas.21 Mais dicas sobre usar URI Docker Hub])
** '''URI library''':// container do repositório online no ''Sylab Container Library''
** URI shub:// container do repositório online no ''Singularity Hub''
** ''' caminho para um outro container .sif ''' numa pasta local na própria máquina host
** '''caminho para um outro container em pasta ''sandbox'' ''' na própria máquina host
** '''caminho para um ''definition file'' '''no formato Singularity CE

* Alguns exemplos:

Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04

Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye
 

==== 4) Corrigir o ownership da sua "pasta sandbox" ====

Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root
'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership para seu_usuario:DomainUsers'''

a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:
id nome_usuario

b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)
sudo chown -Rv [uid]:513 pasta_sandbox/
 

==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====

Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.

Também é indicado usar a opção --no-home para não montar a /home/root da máquina host e evitar que os instaladores tentem salvar algo na home da máquina host.
( Link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )

Se o instalador tentar usar a /home/root, deve-se ler a documentação do instalador para optar por pastas alternativas dentro da estrutura do container como /usr/bin, /usr/local, /opt/
sudo singularity shell --writable --no-home my_container/

* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container e abrir em modo edição.
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 

==== 6) Usar o shell em modo "somente leitura" para testar ====
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:
singularity shell my_container/
Em geral, nesse momento também é necessário montar uma pasta externa ao container para salvar dados e resultados, isso é explicado no pŕoximo item
 
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).

Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]

O caminho de montagem dentro do container é opcional e se for omitido, é usado o mesmo caminho do host, porém o usuário deve ter permissão para acessar a pasta de montagem. No exemplo mostra como deixar o path /homeLocal/fulano acessível dentro do container em /mnt:
singularity shell --bind /homeLocal/fulano:/mnt my_container/

Também é possivel combinar as opções do --bind com --writable --no-home, neste caso, o root precisa ter permissão para acessar a pasta de montagem:
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/

* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====

Depois de pronta, a máquina container, pode ser convertida do formato "pasta sandbox" para o formato de <code>.sif</code>) isso permite que ela execute mais rápido, reduz o espaço em disco.

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>.sif</code>'''. [https://sylabs.io/guides/3.9/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:
sudo singularity build [container_destino] [container_origem]
sudo singularity build my_container-compact.sif my_container/
 

== Limitar recursos do container (RAM, Core's, network e etc) ==

É possível criar um arquivo '''cgroups.toml''' e limitar (ou medir) recursos usados pelo container. Por exemplo, limitar o uso de RAM para não esgotar os recursos da máquina host.

Segue o texto original e os links com mais informações:

''The cgroups (control groups) functionality of the Linux kernel allows you to limit and meter the resources used by a process, or group of processes. Using cgroups you can limit memory and CPU usage. You can also rate limit block IO, network IO, and control access to device nodes.''

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml

* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html
 

== Docker Hub: Usar repositório de 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:

sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1
 

== PIP: Python Package Installer ==
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>
 

== Links dos Comandos Básicos ==
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images

* <code>[https://sylabs.io/guides/3.9/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/3.9/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/3.9/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/3.9/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/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])
 

== <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:

sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest

* Exemplo singularity sandbox usando um repositório qualquer do dockerhub
sudo singularity build --sandbox my_container/ docker://repository_name:tag
 
==== outros exemplos menos usados, pois criam container's não editável ====
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub:
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest

* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:
sudo singularity build my_ubuntu.sif my_container/
 

== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==

* Executar a máquina container no shell, sem salvar modificações feitas na sessão:
singularity shell my_container/
singularity shell my_ubuntu.sif/
 

== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==

* Só é possivel alterar um container em formato <code>sandbox</code>, uma boa prática é adicionar a opção --no-home é importante para não ocorrer a montagem automática da /home do root, e evitar que instaladores tentem usar essa pasta para instalação de pacotes.
sudo singularity shell --writable --no-home my_container/
 

== <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 ([https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras também ] ), 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:/mnt my_container/</code>