使用core-vagrant方式安装CoreOS

CoreOS是一种专门为运行类docker容器而生的linux发行版。与其他通用linux发行版(ubuntudebianredhat)相 比,它具有体型最小,消耗最小,支持滚动更新等特点。除此之外CoreOS内置的分布式系统服务组件也给开发者和运维者组建分布式集群、部署分布式服务应 用带来了极大便利。

CoreOS与知名容器Docker脚前脚后诞生,到目前为止已经较为成熟,国外主流云平台提供商如Amazon EC2Google Compute EngineMicrosoft AzureDigtial Ocean等均提供了CoreOS image,通过这些服务,你可以一键建立一个CoreOS实例,这似乎也是CoreOS官方推荐的主流install方式(最Easy)。

CoreOS当然支持其他方式的安装,比如支持虚拟机安装(vagrant+virtualbox)、PXE(preboot execute environment)安装以及iso install to 物理disk方式。如果仅仅是做一些实验,虚拟机安装是最简单也是最安全的方式。不过由于CoreOS的官方下载站在大陆无法直接访问(大陆程序员们好悲 催啊),因此这一最简单的虚拟机安装CoreOS的过程也就不那么简单了。

通过core-vagrant安装的直接结果是CoreOS被安装到一个VirtualBox虚拟机中,之后我们利用Vagrant命令来进行 CoreOS虚拟机的启停。CoreOS以及Vagrant都在持续演进,尤其是CoreOS目前在active dev中,版本号变化很快,这也是CoreOS滚动升级的必然结果。因此在安装操作演示前,我们有必要明确一下这个安装过程使用的软件版本:

    物理机OS:
        Ubuntu 12.04 3.8.0-42-generic x86_64
    VirtualBox:
        Oracle VM VirtualBox Manager 4.2.10
    Vagrant:
        Vagrant 1.7.3

    CoreOS:
        stable 717.3.0

    coreos-vagrant source:
        commit b9ed7e2182ff08b72419ab3e89f4a5652bc75082

一、原理

如果没有Wall,CoreOS的coreos-vagrant安装将非常简单:

1、git clone https://github.com/coreos/coreos-vagrant
2、编辑配置文件
3、vagrant up
4、vagrant ssh

但是现在有了Wall,步骤3:vagrant up会报错:无法连接到http://stable.release.core-os.net/amd64-usr/717.3.0/xx这个url,导致安装失败。

我大致分析了一下vagrant up的执行过程:

1、设置配置默认值

    $num_instances = 1
    $instance_name_prefix = "core"
    $update_channel = "alpha"
    $image_version = "current"
    $enable_serial_logging = false
    $share_home = false
    $vm_gui = false
    $vm_memory = 1024
    $vm_cpus = 1
    $shared_folders = {}
    $forwarded_ports = {}

2、判断是否存在config.rb这个配置,如果有,则加载。
3、设置config.vm.url,并获取对应的json文件:

{
  "name": "coreos-stable",
  "description": "CoreOS stable",
  "versions": [{
    "version": "717.3.0",
    "providers": [{
      "name": "virtualbox",
      "url": "http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.box",
      "checksum_type": "sha256",
      "checksum": "99dcd74c7cae8b1d90f108f8819f92b17bfbd34f4f141325bd0400fe4def55b6"
    }]
  }]
}

4、根据config.vm.provider(是virtualbox还是vmvare等)来决定采用哪种虚拟机创建逻辑。

这里我们看到,整个过程只需要从core-os.net下载两个文件:coreos_production_vagrant.boxcoreos_production_vagrant.json。如果我们提前将这两个文件下载到本地,并放在一个临时的http server下,修改Vagrantfile和coreos_production_vagrant.json这两个文件,就应该可以通过coreos-vagrant安装了。

二、coreos-vagrant安装single instance CoreOS

好了,根据上述原理,我们首先要下载coreos_production_vagrant.boxcoreos_production_vagrant.json这两个文件,根据我们的channel和版本选择,两个文件的下载地址分别为:

 http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.box
 http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.json

接下来就是不管你用什么梯子,只要把这两个文件下载到本地,并放到一个目录下就好了。

我们需要修改一下coreos_production_vagrant.json,将其中的url改为:
   
    "url": "http://localhost:8080/coreos_production_vagrant.box"

我们要将这两个文件放到一个local file server中,后续供core-vagrant访问。最简单的方法就是使用:

    python -m SimpleHTTPServer 8080

