fadharpra blog

Deploy AWX on k3s Single Node for Ansible Automation

Mon, 29 Dec 2025 00:00:00 GMT

There comes a point in almost every infrastructure or DevOps engineer’s journey when Ansible CLI alone no longer feels enough.
Playbooks keep growing, inventories get more complex, credentials become sensitive, and eventually a question appears:

“I need a UI, RBAC, and job history — but I don’t want to run a full-blown Kubernetes stack.”

That’s where AWX starts to make sense.
And to keep things lightweight, k3s becomes a very reasonable foundation.

This article is not an enterprise best practice guide.
It’s a practical lab note — simple, fast, tidy enough, and realistic for daily use.

AWX vs Ansible Tower vs Red Hat AAP

Section titled “AWX vs Ansible Tower vs Red Hat AAP”

In many teams, the initial requirement is simple: “We need Ansible, but with a UI, RBAC, and job history.”

Officially, the answers are:

Ansible Tower (now deprecated)
Red Hat Ansible Automation Platform (AAP)

The challenge is:

AAP is commercial
Pricing can be overkill for labs or small internal teams
Enterprise support is not always a strict requirement

This is where AWX becomes a pragmatic choice:

Open-source
Upstream project of Ansible Tower
Core features like UI, RBAC, scheduling, and logging are available
Can run on lightweight Kubernetes distributions such as k3s

If you require official support, strict compliance, and SLAs, Red Hat AAP remains the right choice.
But if flexibility and functionality are the priority, AWX is often more than enough.

Setup Goal

Section titled “Setup Goal”

The goal of this setup is intentionally modest:

Single-node Kubernetes
Fast installation
Proof-of-concept environments
No complex ingress configuration
AWX accessible immediately
Suitable for homelab or internal automation
Small teams that need control without enterprise overhead

Not HA. Not enterprise-grade. But usable.

Environment Overview

Section titled “Environment Overview”

Ubuntu Server 22.04
1 VM or bare metal node
Minimum resources:
- 2 vCPU
- 4 GB RAM (8 GB recommended)
Internet access

Step 1 — Preparing the Require Package

Section titled “Step 1 — Preparing the Require Package”

Start with the essentials. Nothing fancy, but explicit.

Terminal window

sudo apt update
sudo apt install -y git build-essential curl

Step 2 — Installing k3s

Section titled “Step 2 — Installing k3s”

One of the reasons k3s is appealing:

Single binary
Bundled container runtime
Built-in Traefik
Built-in local storage provisioner

Installation is literally one command:

Terminal window

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode=644" sh -

The --write-kubeconfig-mode=644 flag allows kubectl usage without sudo.

Verify the node:

Terminal window

kubectl get nodes -o wide

Proceed once the node is Ready.

Step 3 — Verifying Cluster Components

Section titled “Step 3 — Verifying Cluster Components”

This step is often skipped, but it’s useful as a sanity check.

Terminal window

kubectl get all -n kube-system

You should see components such as:

coredns
metrics-server
local-path-provisioner
traefik
svclb-traefik

Seeing Traefik assigned an external IP from your LAN subnet is expected behavior in k3s.

Step 4 — Deploying the AWX Operator

Section titled “Step 4 — Deploying the AWX Operator”

AWX is deployed exclusively via an operator.

Clone the official repository:

Terminal window

git clone https://github.com/ansible/awx-operator.git
cd awx-operator

Checkout a stable version:

Terminal window

git checkout tags/2.19.1
export VERSION=2.19.1
make deploy

The detached HEAD warning is expected when checking out a tag.

Verify the operator:

Terminal window

kubectl get all -n awx

Ensure the controller manager pod is in Running state.

Step 5 — Creating the AWX Admin Secret

Section titled “Step 5 — Creating the AWX Admin Secret”

Before deploying the AWX instance, the admin password must exist.

Terminal window

kubectl create secret generic awx-admin-password \
  --from-literal=password='<STRONG_PASSWORD>' \
  -n awx

Confirm:

Terminal window

kubectl get secrets -n awx

Step 6 — Deploying the AWX Instance

Section titled “Step 6 — Deploying the AWX Instance”

