- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

金鱼哥RHCA回忆录：DO447Ansible Tower的维护和常规管理--基本的故障排除

金鱼哥发表于 2022/07/11 11:05:01 2022/07/11

【摘要】第十四章 Ansible Tower的维护和常规管理--基本的故障排除

🎹 个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区专家博主
📚个人资质：CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必须努力🔥

🎈支持我：可点赞👍、可收藏⭐️、可留言📝

官网：

https://docs.ansible.com/ansible-tower/3.8.1/html_zh/administration//troubleshooting.html

📜14.1.1 Ansible Tower组件

Red Hat Ansible Tower是一个由多个协作进程和服务组成的web应用程序。启用了四个主要网络服务，启动了Ansible Tower的其他组件:

Nginx提供了托管Ansible Tower应用程序的web服务器，并支持web UI和API。
PostgresQL是存储大多数Ansible Tower数据、配置和历史的数据库。
supervise是一个进程控制系统，它本身管理Ansible Tower应用程序的各个组件，执行诸如调度和运行作业等操作，监听正在运行的作业的回调，等等。
Rabbitmq-server是一个AMQP消息代理，它支持Ansible Tower应用组件的信令。

Ansible Tower还使用的第五个组件是memcached内存对象缓存守护进程，它被用作本地缓存服务。

这些网络服务使用正常的网络协议相互通信。对于一个正常的自包含Ansible Tower服务器，需要在系统外公开的主要端口是80/tcp和443/tcp，以允许客户端访问web Ul和API。

但是，其他服务也可能向外部客户端公开端口，除非特别保护。例如，PostqresQL服务监听5432/tcp上的任何连接，RabbitMQ服务器beam监听5672/tcp、15672/tcp和25672/tcp上的连接。如果只有本地Ansible Tower服务需要能够连接到这些端口，那么最好使用本地防火墙阻止对它们的访问。

警告：这就是为什么在用于安装Ansible Tower的清单文件中为PostqreSQL和RabbitMQ服务设置好密码很重要的原因之一。默认情况下，这些服务可以由互联网客户端直接联系，而弱密码可能使它们容易受到远程攻击。

📑启动，停止和重新启动Ansible Tower

Ansible Tower附带了/usr/bin/ansible-tower-service脚本，该脚本可以启动、停止、重启，并给出主要的Ansible Tower服务的状态，包括数据库和消息队列组件。

[root@tower ~]# ansible-tower-service status
Showing Tower Status
Redirecting to /bin/systemctl status postgresql.service
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2021-05-20 09:23:11 CST; 8h ago
 Main PID: 798 (postmaster)
…………

要访问可用选项的列表，运行ansible-tower-service命令，不带任何选项:

[root@tower ~]# ansible-tower-service
Usage: /usr/bin/ansible-tower-service {start|stop|restart|status}

下面的例子演示了重新启动Ansible Tower基础架构:

[root@tower ~]# ansible-tower-service restart
Restarting Tower
Redirecting to /bin/systemctl stop postgresql.service
Stopping rabbitmq-server (via systemctl): [ OK ]
Redirecting to /bin/systemctl stop nginx.service
Redirecting to /bin/systemctl stop supervisord.service
Redirecting to /bin/systemctl start postgresql.service
Starting rabbitmq-server (via systemctl): [ OK ]
Redirecting to /bin/systemctl start nginx.service
Redirecting to /bin/systemctl start supervisord.service

📑Supervisord组件

supervisor是一个过程控制系统，通常用于控制基于django的应用程序。它用于管理和监视长时间运行的进程或守护进程，并根据需要自动重启它们。在Ansible Tower中，supervisor管理Ansible Tower应用程序本身的重要组件。

你可以使用supervisorctl status命令查看由supervisor服务控制的Ansible Tower进程列表:

[root@tower ~]# supervisorctl status
exit-event-listener                     RUNNING   pid 1546, uptime 8:23:20
tower-processes:awx-callback-receiver   RUNNING   pid 1548, uptime 8:23:20
tower-processes:awx-channels-worker     RUNNING   pid 1549, uptime 8:23:20
tower-processes:awx-daphne              RUNNING   pid 1551, uptime 8:23:20
tower-processes:awx-dispatcher          RUNNING   pid 1547, uptime 8:23:20
tower-processes:awx-uwsgi               RUNNING   pid 1550, uptime 8:23:20

正如您在前面的输出中所看到的，supervisor控制着awx用户拥有的多个进程。其中之一是awx-celeryd守护进程，它被用作实时分布式消息传递任务和作业队列。

