Codification

Firefly's Codification feature is one of its most powerful capabilities: it allows you to automatically convert existing cloud resources into Infrastructure-as-Code definitions. In other words, Firefly can generate Terraform/Pulumi/CloudFormation code (and more) for resources that were created manually or that lack IaC, bringing them under management. This section will cover an overview of codification, supported formats, advanced features, and a step-by-step guide to using it effectively.

Overview of Codification

Codification in Firefly refers to the process of taking an unmanaged asset (a resource created via ClickOps or otherwise outside of IaC) and producing the code needed to manage that asset going forward (IaC status | Firefly Documentation Portal). Firefly's scanner discovers all your cloud resources; for those not already tracked in an IaC state, you have the option to codify them. When you run codification, Firefly will output the infrastructure-as-code representation (for example, a Terraform configuration file with the equivalent resource block for that asset, including its current settings). The goal is to help you achieve 100% IaC coverage by generating code for everything running in your cloud.

Firefly not only generates basic resource code, but also captures dependencies and configurations. For instance, if you codify an AWS EC2 instance, Firefly will also identify related resources (like attached EBS volumes, network interface, security groups) and can include those in the code or at least reference them appropriately. This holistic approach ensures that the generated IaC is viable and not missing context.

Codification is extremely useful during cloud cleanup or onboarding phases. Imagine you inherit an environment where many resources were created through the console. Instead of manually writing Terraform for each, you use Firefly to scan and generate the Terraform automatically (Stop ClickOps: 3 Steps to Clean Up Your Cloud). You can then review the code, tweak if necessary, and commit it – turning previously unmanaged infra into code-managed infra.

Supported IaC Formats

Firefly supports codification to multiple Infrastructure-as-Code frameworks. This flexibility lets you adopt the format that your team is comfortable with. The supported IaC formats include:

Terraform: Firefly can generate HCL code (Terraform configurations). This is one of the primary targets, since Terraform is widely used. It can output .tf files representing your resources, and even Terraform modules (if you choose to structure code that way).

Pulumi: Firefly can output Pulumi code (in supported languages like TypeScript or Python) that represents your resources. So if your organization prefers Pulumi for IaC, Firefly can on-board resources into Pulumi stacks.

CloudFormation: Firefly can generate AWS CloudFormation templates (YAML/JSON) for your resources. This is useful for AWS users who rely on CloudFormation or tools like AWS CDK.

AWS CDK: Rather than a raw CloudFormation template, Firefly can also generate AWS CDK code in languages like TypeScript, if desired (Contacting Firefly support | Firefly Documentation Portal). This gives a more programmatic IaC option on AWS.

Crossplane: Firefly supports outputting configurations for Crossplane (a Kubernetes-based IaC for multi-cloud), allowing you to manage cloud resources as Kubernetes custom resources (Contacting Firefly support | Firefly Documentation Portal).

Helm & Kubernetes Manifest: For Kubernetes resources or cloud resources represented in K8s, Firefly can create Helm charts or raw Kubernetes manifests (YAML) (Contacting Firefly support | Firefly Documentation Portal). This is handy if you want to manage configuration via GitOps in a cluster.

Ansible: Firefly can even generate Ansible playbook tasks or roles to manage the discovered resources (Contacting Firefly support | Firefly Documentation Portal). This is beneficial if your ops automation is Ansible-centric.

Config Connector (Google Cloud): Firefly supports Google's Config Connector format, which allows managing GCP resources via Kubernetes CRDs (Contacting Firefly support | Firefly Documentation Portal).

In summary, Firefly meets you where you are – whether you use Terraform, Pulumi, AWS CDK, or other frameworks, codification can output the appropriate files. You'll typically select the desired format when initiating codification (e.g., "Codify to Terraform" vs "Codify to Pulumi"). Under the hood, Firefly's intelligence maps your cloud's API data to the corresponding IaC syntax for each platform.

Each format has its nuances (for example, Terraform might use one naming convention vs. Pulumi using code in a particular language). Firefly's job is to abstract those differences and give you a ready-to-use definition. After generating, you may need to integrate the code into your repositories or pipelines, but the heavy lifting of writing the resource definitions is handled for you.

Advanced Codification Features

Beyond simply generating one-to-one resource code, Firefly's codification offers advanced features to produce clean, maintainable IaC. Key advanced features include:

Module Creation: Firefly can convert groups of resources into reusable Terraform modules (or the equivalent concept in other IaC tools). Instead of spitting out one giant file of flat resources, Firefly is smart about packaging infrastructure patterns. For example, if it detects a recurring group of resources (like a VPC with subnets, route tables, etc.), it can generate a module for that and then generate calls to that module for each instance. This means your codified assets can be DRY (Don't Repeat Yourself) and follow best practices of modular IaC design from the start. Module creation is great for building a library of infrastructure building blocks as you codify your cloud.

Module Calls Alignment: If you already use Terraform modules, Firefly can align new codified assets to those module calls. For instance, say you have an existing Terraform module for S3 buckets that your team uses in code, but someone created a bucket manually outside of Terraform. When codifying that bucket, Firefly might recognize the configuration matches your standard module's pattern. Instead of generating a standalone resource, it could suggest using a module call (with the correct parameters) to incorporate that bucket into your module usage. This feature essentially ties codified output into your existing IaC frameworks, ensuring consistency. It prevents the scenario of codifying something into a raw resource when it really should be managed as part of a module that you already maintain.

Dependency Management: Firefly's codification process handles relationships between resources. In Terraform, this could mean adding depends_on where necessary, or ordering resources properly in Pulumi/CloudFormation so that the generated stack will deploy correctly. It identifies linked resources – for example, if codifying an EC2 instance, Firefly knows to also reference the VPC and subnet it's in, the security group attached, etc. These references might be output as data sources or as separate codified resources with the appropriate dependencies. By managing dependencies, Firefly ensures the IaC it generates is deployable and mirrors the live environment's architecture (no missing pieces). This saves a lot of time – you won't have to manually chase down what connects to what; the tool assembles that for you.

Cross-Cloud Migration: A powerful outcome of codification is that once your infrastructure is represented in code, you have the option to migrate or replicate it to other environments or even other cloud providers. Firefly aids in cross-cloud migration by extracting the current state in a cloud-agnostic definition (depending on the format you choose). For example, you could codify resources from AWS and get Terraform code. With some modifications (changing provider configuration, resource types), you could use that as a blueprint to create equivalent resources in Azure or GCP. Firefly won't magically translate an AWS EC2 to an Azure VM for you (as they are different resource types), but by having everything in Terraform, you have a starting template. Many organizations use Firefly to migrate from unmanaged to managed (on the same cloud) and then optionally from one cloud to another by taking the codified templates and adapting them. Essentially, Firefly gives you the documentation-as-code needed to re-create your infra elsewhere if needed.

Continuous Codification & Drift Remediation: (Advanced usage) Firefly can be set up in workflows such that when drift is detected, it can automatically generate the code to fix the drift or to codify newly found assets. This isn't a single feature to turn on lightly, but it's worth noting that codification can be part of an automation pipeline. For example, if a developer creates a new cloud resource manually, Firefly could detect it and trigger a codification workflow to push code for that resource to Git – effectively self-healing the gap in IaC coverage. This ensures your environment stays as code without manual intervention. (This feature might involve using Firefly's APIs or custom scripting in combination with codification.)

Overall, these advanced features mean codification is not just a one-off script generator – it's an intelligent system that tries to produce usable, high-quality IaC that aligns with your best practices.

Using Codification: Step-by-Step Guide

Using Firefly's codification is straightforward. Here's a step-by-step guide to effectively codify your infrastructure:

Identify Resources to Codify: In the Firefly app, navigate to the Inventory page (or Dashboard) to find unmanaged assets. You can filter the inventory by IaC Status = Unmanaged to see all resources not currently managed by IaC (IaC status | Firefly Documentation Portal). For example, you might see a list of AWS resources that are marked as Unmanaged. Choose one or more resources that you want to manage as code going forward.

Start the Codification Process: Select the asset(s) and look for a "Codify" button or action. Firefly allows codifying single assets or multiple assets at once (e.g., codify an entire group like an AWS CloudFormation stack worth of resources). Click on "Codify assets" and if prompted, pick the target IaC format. For instance, choose Terraform if you want .tf files, or Pulumi if you prefer that, etc. Firefly might also ask you to confirm which specific resources to include (it often automatically includes dependencies).

Configure Output Options: Depending on the format, you may have a few options. For Terraform, you might choose to generate a standalone configuration versus integrate with an existing module. For CloudFormation, you might name the stack/template. If Firefly offers module suggestions (say it detects that it can create modules), you'll be able to review that. Also, if you have connected a Git repository to Firefly, at this stage you might choose a repository/branch where the code will be delivered. For example, you could select your "Infrastructure" repo and have Firefly prepare a Pull Request.

Generate IaC Code: Initiate the generation. Firefly will now translate the live configuration of those assets into code. This usually takes a short moment. After generation, Firefly will present the resulting code for review. You might see a preview of the Terraform config right in the UI. Take this opportunity to inspect the code: check resource names, parameters, and module structures. Firefly strives to use sane defaults (naming conventions etc.), but you can often edit names or reorganize if desired before finalizing. At this stage, no changes have been made to your cloud – you've only created code.

Review Dependencies and Modules: If the codification resulted in multiple files or modules, review the project structure. For example, Firefly might have created a main.tf, a variables.tf, and a module/ directory with new modules. Ensure that all necessary pieces are there. Verify that sensitive data is handled appropriately (Firefly will not include secret keys or such in plaintext, it might reference them as variables).

Export or Push the Code: Now decide how to use the code. You have a few options:

Download the code as a ZIP or copy to clipboard (if you want to integrate manually).

Automatically create a Pull Request (if you linked a VCS integration). Firefly can package the new code and open a PR against your repository with the changes (Stop ClickOps: 3 Steps to Clean Up Your Cloud). This is a great way to bring the code under version control with minimal effort. The PR will contain all the new files and a summary of what was codified.

If using the Pulumi SaaS or Terraform Cloud, you might instead take the code and add it to those systems accordingly. Firefly's role ends at generating the code; deployment is up to your pipeline.

Implement the Code in Your Workflow: Merge the Pull Request or add the code to your IaC repository. Once the code is in your main branch (and reviewed/approved by your team as needed), you should run your standard IaC deployment process. For Terraform, that means terraform plan and terraform apply using the new code. For CloudFormation, deploying the stack, etc. This step will actually create the resources in code or reconcile with existing ones. Important: When you apply the codified code, since the resources already exist, it should recognize them (because Firefly included the correct IDs and settings). In Terraform's case, you might do an import or see that the plan is empty because the state is matched – Firefly can integrate with state files to avoid duplication. Follow any additional instructions Firefly provided (sometimes Firefly might tell you to run a terraform import if it can't automatically manage state).

Verify and Mark as Managed: After a successful deployment of the codified infrastructure, check Firefly's Inventory again. The previously unmanaged resource should now appear as Codified (or at least no longer unmanaged). Essentially, Firefly will detect that the resource is now represented in an IaC state file (because you applied the code and created a state). You have effectively transitioned that asset to be managed by code. It's good practice to verify no drift is reported for it after this (the code and actual should match exactly right after apply).

Repeat and Refine: Continue codifying other resources in your cloud. It's often wise to codify in batches (perhaps by environment or resource type). As you gain more codified assets, your IaC coverage percentage will increase, and your cloud will become more standardized. If you encounter complex scenarios (like codifying an entire legacy environment), consider doing it incrementally rather than all at once, to make review easier. Leverage the advanced features: for example, after codifying, you might decide to modularize further or refactor the generated code to suit your style. Firefly's output is a starting point – you have full control to edit the code as needed since it's now in your hands.

Leverage Automation (Optional): If you have many recurring changes, you can integrate Firefly codification into a CI pipeline or use Firefly's API. For example, some teams set up a nightly job to codify any new unmanaged assets and open PRs automatically, which engineers then review the next day. This kind of automation ensures your environment stays up-to-date in code. Firefly's documentation and support can provide guidance if you choose to script codification for continuous use.

By following these steps, using Firefly's codification becomes a smooth process of turning your "ClickOps" resources into code. The end result is a more maintainable, version-controlled infrastructure. You reduce configuration drift and can apply all the benefits of IaC (peer reviews, testing, rollback, etc.) to resources that were once outside of those processes. Firefly essentially accelerates your journey to full Infrastructure-as-Code, doing in minutes what might otherwise take weeks of manual coding (Stop ClickOps: 3 Steps to Clean Up Your Cloud). Enjoy the benefits of a fully codified cloud with far less manual effort!