Forem: Sireesharaju Kamparaju

Syncing GitLab Projects to AWX — My DevOps Journey

Sireesharaju Kamparaju — Tue, 19 May 2026 13:24:55 +0000

If you've been following my blog series, you already know I've set up Ansible AWX on Kubernetes using Helm. Now the next logical step for me was — how do I actually get my playbooks into AWX without manually uploading them every time?
The answer is GitLab. In this blog I'll walk through how I installed GitLab on a VM, pushed my Ansible playbooks to it, and then synced that repo into AWX as a project — in two ways:

Using an SSH key (SCM Private Key) — this is what I actually use in production
Using a Personal Access Token over HTTP — good for quick lab setups

Let's get into it.

What We're Building Here
The flow looks like this:

Ansible Server → Push Playbooks → GitLab (self-hosted VM) → Sync → AWX Project & Templates
Once this is set up, every time I update a playbook and push to GitLab, AWX syncs and picks up the latest version automatically. That's the real power of this setup.

Part 1 — Installing GitLab on a VM
I installed GitLab on a separate Ubuntu 22.04 VM. Here's exactly what I ran:
Step 1 — Install Dependencies
sudo apt update
sudo apt install -y curl openssh-server ca-certificates tzdata perl
Step 2 — Add GitLab Repository and Install
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt install gitlab-ce
Step 3 — Configure GitLab
sudo vi /etc/gitlab/gitlab.rb
Update the external URL to your VM IP:
rubyexternal_url 'http://10.*.*.**'
Then reconfigure:
sudo gitlab-ctl reconfigure
Step 4 — Get the Initial Root Password
sudo cat /etc/gitlab/initial_root_password
Open http://10.*.*.* in your browser → log in with root and the password above.

Tip: Change your root password immediately after first login — User Settings → Password.

Part 2. Creating a repo and pushing playbooks

Inside GitLab, I created a new blank project called:

ansibleawx

Set it to private and moved on.

On my Ansible server, I configured Git:

git config --global user.name "Sireesha"
git config --global user.email "your@email.com"

Then inside my playbook directory:

cd /etc/ansible

git init
git remote add origin http://ip/ansibleawx.git
git add .
git commit -m "Initial commit - adding ansible playbooks"
git branch -M patches
git push -u origin patches

I’m using a patches branch here because that’s what I decided to track in AWX later.

That part matters more than it looks — branch mismatches will bite you.

Part3. Connecting AWX to GitLab using SSH (production way)

This is the setup I actually use properly. It’s more secure and avoids token expiry issues.

Generate SSH key (on AWX side)
ssh-keygen -t rsa -b 4096 -C "awx@ansible"

Then grab the public key:

cat ~/.ssh/id_rsa.pub

Add it to GitLab

GitLab → User Settings → SSH Keys → paste key → save

Nothing complicated here.

Create AWX credential

In AWX:

Credentials → Add

Name: gitlab-cred
Type: Source Control
Username: root
SCM Private Key: paste private key (~/.ssh/id_rsa)

Click Save.

Create AWX project

AWX → Projects → Add

Name: AnsibleAWX
SCM Type: Git
URL: http:///ansibleawx.git
Branch: patches
Credential: gitlab-cred

Once saved, AWX syncs automatically.

When it turns green, you’re good.

That’s the moment everything starts clicking.

This is exactly the gitlab-cred credential I have set up — you can see from the screenshot it shows Credential Type: Source Control and SCM Private Key: Encrypted.

Part4. Alternative: HTTP with Personal Access Token

This is the quicker setup I used in a lab environment.

Create token in GitLab

GitLab → Settings → Access Tokens

Scope: read_repository

Copy it (you only see it once).

Add to AWX

Credentials → Add

Name: gitlab-http-cred
Username: root
Password:

Save.

Create project

Same as before, but use this credential instead.

It works fine — just not as clean or durable as SSH.

Part 5 — Creating Job Templates in AWX

Once the project sync works, playbooks automatically appear in AWX.

So I created a simple job template:

AWX → Templates → Add

Name: Linux Server Setup
Job Type: Run
Inventory: your inventory
Project: AnsibleAWX
Playbook: select from dropdown
Credentials: your machine credentials

