VeRLab Wiki - User contributions [en]

Trabalhando remotamente

2022-11-23T22:10:19Z

Flavioro: Versão inicial da página

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 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.]]

File:Screenshot-files-mostrando-sftp-para-marvin.png

2022-11-23T22:09:04Z

Flavioro: Screenshot do Gnome Files mostrando a aba "+ Outros Locais" conectada à máquina marvin do laboratório, permitindo transmissão de arquivos.

Screenshot do Gnome Files mostrando a aba "+ Outros Locais" conectada à máquina marvin do laboratório, permitindo transmissão de arquivos.

File:Screenshot-from-gnome-files.png

2022-11-23T21:37:39Z

Flavioro: 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).

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).

Main Page

2022-11-23T21:10:47Z

Flavioro: /* Seja bem vindo a Wiki do VeRLab (Computer Vision and Robotics Laboratory - DCC - UFMG) */

== Seja bem vindo a Wiki do VeRLab (Computer Vision and Robotics Laboratory - DCC - UFMG) ==

=== [[Regras de Conduta e Termo de Compromisso]] ===
=== [[Como rodar seu experimento]] ===
=== [[Trabalhando remotamente]] (página em construção) ===
=== [[Dicas para escrever e apresentar sua publicação]] ===
=== [http://www.verlab.dcc.ufmg.br/mediawiki/index.php/Special:AllPages Relação de todas as páginas dessa wiki] ===

== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Robot Robôs] ==

==== Small size Robots ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Main_Page/e-puck E-puck]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/HeRo HeRo]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Espcopter Espcopter]

==== Mobile Robots ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Roomba Roomba]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kobuki Kobuki]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pioneer Pioneer - ActivMedia Robotics]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jackal Jackal - Clearpath Robotics]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Tamiya Tamiya TXT-1]

==== Robot Arm ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kinova_Gen3_Ultra Gen3 Ultra lightweight robot arm - KINOVA]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Fenrir_Arm Fenrir]

==== Multirotor ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ARdrone Parrot AR.Drone 2.0]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hummingbird AscTec Hummingbird]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pelican AscTec Pelican]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Iris 3DR IRIS+]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/X8 3DR X8+]

==== Fixed-Wing ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Aero 3DR Aero]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/E384 Drone E384]

== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sensor Sensores] ==
==== Laser ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Laser_Hokuyo Hokuyo]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/LaserVelodyne Velodyne]

==== IMU (unidades inerciais, acelerômetro, magnetometro, barômetro e etc ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/IMU IMUs]

==== Câmeras ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Camera_360 Camera 360]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GoPro GoPro]
* TODO Real Sense (RGBD)
* TODO Kinect One (Xbox One)
* TODO Kinect v2 (Xbox 360)
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Asus_Xtion_PRO Asus Xtion PRO]

==== Realidade Virtual e Aumentada ====
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hololens HoloLens]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Oculus_Rift Oculus Rift]

== Atuadores ==
* Dynamixel AX-12
* Dynamixel MX-64AT
* TODO Motor Servo
* TODO Interface Haptica
*

== Placas Controladoras e Sensor Nodes ==
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Arduino Arduino]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP32 ESP32]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP8266 ESP8266]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/RaspberryPi Raspberry Pi]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jetson_Nano Jetson nano - Nvidia]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/mote Sensor Nodes]

== Softwares ==
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity Singularity]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ROS ROS - Robot Operacional System]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Virtualenv Python Virtual Enviroment]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GitHub_do_Verlab GitHub do Verlab]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Windows S.O. Windows]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Linux S.O. Linux]

== Equipamentos de Pesquisa ==
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Impressora3D Impressora 3D]

== Equipamentos de Informática ==
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Cabo_de_Rede Montagem de Cabos de Rede]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Impressoras Impressoras]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/NoBreak No Break]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/HD Teste HD - smartctl]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/RotuladorPT80 Rotuladora PT80]
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/PastaTermica Aplicação e Escolha de Pasta Térmica]

== Ferramentas ==
* TODO
* [http://www.crvindustrial.com/blog/como-medir-parafusos-corretamente como medir parafusos]

Singularity3

2022-11-21T14:43:15Z

Flavioro: /* 2) Criar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) */

= Singularity CE 3.x (Community Edition) =
=== '''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022''' ===

==== Documentação oficial Singularity v3.x ====
* '''User Guide CE v3.9.x'''
** https://www.sylabs.io/docs/
* '''User Guide CE v3.9.x '''
** https://sylabs.io/guides/3.9/user-guide/
** https://sylabs.io/guides/3.9/user-guide/quick_start.html
* '''Adm Guide CE v3.9.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'')
** https://sylabs.io/guides/3.9/admin-guide/
* ''' ''Definition Files'' '''
** https://sylabs.io/guides/3.9/user-guide/definition_files.html#definition-files
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples
* '''Exemplos de container prontos na ''Sylabs Cloud Library'' '''
** https://cloud.sylabs.io/library/sylabs/examples
 

== 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(singularity 2.x) e GHOST(singularity 3.x)''' 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 administrador da rede alterar o onweership 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 e GHOST''' 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://sylabs.io/guides/3.9/admin-guide/configfiles.html#cgroups-toml

* https://sylabs.io/guides/3.9/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>