Deploy

问题场景： 当在Python Django项目中，创建多个APP应用，并且Django实现后端业务逻辑处理过程，属于（后端代码），既然后有后端代码，那基本会与前端代码（前端页面）进行人机交互操作。在此情况下，基本操作前端输入对应的参数和点击对应的按钮事件，将数据实时传输给后端代码进行业务处理，然后并在最短时间内反馈到前端，实现一次完整的输入输出过程（该过程实时并高效快速），但往往该情况属于实时处理，既然有实时，也存在异步操作，此处就以Python调用ansible执行自动化部署操作为例，在该例子中，前端提交部署请求，Python调用ansible进行部署处理，在处理过程中，一般简单操作会快速执行完成并返回结果数据，但当部署复杂的ansible操作时其中等待的时间会更长，给前端会处于等待状态，会因此带来拥塞情况和用户体验较差。针对此情况，Django项目有他处理的成熟方案。 解决方案： 根据以上提出的问题，进行分析，既要让用户不处于一直等待状态，又要让该任务后端异步执行，同时用户需要在任务执行完成后被动知道最终结果。综上所述得出方案：Django项目中采用celery异步任务执行+redis任务队列数据存储+执行任务结束回调过程。 具体实现：mysql存储执行结果日志，redis缓存，Django1.11.7，Python3.6.3（asstes项目，asstes_cd APP应用）

本文收录在 容器技术学习系列文章总目录 1、使用kubectl 1.1 介绍 kubectl 用于运行 Kubernetes 集群命令的管理工具。 1.2 语法 kubectl [command] [TYPE] [NAME] [flags] command ：指定要在一个或多个资源执行的操作，例如操作 create ， get ， describe ， delete 。 TYPE ：指定资源类型 Resource types 。 Name 区分大小写，如果省略 Name ，则显示所有资源的详细信息，例如： $ kubectl get pods 。 1.3 选项 Operation Description Syntax annotate 为一个或多个资源添加注释 kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] api-versions 列出支持的API版本。 kubectl api-versions [flags] apply 对文件或stdin的资源进行配置更改。 kubectl apply -f FILENAME [flags] attach

Replication Controller：用来部署、升级Pod Replica Set：下一代的Replication Controller Deployment：可以更加方便的管理Pod和Replica Set $ mkdir rc-demo $ vim rc-demo.yaml --- apiVersion: v1 kind: ReplicationController metadata: name: rc-demo labels: app: rc spec: replicas: 3 # selecter: # app: rc template: metadata: labels: app: rc spec: containers: - name: nginx-demo image: nginx ports: - containerPort: 80 $ kubectl edit rc rc-demo 在里面可以修改副本集数量 滚动更新: kubectl rolling-update rc-demo --image=nginx:1.7.9 ##(更新到1.7.9版本) ~~~~~RC不是实现一键回滚~~~~~ Deployment: Deployment主要职责和RC一样都是保证Pod的数量和健康 RC的全部功能：Deployment具备上面描述的RC的全部功能

参考： https://blog.51cto.com/wutengfei/2116663 创建和管理多个Pod--Deployment 　　Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。 你只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和ReplicaSet 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。 　　复制控制器（Replication Controller，RC） RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。 　　副本集

Chapter 17 Group Replication Table of Contents 17.1 Group Replication Background 17.1.1 Replication Technologies 17.1.2 Group Replication Use Cases 17.1.3 Group Replication Details 17.2 Getting Started 17.2.1 Deploying Group Replication in Single-Primary Mode 17.2.2 Deploying Group Replication Locally 17.3 Monitoring Group Replication 17.3.1 Group Replication Server States 17.3.2 The replication_group_members Table 17.3.3 The replication_group_member_stats Table 17.4 Group Replication Operations 17.4.1 Deploying in Multi-Primary or Single-Primary Mode 17.4.2 Tuning Recovery 17.4.3 Network

一、CI/CD 持续集成（continuous Integration,CI）：代码合并、构建、部署、测试都在一起。不断执行这个过程，并对结果反馈。 持续部署（Continuous Deployment，CD）: 部署到测试环境、预生产环境、生产环境。 持续交付（Continuous Delivery，CD）：将最终产品发布到生产环境，给用户使用 CI/CD 的最终目的是自动化，减少人工干预，提高总体的产品交付质量。 非容器化的CI/CD常出现因为环境不一致导致各种问题。 Pipeline优势： 项目发布可视化，明确阶段，方便处理问题 一个Jenkinsfile文件管理整个项目生命周期 Jenkinsfile可以放到项目代码中版本管理 Jenkinsfile 文件就是指pipeline script的脚本保存的文件。在流水线中，可以使用pipeline脚本文件，处理文件比之前每个项目都点击按钮去修改配置要方便。 Jenkinsfile保持在仓库中，在Jenkins里面调用即可： Jenkins 与Docker/Kubernetes的自动化CI流水实践 下面内容是核心，有4个步骤：拉取代码-代码编译-打包成镜像推送到镜像仓库-部署 镜像仓库： 填写上需要构建的版本。 以上是docker单机的发布流程。 下面讲解，基于kubernetes的集群实现方案

