Deploy

想法 最原始的办法是通过ftp或者winscp这样的工具能实现内容上传，但是不够简化，首先你要登录服务器，然后找到相应文件夹进行更新。 第二种方法是先更新gitee仓库，然后通过ssh登录服务器，然后从仓库pull下所有代码 第三种方法是不需要gitee仓库，直接在服务器建一个空仓库，然后把本地发布文件push到服务器仓库上 上面3种方法，第1种最原始，第2种比较繁琐，第3种简单可操作，但是第3种有一个问题，就是代码管理全部在服务器上，可视性比较差，能不能通过gitee管理代码，包括原始文件，然后一旦用户push，通过钩子函数，触发服务器主动拉取，这样，所有操作都简化为了本地的一个git push指令。说干就干，问了一圈度娘，果然高手在民间，几个关键步骤都有相应的帖子介绍。 第一步 建立hexo空仓库 本地把项目文件统统push上去，除了node_module文件夹。这样，项目文件也不会丢失，便于以后复用。 第二步 建立服务器到hexo仓库私钥通信 1. 创建ssh连接密钥 参看 https://gitee.com/help/articles/4181#article-header0 none ssh-keygen -t rsa -C "xxxxx@xxxxx.com" # Generating public/private rsa key pair... 产生两个文件：id

=============================================== 2019/12/8_第1次修改 ccb_warlock =============================================== 因为最近的工作项目使用的是mssql（自从知道mssql之后，我几乎不再说起另一个累赘的名字：sql server），不得不去重新学习使用mssql。 我的理解是，使用mssql仅仅只是使用数据表时，用docker运行一个开发用的容器比起在一台win server中安装一个来的高效且省资源。 当然如果还需要写存储过程及其调试，那还是用ssms来开发和调试吧（过程比起oracle、mysql虐心太多）。 因为我自学过docker、又喜欢折腾这种可以省时间的技术，所以整理了这篇笔记给路人参考。 一、前提条件 环境中已经部署了docker swarm（ http://www.cnblogs.com/straycats/p/8978135.html ） 最好也部署了portainer（ http://www.cnblogs.com/straycats/p/8978201.html ） 默认swarm创建了network：swarm-net 二、部署MSSQL 由于项目需要，我部署的是mssql 2017。 2.1 创建目录映射 mkdir -p

目录 0:00 微服务与网关（Microservices & API Gateways） 大家好，我叫Macro，今天我们谈论有关微服务和网关的话题。我是Mashape的CTO,也同时是开源网关Kong的开发者之一。Kong是一个API网关，今天我们就来窥探一下它究竟是怎么工作的以及它如何运用到你的微服务架构中去。 0:23 主题（Topics） 为了明白我们为什么需要API网关，我将从单体架构vs微服务架构谈起。这两个有什么不同点呢？然后我会介绍API网关模式以及它是如何适应“面向微服务”的架构的。然后我们会讨论Kong以及NGINX。 0:47 单体架构（Monolithic Architecture） Ok，过去几年我们目睹的一件事就是从单体应用到面向微服务的架构的过渡。我们都熟悉单体应用程序，以及它们通常的工作原理，这是一个简单的展示。我们把所有的东西都放到一块。而且通常也只有一个数据存储。 通过在多个服务器上重复部署相同的巨大代码块，可以横向扩展单体应用程序。所以每次我们调整应用程序时，我们其实相当于是在改动这些被放在一起的所有的模块，因为他们是一体的。 1:45 单体应用的优缺点（Monolithic Application Pros and Cons） 每一种做法，都有利弊。单体应用程序可以比较容易地构建，而且是以更小的代码库来开始

Step by step Deploy Oracle 11gR2 RAC+Active Dataguard QQ:908601287 Http://www.cnblogs.com/flymaster500.cn p Step y by p step l Install e Oracle 11gR2(11.2.0.3.0) RAC e +Active d Dataguard n on Oracle e Enterprise Linux(OEL 5 5.5 X86_64) 1 1 1 概述和说明 1 1.1 概述 本文档用于详细记录在 OEL 5.5 X86_64 位系统上 安装配置 e Oracle 11gR2(11.2.0.3.0) RAC 的步骤、 RAC 数据库的基本维护、为 RAC 创建单实例 e Active l Physical Dataguard、 验证 e Active Dataguard 的功能、 RAC 主库同单实例物理备库的角色转换等内容。 安装平台选择 VMware 公司的VMware ESXi Version 4.0 的虚拟主机，通过在该虚拟机 上配置两台 OEL 5.5 X86_64 位 Linux 系统的机器，然后在这两台 Linux 机器上配置 Oracle 11gR2 RAC 系统。其中，操作系统选择Oracle 公司的 OEL 5.5 X86_64

