Page tree
Skip to end of metadata
Go to start of metadata

Introduction

AIP Console 2.x brings improvements and changes, mainly designed to improve the overall flexibility of deployment and application analysis. The main changes are in the architecture and deployment areas, as listed below.

  • AIP Console deployment:
    • the front-end AIP Console is now provided as a Linux based Docker container. This means cross-platform deployment and upgrade has been simplified (Docker is compatible with both Linux and Microsoft Windows)
    • the AIP Console authentication provider has been totally restructured and now uses the open-source OAuth2 compatible Keycloak system. Keycloak provides local authentication, and can also interact with other enterprise authentication systems such as LDAP and SAML. This change greatly simplifies the configuration of the authentication method you choose. Keycloak is also provided as a Linux based Docker container.
    • the method for storing settings, options and information about AIP Nodes has been changed from a flat-file H2 database to a PostgreSQL database (the AIP Node Database), also provided as a Linux based Docker container. This database can also be used to host AIP schemas to store analysis and snapshot data if necessary (additional standalone CAST Storage Services/PostgreSQL instances can also be used as in v 1.x and are recommended).
  • AIP Node instance deployment is very similar to v. 1.x: an installation of AIP Core and an AIP Node Service are required and must be installed on a compatible Microsoft Windows server. One significant improvement, however, is that AIP Node instances are now considered to be stateless (the applications are not attached to a specific AIP Node instance). All AIP Node instances register themselves in AIP Console and use common a configuration provided by AIP Console (stored in the PostgreSQL database provided as a Docker container - the AIP Node Database). Thus, all AIP Node instances connect to the same PostgreSQL database (the AIP Node Database) to fetch settings and options and all use the same locations for delivery, deploy and common data (these locations must now always be deployed as shared folders). AIP Node instances also share the connection settings to additional CAST Storage Services/PostgreSQL databases defined in AIP Console for analysis/snapshot requirements (these are no longer defined when the AIP Node service is installed as in v. 1.x). In other words, if multiple CAST Storage Services/PostgreSQL instance are defined in AIP Console, all AIP Node instances will be able to connect to and use all CAST Storage Services/PostgreSQL instances.
  • Application management is similar to v 1.x, however, as outlined above, Applications are no longer tied to one single AIP Node instance. All required storage locations such as deploy/delivery must now be configured as shared folders. AIP Console will also automatically operate in load-balancing mode where the least used AIP Node instance is selected from the pool of AIP Node instances to perform the next job (analysis/snapshot etc.) - note that by default where multiple AIP Node instances are available, AIP Console will choose the AIP Node instance running the most recent release of AIP Core. Therefore when creating a new Application, an AIP Node instance is no longer defined, however, it is now necessary to define a specific CAST Storage Service/PostgreSQL instance for your Application storage requirements at this time (the application remains "tied" to this storage instance).

See AIP Console - 2.x - Main updates and new features for more information.

Benefits of AIP Console 2.x

  • Central configuration and stateless AIP Node instances allows applications to be detached from an AIP Node instance. This makes it possible to add AIP Node instances on request, removes complex routing rules, and allows to load balance the analysis/snapshot processes gracefully.
  • All the front-end components are deployed as Linux based Docker containers to speed up and simplify deployment across both Linux and Microsoft Windows.
  • No synchronization between AIP Console and AIP Node instances required. AIP Node instances use the same PostgreSQL database (AIP Node Database) which contains persistence information about all the applications.
  • AIP Node and Architecture Studio instances share the common data folder deployed as a shared folder, therefore there is no need to upload/download the files between the services as is the case in v 1.x.
  • All the services have bidirectional access to each other through the Service Registry (deployed as a Linux based Docker container).
  • No need to manually add AIP Node instances or other services. AIP Node instances register themselves in the Service Registry and become automatically available.
  • Use of the OAuth2 compatible Keycloak system adds JWT token-based authentication instead of basic authentication provided in v1, removes the need to have custom tokens for AIP Node instances and properly secures all the services.
  • Embedded Dashboards are provided out of the box and require no additional manual configuration.

Current deployment limitations

  • No in place upgrade from AIP Console v. 1.x (same for AIP Node instances).
  • No import of Applications currently managed in CAST Management Studio / AIP Console v 1.x.

Architecture

Docker containers provided by CAST

All Docker containers are Linux based.
ContainerDefault portDescription
aip-gateway8081

This is the entry point to AIP Console. It receives registered services from the Service Registry and forwards incoming requests to the required services. It also acts as a load balancer, so it can transparently handle multiple registered service instances, based on the chosen load balancing strategy.

aip-service-registry8088, 2281Used to register the various required services and monitor their health.
keycloak (OAuth2)8086The OAuth2 server (Keycloak- provides authentication services for AIP Console.
dashboards8087The embedded Health and Engineering Dashboards (available from 2.0.0-beta2).
postgres2285The AIP Node Database: used primarily to store information about the AIP Node instances. It can also be used to store Application analysis/snapshot data if required (but CAST recommends dedicated CAST Storage Service/PostgreSQL instances).

Java JAR installers

In  2.0.0-funcrel, CAST provides Java JAR installers (along side the elements required for a Docker installation) as part of the download media available on CAST Extend (https://extend.castsoftware.com/#/extension?id=com.castsoftware.aip.console&version=latest):

These installers are targeted at deployments on Microsoft Windows on one single machine (including the AIP Node and the CAST Storage Service/PostgreSQL instance) i.e. for demo or POC requirements. While these installers can be used in an enterprise deployment scenario with multiple AIP Nodes, some additional manual configuration is required post installation. CAST highly recommends that Docker is used for an enterprise deployment scenario.

See 2.x - Using Java JAR installers - all on one machine for more information about this.

Prerequisites

See Prerequisites (for CAST Dashboard deployment) or Prerequisites for CAST Imaging (CAST Imaging deployment).

Installation and configuration instructions

See the following:

Upgrade process

See the following:

  • No labels