You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Singularity containers can be built at the command line from images cached locally by Docker. Suppose, for example:
521
521
@@ -564,10 +564,120 @@ results in ``lolcow_from_docker_cache.sif`` for native use by Singularity. There
564
564
565
565
.. note::
566
566
567
-
The Sylabs Cloud Remote Builder *does not* interoperate with local Docker daemons; therefore, images cached locally by Docker, *cannot* be used to bootstrap creation of SIF files via the Remote Builder service.
567
+
The Sylabs Cloud Remote Builder *does not* interoperate with local Docker daemons; therefore, images cached locally by Docker, *cannot* be used to bootstrap creation of SIF files via the Remote Builder service. Of course, a SIF file could be created locally as detailed above. Then, in a separate, manual step, :ref:`pushed to the Sylabs Cloud Singularity Library <sec:pushing_locally_available_images_to_library>`.
Singularity containers can also be built at the command line from Docker images stored locally as ``tar`` files. Suppose, for example, ``lolcow.tar`` is locally stored archive in the *current* working directory; then the contents of this archive can be revealed as follows:
In other words, it is evident that this 'tarball' is a Docker-format image comprised of multiple layers along with metadata in a JSON manifest.
609
+
610
+
.. TODO check the JSON manifest stmt above
611
+
612
+
Through use of the ``docker-archive`` bootstrap agent, a SIF file (``lolcow_tar.sif``) for use by Singularity can be created via the following ``build`` command:
There are two important differences in syntax evident in the above ``build`` command:
639
+
640
+
1. The ``docker`` part of the URI has been appended by ``archive``. This ensures Singularity seek a Docker-format image stored locally as ``lolcow.tar`` to boostrap the conversion process to SIF, as opposed to attempting to retrieve an image remnotely hosted via the Docker Hub.
641
+
642
+
2. ``sudo`` is *not* prepended to the ``build`` command for Singularity. This is *not* required if the executing user has the appropriate access privileges to the stored file.
643
+
644
+
.. note::
645
+
646
+
The Sylabs Cloud Remote Builder *does not* interoperate with locally stored Docker-format images; therefore, images cached locally by Docker, *cannot* be used to bootstrap creation of SIF files via the Remote Builder service. Of course, a SIF file could be created locally as detailed above. Then, in a separate, manual step, :ref:`pushed to the Sylabs Cloud Singularity Library <sec:pushing_locally_available_images_to_library>`.
The outcome of bootstrapping from an image cached locally by Docker, or one stored locally as an archive, is of course a locally stored SIF file. As noted above, this is the *only* option available, as the Sylabs Cloud Remote Builder does not interoperate with the Docker daemon or locally stored archives in the Docker image format. Once produced, however, it may be desirable to make the resulting SIF file available through the Sylabs Cloud Singularity Library; therefore, the procedure to ``push`` a locally available SIF file to the Library is detailed here.
655
+
656
+
From the `Sylabs Cloud Singularity Library <https://cloud.sylabs.io/library>`_, select ``Create a new Project``. In this first of two steps, the publicly accessible project is created as illustrated below:
657
+
658
+
.. image:: create_project.png
659
+
660
+
Because an access token for the cloud service already exists, attention can be focused on the ``push`` command prototyped towards the bottom of the following screenshot:
661
+
662
+
.. image:: push_prototype.png
568
663
569
-
Of course, a SIF file could be created locally as detailed above. Then, in a separate, manual step, uploaded to the Sylabs Cloud Singularity Library.
664
+
In fact, by simply replacing ``image.sif`` with ``lolcow_tar.sif``, the following upload is executed:
Finally, from the perspective of the Library, the **hosted** version of the SIF file appears as illustrated below. Directions on how to ``pull`` this file are included.
675
+
676
+
.. image:: lolcow_lib_listing.png
677
+
678
+
.. note::
679
+
680
+
The hosted version of the SIF file in the Sylabs Cloud Singularity Library is maintainable. In other words, if the image is updated lcoally, the update can be pushed to the Library and tagged appropriately.
571
681
572
682
573
683
Working with Definition Files
@@ -737,7 +847,45 @@ Then,
737
847
738
848
In other words, this is the definition-file counterpart to :ref:`the command-line invocation provided above <sec:mandatory_headers_docker_locally_boostrapped_cli>`.
739
849
740
-
.. TODO remote builder content note - exclusion
850
+
.. TODO remote builder content note - exclusion above
851
+
852
+
Alternatively when ``docker-archive`` is the bootstrap agent in a Singularity definition file, SIF containers can be created from images stored locally by Docker. Suppose the definition file ``lolcow-da.def`` has contents:
through ``build`` results in the SIF file ``lolcow_tar_def.sif``. In other words, this is the definition-file counterpart to :ref:`the command-line invocation provided above <sec:mandatory_headers_docker_locally_stored_bootstrap_cli>` .
887
+
888
+
.. TODO RB Test
741
889
742
890
743
891
Optional Headers
@@ -905,9 +1053,21 @@ In this case, the ``lolcow`` image was hosted remotely via user ``godlovedc`` at
On the other hand, if a locally stored copy of a Docker image was used to bootstrap creation of a container for Singularity, then ``inspect`` reveals existence of ``docker-archive`` in the definition file that was used as follows:
1061
+
1062
+
.. code-block:: none
1063
+
1064
+
$ singularity inspect --deffile lolcow_tar.sif
1065
+
1066
+
bootstrap: docker-archive
1067
+
from: lolcow.tar
1068
+
1069
+
The name of the archive used, ``lolcow.tar`` in this case, appears in the ``from`` header of the definition file retrieved by ``inspect``.
1070
+
911
1071
Of particular relevance to :ref:`execution precedence <sec:def_files_execution_SUB_execution_precedence>`, however, is the ``--runscript`` option for ``inspect``. For example, using the definition file above, the runscript is unsurprisingly:
0 commit comments