Ansible Playbook Tutorial: Install and Configure Nginx on Ubuntu covers a practical workflow that teams can reproduce and audit. It connects the tool’s architecture to an example setup, validation, common failure modes, and production controls. Run the examples only on resources you own or are authorized to manage, and confirm current provider and tool versions before applying changes.
Why configuration management beats command history
One Ubuntu server may be easy to configure by hand. Twenty servers installed at different times are another story. Ansible describes tasks that should bring machines toward a desired state, and many modules are designed to be idempotent. For our example, a control machine will configure Nginx on a test VM through SSH. Use a disposable host and verify a working SSH key and sudo rights first. Avoid running unreviewed playbooks against a broad inventory of production IP addresses.
Prepare inventory and access
Install Ansible with a supported package or isolated Python environment on the control host. Create an inventory file grouping your test machine as webservers. Define the address, SSH user and connection settings without committing private keys or passwords. Try ansible webservers -i inventory.ini -m ansible.builtin.ping to confirm connectivity and a usable Python interpreter on the managed host. This ping module is not an ICMP network ping; it verifies that Ansible can execute its module remotely.
Write an idempotent playbook
A YAML play should include hosts: webservers, become: true, and tasks using ansible.builtin.apt to ensure Nginx is present. Add ansible.builtin.service to ensure it is enabled and running. Avoid using shell commands for actions that have purpose-built modules, because modules usually provide clearer change reporting and better idempotence. Install a controlled site configuration using ansible.builtin.template and a Jinja2 template stored with the repository. Keep environment-specific values in inventory variables or protected variable sources.
Use handlers to reload only when needed
The template task can notify a handler to reload Nginx when its content changes. Pair this with a syntax check such as nginx -t before a reload, using task ordering or a validation option that fits the module. Run ansible-playbook -i inventory.ini site.yml --check --diff for a preview, recognizing that check mode is not perfectly predictive for every module. Then run the actual playbook on your test host and inspect task results. Running it a second time should ideally show no changes unless some configuration has drifted.
Verify from outside the target
Use curl -I http://TEST_HOST from an authorized network, inspect Nginx status and ensure only intended ports are reachable. If SSH fails, check inventory identity and network rules. If the apt task fails, inspect repository health or privilege escalation. If template output is invalid, fix the source Jinja2 and add a validation test rather than editing the target file by hand. Ansible’s changed output is useful but insufficient: the service may be enabled and still return the wrong website.
Move from a demo play to a managed role
For more than one service, organize variables, handlers, templates and tasks into roles with clear inputs. Protect sensitive values using Vault or an approved secret backend and keep decryption keys outside the repository. Use rolling batches such as serial to avoid reconfiguring every server at once. Add linting and integration tests in CI. Record package versions where reproducibility matters and define rollback steps. Configuration management should make changes reviewable and repeatable without giving every engineer unfettered root access.
Example review: what should happen from commit to recovery?
Imagine a teammate joins the on-call rotation and has to explain a release without asking the original author. Can they locate the configuration revision, determine which credentials were used, inspect the result, and revert to a known-good state? Capture the exact steps in your README or runbook. Start from a clean environment, perform the documented setup, and test one normal request. Then simulate a failure such as an unavailable dependency, unauthorized registry access, or bad configuration. Observe whether the system reports a useful error and whether an operator can safely stop or roll back the change.
Keep setup, verification and cleanup commands separated; it should never be easy to run a destructive cleanup step while following initial instructions. If your workflow changes persistent state, rehearse backup restoration separately from application rollback. Prefer small, reviewed changes and collect the outcome of each step so a failed deployment doesn’t become a guessing game.
Practical release and security checklist
Pin dependencies and external actions where practical, use least-privilege identity, and keep secrets outside repository history. Avoid making network services publicly reachable just to simplify a demo. Apply linting or schema validation before changing live state, then execute a real functional smoke test afterward. Store enough logs and metrics to explain failures while minimizing personal and sensitive data retention. Assign clear ownership for upgrades and rollback. When an automated system manages infrastructure, audit its own permissions as carefully as those of human operators.
Frequently asked questions
Does a successful automation run prove a production release is healthy?
No. It usually proves that the requested automation completed. Verify the result with a real application request, resource status, telemetry and an explicit rollback test where possible.
How should a small team introduce this tooling?
Start with one noncritical service and one documented owner. Establish a baseline before automating every environment, require peer review for privileged changes, and compare added complexity to the operational problems it actually solves.
Primary source
Consult the official upstream documentation for current configuration options and supported versions. For parallel experience in packaging and operating AI services, see the FastAPI Dockerfile guide and our Kubernetes deployment walkthrough.
Idempotence exercise: run the same play twice
After your test VM is configured, execute ansible-playbook -i inventory.ini site.yml and record which tasks report changed. Run it again without altering inventory or templates. Ideally, the second run reports no changes for tasks that are already in the desired state. Now alter a harmless Nginx banner or site configuration template, run check mode to preview the diff, and apply the update. Observe that the reload handler triggers only when the managed template changes.
Do not edit the target manually to make the test pass; the goal is to demonstrate repeatable configuration management. Keep playbooks in code review and use separate inventories for staging and production. The Nginx HTTPS tutorial