Create the manifest file awx-prod.yml:

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-production
  namespace: awx
spec:
  admin_user: admin
  admin_password_secret: awx-admin-password
  service_type: nodeport

Apply the manifest:

Terminal window

kubectl apply -f awx-prod.yml
kubectl get pods -n awx -w

At this stage, several pods will be created, including PostgreSQL, awx-web, and awx-task.
This is the most resource-intensive part — give it some time.

Step 7 — Accessing AWX

Section titled “Step 7 — Accessing AWX”

Retrieve the NodePort service:

Terminal window

kubectl get svc -n awx

Access AWX using:

http://<NODE_IP>:<NODEPORT>

From Code to Automated Web Infrastructure on Google Cloud with Terraform

Thu, 25 Dec 2025 00:00:00 GMT

This article was born from real experience as a speaker at GDG Bogor DevFest 2025, where a Terraform session almost ran out of time due to one simple issue: tool installation.

🎤 A Short Story from DevFest 2025

Section titled “🎤 A Short Story from DevFest 2025”

At GDG Bogor DevFest 2025, I delivered a session titled:

“From Code to Automated Web Infrastructure on Google Cloud with Terraform”

The goal was straightforward:

Help participants understand Infrastructure as Code
Continue with hands-on provisioning of web infrastructure on GCP

But reality hit hard:

Participants used different operating systems (Windows, macOS, Linux)
I was using macOS myself
Many had never installed Terraform before

Problems quickly appeared:

Terraform wasn’t installed
the terraform command wasn’t recognized
PATH issues (especially on Windows)
PowerShell, CMD, and Git Bash added extra confusion

In the end:

30–40 minutes of the session were spent just installing Terraform.

That’s when I realized: Tooling setup is not a trivial detail — it’s a single point of failure for workshops.

That’s why this article exists: a pre-workshop survival guide.

Why Terraform Installation Must Be Done First

Section titled “Why Terraform Installation Must Be Done First”

Terraform is a CLI tool.
If the CLI doesn’t work:

The workshop can’t move forward
Speakers panic
Participants get confused
Valuable time is wasted

There’s only one solution:

Make sure the setup is done before the event.

How to Install Terraform (by OS)

Section titled “How to Install Terraform (by OS)”

Windows (Most Critical)

Section titled “Windows (Most Critical)”

Recommended: use Chocolatey

1. Install Chocolatey (if not installed)

Section titled “1. Install Chocolatey (if not installed)”

Open PowerShell (Run as Administrator):

Terminal window

Set-ExecutionPolicy Bypass -Scope Process -Force
irm https://community.chocolatey.org/install.ps1 | iex

Restart PowerShell after installation.

2. Install Terraform

Section titled “2. Install Terraform”

Terminal window

choco install terraform -y

3. Verify

Section titled “3. Verify”

Terminal window

terraform version
where terraform

⚠️ Common issues on Windows

Terraform is installed but the command isn’t recognized
Root cause: PATH not refreshed
Solution: restart PowerShell / Windows Terminal (sometimes a full reboot)

macOS

Section titled “macOS”

Using Homebrew:

Terminal window

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Verify:

Terminal window

terraform version
which terraform

Linux (Ubuntu / Debian)

Section titled “Linux (Ubuntu / Debian)”

Terminal window

sudo apt update
sudo apt install -y gnupg software-properties-common curl

curl -fsSL https://apt.releases.hashicorp.com/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update
sudo apt install terraform

Verify:

Terminal window

terraform version
which terraform

Linux (RHEL / Rocky / Alma)

Section titled “Linux (RHEL / Rocky / Alma)”

Terminal window

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo dnf install terraform

✅ Mandatory Pre-Workshop Checklist

Section titled “✅ Mandatory Pre-Workshop Checklist”

Terraform is installed
terraform version runs without errors
PATH is correctly configured
You have run terraform init at least once

If this checklist is completed, 90% of Terraform workshop problems usually disappear.

Personal Notes (Lessons Learned)

Section titled “Personal Notes (Lessons Learned)”

💡 Lessons learned from DevFest

Never install tools on the event day
Send installation guides at least one day before
Ask participants to test terraform version
It’s better to cut content than lose time on setup

