Proposal of creation and deployment of custom Autoware base images

[youtalk]

Recently there ware unintended build failures of Autoware due to the update of the dependency packages.

• undefined reference to `rosbag2_storage::get_default_storage_id[abi:cxx11]()' #5089
• fix(autoware.repos): fix the morai_msgs version  #5105

These issues could have been resolved if the version control of the dependency packages had been properly managed. However, since the dependency packages for Autoware are numerous, ensuring thorough version control is extremely challenging.

Therefore, I propose creating a base image with all of Autoware's dependency packages pre-installed and using it to build the Autoware container image. If the base image is created at the appropriate time and its version is fixed inside Dockerfile, it will be possible to prevent Autoware's build from failing due to updates of the dependency packages.

The proof-of-concept code already exists as follows.

• Base image repository: https://github.com/youtalk/autoware-base-images
• Base image registry: https://hub.docker.com/r/youtalk/autoware-base/tags
• PR that use the base image to build autoware feat(docker): use autoware-base images youtalk/autoware#92

autoware-base images

There are four images for the base image, autoware-base, as follows:

• autoware-core-base: Image with dependencies of autoware-core installed
• autoware-universe-base: Image with dependencies of autoware-universe installed
• autoware-universe-cuda-base: Image with CUDA drivers additionally installed on top of autoware-universe-base
• runtime-base: Image with dependencies of runtime installed
• runtime-cuda-base: Image with CUDA drivers additionally installed on top of runtime-base

By installing the CUDA drivers in the base image as well, a layer cache of over 4GB remains valid even after running colcon build.

docker/Dockerfile using the autoware-base images

By introducing the autoware-base images, the Dockerfile will be simplified to just the running colcon build and the copying of the artifacts. Additionally, the autoware-universe image is created with the base image without CUDA drivers first, and then the autoware-universe-cuda image is created using the base image with CUDA drivers. This eliminates the need to run two separate but almost duplicate CI runners, -cuda and -no-cuda.

[youtalk]

@oguzkaganozt @xmfcx @mitsudome-r Do you have any feedback for this proposal?
As we proceed with multi-containerization, the container images will be significantly modified multiple times. Therefore, installing the dependency packages and CUDA drivers in the base image is useful for fixing the versions of the dependency packages and for caching the 4GB CUDA driver layer.

[xmfcx]

runtime-base is derived from base.

I assume you mean CUDA development dependencies when you say CUDA driver layer. (I might be wrong)

If you install CUDA driver layer to base, runtime-base will also have these heavy things on it.

Then it makes sense to have a devel-base and runtime-base separately.

And install CUDA development deps to devel-base only.

[youtalk]

The -cuda-base image installs the CUDA driver at that stage. The selection of runtime libraries for the runtime image and development libraries for the devel image remains unchanged. Additionally, CUDA drivers will not be installed on images that do not have -cuda in their name.

[oguzkaganozt]

While I agree that locking versions to ensure stable builds is a valid approach, the added redundancy of creating multiple base images and the increased complexity it introduces to the overall build pipeline do not, in my opinion, justify the trade-off.

[oguzkaganozt]

@youtalk

[youtalk]

I agree. The Dockerfile graph is becoming more complex. As a first step, how about managing the current Autoware base image as is? In this case, I also plan to create a base image with the CUDA driver installed.

[oguzkaganozt]

This sounds better to maintain and still caches the CUDA

[youtalk]

I made a PR to do this. #5159
@oguzkaganozt Please review it.