idwtwt的专栏

1 安装etcd kubernetes先卸载原来的docker-ce社区版yum autoremove docker-ce 安装etcd kubernetes（会附带安装docker）yum install -y etcd kubernetes修改配置文件/etc/sysconfig/docker OPTIONS='--selinux-enabled=false ...

1 构建gogs镜像出错Error parsing reference: "golang:alpine AS binarybuilder" is not a valid repository/tag: inval查了下需要更新docker,先删除原先的docker 597 yum remove docker 598 yum remove docker-common 5...

1 运行nginx实例kubectl run nginx --image=nginx --replicas=2 --port=802 查看pod[root@localhost ~]# kubectl get podsNAME READY STATUS RESTARTS AGEnginx-3449338310-tmlqp ...

原始dockerfile如下FROM alpine:latestMAINTAINER xxx "xxx@gmail.com"WORKDIR $GOPATH/src/appADD conf $GOPATH/src/app/confADD xxx $GOPATH/src/app/xxxRUN mkdir /lib64 && ln -s /lib/libc.musl...

文章原链接docker containerd shim分析// containerd-shim is a small shim that sits in front of a runtime implementation that allows it to be reparented to init and handle reattach from the caller.// the cwd of

由于最新分支在命令方面做了改变,与我研究的docker engine分支(1.13.0)不匹配,决定下个老点的分支来研究.具体方法是直接git下源码,然后:root@os:/opt/goHome/workspace/src/github.com/docker/containerd_bak# git tag0.0.20.0.30.0.40.0.5v0.1.0v0.2.0v0.2.1v0

镜像是按层下载和管理的，新镜像下载的文件临时存放在/var/lib/docker/tmp，文件命名方式是GetImageBlobxxx（xxx是一串随机数字），这些临时文件时按层打包为tar.gz等压缩包。临时文件首先被解压为tar包存在缓存中，然后使用docker\layer\layer_store.go的layerStore的Register函数注册到系统中，最后临时文件被删除。 在dock

镜像服务是镜像操作的抽象接口，实际上对镜像的操作包含两部分，镜像信息和镜像数据；镜像服务基于镜像持久化服务image.StoreBackend提供的接口实现镜像信息的操作，通过镜像层服务image.LayerGetReleaser提供的镜像层操作的的操作，因为镜像都是由镜像层组成，也就是实际操作镜像数据。他们之间的关系大概如下： 接着我们先看下镜像服务，镜像持久化服务和镜像层服务的接口定义

镜像仓库服务是docker对镜像仓库操作（如：拉取，提交，搜索等）的接口抽象，实现主要在docker目录下的registry包，下面是Service接口的定义，实现在docker\registry\service.go：// Service is the interface defining what a registry service should implement.type Service

在《pull命令实现与镜像存储（1）》和《pull命令实现与镜像存储（2）》我们分析pull命令在docker客户端的实现部分，最后我们了解到客户端将结构化参数发送到服务端的URL：/images/create。接下来我们将分析在服务端的实现部分，将从该URL入手。 我们在《dockerd路由和初始化》中了解了docker的API是如何初始化的，我们回顾下：func initRouter(s *a

之前docker的编译环境是在虚拟机上的ubuntu环境中的,最近想在一台物理机上的ubuntu上编译.于是按原来方法(网上找下一堆的)搭建了环境,敲命令:make binary.时间久不说,最后还老是失败,后来分析下原因,估计是墙的原因或镜像源已经更改了,导致找不到.因为docker源码编译时要先构建镜像docker-dev:master的,期间要下很多东西,一部失败就会进行不下去.后来试了几次之

在ubuntu16.04上支持overlay，docker直接启用了overlay，在ubuntu 14.04上还是用aufs。 查看支持的文件系统：root@os:~# modprobe overlay modprobe: FATAL: Module overlay not found.root@os:~# ls /lib/modules/3.13.0-32-generic/kernel/fs

我们在《docker命令解析》篇章我们了解了命令的解析过程，所以不再赘述。我们直接看执行命令任务的代码。 定位到docker\cli\command\commands\commands.go的AddCommands函数，我们容易找到pull命令的实现函数 在hide(image.NewPullCommand(dockerCli))注册。我们进入该函数：// NewPullCommand crea

看代码时，有时我们会需要验证我们对于程序逻辑的想法，于是我们会加一些调试日志，以帮助我们确认正确的程序逻辑。docker在代码中加了调试日志，只要在运行时加-D选项即可。但是这些调试日志是没有位置信息的。为了方便我们了解程序逻辑，我们为调试日志加上位置信息（文件名，函数名，行号等）。 在文件docker/vendor/src/github.com/Sirupsen/logrus/exported.

在《pull命令实现与镜像存储（1）》我们了解到拉取镜像时，runPull函数通过reference.ParseNamed(opts.remote)得到一个描述镜像信息的Named对象。以命令docker pull ubuntu:latest为例，将得到一个NamedTagged对象。我在看下reference.ParseNamed(image)：// ParseNamed parses s and

我们知道docker现在分为核心的服务端dockerd和接受用户命令的客户端docker。dcoker接受并解析客户端的操作指令，然后访问dockerd相应的url，让dockerd做实际的处理。dockerd实际上可简化为一个web后台，提供各种web接口API让docker访问。熟悉web开发的应该知道路由这个概念，现在我们就看看dockerd的路由以及初始化过程。 dcokerd的入口函数在

以前docker启动客户端和服务端使用的都是同一个命令（二进制可执行文件），现在docker将客户端程序和服务端程序分开了分别为docker和dockerd。而且docker的命令解析使用了一个第三方的库，名字叫cobra，github地址在：https://github.com/getting-started。客户端和服务端使用的是一样的命令解析方式，所以我们选取客户端分析docker的命令解析过

1.下载源码git clone git://github.com/lxc/lxc2.运行配置脚本，编译安装 cd lxc/./autogen.sh make && make install3.运行lxc相关命令测试：lxc-info4.相关问题运行命令遇到：lxc-info: error while loading shared libraries: liblx

对于开源项目阅读元源码似乎不可避免。开始网上看了下，有没有相关分析文章。搜了下，发现 孙宏亮写了《Docker源码分析》系列文章，但是是基于docker1.2.0的，而我git的是最新的1.12.1。想来也有参考性，就继续下去。按着《Docker源码分析(二)：Docker Client创建与命令执行》，docker客户端和daemon服务端都是通过docker命令启动的，通过不同参数区分启动