Belajar Cloud Engineer - CLI & Automation

#Pendahuluan

Di episode 7 kalian baru saja memprovision infrastruktur dari kode dengan Terraform — tetapi ada banyak tugas operasional yang tidak cocok untuk Terraform: mengambil informasi, menjalankan job ad-hoc, atau mengotomasi sesuatu yang berulang setiap jam. Untuk itu, kalian butuh CLI dan scripting.

Episode 8 membahas keterampilan yang paling sering dipakai sehari-hari oleh cloud engineer: AWS CLI, gcloud, dan az sebagai bahasa universal manajemen cloud, jq untuk mengolah output JSON, script bash untuk otomasi cepat, dan SDK Python (boto3) untuk kontrol programatik yang lebih kompleks. Di akhir episode kalian akan membangun script manajemen resource yang lengkap.

#Mengapa CLI Lebih Baik dari Console

Console (dashboard web) menyenangkan untuk menjelajah, tetapi buruk untuk bekerja berulang. CLI unggul karena:

1. Scriptable — perintah bisa dipanggil dalam loop, cron, dan pipeline.
2. Idempotent-friendly — bisa dicek hasilnya dengan exit code dan output.
3. Remote-friendly — dijalankan dari server, CI/CD, atau laptop tanpa browser.
4. Consistent — tidak tergantung klik yang bisa salah.

Semua provider menyediakan CLI lengkap: aws (v2), gcloud, dan az. Ketiganya punya pola serupa: {provider} {service} {action} {flags}.

#Bekerja dengan Output JSON dan jq

CLI cloud mengembalikan output JSON — dan jq adalah pisau Swiss Army untuk memotongnya. Contoh nyata: ambil public IP dari instance EC2.

aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=lab-web" \
  --query "Reservations[].Instances[].PublicIpAddress" \
  --output text

Versi jq untuk pemrosesan yang lebih fleksibel:

aws ec2 describe-instances --output json \
  | jq '.Reservations[].Instances[] | {id: .InstanceId, type: .InstanceType, ip: .PublicIpAddress}'

{
  "id": "i-0a1b2c3d4e5f6a7b8",
  "type": "t3.micro",
  "ip": "203.0.113.7"
}

Pola penting: jq bisa menyaring berdasarkan kondisi, memformat, dan menggabungkan data. Dengan jq, kalian bisa menulis script yang membaca, menganalisis, dan bertindak berdasarkan keadaan infrastruktur — ini dasar dari automation monitoring (episode 9).

#Scripting Bash untuk Manajemen Resource

Untuk otomasi cepat — audit, backup kecil, rotasi log — bash masih juara karena ringan dan ada di mana-mana. Contoh: script sederhana untuk membuat snapshot dari semua EBS volume yang ditandai Backup=yes.

#!/bin/bash
set -euo pipefail
 
REGION="ap-southeast-1"
TODAY=$(date +%F)
 
volumes=$(aws ec2 describe-volumes \
  --filters "Name=tag:Backup,Values=yes" \
  --region "$REGION" \
  --query 'Volumes[].VolumeId' --output text)
 
for vol in $volumes; do
  echo "Snapshot $vol pada $TODAY"
  aws ec2 create-snapshot \
    --volume-id "$vol" \
    --description "backup-$TODAY" \
    --region "$REGION" > /dev/null
done
echo "Selesai: $(echo "$volumes" | wc -w) volume di-backup"

Poin penting script yang baik:

• set -euo pipefail — berhenti jika ada error, gagal jika ada variable kosong atau pipe putus.
• Variabel untuk nilai berulang (region, tanggal).
• Output yang jelas di setiap langkah.
• Gunakan tag sebagai mekanisme penanda — tag adalah bahasa metadata cloud (episode 16 FinOps).

#Python SDK (boto3) untuk Kontrol Programatik

Ketika logika makin kompleks — parsing, decision, retry — script bash mulai rapuh. Saatnya beralih ke SDK. boto3 adalah SDK AWS resmi; GCP punya google-cloud-*, Azure punya azure-*. Contoh sama dengan di atas, versi Python:

