分类目录归档:Linux

多用户 Docker 环境下 PyPi 源按需加速

这一篇算是接在上一篇Build a super fast on demand local PyPi mirror的后面吧~

这里会以 docker-compose 的方式为例子,详细写一下~不使用docker-compose的话,则也仅仅需要手动指定 pypicache 与需要这个服务的 container 到同一个 docker 网络中,这样就可以不用去找 pypicache 的 IP 地址,对最终用户透明化,不用增加额外的 pip 安装参数,即可轻松享受本地高速缓存,特别是对于大一点的文件效果更明显~

jupyterhub-docker
jupyterhub-docker

继续阅读多用户 Docker 环境下 PyPi 源按需加速

Build a super fast on demand local PyPi mirror

  • 当公司/局域网里有多人都使用 Python 开发,并且几乎都会用到 pip 来部署环境时,虽然已经有各种镜像源了,但是下载仍受限于与外网的宽带速度,并且同样的包可能被多人下载了多次,在包较大时,重复花的时间并不值
  • 当你使用 Docker 来构建不同的 Python 应用/环境时,在测试 Dockerfile 时可能需要不断的删掉之前 build 的版本,从头开始 build 时,pip 下载与上面面临同样的问题——重复消耗不必要的时间

其一解决方案是公司/局域网内部搞一个 PyPi 的镜像源,实际上维护一个完整的镜像源相当麻烦,占用的储存空间太大,在公司/局域网的情况下,大家开发的东西、使用的技术栈相对比较固定,这就导致完整的镜像源里会有很多包其实几乎没人用。

其二的解决方案可以是预先构建好一个或多个 Docker 镜像,其中包含大家都会用到的包,剩余的一些包则在使用时才被少数需要的人安装。这种方案的缺点则是目前 Docker 服务 + 多用户方案在重启之后会丢掉已经配置过的环境,重启之后依旧需要从镜像源下载包。

那么这里相对一劳永逸的方案则是搭建一个本地的按需下载的 PyPi 镜像源,其原理则是在镜像源与公司/局域网内增加了一个高速缓存,并且由于 PyPi 已经提交分发的whl或者tar.gz是不会变的,因此不用顾虑缓存时间的设置。

最后就像这样~ 182KB/s VS. 36.4MB/s
(cache server为千兆有线链接,MacBook为802.11 AC,测试时链接速度585Mbps)

It's apparently super fast after being cached!
It's apparently super fast after being cached!

继续阅读Build a super fast on demand local PyPi mirror

A brief tutorial on setup an AI lab server for a small team

这个是在之前导师的实验室积累的一些东西,使用场景的话,是适用于2-8人左右的小团队吧,当时有两台机器,一台是放在学校机房的服务器,CPU没注意是什么,印象中是64G内存,4块P20,貌似24G显存?;另一台机器则放在办公室,主要配置的话,一颗AMD Ryzen 2700X,64G内存,再附加两块1080ti 11G,经费肯定是还做不到一人分一块GPU,部分模型的大小也不需要完全独占一块GPU。但是构建一个小型团队使用的AI Lab服务器是没问题了。

当时搭建的AI Lab服务器的主要架构如下

AI Lab Platform Architecture
AI Lab Platform Architecture

系统方面选择了Ubuntu 18.04 LTS,简单方便,毕竟是做AI不是做OS,没有任何必要引入其他方面复杂的操作。然后在这之上则是系统层面的GPU驱动,当时对应的版本为396.26,目前已经有400版本号的驱动了。接下来就是与docker对接的nvidia的runc,由这个runc去给docker内的GPU提供支持。随后当时则是使用了支持多用户的JupyterHub,当然也可以通过分配多个账号解决,这一部分和之后的部分解决方案就很多了。

继续阅读A brief tutorial on setup an AI lab server for a small team

2 Days at LinuxCon 2017

有幸获得了 HACKx 赠送的 LinuxCon 2017 门票,于是便动身参加了 LinuxCon 2017,这也是 LinuxCon 首次在国内举行,顺便也在大会上见到了 Linus Torvalds。

Linus Torvalds @LinuxCon 2017
Linus Torvalds @LinuxCon 2017

这次的 LinuxCon 实际上是三个会议,其一不用说,就是 LinuxCon 了,然后是 ContainerCon 和 CloudOpen,官方合称为 LC3。此次 LC3 的 Keynote 和各展商的 Presentation 覆盖了以下 10 个方面

  • Programming Frameworks 编程框架
  • Application Platforms 应用平台
  • VM / VIM Managers 虚机管理
  • Containers 容器
  • Operating System 操作系统
  • Virtual Machines 虚拟机
  • Network Management & Orchestration
  • Carrier Networking 运营商网络
  • Network Controller 网络控制
  • Data Plane Services 数据平面服务

在这 10 个方面上,作为支撑的则是

  • Security 安全性
  • Governance, Operations & Ecosystem 运维
  • Licensing & IPR 许可和知识产权
  • Training & Certification 培训和认证

