容器

docker主要有镜像、容器、仓库三部分 一、镜像操作： 1.查看镜像： docker images REPOSITORY：镜像名称 TAG：镜像标签 IMAGE ID：镜像ID CREATED：镜像的创建日期（不是获取该镜像的日期） SIZE：镜像大小 这些镜像都是存储在Docker宿主机的/var/lib/docker目录下 2.搜索镜像： docker search 镜像名称 NAME：仓库名称 DESCRIPTION：镜像描述 STARS：用户评价，反应一个镜像的受欢迎程度 OFFICIAL：是否官方 AUTOMATED：自动构建，表示该镜像由Docker Hub自动构建流程创建的 3.拉取镜像： 从中央仓库中下载到镜像到本地 docker pull 镜像名称 4.删除镜像 docker rmi 镜像名称/id 或： docker image rm 镜像名称/id 删除所有镜像： docker rmi `docker images -q` 二、容器操作 1.查看容器： 查看正在运行的容器： docker ps 查看所有容器： docker ps -a 查看最后一次运行的容器： docker -l 查看已经停止的容器： docker ps -f status=exited 2.创建与启动容器 创建容器常用的参数说明： 创建容器命令：docker run -i：表示运行容器

零、前言 Collection是[收集品]的意思,这里称[容器],是java中的一个接口，位于 java.util 包下 Collection下有三大接口： List(列表) 、 Set(集合) 、 Queue(队列) Collection.png 容器接口子类及方法.png 第一节：List接口 List：列表，顾名思义是一种表结构，核心方法： 按索引插入元素 void add(int var1, E var2) 按索引删除元素 E remove(int var1); 按索引修改元素 E set(int var1, E var2) 按索引查询元素 E get(int var1) 特点： 1.增删改查操作都可以按照索引进行精确的控制，所以是元素的有序排列 2.允许相同元素 List子类.png List是java中使用频率非常高的一个接口，最要的子类：ArrayList、Vector、LinkedList 1.其中ArrayList、Vector是AbstractList-->AbstractCollection-->Collection 路线 2.LinkedList不止实现了List，还实现了Deque，就像得到两个师傅的真传，招式(方法)更多一些 Queue接口是队列(先进先出)，Deque接口(双端队列)是Queue的弟子，两头都能随意进出 所以根据需求即可当栈也可当队列

一、前言 以下为C语言实现的类似C++的STL中vector的容器 二、代码 ////////////cvector.h//////////////////////////////// #ifndef VECTOR_H #define VECTOR_H #include <stdlib.h> #include <assert.h> /////////结点存放自己的数据结构////////// typedef struct { char name[10]; int id; }node; typedef struct VectorSt { int size; int maxSize; node *data; } *Vector; Vector VectorNew(void); void VectorPushBack(Vector v, node e); node VectorPopBack(Vector v); node VectorGet(Vector v, int index); int VectorSize(Vector v); int VectorMaxSize(Vector v); void VectorRm(Vector v, int index); void VectorDelete(Vector v); #endif ////////////cvector.c/////

记录一下docker的日常使用命令，本文主要针对linux + mac操作系统而言，window是否适用不太确定，谨慎使用 <!-- more --> 1. docker进程 docker进程启动、停止、重启，常见的三种case # 启动docker service docker start # 关机docker service docker stop # 重启docker service docker restart 2. 镜像操作 镜像作为容器执行的前提条件，一般需要掌握的几个命令无非是搜索，下载，删除，创建 # 镜像列表 docker images # 检索镜像, 从镜像仓库中检索 docker search xxx # 下载镜像 docker pull xxx # 删除镜像 docker rmi xxx 关于创建镜像，有必要稍微详细一点点 # 通过容器创建镜像 docker commit -m="首次提交" -a="一灰灰Blog" dd85eb055fe8 yh/centos:v0.1 # 镜像历史查询 docker history yh/centos 上面的几个参数进行说明 -m 和git的提交一样，后面跟上描述信息 -a 版权声明，这个东西是我创建的，有啥问题，找我 dd85eb055fe8 容器id yhh/quick-os:0.1 创建的镜像名 3. 容器操作

容器自启动 Docker提供了restart policy机制，可以在容器退出或者Docker重启时控制容器能够自启动。这种Restart policy可以保证相关容器按照正确顺序启动。虽然也可以通过进程监控的方式(如systemd)来完成这种动作，但Docker还是建议尽量避免使用进程监控的方式来 "自启动" 容器。 Docker的 Restart policy与dockerd命令的--live-restore启动标志还有区别：--live-restore标志可以在Docker升级的时候保证容器继续运行，但是网络以及用户终端输入会被中断。 那到底什么是restart policy呢？我们来看看实际的情况吧。 在使用docker run启动容器时，使用--restart参数来设置： # docker run -m 512m --memory-swap 1G -it -p 58080:8080 --restart=always --name bvrfis --volumes-from logdata mytomcat:4.0 /root/run.sh --restart具体参数值详细信息： no - 容器退出时，不重启容器； on-failure - 只有在非0状态退出时才从新启动容器； always - 无论退出状态是如何，都重启容器； 如果创建时未指定 --restart

