在实际的项目中可能要访问生产环境是需要各种安全验证和设置的，毕竟客户的数据是最宝贵的资源。一般来说，客户会把一部分访问的权限开放出来。这样在系统出现问题的时候，能够更快更高效的处理问题。
下面是一个简单的图表，能够说明一下其中一个项目的网络访问情况。
右边的绿色区域是公司内部的环境，其中生产问题复现环境的权限较高，这个权限只会分配给部分的人，而开发测试环境是公开环境，开发测试人员都可以访问。
左边的区域是现场环境，生产环境包括现网环境和容灾切换环境，这个是根据需求可以切换的。同时现场测试环境是客户开发给我们的一个访问环境，我们可以通过公司的网络直接访问到现场的测试环境，然后通过现场测试环境来逐步的切换，直到连接到生产环境。
在系统升级和业务问题较多的时候，会尝试从生产环境中抽取很小的一部分数据，把数据以dump的形式拷贝到公司内部环境中的生产问题复现环境中。这样可以并行的排查很多不同的问题。
在问题比较多的时候，总是会收到比较多的邮件请求来拷贝dump文件，其实明白了原理无非就是通过scp/sftp等形式把文件一步一步的拷贝。做多了就感觉是体力活了。而且如果大半夜出现紧急问题，需要排查，需要拷贝文件的时候自己虽然比较忙乎，但是这种拷贝文件的工作还是比较苦闷的。
自己下决心来改进一下。
首先是访问生产环境的权限，我们申请了一个只读用户，只有权限可以访问到一个指定的目录。这样这个账户就可以开放给开发测试人员，不至于出现一些人为操作，他们只能够从生产指定的目录下拷贝文件到现场测试环境。
没法修改任何文件。从某种程度上就杜绝了一些潜在的问题。
其次是现场测试环境和公司内部环境之间的访问是单向的，意思就是只能通过公司内部网络来连接现场测试环境，不能够通过现场测试环境来连接公司内部环境。这样的话，如果要把文件从现场测试环境拷贝到生产问题复现环境的话，使用scp的时候就会有问题。因为生产问题复现环境是不能随便开放给开发测试人员的。所以考虑设置开发测试环境和生产问题复现环境是单向访问。开发测试环境和现场测试环境之间是单向访问。
按照这个思路一个dump文件要从生产环境拷贝的流程就是
生产环境->现场测试环境->开发测试环境->生产问题复现环境 整个流程都是单向的，需要配置单向的信任关系。这样就可以使用shell脚本来动态的实现了。
-->通过开发测试环境来获取现场测试环境的文件
这个部分是关键环节。可以在开发测试环境中使用下面的形式来调用
scp xxxx@现场测试环境:xxxxxx .
我写了如下的脚本来做了进一步的校验。
check_file_valid=`ssh xxxxx@10.196.28.xx "ksh check_file.sh ~/copyban_dump_copy/$1"`
file_not_exist_code=`echo $check_file_valid |grep WARNING|wc -l`
#echo $file_not_exist_code
if [[ $file_not_exist_code -eq 1 ]]
then
echo 'WARNING- source file doesnt exist,please check and try again!'
else
scp xxxx1@现场测试环境:~/dump_copy/$1 .
scp $1 xxxxx2@生产问题复现环境:~/dump_copy
fi
对应的脚本check_file.sh也需要拷贝到现场测试环境中
if [ -f $1 ]
then
echo 'file '$1' exists!'
else
echo 'WARNING -file '$1 ' doesnt exist!'
fi
这样的话，我如果输入的文件不存在或者名字不正确。就会先做校验。
$ ksh scpuat.sh aaa
WARNING- source file doesnt exist,please check and try again!
如果文件存在，就开始把文件先拷贝到开发测试环境中，然后拷贝到生产问题复现环境中。
一个简单例子如下，文件在内网传输会快很多，之间基本没有多少的延迟。
$ ksh scpuat.sh test
test 100% 37 0.0KB/s 0.0KB/s 00:00
test 100% 37 0.0KB/s 0.0KB/s 00:00
关于单向信任关系的建立，可以使用ssh-keygen -t rsa来实现。
需要把id_rsa.pub的内容拷贝从开发测试环境中拷贝到生产问题复现环境中
然后在生产问题复现环境中把id_rsa.pub的内容追加到.ssh/authorized_keys中。
这样使用scp,ssh的时候就不用输入密码了。
总体来说，这种实现要方便一些。而且很大程度上把我的工作解放出来不少。
下面是一个简单的图表，能够说明一下其中一个项目的网络访问情况。
右边的绿色区域是公司内部的环境，其中生产问题复现环境的权限较高，这个权限只会分配给部分的人，而开发测试环境是公开环境，开发测试人员都可以访问。
左边的区域是现场环境，生产环境包括现网环境和容灾切换环境，这个是根据需求可以切换的。同时现场测试环境是客户开发给我们的一个访问环境，我们可以通过公司的网络直接访问到现场的测试环境，然后通过现场测试环境来逐步的切换，直到连接到生产环境。
在系统升级和业务问题较多的时候，会尝试从生产环境中抽取很小的一部分数据，把数据以dump的形式拷贝到公司内部环境中的生产问题复现环境中。这样可以并行的排查很多不同的问题。
在问题比较多的时候，总是会收到比较多的邮件请求来拷贝dump文件，其实明白了原理无非就是通过scp/sftp等形式把文件一步一步的拷贝。做多了就感觉是体力活了。而且如果大半夜出现紧急问题，需要排查，需要拷贝文件的时候自己虽然比较忙乎，但是这种拷贝文件的工作还是比较苦闷的。
自己下决心来改进一下。
首先是访问生产环境的权限，我们申请了一个只读用户，只有权限可以访问到一个指定的目录。这样这个账户就可以开放给开发测试人员，不至于出现一些人为操作，他们只能够从生产指定的目录下拷贝文件到现场测试环境。
没法修改任何文件。从某种程度上就杜绝了一些潜在的问题。
其次是现场测试环境和公司内部环境之间的访问是单向的，意思就是只能通过公司内部网络来连接现场测试环境，不能够通过现场测试环境来连接公司内部环境。这样的话，如果要把文件从现场测试环境拷贝到生产问题复现环境的话，使用scp的时候就会有问题。因为生产问题复现环境是不能随便开放给开发测试人员的。所以考虑设置开发测试环境和生产问题复现环境是单向访问。开发测试环境和现场测试环境之间是单向访问。
按照这个思路一个dump文件要从生产环境拷贝的流程就是
生产环境->现场测试环境->开发测试环境->生产问题复现环境 整个流程都是单向的，需要配置单向的信任关系。这样就可以使用shell脚本来动态的实现了。
-->通过开发测试环境来获取现场测试环境的文件
这个部分是关键环节。可以在开发测试环境中使用下面的形式来调用
scp xxxx@现场测试环境:xxxxxx .
我写了如下的脚本来做了进一步的校验。
check_file_valid=`ssh xxxxx@10.196.28.xx "ksh check_file.sh ~/copyban_dump_copy/$1"`
file_not_exist_code=`echo $check_file_valid |grep WARNING|wc -l`
#echo $file_not_exist_code
if [[ $file_not_exist_code -eq 1 ]]
then
echo 'WARNING- source file doesnt exist,please check and try again!'
else
scp xxxx1@现场测试环境:~/dump_copy/$1 .
scp $1 xxxxx2@生产问题复现环境:~/dump_copy
fi
对应的脚本check_file.sh也需要拷贝到现场测试环境中
if [ -f $1 ]
then
echo 'file '$1' exists!'
else
echo 'WARNING -file '$1 ' doesnt exist!'
fi
这样的话，我如果输入的文件不存在或者名字不正确。就会先做校验。
$ ksh scpuat.sh aaa
WARNING- source file doesnt exist,please check and try again!
一个简单例子如下，文件在内网传输会快很多，之间基本没有多少的延迟。
$ ksh scpuat.sh test
test 100% 37 0.0KB/s 0.0KB/s 00:00
test 100% 37 0.0KB/s 0.0KB/s 00:00
关于单向信任关系的建立，可以使用ssh-keygen -t rsa来实现。
需要把id_rsa.pub的内容拷贝从开发测试环境中拷贝到生产问题复现环境中
然后在生产问题复现环境中把id_rsa.pub的内容追加到.ssh/authorized_keys中。
这样使用scp,ssh的时候就不用输入密码了。
总体来说，这种实现要方便一些。而且很大程度上把我的工作解放出来不少。