📜14.1.2 Ansible Towe配置和日志文件

📑配置文件

Ansible Tower的主要配置文件保存在/etc/tower目录中。这些包括在PostgreSQL数据库之外的Ansible Tower应用程序的设置文件，nginx的TLS证书和其他密钥文件。

对于Ansible Tower应用程序来说，这些文件中最重要的可能是/etc/tower/settings.py文件，该文件指定了作业输出、项目存储和其他目录的位置。

其他单独的服务可能在系统的其他地方有特定于服务的配置文件，例如web服务器使用的/etc/nginx文件。

📑日志文件

Ansible Tower应用程序日志文件存储在两个集中位置中的一个:

• /var/log/tower/

• /var/log/supervisor/

Ansible Tower服务器错误记录在/var/log/tower/目录中。/var/log/tower/目录中的一些关键文件包括:

/var/log/tower/tower.log, Ansible Tower应用程序的主日志。
/var/log/tower/setup*.log，是安装程序运行的日志。安装、备份或恢复Ansible Tower服务器。
/var/log/tower/task_system.log，用于记录各种系统管理任务(例如删除旧作业运行的记录)。

/var/log/supervisor/目录中存放了supervisor管理的服务、守护进程和应用程序的日志文件。此目录中的日志文件是控制所有这些守护进程的服务的主日志文件。其他文件包含有关这些守护进程活动的日志信息。

Ansible Tower还可以向外部日志聚合服务发送详细日志。日志聚合可以提供对Ansible Tower技术趋势或使用情况的洞察。这些数据可用于监视异常、分析事件和关联事件。Splunk、Elastic stack/logstash(以前的ELK)、Loggly和Sumologic都是可以与Ansible Tower一起使用的日志聚合和数据分析系统。

📑其他Ansible Tower文件

Ansible Tower的许多其他密钥文件都保存在/var/lib/awx目录中。这个目录包括:

/var/lib/awx/public/static: 用于静态根目录(这是基于Django的应用程序文件的位置)。
/var/lib/awx/projects: projects的根目录(在这个目录的子目录中，Ansible Tower将存储基于项目的文件-例如git库文件。
/var/lib/awx/job_status: 剧本的作业状态输出存储在这个文件中。

📜14.1.3 常见的故障场景

📑运行剧本问题

默认配置将剧本限制在/tmp目录下，并限制了剧本可以在Ansible Tower服务器上本地访问的内容。这可能会影响playbook委派给本地系统而不是目标主机的任务。

检查您的许可状态和由Ansible Tower服务器管理的唯一主机的数量。如果许可证已经过期，或者注册了太多的主机，您将无法启动作业。

📑连接到主机的问题

如果您在运行剧本时遇到连接错误的问题，请尝试以下方法：

验证您可以与托管主机建立SSH或WinRM连接。Ansible依赖于SSH(或者Microsoft Windows系统的WinRM)来访问您正在管理的服务器。
检查你的清单文件。查看主机名和IP地址。

📑剧本不会出现在作业模板列表中

如果您的剧本没有显示在“作业模板”列表中，请检查以下项目:

检查剧本中的YAML语法，并确保它可以被Ansible解析。
确保正确配置项目路径(/var/lib/awx/projects/)的权限和所有权，以便awx系统用户可以查看这些文件。

📑剧本还在待定状态

当您试图运行作业而它处于挂起状态时，请尝试以下操作:

确保Ansible Tower服务器有足够的可用内存，并且由supervisor管理的服务正在运行。执行命令supervisorctl status。
请确保 /var所在分区剩余空间大于1gb。当/var/目录的空闲空间不足时，作业将无法完成。
使用ansible-tower-service restart命令重新启动Ansible Tower基础设施。

📑错误: 提供的主机列表为空

如果你在Ansible Tower中运行剧本时遇到了Skipping: No Hosts Matched错误消息，请回顾以下内容:

检查并确保剧本中主机声明使用的主机模式与目录中的组或主机名匹配。主机模式是区分大小写的。
请确保组名中没有空格，并将其修改为使用下划线或不使用空格，以确保正确识别组。
如果您在作业模板中指定了一个限制，请确保它是一个有效的限制，并且它与清单中的某些内容相匹配。

📜14.1.4 执行命令行管理

Ansible Tower附带awx-manage命令行实用工具，可以用来访问详细的Ansible Tower内部信息。awx-manage命令必须以root用户或awx (Ansible Tower)用户的身份运行。这个工具最常用来重置Ansible Tower的管理密码和导入一个已存在的静态清单文件到Ansible Tower服务器。

📑修改Ansible Tower管理密码

Ansible Tower内置系统管理员帐号admin的密码是在安装Ansible Tower服务器时初始设置的。awx-manage命令提供了一种从命令行更改管理员密码的方法。要做到这一点，作为Ansible Tower服务器的根用户或awx用户，使用changepassword选项:

[root@tower ~]# awx-manage changepassword admin
Changing password for user 'admin'
Password: new_password
Password (again): new_password
Password changed successfully for user 'admin'

您还可以创建一个新的Ansible Tower超级用户，如果需要，该超级用户具有管理权限。要创建一个新的超级用户，可以使用awx-manage和createsuperuser选项。

[root@tower ~]# awx-manage createsuperuser
Username (leave blank to use 'root'): admin3
Email address: admin@demo.example.com
Password: new_password
Password (again): new_password
Superuser created successfully.

📜14.1.5 课本练习

[student@workstation ~]$ lab admin-troubleshoot start

📑1. 脚本执行后，会发现，页面不能访问。

📑2. 登录到Tower 机器中。

[student@workstation ~]$ ssh root@tower

📑3. 确保组成Ansible Tower的主要组件的服务都在运行，并且服务器的防火墙没有阻塞通信。

[root@tower ~]# firewall-cmd --list-ports
80/tcp 443/tcp

接下来，确定组成Ansible Tower基础设施的服务的状态。使用带有status参数的ansible-tower-service脚本。

[root@tower ~]# ansible-tower-service status
Showing Tower Status
Redirecting to /bin/systemctl status postgresql.service
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2021-05-25 11:37:35 CST; 4min 3s ago
  Process: 808 ExecStart=/usr/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS)
  Process: 788 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=0/SUCCESS)
 Main PID: 808 (code=exited, status=0/SUCCESS)
