Step inside a container

$ grim shell

Some questions are answered faster from inside. Is the file really there, which PHP extensions are loaded, can the container reach the database, what does env say. grim shell puts you in the app container with a prompt, in the directory the code is mounted at.

For a single artisan or Composer command you do not need it: grim artisan and grim composer run one command and return.

Usage

$ grim shell               # bash in the app container
$ grim shell horizon       # the queue worker instead

Run it from the project directory, with the stack up. Leave with exit or Ctrl+D; the container keeps running.

Arguments and options

Open shell in a container

Usage

grim shell [<service>]

Arguments

What it actually does

It runs docker compose exec <service> bash with your terminal attached, and returns the exit code of the session when you leave. With no argument the service is app. Nothing is started and nothing is changed by opening the shell. What you do inside is another matter: the project directory is mounted into the container, so a file you delete there is deleted on your disk.

Pitfalls

Not every service has bash

The app, horizon and scheduler containers are built from the project's dev image and have it. nginx, redis and mailpit are small images without it, and the attempt ends with exec: "bash": executable file not found in $PATH. Use docker compose exec redis sh for those.

The stack has to be up

service "app" is not running is Docker telling you there is no container to enter. Run grim up first.

There is no database container on your machine

Locally the database runs outside the stack, so grim shell mysql finds no such service. Only a project on a shared dev box has a mysql container to step into.

After it finishes

Nothing to clean up. For a deployed app, grim remote:shell opens the same kind of session on the server.

Related spells