基础设施即代码 (Infrastructure As Code)

  本文翻译自老马(Martin Fowler)的博客.

  “基础设施即代码”是一种通过代码来定义计算和网络基础设施的方法,它可以应用于任何软件系统中。这样的代码放在源代码管理中,具有可审查性、可重用型,并且符合测试惯例,还完全遵从持续交付的原则。该方法已经在过去的十年内广泛应用于快速增长的云计算平台中了,而且也将会成为接下来操作计算机基础设施至关重要的方法。


  我(Martin)出生在Iron Age时期(喻指软件开发起步早期),那时发布一款新的服务器应用程序,意味着需要找一些实际的可以运行它的硬件,并且把配置硬件使其支持应用需求,以及把应用程序部署到硬件上。而得到这些硬件的成本往往很高,而且拿到它们的周期也很长,通常大约能达到很多月。但是现在我们生活在云的时代,只要有网络连接和一张信用卡,几秒钟就可以启动一台新的服务器。这些动态的基础设施实际上是通过一些程序命令来创建服务器(通常是虚拟机,当然也可以是裸机),并可以对它们进行分区,销毁,完成这些你甚至都不需要动一个螺丝刀。

实践惯例

  基础设施及代码基于以下一些实践惯例:

  • 使用解释型文件:所有的配置信息都被定义于可执行的配置解释文件中,比如说shell脚本,ansible的playbooks,Chef的recipes,或者Puppet的manifests。人们无需登入服务器,就可以做出实时的动态调整。开发时,这些代码可以作为持续的定义,来减少任何生成SnowflakeServer(Martin提出的概念,喻指重用性差的服务器)的风险。这也意味着更新代码的频率要快。幸运的是,计算机可以快速执行程序,并可以准备数百个服务器,速度比任何人类都快。
  • 自归档的系统和过程:相比于人们使用文档中的指示来执行操作(人工级别的可靠性),代码更加清晰准确并且可以不断的被执行。而且如果有必要的话,这些代码也可以生成一些更具有可读性的文档。
  • 给所有东西做版本控制:要让所有的代码都处于版本控制之中。这样每次配置以及每个修改都会有记录可以查询的到,而且还可以利用可重用的构建(ReproducibleBuild)来诊断问题。
  • 持续地测试系统和过程:测试可以帮助计算机快速地找到基础设施配置中的诸多错误。在现代软件系统中,你可以搭建用于基础设施代码的“部署流水线”,这能够让你实践针对基础设施变化的持续交付流程。
  • 小步改变避免批处理:基础设施改变的动作越大,就越可能包含错误,就会更难去诊断错误,特别是如果有多个错误交织在一起。小步更新就会让发现和改正错误更加容易。所以频繁地修改基础设施(小步)可以减少这种事情的发生。
  • 保证服务持续可用:增长的系统担不起更新或者修复时的宕机。一些技术,比如说蓝绿部署和ParallelChange,可以不失可用性地进行小的更新。

益处:

  所有这些都让我们通过动态的基础设施来简单地搭建新的服务器,以及安全地处理那些被新的配置代替或者重新加载的服务器。创建新的服务器就只需要执行一个脚本来完成所需服务器的搭建。这种方法非常适合凤凰服务器( PhoenixServers)和不可变服务器( ImmutableServers)。

  用代码来定义服务器配置意味着服务器之间拥有了更高的一致性。人为的操作会根据不准确的指导(先不管其中有没有错误)产生不同的理解,导致产生具有细微不同配置的snowflakes(同前文snowflakeServer),也会经常出现一些奇怪难以调试的错误。不一致的监控往往会让困难的情况更加糟糕,而使用代码也保证了监控的一致性。

  最重要的是,使用配置性代码可以使改变更加安全,能够用很小的风险来升级应用程序和系统软件。错误可以很快地被发现和修复,至少修改能够退回到上一次有用的配置状态上。

  将基础设施代码版本控制,有助于提升代码的可塑性和可审查性。配置中的每一次更改都会被记录,不容易受到错误的纪录所影响。

  如果你正计划采用微服务架构,这些就很重要了,因为你需要处理更多的服务器,实现“基础设施即代码”就显得尤其必要。“基础设施即代码”技术针对大型集群服务器十分地有成效,包括配置服务器以及制定它们交互的方式。

一个门外汉对网络和UDP/TCP/IP的理解(3)

Published on:

本文源自对文章Layman’s understanding of Networking & UDP/TCP/IP(点击进入原文)的翻译。