Automation is powerful,
but it only feels powerful when the tools are ready to use.

Closing

Section titled “Closing”

Terraform allows us to:

Define infrastructure as code
Create repeatable environments
Reduce “works on my machine” issues

But before getting to the fun part,

Make sure one simple thing works: Terraform itself.

🔜 Part 2:
From Code to Automated Web Infrastructure on Google Cloud with Terraform
(a deep dive into Terraform code until the infrastructure is fully deployed)

Labs: Deploy Web Infrastructure on Google Cloud Using Terraform (Cloud Run)

Wed, 24 Dec 2025 00:00:00 GMT

This is a continuation of Part 1. Here we focus on the “fun part”: breaking down Terraform code and actually deploying an application to Cloud Run so it’s publicly accessible.

Quick Context (DevFest Mode)

Section titled “Quick Context (DevFest Mode)”

In the talk “From Code to Automated Web Infrastructure on Google Cloud with Terraform”, my goal was simple:

start from Terraform code
end with a real, live web service on Google Cloud

Infrastructure deployed in this Part 2:

Cloud Run (fully managed)
Public service (no auth) via IAM binding roles/run.invoker to allUsers

Perfect for stage demos: fast, repeatable, and no VM headaches.

Directory Structure

Section titled “Directory Structure”

📝 Note:

The *.json file is a service account key (credential). For public repositories, never commit this file.

Prerequisites

Section titled “Prerequisites”

Terraform installed (Part 1)
A GCP project with billing enabled
A service account with minimum required permissions for Cloud Run
Required APIs enabled

Required APIs

Section titled “Required APIs”

run.googleapis.com
iam.googleapis.com
cloudresourcemanager.googleapis.com

Terminal window

gcloud services enable run.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com

Breaking Down the Terraform Files

Section titled “Breaking Down the Terraform Files”

providers.tf — Provider & Authentication

Section titled “providers.tf — Provider & Authentication”

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "7.12.0"
    }
  }
}

provider "google" {
  credentials = file(var.gcp_svc_key)
  project     = var.gcp_project
  region      = var.gcp_region
}

variables.tf — Demo-Friendly Defaults

Section titled “variables.tf — Demo-Friendly Defaults”

variable "gcp_svc_key" {
  default = "service-account-google-your.json"
}

variable "gcp_project" {
  default = "your-gcp-project-id"
}

variable "gcp_region" {
  default = "asia-southeast2"
}

variable "cloud_run_service_name" {
  default = "devfest-demo"
}

variable "container_image" {
  default = "docker.io/fadharpra/devfest-demo:1.6"
}

main.tf — Cloud Run Service

Section titled “main.tf — Cloud Run Service”

resource "google_cloud_run_v2_service" "app" {
  name     = var.cloud_run_service_name
  location = var.gcp_region
  ingress  = "INGRESS_TRAFFIC_ALL"

  scaling {
    max_instance_count = 3
  }

  template {
    containers {
      image = var.container_image
    }
  }
}

Deploy Steps

Section titled “Deploy Steps”

Terminal window

terraform init
terraform plan
terraform apply

Output URL

Section titled “Output URL”

output "cloud_run_url" {
  value = google_cloud_run_v2_service.app.uri
}

Conclusion

Section titled “Conclusion”

Simple Terraform structure, fast Cloud Run deployment, and instant demo results.

Labs: Provision Vertex AI Workbench with Terraform

Tue, 10 Jun 2025 00:00:00 GMT

🚀 A concise guide to help you provision Vertex AI Workbench using Terraform and explore the Iris dataset with Python. Ideal for workshops and self-paced labs.

🎤 A Short Story from Google I/O Extended Bogor 2025

Section titled “🎤 A Short Story from Google I/O Extended Bogor 2025”

Some time ago, I was invited to be a speaker/facilitator for the ~~Code & Create - Build with AI Workshops Session 2~~ Dev Connect session at Google I/O Extended Bogor 2025.

Coming from a system engineering and infrastructure background, I’ll be honest — when the topic included AI, my first reaction was:

“Uh oh… this is way outside my comfort zone.”

I don’t come from an ML or Data Science background, and I genuinely struggled to understand many of GCP’s AI services at first.

