在 Cloudera,我们一直相信自动化是交付安全、随时可用且配置良好的平台的关键。因此,我们很高兴地宣布公开发布基于 Ansible 的自动化来部署 CDP 私有云基础集群。通过以这种方式自动化集群部署,您可以降低配置错误的风险,促进环境中跨多个集群的一致部署,并帮助更快地交付业务价值。
本博客将介绍如何以最少的人工交互部署具有安全性的私有云基础集群。
“作为开发人员,我们拥有的最强大的工具是自动化。” — 斯科特·汉塞尔曼
一旦我们设置了配置文件和自动化环境,Ansible 将在无需干预的情况下构建和配置集群。在以下部分中,我们将介绍:
我们有两个选项来设置您的执行环境(也称为“运行器”)。我们可以运行快速启动环境,它是一个 Docker 容器,我们可以在本地或管道中运行,或者我们可以在我们的数据中心基础设施中的 Linux 机器上安装依赖项。Docker 容器包含本地执行所需的所有依赖项,可在 Linux、Windows 或 OSX 上运行。
如果我们在 docker 中运行,我们可以简单地下载并运行quickstart.sh脚本,这将为我们启动我们的 docker 容器:
wget https://raw.githubusercontent.com/cloudera-labs/cloudera-deploy/main/quickstart.sh && chmod +x quickstart.sh && ./quickstart.sh
否则,如果我们在 Docker 之外运行,我们将克隆cloudera-deploy git 存储库,然后运行centos7-init.sh脚本,该脚本将安装 Ansible 2.10、Ansible Galaxy 集合及其依赖项:
yum install git -y
git clone https://github.com/cloudera-labs/cloudera-deploy.git /opt/cloudera-deploy
cd /opt/cloudera-deploy && git checkout devel && chmod u+x centos7-init.sh && ./centos7-init.sh
您可以在没有任何凭据的情况下运行,但理想情况下,我们将设置一个配置文件,其中包含云凭据(如果部署在公共云上)和 CDP 许可证文件(如果你想使用一个)的路径。
将模板 profile.yml文件复制到:~/.config/cloudera-deploy/profiles/
mkdir -p ~/.config/cloudera-deploy/profiles
cp /opt/cloudera-deploy/profile.yml ~/.config/cloudera-deploy/profiles/default
在此文件 ( ~/.config/cloudera-deploy/profiles/default
) 中,您可以根据需要指定公钥/私钥对和 CDP 许可证文件,以及 Cloudera Manager 的默认密码:
admin_password: "MySuperSecretPassword1!"
license_file: "~/.cdp/my_cloudera_license_2021.txt"
public_key_file: "~/.ssh/mykey.pub"
private_key_file: "~/.ssh/mykey.pem"
以下方法描述了将 CDP 私有云部署到物理机或虚拟机上。在某些情况下(可能是开发环境),可能需要在 EC2、Azure VM 或 GCE 上部署 CDP 私有云,但是应该注意的是,将 CDP 公共云用于任何公共云工作负载都具有显着的成本、性能和敏捷性优势. 这种自动化将允许创建运行集群所需的虚拟机。
如果您在 GCE 中运行,我们可以在我们的配置文件中设置我们的 GCP 凭据。如果您在 Azure 或 AWS 中使用 VM,将从您的本地用户配置文件(.aws或.azure目录)中自动收集默认凭据。我们建议您在配置文件中设置默认值infra_type以匹配您首选的默认公共云基础设施凭据,并检查您的默认凭据是否指向正确的租户。
#infra_type can be omitted, "aws", "azure" or "gcp". Defaults to aws
infra_type: gcp
gcloud_credential_file: '~/.config/gcloud/mycreds.json'
对于 CDP 私有云集群,集群定义目录是我们要定义的位置:
最重要的原则是您永远不需要修改剧本或集合——您希望自定义的所有内容都应该通过定义进行自定义。
我们的集群定义将由三部分组成:
在 cloudera-deploy 仓库中提供了一个基本的定义文件;但这仅包括 HDFS、YARN 和 Zookeeper 服务。
让我们从创建定义目录开始:
mkdir /opt/cloudera-deploy/definitions
cp -r /opt/cloudera-deploy/examples/sandbox /opt/cloudera-deploy/definitions/mydefinition
echo yes | cp /opt/cloudera-deploy/roles/cloudera_deploy/defaults/basic_cluster.yml /opt/cloudera-deploy/definitions/mydefinition/definition.yml
我们将在/opt/cloudera-deploy/definitions/mydefinition/definition.yml文件中填充以下部分:
首先,我们将设置 Cloudera Manager 版本——理想情况下,我们将使用最新版本(在撰写本文时,如果您在配置文件中使用 Cloudera 许可证文件,则为 7.3.1,尽管 7.1.4 是默认版本)如果您使用的是试用许可证):
cloudera_manager_version: 7.3.1
接下来我们将定义我们的集群:
clusters:
- name: Data Engineering Cluster
services: [ATLAS, DAS, HBASE, HDFS, HIVE, HIVE_ON_TEZ, HUE, IMPALA, INFRA_SOLR, KAFKA, OOZIE, RANGER, QUEUEMANAGER, SOLR, SPARK_ON_YARN, TEZ, YARN, ZOOKEEPER]
repositories:
# For licensed clusters:
- https://archive.cloudera.com/p/cdh7/7.1.6.0/parcels/
# For trial clusters uncomment this line:
# - https://archive.cloudera.com/cdh7/7.1.4/parcels/
security:
kerberos: true
configs:
…
host_templates:
…
您可以从集合本身中定义的可用服务和角色列表中自定义服务列表。您可以在此部分中包含Apache Spark 3、Apache NiFi或Apache Flink 等服务,尽管这些服务需要配置单独的CSD。
我们可以指定额外的配置,按角色分组,或者对于服务范围的配置,我们可以使用虚拟角色“ SERVICEWIDE”。大多数配置设置都设置为合理的默认值,由 Cloudera Manager 或 playbook 本身设置,因此您只需要设置特定于您的环境的那些设置。
configs:
ATLAS:
ATLAS_SERVER:
atlas_authentication_method_file: true
atlas_admin_password: password123
atlas_admin_username: admin
HDFS:
DATANODE:
dfs_data_dir_list: /dfs/dn
NAMENODE:
dfs_name_dir_list: /dfs/nn
SECONDARYNAMENODE:
fs_checkpoint_dir_list: /dfs/snn
IMPALA:
IMPALAD:
enable_audit_event_log: true
scratch_dirs: /tmp/impala
YARN:
RESOURCEMANAGER:
yarn_scheduler_maximum_allocation_mb: 4096
yarn_scheduler_maximum_allocation_vcores: 4
NODEMANAGER:
yarn_nodemanager_resource_memory_mb: 4096
yarn_nodemanager_resource_cpu_vcores: 4
yarn_nodemanager_local_dirs: /tmp/nm
yarn_nodemanager_log_dirs: /var/log/nm
GATEWAY:
mapred_submit_replication: 3
mapred_reduce_tasks: 6
ZOOKEEPER:
SERVICEWIDE:
zookeeper_datadir_autocreate: true
在主机模板部分,我们将指定将分配给每个主机模板的角色。在这个简单的集群中,我们只有两个主机模板:Master1和Workers. 对于更复杂的集群,您可能希望拥有更多的主机模板。在下一节中,我们将解释如何将这些主机模板应用于集群节点。
host_templates:
Master1:
ATLAS: [ATLAS_SERVER]
DAS: [DAS_EVENT_PROCESSOR, DAS_WEBAPP]
HBASE: [MASTER, HBASERESTSERVER, HBASETHRIFTSERVER]
HDFS: [NAMENODE, SECONDARYNAMENODE, HTTPFS]
HIVE: [HIVEMETASTORE, GATEWAY]
HIVE_ON_TEZ: [HIVESERVER2]
HUE: [HUE_SERVER, HUE_LOAD_BALANCER]
IMPALA: [STATESTORE, CATALOGSERVER]
INFRA_SOLR: [SOLR_SERVER]
OOZIE: [OOZIE_SERVER]
QUEUEMANAGER: [QUEUEMANAGER_STORE, QUEUEMANAGER_WEBAPP]
RANGER: [RANGER_ADMIN, RANGER_TAGSYNC, RANGER_USERSYNC]
SPARK_ON_YARN: [SPARK_YARN_HISTORY_SERVER]
TEZ: [GATEWAY]
YARN: [RESOURCEMANAGER, JOBHISTORY]
ZOOKEEPER: [SERVER]
Workers:
HBASE: [REGIONSERVER]
HDFS: [DATANODE]
HIVE: [GATEWAY]
HIVE_ON_TEZ: [GATEWAY]
IMPALA: [IMPALAD]
KAFKA: [KAFKA_BROKER]
SOLR: [SOLR_SERVER]
SPARK_ON_YARN: [GATEWAY]
TEZ: [GATEWAY]
YARN: [NODEMANAGER]
最后,我们将添加所需的任何 Cloudera Manager 设置,包括可能需要为非 CDP 服务安装的任何 CSD。
mgmt:
name: Cloudera Management Service
services: [ALERTPUBLISHER, EVENTSERVER, HOSTMONITOR, REPORTSMANAGER, SERVICEMONITOR]
hosts:
configs:
host_default_proc_memswap_thresholds:
warning: never
critical: never
host_memswap_thresholds:
warning: never
critical: never
host_config_suppression_agent_system_user_group_validator: true
cloudera_manager_options:
CUSTOM_BANNER_HTML: "Cloudera Blog Deployment Example"
#cloudera_manager_csds:
# - https://archive.cloudera.com/p/specific_csd_location
在此文件中,我们还可以更改诸如数据库、kerberos和TLS 之类的默认值——尽管在此示例中我们将坚持使用默认值。
我们完整的definition.yml可以在这里找到。
这种自动化支持动态和静态清单——动态意味着我们将提供虚拟机(在 AWS 中),然后在这些主机上构建一个集群,但是它们被命名,静态意味着我们定义了一个配置文件,其中包含一个预配置列表。用于构建集群的现有机器。
对于动态清单,我们需要配置上述的云凭据,并设置infra_type,可以是在我们的profile文件或者extra_vars.我们还需要提供一个inventory_template.ini文件,剧本可以在其中替换任何云提供的主机名。我们的清单模板将如下所示:
[cloudera_manager]
host-1.example.com
[cluster_master_nodes]
host-2.example.com host_template=Master1
[cluster_worker_nodes]
host-3.example.com
host-4.example.com
host-5.example.com
[cluster_worker_nodes:vars]
host_template=Workers
[cluster:children]
cluster_master_nodes
cluster_worker_nodes
[krb5_server]
host-6.example.com
[db_server]
host-6.example.com
[deployment:children]
cluster
cloudera_manager
db_server
krb5_server
在这个文件中,我们有定义的 cloudera_manager, cluster_master_nodes, cluster_worker_nodes, krb5_server, 和db_server的组。清单链接到主机模板,通过使用host_template在这里分配给cluster_worker_nodes和cluster_mater_nodes的变量。注意:每个主机只能有一个主机模板。在此文件中,唯一主机的数量将决定剧本提供的主机数量。另请注意,主机名只是占位符,将被提供的实例主机名替换。
如果我们希望使用静态清单,我们可以创建完全相同的文件,除了替换host-*.example.com为我们提供的主机名。我们可能还希望在此处为清单指定任何 ssh 密钥或 ansible 变量,例如:
[deployment:vars]
ansible_ssh_private_key_file=~/.ssh/root_key
ansible_user=root
静态清单文件可以被命名inventory_static.ini,也可以作为参数传递给使用“ -i” ansible 运行时标志的 playbook 执行。
一旦我们有了定义和清单设置,运行剧本就相当简单了。我们可以使用一些特定的标签分阶段运行剧本,或者只是端到端地运行整个事情。我们花时间确保我们可以启动和重新启动剧本,而无需在两次运行之间清理任何东西。
要运行剧本,请使用以下命令:
ansible-playbook /opt/cloudera-deploy/main.yml \
-e "definition_path=definitions/mydefinition" <extra arguments>
您可能希望传递给此命令的其他选项:
选项 | 价值 | 目的 |
---|---|---|
-i | inventory_static.ini | 指定要使用的静态清单而不是动态清单 |
--extra_vars | key1=value1<space>key2=value2 | 为运行时指定其他变量(例如admin_password ) |
--ask-pass | <不需要值> | 为了在没有公钥/私钥的情况下运行剧本时使用,Ansible 将提示输入 SSH 密码 |
--tags | <逗号分隔的标签列表> | 以增量方式运行剧本 |
--verbose | 0 到 3 | 打开详细日志记录 |
举个例子:
ansible-playbook /opt/cloudera-deploy/main.yml \
-e "definition_path=definitions/mydefinition" \
-i /opt/cloudera-deploy/definitions/mydefinition/inventory_static.ini \
--ask-pass
您还可以设置ANSIBLE_LOG_PATH环境变量以确保日志保存到磁盘并且在您关闭终端时不会丢失。
该剧本将处理支持基础架构、Cloudera Manager 和 CDP Private Cloud Base 集群以及 KeyTrustee 集群(如果您提交的配置需要)的安装。集群部署通常受到parcel分发的网络带宽和硬件速度的限制,但在不到两小时内部署一个中小型集群是现实的。
在本博客中,我们介绍了如何将 CDP 私有云基础自动化部署到物理或虚拟机上的机制,也包括在公共云中部署。通过一个简单的定义,分为三个配置文件以方便使用,我们已经能够控制集群部署的所有方面,包括与企业基础设施的集成。
这种规模的自动化极大地提高了 CDP 私有云基础的价值实现时间。通过使用自动化,我们可以以更高的一致性和更快的速度快速部署多个集群。如果需要,可以为特定目的重建环境,或者为更快的部署进行模板化。通过拥有更多可重复的部署,管理员和开发人员可以花更多的时间专注于入职租户和开发新的管道和洞察力,而不是部署集群。
原文作者:Tristan Stevens
原文链接:https://blog.cloudera.com/automated-deployment-of-cdp-private-cloud-clusters/