让AWS虚机访问公司内网资源,应用发布前保障性能的十八种方式

新项目开发及运行环境配置-nodejs前台+java后台+postgresql数据库+nginx+tomcat,-nodejsnginx

让AWS虚机访问公司内网资源(SSH反向代理),aws虚机

应用发布前保障性能的十八种方式(一)

被文艺青年奉为“爱情圣经”的《爱在三部曲》第一部为我们描述了这样一个美好的故事:两个青年男女邂逅一见钟情,度过了一个美妙的晚上,而此次约会将会在日出之间结束…这是不是像极了应用开发?一次程序员与应用之间的邂逅。然而我们可以确定是,确保应用性能绝不仅仅是程序员自己或者IT运维团队的工作。在应用正式推出之前,开发、DevOps包括IT运维部门应当通力协作,预防应用在实际运行过程中出现意料之外的性能问题。

   
不过,原本独立的各支队伍该如何配合以实现这一共同目标?他们又该如何预防,甚至在应用开发完成之前就识别出其中所包含的性能问题?面对这些问题,国内外多位应用性能管理简称APM)以及相关市场的专业人士,就实际推出前确保应用性能表现这一议题给出了自己的推荐方案,其中包括处理举措、实施方案以及值得认真考量的工具选项等等。

   
由于此类建议性清单种类很多,很多推荐方式之间可能存在交集、或者单一举措与多项条目相符。不过,清单本身的目标并非对此类建议进行定义与归类,而是帮助大家从众多应用性能问题的专业人士口中获得具备泛用性以及实际价值的解决思路。

   
清单当中的多数建议涉及各类工具与流程,在考量这些选项之前,Performance
Tuning Corporation首席战略官Mark
Swanholm推荐大家已这样的心态去阅读:“要在应用正式推出之前保障理想的性能,最理想的“工具”永远是我们自己开放而认真的心态。”除非大家能够选择了一套科学且以实证为基础的、涵盖整套堆栈的方案,否则当今环境的复杂程度必将远超大家的想象,同时带来预料之外的各类问题。专业人士能够提供出色的数据结构、高效的Web服务以及经过细心调试的服务器,但我们仍然需要运用自己的思维制定规划,从而将这一切有利因素整合起来以构成一款完整的高性能应用。”

    1、应用性能管理(简称APM)

   
APM能够帮助IT运维从高层次转向低层次,轻松实现优秀应用性能表现,从而提高客户满意度以及效率:软件正是商业成功的核心所在,这意味着更快的应用发布周期成为每一家企业必须达成的目标。因此,测试、预生产以及生产环境之间的界线开始变得越来越模糊。在此基础之上,APM解决方案应当尽早介入软件开发生命周期,确保我们拥有极致的应用性能表现。诸如代码层分析以及最终用户体验监控这类功能应当被纳入到测试环境之中,从而确保性能问题影响到真实用户之前就被发现。

 --John Rakowski
AppDynamics公司产品营销战略师
前Forrester研究公司基础设施与运维分析师

   
APM是对软件应用的性能和可用性进行监控和管理,致力于发现和定位性能瓶颈和故障,保证应用达到预期服务水平。而整个应用生命周期,从需求开始到研发到测试再到运营都需要监测。复杂的应用交付链下传统IT运维收到了很大的挑战,而APM自上而下的监控方式为用户、业务、代码、服务以及用户体验提供了保障。只要在可能形成性能瓶颈代码或者可能诱发其他性能问题的位置嵌入尽量简洁的代码就能实现APM。

 --Wood
听云 CTO

     2、APM + 统一化监控

   
保障应用性能表现是一项永无休止的任务,这其中将涉及多种产品、功能以及最佳实践。同时利用APM工具以及统一化监控工具为预生产与生产流程带入监控机制。APM工具会追踪/调整我们的应用与应用服务器活动,且通常能够通过事务合并掌握用户体验效果,开发团队与DevOps团队的人员非常需要这类帮助。统一化监控工具则会监控负责支持任务的基础设施,从而给IT运维团队帮上大忙。当然,DevOps也乐于拥有这种基础设施监控能力,因为这有助于提升IT运维团队的工作效率,反过来帮助DevOps保障应用交付。

                                  --Scott Hollis

Zenoss公司产品市场营销主管

    3、Devops

   
关键在于让你的DevOps团队参与进来。实际上开发与运维对于APM的审视角度略有不同,主要因为APM这一概念旨在利用多种互补方案解决与应用性能相关的问题。了解开发即Dev)与运维即Ops)所提出的不同要求是确保应用性能水平的重要前提。一旦明确两支队伍的具体要求,我们就能够在应用正式推出之前的短时间内构建起一套应用性能基准。通过这一基准,我们能够更为透彻地理解应用,同时掌握如何收集性能指标再简洁的加以利用。

--Larry Dragich

APM战略集团创始人