Save and launch.

At this point, AWX is basically running whatever is in GitLab.

No file copying. No manual updates.

Errors I Hit Along the Way
Error 1 — Git Push Branch Mismatch

error: src refspec main does not match any
Fix — rename the branch to match what you set in AWX:
git branch -M patches git push -u origin patches
Error 2 — AWX Sync Failed on SSH Host Key

Host key verification failed
Fix — in your AWX Project settings under Source Control Options, tick:
✅ Disregard Host Checks
Error 3 — Playbook Dropdown Empty in Job Template

After syncing, the playbook dropdown was empty when creating a job template
.
Fix — go back to your Project → hit the Sync button (circular arrow) → wait for green → go back to template. Playbooks will appear.

Before this, updating a playbook meant manually copying files and hoping AWX had the latest version. Now my workflow is:

Edit playbook → git push to patches branch → AWX syncs → Launch job

Everything is version controlled, auditable, and consistent.

Drop your questions in the comments — happy to help!
— Sireesha

Deploying Ansible AWX on Kubernetes Using Helm - By Sireesha

Sireesharaju Kamparaju — Tue, 19 May 2026 10:51:57 +0000

In this blog, I'm going to walk you through how I deployed Ansible AWX on a Kubernetes cluster using Helm. This was one of the most hands-on projects I've worked on — it involves setting up the K8s cluster from scratch, installing the container runtime, deploying Helm, and finally getting AWX up and running. I also hit a few real errors along the way, so I'll share exactly how I fixed them.
It was one of those projects that looks simple on paper but turns into a chain of small problems once you actually start doing it.
Here's the overall flow I followed:
The goal was pretty straightforward:

Set up a Kubernetes cluster on Ubuntu 22.04
Install containerd
Get Helm working
Deploy AWX using the AWX Operator
Fix whatever broke along the way (this part took the longest 😅)

Setting Up the Kubernetes Cluster on Ubuntu 22.04
Before anything else, I want to quickly explain the two types of nodes in a K8s cluster since this matters for the setup:
Master Node — manages the control plane, API calls, pods, services, and everything else in the cluster.
Worker Node — runs the actual containers. Pods can spread across multiple worker nodes for better resource management.
Step 1 — Update and Upgrade (All Nodes)
I started by logging in as root and running updates on all nodes:

hostnamectl set-hostname siri-awx-01 # run on master node hostnamectl set-hostname siri-awx-02 # run on worker node exec bash

apt update apt upgrade

Step 2 — Disable Swap

swapoff -a sed -i '/ swap / s/^$.*$$/#\1/g' /etc/fstab
Step 3 — Load Kernel Modules

tee /etc/modules-load.d/containerd.conf <<EOF overlay br_netfilter EOF

modprobe overlay modprobe br_netfilter

Step 4 — Configure Kernel Parameters
tee /etc/sysctl.d/kubernetes.conf <<EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 EOF

sysctl --system

Installing Containerd Runtime (All Nodes)
apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg

add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

apt update apt install -y containerd.io

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

systemctl restart containerd systemctl enable containerd

Installing Kubernetes Components (All Nodes)
`sudo apt-get install -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg`

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl

Initialising the Cluster (Master Node — siri-awx-01 Only)

systemctl enable kubelet && systemctl start kubelet kubeadm init

mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config

Tip: If you forget to save the kubeadm join output, regenerate it with:
bashkubeadm token create --print-join-command

$kubectl get nodes

Join Worker Node (siri-awx-02)
Run this on siri-awx-02 (use your actual token from kubeadm init output):

kubeadm join 192.168.237.144:6443 --token uhkvxh.mjp6aiyhy18vaxh0 \ --discovery-token-ca-cert-hash sha256:c0200907cc68957eea6d9cc4ad314282fb58ac92bceef2416e8212040441f130

Install Calico Network Plugin (siri-awx-01 Only)

curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml -O kubectl apply -f calico.yaml kubectl get nodes kubectl get pods -n kube-system

Installing Helm

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh

Deploying Ansible AWX Using Helm