………………

[root@tower ~]# ansible-tower-service restart
Restarting Tower
Redirecting to /bin/systemctl stop postgresql.service
Redirecting to /bin/systemctl stop rabbitmq-server.service
Redirecting to /bin/systemctl stop nginx.service
Redirecting to /bin/systemctl stop supervisord.service
Redirecting to /bin/systemctl start postgresql.service
Redirecting to /bin/systemctl start rabbitmq-server.service
Redirecting to /bin/systemctl start nginx.service
Redirecting to /bin/systemctl start supervisord.service

要确认Ansible Tower的基础设施已经启动，请返回工作站，打开Firefox并登录到Ansible Tower的web UI。

📑4. 下一步是确定为什么PostgreSQL数据库没有运行。

[root@tower ~]# systemctl status postgresql -l
（查看 /var/log/messages 也可以）
May 25 11:44:51 tower postmaster[4737]: < 2021-05-25 03:44:51.977 UTC >LOG:  redirecting log output to logging collector process
May 25 11:44:51 tower postmaster[4737]: < 2021-05-25 03:44:51.977 UTC >HINT:  Future log output will appear in directory "pg_log".

PostqreSQL服务器似乎正在登录到pg_log目录。使用find命令定位该目录:

[root@tower ~]# find / -name pg_log
/var/lib/pgsql/data/pg_log
[root@tower ~]# cd /var/lib/pgsql/data/pg_log
[root@tower pg_log]# ls -l
total 20
-rw-------. 1 postgres postgres 11211 May 16 16:32 postgresql-Sun.log
-rw-------. 1 postgres postgres   786 May 20 09:23 postgresql-Thu.log
-rw-------. 1 postgres postgres  2176 May 25 11:44 postgresql-Tue.log
[root@tower pg_log]# less postgresql-Tue.log
< 2021-05-25 01:36:13.431 UTC >LOG:  database system was interrupted; last known up at 2021-05-20 09:58:16 UTC
< 2021-05-25 01:36:14.252 UTC >LOG:  database system was not properly shut down; automatic recovery in progress
< 2021-05-25 01:36:14.266 UTC >LOG:  redo starts at 0/3BC7E90
< 2021-05-25 01:36:14.269 UTC >LOG:  invalid record length at 0/3BCE088: wanted 24, got 0
< 2021-05-25 01:36:14.269 UTC >LOG:  redo done at 0/3BCDFD8
< 2021-05-25 01:36:14.269 UTC >LOG:  last completed transaction was at log time 2021-05-20 10:02:34.83921+00
< 2021-05-25 01:36:14.288 UTC >LOG:  MultiXact member wraparound protections are now enabled
< 2021-05-25 01:36:14.290 UTC >LOG:  autovacuum launcher started
< 2021-05-25 01:36:14.290 UTC >LOG:  database system is ready to accept connections
< 2021-05-25 03:37:35.490 UTC >LOG:  received fast shutdown request
< 2021-05-25 03:37:35.490 UTC >LOG:  aborting any active transactions
< 2021-05-25 03:37:35.490 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.492 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.492 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.492 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.493 UTC >LOG:  autovacuum launcher shutting down
< 2021-05-25 03:37:35.493 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.494 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.495 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.496 UTC >FATAL:  terminating connection due to administrator command
< 2021-05-25 03:37:35.502 UTC >LOG:  shutting down
< 2021-05-25 03:37:35.540 UTC >LOG:  database system is shut down
< 2021-05-25 03:44:51.979 UTC >LOG:  database system was shut down at 2021-05-25 03:37:35 UTC
< 2021-05-25 03:44:51.987 UTC >LOG:  MultiXact member wraparound protections are now enabled
< 2021-05-25 03:44:51.989 UTC >LOG:  database system is ready to accept connections
< 2021-05-25 03:44:51.989 UTC >LOG:  autovacuum launcher started

