Platform Automation with Ansible
Ansible is already running in your organization. The problem: 15 teams, 15 playbooks, no common standard.
The tool is there. The question is not whether to use Ansible, but how. Without shared Collections, without agreed standards, without quality gates, a good tool turns into a patchwork that becomes a liability at the next audit or merger.
lennlay Ansible Collections are the enterprise standardization layer that sits on top of what your teams already have. Not starting over. Getting it right.
The Ansible Sprawl Problem
One organization, multiple teams. Everyone uses Ansible. Nobody uses it the same way. That is not a housekeeping issue. It is a security and audit risk.
- Team A installs JBoss EAP with one role. Team B has their own. Both do "the same thing" — but differently.
- "Worked for us" is the documentation. And the knowledge lives with one person.
- Security hardening is a separate manual step. Done sometimes.
- No shared module versions. No consistent variable naming. No shared Galaxy requirements file.
- A merger brings three more teams with three more playbook styles. Six approaches, one environment.
- Manual effort: Every new system requires manual adjustments because the roles are not interchangeable.
- Audit risk: An auditor asks what hardening measures are running on production systems. "Somewhere in a playbook" is not an answer.
- Drift: Systems that should be identical diverge. The difference only shows up when something breaks.
- Knowledge loss: The colleague who knows all of this leaves. The playbook stays. The understanding goes.
- Merger backlog: Three new teams, three new styles. Consolidation takes years instead of weeks.
The Three Layers of lennlay Collections
Not a monolith. Not a black box. A cleanly layered architecture where each level builds on the one below.
Platform-specific enterprise Collections. Not generic — opinionated, tested, and CIS-hardening-aware. For JBoss EAP: installation, hardening, configuration, deployment. For Apache Tomcat: connector protection, manager lockdown, security headers.
The enterprise foundation. Shared platform roles across all enterprise use cases. Configuration standards, shared variables, common utilities. The layer that enforces consistency regardless of which platform-specific collection is on top.
Public on Ansible Galaxy. Apache License 2.0. Contains the foundation: artifact_download, java, wildfly, service, release_software. Not a teaser, not a limited preview. A real, immediately usable base for platform tasks.
View on Ansible GalaxyWhat lennlay.jboss Actually Does
Not a generic JBoss role. An opinionated enterprise Collection that covers every step of the JBoss EAP lifecycle.
Installation
Reproducible JBoss EAP installation. Same result, every environment, every time. Variables for version, install path, and service user. No manual unpacking, no unknown state afterwards.
Hardening
CIS-Benchmark-referenced security configuration: management interface controls, network binding, security subsystem settings. Applied on first install, not as an optional step bolted on later.
Configuration
standalone.xml and domain.xml managed via Ansible. Datasources, security domains, connector config. All as code, versioned in Git. No manual admin console changes in production.
Deployment
Application deployments via Ansible roles. No manual console access in the deployment path. Repeatable, auditable. Every deployment change traceable in Git.
What lennlay.tomcat Actually Does
Apache Tomcat is widely deployed and frequently under-secured. lennlay.tomcat sets standards that hold up to audit findings.
Connector Hardening
AJP connector secured with RequiredSecret or disabled. Shutdown port controlled. HTTP methods filtered (TRACE disabled). Connector protocol standards enforced rather than left at defaults.
Manager Protection
Manager and Host-Manager applications secured or removed. Default credentials eliminated. Access restricted to defined network ranges. No open management interface in production.
Security Headers
X-Frame-Options, X-Content-Type-Options, HSTS, and Content-Security-Policy as part of the deployment standard. Not as a retrospective fix — built into the role from the start.
AAP Integration and CI/CD
lennlay Collections are not designed for CLI use alone. They are built for the enterprise environment.
Inside Ansible Automation Platform (AAP), lennlay Collection roles work as structured building blocks for job templates. Survey variables, approval workflows, and execution environments are accounted for from the start, not retrofitted.
For CI/CD environments (GitLab CI, Jenkins), the Collections are available for automated platform validation runs. Every configuration change goes through the same quality gates as application code before it reaches production systems.
GitOps workflows are supported throughout: all Collections are designed to be driven entirely from a Git repository. No out-of-band intervention, no undocumented state.
Collection roles as structured AAP building blocks with survey variables and approval workflows.
Automated platform validation runs in CI. Catch regressions before the merge, not after the deploy.
Full Git-driven control. No manual changes outside the defined process.
Collections prepared for AAP-compatible EEs. Reproducible runtime environments for every automation run.
Three Situations Where Standardization Counts Now
More teams, more servers, no standard
Ansible usage is growing. Without a shared Collection foundation, inconsistency grows with it. Before that divergence becomes a security problem, now is the right time to establish common ground.
Audit coming. Playbooks won't hold up.
Current Ansible playbooks are undocumented and unstandardized. Demonstrating to an auditor what they do and do not do is very difficult without a structured Collection foundation. lennlay Collections establish that foundation.
New teams, new playbooks, no shared standard
Mergers bring playbook styles. Three new teams, three new approaches. Starting with a shared Collection standard is cheaper than three years of merge conflicts. This is the entry point.
Tell us about your current automation situation. In 15 minutes we can work out where lennlay Collections can make a concrete difference, what is available today, and what is in progress.