helm install ansible-awx-operator awx-operator/awx-operator -n awx --create-namespace kubectl get pods -n awx

Setting Up Storage — StorageClass, PV and PVC
local-storage-class.yaml

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: local-storage namespace: awx provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer

kubectl create -f local-storage-class.yaml
kubectl get sc -n awx

pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
  namespace: awx
spec:
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/storage # Mount point should available on worker node
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - siri-awx-02    # worker node hostname

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-13-ansible-awx-postgres-13-0
  namespace: awx
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

kubectl apply -f pv.yaml kubectl create -f pvc.yaml kubectl get pv,pvc -n awx

Deploying AWX

`kubectl create -f ansible-awx.yaml

kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager -n awx
`

Accessing the AWX Web Interface

kubectl expose deployment ansible-awx-web --name ansible-awx-web-svc --type NodePort -n awx kubectl get svc ansible-awx-web-svc -n awx

Get admin password

kubectl get secret ansible-awx-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode ; echo

AWX is now accessible at http://: — in my case port 32418. Log in with username admin and the decoded password.

Errors I Hit and How I Fixed Them
Error 1 — Node Taint Issue (Pods Stuck in Pending)

Warning FailedScheduling 2m37s default-scheduler

0/1 nodes are available: 1 node(s) had untolerated taint
{node.kubernetes.io/not-ready: }

First, check the actual taint on your node:
kubectl describe node siri-awx-01 | grep Taints

Taints: node.kubernetes.io/not-ready:NoSchedule

Remove it

kubectl taint nodes siri-awx-01 node.kubernetes.io/not-ready:NoSchedule-

node/siri-awx-01 untainted

After removing the correct taint, pods started coming up properly.

Error 2 — ImagePullSecret Error
FailedToRetrieveImagePullSecret Unable to retrieve some image pull secrets
(redhat-operators-pull-secret); attempting to pull the image may not succeed.

Debug with:
kubectl logs awx-operator-controller-manager-6586fccbdd-xtdvj -n awx kubectl get events -n awx

Fix — edit the deployment and comment out the imagePullSecrets section:

kubectl edit deployment awx-operator-controller-manager -n awx
Kubernetes automatically picks up the changes. No manual restart needed.
Accessing the AWX Web Interface

kubectl expose deployment ansible-awx-web --name ansible-awx-web-svc --type NodePort -n awx kubectl get svc ansible-awx-web-svc -n awx

Get admin password

kubectl get secret ansible-awx-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode ; echo

Final Verification
Once logged in, I ran a demo playbook to make sure everything was wired up correctly. Seeing that first successful job run in the AWX UI after all of this setup was genuinely satisfying.

This wasn’t a smooth “follow steps → done” kind of project.

It was more like:

set up cluster → something breaks
fix networking → something else breaks
fix storage → something else breaks again
finally get AWX running → feels like victory

But I did learn a lot about how Kubernetes actually behaves when things aren’t ideal.

If you’re doing this yourself and hit weird issues, you’re probably not alone—most of the fixes I found were pieced together from random threads and trial-and-error.

Still worth it though.

happy to help! — Sireesha

Automating Windows Server Setup with Ansible: My DevOps Journey (Part 2)

Sireesharaju Kamparaju — Tue, 12 May 2026 13:12:31 +0000

In my previous blog, I covered how I automated Linux server provisioning using Ansible — things like SSH hardening, reusable roles, and playbooks. That setup worked really well, so the next thing I wanted to tackle was Windows.

This post is about the Windows side of the setup — enabling WinRM, creating a reusable Windows role, and finally combining both Linux and Windows automation into a single Ansible workflow..

Windows Automation Feels Different at First
I’ll be honest — moving from Linux automation to Windows automation was a little frustrating in the beginning.

With Linux, Ansible over SSH just works. Most tutorials online assume that setup, so things feel straightforward pretty quickly. Windows was different.

The first thing I learned was that Ansible talks to Windows through WinRM instead of SSH. That meant extra configuration before I could even run my first playbook.

A few things tripped me up early on:

