kodekloud-engineer/100 - days of devops/devops-82.md

Assignment

The Nautilus DevOps team is testing Ansible playbooks on various servers within their stack. They've placed some playbooks under /home/thor/playbook/ directory on the jump host and now intend to test them on app server 3 in Stratos DC. However, an inventory file needs creation for Ansible to connect to the respective app. Here are the requirements:

a. Create an ini type Ansible inventory file /home/thor/playbook/inventory on jump host.

b. Include App Server 3 in this inventory along with necessary variables for proper functionality.

c. Ensure the inventory hostname corresponds to the server name as per the wiki, for example stapp01 for app server 1 in Stratos DC.

Note: Validation will execute the playbook using the command ansible-playbook -i inventory playbook.yml. Ensure the playbook functions properly without any extra arguments.

Solution

Ansible Inventory — App Server 3 (stapp03)

Create an INI-format inventory at /home/thor/playbook/inventory so ansible-playbook -i inventory playbook.yml connects to App Server 3 with no extra arguments.

Note: this is an Ansible task, not Kubernetes — there's no manifest to pipe into kubectl. The heredoc below writes the inventory file instead.

Create the inventory (heredoc → file)

cat > /home/thor/playbook/inventory <<'EOF'
[app_servers]
stapp03 ansible_user=banner ansible_ssh_pass=BigGr33n ansible_connection=ssh
EOF

How it works

Why the hostname must be stapp03

Requirement (c) pins the inventory hostname to the server name from the wiki — stapp01, stapp02, stapp03 for App Servers 1–3 in Stratos DC. This matters twice over:

1. The playbook's hosts: directive refers to hosts (or groups) by these names. Naming the entry appserver3 or a raw IP would mean hosts: stapp03 never matches, and Ansible skips with "no hosts matched."
2. stapp03 is itself resolvable from the jump host (via /etc/hosts / DNS in the lab network), so the inventory name doubles as the connection target. That's why no ansible_host is needed — Ansible resolves stapp03 directly. Hardcoding an IP would add an assumption that could be wrong and break a setup that otherwise works.

Confirm resolution before running anything:

getent hosts stapp03        # or: grep stapp /etc/hosts

If that returns an address, you're set. ansible_host is only warranted in the rare case where the name doesn't resolve — and then you'd take the IP from that lookup or the wiki.

The connection variables

Each key=value after the hostname is a host variable telling Ansible how to authenticate:

Variable	Purpose
ansible_user	SSH username on App Server 3.
ansible_ssh_pass	SSH password. Needed because these servers use password auth, not key-based.
ansible_connection	Transport plugin; ssh is the default for remote hosts, stated explicitly for clarity.

Verify the credentials against your lab's wiki. The values shown (banner / BigGr33n) follow the common Stratos DC pattern, but treat them as placeholders to confirm rather than facts — substitute whatever the wiki lists for App Server 3.

Why the variables live in the inventory

The validation runs exactly ansible-playbook -i inventory playbook.yml — no -u, no -k, no --private-key. So every piece of connection information must come from the inventory file itself. Putting user and password in as host vars is what makes the bare command work; omitting them would force Ansible to fall back to the current user and key-based auth, and the connection would fail.

Password auth needs sshpass

ansible_ssh_pass requires the sshpass utility on the control node (the jump host). It's normally pre-installed in these labs; if Ansible errors with "to use the 'ssh' connection type with passwords, you must install the sshpass program," install it (sudo yum install -y sshpass).

Host key checking

A first-time SSH connection can fail on host-key verification. The safest fix for the validation is an ansible.cfg beside the playbook, since it applies with no extra command-line arguments:

cat > /home/thor/playbook/ansible.cfg <<'EOF'
[defaults]
host_key_checking = False
EOF

(The equivalent export ANSIBLE_HOST_KEY_CHECKING=False works too, but relies on the environment being set when validation runs.)

Verify

cd /home/thor/playbook

# Inventory parses and lists stapp03
ansible-inventory -i inventory --list

# Connectivity check — this settles hostname resolution AND credentials at once
ansible -i inventory stapp03 -m ping

# The actual validation command
ansible-playbook -i inventory playbook.yml

Expected — ansible-inventory showing stapp03 with its vars, the ping returning "ping": "pong" with SUCCESS, and the playbook running to completion with no failed tasks.

UNREACHABLE on the ping means either the hostname didn't resolve (check getent hosts stapp03) or the user/password don't match the wiki. "No hosts matched" from the playbook means its hosts: value doesn't align with stapp03 or the group name — open playbook.yml and match the inventory group to it.