But at the same time, I still wanted to share something relevant from my own perspective as an infrastructure engineer — specifically around automation and provisioning tools like Terraform.

So I treated this as a challenge:

Learn how to use Vertex AI Workbench
Provision everything from scratch
Package it into a hands-on lab focused on automation, not heavy modeling or training

🧠 From that experience, I learned one important thing:
AI–Infra collaboration isn’t about who knows more — it’s about enabling each other with the right tools.

ML teams need environments that are repeatable, secure, and scalable — and that’s exactly where automation tools like Terraform shine.

📦 What You’ll Do in This Lab

Section titled “📦 What You’ll Do in This Lab”

Provision a JupyterLab environment using Vertex AI Workbench
Explore the Iris dataset using Python and pandas
Train and evaluate a simple ML model (RandomForest)

⚙️ Prerequisites

Section titled “⚙️ Prerequisites”

Before getting started, make sure:

You have a GCP project with billing enabled

You have created a service account with the following roles:

Vertex AI Admin
Compute Admin
IAM Service Account User
Service Usage Admin

The following APIs are enabled:

vertexai.googleapis.com
notebooks.googleapis.com
cloudresourcemanager.googleapis.com

🧱 Project Structure

Section titled “🧱 Project Structure”

🛠 Step-by-Step Guide

Section titled “🛠 Step-by-Step Guide”

1. Clone the Repository

Section titled “1. Clone the Repository”

Terminal window

git clone https://github.com/fadharpra/terraform-vertex-ai-workbench.git
cd gdg-workbench-lab

Inside the repository, you’ll find the main Terraform file, main.tf, which defines the Vertex AI Workbench resource used to deploy the JupyterLab environment.

You’ll also find supporting files:

variables.tf — input variable definitions
terraform.tfvars — variable values
enable-apis.sh — script to enable required GCP APIs
explore-iris.ipynb — demo notebook for exploring the Iris dataset

Here’s a snippet from main.tf:

main.tf

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 5.0.0"
    }
  }
}

provider "google" {
  project     = var.project_id
  region      = var.region
  credentials = file(var.service_account_key_path)
}

resource "google_project_service" "resource_manager_api" {
  service = "cloudresourcemanager.googleapis.com"
  disable_on_destroy = true
}

resource "google_project_service" "enable_apis" {
  for_each = toset([
    "aiplatform.googleapis.com",
    "datacatalog.googleapis.com",
    "dataproc.googleapis.com"
  ])
  service = each.key
  disable_on_destroy = true

  depends_on = [google_project_service.resource_manager_api]
}

resource "google_workbench_instance" "notebook" {
  name     = "gdg-workbench-demo"
  location = var.zone

  gce_setup {
    machine_type = "n1-standard-1"

    boot_disk {
      disk_type = "PD_STANDARD"
      disk_size_gb = 150
    }

    vm_image {
      project = "cloud-notebooks-managed"
      family  = "workbench-instances"
    }

    disable_public_ip = false
    enable_ip_forwarding = false
  }

  instance_owners = [var.user_email]
}

2. Add the `variables.tf` File

Section titled “2. Add the variables.tf File”

Create a new file named variables.tf to declare the required variables:

variables.tf

variable "project_id" {}

variable "region" {
  default = "asia-southeast2"
}

variable "zone" {
  default = "asia-southeast2-a"
}

variable "service_account_key_path" {
  default = ".env/service_account_key.json"
}

variable "user_email" {
  description = "Email user yang boleh akses notebook"
}

3. Edit the Variables

Section titled “3. Edit the Variables”

Update terraform.tfvars with your own values:

terraform.tfvars

project_id                = "project-id-kalian"
region                    = "asia-southeast2"
zone                      = "asia-southeast2-a"
service_account_key_path = ".env/service_account_key.json"
user_email                = "kalian@example.com"

4. Enable Required APIs

Section titled “4. Enable Required APIs”

Terminal window

bash enable-apis.sh

5. Deploy the Infrastructure

Section titled “5. Deploy the Infrastructure”

Terminal window

terraform init
terraform apply

📊 Notebook Exploration

Section titled “📊 Notebook Exploration”