WinRM isn’t enabled by default on fresh Windows servers
The modules are completely different from Linux
Even simple tasks use different syntax and collections
Some errors from WinRM are vague and take time to troubleshoot

At one point I thought my firewall rules were wrong, but it turned out I had messed up the WinRM transport settings in the inventory file.

Once I got past those initial issues though, the setup became much smoother.
Note: Port 5985 should be allowed in firewall.

**First Thing — Bootstrap WinRM (Just Once)
Before Ansible can do anything on a Windows server, WinRM needs to be enabled. I ran this PowerShell script once on each new Windows machine — after that, Ansible handles everything:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"
(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file

The first successful win_ping honestly felt like progress because I’d already spent a while debugging connection issues before getting there.

Adding Windows Hosts to the Inventory
I kept windows and linux in the same inventory file because I wanted one central place to manage everything.

The structure stayed mostly the same, but the connection settings were obviously different:

all:
children:
linux_servers:
hosts:
linux-01:
ansible_host: 10.0.1.10
ansible_user: ec2-user
ansible_ssh_private_key_file: ~/.ssh/id_rsa
windows_servers:
hosts:
win-01:
ansible_host: 10.0.2.10
ansible_user: Administrator
ansible_password: "{{ vault_win_password }}"
ansible_connection: winrm
ansible_winrm_transport: ntlm
ansible_port: 5985

The Windows password is vaulted using ansible-vault — I never put credentials in plain text. That's just a habit I've built early on and I'd recommend everyone do the same.

Building the Windows Role
I kept the same role-based structure I used for Linux. Here's how the Windows role looks:

roles/
windows_setup/
├── tasks/main.yml
└── defaults/main.yml

roles/windows_setup/defaults/main.yml

name: Ensure WinRM service is running and set to auto start
ansible.windows.win_service:
name: WinRM
state: started
start_mode: auto
name: Disable unencrypted WinRM traffic
ansible.windows.win_shell: |
winrm set winrm/config/service '@{AllowUnencrypted="false"}'
name: Configure Windows Firewall to allow WinRM
ansible.windows.win_firewall_rule:
name: WinRM HTTP
localport: "{{ winrm_port }}"
action: allow
direction: in
protocol: tcp
state: present
enabled: true
name: Check for available Windows Security Updates
ansible.windows.win_updates:
category_names:
- SecurityUpdates state: searched register: update_result
name: Display available updates

ansible.builtin.debug:

msg: "{{ update_result.updates | length }} security update(s) available"

The Windows Playbook

name: Configure Windows Servers hosts: windows_servers roles:
- windows_setup

One thing I noticed here — there's no become: true like I used on Linux. Windows doesn't use sudo. The Administrator account takes care of privilege escalation directly.

Bringing It All Together — site.yml
This is the part I enjoyed the most. One playbook, one command, both Linux and Windows configured together:

import_playbook: playbooks/linux_setup.yml
import_playbook: playbooks/windows_setup.yml

And to run everything:
ansible-playbook site.yml -i inventory/hosts.yml --ask-vault-pass

That's it. Ansible runs through Linux first, then Windows — clean and consistent every single time.

ansible windows_servers -i inventory/hosts.yml -m ansible.windows.win_ping

If I get pong back, I know I'm good to go.
WinRM transport depends on your environment. I used ntlm since my servers weren't in a domain. If you're working in an Active Directory setup, kerberos is the better and more secure option.
Don't mix Linux and Windows modules. Early on I made the mistake of trying to use a Linux module on a Windows host — it fails and the error isn't always obvious. Stick to ansible.windows.* for everything Windows-related.

What Changed After Automating This
Before automation, setting up a Windows server usually meant opening RDP, clicking through configuration screens, enabling services manually, and hoping I didn’t forget something important.

Now the process is much simpler:

add the server to inventory,
run the playbook,
wait a few minutes,
done.

That consistency alone made the effort worth it.

Combined with the Linux setup from Part 1, I now have a single Ansible environment managing both Linux and Windows servers from one place. Getting both platforms working together took more troubleshooting than I expected, but finishing it felt genuinely rewarding.
Coming Up in Part 3
I'm planning to cover:

User management across Linux and Windows
Scheduling automated patching
Plugging Ansible into a CI/CD pipeline

Drop your questions or thoughts in the comments — always happy to discuss!
— Sireesha

Automating Linux & Windows Server Setup with Ansible: My DevOps Journey

Sireesharaju Kamparaju — Tue, 12 May 2026 13:01:58 +0000

I started this project because managing servers manually was getting repetitive — especially when it came to setup and configuration across both Linux and Windows machines.

So I decided to automate the whole workflow using Ansible. The goal wasn’t just to “use Ansible,” but to actually standardize how servers are configured and reduce the amount of manual SSH and RDP work I was doing every time a new system came up.

In this blog, I’ll walk through how I used Ansible playbooks and roles to automate server setup, including SSH configuration on Linux and basic provisioning tasks across Windows systems.

Why I Chose Ansible for This

**
Before I started using Ansible, server setup meant logging into each machine manually, running the same commands over and over, and hoping nothing was missed. One wrong step and the configuration was inconsistent across environments. Sound familiar?
What drew me to Ansible was its simplicity — no agents to install, no complex setup. Just SSH into Linux, WinRM into Windows, and you're managing your entire fleet from a single control node. That agentless architecture was a game changer for me.

Project Overview

The goal was straightforward: automate the initial setup of both Linux and Windows servers using a clean, reusable Ansible structure. Here's what I set out to configure:

SSH hardening and configuration on Linux servers
WinRM configuration to enable Ansible to talk to Windows servers
Reusable roles for both OS types
A master playbook to tie everything together.

Setting Up the Project Structure
The first thing I did was organize everything into roles. Roles keep your code clean, reusable, and easy to share across projects. Here's the structure I used:

ansible-server-setup/
├── inventory/
│   ├── hosts.yml
├── roles/
│   ├── linux_ssh/
│   │   ├── tasks/main.yml
│   │   ├── templates/sshd_config.j2
│   │   ├── handlers/main.yml
│   │   └── defaults/main.yml
│   ├── windows_setup/
│   │   ├── tasks/main.yml
│   │   └── defaults/main.yml
├── playbooks/
│   ├── linux_setup.yml
│   ├── windows_setup.yml
└── site.yml

Keeping Linux and Windows roles separate made everything much easier to maintain and debug independently.

The Inventory

I defined both Linux and Windows hosts in a single YAML inventory, with the right connection settings for each:

all:
  children:
    linux_servers:
      hosts:
        linux-01:
          ansible_host: 10.0.1.10
          ansible_user: ec2-user
          ansible_ssh_private_key_file: ~/.ssh/id_rsa
    windows_servers:
      hosts:
        win-01:
          ansible_host: 10.0.2.10
          ansible_user: Administrator
          ansible_password: "{{ vault_win_password }}"
          ansible_connection: winrm
          ansible_winrm_transport: ntlm
          ansible_port: 5985

Notice I vaulted the Windows password using ansible-vault — never hardcode credentials in plain text. Learned that lesson early!

SSH Hardening Role for Linux
This was the core of my Linux setup. The linux_ssh role handles SSH daemon configuration to make servers secure and consistent from day one.
roles/linux_ssh/defaults/main.yml

ssh_port: 22
permit_root_login: "no"
password_authentication: "no"
max_auth_tries: 3

roles/linux_ssh/templates/sshd_config.j2

Port {{ ssh_port }}
PermitRootLogin {{ permit_root_login }}
PasswordAuthentication {{ password_authentication }}
MaxAuthTries {{ max_auth_tries }}
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

---
- name: Deploy SSH configuration
  ansible.builtin.template:
    src: sshd_config.j2
    dest: /etc/ssh/sshd_config
    owner: root
    group: root
    mode: "0600"
  notify: Restart SSH

- name: Ensure SSH service is running and enabled
  ansible.builtin.service:
    name: sshd
    state: started
    enabled: true

roles/linux_ssh/handlers/main.yml


---
- name: Restart SSH
  ansible.builtin.service:
    name: sshd
    state: restarted

The handler ensures SSH only restarts when the config actually changes — not on every run. That small detail matters a lot in production.