2.1.1. Install Docker

2.1.2. (Optional) Install Git

2.1.3. (Optional) Install AWS CLI

aws configure
aws iam get-user

2.1.4. (Optional) Install CDP CLI

cdp configure
cdp iam get-user

2.1.5. (Recommended) Confirm your SSH Keypair

2.1.6. (Recommended) Confirm your SSH Agent

2.2.1. Option 1: Download the Quickstart script

curl https://raw.githubusercontent.com/cloudera-labs/cloudera-deploy/main/quickstart.sh -o quickstart.sh

2.2.2. Option 2: Clone the repository

git clone https://github.com/cloudera-labs/cloudera-deploy.git
cd cloudera-deploy

2.2.3. Confirm your Docker service

docker ps -a

2.2.4. Execute the Quickstart script

chmod +x quickstart.sh
./quickstart.sh

2.2.5. Confirm the Quickstart environment

2.2.6. Setup your user profile

vim ~/.config/cloudera-deploy/profiles/default

2.3.1. Check your Credentials

cdp iam get-user

aws iam get-user

az account list

gcloud auth list

2.3.2. Run the main playbook

ansible-playbook /opt/cloudera-deploy/main.yml -e "definition_path=examples/sandbox" \
    -t run,default_cluster -vvv

2.3.3. View the Ansible execution logs

tail -100f $HOME/.config/cloudera-deploy/log/latest-2021-05-08_150448

Cloudera-Deploy is regularly updated by the maintainers with new features and fixes.
The quickstart.sh script will check for an updated Container image to use if there is currently no Container running.
You may use the following process to trigger this behavior.

Stop the cloudera-deploy Docker Container

In the cloudera-deploy directory, pull the latest changes with git

Finally, rerun the quickstart to download the latest image.

Cloudera Deploy requires a number of host applications, services, and Python libraries for its execution. These dependencies are already packaged for ease-of-use in Cloudera Labs Ansible-Runner, another project within Cloudera Labs, and are made readily accessible through the quickstart.sh script.

Alternatively, and especially if you plan on running Cloudera Deploy in your own environment, you may install the dependencies yourself.

3.1.1. Collections and Roles

# Get the cldr-runner dependency file first
curl https://raw.githubusercontent.com/cloudera-labs/cldr-runner/main/payload/deps/ansible.yml \
    --output requirements.yml

# Install the collections (and their dependencies)
ansible-galaxy collection install -r requirements.yml

# Install the roles
ansible-galaxy role install -r requirements.yml

# Install the crypto collection
ansible-galaxy collection install community.crypto

3.1.2. Python and Clients

Cloudera Deploy does require a small set of user-supplied information for a successful deployment. A minimum set of user inputs is defined in a profile file (see the profile.yml template for details). For example, the profile.yml should define your password for the Administrator account of the deployed services, and you should set a unique name_prefix to avoid clashing with other deployments.

The default location for profiles is ~/.config/cloudera-deploy/profiles/. Cloudera Deploy looks for the default file in this directory unless the Ansible runtime variable profile is set, e.g. -e profile=my_custom_profile. Creating additional profiles is simple, and you can use the profile.yml template as your starting point.

3.2.1. CDP Public Cloud

3.2.2. Cloud Providers

3.2.3. CDP Private Cloud

✓ - Supported

O - Support in CDP, but not in Cloudera-Deploy

X - Not Supported in CDP

Cloudera Deploy exposes a set of Ansible tags that allows fine-grained inclusion and exclusion of functions, in particular, a runlevel-like management process.

Current Tags: verify_inventory, verify, full_cluster, default_cluster, verify_definition, custom_repo, verify_parcels, database, security, kerberos, tls, ha, os, users, jdk, mysql_connector, oracle_connector, fetch_ca, cm, license, autotls, prereqs, restart_agents, heartbeat, mgmt, preload_parcels, kts, kms, restart_stale, teardown_ca, teardown_all, teardown_tls, teardown_cluster, infra, init, plat, run, validate

With these tags, you can set your deployment to a given "runlevel" state:

or select or skip a level or function:

For further details on the various runlevel-like tags for CDP Public Cloud, see the Runlevel Guide in the cloudera.exe project.

Terraform can optionally be used to create the cloud infrastructure. This will attempt to create the cloud provider assets at the infra (network, storage and compute) and plat (IAM policies and roles) runlevels using Terraform resources. A list of Terraform related parameters are shown in the table below.

The required definition.yml file contains top-level configuration keys that define and direct the deployment.

Within the top-level keys, you may override the defaults appropriate to that section.

You may also add other top-level configuration keys if your automation requires it, e.g. if your application.yml playbook needs its own configuration details.

More detailed documentation of all the options is beyond the scope of this introductory readme; further documentation is forthcoming.

The required application.yml file is not a configuration file, it is actually an Ansible playbook. At minimum, this playbook requires a single Ansible play; a basic no-op task works well if you wish to take no additional actions beyond the core deployment.

For more sophisticated post-deployment actitivies, you can expand this playbook as much as needed. For example, the playbook can interact with hosts and inventory, execute computing jobs on deployment environments, and include additional playbooks and configuration files.

You may also include an inventory_static.ini file that describes your static Ansible inventory. This file will be automatically loaded and added to the Ansible inventory. Note that you can also use the standard Ansible -i switch to include other static inventory.

If included, Cloudera Deploy will use a definition’s inventory_template.ini file, which describes a set of dynamic host inventory, and provision these hosts as infrastructure for the deployment, typically for a CDP Private Cloud cluster.