容器

Docker 镜像和容器的导入导出 一、镜像的导出和导入 1.镜像的保存 [root@k8s-master ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest ae513a47849c 2 months ago 109MB debian jessie 4eb8376dc2a3 2 months ago 127MB rabbitmq 3.6.8 8cdcbee37f62 15 months ago 179MB [root@k8s-master tmp]# docker save ae513a47849c > nginx-save.tar [root@k8s-master tmp]# ls -lh total 108M -rw-r--r-- 1 root root 108M Jul 4 09:32 nginx-save.tar 2.镜像的导入 可以将导出的nginx-save.tar包传到需要的docker主机上面，然后执行导入命令. [root@k8s-master tmp]# ls -lh total 108M -rw-r--r-- 1 root root 108M Jul 4 09:32 nginx-save.tar [root@k8s-master tmp]# docker load <

cgroup和namespace是实现容器底层的重要技术 cgroup：实现资源限制 namespace：实现资源隔离 1.cgroup：control group Linux操作系统通过cgroup可以设置进程使用CPU，内存和IO资源使用的限额。我们之前学习的通过-m，--memory-swap，-c，--blkio-weight就是通过cgroup实现的。那么cgroup到底是什么样子的呢？ 可以在 /sys/fs/cgroup 里面找到，例如： 我们运行一个容器，我们设置的cpu的权重是700 我们进入/sys/fs/cgroup/cpu/docker目录下的相应的容器的ID的目录里面，看cpu.shares，可以看到我们设置的权重是700 同样的我们进入/sys/fs/cgroup/memory/docker/中大概是memory.limit_in_bytes这个文件是容器内存的大小 同样的我们进入/sys/fs/cgroup/blkio/docker/中，blkio.weight这个文件是Block IO的权重文件 我们可以在以上的文件中，查看或者更改容器资源的大小 2.namespace 我们运行的每一个容器，都像是一个新的操作系统一样，都有文件系统，网卡等资源；那网卡来说，每个容器都会认为自己有一块独立的网卡，即使Host主机实际只有一块网卡资源

https://www.cnblogs.com/CloudMan6/p/7045784.html 为了更好地理解容器的特性，本节我们将讨论容器的底层实现技术。 cgroup 和 namespace 是最重要的两种技术。cgroup 实现资源限额， namespace 实现资源隔离。 cgroup cgroup 全称 Control Group。Linux 操作系统通过 cgroup 可以设置进程使用 CPU、内存 和 IO 资源的限额。相信你已经猜到了：前面我们看到的 --cpu-shares 、 -m 、 --device-write-bps 实际上就是在配置 cgroup。 cgroup 到底长什么样子呢？我们可以在 /sys/fs/cgroup 中找到它。还是用例子来说明，启动一个容器，设置 --cpu-shares=512 ： 查看容器的 ID： 在 /sys/fs/cgroup/cpu/docker 目录中，Linux 会为每个容器创建一个 cgroup 目录，以容器长ID 命名： 目录中包含所有与 cpu 相关的 cgroup 配置，文件 cpu.shares 保存的就是 --cpu-shares 的配置，值为 512。 同样的，/sys/fs/cgroup/memory/docker 和 /sys/fs/cgroup/blkio/docker 中保存的是内存以及

最近有闲，在工作之余重读了《effective STL》一书，并通过 twitter 记了一下笔记，今天整理收集到这里。 twitter 真的非常适合记读书笔记，哈哈，以后要好好地发扬。另，我的手机还是很老的 UIQ 3.0 的索爱手机，有没有达人推荐一些上推的应用程序？谢谢。 ==================================== #estl 第50条：熟悉与STL相关的web站点。三个：www.sgi.com/tech/stl、www.stlport.org 和 www.boost.org。 #estl 第49条：学会分析与STL相关的编译器诊断信息。嗯，第一招是替换大法，然后介绍了一下与容器、插入迭代器、绑定器、输出迭代器或算法相关的错误大概有什么套路看。 #estl 第48条：总是包含（#include）正确 的头文件。因为C++标准没有规定头文件的互相包含关系，所以不同的STL实现有所不同。要记住容器基本上声明在同名文件中，算法是algo..和 num..，迭代器在iterator中，函数子和配接器在functional中。 #estl 第47条：避免产生“直写型”（write-only）的代码。即所谓容易编写，但难以阅读和理解的代码，比如一行调用函数12次，其中 10 个是互不相同的。 #estl 第46条

读Spring源码之前，你要先清楚，为什么你要用Spring... Spring最基本的功能是做为管理bean的容器，所以我以为应该先从org.springframework.context包了解咯，包括org.springframework.web.context； 然后是org.springframework.beans org.springframework.aop 你看那个从core开始看就可以了 从ApplicationContext Spring中文手册是必须的～～ 1.阅读源码的入口在哪里？ 2.入门前必备知识了解：IOC和AOP 一、我们从哪里开始 1.准备工作：在官网上下载了Spring源代码之后，导入Eclipse，以方便查询。 2.打开我们使用Spring的项目工程，找到Web.xml这个网站系统配置文件，在其中找到Spring的初始化信息： [html] view plain copy < listener > < listener-class > org.springframework.web.context.ContextLoaderListener </ listener-class > </ listener > 由配置信息可知，我们开始的入口就这里ContextLoaderListener这个监听器。 在源代码中我们找到了这个类，它的定义是：

第一种：下载jetty插件 Help->Eclipse Marketplace 运行时配置访问路径及端口号 第二种：在pom.xml中配置jetty插件信息 <!-- maven 插件扩展clean jetty:run-war --> < plugin > < groupId > org.eclipse.jetty </ groupId > < artifactId > jetty-maven-plugin </ artifactId > < version > 9.2.18.v20160721 </ version > < configuration > < war > ${project.basedir}/target/${artifactId} </ war > < httpConnector > < port > 8088 </ port > </ httpConnector > < webAppConfig > < contextPath > /${project.artifactId} </ contextPath > </ webAppConfig > </ configuration > </ plugin > 运行时：run As–>maven build 第三种：配置tomcat window->show view->other->servers->finish

微服务的扩展立方模型 “扩展立方模型”是指微服务架构的在拆分时包括三个维度，如上图所示，X 轴表示水平副本，通过副本进行扩展；Y 轴表示功能解耦，通过分解功能，在不同模块之间的扩展；Z 轴是数据分区，一个系统会有一些业务和数据，微服务架构可以通过数据分区的形式进行扩展。 Docker 的两大核心技术 Docker 主要包含两个方面的技术： 一方面是容器技术，可以进行物理资源的有效分配与管理，并实现资源隔离，从这个角度看来，容器跟虚拟机的理念比较类似。容器的诞生会占 据虚拟机的一些市场，但不是完全替代虚拟机，主要是隔离强度的问题，容器技术是共享内核资源的，在一些比较严苛的状况下，虚拟机更胜一筹。 Docker 的第二个技术——镜像技术。打破了 “代码即应用” 的观念，Docker 真正实现了从系统环境开始，自底向上地打包一个软件。Docker 解决了软件的环境一致性问题，使得软件的分发与交付异常便捷。 Docker 如何让微服务架构更简单？ 如下图所示，结合微服务的「扩展立方」来看，Docker 镜像的一致性可以保证水平扩展，部署秒级，扩展立方的 Y轴，是功能解耦，可以把一个系统分成不同的模块，Docker 的优势是 application-centric，Docker 镜像完全独立。在数据分区方面，Docker 与数据服务结合，在这个方面，Docker 还有一些路要走。

文章目录 前言 1、Aware 系列接口 2、InitializingBean 3、BeanPostProcessor 4、BeanFactoryPostProcessor 5、ImportSelector 6、ImportBeanDefinitionRegistrar 7、FactoryBean 8、ApplicationListener 最后 前言 Spring 提供了非常多的扩展接口，官方将这些接口称之为钩子，这些钩子会在特定的时间被回调，以此来增强 Spring 功能，众多优秀的框架也是通过扩展这些接口，来实现自身特定的功能，如 SpringBoot、mybatis 等。 1、Aware 系列接口 Aware 从字面意思理解就是“知道”、“感知”的意思，是用来获取 Spring 内部对象的接口。Aware 自身是一个顶级接口，它有一系列子接口，在一个 Bean 中实现这些子接口并重写里面的 set 方法后，Spring 容器启动时，就会回调该 set 方法，而相应的对象会通过方法参数传递进去。我们以其中的 ApplicationContextAware 接口为例。 ApplicationContextAware 大部分 Aware 系列接口都有一个规律，它们以对象名称为前缀，获取的就是该对象，所以 ApplicationContextAware 获取的对象是

//容器vector,可以单方向扩展 //扩展的速度是以二倍的速度扩展 #include <iostream> #include <vector> using namespace std; int main() { vector<int> v;//定义一个空vector vector<int> v1(4);//定义一个大小为4的vector,初始值为0 vector<int> v2(4,6);//定义一个大小为4的vector,初始值为6 vector<int> v3{1,2,3,4,5};//定义一个vector,并初始化 for(auto x:v3) cout<<x; cout<<endl; cout<<v3[1];//获取元素的两种方式 cout<<v3.at(2); return 0; } //容器vector的一些基本操作 #include <iostream> #include <vector> using namespace std; int main() { vector<int> v; v.push_back(1); v.push_back(2); v.push_back(4);//在vector后追加数字 for(auto x:v) cout<<x; cout<<endl; v.resize(10);//重置大小，不赋值的话默认追加0 v[9]=8; v

过去几年开源界以OpenStack为代表的云计算持续火了好久，这两年突然又冒出一个叫Docker的容器技术，其发展之迅猛远超预料。 网上介绍Docker容器的文章已经很多了，用一句话概括：Docker是一种轻量虚拟化的容器技术，提供类似虚拟机的隔离功能，并使用了一种分层的联合文件系统技术管理镜像，能极大简化环境运维过程。 Docker容器云则是使用Docker技术打造的一站式容器云服务平台，即CaaS（Containers as a Service）——容器即服务；可以将它简单看作为PaaS的升级版，使用Docker容器技术的CaaS平台功能更强大，使用灵活，部署更方便。 Docker容器作为一个全新的概念虽然广受关注，但是对于如何使用Docker，将容器技术真正落地用起来，目前估计很多人还没有非常清晰的思路。写这篇文章主要目的就是根据Docker容器的特点，描述Docker容器到底能用来干什么，达到抛砖引玉的目的。 可以认为容器云是处于IaaS和PaaS之间的位置，容器编排集成度越高越像PaaS，反之越像IaaS，据此这里简单地将Docker容器的使用分两大类：主机和服务。 1. 作为云主机使用 相比虚拟机来说，容器使用的是一系列非常轻量级的虚拟化技术，使得其启动、部署、升级跟管理进程一样迅速，用起来灵活又感觉跟虚拟机一样没什么区别