容器

Docker Build,Ship and Anywhere 1.基本概念 Docker Client:Docker提供给用户的客户端，功能就是提供给用户一个终端，用户输入docker提供的命令来管理本地或者远程的服务器。 Docker Server:Docker Daemon是主要组成部分，Docker服务的守护进程，功能接受Docker Client发过来的指令请求，并按照相应的路由规则实现路由分发。 Docker Images:Docker镜像，类比电脑装系统的CD盘，只读的CD Docker Registry:Docker Images的仓库，类比git，有私人的，有公共的，如github，docker提供了官方的Registry,Dock Hub Docker Container:Docker 容器，在容器里，跑项目程序、消耗机器资源、提供服务的地方；容器（Docker Container）通过镜像（Docker Images）启动，在镜像的基础上运行程序。可以理解为容器提供了硬件环境，然后使用了镜像这些制作好的系统盘，再加上项目程序，跑起来就可以提供服务。 理解上图：搭载Docker的主机，通过Docker Client使用 docker build docker pull docker run 让Docker Daemon从Docker

程序的耦合性： 耦合性(Coupling)，又叫耦合度，是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关 系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差( 降低耦合性，可以提高其独立 性)。 I o C容器 IoC 是 Inversion of Control 的缩写，即控制反转的意思，是解决程序耦合性的一种思想。通常创建对象的时候使用new关键字，控制权由程序员控制，而"控制反转"是指new实例工作不由程序员来做而是交给Spring容器来做。解决程序耦合性的办法有很多，而依赖注入（DI）这一功能就是IOC思想的一种具体实现 Spring pom.xml配置： <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.2.0.RELEASE</version> </dependency> </dependencies> Spring 项目结构依赖： Spring bean.xml的配置： <?xml version="1.0" encoding="UTF-8"?>

1. 虚拟化 1）什么是虚拟化 在计算机中，虚拟化(英语:Virtualization)是一种资源管理技术，是将计算机的各种 实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间 的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。这些资源的新虚 拟部份是不受现有资源的架设方式，地域或物理组态所限制。一般所指的虚拟化资源包括计 算能力和资料存储。 在实际的生产环境中，虚拟化技术主要用来解决高性能的物理硬件产能过剩和老的旧的 硬件产能过低的重组重用，透明化底层物理硬件，从而最大化的利用物理硬件 对资源充 分利用 虚拟化技术种类很多，例如:软件虚拟化、硬件虚拟化、内存虚拟化、网络虚拟化(vip)、 桌面虚拟化、服务虚拟化、虚拟机等等。 2. 什么是Docer 　　 docker是一种容器技术 。容器是直接运行在操作系统内核之上的用户空间。容器虚拟化也被称为“操作系统级虚拟化”，容器技术可以让多个独立的用户空间运行 在同一台宿主机上。 容器的局限性： 　　由于“客居”于操作系统，容器只能运行与底层宿主机相同或者相似的操作系统，这看 起来并不是非常灵活。例如:可以在 Ubuntu 服务中运行 Redhat Enterprise Linux，但无法再 Ubuntu 服务器上运行 Microsoft Windows。 　　相对于彻底隔离的管理程序虚拟化

//容器deque,双向队列，在内存中是分段连续的 //在内存中可以在左端，也可以在右端扩充，每次扩充，扩充一个buffer //排序时需要调用全局的sort #include <iostream> #include <deque> using namespace std; int main() { deque<int> d; d.push_back(3); d.push_back(4); d.push_front(2); d.push_front(1); d.pop_front(); d.pop_back(); for(auto x:d) cout<<x; } 来源： https://www.cnblogs.com/zmachine/p/12286319.html

//双向链表，比较节省内存，每次扩充只扩充一个单元//由属于自己的sort,为了提高运行的效率尽量不要采用全局的sort#include <iostream> #include<list> using namespace std; int main() { list<int> li; li.push_back(3); li.push_front(2); li.emplace_front(1);//优化改进的push_front; li.emplace_back(4); li.insert(++li.begin(),9);//在具体位置处添加对应的元素 for(auto x:li) cout<<x; return 0; } 来源： https://www.cnblogs.com/zmachine/p/12286288.html

请到这里看09-08-18更新版本 类似的多级浮动菜单网上也很多实例，但大部分都是只针对一种情况或不够灵活，简单说就是做死了的。 所以我就想到做一个能够自定义菜单的，有更多功能的多级浮动菜单。 而其中的关键就是怎么根据自定义的菜单结构来生成新菜单， 关键中的难点就是怎么得到下级菜单结构和容器对象的使用。 理想的做法是每次有下级菜单时，从对象直接取得下级菜单结构，放到容器对象中， 并且容器能重用，而不是每次都重新生成。 但想了很久也想不到适合的做法，直到做了 多级联动下拉菜单 终于得到了灵感。 放弃了直接取得下级菜单结构，而是每次都从原来的菜单结构中获取当前需要的下级菜单结构。 容器对象也不是自动生成，而是由用户先定义好（后来也做到能自动生成了）。 放下了这些包袱后，后面的开发就顺畅了。 特点： 1.根据自定义菜单结构生成菜单； 2.多级联动功能； 3.自定义浮动位置（上下左右）； 4.自定义延迟效果； 5.js控制编辑菜单； 6.可根据需要自动生产容器对象； 效果： //--> */ /*--> */ //--> 程序原理 程序是根据传统浮动菜单扩展而来，这里说一下几个比较关键或有用的地方： 【延时功能】 这个很多人 都懂，就是设个setTimeout计时器，这里有两个计时器，分别是容器计时器和菜单计时器。 容器计时器的作用是鼠标移到容器外面时隐藏容器