本文是 GitHub Action 的入门教程，如您已有相关使用经验可以直接关掉。 GitHub Action 是 GitHub 于 2018 年 10 月推出的一个 CI\CD 服务。 之前一直都是 Beta 版本，正式版于 2019 年 11 月正式推出。 首先还是先放几个官方的链接： GitHub Action ： https://github.com/features/actions GitHub Action 官方市场： https://github.com/marketplace?type=actions CI\CD CI\CD 其实说的是三件事情：「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」、「持续部署（Continuous Deployment）」。 因为「持续交付」和「持续部署」的英文缩写是一样的，所以这三件事情缩写成了 CI\CD 。 持续集成 那么什么是「持续集成」？借用一幅图： 从这幅图上可以很清楚的看到「持续集成」的流程： 开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程 向开发人员反馈结果的 report

立即使用新版本 Serverless Framework，只需一键扫码，便可快速新建和部署项目，还等什么，赶快加入体验吧~ 之前的版本中，我们只能通过 CLI 命令行的方式建立新项目及部署，需要了解 CLI，才能进行 serverless 应用部署，对很多小白用户不友好，有门槛。为此，我们推出一键部署的功能，极大地方便了新手或者喜欢通过 UI 界面操作的用户, 同时也减少了操作失误的可能。 新版本的 Serverless Framework 目前支持 scf 、 express 、 website 三个模板的一键扫码部署。 以 express 为例，访问： https://serverless.cloud.tencent.com/deploy/express 如果您的腾讯云账号还未登陆，使用微信扫一扫，授权登陆进行部署。 如果您已经登陆了腾讯云账号，如下图，直接点击「开始部署」即可。 进入部署状态页，如下： 3～5 秒即部署成功，可以看到我们的部署相关信息，如下： 访问 output apigw.url，您可以看到一个「hello express」框架应用已经部署成功啦~ {" msg " : " Hello Express , Request received : GET - /"} 接下来我们正式开发！ 直接点击上方「下载项目代码」红色按钮

函数计算（Function Compute） ： 函数计算 是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地可靠地运行任务，并提供日志查询、性能监控和报警等功能。借助函数计算，您可以快速构建任何类型的应用和服务，并且只需为任务实际消耗的资源付费。 访问 PostgreSQL 数据库是指在函数计算中通过编写代码调用数据库驱动库通过 TCP 协议实现对数据库进行的插入、查询等操作。通常函数计算中运行的不同函数实例之间是不共享状态的，对于结构化的数据可以通过数据库的形式进行持久化以实现状态共享。由于用户函数运行在函数计算的 VPC 中，而用户的数据库运行在用户所属的 VPC 中，所以在函数计算平台访问数据库会涉及到跨 VPC 访问的场景，下面我们先来介绍一下其工作机制。 工作机制 访问 PostgreSQL 的原理、工作机制与访问 Mysql 数据库完全相同，本文不再重复阐述，更详细的内容请参考 访问 Mysql 数据库 中的工作机制章节。 配置与函数编写 公共配置 创建专有网络VPC 登录 VPC控制台 。 参阅 VPC 搭建专有网络 创建VPC和交换机。 创建安全组 在 安全组控制台 新建安全组，点击 创建安全组 ，设置安全组名称，网络类型选择 专有网络 ，并选择刚才创建的专有网络。 注意

立即使用新版本 Serverless Framework，只需一键扫码，便可快速新建和部署项目，还等什么，赶快加入体验吧~ 之前的版本中，我们只能通过 CLI 命令行的方式建立新项目及部署，需要了解 CLI，才能进行 serverless 应用部署，对很多小白用户不友好，有门槛。为此，我们推出一键部署的功能，极大地方便了新手或者喜欢通过 UI 界面操作的用户, 同时也减少了操作失误的可能。 新版本的 Serverless Framework 目前支持 scf 、 express 、 website 三个模板的一键扫码部署。 以 express 为例，访问： https://serverless.cloud.tencent.com/deploy/express 如果您的腾讯云账号还未登陆，使用微信扫一扫，授权登陆进行部署。 如果您已经登陆了腾讯云账号，如下图，直接点击「开始部署」即可。 进入部署状态页，如下： 3～5 秒即部署成功，可以看到我们的部署相关信息，如下： 访问 output apigw.url，您可以看到一个「hello express」框架应用已经部署成功啦~ {" msg " : " Hello Express , Request received : GET - /"} 接下来我们正式开发！ 直接点击上方「下载项目代码」红色按钮