云管理员：云的内务管理

2020-08-13 10:27:10

CloudKeeper是一个独立的CLI工具，它定期收集云账户中的资源列表，提供有关它们的指标，并可以清理它们。

对于每个激活的收集器插件(--Collector)，资源收集按时间间隔(--Interval)执行。资源收集完成后，可以执行资源清理(--Cleanup)。默认情况下不会进行任何清理！必须安装和配置清理插件，或者使用内置CLI手动标记要清理的资源。在下面的插件部分中阅读有关收集器和清理插件的更多信息。

CloudKeeper是为对其组织的云帐户使用和支出负责的人员而设计的，他们对Linux shell感到满意。假设用户希望创建适合其特定用例和组织需求的自己的插件。不过，它可以在没有任何编程经验的情况下使用，只需使用附带的CLI和插件即可。

$docker run-it中间层/CloudKeeper--详细\--清理--no-cli--one-shot--间隔0\--收集器aws\-aws-access-key-id AKIAIO5FODNN7EXAMPLE\--aws-Secure-access-key'；ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE'；\--注册CLI-ACTION"；\CLEANUP_PLAN：\MATCH RESOURCE_TYPE=AWS_EC2_VOLUME\|MATCH VOLUME_STATUS=Available\。7d\|匹配LAST_UPDATE>；7d\|清理"；\--清理-干运行。

这将收集AWS帐户中所有地区的所有已知资源。一旦收集阶段完成，清理阶段开始，它将运行注册的CLI操作。在这种情况下，它会选择所有未使用、超过7天且在过去一周内没有任何读写IOPS的AWS EBS卷，并将其标记为要清理。在下一步中，如果没有--Cleanup-Dry-Run标志，CloudKeeper将删除所有标记为要清理的资源。

如果您只想收集特定的区域，例如。US-EAST-1和US-WEST-2您可以指定--AWS-REGION US-EAST-1US-WEST-2。

如果您希望CloudKeeper在组织范围内执行相同的操作，请使用您的root帐户的凭据，或者不要将其指定为CLI参数导出AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY或AWS_PROFILE。如果您在EC2内部运行，还可以分配实例配置文件并导出AWS_CONFIG_FILE。然后提供--AWS-Role和--aws-sccup-org参数，这样CloudKeeper就会发现您组织的所有AWS子帐户并承担其中的角色。

最后，args--leanup--no-cli--one-shot--interval 0打开清理代码(而不仅仅是收集资源和生成指标)，关闭内置的CLI，告诉cloudKeeper运行一个资源收集循环，然后退出(而不是永远运行)，并将循环间隔设置为0秒(而不是默认的1小时)，这样一旦收集循环完成，CloudKeeper立即退出，而不是等待间隔结束。

CloudKeeper是D2iQ开发的内部工具，用于收集和清理最昂贵的AWS资源。我们在目前的状态下将其开源，因为在过去的几个月里，它对我们大幅减少云支出非常有帮助，我们认为特别是在新冠肺炎疫情期间，它可能对其他人也很有用。

正如前面提到的，CloudKeeper目前的主要关注点是收集和清理AWS资源，因为这是我们花费最多的云。然而，基础设施是用来实现其他云收集器的。在plugins/exampleCollector/中有一个示例，还有另外两个示例，即plugins/OneLogin/和plugins/slack/，我们将它们用于通知目的。

此外，CloudKeeper可以使用远程插件分布式运行。例如，您可以为每个AWS帐户运行一个CloudKeeper，然后将这些单独收集的资源合并到一个中心位置。或者运行一个CloudKeeper进行收集，另一个运行CloudKeeper进行清理。收集实例将只需要对您的云帐户的读取访问权限，并且清理实例可以从收集实例检索收集的数据并删除未使用的资源。

在plugins/文件夹中还可以找到许多清理插件。默认情况下，Docker映像包含该文件夹中的所有插件。

在下面的TODO部分中，您将找到最直接打开的任务列表。这些包括实现更多的云提供商，为现有的云提供商提供更多的资源类型，编写更好的测试和更广泛的插件文档。

