Skip to content

Technical Reference: Rhapsody Status Check Logic

Parent Page: [How-To: Rhapsody Status Workflows] Description: This document details the step-by-step technical execution performed by the Ansible playbook (play-rhapsody-status.yml) and its role (rhapsody_status) when verifying the health of a Rhapsody instance.

🔍 High-Level Overview

This automation acts as a "sanity check" to verify that the Rhapsody engine is actually running and responding to HTTP requests on the target VM. It performs local connectivity checks (avoiding external firewall issues) and dumps the HTTP headers and body to the workflow logs for verification.

🔄 Workflow Diagram

graph TD
    A[Start] --> B{Execution Context Check}
    B -- Is GitHub Runner --> C[Fail Execution]
    B -- Is Target VM --> D[Gather Context]
    D --> E{Wait for Port 8444}
    E -- IPv4 (127.0.0.1) --> F[Target Found]
    E -- IPv6 (::1) --> F
    E -- Timeout --> G[Fail: Service Down]
    F --> H[Curl Headers (NO_PROXY)]
    H --> I[Curl Body (NO_PROXY)]
    I --> J[Display Output]
    J --> K[Finish]

🛠️ Detailed Execution Steps

1. Pre-Flight Assertions

To prevent "false positives" where the playbook might accidentally run on the controller node instead of the target, the script verifies the execution environment.

  • Hostname Check: Asserts that github-runner is not present in the hostname.

  • Context: Logs the current user ID and hostname to confirm the Ansible connection to the Azure VM was successful.

2. Service Listener Checks

The playbook attempts to verify that the Rhapsody process has bound to the standard HTTPS port (8444).

  • IPv4 Priority: First attempts to wait for 127.0.0.1:8444.

  • IPv6 Fallback: If IPv4 is not detected, it checks [::1]:8444.

  • Timeout: Fails if no listener is detected within 60 seconds (30s per protocol), indicating the Rhapsody service is stopped or crashed.

3. HTTP Health Check (Curl)

Once the port is open, the playbook uses curl to fetch the Rhapsody login page. This is done locally on the VM (localhost) to prove the application is handling requests.

Key Flags Used:

  • -k: Skip SSL certificate verification (since we are hitting localhost, the cert CN likely won't match).

  • -I: Fetch Headers only (first task).

  • -L: Follow redirects (essential as Rhapsody often redirects root / to /rhapsody/login).

  • --max-time 5: Prevents hanging if the engine is "zombie" (listening but not responding).

4. Proxy Bypassing

A critical component of this logic is the explicit nullification of proxy variables.

  • The Problem: Many enterprise environments force http_proxy variables for all user sessions. If curl tries to hit localhost via a corporate proxy, it will fail.

  • The Fix: The playbook explicitly injects the following environment variables for the curl command:

    NO_PROXY: "127.0.0.1,localhost,::1"
HTTP_PROXY: ""
HTTPS_PROXY: ""

5. Output Reporting

The playbook registers the stdout from the curl commands and prints them to the Ansible console.

  • Headers: Useful for checking HTTP Status codes (e.g., 200 OK, 302 Found).

  • Body: Useful for verifying that the HTML content returned is actually the Rhapsody Login page and not a generic error page.

⚠️ Technical Notes & Debugging

  • "Debug Mode": The role contains hidden tasks (showing ss -ltnp and environment variables) that only run if the variable debug_rhapsody is set to true. This is useful for deep-dive troubleshooting if the status check fails mysteriously.

  • User Context: All checks run as azureuser using become: true, ensuring permissions are consistent with how an administrator would manually check the server.