Once the instance is running, open JupyterLab from the Vertex AI Workbench Console, upload explore-iris.ipynb, and run all cells.

You’ll see:

Dataset preview
Summary statistics
Training and evaluation of a simple ML model

🎓 Bonus Ideas

Section titled “🎓 Bonus Ideas”

You can extend this lab by:

Loading datasets from BigQuery
Uploading and loading models from GCS
Connecting to Vertex AI endpoints using the Python SDK

✅ Conclusion

Section titled “✅ Conclusion”

Vertex AI Workbench makes it easier, safer, and more repeatable to set up ML environments on GCP.
With Terraform, you can automate this setup and integrate it into your infrastructure workflow.

Happy hacking! 🎉

Managing Terraform State on AWS Without DynamoDB Drama

Mon, 19 May 2025 00:00:00 GMT

If you’ve ever run terraform apply at the same time as 2–3 other people without a remote state… congratulations! You’ve unlocked one of the hardcore modes of the DevOps world 😂

🎯 Background

Section titled “🎯 Background”

At my previous workplace, I ran into a situation that’s (unfortunately) very common in small teams: everyone used Terraform, everyone relied on local state, and the most critical part — nobody coordinated applies… except when someone applied silently.

So I decided to clean things up a bit. The goals were:

Separate each project’s state into a clean backend
Store the state in S3
Without using DynamoDB (because it’s extra setup, and turns out it’s no longer necessary)

🧱 Project Structure

Section titled “🧱 Project Structure”

⚙️ S3 Backend Configuration with `use_lockfile`

Section titled “⚙️ S3 Backend Configuration with use_lockfile”

In each project (usually in providers.tf), add:

terraform {
  backend "s3" {
    bucket = "fadharpra-terraform-state-bucket"
    region = "ap-southeast-1"
    key    = "lockfile-test/terraform.tfstate"
    use_lockfile = true
  }
}

Or you can separate it into its own file by creating backend-config.hcl:

bucket       = "fadharpra-terraform-state-bucket"
key          = "production/website.tfstate"
region       = "ap-southeast-1"
use_lockfile = true
encrypt      = true

Yep — starting from Terraform 1.7+, we can use native locking directly in S3 without DynamoDB. Terraform automatically creates a .lock file in the bucket while apply is running.

🚀 Setup Steps

Section titled “🚀 Setup Steps”

Terminal window

terraform init -backend-config=../backend-config.hcl
terraform plan
terraform apply

If someone else tries to apply at the same time, you’ll see something like this:

│ Error: Error acquiring the state lock
│
│ Error message: resource temporarily unavailable
│ Lock Info:
│   ID:        6c4d7907-ccb1-15c3-2e68-80cc0459f2f4
│   Path:      terraform.tfstate
│   Operation: OperationTypeApply
│   Who:       fadhliari@MacBook-Air-Fadhli.local
│   Version:   1.11.4
│   Created:   2025-05-19 06:36:42.430544 +0000 UTC
│   Info:
│
│ ...

🎉 That means the locking mechanism is working as expected.

🧠 Why This Matters

Section titled “🧠 Why This Matters”

Because terraform.tfstate is not just another file. It stores the entire “source of truth” for all resources that have ever been created. If two people run apply simultaneously — even on different resources — things can break:

The state won’t be aware of resources created by others
Resources can be deleted, modified incorrectly, or duplicated

So there’s no more excuse for “wait… why is the VM gone?”

💬 Closing Thoughts

Section titled “💬 Closing Thoughts”

Cleaning up Terraform structure isn’t a one-time task. But with small steps like this — using S3, enabling use_lockfile, and separating state per project — you can already avoid 90% of the drama that usually happens in small teams.

If you’ve got your own chaotic terraform apply stories, drop them in the comments or connect with me. DevOps war stories are always fun to share 😄

Why Did I Start This Blog?

Thu, 10 Apr 2025 00:00:00 GMT

Sometimes, internal documentation isn’t enough.
Sometimes, notes in Notion disappear.
Sometimes, you want to write something that’s more than just a how-to.

And at that point… I realized:
I needed my own space. A place to write, to store things, and to remind myself.

✍️ So, why do I write?