看来是有人手动停止了服务。

📑5. 现在您已经解决了服务器错误，本练习的其余部分将探索其他日志文件和用于排除Ansible Tower故障的有用工具。

supervisord服务负责运行一组程序，这些程序控制Ansible Tower的主要逻辑。这包括从正在运行的作业中接收作业事件的回调接收进程。

在Ansible Tower服务器的/var/log/supervisor目录中有很多supervisor服务的日志文件。在该目录中，显示supervisord.log日志文件。

[root@tower pg_log]# cd /var/log/supervisor
[root@tower supervisor]# tail -n 50 supervisord.log
2021-05-25 11:44:46,755 INFO exited: exit-event-listener (terminated by SIGTERM; not expected)
2021-05-25 11:44:46,756 WARN received SIGTERM indicating exit request
2021-05-25 11:44:46,757 INFO waiting for awx-dispatcher, awx-callback-receiver, awx-channels-worker, awx-uwsgi, awx-daphne to die
2021-05-25 11:44:46,769 INFO stopped: awx-channels-worker (terminated by SIGTERM)
2021-05-25 11:44:47,319 INFO stopped: awx-callback-receiver (exit status 0)
2021-05-25 11:44:47,354 INFO stopped: awx-dispatcher (exit status 0)
2021-05-25 11:44:47,761 INFO stopped: awx-uwsgi (exit status 0)
2021-05-25 11:44:49,765 INFO waiting for awx-daphne to die
2021-05-25 11:44:51,768 WARN killing 'awx-daphne' (1554) with SIGKILL
2021-05-25 11:44:51,781 INFO stopped: awx-daphne (terminated by SIGKILL)
2021-05-25 11:44:58,739 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2021-05-25 11:44:58,739 INFO Included extra file "/etc/supervisord.d/tower.ini" during parsing
2021-05-25 11:44:58,739 INFO Increased RLIMIT_NOFILE limit to 4096
2021-05-25 11:44:58,751 INFO RPC interface 'supervisor' initialized
2021-05-25 11:44:58,751 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2021-05-25 11:44:58,752 INFO daemonizing the supervisord process
2021-05-25 11:44:58,753 INFO supervisord started with pid 5175
2021-05-25 11:44:59,758 INFO spawned: 'exit-event-listener' with pid 5176
2021-05-25 11:44:59,762 INFO spawned: 'awx-dispatcher' with pid 5177
2021-05-25 11:44:59,765 INFO spawned: 'awx-callback-receiver' with pid 5178
2021-05-25 11:44:59,769 INFO spawned: 'awx-channels-worker' with pid 5179
2021-05-25 11:44:59,774 INFO spawned: 'awx-uwsgi' with pid 5180
2021-05-25 11:44:59,788 INFO spawned: 'awx-daphne' with pid 5181
2021-05-25 11:45:00,887 INFO success: exit-event-listener entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-05-25 11:45:00,887 INFO success: awx-dispatcher entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-05-25 11:45:00,887 INFO success: awx-callback-receiver entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-05-25 11:45:00,887 INFO success: awx-channels-worker entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-05-25 11:45:00,887 INFO success: awx-uwsgi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-05-25 11:45:00,887 INFO success: awx-daphne entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

