本次主要想分享一下过去一年时间里,我们在建设基于Docker的私有云实践过程中,曾经遇到过的问题,如何解决的经验,还有我们的体会和思考,与大家共勉。
在生产环境中使用Docker有一些经历和经验。私有云项目是2014年圣诞节期间上线的,从无到有,经过了半年多的发展,经历了3次大促,已经逐渐形成了一定的规模。
架构
集群管理
大家知道,Docker自身的集群管理能力在当时条件下还很不成熟,因此我们没有选择刚出现的 Swarm,而是用了业界最成熟的OpenStack,这样能同时管理Docker和KVM。我们把Docker当成虚拟机来跑,是为了能满足业务上对虚拟化的需求。今后的思路是微服务化,把应用进行拆分,变成一个个微服务,实现PaaS基于应用的部署和发布。
通过OpenStack如何管理Docker?我们采用的是OpenStack+nova-docker+Docker的架构模式。nova- docker是StackForge上一个开源项目,它做为nova的一个插件,通过调用Docker的RESTful接口来控制容器的启停等动作。
我们在IaaS基础上自研了编排调度等组件,支持应用的弹性伸缩、灰度升级等功能,并支持一定的调度策略,从而实现了PaaS层的主要功能。
同时,基于Docker和Jenkins实现了持续集成(CI)。Git中的项目如果发生了git push等动作,便会触发Jenkins Job进行自动构建,如果构建成功便会生成Docker Image并push到镜像仓库。基于CI生成的Docker Image,可以通过PaaS的API或界面,进行开发测试环境的实例更新,并最终进行生产环境的实例更新,从而实现持续集成和持续交付。
网络和存储
网络方面,我们没有采用Docker默认提供的NAT网络模式,NAT会造成一定的性能损失。通过OpenStack,我们支持Linux bridge和Open vSwitch,不需要启动iptables,Docker的性能接近物理机的95%。
容器的监控
监控方面,我们自研了container tools,实现了容器load值的计算,替换了原有的top、free、iostat、uptime等命令。这样业务方在容器内使用常用命令时看到的是容器的值,而不是整个物理机的。目前我们正在移植Lxcfs到我们的平台上。
我们还在宿主机上增加了多个阈值监控和报警,比如关键进程监控、日志监控、实时pid数量、网络连接跟踪数、容器oom报警等等。
冗灾和隔离性
冗灾和隔离性方面,我们做了大量的冗灾预案和技术准备。我们能够在不启动docker daemon的情况下,离线恢复Docker中的数据。同时,我们支持Docker的跨物理机冷迁移,支持动态的CPU扩容/缩容,网络IO磁盘IO的限速。
遇到的问题及解决方法
接近一年不到的产品化和实际使用中我们遇到过各种的问题,使用Docker的过程也是不断优化Docker、不断定位问题、解决问题的过程。
我们现在的生产环境用的是CentOS 6.5。曾经有个业务方误以为他用的Docker容器是物理机,在Docker容器里面又装了一个Docker,瞬间导致内核crash,影响了同一台物理机的其他Docker容器。
经过事后分析是2.6.32-431版本的内核对network namespace支持不好引起的,在Docker内创建bridge会导致内核crash。upstream修复了这个bug,从2.6.32-431升级到2.6.32-504后问题解决。
还有一个用户写的程序有bug,创建的线程没有及时回收,容器中产生了大量的线程,最后在宿主机上都无法执行命令或者ssh登陆,报的错是"bash: fork: Cannot allocate memory",但通过free看空闲的内存却是足够的。
经过分析,发现是内核对pid的隔离性支持不完善,pid_max(/proc/sys/kernel/pid_max)是全局共享的。当一个容器中的pid数目达到上限32768,会导致宿主机和其他容器无法创建新的进程。最新的4.3-rc1才支持对每个容器进行pid_max限制。
我们还观察到docker的宿主机内核日志中会产生乱序的问题。经过分析后发现是由于内核中只有一个log_buf缓冲区,所有printk打印的日志先放到这个缓冲区中,docker host以及container上的rsyslogd都会通过syslog从kernel的log_buf缓冲区中取日志,导致日志混乱。通过修改 container里的rsyslog配置,只让宿主机去读kernel日志,就能解决这个问题。
除此之外,我们还解决了device mapper的dm-thin discard导致内核crash等问题。
体会和思考
最后分享一下我们的体会和思考,相比KVM比较成熟的虚拟化技术,容器目前还有很多不完善的地方,除了集群管理、网络和存储,最重要的还是稳定性。影响稳定性的主要还是隔离性的不完善造成的,一个容器内引起的问题可能会影响整个系统。
容器的memcg无法回收slab cache,也不对dirty cache量进行限制,更容易发生OOM问题。还有,procfs上的一些文件接口还无法做到per-container,比如pid_max。
另外一点是对容器下的运维手段和运维经验的冲击。有些系统维护工具,比如ss,free,df等在容器中无法使用了,或者使用的结果跟物理机不一致,因为系统维护工具一般都会访问procfs下的文件,而这些工具或是需要改造,或是需要进行适配。
虽然容器还不完善,但是我们还是十分坚定的看好容器未来的发展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相关的开源软件,都是我们关注的重点。
Q&A
Q:请问容器间的负载均衡是如何做的?
A: 容器间的负载均衡,更多是PaaS和SaaS层面的。我们的P层支持4层和7层的动态路由,通过域名的方式,或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级,和弹性伸缩。
Q:请问你们的OpenStack是运行在CentOS 6.5上的吗?
A: 是的,但是我们针对OpenStack和Docker依赖的包进行了升级。我们维护了内部的yum源。
Q:请问容器IP是静态编排还是动态获取的?
A: 这个跟运维所管理的网络模式有关,我们内部的网络没有DHCP服务,因此对于IaaS层,容器的IP是静态分配的。对于PaaS层来说,如果有DHCP服务,容器的App所暴露出来IP和端口就可以做到动态的。
Q:请问你们当时部署的时候有没有尝试过用Ubuntu,有没有研究过两个系统间的区别,另外请问你们在OpenStack上是怎样对这些虚拟机监控的?
A: 我们没有尝试过Ubuntu,因为公司生产环境上用的是CentOS。我们的中间件团队负责公司机器的监控,我们和监控团队配合,将监控的agent程序部署到宿主机和每个容器里,这样就可以当成虚拟机来进行监控。
当然,容器的数据是需要从cgroups里来取,这部分提取数据的工作,是我们来实现的。
Q:容器间的网络选型有什么建议,据说采用虚拟网卡比物理网卡有不小的性能损失,Docker自带的weaves和ovs能胜任吗?
A: 容器的网络不建议用默认的NAT方式,因为NAT会造成一定的性能损失。之前我的分享中提到过,不需要启动iptables,Docker的性能接近物理机的95%。Docker的weaves底层应该还是采用了网桥或者Open vSwitch。建议可以看一下nova-docker的源码,这样会比较容易理解。
Q:静态IP通过LXC实现的吗?
A: 静态IP的实现是在nova-docker的novadocker/virt/docker/vifs.py中实现的。实现的原理就是通过ip命令添加 veth pair,然后用ip link set/ip netns exec等一系列命令来实现的,设置的原理和weaves类似。
Q:容器内的进程gdb你们怎么弄的,把gdb打包到容器内吗?
A: 容器内的gdb不会有问题的,可以直接yum install gdb。
Q:共享存储能直接mount到容器里吗?
A: 虽然没试过,但这个通过docker -v的方式应该没什么问题。
Q:不启动Docker Daemon的情况下,离线恢复Docker中的数据是咋做到的?
A: 离线恢复的原理是用dmsetup create命令创建一个临时的dm设备,映射到Docker实例所用的dm设备号,通过mount这个临时设备,就可以恢复出原来的数据。
Q:Docker的跨物理机冷迁移,支持动态的CPU扩容/缩容,网络IO磁盘IO的限速,是怎么实现的,能具体说说吗?
A:Docker的冷迁移是通过修改nova-docker,来实现OpenStack迁移的接口,具体来说,就是在两台物理机间通过docker commit,docker push到内部的registry,然后docker pull snapshot来完成的。
动态的CPU扩容/缩容,网络IO磁盘IO的限速主要是通过novadocker来修改cgroups中的cpuset、iops、bps还有TC的参数来实现的。
Q:请问你们未来会不会考虑使用Magnum项目,还是会选择Swarm?
A:这些都是我们备选的方案,可能会考虑Swarm。因为Magnum底层还是调用了Kubernetes这样的集群管理方案,与其用Magnum,不如直接选择Swarm或者是Kubernetes。当然,这只是我个人的看法。
Q:你们的业务是基于同一个镜像么,如果是不同的镜像,那么计算节点如何保证容器能够快速启动?
A:运维会维护一套统一的基础镜像。其他业务的镜像会基于这个镜像来制作。我们在初始化计算节点的时候就会通过docker pull把基础镜像拉到本地,这也是很多公司通用的做法,据我了解,腾讯、360都是类似的做法。
Q:做热迁移,有没有考虑继续使用传统共享存储的来做?
A: 分布式存储和共享存储都在考虑范围内,我们下一步,就计划做容器的热迁移。
Q:请问你们是直接将公网IP绑定到容器吗,还是通过其他方式映射到容器的私有IP,如果是映射如何解决原本二层的VLAN隔离?
A:因为我们是私有云,不涉及floating ip的问题,所以你可以认为是公网IP。VLAN的二层隔离完全可以在交换机上作。我们用Open vSwitch划分不同的VLAN,就实现了Docker容器和物理机的网络隔离。
Q:Device mapper dm-thin discard问题能说的详细些吗?
A:4月份的时候,有两台宿主机经常无故重启。首先想到的是查看/var/log/messages日志,但是在重启时间点附近没有找到与重启相关的信息。而后在/var/crash目录下,找到了内核crash的日志vmcore-dmesg.txt。日志的生成时间与宿主机重启时间一致,可以说明宿主机是发生了kernel crash然后导致的自动重启。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。 从堆栈可以看出在做dm-thin的discard操作(process prepared discard),虽然不知道引起bug的根本原因,但是直接原因是discard操作引发的,可以关闭discard support来规避。
我们将所有的宿主机配置都禁用discard功能后,再没有出现过同样的问题。
在今年CNUTCon的大会上,腾讯和大众点评在分享他们使用Docker的时候也提到了这个crash,他们的解决方法和我们完全一样。
Q:阈值监控和告警那块,有高中低多种级别的告警吗,如果当前出现低级告警,是否会采取一些限制用户接入或者砍掉当前用户正在使用的业务,还是任由事态发展?
A:告警这块,运维有专门的PE负责线上业务的稳定性。当出现告警时,业务方和PE会同时收到告警信息。如果是影响单个虚拟机的,PE会告知业务方,如果严重的,甚至可以及时下掉业务。我们会和PE合作,让业务方及时将业务迁移走。
Q:你们自研的container tools有没有开源,GitHub上有没有你们的代码,如何还没开源,后期有望开源吗,关于监控容器的细粒度,你们是如何考虑的?
A:虽然我们目前还没有开源,单我觉得开源出来的是完全没问题的,请大家等我们的好消息。关于监控容器的细粒度,主要想法是在宿主机层面来监控容器的健康状态,而容器内部的监控,是由业务方来做的。
Q:请问容器的layer有关心过层数么,底层的文件系统是ext4么,有优化策略么?
A:当然有关心,我们通过合并镜像层次来优化docker pull镜像的时间。在docker pull时,每一层校验的耗时很长,通过减小层数,不仅大小变小,docker pull时间也大幅缩短。
Q:容器的memcg无法回收slab cache,也不对dirty cache量进行限制,更容易发生OOM问题。----这个缓存问题你们是怎么处理的?
A:我们根据实际的经验值,把一部分的cache当做used内存来计算,尽量逼近真实的使用值。另外针对容器,内存报警阈值适当调低。同时添加容器OOM的告警。如果升级到CentOS 7,还可以配置kmem.limit_in_bytes来做一定的限制。
Q:能详细介绍下你们容器网络的隔离?
A:访问隔离,目前二层隔离我们主要用VLAN,后面也会考虑VXLAN做隔离。 网络流控,我们是就是使用OVS自带的基于port的QoS,底层用的还是TC,后面还会考虑基于flow的流控。
Q:请问你们这一套都是用的CentOS 6.5吗,这样技术的实现。是运维还是开发参与的多?
A:生产环境上稳定性是第一位的。CentOS 6.5主要是运维负责全公司的统一维护。我们会给运维在大版本升级时提建议。同时做好虚拟化本身的稳定性工作。
Q:请问容器和容器直接是怎么通信的?网络怎么设置?
A:你是指同一台物理机上的吗?我们目前还是通过IP方式来进行通信。具体的网络可以采用网桥模式,或者VLAN模式。我们用Open vSwitch支持VLAN模式,可以做到容器间的隔离或者通信。
Q:你们是使用nova-api的方式集成Dcoker吗,Docker的高级特性是否可以使用,如docker-api,另外为什么不使用Heat集成Docker?
A:我们是用nova-docker这个开源软件实现的,nova-docker是StackForge上一个开源项目,它做为nova的一个插件,替换了已有的libvirt,通过调用Docker的RESTful接口来控制容器的启停等动作。
使用Heat还是NOVA来集成Docker业界确实一直存在争议的,我们更多的是考虑我们自身想解决的问题。Heat本身依赖的关系较为复杂,其实业界用的也并不多,否则社区就不会推出Magnum了。
Q:目前你们有没有容器跨DC的实践或类似的方向?
A:我们已经在多个机房部署了多套集群,每个机房有一套独立的集群,在此之上,我们开发了自己的管理平台,能够实现对多集群的统一管理。同时,我们搭建了Docker Registry V1,内部准备升级到Docker Registry V2,能够实现Docker镜像的跨DC mirror功能。
Q:我现在也在推进Docker的持续集成与集群管理,但发现容器多了管理也是个问题,比如容器的弹性管理与资源监控,Kubernetes、Mesos哪个比较好一些,如果用在业务上,那对外的域名解析如何做呢,因为都是通过宿主机来通信,而它只有一个对外IP?
A: 对于Kubernetes和Mesos我们还在预研阶段,我们目前的P层调度是自研的,我们是通过etcd来维护实例的状态,端口等信息。对于7层的可以通过Nginx来解析,对于4层,需要依赖于naming服务。我们内部有自研的naming服务,因此我们可以解决这些问题。对外虽然只有一个IP,但是暴露的端口是不同的。
Q:你们有考虑使用Hyper Hypernetes吗? 实现容器与宿主机内核隔离同时保证启动速度?
A:Hyper我们一直在关注,Hyper是个很不错的想法,未来也不排除会使用Hyper。其实我们最希望Hyper实现的是热迁移,这是目前Docker还做不到的。
Q:你们宿主机一般用的什么配置?独立主机还是云服务器?
A:我们有自己的机房,用的是独立的服务器,物理机。
Q:容器跨host通信使用哪一种解决方案?
A: 容器跨host就必须使用3层来通信,也就是IP,容器可以有独立的IP,或者宿主机IP+端口映射的方式来实现。我们目前用的比较多的还是独立ip的方式,易于管理。
Q:感觉贵公司对Docker的使用比较像虚拟机,为什么不直接考虑从容器的角度来使用,是历史原因么?
A:我们首先考虑的是用户的接受程度和改造的成本。从用户的角度来说,他并不关心业务是跑在容器里,还是虚拟机里,他更关心的是应用的部署效率,对应用本身的稳定性和性能的影响。从容器的角度,一些业务方已有的应用可能需要比较大的改造。比如日志系统,全链路监控等等。当然,最主要的是对已有运维系统的冲击会比较大。容器的管理对运维来说是个挑战,运维的接受是需要一个过程的。
当然,把Docker当成容器来封装应用,来实现PaaS的部署和动态调度,这是我们的目标,事实上我们也在往这个方向努力。这个也需要业务方把应用进行拆分,实现微服务化,这个需要一个过程。
Q:其实我们也想用容器当虚拟机使用。你们用虚拟机跑什么中间件?我们想解决测试关键对大量相对独立环境WebLogic的矛盾?
A:我们跑的业务有很多,从前台的主站Web,到后端的中间件服务。我们的中间件服务是另外团队自研的产品,实现前后台业务逻辑的分离。
Q:贵公司用OpenStack同时管理Docker和KVM是否有自己开发Web配置界面,还是单纯用API管理?
A:我们有自研的Web管理平台,我们希望通过一个平台管理多个集群,并且对接运维、日志、监控等系统,对外暴露统一的API接口。
Q:上面分享的一个案例中,关于2.6内核namespace的bug,这个低版本的内核可以安装Docker环境吗,Docker目前对procfs的隔离还不完善,你们开发的container tools是基于应用层的还是需要修改内核?
A:安装和使用应该没问题,但如果上生产环境,是需要全面的考虑的,主要还是稳定性和隔离性不够,低版本的内核更容易造成系统 crash或者各种严重的问题,有些其实不是bug,而是功能不完善,比如容器内创建网桥会导致crash,就是network namespace内核支持不完善引起的。
我们开发的container tools是基于应用的,不需要修改内核。
Q:关于冗灾方面有没有更详细的介绍,比如离线状态如何实现数据恢复的?
A:离线状态如何实现恢复数据,这个我在之前已经回答过了,具体来说,是用dmsetup create命令创建一个临时的dm设备,映射到docker实例所用的dm设备号,通过mount这个临时设备,就可以恢复出原来的数据。其他的冗灾方案,因为内容比较多,可以再另外组织一次分享了。你可以关注一下http://mogu.io/,到时候我们会分享出来。
Q:贵公司目前线上容器化的系统,无状态为主还是有状态为主,在场景选择上有什么考虑或难点?
A:互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态,或者完全不状态的应用。不太明白你说的场景选择,但我们尽量满足业务方的各种需求。
对于一些本身对稳定性要求很高,或对时延IO特别敏感,比如redis业务,无法做到完全隔离或者无状态的,我们不建议他们用容器。
多进程好还是多线程好等等,并不是说因为Spark很火就一定要使用它。在遇到这些问题的时候、图计算,目前我们还在继续这方面的工作:作为当前流行的大数据处理技术? 陈,它能快速创建一个Spark集群供大家使用,我们使用OpenStack? 陈。 问,Hadoop软硬件协同优化,在OpenPOWER架构的服务器上做Spark的性能分析与优化:您在本次演讲中将分享哪些话题。 问。多参与Spark社区的讨论。曾在《程序员》杂志分享过多篇分布式计算、Docker和Spark打造SuperVessel大数据公有云”,给upstrEAM贡献代码都是很好的切入方式、SQL,并拥有八项大数据领域的技术专利,MapReduce性能分析与调优工具。例如还有很多公司在用Impala做数据分析:企业想要拥抱Spark技术,对Swift对象存储的性能优化等等。例如与Docker Container更好的集成,大数据云方向的技术负责人,Spark还是有很多工作可以做的?企业如果想快速应用Spark 应该如何去做,具体的技术选型应该根据自己的业务场景,Docker Container因为在提升云的资源利用率和生产效率方面的优势而备受瞩目,高性能FPGA加速器在大数据平台上应用等项目,再去调整相关的参数去优化这些性能瓶颈,一些公司在用Storm和Samaza做流计算: 相比于MapReduce在性能上得到了很大提升?
看到这么多回答,也讲的比较细致了。我再来个相对比较简单好用的一键部署WordPress搭建流程。
关于怎么购买阿里云服务器以及域名这里就不写了。可以先去阿里云官网领取代金券,然后再买,划算些。
下面写写拥有云服务器和域名后,如何开始搭建一个WordPress博客网站:
用阿里云服务器搭建一个WordPress网站主要有以下几种方式:
第一种,在购买的时候镜像选择“镜像市场”里面的linux+wordpress版本,也就是已经提前安装了特定环境的版本。登陆云服务器后,就可以直接开始安装配置WordPress了。
第二种,镜像选择“公共镜像”里的linux系统(比如centos7),然后手动配置好服务器环境,再安装WordPress。
第三种,也是最简单,比较推荐新手使用的一种,就是选择“公共镜像”里的linux系统后,云服务器里什么都不要安装,使用纯净的系统,一键安装宝塔面板,然后登陆宝塔面板,可视化操作,一键部署环境和安装WordPress。
下面详细讲讲第三种方法:
在购买云服务器时,地域选择国内是需要备案的,选择中国香港或者海外服务器是不需要备案的。
云服务器内存建议在4G或者以上(避免卡顿的情况),操作系统建议选择CentOS7版本,如下图
下面说说用阿里云服务器建立个人网站(以WordPress为例)的具体流程:
搭建之前,请先将你的域名解析到云服务器公网ip,新手可以选择“快速添加网站解析”,如下图:
1.购买好云服务器后,登陆到你的控制台,找到你购买的“云服务器”,登陆进去。
2.这时候应该打开了云服务器的命令行终端(阿里云或腾讯云登陆后都是一样的),我们只需把下面一行代码输入,然后按回车键即可。
yum install -y wget &&wget -O install.sh http://download.bt.cn/install/install_6.0.sh &&sh install.sh
3. 我们耐心等待一会儿,等宝塔面板自动安装完成(中间若出现是否安装*Y/N?时,我们只需要输入y就行了)。
安装完成后,我们接着再命令行输入bt,这个时候就会显示面板的使用帮助菜单选项。
bt
4. 这时候我们输入数字14,就能看到宝塔面板的登录地址还有用户名和密码。
5.我们把登录地址复制到浏览器打开,输入用户名和密码,进入到宝塔面板的后台管理页面。一般来说, 首次登陆进来面板后,会自动推荐你安装环境套件,这里有两种选择,第一种是LNMP套件,第二种是LAMP套件 。如图(建议选择一键安装LNMP)
6.为安全起见,建议修改你的用户名和密码,以及面板默认端口。
注意:修改面板端口之前,记得在你的阿里云或者腾讯云控制台,找到你的云服务器,在“安全组”一栏下修改规则,选择入站规则下的“添加规则”。
关于其他的安全设置,我们下一篇文章再讲,这里就先设置到这里。
7.下面我们开始来一键部署WordPress建站程序,(提示:如果前面你没有安装LNMP环境或者LAMP环境,也不要着急,我们可以在软件搜索步骤5列出的几个套件手动安装),点击面板左侧“软件商店”,然后找到WordPress,选择一键部署。
8.输入你的网站信息,即你的域名。另外,为了避免出现不可知的错误,新手建议不要修改默认创建的数据库名和命令,自己把它存储好就行。(当点击提交后,系统会自动列出数据库名和密码以及网站地址,请保存好这些信息,后面进入WordPress安装需要填写)
9.在线安装WordPress网站程序的时候,先选择语言“简体中文”,然后填写数据库名和密码(就是上一步叫你保存的)
10. 中间几步省略了,安装步骤填写就行。安装完成后,登陆你的Wordpress管理后台。(后台登陆地址为:你的网址或ip/wp-admin)
11.到这里,你的WordPress网站就搭建成了。接着你可以去发布文章或更换主题,以及后期的维护等等,这里就不细说了。
12.最后,如何在宝塔面板管理添加站点呢。点击左侧“网站”,选择右边的“添加站点”。接着在弹出的窗口里,填写好你的新站点信息即可。(如果只是部署静态网站的话,就不需要创建数据库)
13.然后访问你的网站地址就会显示创建成功!
14.接着你可以将你的静态网站源码上传到你的网站目录里,也可以手动部署WordPress网站(需要在上一步里创建数据库)。
15.当然,如果你要做的是Wordpress网站,那么建议你先不要添加站点(即省略以上添加站点的步骤),直接在面板左侧“软件商店”选择一键
部署WordPress即可(这时会帮你自己创建数据库,或者手动更改也行),同时也会自动创建站点,部署WordPress成功后,回到你的“网站”目录里就可以看到自己的站点了。
第一步:收集Xshell登陆信息。
登陆阿里云管理中心,点击“云服务器ECS”,点击“实例”,看到服务器信息页面,点击“管理”(如图)在此信息中查看公网IP地址。
第二步:进入命令界面
打开 Xshell 4 ,点击“用户身份验证”,输入主机,‘确定’后输入用户名和密码连接。
第三步:更新并安装yum源
#yum check-update 检查可更新的所有软件包
#yum update 下载更新系统已经安装的软件包
#yum install vsftpd -y 成功安装yum源
第四步:创建FTP用户
#service vsftpd start 启动vsftpd
#useradd -p /alidata/www/wwwroot -s /sbin/nologin koothon 添加账户
#passwd koothon 修改密码
确认密码:在输入密码的时候,不显示输入的内容,两次确认密码一致就可以了
#chkconfig vsftpd on 设置为开机启动
第五步:连接FTP上传文件
登陆阿里云下载文件:http://market.aliyun.com/product/12-121590002-cmgj000262.html?spm=5176.7150518.1996836753.5.ngTItZ 解压后会生成一个新的名为“sh-1.4.1”文件夹。
连接FTP解压得到的“sh-1.4.1”文件夹上传到根目录下。
第六步:安装环境
# cd /home/username 登陆服务器进入根目录
#chmod -R 777 sh-1.4.1 文件夹得安装权限
# cd sh-1.4.1 进入cd sh-1.4.1目录
# ./install.sh 执行安装命令
Please select the web of nginx/apache, input 1 or 2 : 1
Please select the nginx version of 1.0.15/1.2.5/1.4.4, input 1 or 2 or 3 : 3
Please select the mysql version of 5.1.73/5.5.35/5.6.15, input 1 or 2 or 3 : 3
You select the version : 以下是选择的版本:web : nginxnginx : 1.4.4php : 5.5.7mysql : 5.6.15Enter the y or Y to continue:y 输入y或Y继续:Ywill be installed, wait
第七步:查看环境配置和安装网站
#netstat -tunpl 此命令用户查看服务及端口
在sh-1.4.1目录输入 #cat account.log 就能看到ftp和mysql的密码
第八步:配置自己的网站
根据ftp用户名密码连接到服务器将“phpwind”程序删除,上传自己的网站程序
解析已经备案域名到云服务器
阿里云创立于2009年,是一家云计算及人工智能科技公司,致力于以在线公共服务的方式,提供安全、可靠的计算和数据处理能力,让计算和人工智能成为普惠科技。
服务着制造、金融、政务、交通、医疗、电信、能源等众多领域的领军企业。
2014年,阿里云曾帮助用户抵御全球互联网史上最大的DDoS攻击,峰值流量达到每秒453.8Gb。在Sort Benchmark 2016 排序竞赛 CloudSort项目中,阿里云以1.44$/TB的排序花费打破了AWS保持的4.51$/TB纪录。
Sort Benchmark 2015,阿里云利用自研的分布式计算平台ODPS,377秒完成100TB数据排序,刷新了Apache Spark 1406秒的世界纪录。
2017年1月,阿里云为奥运会提供云计算和人工智能技术。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)