Fail to test Boundary 0.3.0 Docker image locally

Boundary
1

Hi everybody,
I’m new about Boundary Project and am trying to test it locally.
On my macOs BigSur with Docker version 20.10.7 (probably latest version …) I’m testing commands specified at GitHub page and I verified error “Couldn’t start Boundary with IPC_LOCK. Disabling IPC_LOCK, please use --privileged or --cap-add IPC_LOCK”.
The error disappears by adding the “–privileged” parameter but any command displays Boundary usage command line help:

docker run --privileged --network host -t hashicorp/boundary -p 9200:9200 -p 9201:9201 -p 9202:9202 -e 'BOUNDARY_POSTGRES_URL=postgresql://postgres:postgres@0.0.0.0:5432/postgres?sslmode=disable' boundary

Usage: boundary <command> [args]

Commands:
    accounts            Manage Boundary accounts
    auth-methods        Manage Boundary auth methods
    auth-tokens         Manage Boundary auth tokens
    authenticate        Authenticate the Boundary command-line client
    config              Manage resources related to Boundary's local configuration
    connect             Connect to a target through a Boundary worker
    database            Manage Boundary's database
    dev                 Start a Boundary dev environment
    groups              Manage Boundary groups
    host-catalogs       Manage Boundary host catalogs
    host-sets           Manage Boundary host sets
    hosts               Manage Boundary hosts
    logout              Delete the current token within Boundary and forget it locally
    managed-groups      Manage Boundary managed groups
    roles               Manage Boundary roles
    scopes              Manage Boundary scopes
    server              Start a Boundary server
    sessions            Manage Boundary sessions
    targets             Manage Boundary targets
    users               Manage Boundary users

also for this command:

docker run --privileged --network host -t hashicorp/boundary -p 9200:9200 -p 9201:9201 -p 9202:9202 -e 'BOUNDARY_POSTGRES_URL=postgresql://postgres:postgres@0.0.0.0:5432/postgres?sslmode=disable' boundary database init -config /boundary/config.hcl

How can I solve?
Thanks in advance and I’m sorry for trivial questions :wink:

2

BLUF: Try this instead –

docker run --network host -t -p 9200:9200 -p 9201:9201 -p 9202:9202 -e 'BOUNDARY_POSTGRES_URL=postgresql://postgres:postgres@0.0.0.0:5432/postgres?sslmode=disable' hashicorp/boundary boundary database init -config /boundary/config.hcl

0.3.0 changed the way Boundary’s container is built by adding an entrypoint script, patterned after the one Vault uses. Prior to this, it was not possible to start Boundary with IPC_LOCK capability in environments like Kubernetes, because of the way the Boundary container ran as a non-root user.

Starting with 0.3.0, the entrypoint script runs, checks if IPC_LOCK is both available and enabled (as you saw), and then runs the boundary command as a non-root user with the arguments the container was called with. The end result is that because we can now run the container entrypoint as root, we can both enable mlock and run Boundary as a non-root user.

One of the side effects of the entrypoint script is, that either the script has to handle bare subcommands specially, or the user/orchestrator has to specify boundary foo rather than just foo as the command to run, or the entrypoint has to assume that the first argument to the container is always a Boundary flag or subcommand (i.e. if invoked as docker run -it hashicorp/boundary /bin/sh, the entrypoint would try to run boundary /bin/sh inside the container).

Boundary has a lot of subcommands, and we don’t necessarily want to disable running non-Boundary utilities inside the container entirely or force the user to always run boundary explicitly in the container command, so we do what Vault’s entrypoint does: a certain set of subcommands gets special handling – in this case, just one: boundary server.

So if you want to run boundary server, you can still run it as docker run hashicorp/boundary server [...], but if you want to run other commands like boundary database init, you will need to specify boundary explicitly and run docker run hashicorp/boundary boundary database init [...].

Looking at your database init command line, note that although you are correctly explicitly specifying the boundary command, you have some Docker flags like -p and -e before that but after the image name – that wouldn’t work in any case, because arguments after the image name are always interpreted as command and arguments to the container, so you’re effectively trying to run this command line inside the container:

-p 9200:9200 -p 9201:9201 -p 9202:9202 -e 'BOUNDARY_POSTGRES_URL=postgresql://postgres:postgres@0.0.0.0:5432/postgres?sslmode=disable' boundary database init -config /boundary/config.hcl

Try this instead:

docker run --network host -t -p 9200:9200 -p 9201:9201 -p 9202:9202 -e 'BOUNDARY_POSTGRES_URL=postgresql://postgres:postgres@0.0.0.0:5432/postgres?sslmode=disable' hashicorp/boundary boundary database init -config /boundary/config.hcl

I just got bitten by exactly this boundary database init case earlier today while setting up a demo environment :smirk:, so I’m thinking database and dev need adding to the special handling list in the entrypoint (also, doc changes might be in order even after that change).

1 Like
3

Thanks, your help was great! :smiley:

4

The just-released 0.5.0 has the fix for this; you should now be able to docker run hashicorp/boundary [subcommand] and have it do the right thing.

1 Like