当然使用Go实现一个简单的http file server也是非常简单的:

//fileserver.go
package main

import "net/http"
import "log"

func main() {
    log.Fatal(http.ListenAndServe(":8080", http.FileServer(http.Dir("./"))))
}

接下来我们就可以按照正常步骤,下载coreos-vagrant并up了:

$git clone https://github.com/coreos/coreos-vagrant

修改Vagrantfile:

$ diff Vagrantfile Vagrantfile.bak
14,15c14,15
< $update_channel = "stable"
< $image_version = "717.3.0"

> $update_channel = "alpha"
> $image_version = "current"
55c55
<   config.vm.box_url = "http://localhost:8080/coreos_production_vagrant.json"

>   config.vm.box_url = "http://%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json" % [$update_channel, $image_version]

将user-data.sample改名为user-data,并编辑user-data,在etcd2下面增加一行:

      etcd2:
    name: core-01

将units:下面对于etcd2的注释去掉,以enable etcd2服务。(将etcd服务注释掉)

万事俱备,只需vagrant up。

$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider…
==> core-01: Box 'coreos-stable' could not be found. Attempting to find and install…
    core-01: Box Provider: virtualbox
    core-01: Box Version: 717.3.0
==> core-01: Loading metadata for box 'http://localhost:8080/coreos_production_vagrant.json'
    core-01: URL: http://localhost:8080/coreos_production_vagrant.json
==> core-01: Adding box 'coreos-stable' (v717.3.0) for provider: virtualbox
    core-01: Downloading: http://localhost:8080/coreos_production_vagrant.box
    core-01: Calculating and comparing box checksum…
==> core-01: Successfully added box 'coreos-stable' (v717.3.0) for 'virtualbox'!
==> core-01: Importing base box 'coreos-stable'…
==> core-01: Matching MAC address for NAT networking…
==> core-01: Checking if box 'coreos-stable' is up to date…
==> core-01: Setting the name of the VM: coreos-vagrant_core-01_1437121834188_89503
==> core-01: Clearing any previously set network interfaces…
==> core-01: Preparing network interfaces based on configuration…
    core-01: Adapter 1: nat
    core-01: Adapter 2: hostonly
==> core-01: Forwarding ports…
    core-01: 22 => 2222 (adapter 1)
==> core-01: Running 'pre-boot' VM customizations…
==> core-01: Booting VM…
==> core-01: Waiting for machine to boot. This may take a few minutes…
    core-01: SSH address: 127.0.0.1:2222
    core-01: SSH username: core
    core-01: SSH auth method: private key
    core-01: Warning: Connection timeout. Retrying…
==> core-01: Machine booted and ready!
==> core-01: Setting hostname…
==> core-01: Configuring and enabling network interfaces…
==> core-01: Running provisioner: file…
==> core-01: Running provisioner: shell…
    core-01: Running: inline script

登入你的coreos实例:
$ vagrant ssh
CoreOS stable (717.3.0)
core@core-01 ~ $

在vagrant up时,你可能会遇到如下两个错误:

错误1:

Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Could not open the medium storage unit '/home1/tonybai/.vagrant.d/boxes/coreos-stable/717.3.0/virtualbox/coreos_production_vagrant_image.vmdk'.
VBoxManage: error: VMDK: inconsistent references to grain directory in '/home1/tonybai/.vagrant.d/boxes/coreos-stable/717.3.0/virtualbox/coreos_production_vagrant_image.vmdk'  (VERR_VD_VMDK_INVALID_HEADER).

这个问题的原因很可能是你的Virtualbox版本不对,比如版本太低,与coreos_production_vagrant.box格式不兼容。可尝试安装一下高版本virtualbox来解决。

错误2:

core-01: SSH address: 127.0.0.1:2222
core-01: SSH username: core
core-01: SSH auth method: private key
core-01: Warning: Connection timeout. Retrying…
core-01: Warning: Connection timeout. Retrying…
core-01: Warning: Connection timeout. Retrying…

coreos虚拟机创建后,似乎一直无法连接上。在coreos的github issue中,有人遇到了这个问题,目前给出的原因是因为cpu的支持虚拟化技术的vt开关没有打开,需要在bios中将其开启。这主要在安装64bit box时才会发生。

到这里,我们已经完成了一个single instance coreos虚拟机的安装。vagrant halt可以帮助你将启动的coreos虚拟机停下来。