作为我们资源收集的副产品，我们能够在/metrics端点导出普罗米修斯指标。默认侦听端口(--web-port)为8000。可以使用--tag-as-metrics-label参数定义基于资源标签的自定义指标标签。示例：--Tag-as-Metrics-Label项目子项目将根据资源项目和子项目的内容确保每个指标都有两个额外的标签，从而产生如下指标输出：

由于收集指标的方式，资源目前只公开指标。单个资源可以增加或减少量规。在插件中，可以定义任何类型的指标。CloudKeeper本身大量使用摘要和计数器指标来对自己的性能进行基准测试。

$git克隆https://github.com/mesosphere/cloudkeeper.git$CD CloudKeeper$python3.8-m venv venv$source venv/bin/激活$pip安装--可编辑的cloudKeeper/$pip安装--可编辑的插件/aws/#其他插件之一取决于aws$Find插件/-最大深度1分钟深度1-类型d-exec pip安装--可编辑"；{}"；\+

#$是您的shell#&>是CloudKeeper shell#如果您安装了AWS CLI($pip install awscli)设置AWS CLI凭据以便您#登录到帐户，或者提供--aws-access-key-id/--aws-ret-access-key#您还可以导出AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY环境变量或在#~/.aws/Credentials中定义它们，然后导出AWS_PROFILE。$aws。Count resource_type#按RESOURCE_TYPE计算所有收集的资源&>MATCH RESOURCE_TYPE=AWS_EC2_INSTANCE#列出所有发现的EC2实例&>MATCH RESOURCE_TYPE=AWS_EC2_INSTANCE|MATCH AGE&>30d#列出超过30天的所有EC2实例&>MATCH RESOURCE_TYPE=AWS_EC2_VOLUME|COUNT#查找所有EC2卷并对其计数&>MATCH RESOURCE_TYPE~^AWS_|Match Tags[Owner]~。>；backup/tmp/graph#将当前加载的图形的备份存储到/tmp/graph#加载以前收集的图形，并在试运行模式下激活清理代码$CLOUDKeeper--收集器远程--远程端点file:///tmp/graph--清理--清理-演练&>MATCH RESOURCE_TYPE=AWS_EC2_VOLUME|HEAD-10#列出前十个EC2卷匹配标记[所有者]~sre|COUNT_RESOURCE_TYPE#查找标记&#的所有资源。并按resource_type#count by account计数。命名所有没有所有者的AWS EC2实例、ALB和ELB(AWS_[ae]lb\|AWS_EC2_INSTANCE)$|没有标记[Owner]|count account。name>；Match resource_type=AWS_ELB|head-1|dump#找到第一个弹性负载均衡器(经典)并转储对象&。并列出其子资源>；match name=sometestinstance|prepresires#查找名称为sometestinstance'；的资源，并列出其父资源。

CloudKeeper附带一个简单的CLI。最初，它只用于调试内部数据结构，现在还可以用来执行简单的搜索和标记要清理的资源。输入help将给出所有命令的列表。HELP<；COMMAND&>将为该命令提供其他帮助。可以使用"；|"；将命令相互传递。可以使用"；；"；连续运行多个命令。如果您需要在命令中使用竖线或分号字符，请确保使用反斜杠对它们进行转义。内部命令接收和输出Iterables，通常由Cloud资源组成。命令可以匹配这些资源的任何属性。例如，如果AWS EBS卷具有属性VOLUME_SIZE，则可以使用以下命令查询所有大于100 GB的EBS卷：MATCH RESOURCE_TYPE=AWS_EC2_VOLUME|MATCH VOLUME_SIZE>；100。

默认情况下，所有资源都有Unix属性，如表示为Python DateTime对象的ctime、mtime、atime。从这些属性派生的是age、last_update、last_access。目前，大多数资源支持ctime属性，但支持mtime和atime的资源较少。默认情况下，如果云API没有返回修改时间，则将mtime和atime的值设置为当前时间戳。这里的推理是，这些属性用于确定资源上次使用的时间。通常，我希望清理很长时间没有使用的资源，而不是最近使用的资源。

当CLI发现某个属性属于特定数据类型时，它会尝试将输入值转换为该类型，以便进行比较操作。在下一个示例中，我们将删除所有在2020年1月1日之前创建且在过去7天内未写入或读取的大于100 GiB的未使用EBS卷。

