Installation Scenarios for CDA

This chapter provides an overview on how you can set up Automic Continuous Delivery Automation in your organization.

The user of Automic Continuous Delivery Automation uses the CDA Client with browser-based access to Web Application and user interfaces. One of the clients is used for administrative purposes. Therefore database management tools are also installed on one of the clients.

All components (see CDA Architecture) can either be installed on one server (one-box installation) or on separate servers, even with different operating systems. The requirements for each component are described in the subsequent General Requirements for Upgrading CDA chapters.

The relationship between the various components depends on how you implement CDA in your organization:

• All components run on one server.
• All application components on one server, with a separate database server/cluster:
  • With one database server/cluster
  • With two separate database servers
• Two servers with separate, local database servers

For an illustration and explanation for each scenario, see the sections that follow.

Important! Before starting with the deployment of Automic Continuous Delivery Automation modules, we strongly recommend getting familiar with the structure and inter-dependencies (see CDA Architecture) of modules and General Requirements for Upgrading CDA. You are also requested to come to basic decisions on user and user groups, and to define authorization hierarchy and naming conventions.

In this scenario, the following applies:

• CDA CLI can be installed on any Windows-machine
• Agent-Setup is an example: The agent distribution has to be designed according to needs of specific IT architecture (network security, scalability). A typical setup includes one agent on the central server for all Database- and Webservices-related actions and local agents for all the other deployment targets. For application server management, there is typically one agent on the administration server of a domain or cell (Weblogic, Websphere) or locally for standalone servers and for JBOSS, one local agent on any of the JBOSS instances in a farm is recommended. For IIS management, a local agent is required. For Apache Tomcat, a local agent is recommended.

CDAImplementation on One Server but with Separate Databases

You can install all components, except the database components, on one server and have the databases on a separate server or cluster. Two variations of this installation scenario are described here:

• The CDA and the Automation Engine databases on the same server, separate from all the other components
• The CDA and the Automation Engine databases each on their own servers, and separate from the server for all the other components

Illustrations of each of these scenarios for separate database servers follow.

Note: The operating system interactions are excluded from this description, but they are still part of the overall processing. For a detailed view of all components in a CDA installation, see the scenario that is described in CDA Implementation on One Server.

Note: The operating system interactions are excluded from this description, but they are still part of the overall processing. For a detailed view of all components in a CDA installation, see the scenario that is described in CDA Implementation on One Server.

Note: The operating system interactions are excluded from this description, but they are still part of the overall processing. For a detailed view of all components in a CDA installation, see the scenario that is described in CDA Implementation on One Server.

Variations

Further feasible variations on the previous scenario would be:

• Having the databases on extra, separate servers. This approach combines the previous illustration and the scenarios illustrated in ARA Implementation on One Server but with Separate Databases.
• Installing AWI on the Automation Engine server or on a separate server altogether.

CDA Implementation with an Active/Active Configuration

You can install CDA with all its related components and run them using and active/active configuration. In this case, you need to use a separate load balancing component to manage the traffic between components by detecting outages and dynamically re-routing traffic as needed.

If you use an active/active configuration, be aware of the following:

• Failover may take up to 15 seconds of downtime.
• User sessions are not automatically transferred, so users need to log in again.
• Active/active mode can be used only for servers. Databases must be shared between all instances.
• Sticky sessions must be supported. Like many Java webapps, CDA uses the JSESSIONID session cookie. You can configure your load balancer to use this cookie or add its own to route requests of the same session to the same server.
• If you run CDA with WebSockets enabled, your load balancer must support them.
• Use the same path on your load balancer and the servlet containers. Example: If your servers are on http://backend1/ara and http://backend2/ara, and your load balancer is located on the host publicatahost, configure your load balancer to serve CDA on http(s)://publicarahost/ara
• The AWI instance and the CDA instance of an installation are bound together. Therefore, the AWI instance that is defined in the customer.config file (Automic\Release.Manager\WebUI\customer.config) and the CDA instance that is defined in the connection.properties file of the webui-plugin-bond folder must point to the corresponding AWI/CDA instances of the same installation.

The following illustration shows you the overall relationship between components when implementing CDA with an active/active configuration. The diagram illustrates the active/active configuration with one server as a high-level overview.