From a009e321a78210a2fed9fbee8c81a4485699ee96 Mon Sep 17 00:00:00 2001 From: Ali Khajeh-Hosseini Date: Mon, 19 Feb 2024 22:53:43 +0300 Subject: [PATCH] docs: add test step (#182) --- README.md | 183 +----------------------------------------------------- 1 file changed, 1 insertion(+), 182 deletions(-) diff --git a/README.md b/README.md index dd04deb..15f1328 100644 --- a/README.md +++ b/README.md @@ -155,188 +155,7 @@ jobs: INFRACOST_API_KEY: ${{ secrets.INFRACOST_API_KEY }} ``` -5. Test the integration using the following steps: - - 1. In your infra-as-code repo, create a new branch "infracost_test". - 2. In the test branch, add a new file called `infracost_test.tf` at the repo root with the following example Terraform code. -
Example AWS Terraform code - - ```hcl - provider "aws" { - region = "us-east-1" - skip_credentials_validation = true - skip_requesting_account_id = true - access_key = "mock_access_key" - secret_key = "mock_secret_key" - } - - resource "aws_instance" "my_web_app" { - ami = "ami-005e54dee72cc1d00" - - instance_type = "m3.xlarge" # <<<<<<<<<< Try changing this to m5.xlarge to compare the costs - - tags = { - Environment = "production" - Service = "web-app" - } - - root_block_device { - volume_size = 1000 # <<<<<<<<<< Try adding volume_type="gp3" to compare costs - } - } - - resource "aws_lambda_function" "my_hello_world" { - runtime = "nodejs12.x" - handler = "exports.test" - image_uri = "test" - function_name = "test" - role = "arn:aws:ec2:us-east-1:123123123123:instance/i-1231231231" - - memory_size = 512 - tags = { - Environment = "Prod" - } - } - ``` - - In the above example, the Infracost pull request comment points out that: - 1. The `root_block_device` defaults to AWS `gp2` since `volume_type` has not been specified. You should consider using `gp3` as it enables you to define performance independent of storage capacity, while providing up to 20% lower price per GB. - 2. Also, the `m3` instance type is previous generation and should be upgraded to `m5` since that gives you a 27% saving for a more performant machine. - -
- -
Example Azure Terraform code - - ```hcl - provider "azurerm" { - skip_provider_registration = true - features {} - } - - resource "azurerm_linux_virtual_machine" "my_linux_vm" { - location = "eastus" - name = "test" - resource_group_name = "test" - admin_username = "testuser" - admin_password = "Testpa5s" - - size = "Standard_F16s" # <<<<<<<<<< Try changing this to Standard_F16s_v2 to compare the costs - - tags = { - Environment = "production" - Service = "web-app" - } - - os_disk { - caching = "ReadWrite" - storage_account_type = "Standard_LRS" - } - - network_interface_ids = [ - "/subscriptions/123/resourceGroups/testrg/providers/Microsoft.Network/networkInterfaces/testnic", - ] - - source_image_reference { - publisher = "Canonical" - offer = "UbuntuServer" - sku = "16.04-LTS" - version = "latest" - } - } - - resource "azurerm_service_plan" "my_app_service" { - location = "eastus" - name = "test" - resource_group_name = "test_resource_group" - os_type = "Windows" - - sku_name = "P1v2" - worker_count = 4 # <<<<<<<<<< Try changing this to 8 to compare the costs - - tags = { - Environment = "Prod" - Service = "web-app" - } - } - - resource "azurerm_linux_function_app" "my_function" { - location = "eastus" - name = "test" - resource_group_name = "test" - service_plan_id = "/subscriptions/123/resourceGroups/testrg/providers/Microsoft.Web/serverFarms/serverFarmValue" - storage_account_name = "test" - storage_account_access_key = "test" - site_config {} - - tags = { - Environment = "Prod" - } - } - ``` - - In the above example, the Infracost pull request comment points out that: - 1. The `Standard_F16s` instance type is previous generation and should be upgraded to `Standard_F16s_v2`, since that gives you a more performant machine at a lower cost. - 2. The App Service plan SKU name should be upgraded to a v3 plan, such as `P0v3`, since that gives you more performance and is eligible for savings plans and reserved instance pricing, opening opportunities for major savings. - -
- -
Example Google Terraform code - - ```hcl - provider "google" { - region = "us-central1" - project = "test" - } - - resource "google_compute_instance" "my_instance" { - zone = "us-central1-a" - name = "test" - - machine_type = "n1-standard-16" # <<<<<<<<<< Try changing this to n1-standard-32 to compare the costs - network_interface { - network = "default" - access_config {} - } - - boot_disk { - initialize_params { - image = "debian-cloud/debian-9" - } - } - - scheduling { - preemptible = true - } - - guest_accelerator { - type = "nvidia-tesla-t4" # <<<<<<<<<< Try changing this to nvidia-tesla-p4 to compare the costs - count = 4 - } - - labels = { - environment = "production" - service = "web-app" - } - } - - resource "google_cloudfunctions_function" "my_function" { - runtime = "nodejs20" - name = "test" - available_memory_mb = 512 - - labels = { - environment = "Prod" - } - } - ``` - - In the above example, the Infracost pull request comment points out that the `n1-standard-16` instance type is previous generation and should be upgraded to something like `n2-standard-16` as that gives you a more performant machine. - -
- 3. Commit and push the change. - 4. Send a pull request from the test branch into main/master (don't worry we won't merge it!). - 5. 🎉 That's it! You should see a pull request comment showing the cost estimate as well as FinOps best practices that could be considered. - 6. Feel free to change other things in the `infracost_test.tf` file. The pull request comment gets updated when new changes are pushed, e.g. the 📉 and 📈 emojis will update when costs decrease or increase. Close the pull request when you are done testing. +5. Follow [these simple steps](https://www.infracost.io/docs/infracost_cloud/get_started/#4-send-a-pull-request) to test the integration. This is important as it ensures the CLI commands are running correctly in your workflow 👌 6. [Infracost Cloud](https://dashboard.infracost.io) is our SaaS product that builds on top of Infracost open source. It enables team leads, managers and FinOps practitioners to setup [tagging policies](https://www.infracost.io/docs/infracost_cloud/tagging_policies/), [guardrails](https://www.infracost.io/docs/infracost_cloud/guardrails/) and [best practices](https://www.infracost.io/docs/infracost_cloud/cost_policies/) to help guide the team. For example, you can check for required tag keys/values, or suggest switching AWS gp2 volumes to gp3 as they are more performant and cheaper.