hanbert.github.io/search.xml at master · hanbert/hanbert.github.io

History

144 lines (144 loc) · 149 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

<?xml version="1.0" encoding="utf-8"?>

<entry>

<url>%2F2017%2F10%2F03%2FKolla%E7%9B%B8%E5%85%B3%E9%9B%B6%E9%9B%B6%E7%A2%8E%E7%A2%8E%2F</url>

<content type="text"><![CDATA[本部分主要介绍一些Kolla使用过程中总结的经验和技巧等零碎知识，不成体系，也会附带一部分Sahara Plugin在由Kolla部署OpenStack环境下，如何增加和生效。节点规划节点的规划和容器的分布由inventory控制，/usr/share/kolla/ansible/inventory目录下的all-in-one和multinode,如果单节点部署，需要指定all-in-one；如果是多节点部署，你需要指定multinode。尽量不要动all-in-one，但是如果采用多节点安装，则multinode应该根据自己的实际情况改写。变量配置部署过程中用到的很多参数，大部分都写在kolla-ansible/ansible/group_vars/all.yml这个文件里面，有一部分写在kolla-ansible/etc/kolla/globals.yml中，两者有部分是重复的，globals.yml会覆盖all.yml的配置项。这些变量的值，最终会替换ansible的playbook里面对应的变量的值，控制playbook的最终结果。这些playbook主要分为4类： default：代表默认的一些配置 meta：代表依赖于哪个playbook task：代表具体的部署任务 template：代表模板，主要包含容器的配置文件，以及容器启动时的一些初始化操作，主要是拷贝配置文件和启动该容器对应的服务。这些配置playbook全部放在kolla-ansible/ansible/roles对应的目录下。部署前检测kolla提供了一个检测命令，可以对各个角色节点进行一些检测，主要是包括：版本检测：docker-py,Ansible 端口检测：所有容器配置的监听端口是否已经被占用服务检测：这里检测的就比较杂了，比如libvirt是否在运行，如果运行就会报错，比如Docker版本是否满足要求等等你可以查看kolla-ansible/ansible/rolesprechecks/tasks下面的playbook，知道所有的检测项。当检测出错时，你就需要根据出错的信息，对某些角色的节点进行些修改配置。检测通过，下面的部署不一定成功，但检测没通过，下面的部署是肯定失败的。部署完成后的清理在某些情况下，可能需要对环境中的容器，镜像，甚至节点上的所有关于kolla的配置，进行清理，可以使用kolla-ansible destroy -i inventory/multinode的子命令对环境清理。部署完成后的扩展kolla增加节点理论上很简单，只需要两步，一是修改对应的inventory，二是对待添加节点做好部署前的准备工作。修改某个容器的配置通过修改对应节点/etc/kolla/目录下对应的服务的配置文件，然后重启对应的容器，就可以修改相关配置。1docker restart CONTAINER1 CONTAINER2 CONTAINER3 ...... 如果是修改多个容器的配置，可以通过修改kolla-ansible/ansible/roles目录下对应的配置文件的模板，/etc/kolla/globals.yml下面的配置项，kolla-ansible/ansible/group_vars/all.yml里面的配置项，然后执行 kolla-ansible reconfigure命令即可。 Note:这种方式会将所有容器的配置重新覆盖一次，所有容器都会重启一次修改代码使用docker exec -it -u root CONTAINER_ID /bin/bash命令以root用户的身份登录到相应的container中，然后直接修改里面的代码，如果需要修改配置文件，可以直接修改/etc/kolla/相应目录下的.conf文件，然后重启容器即可。如果需要复用这个修改后的容器，可以使用docker commit基于你改动的容器，重新制作一个镜像，指定一个合适的tag(即容器镜像的版本，不要和已有镜像的重复)，最后上传到本地镜像仓库中即可。 Note：当移除旧的容器，如果简单的执行docker run的相关命令启动一个新的容器会出错，原因是启动容器时会做些初始化的操作，由于涉及到文件的拷贝，所以会出现缺少相关文件的报错。而启动容器以及容器的初始化的操作由kolla_toolbox（这是kolla在部署过程中，第二个启动的容器）执行，具体的由kolla_toolbox里的/usr/local/bin/kolla_start和 /usr/local/bin/kolla_set_configs来控制。基于Dockerfile重新制作的镜像：由于采用源码的方式安装相关的第三方库，我们可以在git上维护相关的所有代码，在我们提交新的commit的时候，通过拉取新的源码，重新用Dockerfile制作镜像。一般来说Dockerfile都不需要变化。部署完成后的环境的升级可以通过修改/etc/kolla/global.yml里面openstack-release的参数，然后执行kolla-ansible upgrade的命令升级环境。理论上可以做到单个容器的升级，但是具体能不能实现，有待验证。如果需要回滚就只是将/etc/kolla/global.yml里面openstack-release的参数，改回原来的版本即可。 kolla网络相关参数 network_interface：为下面几种interface提供默认值 api_interface: 用于management network,即openstack内部服务间通信，以及服务于数据库通信的网络。这是系统的风险点，所以，这个网络推荐使用内网，不能够接出到外网，默认值为：network_interface kolla_external_vip_interface: 这是一个公网网段，当你想要HAProxy Public endpoint暴漏在不同的网络中的时候，需要用到。当kolla_enables_tls_external设置为yes的时候，是个必选项。默认值为：network_interface storage_interface: 虚拟机与Ceph通信接口，这个接口负载较重，推荐放在10Gig网口上。默认值为：network_interface cluster_interface: 这是Ceph用到的另外一个接口，用于数据的replication，这个接口同样负载很重，当其成为bottleneck的时候，会影响数据的一致性和整个集群的性能。默认：network_interface tunnel_interface: 这个接口用于虚拟机与虚拟机之间的通信，通过 tunneled网路进行，比如：Vxlan，GRE等，默认为：network_interface neutron_external_interface: 这是Neutron需要的接口，Neutron会将其绑定在br-ex上，既可以是flat网络，也可以是tagged vlan网络，必须单独设置 Docker的一些配置建议Docker是kolla的核心依赖，配置好Docker能够有效改变kolla的使用体验，在某些版本中Docker的存储驱动默认是devicemapper，这个driver严重损害性能。我们推荐使用btrfs或者aufs作为驱动。 kolla将所有的永久数据存放在Docker volumes中，默认这个volumes在docker的工作目录下面创建，默认是：/var/lib/docker，建议确认这个目录具有足够的空间，否则会影响Database的commits和rabbitmq的性能尤其当enable_central_logging和openstack_logging_debug设置为true的时候，更需要关注. 部署完成后的服务运行日志所有组件的日志都放在/var/lib/docker/volumes/kolla_logs/_data/对应的目录下。替换Horizon的图标提前将需要用到的文件凡在一台可以被container 通过ssh连接到的host的/opt目录下：1234567891011121314151617//登陆Horizon的container中docker exec -it -u root horizon /bin/bash//替换下面这个目录下的对应文件cd /var/lib/kolla/venv/lib/python2.7/site-packages/openstack_dashboard/static/dashboard/imgscp root@[SERVER_IP]:/opt/logo-splash.svg ./scp root@[SERVER_IP]:/opt/logo.svg ./scp root@[SERVER_IP]:/opt/favicon.ico .///替换下面这个目录下的对应文件cd /var/lib/kolla/venv/lib/python2.7/site-packages/static/dashboard/imgscp root@[SERVER_IP]:/opt/logo-splash.svg ./scp root@[SERVER_IP]:/opt/logo.svg ./scp root@[SERVER_IP]:/opt/favicon.ico .///退出登陆exit 以上过程做完后，无需重启容器，清空浏览器缓存，从新刷新Dashboard页面即可看到生效。 Note:如果存在多个controller节点，需要每个controller节点都做修改！！！部署Sahara的Plugin代码首先先将需要部署的Plugin代码放置到一台可以被container 通过ssh连接到的host的/opt目录下： ① 修改Sahara_engine服务容器1234567891011121314151617181920212223//登陆Sahara_engine容器docker exec -u root -it sahara_engine /bin/bash//拷贝Plugin代码cd /var/lib/kolla/venv/lib/python2.7/site-packages/sahara/pluginsscp -r root@[SERVER_IP]:/opt/sandbox/ .///修改 *.egg-info/entry_points.txt文件//在[sahara.cluster.plugins]选项下，添加“sandbox = sahara.plugins.sandbox.plugin:VanillaProvider”cd /var/lib/kolla/venv/lib/python2.7/site-packages/sahara-6.0.1-py2.7.egg-infovi entry_points.txt //退出容器exit//修改Sahara_engine的配置文件//在[DEFAULT]下，添加“plugins = sandbox,vanilla,spark,cdh,ambari,storm,mapr”docker restart sahara_enginecd /etc/kolla/sahara-enginevi sahara.conf//重启Sahara_engine容器docker restart sahara_engine ② 修改Sahara_api服务容器1234567891011121314151617181920212223//登陆Sahara_api容器docker exec -u root -it sahara_api /bin/bash//拷贝Plugin代码cd /var/lib/kolla/venv/lib/python2.7/site-packages/sahara/pluginsscp -r root@[SERVER_IP]:/opt/sandbox/ .///修改 *.egg-info/entry_points.txt文件//在[sahara.cluster.plugins]选项下，添加“sandbox = sahara.plugins.sandbox.plugin:VanillaProvider”cd /var/lib/kolla/venv/lib/python2.7/site-packages/sahara-6.0.1-py2.7.egg-infovi entry_points.txt //退出容器exit//修改Sahara_api的配置文件//在[DEFAULT]下，添加“plugins = sandbox,vanilla,spark,cdh,ambari,storm,mapr”docker restart sahara_apicd /etc/kolla/sahara-apivi sahara.conf//重启Sahara_api容器docker restart sahara_api 上述过程做完后，登陆Dashboard，找到Data processing下的Plugin,即可以看到已经生效。 Note:如果存在多个controller节点，需要每个controller节点都做修改！！！通过Kolla工具进行Build镜像此处的Kolla不同于上面的Kolla，上面的Kolla是指Kolla-ansible这个部署工具，这里的kolla 是个OpenStack的服务组件的Docker镜像构建工具，这点一定要分清。 ① 安装kolla，源码安装123456git clone http://git.trystack.cn/openstack/kollacd kolla//切换到O版的分支git checkout origin/stable/ocatapip install ./pip show kolla //查看kolla的版本 ② 开始build镜像1kolla-build –b centos –t binary –p default 相关参数说明： -b：指定build的镜像系统类型，centos或者ubuntu -t：制定安装类型，binary为二进制安装,source为源码安装 -p：指定build哪些镜像，默认：chrony,cron,kolla-toolbox,glance,haproxy,heat,heka,horizon,keepalived,keystone,mariadb,memcached,neutron,nova,openvswitch,rabbitmq；如果不指定-p可以单独指定build某个，如：nova Note:这个过程可能会因为网络问题导致build失败，可以重复几次。 ③ build完成后查看本地镜像，并打包保存：12345// 查看本地镜像docker images//镜像打包保存docker save lokolla/centos-binary-haproxy >/opt/centos-binary-haproxy.tar ④ 在目标机器上启动一个Registry服务：1docker run -d -p 4000:5000 --restart=always --name registry registry:2 ⑤ 将打包好的本地镜像，先拷贝到目标机器上，load一下推送到registry中去：123456//导入到目标机器上docker load < /opt/centos-binary-haproxy.tar//给单独的一个镜像打标签，以haproxy为例docker tag 7f5595d85f41 [SERVER_IP]:4000/test/centos-binary-haproxy:4.0.3//推送到本地registry中docker push [SERVER_IP]:4000/test/centos-binary-haproxy Reference: OpenStack实战分享：Kolla多节点部署加Ceph后端: http://www.99cloud.net/html/2017/jiuzhouyuanchuang_0317/302.html Docker更换国内镜像下载源由于国内特殊的网络环境，往往我们从Docker Hub中拉取镜像并不能成功，而且速度特别慢。那么我们可以给Docker配置一个国内的registry mirror，当我们需要的镜像在mirror中则直接返回，如果没有则从Docker Hub中拉取。是否使用registry mirror对Docker用户来说是透明的。 DaoCloud在国内提供了首个Docker Hub镜像服务，而且免费，大大提高了国内Docker用户的使用热情，非常感谢DaoCloud。使用方法： ① 修改Docker配置文件/etc/default/docker，添加如下内容： 1DOCKER_OPTS="--registry-mirror=http://aad0405c.m.daocloud.io" ② 重启Docker服务： 1service docker restart 现在就可以直接从国内源pull镜像啦！]]></content>

</categories>

<tags>

<tag>Openstack</tag>

<tag>Kolla</tag>

</tags>

</entry>

<entry>

<url>%2F2017%2F10%2F03%2FKolla%E5%A4%9A%E8%8A%82%E7%82%B9%E7%89%A9%E7%90%86%E6%9C%BA%E9%83%A8%E7%BD%B2OpenStack%2F</url>

<content type="text"><![CDATA[2014年下半年，OpenStack基金会已经意识到Docker对OpenStack可能造成的威胁，研究OpenStack和Docker如何并存迫在眉睫，在2015年的温哥华峰会上，推出了3个项目： kolla：把OpenStack放到容器里面，部署OpenStack Magnum：在OpenStack平台上面部署容器，后来改成COE(Container Orchestration Engine) Solum：利用Docker来实现CI(Continuous Integration)/CD(Continuous Delivery) 这就是当初基金会的设想，只不过经过2年的发展，目前就Kolla项目是最靠谱的。Magnum修改了自己的方向，并且带来的价值不大。Solum已经基本快要死掉了。目前依据OpenStack的传统，Kolla项目被拆分成了三个项目： Kolla：主要负责OpenStack各个组件Docker镜像的制作 Kolla-Ansible：负责容器的管理配置，即OpenStack的部署，以Ansible作为编排引擎 Kolla-Kubernetes：和上面功能一样，只不过是以Kubernetes作为编排引擎 Kolla项目自诞生以来，短短一年内投入生产环境，真正放到生产环境是在Mitaka版本。又经过了一年的完善，终于在Ocata版本，做到了一个很完善的地步。 Kolla的优势和使用场景，体现在如下几个方面：原子性的升级或者回退OpenStack部署；基于组件升级OpenStack；基于组件回退OpenStack； Kolla的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过Docker Image将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。 Kolla使用到的技术如下： Docker Ansible Python Docker-py Jinja2 Note：很多对Docker不熟悉人，以为把OpenStack放到Docker里，虚拟机也是跑在Docker里。其实这是误解。Kolla仅仅是把OpenStack各个服务的进程，放到Docker里而已。以前的vm怎么运行，现在还是怎么运行，没做任何的改变。一、Kolla部署OpenStack的架构如下图所看到，通过Kolla部署OpenStack能够实现，全组件HA(High Available)，其中，像其他OpenStack部署项目一样，对于MySQL的HA方案，默认采用的均是Galera。二、前期准备目前Kolla能够在Ubuntu和Centos两种Linux发行版上部署OpenStack，本次部署使用Centos7，OpenStack组件Nova，Cinder，Swift后端存储使用Ceph，Glance理论上后端存储也可以采用Ceph，但是采用Ceph作为后端存储的话，Glance的镜像格式必须是raw，目前主流镜像格式img、qcow2都需要转换为raw格式才能够正常使用，但是raw镜像不支持快照。可以自行搜索这些镜像格式之间的区别。具体基础环境要求如下：物理机最小配置：8 GB 内存，40 GB 存储 Centos7 操作系统，最小化安装，最好根据自己规划，在安装过程中及时更改主机名最少2块网卡，此处部署使用3块，其中一个网卡是万兆网卡数据盘与系统盘分离，至少1块数据盘，理想状态3块数据盘至少保证部署机有root登陆权限，其余节点可以视情况而定 Reference: QCOW2/RAW/qemu-img 概念浅析: http://blog.csdn.net/Jmilk/article/details/69418999?locationNum=5&fps=1 qcow2、raw、vmdk等镜像格式的比较和基本转换: http://blog.chinaunix.net/uid-14735472-id-4220089.html 三、网络环境准备本次部署，使用一台单独的48口交换机，因为采用了三个网卡，故在交换机上划分出了三个网段： Admin Network：部署过程中各节点通信，部署完成后OpenStack各组件间通信，能够连接互联网 Public Network：给OpenStack平台上的VM提供Floating IP以使其能够正常远程SSH和连接网络，能够连接互联网 Storage Network：Ceph节点间通信和数据传输的网段，内网网段，与互联网隔离本次部署三个网卡与三个网段的对应的情况如下： em1：连接到Admin Network，提前在网卡上配置好IP地址，确保能够远程SSH，且能够连接互联网 em2：连接到Pubic Network，只需要把网上连接到相应Port上，网卡状态为UP即可，不需要配置IP p5p2：连接到 Storage Network，万兆网卡，需要提前配置一个内网地址段IP确保各个节点间能通信 Note: Public Network需要提前划分出一个地址段，预留足够的IP地址给OpenStack的VM使用 em2网卡一定不要配置IP地址 p5p2网卡不要配置GateWay，否则可能会与em1网卡的Gateway冲突，导致该主机不能够正常联网四、部署规划本次部署共12个节点，其中3个controller节点，分别命名为：controller1，controller2，controller3；9个compute节点，分别命名为：compute1~9；其中一台controller节点还承担Kolla部署机角色，具体角色划分如下： Kolla部署机：controller1 OpenStack镜像本地源服务器：controller1 3台controller节点：controller1~3 9台compte节点：compute1~9 Ceph的OSD节点：controller1~3，compute1~9的所有的数据盘五、配置免密登陆这一过程不是必须的，但是为了方便操作，最好在各个节点之间实现免密登陆，以下过程在所有的节点上执行： ① 生成秘钥对，输入以下命令，然后一路回车：1[root@controller1 ~]# ssh-keygen -t rsa ② 将所有的公钥复制到authorized_keys文件中：12[root@controller1 ~]# cd ~/.ssh/[root@controller1 ~]# vim authorized_keys 搜集每个节点上的id_rsa.pub文件内容，添加到authorized_keys文件中，然后保存退出。 ③ 同样的过程，在剩余所有节点上执行一遍，然后修改hosts文件：1[root@controller1 ~]# vim /etc/hosts 输入每个主机的IP 主机名，然后退出保存。 ④ 验证是否成功：1[root@controller1 ~]# ssh controller2 六、安装依赖包以下过程在所有节点上都：安装epel-release、pip、git：1[root@controller1 ~]# yum install -y epel-release python-pip git 如果安装过程特别慢，可以考虑更换软件源，以下是Centos7更换阿里云源的方法：1234cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bakwget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo或者：curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo 升级pip到最新版：1[root@controller1 ~]# pip install -U pip 如果pip下载包也比较慢，可以更换pip的源为豆瓣源或者阿里云源，以下以更换为阿里云源为例：1234567[root@controller1 ~]# mkdir -p ~/.pip[root@controller1 ~]# vim ~/.pip/pip.conf// 添加以下内容：[global]index-url = http://mirrors.aliyun.com/pypi/simple/[install]trusted-host=mirrors.aliyun.com 安装其他的一些依赖：1[root@controller1 ~]# yum install python-devel libffi-devel gcc openssl-devel libselinux-python OpenStack、RabbitMQ、Ceph等都对节点间的时间差有一定的要求，如果时间差过大，可能导致服务不能够正常运行，为此，我们最好能够安装NTP服务，让每个节点自动进行时间同步：123[root@controller1 ~]# yum install ntp[root@controller1 ~]# systemctl enable ntpd.service[root@controller1 ~]# systemctl start ntpd.service 安装ansible，并升级到最新版：12[root@controller1 ~]# yum install ansible[root@controller1 ~]# pip install -U ansible 停止libvirt组件，否则后面安装会失败：12[root@controller1 ~]# systemctl stop libvirtd.service[root@controller1 ~]# systemctl disable libvirtd.service 安装最新版Docker，升级到最新版，然后检查Docker的版本：123[root@controller1 ~]# curl -sSL https://get.docker.io | bash[root@controller1 ~]# pip install -U docker[root@controller1 ~]# docker --version 如果由于网络原因，以上安装方法Docker不能够成功安装，可以使用下面的方法进行安装：12345678910111213// 设置repo[root@controller1 ~]# tee /etc/yum.repos.d/docker.repo << 'EOF'[dockerrepo]name=Docker Repositorybaseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/enabled=1gpgcheck=1gpgkey=https://yum.dockerproject.org/gpgEOF// 安装Docker[root@controller1 ~]# yum install docker-engine docker-engine-selinux[root@controller1 ~]# pip install -U docker[root@controller1 ~]# docker --version 对Docker进行配置：12345[root@controller1 ~]# mkdir /etc/systemd/system/docker.service.d[root@controller1 ~]# tee /etc/systemd/system/docker.service.d/kolla.conf <<-'EOF'[Service]MountFlags=sharedEOF 重新加载守护进程，并重启Docker服务：1234[root@controller1 ~]# systemctl daemon-reload[root@controller1 ~]# systemctl restart docker// 设置docker开机自启[root@controller1 ~]# systemctl enable docker 为Docker配置访问私有仓库，修改ExecStart字段：123[root@controller1 ~]# vim /usr/lib/systemd/system/docker.service#ExecStart=/usr/bin/dockerdExecStart=/usr/bin/dockerd --insecure-registry [SERVICE_IP]:4000 其中[SERVICE_IP]换成你部署的私有仓库所在主机的IP，本次部署在controller1上，所以用controller1的IP。重启Docker服务：12[root@controller1 ~]# systemctl daemon-reload[root@controller1 ~]# systemctl restart docker 七、配置Docker的私有仓库限于国内网络环境的问题，如果直接在线安装很容易失败，所以我们非常有必要建立一个本地仓库。建立本地仓库所需要的OpenStack的各个组件的镜像，既可以通过Kolla进行build，也可以直接下载官网制作好的镜像。运行Registry服务的容器，由于5000端口与keystone端口号冲突，所以我们需要修改其映射到本地4000端口上：123[root@controller1 ~]# docker run -d -v /opt/registry:/var/lib/registry -p 4000:5000 --restart=always --name registry registry:2// 查看是否成功启动[root@controller1 ~]# docker ps 运行以上命令后，会自动在线拉取registry:2的镜像，如果因为网络环境不能够正常下载，也可以在一个网络状况比较好的机器上先下载好，然后导出为.tar包，再在相应的机器上导入：1234567// 网络状况较好的机器上[root@localhost ~]# docker pull registry:2[root@localhost ~]# docker images[root@localhost ~]# docker save -o registry_v2.tar registry:2// 手动将 registry_v2.tar 包拷贝到目标机器上，然后导入[root@controller1 ~]# docker load -i ./registry_v2.tar[root@controller1 ~]# docker images 当前机器内有了本地镜像了以后，在运行docker run，启动registry容器：123[root@controller1 ~]# docker run -d -v /opt/registry:/var/lib/registry -p 4000:5000 --restart=always --name registry registry:2// 查看是否正常启动[root@controller1 ~]# docker ps 提前下载好官方的镜像包，本次使用：centos-source-registry-ocata.tar.gz,将其解压到：1tar -zxvf centos-source-registry-ocata.tar.gz -C /opt/registry/ 在浏览器中输入：[SERVICE_IP]:4000/v2/_catalog，如果现实如下，则说明已经成功安装了本地仓库： Reference: OpenStack官方kolla镜像包下载地址：http://tarballs.openstack.org/kolla/images/ 八、安装Kolla-ansible部署工具此过程只需要在部署机上面执行，kolla-ansible既可以使用pip来安装，也可以通过git源码安装，本次通过源码安装：下载源码包，一定要下载对应的版本，我们此次部署的是O版，所以下载O版的kolla-ansible：12[root@controller1 ~]# cd /opt[root@controller1 ~]# git clone http://git.trystack.cn/openstack/kolla-ansible –b stable/ocata 安装kolla-ansible：12[root@controller1 ~]# cd kolla-ansible[root@controller1 ~]# pip install ./ 复制配置文件和inventory文件：12[root@controller1 ~]# cp -r etc/kolla /etc/kolla/[root@controller1 ~]# cp -r ansible/inventory /home/inventory/ 如果是在虚拟机里装kolla，希望可以启动再启动虚拟机，那么你需要把virt_type=qemu，默认是kvm：123456[root@controller1 ~]# mkdir -p /etc/kolla/config/nova[root@controller1 ~]# cat << EOF > /etc/kolla/config/nova/nova-compute.conf[libvirt]virt_type=qemucpu_mode = noneEOF 生成密码文件：1[root@controller1 ~]# kolla-genpwd 修改登录dashboard的admin用户的登录密码：123[root@controller1 ~]# vim /etc/kolla/passwords.yml// 修改以下字段keystone_admin_password: admin 九、开始部署由于我们采用的是多节点物理机部署，在部署之前，我们需要修改globals.yml和multinode两个配置文件。 ① 修改globals.yml1[root@controller1 ~]# vim /etc/kolla/globalss.yml 给出以下样例，附带部分相关说明：123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346---#################### Kolla options#################### Valid options are [ COPY_ONCE, COPY_ALWAYS ]#config_strategy: "COPY_ALWAYS"# Valid options are [ centos, oraclelinux, ubuntu ]# 和我们使用的操作系统有关系，此处我们用的centos7，所以填写“centos”kolla_base_distro: "centos" # Valid options are [ binary, source ]# 我们下载的官方镜像包是“source”类型的，如果是“binary”就改成“binary”kolla_install_type: "source"# Valid option is Docker repository tag# 这个可以看看官方镜像包中软件的tag是多少，我们下载的O版对应：4.0.3openstack_release: "4.0.3"# Location of configuration overrides#node_custom_config: "/etc/kolla/config"# This should be a VIP, an unused IP on your network that will float between# the hosts running keepalived for high-availability. When running an All-In-One# without haproxy and keepalived, this should be the first IP on your# 'network_interface' as set in the Networking section below.#这个IP地址是和em1网卡在同一个网段，但是没有使用的地址，用来做HA的绑定地址kolla_internal_vip_address: "xxx.xxx.xxx.xxx"# This is the DNS name that maps to the kolla_internal_vip_address VIP. By# default it is the same as kolla_internal_vip_address.#kolla_internal_fqdn: "{{ kolla_internal_vip_address }}"# This should be a VIP, an unused IP on your network that will float between# the hosts running keepalived for high-availability. It defaults to the# kolla_internal_vip_address, allowing internal and external communication to# share the same address. Specify a kolla_external_vip_address to separate# internal and external requests between two VIPs.#kolla_external_vip_address: "{{ kolla_internal_vip_address }}"# The Public address used to communicate with OpenStack as set in the public_url# for the endpoints that will be created. This DNS name should map to# kolla_external_vip_address.#kolla_external_fqdn: "{{ kolla_external_vip_address }}"##################### Docker options##################### Below is an example of a private repository with authentication. Note the# Docker registry password can also be set in the passwords.yml file.#填写本地仓库的运行的服务器地址+端口号docker_registry: "[SERVICE_IP]:4000"#如果使用的是OpenStack官方的镜像包，此项必须为：“lokolla”docker_namespace: "lokolla"#docker_registry_username: "sam"#docker_registry_password: "correcthorsebatterystaple"################################ Neutron - Networking Options################################ This interface is what all your api services will be bound to by default.# Additionally, all vxlan/tunnel and storage network traffic will go over this# interface by default. This interface must contain an IPv4 address.# It is possible for hosts to have non-matching names of interfaces - these can# be set in an inventory file per host or per group or stored separately, see# http://docs.ansible.com/ansible/intro_inventory.html# Yet another way to workaround the naming problem is to create a bond for the# interface on all hosts and give the bond name here. Similar strategy can be# followed for other types of interfaces.#此处配置第一块网卡，也是其他未制定网卡的Interface的默认选项network_interface: "em1"# These can be adjusted for even more customization. The default is the same as# the 'network_interface'. These interfaces must contain an IPv4 address.#kolla_external_vip_interface: "{{ network_interface }}"#api_interface: "{{ network_interface }}"#Ceph数据传输专用网卡,此项最好为万兆网卡，以提升总体性能storage_interface: "p5p2"cluster_interface: "p5p2"#tunnel_interface: "{{ network_interface }}"#dns_interface: "{{ network_interface }}"# This is the raw interface given to neutron as its external network port. Even# though an IP address can exist on this interface, it will be unusable in most# configurations. It is recommended this interface not be configured with any IP# addresses for that reason.#floatingIP用来外转数据包的网卡，就是我们空出来，没有配置IP的那个网卡neutron_external_interface: "em2"# Valid options are [ openvswitch, linuxbridge ]#neutron_plugin_agent: "openvswitch"##################### keepalived options##################### Arbitrary unique number from 0..255#keepalived_virtual_router_id: "51"##################### TLS options##################### To provide encryption and authentication on the kolla_external_vip_interface,# TLS can be enabled. When TLS is enabled, certificates must be provided to# allow clients to perform authentication.#kolla_enable_tls_external: "no"#kolla_external_fqdn_cert: "{{ node_config_directory }}/certificates/haproxy.pem"##################### OpenStack options##################### Use these options to set the various log levels across all OpenStack projects# Valid options are [ True, False ]#openstack_logging_debug: "False"# Valid options are [ novnc, spice ]#nova_console: "novnc"# OpenStack services can be enabled or disabled with these options# 以下选项根据自己想要安装的OpenStack组件，把相应选项前的注释去掉即可enable_aodh: "yes"#enable_barbican: "no"enable_ceilometer: "yes"#enable_central_logging: "no"enable_ceph: "yes"#如果用ceph作为swift的后端存储，enable_ceph_rgw必须为yesenable_ceph_rgw: "yes"#enable_chrony: "no"enable_cinder: "yes"#enable_cinder_backend_hnas_iscsi: "no"#enable_cinder_backend_hnas_nfs: "no"#enable_cinder_backend_iscsi: "no"#enable_cinder_backend_lvm: "no"#enable_cinder_backend_nfs: "no"#enable_cloudkitty: "no"#enable_collectd: "no"#enable_congress: "no"#enable_designate: "no"#enable_destroy_images: "no"#enable_etcd: "no"enable_freezer: "yes"enable_gnocchi: "yes"#enable_grafana: "no"enable_heat: "yes"enable_horizon: "yes"#enable_horizon_cloudkitty: "{{ enable_cloudkitty | bool }}"enable_horizon_freezer: "{{ enable_freezer | bool }}"#enable_horizon_ironic: "{{ enable_ironic | bool }}"#enable_horizon_karbor: "{{ enable_karbor | bool }}"enable_horizon_magnum: "{{ enable_magnum | bool }}"#enable_horizon_manila: "{{ enable_manila | bool }}"#enable_horizon_mistral: "{{ enable_mistral | bool }}"#enable_horizon_murano: "{{ enable_murano | bool }}"enable_horizon_neutron_lbaas: "{{ enable_neutron_lbaas | bool }}"enable_horizon_sahara: "{{ enable_sahara | bool }}"#enable_horizon_searchlight: "{{ enable_searchlight | bool }}"#enable_horizon_senlin: "{{ enable_senlin | bool }}"#enable_horizon_solum: "{{ enable_solum | bool }}"#enable_horizon_tacker: "{{ enable_tacker | bool }}"#enable_horizon_trove: "{{ enable_trove | bool }}"#enable_horizon_watcher: "{{ enable_watcher | bool }}"#enable_influxdb: "no"#enable_ironic: "no"#enable_karbor: "no"#enable_kuryr: "no"enable_magnum: "yes"#enable_manila: "no"#enable_manila_backend_generic: "no"#enable_manila_backend_hnas: "no"#enable_mistral: "no"enable_mongodb: "yes"#enable_murano: "no"#enable_multipathd: "no"#enable_neutron_dvr: "yes"#enable_neutron_lbaas: "yes"#enable_neutron_fwaas: "yes"#enable_neutron_qos: "yes"#enable_neutron_agent_ha: "no"#enable_neutron_vpnaas: "yes"#enable_nova_serialconsole_proxy: "no"#enable_octavia: "no"#enable_panko: "no"#enable_rally: "no"enable_sahara: "yes"#enable_searchlight: "no"#enable_senlin: "no"#enable_solum: "no"#这个如果开启了enable_ceph_rgw_keystone, enable_swift必须为no，两者只能启用一个#enable_swift: "no"#enable_telegraf: "no"#enable_tacker: "no"#enable_tempest: "no"#enable_trove: "no"#enable_vmtp: "no"#enable_watcher: "yes"#################### Ceph options#################### Ceph can be setup with a caching to improve performance. To use the cache you# must provide separate disks than those for the OSDs#ceph_enable_cache: "no"# Valid options are [ forward, none, writeback ]#ceph_cache_mode: "writeback"# A requirement for using the erasure-coded pools is you must setup a cache tier# Valid options are [ erasure, replicated ]#ceph_pool_type: "replicated"# Integrate ceph rados object gateway with openstack keystone#和enable_swift两个只能选择一个为“yes”enable_ceph_rgw_keystone: "yes"############################### Keystone - Identity Options############################### Valid options are [ uuid, fernet ]#keystone_token_provider: 'uuid'# Interval to rotate fernet keys by (in seconds). Must be an interval of# 60(1 min), 120(2 min), 180(3 min), 240(4 min), 300(5 min), 360(6 min),# 600(10 min), 720(12 min), 900(15 min), 1200(20 min), 1800(30 min),# 3600(1 hour), 7200(2 hour), 10800(3 hour), 14400(4 hour), 21600(6 hour),# 28800(8 hour), 43200(12 hour), 86400(1 day), 604800(1 week).#fernet_token_expiry: 86400########################## Glance - Image Options########################## Configure image backend.# 此处我们选择glance后端为file，因为ceph作为后端的时候，只能使用raw的镜像glance_backend_file: "yes"glance_backend_ceph: "no"######################## Ceilometer options######################## Valid options are [ mongodb, mysql, gnocchi ]# 此时我们用gnocchi作为ceilometer的数据库，也可以选用mongodbceilometer_database_type: "gnocchi"# Valid options are [ mongodb, gnocchi, panko ]# 此时我们用gnocchi作为ceilometer的数据库，也可以选用mongodbceilometer_event_type: "gnocchi"######################## Barbican options######################## Valid options are [ simple_crypto, p11_crypto ]#barbican_crypto_plugin: "simple_crypto"#barbican_library_path: "/usr/lib/libCryptoki2_64.so"######################### Panko options######################## Valid options are [ mongodb, mysql ]#panko_database_type: "mysql"######################## Gnocchi options######################## Valid options are [ file, ceph ]#gnocchi_backend_storage: "{{ 'ceph' if enable_ceph|bool else 'file' }}"################################## Cinder - Block Storage Options################################## Enable / disable Cinder backends#用ceph作为cinder的后端存储cinder_backend_ceph: "{{ enable_ceph }}"#cinder_volume_group: "cinder-volumes"#cinder_backup_driver: "nfs"#cinder_backup_share: ""#cinder_backup_mount_options_nfs: ""######################## Designate options######################## Valid options are [ bind9 ]designate_backend: "bind9"designate_ns_record: "sample.openstack.org"########################## Nova - Compute Options##########################用ceph作为nova的后端存储nova_backend_ceph: "{{ enable_ceph }}"############################### Horizon - Dashboard Options###############################horizon_backend_database: "{{ enable_murano | bool }}"######################################## Manila - Shared File Systems Options######################################## HNAS backend configuration#hnas_ip:#hnas_user:#hnas_password:#hnas_evs_id:#hnas_evs_ip:#hnas_file_system_name:################################### Swift - Object Storage Options################################### Swift expects block devices to be available for storage. Two types of storage# are supported: 1 - storage device with a special partition name and filesystem# label, 2 - unpartitioned disk with a filesystem. The label of this filesystem# is used to detect the disk which Swift will be using.# Swift support two mathcing modes, valid options are [ prefix, strict ]#swift_devices_match_mode: "strict"# This parameter defines matching pattern: if "strict" mode was selected,# for swift_devices_match_mode then swift_device_name should specify the name of# the special swift partition for example: "KOLLA_SWIFT_DATA", if "prefix" mode was# selected then swift_devices_name should specify a pattern which would match to# filesystems' labels prepared for swift.#swift_devices_name: "KOLLA_SWIFT_DATA"################################################# Tempest - The OpenStack Integration Test Suite################################################# following value must be set when enable tempesttempest_image_id:tempest_flavor_ref_id:tempest_public_network_id:tempest_floating_network_name:# tempest_image_alt_id: "{{ tempest_image_id }}"# tempest_flavor_ref_alt_id: "{{ tempest_flavor_ref_id }}" ② 配置multinode文件，这个文件主要是指定物理节点的角色，供ansible使用：1[root@controller1 ~]# vim /home/inventory/multinode 给出如下样例：123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051# These initial groups are the only groups required to be modified. The# additional groups are for more control of the environment.[control]# These hostname must be resolvable from your deployment hostcontroller1controller2controller3# The above can also be specified as follows:#control[01:03] ansible_user=kolla# The network nodes are where your l3-agent and loadbalancers will run# This can be the same as a host in the control group[network]controller1controller2controller3[compute]compute1compute2compute3compute4compute5compute6compute7compute8compute9[monitoring]controller1# When compute nodes and control nodes use different interfaces,# you can specify "api_interface" and other interfaces like below:#compute01 neutron_external_interface=eth0 api_interface=em1 storage_interface=em1 tunnel_interface=em1[storage]controller1controller2controller3compute1compute2compute3compute4compute5compute6compute7compute8compute9# 以下剩余的部分不需要修改 ③ 为安装Ceph准备OSD节点，在所有的存储节点上执行如下命令，此次我们以有两块数据盘 sdb、sdc为例：格式化sdb数据盘：12345678[root@controller1 ~]# parted /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1[root@controller1 ~]# parted /dev/sdb printModel: VMware, VMware Virtual S (scsi)Disk /dev/sdb: 500GBSector size (logical/physical): 512B/512BPartition Table: gptNumber Start End Size File system Name Flags 1 1049kB 10.7GB 10.7GB KOLLA_CEPH_OSD_BOOTSTRAP 格式化sdc数据盘：12345678[root@controller1 ~]# parted /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1[root@controller1 ~]# parted /dev/sdc printModel: VMware, VMware Virtual S (scsi)Disk /dev/sdc: 500GBSector size (logical/physical): 512B/512BPartition Table: gptNumber Start End Size File system Name Flags 1 1049kB 10.7GB 10.7GB KOLLA_CEPH_OSD_BOOTSTRAP ④ 部署前检查，只需要在部署节点上执行如下命令：1[root@controller1 ~]# kolla-ansible prechecks -i /home/inventory/multinode 这时候，kolla会自动对配置文件，和当前机器的部署环境做检测，如果全是ok，那就可以开始部署，如果出现了fail可以根据相应的提示，查找问题并是修复，然后再检查一遍，如此循环，直到全部ok为止。预计执行大概需要半个小时，如果相看详细的输出日志，可以在命令后面加上-vvv。 ④ 开始部署，只需要在部署节点上执行如下命令：1[root@controller1 ~]# kolla-ansible deploy -i /home/inventory/multinode 这时候，kolla便开始自动从本地仓库中拉取相应的镜像，在/etc/kolla/目录下生成各个组件的配置文件，根据配置文件启动相应的组件的container并调用kolla_start脚本进行初始化，然后配置各个服务的endpoint地址，最终完成OpenStack的安装。首次执行需要拉取镜像，时间会比较长，以后每次重复执行不需要拉取镜像，大概运行时间为半个小时左右，如果想看详细的日志信息，可以在命令后面加上-vvv。 ⑤ 部署过程中如果遇到什么错误导致了fail，可以先看看输出信息，是否能够定位到具体的问题，如果可以则修复问题，如果没有什么头绪，可以直接重试运行上述命令，进行再次部署，基本可能会成功，如果问题重复出现，则需要好好看看输出日志，找找问题所在并修复。 ⑥ 成功部署后，可以通过如下命令查看是否所有的container都在正常运行：1[root@controller1 ~]# docker ps -a 如果都正常，可以在浏览器中输入你再globals.yml制定的kolla_internal_vip_address的IP地址来访问dashboard。用户名为：admin，登陆密码为你再passwords.yml中制定的keystone_admin_password字段的值。 ⑦ 如果想要增加组件，可以直接修改globals.yml文件中的配置项，然后运行④中的命令。 ⑧ 如果想要重新部署，可以使用如下命令清理环境，然后再次运行④中的命令：1[root@controller1 ~]# kolla-ansible destroy -i /home/inventory/multinode 会有一个提示你确认的过程，只需要按照它的提示，输入相应的命令选项确认即可。 Note:在执行destroy命令之前一定要确保，当前OpenStack平台上没有存储镜像，也没有相应的instance和volume,也没有swift的存储空间，总而言之，OpenStack上面除了配置选项外，不能存有任何额外的东西，否则会导致清理环境失败。这点一定要切记，很重要！！！如果使用的Ceph储存，还需要删除相应的挂在盘并重新打上OSD标签，此处以有sdb，sdc两块数据盘为例：1234567891011121314//查看当前[root@controller1 ~]# df -h....../dev/sdb1 495G 41M 495G 1% /var/lib/ceph/osd/40d7390c-43d5-48f9-ad94-9cd59393b111/dev/sdc1 495G 41M 495G 1% /var/lib/ceph/osd/2d4f594e-5212-4fcc-ada3-e9553f7c8050......//卸载这两块盘[root@controller1 ~]# umount /dev/sdb1[root@controller1 ~]# umount /dev/sdc1//重新为两块盘打上OSD标签[root@controller1 ~]# parted /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1[root@controller1 ~]# parted /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1 此时部署环境已经准备好，再次运行④中的命令，进行部署，非常方便。十、验证部署并初始化部署完成后，我们需要进行验证，会在/etc/kolla目录下生成admin-openrc.sh文件：1[root@controller1 ~]# kolla-ansible post-deploy 安装OpenStack的client端：1[root@controller1 ~]# pip install python-openstackclient 编辑初始化脚本文件/usr/share/kolla-ansible/init-runonce：12345[root@controller1 ~]# vim /usr/share/kolla-ansible/init-runonce// 修改一下部分EXT_NET_CIDR='192.168.12.0/24'EXT_NET_RANGE='start=192.168.12.30,end=192.168.12.40'EXT_NET_GATEWAY='192.168.12.1' Note:192.168.12.0只是一个示例网络，这个网络是给VM的floatingIP来用，就是我上面em2接的网络，这个网络需要可以通过路由器访问互联网，并且能够远程SSH。此处的IP地址请根据自己的实际情况修改。运行初始化脚本，进行初始化：123[root@controller1 ~]# source /etc/kolla/admin-openrc.sh[root@controller1 ~]# cd /usr/share/kolla-ansible[root@controller1 ~]# ./init-runonce Note:上面这个初试化过程中需要从http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img下载一个测试镜像，限于网络原因，有可能下载很慢或者下载失败，我们可以手动用下载工作下载好，放到/usr/share/目录下，这样，脚本就会检测到已经下载完成，不会再进行下载，直接上传。可以根据脚本最后运行完的提示运行如下命令，创建一个VM：123456openstack server create \ --image cirros \ --flavor m1.tiny \ --key-name mykey \ --nic net-id=2ba93782-71e2-44d6-ad64-796c5853dcce \ demo1 登陆dashboard，正常使用OpenStack。十一、附Docker常用命令：12345678910111213141516171819202122232425262728293031323334// 列出当前宿主机上已有的镜像[root@controller1 ~]# docker images// 在docker index中搜索image[root@controller1 ~]# docker search IMAGE_NAME// 从docker registry server 中下拉image或repository，只写名字为从官方hub拉取[root@controller1 ~]# docker pull [SERVICE_IP]:4000/mongo:latest// 推送一个image或repository到registry[root@controller1 ~]# docker push [SERVICE_IP]:4000/mongo:2014-10-27// 从image启动一个container[root@controller1 ~]# docker run [OPTIONS] IMAGE [COMMAND] [ARG...]// 将一个container固化为一个新的image[root@controller1 ~]# docker commit <container> [repo:tag]// 开启/停止/重启container（start/stop/restart）[root@controller1 ~]# docker start/stop/restart CONTAINER_ID// 查看image或container的底层信息（inspect）[root@controller1 ~]# docker inspect CONTAINER_ID// 删除一个或多个container[root@controller1 ~]# docker rm <container_id/contaner_name>// 删除所有停止的容器[root@controller1 ~]# docker rm $(docker ps -a -q)// 删除一个或多个image[root@controller1 ~]# docker rmi <image_id/image_name ...>// 查看容器的信息container[root@controller1 ~]# docker ps -a// 查看容器中正在运行的进程[root@controller1 ~]# docker top CONTAINER_ID// 查看容器的运行日志[root@controller1 ~]# docker logs CONTAINER_ID// 导出当前宿主机上已有的镜像[root@controller1 ~]# docker save -o NAME.tar IMAGE_NAEM:TAG// 导入已有的镜像tar包[root@controller1 ~]# docker Load -i NAME.tar// 以root权限登陆container内部[root@controller1 ~]# docker exec -it -u root CONTAINER_ID /bin/bash 十二、参考资料 Reference：官方文档：https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html Kolla安装Ocata 单节点：http://www.chenshake.com/kolla-installation/ OpenStack实战分享：Kolla多节点部署加Ceph后端：http://www.99cloud.net/html/2017/jiuzhouyuanchuang_0317/302.html Docker私有仓库Registry的搭建验证：http://www.cnblogs.com/lienhua34/p/4922130.html Jeffrey Zhang的blog：http://xcodest.me/ kolla的一点心得：http://blog.csdn.net/pengdake300/article/details/54581499]]></content>

</categories>

<tags>

<tag>Openstack</tag>

<tag>Kolla</tag>

</tags>

</entry>

<entry>

<url>%2F2017%2F05%2F24%2F%E4%BF%AE%E6%94%B9Sahara%E6%BA%90%E7%A0%81%E5%90%8E%E7%9A%84%E9%83%A8%E7%BD%B2%E9%97%AE%E9%A2%98%2F</url>

</categories>

<tags>

<tag>Openstack</tag>

<tag>Sahara</tag>

</tags>

</entry>

<entry>

<url>%2F2017%2F04%2F10%2FKolla%E9%83%A8%E7%BD%B2%E5%B7%A5%E5%85%B7%E7%AE%80%E4%BB%8B%2F</url>

</categories>

<tags>

<tag>Openstack</tag>

<tag>Kolla</tag>

</tags>

</entry>

<entry>

<url>%2F2017%2F04%2F09%2FDevstack%E9%83%A8%E7%BD%B2Openstack%E5%BC%80%E5%8F%91%E7%8E%AF%E5%A2%83%2F</url>

<content type="text"><![CDATA[Devstack 是面向 Openstack 开发者的快速自动化部署 Bash 脚本，提供了辅助开发和调试的源码环境，能够支持 All-In-One 和多节点部署模式，同时也支持 Plug-in 模式。Devstack 的使用可以说贯穿整个 Openstack 开发生涯，熟练的使用 Devstack 能有效提高开发效率。正如官方所强调的：Devstack不适合生产环境！支持的服务基础的操作系统 OpenStack技术委员会把现在的CI策略定义为支持最新的Ubuntu发行版和最新的RHEL发行版（为了测试Python2.6）。 Ubuntu: current 长期支持版(LTS release)加上现在的开发版 Fedora: 当前版本加上之前的版本 RHEL: 当前的主要发行版本其他OS平台可能继续支持，比如：Debian、OpenSUSE，但不是所有这些存在的平台都能得到支持 Ubuntu或是Fedora的补丁不会被支持，因为对其他的平台有副作用数据库 MySQL PostgreSQL 消息队列 Rabbit Qpid Web服务器 Apache Openstack网络默认使用Nova Network，可以选定使用Neutron Nova Network: FlatDHCP Neutron: 使用linuxbridge或是 OpenVSwitch的基本配置，接近于初始的FlatDHCP方式。 Openstack服务 DevStack中配置的默认服务有：认证（Keystone）对象存储（Swift）映像存储（Glance）块存储（Cinder）计算（Nova）控制面板（Horizon）编排（Heat）其他没有直接包含在DevStack中的附加服务可以通过插件机制绑定在stack.sh里面插件机制可以调用脚本来进行配置和启动相关服务节点配置单一节点多节点，但不是重点支持对象，核心团队并不定期测试多节点的配置，即使测试也只包含最小配置 Devstack 的安装与使用Devstack的安装过程比较简单，只需要从github库中git clone下来源码到本地，然后对本地做简单的配置即可。安装Linux本次使用的是Openstack官网推荐的Ubuntu16.04。由于Devstack自动部署过程中很多地方都需要用到git的相关命令，所以我们先为操作系统安装git：1# apt-get install git 添加stack用户Devstack必须运行在非root用户下，且该用户必须要sudo权限，本次为系统添加一个stack用户。1234#切换到root用户$ su#添加账户，并指定shell和home所在地# useradd -s /bin/bash/ -d /opt/stack -m stack 为刚添加的stack账户添加sudo权限12# tee <<< "stack ALL=(ALL) NOPASSWD:ALL" /etc/sudoers# su - stack 在Ubuntu中sudoers即使root用户默认也没有权限修改的，所以使用tee命令来写入，可以避免权限问题也可以直接找到/etc/shudoers这个文件，改变其读写权限，然后打开文件写入，当不推荐这样做下载Devstack 可以直接从github上下载最新版的额Devstack源码12$ git clone https://git.openstack.org/openstack-dev/devstack$ cd devstack Download 下来的源码中就包含安装Openstack的脚本和相应的配置模板，理论上，现在就可以运行stack.sh脚本来安装Openstack。但往往为了方便我们开发使用，及保证安装的成功率，我们会在local.conf文件中进行一些配置，覆盖掉其默认的配置后，再进行安装。开始安装下载完Devstack，并做好配置后，就可以开始安装Openstack了，只需要运行devstack/目录下的stack.sh脚本既可以全自动进行安装，这期间会遇到一些问题，需要一点点手动解决。所以安装时间的长短因人而异。1$ ./stack.sh 由于默认Devstack是从github直接拉取源码进行安装，所以需要一个好的网络环境才可以，如果不具备，则可以考虑换一个靠谱点的git库，比如：http://git.trystack.cn，这个git库测试性能良好。如果一切顺利的话，大概20-30分钟可以完全部署完。如果遇到错误，需要手动解决ERROR后重新跑脚本，这样安装时间可能是具体情况无限制的延长。 Devstack的配置过程Devstack一致致力于通过最少的配置完成最多的功能。因为各个项目加入了新的特性，新的项目加入，还有不同的组合需要测试，选项的数目已经飞速地膨胀了。DevStack的传统做法是从localrc文件得到所有的本地化的配置和定制信息。传递给各个项目的配置变量的数目也在增加。原有的机制 (EXTRAS_OPTS之类)需要对每个文件进行编码，已经不太适应现在的环境。在2013年10月引入了一个新的配置方式local.conf（参看https://review.openstack.org/#/c/46768/），希望能够简化配置过程，达到下列目的：在单一的文件中包含所有非默认的本地配置与 localrc 的方式向后兼容，保证迁移过程的平滑允许对任意配置文件中的设置进行更改现在 Devstack 提供了两种配置安装的方式 local.conf(新版) 和 localrc(旧版),，两种方式我们都应该有所了解，因为在不同的团队中会习惯的选择使用其中一种甚至两种方式。 local.conf local.conf文件的样例路径为：devstack/samples/local.conf 新的配置文件是local.conf，和旧的localrc文件在同一个目录。它是一个修正后的INI格式文件，引入了meta-section（[[<phase>|<config-file-name>]]）来承载额外的信息。改文件最终会被stack.sh脚本加载使用，所以其语法必须是符合Bash语法规则的，比如：等号“=”的两边不能存在空格。 Section（也就是<phase>）有以下几种类型：”local”、”post-config”、”extra”、”post-extra”。它们规定了Devstack的安装流程和配置，在安装过程中会严格按照这个顺序进行读取和执行： local：对应的Section为[[local|localrc]]，指定在local.conf被stackrc加载之前，先从localrc中提取配置项，配置实例如下： 12345[[local|localrc]]ADMIN_PASSWORD=nomoresecretDATABASE_PASSWORD=stackdbRABBIT_PASSWORD=stackqueueSERVICE_PASSWORD=$ADMIN_PASSWORD post-config：对应的Section为[[post-config|/$Q_PLUGIN_CONF_FILE]]，指定在项目服务自动配置完成后，且在服务正式启动之前，这其中的配置选项会被执行，配置实例如下： 123456789[[post-config|/$NOVA_CONF]][DEFAULT]use_syslog = True[osapi_v3]enabled = False# NOTE: Q_PLUGIN_CONF_FILE 独特之处在于它的配置项如果在前面不加 `/`，那么这个配置项就不会生效。所以为了使其生效添加 `/` 是必须的。 extra：指定在各Openstack项目的主服务启动之后，并且在extra.d中的文件别执行之前，extra的配置项会被执行 post-extra：指定在extra.d中的文件被执行之后，执行post-extra中的配置项。从以上可以看出，这么多的Section只是指定了其中的配置项在安装过程中的那个阶段被加载，一般情况下，我们只需要关注local这个Section即可，其他的稍作了解一下即可。 [[local|localrc]]是一个非常特别的Section，我们可以将配置项全部都定义到其下，并且它还指定了是否会将Devstack根目录下的localrc文件的配置项提取到其下，同时也允许所有的自定义安装配置项都包含在localrc文件中。这样做只是为了将Devstack的配置方式从localrc平滑过渡到local.conf，也就是说，可以将所有的安装配置项都定义到localrc，而无需修改local.conf文件。一个最小化安装Openstack的local.conf配置样例： 12345678[[local|localrc]]HOST_IP=192.168.0.2 ADMIN_PASSWORD=<YOUR_PASSWORD>DATABASE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORD#FIXED_RANGE=172.31.1.0/24#FLOATING_RANGE=192.168.20.0/25 在上面的配置中，主要做了两件事情，第一、在HOST_IP字段指定本机的IP，这个是为了方面后面建立Endpoint，即所有服务的API用到的IP。理论上，Devstack可以自动检测本机IP，但是这个功能不能特别完善，有时候会出错，所有建议手动指定；第二、指定了各项需要服务的密码，<YOUR_PASSWORD>字段换成你自己想用的密码即可。FIXED_RANGE和FLOATING_RANGE两个字段可以用来指定内网和公网IP地址的范围，此处被注释掉了，使用其默认的网络配置。 Devstack的部署流程及需要注意的问题Devstack的自动化部署流程大概包含以下几个主要步骤：加载配置文件local.conf和localrc(如果用到了的话) 安装依赖包，此时是从系统的软件库中拉取的依赖包，包括安装pip的过程安装消息队列和数据库安装Openstack Clients 安装并配置Openstack的各项服务，此时为从github库中直接拉取源码下载和上传镜像文件，从镜像的提供方官网下载的镜像显示登录信息，出现这个信息说明部署成功了其中下载依赖包，由于是从系统的软件库中直接边下载变安装的，所以建议提前对操作系统进行换源，以防以为网络问题导致安装失败。在Centos7和Ubuntu16.04两种操作系统上，经过测试阿里云源表现还是不错的： Centos7系统更换阿里云源： 123# cd /etc/yum.repos.d# cp CentOS-Base.repo CentOS-Base.repo.bak //备份原来的源# vim CentOS-Base.repo //打开源的文件，删除原有的源，写入新的源清空原本CentOS-Base.repo的内容，写入如下的内容： 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970# CentOS-Base.repo## The mirror system uses the connecting IP address of the client and the# update status of each mirror to pick mirrors that are updated to and# geographically close to the client. You should use this for CentOS updates# unless you are manually picking other mirrors.## If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead.##[base]name=CentOS-$releasever - Base - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/os/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/os/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=osgpgcheck=1gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7#released updates [updates]name=CentOS-$releasever - Updates - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/updates/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/updates/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updatesgpgcheck=1gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7[updates]name=CentOS-$releasever - Updates - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/updates/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/updates/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updatesgpgcheck=1gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7#additional packages that may be useful[extras]name=CentOS-$releasever - Extras - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/extras/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/extras/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extrasgpgcheck=1gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7#additional packages that extend functionality of existing packages[centosplus]name=CentOS-$releasever - Plus - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/centosplus/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/centosplus/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplusgpgcheck=1enabled=0gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7#contrib - packages by Centos Users[contrib]name=CentOS-$releasever - Contrib - mirrors.aliyun.comfailovermethod=prioritybaseurl=http://mirrors.aliyun.com/centos/$releasever/contrib/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/contrib/$basearch/#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contribgpgcheck=1enabled=0gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7 然后执行以下命令，确定阿里云源已经正常工作： 1# yum update //升级本系统的软件 Ubuntu16.04更换阿里云源： 123# cd /etc/apt/# cp sources.list sources.list.bak //备份原有的源# vim sources.list //打开源文件，清空原有的源，写入新的源清空sources.list中的原有内容，写入如下的内容： 123456789101112131415161718# deb cdrom:[Ubuntu 16.04 LTS _Xenial Xerus_ - Release amd64 (20160420.1)]/ xenial main restricteddeb-src http://archive.ubuntu.com/ubuntu xenial main restricted #Added by software-propertiesdeb http://mirrors.aliyun.com/ubuntu/ xenial main restricteddeb-src http://mirrors.aliyun.com/ubuntu/ xenial main restricted multiverse universe #Added by software-propertiesdeb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricteddeb-src http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted multiverse universe #Added by software-propertiesdeb http://mirrors.aliyun.com/ubuntu/ xenial universedeb http://mirrors.aliyun.com/ubuntu/ xenial-updates universedeb http://mirrors.aliyun.com/ubuntu/ xenial multiversedeb http://mirrors.aliyun.com/ubuntu/ xenial-updates multiversedeb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse #Added by software-propertiesdeb http://archive.canonical.com/ubuntu xenial partnerdeb-src http://archive.canonical.com/ubuntu xenial partnerdeb http://mirrors.aliyun.com/ubuntu/ xenial-security main restricteddeb-src http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted multiverse universe #Added by software-propertiesdeb http://mirrors.aliyun.com/ubuntu/ xenial-security universedeb http://mirrors.aliyun.com/ubuntu/ xenial-security multiverse 然后执行以下命令，确定阿里云源已经换源成功： 12# apt-get update# apt-get upgrade //升级本系统的软件不同版本的操作系统，对应的源的地址不同，此处只写出了centos7和ubuntu16.04的操作系统对应的阿里云源，其他版本系统的请自行网上搜索。安装pip过程中可能遇到的问题在安装pip的过程中，Devstack会从网上先下载一个get-pip.py的文件到devstack/files/文件夹下面，然后执行python get-pip.py运行这段程序来安装pip。所以当这个过程因为网络问题，导致get-pip.py不能够正常下载，导致安装失败的时候，我们可以手动下载get-pip.py文件，然后将其放入devstack/files/文件夹下面。除了上面的方法之外，我们也可以手动安装pip123> $ apt-get install python-pip //安装pip> $ pip install --upgrade pip //升级到最新版本> pip换源的问题由于Devstack部署过程中会用pip安装许多的软件包，而默认的pip的源的地址为https://pypi.python.org/simple这个地址在国内网络环境下访问不是很顺畅，时常出现下载包失败的情况，所以建议更换为国内源，此处换成了豆瓣源： 12$ sodu mkdir /root/.pip/ //新建一个.pip文件夹$ vim /root/.pip/pip.conf //在新建的文件夹下面新建pip.conf文件然后在pip.conf文件中写入以下内容： 12[global]index-url = https://pypi.douban.com/simple 此时即可换源成功。 pip安装软件包的问题如果换源后，pip中的某些软件包，仍然会从官方源下载，并且导致下载失败，可以手动停掉当然运行stack.sh脚本，把出错的安装命令复制一遍，手动指定安装源来进行安装，一般能够成功。命令格式为： 1$ pip install <YOUR_PACKAGES> -i https://pypi.doubanio.com/simple 这样该软件包就可以从我们指定的源地址进行下载安装。再部署过程中很多软件包pip自动安装失败，导致部署过程出错的问题，都可以通过手动指定软件源，手动安装，然后重新跑stack.sh来解决。另外，如果安装过程中出现如下错误： 1232016-04-10 08:40:55.596 | [ERROR] /home/devstack/functions-common:1066 Failed to update apt repos, we’re dead now2016-04-10 08:40:56.600 | Error on exit2016-04-10 08:40:56.601 | ./stack.sh: line 488: generate-subunit: command not found 可以通过运行如下三条命令来解决： 123sudo apt-get install python-pipsudo pip install --upgrade pipsudo pip install -U os-testr -i https://pypi.douban.com/simple 长时间卡在运行setup.py程序如果运行过程中，出现长时间卡在这一步的情况，基本可以手动Ctrl-C停掉部署过程，然后向上翻输出的部署过程，找到如下内容： 1sudo -H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt -e /opt/stack/keystone 复制这段文字，然后手动运行这段命令，运行过程中如果出现安装源的问题，就用上面的-i https://pypi.douban.com/simple来制定安装源，如果能正常下载安装，就让它继续安装就可以，另外，此过程中如果出现某一个软件包安装时间过程也可以按一下Crtl-C，会自动重新安装这个软件包。 Python虚拟环境搭建与使用 123$ pip install virtualenv #安装virtualenv工具$ virtualenv venvName # 创建名为venvName的虚拟环境$ source venvName/bin/activate # 进入虚拟环境在部署过程中，Devstack会搭建好几个虚拟环境，这些虚拟环境都可以用上面的第三条命令来手动进入。 Devstack 多节点部署Devstack大部分时候只是用来搭建一个all in one的开发测试环境，并不能够用于生产环境，但是作为一个部署工具，其本身也能够承担起多节点部署的任务。Devstack的多节点部署的本质就是：在不同的节点上，使用不同的local.conf配置文件来运行Devstack的部署脚本。但需要注意的是，Openstack的多节点部署不仅仅意味着不同的项目部署到不同的节点上，我们应该理解为，将Openstack不同的服务部署到不同的节点上，不同节点承担不同的功能。一般来说，很少有人用Devstack来进行多节点的部署，这里可以只做了解即可。 Controller节点的配置文件内容： 123456789101112131415161718192021222324252627# MiscADMIN_PASSWORD=<YOUR_PASSWORD>DATABASE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORDSERVICE_TOKEN=$ADMIN_PASSWORD# Target PathDEST=/opt/stack.mitaka# Enable LoggingLOGFILE=$DEST/logs/stack.sh.logVERBOSE=TrueLOG_COLOR=TrueSCREEN_LOGDIR=$DEST/logs# Current host ipHOST_IP=192.168.56.102FLAT_INTERFACE=eth1# 这个地方选择 True，开启多节点部署MULTI_HOST=True# 将应该部署到这个节点上的都 enable，部署到其他节点的都 disable# Enable/Disable Nova/Cinder ControllerNode serviceenable_service n-novnc n-cauthdisable_service n-cpu n-net n-api-meta c-vol computer节点的配置文件内容： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143# MiscADMIN_PASSWORD=<YOUR_PASSWORD>DATABASE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORDSERVICE_TOKEN=$ADMIN_PASSWORD# Target PathDEST=/opt/stack.mitaka# Enable LoggingLOGFILE=$DEST/logs/stack.sh.logVERBOSE=TrueLOG_COLOR=TrueSCREEN_LOGDIR=$DEST/logs# Current host ipHOST_IP=192.168.56.103FLAT_INTERFACE=eth1# Enable Nova/Cinder ComputeNode serviceenable_service n-novnc n-cauthENABLED_SERVICES=n-cpu,n-net,n-api-meta,c-vol# Needed by cinder-volume serviceDATABASE_TYPE=mysql# ControllerNode ipaddressSERVICE_HOST=192.168.56.102MYSQL_HOST=$SERVICE_HOSTRABBIT_HOST=$SERVICE_HOSTGLANCE_HOSTPORT=$SERVICE_HOST:9292NOVA_VNC_ENABLED=TrueNOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"VNCSERVER_LISTEN=$HOST_IPVNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN```bash### 附：本次部署过程中用到的`local.conf`文件本次部署过程中，我们开启了`Sahara`服务，`ceilometer`服务，`aodh`服务和`heat`服务，这几项服务Devstack部署过程中默认是不安装的，需要手动开启，另外还有一些其他的组件也可以在部署过程中开启。具体的方法，可以在Openstack官网相应组件的介绍的`xxx and devstack`页面下找到。`local.conf`文件内容：```bash[[local|localrc]]############################################################# Customize the following HOST_IP based on your installation############################################################HOST_IP=10.10.87.5#NEUTRON_CREATE_INITIAL_NETWORKS=FalseGIT_BASE=http://git.trystack.cnNOVNC_REPO=http://git.trystack.cn/kanaka/noVNC.gitSPICE_REPO=http://git.trystack.cn/git/spice/spice-html5.gitSERVICE_PASSWORD=123ADMIN_PASSWORD=123SERVICE_TOKEN=123IP_VERSION=4DATABASE_PASSWORD=123RABBIT_PASSWORD=123############################################################# Customize the following section based on your installation############################################################# Pip#PIP_USE_MIRRORS=False#USE_GET_PIP=1#OFFLINE=False#RECLONE=True#ENABLE_IDENTITY_V2=False# LoggingLOGFILE=$DEST/logs/stack.sh.logSCREEN_LOGDIR=$DEST/logs/screenVERBOSE=TrueENABLE_DEBUG_LOG_LEVEL=TrueENABLE_VERBOSE_LOG_LEVEL=True# Neutron ML2 with OpenVSwitch#Q_PLUGIN=ml2#Q_AGENT=openvswitch#Q_DVR_MODE=dvr_snat#enable_plugin gbp http://git.trystack.cn/openstack/group-based-policy master#enable_service neutron#enable_service q-svc#enable_service q-agt#enable_service q-meta#enable_service q-dhcp#enable_service q-l3#disable_service n-net#disable_service c-api cinder c-bak c-vol c-sch#disable_service tempest#disable_service heat h-api h-eng# Swift# -----# Swift is now used as the back-end for the S3-like object store. Setting the# hash value is required and you will be prompted for it if Swift is enabled# so just set it to something already:SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5# For development purposes the default of 3 replicas is usually not required.# Set this to 1 to save some resources:SWIFT_REPLICAS=1# The data for Swift is stored by default in (``$DEST/data/swift``),# or (``$DATA_DIR/swift``) if ``DATA_DIR`` has been set, and can be# moved by setting ``SWIFT_DATA_DIR``. The directory will be created# if it does not exist.SWIFT_DATA_DIR=$DEST/data# Enable saharaenable_plugin sahara http://git.trystack.cn/openstack/sahara# Enable sahara-dashboardenable_plugin sahara-dashboard http://git.trystack.cn/openstack/sahara-dashboard#Enable heat servicesenable_service h-eng h-api h-api-cfn h-api-cw#Enable heat pluginenable_plugin heat http://git.trystack.cn/openstack/heatIMAGE_URL_SITE="http://download.fedoraproject.org"IMAGE_URL_PATH="/pub/fedora/linux/releases/25/CloudImages/x86_64/images/"IMAGE_URL_FILE="Fedora-Cloud-Base-25-1.3.x86_64.qcow2"IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE#Enable ceilometer and aodh serviceCEILOMETER_BACKEND=mongodbenable_plugin ceilometer http://git.trystack.cn/openstack/ceilometerenable_plugin aodh http://git.trystack.cn/openstack/aodh#Enable OSprofiler serviceCEILOMETER_NOTIFICATION_TOPICS=notifications,profiler Reference Devstack官网 Devstack配置文件详解 Openstack 实现技术分解 (1) 开发环境 — Devstack 部署案例详解 Openstack 开发人员安装脚本解读 DevStack剖析（二）DevStack配置过程简述 Openstack部署工具总结——陈沙克日志 devstack安装和测试——陈沙克日志国内的Openstack的git库: http://git.trystack.cn/cgit 以上只是个人使用Devstack的一个学习过程的总结，其中难免有疏漏或者不当的地方，敬请指出！文中部分内容来源于网络，在此对于原作者表示感谢！]]></content>

</categories>

<tags>

<tag>Devstack</tag>

<tag>Openstack</tag>

</tags>

</entry>

<entry>

</categories>

<tags>

</tags>

</entry>

<entry>

<url>%2F2016%2F10%2F11%2FHBase-%E9%AB%98%E5%8F%AF%E7%94%A8%EF%BC%88HA%EF%BC%89%E9%9B%86%E7%BE%A4%E9%83%A8%E7%BD%B2%2F</url>

<content type="text"><![CDATA[本文主要介绍，在高可用（HA）Hadoop集群基础上搭建高可用（HA）的HBase集群。一、HBase 是什么HBase是一个分布式的、面向列的开源数据库，就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。它是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。 HBase有如下使用场景：大数据量（100s TB级数据）且有快速随机访问的需求。例如淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。容量的优雅扩展。大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）。优化方面：合理设计rowkey。因为hbase的查询用rowkey是最高效的，也几乎的唯一生产环境可行的方式。所以把你的查询请求转换为查询rowkey的请求吧。二、HBase 该可用集群架构由于我们是在已有的Hadoop可用集群基础上来搭建的，所以我们将HMaster分别部署在hadoop集群的master1和master2节点上，这样就能保证HBase的高可用性，放置单节点问题。将RegionServer部署在三个slaver节点上，分别是：slaver1、slaver2、slaver3。并且使用zookeeper做故障自动切换管理。二、HBase 部署首先从官网下载：hbase-1.2.3-bin.tar.gz，下载链接为：Click Me 。然后上传到master1这个节点上。 § 基础准备1、解压并重命名为hbase:123# tar -axvf hbase-1.2.3-bin.tar.gz -C /opt// 重命名# mv hbase-1.2.3 hbase 2、配置hbase的环境变量/etc/profile:123456789// 修改配置文件# sudo vi /etc/profile// 在最后下添加export HBASE_HOME=/opt/hbaseexport PATH=$PATH:$HBASE_HOME/bin// 刷新配置文件# source /etc/profile § 修改hadoop配置文件，共3个1、HBase的所有配置文件都放在/hbase/conf/目录下，修改hbase-env.sh，将文件中的export JAVA_HOME=${JAVA_HOME}写成我们自己jdk的绝对路径：1234567# The java implementation to use. Java 1.7+ required.export JAVA_HOME=/opt/jdk8# Tell HBase whether it should manage it's own instance of Zookeeper or not.export HBASE_MANAGES_ZK=true 2、修改hbase-site.xml文件，在中间加入如下内容： 1234567891011121314151617181920212223242526272829303132333435363738394041<configuration> <property>  <name>hbase.rootdir</name> <value>hdfs://ns1/hbase</value> </property> <property> <name>hbase.master</name>  <value>60000</value> </property> <property> <name>hbase.cluster.distributed</name> <value>true</value> </property> <property>  <name>hbase.zookeeper.quorum</name> <value>slaver1,slaver2,slaver3</value> <description>The directory shared by RegionServers.</description> </property> <property> <name>hbase.zookeeper.property.dataDir</name> <value>/opt/zookeeper/data</value> <description>Property from ZooKeeper config zoo.cfg. The directory where the snapshot is stored.</description> </property> <property> <name>hbase.zookeeper.property.clientPort</name> <value>2181</value> </property>  <property> <name>hbase.master.info.port</name> <value>16010</value> </property>  <property> <name>hbase.regionserver.info.port</name> <value>16030</value> </property></configuration> 3、修改regionservers文件，加入所有需要加入HBase集群中的从节点：12345slaver1slaver2slaver3~ ~ § 将配置好的文件分发到其余各个节点12345# cd /opt# scp -r ./hbase master2:/opt# scp -r ./hbase slaver1:/opt# scp -r ./hbase slaver2:/opt# scp -r ./hbase slaver3:/opt § 启动HBase集群在启动HBase之前，必须先启动zookeeper集群和hadoop集群。1、在master1上面，运行以下命令，如果没有配置好hbase的环境变量，可以到hbase/bin目录下执行 ./start-hbase.sh：1# start-hbase.sh 2、在master2上，单独启动一个HMaster进程：1# hbase-daemon.sh start master NOTE: 中间的start参数换成stop就成了停止指定进程的命令。 3、HBase集群停止命令，在master1上运行：1# stop-hbase.sh 4、验证已经正常启动：在各个节点运行jps命令可以看到一下进程，其中HMaster和HRegionServer为HBase的相关进程：12345678910111213141516171819202122232425262728293031323334353637// master1上运行的进程，前面的数字对应的进程的pid号3376 HMaster977 ResourceManager32756 DFSZKFailoverController3657 Jps522 NameNode// master2上运行的进程，前面的数字对应的进程的pid号30995 Jps28164 NameNode28502 ResourceManager30344 HMaster28059 DFSZKFailoverController// slaver1上运行的进程，前面的数字对应的进程的pid号13520 DataNode13367 JournalNode14488 HRegionServer13690 NodeManager14762 Jps4523 QuorumPeerMain// slaver2上运行的进程，前面的数字对应的进程的pid号21744 DataNode21591 JournalNode13450 QuorumPeerMain21915 NodeManager22972 Jps22686 HRegionServer// slaver3上运行的进程，前面的数字对应的进程的pid号22898 DataNode22744 JournalNode23848 HRegionServer24105 Jps17210 QuorumPeerMain23069 NodeManager 5、通过hadoop的web页面，查看是否异常，以及高可用是否正常运行：在浏览器中输入：http://master1:16010，其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master1换成相应的IP，显示如下：在浏览器中输入：http://master2:16010，其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master2换成相应的IP，显示如下：由以上两张图可以看出，目前master1处于active状态，master2处于standby状态，说明HBase的HA已成功建立。三、总结总的来说，HBase高可用集群的搭建还是相当的简单的。但有时候需要注意一下这个问题：如果HBase启动过程中显示不能够正常搜索HDFS的namespace或者不能解析HDFS路径，可以将/opt/hadoop/etc/hadoop下的core-site.xml 和hdfs-site.xml拷到/opt/hbase/conf/下，一般可以解决问题。]]></content>

</categories>

<tags>

<tag>HBase</tag>

<tag>Hadoop</tag>

</tags>

</entry>

<entry>

<url>%2F2016%2F10%2F10%2FHadoop-2-7-3-%E9%AB%98%E5%8F%AF%E7%94%A8%EF%BC%88HA%EF%BC%89%E9%9B%86%E7%BE%A4%E9%83%A8%E7%BD%B2%2F</url>

<content type="text"><![CDATA[本文主要介绍如何搭建HDFS（NameNode）和ResourceManager高可用的Hadoop集群。 HDFS的高可用（HA）的实现方式：一种是将NN维护的元数据保存一份到NFS上，当NN故障，可以通过另一台NNe读取NFS目录中的元数据备份进行恢复工作，需要手动进行操作，并不是真正意义上的HA方案。另一种是准备一台备用NN节点，通过定期下载NN的元数据和日志文件来备份，当NN故障时，可以通过这台进行恢复，由于主备节点元数据和日志并不是实时同步，所以会丢失一些数据。前两种方案都不是很理想，社区提供一种更好的方案，基于QJM（Qurom Journal Manager）的共享日志方案。QJM的基本原理是NN（Active）把日志写本地和2N+1（奇数）台JournalNode上，当数据操作返回成功时才写入日志，这个日志叫做editlog，而元数据存在fsimage文件中，NN（Standby）定期从JournalNode上读取editlog到本地。在这手动切换的基础上又开发了基于Zookeeper的ZKFC（ZookeeperFailover Controller）自动切换机制，Active和Standby节点各有ZKFC进程监控NN监控状况，定期发送心跳，当Active节点故障时Standby会自动切换为ActiveNode，本次就用的此方案。如下图所示： ResourceManager(RM) HA实现方式： RM将状态信息存储在Zookeeper中，当Active故障，Standby切换为Active后，从ZK读取相应的作业信息，重新构建作业的内存信息，然后开始接受NodeManager心跳，并接受客户端提交作业的请求等。一、部署前的准备工作 OpenStack 平台，构建虚拟机，也可用VMWare代替 Centos7 x64 操作系统 Hadoop 2.7.3 64位安装包（bin版） Zookeeper 3.4.9 安装包（bin版） Apache 镜像下载地址：http://www.apache.org/dist/Hadoop官方文档：Hadoop Document 二、集群规划主机名 IP 安装的软件运行的进程 master1 172.16.1.33 hadoop NameNode(active)、DFSZKFailoverController、ResourceManager(active) master2 172.16.1.35 hadoop NameNode(Standby)、DFSZKFailoverController、ResourceManager(Standby) slaver1 172.16.1.22 hadoop、zookeeper DataNode、NodeManager、QuorumPeerMain、JournalNode slaver2 172.16.1.23 hadoop、zookeeper DataNode、NodeManager、QuorumPeerMain、JournalNode slaver3 172.16.1.24 hadoop、zookeeper DataNode、NodeManager、QuorumPeerMain、JournalNode Note：如果节点资源足够多，也可以吧ResourceManager单独安装在两个节点上，这样更符合HA的特性除了必须有两个NameNode之外，DataNode的节点可以尽可能的多，配置方式一样三、基础环境配置§ 更改主机名，并建立主机名与IP的映射关系（每个节点都要做）1、临时更改主机名，机器重启后失效，以master1为例，其余每个节点同样设置： 123# hostname master1# hostnamemaster1 2、永久修改主机名修改centos网络配置文件/etc/sysconfig/network，在末尾添加HOSTNAME=master1:123456# vim /etc/sysconfig/networkNETWORKING=yesNOZEROCONF=yesHOSTNAME=master1~ ~ 3、修改/etc/hosts文件，最终状态，节点中的每台主机都要修改好相应的主机名，并在hosts文件中写入相应的IP 和主机名的映射关系，状态如下所示：12345678910# vim /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6172.16.1.33 master1172.16.1.35 master2172.16.1.22 slaver1172.16.1.23 slaver2172.16.1.24 slaver3~ ~ 这样是永久修改，重启后生效，也可以结合第一种方法，让该用户名立即生效。 NOTE: 在/etc/下有一个hostname文件，如果是Ubuntu系统可以直接在这个文件下面写入想要设置的主机名来达到永久修改主机名。经过验证，openstack生成的虚拟机中，hostname会写有一个类似于test.novalocal的以*.novalocal结尾的主机名，如果按照方法2修改主机名，每次重启后，会自动把主机名设成这个名字，而不能如愿更改为我们想要的主机名，即使在hostname文件中，删掉原有主机名，写上我们想要设置的主机名，重启后以后会还原为删掉之前的样子。所以，在本次配置中，我们使用方法1来临时修改主机名，尽量不重启机器，如果需要重启机器，重启后重新修改主机名，以防Hadoop不能正常启动。 4、如果机器的时间差相差太大容易导致启动失败，所以提前进行时间同步：12# yum install ntp# ntpdate ntp.fudam.edu.cn § 关闭防火墙（每个节点都要配置）如果是生产环境中可以通过配置iptables规则来开放端口，此处我们作为实验且私网环境直接关闭放火墙来达到目的：1234// 关闭防火墙# sudo systemctl stop firewalld.service // 关闭开机启动# sudo systemctl disable firewalld.service § 创建专门的用户（每个节点都要配置）在安装完Centos7后，如果在真实的生产环境中，最好建立一个新的用户和组，专门用来安装Hadoop。1、在root下，创建组和用户，为每一台虚拟机创建一个Hadoop用户123456// 先创建组cloud# groupadd cloud// 创建用户并加入组clouduseradd -g cloud hadoop// 修改用户hadoop的密码# passwd hadoop 2、将hadoop用户加到soduers列表，获取root权限1234567891011121314// 查看/etc/sudoers的权限# ls -l /etc/sudoers// 修改权限为 777# chmod 777 /etc/sudoers// 将hadoop添加root权限# vim /etc/sudoers## The COMMANDS section may have other options added to it.#### Allow root to run any commands anywhere root ALL=(ALL) ALLhadoop ALL=(ALL) ALL// 还原权限# chmod 440 /etc/sudoers 其他节点的机器同样操作。 NOTE: 本次部署，我们直接用的root用户，而没有新建hadoop用户和cloud组相比于一台一台的修改配置文件，可以先在一台上面修改，然后用scp命令分发到其余各个节点的相应位置 § 配置ssh免密登录（每个节点都要配置）hadoop在使用过程中需要分发好多文件，配置好免密登录可以免去我们要不断地输入密码的麻烦。也有助于我们部署过程中把自己修改的配置文件分发到各个节点。 1、生成公钥和私钥，过程中会有一些提示选项，直接按回车，采用默认值便好 # ssh-keygen -t rsa 2、执行完上面的命令后，会生成两个文件id_rsa（私钥）、id_rsa.pub（公钥），将公钥拷贝到要免登陆的机器上： # ssh-copy-id 172.16.1.33 # ssh-copy-id 172.16.1.35 # ssh-copy-id 172.16.1.22 # ssh-copy-id 172.16.1.23 # ssh-copy-id 172.16.1.24 3、这时会在相应的主机的~/.ssh/下产生一个名为authorized_keys的文件，这时通过 ssh 172.16.1.35(修改为相应的主机对应的IP) 时可以直接免密登陆进入主机。4、其他的每一个节点同样操作。 NOTE: 也可以选择先在每一个节点上生成相应的私钥和公钥，然后把公钥通过用scp命令发送到一台机器上，比如master1，然后统一一块加入到这台机器~/.ssh/authorized_keys文件里面然后把这个文件用scp分发到每一台机器的~/.ssh/文件夹中这样就实现了集群中每一个节点的相互免密登录，而且，省去了每个节点都要手动配置的麻烦四、安装JDK（每个节点都要配置）本次是用的是 jdk-8u101-linux-x64.tar.gz ，可以从Oracle官网下载，然后传送到每一台机器上，并解压，解压的路径可以自由选择，本次选择/opt/。123# tar -zxvf jdk-8u101-linux-x64.tar.gz -C /opt// 修改文件夹名字# # mv /opt/jdk1.8.0_101 /opt/jdk8 配置环境变量： 12345678910// 修改配置文件# sudo vim /etc/profile // 在最后下添加export JAVA_HOME=/opt/jdk8export PATH=$JAVA_HOME/bin:$PATHexport CLASSPATH=.:$JAVA_HOME/lib // 刷新配置文件# source /etc/profile 其他每台机器都做同样的配置，或者将这个配好的jdk和profile文件用scp命令分发到每一台机器上。 NOTE: jdk的安装目录尽量不要选在普通用户的/home/USER_NAME家目录下，因为在后面hadoop配置中需要用到这个jdk的目录的绝对路径，如果写到/home/USER_NAME这个里面，其中的/USER_NAME会根据分发到各节点的用户名不同而不同，所以要在hadoop中重新配置这个JAVA_HOME的绝对路径，否则会导致启动失败。五、安装zookeeper（所有的slaver节点都要安装）在slaver1、slaver2、slaver3上安装zookeeper。1、从Apache官网下载zookeeper-3.4.9.tar.gz，并上传到以上三台节点的任意一台上面，然后解压到/opt：123# tar -zxvf zookeeper-3.4.8.tar.gz -C /opt// 重命名文件夹# mv zookeeper-3.4.8 zookeeper 2、修改zookeeper的默认配置文件./zookeeper/conf/zoo.cfg：12# mv zoo_sample.cfg zoo.cfg# vim zoo.cfg 3、在打开的文件中修改或添加一下内容：修改dataDir指向我们数据文件夹，默认没有这个文件夹，需要后面的步骤创建:12dataDir=/opt/zookeeper/datadataLogDir=/opt/zookeeper/logs 并在最后添加：123server.1=slaver1:2888:3888server.2=slaver2:2888:3888server.3=slaver3:2888:3888 NOTE: 此文件中的部分参数说明： tickTime：ZK服务器之间或客户端与服务器之间间隔多长时间发送一个心跳，单位毫秒 initLimit：ZK服务器集群中连接Leader的Follower服务器初始化连接时最长忍受多长心跳时间间隔（5*20000=10s） syncLimit：标识Leader与Follower同步消息，如果超过时间（5*2000=10s），未完成同步，将剔除这个节点，所有连接此> > - Follower服务器的客户端将连接到另一个Foolower服务器上 dataDir：ZK保存数据的目录，默认情况下，ZK也会将日志文件保存在此目录 dataLogDir：指定日志文件目录 clientPort：客户端连接ZK服务器端口 server.1：第一个1代表第几号ZK服务器，slaver1是这个服务器的主机名或IP，2888是这个ZK服务器与集群中Leader服务器交换信息的端口，3888是Leader服务器出现故障时，用这个端口通信重新选举，在选出一个新的Leader 4、创建相应的目录和myid文件，其中，这个myid文件必须创建，否则启动会报错。分别在ZK集群节点创建myid号，myid一定对应好zoo.cfg中配置的server后面1、2、3这个ZK号，即本次部署过程中，myid文件的内容在slaver1上为1、在slaver2上为2、在slaver3上为3：1234# mkdir /opt/zookeeper/data# mkdir /opt/zookeeper/logs# vim /opt/zookeeper/data/myid 1 NOTE: 上面的这个/opt/zookeeper/data等文件夹也可以换到别的目录创建，不一定非得在代码所在目录下，只需要在上面那个zoo.cfg指定即可。比如/home/zookeeper/data。同理logs文件夹也是。 5、分别启动所有的ZK节点（在所有的slaver上操作）1/opt/zookeeper/bin/zkServer.sh start NOTE: ZK的每次启动都得单独一台一台的启动，不能够通过hadoop来统一管理启动！ 6、检查启动是否成功，在三台slaver上运行下面的命令，就能找到唯一的一个leader和剩余的全是follower: # /opt/zookeeper/bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /opt/zookeeper/bin/../conf/zoo.cfg Mode: follower 运行jps来查看相应的java进程，能够看到： # jps 4523 QuorumPeerMain 11503 Jps 以上说明zookeeper已经成功安装并启动。 7、zookeeper停止命令： /opt/zookeeper/bin/zkServer.sh stop 需要在每一个需要停止zookeeper的节点上运行。 NOTE: 如果我们就找到leader那台机器，然后运行上面的命令停掉ZK，或者jps查到QuorumPeerMain的pid号，然后用kill命令 8、设置zookeeper的环境变量，在/etc/profile文件末尾添加如下内容：123456# vim /etc/profileexport ZOOKEEPER_HOME=/opt/zookeeperexport PATH=$ZOOKEEPER_HOME/bin:$PATH# source /etc/profile NOTE: 如果提前在/etc/profile文件中写入export的zookeeper的环境变量，便可以不用每次执行命令都先cd到相应的文件夹下，下面部署过程中配置环境变量也是同样的道理。六、安装hadoop（所有的节点都要安装）先从官网下载hadoop-2.7.3.tar.gz，上传到master1这台机器上。先在master1上解压，配置，然后用scp命令分发到其余各个节点即可。 § 解压hadoop并配置环境变量1、将上传来的hadoop解压到/opt文件夹下，并重命名为hadoop：12# tar -zxvf hadoop-2.7.3.tar.gz -C /opt# mv hadoop-2.7.3 hadoop 2、配置环境变量，以便能够在任何位置使用hadoop的相关命令：1# vim /etc/profile 在末尾添加以下内容：1234export HADOOP_HOME=/opt/hadoopexport PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATHexport HADOOP_LOG_DIR=/home/hadoop/logsexport YARN_LOG_DIR=$HADOOP_LOG_DIR 让配置文件生效：1# source /etc/profile 3、测试：12# which hadoop/opt/hadoop/bin/hadoop § 建立hadoop的工作目录结构本次选择在/home目录下建立hadoop的工作目录。目录结构为：1234567/home/hadoop/home/hadoop/tmp/home/hadoop/logs/home/hadoop/hdfs/home/hadoop/journal/home/hadoop/hdfs/datanode/home/hadoop/hdfs/namenode § 修改hadoop配置文件，共7个所有的配置文件都在hadoop根目录下hadoop/etc/hadoop文件夹下面，所以要先cd到这个目录下。 1、配置hadoop-env.sh，将文件中的export JAVA_HOME=${JAVA_HOME}写成我们自己jdk的绝对路径：12# The java implementation to use.export JAVA_HOME=/opt/jdk8 2、修改yarn_env.sh，将其中的export JAVA_HOME=${JAVA_HOME}写成自己的jdk的绝对路径：12# some Java parametersexport JAVA_HOME=/opt/jdk8 3、修改core-site.xml，在<configuration></configuration>中间加入如下内容：1234567891011121314151617<configuration>  <property> <name>fs.defaultFS</name> <value>hdfs://ns1</value> </property>  <property> <name>hadoop.tmp.dir</name> <value>file:/home/hadoop/tmp</value> </property>r <property> <name>ha.zookeeper.quorum</name> <value>slaver1:2181,slaver2:2181,slaver3:2181</value> </property></configuration> 4、修改hdfs-site.xml，注意，在这个文件中有关于journalnode的配置信息，我们一般把journalnode部署到slaver节点上，并且只能为奇数，至少为3台（也可以是5、7、9等台数），在<configuration></configuration>中间加入如下内容：123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596<configuration>  <property> <name>dfs.nameservices</name> <value>ns1</value> </property>  <property> <name>dfs.ha.namenodes.ns1</name> <value>nn1,nn2</value> </property>  <property> <name>dfs.datanode.data.dir</name> <value>/home/hadoop/hdfs/datanode</value> <final>true</final> </property>  <property> <name>dfs.namenode.name.dir</name> <value>/home/hadoop/hdfs/namenode</value> <final>true</final> </property>  <property> <name>dfs.namenode.rpc-address.ns1.nn1</name> <value>master1:8020</value> </property>  <property> <name>dfs.namenode.http-address.ns1.nn1</name> <value>master1:50070</value> </property>  <property> <name>dfs.namenode.rpc-address.ns1.nn2</name> <value>master2:8020</value> </property>  <property> <name>dfs.namenode.http-address.ns1.nn2</name> <value>master2:50070</value> </property>  <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://slaver1:8485;slaver2:8485;slaver3:8485/ns1</value> </property>  <property> <name>dfs.journalnode.edits.dir</name> <value>/home/hadoop/journal/</value> </property>  <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property>  <property> <name>dfs.client.failover.proxy.provider.ns1</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property>  <property> <name>dfs.ha.fencing.methods</name> <value> sshfence(hdfs) shell(/bin/true) </value> </property>  <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/root/.ssh/id_rsa</value> </property>  <property> <name>dfs.ha.fencing.ssh.connect-timeout</name> <value>30000</value> </property></configuration> 5、修改mapred-site.xml，首先需要将文件夹中的mapred-site.xml.template复制并重命名为mapred-site.xml:1# cp mapred-site.xml.template mapred-site.xml 在<configuration></configuration>中间加入如下内容：1234567891011121314151617<configuration> <property>  <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property>  <name>mapreduce.jobhistory.address</name> <value>0.0.0.0:10020</value> </property> <property>  <name>mapreduce.jobhistory.webapp.address</name> <value>0.0.0.0:19888</value> </property></configuration> 6、修改yarn-site.xml，在<configuration></configuration>中间加入如下内容：12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697<configuration>  <property> <name>yarn.resourcemanager.ha.enabled</name> <value>true</value> </property>  <property> <name>yarn.resourcemanager.cluster-id</name> <value>rm-cluster</value> </property> <property>  <name>yarn.resourcemanager.ha.rm-ids</name> <value>rm1,rm2</value> </property>  <property> <name>yarn.resourcemanager.ha.automatic-failover.recover.enabled</name> <value>true</value> </property>   <property> <name>yarn.resourcemanager.hostname.rm1</name> <value>master1</value> </property>  <property> <name>yarn.resourcemanager.hostname.rm2</name> <value>master2</value> </property>  <property> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value> </property>  <property> <name>yarn.resourcemanager.zk-address</name> <value>slaver1:2181,slaver2:2181,slaver3:2181</value> </property>  <property> <name>yarn.resourcemanager.scheduler.address.rm1</name> <value>master1:8030</value> </property> <property> <name>yarn.resourcemanager.scheduler.address.rm2</name> <value>master2:8030</value> </property>  <property> <name>yarn.resourcemanager.resource-tracker.address.rm1</name> <value>master1:8031</value> </property> <property> <name>yarn.resourcemanager.resource-tracker.address.rm2</name> <value>master2:8031</value> </property>  <property> <name>yarn.resourcemanager.address.rm1</name> <value>master1:8032</value> </property> <property> <name>yarn.resourcemanager.address.rm2</name> <value>master2:8032</value> </property>  <property> <name>yarn.resourcemanager.admin.address.rm1</name> <value>master1:8033</value> </property> <property> <name>yarn.resourcemanager.admin.address.rm2</name> <value>master2:8033</value> </property>  <property> <name>yarn.resourcemanager.webapp.address.rm1</name> <value>master1:8088</value> </property> <property> <name>yarn.resourcemanager.webapp.address.rm2</name> <value>master2:8088</value> </property>  <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration> 7、修改slaves文件，这个文件中是写入希望成为datanode节点的机器的主机名：12345# vim slavesslaver1slaver2slaver3 § 将配置好的hadoop拷贝到其他主机1、用scp命令向其他主机分发配置好的hadoop文件：12345# cd /opt# scp -r ./hadoop master2:/opt# scp -r ./hadoop slaver1:/opt# scp -r ./hadoop slaver2:/opt# scp -r ./hadoop slaver3:/opt 2、用scp命令向其他主机分发配置好的/etc/profile文件：1234# scp /etc/profile master2:/etc# scp /etc/profile slaver1:/etc# scp /etc/profile slaver2:/etc# scp /etc/profile slaver3:/etc NOTE: 此次分发会把三台slaver上的关于zookeeper的环境变量给覆盖掉，请重新配置。如果不想重新配置zookeeper的环境变量，也可以手动复制hadoop的环境变量到每台机器上/etc/profile文件末尾，分别配置每台机器上的中hadoop的环境变量。 3、在每台主机上更新环境变量，使其生效：1# source /etc/profile 七、启动hadoop集群启动hadoop的高可用集群的时候，有启动顺序的限制： 1、在三台slaver节点上，分别启动zookeeper，前面已经做过，只需检查下QuorumPeerMain进程还在即可：123# jps21273 Jps13450 QuorumPeerMain 2、在三台slaver节点上，分别启动journalnode进程，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下./hadoop-daemon.sh start journalnode：1# hadoop-daemon.sh start journalnode NOTE: 中间的start参数换成stop就成了停止指定进程的命令。 3、第一次运行要对HDFS(namenode)进行格式化，在master1上执行以下命令，如果没有配置好hadoop的环境变量，可以到hadoop目录下的bin目录下执行./hdfs namenode –format：12# hdfs namenode -format# hadoop-daemon.sh start namenode NOTE: 格式化第二次有可能会造成DataNode无法启动，原因是NameSpaceID不一致造成，解决方法是找出dafs/datanode目录下不一致的VERSION修改NameSpaceID，也可以尝试删除hdfs/datanode目录，重新格式化。 4、在master2使用以下命令，把master2节点的目录格式化并同步两个master节点的元数据，这个命令不会把journalnode目录再格式化了：12# hdfs namenode -bootstrapStandby# hadoop-daemon.sh start namenode NOTE: 也可以在master2上重复上一条命令，重新格式化NameNode。 5、在master1上，执行以下命令格式化ZK，如果没有配置好hadoop的环境变量，可以到hadoop目录下的bin目录下执行./hdfs zkfc –formatZK：1# hdfs zkfc -formatZK 6、在master1和master2上，分别启动ZKFC来监控NameNode的状态，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./hadoop-daemon.sh start zkfc：1# hadoop-daemon.sh start zkfc NOTE: 中间的start参数换成stop就成了停止指定进程的命令。 7、在master1上，启动HDFS(NameNode)，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./start-dfs.sh：1# start-dfs.sh 8、在master1上，启动YARN( ResourceManager)，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./start-yarn.sh：1# start-yarn.sh 9、在master2上启动YARN( ResourceManager)，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./yarn-daemon.sh start resourcemanager：1# yarn-daemon.sh start resourcemanager NOTE: 中间的start参数换成stop就成了停止指定进程的命令。 10、如果在master2上NameNode没有正常启动，可以通过以下命令手动启动，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./yarn-daemon.sh start resourcemanager：1# hadoop-daemon.sh start namenode NOTE: 中间的start参数换成stop就成了停止指定进程的命令。 11、验证hadoop集群（HDFS和YARN）是否正常启动，可以通过jps命令，查看各节点运行的java进程：1234567891011121314151617181920212223242526272829303132// master1上运行的进程，前面的数字对应的进程的pid号977 ResourceManager32756 DFSZKFailoverController1364 Jps522 NameNode// master2上运行的进程，前面的数字对应的进程的pid号28164 NameNode28502 ResourceManager28633 Jps28059 DFSZKFailoverController// slaver1上运行的进程，前面的数字对应的进程的pid号13520 DataNode13876 Jps13367 JournalNode13690 NodeManager4523 QuorumPeerMain// slaver2上运行的进程，前面的数字对应的进程的pid号21744 DataNode22101 Jps21591 JournalNode13450 QuorumPeerMain21915 NodeManager// slaver3上运行的进程，前面的数字对应的进程的pid号22898 DataNode23253 Jps22744 JournalNode17210 QuorumPeerMain23069 NodeManager 12、通过hadoop的web页面，查看是否异常，以及高可用是否正常运行：在浏览器中输入：http://master1:50070 其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master1换成相应的IP，显示如下：在浏览器中输入：http://master2:50070 其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master2换成相应的IP，显示如下：由以上两个图可以看出，master1出于active状态，master2处于standby状态，说明HDFS的HA已成功建立。在浏览器中输入：http://master1:8088/cluster/cluster 其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master1换成相应的IP，显示如下：在浏览器中输入：http://master2:8088/cluster/cluster 其中如果本地hosts中没有建立相应的主机名与IP的映射关系，将master2换成相应的IP，显示如下：由以上两个图可以看出，master1出于active状态，master2处于standby状态，说明ResourceManager的HA也已成功建立。 NOTE: 如果是在Openstack虚拟机上搭建的hadoop，那么使用对应主机的IP的时候，要用每台主机对应的floating ip，而不是openstack的内部私网IP，比如开始的172.16.1.33，就是openstack内部的私网IP。可以通过kill命令后面跟相应进程的pid号来停掉active节点的相应进程，模拟故障状态，观察HA的迁移，但注意关掉后，再单独启动起来。 13、停止hadoop集群，可以通过执行以下命令来停止hadoop集群，如果没有配置好hadoop的环境变量，可以到hadoop目录下的sbin目录下执行./stop-all.sh：1# stop-all.sh NOTE: 这种方法并不能够停掉zookeeper相关进程和master2上单独启动的ResourceManager进程，如有必要，这些需要另外手动停掉。八、总结Hadoop的高可用集群部署并不是特别困难，但是配置内容比单NameNode节点的要多的多，且比较复杂，应当细心。另外，最好多了解下这些配置文件里面各个项所表示的含义，比较好的方法是仔细研读一下相应版本的官方文档，也方便对相应细节做出优化。九、附：HDFS操作命令1234567891011121314151617181920// 查看DataNode节点信息，可以使用这个命令脚本监控DFS状况# hadoop dfsadmin -report // 指定HDFS地址访问# hadoop fs -ls hdfs://hcluster:9000/ // 列出HDFS文件系统目录下文件和目录# hadoop fs -ls / // 递归列出目录# hadoop fs -lsr / // 创建test目录# hadoop fs -mkdir /test // 上传文件到test目录# hadoop fs -put /root/test.txt /test/test.txt // 查看文件内容# hadoop fs -cat /test/test.txt // 查看文件大小# hadoop fs -du /test/test.txt // 删除文件 # hadoop fs -rm /test/test.txt // 递归删除目录或文件# hadoop fs -rmr /test]]></content>

</categories>

<tags>

<tag>Hadoop</tag>

</tags>

</entry>

<entry>

<url>%2F2016%2F06%2F11%2FCloud-Foundry-%E9%83%A8%E7%BD%B2%E5%BA%94%E7%94%A8%E7%9A%84%E8%BF%87%E7%A8%8B%E5%8F%8A%E9%97%AE%E9%A2%98%2F</url>

<content type="text"><![CDATA[一、Cloud Foundry 简介Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题。同时，它本身是一个基于Ruby on Rails的由多个相对独立的子系统通过消息机制组成的分布式系统，使平台在各层级都可水平扩展，既能在大型数据中心里运行，也能运行在一台桌面电脑中，二者使用相同的代码库。作为新一代云应用平台，Cloud Foundry专为私有云计算环境、企业级数据中心和公有云服务提供商所打造。Cloud Foundry云平台可以简化现代应用程序的开发、交付和运行过程，在面对多种公有云和私有云选择、符合业界标准的高效开发框架以及应用基础设施服务时，可以显著提高开发者在云环境中部署和运行应用程序的能力。二、自定义buildpack包§ Buildpack包的简介CF默认集成的buildpack包： Name Supported Languages and Frameorks GitHub Repo Java Grails, Play, Spring, or any other JVM-based language or framework Java Source Ruby JRuby, Rack, Rails, or Sinatra Ruby source Node.js Node or JavaScript Node.js source Binary N/A Binary source Go N/A Go source PHP Cake, Symfony, Zend, Nginx, or HTTPD PHP source Python Django or Flask Python source Staticfile HTML, CSS, JavaScript, or Nginx Staticfile source 这只是CF默认自带的几种，理论上，只要能做出buildpack包，任何语言都可以正常在CF上运行。 More Buildpacks： Cloud Foundry Community Buildpack Heroku Third-Party Buildpack Create your own buildpack: Custom Buildpack 一般buildpack包只包含的基础环境和简单的脚本设置，在使用的时候才会根据设置，从网上的源自己获取相应的 dependencies ，但大部分的源，国内访问都不是很方便，经常会出现无法下载相应的 dependencies 而导致 staging 失败。所以，国内想正常使用CF基本需要 offline 的 buildpack 包，而目前网络上提供的纯 offline 的 buildpack 比较少。 For more information about custom buildpacks: Custom Buildpacks Packaging Dependencies for Offline Buildpacks Supported Binary Dependencies 就目前我们所能找到的 buildpack 包来看，都是用 Ruby 写的，所以，如果你想全新创建一个 buildpack 包，不仅要了解buildpack 的构成和逻辑，还需要懂 Ruby 编程知识。所以，目前大家首选的自定义方法是，在现有的 buildpack 包的基础之上，根据自己的实际需求进行修改，并离线所有的 dependencies 或者建立自己的本地源。另外，从 github 上下载 buildpack 包，基本不能直接使用，需要经过以下步骤处理： Make sure you have fetched submodules 1git submodule update --init Get latest buildpack dependencies 1BUNDLE_GEMFILE=cf.Gemfile bundle Build the buildpack 1BUNDLE_GEMFILE=cf.Gemfile bundle exec buildpack-packager [ --cached | --uncached ] Use in Cloud Foundry 12cf create-buildpack CUSTOM_BUILDPACK_NAME CUSTOM_BUILDPACK_NAME.zip 1cf push my_app -b CUSTOM_BUILDPACK_NAME Java buildpack 的编译和打包操作和以上有些不一样： 1234bundle installbundle exec rake package OFFLINE=true PINNED=true...Creating build/java-buildpack-offline-cfd6b17.zip NOTE: 本地电脑上要事先安装 zip 工具本地电脑上要事先安装 Ruby 语言并配置好环境变量本地电脑上要事先安装 Bundler 工具事先学会 Bundler 的基本使用，参考 bundler.io 由于 Bundler 的源是国外的，连接会不稳定，断开后，可以重新运行命令继续 § 基本原理CF运行应用的基本过程是将用户发布的应用程序包解压开，然后将自己的所有buildpack拿来，按照指定顺序与程序包进行匹配，直到找到第一个能够运行这些代码的buildpack，然后将buildpack也解开，与这些应用代码打成一个包（即droplet），在按照指定的运行环境参数生成容器，将droplet扔进去，按照buildpack指定的启动命令，启动应用。在上面的过程中，buildpack做了三个动作： detect: 检查当前应用程序包是否能够用本buildpack支持运行，比如，java buildpack发现WEB-INF路径就认为自己能够运行它。 compile: 这是buildpack的核心文件，一般作用就是去拉取相应的Runtime（e.g. python2.7/ruby1.9.3）下来，做一下配置放到指定位置，拉取相应的Framework（e.g. Flask/Django）下来，做一下配置，放到指定位置。将应用程序包与buildpack包水乳交融一下，比如将java程序包放到tomcat的应用目录下，然后替换某些参数，比如将当前dea里的随机端口赋予这个tomcat实例。 release: 将droplet启动，比如运行tomcat的startup.sh。任何一个buildpack都有一个bin路径，放着三个指定名字（detect、compile、release）的脚本（任何dea的os能执行的脚本都可以），然后具体的实现逻辑就从这里触发了。 § 自定义 buildpack 包的样例下面我们自定义一个buildpack来支持java web项目。 bin/detect脚本文件 A. bash 版 1234567891011121314#!/usr/bin/env bash # cf 会给detect脚本传入一个参数，即 build dir，里边就是那一坨app散文件BUILD_DIR=$1# 既然是java web的项目，而且跑在tomcat上，我们没别的要求，只要web.xml位于规范位置即可if [ -d "${BUILD_DIR}/WEB-INF" ] && [ -f "${BUILD_DIR}/WEB-INF/web.xml" ]; then# 按照惯例，一般会把所侦测到的项目类型echo出来，# 这个echo出来的字符串和compile、release脚本没有半毛钱关系echo "JavaWeb"# 返回0表示detect成功执行，cf会继续执行compile，返回非0值cf就不继续往下走了exit 0fiecho "no"exit 1 B. ruby 版 12345678910#!/usr/bin/env rubygemfile_path = File.join ARGV[0], "Gemfile"if File.exist?(gemfile_path) puts "Ruby" exit 0else exit 1end bin/compile 脚本文件 compile 文件做的事情稍微复杂一些，也是三个脚本文件中任务最重的一个。如果觉得 bash 脚本语言不能够很好的胜任，可以换用其他任何可以运行的脚本语言，比如 Ruby。 12345678910111213141516# detect、compile、release这几个文件都没有后缀，用你喜欢的语言就好，这里是用的ruby$stdout.sync = true# 自己创建了一个lib目录，塞入环境变量，# 如之前所述，除了bin目录必须固定之外，其他文件（夹）随你喜欢来安排$:.unshift File.expand_path('../../lib', __FILE__)require 'global'require 'main_pack'require 'fileutils' build_path = ARGV[0]cache_path = ARGV[1]FileUtils.mkdir_p(build_path)FileUtils.mkdir_p(cache_path)# 主要逻辑都放在MainPack里了，无非就是下载、配置pack = MainPack.new(Global.new(build_path, cache_path))pack.compile NOTE: 为了提高下载速度，免受网络困扰，同时增加掌控力度，一般会把依赖的tar包放到内网某个位置去自己管理 build_dir/.profile.d/*.sh文件都会在运行app之前由 CloudFoundry 帮我们提前运行，那在此导出一些环境变量之类的就比较方便了 bin/release 脚本文件此处的 release 脚本文件同样是用ruby写的： 12345678910111213#!/usr/bin/env rubyrequire 'yaml'yml = {'addons' => [],'config_vars' => {},'default_process_types' => {'web' => './bin/catalina.sh run'}}.to_yamlputs yml default_process_types字段下面的web字段的值就是告诉CloudFoundry如何启动这个app，当然，我们可以在push应用的时候覆盖这个配置。 buildpack 中提供的语言环境和 runtime（比如 php、apache），一般有多个版本可选，如果默认版本不符合用户需求，用户可以在自己程序的某个指定文件中配置自己所需要的版本，比如，用户程序中有个config/dependency.yml，如果用户提供了此文件，用用户指定的版本，如果用户没有提供，那就用 buildpack 默认的版本。 CloudFoundry 有一个内部的仓储（里边是python、jdk、apache、php之类的buildpack需要的），版本管理由用户自己介入通过用户程序中的config/dependency.yml作为媒介，用户可以自由的做版本的管理。而有些不太好搞的依赖，比如某个python webapp要求系统事先安装flask1.0，推荐做法是，用户自己把flask打包到自己的程序中一起上传（这样用户发布出来的包就已经是没有依赖的)；也可以在根目录下提供一个requirements.txt，里边写上要安装的库，启动之前用pip来自动安装。如果有些依赖仍然搞不定，用户可以在启动脚本中写一些自定义命令。总体来看，buildpack 帮助 paas 平台完成了一个 app 在部署层面的抽象，主要搞定 app 依赖的 runtime 和 framework ，相当于搞定了静态依赖。操作系统特性通过统一定制 rootfs 来搞，不在 buildpack 问题域。配置文件差异问题，buildpack 认为一个app 一套配置，上层怎么处理，开发人员自己说了算，可以搭建多套 CloudFoundry 或者创建不同的 app：dev-app/prod-app之类；运行时依赖也需要开发人员自己搞定，提前确认好相应的依赖是否已经在 run，版本是否OK之类。 § 当前系统中的 Buildpack 版本本次在尝试自定义 Buildpack 包的过程中，还对当前Cloud Foundry 系统中的Buildpack做了全面的更新。目前的已有的Buildpack的版本如下： 123456789buildpack position enabled locked filenamestaticfile_buildpack 1 true false staticfile_buildpack-cached-v1.3.10.zipruby_buildpack 2 true false ruby_buildpack-cached-v1.6.20.zipnodejs_buildpack 3 true false nodejs_buildpack-cached-v1.5.18.zipgo_buildpack 4 true false go_buildpack-cached-v1.7.11.zippython_buildpack 5 true false python_buildpack-cached-v1.5.8.zipphp_buildpack 6 true false php_buildpack-cached-v4.3.17.zipbinary_buildpack 7 true false binary_buildpack-cached-v1.0.3.zipjava_buildpack 8 true false java-buildpack-offline-v3.8.1_4.zip 这是目前Pivotal官网所能提供的最新版。 NOTE:可以从network.pivotal.io下载 Pivotal 相关的产品。由于Pivotal官网服务器不在国内，所以，下载东西如果100MB+需要有点耐心，可能出现频繁下载失败的情况。这个时候，只需要反复下载，尽量选择晚上下载，网速能好一点。比如下图下载Python的Buildpack，反反复复下载了三天，侥幸成功! 有时候不努力一把你就不知道什么叫做绝望！三、部署应用§ Java Buildpack 的使用Java Buildpack 可以用来部署 Grails, Play, Spring 或者其他任何基于JVM的语言或者框架。JVM类的应用程序，在CloudFoundry上部署之前需要事先在本地打包，所谓的打包，就是把用到的类工具、资源（图片等）、源码、编译后的文件等全都放到一起，以达到发布、管理、修改、维护方便的目的。包的种类： JAR包：打成JAR包的代码，一般作为工具类，在项目中，会应用到N多JAR工具包； WAR包：JAVA WEB工程，都是打成WAR包，进行发布，如果我们的服务器选择TOMCAT等轻量级服务器，一般就打出WAR包进行发布； EAR包：这针对企业级项目的，实际上EAR包中包含WAR包和几个企业级项目的配置文件而已，一般服务器选择WebSphere等，都会使用EAR包。对于不同的基于JVM的语言或者框架，其打包的方式略有不同。 Grails Grails packages applications into WAR files for deployment into a Servlet container. To build the WAR file and deploy it, run the following: 12$ grails prod war$ cf push my-application; -p target/my-application-version.war Groovy Groovy applications based on both Ratpack and a simple collection of files are supported. Ratpack Ratpack packages applications into two different styles; Cloud Foundry supports the distZip style. To build the ZIP and deploy it, run the following: 12$ gradle distZip$ cf push my-application -p build/distributions/my-application.zip Raw Groovy Groovy applications that are made up of a single entry point plus any supporting files can be run without any other work. 1$ cf push my-application Java Main Java applications with a main()method can be run provided that they are packaged as self-executable JARs. NOTE:If your application is not web-enabled, you must suppress route creation to avoid a “failed to start accepting connections”error. To suppress route creation, add no-route: true to the application manifest.yml or use the --no-route flag with the cf push command. Maven A Maven build can create a self-executable JAR. To build and deploy the JAR, run the following: 12$ mvn package$ cf push my-application -p target/my-application-version.jar Gradle A Gradle build can create a self-executable JAR. To build and deploy the JAR, run the following: 12$ gradle build$ cf push my-application -p build/libs/my-application-version.jar Play Framework The Play Framework packages applications into two different styles. Cloud Foundry supports both the staged and dist styles. To build the dist style and deploy it, run the following: 12$ play dist$ cf push my-application -p target/universal/my-application-version.zip Spring Boot CLI Spring Boot can run applications comprised entirely of POGOs. To deploy then, run the following: 12$ spring grab *.groovy$ cf push my-application Servlet Java applications can be packaged as Servlet applications. Maven A Maven build can create a Servlet WAR. To build and deploy the WAR, run the following: 12$ mvn package$ cf push my-application -p target/my-application-version.war Gradle A Gradle build can create a Servlet WAR. To build and deploy the JAR, run the following: 12$ gradle build$ cf push my-application -p build/libs/my-application-version.war NOTE:在上面使用各种工具打包的过程中，经常会遇到，需要安装本地环境或各种工具。所以，如果遇到不能正常打包的情况，最好仔细看看它的错误提示，根据错误提示，看是本地环境问题，还是在线安装的时候，网络出了问题，如果是网络出了问题，能不能手动根据其下载地址，把工具或者依赖下下来，手动安装或者建立本地仓库，然后更新其配置文件中相应的下载链接等等。当然，由此带来的问题是，可能打包时间过长，耐心等待。总而言之，这个过程基本上不会一帆风顺，需要比较强的Troubleshooting的能力。 § Ruby Buildpack 的使用Ruby Buildpack 包可以用来部署Rack, Rails, or Sinatra应用。在部署应用之前，首先要做的是，用Bundler工具在你的应用文件夹下面创建Gemfile和Gemfile.lock文件。 Bundler的安装和使用： 1234$ gem update --system$ gem install bundler$ bundle install$ git add Gemfile Gemfile.lock 部署一个Ruby的应用： Prerequisites A Ruby 2.x application that runs locally on your workstation Bundler configured on your workstation Basic to intermediate Ruby knowledge The cf Command Line Interface (CLI) installed on your workstation Clone the pong_matcher_ruby app from GitHub： 1git clone https://github.com/cloudfoundry-samples/pong_matcher_ruby.git Note: Ensure that your Ruby app runs locally before continuing with this procedure. Create and Bind a Service Instance for a Ruby ApplicationCreate a Service Instance 123456# view services and plans that are available to you$ cf marketplace#cf create-service SERVICE PLAN SERVICE_INSTANCE$ cf create-service rediscloud 30mb redisCreating service redis in org Cloud-Apps / space development as [email protected] Bind a Service Instance When you bind an app to a service instance, Cloud Foundry writes information about the service instance to the VCAP_SERVICES app environment variable. The app can use this information to integrate with the service instance. You can bind a service to an application with the command : 1$ cf bind-service APPLICATION SERVICE_INSTANCE Alternately, you can configure the deployment manifest file by adding a services block to the applications block and specifying the service instance. 12services: - redis Log in and Target the API Endpoint 1$ cf login -a API_ENDPOINT Deploy an App 1$ cf push pong_matcher_ruby -n HOST_NAME 通过修改manifest.yml 文件，能够有效地控制部署应用的过程，包括instances、memory、command等 123456789101112---applications: - name: pong memory: 256M instances: 1 path: . command: ruby server.rb# code_snippet ruby-2b start services: - redis# code_snippet ruby-2b end § Node.js Buildpack 的使用Cloud Foundry expects a package.json in your Node.js app. You can specify the version of Node.js you want to use in the engine node of your package.json file. 123456789101112131415{ "name": "first", "version": "0.0.1", "author": "Demo", "dependencies": { "express": "3.4.8", "consolidate": "0.10.0", "express": "3.4.8", "swig": "1.3.2" }, "engines": { "node": "0.12.7", "npm": "2.7.4" }} You must use the PORT environment variable to determine which port your app should listen on. In order to also run your app locally, you may want to make port 3000 the default: 1app.listen(process.env.PORT || 3000); Node.js apps require a start command. You can specify the web start command for a Node.js app in a Procfile or in the app deployment manifest. 12345---applications:- name: my-app command: node my-app.js //start command... the rest of your settings ... Alternately, specify the start command with cf push -c. 1$ cf push my-app -c "node my-app.js" Application BundlingYou do not need to run npm install before deploying your app. Cloud Foundry runs it for you when your app is pushed. If you prefer to run npm install and create a node_modules folder inside of your app, this is also supported. § Binary Buildpack 的使用Binary Buildpack不想Cloud Foundry的其他Buildpack包，在使用的时候，必须指定Buildpack包。可以使用cf push 的 - b选项来指定相应的本地Buildpack的名字或者github的Buildpack包地址。 1$ cf push my_app -b https://github.com/cloudfoundry/binary-buildpack.git 可以通过以下两种途径，执行binary文件： Procfile: In the root directory of your app, add a Procfile that specifies a web task: 1web: ./app Command line: Use cf push APP-NAME with the - c option: 1$ cf push my_app -c './app' -b binary-buildpack Compiling your Binary Your binary should run without any additional runtime dependencies on the cflinuxfs2 or lucid64 root filesystem (rootfs). Any such dependencies should be statically linked to the binary. To boot a docker container running the cflinuxfs2 filesystem, run the following command: 1$ docker run -it cloudfoundry/cflinuxfs2 bash To boot a docker container running the lucid64 filesystem, run the following command: 1$ docker run -it cloudfoundry/lucid64 bash 需要提前安装docker，并配置好docker源下载比较缓慢，经常失败 When deploying your binary to Cloud Foundry, use cf push with the -s option to specify the root filesystem it should run against. 1$ cf push my_app -s (cflinuxfs2|lucid64) § Go Buildpack 的使用The Go buildpack will be automatically detected if: Your app has been packaged with godep using godep save Your app has a vendor/ directory and has any files ending with .go. Your app has a GOPACKAGENAME environment variable specified and has any files ending with .go. Your app has a glide.yaml file and is using glide (starting in buildpack version 1.7.9). Pushing Apps with godep If you are using godep to package your dependencies, make sure that you have created a valid Godeps/Godeps.json file in the root directory of your app by running godep save. When using godep, you can fix your Go version in GoVersion key of the Godeps/Godeps.json file. Go 1.5An example Godeps/Godeps.json: 12345{ "ImportPath": "go_app", "GoVersion": "go1.5", "Deps": []} An example manifest.yml: 123---applications: - name: my-app-name Go 1.6 NOTE: if you are using godep with Go 1.6, you must set the GO15VENDOREXPERIMENT environment variable to 0, otherwise your app will not stage. An example Godeps/Godeps.json: 12345{ "ImportPath": "go_app", "GoVersion": "go1.6", "Deps": []} An example manifest.yml: 12345---applications: - name: my-app-name env: GO15VENDOREXPERIMENT: 0 Pushing Apps with Glide If you are using glide to specify and/or package your dependencies, make sure that you have created a valid glide.yaml file in the root directory of your app by running glide init. To vendor your dependencies before pushing, run glide install. This will generate a vendor directory and a glide.lockfile specifying the latest compatible versions of your dependencies. A glide.lock is not required when deploying a non-vendored app. A glide.lock is required when pushing a vendored app. An example glide.yaml: 12345package: go_app_with_glideimport:- package: github.com/ZiCog/shiny-thing subpackages: - foo Pushing Apps with Native Go Vendoring If you are using the native Go vendoring system, which packages all local dependencies in the vendor/directory, you must specify your app’s package name in the GOPACKAGENAME environment variable. An example manifest.yml: 123456---applications: - name: my-app-name command: go-online env: GOPACKAGENAME: go-online Go 1.5 NOTE: For Go 1.5, since native vendoring is turned off by default, you must set the environment variable GO15VENDOREXPERIMENT to 1 in your manifest.yml to use this feature. If you are using the vendor/ directory for dependencies, you can set the Go version with the GOVERSION environment variable. An example manifest.yml: 1234567---applications: - name: my-app-name env: GOVERSION: go1.5 GOPACKAGENAME: app-package-name GO15VENDOREXPERIMENT: 1 Go 1.6 An example manifest.yml: 1234567---applications: - name: my-app-name command: example-project env: GOVERSION: go1.6 GOPACKAGENAME: github.com/example-org/example-project]]></content>

</categories>

<tags>

<tag>Cloud Foundry</tag>

</tags>

</entry>

<entry>

<url>%2F2016%2F06%2F10%2F%E9%80%9A%E8%BF%87rvm%E5%AE%89%E8%A3%85Ruby%E3%80%81Bundler%E5%92%8CRails%2F</url>

<content type="text"><![CDATA[Ruby Version Manager简称RVM,是一款非常好用的ruby版本管理以及安装工具。 Step1: 安装rvm$ gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 $ curl -sSL https://get.rvm.io | bash -s stable # 如果上面的连接失败，可以尝试: $ curl -L https://raw.githubusercontent.com/wayneeseguin/rvm/master/binscripts/rvm-installer | bash -s stable 然后，载入 RVM 环境（新开 Termal 就不用这么做了，会自动重新载入) 1$ source /usr/local/rvm/scripts/rvm 修改 RVM 下载 Ruby 的源，到 Ruby China 的镜像:1echo "ruby_url=https://cache.ruby-china.org/pub/ruby" > /usr/local/rvm/user/db Step2: 用 RVM 安装 Ruby 环境安装依赖环境： $ rvm requirements 显示已安装的Ruby的列表： $ rvm list 显示可以安装的Ruby的列表： $ rvm list known 安装Ruby 2.3.0： $ rvm install 2.3.0 RVM 装好以后，需要执行下面的命令将指定版本的 Ruby 设置为系统默认版本： $ rvm use 2.3.0 --default 测试是否正确： $ ruby -v ruby 2.3.0 ... $ gem -v 2.1.6 请尽可能用比较新的 RubyGems 版本，建议 2.6.x 以上： $ gem update --system # 这里请翻墙一下 $ gem -v 2.6.6 更换RubyGems的源： $ gem sources --add https://gems.ruby-china.org/ --remove https://rubygems.org/ $ gem sources -l https://gems.ruby-china.org # 确保只有 gems.ruby-china.org Step3：安装Bundlergem install bundler 在已有的project的文件下的Gemfile文件中添加以下内容，指定依赖： source 'https://rubygems.org' gem 'nokogiri' gem 'rack', '~>1.1' gem 'rspec', :require => 'spec' 在同样的文件夹下： $ bundle install $ git add Gemfile Gemfile.lock Step4：安装Rails环境Ruby 环境就安装好了，接下来安装 Rails： $ gem install rails 然后测试安装是否正确： $ rails -v Rails 4.2.5 More：http://bundler.io/https://gems.ruby-china.org/https://ruby-china.org/wiki/install_ruby_guide]]></content>

</categories>

<tags>

<tag>Rails</tag>

</tags>

</entry>

<entry>

<url>%2F2016%2F04%2F10%2Fhello-world%2F</url>

</categories>

<tags>

</tags>

</entry>

</search>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

search.xml

Latest commit

History

search.xml

File metadata and controls