除了 Keynote Session 之外,各展商的 Presentation 都是同时在不同会议室展开的,我只去听了其中几场

  • Much Ado About Blocking: Wait/Wake in the Linux Kernel - Davidlohr Bueso, SUSE Labs
  • Rethinking the OS: A Travel Journal - Simora Arsene, SUSE
  • MD RAID1 and NVMe: High Performance Data Duplication - Coly (Yong) Li, SUSE Linux
  • Kubernetes Bootcamp 101 - Caicloud
  • LinuxCon K8S + TensorFlow Bootcamp 101 - Caicloud

要说什么的话,这次的 LC3 给我的感觉是(大部分)围绕 Container 来进行的,包括但不限于 SUSE、Intel、VMWare、Caicloud 在内的公司都在致力于为 Containter 提供更好、更易用、更安全的体验。

这里我挑选几个印象最深的来说说吧。

首先是 SUSE 正式发布了 SUSE MicroOS(Micro stands for Microservice),官方是这样描述的,

A purpose built Operating System designed for microservice & containers and optimized for large deployments.

一个专为微服务容器打造的,且为大规模部署优化过的操作系统。

主要特点则是

  • An always up-to-date Operating System
  • An easy to manage/upgrade OS
  • Easily setup/manage a cluster of nodes
  • scalable - up to 1000s of nodes

An always up-to-date Operating System(一个总是最新的操作系统)。关于更新这一点,可能有人遇到过更新之后出现问题的情况,SUSE 在这边使用了 Atomic Upgrade(原子更新),保证了在更新期间,即使出现了问题,也能回滚到更新前的状态。接下来,SUSE 做到 always up-to-date 的方案则是,一直在后台拉取更新,然后在系统负载低时进行更新。

SUSE MicroOS 则是作为 SUSE CaaS Platform 的组成之一,剩下则是 Kubernetes 和 Container Engines。

SUSE CaaS Platform 3 Key Technology Components v1.1
SUSE CaaS Platform 3 Key Technology Components v1.1
Source: https://www.suse.com/communities/blog/suse-caas-platform-whats-buzz/

关于 SUSE CaaS Platform 的更多信息,可以参考 SUSE 官方的博客

接下来则是 Intel 的 Clear Linux 和 Clear Container 技术。需要注意的是,虽然这两个项目命名方式类似,但是实际上是两个不相干的项目。

Clear Container 技术是为了给现有的 Container 提供一个虚拟机级别(例如 VMWare)的隔离。在现有的 Container Engine 技术中,由于不同的 Container 共享的是一个 Linux Kernel,如果其中一个感染了可以取得 Kernel 代码执行权限的病毒,那么这个病毒就可以绕过 Container Engine 的隔离,感染所有正在运行的 Container。

在 Clear Container 中,Intel 目前实现了与 Docker 无缝对接,利用 Intel VT-x 实现了 Kernel 级别的隔离,因此不同的 Container 也可以运行在不同版本的 Kernel 之上。当然,虽说是无缝对接,但是实际上还是多了一层,即 Intel VT-x 那层,据 Intel 的说明,目前在内部测试出来的开销并不大,启动一个 Container 只多 20ms 的样子,但是对文件读取的开销还没有非常明确,目前是将文件映射到内存以尽可能降低这方面的开销。

Clear Linux 则是另一个项目,这个项目的目标是构造一个尽可能小的 Linux 用于 Container,并且内核模块全部使用静态链接的方式换取速度与安全,如果你有特别的需求的话,可以自己在 Clear Linux 的基础上编译内核(当然也都是静态方式)。目前 Clear Linux 的 Container 镜像仅仅 5 MB。

Jetson TX1入手(/ω\)

其实在去年12月10来号的时候,就已经决定要入手一个Jetson TX1做开发了,一方面是因为现在使用的MacBook自带的Intel(R) HD Graphics 515性能比较低,当时用waifu2x把一个720P的视频拉到了2560x1440,跑了两周多吧……另一方面是想学习一些并行计算和机器学习的技术。于是就让梅子帮我拿到了一个教育版的Jetson TX1~(我们学校那时还没有教育邮箱,不过现在可以申请啦)

实际拿到Jetson TX1是在12月30号,不过当时刷完系统,装了torch 7之后发现居然就没剩多少了

df -h
df -h

于是剁了一块SSD(下个月吃土吧_(:_」∠)_)

继续阅读Jetson TX1入手(/ω\)

iOSOpenDev的补丁~

之前写过为iOSOpenDev增加指定设备端口功能 (English ver. is here),今天在看LPI的时候,书中提到了Linux的内核升级,其中就用了patch来给内核文件打补丁。

这样的方式比起我当时给出的“自己对应目录层级”覆盖文件好多了,于是就当是学习diff和patch的使用方法,做了一个iOSOpenDev的补丁,不过我是按照1.6-2版本的iOSOpenDev做的,其他版本的没有测试。

文件在这: iOSOpenDev.patch

Usage: sudo gzip -cd iOSOpenDev.patch.gz | patch -p0

继续阅读iOSOpenDev的补丁~