现在，CLI对于浏览收集的数据很有用，但是如果您有一个重复的清理查询，那么定期手动运行它将是乏味的。为此，CloudKeeper支持一个参数--register-cli-action，它接受一个小写的事件名称(请参见下面的事件)，后面跟一个冒号：和在该事件被分派时应该执行的CLI命令。如果我们希望在每次CloudKeeper完成资源收集时都从前面运行卷清理，我们可以这样调用它：

顺便说一句，有一个插件插件/CLEANUP_VOLUES/就可以做到这一点。它是在Cloudk之前写的

CloudKeeper旨在清理资源。因此，在选择和筛选要清理的资源时要谨慎行事。任何CLI命令的默认输入都是所有云资源的列表。这意味着当您运行MATCH RESOURCE_TYPE=AWS_EC2_VOLUME时，它会针对所有资源运行此匹配。然而，这也意味着如果您运行DELETE--是的，前面没有任何匹配或其他筛选器，CloudKeeper将对所有云资源顺序运行DELETE。它相当于您的云的RM-RF/。更有效的破坏性命令是清理；清理。在这种情况下，CloudKeeper将首先标记要清理的所有资源，创建清理计划，然后以非常高效和并行的方式删除它们。

在第一次进行资源清理选择时，最好在发出Cleanup命令之前使用MATCH CLEAN=TRUE|COUNT或MATCH CLEAN=TRUE|COUNT RESOURCE_TYPE等命令确认所选资源的列表是否可信。

在内部，CloudKeeper将所有资源存储在一个有向无环图(DAG)中。添加到图中的每个节点(资源)都必须继承BaseResource。图中的依赖关系用于确定资源清理的顺序。这意味着如果资源具有子级(继任者)，则很可能无法删除。在收集过程中，将创建一个与当前活动图并行的新暂存图，并且随着收集器插件返回其自己的本地图，将构建其分支。一旦所有收集器都完成了他们的工作，旧的实时图形就会与临时图形交换，从而使其成为新的实时图形。这意味着，在查询指标或执行CLI查询时，您始终可以全面了解所有云资源。

使用分布式实例中提到的插入点，您还可以将图形导出为各种格式(GraphML、GEXF、JSON等)。了解并探索您的云服务。

CloudKeeper知道两种类型的插件，收集器和持久性。您可以在plugins/Example_Collector/和Plugin/Example_Persistent/中找到每种类型的示例代码。COLLECTOR Plugins收集云资源，并在每次收集运行时被实例化。持久插件在启动时实例化一次，主要用于资源清理、决策或通知(例如，向刚刚删除的实例的所有者发送松弛消息)。

每个收集器插件都有一个本地图。收集器插件为云提供商(例如AWS、GCP、Azure、AliCloud等)实施资源收集。在收集期间，插件添加资源(例如实例、负载均衡器、卷、用户等)。到那张图上。插件图形的根部是云本身(例如，AWS)。在此下方将添加一个或多个帐户。下面的客户CloudKeeper希望找到地区。在区域内，插件可以添加它认为合适的任何资源。插件可以在资源之间创建有向边(连接)来标记依赖关系。当我们谈论依赖关系时，我们总是在谈论删除依赖关系，而不是逻辑依赖关系。这意味着如果不先删除子项，就不能删除具有子项的资源。这听起来合乎逻辑，但可能相当不直观。例如，AWS EC2实例将是EBS卷的子卷，而不是反过来，因为您可以在不删除卷的情况下删除该实例，但不能在该实例仍在使用该卷时将其删除。

一旦收集器完成，CloudKeeper将获取收集器插件的图形并将其与自己的图形合并。这样，每个插件都可以在其自己的图形上独立操作，而不会出现任何并发问题。插件本身也可以使用相同的模式。例如，如果插件想要并行收集多个帐户和/或多个区域，它可以为每个帐户和区域创建一个图表，并在收集到区域时将其合并。

