Multiple additions and switch to png images

content/advanced_running_containers.rst

@@ -20,7 +20,7 @@ This is done via method called **mount binding**.
 Binding means that a folder from the host system is mapped into a folder
 inside the container.
 
-.. figure:: img/default_mounts.svg
+.. figure:: img/default_mounts.png
 
    Figure 1: Only some folders are mounted by default
 
@@ -39,7 +39,7 @@ The following would bind folder ``/scratch`` from the host system to
 
    $ apptainer exec --bind /scratch example.sif ls /scratch
 
-.. figure:: img/bind_example.svg
+.. figure:: img/bind_example.png
 
    Figure 2: Binding a directory inside a container
 
@@ -86,6 +86,10 @@ Now when we launch the image, we can give the image GPU access with
 
    $ apptainer exec --nv pytorch-cuda.sif python -c 'import torch; print(torch.cuda.is_available())'
 
+.. figure:: img/nv_example.png
+
+   Figure 3: Enabling NVIDIA's GPUs in containers
+
 .. admonition:: Expected result
    :class: dropdown
 
@@ -96,6 +100,8 @@ Now when we launch the image, we can give the image GPU access with
       $ apptainer exec --nv pytorch-cuda.sif python -c 'import torch; print(torch.cuda.is_available())'
       True
 
+
+
 Using AMD's GPUs
 ****************
 
@@ -107,6 +113,10 @@ As an example, let's get a ROCm-enabled PyTorch-image:
 
    $ apptainer pull pytorch-rocm.sif docker://docker.io/rocm/pytorch:rocm6.1_ubuntu22.04_py3.10_pytorch_2.1.2
 
+.. figure:: img/rocm_example.png
+
+   Figure 4: Enabling AMD's GPUs in containers
+
 Now when we launch the image, we can give the image GPU access with
 
 .. code-block:: console
@@ -116,7 +126,7 @@ Now when we launch the image, we can give the image GPU access with
 .. admonition:: Expected result
    :class: dropdown
 
-   If you run this in a system with an NVIDIA GPU, you should see the following result:
+   If you run this in a system with an AMD GPU, you should see the following result:
 
    .. code-block:: console
 

content/basics_running_containers.rst

@@ -6,6 +6,49 @@ Basics of running containers
    * Learn what methods are available to run a container
 
 
+Different ways you can run your containers
+------------------------------------------
+
+You can run your container in multiple different ways:
+
+- You can run the container as a single application
+- You can get an interactive terminal in the container
+- You can run an application from within the container
+
+
+We'll cover these ways in this individual sections.
+
+
+How to read Apptainer commands?
+-------------------------------
+
+Apptainer's commands can sometimes have multiple flags
+which can make it hard to parse the command line.
+
+A typical apptainer command has:
+
+1. ``apptainer`` is at the start because we use the
+   Apptainer client to run the commands.
+2. A subcommand (like ``pull``, ``build``, ``exec``, ``run`` etc.)
+   that tells which Apptainer feature we want to use.
+3. Often after the subcommand we have the name of the image we
+   want to use.
+4. At the end we might have additional commands that Apptainer
+   ignores.
+
+For legibility reasons many commands in this lesson are highlighted
+in this format:
+
+.. figure:: img/apptainer_example.png
+   :width: 100%
+
+   Figure 1: How apptainer-commands are highlighted
+
+
+For the comprehensive list of client commands, see
+`Apptainer CLI reference page <https://apptainer.org/docs/user/latest/cli.html>`__.
+
+
 Obtaining a container from container registry
 ---------------------------------------------
 
@@ -19,8 +62,6 @@ Let's create the container image with the following command:
 
 .. code-block:: console
 
-   $ mkdir apptainer_cache
-   $ export APPTAINER_CACHEDIR=$PWD/apptainer_cache
    $ apptainer pull python.sif docker://python
 
 We'll talk about container images and image building later on.
@@ -31,7 +72,8 @@ Running the container
 ---------------------
 
 Running the container means that we run some specific program
-that the image creator has considered to be especially important.
+that the image creator has decided to be the main program for
+this image.
 
 When we run the container we will execute a so-called entry script
 or runscript that contains commands specified by the image creators.
@@ -61,9 +103,10 @@ Let's run the Python container image:
 
 You should read the command line like this:
 
-.. figure:: img/run_example.svg
+.. figure:: img/run_example.png
+   :scale: 50%
 
-   Figure 1: A simple run command
+   Figure 2: A simple run command
 
 This syntax might seem self-evident, but in more complex use cases we will give
 additional flags to various parts of the command.
@@ -92,9 +135,10 @@ We can launch an interactive shell in a container with
 
 You should read the command line like this:
 
-.. figure:: img/shell_example.svg
+.. figure:: img/shell_example.png
+   :scale: 50%
 
-   Figure 2: Launch a shell in a container
+   Figure 3: Launch a shell in a container
 
 
 Running a single program from the container
@@ -123,9 +167,10 @@ Let's check the Debian version in the container:
 
 You should read the command line like this:
 
-.. figure:: img/exec_example.svg
+.. figure:: img/exec_example.png
+   :scale: 50%
 
-   Figure 3: Launch a program in a container
+   Figure 4: Launch a program in a container
 
 
 Review of this session