Difference between revisions of "Singularity"

Revision as of 11:07, 30 August 2019

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 basta logar em uma máquina de processamento para rodar seu experimento.

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:

Máquinas locais 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. Essa pasta deve dar permissão para qualquer usuários criarem e modificarem suas máquinas container.
• Configurar o comando $sudo singularity ... de modo que todo usuário possa rodá-lo dentro da pasta /homeLocal, sem necessitar de senha root

Máquinas de processamento da rede com GPU Nvidia e acesso ao /srv/forge e /srv/storage/singularity/forge

• Foi escolhido que das máquinas de processamento na rede, apenas PROC2 e ESCHER 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 PROC2 e ESCHER 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 sem modo de edição ($singularity shell...), a pasta /srv/forge é espelhada em proc2:/srv/storage/singularity/forge$ e escher:/srv/storage/singularity/forge$

IMPORTANTE: Diferença entre os 3 formatos criados pelo build:

Arquivo único, extensão .simg: NÃO é possivel editar container

• Destinado para fase de experimentos em massa (produção)
• Vantagem: Em geral, ocupa menos espaço e executa mais rápido que um container equivalente no formato .img. Indicado para produção, versão final de experimentos.
• Desvantagem: Não pode-se fazer modificação no container. Para Instalar algo, tem que transformar em .img ou "pasta sandbox".
• (single file) compressed read-only squashfs file system suitable for production (default)

Arquivo único, extensão .img: NÃO indicado para editar o container, apesar de possível com limitação de espaço

• Destinado para a fase de desenvolvimento, mas com container sofrendo poucas alterações.
• Vantagem: Em geral, ocupa menos espaço e executa mais rápido que um container equivalente no formato "pasta sandbox". E ainda pode-se instalar pacotes (opção --writable), porém tem limitação de espaço em disco.
• Desvantagem: O disco tem tamanho fixo, então é possível fazer modificações e instalações com opção --writable, mas se não couber no disco, o mesmo tem que ser expandido manualmente com image.expand --size
• (single file): writable ext3 file system suitable for interactive development ( --writable option )

Pasta Sandbox sandbox directory : INDICADO PARA EDITAR, sem limitações de espaço significativas

• Destinado para desenvolvimento inicial do container, quando ainda não se sabe exatamente as configurações e ferramentas a serem usadas, logo o container ainda sofre muitas alterações.
• Vantagem: vários arquivos e sub-pastas que são expansíveis automaticamente conforme vai-se instalando pacotes (opção --writable). O tamanho do disco é expansível conforme disponibilidade da máquina host.
• Desvantagem: Mais lento dos formatos para execução!
• (many files and sub-folders): writable (ch)root directory called a sandbox for interactive development ( --sandbox option)

Regras de bom uso dos recursos

• Cada usuário deve criar uma pasta com seu nome de usuário dentro das pastas de uso comum ( /homeLocal/fulano ou /srv/forge/fulano ou /srv/storage/datasets ) e usá-la para seus arquivos. Assim fica organizado e facilita identificar quem são os donos dos containers ou datasets.

• A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (.img ou .simg). Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".

• Usuários não devem deixar o dataset dentro da sua pasta home na rede. 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. Os datasets devem ser armazenados numa pasta local do computador com o nome do usuário ou no servidor de storage (usando uma pasta com o nome do usuário).
  • Por exemplo, para o login "fulano" não usar /home/fulano/dataset mas sim:
  • /homeLocal/fulano/dataset
  • /srv/storage/datasets/fulano/

• Cada usuário deve criar/preparar sua máquina container em uma pasta local e executá-la em "modo edição" e como "pasta sandbox" (--writable) para instalar os pacotes e dependências para seus experimentos. Por exemplo, usar a pasta local /homeLocal/fulano/my_container . Depois de pronta, a máquina container, pode ser convertida para o formato de imagem (.img ou .simg) 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.

Passo a Passo: caso de uso do Singularity

Criar sua máquina container em "modo edição" e no formato "pasta sandbox" ( para instalar os pacotes e dependências para seus experimentos).

1) Criar sua pasta de usuario em /srv/forge/fulano/ ou /homeLocal/fulano  :

   cd /srv/forge 
   mkdir fulano
   cd /srv/forge/fulano

   cd /homeLocal
   mkdir fulano
   cd /homeLocal/fulano

2) criar seu container singularity no formato "pasta sandbox" para ser possível instalar pacotes:

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

3) executar seu container singularity em modo edição para instalar pacotes:

   sudo singularity shell --writable my_container/

Depois de pronta, a máquina container, pode ser convertida para o formato de imagem (.img ou .simg) 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.

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

   singularity shell my_container/