理解端口


  既然你理解了两台电脑之间如何对话,那么接下来我们会进一步探讨这个。在大多数情况下,你会在同一个时刻有很多种网络连接。或许你正在网页上听音乐,又或许你是在163或者qq登陆电子邮箱浏览内容。对于所有的这些连接,一个数据包是如何知道它是指向哪个应用的呢?当然,你肯定不想在你浏览网页的中间看到音频数据包。谁知道那玩意是啥样的呢。
  对,除了IP地址,你别玩了还有端口。把你的电脑想象成一所房子。这样你就可以把端口看成一个门,或者你房内的一个房间。你的房子有一个地址(一个外部IP地址)。每个数据包或者数据报将会有一个专门为其设计的端口。这样,各个数据包/报之间就不会混淆了。

  Yahoo Answer里的一篇内容促使原作者写了这篇文章。原作者认为有必要写一个更加深入的回答,通过他足够清晰的解释,来让所有人都来理解计算机网络的工作原理。原作者也欢迎大家的评价/问题/批评,这将帮助他和其他读者更好的理解这些内容。

一个门外汉对网络和UDP/TCP/IP的理解(2)

Published on:

本文源自对文章Layman’s understanding of Networking & UDP/TCP/IP(点击进入原文)的翻译。

域名是什么


  我希望我上面的解释还是比较清楚的。只是上面我没有提到或者强调地址,因为我觉得很明显,当我们发一封邮件时,知道收信人的人姓名及地址信息是必须的。
  因为计算机网络就像邮局的作用一样,所有的数据报必须有一个地址(在UDP中)。在TCP中,你需要一个地址去建立连接。在计算机中,所有的地址几乎都是数字的组合。然而我们人类更喜欢名字。因此,这儿明显有冲突。所以接下来就会介绍域名系统(DNS)。
  域名系统(DNS)可以看成地址解析服务。你给它一个名字,它就会通过电脑返回一个你需要的地址,来完成某些事情。换句话说,它就像一个通讯录。你可能不知道某个人的电话号码,但是你知道他的名字。在通讯录中,你可以将名字和电话号码联系起来。同样地,在因特网中,你将域名和IP地址联系起来。

域名注册

  在你通讯录中,詹姆斯的电话是415-555-1234,但在别人的通讯录红,詹姆斯的电话号码可能是510-123-4567。如果你只用你自己的通讯录,别人用别人的通讯录,就没有问题。然而在因特网里,不同的地址之间却不能有一样的名字。因此,他们创建了一注册服务。这是你注册一个和其他已存在的名字(就像上面的詹姆斯)不冲突的名字最基本的方式。为此,你需要给提供该服务的公司支付一定的费用。我喜欢的一个公司就叫做GoDaddy.

域名服务器及将域名解析为地址

  之前浏览网页的时候,你是否看到过Address Not Found的问题?接下来,我将会给你解释为什么发生了这个。

  比如说,当你在浏览器内输入域名的时候,你的电脑会尝试去把它解析为一个等效的IP地址,这样它才可以连接上。下面就是计算机在创建连接时背后会做的事情:

  1. 查看域地址是否在resolv.conf文件中列出来了。你可以把resolv.conf看成你自己的私人通讯录。该文件总是第一个被查询。
  2. 如果它不在resolv.conf文件中,就会按照你的设置查询DNS服务器内指定位置。DNS代表域名系统。就是那个你提供域名给它,它就会返回这个域名对应的IP地址的系统。
  3. DNS返回IP地址。
  4. 你的电脑获取IP地址,然后它就可以连接到该地址。

  现在,你知道了你的电脑创建连接的先决条件,那么你就可有在你遇到上面的Address Not Found错误时更加深入地调试你的连接了。这或许是因为你的网络断了。也或许是这个域地址真的没有一个对应的IP地址,又或者是你的DNS服务器挂了。

  我们假设你想去www.microshell.com这个网站。首先,你的电脑需要获取到www.microshell
.com的IP地址,然后你的网页浏览器才可以和服务器创建连接,并且下载该页面。

  1. 首先,你的电脑会询问你的DNS服务器是否知道www.microshell.com。
  2. 有可能,你的DNS服务器不认识www.microshell.com。所以它会转发这个请求到下一级域名,com根域。
  3. com根域不知道www.microshell.com。但是它知道Microshell的DNS服务器知道www.microshell.com。所以它告诉你的DNS服务器Microshell的DNS服务器知道这个域名。
  4. 然后你的DNS服务会询问Mircoshell的DNS服务器www.microshell.com的内容。
  5. Mircoshell的DNS服务器认识www.microshell.com,并且返回对应的IP地址。
  6. 你的DNS紧接着就会返回从Mircoshell DNS服务器获取的IP地址。
  7. 这样,我们就将www.microshell.com解析成了对等的IP地址。

一个门外汉对网络和UDP/TCP/IP的理解(1)

Published on:

本文源自对文章Layman’s understanding of Networking & UDP/TCP/IP(点击进入原文)的翻译。
  本文,我将以一个门外汉的角度来解释电脑网络工作的原理,特别是TCP/IP这个用于因特网的协议。这里将涵括因特网编址、域名、以及端口等内容。希望通过阅读此文,你可以更好的理解电脑间的信息传输。在第(1)节,主要讨论计算机网络的基础。第(2)节主要讨论域名,而在第(3)节讨论端口。

计算机网络的基本内容(它就像一个邮局)


  首先,问题来了。如果我需要把一段信息(文件内,或者你输入的内容,又或者其他形式)从电脑A传到电脑B。我应该怎么做?
  我觉得最好的类比,就是把两台电脑之间信息的传输看做平常的信件邮递服务。比如,在一个信件邮递服务中,亨利(电脑A)有一封信或者一份文档(电脑上的一个文件)要寄给约翰(电脑B)。那么他要做的无非就是把信放在信封内,然后把它送到邮局,之后,邮局就会把它邮递到约翰那儿。
  假设这封信有三十页长,而由于某些原因,目前的信封只能装1页内容。那怎么办?因为不能够换一个更大的信封,那就只能用30个信封了,每个信封装一页纸,然后再发30次邮件。对于邮局而言,就是把这30封信封邮寄到约翰那儿。而当约翰收到这些时,却不能保证他是按照发送的顺序接收到这些邮件的。因此他我们必须确定这些信封是否含有第一页,第二页等等的标签。那么,当约翰收到信时,就能重新把它们正确的排序了。

把它放在计算机网路中会怎样

  在计算机网络中,它几乎会发生一模一样的事。你有一个需要传送的文件,它会被分成多个更小的块,把它放在信封中并传送给网关(Gateway)或者网络服务提供者(ISP)。就像一封常规的邮件,这个信封包含了收信人的地址以及序号。携带准备被发送数据的信封叫做数据报(Datagram)。

用户数据报协议(UDP)

  联系我们上面的例子。亨利想发30个数据包,约翰将收到30个数据报。约翰要知道信封的顺序的话,他所要做的就是拆开信封并且按照信封上标记的顺序摆放信件。同样地,用于接收的计算机也会得到所有30个数据报,并且它可以将这些文件重新正确地排序。

  上面解释的方法被称作用户数据报协议(UDP)。想知道更多关于UDP的技术信息,你可以看看 Wikipedia上的对它的解释。
  好,现在你理解了UDP,并且类比了通过邮局发送常规邮件的形式,你可能发现在执行时由一个潜在的问题。我们假设在上面的例子中,约翰收到了除了23号信封之外的所有信封。他可以告诉亨利重新发送23号信封,但是约翰怎么知道何时去请求?可能但约翰发送了重新发送23号信封请求时,邮局就把这丢失的23号信封送来了。23号信封邮递延误的原因有很多。可能是邮递员当天生病了,或者任何其他原因。
  所以我们需要一个更好的方式来确认约翰正确地收到了所有数据。幸运的是,在计算机网络中,UDP并不是唯一在计算机间发送数据的协议。

传输控制协议(TCP)

  在UDP中,一个人可以随意发送一个数据包。比如说,在约翰不知情时,亨利可以发送邮件给约翰。并且一旦亨利发送了邮件,他将不得不推断邮件已经被传送,除非约翰回来请求再重新发送他没有收到的特定的信封。
  和UDP不同的是,TCP协议需要你首先建立连接。因此如果亨利要使用TCP协议发送邮件,他必须首先和约翰建立连接。一旦一个连接已经建立了,亨利发送第一个信封并且去等待约翰确认收到了邮件。当亨利收到了来自约翰的第一个信封安全收到的确认信息,亨利就能够发送第二个信封。这个过程会一直重复,直到亨利告诉约翰他已经发送完所有的信封。
  不同于UDP,使用TCP协议,约翰能够保证收到的所有信封是安装正确的顺序,因为亨利会发送一个信封并且等待来自约翰的确认,然后再发送下一个信封,如此循环。想知道更多关于TCP的技术描述,请访问Wikipedia

Windows PowerShell DSC实践(Ultimate)

Published on:

续言


  距离上一次编写博客已经有一段时间了,DSC实践的很多内容,包括很多细节的总结和问题解决方案都没有说到,接下来我也可能也不会花过多时间在此上,该篇博客我将简单总结一下DSC的实现机制和脚本编写的内容,然后会介绍我在实践过程中遇到的一本不错的关于DSC的英文指南,以及我的中文翻译版,最后简述一下个人对DSC未来的看法。如果你在使用或者探索DSC的过程中遇到任何问题,欢迎和我一起探讨,我的邮箱地址:wjyao@thoughtworks.com .

DSC的实现机制


  DSC本质上类似PowerShell的一个模块,所以DSC脚本实质也是一种PowerShell脚本。DSC脚本相比单纯的PowerShell脚本,它的好处在于它是声明性的,它包含了一个软件环境各个要素的所有基本信息,比如安装了10.9.8版本的chrome、IIS管理器启动、某个路径文件应该存在等等内容,所以更加易读,易管理。
  DSC部署的实现机制是:运行DSC部署脚本,PowerShell就会针对每一个目标机器生成一个托管对象格式(MOF)文件。这个MOF文件以某种方式传递到它们需要实际配置或者部署的机器上。最后,这些机器开始根据MOF文件的内容来调用对应的DSC 资源(Resource),使自己与MOF文件所描述的内容匹配。
  整个过程最重要的有三个部分:一是DSC配置脚本的编写,二是MOF文件的推送,三是DSC资源的编写与调用。
  将MOF文件和要使用的DSC资源推送到它们的目标(待部署)机器上,有两种方式可以实现:
  - Push模式是一种类似人工拷贝文件的形式,基于Windows 远程管理的远程(Remoting)协议来执行。
  - Pull模式通过设定待部署机器录入到一个特殊的网页服务器上,也就是说通过http协议,目标机器主动抓取它们的MOF文件来实现。Pull模式也可以通过使用服务器消息块(SMB:Windows原生的文件共享协议)来实现从文件服务器上拉回MOF文件。可以看出来,它和Push模式最大的不同点是,目标机器会主动从一个服务器上拉取对应的MOF文件。

DSC脚本

  DSC配置脚本主要由三项组成:

  • 主配置(Configuration)块,基本包含所有内容。
  • 一个或者多个节点(Node)段落,根据机器名或者IP指定特定的目标机器,并且包含配置项。
  • 每个节点段落都有一个或者多个配置项(由DSC资源定义的),用于指定你想那些节点(待部署机器)被配置成什么样。   其中,Configuration关键字包含整个配置块,Node声明了该段配置的目标机器或者机器群,具体的部署配置内容用各个DSC资源配置项来实现。

DSC Resource

  所有的DSC资源至少包含两个文件,一个.schema.mof格式文件,一个.psm1格式文件。前者用于声明资源的各个属性值;后者属于PowerShell模块,是具体的PowerShell脚本用于实现。在实际使用过程中,两者的关系有点类似C语言编程的头文件和源文件。
  psm1文件内又主要包含三个函数:
  -Get-TargetResource,
  -Test-TargetResource,
  -Set-TargetResource。
  它们三者分别用于获取配置内容是否存在,测试配置的各个属性是否和对应脚本描述一致,以及根据获取、测试结果按属性设定进行相应配置。

The DSC Book


  在实际解决过程中,在PowerShell.org发现了一本不错的书---The DSC Book,里面对DSC的操作及原理做出了很多解释,也指出了很多问题的解决方案,甚喜。于是我借助空余时间把它翻译成了中文,并于原作者Don Jones联系,放在Penflip上分享,里面较为全面的介绍了DSC,感兴趣者可以参考本书,遇到问题的童鞋也可能在书内寻找到答案,甚至可以加入这本的维护团队中去(本书及原著都可能还会有些有误或者不准确之处,我们把他当做开源项目来做)。
  - The DSC Book (中文版)
  - The DSC Book

最后


  DSC其实还有很多待完善的部分,但是确实是Windows环境下用于自动化配置管理,甚至是部署的一个不错的选择。微软在WMF5.0预览版中也增加大量了针对DSC的改善措施,可见DSC作为微软官方提供的声明配置技术,还是拥有很值得憧憬的应用价值的!
  另外,推荐pstips这个网站,适合学习PowerShell,也有很多DSC的内容。

Windows PowerShell DSC实践(二)| 开始动手!

Published on:

Let's Start!



  在一切工作开始之前,我们必须把Powershell版本升到4.0,具体的升级方法推荐下载安装Chocolatey后,利用cinst命令安装(安装成功后需重启机器),通过在Powershell窗口输入$PsVersiontable命令查看当前版本,如下方所示:
PS C:\Windows\system32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.17929
BuildVersion                   6.3.9600.16406
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2

1.开始一个DSC脚本

  首先,用管理员身份打开Powershell ISE,在Script Pane编写脚本。当然也可以随便用一个编辑器,在其中编写完后,储存为.ps1格式的Powershell脚本,DSC脚本的简洁写法如下:

#MyConfig.ps1
Configuration MyConfig
{
  Node ($MachineName0,$MachineName1)
  {
    WindowsFeature MyRoleExample
    {
      Ensure = "Present" # To uninstall the role, set Ensure to "Absent"

      Name = "Web-Server"  
    }

    Script Test
    {
      SetScript = {
        Write-Verbose “This is just a test script!"
      }
      TestScript = {$false}
      GetScript = { <# This must return a hash table #> }
    }

  }
}
MyConfig

  DSC脚本主要涉及到对Configuration, Node, WindowsFeature, Script等等关键字的识别。Configuration后接用户定义的DSC脚本名,Node后接一个或多个机器的名字(可以是localhost或者其他机器的IP),而WindowsFeature, Script是DSC内置的Resource(微软官方提供的Resource还有File, Environment 等等),然后Resource里对应的是其属性(属性也是Resource本身定义好的)。其实脚本的三个层次一目了然,一个DSC脚本整体框架内,有一个或几个机器节点,每个节点对应相应的若干Resource,再利用Resource的相应属性对各个节点进行相应的配置。

2.生成.mof文件,运行DSC

  同样,在此开始之前我们依然得确认几个前提:
A. Powershell的执行策略是不是UnRestricted(一般默认是Restricted,这样执行上文的MyConfig.ps1时会报错),所以我们需要手动输入下面命令,调整执行策略:

Set-ExecutionPolicy UnRestricted

B. Powershell的Remoting是否使能(Disable情况下也会出错),所以同样需要有这么一步:

Enable-PSRemoting

  然后再Powershell命令行中输入该脚本(Myconfig.ps1), 并执行。你会看到在同一路径下,生成了一个与该脚本同名的文件夹,文件夹内是同名的.mof文件(MyConfig.mof)。接下来你只要执行类似如下命令,即可完成一个简单DSC配置的过程(其中-Path指向.mof所在路径):

Start-DscConfiguration -Wait -Verbose -Force -Path ./MyConfig

3.认识Resource

  Resource是实现DSC最基本的元素,所以有必要对Resource有一定的了解。执行Get-DscResource指令可以查看系统已经存在的Resource,如下:

PS C:\Windows\system32> Get-DscResource

ImplementedAs   Name                      Module                         Properties
-------------   ----                      ------                         ----------
Binary          File                                                     {DestinationPath, Attributes, Checksum, Con.
PowerShell      Archive                   PSDesiredStateConfiguration    {Destination, Path, Checksum, DependsOn...}
PowerShell      Environment               PSDesiredStateConfiguration    {Name, DependsOn, Ensure, Path...}
PowerShell      Group                     PSDesiredStateConfiguration    {GroupName, Credential, DependsOn, Descript.
Binary          Log                       PSDesiredStateConfiguration    {Message, DependsOn}
PowerShell      Package                   PSDesiredStateConfiguration    {Name, Path, ProductId, Arguments...}
PowerShell      Registry                  PSDesiredStateConfiguration    {Key, ValueName, DependsOn, Ensure...}
PowerShell      Script                    PSDesiredStateConfiguration    {GetScript, SetScript, TestScript, Credenti.
PowerShell      Service                   PSDesiredStateConfiguration    {Name, BuiltInAccount, Credential, DependsO.
PowerShell      User                      PSDesiredStateConfiguration    {UserName, DependsOn, Description, Disabled.
PowerShell      WindowsFeature            PSDesiredStateConfiguration    {Name, Credential, DependsOn, Ensure...}
PowerShell      WindowsProcess            PSDesiredStateConfiguration    {Arguments, Path, Credential, DependsOn...}

  从上面的结果可以看到微软内置的全部Resource以及它们的属性。当你查看这些Resource产生的源文件(.psd, .psm, .schema.mof文件)时,了解了Resource的运行机制时,你便可以编写自己定义的Resource(下文将主要讨论这一块),这给DSC提供了更大的灵活性。

Windows Powershell DSC实践(一)| 认识及工具准备

Published on:

DSC? Who are you?



  DSC(Desired Stated Configuration)是微软2013年发布的PowerShell4.0携带的一项新功能,稍微检索了一下,貌似没有发现统一标准的中文译名,google翻译给的直译结果是“理想状态配置”,嗯嗯,靠谱。
  DSC提供了对Powershell语言的扩展、新的Cmdlet,以及可以用来配置各种软件环境的Resource。最大的好处是用户可以根据自身的需求编写自己量身定制的Resource,编写用户定制的具体流程将在之后的博客中展示。
  DSC可以干什么?部署新的软件,启动和关闭服务与进程,管理User和Group、环境变量、文件与目录、注册表设置,甚至可以运行powershell脚本,还有等等等等。但是可能发布时间不长,物有所长,必有所短,在使用过程中还是发现诸多小问题,这也将在之后讨论。 欲了解更多DSC官方信息,请戳这儿.
  好了!说了这些,看了官方文档,你是否对DSC有了一定了解?
  什么?!还是不知道干什么?感兴趣那就一起来做几份套餐吧!
  首先设想我们身处一个基于windows开发测试平台的中型或者大型项目之中,目前只有一堆空荡荡的机器(并且可以升级powershell至4.0的)和几个拥有一堆Resource(文件、程序等等)的服务器,经理要让你配置几台机器给QA用于测试,配置几台给Dev开发,配置几台用作流水线上的其他工作。。。这时候,你肯定不能把机器搬过来,插上电源,启动就完事了(很多时候这些步骤都走完了)。要你做的是了解不同用途的机器需要安装什么样的程序,需要什么样的环境和文件等等,然后利用你的知识实现自动部署上去。这时候你就可以站起来坚定地说:我们可以试试DSC!对,如果这儿是餐厅,DSC就是配菜师,帮你搭配好几份套餐用于满足不同客户群体的需求。

Tools I used



  没有windows操作系统的电脑?没关系,用虚拟机搭建,这里我们使用支持多种平台的VirtualBox来搭建虚拟的搭载windows系统的机器。然后,推荐使用与之搭配的工具Vagrant,更好的管理虚拟机。这样你就可以随意的在你搭建的虚拟机上肆意的开发和调试了(话有点过了,还是没有那么随意的),一旦你的目的达成就可以销毁这台虚拟机了(是不是有点过河拆桥的感觉,猿类,就是这么任性!)。
  另外,为了像Linux平台上用yum或apt-get那样的软件包管理器来优雅的安装程序,再推荐一款不错的针对windows平台的包管理器,它的名字叫Chocolatey。你可以从Chocolatey.org的官网上直接下载安装包,也可以指定自己的软件包地址。后面很多软件包都可以通过它来实现安装,比如powershell4.0的安装就可以通过如下两个简单命令(其实两者意思相同)中任一个来实现:
cinst powershell4
chocolatey install powershell4

  当然,在这里就需要我们把它包装成DSC的一个Resource,这个后续再述。
  这三款工具还有个最大的好处,那便是开源、免费。


  想了解以上三种工具的详细信息,请关注以下:

  • 了解Virtual Box,请戳这里

  • 了解Vagrant,请戳这里

  • 了解Chocolatey,请戳这里
  • 初涉ThoughtWorks---实习双周杂记

    Published on:

      前两周的实习生活结束,ThoughtWorks给我的感受总体上与北京凛冽的西北风带给人的寒意大相径庭,深切的喜欢这种富有“情怀”(虽然这个词最近由于大部分都知道的原因变得没那么褒义,但是,请原谅我词穷)的公司,真切的羡慕这群富有热情、待人真诚、技术精湛的人们。抽空写点博文,一是坚定我这越来越失记录热情的家伙计划以后花点时间写一些文字的决心,二是开通博客试试水,三是因为在这个注重分享的群体内,博客啥的是被鼓励的。下面分几个大的方面小小阐述一点近期迁徙到北方后的感受与认识。

    关于ThoughtWorks

      说实话,在笔试之前我是完全不知道ThoughtWorks的,关于它具体是做什么的,这里我也不再赘述,感兴趣的可以自行百度、google。作为一个潜在的程序猿,我还是以一个比较清晰的分支结构介绍些许东西。

    1.文化/精神/风格

      作为实习生,来到北京办公室之后,我们和社会招聘进来的两位”前辈“,以及从新加坡办公室过来学习的recruiter一起参加了几场简短的关于公司文化等等的入职前session,基本从口头上了解了TW的精神内涵:P1.经营可持续的业务;P2.推动IT变革,追求软件卓越;P3.积极提倡社会和经济公正(这三小句说着这么标准,肯定不是我总结的,网上拷贝的,嘿嘿,见谅)。但真正的感触还是从后面几天与大家的接触才认识到的。

    P1.经营可持续的业务

      这个和TW的公司性质有关,签约之后,我有了解一些这些方面的书,发现TW是和敏捷开发、持续集成、极限编程、测试驱动开发、结对编程这些我之前丝毫不了解的概念紧密相连(很多这些类型的书都是TW内的大牛写的,这些人也或许是行业内著作的译者)。经营可持续的业务便建立在这种技术基础上。说实话,作为新人或者外行,这些概念都只是些看起来迷惑人的词汇。但当你看到贴在玻璃门墙上的各色用户故事贴纸,看到会议室内常有的客户需求会议,看到每天早上办公室里一小撮一小撮的站立会议,看到两个程序猿盯着两个屏幕面对两个键盘敲着同一段代码,你才会意识到这里已经把这些开发方法渗透到公司的血液之中了。

    P2.推动IT变革,追求软件卓越

      待了近两周,给我的感受是这样的,在这里都是比较善谈的牛人,CTO会告诉你他从十岁就开始敲代码了(想想自己大一还不知道编程是个什么玩意,惭愧呀...),这里的很多人对新技术有着自己的热情,他们热衷交流和分享,他们是很多技术社区活动的活跃分子或者组织者,周末办公室经常会举办各种技术研讨类的活动。在这里,你会一不小心就成了Lead Consultant的学生,在这里,他们总结技术雷达会被当作行业内的某种标准,在这里,他们之前的推行的开发技术开始慢慢在各领域流行的时候,又开始一些新的探索。这里的人看书、译书、写书。况且作为一个全球化的企业,人才的分布也是遍地开花的,TW的客户也基本处于国际化中高档水平。P2这变成了理所当然应当遵从的理念。

    P3.积极提倡社会和经济公正

      关于这点,入职的session在给我们新人整体介绍完P1、P2、P3之后,又单独开了专门的session让大家了解TW在这方面的认识和努力,足以见得TW对此的重视。TW在这方面用自己擅长的方式在做着各种努力,并会有更多的想法与行动。先不说其他的,你可以在TW看到大量的女开发人员,以及校招时承诺的男女比例1:1,这在其他软件类的公司是比较少见的。我有幸见识这边办公室校招时HR和技术官最后讨论刷人的“残酷”场景,TW看的绝对不只是你的能力,这再次加深我对此的认识。

    未标题-2.jpg

    2.自由制度及人文关怀


      几天内这是让我感觉到最舒服的一点,扁平化的制度亲切而又有魅力。办公室老大、元老、技术大牛完全没有那种高高在上的感觉,因为这里的交流不会存在身份的距离,有距离也只是停留在现阶段的技术水平之上。每个人给你的感觉是那么平等,对此我有时候会惊讶我只是一个小小的实习生。。。我们可以享受和一般员工的对待,我想这大概便是上文中P3的现实体现。
      至今我还疑惑一点的是具体的上班时间是多少,一般早上九点左右过来,办公室仅有零星的几人,和同事道几声“早”,去吧台“偷”两块面包,喝点热水或者饮料,找个合适的位置坐下来,接下来的半小时,办公室才会人气慢慢升起来。紧接着就是比较有特色的简短”站会“。。。至今我还疑惑一点的是中午有没有具体的午饭时间,一般饭点要么有人吼一声“XXX有XXXsession,饭到了”,要么可能就是几拨人跑到公司楼下自行解决,饭后乒乓球室、小会议室总会有一波人打一会儿球、玩一会PS4、又或是聊聊天啥的(当然也有一些人继续埋头在自己的“产线”之上),之后下午的“搬砖”生活便又陆陆续续开始了。。。
      这里似乎没有人催你上下班,没人逼你做你不喜欢的事(能进来的人多少对编程有一份自己的追求和热爱),没有人告诉你什么事不可以做,没有人会拒绝你的提问。。。
      关于人文关怀,硬件上我觉得对我已经足够好,甚至有种受宠若惊的感觉,TW让我第一次来到北京,让我第一坐上飞机,让我和一同过来的实习生住着比一般星级酒店都要好的公寓(进去给人一种居家过日子的感觉),让我们每个人都有一台MAC(方便工作,虽然工作的时候大部分是在公司的机器上操作,但是一台MAC还是非常有利于私下的学习的)。。。软件上就更nice了,每年对新人培训的大量投入,鼓励员工创新创业,编程你会有pair,遇到问题你可以找buddy,更别说正式入职之后到印度的为期5周的TW University。。。

    3.Interesting Things And People

      看到那些坐在你旁边的天天玩着电脑的老外可能就是这个项目的客户大boss,和平常那样打声招呼就好。整个办公室看不到一个专门为头头设立的办公地点,他们往往坐在靠近门旁边任何一个位置,和平常员工没有什么两样。北京办公室分两个大厅,东宫和西宫(听说成都办公室的女厕所挂名都改成了“妃”),还有好多个大小会议室,以朝代命名,所以你可以看到“蜀”、“汉”等等各种称谓。公司除了零食水果和饮料之外是不包员工吃饭的,但是如果有哪天中午谁要开个session,便会发邮件给同事门,能参与的同事都可以边吃免费的午餐边听session。
      公司大部分的人富有技术热情,待人亦很亲近。最近一起pair的磊哥(之前在CSDN、Red Hat工作过,社招DevOps第一人,和我们同时进的TW)是一个特别喜欢分享,喜欢帮助银的东北银。我的室友是个纯正的广东能,一口纯正的粤语腔,开放而又富有热情,我们两是从武汉过来的F4之二。东宫还有几个国外的同事,来自荷“南”、巴西和法国等地的办公室,鉴于自己的口语水平,偶尔有对上两句诸如“Morning”、“Hey”这种高级别的词汇。还有好多人,在此就不一一讲述。

    4.招聘

      在面试之前(那时候还在武汉的校园寻觅)看过网上一篇关于ThoughtWorks面试的帖子,其间对TW面试过程的评价实在有点让当时即将参与面试的人有几分担心,但当你真正经历之后,你才会发现有些或许子虚乌有,有些或许夸大其词。校招的流程确实有点长,但是国内的四五轮已经比新加坡的七轮(这一点是从新加坡过来的recruiter那里听到的)好很多了,面试难度有时候确是TW招聘过程中一个比较大的噱头(百度上经常有诸如TW力压***成为全球面试难度第*的***),但我感觉国内相比国外估计要容易几个级别。面试的过程完全没有那篇帖子上说的那样,就我个人经历而言,HR面和技术面更像是一种平等的、亲和的交流,双方互相了解对方(见有幸看到北京这边校招面试,过来面试的孩子还可以先听一节课,领一份小礼物,吃一餐午饭(披萨),实在是太幸胡了),比一般的面试给人感觉还要舒服。而TW前期的笔试和家庭作业也非常与众不同,笔试中没有一点涉及技术概念、技术细节的考量,经历过的童鞋或许才会深有体会,家庭作业(这里就需要有一定编程基础了)也是一个重要而又和一般公司不同的方面。
      想起北京这边办公室关于新人的一次游戏,HR姐姐让我每个人写一个自己最遗憾、最骄傲的三件事,游戏的过程不说,最后却是让我们了解我们这些人所拥有的一些共性。其间,她的一句话让印象深刻,“我们其实是在招我们自己”。是的,一波拥有相似理念、信念的人才能相处融洽,才能共同快速成长。

    关于北京

      接下来简短说说对于帝都的感受,承蒙APEC后遗症厚爱,来帝都两周,只有一天需要带上帝都专属面具。总体上,帝都比我想象中要好一些,不知道是不是公司和公寓都二环以内(靠近二环线)的原因,交通上的拥堵没怎么感受得到,天安门等等著名景点也没有特别密集的人群,甚至有种地铁还没武汉堵的错觉(对,没错,以上肯定是错觉!)。住得旁边有不少胡同,平常感觉人也不多,有种冬日里的安详感,大部分老北京也有带着一股京腔的礼貌。其他方面,气候干冷,对于我这个中部人来说其实还好,除了个别晚上在外面走的时候有种快要被风吹走的幻觉;物价肯定是比武汉的学校旁边贵几番了,但是好歹在帝都,可以接受。

    关于DevOps

      DevOps,实习之前,我对这个名词丝毫不了解,看到公司某个墙上写着这个词汇时,也仅仅以为是Developer的缩写。后来在项目中接触,才对DevOps有个目前这种浅显的了解(实习估计就紧密联系这了)。下面仅仅以我现在粗浅的了解谈一点认识,不当不正之处还望见谅。
      DevOps是Development和Operations的组合,与CD(持续交付)紧密相关,需要掌握的是跨系统跨平台的配置管理手段、部署方法、虚拟化和自动化技术,总结起来可能就可以理解为软件上的基础设施建设,保障和促进高效有用的交付。需要做的不只是对各种工具的应用,对各种操作系统环境的熟悉,还有对相关脚本语言的熟悉,以及对新技术的敏感和学习。
      就这两周而言,用到的或者看到的工具就有好多:Virtual Box,ansible,vagrant,git...看到各种程序语言的应用:C#,java,shell,Powershell,Ruby,Python...连操作系统都各种切换:windows server,OS X,fedora,ubuntu...
      仅仅在DevOps,我就感觉有好多东西需要去学习,虽然现在还是个小白,但我庆幸我走在一条远离小白的路上。任重而道远!

    最后

      感谢有心人看完整篇文章或者其中的某小段,忍受我这支离破碎的语言和不加协调的文风。前方的路途很遥远,但我喜欢这种道路,便前后无悔,愿与同志者共勉,与异志者互励!
      最后,顺便表达一下其他方面:感谢TW,感谢TW有爱的同事和老师们以及那帮关心我的朋友们,感谢爸妈给予的无条件的爱与付出,感谢远方那个谁抛弃很多后对于我倾注的支持和鼓励,想对她说:“眷恋不只是责任,空间让我不能风雨兼守,但愿时间能让我伴你终久,多给我电话”。

    <博客第一篇博文,主要是一些感想,部分图片盗取自室友,以后在这里将尽量以技术学习分享为主了>