持久插件在启动时运行，可以注册一个或多个事件。这样，插件可以在例如清理即将开始时被通知，作为事件的一部分，它将被递给对当前实况图的引用。然后，它可以查看该图中的资源、搜索它们、过滤它们、查看它们的属性等，并执行保护资源不被删除或标记要删除的资源等操作。它还可以向发出运行结束信号的事件注册，并查看哪些资源已被清理，以生成可通过电子邮件发送的报告，或通知Slake上的资源所有者其资源已被清理。

EventType：数据启动：无START_COLLECT：NONE PROCESS_BEGIN：cloudkeeper.raph.Graph Collect_Begin：cloudkeeper.raph.Graph Generate_Metrics：cloudkeeper.raph.Graph Collect_Finish：cloudkeeper.raph.Graph Cleanup_plan：cloudkeeper.raph.Graph Cleanup_Begin：cloudkeeper.raph.Graph Cleanup_Finish：cloudkeeper.raph.Graph Process_Finish：cloudkeeper.graph。

如果插件希望CloudKeeper在不等待--interval秒的情况下开始其收集运行，那么它可以调度start_Collect。PROCESS_BEGIN表示循环开始。在该循环资源收集中，正在执行指标生成和资源清理。GENERATE_METRICS是插件的信号，它允许插件修改现有的指标或向登台图中的资源添加新的指标。CLEANUP_PLAN是通常调用持久清理插件的点。在这里，他们可以查看所有资源的标签和使用年限，并决定清理哪些资源。CLEANUP_BEGIN表示清理过程开始。这个钩子对于想要查看或修改先前创建的清理计划的插件很有用。当用户在CLI中输入Quit或Ctrl+c或接收到关闭信号(int/term)时，将调度关闭。插件也可能导致关机，尽管此功能应该谨慎使用。目前只有一个插件插件/Snowflake_Protection/使用此事件。它负责雪花保护(保护非常特殊的资源不被删除)，如果它不能解析其配置，它将偏离紧急关闭事件的路径。这使得CloudKeeper立即终止Python解释器，以确保不会意外删除任何受保护的资源。

CloudKeeper支持使用JOBS、ADD_JOB和REMOVE_JOB CLI命令或在提供给--Scheduler-config参数的crontab样式配置文件中计划CLI命令。计划的CLI命令可以使用小写字母的事件名称作为前缀，后跟冒号，这将使CloudKeeper在指定的时间点关联命令，以便在下次触发事件时运行一次。

第一行：每个星期六早上5点，安排一个命令在下一次调度CLEANUP_PLAN事件时运行。这个特定的命令将擦除ID为119548413362的帐户中的所有ec2实例和负载均衡器，这些实例和负载均衡器是在当天凌晨5点之前创建的。

第二行：每天午夜按资源类型计算资源数量，记录输出，并将其写入文件名中包含今天日期的文件。

如果命令没有以事件名称为前缀，则会立即在指定的时间点执行该命令。

CloudKeeper附带一个内置的开发Web服务器(默认为端口8000)。它用于少数内部请求(即不公开它)，并提供许多端点：

/Health#GET返回静态200 OK/metrics#GET Returns Prometheus Metrics/Collect#POST告诉CloudKeeper执行收集运行/Graph.gexf#GET返回实时Graph的GEXF表示/raph.raphml#GET返回实时Graph的GraphML表示/Graph.json#Get返回实时Graph的JSON表示/raph.txt#Get返回实时Graph的JSON表示/raph.txt#Get返回实时Graph/Graph.txt的JSON表示。

其中最有用的是/metrics和/graph。在我们自己的设置中，我们的CloudKeeper实例前面有一个身份验证和TLS代理。由于一次收集运行可能需要花费相当长的时间，具体取决于需要收集的帐户数量(在我们的示例中，收集和清理40多个AWS帐户需要大约一个小时)，因此我进入了一个开发工作流程，我将实时图表下载到本地系统，然后处理该本地副本。

$CloudKeeper--收集器远程--远程端点https://somelogin:[email protected]/graphor$curl-o图https://somelogin:[email protected]/graph$CloudKeeper--收集器远程--远程端点file://graph。

远程图形将在某种程度上智能地合并到本地图形中。您可以创建任意深度的CloudKeeper实例链，收集和合并帐户。

https://github.com/mesosphere/cloudkeeper

tags users