Atlantis Local Command

[billyshambrook]

Before creating the PR it can be helpful to run a plan while you are locally editing the terraform. One thing that is annoying is that if you are using workspaces in atlantis via the atlantis.yml config, there is currently no way of enforcing a specific workspace when running locally using the standard terraform cli, unless you are using the new terraform remote backend that only works with TFE.

What I would like to propose is a local sub command that would allow you to use the Atlantis cli to run a plan locally, using the config provided in the atlantis.yaml.

atlantis local plan -p dev

This would then run the same logic as it would if you submitted a pr comment...

atlantis -p dev

[kipkoan]

What about not using workspaces? Hashicorp advises not to do so for long lived environments. Use modules instead.

On Jun 11, 2019, at 8:10 PM, Billy Shambrook [email protected] wrote:

Before creating the PR it can be helpful to run a plan while you are locally editing the terraform. One thing that is annoying is that if you are using workspaces in atlantis via the atlantis.yml config, there is currently no way of enforcing a specific workspace when running locally using the standard terraform cli, unless you are using the new terraform remote backend that only works with TFE.

What I would like to propose is a local sub command that would allow you to use the Atlantis cli to run a plan locally, using the config provided in the atlantis.yaml.

atlantis local plan -p dev

This would then run the same logic as it would if you submitted a pr comment...

atlantis -p dev

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mdeeks]

Hashicorp advises both directories (with modules) and workspaces in their guide: https://learn.hashicorp.com/tutorials/terraform/organize-configuration (about half way down)

To separate environments with potential configuration differences, use a directory structure. Use workspaces for environments that do not greatly deviate from one another, to avoid duplicating your configurations. Try both methods in the sections below to help you understand which will serve your infrastructure best.

We almost exclusively use workspaces. A local atlantis would be extremely helpful for us.

[red8888]

This seems like it would be a non-trivial effort and overlap with tf enterprise, but it would be amazing to have.

Maybe this is outside the scope of what was asked but if you could remotely execute atlantis that would be ideal. So you arent running it locally your hitting an api and atlantis is running terraform and returning the results (I think thats how tf enterprise works). That would be nice too for things like secrets- if atlantis is deployed through k8s for example and has all the secrets injected.

Maybe this could be done by scripting out kubectl exec calls or something too I guess

[nitrocode]

This would be pretty nice to have so devs do not have to rely on the PR process to run a plan if the project is complicated.

projects:
- name: my-service-ue2-dev
  dir: components/terraform/my-service
  workspace: ue2-dev
  workflow: myworkflow
  autoplan:
    when_modified: ["**/*.tf", "tfvars/ue2-dev.tfvars"]

workflows:
  myworkflow:
    steps:
      - run: "..."
  myworkflow-new:
    steps:
      - run: "..."

Maybe atlantis local or a completely separate atlantis-cli

atlantis plan --project my-service-ue2-dev
atlantis plan --project my-service-ue2-dev --workflow myworkflow-new
atlantis plan --project my-service-ue2-dev --workflow myworkflow-new --dry-run
atlantis apply --project my-service-ue2-dev --workflow myworkflow-new --dry-run

A separate CLI would be easier to implement since it would only need to read the local repository's atlantis.yaml file

[jamengual]

now with the API this could be very possible BUT the authentication will have to be done by the user as in using an oauth2 proxy or something like that

[nitrocode]

I don't believe the user would have to authenticate if all the commands are done locally. All the user would need to have is the atlantis.yaml configuration file and the unique project name and any overrides.

For example, from the above, if the user ran this locally

atlantis plan --project my-service-ue2-dev --dry-run

It should show the following commands (use cd or -chdir depending on the terraform version)

cd components/terraform/my-service
terraform workspace select ue2-dev
terraform init
terraform plan
cd -

but perhaps this could issue can be separated into a local or remote subcommand? Where the local would only locally run the terraform workflows and remote would communicate with the atlantis API and then would require authentication as you mentioned.

atlantis local plan --project my-service-ue2-dev --dry-run
atlantis remote plan --project my-service-ue2-dev --dry-run

[jamengual]

local will have to have a full implementation of atlantis minus the VCS integration I guess and the remote will interact with a full deployed atlantis and then it will need auth somehow

[red8888]

Auth to the atlantis api would require some effort, but maybe it could default to no auth and users just control access via firewalling.

But looking at this again I realize I dont really want Atlantis local I want private terraform enterprise.

Speaking for myself I dont need any of the VCS stuff. What I want is a command to upload/scp/whatever files in my cwd to the location where terraform is executed remotely. I switch to my branch before running the command, the command itself is not VCS aware.

So thinking about a simple implementation:

• A k8s deployment with ssh port open. Container has terraform and any other tools I need installed
• The script/cli command first scps files into cwd into the running container
• Then it kubectl execs into the running container and calls terraform

Obvious security issues because you'd need admin perms.