123 lines
5.2 KiB
Markdown
123 lines
5.2 KiB
Markdown
# 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)
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
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. |