former2
digger
former2 | digger | |
---|---|---|
11 | 86 | |
2,140 | 2,697 | |
- | 2.8% | |
7.6 | 9.9 | |
about 2 months ago | 3 days ago | |
JavaScript | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
former2
-
Top 10 terraform tools you should know about.
Former2 is a tool that automates the creation of Infrastructure-as-Code (IaC) scripts from existing AWS resources. It utilizes the AWS JavaScript SDK to scan the user’s AWS infrastructure, identifying all available resources. Users can then select from this list which resources they want to include in their IaC outputs. This process simplifies the task of writing IaC scripts, especially for complex environments, by directly converting current AWS configurations into ready-to-use code. Former2 is particularly useful for documenting existing infrastructure or for migrating manually created resources into an IaC framework.
-
[Question] Cloud formation Template Import Resources tools
More info: https://github.com/iann0036/former2
- former2
-
Importing multiple modules at once from AWS
You can use tools like https://github.com/cycloidio/terracognita or https://github.com/iann0036/former2 to generate the terraform code for you. Then you can consolidate them and if they are simply the same type of objects with different values then you can use terragrunt to pass values to your terraform module.
- Is there a way to turn a existing cloudformation template into a terraform file?
-
Overwhelmed by AWS
I have never tried out this tool, but maybe it's worth checking: you could create all the stuff via AWS Console in a sandbox environment and then try to use former2. Nothing autogenerated will ever be good enough compared to handcrafted, but it should give you a nice starting point without much effort.Such a tool can not be expected to work reliably. Thankfully, you need to cover only classic, foundational services like EC2, ELB, and IAM, so I would expect them to work properly for those use cases.
-
how reliable is it to generate a cloud formation automatically from an existing AWS environment?
Author of Former2 here.
-
Disaster Recovery with Former2?
I've heard of a few people setting up pipelines that use the CLI with the `ALL` services option to generate inventories of their systems, but the generated template would almost certainly not work out of the box due to:
- tool to log into AWS and generate Terraform code
-
Current infrastructure as code
Not quite: a command line tool is also available: https://github.com/iann0036/former2/blob/master/cli/README.md
digger
-
OpenTofu 1.7.0 is out with State Encryption, Dynamic Provider-defined Functions
None of these are a replacement of Terraform Cloud (recently rebranded to HCP Terraform). For example, when you create a PR, it could affect multiple workspaces. The new experimental version of TFC/TFE (I refuse to call it HCP!) implements Stacks, which is something like a workflow, and links one workspace output to other workspace inputs. None of the open-source solutions, including the paid Digger [0], support this - only the paid one, such as Spacelift [1] (which is the closest to TFC if you ask me). Having a monorepo of Terraform is a common design pattern, so, if I change an embedded module, it could trigger changes it many workspaces. As far as I know, Atlantis [2] can't really help in this case.
By the way, the reason I singled-out Spacelift is due to its quality, and the great Terraform provider it has. Scalr [3], for example, has a really low-quality Terraform provider. I extensively use the hashicorp/tfe provider to manage TFC itself.
[0]: https://digger.dev/
[1]: https://spacelift.io/
[2]: https://www.runatlantis.io/
[3]: https://www.scalr.com/
-
Ask HN: Should we build support for more CI platforms, or features for Actions?
Currently, Github Actions is de-facto the only fully supported CI platform in Digger, we’ve been building it as a CI-agnostic tool (https://github.com/diggerhq/digger) from get go. We keep getting requests to support more CI systems on our community slack and over Github issues (https://github.com/diggerhq/digger/issues/81).
Unlike other automation tools for Terraform, Digger doesn’t run jobs on the server; instead it uses your CI (like Actions) as a compute backend. This is more secure and also much cheaper if you use your own runners in your CI.
But each CI and each VCS is ever so slightly different; and we are now at a crossroads - Should we build support for more CI platforms, or more features for GitHub Actions? We’d love any thoughts/inputs!
-
Ask HN: Should open-source projects allow disabling telemetry?
We just had a user submit an issue and a PR to revert the changes we made earlier that remove the option to disable telemetry. We feel like it’s a fair ask to share usage data with authors of an open-source tool that’s early in the making; but the user’s viewpoint is also perfectly understandable. Are we in the wrong here?
https://github.com/diggerhq/digger/issues/1179
Surely we aren’t the first open-source company to face this dilemma. We don’t want to alienate the community; but losing visibility of usage doesn’t sound great either. Give people the “more privacy” button and most are going to press it. Is there a happy medium?
-
Terraform drift detection and remediation - a primer
Detecting and managing drift in Terraform is a multifaceted process. The use of Terraform commands such as terraform refresh and terraform plan plays a critical role in identifying drifts. Additionally, periodic monitoring of the infrastructure using these commands can aid in early detection and prevention of larger issues. Tools like Digger and Terraform Cloud offer dedicated drift detection and remediation mechanisms. These tools provide continuous monitoring and notifications, enabling teams to stay informed about the state of their infrastructure.
-
Typical challenges faced while setting up CI/CD for Terraform at scale
Star us on GitHub | Check out Docs | Blog | Slack
-
GitHub issues from top Open Source Golang Repositories that you should contribute to
I would be extremely grateful if you could give us a star & share your thoughts in the comments section below https://github.com/diggerhq/digger
-
Tools used by the top 1% of Platform Engineers and their Commercial Open Source Alternatives
Check Digger's repo on GitHub
-
5 Open Source tools written in Golang that you should know about
Digger is an Open Source Infrastructure as Code management tool that helps orchestrate IaC such as Terraform & OpenTofu within GitHub Actions. Digger reuses compute used for application code so that you don't overpay for 3rd party managed compute for IaC. This approach eliminates the duplication of CI/CD infrastructure such as compute, jobs, and logs, and reduces security concerns by keeping sensitive data within the CI job. Digger's integration with existing CI systems offers scalability by leveraging on-demand compute resources and enhances security by confining data within the existing CI environment.
-
Top 10 terraform tools you should know about.
Digger is an Open Source IaC management platform that allows you to orchestrate terraform/OpenTofu in your CI/CD system. It helps you resue async jobs infrastructure with compute, orchestration, logs, etc of your existing CI. Digger also has a pro version built on top of Digger’s community edition. Digger’s “bring your own compute” ensures that users have private runners by defualt and don’t have to pay for it additionally. Digger pro gives team leads, managers and IaC practitioners dashboards, Drift Detection, RBAC via OPA policies and concurrency so they can help guide the team.
-
Restricting apply permissions
We have this issue filed by a user and cannot quite decide internally what to do about it. It is clear that allowing everyone who comments to trigger apply is problematic. And we have this covered by the RBAC via OPA feature that allows users to set granular rego policies for who can do what. But it can also be viewed as an overkill to introduce the whole policy-as-code setup for a basic restriction like this.
What are some alternatives?
terraformer - CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code
terrakube - Open source IaC Automation and Collaboration Software.
terracognita - Reads from existing public and private cloud providers (reverse Terraform) and generates your infrastructure as code on Terraform configuration
atlantis - Terraform Pull Request Automation
aws-nuke - Nuke a whole AWS account and delete all its resources.
terrateam - Terraform automation for teams. Purpose-built for GitHub.
terraforming - Export existing AWS resources to Terraform style (tf, tfstate) / No longer actively maintained
terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
aws-multi-account-viewer - Serverless app designed for any customer with two or more accounts to view resources across accounts/regions in simple single pane of glass website
otf - An open source alternative to terraform enterprise.
driftctl - Detect, track and alert on infrastructure drift
iTorrent - Torrent client for iOS 9.3+