1，es不能使用root用户启动 　　es不能使用root用户启动，故需要主机上创建普通的用户，给普通用户sudo免密权限，visudo命令，在root ALL=(ALL) ALL这行下添加，内容是把以上root改成普通用户，最后的ALL换成NOPASSWD:ALL。实际工作中，如果以openstack等方式，需要es主机的话，自动创建好普通es用户，该要的权限也都可以添加好。最好后面部署的时候，不使用sudo的方式，我自己的练习用户是wenwen，所有部署目录都在/home/wenwen下，以后会尝试把用户做成变量，另外一些主机ip和目录的配置，也尽量做成变量，以便支持web平台的相关操作。

2，使用VMware练习，要准备四台虚拟机　　如果是使用VMware练习，准备四台虚拟机。ansible功能大多依赖python，如果是centos7以上，默认安装python，不用再装了。然后选择一台，安装ansible，其余的不用，这是ansible方便的地方。安装ansible的主机，我喜欢称之为跳板机或者堡垒机，后面都称为跳板机。为什么呢，因为即使ansible执行后，输入远程主机密码会保存会话，下次不用再输入了，但万一远程主机密码修改或会话失效呢，还要重新来。而设置免密登录，以rsa方式认证，则大致能避免这个问题。免密登录配置方式，可以参考别人的博客，https://www.cnblogs.com/276815076/p/10449354.html#5113218，里面有一些我遇到坑时的解决方式。我推测如果有openstack方式，则连免密登录配置都不用手动做了，跳板机上生成的公钥，当作openstack的一个变量应用于初始机器的authorized_key了，方便很多。这只是我的一种思路，实际上如果是使用密码，ansible也是支持把账号密码写到/etc/ansible/hosts里的，如下 方法一 主机+端口+密码 [webserver] 192.168.1.31 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456" 方法二 主机+端口+密码 [webserver] 192.168.1.3[1:3] [webserver:vars] ansible_ssh_pass="123456" 3，ansible执行时sudo的用户是普通用户还是root用户　　ansible在远程主机上执行时，可能会需要一些root权限，一般编写playbook会将remote_user设置为root，以下选项不用开启也可以，但是remote_user为root，就需要给root加免密登录了。我不想做root的免密，就让remoter_user为我自己的wenwen用户，然后开启以下的配置。修改ansible安装目录的ansible.cfg文件，以下配置开启 [privilege_escalation] become=True ***//使用“true”或“yes”来表示启用这个特权，如：become=true表示打开了become开关。 become_method=sudo *//*******表示用什么方式将普通账户切换到root或所需的其他账户，这里可以用su或sudo。 #become_user=root *//*****设置为root账户，相当于我们以普通账户登入到远程主机时，再使用su - root切换为root账户。 #become_ask_pass=False//表示询问密码 4，开始编写创建roles和playbook　　每个软件的安装都是一个role，在roles目录下，创建以下目录，刚创建的目录中再创建task,vars,handle,templates等，安装的role有以下： install-openjdk-epel-npm-unzip-nodejs-bzip2 这是一些需要yum的安装，需要将上面3中提到的sudo用户为root，使用我的wenwen用户就提示不让，也不知道为啥，明明给wenwen配置了所有root权限了，可能还是有些地方普通用户还是没有配好吧。 install-es 使用wenwen用户安装es和es-head，但是es-head的运行放到一个单独的playbook中了，因为可能需要sudo用户为root，后面再提。 install-kibana ，使用wenwen用户安装kibana并运行，需要es安装好并且es的全部节点都启动成功了。 install-logstash ，使用wenwen用户安装logstash并运行，配置的logstash.conf的output为es，也需要es节点都启动成功。 注意事项：install-es中还有一个修改系统配置文件的步骤，是需要root用户执行的，yml文件是task下的modifysys.yml，这个修改也太清楚作用，因为这个编写是用echo追加文件的方式，卸载elk里如果删除这几个配置的话，担心影响其它非elk软件的使用，所以如果确认主机上没有配置过，则可以去掉修改main.yml中的注释安装，执行后，再加上注释。不然下次安装，就重复添加了。 es-playbook 这是es-head的启动需要的playbook，没有做成role方式，为了不混淆安装卸载的role，将npm运行拆分出来了，和roles目录平级。里面是一个playbook的yml文件，第一次执行需要sudo为root用户，后面可以为普通用户，启动的的命令配置的nohup输出为/dev/null，我若配置到输出文件中，就不能正常启动，是不是因为输出到文件中的问题也不清楚，就只好按照能启动成功的方式来写了。 卸载的role： uninstall-elk 停止进程，删除目录，移除yum的一些组件，如openjdk，npm等，同样存在卸载风险，一些工具如jdk，可能非elk的软件也在用，卸载的话，就得不偿失了。把卸载依赖软件的部分在main.yml文件中注释了，保留了停止进程和删除目录的步骤，并打了tags，这样可以有选择的执行停止elk某个组件进程或者删除目录。如果需要卸载依赖软件，需要使用root用户。 5，关于role的介绍roles: <--所有的角色必须放在roles目录下，这个目录可以自定义位置，默认的位置在/etc/ansible/roles project: <---具体的角色项目名称，比如nginx、tomcat、php files： <--用来存放由copy模块或script模块调用的文件。 templates： <--用来存放jinjia2模板，template模块会自动在此目录中寻找jinjia2模板文件。 tasks： <--此目录应当包含一个main.yml文件，用于定义此角色的任务列表，此文件可以使用include包含其它的位于此目录的task文件。 main.yml handlers： <--此目录应当包含一个main.yml文件，用于定义此角色中触发条件时执行的动作。 main.yml vars： <--此目录应当包含一个main.yml文件，用于定义此角色用到的变量。 main.yml defaults： <--此目录应当包含一个main.yml文件，用于为当前角色设定默认变量。 main.yml meta： <--此目录应当包含一个main.yml文件，用于定义此角色的特殊设定及其依赖关系。 main.yml 6，手动添加防火墙规则　　偷懒没写到ansible中，分别在每台机器手动添加了，实际应用中，全是内网的话，机器初始化时，防火墙可能是关闭的，如果开启的话，可以用以下命令添加一个网段的所有端口访问。如果想按照需要添加端口，可网上搜索教程。 firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.0.0/16" accept" 7，执行ansible-playbook任务yml文件在roles目录下，定义了执行的主机，和用户，分别是以下几个，和role目录对应， install-openjdk-epel-npm-unzip-nodejs-bzip2.yml install-es.yml install-kibana.yml install-logstash.yml uninstall-elk.yml 8，执行说明 　　上面提过，首次安装需要来回切换用户，这个是针对es的安装，kibana和logstash安装普通用户就可以，只要远程主机安装了tar命令解压文件。还有对变量可能要做修改，我在各个role的vars目录的main.yml定义了变量，可以进行修改。另外es的节点名称变量定义在了hosts文件中，jinjia2模板就根据ip读取到了，以后可能有更加明细的方式，比如用when做判断。还有几个软件的本机ip，用到的是setup模块能够查询到的，如ansible_all_ipv4_addresses #ipv4地址，在j2文件中就是{{ ansible_all_ipv4_addresses|to_json }}，加上“|to_json”是为了将unicode转化成对象，就知道要这样用，为了解决copy到远程主机上前面加个u标记，不加“|to_json”是如[u"192.168.229.130"]这样的，启动也会报错。

9，需要优化的地方 　　没有加开机自启动配置的步骤，没有将handlers 和notity结合使用，这两个的作用是由特定条件触发的操作，满足条件方才执行，否则不执行，比如模板配置文件的copy，我是以加tags的方式，执行时要加-t参数。而handlers 和notity能自动判断文件变化，当notity变化，就执行handlers 的步骤，这以后再优化了。还有就是我的卸载的role，把三个都放一起了，每次执行要修改yml文件的hosts，还要用-t关联tags。实际操作很可能一不小心，忘记加-t参数了，就所有软件都卸载了，有点小坑，需要继续用ansible的一些知识优化