正如您在输出中看到的，由supervisor服务管理的一些服务也已经停止。在执行ansible-tower-service restart命令重新启动停止的PostareSQL服务器之后，它们也被supervisor成功派生，允许你登录到Ansible Tower的web UI。

📑6. 可以通过使用supervisorctl命令确定supervisor管理的进程的状态。

[root@tower supervisor]# supervisorctl status
exit-event-listener                     RUNNING   pid 1542, uptime 0:17:22
tower-processes:awx-callback-receiver   RUNNING   pid 1544, uptime 0:17:22
tower-processes:awx-channels-worker     RUNNING   pid 1545, uptime 0:17:22
tower-processes:awx-daphne              RUNNING   pid 1547, uptime 0:17:22
tower-processes:awx-dispatcher          RUNNING   pid 1543, uptime 0:17:22
tower-processes:awx-uwsgi               RUNNING   pid 1546, uptime 0:17:22

📑7. 与Ansible Tower相关的其他日志文件保存在/var/log/tower目录下。

例如，如果使用Ansible Tower执行作业时出现问题，需要检查一个文件是/var/log/tower/tower.log。此日志包含了执行作业的状态和Ansible Tower inventory或Job模板中的更改的有用信息。

[root@tower supervisor]# grep job_templates /var/log/tower/tower.log
2021-05-20 01:33:52,819 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v2/job_templates/ from 172.25.250.9
2021-05-20 01:35:52,136 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v2/job_templates/ from 172.25.250.9
2021-05-20 01:48:29,945 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v2/job_templates/ from 172.25.250.9
2021-05-20 02:08:38,739 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v2/job_templates/ from 172.25.250.250
2021-05-20 02:40:36,228 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v1/workflow_job_templates/46/notification_templates_success/ from 172.25.250.9
2021-05-20 02:48:39,239 WARNING  awx.api.generics status 400 received by user admin attempting to access /api/v2/job_templates/48/ from 172.25.250.7
2021-05-20 02:49:48,873 WARNING  django.request Not Found: /api/v2/job_templates/Exact copy of DEV ftpservers setup/
2021-05-20 02:54:04,189 WARNING  django.request Not Found: /api/v2/job_templates/New template/
2021-05-25 03:37:30,131 WARNING  awx.api.generics status 404 received by user admin attempting to access /api/v1/job_templates/55555/launch/ from 172.25.250.9
2021-05-25 03:37:30,135 WARNING  django.request Not Found: /api/v1/job_templates/55555/launch/

这里的日志消息表明有东西试图启动一个不存在的作业模板。

📑8. 管理员尝试使用API从172.25.250.9启动一个不存在的ID为55555的作业模板，这也应该显示在nginx web服务器的access.log文件中。

[root@tower supervisor]# grep 55555 /var/log/nginx/access.log
172.25.250.9 - admin [25/May/2021:11:37:30 +0800] "POST /api/v1/job_templates/55555/launch/ HTTP/1.1" 404 23 "-" "curl/7.61.1" "-"

📑9.使用awx-manage命令创建一个额外的Ansible Tower系统管理员帐户并更改其密码。

首先，使用awx-manage命令和createsuperuser子命令创建一个新的系统管理员用户。使用以下信息:

[root@tower supervisor]# awx-manage createsuperuser
Username (leave blank to use 'root'): admin2
Email address: admin2@lab.example.com
Password: redhat
Password (again): redhat
Superuser created successfully.

📑10. 使用awx-manage命令和changepassword子命令重置admin2用户的密码。

[root@tower supervisor]# awx-manage changepassword admin2
Changing password for user 'admin2'
Password: redhat2
Password (again): redhat2
Password changed successfully for user 'admin2'

📑11. 测试登录。

📑12. 清除实验。

[student@workstation ~]$ lab admin-troubleshoot finish

💡总结

RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶🤪。

以上就是【金鱼哥】对 第十四章 Ansible Tower的维护和常规管理–基本的故障排除 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾红帽认证专栏系列：
RHCSA专栏：戏说 RHCSA 认证
RHCE专栏：戏说 RHCE 认证
此文章收录在RHCA专栏：RHCA 回忆录

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！

点赞
收藏
关注作者

0/1000

抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认取消

加入云驻计划，成为创作者

华为云周边好礼
免费体验产品
特殊身份标识
线下官方门票
内部专家零距离
与10000+优质创作者共同成长

立即加入