keep changes in the container for later use

[koraykoca]

Hello everyone,

I cannot save my changes in docker containers when I run them with rocker. It always creates a new container with a different id. I need to enter the same container to be able to reach my previous installed libraries, folders etc. I made followings for this purpose:

I want to use Autoware Universe and followed the instructions on the website.
I created a docker container with rocker command from the image 'ghcr.io/autowarefoundation/autoware-universe:latest' with this command:

rocker -e LIBGL_ALWAYS_SOFTWARE=1 --x11 --user --name aw-universe --noclean \
--volume $HOME/autoware \
--volume $HOME/adehome/workspace:$HOME/workspace  \
--volume $HOME/adehome/pycharm:$HOME/pycharm \
-- ghcr.io/autowarefoundation/autoware-universe:latest

It says successfully built 72c229086e34. The output of 'docker container ls' is:

Then I built the scenario simulator in the container (aw-universe). The prompt in the terminal is koray@72c229086e34 and I can run the simulation without problem.

When I exit from the container (aw-universe) and then enter it with the command 'docker start aw-universe', there is this error:
Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/tmp/.docker9dh_w1co.xauth" to rootfs at "/tmp/.docker9dh_w1co.xauth" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Since I couldn't enter the container, I tried to generate a new image from the container using the command docker commit aw-universe aw-universe-i. So, I saved the modified container as a new image, to be able to create new containers later from this image and not install the libraries, folders every time. The output of the command docker images is now:

As you see, the newly created image is larger than the original one.

When I create a new container using aw-universe-i:

 rocker -e LIBGL_ALWAYS_SOFTWARE=1 --x11 --user --name aw-universe2 --noclean \
--volume $HOME/autoware \
--volume $HOME/adehome/workspace:$HOME/workspace  \
--volume $HOME/adehome/pycharm:$HOME/pycharm \
-- aw-universe-i

it says successfully built fbc79a0e2e3f. However, the prompt in the terminal is bash-5.0 now, which is supposed to be koray@fbc79a0e2e3f. And when I try to run the simulation, it says PermissionError: [Errno 13] Permission denied: '/home/koray/.ros'

My question is: How can I keep the changes in the container properly to use them later, or how can I start the saved container, which is generated with rocker?.

Thank you in advance.

[brkay54]

Did you try to add $HOME as a volume? Maybe it can solve your PermissionError: [Errno 13] Permission denied: '/home/koray/.ros' problem.

[koraykoca]

Hi, thank you for the answer. You're right, adding --home flag to the command solved this problem. However, with this solution, I always need to commit the container and create an image, after every change. Then I need to create a new container from that new image. This shouldn't be like that. I should be able to start the same container with docker start (or rocker start, but there is no command like that) command. Do you have an idea about it?

[kenji-miyake]

@koraykoca
I believe it is generally not recommended that you edit/commit a Docker container.
Instead, you have to provided containers as they are.
Considering your changes with the Docker image, there are several ways to resolve this.

1. Include scenario_simulator (simularot.repos) into the autoware-universe image.

To do this, we have to either:

• Resolve Import SmartWatch Application #21.
• Add a flag whether to include scenario_simulator or not, and enable the flag only for amd64.

I personally would like to avoid this option because the dependency will increase and it makes maintenance difficult.

2. Run scenario_simulator from a different Docker image.

I guess you can use this image.
In this case, you don't have to build scenario_simulator inside the autoware.universe image.

(The documentation should be updated to support Docker.)

@WJaworskiRobotec @hakuturu583 What do you think about this option?

3. Extend the autoware-universe image in your local machine before using rocker.

Please refer to the example of .devcontainer/Dockerfile in https://github.com/autowarefoundation/autoware/blob/0817e56d8ac2041580b19a2fbff62e1b9d877f6f/docker/README.md#precautions-for-not-using-rocker

[kenji-miyake]

In short, my recommendation is:

• If your changes are only for scenario_simularot_v2, use option 2.
• If you have other changes, use option 2 for scenario_simularot_v2 and 3 for other changes.

[koraykoca]

thank you for your answer @kenji-miyake. I could try your suggestions now (because of illness).

For the option 2, I don't know how to run autoware launch files in the simulator container, because Autoware is not installed in the simulator container, in that case, it looks like I need to build Autoware in the simulator container to be able to run for example planning_simulator.launch.xml from the autoware_launch package.

That's why, to solve the simulation issue, option 3 seemed the easiest way, and we did it. I think it would be nice, also for others, to create an optional tag to select an image with the simulator. There are only two lines which have to be added to the Dockerfile, and it will not create a lot of dependencies, I think.

For other changes, we just created our own container.

[kenji-miyake]

For the option 2, I don't know how to run autoware launch files in the simulator container, because Autoware is not installed in the simulator container, in that case, it looks like I need to build Autoware in the simulator container to be able to run for example planning_simulator.launch.xml from the autoware_launch package.

You have to launch 2 containers, one is Autoware and another is scenario_simulator.
And communicate between the containers.

There are only two lines which have to be added to the Dockerfile, and it will not create a lot of dependencies, I think.

Yes, it's possible, but there is a problem that scenario_simularor_v2 doesn't support ARM build yet (without manually building the dependent library).
#21

[koraykoca]

You have to launch 2 containers, one is Autoware and another is scenario_simulator. And communicate between the containers.

I did like that, from universe container I launched the launch file and from the simulator container I launched only rviz. It didn't work somehow, but it's not so important right now, we could find a workaround for our case. Thank you for your answers.