Converter uma máquina container container do formato "pasta sandbox" para o formato .simg

• Para converter do formato "pasta sandbox" para o formato .simg. Dicas sobre conversão de formatos das máquinas container:

   sudo singularity build my_ubuntu.simg my_container/

Links para aprender Singularity

Documentação oficial

• https://www.sylabs.io/docs/ (atual, desde julho/2018)

• https://singularity.lbl.gov/docs-docker (verãos antiga)

More details about the different build options and best practices, read singularity flow:

https://sylabs.io/guides/2.5/user-guide/introduction.html#the-singularity-usage-workflow

Docker Hub: Máquinas Container Prontas!

• Docker Hub: várias imagens prontas com ferramentas instaladas

   https://hub.docker.com/

Por exemplo pode-se buscar no google: "docker hub opencv ubuntu", uma das respostas será o repositório

   https://hub.docker.com/r/jjanzic/docker-python3-opencv

Para usar um endereço de imagem docker hub e criar seu container singularity, usa-se o formato docker://REPOSITORIO:TAGS

No caso do repósitório exemplo, ao abrir o link, vai encontrar diversas TAGS listadas na pagina:

   List of available docker tags:
   opencv-4.1.0 (latest branch)
   contrib-opencv-4.1.0 (opencv_contrib branch)
   opencv-4.0.1
   contrib-opencv-4.0.1
   opencv-4.0.0
   contrib-opencv-4.0.0
   opencv-3.4.2
   contrib-opencv-3.4.2
   (...)

Assim para criar o container usando build e copiando do repositório exemplo a tag opencv-4.0.1, tem-se:

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

Alguns Comandos Básicos

https://www.sylabs.io/guides/2.5.1/user-guide/quick_start.html#interact-with-images

• build: Cria uma imagem para a máquina container old link

• shell: Executa a máquina container no prompt do shell old link

• exec: Executa um comando dentro do shell da máquina container, em segundo plano, e apresenta o resultado no shell da máquina host old link

• run: Executa ações e scripts configurados no container, como se fosse um executável. old link

• pull: ??? Copia um container de um repositório, pasta sandbox ou imagem pronta ???

build: Criar uma máquina container

Criar uma máquina container editável (para instalar pacotes)

• Deve-se usar um singularity no formato "pasta sandbox" (estrutura de diretórios). Dicas sobre a opção --sandbox.
• Criar singularity sandbox usando o repositório Ubuntu 18.04 do Docker Hub:

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

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

• Exemplo singularity sandbox usando um repositório qualquer do dockerhub

sudo singularity build --sandbox my_container/ docker://repository_name:tag

outros exemplos menos usados, pois criam container's com limitação de edição ou não editável

• Criar uma máquina container em formato .img (read-only) a partir de um repositório Docker Hub:

    sudo singularity build my_ubuntu.img docker://index.docker.io/library/ubuntu:latest 

Deve-se usar o formato .img (writable) a partir de um repositório Docker Hub:

    sudo singularity build --writable my_ubuntu.img docker://index.docker.io/library/ubuntu:latest 

• Para aumentar o tamanho do disco no container formato .img pode-se utilizar o comando singularity image.expand --size XXX

   singularity image.expand my_test.img   # Specify a size for an operation in MiB, i.e. 1024*1024B (default 768MiB)
   singularity image.expand --size 500 my_test.img   # expand size of 500 MiB

• Converter ou Criar uma máquina container em formato de imagem a partir de uma pasta sandbox: (Dicas sobre conversão de formatos das máquinas container

   sudo singularity build my_ubuntu.simg my_container/

• Criar uma máquina container em formato .simg (read-only) a partir de um repositório Docker Hub:

    singularity build lolcow.simg docker://godlovedc/lolcow 

Executar a máquina container sandbox no shell para instalar pacotes:

• TODO: Como fazer na homeLocal e como fazer na proc2:/srv/forge

sudo singularity shell --writable my_container/

Executar a máquina container no shell:

You can make changes to the container (assuming you have the proper permissions to do so) but those changes will disappear as soon as you exit. To make your changes persistent across sessions, use the --writable option. It’s also a good practice to shell into your container as root to ensure you have permissions to write where you like.

• Executar a máquina container no shell, sem salvar modificações feitas na sessão:

singularity shell my_container/

singularity shell my_ubuntu.img/

• para algum teste de configuração ou instalação de pacote temporário

sudo singularity shell my_ubuntu.img/

• Executar a máquina container no shell, salvando as modificações da sessão ao sair do container. usar opção --writable (Dicas sobre a opção --writable)

sudo singularity shell --writable my_container/ - para instalação de pacotes / configuração

singularity shell --writable my_container/ - para a execução de experimentos

Exemplos com exec