Difference between revisions of "Singularity"

From VeRLab Wiki
Jump to: navigation, search
(→‎Criar uma máquina container)
(→‎Singularity)
 
(159 intermediate revisions by 5 users not shown)
Line 10: Line 10:
 
* 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.
 
* 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.
  
−
* 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 basta logar em uma máquina de processamento para rodar seu experimento.
+
* 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.
  
−
== Instalação ==
+
* 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.
−
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><br>
  
−
A equipe de rede é responsável por:
+
== Singularity vs. Docker ==
 +
<br>
 +
'''Docker'''
  
−
* '''Instalar o Singularity''' em toda máquina host com GPU (máquina de processamento)
+
* Popularidade: Docker é amplamente utilizado e tem uma grande comunidade de desenvolvedores.
−
* ''' Criar a pasta <code>/homeLocal</code>''' em toda máquina host para os usuários criarem e modificarem suas máquinas container.
+
* Flexibilidade: Permite a criação de containers para diferentes sistemas operacionais (Linux, Windows, macOS).
−
* ''' 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
+
* Ecosistema: Oferece uma vasta gama de imagens pré-construídas (Docker Hub) e integração com ferramentas de CI/CD.
 +
* Segurança: Embora seguro, pode exigir permissões elevadas (root) para certas operações.
  
−
== Regras de bom uso dos recursos ==
+
'''Singularity'''
−
* A máquina container para rodar os experimentos deve estar em formato de imagem (<code>.img</code> ou  <code>.simg</code>).
 
  
−
* Usuários não devem deixar o dataset (massa de arquivos grande, em geral >=500GB, que vão ser acessados durante o experimento) dentro da sua pasta home na rede (por exemplo, para o login "fulano" <code> /home/fulano/dataset </code> na rede, pois isso aumenta o tráfego na rede desnecessáriamente. Os datasets devem ser armazenados numa pasta local do computador com o nome do usuário ou no servidor de storage. Por exemplo <code> /homeLocal/fulano/dataset </code>
+
* Foco em HPC: Singularity é especialmente popular em ambientes de computação de alto desempenho (HPC) e pesquisa científica.
 +
* Segurança: Projetado para ser executado com permissões de usuário comuns, sem a necessidade de privilégios elevados.
 +
* Portabilidade: Focado principalmente em ambientes Linux, mas com suporte limitado para outros sistemas operacionais.
 +
* Definição de Containers: Utiliza arquivos de definição (Singularity Definition Files) que são diferentes dos arquivos Dockerfile.
  
−
* Cada usuário deve criar/preparar sua máquina container em uma '''pasta local''' e executá-la em ''"modo edição" (<code>--writable</code>)'' para instalar os pacotes e dependências para seus experimentos. Por exemplo, usar a pasta local <code> /homeLocal/fulano/my_container </code>. Depois de pronta, a máquina container, pode ser convertida para o formato de imagem (<code>.img</code> ou  <code>.simg</code>) e ser ser armazenado na pasta home da rede, assim pode ser executada como leitura de qualquer máquina de processamento que o usuário logar.
+
<br><br><br>
  
−
* Use <code>sudo</code> somente quando necessário (e.g., instalação de pacotes e configuração). Quando for rodar o container para experimentos, não será necessário invocar o singularity com permissão <code>sudo</code>.
+
== Versão em uso no VeRLab/JLab ==
  
−
== Links para aprender Singularity e Criar sua Máquina Container ==
+
Atualmente temos a versão 4.1.x instalada nas máquinas da rede VeRLab/JLab.
  
−
* Documentação oficial:
+
=== '''Singularity CE v4.x''' ( ''Community Edition'', ''freeware'', versão em todas as máquinas <span style="color: red;">a partir de jun/2024</span>) ===
 +
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity4  Link para dicas de uso do Singularity CE v4.x]
  
−
https://www.sylabs.io/docs/ (desde julho/2018)
 
  
−
https://singularity.lbl.gov/docs-docker
 
  
−
* More details about the different build options and best practices, read singularity flow:
+
'''Versões anteriores utilizadas na rede rede VeRLab/Jlab'''
−
https://www.sylabs.io/guides/2.5.1/user-guide/singularity_flow.html#singularity-flow
 
  
−
== Alguns Comandos Básicos ==
+
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3  Link para dicas de uso do Singularity CE v3.x]  (descontinuada em mai/2024)
−
https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#interact-with-images
 
  
−
* <code>[https://www.sylabs.io/guides/2.5.1/user-guide/build_a_container.html#build-a-container '''build''']</code>: Cria uma imagem para a máquina container  [http://singularity.lbl.gov/docs-build '''old link''']
+
* 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.
−
* <code> [https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#shell '''shell''']</code>: Executa a máquina container no prompt do shell  [http://singularity.lbl.gov/docs-shell '''old link''']
+
<!-- Comentado
−
* <code>[https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#executing-commands '''exec''']</code>: Executa um comando dentro do shell da máquina container, em segundo plano, e apresenta o resultado no shell da máquina host  [http://singularity.lbl.gov/docs-exec '''old link''']
+
* '''Singularity v2.5.x''' (''freeware'', <span style="color: red;">versão sem suporte desde jul/2018, vai ser descontinuada na rede VeRLab/JLab</span>)
−
* <code>[https://www.sylabs.io/guides/2.5.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. [http://singularity.lbl.gov/docs-run '''old link''']
+
**[https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity2  Link para dicas de uso do Singularity v2.5.x]
−
* <code>[http://singularity.lbl.gov/docs-pull '''pull''']</code>: ??? Copia um container de um repositório, pasta sandbox ou imagem pronta ???
+
-->
−
+
<br> <br> <br>
−
==== Criar uma máquina container ====
 
−
* Diferença entre os 3 formatos criados pelo <code>build</code>:
 
−
** <code>.simg</code> (single file): compressed read-only squashfs file system suitable for production (default)
 
−
** <code>.img</code> (single file): writable ext3 file system suitable for interactive development ( --writable option )
 
−
** <code>sandbox directory </code> (many files and sub-folders): writable (ch)root directory called a sandbox for interactive development ( --sandbox option)
 
  
 +
== Regras de bom uso dos recursos ==
 +
* Arquivos mais importantes e pequenos, como códigos, documentos e resultados finais, devem ser mantidos na home do usuário.
 +
** '''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.
  
