You can set a container to read only mode in compose with the read_only key for a given service:
version: "3.8"
services:
test:
image: busybox
read_only: true
command: sleep 999
This effectively removes the container's write layer, which means you'll get a Read-only file system error if any process attempts to write to the container`s filesystem.
If you are an image author, you certainly need to take this into account. Any location that the containerized software expects to be able to write to should be mounted as a volume. The image author should mark every such location in the Dockerfile using the VOLUME instruction. When the resulting container image runs, an anonymous volume will be attached at that location in read-write mode. At runtime, you can specify a named volume or bind mount at that same location if an anonymous volume is not appropriate.
The example you gave for a read/write usecase is logging. Docker includes its own logging subsystem that treats the stdout/stderr of the main process in the container as a log stream. This works even with the container in read-only mode, so configure your application to write its logs that way.
Other examples of a read-write requirement in a container is a database or any other system that wants to persist data to disk. That data should go into a volume instead of on the container's filesystem whether or not you utilize the read_only feature.