Deploy pipelines into selected instances and configure the runtime behavior using policies.

Objectives

In this section you will learn:

  • Assign deployment pipeline plan.
  • Work with Policies.
  • Deploy


Overview

Please make sure you know what you’re doing. You can break production stuff.

Once a pipeline has been tested and you are ready to move things to a development or production environment, it is important to set up an appropriate deployment plan. Deployment plans will help you configure a number of critical steps such as remote or manual installation, the policies that dictate how the DDC operates in the host environment, and the properties of the installation, once complete such as the version, status, and functionality. You will need a previously created Pipeline that has been tested and published.

Deploying Pipelines

Once you are ready to create an instance you will want to Add an Instance, which will allow for the loading of a previously published and named DDC pipeline.

By adding an Instance to a machine you be able to select the product instance, product version number, JVM machine policy, and log policy.

Add a pipeline


Once a pipeline has been selected and assigned the Pipeline and policy will be selected and you will have the opportunity to confirm that the components are correct, and if not, you will be able to edit the installation method, the pipeline and the policy settings.

This will then allow you to select the correct pipeline, policies and assign this to the deployment instance.



Next you will add select the policy.  Adding a policy is done through the add a policy drop down. Either select the default policy or you can stop and and use DDC deployment policy to create a new policy plan to use on the deployment. Then assign the Pipeline policy you want to use, then add the pipeline that corresponds to the the policy you wish to run and  use.See the DDC policies section for more details on using the DDC policies to set the runtime behavior of the Pipeline. Once named and save it can be used in a deployment plan under the policies tab.


The default policy thread and batch values will be inefficient for some sources, please set them accordingly.

Pipeline Policies 

Each running pipeline needs a runtime configuration. A pipeline can not be run without previously creating a named Pipeline policy. The Pipeline Policy editor represents the designed pipeline and allows the configuration of DDC Policies. You can't change the shape of a pipeline in terms of components and streams however you can select each component and stream and assign runtime properties. These policies impact the behavior of the runtime behaviors and are important for the proper execution of the pipeline. These Pipeline policies can be saved and used later for reoccurring pipeline needs by selecting them after saving them, by selecting them in the DDC pipeline drop down

Policies

 There several types of policies depending on what you want to define as an additional consideration. Please see the table below for more information.


Type

Has default policy?

Depends on a version?

Description


Machine policy

Yes

No, machines have no versioning.

It defines whatever applies to the machine/OS or the Chef agent.

Currently, we will only define 2 parameters for the agent (interval and splay). Note:  it is set to a default null value.

Is useful for setting specific parameters that are more related to the machine, for example, the user to execute the chef agent, or the level of patching we want for the OS.

DDD policy

Yes

No, instances have no versioning.

Configuration parameters for the DDD, such as ramfile size and so on.

DDC policy

Yes

No, instances have no versioning.

it defines the policy that affects a DDC instance, such as:

  • JVM options

  • Logging options (log4j.xml)

  • Anything else that affects the whole instance, for example DDC port.

The reason for this is we want to keep everything in the same policy to prevent having lots of micro-policies.

DDC pipeline policy

YES

However using a default policy may need some level of fine tuning based on use case.

Yes, it depends on a DDC Pipeline version.

Specific policy for a DDC pipeline. You can have as many as possible. Each running combination (instance-pipeline) might have a different policy, or all instances can share the same one if hardware resources are similar. See Pipeline policies for creating a saved and name Pipeline policy.


Deploy


Once a machine, instance, DDC pipeline, and Pipeline policy are configured and assigned it is then possible to deploy.


Steps to deploy generally, and especially for the first time follow these steps.

  • Create the machine(s) and instance(s) necessary
  • Create the DDC pipeline
  • Assign the DDC pipeline policies either default or assign a DDC pipeline policy
  • Assign a pipeline to an instance
  • Deploy



Add a machine;

Add an Instance;


Add a Pipeline from a published version;


Choose a Pipeline policy;


Assign it to an Instance;



Apply changes to Deploy;



Should everything work correctly you will now have a green indicator in both the Overview and Infrastructure panels.





It is also possible to stop a DDC, or delete a DDC on an instance by using the marked buttons. One possible reason to delete an DDC is if you would like to assign a new policy, as you would like to change the policy, or pipeline policy associated with the instance on the machine.



Stop a DDC, press stop.

Delete a DDC use the 3 vertical dot but and select from the drop down.