$ vagrant halt
==> core-01: Attempting graceful shutdown of VM…

三、  CoreOS cluster

上面虽然成功的安装了coreos,然并卵。在实际应用中,CoreOS多以Cluster形式呈现,也就是说我们要启动多个CoreOS实例。

使用vagrant启动多个coreos实例很简单,只需将配置中的$num_instances从1改为n。

这里我们启用config.rb这个配置文件(将config.rb.sample改名为config.rb),并将其中的$num_instances修改为3:

# Size of the CoreOS cluster created by Vagrant
$num_instances=3

该配置文件中的数据会覆盖Vagrantfile中的默认配置。

三个instance中的etcd2要想组成集群还需要一个配置修改,那就是在etcd.io上申请一个token:

$curl https://discovery.etcd.io/new

https://discovery.etcd.io/fe81755687323aae273dc5f111eb059a

将这个token配置到user-data中的etcd2下:

  etcd2:

    #generate a new token for each unique cluster from https://discovery.etcd.io/new
    #discovery: https://discovery.etcd.io/<token>
    discovery: https://discovery.etcd.io/fe81755687323aae273dc5f111eb059a

我们再来up看看:

$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider…
Bringing machine 'core-02' up with 'virtualbox' provider…
Bringing machine 'core-03' up with 'virtualbox' provider…
==> core-01: Checking if box 'coreos-stable' is up to date…
==> core-01: VirtualBox VM is already running.
==> core-02: Importing base box 'coreos-stable'…
==> core-02: Matching MAC address for NAT networking…
==> core-02: Checking if box 'coreos-stable' is up to date…
==> core-02: Setting the name of the VM: coreos-vagrant_core-02_1437388468647_96550
==> core-02: Fixed port collision for 22 => 2222. Now on port 2200.
==> core-02: Clearing any previously set network interfaces…
==> core-02: Preparing network interfaces based on configuration…
    core-02: Adapter 1: nat
    core-02: Adapter 2: hostonly
==> core-02: Forwarding ports…
    core-02: 22 => 2200 (adapter 1)
==> core-02: Running 'pre-boot' VM customizations…
==> core-02: Booting VM…
==> core-02: Waiting for machine to boot. This may take a few minutes…
    core-02: SSH address: 127.0.0.1:2200
    core-02: SSH username: core
    core-02: SSH auth method: private key
    core-02: Warning: Connection timeout. Retrying…
==> core-02: Machine booted and ready!
==> core-02: Setting hostname…
==> core-02: Configuring and enabling network interfaces…
==> core-02: Running provisioner: file…
==> core-02: Running provisioner: shell…
    core-02: Running: inline script
==> core-03: Importing base box 'coreos-stable'…
==> core-03: Matching MAC address for NAT networking…
==> core-03: Checking if box 'coreos-stable' is up to date…
==> core-03: Setting the name of the VM: coreos-vagrant_core-03_1437388512743_68112
==> core-03: Fixed port collision for 22 => 2222. Now on port 2201.
==> core-03: Clearing any previously set network interfaces…
==> core-03: Preparing network interfaces based on configuration…
    core-03: Adapter 1: nat
    core-03: Adapter 2: hostonly
==> core-03: Forwarding ports…
    core-03: 22 => 2201 (adapter 1)
==> core-03: Running 'pre-boot' VM customizations…
==> core-03: Booting VM…
==> core-03: Waiting for machine to boot. This may take a few minutes…
    core-03: SSH address: 127.0.0.1:2201
    core-03: SSH username: core
    core-03: SSH auth method: private key
    core-03: Warning: Connection timeout. Retrying…
==> core-03: Machine booted and ready!
==> core-03: Setting hostname…
==> core-03: Configuring and enabling network interfaces…
==> core-03: Running provisioner: file…
==> core-03: Running provisioner: shell…
    core-03: Running: inline script

$vagrant ssh core-02
CoreOS stable (717.3.0)
core@core-02 ~ $

可以看到Vagrant启动了三个coreos instance。关闭这些instance,同样用halt:

$ vagrant halt
==> core-03: Attempting graceful shutdown of VM…
==> core-02: Attempting graceful shutdown of VM…
==> core-01: Attempting graceful shutdown of VM…

四、小结

