标签：#bash

If you are just getting started with Azure CLI and Bash scripting, this post is for you. I will walk you through how I automated the creation of Azure resource groups for multiple environments using a single Bash script — something that was taking a cloud admin several manual steps every week. This is Project 2 in my TechRush Cloud Engineering bootcamp series. If you want to see where this journey started, you can read my previous post where I tackled deploying a web app across two Azure regions for the first time . That project involved real blockers — quota limits, CLI version mismatches, and a deep dive into Azure Resource Providers. This one went smoother, and I think that is because the previous project was the hard school. The Problem Imagine a cloud administrator who has to create five resource groups every single week, one for each active project: Project-A-RG Project-B-RG Project-C-RG Project-D-RG Project-E-RG Every week. By hand. Management's response was simple: automate it. But here is where the task gets more interesting. Instead of creating one flat resource group per project, the better approach is to create four resource groups per project — one for each environment: Dev Test UAT Production This matters because each environment needs its own access controls, cost tracking, and lifecycle rules. You do not want your Development environment sharing a resource group with Production. Keeping them separate is a real-world cloud best practice, not just a bootcamp exercise. What You Will Need Before running this script, make sure you have the following set up: Azure CLI installed on your local machine. You can follow the official installation guide . An active Azure account . A free account works fine for this. A terminal that runs Bash — Linux, macOS, or WSL on Windows. Understanding the Design The core idea behind this script is parameterization . Instead of hardcoding project names, the script accepts a project name as input and uses it as a prefix for ev

The Scenario: The Help Desk Bottleneck From 2019 to 2021, while serving as Lead Backend Software Engineer at a fast-growing company, I occasionally support our Linux System Administration tasks. When the DevOps team encountered a critical bottleneck during an initiative to scale dozens of new server deployments, I stepped in to streamline the infrastructure processes. The DevOps team was being hampered by constant, fragmented requests from the help desk to manually create new Linux accounts for recruits testing the latest application. These interruptions were not only time-consuming but were directly preventing the team from focusing on the high-priority infrastructure deployments that define their core responsibilities. I realized that we weren't just struggling with a task; we were struggling with a scaling bottleneck. To regain the team's focus and ensure we hit our project deadlines, I decided to automate this workflow. The First Step: The Interactive Script My first objective was to develop a robust, automated shell script to efficiently create new Linux user accounts. I started with an interactive Bash script (create-user-interactive.sh) that prompted for input. This was a good educational exercise for learning the fundamentals of Bash—like useradd, passwd, and shell variables. However, I quickly learned that while interactive scripts are great for learning, they are rarely used in professional DevOps environments. Why Manual Scripts Don’t Scale As I transitioned into a more infrastructure-focused role, I realized that manual scripts fail for three key reasons: Lack of Automation: DevOps is about "Infrastructure as Code" (IaC). Asking an engineer to sit at a terminal and type prompts is slow, error-prone, and destroys the ability to automate. Lack of Centralization: In a real team, we aren't creating users on individual local machines. We manage identity across hundreds of servers. Security Risks: Hardcoding passwords or piping them through echo is a major red