−
* Criar uma máquina container em formato <code>.simg</code> (read-only) a partir de um repositório Docker Hub:
 
−
<code> singularity build lolcow.simg docker://godlovedc/lolcow </code>
 
  
 +
* 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).
  
−
* Criar uma máquina container em formato <code>.img</code> (read-only) a partir de um repositório Docker Hub:
 
−
<code> sudo singularity build my_ubuntu.img docker://index.docker.io/library/ubuntu:latest </code>
 
  
 +
* Temos as seguintes opções de pastas de uso comum para massa de dados:
 +
**<code>/homeLocal/</code> : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.
 +
**<code>/srv/storage/datasets</code>) : pasta no servidor de storage para armazenar datasets
 +
**<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.
 +
**<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)
 +
*** 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>'''.
 +
*** Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
  
−
* Criar uma máquina container em formato <code>.img</code> (writable) a partir de um repositório Docker Hub:  
+
 
−
<code> sudo singularity build --writable my_ubuntu.img docker://index.docker.io/library/ubuntu:latest </code>
+
* 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":
 +
**  '''O usuário é responsável por liberar o espaço em disco quando não estiver mais precisando do mesmo ou fazendo testes'''
 +
**<code>/homeLocal/fulano</code> :
 +
**<code>/srv/storage/datasets/fulano</code>
 +
**<code>/srv/storage/singularity/forge/fulano</code>
 +
**<code>/srv/storage/singularity/images/fulano</code>
  
  
−
* Criar uma máquina container container formato de estrutura de diretórios (formato sandbox) a partir do repositório Ubuntu 16.04 do Docker Hub: ([https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#sandbox-directory Dicas sobre a opção <code>--sandbox</code>])
+
* A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (<code>.sif</code>.  
 +
** Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".
 +
** 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.
 +
** '''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.
  
−
<code> sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:latest </code>
+
<br> <br> <br>
−
 
 
−
<code>sudo singularity build --sandbox my_container/ docker://index.docker.io/library/ubuntu:16.04</code>
 
−
 
 
−
* Criar um sandbox
 
