GitLab Runner Docker Executor

GitLab Runner

执行器(Executor )的比较

Shell 是最易于配置的执行器。构建中所需的依赖得你手工装在 Runner 所在机器上。

更好的方式是使用 Docker,它让你拥有干净的构建环境,以及简易的依赖管理——所有的编译项目所需的依赖都可以放进 Docker 镜像中。Docker 执行器很容易就能创建带有依赖服务的编译环境,比如 MySQL。

通常不建议使用 Docker-SSH,这是 Docker 执行器的特殊版本。该执行器可以连接到 Docker 容器,其中运行 SSH 守护进程。如果你的 Docker 镜像要复制一个完整的工作系统,这会很有用:使用进程管理系统(init),暴露 SSH 进程,并含有系列安装好的服务。这类镜像是肥镜像,Docker 社区通常也不建议使用。

以下原文:https://docs.gitlab.com/runner/executors/docker.html

Docker 执行器

GitLab Runner 能在用户提供的镜像上,使用 Docker 来执行编译。这通过 Docker 执行器完成。

Docker 执行器与 GitLab CI 一起使用时,它连到 Docker Engine,并在独立且隔离的容器中运行每个构建。它会使用在 .gitlab-ci.yml中预设好的镜像,并按照 config.toml 所定来执行。

这样可以拥有一个简单可重复的构建环境,这也可以在你的工作站上运行。附加的好处是可以测试我们将在以后从 Shell 中探索的所有命令,而不必在专用的 CI 服务器上进行测试。

工作流程

Docker 执行器将构建分为多个步骤:

  1. Prepare:创建并启动服务。
  2. Pre-build:克隆,恢复 Cache 并从以前的阶段下载工件(Artifacts)。这是在特殊的 Docker 镜像上运行的。
  3. Build:用户构建。这是在用户提供的 Docker 镜像上运行的。
  4. Post-build:创建缓存,将工件上传到 GitLab。这是在特殊的 Docker 镜像上运行的。

此特殊的 Docker 镜像基于 Alpine Linux,并包含运行 prepare 步骤所需的所有工具:Git 二进制文件和用于支持 Cache 和工件(Artifacts)的 Runner 二进制文件。 您可以在官方的 Runner 仓库中找到此特殊镜像的定义。

image 关键字

image 关键字是本地 Docker Engine 中存在的 Docker 镜像的名称(docker image 可列出所有docker 镜像),或是可在 Docker Hub 中找到的任何镜像。有关镜像和 Docker Hub 的更多信息,请阅读 Docker Fundamentals文档。

简言之,使用image引用 docker 镜像来创建容器,构建将在此容器上运行。

如果不指定命名空间,Docker 默认命名空间为包含所有官方镜像library。这就是为什么你会看到很多次.gitlab-ci.ymlconfig.toml中省略的library部分。例如,可以定义像image: ruby:2.1这样的镜像,它是image: library/ruby:2.1的快捷方式。

然后,每个 Docker 镜像都有标签(tag),表示镜像版本。这些在镜像名称后面用冒号(:)定义。 例如,对于Ruby,可以在 https://hub.docker.com/_/ruby/ 上看到支持的标签。如果没有指定标签(如image:ruby),则表示latest

services 关键词

services关键字定义了在构建期间运行的另一个 Docker 镜像,并链接到image关键字所定义的 Docker 镜像。这允许你在构建时访问服务镜像。

服务镜像可以运行任何应用程序,但最常见的使用场景是运行数据库容器,例如mysql。用已有的镜像来运行额外容器会更加容易快速,而不是每次构建项目时都安装mysql

你可以在 CI 服务示例的相关文档中看到一些广泛使用的服务示例。

服务如何链接到构建

要更好地了解容器链接的工作原理,请阅读 Linking containers together

总而言之,如果你将mysql作为服务添加到应用程序中,则该镜像将用于创建一个链接到构建容器的容器。根据工作流程,这是运行实际构建之前执行的第一步。

MySQL 的服务容器可使用主机名mysql访问。因此,为了访问你的数据库服务,您必须连接到名为mysql的主机而不是套接字(socket)或localhost

.gitlab-ci.yml定义imageservices

你可以简单地定义将用于所有作业的镜像,和要在构建时使用的服务列表。

image: ruby:2.2

services:
  - postgres:9.3

before_script:
  - bundle install

test:
  script:
  - bundle exec rake spec

也可以为每个作业定义不同的镜像和服务:

before_script:
  - bundle install

test:2.1:
  image: ruby:2.1
  services:
  - postgres:9.3
  script:
  - bundle exec rake spec

test:2.2:
  image: ruby:2.2
  services:
  - postgres:9.4
  script:
  - bundle exec rake spec

Define image and services in config.toml

查找[runners.docker]部分:

[runners.docker]
  image = "ruby:2.1"
  services = ["mysql:latest", "postgres:latest"]

这里定义的镜像和服务将添加到 Runner 运行的所有构建中,因此即使在.gitlab-ci.yml内没有定义imageconfig.toml中定义的将被使用。

从私有 Docker Registry 中定义镜像

从 GitLab Runner 0.6.0 开始,你可以定义位于私有 Registry 的镜像,这可能需要身份验证。

.gitlab-ci.yml的镜像定义中显式声明即可。

image: my.registry.tld:5000/namepace/image:tag

上例中,GitLab Runner 到my.registry.tld:5000寻找namespace/image:tag镜像。

如果存储库是私有的,则需要提供 GitLab Runner 的身份验证凭据 。更多内容参见:使用私有 Docker Registry

访问服务

假设需要一个 WordPress 实例,来测试它和你应用的 API 集成。

你可以在.gitlab-ci.yml中使用如tutum/wordpress作为服务镜像:

services:
  - tutum/wordpress:latest

当构建运行时,tutum/wordpress将首先启动,你可以用主机名为tutum__wordpresstutum-wordpress的构建容器来访问它。

GitLab Runner 为你可以使用的服务创建两个主机名别名。别名取自镜像名称,遵循以下规则:

  1. :后的一切都被舍弃
  2. 第一个别名,斜杠(/)替换为双下划线(__
  3. 第二个别名,斜杠(/)替换为单破折号(-

使用私有镜像服务将剥离给出的任何端口,并应用上述规则。服务registry.gitlab-wp.com:4999/tutum/wordpress将生成主机名registry.gitlab__wp.com__tutum__wordpressregistry.gitlab-wp.com-tutum-wordpress

配置服务

许多服务接受环境变量,允许你根据环境来轻松更改数据库名或设置帐户名。

GitLab Runner 0.5.0 及以上版本将所有 YAML 定义的变量传递给创建的服务容器。

对于所有可能的配置变量,请检查其对应Docker集线器页面中提供的每个映像的文档。

所有变量将被传递到所有服务容器。没有某服务专用的变量。

安全变量(Secure Variables)只传递给构建容器。

服务中的构建目录

从 1.5 版本开始,GitLab Runner 将一个/build目录装载到所有的共享服务中。

参见这个 issue:https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1520

PostgreSQL 服务示例

请参阅具体文档使用 PostgreSQL 作为服务

MySQL 服务示例

请参阅具体文档使用 MySQL 作为服务

服务健康检查

服务启动后,GitLab Runner 等待一段时间的服务响应。当前,Docker 执行程序会尝试打开与服务容器中第一个暴露服务的 TCP 连接。

你可以看到它 在这个 Dockerfile 中是如何实现的。

构建和缓存存储

Docker 执行器默认将所有构建存储在/builds/<namespace>/<project-name>中,所有缓存在/cache(在容器内)中。

您可以在config.toml文件的[[runners]]部分下,定义builds_dircache_dir选项,来覆盖/builds/cache目录。这将修改数据存储在容器内的位置。

如果你修改/cache存储路径,你还需要更改config.toml[runners.docker]部分的volumes = ["/my/cache/"],确保把上述目录标记为 persistent。

要了解更多信息,请阅读下一部分持久存储。

持久存储

Docker执行器可以在运行容器时提供持久存储。
volumes =下定义的所有目录将在构建之间持久化。

volumes指令支持2种类型的存储:

  1. <path>动态存储<path>在该项目的同一并发作业的后续运行中持续存在。数据附加到自定义缓存容器:runner-<short-token>-project-<id>-concurrent-<job-id>-cache-<unique-id>
  2. <host-path>:<path>[:<mode>]主机绑定存储<path>绑定到主机系统上的<host-path>。可选的<mode>可以指定该存储是只读或读写(默认)。

构建的持久存储

如果你将/builds作为主机绑定的存储,你的构建将被存储在:/builds/<short-token>/<concurrent-id>/<namespace>/<project-name>,其中:

  • <short-token>是 Runner Token 的缩写版(前 8 个字母)
  • <concurrent-id>是个唯一数字,用于标识项目上下文中特定 Runner 的本地作业 ID

特权(privileged)模式

Docker 执行器支持许多选项来微调构建容器。其中之一是privileged模式

使用具有特权模式的 docker-in-docker

配置的privileged标志被传递给构建容器和所有服务,从而允许轻松使用 docker-in-docker 方法。

首先,将您的 Runner(config.toml)配置为以privileged模式运行:

[[runners]]
  executor = "docker"
  [runners.docker]
    privileged = true

然后,使你的构建脚本(.gitlab-ci.yml)使用 docker-in-docker 容器:

image: docker:git
services:
  - docker:dind

build:
  script:
    - docker build -t my-image .
    - docker push my-image

ENTRYPOINT

Docker 执行器不会覆盖 Docker 镜像的ENTRYPOINT

这意味着,如果你的镜像定义了ENTRYPOINT,并且不允许使用CMD来运行脚本,那么该镜像将不能与 Docker 执行器一起使用。

使用ENTRYPOINT可以创建在自定义环境或安全模式下运行构建脚本的特殊 Docker 镜像。

您可能会想到创建一个使用不执行构建脚本的ENTRYPOINT的 Docker 镜像,但执行一组预定义的命令,例如从你的目录里构建 Docker 镜像。在这种情况下,您可以以特权模式运行构建容器,并使 Runner 的构建环境安全。

请考虑以下例子:

  1. 创建一个新的 Dockerfile:
    FROM docker:dind
    ADD / /entrypoint.sh
    ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]
    
  2. 创建一个用作ENTRYPOINT的 bash 脚本(entrypoint.sh):
    #!/bin/sh
    
    dind docker daemon
        --host=unix:///var/run/docker.sock \
        --host=tcp://0.0.0.0:2375 \
        --storage-driver=vf &
    
    docker build -t "$BUILD_IMAGE" .
    docker push "$BUILD_IMAGE"
    
  3. 推送镜像到 Docker Registry。

  4. privileged模式下运行 Docker 执行器。在config.toml中定义:

    [[runners]]
      executor = "docker"
      [runners.docker]
        privileged = true
    
  5. 在你的项目中使用以下.gitlab-ci.yml
    variables:
      BUILD_IMAGE: my.image
    build:
      image: my/docker-build:image
      script:
      - Dummy Script
    

这只是一个例子。通过这种方法,是有无限可能的。

镜像拉取策略如何工作

当使用dockerdocker-sshdocker+machinedocker-ssh+machine执行器时,可以设置pull_policy参数来定义 Runner 在拉取 Docker 镜像时的工作方式(imageservices关键字)。

注:
如果没有为pull_policy参数设置任何值,则 Runner 将默认使用always拉取策略。

现在看看这些策略如何工作。

使用拉取策略never

never策略完全禁止镜像拉取。如果 Runner 的pull_policy参数设为never,那用户只能使用 Runner 运行的 docker 主机上已经手工拉取的镜像。

如果在本地找不到指定的镜像,则 Runner 将会使构建失败,错误类似于:

Pulling docker image local_image:latest ...
ERROR: Build failed: Error: image local_image:latest not found

何时使用此拉取策略?

如果您希望或需要完全控制 Runner 用户使用哪些镜像,则应使用此拉取策略。对于专用于只能使用特定镜像(在任何 registry 上都不公开)的项目的私有 Runner 来说,这是一个不错的选择。

何时不使用此拉取策略?

大部分 auto-scaled 的 Docker 执行器使用场景下,该拉取策略无法正常工作。由于自动伸缩的工作原理,只有在为特定云服务提供商使用预定义的云实例镜像时,never拉取策略才可用。镜像需要包含预装的 Docker Engine 和已使用镜像的本地副本。

使用拉取策略if-not-present

使用if-not-present拉取策略时,Runner 首先检查本地是否有该镜像。如果有则使用本地版本的镜像。否则 Runner 将尝试拉取镜像。

何时使用此拉取策略?

如果想使用远程 Registry 拉取的镜像,但当使用重型和很少更新的镜像时,又希望减少分析镜像层差异费时,这种拉取策略是一个不错的选择。在这种情况下,您需要一段时间才能从本地 Docker Engine 存储区手动删除镜像以强制更新镜像。

如果您需要只在本地构建和本地可用的镜像,那么这也是一个不错的选择,但另一方面,还需要允许从远程 Registry 中拉取镜像。

何时不使用此拉取策略?

如果你的构建使用经常更新并需要在最新版本中使用的镜像,则不应使用此拉取策略。在此情况下,策略所减少的网络负载,与非常频繁地删除本地镜像副本的必要性相比,可能不太值得。(In such situation, the network load reduction created by this policy may be less worthy than the necessity of the very frequent deletion of local copies of images.)

如果 Runner 可以被不同用户使用,而这些用户又不能访问彼此使用的私有镜像,那么此拉取策略也不应该被使用。特别不要为共享 Runner 使用这个拉取策略。

要了解为什么if-not-present拉取策略在与私有镜像一起使用时会产生安全问题,请阅读安全注意事项文档

使用拉取策略always

always拉取策略确保镜像始终被拉取。当使用always时,即使本地副本可用,Runner 也会尝试拉取镜像。如果未找到镜像,则构建将失败,并显示类似以下错误:

Pulling docker image registry.tld/my/image:latest ...
ERROR: Build failed: Error: image registry.tld/my/image:latest not found

注:
对于v1.8之前的版本,当使用always拉取策略时,可能会返回(fall back)到镜像的本地副本并警告:

Pulling docker image registry.tld/my/image:latest ...
WARNING: Cannot pull the latest version of image registry.tld/my/image:latest : Error: image registry.tld/my/image:latest not found
WARNING: Locally found image will be used instead.

这在v1.8版本中已更改。To understand why we changed this and how incorrect usage of may be revealed please look into issue #1905

何时使用此拉取策略?

如果您的 Runner 公开可用,并将其配置为 GitLab 实例中的共享 Runner,则应使用此拉策略。当 Runner 将与私有镜像一起使用时,它是唯一可以被视为安全的拉取策略。

如果要强制用户始终使用最新的镜像,这也是一个不错的选择。

此外,这将是 Runner 自动伸缩(auto-scaled) 配置的最佳解决方案。

何时不使用此拉取策略?

如果你需要使用本地存储的镜像,则此拉取策略将无法正常工作。在这种情况下,Runner 将跳过镜像的本地副本,并尝试将其从远程 Registry 中拉出。如果镜像是本地构建的,并且不存在于任何公共 Registry 中(尤其是在默认的 Docker Registry 中),则构建将会失败:

Pulling docker image local_image:latest ...
ERROR: Build failed: Error: image local_image:latest not found

Docker vs Docker-SSH

注意
docker-ssh 执行器已被弃用,并且不会添加任何新功能。

我们提供一种特殊类型的 Docker 执行器的支持,即 Docker-SSH。Docker-SSH 使用与 Docker 执行器相同的逻辑,但不是直接执行脚本,它使用 SSH 客户端连接到构建容器。

然后,Docker-ssh 使用其内部 IP 连接到容器内部运行的 SSH 服务器。

GitLab Flow 的 11 条规则

使用 Git 进行版本管理,是对 Git 出现前所有方法的改进。然而,很多组织最终会出现凌乱的工作流程,或过于复杂的流程。这种问题对从其他版本控制系统转过来的组织来说尤为突出。

本文为 GitLab 工作流程制定了11条规则,以帮助简化和清晰该流程。规则的主要好处(或说希望的好处)是它简化过程,并产生更加有效和更清晰的结果。

改善空间永存,一切皆为草稿。一如既往,人人皆可贡献!欢迎反馈!

1. 使用功能分支,不直接提交(commit)到 master 分支

如果从 SVN 转过来,举例来说,你会习惯基于主干(trunk)的工作流。而使用 Git 时,任何正进行的操作,都应为之创建一个分支(branch),以便在最终合并(merge)之前进行代码审查(code review)。

2. 测试所有提交,而不仅只在 master 分支上

有些人将 CI 系统设置为只测试合并到 master 分支的东西。这太迟了!总是拥有绿色的 master 测试(译者注:绿色在 CI 里通常意味着测试通过,而红色意味着测试失败),人们会觉得有信心。例如,在开始开发新功能之前,人们不得不测试 master 分支那是没有意义和荒谬的。CI 并不昂贵,所以这样做是最好的。

3. 在所有的提交上,运行所有的测试(如果你的测试时间长于 5 分钟则使其并行)

如果功能分支有新的提交(commit),请随之运行测试。如果测试需要很长时间,请尝试并行运行。合并请求(merge requests)时,在服务器端来执行此操作以运行完整的测试套件。如果有一个用于开发的测试套件,而另一个测试套件只是为新版本运行,那么设置并行测试并运行全部测试套件是值得的。

4. 在合并到 master 之前执行代码审查,而不是事后审查

不要在一周结束时测试,应该当场就搞!这样更有可能抓住可能导致问题的东西,而其他人也会努力提出解决方案。

5. 部署是自动的,并基于分支或标签(tag)。

如果不想每次都部署 master 分支,那可以创建一个 production 分支;但没理由用脚本(script)或登录到某个地方去手动操作。请自动化一切,或用特定的分支来触发生产部署

6. 由用户创建标签(tag),而不应由 CI 创建

由用户来打标签tag),并基于此,CI 将执行一个动作。不应让 CI 去更改代码库。如需非常详细的指标,那应该有一个服务器报告来详细说明新版本。

7. 发布(release)是基于标签(tag)的

如果打了 tag,则意味着创建了一个新版本。

8. 永不对已推送的提交(pushed commits)进行变基(rebase

当推送(push)到公共分支后,就不该对其变基,因为这样会很难跟进你正在改进的内容,很难跟进测试结果,而且这样打破了 cherry-picking。有时我们在审查流程的后期要求代码贡献者合并及变基(git merge --squash),以使一些东西容易还原时,我们也会违背这一规则。但一般而言,准则是:代码应干净,修改历史应真实。

9. 每个人都从 master 分支开始工作,目标也是 master 分支

这意味着没有任何长期分支。你可以检出 master 分支,构建功能,创建合并请求,并再次指向到 master 分支。在合并之前要做完整的代码审查,不应在代码审查和合并间搞任何的中间阶段。

10. 在 master 分支中修正错误,其次再到发布分支

如果发现了 bug,最糟糕的事莫过于在刚发布的版本里修复了它,但却没在 master 里修复。为避免这种情况,应总是向前修复(fix forward)。在 master 中修复,然后 cherry-pick 到其他补丁发布分支(比如 production 分支)。

11. 提交信息(commit message)应体现意图

不仅要说清楚做了什么,还要说明为什么这么做。
如果解释一下为什么用这种方式,而不是其他方式,则会更加有用。

更多内容请移步 GitLab Flow 文档。

原文:https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/

run xware on 64bit Ubuntu system

root@server-name# file portal
portal: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.36, not stripped

Install some i386 libaries on 64bit system.

apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386

[已过时] 部署 Docker Registry 服务

本文所述已经过时,已无参考价值。

本文阐释了怎样部署私有的 Docker Registry 服务 —— 或为公司私用,或公开给其他用户使用。例如,你公司可能需要私人的 Registry 来支持持续集成(CI)。又或,你的公司可能有大量镜像方式的产品或服务,你想以公司品牌的方式来整体提供和呈现。

继续阅读

在 VMware ESXi 中安装 OmniOS

〇、获取安装文件

第〇步,当然是搞一个安装文件回来

到 http://omnios.omniti.com/wiki.php/Installation ,弄一个当前稳定版或者 LTS 版本。

截至发稿,当前 LTS/Stable 版本为 r151014,相应的 ISO 文件链接为:
http://omnios.omniti.com/media/OmniOS_Text_r151014.iso

记得校验一下:
md5 (OmniOS_Text_r151014.iso) = 796fbfe1305f0e4922e9cf627d3e67c2
sha1 (OmniOS_Text_r151014.iso) = ff91fbfa2b01ca9ac61d5812570109c640c1ddd1

下载回来之后,用 ssh/scp 或者 vSphere Client 等将光盘镜像文件上传到 ESXi 的 datastore 中。

一、创建 ESXi 虚拟机

以下以 ESXi 5.5 为例。

选择自定义创建。
esxi-customize

OS 类型选择 Oracle Solaris 10 (64-bit)esxi-ostype

网卡类型选择 VMXNET3
esxi-nic

SCSI 控制器选择 LSI Logic Parallel
esxi-scsi

新建磁盘。如果只需要 OmniOS,那么新建一个 5GB 的磁盘就够了。OmniOS 官方建议 4.1 GB,最小 2.1 GB。为了升级及临时文件等需要,还是适当放宽一些。如果后续需要安装 Napp-it 作为上层的存储应用系统,那么建议的磁盘大小是 25GB。

在启动前,对虚拟机配置最后做一下编辑。首先是挂载 OmniOS 系统安装光盘镜像,并选择 Connect at power on
esxi-cdrom

虚拟机的创建即告完成。

二、安装 OmniOS

乏善可陈,基本上 F2(下一步)、F2、F2 … 就完成了。好吧,我们的重点在于后续的 VMXNet3 万兆网卡的配置。

OmniOS 安装完成后,root 密码默认为空,需要你设置密码,及创建新普通用户用于 SSH 登录,或者修改 SSHd 配置文件允许 root 登录之类 balabala….

01-emptypwd

三、安装 VMware Tools 及 VMXNet3 网卡

OmniOS 没有自带 VMXNet3 网卡驱动,因此到了当前这步时,咱们是没有网络可用的,需要安装相关驱动。

首先,断开安装 OS 时为虚拟机挂接上的光驱设备。

VM -> Edit Settings

取消光驱设备的 ConnectedConnect at power on 选项。如果提示锁定之类的,直接点选 Yes 强制解除锁定即可。
2015-04-09_14-18-09

随后在控制台用以下命令开启 OmniOS 的即插即用服务。

svcadm enable hotplug

VM -> Guest -> Install/Upgrade VMware Tools

安装 VMware Tools 这个过程,VMware 是以向虚拟机挂载软件光盘,并尝试自动启动安装进程来进行的,遗憾的是,Solaris 类型的客户机并不能自动挂载光驱,还得手动操作一下。

先找出光驱设备名

ls –l /dev/dsk | grep ide | grep c\*s2

上图中的设备节点 c1t0d0s2,就是我们要找的东西,下面的命令则需要根据你的实际情况来调整。挂载光驱设备:

mount –F hsfs –o ro /dev/dsk/c1t0d0s2 /media

解压展开 VMware Tools 安装文件:

cd /tmp
tar zxvf /media/vmware-solaris-tools.tar.gz
cd vmware-tools-distrib
./vmware-install.pl

提示的所有问题,都用默认值回答,也就是一路狂按 Enter 键。

VMware Tools 安装完成之后,网卡驱动也随之就绪,我们可以开始配置网卡了。

dladm show-link

02-nic

网卡设备 vmxnet3s0 state unknow,为不可用状态。我们为其添加 IP interface

ipadm create-if vmxnet3s0

接下来为该 Interface 添加 IP 地址等参数:

ipadm create-addr –T static –a <IP-address>/24 vmxnet3s0/v4

这时,你再使用 dladm show-link 及 dladm show-phys,应该会得到以下输出:
2015-04-09_14-46-45

设置默认网关路由:

route –p add default <Gateway-IP-address>

指定 DNS 解析服务器并激活:

echo 'nameserver <Nameserver-IP-address>' >> /etc/resolv.conf
cp /etc/nsswitch.dns /etc/nsswitch.conf

 

大功告成,OmniOS 安装告一段落。

对了,建议参照 OmniOS Shell Env Check List 所述,对 OS 环境进行设置以改善操作体验。

VMware 下 CoreOS OVA 镜像的安装与配置

此文提供了在 VMware ESXi/Workstation/Fusion 上安装 CoreOS ova 镜像及其基本配置的有关信息,并以 CoreOS release 557 为例。

CoreOS 是一个新的 Linux 分发版本,它设计用来为集群部署提供基础架构。

本文包含以下主题:

  • 安装介绍
  • 集成 Open VM Tools

安装介绍

从版本 540.0.0 开始,CoreOS 引入了对虚拟机 OVA 格式的支持。作为推荐的方式,以下安装指引也只面向 OVA 镜像。

前置需求

检验是否完成以下步骤:

  • Read General Installation Instructions for All VMware Products.
  • Read General Knowledge for CoreOS at https://coreos.com/docs/quickstart/.

注:

安装步骤

1、将文件 coreos_production_vmware_ova.ova 上传到 Workstation/Fusion/ESXi 的 Datastore。

2、部署 CoreOS 虚拟机到 VMware。

在 VMware Workstation 或 Fusion 上部署 CoreOS 虚拟机:

1、打开文件 coreos_production_vmware_ova.ova 所处位置,并用 VMware Workstation 或 Fusion 打开。
2、编辑其名称及存储路径,然后点击导入/Import 按钮。
3、当遇到以下警告信息时,点击重试/Retry 按钮。
retry

在 VMware vSphere 上部署 CoreOS 虚拟机:

1、打开 vShere C# 客户端,或使用任何能连接到 vCenter Server 的 vSphere C# Client 或 vSphere Web Client,并连接至你的 ESXi 实例。
2、浏览至 文件/File -> 部署 OVF 模板/Deploy OVF Template,并点击浏览并定位到 coreos_production_vmware_ova.ova 所处的路径。
3、继续余下的步骤以完成虚拟机创建。

3、CoreOS 虚拟机的自动登录。

执行以下步骤以访问 CoreOS 虚拟机:

1、打开 CoreOS 虚拟机电源,并打开控制台。
2、当 Boot Loader 提示出现的时候,按下 e 键来编辑 GRUB 菜单。
3、添加 coreos.autologin 作为启动参数,并 Ctrl-x 或 F10 重启。这将使控制台跳过登录提示并直接进入用户 core 的 shell。
autologin
4、给用户 core 设置密码用以 SSH 访问。
ssh

4、Cloud-Config 文件

注:Cloud-config 文件位于 /usr/share/oem/cloud-config.yml 。访问 Cloud-Config Validator ,或者运行 coreos-cloudinit -validate 以验证 cloud-config 在该 CoreOS 虚拟机中可用。

1、为用户 core 设置 SSH 公钥。
2、从你的客户端生成一个新的 SSH key。
ssh-keygen -t rsa
3、输入一个 passphrase,并检查 id_rsa 和 id_rsa.pub 是否已经生成。
4、检查 CoreOS 虚拟机的 IP 地址。
5、登录到 CoreOS 虚拟机并编辑 /usr/share/oem/cloud-config.yml 文件。
cloudconfigyml
6、拷贝 RSA 公钥 id_rsa.pub 的内容到 ssh_authorized_keys 里。
ssh-rsa [id_rsa.pub.content.here]
sshkey
7、重启 CoreOS 虚拟机并用 RSA 私钥校验是否能登录。
[root@localhost .ssh]# ssh -i id_rsa core@[your.ip.address.here]
sshlogin

更多关于cloud-config自定义的信息,请参考 cloud-config 指南

完成首台虚拟机 user_data 自定义之后,你就可以部署更多的 CoreOS 虚拟机来设置 CoreOS 集群。

Open VM Tools

CoreOS 490.0.0 及其后版本已包含 open-vm-tools —— VMware Tools 的开源实现。更多信息,参考 VMware support of open-vm-tools (2073803)

OmniOS Shell Env Check List

bash Shell

~/.profile

#!/bin/bash
# Solaris 衍生的 OS,默认都将 GNU 路径放在前面
# 而支持 ACLs 的 ls/chmod ,是在 /usr/bin 目录中的
export PATH=/usr/bin:/usr/sbin:/sbin:/usr/gnu/bin

export TERM=xterm-color

# Enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors &amp;&amp; eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='/usr/bin/ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# Some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

~/.vimrc

set nocp
set bs=2
syntax on

./.inputrc

"\e[1~": beginning-of-line     # Home
"\e[4~": end-of-line           # End
"\e[5~": beginning-of-history  # PageUp
"\e[6~": end-of-history        # PageDown
"\e[3~": delete-char           # Delete
"\e[2~": quoted-insert         # Insert
"\eOD": backward-word          # Ctrl+Left
"\eOC": forward-word           # Ctrl+Right

/etc/default/init

TZ="Asia/Shanghai"
CMASK=022
LANG=en_US.UTF-8

转 [译] 为什么我们找不到前端工程师?

原文为 Why can’t we find Front End developers? 作者是 Jose Aguinaga,前端工程师、用户体验设计师跟热爱 JavaScript 的软件工程师。

正文开始


有天,作者偶然在 Quora 上发现一个跟前端工程师及新创公司有关的问题:为什么新创公司很难找到前端工程师?

该讨论串的原 PO 提到:

(前略)我想多数人都同意前端开发比其他软件工程领域简单一些,那到底为何那些新创公司还是很难找到前端工程师?

我看到几个不错的回应,这些回应大多一针见血。而根据过去我寻找前端职缺,面试前端工程师,以及平常在前端项目里的工作经验,以下提出我的个人意见:

继续阅读

Install ShadowSocks Client as a Windows Service

1/ Install Node.js

http://nodejs.org/

2/ Install ShadowSocks

Open Node.js command line environment, and type following command:

npm install -g shadowsocks

3/ NSSM Configure

Download from http://nssm.cc/

Run nssm.exe from command line window.

nssm.exe install

nssm service installer

 

 

 

 

 

 

Key parameters:

Parameter Description Example Value
Path ShadowSocks client full path. C:\Users\Administrator\AppData\Roaming\npm\sslocal.cmd
Startup directory ShadowSocks config file location. C:\xxxxx\AuthInfo
Arguments ShadowSocks startup parameter, include config file name. -c Linode_ShadowSocks_Local.json

 

Example Screen:

TAB Application:

nssm_application_tab

 

 

 

 

 

 

TAB Details

nssm_detail_tab

 

 

 

 

 

 

TAB Log on

nssm_logon_tab