先看效果 kubectl apply -f deploy.yaml 执行上面的命令后，通过netstat -nltp 确认本机80、443是nginx进程在监听 apiVersion : v1 kind : Namespace metadata : name : ingress-nginx labels : app.kubernetes.io/name : ingress-nginx app.kubernetes.io/instance : ingress-nginx --- # Source: ingress-nginx/templates/controller-serviceaccount.yaml apiVersion : v1 kind : ServiceAccount metadata : labels : helm.sh/chart : ingress-nginx-2.0.3 app.kubernetes.io/name : ingress-nginx app.kubernetes.io/instance : ingress-nginx app.kubernetes.io/version : 0.32.0 app.kubernetes.io/managed-by : Helm app.kubernetes.io/component : controller name :

一、Deployment 定义 　　1、简介 [root@k8smaster manifests]# kubectl explain deploy（也可以写作deployment） KIND: Deployment VERSION: extensions / v1beta1 #属于该群组，但是1.10包括1.11版本中其已经被摞到另外一个群组 apps/v1 版中，因此这个文档的版本是落后于我们k8s自身的。 DESCRIPTION: DEPRECATED - This group version of Deployment is deprecated by apps /v1beta2/Deployment. #此版本也是老版的，当前1.11版本为apps/v1 See the release notes for more information. Deployment enables declarative updates for Pods and ReplicaSets. FIELDS: apiVersion < string > APIVersion defines the versioned schema of this representation of an object . Servers should convert recognized schemas to

pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体） 　　　

转载于网络 pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体）

1 以太坊开发与传统应用开发的差异 相比起传统应用而言，以太坊开发引入了新的基础设施，由此必不可少的带来了部署和运维的复杂度，比如作为系统设计者，我们需要做出选择： 自建节点，还是信任第三方节点？ 公有链、联盟链、私有链？ 由于加入了新的设计单元：智能合约，我们将面对 设计的复杂度 合约的升级问题：因为智能合约一旦发布就无法更改，万一需要更新合约错误或规则，怎么办？ 合约的组织问题。 与一般代码不同，合约的好坏直接与金钱挂钩 不安全的合约会造成客户的金钱损失，立竿见影。 合约的每一步都需要消耗gas，不讲究的合约会造成执行成本高居不下。 并且，以太坊本身的限制同样也会影响到整个应用系统的设计和选型： 交易确认需要时间：20笔/秒 交易易受外界影响 交易费的高低 流行应用会造成网络拥堵，从影响交易的确认 相比起传统CS编程，与以太坊进行交互要复杂得多： 需要有钱包账户 发出去的交易需要签名 由于整个过程是异步为主，因此交易需要验证 对于区块链本身的定位，同样也会影响设计： 仅仅用作数据共享和防篡改的基础设施？ 围绕区块链打造价值网络？ Token设计模式 Token引入对于业务本身带来的影响 这一点尤其差异巨大，不单单像传统开发那样仅仅只需要了解用户的业务就可以开足马力前进。Token设计本身需要一定的经济常识，虽说这部分可以由专业背景的人来设计，但对于开发者和架构师而言

Gerapy 是一款国人开发的爬虫管理软件（有中文界面） 　　 是一个管理爬虫项目的可视化工具，把项目部署到管理的操作全部变为交互式，实现批量部署，更方便控制、管理、实时查看结果。 gerapy和scrapyd的关系就是，我们可以通过gerapy中配置scrapyd后，不使用命令，直接通过图形化界面开启爬虫。 》》安装 pip install gerapy 》》配置环境变量 C:\Users\wangjialu\AppData\Local\Programs\Python\Python37\Scripts\ 》》cmd 初始化工作目录 >gerapy init 》》进入该目录初始数据库，会生成一个SQLite数据库，数据库保存主机的配置信息和部署版本。 > cd gerapy >gerapy migrate 》》启动服务 http://127.0.0.1:8000 访问界面 >gerapy runserver 》》部署项目 我们将Scrapy项目放在 gerapy/project 目录下。 添加Scrapy远程服务，我们的scrapy项目发布到Scrapyd上面。 或者 打开你的爬虫项目根目录 配置scrapy.cfg [deploy:abckg] url = http://localhost:6800/ project = Abckg #url 把#去掉 输入命令：scrapyd