55 docs tagged with "system administration"

Deploy keeps all active tasks in the Monitoring section, which is located under the search bar at the top left of the screen.

You can create a package retention policy (policy.PackageRetentionPolicy) that retains the deployment packages based on the configured regular expression. Deployed packages are never removed by the package retention policy. If a deployed package is part of the packages identified for removal, then it will be skipped, with no impact on other packages.

Deploy records and archives information about all tasks that it executes. This information is available through the statistics, graphs, and task archives on the Reports screen.

We recommended that you regularly create a backup of your Deploy server.

This topic describes how to perform a basic installation of Deploy - either a simple setup with the default configuration, or a manual setup in which you can choose specific options. If you are installing Deploy in a production-ready environment that includes options like a separate, clustered database server, load balancing for your Deploy servers, an active/hot-standby cluster configuration for your Deploy servers, and other security, monitoring, and performance considerations, see Production install.

Store and version different parts of a XebiaLabs installation

To support high availability (HA), you can configure Deploy in clustered active/hot-standby mode. In this mode, only one Deploy node is active at one time, while the hot standby node is ready to become active if needed.

You can configure the following advanced Deploy client settings in /centralConfiguration/deploy-client.yaml. For more information, see Deploy Properties:

Deploy allows you to store the repository in a relational database instead of on the filesystem. If you use an external database, then you can set up failover handling by creating multiple instances of Deploy that will use the same external database.

This topic describes how to configure Deploy authentication using the OpenID Connect (OIDC) protocol.

This topic describes how to configure Keycloak to authenticate Deploy users and REST API calls (using the Bearer Token Authorization).

Enable communication with satellites

If you configured your Deploy server to use a self-signed certificate, you will notice that trying to connect with a normal command-line interface (CLI) configuration will fail:

In Deploy, deployment tasks are executed by dedicated worker instances. A Deploy master generates a deployment plan that contains steps that a Deploy worker's task execution engine will carry out to deploy an application. You can read more about masters and workers here

By default, Deploy authenticates users and retrieves authorization information from its repository. Deploy can also be configured to use an Atlassian Crowd repository to authenticate users and to retrieve role (group) membership. In this scenario, the Atlassian Crowd users and groups are used as principals in Deploy and can be mapped to Deploy roles. Role membership and rights assigned to roles are stored in the Deploy repository.

Data Anonymization is the process of protecting private or sensitive information, such as passwords, by deleting or encrypting personally identifiable information. As organizations store tend to store user information on local or cloud servers for various business requirements, data anonymization becomes a vital requirement to maintain data integrity, and to prevent security breaches.

If you want to apply the same connectivity CI to multiple new CIs that require it, you can use a default convention to assign one of these CIs as the default. Reserved names are used to provide a consistent method of defining the default CI across the system.

You can install the Deploy command-line interface (CLI) on any remote computer and connect to the Deploy server.

To safely restart the Deploy server, administrators can use Deploy maintenance mode to temporarily prevent users from starting new deployments and other tasks.

The repository object in the Deploy command-line interface (CLI) allows you to export the Deploy repository tree to a ZIP file that can be imported into the same Deploy server or into another Deploy server. The ZIP file contains all configuration item (CI) properties, including artifact files.

The Feature Settings page allows you to toggle or configure the optional features Digital.ai Deploy.

Deploy header color

By default, Deploy will not hide any internal server errors due to incorrect user input. You can turn this behavior off by editing the conf/deployit.conf file in the Deploy server directory and edit the following setting:

Cross site request forgery or CSRF) is a class of attack that forces an end user to execute unwanted actions on an application when the user is authenticated. The Digital.ai Deploy frontend uses endpoints protected with CSRF .

Requirements for a satellite server

You can install and run Deploy Satellite as a service on your Unix or Microsoft Windows machine. The satellite service wrapper requires Java Development Kit 8 or higher to be installed on the target Unix or Windows machine.

