Ze względu na kwestie bezpieczeństwa, budowa kontenerów bezpośrednio na klastrze jest trudna. Nawet funkcja fakeroot w apptainer nie pozwala na budowę kontenerów bezpośrednio na superkomputerze.
Ten problem rozwiązuję buildtainer - system, przez który można zlecić budowę kontera bezpośrednio z superkomputera.
Dla pracy z buildtainer są potrzebne:
WAŻNE: Jeśli dla kontenera jest potrzebny kontekst (n.p. do środka konenera są kopiowane pliki poleceniem
COPY) to należy korzystać z opcji repozytorium git, ponieważ aktualnie system nie obsługuje budowania kontenerów z kontekstem z lokalnego systemu plików.
Korzystanie z buildtainer odbywa się przez skrypt sub o nazwie sub-k8s-buildtainer.sh:
$ sub-k8s-buildtainer.sh --help
buildtainer V2 - Apptainer remote build system for SLURM
Usage: ./sub-buildtainer.sh [arguments...] build apptainer images remotely via slurm jobs
Options:
-h or --help Show this help message and exit
-l [path] or --local-dockerfile=[path]
Build from a local Dockerfile (no context)
-g or --git Build from git repository (with context)
You will be prompted for the repository link on first call
Format: "https://<username>:<token>@<git_repo>"
Saved in ~/.buildtainer
-gc or --git-force-configure
Build from git repository (with context)
Force reconfigure the Git URL (always prompts for new URL)
Najpierw należy dostarczyć Dockerfile na klaster - skopiować z własnego systemu poprzez SCP, wkleić w pusty plik utworzony ręcznie albo pobrać z sieci. Ten Dockerfile nie może korzystać z kontekstu. Przy potrzebie użycia kontekstu (e.g. polecenia ADD, COPY) należy umieśćic plik Dockerfile w repozytorium git (sekcja niżej)
Za pomocą wyżej wspomnianego skryptu sub z opcją -l albo --local-dockerfile można zlecić zadanie do systemu kolejkowego SLURM:
$ sub-k8s-buildtainer.sh -l ./Dockerfile
Submitted batch job <job_id>
Należy utworzyć repozytorium git - n.p. na naszym git.e-science.pl. Jeśli to repozytorium jest prywatne - należy wygenerować access token.
Następnie, należy uruchomić skrypt sub z opcją -g albo --git, co przy pierwszym uruchomieniu skutkuje dialogiem konfiguracyjnym:
$ sub-k8s-buildtainer.sh -g
Enter Git repository HTTPS URL (with credentials if needed): https://***:***@git.example.com/user/example.git
Enter Dockerfile path within repo (Default: ./Dockerfile):
Submitted batch job 710
Dane dotyczące repozytorium (czyli link HTTPS z ewentualnymi poświadczeniami w postaci Basic HTTP Auth oraz ścieżka relatywna do Dockerfile) zostaną zapisane do pliku ~/.buildtainer w katalogu domowym i zostaną użyte automatycznie przy każdym kolejnym uruchomieniu skryptu sub z flagą -g albo --git. Przy potrzebie zmiany tych danych należy uruchomić skrypt sub z flagą -gc albo --git-force-configure - to uruchomi dialog konfiguracyjny ponownie i umożliwi wpisanie nowego repozytorium i/albo nowej ścieżki do Dockerfile.
Dla prywatnych repozytoriów należy wykorzystywać tokeny dostępu - przetestowano tokeny dostępu projektowe oraz tokeny dostępu personalne. Tokeny należy podawać jako hasła w Basic HTTP Auth (czyli zgodnie z formatem przedstawionym w wiadomości --help).
W trakcie zadania można przeglądać logi na żywo - w pliku k8s-build-<job_id>.out (okres pobierania logów - ok. 5 sekund) podobnie do większości innych zadań wsadowych w systemie SLURM. Śledzić te logi można za pomocą polecenia tail -F k8s-build-<job_id>.out.
W przypadku skutecznego zakończenia zadania w katalogu roboczym pojawi się plik obrazu apptainer (.sif) z nazwą w formacie: image_<job_id>.sif
Taki obraz można uruchomić zgodnie z instrukcjami dostępnymi w artykule o Apptainer.