以上仅仅是CoreOS最基本的入门,虽然现在安装ok了,但CoreOS的各种服务组件的功用、配置;如何与Docker配合形成分布式服务系统;如何用Google Kubernetes管理容器集群等还需更进一步深入学习,这个后续会慢慢道来。

Go 1.5中值得关注的几个变化

GopherCon2015开幕之 际,Google Go Team终于放出了Go 1.5Beta1版本的安装包。在go 1.5Beta1的发布说明中,Go Team也诚恳地承认Go 1.5将打破之前6个月一个版本的发布周期,这是因为Go 1.5变动太大,需要更多时间来准备这次发布(fix bug, Write doc)。关于Go 1.5的变化,之前Go Team staff在各种golang技术会议的slide  中暴露不少,包括:

- 编译器和运行时由C改为Go(及少量汇编语言)重写,实现了Go的self Bootstrap(自举)
- Garbage Collector优化,大幅降低GC延迟(Stop The World),实现Gc在单独的goroutine中与其他user goroutine并行运行。
- 标准库变更以及一些go tools的引入。

每项变动都会让gopher激动不已。但之前也只是激动,这次beta1出来后,我们可以实际体会一下这些变动带来的“快感”了。Go 1.5beta1的发布文档目前还不全,有些地方还有“待补充”字样,可能与最终go 1.5发布时的版本有一定差异,不过大体内容应该是固定不变的了。这篇文章就想和大家一起浅显地体验一下go 1.5都给gophers们带来了哪些变化吧。

一、语言

【map literal】

go 1.5依旧兼容Go 1 language specification,但修正了之前的一个“小疏忽”。

Go 1.4及之前版本中,我们只能这么来写代码:

//testmapliteral.go
package main

import (
    "fmt"
)

type Point struct {
    x int
    y int
}

func main() {
    var sl = []Point{{3, 4}, {5, 6}}
    var m = map[Point]string{
        Point{3,4}:"foo1",
        Point{5,6}:"foo2",
    }
    fmt.Println(sl)
    fmt.Println(m)
}

可以看到,对于Point这个struct来说,在初始化一个slice时,slice value literal中无需显式的带上元素类型Point,即

var sl = []Point{{3, 4}, {5, 6}}

而不是

var sl = []Point{Point{3, 4}, Point{5, 6}}

但当Point作为map类型的key类型时,初始化map时则要显式带上元素类型Point。Go team承认这是当初的一个疏忽,在本次Go 1.5中将该问题fix掉了。也就是说,下面的代码在Go 1.5中可以顺利编译通过:

func main() {
    var sl = []Point{{3, 4}, {5, 6}}
    var m = map[Point]string{
        {3,4}:"foo1",
        {5,6}:"foo2",
    }
    fmt.Println(sl)
    fmt.Println(m)
}

【GOMAXPROCS】

就像这次GopherCon2015上现任Google Go project Tech Lead的Russ Cox的开幕Keynote中所说的那样:Go目标定位于高度并发的云环境。Go 1.5中将标识并发系统线程个数的GOMAXPROCS的初始值由1改为了运行环境的CPU核数。

// testgomaxprocs.go
package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Println(runtime.GOMAXPROCS(-1))
    fmt.Println(runtime.NumGoroutine())
}

这个代码在Go 1.4下(Mac OS X 4核)运行结果是:

$go run testgomaxprocs.go
1
4

而在go 1.5beta1下,结果为:

$go run testgomaxprocs.go
4
4

二、编译

【简化跨平台编译】

1.5之前的版本要想实现跨平台编译,需要到$GOROOT/src下重新执行一遍make.bash,执行前设置好目标环境的环境变量(GOOS和 GOARCH),Go 1.5大大简化这个过程,使得跨平台编译几乎与普通编译一样简单。下面是一个简单的例子:

//testcrosscompile.go
package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Println(runtime.GOOS)
}

在我的Mac上,本地编译执行:
$go build -o testcrosscompile_darwin testcrosscompile.go
$testcrosscompile_darwin
darwin

跨平台编译linux amd64上的目标程序:

$GOOS=linux GOARCH=amd64 go build -o testcrosscompile_linux testcrosscompile.go

上传testcrosscompile_linux到ubuntu 14.04上执行:
$testcrosscompile_linux
linux

