Could not locate Gemfile or .bundle/ directory in Docker container when mounting current directory containing config dir

Terraspace
1

When I run the following command to get a bash prompt in a docker container:

docker run --rm -ti boltops/terraspace:1.1.5-ubuntu

I can successfully run the terraspace command.

However, when I run this instead:

docker run --rm -ti -v $(pwd):/root/work -w /root/work boltops/terraspace:1.1.5-ubuntu

and then run terraspace (from the /root/work directory), I get the following:

Could not locate Gemfile or .bundle/ directory

However, if I change directory out of the specified workdir (/root/work), I can successfully run terraspace.

This indicates to me that there is something in my host machine’s current directory that is somehow interfering with terraspace, so to determine what that might be, I removed everything from the host’s current directory except for the app and config directories containing my terraspace files.

That still caused terraspace to produce the same message as above.

However, as soon as I renamed the config directory to something else, terraspace worked!

Of course, attempting to run terraspace build with my config directory renamed to something else, I then got the following error:

ERROR: It doesnt look like this is a terraspace project. Are you sure you are in a terraspace project?

(BTW: notice that in the error message, “doesnt” is missing the apostrophe.)

How am I supposed to get terraspace to work inside of Docker with the app and config directories that Terraspace requires?

2

It appears that this is due to the presence of the file config/app.rb because /usr/local/bin/terraspace is this:

#!/bin/bash
unset GEM_HOME
unset GEM_PATH
export PATH=/opt/terraspace/embedded/bin:$PATH
if [ -f config/app.rb ]; then
  exec bundle exec terraspace "$@"
else
  exec terraspace "$@"
fi

The contents of config/app.rb is simply this:

Terraspace.configure do |config|
  config.logger.level = :info
  config.test_framework = "rspec"
end

Why would I need a Gemfile? (Note: I have almost no Ruby experience.)

3

Glad you were able to find that /usr/local/bin/terraspace wrapper. Yes, it’s part of the standalone installer used by the Terraspace Docker images. Killing two birds with one stone by using standalone installers for the Terraspace Docker images.

Docs for the wrapper are here https://terraspace.cloud/docs/install/standalone/details/path/ and here https://terraspace.cloud/docs/install/shim/#standalone-installer-shim The wrapper/shim ensures that bundle exec is prepended. So bundle exec terraspace is used vs terraspace when within a Terraspace project folder.

The Gemfile is used within the Terraspace project folder to pin down exact versions of gem dependencies. The Gemfile and Gemfile.lock concept is similar to package.json and package-lock.json in the nodejs world and sort of like requirements.txt and pyenv in the python world. These projects seem to inspire each other.

Docs with more details on why it’s needed: https://terraspace.cloud/docs/install/shim/#long-answer-why-bundle-exec Also related here https://terraspace.cloud/docs/install/gem/multiple-versions/

This is mentioned in the docs, but surfacing for convenience. Internally to Terraspace, it also runs the SDK version of bundle exec to load Gemfile.lock. Terraspace does this to discover what terraspace plugin the project is using. IE: terraspace_plugin_aws, terraspace_plugin_azurerm, terraspace_plugin_google. Depending on the plugin, different helper methods are available, and different expansions variables are available for backend.tf