Configuration and Deployment
Introduction
This document covers the environment variables, Docker deployment, and operational considerations for the Ansible Service.
Configuration
The service is configured primarily through environment variables.
Environment Variables
| Variable | Required | Default | Description |
|---|---|---|---|
PORT | No | 8080 | Port the API service will listen on. |
GIN_MODE | No | release | Gin framework mode (debug or release). |
Deployment
Docker Deployment
The service is containerized using a multi-stage Docker build.
Dockerfile Summary:
- Builder: Uses
golang:alpineto build the static binary. - Runtime: Uses
alpine:latestand installsansible,openssh-client, andsshpass.
Running with Docker:
docker build -t ravenxcope-ansible:latest .
docker run -d \
--name ansible-service \
-p 8080:8080 \
ravenxcope-ansible:latest
[!IMPORTANT] The container must have
ansibleand SSH utilities installed because it executes theansible-playbookcommand as a subprocess.
SSH Authentication
The service supports password-based SSH authentication for remote hosts. It uses the sshpass utility internally (via Ansible) to handle passwords provided in the API request.
Host Key Checking
By default, the service disables SSH host key checking (ANSIBLE_HOST_KEY_CHECKING=False) to ensure that automated deployments are not blocked by interactive "trust this host" prompts.
Operational Notes
1. In-Memory Executions
Playbook execution records are stored in an in-memory map.
- Risk: Restarting the service will clear all execution history and logs.
- Best Practice: The Ravenxcope Backend should capture and persist the final status/output if long-term history is required.
2. Concurrency
The service uses Go routines to run playbooks asynchronously.
- Multiple playbooks can run simultaneously.
- Sudo/privilege escalation is handled via
ansible_become_passprovided in the request.
3. Rule Storage
The rules-default/ directory should be backed up or mounted to a persistent volume if rule uploads are frequent.