The docker containers can have shell scripts inside. The host machine doesn't have a shell. You can bring a docker container with a shell, and run it privileged, to have a shell on the host machine.

You can also launch an admin container and type `sudo sheltie` in it to get a root shell on the bottlerocket host OS if you need to debug things.

We've been using Bottlerocket together with its update operator on K8s for about a year now and we are really happy with it as it solves patch management by swapping out an immutable host OS image instead.

It's not uncommon to have docker containers without a shell for security reasons. For example distroless.

Or scratch containers, which work fine if you have a tool chain that can easily do static linking (GoLang, rust, for example).

The idea with Bottlerocket is that the host itself does not have a direct shell nor a way to access it via SSH or any other method. Instead this responsibility is delegated to the admin container which is where you would actually connect to via SSM/SSH. From here if you needed a root shell you would use the `sheltie` utility to do so.

Here's a diagram on the subsystems. Bottlerocket has API that can be called from a shell in a container.

      shells
        |
    containers
        |
    Bottlerocket
        |
     OS kernel

Containers which contain shell scripts also contain the shell itself. It is not typical for the host machine's shell binary to be made available to containers running on the host.

Yes, It's for worker nodes in orchestration services (k8s, ecs).