snapshot_ebs.py

import boto3
from datetime import date
 
ec2 = boto3.client("ec2", region_name="ap-southeast-1")
today = date.today().isoformat()
 
volumes = ec2.describe_volumes(
    Filters=[{"Name": "tag:Backup", "Values": ["yes"]}]
)["Volumes"]
 
for vol in volumes:
    print(f"Snapshot {vol['VolumeId']} pada {today}")
    ec2.create_snapshot(
        VolumeId=vol["VolumeId"],
        Description=f"backup-{today}",
    )
print(f"Selesai: {len(volumes)} volume di-backup")

Kapan memakai bash vs Python? Bash untuk operasi singkat yang menggabungkan perintah; Python saat ada logika bercabang, error handling, atau perlu dipakai lintas platform. Keduanya saling melengkapi — cloud engineer menguasai dua-duanya.

#Otomasi Terjadwal dengan Cron

Script yang dijalankan manual belum otomasi. Tempelkan ke cron untuk eksekusi terjadwal:

0 2 * * * /home/risa/cloud-lab/snapshot-ebs.sh >> /var/log/ebs-backup.log 2>&1

Pada cloud, cara yang lebih "cloud-native" adalah scheduled function serverless (CloudWatch Events/EventBridge + Lambda, Cloud Scheduler + Cloud Functions) — kita akan bahas saat event-driven architecture di episode 11 dan 13. Untuk sekarang, cron cukup untuk tugas operasional lokal.

#Praktik: Script Manajemen Resource Lengkap

Mari rangkai semuanya: script yang mengelola lifecycle VM development — start di pagi hari, stop di malam hari — untuk menghemat biaya. Struktur:

1. stop-dev-vms.sh — stop semua instance bertag Env=dev,Shutdown=night.
2. start-dev-vms.sh — start yang sama di pagi hari.
3. Cron: 0 19 * * 1-5 (stop), 0 7 * * 1-5 (start).

#!/bin/bash
set -euo pipefail
 
ids=$(aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  "Name=tag:Env,Values=dev" "Name=tag:Shutdown,Values=night" \
  --query 'Reservations[].Instances[].InstanceId' --output text)
 
if [[ -z "$ids" ]]; then
  echo "Tidak ada instance dev yang berjalan."
  exit 0
fi
 
aws ec2 stop-instances --instance-ids $ids
echo "Stopped: $ids"

Kebiasaan seperti ini — mengotomasi stop/start dan menghapus resource menganggur — adalah langkah FinOps nyata yang bisa menghemat puluhan persen biaya bulanan (kita akan dalami di episode 16).

#Kesalahan Umum (Common Pitfalls)

1. aws configure berisi key root — selalu IAM user dengan least privilege (episode 6).
2. Output di-parse dengan regex/grep — rapuh; gunakan jq/JMESPath.
3. Loop bash tanpa set -e — satu kegagalan tidak terdeteksi.
4. Script berhenti di tengah karena > menimpa file penting — pakai >> untuk log dan double-check redirect.
5. Membiarkan VM dev hidup 24/7 — kebiasaan paling mahal; otomasi stop/start.

#Penutup

Inti yang harus dibawa pulang:

• CLI (aws/gcloud/az) adalah bahasa kerja sehari-hari cloud engineer — scriptable, remote-friendly, konsisten.
• jq mengubah output JSON menjadi bahan pengambilan keputusan.
• Bash untuk otomasi cepat, Python SDK untuk logika kompleks — kuasai keduanya.
• Cron/scheduler menempelkan script ke jadwal; uji manual dulu sebelum terjadwal.
• Otomasi stop/start resource dev adalah langkah FinOps paling mudah yang langsung terasa di tagihan.

Di episode 9 selanjutnya kita akan membahas monitoring & logging cloud — CloudWatch, Cloud Monitoring, Azure Monitor, log aggregation, alarm, dan dashboard — untuk memastikan seluruh resource yang kalian otomasi bisa diamati dan bertindak cepat saat ada masalah. Sampai jumpa di episode 9!