容器

需求;项目对外提供接口，要求每个对外接口都要进行token认证。 解决办法：写一个token认证的工具类，在每个需要认证的接口方法开始的地方，调用工具类中的token认证方法。 问题：因为要满足指定条件才可以进行下一步，在接口中调用token认证的时候，要返回结果进行判断，不止是一行代码可以解决问题。 优化：使用aop 切面编程，在执行接口的内容之前，进行认证。通过注解的方式，织入到切点中。这样在需要进行认证的接口上只需要添加一个注解就可以token认证功能。 问题：基于Aspect注解实现该功能，在程序启动时，访问接口，直接进入接口，没有进入切面。 AuthController @RestController public class AuthController { @PostMapping("authentication") @TokenChecker public Result getToken(String username,String password){ return null; } } 切面类：execution 表达式没有任何问题。 @Aspect @Component public class TokenAspect { 　　//匹配指定类下的有指定注解的方法。只要在要切入的方法上加上注解就可以将该方法作为切入点。 @Pointcut("execution

CSS3弹性盒布局方式 一、CSS3弹性盒子 弹性盒子是CSS3的一种新布局模式。 CSS3 弹性盒（ Flexible Box 或 flexbox），是一种当页面需要适应不同的屏幕大小以及设备类型时确保元素拥有恰当的行为的布局方式。 引入弹性盒布局模型的目的是提供一种更加有效的方式来对一个容器中的子元素进行排列、对齐和分配空白空间。 二、CSS3弹性盒模型常用的属性 属性 描述 flex-direction 指定弹性容器中子元素排列方式 flex-wrap 设置弹性盒子的子元素超出父容器时是否换行 flex-flow flex-direction 和 flex-wrap 的简写 align-items 设置弹性盒子元素在侧轴（纵轴）方向上的对齐方式 align-content 修改 flex-wrap 属性的行为，类似 align-items, 但不是设置子元素对齐，而是设置行对齐 justify-content 设置弹性盒子元素在主轴（横轴）方向上的对齐方式 1. flex-direction 属性 决定项目的方向。 注意：如果元素不是弹性盒对象的元素，则 flex-direction 属性不起作用。 属性值 值 描述 row 默认值。元素将水平显示，正如一个行一样。 row-reverse 与 row 相同，但是以相反的顺序。 column 元素将垂直显示，正如一个列一样。

郑昀 创建于2016/7/31 最后更新于2016/8/3 2014年年底，我们开始试着将原有的持续集成和持续发布流程，从 OpenStack 迁移到 Docker 上。后来，我整理过两篇文章讲容器私有云和持续发布都要解决哪些基础问题（ I ， II ）。 现在，OpenStack 又回来了，与 Docker 并肩作战。不管是容器化 OpenStack，还是 Docker 集群，做到这一步就解决问题了吗？ Docker+OpenStack，就够了吗？ 我们要的不仅仅是容器或虚拟机 我们都知道，Docker 实现的只是 镜像内部的小环境的一致性 ，它保证了一个应用程序在不同机器上运行时的一致性。 就我们之前持续经营了五年之久的 O2O 电商平台而言，首先它存在多条业务线： 团购 POP 平台 电影订座 网店通 …… 其次，它打通了供应链管理的全链条，从商机管理，销售行动管理，签约，终端设备铺设，……，到与商户的资金结算，与销售体系的佣金计算，与第三方支付的自动对账，与流量渠道的佣金对账，各种平台收费的核帐和摊销等等，加上外围技术支撑体系（如 天机和鹰眼 ）， 里里外外大约近百个 Java 和 PHP 工程，每个工程都是集群 。 这还不算上那些开源组件所需的集群，如 ZooKeeper，Redis， MyCat，Elastic Search，还不算上商业智能的那套体系。

Compose和Docker版本兼容性对应关系如下: docker compose的顶级配置项有: version 定义了版本信息 services 定义了服务的配置信息 services 的定义包含应用于为该服务启动的每个容器的配置，非常类似于将命令行的 docker container create networks 定义了网络信息，提供给 services 中的 具体容器使用 networks 的定义类似于命令行的 docker network create volumes 定义了卷信息，提供给 services 中的 具体容器使用 volumes 的定义类似于命令行的 docker volume create services 常用相关配置 container_name 指定容器名称。默认将会使用项目名称服务名称序号 container_name: nginx-front #指定容器名称后，该服务将不允许进行扩展（scale），因为Docker不允许多个容器具有相同的名称。 labels 定义容器的元数据（metadata）信息。例如可以为容器添加辅助说明信息 labels: com.startupteam.description: "webapp for a startup team" com.startupteam.department: "test

一般情况下，linux系统管理员通过ssh服务来管理操作系统，但是docker的很多镜像是不带ssh服务的，那么我们怎么样才能管理操作系统呢？ 我们学过attach ,exec的命令进入容器的方法，但是都无法解决远程管理容器的问题，因此，我们需要远程登录到容器内进行一些操作的时候，就需要ssh的支持了。 以下的镜像基于docker commit命令创建。 1. 首先使用ubuntu:14.04创建一个一个容器 docker run -it -v /opt/ssh:/opt/ssh ubuntu:14.04 /bin/bash 解释一下： 基于ubuntu的14.04版本的镜像启动一个容器 -it是为了让docker分配一个伪终端，并绑定到标准输入上，且让容器的标准输入保持打开。 -v 后面的是将本地的/opt/ssh目录挂到容器的/opt/ssh上面去（如果容器里面的/opt下面没有ssh目录，则直接会创建ssh目录），是为了将宿主机上面的文件拷贝到容器里面去。（主要是为了将authorized_keys文件从宿主机拷贝到容器中的去） 2.默认没有sshd服务，安装sshd服务 apt-get install openssh-server 一般会失败，这是因为ubuntu官方镜像中并没有包含软件包的缓存文件，使用如下命令来更新软件源信息： apt-get update 再使用

k8s之yaml详解 apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中 kind: Pod #指定创建资源的角色/类型 metadata: #资源的元数据/属性 name: web04-pod #资源的名字，在同一个namespace中必须唯一 labels: #设定资源的标签 k8s-app: apache version: v1 kubernetes.io/cluster-service: "true" annotations: #自定义注解列表 - name: String #自定义注解名字 spec:　　　　　　　　　　 #specification of the resource content 指定该资源的内容 restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器 nodeSelector: #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1 zone: node1 containers: - name: web04-pod #容器的名字 image: web:apache #容器使用的镜像地址 imagePullPolicy: Never #三个选择Always、Never

/*--> */ /*--> */ Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。 Docker技术的三大核心概念，分别是： 镜像（Image） 容器（Container） 仓库（Repository） 简单理解三者的对应关系： 其中，dockerfile是一种被docker程序解释的脚本，有一条一条的指令组成，每条指令对应Linux下的一条命令，docker程序解析这些命令间的依赖关系，根据指令生成定制的image。 常用命令： docker images #列出所有本地的docker images docker pull {REPOSITORY}:{TAG} #如docker pull dockerhub.xxx.com/rdb:cr 根据仓库名和标签拉取最新的docker 镜像 docker rmi IMAGE_ID #删除指定的images docker ps -a #显示所有的docker，包含不运行的；不使用-a则只显示正在运行的docker 使用docker ps -a查看docker images ，再使用 docker port container ID 可以查看该容器的端口映射情况 docker run {REPOSITORY}:{TAG} #启动docker 容器 docker start container ID #start docker

STL关联式容器 关联式容器： 跟STL中的序列式容器是相同的都是用来存储数据，与序列式容器不同的是，关联式容器存储的是<key，value>结构的键值对，在数据检索是，关联式容器的效率比序列式容器更高； 键值对： 用来表示具有一一对应关系的的一种结构；该结构值一般只包含量两个成员变量key和vlaue，其中key代表键值，value表示与key值对应的信息； 关联式容器底层数据结构： 树形结构 和 哈希结构 树形结构： set、map、muitimap、multiset 哈希结构： unordered_map、unordered_set 键值的结构表示： template < class T1 , class T2 > struct pair { typedef T1 first_type ; typedef T2 second_type ; T1 first ; T2 second ; pair ( ) : first ( T1 ( ) ) , second ( T2 ( ) ) { } pair ( const T1 & a , const T2 & b ) : first ( a ) , second ( b ) { } } ; make_pair template < class T1 , class T2 > pair < T1 , T2 > make_pair (

Calico容器网络方案 Calico共有两个容器网络方案：Calico BGP和Calico IPIP。 Calico BGP方案 Calico BGP数据面如下： 同节点容器通信 容器A访问容器B，数据面流程如下： 容器A内的calic0设备的掩码长度为32，即与容器B属于不同网络，需要通过网关进行通信 容器A查找路由表，存在default路由，下一跳为169.254.1.1，且169.254.1.1可通过cali0直达 容器A发送ARP请求给169.254.1.1，ARP请求报文到达veth设备的另一端califXXX接收 由于califXXX设备使能了ARP proxy，Linux内核会以califXXX的MAC地址来响应ARP请求，并从califXXX发出； 容器A收到ARP响应后，得到169.254.1.1的MAC地址，封装二层报文，发送报文给169.254.1.1，报文从cali0设备发出 报文通过veth设备进入Host内核协议栈； 由于目的IP不在本节点，Host内核会进行报文转发（ip_forward已开启） Host内核超找路由表，发现路由条目，通过califYYYYYY设备可以直达 Host内核发送ARP请求给容器B，通过califYYYYYY设备发出 ARP请求报文通过veth设备到达容器B，容器B响应ARP请求，ARP响应通过veth设备到达Host内核

简介 定义和运行多个 Docker 容器的应用，一个项目往往包含多个容器，每次重启都需要手动重启多个容器，显得太不简洁，而docker-compose就是一个完美的解决方案。 两个重要的概念 服务 (service)：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例 项目 (project)：由一组关联的应用容器组成的一个完整业务单元，在 docker-compose.yml 文件中定义。 安装 $pip install docker-compose $docker-compose --version 命令 因为docker-compose 是根据docker提供的api进行的一层封装，因此，只需要我们熟练掌握docker的命令，docker-compose的命令我想只需要记住如下两个即可。 $docker-compose up 该命令十分强大，它将尝试自动完成包括构建镜像，（重新）创建服务，启动服务，并关联服务相关容器的一系列操作。 链接的服务都将会被自动启动，除非已经处于运行状态。 可以说，大部分时候都可以直接通过该命令来启动一个项目。 默认情况，docker-compose up 启动的容器都在前台，控制台将会同时打印所有容器的输出信息，可以很方便进行调试。 当通过 Ctrl-C 停止命令时，所有容器将会停止。 如果使用 docker-compose up -d