Skip to main content
Version: Deploy 23.1

Configure Task Queuing

This topic covers how Deploy uses task queuing with JMS 2.0 to manage task execution in version 9.5 and later. Deploy will queue any tasks, regardless of whether a worker is available to execute them. When a worker does become available, it will automatically pick tasks from the queue and execute them.

How it Works​

Understanding tasks in Deploy provides a detailed discussion of Deploy task types and behavior.

As described in High availability with master-worker setup, there are three types of workers: in-process, local and external.

  • If you are running Deploy using the in-process worker, no configuration changes are required and Deploy will fallback to an in-process Artemis queue. Note: an in-process worker setup is not recommended for production environments.
  • If you are using local and/or external workers, an external task queue is required and you can perform the configuration described in this topic to support task queuing.

Starting with version 9.5, Deploy will now hold pending tasks in the queue that are not yet assigned a worker, and wait for one to become available. In this case, you can create a task and it will transition to a queued state. If you schedule a task, it will be successfully scheduled, even if no worker is available. When the scheduled start time has passed, the task will be sent to the queue and the worker will pick it up from the queue.

From Deploy's perspective, the queued state already existed in earlier versions, but it works differently as of Deploy 9.5:

  • In previous Deploy versions, the task was immediately assigned to a worker which had its own internal queue. Tasks that exceeded the available threads on that worker were listed as queued.
  • Now, the internal worker queue is replaced by a shared JMS queue. A task can be in the queued state without being assigned a worker to process it. Once a worker has a free execution thread, it will pick up the task and begin processing it.

Configuration Overview​

To configure task queuing:

  1. Determine your JMS 2.0 message broker (for example, ActiveMQ, RabbitMQ).
  2. Configure your message broker setup.
  3. Download the .jar files for your message broker and copy them to the Deploy lib directory.
  4. Update the deploy.task.queue.external block in your deploy-task.yaml file to specify the broker.
  5. (Optional) Navigate to your message broker's web console URL.
  6. Restart Deploy.

Select a JMS Message Broker​

Digital.ai Deploy was verified to work with both the following JMS 2.0 brokers:

  • ActiveMQ (supported version is ActiveMQ Artemis 2.15.0)
  • RabbitMQ

Configure your JMS Message Broker​

To properly manage queuing for all types of Deploy tasks, your JMS message broker setup should be configured to support both the Queue and Topic approaches. For background, see the following:

Note the following:

  • The Queue approach is used for tasks such as initial deployments, upgrades and undeployments.
  • The Topic approach is used for Rollback to send the Rollback task to the specific worker that was performing the deployment to be rolled back.
  • For RabbitMQ, the Topic exchange is disabled by default and should be enabled by Enabling the Topic Selector Plug-in.

Configure RabbitMQ with SSL​

Starting with version 23.1, Deploy supports RabbitMQ with SSL. Follow these steps to configure RabbitMQ with SSL:

See Configure RabbitMQ with SSL Enabled.

To generate a certificate:

  1. Create a directory with RabbitMQ in ownership

  2. Create server certificate

  3. Create client certificate

  4. Create trust certificate

    keytool -import -alias server1 -file /path/to/server_certificate.pem -keystore /path/to/rabbitstore

  5. Create a rabbitmq.conf file at /etc/rabbitmq and copy the following code to the file:

    listeners.ssl.default = 5671
    ssl_options.cacertfile = /etc/pki/tls/testca/ca_certificate.pem
    ssl_options.certfile = /etc/pki/tls/server/server_certificate.pem
    ssl_options.keyfile = /etc/pki/tls/server/private_key.pem
    ssl_options.verify = verify_peer
    ssl_options.fail_if_no_peer_cert = true

    Once RabbitMQ is enabled with SSL, restart the RabbitMQ server and verify the logs at /var/log/rabbitmq for TLS and SSL ports.

Add JMS .jar Files to Deploy​

This section provides details specific to ActiveMQ and RabbitMQ. Download the latest version for your preferred message broker:

ActiveMQ Files​

Add the org.apache.activemq:activemq-client jar to your lib directory.

RabbitMQ Files​

Add the following drivers to your lib folder:

  • com.rabbitmq.jms:rabbitmq-jms
  • com.rabbitmq:amqp-client

Update Your deploy-task.yaml File​

On all masters and workers in your environment, update your deploy-task.yaml file to configure your external queue settings.

ActiveMQ Example​

Edit the task section in deploy-task.yaml file to include queue configuration details.

Here is an example configuration for ActiveMQ:

jms-driver-classname: org.apache.activemq.ActiveMQConnectionFactory
jms-password        : guest
jms-url             : amqp://localhost:5672
jms-username        : guest

RabbitMQ Example​

Edit the task section in deploy-task.yaml file to include queue configuration details.

Here is an example configuration for RabbitMQ:

jms-driver-classname: com.rabbitmq.jms.admin.RMQConnectionFactory
jms-password        : guest
jms-url             : amqp://localhost:5672
jms-username        : guest

Here is an example configurtation for RabbitMQ with SSL enabled:

  external:
    jms-driver-classname: com.rabbitmq.jms.admin.RMQConnectionFactory
    jms-password: '{cipher}4fd886bf0c784f1a443b5ed59e145f58e587ff8cdf46f476bb1b8fc0eadf6362'
    jms-url: amqps://172.18.40.177:5671
    jms-username: test
    ssl:
     keyStore: /etc/pki/tls/client/client_certificate.p12
     key-Password: MySecretPassword
     key-Store-Password: MySecretPassword
     protocol: "TLSv1.3"
     trustStore: /etc/pki/tls/rabbitstore/rabbitstore.jks
     trust-Store-Password: MySecretPassword

Complete the Configuration​

  1. Ensure that all masters and workers in your environment share the same deploy-task.yaml configuration.
  2. Restart all masters and workers.
  3. You can confirm the connection by executing a simple task and navigating to the broker's web console URL to see that the task was processed.

Monitoring​

In addition to the task monitoring you can perform using Deploy, you can also use the broker's web console to monitor the queue load. For example, if there are many unread messages in the queue/topics, you can consider increasing a worker's execution threads or add more workers to your Deploy environment.