Implementing XL Deploy, part 2: technical considerations

XebiaLabs' CTO Vincent Partington discussed some important organizational topics you will want to address while introducing deployment automation using XL Deploy. Preparing your organization is, of course, crucial to getting maximum possible benefits from deployment automation. A few technical considerations also apply when introducing XL Deploy, and here we'd like to go into these so that you can be sure your infrastructure is ready when it comes to carrying out your first fully automated deployment.

Preparing your infrastructure

Getting XL Deploy running on your infrastructure usually requires only minimal adjustments, but you'll be able to get up and running even more quickly if a couple of things are set up in advance.

Configuring LDAP groups

Roles and access rights in XL Deploy are associated with users and groups in your LDAP. Once you have thought about who should have which permissions in your organization you can create the appropriate LDAP groups and assign users to them. Common examples are a developers group (or even one per application or "funtional area"), a set of deployers, middleware-experts and, of course, the administrators. If some of your development is outsourced and you're going to set up XL Deploy to allow externals to carry out secure "self-service" deployments, you'll want to consider how to manage their access rights. One account per project or oursourcer is common, but we've also seen limited LDAP federation used here.

Identifying a XL Deploy host

In a normal installation, the XL Deploy server runs as a standalone Java 1.5 application. Its low resource footprint means that you don't usually need a dedicated machine; we usually see XL Deploy installed on a "utility" box. Since the XL Deploy server will attempt to make connections to the target machines, it is, however, essential to choose a host with network connectivity to all the machines XL Deploy will manage. The ports that need to be accessible will depend on the connection type, with SSH being by far the most common option. Of course, the XL Deploy server will also have to be able to access the LDAP used for authentication. Users working with XL Deploy's Flex GUI simply use a web browser to connect to the server. Obviously, they need to be able to make HTTP(S) connections from their local machines to the XL Deploy server to do this.

Preparing target machines

As XL Deploy is agent-less, no intrusive changes to the managed machines are required. A couple of small things are worth verifying before installing XL Deploy, though. Obviously, the XL Deploy server will need to be able to connect to the managed machines, using the protocol and credentials given. Verifying that the specified account is correctly set up, can connect remotely and has sufficient permissions to execute management commands (refer to the User Guide requires authentication) is a good idea. You can also use different credentials for connecting to the target machine and command execution, by specifying a SUDO user. If so, check that that user will be able to run the management commands.

Checking your middleware configuration

XL Deploy supports many versions of popular middleware stacks such as WebSphere, WebLogic and JBoss; check for your version on the list. Since XL Deploy uses native management interfaces, such as wsadmin and WLST, to manage and deploy to middleware, you're generally quite free to set up your middleware installation in your preferred way. For some stacks there are a small number of requirements, such as wsadmin being installed. Also, if you will be deploying Java EE applications that are "fronted" by a web server such as Apache, XL Deploy needs to be able to modify the web server's configuration. The documentation of the standard plugins describes these requirements in detail, and it's good to check them in advance. In some cases, such as deploying to Tomcat, certain features depend on specifc container configurations or modules. Deployments can also be carried out on a "bare-bones" installation, of course, which may well be enough for your needs.

Preparing data for your Configuration Item Repository

In order know how to connect to and manage your target machines, XL Deploy needs some information about your environments, such as the IP addresses or hostnames of servers, or the WAS home directory of a WebSphere cell. By looking at the Configuration Items you plan to use, it's easy to get an overview of the pieces of information required. Collecting these and extracting them from CMDBs and similar data sources, where appropriate, will make it easy to automatically feed them into XL Deploy via its Command Line Interface.

Next steps

Running through this checklist will put your in a great position to get XL Deploy installed, up and running and carrying out deployments using the out-of-the-box processes with a minimum of hassle. Next time, we'll discuss how to identify and evaluate the need for customizations to the standard process, and how you can go about further adapting XL Deploy to your organization's procedures.If you want to know more, these and other relevant issues - technical as well as business-oriented - are covered in detail in the free XL Deploy Training Series.