原文: Docker容器开机自动启动 Docker容器开机自动启动 容器自启动 Docker提供了restart policy机制，可以在容器退出或者Docker重启时控制容器能够自启动。这种Restart policy可以保证相关容器按照正确顺序启动。虽然也可以通过进程监控的方式(如systemd)来完成这种动作，但Docker还是建议尽量避免使用进程监控的方式来 "自启动" 容器。 Docker的 Restart policy与dockerd命令的--live-restore启动标志还有区别：--live-restore标志可以在Docker升级的时候保证容器继续运行，但是网络以及用户终端输入会被中断。 那到底什么是restart policy呢？我们来看看实际的情况吧。 在使用docker run启动容器时，使用--restart参数来设置： # docker run -m 512m --memory-swap 1G -it -p 58080:8080 --restart=always --name bvrfis --volumes-from logdata mytomcat:4.0 /root/run.sh --restart具体参数值详细信息： no - 容器退出时，不重启容器； on-failure - 只有在非0状态退出时才从新启动容器； always -

我们设置了docker自启动后，docker可以管理各种容器了，对于容器我们也可以设置重启的策略。 在容器退出或断电开机后，docker可以通过在容器创建时的--restart参数来指定重启策略； # 多个参数值选择 no 不自动重启容器. (默认值) on-failure 容器发生error而退出(容器退出状态不为0)重启容器,可以指定重启的最大次数，如：on-failure:10 unless-stopped 在容器已经stop掉或Docker stoped/restarted的时候才重启容器 always 在容器已经stop掉或Docker stoped/restarted的时候才重启容器，手动stop的不算 # 设置启动策略 docker run --restart always --name mynginx -d nginx 如果容器已经被创建，我们想要修改容器的重启策略 docker update --restart no mynginx 注意： 容器只有在成功启动后restart policy才能生效。这里的"成功启动"是指容器处于up至少10秒且已经处于docker监管。这是避免没有成功启动的容器陷入restart的死循环。 如果手动stop一个容器，容器设置的restart policy将会被忽略，除非Docker守护进程重启或者容器手动重启

spring 是父容器 springmvc是子容器。 子容器可以访问父容器，但父容器不能访问子容器 SpringMVC内的Bean可以使用@Autowire注入Spring容器管理的Bean，反之不行 在主容器中（applicationContext.xml），将Controller的注解排除掉 <context:component-scan base-package="com"> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" /> </context:component-scan> 而在springMVC配置文件中 <context:component-scan base-package="com" use-default-filters="false"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller" /> </context:component-scan> 自己总结：spring ioc注入除controller bean。 springmvc只需要注入controller

一.IoC的基础知识以及原理： IoC理论的背景： 在采用面向对象方法设计的软件系统中，底层实现都是由N个对象组成的，所有的对象通过彼此的合作，最终实现系统的业务逻辑。即软件系统中对象之间的耦合，对象A和对象B之间有关联，对象B又和对象C有依赖关系，这样对象和对象之间有着复杂的依赖关系，所以才有了控制反转这个理论。 什么是控制反转(IoC)： (1).IoC是Inversion of Control的缩写，有的翻译成“控制反转”，还有翻译成为“控制反向”或者“控制倒置”。 (2).1996年，Michael Mattson在一篇有关探讨面向对象框架的文章中，首先提出了IoC 这个概念。简单来说就是把复杂系统分解成相互合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展。IoC理论提出的观点大体是这样的： 借助于“第三方”实现具有依赖关系的对象之间的解耦 ，如下图所示： 即把各个对象类封装之后，通过IoC容器来关联这些对象类。这样对象与对象之间就通过IoC容器进行联系，但对象与对象之间并没有什么直接联系。 如果去掉IoC容器后系统中的对象A与对象B就有了直接关系，如下图所示： 比如好多的对象类要关联起来的话，就会变得很复杂，如下图所示： 所以提出IoC控制反转是很有必要的。 (3).为什么要把这种方式叫做控制反转呢？

注意： 在使用注解之前需要在Spring配置文件中配置以下内容开启注解扫描。 <context:component-scan base-package="cn.test"/> @Service用于标注业务层组件。 @Controller用于标注控制层组件（如struts中的action）。 @Repository用于标注数据访问组件，即DAO组件。 @Component泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标注。 @Autowired 默认按类型装配，如果我们想使用按名称装配，可以结合@Qualifier注解一起使用。如下： @Autowired和 @Qualifier("personDaoBean") 存在多个实例时配合使用。 @Resource默认按名称装配，当找不到与名称匹配的bean才会按类型装配。 @Required注解适用于bean属性的setter方法并且它指示，受影响的bean属性必须在配置时被填充在XML配置文件中，否则容器将抛出BeanInitializationException 例外。 实现依赖注入时执行顺序的概括： @Autowired 1. 匹配类型 2. 根据Qualifiers注解设置的名称 3. 根据名称 @Resource 1. 根据名称 2. 根据类型 3. Qualifiers无效