Deploy

common子模块已经移除fastjson controller模块打包的时候还是依然报错 Could not resolve dependencies for project com.xiaomi.mipass:mipass-stats-controller:war:0.0.1-SNAPSHOT: Failure to find com.alibaba:fastjson:jar:1.2.21 in http://xxx/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced -> [Help 1] 这是子模块未deploy的缘故，maven打包的时候看不到，移除操作； 但是编译器idea确当做已经移除处理，所以tree dependency查不出来alibaba:fastjson:jar的依赖情况 两种解决办法： deploy common子模块 在controller的pom文件中引入common子模块中加上 <exclusion> <artifactId> fastjson </artifactId>

本文带大家来了解一下云函数的冷热启动过程，以及面对云函数这种冷热启动模式，开发者需要注意哪些问题。 本文来自 Serverless 社区用户「乂乂又又」投稿 效果展示 云函数被第一次调用（冷启动） 云函数被多次连续调用（热启动） 云函数的冷、热启动模式 先跟大家讲下这里的云函数冷热启动模式是什么意思。 冷启动是指你在服务器中新开辟一块空间供一个函数实例运行，这个过程有点像你把这个函数放到虚拟机里去运行，每次运行前都要先启动虚拟机加载这个函数，这是比较耗时的一个过程，所以云函数需要尽量减少自身冷启动的次数。 热启动则是说如果一个云函数被持续触发，那我就先不释放这个云函数实例，下次请求仍然由之前已经创建了的云函数实例来运行，就好比我们打开虚拟机运行完这个函数之后没有关闭虚拟机，而是让它待机，等待下一次被重新触发调用运行，这样做的好处就是省去了给虚拟机「开机」的一个耗时环节，缺点是要一直维持这个虚拟机的激活状态，系统开销会大一些。 当然这里的云函数资源分配的问题并不需要我们操心，云函数的底层会通过算法自行调配。 在腾讯云云函数文档里的 简介 里有这么一段描述： 腾讯云云函数是腾讯云提供的 Serverless 执行环境。您只需编写简单的、目的单一的云函数即可将它与您的腾讯云基础设施及其他云服务产生的事件关联。 使用云函数时，您只需使用平台支持的语言（Python、Node.js、PHP

Serverless 是全球流行的应用架构，Serverless 实现了自动伸缩扩容，稳定性好；不需要运维，按运行时间付费，降低了开发成本；门槛降低，让前端工程师有望成为全栈工程师。诸多优点，吸引了云厂商相继布局。 云函数 SCF 是腾讯云 serverless 团队为企业和开发者们提供的无服务器执行环境，目前支持 Java、node.js、PHP、Python、Golang 等多种语言，同时 Serverless 团队也在不断的丰富其组件库，目前已经支持 Node.js 的 Express、Koa、Egg 框架，以及 Python 的 Django 框架等。 更多参见： 产品概述 当用户使用云函数编写自己的业务逻辑时，以 Web 举例，需要通过网关调用接口，开源网关单节点容易宕机，多节点需要创建集群维护成本较高，所以大多数用户会选择腾讯云 API 网关，只需要几行网络请求的代码甚至不需要代码就可以使用，减少了人力成本。 Serverless Http 服务是基于腾讯云 API 网关和云函数的能力，支持 Swagger/OpenAPI 等协议，不需要用户配置，部署完成后，可通过 Dashboard 去查看 API 监控管理，如下图所示，极大的方便了用户快速上线自己的业务逻辑，通过规范的 API 支持内外系统的集成和连接。 对于 Web Service，Serverless HTTP

