cli3创建vue项目是精简版的少了build和config这2个文件,所以配置开发环境.测试环境.生产环境的话需要自己创建env文件. 需要注意2点: 1.cli2创建项目生成的config文件里的env文件是js后缀 2.cli3创建自定义env文件的话不需要js后缀 下面开始创建配置: 一.直接在你项目的根目录创建三个文件(注意都没有后缀,直接创建新文件):.env.development (开发环境) .env.test(测试环境).env.production(生产环境) .env.d

先找到package.json  (这是nuxt版的vue 可能会跟一般vue不一样  当然总体上差不多的) "scripts": { "dev": "cross-env NODE_ENV=development nuxt", "pro": "cross-env NODE_ENV=production nuxt", "pre": "cross-env NODE_ENV=prer

新建一个配置js,导入到接口请求管理类,可以自动根据环境切换if (process.env.NODE_ENV == 'development') { baseUrl = ''; }else{ baseUrl = 'https://mainsite-restapi.ele.me'; } export { baseUrl, }

在测试账户系统过程中遇到了线上大面积用户登录态失效的严重问题,事后对于其原因及测试盲点做了一些总结记录以便以后查阅,总结分为以下7点,其中原理性的解释有些摘自网络. 1.账户系统token失效问题复盘2.Redis 经典流程3.Redis分片部署方式4.Redis扩容导致缓存数据失效5.Redis Sharding一致性hash算法6.缓存失效,缓存击穿,缓存穿透7.Redis缓存测试总结 账户系统token失效问题复盘现象:redis扩容后线上大量用户登录态失效,需要重新登录.由于登录态可以持

本文讲述如何使用fabric进行批量部署上线的功能 这个功能对于小应用,可以避免开发部署上线的平台,或者使用linux expect开发不优雅的代码. 前提条件: 1.运行fabric脚本的机器和其他机器tcp_port=22端口通 2.ssh可以登录,你有账号密码 一.先说批量部署上线 先上代码,再仔细讲解,脚本如下 # -*- coding:utf-8 -*- from fabric.colors import * from fabric.api import * from contextl

在上一篇 Docker + node(koa) + nginx + mysql 开发环境搭建,我们进行了本地开发环境搭建 现在我们就来开始线上环境部署 如果本地环境搭建没有什么问题,那么线上部署的配置也就很简单了 我所使用的环境,Linux Mint,命令有不同可以适当更改 目录结构 - compose 新建,线上环境配置 - data - conf - node_modules - static - docker-compose.yml - docker-compose-prod.yml 新建

通常情况下布署的三套环境:测试.预发及线上环境.调试或者辅助验证测试时,切环境改变量甚是麻烦.这些变量包括但不限于:一些url信息,数据库信息,预置用户信息等. 切换环境方法一:使用变量文件,通过判断运行时输入的变量来返回不同的环境信息    名称解释:变量文件中包含了测试数据中的变量,变量文件可以动态地创建任意类型的变量     下面是导入Variables 视图,导入变量文件时使用args,传入变量${env},实际值为运行时上图指定的变量值:online 以下是env_chang.py的内

Wechat开发笔记 线上环境搭建: 申请一个wechat公众平台. 手机个人微信可以用webwechat来测试. Website:https://web.weixin.qq.com/ 手机客户端扫一扫就可以登录. 在公众平台申请经过审核后,在左边菜单功能下高级功能,进入开发模式. 第一次进入开发者模式,需要填写接口的配置信息,url指向网络上的服务器中php文件. Token是 在服务器上要上传的php代码,示例代码可以从以上页面的接入指南中去下载. 打开Wx_sample.php文件. 对实

1.PM2介绍 PM2是一个线上环境下,用于启动nodejs进程守护的工具,用来保证服务的稳定及分摊服务器进程和压力. 2.下载安装 npm install pm2 -g  => pm2 --version  => 在package.json scripts中配置 "prd": "cross-env NODE_ENV=production pm2 start app.js" =>  npm run prd运行,运行结果如下图: 3.常用命令 启动:

目录 [测试右移]介绍 ELK Stack 介绍 ELK 监控体系搭建 ES & Kibana 搭建 Nginx 日志自动采集 Nginx Agent 安装 Nginx 服务器 数据分析 Logstash 搭建 [测试右移]介绍 为什么要做测试右移? 测试环境不能完全模拟线上环境. 线上质量不仅取决于已发布代码,还取决于数据变更与配置变更. 线上测试可以获得更多质量数据,以辅助产品更新. 测试右移主要实践: 应用监控 综合监控质量监控(ContinuousQuality Monitoring)

CAS (15) - CAS 线上环境 Ehcache Replication 的非稳定重现错误 摘要 线上环境在 EhCache Replication 过程中出现 java.util.ConcurrentModificationException 2016-12-21 14:58:02,022 ERROR [net.sf.ehcache.distribution.RMISynchronousCacheReplicator] - <Exception on replication of put

一.前言 通常我们在本地电脑上开发微信小程序,调用和访问小程序会有很多问题.特别是在配有自己后端的情况下,我们通过真机访问我们的小程序会出现不可访问的问题 二.线上环境搭建 在这里我们主要以腾讯云给大家做演示 1.注册并登陆腾讯云   https://cloud.tencent.com/ 2.上传代码 a.把客户端代码和服务端代码放置在微信小程序目录下 b.将客户端代码放置到client文件加中,服务端代码放置在server文件加中 c.把原微信小程序project.config.js文件转移到

正常情况下,hmaster会定期清理oldWALs文件夹,一般该文件大小也就几百兆,但是我们线上 环境出现了该文件没有自动回收情况,如图: 该目录占用hdfs空间多达7.6T,浪费空间: 后来经过多番查找,找到了问题所在,之前开启hbase复制之peers,参考博文连接如下: https://stackoverflow.com/questions/28725364/hbase-oldwals-what-it-is-and-how-can-i-clean-it 使用remove_peer,"id&

vue本身为运行脚手架项目自家搭载了一个nodejs后台环境,本地可通过proxyTable来处理跨域问题,但是上线(或生产环境)之后改域名真是一件麻烦的事情,所以进行一些配置. config/index.js proxyTable: { '/apis': { target: 'http://www.baidu.com', //域名,主要修改这一块 changeOrigin: true, pathRewrite: { '^/apis': '/' //注意名字 }, } }, //修改下面的两个文

故障前提 ElasticSearch 版本:5.2 集群节点数:5 索引主分片数:5 索引分片副本数:1 线上环境ES存储的数据量很大,当天由于存储故障,导致一时间 5个节点的 ES 集群,同时有两个节点离线,一个节点磁盘只读(机房小哥不会处理,无奈只有清空数据重新安装系统),一个节点重启后,ES集群报个别索引分片分配异常,ES索引出于保证数据一致性的考虑,并没有把重启节点上的副本分片提升为主分片,所以该索引处于个别主分片丢失 不可写入 状态(索引分片 red). 由于此图是后来取消副本数为0后

本文主要内容来自MongoDB官方文档http://docs.mongodb.org/manual/administration/production-notes/.并结合了实际工作情况进行分享. 1)软件包的选择 确保使用最新的稳定版本.目前我们线上使用的版本是2.4.6.MongoDB软件包下载页面http://www.mongodb.org/downloads. 确保线上环境总是使用64位版本.32位版本只能用于测试和开发使用,因为32位版本最大只能存储2GB的数据.启动MongoDB的时

在resources 新建application.properties 分开在resources 新建的多个环境的文件 #测试环境 applicaion-test.properties #开发环境 application-dev.properties #生产环境 application-prod.properties 然后在application.properties  里面配置   spring.profiles.active=dev ,表示配置开发环境,然后 在项目里面读取,如 @Value

前言 因为前段时间新项目已经完成目前趋于稳定,所以最近我被分配到了公司的运维组,负责维护另外一个项目,包含处理客户反馈的日常问题,以及对系统缺陷进行优化. 经过了接近两周的维护,除了日常问题以外,代码层面我一共处理了一个BUG,优化了三个问题,我把这四个问题归纳成了四段编码小技巧分享给大家,希望能有所帮助,今后若遇到类似的问题可以到我这里翻出来看看,想必能节省许多时间. 技巧 1.stream分组 很多人都知道java8的stream很好用,但很多人其实不会用,或者说搜了许多资料还是用不好,归根

利用Dump转储文件获取正式环境程序堆栈状态 服务异常找不到原因时,我们通常通过重新启动服务来尝试解决问题,但是在决定重启之前,请不要立刻重启Windows服务或站点 重启服务会让当前案发现场的内存证据丢失,即便是服务恢复正常了,也无法确认问题发生的原因,利用 Windows Dump 转储文件,可以将正在运行中的服务或站点的堆栈信息保存下来,然后在Visual Studio或WinDbg来查看线上服务的对象信息 Dump转储文件生成 Dump转储文件可以通过 任务管理器 -> 进程 -> 右

转自:https://blog.csdn.net/bntx2jsqfehy7/article/details/84207884一.一个新闻 新闻内容如下:php工程师执行redis keys * 导致数据库宕机! 某公司技术部发生2起本年度PO级特大事故,造成公司资金损失400万,原因如下: 由于php工程师直接操作上线redis,执行: keys * wxdb(此处省略)cf8* 这样的命令,导致redis锁住,导致CPU飙升,引起所有支付链路卡住,等十几秒结束后,所有的请求流量全部挤压到了r

运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态 先从原因分析一下为什么,问题就迎刃而解了. 首先是TIME_WAIT: 理解一下TIME_WAIT状态产生的原因,这个问题已经被很多很多的书说烂了,但是为什么很多人还是不能解决,究其原因还是因为 大多数都是学术派,并没有真正的遇到过这样的问题,因为TIME_WAIT大量产生很多都发生在实际应用环境中. TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