−
<code> sudo singularity build --sandbox my_container/ docker://repository_name:tag </code>
 
  
 +
== Instalação ==
 +
Toda máquina de processamento do Verlab/J (máquinas com GPU) deve ter o Singularity instalado e não precisam ter pacotes específicos de software como ROS, cuda, tensorflow.
  
−
* Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox: ([https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#converting-images-from-one-format-to-another Dicas sobre conversão de formatos das máquinas container]
+
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:
  
−
<code>sudo singularity build my_ubuntu.simg my_container/</code>
+
=== Estações de trabalho Desktop no Verlab/J com GPU Nvidia ===
 +
* Instalar o Singularity em toda máquina host com GPU (máquina de processamento)
 +
* Criar a pasta <code>/homeLocal</code> em toda máquina host.
 +
** 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.
 +
* 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
  
−
==== Executar a máquina container no shell: ====
+
=== Servidores de Processamento da rede Verlab/J com GPU Nvidia ===
 +
* Configurar montagem automática das pastas na rede:
 +
**<code>/srv/forge</code> (apenas '''EPONA, GHOST e MAGRITTE''')
 +
**<code>/srv/storage/datasets</code>
 +
**<code>/srv/storage/singularity/images/</code>
 +
**<code>/srv/storage/singularity/forge/</code>
  
−
You can make changes to the container (assuming you have the proper permissions to do so) but those changes will disappear as soon as you exit. To make your changes persistent across sessions, use the --writable option. It’s also a good practice to shell into your container as root to ensure you have permissions to write where you like.
+
* 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>'''.
 +
* Uma segunda restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
 +
* 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
 +
* Para executar o container em modo leitura ('''<code>$singularity shell...</code>'''), a pasta <code>/srv/forge</code> é espelhada nas demais máquinas:
 +
**<code>/srv/storage/singularity/forge$</code>
  
−
* Executar a máquina container no shell, sem salvar modificações feitas na sessão:
+
== Dicas de Uso ==
  
−
<code>singularity shell my_container/</code>
+
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>
  
−
<code>singularity shell my_ubuntu.img/</code>
+
A principal '''vantagem''' dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.
 +
<br>
 +
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!
  
−
<code>sudo singularity shell my_ubuntu.img/</code> - para algum teste de configuração ou instalação de pacote temporário
+
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.
  
−
* Executar a máquina container no shell, salvando as modificações da sessão ao sair do container. usar opção --writable ([https://singularity.lbl.gov/docs-flow#writable-image Dicas sobre a opção <code>--writable</code>])
+
Pode-se verificar a versão do driver Nvidia instalado executando '''<code>nvidia-smi</code>''' na máquina host.
  
−
<code>sudo singularity shell --writable my_container/</code> - para instalação de pacotes / configuração
+
Por conta disso, '''pode ser que a versão do driver instalada na máquina host não suporte todas as versões do CUDA'''. Para ver quais versões são suportadas, é importante se atentar a quais
 +
versões do CUDA a versão do driver atual suporta. Isso pode ser verificado em:
  
−
<code>singularity shell --writable my_container/</code> - para a execução de experimentos
+
* https://docs.nvidia.com/deploy/cuda-compatibility/index.html.
  
−
==== Exemplos com exec ====
+
Para carregar o driver Nvidia no container use a opção  '''<code>--nv</code>'''

Latest revision as of 16:43, 13 November 2024

Singularity

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:

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




Singularity vs. Docker


Docker

  • Popularidade: Docker é amplamente utilizado e tem uma grande comunidade de desenvolvedores.
  • Flexibilidade: Permite a criação de containers para diferentes sistemas operacionais (Linux, Windows, macOS).
  • Ecosistema: Oferece uma vasta gama de imagens pré-construídas (Docker Hub) e integração com ferramentas de CI/CD.
  • Segurança: Embora seguro, pode exigir permissões elevadas (root) para certas operações.

Singularity

  • Foco em HPC: Singularity é especialmente popular em ambientes de computação de alto desempenho (HPC) e pesquisa científica.
  • Segurança: Projetado para ser executado com permissões de usuário comuns, sem a necessidade de privilégios elevados.
  • Portabilidade: Focado principalmente em ambientes Linux, mas com suporte limitado para outros sistemas operacionais.
  • Definição de Containers: Utiliza arquivos de definição (Singularity Definition Files) que são diferentes dos arquivos Dockerfile.




Versão em uso no VeRLab/JLab

Atualmente temos a versão 4.1.x instalada nas máquinas da rede VeRLab/JLab.

Singularity CE v4.x ( Community Edition, freeware, versão em todas as máquinas a partir de jun/2024)


Versões anteriores utilizadas na rede rede VeRLab/Jlab

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




Regras de bom uso dos recursos

  • Arquivos mais importantes e pequenos, como códigos, documentos e resultados finais, devem ser mantidos na home do usuário.
    • 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.


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


  • Temos as seguintes opções de pastas de uso comum para massa de dados:
    • /homeLocal/ : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.
    • /srv/storage/datasets) : pasta no servidor de storage para armazenar datasets
    • /srv/storage/singularity/images/ : pasta no servidor de storage para armazenar as imagens singularity fechadas (.sif) que são executadas nos experimentos.
    • /srv/storage/singularity/forge/ : pasta no servidor de storage para criação de imagens singularity em modo sandbox (evitar deixar as imagens em sandbox, mais detalhes abaixo)
      • 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 $sudo singularity shell --writable... .
      • Outra restrição é que essa permissão só pode ser executada na pasta /srv/forge

 

  • 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":
    • O usuário é responsável por liberar o espaço em disco quando não estiver mais precisando do mesmo ou fazendo testes
    • /homeLocal/fulano :
    • /srv/storage/datasets/fulano
    • /srv/storage/singularity/forge/fulano
    • /srv/storage/singularity/images/fulano


  • A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (.sif.
    • Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".
    • Pedimos que não mantenham muitas imagens singularity em modo sandbox. Sempre que possível, feche sua imagem (converter para .sif e de preferência coloque-as na pasta storage/singularity/images.
    • 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.




Instalação

Toda máquina de processamento do Verlab/J (máquinas com GPU) deve ter o Singularity instalado e não precisam ter pacotes específicos de software como ROS, cuda, tensorflow.

A equipe de rede é responsável por manter máquinas locais e máquinas de processamento disponíveis para executar o singularity. Foi escolhido que o sigularity estará disponível apenas nas máquinas com GPU Nvidia, assim confira a lista de máquinas na área restrita do site do verlab:

Estações de trabalho Desktop no Verlab/J com GPU Nvidia

  • Instalar o Singularity em toda máquina host com GPU (máquina de processamento)
  • Criar a pasta /homeLocal em toda máquina host.
    • O usuário precisa solicitar à equipe de rede para criar uma pasta filha na /homeLocal/nome_do_usuario 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.
  • Configurar o comando $sudo singularity ... de modo que todo usuário possa rodá-lo dentro da pasta /homeLocal, sem necessitar de senha root

Servidores de Processamento da rede Verlab/J com GPU Nvidia

  • Configurar montagem automática das pastas na rede:
    • /srv/forge (apenas EPONA, GHOST e MAGRITTE)
    • /srv/storage/datasets
    • /srv/storage/singularity/images/
    • /srv/storage/singularity/forge/
  • 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 $sudo singularity shell --writable... .
  • Uma segunda restrição é que essa permissão só pode ser executada na pasta /srv/forge
  • Configurar a montagem da pasta /srv/forge nas máquinas EPONA, GHOST e MAGRITTE e configurar a montagem das mesmas para que o comando $sudo singularity ... possa ser executado por qualquer usuário, sem necessitar de permissão root
  • Para executar o container em modo leitura ($singularity shell...), a pasta /srv/forge é espelhada nas demais máquinas:
    • /srv/storage/singularity/forge$

Dicas de Uso

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.

A principal vantagem dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!

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.

Pode-se verificar a versão do driver Nvidia instalado executando nvidia-smi na máquina host.

Por conta disso, pode ser que a versão do driver instalada na máquina host não suporte todas as versões do CUDA. Para ver quais versões são suportadas, é importante se atentar a quais versões do CUDA a versão do driver atual suporta. Isso pode ser verificado em:

Para carregar o driver Nvidia no container use a opção --nv

Retrieved from "http://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity&oldid=1435"