Nathan Glover’s Post

1. Start by creating a Git repository to store your Terraform configuration. 2. Make sure to include a .gitignore file in your repository with the necessary rules. 3. Keep the file structure consistent across all your Terraform projects. 4. Before committing and pushing your Terraform files, use 'terraform fmt-diff' to check and format them properly.Mohammed Adil Khan Yusufzai Jawwad Khan Junaid Khan Abdulhamid Sonaike Mohd Azmath Ullah Shareef Mohammed Numaan Ahmed Mohammed Junaid

𝗜 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗱 𝗮 𝗱𝗼𝗰𝗸𝗲𝗿 𝗼𝘂𝘁𝗽𝘂𝘁 𝗳𝗼𝗿𝗺𝗮𝘁𝘁𝗲𝗿 𝘁𝗼 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗲 `𝗱𝗼𝗰𝗸𝗲𝗿 𝗽𝘀` 𝗼𝘂𝘁𝗽𝘂𝘁 `docker ps` and `docker ps -a` are perhaps the most used commands for software engineers to view containers & their statuses. The output of these two commands is descriptive & well defined. Still, this list gets messy & bit unreadable when the number of containers increases & each containers have multiple ports mapping. This may sometimes lead to a line break of container information & the list gets a bit unreadable. That is why I thought to make a docker output formatter to view the list in a more organized way. 💫 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀: • The container list & statues are shown in a proper tabular format with proper spacing between each line to show proper separation between containers • It shows the port mappings each in a new line. So if one container has multiple port mappings, it will show you each in a comma-separated one line. This avoids the wrapping issue from the default command 🛠️ 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀: • I wrote the formatter in Go, compiled it into an executable, and placed it in my system's executable path • Then I customized my shell configuration to create a custom command `docker fps` & `docker fps -a` which stands for "formatted ps" This is a small, practical tool that helps me quickly and clearly see the status of my Docker containers. This is nothing fancy, but I found it useful for me to view my containers list & statues. 👋 Feel free to look into the Github repo & try it out if you think it might be useful for you too! Github repo: https://lnkd.in/g-eXQvEF

Day 5 Terraform fmt The terraform fmt command is used to format Terraform configuration files (*.tf) according to the standard formatting rules. This ensures that your Terraform code is consistent and easily readable. It automatically updates the indentation, spacing, and other formatting aspects to adhere to best practices. Here’s how to use it: Basic Usage: terraform fmt This will format all .tf files in the current directory. Formatting a Specific File: If you only want to format a specific file, you can specify it like so: terraform fmt path/to/your/file.tf Recursively Format All Files: To format .tf files in the current directory as well as all subdirectories, use the -recursive flag: terraform fmt -recursive Check if Files are Formatted: If you just want to check if files are properly formatted without actually changing them, you can use the -check flag: terraform fmt -check This will exit with a non-zero code if any files are not formatted correctly. Additional Options: • -write: This is enabled by default and writes the formatted output to the files. Use -write=false to disable writing to files, though this is rarely needed. Example: terraform fmt -recursive This command will ensure that all Terraform configuration files in the current directory and all subdirectories are formatted according to the Terraform style guide. Using terraform fmt is a good practice to ensure that your code remains consistent and easy to read, especially in collaborative environments.

List of pre-commit git hooks to take care of Terraform configurations!

GitHub Actions let you automate tasks like building & deploying in GitHub repos. But testing Actions can be quite a process – which is where the act CLI tool comes in. In this guide, Rajdeep shows you how to use it to run GitHub Actions locally.

TerraHash - a way to lock and verify modules in Terraform by hash. This is the Go project I alluded to earlier in the week. This is still very much a WIP. I haven't even created a build pipeline to generate binaries. Here's the problem I'm trying to address: Modules used by Terraform are not locked in any way or verified by a hash. My recommendation is to set the version constraint for a module to a specific version (e.g. version = "1.2.3") and not a range. Even if you do that, the module maintainer could (in theory) recreate the release with the same version number and different code. It's a possible attack vector or simply has the potential to break things. The solution could be similar to what the .terraform.lock.hcl file does for providers. Create a module lock file that has a hash of each module's contents and verify the hash after initialization. That's what TerraHash is meant to do. You can run it after Terraform initializes using the `terrahash init` command and it will create a lock file called .terraform.module.hcl. The `terrahash check` command verifies the module hashes against the lock file and exits with a 1 code if they don't match. The `terrahash upgrade` command updates the lock file to the current modules. There's still a lot of testing and features I need to get to. But let me know what you think! https://lnkd.in/egBDWYhs

