Five features of JBoss EAP that help you get production ready

JBoss Enterprise Application Server 7 has been out since June, and if you build and deliver using a Java EE environment and haven’t yet upgraded to EAP7, it’s time to make the jump.

Here’s a look at what’s new in JBoss EAP 7, what has changed since JBoss EAP 6, and how to get the most out of JBoss EAP 7 as your Java EE7 server.

Overview

JBoss EAP 7 is bassed on WildFly Application Server 10, which provides a complete implementation of the Java EE 7 Full and Web Profile standards. WildFly 10 does much to simplify modern application delivery based on containers and microservices.

JBoss EAP 7 features certified support for Java EE7 and Java 8 SE. The WildFly integration brings experimental Java 9 support, too. It also supports current development snapshots of Java 9, which is expected for release this fall.

The JBOSS EAP 7 release is available for download from JBoss.org.

Continue reading “Five features of JBoss EAP that help you get production ready”

Share

Top 10 "Yum" installables to be productive as a developer on Red Hat Enterprise Linux

Red Hat Enterprise Linux (RHEL) is not Ubuntu. Out of the box, it seems the default packages installed for developers are somewhat limited. To provide exceptional long-term stability, Red Hat takes a different approach to default packages and software repositories (repos). Development tools aren’t installed unless specifically selected. The repos that are initially enabled only contain packages that Red Hat supports over the long term lifecycle of RHEL. Because RHEL’s default repos don’t have as large a selection of development tools as other freely available operating systems’ servers, that doesn’t mean you are out of luck. Enabling a few additional repos from Red Hat and a third party makes a wide variety of packages available using the same familiar yum commands.

In preparing to write this article, I spent hours scouring RHEL’s package lists in order to highlight some of the most useful “yum” installables that you can use to supercharge your development productivity. Some are available from the default repos, others require enabling an additional repo which I’ll point out. Here are my top 10.

Continue reading “Top 10 "Yum" installables to be productive as a developer on Red Hat Enterprise Linux”

Share

How to install and configure Jenkins to build .NET apps on Red Hat Enterprise Linux

In the process of writing my posts (#1 and #2) on .NET Core and RHEL, it was made clear to me by several friends that I had neglected to use the de facto standard for continuous integration on Linux, Jenkins. Always happy to try out new (to me) tools, I settled in for what I was assured would be a simple configuration to test out my previous work in this bastion of automation.

What is Jenkins?

The first order of business was to understand the difference between Jenkins and TeamCity, another popular CI platform. After 20 minutes of reading, I discovered the following crucial differences:

  • Jenkins has been around longer (though not always under the Jenkins moniker).
  • Jenkins is open source.
  • There are many plugins for Jenkins.

Other than these three things, any noteworthy differences I found seemed to ultimately boil down to personal preference. Even so, with my research out of the way, it was off to the races!

Continue reading “How to install and configure Jenkins to build .NET apps on Red Hat Enterprise Linux”

Share

How to install and configure Ansible on Red Hat Enterprise Linux

With DevOps taking hold in businesses ranging from small design agencies to large enterprises, there has been a real push to automate deployments and make them consistent. As part of this, maintaining configuration as code and utilizing a version control system such as Git or Subversion to house it is becoming more prominent. Tools like Puppet and Chef have been around for a number of years, but many find these difficult or cumbersome to configure. Then Ansible came along. This article is going to show you how to get started with Ansible and demonstrate how it has become a viable alternative to Puppet or Chef.

Our Objectives

  • Establish Prerequisites
  • Install Ansible
  • Discuss Ansible layout
  • Create a basic configuration

Establish Prerequisites

For the purposes of this article, we’re working on a Red Hat Enterprise Linux 7.2 server which has been registered to the Red Hat Network for updates using subscription-manager register --auto-attach. The easiest way to install Ansible is by adding a third-party repository named EPEL (Extra Packages for Enterprise Linux), which is maintained over at http://fedoraproject.org/wiki/EPEL. You can easily add the repo by running the following command:

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

No other software is required as Ansible utilizes SSH to interact with remote servers.

Continue reading “How to install and configure Ansible on Red Hat Enterprise Linux”

Share

Six popular incident management tools for Red Hat Enterprise Linux

From a developer’s perspective, “incident management” can be a pretty ambiguous term. While the first thing that comes to mind is receiving and responding to alerts, most IT professionals know it is so much more than that. Effective incident management starts with data collection and continues through alerting, escalation, collaboration, and resolution. At the server level, the most important pieces of incident management are infrastructure monitoring and log management, the vast majority of which are easily configurable on a Red Hat Enterprise Linux system.

When it comes to incident management tools, they can be grouped into two separate categories depending on the security requirements of your organization: internal and external.

Continue reading “Six popular incident management tools for Red Hat Enterprise Linux”

Share

Why Red Hat’s new ‘dnf’ package manager is not “just another ‘yum'”

Around this time last year, Fedora 22 brought a major update for anyone working under the Fedora hood — Yum was deprecated and replaced by DNF.  It brings some significant changes:

  • Faster, more mathematically correct method for solving dependency resolution
  • A “clean”, well documented Python API with C bindings &
  • Python 3 support

Isn’t this a Release by Another Name?

No, DNF marks a shift, and not just a fork to Python 3, C support and cleaner docs.  The move to libsolv, librepo and a slim, planned API means Yum’s organic sprawl and bespoke depsolving are being phased out.

The shift solves old depsolving problems and readies DNF for some of the changes afoot in the devops world — e.g. empowered and independent devops-ers who don’t want to reinvent the wheel on each deploy.  Whether that warrants more than a major release is a bike-shed argument.

Continue reading “Why Red Hat’s new ‘dnf’ package manager is not “just another ‘yum’””

Share