兼Auto Club Group企业应用服务主管

   
即使在应用生命周期早期,运维也应当成为决策考量的重要组成部分。作为规划会议的参与者,保证其能够在与积压工作以及下一阶段开发目标相关的开发讨论当中发挥影响力。运维团队关注的内容需要与用户背景或者运维背景相结合,并作为重要信息反馈给开发团队。总的来说,DevOps代表的是一种企业文化的转变,即建立起以信任、开放与协作为核心的新型文化体系。

--Cameron Haight

Gartner公司IT运营与研究副总裁

   
目前企业的运维手段很难触及深入到业务级的应用性能管理。这并非是技术上的问题,而是由于传统的Web性能监控关注的焦点往往偏向后端,比如服务器本身的CPU、内存等,这种监控方式较标准化、规范化,获得的数据也更方便、直观。而当涉及到应用层面的性能监控时,需要将响应时间、数据库调用、缓存、SOA、RPC、External
API等,都作为监控的重要目标。在应用系统较复杂的情况下,还要涉及Web
Service的调用。这使运维人员非常苦恼,因为他们很难再找到一个标准化的方式去执行。

   
听云APM通过嵌码的方式深入应用代码中,通过调用的监测方式去监测业务代码的调用时间,出错与异常,并及时上报监测到的指标。通过对Web应用的性能和可用性进行监控和管理,发现和定位性能瓶颈和故障,并将其做成一种SaaS服务。依赖听云的SaaS平台,运维人员就可以在应用上线后,根据业务需求完成监控动作,而不再像之前只能依赖于研发才能实现某种功能,运维不再像原来那样,必须依赖于研发才能实现它的监控,这使研发、运维都能将更多的精力投入到对业务的更新迭代中去,加速了企业DevOps实现的进程。

--廖雄杰

听云技术副总裁

    4、移动APM

   
开发人员应当确保自己的清单当中包含一套企业级移动APM解决方案,能够报告移动应用性能水平给实际业务带来的影响。除了目标URL与应用操作响应速度等最基本的消费者吸引力因素之外,我们还应将更为复杂的商业活动条件纳入其中。

--Mike Marks

Aternity公司首席产品经理

    5、最终用户体验

   
性能优化工作从始至终都应当从最终用户角度出发。IT与生产团队需要以每一个数字化触点为基准掌握用户体验——包括Web、移动Web以及移动应用。当然,在正式发布之前进行负载测试同样非常重要,不过单纯以内部方式进行应用性能审查远远不够。为了确保应用具备与预期相符的性能水平,我们需要一套综合性解决方案,从而将开发、测试与运维团队统一起来,并对每一项事务进行合并与真实用户体验监控单凭抽样并不足以说明问题)。

 

   
只有这样,我们才能体会用户实际使用的真实感受。这类统一化方案不仅能够在问题出现之前即将其解决,同时也能确保理想的上市时间并立即找到任何问题的根源与解决办法。另外,它还能够加快新功能与新特性的迭代速度,同时确保性能始终保持在可行区间内的最佳状态。

--David Jones

Dynatrace公司技术专员主管

   
开发、IT运维以及DevOps团队的最终目标都是为了服务客户。这意味着他们需要将大部分精力用于关注最终用户体验。性能监控工具体系应当成为贯穿整个软件开发生命周期的重要组成部分。如果我们能够在开发或者分段过程中发现问题并加以修复,那么这干预成本就能保持在最低水平。不过最理想也最为可行办法仍然是在开发周期当中不断向生产环境推出小型增量式更新,并对各个发布版本进行广泛的全栈式监控。

--Dan Kuebrich

AppNeta公司应用性能产品主管

  注:本文系听云工程师编译整理

)
被文艺青年奉为爱情圣经的《爱在三部曲》第一部为我们描述了这样一个美好的故事:两个青年男女…

前言

日前需要开新项目,那么,就要新建一个svn及网站运行环境了。于是有Lee该文章。
好了,看这篇文章的时候你可以先看看:
阶段巨献 –
centos+php-fpm+mariaDB+svn+nodejs,配置linux的php和nodejs网站运行环境。
centos配置ocaml及unison进行双向文件同步搭建
【centos】配置postgresql数据库。
【java开发部署】利用svn及ocaml及unison进行javaweb网站部署

unison的配置

rsync同步文件

tomcat配置要点。