前言 最近在开发一套管理系统，做了前后端分离。 后台使用的是Asp.Net Core 3.1 前端使用的是Vue+Ant Design 自己搞了一台云服务器，打算把系统部署到云服务器上。以供外网访问。 服务器OS是WinServer2016 所以打算通过IIS平台来发部与部署系统。 后台部署 后台部署很好办。因为可以通过Visual Studio，使用IIS的Web Deploy组件一健发布到服务器 前端部署-手动 因为项目还小。要部署的也就一个前端，一个后端。也没有什么分布式部署。 显然现还用不到到通过工具自动从GIT拿代码，然后通过流水线自动构建这种大炮。 在没有使用PowerShell自己部署前，前端部署流程是： 1。通过npm run build:live编译，然后会把编译好的文件生成在dist目录 2。通过Windows远程桌面，连接到远程服务器。然后Ctrl+C,Ctrl+V把文件复制到服务器指定目录 因为dist目录文件数量太多，但是大小都比较小，直接复制可能比较慢。 一般是先用WinRAR把dist目录压缩一下。然后手动复制到服务器，然后解压到服务器目录。 这样速度上来说比直接复制快一点。 但是一想到后端可以通过VS一键发布到服务器，而前端就要通过手动的方式复制到服务器 这样的差距有点大。所以自己想通过写一些脚本达到自动部署的目的。 自动部署方案

背景交代 相信每个程序员都有自己做过个人网站,博客之类的项目了，但是现在还在维护吗？反正我前前后后做过2到3个了，维护一段时间后因为一些不可逆的原因(主要是懒)都没有维护了，购买的一些域名和服务器信息也都过期了，最近玩了一下hexo，发现这个东西挺方便的，基本半个小时就可以搞完，并且如果 完全托管在github上基本就是0成本，用作学习记录输出是够了。 1.依赖于nodejs安装，安装nodejs和npm 下载地址，可以对照电脑系统版本进行下载安装：https://nodejs.org/en/download/ 现在nodejs的安装包内置了npm，所以下载安装完成之后，nodejs和npm都会安装好 检查安装是否成功 安装成后会显示出对应的版本信息，由于我电脑之前就安装过了，所以应该不是最新的版本 2.安装hexo 安装命令： sudo npm i -g hexo 直接一步就安装完成了,然后可以通过hexo -v查看是否安装成，成功安装的话，会打印出上面截图中的一些版本信息 3.hexo初始化博客项目 命令： hexo init 初始化完成之后，看看hexo在文件夹给我生成了哪些文件 如果你是一名前端或者nodejs开发者，相信对这些文件再熟悉不过了，还是对上述几个文件简单解释一下： node_modules：存放依赖包信息 public：存放生成的页面 scaffolds

k8s 实战 备注： 用到的源代码可以联系QQ：122725501 索取即可 传统部署与k8s部署的区别 传统部署 k8s 部署架构 项目迁移到k8s的流程 制作镜像 镜像分类 基础镜像 环境镜像 项目镜像 控制器管理POD Deployment：无状态部署，例如Web，微服务，API StatefulSet：有状态部署，例如数据库，ZK，ETCD DaemonSet：守护进程部署，例如监控Agent、日志Agent Job & CronJob：批处理，例如数据库备份，邮件通知 Pod数据持久化 容器部署过程中一般有如下的三种数据 启动时需要的初始数据，可以是配置文件 启动过程中产生的初始化数据，该临时数据需要多个容器间共享 启动过程中产生的业务数据 暴露应用 使用Service ClusterIP类型暴露集群内部的应用访问 service定义了Pod逻辑集合和访问这个集合的策略 service引入为了解决Pod的动态变化，提供服务发现和负载均衡 使用coreDNS解析Service名称 对外发布应用 使用ingress对外暴露应用 通过Service关联Pod 基于域名访问 通过Ingress Controller实现pod的负载均衡 支持TCP/UDP四层和Http七层 部署Java/PHP项目 部署Java项目 构建环境镜像 $ mkdir ~/base_env/ && cd