Deploy runs on the Java Virtual Machine (JVM) and has two classloaders: one for the server itself, and one for the plugins and extensions. A plugin can have an .xldp or a .jar extension. The XLDP format is a ZIP archive that bundles a plugin with all of its dependencies.

Here are the software and hardware requirements to install and run Digital.ai Deploy. Your setup might have to be better than the stated minimum requirements depending on your site's size and usage pattern. Contact Digital.ai support for assistance.

In Deploy there are two main types of licenses: a 30 day Trial Edition license, and an Enterprise Edition. If you have an Enterprise Edition of Deploy, you can download your license file from the Deploy/Release Software Distribution site. This site requires enterprise customer login. If you have a Trial Edition of Deploy, you will receive a license key by email when you register to download a trial.

Elastic Stack

By default, the Deploy server writes informational, warning, and error log messages to standard output and to XLDEPLOYSERVER_HOME/log/deployit.log when it is running. In addition, Deploy:

This topic describes how to change the encryption key password and the admin user's password in Deploy.

Pre-requites before verifying the SSH connection using Oslogin API

* The Digital.ai Deploy's Permission service—by default—runs (embedded) on the Digital.ai Deploy server.

Digital.ai Deploy runs on the Java Virtual Machine (JVM) and has two classloaders: one for the server itself, and one for the plugins and extensions. A plugin can have an .xldp or a .jar extension. The XLDP format is a ZIP archive that bundles a plugin with all of its dependencies.

Deploy includes a fine-grained access control scheme to ensure the security of your middleware and deployments. The security scheme is based on the concepts of principals, roles, and permissions.

Deploy uses a scheduling mechanism to run various system administration jobs on top of the repository, such as garbage collection, purge policies, and so on. You can also use this mechanism to run specific control tasks on configuration items (CIs) stored in the repository.

This topic describes how to set up an active-active cluster for Deploy with multiple master and multiple external workers.

To set up LDAP:

Deploy provides fine-grained security settings based on roles and permissions that you can configure in the GUI and through the command-line interface (CLI).

When Deploy is installed, no permissions are granted to any user. The only users that have permissions granted are the administrator users, and they have all permissions granted to them. Deploy has one predefined administrator user called admin, with the default password admin. For more information, see roles and permissions.

Shut down Deploy using the CLI

The file.encoding system property defines the file encoding setting on the Deploy server. By default, it is set to UTF-8 to work with the most systems.

To start the Deploy server, open a command prompt or terminal, go to the XLDEPLOYSERVER_HOME/bin directory, and execute the appropriate command:

In the Configuration section of the CI Library, you can define one or more sets of credentials to be used with source artifacts. To define credentials, you must have admin global permissions. You can use the defined credentials to provide a username and password to any HTTP URL that requires authentication.

In the Configuration section of the CI Library, you can define one or more sets of proxy servers to be used with source artifacts. To define a proxy server, you must have admin global permissions. You can use the defined proxy servers to provide a

Your infrastructures can include multiple remote hosts that share the same credentials. To simplify credential management across these hosts, you can configure a single CI to define shared credentials for any remote host that requires authentication. Then, when you define an overthere host connection, you can select the shared credentials CI. This is applicable to the following host types:

The XLDEPLOYSERVER_HOME/work directory is used to temporarily store data that cannot be kept in memory. Examples of items that are temporarily stored in the work directory are:

This topic describes how to install a trial version of Deploy.

Server seems to be stuck on startup

You can perform an unattended install of the Deploy server, for example, using Puppet.

To support secure communications, Deploy can generate a self-signed digital certificate. This can cause issues in situations where Deploy needs to be accessed using a URL other than https4516, because the Common Name in the certificate is localhost.

This topic describes the prerequisites, considerations and process for upgrading Deploy from version 10.1 or later to the current version.

When you upgrade to a new version of Deploy, you must also upgrade your satellite servers to the corresponding version of the satellite distribution ZIP.

Pre-requites before verifying oslogin and Metadata SSH connection to GCP instance