安装说明 
安装环境:CentOS-7.0.1406
安装方式:源码安装 
软件:apache-tomcat-7.0.29.tar.gz 
下载地址:http://tomcat.apache.org/download-70.cgi
安装前提 
系统必须已安装配置JDK6+,安装请参考:在CentOS-6.3中安装与配置JDK-7。
安装tomcat 
将apache-tomcat-7.0.29.tar.gz文件上传到/usr/local中执行以下操作:
代码如下:
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
[root@admin local]# cd /usr/local  
[root@admin local]# wget http://apache.fayea.com/apache-mirror/tomcat/tomcat-7/v7.0.57/bin/apache-tomcat-7.0.57.tar.gz  
[root@admin local]# tar -zxv -f apache-tomcat-7.0.29.tar.gz // 解压压缩包  
[root@admin local]# rm -rf apache-tomcat-7.0.29.tar.gz // 删除压缩包  
[root@admin local]# mv apache-tomcat-7.0.29 tomcat  
启动Tomcat
执行以下操作:
代码如下:
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
[root@admin ~]# /usr/local/tomcat/bin/startup.sh //启动tomcat  
Using CATALINA_BASE: /usr/local/tomcat  
Using CATALINA_HOME: /usr/local/tomcat  
Using CATALINA_TMPDIR: /usr/local/tomcat/temp  
Using JRE_HOME: /usr/java/jdk1.7.0/jre  
Using CLASSPATH: /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar  
出现以上信息说明已成功启动。
防火墙开放8080端口
增加8080端口到防火墙配置中,执行以下操作:
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
[root@admin ~]# vi + /etc/sysconfig/iptables  
#增加以下代码
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT  
重启防火墙
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
[root@admin java]# service iptables restart  
检验Tomcat安装运行
通过以下地址查看tomcat是否运行正常:
http://192.168.15.231:8080/
看到tomcat系统界面,说明安装成功!
停止Tomcat
[plain] view plaincopyprint?在CODE上查看代码片派生到我的代码片  
[root@admin ~]#  /usr/local/tomcat/bin/shutdown.sh   //停止tomcat  

背景说明

今天我要将AWS虚机升级到beta版本并进行一些测试。

由于beta版本只在公司内网提供,因此我需要将升级用的文件手动拷贝到AWS虚机中。原始的方法,很容易理解:

然而这就遇到一个问题,因为镜像文件有4.2GB大小,传输过程不仅占用带宽资源,而且还会浪费很多时间。

第一步、配置svn中的nodejs项目骨架

创建nodejs的项目的步骤为:
1 创建代码仓库
2 设定钩子–post-commit达到自动同步到网站目录的效果
3 设定nginx的子网站配置文件,开放相关端口
4 测试是否成功

需要注意的是,使用的是nodejs的express框架,需要在app.js里面设定使用的端口。这里采用预先采用的端口为:3007

这里有相关设置:
这里写链接内容

相关命令

这里将项目名称暂定为blue-hat
sudo mkdir -p /var/svn/blue-hat
sudo svnadmin create /var/svn/blue-hat
sudo vim /var/svn/blue-hat/conf/svnserve.conf
sudo vim /var/svn/blue-hat/conf/passwd
sudo vim /var/svn/blue-hat/conf/authz
sudo systemctl restart svnserve

注意,请根据参考资料一步一步完成配置,这里不啰嗦了。接下来,给项目添加一个对应的web运行目录,该目录路径初步定为:/usr/local/webroot/blue-hat

/usr/local/webroot/blue-hat

mkdir -p /usr/local/webroot/blue-hat
svn checkout svn://localhost/blue-hat /usr/local/webroot/blue-hat --username testuser --password abc --non-interactive

添加post commit

cd /var/svn/blue-hat/hooks
cp post-commit.tmpl post-commit
chmod +x post-commit
vi post-commit

这样修改

#!/bin/sh

# 库的路径
REPOS="$1"
# 新提交的版本号
REV="$2"

WEB=/usr/local/webroot/blue-hat
SVN=/usr/bin/svn
LOG=/usr/local/webroot/auto_svn.log


export LC_ALL=zh_CN.UTF-8

changed=$(svnlook changed -r $REV $REPOS)
log=$(svnlook log -r $REV $REPOS)
echo "now the changed is:$changed">>$LOG

n=$'\n'
$SVN update $WEB  --username testuser --password abc --non-interactive #更新到我们的目标网站目录。

重启svn

接下来就是svn的上传下载了

注意,开发环境不需要配置nginx+express

研究过程

配置postgres数据库

略,请自行用脚本进行配置

提醒,数据库的备份还原迁移都是必须要知道的。

方案1【被舍弃】

解决办法我首先想到将目录http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170621.0/compose/Server/x86_64/debug/tree/拷贝到虚机上,然后用它来做YUM源进行升级。但我很快就发现自己并不能确定哪些package是升级所需要的,因此只能上传全部的文件,这样做并不能有效解决问题。

配置java项目的svn

这里将项目名称暂定为blue-hat-server
sudo mkdir -p /var/svn/blue-hat-server
sudo svnadmin create /var/svn/blue-hat-server
sudo vim /var/svn/blue-hat-server/conf/svnserve.conf
sudo vim /var/svn/blue-hat-server/conf/passwd
sudo vim /var/svn/blue-hat-server/conf/authz
sudo systemctl restart svnserve

注意,这里不用配置post 钩子。因为源代码不可以直接执行的。

方案2【被舍弃】

其次,我想到在AWS虚机上安装客户端,通过VPN方式访问内网资源。这样做当然是可行的,只是openvpn配置起来需要将证书拷来拷去,这使我担心潜在的安全问题,也担心后续会过多地占用VPN服务器资源,因此这个想法只能作罢。

发表评论

电子邮件地址不会被公开。 必填项已用*标注