Modernize Your JBoss Platform
You inherit a JBoss landscape. Every instance is the fingerprint of whoever configured it last. No shared standard. No documented baseline. Just servers that run, and the question: what is the actual correct state here?
Day one as the new platform lead. You find 23 JBoss instances.
The instances run core business operations: mission-critical applications, payment processing, customer data. The previous admin is gone. What they built still runs. What exactly runs, and why it was configured this way, nobody knows anymore.
- jboss-prod-01 EAP 7.1 — EOL since 2022
- jboss-prod-02 EAP 7.4.8 — manually patched
- jboss-prod-03 EAP 7.4.12 — script unknown
- Management Console exposed to network (7 instances)
- Management Console localhost only (16 instances)
- Startup scripts 4 different variants
- Connector config 6 different variants
- JVM heap settings undocumented everywhere
- Baseline not defined
- Previous admin unreachable
A binding baseline that says: this is what a correct JBoss EAP instance looks like in this environment. Not a Word document, but code in a repository that can actually be enforced.
The baseline is applied to every instance, reproducibly and without manual steps. What was once configured stays configured, and can be restored to that exact state at any time.
Which instance has which configuration? When was it changed? What deviates from the baseline? These answers come from version control, not from someone's memory or institutional knowledge.
Next time someone leaves, the knowledge stays. It lives in Ansible roles and Git repositories, not in a single person who has left the building.
Not an update. A foundation.
Upgrading JBoss to a newer version is not modernization. Modernization means that afterwards you know what is running, why it is running that way, and that you can reproduce that exact state at any point in time.
Which instances exist, which JBoss versions are running, which applications are deployed, where discrepancies between instances occur. No assumptions, only facts from the actual environment.
What should a JBoss EAP instance in your environment look like? Which ports are open, which are not? Which security settings apply universally? This gets written down as code, not decided in a meeting and then forgotten.
The baseline is applied to every instance, automatically. Ansible roles, not scripts someone wrote one afternoon. Reproducible. Verifiable. Applicable again whenever needed.
Every instance configuration is documented, versioned, and auditable. Not as screenshots or Word documents, but as code in a repository that captures the history of every change.
Ansible roles for every step of JBoss operations
The lennlay.jboss Enterprise Collection bundles roles for installation, hardening, configuration management, and compliance checking. Everything needed to keep JBoss EAP instances in a defined, traceable, reproducible state.
JBoss EAP is installed in a defined, reproducible way. No manual steps, no open questions after the fact, no "I think this is how it was installed" the next time around. Run the role, get the same result.
CIS-based hardening baseline: management interface protection, connector configuration, security subsystem. Not manual checklist work, but an automated, repeatable policy. Every instance gets the same baseline applied the same way.
Standardized configuration management. Application deployments run through Ansible, not through the management console or SCP. What is deployed is documented, versioned, and traceable back to a decision.
Scanner scripts check a running JBoss instance against the defined baseline. Configuration drift is detected before the auditor finds it. Not as a one-time scan, but as an ongoing check of the actual state against what it should be.
The JBoss baseline as a delivered artifact
Red Hat JBoss EAP is in the GIaaS MVP catalog. The hardened JBoss baseline exists as a policy-governed artifact, not as a manual configuration living on a single server that can never be reproduced in exactly the same way again.
GIaaS sells no images. GIaaS sells security, responsibility, and audit peace of mind.
Defines what a compliant JBoss EAP instance looks like. Security requirements, configuration standards, patch level.
Automated build process. The policy is translated into a concrete, tested artifact. No manual step between definition and output.
The artifact is versioned, signed, and made available in a controlled catalog. No ad-hoc images, no unknown provenance.
Delivered to the target environment. Every recipient knows exactly what they are getting and can verify it against the policy.
JBoss EAP requires a valid Red Hat subscription.
Three moments when standardization stops being optional
JBoss EAP versions are approaching end of life. There is no clear migration path because there is no defined standard to migrate toward. Without a baseline, there is no target platform to work toward.
An internal or external audit is coming. Every instance has a different configuration. No documented baseline exists. The first question the auditor asks cannot be answered by anyone in the room.
The person who knows the JBoss landscape has left the company. The institutional knowledge about configuration, dependencies, and undocumented decisions is gone with them. What remains are servers that run, and nobody who can explain why they are set up the way they are.
Analyze your JBoss platform
Tell us about your JBoss situation. In 15 minutes we will identify what the right first step is, and whether EaaS, the jboss Collection, or GIaaS is the right entry point for your environment.
