spec

今天接触了swagger，不得不为它惊奇，后端接口编写测试更加的动态化，更加的满足后端人员的需求。 转；http://www.cnblogs.com/JoiT/p/6378086.html 关于 Swagger Swagger能成为最受欢迎的REST APIs文档生成工具之一，有以下几个原因： Swagger 可以生成一个具有互动性的API控制台，开发者可以用来快速学习和尝试API。 Swagger 可以生成客户端SDK代码用于各种不同的平台上的实现。 Swagger 文件可以在许多不同的平台上从代码注释中自动生成。 Swagger 有一个强大的社区，里面有许多强悍的贡献者。 Swagger 文档提供了一个方法，使我们可以用指定的 JSON 或者 YAML 摘要来描述你的 API，包括了比如 names、order 等 API 信息。 你可以通过一个文本编辑器来编辑 Swagger 文件，或者你也可以从你的代码注释中自动生成。各种工具都可以使用 Swagger 文件来生成互动的 API 文档。 注意：用 Swagger 文件生成互动的 API 文档是最精简的，它展示了资源、参数、请求、响应。但是它不会提供你的API如何工作的其他任何一个细节。 Petstore 的 Swagger 例子 为了更好的理解 Swagger ，我们现在来探索一下 Petsotre 项目的例子。记住

核心API 想要灵活使用，就先知道几个核心API DragSource 用于包装你需要拖动的组件，使组件能够被拖拽（make it draggable） DropTarget 用于包装接收拖拽元素的组件，使组件能够放置（dropped on it） DragDropContex 用于包装拖拽根组件，DragSource 和 DropTarget 都需要包裹在DragDropContex内 DragDropContextProvider 与 DragDropContex 类似，用 DragDropContextProvider 元素包裹拖拽根组件。 大致理解这几个API的概念后，垃圾（Box.jsx）扔进垃圾桶（Dustbin.jsx）的代码将会是： // Box.jsx import { DragSource } from 'react-dnd'; @DragSource(type, spec, collect) export default class Box { /* ... */ } // Dustbin.jsx import { DropTarget } from 'react-dnd'; @DropTarget(types, spec, collect) export default class Contaier { /* ... */ } // Contaier.jsx

1.emptyDir存储卷 apiVersion: v1 kind: Pod metadata: name: cunchujuan spec: containers: - name: myapp #定义第一容器用于显示index.html文件内容 image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent volumeMounts: #调用存储卷 - name: html #使用存储卷的名称要和下面定义的一样 mountPath: /usr/share/nginx/html/ #在容器内部挂载的路径 - name: busybox #定义第二个容器用于产生index.html内容 image: busybox:latest imagePullPolicy: IfNotPresent volumeMounts: - name: html mountPath: /data/ command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done'] #该命令会不停向,存储卷的index.html文件追加时间 volumes: #定义存储卷 - name: html #定义存储卷名称 emptyDir: {} #定义存储卷类型 在上面

1.emptyDir存储卷 apiVersion: v1 kind: Pod metadata: name: cunchujuan spec: containers: - name: myapp #定义第一容器用于显示index.html文件内容 image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent volumeMounts: #调用存储卷 - name: html #使用存储卷的名称要和下面定义的一样 mountPath: /usr/share/nginx/html/ #在容器内部挂载的路径 - name: busybox #定义第二个容器用于产生index.html内容 image: busybox:latest imagePullPolicy: IfNotPresent volumeMounts: - name: html mountPath: /data/ command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done'] #该命令会不停向,存储卷的index.html文件追加时间 volumes: #定义存储卷 - name: html #定义存储卷名称 emptyDir: {} #定义存储卷类型 在上面

作者 | 子誉 蚂蚁金服高级技术专家 关注“阿里巴巴云原生”公众号，回复关键词 “入门” ，即可下载从零入门 K8s 系列文章 PPT。 Kubernetes 调度过程 首先来看第一部分 - Kubernetes 的调度过程。如下图所示，画了一个很简单的 Kubernetes 集群架构，它包括了一个 kube-ApiServer，一组 Web-hook Controllers，以及一个默认的调度器 kube-Scheduler，还有两台物理机节点 Node1 和 Node2，分别在上面部署了两个 kubelet。 我们来看一下，假如要向这个 Kubernetes 集群提交一个 pod，它的调度过程是什么样的一个流程？ 假设我们已经写好了一个 yaml 文件，就是下图中的橙色圆圈 pod1，然后往 kube-ApiServer 里提交这个 yaml 文件。 此时 ApiServer 会先把这个待创建的请求路由给我们的 webhook Controllers 进行校验。 通过校验之后，ApiServer 会在集群里面生成一个 pod，此时生成的 pod，它的 nodeName 是空的，并且它的 phase 是 Pending 状态。在生成了这个 pod 之后，kube-Scheduler 以及 kubelet 都能 watch 到这个 pod 的生成事件，kube-Scheduler