什么叫资源？ k8s中所有的内容都抽象为资源，资源实例化之后，叫做对象 。 在k8s中有哪些资源？ 工作负载型资源(workload) ： Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob(ReplicationController在v1.11版本被废弃) 服务发现及负载均衡型资源（ServiceDiscovery LoadBalance）： Service、Ingress、... 配置与存储型资源： Volume(存储卷)、CSI(容器存储接口,可以扩展各种各样的第三方存储卷) 特殊类型的存储卷： ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感数据)、DownwardAPI(把外部环境中的信息输出给容器) 以上这些资源都是配置在名称空间级别 集群级资源： Namespace、Node、Role、ClusterRole、RoleBinding(角色绑定)、ClusterRoleBinding(集群角色绑定) 元数据型资源： HPA(Pod水平扩展)、PodTemplate(Pod模板,用于让控制器创建Pod时使用的模板)、LimitRange(用来定义硬件资源限制的) 资源清单 什么是资源清单 在k8s中，一般使用yaml格式的文件来创建符合我们预期期望的pod

常用基础命令 环境：Linux Ubuntu 1.查看docker信息 docker version | docker info 2.启动docker服务 sudo systemctl start docker 3.列出本机所有的image文件 docker image ls | docker images 4.删除docker image docker image rm imageName 5.把docker文件从仓库抓到本地 docker image pull hello-world 6.运行一个image文件，生成一个容器 docker container run hello-world ps: ①docker container run命令具有自动抓取image文件的功能，如果发现本地没有指定的image文件，就会从仓库直接抓取。因此，docker image pull 不是必须的步骤 ②docker container run -p 8000:3000 --rm -it -v /home/dock/:/home/mount/ --name first koa-demo /bin/bash 通过： -p 容器端口与本地端口映射，冒号前为本地端口，冒号后为容器端口。这里的例子是将容器的3000端口映射到 8000端口 --rm 在容器终止运行后自动删除容器文件 -it

老版Abp对Castle的严重依赖在vnext中已经得到了解决,vnext中DI容器可以任意更换,为了实现这个功能,底层架构相较于老版abp,可以说是进行了高度重构.当然这得益于.Net Core的DI容器组件本身的优势.接着 abp vnext2.0核心组件之模块加载组件源码解析 上文,上文中我跳过了DI切换这个流程,因为我觉得这是整个框架的亮点之一,所以单独写了这篇随笔. .Net Core2.2之后,切换DI的实现换了,改成实现如下接口 1、核心ServiceProviderFactory接口实现 核心原理非常的简单,看看vnext如何实现这个工厂约束接口,并返回指定provider. 大致的逻辑是传入ServiceCollection,遍历ServiceCollection使用autofac的containerbuilder进行注入.最后调用containerbuilder实例的builder的build方法,返回provider.一气呵成,很简单. 接着,重点来了,看看Populate方法,看看其如何将ServiceCollection中的类型注入autofac容器的. 先将原生DI的相关功能转换成Autofac的,接着进行类型注册. 第一步获取模块加载类型中所有的模块,模块信息如下: 第二步释出DI容器中的ServiceRegistrationActionList

Docker的安全性 Docker的安全性主要体现在如下几个方面： Docker容器的安全性这是指容器是否会危害到宿主机或其他容器； 镜像的安全性用户如何确保下载下来的镜像是可信的、未被篡改过的； Docker daemon的安全性如何确保发送给daemon的命令是由可信用户发起的。用户通过CLI或者REST API向daemon发送命令已完成对容器的各种操作，例如通过docker exec命令删除容器里的数据，因此需要保证client与daemon的连接时可信的。 Docker容器的安全性 容器的安全性问题的根源在于容器和宿主机共用内核，因此受攻击的面特别大，另外，如果容器里的应用导致Linux内核崩溃，那么毫无疑问，整个系统哥都会崩溃。这一点与虚拟机是不同的，虚拟机与宿主机的接口非常有限，而且虚拟机崩溃一般不会导致宿主机崩溃。 在共用内核的前提下，容器主要通过内核的Cgroup和Namespace这两大特性来达到容器隔离和资源限制的目的。目前Cgroup对系统资源的限制已经比较完善了，但Namespace的隔离还是不够完善，只有PID、mount、network、UTS、IPC和user这几种。而对于未隔离的内核资源，容器访问时也就会存在影响到宿主机及其他容器的风险。 比如，procfs里的很多接口都没有被隔离，因此通过procfs可以查询到整个系统的信息，例如系统的CPU