🚀 New GitHub Project Alert! 🚀 I am excited to share that I have just completed a comprehensive GitHub Actions workflow for a 3-tier application. This project leverages GitHub Actions to automate essential CI/CD tasks, ensuring a smooth and secure software development pipeline. Key features include: ✅ Manual Workflow Trigger: Easily trigger the workflow using workflow_dispatch. ✅ Node.js Version Management: Choose from multiple Node.js versions to suit your project needs. ✅ Caching: Efficient caching mechanisms to speed up dependency installations. ✅ SonarQube Scans: Integrated SonarQube scans to ensure code quality. ✅ Security Checks: Snyk tests for both frontend and backend to identify and fix vulnerabilities. ✅ Docker Image Building: Automated Docker image builds and pushes to AWS ECR for both frontend and backend. ✅ Kubernetes Deployment Updates: Seamlessly updates Kubernetes deployment files with the latest Docker image tags. This workflow automates the essential steps to build, test, and secure codebases, streamlining the CI/CD pipeline for any project. Check out the repository on GitHub: https://lnkd.in/gWqTPEHV Feel free to explore, use, and contribute! 🚀

GitHub Actions let you automate tasks like building & deploying in GitHub repos. But testing Actions can be a long process. This is where the act CLI tool comes in. In this guide Rajdeep shows you how to use it to run GitHub Actions locally.

🔥 Advanced Terraform Commands to Level Up Your IaC Game 🔥 1. terraform taint * Purpose: Force re-creation of a specific resource by marking it as “tainted.” * Benefit: Troubleshoot or refresh a single resource without redeploying everything. * Usage: terraform taint <resource_type.resource_name> 2. terraform import * Purpose: Import existing infrastructure into Terraform’s control. * Benefit: Bring manually created resources under Terraform management. * Usage: terraform import <resource_type.resource_name <unique_resource_id> 3. terraform state * Purpose: Manage resources directly in your state file. * Usage: terraform state list - Lists all resources managed by Terraform. terraform state rm <resource_name> - Removes a resource from state without deleting it. 4. terraform console * Purpose: Open an interactive console to experiment with expressions and test configurations. * Benefit: Quickly debug, test variables, and see computed values. * Usage: Simply type terraform console 5. terraform graph * Purpose: Generate a visual diagram of resources and dependencies. * Usage: terraform graph | dot -Tpng > graph.png (requires Graphviz) 6. terraform workspace * Purpose: Manage multiple environments (like dev, staging, prod) within one configuration. * Usage: terraform workspace new <name> - Create a new environment. terraform workspace select <name> - Switch to a different environment. 7. terraform validate * Purpose: Check for syntax errors and ensure your configuration is ready for deployment. * Usage: terraform validate

Optimizing Your Terraform Projects: Best Practices for Folder Structure 🌍 Hey LinkedIn community! 👋 Managing infrastructure as code (IaC) with Terraform is a game-changer for maintaining scalable and reliable environments. One critical aspect of a successful Terraform project is having a well-organized folder structure. Here are some best practices to keep your projects tidy and maintainable: Root Module Directory: Place your primary configuration files (main.tf, variables.tf, outputs.tf) in the root directory of your project. This is your entry point for running Terraform commands. Environment-Specific Configurations: Create subdirectories for each environment (e.g., prod, staging, dev). Each environment should have its own set of .tf files and a terraform.tfvars file to define specific variables ├── prod │  ├── main.tf │  ├── variables.tf │  ├── outputs.tf │  └── terraform.tfvars ├── dev │  ├── main.tf │  ├── variables.tf │  ├── outputs.tf │  └── terraform.tfvars Modules: Use a modules directory to define reusable modules. Modules encapsulate resources and can be shared across different environments. ├── modules │  ├── azurerm_rg │  │  ├── main.tf │  │  ├── variables.tf │  │  └── outputs.tf │  ├── azurerm_vnet │  │  ├── main.tf │  │  ├── variables.tf │  │  └── outputs.tf