发布一个k8s部署视频：https://edu.csdn.net/course/detail/26967 课程内容：各种k8s部署方式。包括minikube部署，kubeadm部署，kubeasz部署，rancher部署，k3s部署。包括开发测试环境部署k8s，和生产环境部署k8s。 ———————————————— namespace： • 名称空间 • 用于隔离不同的应用 • 简称 ns 常用命令： • kubectl get namespaces • kubectl describe namespace default • kubectl create -f namespace- test.yaml • kubectl delete namespace test • kubectl apply -f namespace- test.yaml • kubectl label namespace test aa =bb • kubectl get ns -l aa =bb • kubectl label ns test aa - • kubectl edit ns test • kubectl annotate ns test aa =bb • kubectl annotate ns test aa - • kubectl delete ns test --force -

1.容器及其三要素 1.1.容器是什么 容器的本质是一种特殊的进程。 在linux容器中有三个重要的概念：Namespace、Cgroups、rootfs。 Namespace做隔离，让进程只能看到Namespace中的世界； Cgroups 做限制，让这个“世界”围着一个看不见的墙。 rootfs 做文件系统，rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。 这样就实现了进程在我们所看到的一个与世隔绝的房间，这个房间就是Pass项目赖以生存的"沙盒"。 1.2.Namespace 进入容器后，ps命令看到的容器的应用进程都是1号进程，这个其实是pid namespace导致，他其实就是个障眼法， 让你看到的是类似于一个新的虚拟机新环境，其实是不一样的，容器就是一个运行的进程，而容器中的其他进程则是pid为1的子进程。 除了刚刚pid namespace，还有其它的namespace如下： 容器是怎么新建namespace的？ docker创建容器，其实就是linux系统的一次fork的调用， 在进行fork调用时，会传入一些flag参数，这个参数可以控制对linux内核调用新的namespace。 1.3.rootfs 挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫作：rootfs

发布一个k8s部署视频：https://edu.csdn.net/course/detail/26967 课程内容：各种k8s部署方式。包括minikube部署，kubeadm部署，kubeasz部署，rancher部署，k3s部署。包括开发测试环境部署k8s，和生产环境部署k8s。 ———————————————— • 在 k8s 集群中， service 是一个抽象概念，它通过一个虚拟的 IP 映射指定的端口，将代理客户端发来的请求转到后端一组 pod 中的一个上。这是个神马意思呢？ pod 中的容器经常在不停地销毁和重建，因此 pod 的 IP 会不停的改变，这时候客户端就没法访问到 pod 了，现在有了 service 作为客户端和 pod 的中间层，它在这里抽象出一个虚拟 IP ，然后集群内部都可以通过这个虚拟 IP 访问到具体的 pod 。 常用命令： • kubectl get svc • kubectl label svc S erviceName type=s1 • kubectl label svc ServiceName type- • kubectl get svc -l type=s1 • kubectl describe svc ServiceName • kubectl edit svc ServiceName • Kubectl delete svc

spec网站： 1.USB spec https://www.usb.org/documents 2. USB官网 https://www.usb.org/ 源码查看： 1.android 在线代码： https://www.androidos.net.cn/sourcecode 2.linux在线代码： https://elixir.bootlin.com/linux/latest/source 来源： CSDN 作者： Super_shunzi 链接： https://blog.csdn.net/Super_shunzi/article/details/103674089

前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第2篇，开闭原则OCP（The Open/Closed Principle ）。 开闭原则的描述是： Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.软件实体（类，模块，方法等等）应当对扩展开放，对修改关闭，即软件实体应当在不修改的前提下扩展。 open for extension（对扩展开放）的意思是说当新需求出现的时候，可以通过扩展现有模型达到目的。而Close for modification（对修改关闭）的意思是说不允许对该实体做任何修改，说白了，就是这些需要执行多样行为的实体应该设计成不需要修改就可以实现各种的变化，坚持开闭原则有利于用最少的代码进行项目维护。 英文原文：http://freshbrewedcode.com/derekgreer/2011/12/19/solid-javascript-the-openclosed-principle/ 问题代码 为了直观地描述，我们来举个例子演示一下，下属代码是动态展示question列表的代码（没有使用开闭原则）。 // 问题类型var AnswerType = {