Section titled “✍️ So, why do I write?”

To avoid repeating the same mistakes.
To share things with teammates without explaining them over and over again.
To help someone out there who’s Googling and happens to find something useful — even if it’s small.

🛠 What will I write about?

Section titled “🛠 What will I write about?”

Mostly things like:

Infrastructure (cloud, Linux, containers, monitoring)
Automation (Terraform, Ansible, CI/CD, simple bash scripts)
Small insights that come from real troubleshooting
And sometimes… personal opinions about the DevOps world itself

🙏 Finally…

Section titled “🙏 Finally…”

I don’t promise to write consistently.
But I do promise that everything I write, I’ll try to make genuinely useful.

If something I write helps you, let me know.
If something’s wrong — even better — let me know sooner.

Thanks for stopping by. ✌️

Modern Laravel 10 Deployment with Docker (2024–2025 Best Practices)

Sun, 30 Mar 2025 00:00:00 GMT

Best Practice

🚀 A modern, production-friendly approach to running Laravel 10 with Docker on Ubuntu 22.04 / 24.04 — cleaner, safer, and easier to maintain.

📦 Stack Overview

Section titled “📦 Stack Overview”

Laravel 10
PHP-FPM 8.1+
MySQL 8.0
phpMyAdmin (optional, non-production)
Nginx (Reverse Proxy)
Docker Compose v2

🧠 Key Improvements vs Legacy Setup

Section titled “🧠 Key Improvements vs Legacy Setup”

No static container IPs
No exposed database ports (internal network only)
Environment variables via .env
Named volumes for persistence
Docker Compose v2 (docker compose)
phpMyAdmin marked as optional / non-prod

🐳 Step 1 — Install Docker Engine (Official Method)

Section titled “🐳 Step 1 — Install Docker Engine (Official Method)”

Terminal window

sudo apt update -y
sudo apt install -y ca-certificates curl gnupg

Terminal window

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Terminal window

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update -y
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verify:

Terminal window

docker version
docker compose version

📁 Step 2 — Project Structure

Section titled “📁 Step 2 — Project Structure”

🔐 Step 3 — Environment Configuration (.env)

Section titled “🔐 Step 3 — Environment Configuration (.env)”

APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost

DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=secret

🛠️ Step 4 — Dockerfile PHP-FPM

Section titled “🛠️ Step 4 — Dockerfile PHP-FPM”

docker/php/Dockerfile:

FROM php:8.1-fpm

RUN apt-get update && apt-get install -y \
    git curl zip unzip libpng-dev libonig-dev libxml2-dev \
    && docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd

COPY --from=composer:2 /usr/bin/composer /usr/bin/composer

WORKDIR /var/www/html

🧩 Step 5 — docker-compose.yml (Clean & Modern)

Section titled “🧩 Step 5 — docker-compose.yml (Clean & Modern)”

services:
  app:
    build:
      context: .
      dockerfile: docker/php/Dockerfile
    container_name: laravel-app
    volumes:
      - ./app:/var/www/html
    env_file:
      - .env
    depends_on:
      - db

  web:
    image: nginx:alpine
    container_name: nginx
    ports:
      - "80:80"
    volumes:
      - ./app:/var/www/html
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app

  db:
    image: mysql:8.0
    container_name: mysql
    restart: always
    environment:
      MYSQL_DATABASE: laravel
      MYSQL_USER: laravel
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - dbdata:/var/lib/mysql

  phpmyadmin:
    image: phpmyadmin
    container_name: phpmyadmin
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
    profiles:
      - debug

volumes:
  dbdata:

🌐 Step 6 — Nginx Configuration

Section titled “🌐 Step 6 — Nginx Configuration”

docker/nginx/default.conf:

server {
    listen 80;
    index index.php index.html;
    root /var/www/html/public;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

🚀 Step 7 — Run the Stack

Section titled “🚀 Step 7 — Run the Stack”

Terminal window

docker compose up -d --build

Generate Laravel key:

Terminal window

docker compose exec app php artisan key:generate

Access the app:

Laravel: http://localhost
phpMyAdmin (debug): http://localhost:8081

🧠 Production Notes

Section titled “🧠 Production Notes”

Use .env.production
Disable phpMyAdmin
Add HTTPS (Traefik / Nginx + Certbot)
Use non-root containers if needed
Consider queue & scheduler containers

✅ Final Thoughts

Section titled “✅ Final Thoughts”

This setup is intentionally boring — and that’s a good thing.
Simple Compose files, predictable networking, and fewer moving parts mean fewer 3 AM incidents.

If you’re migrating from an older Laravel Docker setup, this structure is a solid baseline going forward.

Monitoring Linux Servers with Prometheus, Node Exporter, and Grafana

Fri, 04 Aug 2023 00:00:00 GMT

Caution

🚀 A hands-on guide to setting up a Prometheus-based monitoring stack. We’ll use two Ubuntu-based VMs: one for Node Exporter, and another for Prometheus + Grafana.

🖥️ Architecture Overview

Section titled “🖥️ Architecture Overview”

VM 1 (vms-01, IP: 192.168.1.7): Node Exporter
VM 2 (vms-02, IP: 192.168.1.8): Prometheus & Grafana

🔧 Step 1 — Install Node Exporter

Section titled “🔧 Step 1 — Install Node Exporter”

Node Exporter collects hardware and OS metrics, which are then scraped by Prometheus.

Terminal window

sudo useradd --no-create-home --shell /bin/false node_exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz -P /mnt
cd /mnt
tar -zxvf node_exporter-1.6.1.linux-amd64.tar.gz
cp node_exporter-1.6.1.linux-amd64/node_exporter /usr/local/bin
chown node_exporter:node_exporter /usr/local/bin/node_exporter

Create the systemd service:

/etc/systemd/system/node_exporter.service

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Enable and start the service:

Terminal window

systemctl daemon-reload
systemctl start node_exporter
systemctl enable node_exporter

Verify via browser: http://192.168.1.7:9100/metrics

📦 Step 2 — Install Prometheus

Section titled “📦 Step 2 — Install Prometheus”

Terminal window

sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.46.0/prometheus-2.46.0.linux-amd64.tar.gz -P /mnt
cd /mnt
tar -zxvf prometheus-2.46.0.linux-amd64.tar.gz
cp prometheus-2.46.0.linux-amd64/{prometheus,promtool} /usr/local/bin/
chown prometheus:prometheus /usr/local/bin/prom*

mkdir /etc/prometheus
cp -r prometheus-2.46.0.linux-amd64/{consoles,console_libraries,prometheus.yml} /etc/prometheus
chown -R prometheus:prometheus /etc/prometheus

Edit /etc/prometheus/prometheus.yml:

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "node_exporter"
    static_configs:
      - targets: ["192.168.1.7:9100"]

Create the Prometheus service:

/etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus Monitoring
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus   --config.file /etc/prometheus/prometheus.yml   --storage.tsdb.path /etc/prometheus/data/   --web.console.templates=/etc/prometheus/consoles   --web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

Enable and start Prometheus:

Terminal window

systemctl daemon-reload
systemctl start prometheus
systemctl enable prometheus

Access Prometheus UI: http://192.168.1.8:9090

📈 Step 3 — Install Grafana

Section titled “📈 Step 3 — Install Grafana”

Terminal window

apt-get install -y apt-transport-https software-properties-common wget
wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key
echo "deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
apt-get update -y
apt-get install grafana -y

systemctl start grafana-server
systemctl enable grafana-server

Access Grafana at http://192.168.1.8:3000:

Username: admin
Password: admin

🧩 Integrate Grafana with Prometheus

Section titled “🧩 Integrate Grafana with Prometheus”

Navigate to Connections → Data Sources
Select Prometheus → URL: http://192.168.1.8:9090
Click Save & Test

🧠 Dashboard Setup

Section titled “🧠 Dashboard Setup”

Use the community dashboard template:
https://grafana.com/grafana/dashboards/10180

Steps:

Click New → Import
Enter Dashboard ID: 10180
Select Prometheus as the data source → Import

🎉 Done! You now have a powerful, open-source observability stack running.

If you run into issues during setup, drop a question in the comments.
Or share your own monitoring chaos stories — chances are, we’ve all been there 😄