diff --git a/docs/docs.json b/docs/docs.json index 1b9e62432..fae32d2bd 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -22,8 +22,7 @@ "group": "Introduction", "pages": [ "readme/introduction", - "readme/howitworks", - "readme/feedback" + "readme/howitworks" ] }, { diff --git a/docs/readme/feedback.mdx b/docs/readme/feedback.mdx deleted file mode 100644 index 9cbb08763..000000000 --- a/docs/readme/feedback.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Feedback" ---- - -We are always looking at feedback and suggestions from the community. If something is missing, if you have a feature request, or if something isn't working as it is supposed to, -please tell us. We are always keen on thoughts/feedback. - - -Head over to [Github](https://github.com/diggerhq/digger/blob/develop/docs/readme/feedback.mdx) and raise a PR to add your feedback below (Optionally link to a github issue if you find it is relevant to your feedback) - -## To-do list (Issues, feedback and feature requests) - -1. Terraform file for the initial condiguration to setup S3 bucket and dynamo DB for [state management](https://github.com/diggerhq/digger/issues/206). - -2. Decouple auth from [frontegg](https://github.com/diggerhq/digger/issues/1074). \ No newline at end of file diff --git a/docs/readme/howitworks.mdx b/docs/readme/howitworks.mdx index c8cc97c26..3706079dd 100644 --- a/docs/readme/howitworks.mdx +++ b/docs/readme/howitworks.mdx @@ -2,19 +2,39 @@ title: "How it works" --- -Digger has 2 main components: +Before OpenTaco the project was called digger and it consisted of purely a piece for PR automation. This engine was responsible for +integrating with github actions and running CI jobs with terraform in response to certain events. We call this the PR Automation or "orchestrator" service. -- A CLI agent that runs in your CI and interacts with Terraform CLI -- An orchestrator backend that responds to events from GitHub and triggers CI jobs +The same engine now became part of the OpenTaco suite and continues to be improved. -When a PR is opened, Digger starts a CI job that runs `terraform plan` and posts plan output as comment. You can then comment "digger apply" to run `terraform apply`. Digger can also be configured to run apply only after the PR has been merged; to check plan output against OPA policies; to run drift detection on schedule; and so on. +The OpenTaco architecture consists of these components: -The orchestrator backend does not have access to your cloud account, or terraform states, or plan output, or tfvars, or any other sensitive data. It just triggers CI jobs; your sensitive data never leaves the high-trust environment of your CI. For this reason, there is little reason to self-host the backend of Digger (although you still can). Much easier to use the managed cloud version of the orchestrator. +- Statesman: Offers states management and remote runs capabilities +- Drift: All drift detection capabilities including detection and remediation +- Token: A token validation service (internal) +- Orchestrator (formerly digger): Responsible for starting and stopping CI Jobs, currently responsible for all of PR automation. +- UI: the UI layer, also acts as a gateway proxy to the other services - -Digger can also run as a standalone GitHub Action without a backend. In this case: -- comments and status checks will be updated with a delay -- all applies will run sequentially in one job without concurrency -- clashing applies from other jobs will fail as they cannot be queued -- buckets / tables for PR-level locks need to be configured manually in your cloud account - +```mermaid +flowchart LR + subgraph Clients + dev[Developer / User] + end + + subgraph OpenTaco + ui[UI
• Gateway proxy
• Token validation] + + subgraph Backend Services + orch[Orchestrator
• Start/stop CI jobs
• PR automation] + states[Statesman
• State mgmt
• Remote runs] + drift[Drift
• Drift detection
• Remediation] + end + end + + dev -->|HTTP / Browser| ui + + %% Forward validated requests internally + ui --> orch + ui --> states + ui --> drift +``` diff --git a/docs/readme/introduction.mdx b/docs/readme/introduction.mdx index ff2b2fa2d..060bd88e3 100644 --- a/docs/readme/introduction.mdx +++ b/docs/readme/introduction.mdx @@ -1,49 +1,26 @@ --- -title: "About Digger" -description: "Digger is an open-source CI/CD orchestrator for Terraform" +title: "About OpenTaco" +description: "OpenTaco is an all-in-one Toolkit for Terraform" --- -- Unlike application code, terraform code has state. This makes CI/CD for it [painful](https://itnext.io/pains-in-terraform-collaboration-249a56b4534e) -- You could use a dedicated CI like Terraform Cloud or Atlantis, known as [TACOs](https://itnext.io/spice-up-your-infrastructure-as-code-with-tacos-1a9c179e0783) -- But then you end up duplicating your CI/CD infrastructure - compute, jobs, logs etc -- And you need to give it admin access to your cloud accounts - - - ## Want to get started quickly? - -

- Get started with Digger in minutes. -

+ +

Get started with OpenTaco in minutes.

 +## An All-in-One Terraform Toolkit +OpenTaco is a comprehensive solution that brings together everything you need to manage Terraform workflows effectively: +**State Management**: Built-in state management with RBAC, validation, and cross-account access. The state manager provides versioning and rollback capabilities. +**PR Automation**: Automatically run `terraform plan` on pull requests and post results as comments. Apply changes automatically within the PR, configure apply-on-merge workflows, and enforce approval requirements. OpenTaco handles PR-level locking to prevent conflicts between concurrent changes. +**Remote Runs**: Execute Terraform commands remotely and stream logs back to your terminal or CI system (using the TFE protocol) -## Run Terraform in your CI - -Digger spins up jobs in your existing CI instead of running its own CI-like infrastructure. This is: -- More scalable, because the on-demand compute of your CI is reused -- More secure, because your sensitive data never leaves the CI job - -## Compared to Atlantis -- No need to host and maintain a server -- Secure by design -- Scalable compute with jobs isolation -- Role-based access control via OPA - -Read more about differences with Atlantis in our [blog post](https://medium.com/@DiggerHQ/digger-and-atlantis-key-differences-c08029ffe112) - -## Compared to Terraform Cloud and other TACOs -- Open source -- No duplication of the CI/CD stack -- Secrets not shared with a third party - -## Support for other CI's - -We are currently designing Digger to be Multi-CI, so that in addition to GitHub Actions, you can run Terraform/OpenTofu within other CI's such as Gitlab CI, Azure DevOps, Bitbucket, TeamCity, Circle CI and Jenkins, while still having the option to orchestrate jobs using Digger's [Orchestrator Backend](https://docs.digger.dev/self-host/deploy-docker). - -Read more in this [blog](https://blog.digger.dev/how-we-are-designing-digger-to-support-multiple-ci-systems/), and please share your requirement on [Slack](https://bit.ly/diggercommunity) if you require support for other CI's. Your feedback/insight would help us a lot as this feature is in active development. \ No newline at end of file +**Drift Detection**: Continuously monitor your infrastructure for configuration drift. Schedule automated scans that detect changes and create GitHub issues for remediation.