http://www.verlab.dcc.ufmg.br/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=OthiagoVeRLab Wiki - User contributions [en]2026-04-03T19:11:00ZUser contributionsMediaWiki 1.29.0http://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity3&diff=1327Singularity32024-06-08T15:59:23Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 3.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022, atualmente instalado nas máquinas a v3.10.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v3.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v3.10.x ''' =====<br />
* https://docs.sylabs.io/guides/3.10/user-guide/<br />
* https://docs.sylabs.io/guides/3.10/user-guide/quick_start.html<br />
===== '''Adm Guide CE v3.10.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v3.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Corrigir o ownership da sua "pasta sandbox"<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu22-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/3.10/user-guide/build_a_container.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu22-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 4) Corrigir o ownership da sua "pasta sandbox" ====<br />
<br />
Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root<br />
<br />
'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership da pasta para seu_usuario:DomainUsers''' <br />
<br />
a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:<br />
id nome_usuario<br />
<br />
<br />
b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)<br />
sudo chown -Rv [uid]:513 pasta_sandbox/<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( 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] )<br />
<br />
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/<br />
sudo singularity shell --writable --no-home my_container/<br />
<br />
* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
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] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity3&diff=1326Singularity32024-06-08T15:59:04Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 3.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de mar/2022, atualmente instalado nas máquinas a v3.10.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v3.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v3.10.x ''' =====<br />
* https://docs.sylabs.io/guides/3.10/user-guide/<br />
* https://docs.sylabs.io/guides/3.10/user-guide/quick_start.html<br />
===== '''Adm Guide CE v3.10.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v3.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Corrigir o ownership da sua "pasta sandbox"<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 22.04 e instala os pacotes para executar o cuda:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu22-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu22-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/3.10/user-guide/build_a_container.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu22-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 4) Corrigir o ownership da sua "pasta sandbox" ====<br />
<br />
Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root<br />
<br />
'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership da pasta para seu_usuario:DomainUsers''' <br />
<br />
a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:<br />
id nome_usuario<br />
<br />
<br />
b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)<br />
sudo chown -Rv [uid]:513 pasta_sandbox/<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( 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] )<br />
<br />
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/<br />
sudo singularity shell --writable --no-home my_container/<br />
<br />
* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
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] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1325Singularity42024-06-08T15:58:23Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
</pre><br />
Para criar seu container <br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no <code>%environment</code> durante a edição da pasta sandbox, basta editar o arquivo <code>90-environment.sh</code> localizado em <code>/.singularity.d/env/</code> dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1324Singularity42024-06-08T15:56:36Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
</pre><br />
Para criar seu container <br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no <code>%environment</code> durante a edição da pasta sandbox, basta editar o arquivo <code>90-environment.sh</code> localizado em <code>/.singularity.d/env/</code> dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1323Singularity42024-06-08T15:55:01Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
</pre><br />
To build the container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no <code>%environment</code> durante a edição da pasta sandbox, basta editar o arquivo <code>90-environment.sh</code> localizado em <code>/.singularity.d/env</code> dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1322Singularity42024-06-08T15:54:05Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
</pre><br />
To build the container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no <code>%environment<\code> durante a edição da pasta sandbox, basta editar o arquivo <code>90-environment.sh<\code> localizado em <code>/.singularity.d/env<\code> dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1321Singularity42024-06-08T15:52:42Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
</pre><br />
# To build the container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
<br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no `%environment` durante a edição da pasta sandbox, basta editar o arquivo 90-environment.sh localizado em /.singularity.d/env dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1320Singularity42024-06-08T15:51:34Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
|}<br />
Caso precise adicionar ou remover variáveis no `%environment` durante a edição da pasta sandbox, basta editar o arquivo 90-environment.sh localizado em /.singularity.d/env dentro do container sandbox.<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1319Singularity42024-06-08T15:50:47Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
Caso precise adicionar ou remover variáveis no `%environment` durante a edição da pasta sandbox, basta editar o arquivo 90-environment.sh localizado em /.singularity.d/env dentro do container sandbox.<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1318Singularity42024-06-08T14:01:10Z<p>Othiago: /* 3) Escrever a "receita" (definition file) do seu container Singularity */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu20-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1317Singularity42024-06-08T14:00:23Z<p>Othiago: /* Uso simplificado: NÃO É MAIS NECESSÁRIO USAR O COMANDO sudo PARA UTILIZAR O SINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1316Singularity42024-06-08T14:00:14Z<p>Othiago: /* Uso simplificado: NÃO É MAIS NECESSÁRIO USAR O COMANDO sudo PARA UTILIZAR O SINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização.<br />
Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1315Singularity42024-06-08T13:59:29Z<p>Othiago: /* Uso simplificado: NÃO É MAIS NECESSÁRIO USAR O COMANDO sudo PARA UTILIZAR O SINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1314Singularity42024-06-08T13:59:12Z<p>Othiago: /* A utilização ficou mais simples: NÃO É PRECISO USAR MAIS O COMANDO sudo QUANDO FOR USAR OSINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''Uso simplificado''': <span style="color: red;">NÃO É MAIS NECESSÁRIO USAR O COMANDO <code>sudo</code> PARA UTILIZAR O SINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity&diff=1313Singularity2024-06-08T13:56:10Z<p>Othiago: /* Versão em uso no VeRLab/JLab */</p>
<hr />
<div>== Singularity ==<br />
<br />
<br />
O '''Singularity''' é uma ferramenta para a criação de ''"máquina container"'' (uma espécie de ''"máquina virtual"'') que trás algumas vantagens, quando for rodar experimentos nas máquinas de processamento do Verlab/J:<br />
<br />
* Não precisa ser usuário com privilégios root para executar sua ''máquina container'' (apenas para criar) e pode instalar suas dependências de experimento no container sem alterar a ''máquina host''. Isso evita mudanças e instalação de pacotes nas máquinas de processamento e que podem atrapalham experimentos de outros usuários.<br />
<br />
* Depois de criar sua ''máquina container'' com todas suas dependências, pode-se usá-la para rodar experimento em diferentes máquinas host que tenham GPU. Isso trás flexibilidade para rodar experimento em máquinas simultaneamente, sem precisar instalar todas dependências novamente em outra ''máquina host''.<br />
<br />
* A massa de arquivos de dataset (que geralmente ocupam espaço >=500GB) ficam localmente armazenados na máquina host, assim evita tráfego desnecessário na rede. Geralmente na pasta /homeLocal/nome_do_usuario.<br />
<br />
* O usuário deixa na sua pasta home da rede apenas sua máquina container em formato de imagem (que em geral ocupa ~4GB) assim quando logar em qualquer máquina de processamento a mesma estará disponível para rodar seu experimento.<br />
<br />
* Dataset's e containers podem ser armazenados no serviço de storage da rede, assim ficam disponíveis em qualquer máquina de processamento para rodar seu experimento. Geralmente na pasta /srv/storage/datasets/nome_do_usuario e /srv/storage/singularity/images/nome_do_usuario.<br />
<br> <br> <br><br />
<br />
== Versão em uso no VeRLab/JLab ==<br />
<br />
Atualmente temos a versão 4.1.x instalada nas máquinas da rede VeRLab/JLab. <br />
<br />
=== '''Singularity CE v4.x''' ( ''Community Edition'', ''freeware'', versão em todas as máquinas a partir de jun/2024) ===<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity4 Link para dicas de uso do Singularity CE v4.x]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3 Link para dicas de uso do Singularity CE v3.x]<br />
<br />
<br />
A versão 2.5.x já foi utilizada, mas seu suporte parou em jul/2018 e foi descontinuada na rede VeRLab/Jlab desde mar/2022.<br />
<!-- Comentado<br />
* '''Singularity v2.5.x''' (''freeware'', <span style="color: red;">versão sem suporte desde jul/2018, vai ser descontinuada na rede VeRLab/JLab</span>)<br />
**[https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity2 Link para dicas de uso do Singularity v2.5.x]<br />
--><br />
<br> <br> <br><br />
<br />
== Regras de bom uso dos recursos ==<br />
* Arquivos mais importantes e pequenos, como códigos, documentos e resultados finais, devem ser mantidos na home do usuário.<br />
** '''Obs:''' Usuários '''não''' devem deixar o datasets e arquivos temporários de processamento dentro da sua pasta '''home'''. Os datasets são muitos arquivos que vão ser acessados durante o experimento e que seu tamanho total, em geral, é >=500GB. Pois isso aumenta o tráfego na rede desnecessáriamente. <br />
<br />
<br />
* Massa de dados e arquivos maiores, tais como datasets, dados pre-processados e resultados parciais, devem ser armazenados em locais de uso comum dentro de uma pasta com o "nome do usuário" ou "nome do projeto" (no caso de um grupo de trabalho maior que tem um aluno sênior coordenando).<br />
<br />
<br />
* Temos as seguintes opções de pastas de uso comum para massa de dados:<br />
**<code>/homeLocal/</code> : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.<br />
**<code>/srv/storage/datasets</code>) : pasta no servidor de storage para armazenar datasets<br />
**<code>/srv/storage/singularity/images/</code> : pasta no servidor de storage para armazenar as imagens singularity fechadas (<code>.sif</code>) que são executadas nos experimentos.<br />
**<code>/srv/storage/singularity/forge/</code> : pasta no servidor de storage para criação de imagens singularity em modo sandbox (evitar deixar as imagens em sandbox, mais detalhes abaixo)<br />
*** 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 com '''<code> $sudo singularity shell --writable... </code>'''. <br />
*** Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br />
<br />
* Cada usuário deve criar uma pasta com seu "nome de usuário" (ou "nome de projeto" se for o caso) dentro da pasta de uso comum para conter seus arquivos. Assim fica organizado e facilita identificar quem são os donos dos containers ou datasets. Exemplos para o nome de usuário "fulano":<br />
** '''O usuário é responsável por liberar o espaço em disco quando não estiver mais precisando do mesmo ou fazendo testes'''<br />
**<code>/homeLocal/fulano</code> :<br />
**<code>/srv/storage/datasets/fulano</code><br />
**<code>/srv/storage/singularity/forge/fulano</code><br />
**<code>/srv/storage/singularity/images/fulano</code><br />
<br />
<br />
* A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (<code>.sif</code>. <br />
** Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".<br />
** Pedimos que não mantenham muitas imagens singularity em modo sandbox. Sempre que possível, feche sua imagem (converter para <code>.sif</code> e de preferência coloque-as na pasta storage/singularity/images.<br />
** '''Obs:''' Imagens em modo sandbox deixam uma quantidade enorme de arquivos, e como o servidor de storage tem que mapear todos os arquivos na memória RAM, e às vezes a mesma estoura por esse motivo.<br />
<br />
<br> <br> <br><br />
<br />
== Instalação ==<br />
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. <br />
<br />
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 [https://www.verlab.dcc.ufmg.br/restrict-area/ área restrita] do site do verlab:<br />
<br />
=== Estações de trabalho Desktop no Verlab/J com GPU Nvidia ===<br />
* Instalar o Singularity em toda máquina host com GPU (máquina de processamento)<br />
* Criar a pasta <code>/homeLocal</code> em toda máquina host. <br />
** O usuário precisa solicitar à equipe de rede para criar uma pasta filha na <code>/homeLocal/nome_do_usuario</code> e dar permissão de leitura/escrita. Assim, para casos específicos é possível criar e modificarem máquinas container localmente, sem usar o serviço de storage.<br />
* Configurar o comando <code> $sudo singularity ... </code> de modo que todo usuário possa rodá-lo dentro da pasta <code>/homeLocal</code>, sem necessitar de senha root<br />
<br />
=== Servidores de Processamento da rede Verlab/J com GPU Nvidia ===<br />
* Configurar montagem automática das pastas na rede:<br />
**<code>/srv/forge</code> (apenas '''EPONA, GHOST e MAGRITTE''')<br />
**<code>/srv/storage/datasets</code><br />
**<code>/srv/storage/singularity/images/</code><br />
**<code>/srv/storage/singularity/forge/</code><br />
<br />
* 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 com '''<code> $sudo singularity shell --writable... </code>'''. <br />
* Uma segunda restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* Configurar a montagem da pasta <code>/srv/forge</code> nas máquinas EPONA, GHOST e MAGRITTE e configurar a montagem das mesmas para que o comando <code> $sudo singularity ... </code> possa ser executado por qualquer usuário, sem necessitar de permissão root<br />
* Para executar o container em modo leitura ('''<code>$singularity shell...</code>'''), a pasta <code>/srv/forge</code> é espelhada nas demais máquinas:<br />
**<code>/srv/storage/singularity/forge$</code><br />
<br />
== Dicas de Uso ==<br />
<br />
O uso do Singularity é direto ao ponto em muitos sentidos. Isso se deve ao fato de que, para utilizar os recursos da GPU, o container Singularity faz um linking com o driver da máquina host, o que já disponibiliza, para o container, a mesma versão do driver e do CUDA que já estão instalados na máquina host.<br />
A principal vantagem dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.<br />
<br />
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!<br />
<br />
A versão de CUDA instalada dentro do container é totalmente independente da versão instalada na máquina host, o que significa que é possível rodar uma versão do CUDA no container que é diferente da versão instalada na máquina host. Mas é importante prestar atenção que a versão do driver do container será sempre igual à versão do driver na máquina host, pois é feito um link do container para o host, e isso não pode ser mudado. Por conta disso, pode ser que a versão do driver atual não suporte todas as versões do CUDA. Para ver quais versões são suportadas, é importante se atentar a quais<br />
versões do CUDA a versão do driver atual suporta. Isso pode ser verificado em https://docs.nvidia.com/deploy/cuda-compatibility/index.html.<br />
<br />
A versão instalada do driver pode ser obtida rodando <code>nvidia-smi</code> dentro da máquina host.</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity&diff=1312Singularity2024-06-08T13:55:22Z<p>Othiago: /* Singularity CE v3.x ( Community Edition, freeware, versão em todas as máquinas a partir de mar/2022) */</p>
<hr />
<div>== Singularity ==<br />
<br />
<br />
O '''Singularity''' é uma ferramenta para a criação de ''"máquina container"'' (uma espécie de ''"máquina virtual"'') que trás algumas vantagens, quando for rodar experimentos nas máquinas de processamento do Verlab/J:<br />
<br />
* Não precisa ser usuário com privilégios root para executar sua ''máquina container'' (apenas para criar) e pode instalar suas dependências de experimento no container sem alterar a ''máquina host''. Isso evita mudanças e instalação de pacotes nas máquinas de processamento e que podem atrapalham experimentos de outros usuários.<br />
<br />
* Depois de criar sua ''máquina container'' com todas suas dependências, pode-se usá-la para rodar experimento em diferentes máquinas host que tenham GPU. Isso trás flexibilidade para rodar experimento em máquinas simultaneamente, sem precisar instalar todas dependências novamente em outra ''máquina host''.<br />
<br />
* A massa de arquivos de dataset (que geralmente ocupam espaço >=500GB) ficam localmente armazenados na máquina host, assim evita tráfego desnecessário na rede. Geralmente na pasta /homeLocal/nome_do_usuario.<br />
<br />
* O usuário deixa na sua pasta home da rede apenas sua máquina container em formato de imagem (que em geral ocupa ~4GB) assim quando logar em qualquer máquina de processamento a mesma estará disponível para rodar seu experimento.<br />
<br />
* Dataset's e containers podem ser armazenados no serviço de storage da rede, assim ficam disponíveis em qualquer máquina de processamento para rodar seu experimento. Geralmente na pasta /srv/storage/datasets/nome_do_usuario e /srv/storage/singularity/images/nome_do_usuario.<br />
<br> <br> <br><br />
<br />
== Versão em uso no VeRLab/JLab ==<br />
<br />
Atualmente temos a versão 3.10.x instalada nas máquinas da rede VeRLab/JLab. <br />
<br />
=== '''Singularity CE v4.x''' ( ''Community Edition'', ''freeware'', versão em todas as máquinas a partir de jun/2024) ===<br />
** [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity4 Link para dicas de uso do Singularity CE v4.x]<br />
** [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3 Link para dicas de uso do Singularity CE v3.x]<br />
<br />
<br />
A versão 2.5.x já foi utilizada, mas seu suporte parou em jul/2018 e foi descontinuada na rede VeRLab/Jlab desde mar/2022.<br />
<!-- Comentado<br />
* '''Singularity v2.5.x''' (''freeware'', <span style="color: red;">versão sem suporte desde jul/2018, vai ser descontinuada na rede VeRLab/JLab</span>)<br />
**[https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity2 Link para dicas de uso do Singularity v2.5.x]<br />
--><br />
<br> <br> <br><br />
<br />
== Regras de bom uso dos recursos ==<br />
* Arquivos mais importantes e pequenos, como códigos, documentos e resultados finais, devem ser mantidos na home do usuário.<br />
** '''Obs:''' Usuários '''não''' devem deixar o datasets e arquivos temporários de processamento dentro da sua pasta '''home'''. Os datasets são muitos arquivos que vão ser acessados durante o experimento e que seu tamanho total, em geral, é >=500GB. Pois isso aumenta o tráfego na rede desnecessáriamente. <br />
<br />
<br />
* Massa de dados e arquivos maiores, tais como datasets, dados pre-processados e resultados parciais, devem ser armazenados em locais de uso comum dentro de uma pasta com o "nome do usuário" ou "nome do projeto" (no caso de um grupo de trabalho maior que tem um aluno sênior coordenando).<br />
<br />
<br />
* Temos as seguintes opções de pastas de uso comum para massa de dados:<br />
**<code>/homeLocal/</code> : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.<br />
**<code>/srv/storage/datasets</code>) : pasta no servidor de storage para armazenar datasets<br />
**<code>/srv/storage/singularity/images/</code> : pasta no servidor de storage para armazenar as imagens singularity fechadas (<code>.sif</code>) que são executadas nos experimentos.<br />
**<code>/srv/storage/singularity/forge/</code> : pasta no servidor de storage para criação de imagens singularity em modo sandbox (evitar deixar as imagens em sandbox, mais detalhes abaixo)<br />
*** 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 com '''<code> $sudo singularity shell --writable... </code>'''. <br />
*** Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br />
<br />
* Cada usuário deve criar uma pasta com seu "nome de usuário" (ou "nome de projeto" se for o caso) dentro da pasta de uso comum para conter seus arquivos. Assim fica organizado e facilita identificar quem são os donos dos containers ou datasets. Exemplos para o nome de usuário "fulano":<br />
** '''O usuário é responsável por liberar o espaço em disco quando não estiver mais precisando do mesmo ou fazendo testes'''<br />
**<code>/homeLocal/fulano</code> :<br />
**<code>/srv/storage/datasets/fulano</code><br />
**<code>/srv/storage/singularity/forge/fulano</code><br />
**<code>/srv/storage/singularity/images/fulano</code><br />
<br />
<br />
* A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (<code>.sif</code>. <br />
** Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".<br />
** Pedimos que não mantenham muitas imagens singularity em modo sandbox. Sempre que possível, feche sua imagem (converter para <code>.sif</code> e de preferência coloque-as na pasta storage/singularity/images.<br />
** '''Obs:''' Imagens em modo sandbox deixam uma quantidade enorme de arquivos, e como o servidor de storage tem que mapear todos os arquivos na memória RAM, e às vezes a mesma estoura por esse motivo.<br />
<br />
<br> <br> <br><br />
<br />
== Instalação ==<br />
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. <br />
<br />
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 [https://www.verlab.dcc.ufmg.br/restrict-area/ área restrita] do site do verlab:<br />
<br />
=== Estações de trabalho Desktop no Verlab/J com GPU Nvidia ===<br />
* Instalar o Singularity em toda máquina host com GPU (máquina de processamento)<br />
* Criar a pasta <code>/homeLocal</code> em toda máquina host. <br />
** O usuário precisa solicitar à equipe de rede para criar uma pasta filha na <code>/homeLocal/nome_do_usuario</code> e dar permissão de leitura/escrita. Assim, para casos específicos é possível criar e modificarem máquinas container localmente, sem usar o serviço de storage.<br />
* Configurar o comando <code> $sudo singularity ... </code> de modo que todo usuário possa rodá-lo dentro da pasta <code>/homeLocal</code>, sem necessitar de senha root<br />
<br />
=== Servidores de Processamento da rede Verlab/J com GPU Nvidia ===<br />
* Configurar montagem automática das pastas na rede:<br />
**<code>/srv/forge</code> (apenas '''EPONA, GHOST e MAGRITTE''')<br />
**<code>/srv/storage/datasets</code><br />
**<code>/srv/storage/singularity/images/</code><br />
**<code>/srv/storage/singularity/forge/</code><br />
<br />
* 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 com '''<code> $sudo singularity shell --writable... </code>'''. <br />
* Uma segunda restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* Configurar a montagem da pasta <code>/srv/forge</code> nas máquinas EPONA, GHOST e MAGRITTE e configurar a montagem das mesmas para que o comando <code> $sudo singularity ... </code> possa ser executado por qualquer usuário, sem necessitar de permissão root<br />
* Para executar o container em modo leitura ('''<code>$singularity shell...</code>'''), a pasta <code>/srv/forge</code> é espelhada nas demais máquinas:<br />
**<code>/srv/storage/singularity/forge$</code><br />
<br />
== Dicas de Uso ==<br />
<br />
O uso do Singularity é direto ao ponto em muitos sentidos. Isso se deve ao fato de que, para utilizar os recursos da GPU, o container Singularity faz um linking com o driver da máquina host, o que já disponibiliza, para o container, a mesma versão do driver e do CUDA que já estão instalados na máquina host.<br />
A principal vantagem dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.<br />
<br />
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!<br />
<br />
A versão de CUDA instalada dentro do container é totalmente independente da versão instalada na máquina host, o que significa que é possível rodar uma versão do CUDA no container que é diferente da versão instalada na máquina host. Mas é importante prestar atenção que a versão do driver do container será sempre igual à versão do driver na máquina host, pois é feito um link do container para o host, e isso não pode ser mudado. Por conta disso, pode ser que a versão do driver atual não suporte todas as versões do CUDA. Para ver quais versões são suportadas, é importante se atentar a quais<br />
versões do CUDA a versão do driver atual suporta. Isso pode ser verificado em https://docs.nvidia.com/deploy/cuda-compatibility/index.html.<br />
<br />
A versão instalada do driver pode ser obtida rodando <code>nvidia-smi</code> dentro da máquina host.</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1311Singularity42024-06-08T13:51:08Z<p>Othiago: /* A utilização ficou mais simples: NÃO É PRECISO USAR MAIS O COMANDO sudo QUANDO FOR USAR OSINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real, [https://docs.sylabs.io/guides/4.1/user-guide/fakeroot.html#fakeroot veja na documentação].<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1310Singularity42024-06-08T13:46:55Z<p>Othiago: /* Passo a Passo: Uso do Singularity CE v4.1.x */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1309Singularity42024-06-08T13:46:40Z<p>Othiago: /* IMPORTANTE: Diferença entre os 2 formatos suportados pelo singularity build: */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1308Singularity42024-06-08T13:46:04Z<p>Othiago: /* Passo a Passo: Uso do Singularity CE v4.1.x */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1307Singularity42024-06-08T13:45:53Z<p>Othiago: /* Passo a Passo: Uso do Singularity CE v4.1.x */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1306Singularity42024-06-08T13:45:35Z<p>Othiago: /* A utilização ficou mais simples: NÃO É PRECISO USAR MAIS O COMANDO sudo QUANDO FOR USAR OSINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1305Singularity42024-06-08T13:45:08Z<p>Othiago: /* A utilização ficou mais simples: NÃO É PRECISO USAR MAIS O COMANDO sudo QUANDO FOR USAR OSINGULARITY */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br />
singularity --version<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1304Singularity42024-06-08T13:40:00Z<p>Othiago: /* IMPORTANTE: Diferença entre os 2 formatos suportados pelo singularity build: */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR OSINGULARITY</span> ====<br />
Com a introdução do Singularity 4.1.x, alguns comandos agora requerem o uso da flag <code>--fakeroot</code>. Esta flag permite que usuários comuns possam construir e modificar containers sem a necessidade de privilégios de superusuário, simplificando a utilização. Ao utilizar <code>--fakeroot</code>, o Singularity simula um ambiente root, permitindo operações que normalmente precisariam de acesso root real.<br />
<br />
Exemplo de comando com <code>--fakeroot</code>:<br />
<br />
singularity build --sandbox --fakeroot --fix-perms my-def-v1 my-def-v1.def<br />
Este comando constrói um container no formato sandbox usando um arquivo de definição, sem precisar de privilégios de superusuário.<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1303Singularity42024-06-08T13:34:57Z<p>Othiago: /* IMPORTANTE: Diferença entre os 2 formatos suportados pelo singularity build: */</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
==== '''A utilização ficou mais simples''': <span style="color: red;">NÃO É PRECISO USAR MAIS O COMANDO <code>sudo</code> QUANDO FOR USAR ALGUM COMANDO COM SINGULARITY</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1302Singularity42024-06-08T13:25:43Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 4) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1301Singularity42024-06-08T13:20:25Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
singularity build --sandbox --fakeroot --fix-perms [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
singularity build --sandbox --fakeroot --fix-perms ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1300Singularity42024-06-08T13:18:41Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
A pasta do home do usuário é montada automaticamente pelo singularity dentro da máquina container ([https://docs.sylabs.io/guides/4.1/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://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1299Singularity42024-06-08T13:12:58Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#interact-with-images<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container<br />
<br />
* <code> [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a imagem da máquina container e permite a interação no prompt do shell<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/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<br />
<br />
* <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#running-a-container '''run''']</code>: Executa ações e scripts configurados no container, como se fosse um executável.<br />
<br />
* opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-file '''--bind''']</code>: Permite acessar pastas e arquivos (path) da máquina host dentro da máquina container ([https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). [https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#building-images-from-scratch Dicas sobre a opção <code>--sandbox</code>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 20.04 do Docker Hub: <br />
<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1298Singularity42024-06-08T13:03:23Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
1) Para converter do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>'''. [https://docs.sylabs.io/guides/4.1/user-guide/build_a_container.html#converting-containers-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]:<br />
singularity build --fakeroot --fix-perms [container_destino] [container_origem]<br />
singularity build --fakeroot --fix-perms my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1297Singularity42024-06-08T12:59:18Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v4.1.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu20-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu20-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home --fakeroot (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( Link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#using-no-home-and-containall-flags outras dicas sobre --no-home] )<br />
<br />
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/<br />
singularity shell --writable --no-home --fakeroot my_container/<br />
<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
O comportamento padrão do SingularityCE é montar as pastas /home/$USER, /tmp, and $PWD da máquina host dentro do container ([httphttps://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#system-defined-bind-paths algumas outras pastas também] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
singularity shell --writable --no-home --fakeroot --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://docs.sylabs.io/guides/4.1/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1296Singularity42024-06-08T12:48:16Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v3.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 20.04 e instala os pacotes para executar o cuda toolkit 11.4:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu20-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:20.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu22-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu22-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( 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] )<br />
<br />
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/<br />
sudo singularity shell --writable --no-home my_container/<br />
<br />
* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
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] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1295Singularity42024-06-08T12:46:08Z<p>Othiago: </p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v3.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 22.04 e instala os pacotes para executar o cuda:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu22-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:22.04<br />
<br />
%post<br />
cd<br />
apt -y update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install \<br />
git \<br />
curl \<br />
wget \<br />
zip \<br />
cmake \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev<br />
<br />
# CUDA Toolkit 11.4 pode ser encontrado em https://developer.nvidia.com/cuda-11-4-0-download-archive<br />
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin<br />
mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600<br />
wget https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
dpkg -i cuda-repo-ubuntu2004-11-4-local_11.4.2-470.57.02-1_amd64.deb<br />
apt-key add /var/cuda-repo-ubuntu2004-11-4-local/7fa2af80.pub<br />
apt update<br />
DEBIAN_FRONTEND=noninteractive \<br />
apt -y install cuda<br />
<br />
wget https://github.com/colmap/colmap/archive/refs/tags/3.9.1.zip<br />
unzip 3.9.1.zip<br />
cd colmap-3.9.1<br />
mkdir build<br />
cd build<br />
cmake .. -GNinja -DCMAKE_CUDA_ARCHITECTURES=70<br />
ninja<br />
ninja install<br />
cd<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export PATH=$PATH:/usr/local/cuda/bin<br />
export LC_ALL=C<br />
<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu22-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu22-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( 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] )<br />
<br />
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/<br />
sudo singularity shell --writable --no-home my_container/<br />
<br />
* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
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] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity4&diff=1294Singularity42024-06-08T12:25:08Z<p>Othiago: Created page with "= Singularity CE 4.x (Community Edition) = === <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas m..."</p>
<hr />
<div>= Singularity CE 4.x (Community Edition) =<br />
=== <span style="color: red;">'''Esta será a versão utilizada na rede VeRLab/JLab a partir de jun/2024, atualmente instalado nas máquinas a v4.1.x'''</span> ===<br />
<br />
==== Documentação oficial Singularity CE v4.1.x ====<br />
* https://www.sylabs.io/docs/<br />
===== '''User Guide CE v4.1.x ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/<br />
* https://docs.sylabs.io/guides/4.1/user-guide/quick_start.html<br />
===== '''Adm Guide CE v4.1.x ''' (''Apenas para problemas mais específicos de segurança e instalação!'') =====<br />
* https://docs.sylabs.io/guides/4.1/admin-guide/<br />
===== ''' ''Definition Files'' ''' =====<br />
* https://docs.sylabs.io/guides/4.1/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/4.1/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
== <span style="color: red;">IMPORTANTE</span>: Diferença entre os 2 formatos suportados pelo <code>singularity build</code>: ==<br />
<br />
==== '''Pasta <code>sandbox</code>''': <span style="color: red;">INDICADO PARA FASE DE TESTES E MODIFICAÇÕES no container (instalar pacotes)</span> ====<br />
* 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.<br />
* 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. <br />
* Desvantagem: Execução mais lenta, muitos arquivos para copiar de uma máquina para outra e reproduzir o experimento <br />
* writable (ch)root directory called a sandbox for interactive development ( --sandbox option)<br />
<br><br />
==== '''Arquivo único, extensão <code>.sif</code>''': <span style="color: red;">SOMENTE LEITURA, NÃO é possível editar o container</span> ====<br />
* Destinado para fase de experimentos em massa (production)<br />
* 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<br />
* Desvantagem: Não é possível instalar/modificar pacotes do container. Para instalar/editar algo, tem que transformar em '''"pasta sandbox"'''.<br />
* compressed read-only Singularity Image File (SIF) format suitable for production (default)<br />
<br><br />
<br />
== Passo a Passo: Uso do Singularity CE v3.x ==<br />
<br><br />
Exemplos de interação mais usuais com o container singularity<br />
<br />
# Confirmar se a máquina tem singularity instalado e a versão<br />
# Solicitar sua pasta de trabalho com seu nome de usuário (storage ou homeLocal)<br />
# Escrever a "receita" (definition file) do seu container Singularity <br />
# Criar seu container Singularity no formato "pasta sandbox" usando seu definition file<br />
# Corrigir o ownership da sua "pasta sandbox"<br />
# Usar o shell do container em modo --writable --no-home (instalar, modificar e testar)<br />
# Usar o shell em modo "somente leitura" para testar<br />
# Usar o shell e montar uma pasta do host<br />
# Converter um container singularity do formato "pasta sandbox" para o formato '''<code>.sif</code>''' (imagem compactada)<br />
<br><br><br />
<br />
==== 1) Conferir se a máquina tem singularity instalado e a versão ====<br />
singularity --version<br />
<br><br><br />
<br />
==== 2) Solicitar a criação da sua pasta de trabalho com seu nome de usuário (storage ou homeLocal) ====<br />
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>).<br />
<br />
Existem duas opções de locais para armazenar sua pasta de containers singularity:<br />
* No serviço de storage da rede, na pasta <code>/srv/forge/fulano/</code> ou <br />
* Localemente em alguma máquina, na pasta <code>/homeLocal/fulano</code><br />
<br />
===== 2a) Pasta no serviço de storage (<code>'''/srv/forge'''</code>): =====<br />
* Foi escolhido que das máquinas de processamento na rede, apenas '''EPONA, GHOST e MAGRITTE''' serão capazes de criar um container. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço na storage para os demais usuários.<br />
cd /srv/forge <br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /srv/forge/fulano<br />
<br />
===== 2b) Pasta no disco local de alguma máquina da rede <code>'''/homeLocal'''</code>): =====<br />
* As máquinas da rede com GPU costumam ter uma partição do disco separada para os usuários ocuparem com dados de experimentos e testes. Essa partição é montada na pasta <code>'''/homeLocal'''</code><br />
* É importante que cada usuário limpe seus dados de experimentos e testes com frequência, pois não existe uma política de "quotas", assim todos contribuem para para liberar espaço em disco para os demais usuários.<br />
cd /homeLocal<br />
sudo mkdir fulano<br />
sudo chown -Rv fulano:513 fulano/<br />
cd /homeLocal/fulano<br />
<br><br><br />
<br />
==== 3) Escrever a "receita" (definition file) do seu container Singularity ====<br />
<br />
O Definition file é o arquivo que descreve a forma como o Singularity vai criar seu container, qual sistema operacional será usado como base, quais pacotes instalar, criar alguma pasta e etc <br />
Na documentação so singularity tem mais explicações sobre a sintaxe e função de cada campo: <br />
<br><br />
''' ''Definition Files'' '''<br />
* https://docs.sylabs.io/guides/3.10/user-guide/definition_files.html<br />
** '''Exemplos de ''Definition Files'' ''': https://github.com/sylabs/examples<br />
** '''Singularity ''Definition Files'' vs. ''Docker file'' ''': https://docs.sylabs.io/guides/3.9/user-guide/singularity_and_docker.html#sec-deffile-vs-dockerfile<br />
<br><br />
<br />
Abaixo um exemplo de definition file (salvo como ubuntu-cuda.def) que tem como base um sistema operacional ubuntu 22.04 e instala os pacotes para executar o cuda:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Exemplo de Definition File - ubuntu22-cuda.def<br />
|-<br />
|<pre><br />
BootStrap: library<br />
From: ubuntu:22.04<br />
<br />
%post<br />
apt -y update<br />
apt -y install \<br />
git \<br />
pip \<br />
wget \<br />
zip \<br />
cmake \<br />
python3.11 \<br />
ninja-build \<br />
build-essential \<br />
libboost-program-options-dev \<br />
libboost-filesystem-dev \<br />
libboost-graph-dev \<br />
libboost-system-dev \<br />
libeigen3-dev \<br />
libflann-dev \<br />
libfreeimage-dev \<br />
libmetis-dev \<br />
libgoogle-glog-dev \<br />
libgtest-dev \<br />
libsqlite3-dev \<br />
libglew-dev \<br />
qtbase5-dev \<br />
libqt5opengl5-dev \<br />
libcgal-dev \<br />
libceres-dev \<br />
nvidia-cuda-toolkit \<br />
nvidia-cuda-toolkit-gcc<br />
<br />
git clone https://github.com/profDarlanBrito/RoutePlanner.git<br />
wget https://downloads.coppeliarobotics.com/V4_5_1_rev4/CoppeliaSim_Edu_V4_5_1_rev4_Ubuntu22_04.tar.xz<br />
<br />
tar -xvf CoppeliaSim_Edu_V4_5_1_rev4_Ubuntu22_04.tar.xz<br />
<br />
pip install -r RoutePlanner/requirements.txt<br />
<br />
# limpar cache das instalações<br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
<br />
<br />
%environment<br />
export LC_ALL=C<br />
<br />
%apprun scene1<br />
CoppeliaSim_Edu_V4_5_1_rev4_Ubuntu22_04/coppeliaSim.sh -h -q base_scene_quadcopter_cars.ttt &<br />
python RoutePlanner/RouteOptimization.py<br />
<br />
%apprun scene2<br />
CoppeliaSim_Edu_V4_5_1_rev4_Ubuntu22_04/coppeliaSim.sh -h -q base_scene_quadcopter_build.ttt &<br />
python RoutePlanner/RouteOptimization.py<br />
<br />
%apprun scene3<br />
CoppeliaSim_Edu_V4_5_1_rev4_Ubuntu22_04/coppeliaSim.sh -h -q base_scene_quadcopter_office.ttt &<br />
python RoutePlanner/RouteOptimization.py<br />
<br />
%labels<br />
Author Verlab<br />
<br />
<br />
# To build the container<br />
# $ singularity build --sandbox --fakeroot --fix-perms my-cuda/ ubuntu22-cuda.def<br />
<br />
</pre><br />
<br />
<br />
|}<br />
<br />
<br><br><br />
<br />
==== 3) Criar seu container Singularity no formato "pasta sandbox" usando seu definition file ====<br />
<br />
O formato sandbox é usado para modificar e instalar pacotes no container<br />
<br />
sudo singularity build --sandbox [pasta_destino] [definition-file.def]<br />
<br />
A base usada na construção do container pode ter outras fontes online ou local, [https://docs.sylabs.io/guides/3.10/user-guide/build_a_container.html veja na documentação].<br />
<br />
<br />
Alguns exemplos:<br />
<br />
Usando o definition file '''ubuntu22-cuda.def''' como receita para criar o container<br />
sudo singularity build --sandbox ubuntu22-cuda ubuntu22-cuda.def<br />
<br />
Usando o [https://hub.docker.com/_/ubuntu repositório do docker do ubuntu 20] como base para o container<br />
sudo singularity build --sandbox my_ubuntu20 docker://index.docker.io/library/ubuntu:20.04<br />
<br />
Usando o [https://hub.docker.com/_/python repositório docker do python 3.8] como base para o container (<br />
sudo singularity build --sandbox my_ubuntu20_py3 docker://python:3.8-bullseye<br />
<br><br><br />
<br />
==== 4) Corrigir o ownership da sua "pasta sandbox" ====<br />
<br />
Como seu container foi criado usando sudo singularity, o ownership da pasta vai ser root:root<br />
<br />
'''Deve-se pedir para algum gestor da infraestrutura da rede VeRLab/JLab alterar o ownership da pasta para seu_usuario:DomainUsers''' <br />
<br />
a) descobrir o UID do usuário e o GID do grupo DomainUsers com o comando id:<br />
id nome_usuario<br />
<br />
<br />
b) mudar o ownership, recursivamente, de todos arquivos da pasta sandbox (-R=recursive, -v=verbose)<br />
sudo chown -Rv [uid]:513 pasta_sandbox/<br />
<br><br><br />
<br />
==== 5) Usar o shell do container em modo --writable --no-home (instalar, modificar e testar) ====<br />
<br />
Executar seu singularity no formato "pasta sandbox" em "modo escrita" para instalar pacotes.<br />
<br />
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. <br />
( 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] )<br />
<br />
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/<br />
sudo singularity shell --writable --no-home my_container/<br />
<br />
* Use <code>sudo</code> somente quando necessário modificar o container com instalação de pacotes e configuração<br />
* 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. <br />
* Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code><br />
<br><br><br />
<br />
==== 6) Usar o shell em modo "somente leitura" para testar ====<br />
Executar seu singularity no formato "pasta sandbox" em modo "somente leitura" para testar:<br />
singularity shell my_container/<br />
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<br />
<br><br><br />
==== 7) Montar /homeLocal/usuario dentro container para salvar resultados (opção <code> --bind </code>) ====<br />
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] ).<br />
<br />
Para acessar outros diretórios da máquina host dentro do container usa-se a sintaxe<br />
singularity shell --bind [/absolute/path/host/]:[/absolute/path/inside/container]<br />
<br />
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:<br />
singularity shell --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
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:<br />
sudo singularity shell --writable --no-home --bind /homeLocal/fulano:/mnt my_container/<br />
<br />
* link sobre a opção <code>[https://sylabs.io/guides/3.9/user-guide/quick_start.html#working-with-files '''--bind''']</code><br />
* link com [https://sylabs.io/guides/3.9/user-guide/bind_paths_and_mounts.html#user-defined-bind-points outras dicas sobre --bind])<br />
<br><br><br />
<br />
==== 8) Converter um container singularity do formato '''"pasta sandbox"''' para o formato '''<code>.sif</code>''' (imagem compactada) ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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]:<br />
sudo singularity build [container_destino] [container_origem]<br />
sudo singularity build my_container-compact.sif my_container/<br />
<br> <br><br />
<br />
== Limitar recursos do container (RAM, Core's, network e etc) ==<br />
<br />
É 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. <br />
<br />
Segue o texto original e os links com mais informações:<br />
<br />
''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.''<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html#cgroups-toml<br />
<br />
* https://docs.sylabs.io/guides/3.10/admin-guide/configfiles.html<br />
<br><br><br />
<br />
== Docker Hub: Usar repositório de Máquinas Container Prontas! ==<br />
* Docker Hub: várias imagens prontas com ferramentas instaladas<br />
<br />
https://hub.docker.com/<br />
<br />
Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório <br />
<br />
https://hub.docker.com/r/jjanzic/docker-python3-opencv<br />
<br />
Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o '''formato docker://REPOSITORIO:TAGS'''<br />
<br />
No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina: <br />
<br />
List of available docker tags:<br />
opencv-4.1.0 (latest branch)<br />
contrib-opencv-4.1.0 (opencv_contrib branch)<br />
opencv-4.0.1<br />
contrib-opencv-4.0.1<br />
opencv-4.0.0<br />
contrib-opencv-4.0.0<br />
opencv-3.4.2<br />
contrib-opencv-3.4.2<br />
(...)<br />
<br />
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:<br />
<br />
sudo singularity build --sandbox opencv-base docker://jjanzic/docker-python3-opencv:opencv-4.0.1<br />
<br><br><br />
<br />
== PIP: Python Package Installer ==<br />
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''.<br />
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.<br />
<br />
<code> pip install <package> -t /usr/local/lib/python2.7/dist-packages/ </code><br />
<br> <br><br />
<br />
== Links dos Comandos Básicos ==<br />
https://www.sylabs.io/guides/3.9/user-guide/quick_start.html#interact-with-images<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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<br />
<br />
* <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.<br />
<br />
* 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])<br />
<br><br><br />
<br />
== <code>'''build'''</code>: Criar uma máquina container ==<br />
<br />
==== Criar uma máquina container editável (para instalar pacotes) ====<br />
* 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>].<br />
* Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub: <br />
<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:20.04<br />
sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Exemplo singularity sandbox usando um repositório qualquer do dockerhub<br />
sudo singularity build --sandbox my_container/ docker://repository_name:tag<br />
<br><br><br />
==== outros exemplos menos usados, pois criam container's não editável ====<br />
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
Deve-se usar o formato <code>.sif</code> (writable) a partir de um repositório Docker Hub: <br />
sudo singularity build my_ubuntu.sif docker://index.docker.io/library/ubuntu:latest<br />
<br />
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox:<br />
sudo singularity build my_ubuntu.sif my_container/<br />
<br><br><br />
<br />
== <code>'''shell'''</code>: Executar a máquina container e interagir no shell: ==<br />
<br />
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:<br />
singularity shell my_container/<br />
singularity shell my_ubuntu.sif/<br />
<br><br><br />
<br />
== <code>opção '''--writable'''</code>: Permitir alterar o container em formato pasta sandbox: ==<br />
<br />
* 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.<br />
sudo singularity shell --writable --no-home my_container/<br />
<br><br><br />
<br />
== <code>opção '''--bind'''</code>:Montando pastas da máquina host para acessar dentro da máquina container ==<br />
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.<br />
<br />
* Executar a máquina container no shell e montar o caminho /homeLocal/fulano da máquina host dentro da máquina container <br />
<br />
<code>singularity shell --bind /homeLocal/fulano:/mnt my_container/</code><br />
<br><br></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1265DJI2023-11-21T15:52:03Z<p>Othiago: </p>
<hr />
<div>==Wiki Tello Pilots==<br />
<br />
Aqui você pode encontrar diversas informações sobre drones Tello.<br />
https://tellopilots.com/wiki/<br />
<br />
<br />
==Api==<br />
https://djitellopy.readthedocs.io/en/latest/tello/<br />
<br />
<br />
Para conseguir se conectar ao drone através da api, é necessário está conectado na rede Wi-Fi do drone.<br />
O mesmo vale para a controlar através de um dispositivo mobile.</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1264DJI2023-11-21T14:13:29Z<p>Othiago: </p>
<hr />
<div>==Wiki Tello Pilots==<br />
<br />
Aqui você pode encontrar diversas informações sobre drones Tello.<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1263DJI2023-11-21T14:11:07Z<p>Othiago: </p>
<hr />
<div>==Wiki Tello Pilots==<br />
<br />
Wiki Tello<br />
<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1262DJI2023-11-21T14:10:57Z<p>Othiago: </p>
<hr />
<div>===Wiki Tello Pilots===<br />
<br />
Wiki Tello<br />
<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1261DJI2023-11-21T14:10:06Z<p>Othiago: </p>
<hr />
<div>=DJI Tello=<br />
<br />
Wiki Tello<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1260DJI2023-11-21T14:09:52Z<p>Othiago: </p>
<hr />
<div>=DJI Tello+<br />
<br />
Wiki Tello<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=DJI&diff=1259DJI2023-11-21T14:07:07Z<p>Othiago: Created page with "DJI Tello Wiki Tello https://tellopilots.com/wiki/"</p>
<hr />
<div>DJI Tello<br />
<br />
Wiki Tello<br />
https://tellopilots.com/wiki/</div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Main_Page&diff=1258Main Page2023-11-21T14:05:34Z<p>Othiago: /* Multirotor */</p>
<hr />
<div><br />
<br />
<br />
== Seja bem vindo a Wiki do VeRLab (Computer Vision and Robotics Laboratory - DCC - UFMG) ==<br />
<br />
=== [[Regras de Conduta e Termo de Compromisso]] ===<br />
=== [[Como rodar seu experimento]] ===<br />
=== [[Trabalhando remotamente]] ===<br />
<br />
=== [[Dicas para escrever e apresentar sua publicação]] ===<br />
=== [http://www.verlab.dcc.ufmg.br/mediawiki/index.php/Special:AllPages Relação de todas as páginas dessa wiki] ===<br />
<br />
== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Robot Robôs] ==<br />
<br />
==== Small size Robots ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Main_Page/e-puck E-puck]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/HeRo HeRo]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Espcopter Espcopter]<br />
<br />
==== Mobile Robots ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Roomba Roomba]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kobuki Kobuki]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pioneer Pioneer - ActivMedia Robotics]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jackal Jackal - Clearpath Robotics]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Tamiya Tamiya TXT-1]<br />
<br />
==== Robot Arm ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kinova_Gen3_Ultra Gen3 Ultra lightweight robot arm - KINOVA]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Fenrir_Arm Fenrir]<br />
<br />
==== Multirotor ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ARdrone Parrot AR.Drone 2.0]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hummingbird AscTec Hummingbird]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pelican AscTec Pelican]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Iris 3DR IRIS+]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/X8 3DR X8+]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/DJI Tello]<br />
<br />
==== Fixed-Wing ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Aero 3DR Aero]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/E384 Drone E384]<br />
<br />
== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sensor Sensores] ==<br />
==== Laser ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Laser_Hokuyo Hokuyo]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/LaserVelodyne Velodyne]<br />
<br />
==== IMU (unidades inerciais, acelerômetro, magnetometro, barômetro e etc ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/IMU IMUs]<br />
<br />
==== Câmeras ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Camera_360 Camera 360]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GoPro GoPro]<br />
* TODO Kinect One (Xbox One)<br />
* TODO Kinect v2 (Xbox 360)<br />
* TODO [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ZED StereoLabs ZED(RGBD)]<br />
* TODO [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/RealSense Intel Real Sense (RGBD)]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Asus_Xtion_PRO Asus Xtion PRO]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/WebCams WebCams]<br />
<br />
==== Realidade Virtual e Aumentada ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hololens HoloLens]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Oculus_Rift Oculus Rift]<br />
<br />
== Atuadores ==<br />
* Dynamixel AX-12<br />
* Dynamixel MX-64AT<br />
* TODO Motor Servo<br />
* TODO Interface Haptica<br />
*<br />
<br />
== Placas Controladoras e Sensor Nodes ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Arduino Arduino]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP32 ESP32]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP8266 ESP8266]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/RaspberryPi Raspberry Pi]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jetson_Nano Jetson nano - Nvidia]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/mote Sensor Nodes]<br />
<br />
== Softwares ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity Singularity]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ROS ROS - Robot Operacional System]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Virtualenv Python Virtual Enviroment]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GitHub_do_Verlab GitHub do Verlab]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Windows S.O. Windows]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Linux S.O. Linux]<br />
<br />
== Equipamentos de Pesquisa ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Impressora3D Impressora 3D]<br />
<br />
== Equipamentos de Informática ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Cabo_de_Rede Montagem de Cabos de Rede]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Impressoras Impressoras]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/NoBreak No Break]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/HD Teste HD - smartctl]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/RotuladorPT80 Rotuladora PT80]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/PastaTermica Aplicação e Escolha de Pasta Térmica]<br />
<br />
== Ferramentas ==<br />
* TODO<br />
* [http://www.crvindustrial.com/blog/como-medir-parafusos-corretamente como medir parafusos]<br />
<!--<br />
<strong>MediaWiki has been installed.</strong><br />
<br />
Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br />
<br />
== Getting started ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list] <br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br />
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br />
--></div>Othiagohttp://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Main_Page&diff=1257Main Page2023-11-21T13:54:30Z<p>Othiago: /* Multirotor */</p>
<hr />
<div><br />
<br />
<br />
== Seja bem vindo a Wiki do VeRLab (Computer Vision and Robotics Laboratory - DCC - UFMG) ==<br />
<br />
=== [[Regras de Conduta e Termo de Compromisso]] ===<br />
=== [[Como rodar seu experimento]] ===<br />
=== [[Trabalhando remotamente]] ===<br />
<br />
=== [[Dicas para escrever e apresentar sua publicação]] ===<br />
=== [http://www.verlab.dcc.ufmg.br/mediawiki/index.php/Special:AllPages Relação de todas as páginas dessa wiki] ===<br />
<br />
== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Robot Robôs] ==<br />
<br />
==== Small size Robots ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Main_Page/e-puck E-puck]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/HeRo HeRo]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Espcopter Espcopter]<br />
<br />
==== Mobile Robots ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Roomba Roomba]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kobuki Kobuki]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pioneer Pioneer - ActivMedia Robotics]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jackal Jackal - Clearpath Robotics]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Tamiya Tamiya TXT-1]<br />
<br />
==== Robot Arm ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Kinova_Gen3_Ultra Gen3 Ultra lightweight robot arm - KINOVA]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Fenrir_Arm Fenrir]<br />
<br />
==== Multirotor ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ARdrone Parrot AR.Drone 2.0]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hummingbird AscTec Hummingbird]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Pelican AscTec Pelican]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Iris 3DR IRIS+]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/X8 3DR X8+]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ DJI Tello]<br />
<br />
==== Fixed-Wing ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Aero 3DR Aero]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/E384 Drone E384]<br />
<br />
== [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sensor Sensores] ==<br />
==== Laser ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Laser_Hokuyo Hokuyo]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/LaserVelodyne Velodyne]<br />
<br />
==== IMU (unidades inerciais, acelerômetro, magnetometro, barômetro e etc ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/IMU IMUs]<br />
<br />
==== Câmeras ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Camera_360 Camera 360]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GoPro GoPro]<br />
* TODO Kinect One (Xbox One)<br />
* TODO Kinect v2 (Xbox 360)<br />
* TODO [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ZED StereoLabs ZED(RGBD)]<br />
* TODO [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/RealSense Intel Real Sense (RGBD)]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Asus_Xtion_PRO Asus Xtion PRO]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/WebCams WebCams]<br />
<br />
==== Realidade Virtual e Aumentada ====<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Hololens HoloLens]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Oculus_Rift Oculus Rift]<br />
<br />
== Atuadores ==<br />
* Dynamixel AX-12<br />
* Dynamixel MX-64AT<br />
* TODO Motor Servo<br />
* TODO Interface Haptica<br />
*<br />
<br />
== Placas Controladoras e Sensor Nodes ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Arduino Arduino]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP32 ESP32]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ESP8266 ESP8266]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/RaspberryPi Raspberry Pi]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Jetson_Nano Jetson nano - Nvidia]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/mote Sensor Nodes]<br />
<br />
== Softwares ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity Singularity]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/ROS ROS - Robot Operacional System]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Virtualenv Python Virtual Enviroment]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/GitHub_do_Verlab GitHub do Verlab]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Windows S.O. Windows]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Sistema_Operacional_Linux S.O. Linux]<br />
<br />
== Equipamentos de Pesquisa ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Impressora3D Impressora 3D]<br />
<br />
== Equipamentos de Informática ==<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Cabo_de_Rede Montagem de Cabos de Rede]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/Impressoras Impressoras]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/NoBreak No Break]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/HD Teste HD - smartctl]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/RotuladorPT80 Rotuladora PT80]<br />
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/EquipamentoInformatica/PastaTermica Aplicação e Escolha de Pasta Térmica]<br />
<br />
== Ferramentas ==<br />
* TODO<br />
* [http://www.crvindustrial.com/blog/como-medir-parafusos-corretamente como medir parafusos]<br />
<!--<br />
<strong>MediaWiki has been installed.</strong><br />
<br />
Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br />
<br />
== Getting started ==<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list] <br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br />
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br />
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br />
--></div>Othiago