4. Play around

1. Check the logs

The output of the ds commands, besides being displayed on the screen, is also saved on a log file, for later inspection:

/var/test/app1 # tree
.
├── logs
│   └── app1-20211018.out
└── settings.sh

1 directory, 2 files

/var/test/app1 # less -r logs/app1-20211018.out

2. Get a shell inside the container

To get a shell inside the container we can use ds shell:

/var/test/app1 # ds shell
root@app1:/host# ls -lR
.:
total 8
drwxr-xr-x 2 root root 4096 Oct 18 15:08 logs
-rw-r--r-- 1 root root   53 Oct 18 12:54 settings.sh

./logs:
total 56
-rw-r--r-- 1 root root 49202 Oct 18 15:12 app1-20211018.out
root@app1:/host# cat settings.sh
APP=/var/test/scripts1
IMAGE=scripts1
CONTAINER=app1
root@app1:/host# touch test.txt
root@app1:/host# exit
/var/test/app1 # ls
logs  settings.sh  test.txt
/var/test/app1 # rm test.txt

You will notice that the directory of the container (/var/test/app1) is mounted inside the container at /host. This helps sharing of data between the container and the host, for example in the case of backup/restore. It also helps the scripts that run inside the container to easily load the container settings (by sourcing /host/settings.sh).

3. Fix the prompt of the container

Probably you noticed that the default ubuntu prompt inside the container looks kind of dull. To fix it, we can run the script ubuntu-fixes.sh inside the container, which sets a better prompt (among other things). This is done with ds inject, which copies the script inside the container and executes it from there:

/var/test/app1 # ds inject ubuntu-fixes.sh

--> Running script '/usr/local/lib/ds/inject/ubuntu-fixes.sh'
. . . . . . . . . .

If you get a container shell again, you will notice that the prompt inside the container has changed:

/var/test/app1 # ds shell

app1 root@app1:/host
==> # ls
logs  settings.sh

app1 root@app1:/host
==> # exit
exit
/var/test/app1 #

4. Use the debug options

If you wonder what docker commands ds is using behind the scenes, you can use the option -d to enable the setting SHOW_DOCKER_COMMANDS:

/var/test/app1 # ds -d stop
+ docker stop app1
app1

/var/test/app1 # ds -d start
+ docker start app1
app1

/var/test/app1 # ds -d restart
+ docker restart app1
app1

/var/test/app1 # ds -d exec ls /
+ docker ps
+ docker exec -u root -it app1 env TERM=xterm ls /
bin   dev  home  lib	lib64	media  opt   root  sbin  sys  usr
boot  etc  host  lib32	libx32	mnt    proc  run   srv	 tmp  var
/var/test/app1 # ds -d shell
+ docker exec -u root -it app1 env TERM=xterm bash

app1 root@app1:/host
==> # exit
exit
/var/test/app1 #

Or you can enable it using env variables:

/var/test/app1 # SHOW_DOCKER_COMMANDS=true ds shell

/var/test/app1 # export SHOW_DOCKER_COMMANDS=true
/var/test/app1 # ds shell

/var/test/app1 # unset SHOW_DOCKER_COMMANDS
/var/test/app1 # ds shell

Use the option -x to see all the steps that ds takes while executing a command:

/var/test/app1 # ds -x make

/var/test/app1 # ds -x -d make

/var/test/app1 # ds -x make > output.log
The options -x and -d should come right after ds and before anything else. When they are used together, -x should come before -d. This is not really flexible but that’s how it is.

5. Customize the configuration

If you now go to the container’s shell (with ds shell), you will notice that we have lost the customization of the prompt that we did before (with ds inject). This is because the command ds make creates a new container from the image and the customizations that we made to the old one are lost.

However, the command ds make calls also ds config after ds create (maybe you noticed this while trying ds -x make > output.log). We can customize ds config to fix the prompt, like this:

/var/test/app1 # mkdir cmd
/var/test/app1 # cat <<EOF > cmd/config.sh
cmd_config() {
  ds inject ubuntu-fixes.sh
}
EOF
/var/test/app1 # ds make
/var/test/app1 # ds shell

The local file cmd/config.sh, which defines the function cmd_config(), is included by ds and overrides the default cmd_config() of the framework. By the way, the default config.sh looks like this:

cmd_config_help() {
    cat <<_EOF
    config
        Run configuration scripts inside the container.
_EOF
}
cmd_config() {
    # Run configuration scripts with: # ds inject script.sh
    # Configuration scripts are located at $LIBDIR/inject/
    # or at $APPDIR/inject/ or at $CONTAINER_DIR/inject/
    :
}

You can see that it does nothing, so it’s ok to override it with a local configuration script.