From c376922e21c69252d3e4ff12ab64c7461179c86b Mon Sep 17 00:00:00 2001 From: Angelo Fenoglio Date: Thu, 1 Oct 2026 13:41:10 -0300 Subject: [PATCH] Drop references to Docker and containers --- README.md | 35 ++++++++++++++++++--------------- leverage/logger.py | 2 +- leverage/modules/credentials.py | 1 - leverage/modules/tf.py | 8 ++++---- leverage/modules/tfautomv.py | 2 +- 5 files changed, 25 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index a571717..c669f7b 100644 --- a/README.md +++ b/README.md @@ -7,11 +7,9 @@ Leverage CLI is the tool used to manage and interact with any Leverage project. -It transparently handles the most complex and error prone tasks that arise from working with a state-of-the-art -infrastructure definition like our Leverage Reference Architecture. Leverage CLI uses a dockerized approach to -encapsulate the tools needed to perform such tasks and to free the user from having to deal with the configuration and -management of said tools. -Provides the means to interact with your Leverage project and allows you to define custom tasks to run. +It transparently handles the most complex and error-prone tasks that arise from working with a state-of-the-art infrastructure definition like our Leverage Reference Architecture. It understands the structure of the Leverage Reference Architecture and assists the user in their day-to-day operation. + +Leverage CLI orchestrates a set of tools used to operate in a Leverage project. Usually this means OpenTofu/Terraform, but also aws-cli, kubectl and more. Reviewing and implementing the [Binbash Leverage Landing Zone for AWS](https://leverage.binbash.co/try-leverage/) would be a very good place to start! @@ -23,10 +21,13 @@ to [this page](https://leverage.binbash.co/user-guide/leverage-cli/installation/ ### Note for migration from previous versions -If you come from Leverage CLI version <1.8.0 and want to install Leverage CLI version >= 1.8.0 keep into account the +If you come from Leverage CLI version <3.0.0 and want to use Leverage CLI version >= 3.0.0 keep into account the following. -The `build.env` file format has changed. As an example, this is the old format: +Leverage CLI no longer runs tools inside a Docker container; it executes the OpenTofu/Terraform binaries installed on +your host. Because of this, the `TERRAFORM_IMAGE_NAME`/`TF_IMAGE_NAME` and `TERRAFORM_IMAGE_TAG`/`TF_IMAGE_TAG` +parameters in the `build.env` file no longer exist. In their place, the optional `TF_BINARY` parameter specifies the path +to the OpenTofu/Terraform binary to use. As an example, this is the old format: ``` # Project settings @@ -36,8 +37,7 @@ PROJECT=bb MFA_ENABLED=false # Terraform -TERRAFORM_IMAGE_NAME=binbash/terraform-awscli-slim -TERRAFORM_IMAGE_TAG=1.1.9 +TF_IMAGE_TAG=1.5.0-0.2.0 ``` New version example: @@ -49,16 +49,19 @@ PROJECT=bb # General MFA_ENABLED=false -# Terraform -TF_IMAGE_TAG=1.5.0-0.2.0 +# OpenTofu/Terraform binary +TF_BINARY=/usr/local/bin/tofu ``` -So, if you have created a project with version <1.8.0 and want to use it with version >=1.8.0 you should: - -- remove TERRAFORM_IMAGE_NAME line -- update TF_IMAGE_TAG from this form '9.9.9' to this one '9.9.9-9.9.9'. +So, if you have created a project with version <3.0.0 and want to use it with version >=3.0.0 you should: -For the second item you can check the version [here](https://hub.docker.com/r/binbash/leverage-toolbox/tags). +- remove the `TERRAFORM_IMAGE_NAME`/`TF_IMAGE_NAME` and `TERRAFORM_IMAGE_TAG`/`TF_IMAGE_TAG` lines +- install [OpenTofu](https://opentofu.org/docs/intro/install/) or [Terraform](https://developer.hashicorp.com/terraform/install) + on your host +- optionally, set `TF_BINARY` to the path of the binary. This is useful when you have multiple versions of + OpenTofu/Terraform installed, or when the binary lives in an unconventional location. It can be an absolute path, a path starting with `~`, or a path + relative to the project root. If not set, the `tofu` or `terraform` binary is looked up in your `PATH`. Keep in mind + the binary must match the command you use: `leverage tofu` expects OpenTofu and `leverage terraform` expects Terraform. ## System requirements diff --git a/leverage/logger.py b/leverage/logger.py index 27306c9..7a178cb 100644 --- a/leverage/logger.py +++ b/leverage/logger.py @@ -174,7 +174,7 @@ def get_tasks_logger(): def _raw_logger(): """ - Provide a raw logger, in case we need to print stuff that already comes formatted (like some container logs). + Provide a raw logger, in case we need to print stuff that already comes formatted. """ logger = logging.getLogger("raw") logger.setLevel(logging.INFO) diff --git a/leverage/modules/credentials.py b/leverage/modules/credentials.py index 0de0dfd..06a83dc 100644 --- a/leverage/modules/credentials.py +++ b/leverage/modules/credentials.py @@ -253,7 +253,6 @@ def credentials(state): raise an exception If we reached the only common.tfvars scenario, we have no project name nor TF_IMAGE_TAG. - So the best chance is to read the common.tfvars directly without a container, e.g. with sed or grep """ project_config = _load_project_yaml() build_env = Path(f"{PROJECT_ROOT}/build.env") diff --git a/leverage/modules/tf.py b/leverage/modules/tf.py index 5394a69..f3e449c 100644 --- a/leverage/modules/tf.py +++ b/leverage/modules/tf.py @@ -23,8 +23,8 @@ @pass_state def tofu(state): """Run OpenTofu commands in the context of the current project. - All tofu subcommands that receive extra args will pass the given strings as is to their corresponding OpenTofu - counterparts in the container. For example as in `leverage tofu apply -auto-approve` or + All tofu subcommands that receive extra args will pass the given strings as is to the OpenTofu binary. + For example as in `leverage tofu apply -auto-approve` or `leverage tofu init -reconfigure` """ state.runner = TFRunner(binary=state.paths.tf_binary, env_vars=state.environment) @@ -34,8 +34,8 @@ def tofu(state): @pass_state def terraform(state): """Run Terraform commands in the context of the current project. - All terraform subcommands that receive extra args will pass the given strings as is to their corresponding Terraform - counterparts in the container. For example as in `leverage terraform apply -auto-approve` or + All terraform subcommands that receive extra args will pass the given strings as is to the Terraform binary. + For example as in `leverage terraform apply -auto-approve` or `leverage terraform init -reconfigure` """ state.runner = TFRunner(binary=state.paths.tf_binary, terraform=True, env_vars=state.environment) diff --git a/leverage/modules/tfautomv.py b/leverage/modules/tfautomv.py index 9f67d51..7f0bcbe 100644 --- a/leverage/modules/tfautomv.py +++ b/leverage/modules/tfautomv.py @@ -12,7 +12,7 @@ @authenticate @pass_state def tfautomv(state, args): - """Run TFAutomv commands in the context of the current project.`""" + """Run TFAutomv commands in the context of the current project.""" tf_default_args_string = " ".join(tf_default_args()) state.environment["TF_CLI_ARGS_init"] = tf_default_args_string state.environment["TF_CLI_ARGS_plan"] = tf_default_args_string