虽然从用户角度跨平台编译命令很简单,但事实是go替你做了很多事情,我们可以通过build -x -v选项来输出编译的详细过程,你会发现go会先进入到$GOROOT/src重新编译runtime.a以及一些平台相关的包。编译输出的信息 太多,这里就不贴出来了。但在1.5中这个过程非常快(10秒以内),与1.4之前版本的跨平台编译相比,完全不是一个级别,这也许就是编译器用Go重写完的好处之一吧。

除了直接使用go build,我们还可以使用go tool compile和go tool link来编译程序,实际上go build也是调用这两个工具完成编译过程的。

$go tool compile testcrosscompile.go
testcrosscompile.o
$go tool link testcrosscompile.o
a.out
$a.out
darwin

go 1.5移除了以前的6a,6l之类的编译连接工具,将这些工具整合到go tool中。并且go tool compile的输出默认改为.o文件,链接器输出默认改为了a.out。

【动态共享库】

个人不是很赞同Go语言增加对动态共享库的支持,.so和.dll这类十多年前的技术在如今内存、磁盘空间都“非常大”的前提下,似乎已经失去了以往的魅 力。并且动态共享库所带来的弊端:"DLL hell"会让程序后续的运维痛苦不已。Docker等轻量级容器的兴起,面向不变性的架构(immutable architecture)受到更多的关注。人们更多地会在container这一层进行操作,一个纯static link的应用在部署和维护方面将会有天然优势,.so只会增加复杂性。如果单纯从与c等其他语言互操作的角度,似乎用途也不会很广泛(但游戏或ui领域 可能会用到)。不过go 1.5还是增加了对动态链接库的支持,不过从go tool compile和link的doc说明来看,目前似乎还处于实验阶段。

既然go 1.5已经支持了shared library,我们就来实验一下。我们先规划一下测试repository的目录结构:

$GOPATH
    /src
        /testsharedlib
            /shlib
                – lib.go
        /app
            /main.go

lib.go中的代码很简单:

//lib.go
package shlib

import "fmt"

// export Method1
func Method1() {
    fmt.Println("shlib -Method1")
}

对于希望导出的方法,采用export标记。

我们来将这个lib.go编译成shared lib,注意目前似乎只有linux平台支持编译go shared library:

$ go build -buildmode=shared testsharedlib/shlib
# /tmp/go-build709704006/libtestsharedlib-shlib.so
warning: unable to find runtime/cgo.a

编译ok,那个warning是何含义不是很理解。

要想.so被其他go程序使用,需要将.so安装到相关目录下。我们install一下试试:

$ go install -buildmode=shared testsharedlib/shlib
multiple roots /home1/tonybai/test/go/go15/pkg/linux_amd64_dynlink & /home1/tonybai/.bin/go15beta1/go/pkg/linux_amd64_dynlink

go工具居然纠结了,不知道选择放在哪里,一个是$GOPATH/pkg/linux_amd64_dynlink,另外一个则是$GOROOT/pkg/linux_amd64_dynlink,我不清楚这是不是一个bug。

在Google了之后,我尝试了网上的一个解决方法,先编译出runtime的动态共享库:

$go install -buildmode=shared runtime sync/atomic

编译安装后,你就会在$GOROOT/pkg下面看到多出来一个目录:linux_amd64_dynlink。这个目录下的结构如下:

$ ls -R
.:
libruntime,sync-atomic.so  runtime  runtime.a  runtime.shlibname  sync

./runtime:
cgo.a  cgo.shlibname

./sync:
atomic.a  atomic.shlibname

这里看到了之前warning提到的runtime/cgo.a,我们再来重新执行一下build,看看能不能消除warning:

$ go build -buildmode=shared testsharedlib/shlib
# /tmp/go-build086398801/libtestsharedlib-shlib.so
/home1/tonybai/.bin/go15beta1/go/pkg/tool/linux_amd64/link: cannot implicitly include runtime/cgo in a shared library

这回连warnning都没有了,直接是一个error。这里提示:无法在一个共享库中隐式包含runtime/cgo。也就是说我们在构建 testshared/shlib这个动态共享库时,还需要显式的link到runtime/cgo,这里就需要另外一个命令行标志:- linkshared。我们再来试试:

$ go build  -linkshared -buildmode=shared testsharedlib/shlib

这回build成功!我们再来试试install:

$ go install  -linkshared -buildmode=shared testsharedlib/shlib

同样成功了。并且我们在$GOPATH/pkg/linux_amd64_dynlink下发现了共享库:

$ ls -R
.:
libtestsharedlib-shlib.so  testsharedlib

./testsharedlib:
shlib.a  shlib.shlibname

$ ldd libtestsharedlib-shlib.so
    linux-vdso.so.1 =>  (0x00007fff93983000)
    libruntime,sync-atomic.so => /home1/tonybai/.bin/go15beta1/go/pkg/linux_amd64_dynlink/libruntime,sync-atomic.so (0x00007fa150f1b000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa150b3f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa150921000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa1517a7000)

好了,既然共享库编译出来了。我们就来用一下这个共享库。

//app/main.go

package main

import (
    "testsharedlib/shlib"
)

func main() {
    shlib.Method1()
}

$ go build -linkshared main.go
$ ldd main
    linux-vdso.so.1 =>  (0x00007fff579f7000)
    libruntime,sync-atomic.so => /home1/tonybai/.bin/go15beta1/go/pkg/linux_amd64_dynlink/libruntime,sync-atomic.so (0x00007fa8d6df2000)
    libtestsharedlib-shlib.so => /home1/tonybai/test/go/go15/pkg/linux_amd64_dynlink/libtestsharedlib-shlib.so (0x00007fa8d6962000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa8d6586000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa8d6369000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa8d71ef000)

$ main
shlib -Method1

编译执行ok。从输出结果来看,我们可以清晰看到main依赖的.so以及so的路径。我们再来试试,如果将testsharedlib源码目录移除后,是否还能编译ok:

$ go build -linkshared main.go
main.go:4:2: cannot find package "testsharedlib/shlib" in any of:
    /home1/tonybai/.bin/go15beta1/go/src/testsharedlib/shlib (from $GOROOT)
    /home1/tonybai/test/go/go15/src/testsharedlib/shlib (from $GOPATH)

go编译器无法找到shlib,也就说即便是动态链接,我们也要有动态共享库的源码,应用才能编译通过。

internal package

internal包不是go 1.5的原创,在go 1.4中就已经提出对internal package的支持了。但go 1.4发布时,internal package只能用于GOROOT下的go core核心包,用户层面GOPATH不支持internal package。按原计划,go 1.5中会将internal包机制工作范围全面扩大到所有repository的。我原以为1.5beta1以及将internal package机制生效了,但实际结果呢,我们来看看示例代码:

测试目录结构如下:

testinternal/src
    mypkg/
        /internal
            /foo
                foo.go
        /pkg1
            main.go

    otherpkg/
            main.go

按照internal包的原理,预期mypkg/pkg1下的代码是可以import "mypkg/internal/foo"的,otherpkg/下的代码是不能import "mypkg/internal/foo"的。

//foo.go
package foo

import "fmt"

func Foo() {
    fmt.Println("mypkg/internal/foo")
}

//main.go
package main

import "mypkg/internal/foo"

func main() {
    foo.Foo()
}

在pkg1和otherpkg下分别run main.go:

mypkg/pkg1$ go run main.go
mypkg/internal/foo

otherpkg$ go run main.go
mypkg/internal/foo

可以看到在otherpkg下执行时,并没有任何build error出现。看来internal机制并未生效。

我们再来试试import $GOROOT下某些internal包,看看是否可以成功:

package main

import (
    "fmt"
    "image/internal/imageutil"
)

func main() {
    fmt.Println(imageutil.DrawYCbCr)
}

我们run这个代码:

$go run main.go
0x6b7f0

同样没有出现任何error。

不是很清楚为何在1.5beta1中internal依旧无效。难道非要等最终1.5 release版么?

【Vendor】
Vendor机制是go team为了解决go第三方包依赖和管理而引入的实验性技术。你执行以下go env:

$go env
GOARCH="amd64"
GOBIN="/Users/tony/.bin/go15beta1/go/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tony/Test/GoToolsProjects"
GORACE=""
GOROOT="/Users/tony/.bin/go15beta1/go"
GOTOOLDIR="/Users/tony/.bin/go15beta1/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT=""
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

从结果中你会看到新增一个GO15VENDOREXPERIMENT变量,这个就是用来控制vendor机制是否开启的环境变量,默认不开启。若要开启,可以在环境变量文件中设置或export GO15VENDOREXPERIMENT=1临时设置。

vendor机制是在go 1.5beta1发布前不长时间临时决定加入到go 1.5中的,Russ Cox在Keith Rarick之前的一个Proposal的基础上重新做了设计而成,大致机制内容:

If there is a source directory d/vendor, then,
    when compiling a source file within the subtree rooted at d,
    import "p" is interpreted as import "d/vendor/p" if that exists.

    When there are multiple possible resolutions,
    the most specific (longest) path wins.

    The short form must always be used: no import path can
    contain “/vendor/” explicitly.

    Import comments are ignored in vendored packages.

下面我们来测试一下这个机制。首先我们临时开启vendor机制,export GO15VENDOREXPERIMENT=1,我们的测试目录规划如下:

testvendor
    vendor/
        tonybai.com/
            foolib/
                foo.go
    main/
        main.go

$GOPATH/src/tonybai.com/foolib/foo.go

//vendor/tonybai.com/foolib/foo.go
package foo

import "fmt"

func Hello() {
    fmt.Println("foo in vendor")
}

//$GOPATH/src/tonybai.com/foolib/foo.go
package foo

import "fmt"

func Hello() {
    fmt.Println("foo in gopath")
}

vendor和gopath下的foo.go稍有不同,主要在输出内容上,以方便后续区分。

现在我们编译执行main.go

//main/main.go
package main

import (
    "tonybai.com/foolib"
)

func main() {
    foo.Hello()
}

$go run main.go
foo in gopath

显然结果与预期不符,我们通过go list -json来看main.go的依赖包路径:

$go list -json
{
… …
    "Imports": [
        "tonybai.com/foolib"
    ],
    "Deps": [
        "errors",
        "fmt",
        "io",
        "math",
        "os",
        "reflect",
        "runtime",
        "strconv",
        "sync",
        "sync/atomic",
        "syscall",
        "time",
        "tonybai.com/foolib",
        "unicode/utf8",
        "unsafe"
    ]
}

可以看出并没有看到vendor路径,main.go import的是$GOPATH下的foo。难道是go 1.5beta1的Bug?于是翻看各种资料,最后在go 1.5beta1发布前最后提交的revison的commit log中得到了帮助:

cmd/go: disable vendoredImportPath for code outside $GOPATH
It was crashing.
This fixes the build for
GO15VENDOREXPERIMENT=1 go test -short runtime

Fixes #11416.

Change-Id: I74a9114cdd8ebafcc9d2a6f40bf500db19c6e825
Reviewed-on: https://go-review.googlesource.com/11964
Reviewed-by: Russ Cox <rsc@golang.org>

从commit log来看,大致意思是$GOPATH之外的代码的vendor机制被disable了(因为某个bug)。也就是说只有$GOPATH路径下的包在 import时才会考虑vendor路径,我们的代码的确没有在$GOPATH下,我们重新设置一下$GOPATH。

$export GOPATH=~/test/go/go15
[tony@TonydeMacBook-Air-2 ~/test/go/go15/src/testvendor/main]$go list -json
{
  
  … …
    "Imports": [
        "testvendor/vendor/tonybai.com/foolib"
    ],
    "Deps": [
        "errors",
        "fmt",
        "io",
        "math",
        "os",
        "reflect",
        "runtime",
        "strconv",
        "sync",
        "sync/atomic",
        "syscall",
        "testvendor/vendor/tonybai.com/foolib",
        "time",
        "unicode/utf8",
        "unsafe"
    ]
}

这回可以看到vendor机制生效了。执行main.go:

$go run main.go
foo in vendor

这回与预期结果就相符了。

前面提到,关闭GOPATH外的vendor机制是因为一个bug,相信go 1.5正式版发布时,这块会被enable的。

三、小结

Go 1.5还增加了很多工具,如trace,但因文档不全,尚不知如何使用。

Go 1.5标准库也有很多小的变化,这个只有到使用时才能具体深入了解。

Go 1.5更多是Go语言骨子里的变化,也就是runtime和编译器重写。语法由于兼容Go 1,所以基本frozen,因此从外在看来,基本没啥变动了。

至于Go 1.5的性能,官方的说法是,有的程序用1.5编译后会变得慢点,有的会快些。官方bench的结果是总体比1.4快上一些。但Go 1.5在性能方面主要是为了减少gc延迟,后续版本才会在性能上做进一步优化,优化空间还较大的,这次runtime、编译器由c变go,很多地方的go 代码并非是最优的,多是自动翻译,相信经过Go team的优化后,更idiomatic的Go code会让Go整体性能更为优异。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats