ClearContainer 网络部分源码分析

// cc-oci-runtime/src/oci.c

/*!

* Create the state file, apply mounts and run hooks, but do not start the VM

*/

gboolean cc_oci_create(struct cc_oci_config *config)

(1)、依次调用cc_oci_config_file_parse(config),cc_oci_config_check(config),cc_oci_runtime_dir_setup(config)和cc_oci_handle_mounts(config)

(2)、当cc_pod_is_vm(config)为true时,调用cc_oci_vm_launch(config),否则调用cc_pod_container_create(config)

// cc-oci-runtime/src/process.c

/*!

* Start the hypervisor as a child process.

* Due to the way networking is handled in Docker, the logic here is unfortunately rather complex.

* \param config \ref cc_oci_config.

* \return \c true on success, else \c false.

*/

gboolean cc_oci_vm_launch(struct cc_oci_config *config)

(1)、调用setup_networking = cc_oci_enable_networking();   --->仅仅只是确定是否是root,因为要创建interface

...

(2)、调用config->state.status = OCI_STATUS_CREATED;

/* The namespace setup occurs in the parent to ensure the hooks run successfully. The child will

* automatically inherit the namespaces.

*/

(3)、调用cc_oci_ns_setup(config)

/* Connect to the proxy before launching the shim so that the proxy socket fd can be passed to the shim*/

(4)、调用cc_proxy_connect(config->proxy)

/* Set up comms channels to the child:

* - one to pass the full list of expanded hypervisor arguments.

* - one to allow detection of successful child setup: if the child closes the pipe,

* it was successful, but if it writes data to the pipe, setup failed.

*/

(5)、调用pipe2(child_err_pipe, O_CLOEXEC)和pipe2(hypervisor_args_pipe, O_CLOEXEC)

(6)、fork()一个子进程,在子进程中最终运行cc_oci_setup_child(config)以及execvp(args[0], args)

....

/* Run the pre-start hooks.

* Note that one of these hooks will configure the networking in the network namespace.

* If a hook returns a non-zero exit code, then an error including the exit code and the stderr is

* returned to the caller and the container is torn down.

*/

(7)、hook_status = cc_run_hooks(config->oci.hooks.prestart, config->state.state_file_path, true)

// add network config bits to following functions:

// - cc_oci_container_state()

// - oci_state()

// - cc_oci_update_options()

(8)、如果setup_networking为true,则依次调用hndl = netlink_init(),cc_oci_vm_netcfg_get(config, hndl)和cc_oci_network_create(config, hndl)

.......

// cc-oci-runtime/src/netlink.c

/*!

* Setup the netlink socket to use with netlink transactions.This handle should be used for all netlink

* transactions for a given thread.

*/

struct netlink_handle *netlink_init(void)

初始化一个netlink_handle实例

// cc-oci-runtime/src/process.c

/*!

* Obtain the network configuration by quering the network namespace.

* \param[in, out] config \ref cc_oci_config.

* \param hndl handle returned from a call to \ref netlink_init().

*/

private gboolean cc_oci_vm_netcfg_get(struct cc_oci_config *config, struct netlink_handle *hndl)

仅仅调用cc_oci_network_discover(config, hndl)

// cc-oci-runtime/src/networking.c

/*!

* Obtain the networking configuration of the container

* Currently done by scanned the namespace

* Ideally the OCI spec should be modified such that

* these parameters are sent to the runtime

*/

gboolean cc_oci_network_discover(struct cc_oci_config *const config, struct netlink_handle *hndl)

...

(1)、调用getifaddrs(&ifaddrs)  --> discover container interfaces

....

/*!

* Request to create the networking framework that will be used to

* connect the specified container network(veth) to the VM

*

* The container may be associated with multiple networks and function has to be invoked

* for each of those networks

* Once the OCI spec supports the creation of VM compatible tap interfaces in the network plugin

* this setup will not be required

*/

gboolean cc_oci_network_create(const struct cc_oci_config *const config, struct netlink_handle *const hndl)

/* Each container has its own namespace. Hence we use the same mac address prefix

* for tap interfaces on the host side. This method scales to support upto 2^16 networks

*/

遍历config->net.interfaces,

// cc-oci-runtime/src/namespace.c

/**

* Setup namespace.

* This should not strictly be required (since the runtime does not implement a "traditional linux" container).

* Howerver, namespace are used to pass network configuration to the runtime so the network namespace

* must be supported.

* \param config \ref cc_oci_config.

* \return \c true on success, else \c false.

* \todo Show the namespace path. For unshare, the strategy should be to call cc_oci_resolve_path (),

* passing it the value of ."/proc/self/ns/%s". The complication is that %s does *NOT* match the

* namespace names chosen by OCI, hence oci_ns_map will need to be extended to add a "gchar *proc_name" element

* \note in the case of error, check the value of errno immediately after this call to determine the reason.

*/

gooblean cc_oci_ns_setup(struct cc_oci_config *config)

从config中解析出network space的ns->path,并调用fd = open(ns->path, O_RDONLY),最后调用setns(fd, ns->type)加入该network namespace

时间: 2024-11-07 12:56:31

ClearContainer 网络部分源码分析的相关文章

电驴 emule 源码分析 (1)

关于电驴emule 的源码,网上有一个  叫刘刚的人 分析的 很多,但是如果你只是看别人的分析,自己没有亲身去阅读代码的话,恐怕很难  剖析整个系统. 关于emule  主要就是 连接 kad网络部分, 搜索部分,共享部分,下载部分,还有就是IRC聊天部分.IRC聊天部分应该不是大多数人想知道的重点,核心部分  还是kad网络的构造 和 下载部分 的实现. 我看了下 搜索部分,大致的过程是以下酱紫.  希望有更多 学习emule源码的人 一起交流共享. 1. 执行添加kad文件的过程. 读取ka

Docker源码分析(八):Docker Container网络(下)

1.Docker Client配置容器网络模式 Docker目前支持4种网络模式,分别是bridge.host.container.none,Docker开发者可以根据自己的需求来确定最适合自己应用场景的网络模式. 从Docker Container网络创建流程图中可以看到,创建流程第一个涉及的Docker模块即为Docker Client.当然,这也十分好理解,毕竟Docker Container网络环境的创建需要由用户发起,用户根据自身对容器的需求,选择网络模式,并将其通过Docker Cl

TeamTalk源码分析之login_server

login_server是TeamTalk的登录服务器,负责分配一个负载较小的MsgServer给客户端使用,按照新版TeamTalk完整部署教程来配置的话,login_server的服务端口就是8080,客户端登录服务器地址配置如下(这里是win版本客户端): 1.login_server启动流程 login_server的启动是从login_server.cpp中的main函数开始的,login_server.cpp所在工程路径为server\src\login_server.下表是logi

Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)

1 背景 还记得前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>中关于透过源码继续进阶实例验证模块中存在的点击Button却触发了LinearLayout的事件疑惑吗?当时说了,在那一篇咱们只讨论View的触摸事件派发机制,这个疑惑留在了这一篇解释,也就是ViewGroup的事件派发机制. PS:阅读本篇前建议先查看前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>,这一篇承接上一篇. 关于View与ViewGroup的区别在前一篇的A

HashMap与TreeMap源码分析

1. 引言     在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Java这么久,也写过一些小项目,也使用过TreeMap无数次,但到现在才明白它的实现原理).因此本着"不要重复造轮子"的思想,就用这篇博客来记录分析TreeMap源码的过程,也顺便瞅一瞅HashMap. 2. 继承结构 (1) 继承结构 下面是HashMap与TreeMap的继承结构: pu

Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)(Linux-3.0 ARMv7)【转】

原文地址:Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)(Linux-3.0 ARMv7) 作者:tekkamanninja 转自:http://blog.chinaunix.net/uid-25909619-id-4938395.html 前面粗略分析start_kernel函数,此函数中基本上是对内存管理和各子系统的数据结构初始化.在内核初始化函数start_kernel执行到最后,就是调用rest_init函数,这个函数的主要使命就是创建并启动内核线

Spark的Master和Worker集群启动的源码分析

基于spark1.3.1的源码进行分析 spark master启动源码分析 1.在start-master.sh调用master的main方法,main方法调用 def main(argStrings: Array[String]) { SignalLogger.register(log) val conf = new SparkConf val args = new MasterArguments(argStrings, conf) val (actorSystem, _, _, _) =

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三)

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三) 本文是SolrCloud的Recovery策略系列的第三篇文章,前面两篇主要介绍了Recovery的总体流程,以及PeerSync策略.本文以及后续的文章将重点介绍Replication策略.Replication策略不但可以在SolrCloud中起到leader到replica的数据同步,也可以在用多个单独的Solr来实现主从同步.本文先介绍在SolrCloud的leader到replica的数据同步,下一篇

zg手册 之 python2.7.7源码分析(4)-- pyc字节码文件

什么是字节码 python解释器在执行python脚本文件时,对文件中的python源代码进行编译,编译的结果就是byte code(字节码) python虚拟机执行编译好的字节码,完成程序的运行 python会为导入的模块创建字节码文件 字节码文件的创建过程 当a.py依赖b.py时,如在a.py中import b python先检查是否有b.pyc文件(字节码文件),如果有,并且修改时间比b.py晚,就直接调用b.pyc 否则编译b.py生成b.pyc,然后加载新生成的字节码文件 字节码对象