关于git的基本操作 开始项目 开始项目了，我们要从仓库中将整个项目放到本地。首先我们要找到clone，复制地址 git clone [url] 切换分支 其次要先明白各种分支的目的：就实习的这个项目而言（dev/dev-deploy/release）dev所对应的就是日常开发环境；dev-deploy所对应的就是测试环境分支；release所对应的就是上线后的正式环境 git checkout branch-name 提交代码 当代码编写完成后，需要提交到仓库 git add . //相当于stage all differences git commit -m 'your message' // 说起commit貌似有一个commit规范 git push 拉取代码 在项目中有可能落后于整个项目的进度，此时就需要我们拉取代码 git pull 合并代码 分支间的代码进度会有所出入，此时需要进行合并代码 //在dev分支中合并dev-deploy的代码 git checkout dev git merge dev-deploy //在dev-deploy分支中合并dev的代码 git checkout dev-deploy git merge dev 本地创建新的分支/创建新的远程分支 // 从已有的分支上创建一个新的分支 git checkout -b branch-name /

Office 2019 中有哪些变化？ （Office 2019概述： https://docs.microsoft.com/zh-cn/deployoffice/office2019/overview ） ​（Office 2019安装： https://docs.microsoft.com/zh-cn/DeployOffice/office2019/deploy ） 从 Office 2016 起，最大的变化在于新的批量许可版本 Office 使用的是即点即用安装技术，而不是 Windows Installer (MSI)。 自 Office 2013 发布之后，大多数 Office 产品均采用的是即点即用安装技术。 除了即点即用之后，以下是你需要注意的一些其他更改： Office 2019 在 Windows 10 上受支持，但在在 Windows 7 或 Windows 8.1 上不受支持。 有关详细信息，请查看系统要求。 若要配置和执行安装，你可以使用 Office 部署工具，该工具可从 Microsoft 下载中心免费下载。 以前用于 Windows Installer (MSI) 的 Office 自定义工具不再使用。 你可以使用 Office 部署工具直接从 Internet 上的 Office 内容交付网络 (CDN) 上下载安装文件，而无需从批量许可服务中心

验证码识别是搞爬虫实现自动化脚本避不开的一个问题。通常验证码识别程序要么部署在本地，要么部署在服务器端。如果部署在服务器端就需要自己去搭建配置网络环境并编写调用接口，这是一个极其繁琐耗时的过程。 本文来自 Serverless 社区用户「乂乂又又」供稿 但是现在我们通过腾讯云云函数 SCF，就可以快速将本地的验证码识别程序发布上线，极大地提高了开发效率。 效果展示 可以看到，识别效果还是蛮好的，甚至超过了肉眼识别率。 操作步骤 传统的验证码识别流程是 图像预处理（灰化，去噪，切割，二值化，去干扰线等） 验证码字符特征提取（SVM，CNN 等） 验证码识别 下面我就带大家一起来创建、编写并发布上线一个验证识别云函数 第一步：新建 python 云函数 参见系列文章 《万物皆可Serverless之使用 SCF+COS 快速开发全栈应用》 第二步：编写验证识别云函数 Life is short, show me the code. 这里我就以一个最简单的验证码识别程序为例，直接上代码 import io import os import time from PIL import Image as image import json #字符特征 chars = { '1': [1, 1, 1, 0, 1, ...], '2': [1, 0, 0, 1, 0, ...], '3': [0,

1.修改配置文件 sed -i 's/nginx:v1/nginx:v2/g' image_update.yaml 重新应用配置文件 kubectl apply -f image_update.yaml kubectl get pod -o wide 2.使用patch命令 首先找的deployment kubectl get deploy 通过patch更新 kubectl patch deployment deployment名 --patch '{"spec" : { "template" : { "spec" : { "containers" : [{ "name" : "nginx" , "image" : "新image" }]}}}}' 3.使用set image 命令 kubectl set image deploy image-deployment *=registry.cn-beijing.aliyuncs.com/mrvolleyball/nginx:v2 来源： oschina 链接： https://my.oschina.net/u/3966437/blog/4498784