Windows

Windows

睽违已久:Travis CI终于牵手Windows

大卫 发表了文章 • 0 个评论 • 1221 次浏览 • 2018-10-12 17:16 • 来自相关话题

在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。 Windows系统现已面向tarvis-ci.org或 ...查看全部
在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。

Windows系统现已面向tarvis-ci.org或者travis-ci.com上的全部开源及私有项目使用,我们亦有计划尽快将其引入企业环境。这是我们第一次发布Windows支持方案,因此相关工具链还不够完善——期待大家能够在我们的社区论坛上提供反馈。请马上加入吧!

我们知道,大家一直在期待对Windows系统的支持方案。在论坛上的2104号问题中,我们发布了一些关于初步规划的见解,而我们杰出的贡献者Hiro Asari于2013年也加入到项目中来。Hiro开发出多个早期概念验证方案以及一系列其它成果,同时快速成为我们在GitHub上的应答发言人,外加travis-build与dpl的维护者/开发者。经过这么长的时间,以及众多原型设计,Windows支持能力终于准备就绪——这样的结果令我们的激动之情溢于言表。

另外,我们在npm上的好朋友们同样对此抱有极高热情!

今天的公告带来了令人振奋的消息。我们知道,有超过40%的npm用户在使用Windows设备,但在此之前只有一小部分软件包能够在CI当中主动运行Windows测试。为Travis CI添加Windows支持能力将为JavaScript社区的主体带来更稳定的开发体验——更具体地讲,npm Registry中有32%的项目在使用Travis CI。我们期待着继续与Travis CI开展合作,从而降低开发人员的日常工作难度,并最终确保全球超过1000万开发者构建出令人惊叹的产品。 ——npm有限公司首席执行官Laurie Voss

我们迫不及待希望扩展Windows Build Environment,用以支持大家团队及社区中正在进行的一切出色工作!
#Windows Build Environment
这套Windows构建环境在发布之初支持Node.js、Rust以及Bash语言。我们还运行有一套git bash shell,用以维持与我们其它基于bash环境间的一致性。此外,Docker同样可用于各Windows build。

我们利用Chocolatey作为软件包管理器,同时预安装有Visual Studio 2017 Build Tools以帮助用户。大家现在可以点击此处通过文档查阅我们目前在Windows构建环境中提供的全部软件包。Windows构建环境目前基于Windows Server 1803,其中作为容器运行平台的系统版本为Windows Server 2016。

我们还在Google Compute Engine中托管我们的Windows虚拟机,不过我们发现其启动时间会有所差别。因此我们打算在接下来的基础设施调整工作当中,持续对其做出改进与优化。
##上手指南
要运行一套Windows build,请将以下内容添加至 .travis.yml当中:
os: windows

大家也可以利用以下内容对多套操作系统进行测试:
os:
- windows
- linux
- osx

我们还在Windows上为大家准备了其它一些酷炫的项目,例如:

* yargs/yargs
* npm/node-semver
* docker-library/golang -(请参阅PR for how docker-libary/golang added Windows support!

希望上述内容能够为大家带来更多启示与灵感!
#展望未来
在早期版本发布之后,我们将根据大家的反馈对构建环境及运行时工具的安装与配置做出持续改进。我们希望在接下来的3到6个月内进行快速迭代,并计划在2019年第二季度推出稳定版本。在同一时间点上,我们还希望能够推出Windows Build Environments for Enterprise。如果大家热切盼望其尽早推出,请与我们的企业团队!
#分享您的反馈!
要将Windows推向更高级别,我们需要您带来的反馈意见——特别是在Windows上进行开发的朋友们!您希望获得哪些工具?环境应当如何运作?您需要了解哪些内容才能保证自己的团队快速上手?请在社区论坛上给我们留言。我们正在努力为最好的CI社区构建最出色的CI方案,而您的意见是我们达成目标的必要前提。

此外,这里还要感谢一直为我们提供帮助的贡献者们——特别是Jordan Harband、Alex Crichton、Tianon Gravi以及其他无数参与者!

我们期待着听到您对Travis CI与Windows平台结合方面提出的宝贵建议!

原文链接:Windows is Available (Early Release)

如何在Windows 10上运行Docker和Kubernetes?

yahoon 发表了文章 • 1 个评论 • 12920 次浏览 • 2018-08-12 22:08 • 来自相关话题

在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。 但是 ...查看全部
在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。

但是不要担心!

这篇文章就是为在Winodws上刚刚入门容器和Kubernetes的同学而准备的。

你将会学习到如何做出正确的选择来搭建Windows上的容器开发环境。

让我们从Docker说起。
# 你正在使用Windows 10 Home版?你将无法运行Docker for Windows
当Docker的开发者们决定在Winodows上实现Docker时,他们选择了Hyper-V作为虚拟化技术。这个优点十分明显:优秀的性能和原生的hypvervisor。

不幸的是并不是所有的Windows版本带Hyper-V支持

如果你正在使用Windows 10 home版或者Student版,那么你就中招了。你将无法安装和运行Docker for Windows。

但是先别失望。

你有许多基于Docker Machine的替代品可用,例如Docker toolbox或者minikube。

Docker Machine的工作方式很简单:有一个VM装好了Linux和Docker给你。你可以从你的主机连到虚拟机上的Docker deamon。

Minikube可以说是基于Docker Machine的最有趣的VM之一——你可以在里面运行Kubernetes集群。

事实上,minikube是一个运行Docker和Kubernetes的VM。它通常是用来单独运行Kubernetes的,但是你也可以用它来跑Docker容器。

你可能不会拥有Docker for Windows那样的速度,但是毕竟你不需要Hyper-V就能够构建和运行容器了。
# 有了Windows 10 Pro,Docker for Windows是最佳选择(除了特殊情况)
你有最新的Win 10 Pro,你可以安装Docker for Windows。 你拥有了优秀的性能和开发者体验,一切都搞定了,是吗?

答案是不一定!

Docker for Windows使用的hypvervisor是相当强大的——它属于`Type-1 hypervisor`。 它确实很强大但是它却无法与Virtualbox这样的`Type-2 hypervisor`一起工作。

你不能在同一台机器上同时运行Type 1和Type 2的hypervisor。换句话说,如果你运行Docker for Windows,那你就无法启动VirtualBox里面的VM了。

这跟你的设置相关,影响可大可小。

如果你已经完全使用容器化了,你就不需要担心VM——过时的东西。

但是如果你仍然要使用VM,以及类似Vagrant这样的工具,那你可能就有麻烦了。

你可以随意的启用或者关闭Hyper-V hypervisor,但是你要重启机器

如果你频繁的要从容器切换到VM,那可能使用minikube更方便。当你从容器切换到VM的时候就不用重启电脑了。 缺点就是你没办法得到更高性能和更好体验。

最后,如果你要运行Windows容器——`base镜像是来自于Windows的容器`——Docker for Windows是唯一选择。 你只能使用Windows 10 Pro或者Enterprise版。
# 运行一个本地的Kubernetes集群
如果你想要跑一个本地的Kubernetes,那你应该考虑minikube。

Minikube是一个预装有嵌入式Linux(Buildroot)和Docker daemon的VM。

它是一个最小完整的Kubernetes环境

Minikube的VM可以通过VirtualBox或者Hyper-V来运行(当然也有其他选择)。如果你已经有Hyper-V也要用它来跑Docker和minikube的话就会很方便。

当然如果你不能跑Hyper-V也没关系,你可以用VirtualBox实现同样的功能。

有很多的选择和权衡,下图列出了一些:
1.png

# 前提
你可以从官网上下载安装Docker for Windows、Docker Toolbox、VirtualBox、kubectl、Docker CLI等,但是相当麻烦。

你要去到官网找到正确的下载地址,选择正确的版本,下载安装,最后加到你的path里面去。

这当然可行,但是我敢肯定你更愿意把时间花在编码而不是从网站上下载安装软件包上。

使用Chocolatey

Chocolatey是一个Widnows的包管理器。你告诉它想要安装的包,它会为你装好。你把软件安装的活外包给它了。

安装Chocolatey很简单,你可以在它的官方网站找到步骤。简单来说,就这么几步:

1、以管理员启动`cmd.exe`

2、执行下面这个命令:
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

3、重新加载`cmd.exe`

如果安装成功,那么你可以搜索软件包:
choco search docker

我们来试一把,安装Cmder——一个Windows上的时尚shell:
choco install cmder -y

Chocolatey会安装到`C:\tools`下。如果你要用Cinder做如下的练习,您可以以管理员启动它:
2.png

看起来不错!
# 1. 在Windows 10 Pro上安装Docker和Kubernetes
##安装Docker
安装Docker for Windows:
choco install docker-for-windows -y

重启你的电脑。Docker会问你是否要启用Hyper-V。
3.png

选择Yes。

你需要知道Docker需要启用VT-X/AMD-v的硬件虚拟化扩展来运行容器。你需要在重启电脑时在BIOS里面配置它。

你可以用systeminfo命令来检查VT-x/AMD-v是否打开。

如果你不确定VT-x/AMD-v是否打开,也不用担心。因为你没有的话,Docker会报错:

Hardware assisted virtualization and data execution protection must be enabled in the BIOS.



4.png

另一个常见问题是Hyper-V没有启用,这样你会见到如下错误:
5.png

你应该启用Hyper-V。以管理员打开新的命令提示符,敲入:
bcdedit /set hypervisorlaunchtype auto

你重启电脑之后Docker就应该可以启动了。

但如何知道Docker已经跑起来了呢?

打开命令提示符:
docker ps


如果一切正常,那么你会看见输出一个空的列表(正在运行的容器列表)。

如果Docker deamon没有运行的话,你可能就会遇到如下错误:
6.png

上面的错误表示你的Docker安装不正常,Docker无法启动。

你应该先启动Docker daemon,然后再连接它。
# 在Hyper-V上安装Minikube

安装minikube:
choco install minikube -y

在启动集群之前,你应该先创建一个外部的网络交换机。

第一步,你应该先查看你电脑的网络适配器。

你应该忽略掉虚拟网卡,而关注在真实活跃的物理网卡上,比如Ethernet或者WiFi。

选择好物理网卡让它与虚拟交换机共享网络连接。

要查看你当前的网络适配器,你可以在PowerShell里面使用Get-NetAdapter cmdlet。

点击左下角的Windows图标,输入PowerShell来打开它:

输入如下命令来列出所有的适配器:
Get-NetAdapter

7.png

如果你还是不知道该选哪个,那么就选择Up状态的那个。

一旦你选择好了适配器,你就可以开始创建外部虚拟交换机了:
New-Switch -Name "minikube" -AllowManagement $TRUE -NetAdapternmae "INSERT_HERE_ADAPTER"

别忘了填入之前选择的适配器名字。

如果你没有创建好网络交换机,那么启动minikube的时候会报如下错误:

E0427 09:06:16.000298 3252 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks. no External vswitch found. A valid vswitch must be available for this command to run. Check https://docs.docker.com/machine/drivers/hyper-v/.



你可以运行以下命令来测试minikube安装是否成功:
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube


请注意:`--vm-driver=hyperv --hyperv-virtual-switch=minikube` 只在第一次启动时需要。如果你希望更改driver或者内存,那么你需要执行`minkube destroy`然后用新的配置重新创建。

如果minikube启动失败,那么你可以通过以下命令调试:
minikube delete
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube --v=7 --alsologtostderr

更多的输出日志可以帮助你快速排错。我遇到过如下的问题:

E0427 09:19:10.114873 10012 start.go:159] Error starting host: Error starting stopped host: exit status 1.



这看不出来啥。我就打开详细的日志输出,错误就变得明显了:
+ Hyper-V\Start-VM minikube 
+ + ~~~~~~~~~~~~~~~~~~~~~~~~~
+ + CategoryInfo : FromStdErr: (:) [Start-VM], VirtualizationException
+ + FullyQualifiedErrorId : OutOfMemory,Microsoft.HyperV.PowerShell.Commands.StartVM

内存不够了!

这时可以看看安装成功了没。在命令提示符输入:
kubectl get nodes


你会看到Kubernetes里面有一个node显示出来。

在virtualbox里面运行虚拟机

因为你已经在设备上启用了Hyper-V,你就无法再通过virtualbox跑VM了。如果你强行要启用vm的话,会遇到如下错误:
8.png

如果你想用VirtualBox这种Type-2 的hypervisor, 你先要停掉Hyper-V然后重启电脑。

以管理员打开命令提示符:
bcdedit /set hypervisorlaunchtype off

当机器重启之后,你就可以正常使用VirtualBox了。

如果你又想要用Docker和minkube了,你要重新打开Hyper-V然后重启机器。

以管理员打开命令行,输入:
bcdedit /set hypervsiorlaunchtype auto

重启, 这样你就可以将容器部署到Kubernetes中了。

请跳到测试你的Docker 安装
#2. 在Win 10 Home版本上安装Docker和Kubernetes
如果你正使用Windows 10的Home版或者Student版,你可能不需要安装Docker Machine 工具(比如Docker Toolbox)。

你应该使用minikube作为远程的Docker deamon和本地的Kubernetes集群。

你可以下载安装minikube:
choco install minikube

在装完了以后,你可以启动:
minikube start

这个命令会下载一个VirtualBox要用到的ISO,然后启动VM。启动之后你就可以查看集群状态:
kubectl get nodes

看见一个node列出来。

要连接到远程的Docker deamon,你应该安装Docker客户端:
choco install docker -y

你可以连到minkube上远程的Docker daemon:
@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i


注意:每次你打开一个新的命令行窗口,你都需要以上命令。一种提醒你自己的简单方式是敲一下`minikube docker-env`。

如果连接成功,你可以列出当前正在运行的容器:
docker ps

你会看到很多容器正在运行。大部分属于Kubernetes。

你已经一切准备就绪!

但是在你继续之前,你需要清楚使用minikube作为你远程Docker daemon的一些限制。

Docker被设计为两个部分:

  • Docker daemon ——你可以将它理解为一个API server。你把命令发给它的API,Docker接收然后执行命令。
  • Docker CLI —— 将命令发送给Daemon API的可执行文件。

大部分时间你都只会跟Docker CLI 交互,你不会看到Docker daemon。

那么为什么要有客户端和服务器?为什么不用一个文件?

这都是为了灵活性

当你运行Docker for Windows时,Docker CLI连接的是本地的Docker daemon。
9.png

但是有时候你本地没有daemon

可能你需要在一台远端的机器上构建Docker容器。

可能你没有Hyper-V环境,你的Docker daemon是安装到VirtualBox里面的VM中的。

特别是你正在运行minikube。

你的Docker CLI会连接到远程的部署在minikube虚拟机里面的Docker Daemon上。
10.png

当你的容器运行在远程的Docker daemon上的时候,你需要调整端口绑定。

在Docker for Windows,你可以将容器端口绑定到8080:
docker run -ti -p 8080:80 nginx

注意:容器本身暴露的是80,你把它映射到了8080。

然后你可以访问http://localhost:8080然后看见Nginx的欢迎页面。

如果你在远程的Docker daemon上运行此命令然后访问这个URL时,你会发现什么也没有,URL不可达。

所以有什么不同?

Docker deamon负责运行容器和端口转发。

Docker for Windows的daemon是在本地运行的——你自己的本机

所以你可以访问本机上的容器。

Minikube则不同,它的Docker daemon是运行在VM里面的。

它是远程的deamon。


如果你想要看见你运行的容器你需要访问Docker daemon所在的机器。 你可以用以下命令找到IP:
minikube ip

你可以通过http://your_minikube_ip:8080来访问,看到Nignx的欢迎页面。
# 测试你的Docker安装
你已经安装好了Docker,那你如何知道它是否工作正常呢?

进入到终端,输入:
docker run -ti -p 8080:80 wordpress

一旦Docker下载完所有的包,你可以通过http://localhost:8080来访问。

注意:如果你在使用远程的minikube上的Docker daemon时,你应该使用http://your_minikube_ip:8080来访问。

你应该可以看到Wordpress的安装向导了。

万岁!恭喜你!

Wordress就在一个容器里面对外服务了。

注意:你还不能完成那个Wordpress的安装因为你还有数据库。
# 测试你的Kubernetes集群安装
是时候测试你的本地的Kubernetes集群了。在这一部分,你将会部署Smashing.io面板
11.png

## 部署Smashing到Kubernetes里面
你可以用如下命令部署:
kubectl run smashing --image=/visibilityspots/smashing --port=3030

一旦Kubernetes完成了容器的安装,你可以查看运行状态:
kubectl get pods

## 暴露面板
你可以将你部署的服务器暴露出来:
kubectl expose deployment smashing --type=NodePort

你可以通过浏览器打开面板:
minikube service smashing

这样你就可以从Kubernetes里面访问面板了! 万岁!
# 鸟瞰Kubernetes
Minikube本身自带了一些好东西。

你可以访问官方自带的面板
minikube dashboard

12.png

从这里,你可以查看你的集群详细信息和部署应用。
# 总结
现在你已经了解了在Windows上安装Docker和Kubernetes的所有选项。

如果你遇到了文章没提到的错误,请通过@learnk8s或者slack告诉我们。

接下来,你可以在你的环境里面部署更多应用了。请看文档

原文链接:Get started with Docker and Kubernetes on Windows 10(翻译:姚洪)

Docker公司新发布的多云战略,能让他在B端扳回一局吗?

大卫 发表了文章 • 0 个评论 • 1303 次浏览 • 2018-06-19 08:17 • 来自相关话题

在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。 ...查看全部
在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。

Docker公司推出的Docker企业版是一款用于管理容器化应用程序的商业产品,可帮助企业客户将部署在内部、云环境以及托管Kubernetes当中的应用程序联合起来。目前的主流云托管Kubernetes方案包括Azure Kubernetes Service(简称AKS)、AWS Elastic Conatiner Service for Kubernetes(简称EKS)以及谷歌Kubernetes引擎(简称GKE)。

根据Docker公司的介绍,Docker企业版是目前惟一能够通过安全供应链提供联合应用程序管理功能的容器平台。利用Docker企业版,客户可以任意选择Linux发行版或Windows Server、将其运行在虚拟机或者裸机之上,运行传统或微服务应用程序并配合Swarm或者Kubernetes编排工具,同时灵活选择用于运行容器化工作负载的云平台。

Docker企业版中提供的联合控制平台还能够进一步提升应用程序的可用性。部署在某一位置的应用程序将自动跨越多个集群进行复制。当主集群不可用时,Docker企业版会将流量以透明方式路由至另一正常集群处。除此之外,客户还能够利用Docker企业版无缝跨越不同开发、分段及生产环境以管理应用程序。

自决定对接Kubernetes以来,Docker公司一直努力寻找新的独特竞争优势。通过应用程序管理联合,Docker公司希望填补现有Kubernetes产品当中存在的空白。然而,这项功能并非Docker企业版独家所有。

事实上,Kubernetes社区一直在努力以对支持不同环境的运行集群进行联合。上游Kubernetes发布一套更为稳定且流畅的集群联合方案已经只是时间问题。因此,Docker公司不得不利用其企业平台正面对抗其它基于Kubernetes的产品。

Docker公司正与微软方面密切合作,旨在将Kuberntes与Windows容器相集成。微软已经通过Docker API与CLI公布原生Windows容器。Docker与微软目前亦着手将Windows工作负载运行在由Kubernetes与Docker企业版结合而来的平台之上。这意味着企业客户将能够选择Swarm或者Kubernetes部署自己的Windows与.NET应用程序,且确保其与Linux应用程序产行运作。

微软公司正在积极推动Windows成为Kubernetes世界中的一等公民。Azure Kubernetes Service作为由微软推出的云托管Kubernetes方案,目前已经能够支持Windows容器。客户现在可以注册以体验该功能的技术预览版本。

微软公司的目标是在Azure Stack私有云平台上实现Azure服务。最终,AKS也将正式登陆Azure Stack,并为Windows Server提供原生容器编排支持。当这一切成为现实后,市场态势将转变为Docker企业版与AKS on Azure Stack的对决。

Docker公司亦面对着来自红帽及Pivotal等专门面向企业客户的供应商的竞争压力。来自红帽的OpenShift容器平台与来自Pivotal的Pivotal容器服务(简称PKS)都直接将矛头指向Docker企业版。此外,AKS、EKS以及GKE等公有云托管型Kubernetes产品同样发展迅速。很明显,Docker公司必须建立自己的差异化优势才有机会力压其它各大Kubernetes供应商。

那么,将应用程序与Windows容器联合起来是否有助于该公司获取市场份额?我觉得Docker企业版的主旨并不在于此。事实上,Docker公司的核心任务在于推动创新,从而为其企业平台创造引人注目的价值主张。

容器生态系统已经变得非常拥挤。从主流平台厂商——例如红帽与微软,到早期初创企业,每个人都想在其中分一杯羹。而对Docker公司来说,赢取企业市场份额无疑将是一场艰苦的斗争。

原文链接:Will Multi-Cloud Strategy Help Docker Inc. Win The Enterprise?

LCOW —— 单一Docker引擎下可同时运行Linux和Windows容器啦!

tiny2017 发表了文章 • 0 个评论 • 4970 次浏览 • 2018-01-26 13:19 • 来自相关话题

【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。 ...查看全部
【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。

就在上周,Docker官方的master分支上新增了LCOW(Linux Containers on Windows)功能。启用这项功能,即可在单一的Docker引擎下,同时运行Linux和Windows容器。

下面赶紧跟小编一起,看看Windows 10将会发生哪些变化?
lcow-marked.jpg


  • 可以用Docker命令`docker ps`,列出所有正在运行的Linux或Windows容器。
  • 在容器和主机之间通过存储卷共享数据。
  • 容器之间可以通过容器网络互相通信。
  • 通过将端口映射到主机,实现本地访问。但目前,它还只是Windows 10 1803版预览体验计划(Windows Insider)的一项功能。

#运行Linux容器

现在,你需要指定`--platform`来拉取Linux镜像。如果拉取的是一个既有Linux又有Windows的多重架构的镜像,同样需要指定该选项。
docker pull --platform linux alpine

镜像拉取完毕即可运行,无需指定`--platform`选项。
docker run alpine uname -a

另外,Windows上运行Linux容器需要一台小型的Hyper-V虚拟机。同时,LinuxKit项目提供了LCOW的镜像,请参照:https://github.com/linuxkit/lcow
#共享存储

接下来我们看一下,如何用一种简单的方式,实现不同平台容器间的数据共享。

方法是把Linux和Windows容器,绑定到同一个存储卷。

下面的例子中,Linux和Windows容器通过主机的一个共享文件夹,实现数据共享。
2.gif

首先,在Windows 10 上新建一个文件夹。
cd \
mkdir host

##启动Linux容器

在Windows 10主机上启动一个Linux容器,并且将主机上的共享文件夹挂载到该容器的`/test`文件夹。
docker run -it -v C:\host:\test alpine sh

我们在`/test`文件夹下,新建一个名为hello-from-linux.txt的文件。
uname -a > test/hello-from-linux.txt

##启动Windows容器

在Windows 10主机上启动一个Windows容器,并且将主机上的共享文件夹挂载到该容器的`C:\test`文件夹。
docker run -i -v C:\host:C:\test microsoft/nanoserver:1709 cmd

我们在`C:\test`文件夹下,新建一个名为hello-from-windows.txt的文件。
ver > test\hello-from-windows.txt

##测试结果

上述两个容器中新建的文件,都保存在Windows 10 主机的共享文件夹。
PS C:\> dir host


Directory: C:\host


Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 1/21/2018 4:32 AM 85 hello-from-linux.txt
-a---- 1/21/2018 4:33 AM 46 hello-from-windows.txt

在开发过程中,如果需要共享配置文件或代码的话,这实在是太方便了有木有~
#混合编排

值得一提的是,使用Docker Compose还可混合编排容器。下面是一个混合编排Linux和Window web服务器的例子。
    version: "3.2"

services:

web1:
image: nginx
volumes:
- type: bind
source: C:\host
target: /test
ports:
- 80:80

web2:
image: stefanscherer/hello-dresden:0.0.3-windows-1709
volumes:
- type: bind
source: C:\host
target: C:\test
ports:
- 81:3000

networks:
default:
external:
name: nat

你也可以思考一下,如何编排一个Linux数据库和Windows前端,反过来也一样。
#如何搭建你的LCOW测试环境

如果你想试着玩一下LCOW,建议使用Windows 10 1709虚拟机。
##Azure

我在微软Azure上用Windows 10 1709虚拟机测试过LCOW。你可以选择具有嵌套式hypervisor的V3 机器以便运行Hyper-V容器。
##容器和Hyper-V

首先,启用容器和Hyper-V功能:
Enable-WindowsOptionalFeature -Online -FeatureName containers -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart

##LinuxKit

然后,为你的LCOW安装一个LinuxKit镜像。下面是我下载的最新版LinuxKit,你也可以自行从linuxkit/lcow下载。
Invoke-WebRequest -OutFile "$env:TEMP\linuxkit-lcow.zip" "https://23-111085629-gh.circle-artifacts.com/0/release.zip"
Expand-Archive -Path "$env:TEMP\linuxkit-lcow.zip" -DestinationPath "$env:ProgramFiles\Linux Containers" -Force

##创建Docker

现在,你可以下载并安装Docker引擎了。
Invoke-WebRequest -OutFile "$env:TEMP\docker-master.zip" "https://master.dockerproject.com/windows/x86_64/docker.zip"
Expand-Archive -Path "$env:TEMP\docker-master.zip" -DestinationPath $env:ProgramFiles -Force

接下来,安装Docker service并打开实验功能。
 . $env:ProgramFiles\docker\dockerd.exe --register-service --experimental

紧接着,配置PATH以便使用Docker CLI。
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";$($env:ProgramFiles)\docker", [EnvironmentVariableTarget]::Machine)

恭喜你!现在可以重启机器了。重启过程中会自动更新容器和Hyper-V的配置。如果一切顺利,重启完后Docker engine应该已经起来并处于运行状态了,这时你可以在PowerShell终端使用Docker CLI。
#本地的Vagrant环境

如果你的Vagrant安装了Hyper-V或VMware,那就更方便了。只需几个命令,就可轻松搭建本地测试环境。

你只需要从我的GitHub下载包含LCOW环境的docker-windows-box,执行以下命令就可以了。
git clone https://github.com/StefanScherer/docker-windows-box
cd docker-windows-box
cd lcow
vagrant up

如果你的Windows 10虚拟机上没有Vagrant base box,系统会自动下载安装。如果已经下载了,则只进行安装。
#总结

未来几个月,随着这些Docker新功能加入到Windows,Windows 10无疑将成为2018年最具吸引力的开发者平台。

想象一下,你用`docker-compose.yml`编排Linux和Windows容器,通过Visual Studio Code实时调试你的应用程序,等等。

如果您喜欢这篇文章,请分享给您的朋友。如果想了解Windows容器的最新情况,请关注原文作者的推特@stefscherer

原文链接:A sneak peek at LCOW (翻译:Tiny Guo)

Windows Server 1709:以容器为中心,向DevOps画圆

ds_sky2008 发表了文章 • 0 个评论 • 2853 次浏览 • 2017-11-05 16:58 • 来自相关话题

【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。 大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是 ...查看全部
【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。

大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是对Windows Server服务器的核心版本做了重大更新,其中包括企业版和数据中心版的新版本。新的Windows Server支持基于DevOps的组织并增强对容器和云部署的支持。

但是为了“尝鲜”新版本的好处,你将不得不放弃Windows Server UI,转而使用命令行(特别是通过PowerShell)和远程用户界面(如熟悉的RSAT和基于浏览器的新项目火奴鲁鲁Honolulu)来管理服务器。

下载InfoWorld Deep Dive:[基于Windows,Windows Server和Exchange 的PowerShell使用指南。]

千万别太惊讶:其实微软已经离开服务器GUI有一段时间了,而且其命令行工具在使用脚本进行远程管理多个服务器方面具有显著的优势。混合使用PowerShell和火奴鲁鲁(Honolulu)不会使管理变得更加困难,这将使Windows Server与各种基于Unix的竞争对手站在同一起跑线。它还将为微软提供一个新的管理基准,在这个基准上添加对容器的支持以及其他与服务器操作系统一起工作的新方法。

要安装Windows Server 1709,你必须进行全新安装(clean install),因为它会将你移至新的、每年两次的新版本发布频道。通过强制全新安装,Microsoft正在试图清楚地表明,你正在逐渐从Windows Server 2016的长期支持的5 + 5支持模式转向一个每年两次的新版本和18个月的支持模式。
# Windows Server 1709中的新容器功能
微软显然更钟情于正在使用Windows Server 1709的应用程序和容器开发人员。新的容器基础镜像包括服务器核心和纳米服务器;服务器核心,用于现有应用程序的“提升和移位”方案,以及用于基于.Net Core或Node.js的新应用程序的Nano Server。容器基础镜像也显著缩小 - 服务器核心镜像减少60%,纳米服务器减少80% - 使得在这些镜像之上部署新容器的速度更快。

“提升和移位”选项是一个有趣的选择,因为它可以让你用最少的工作容器化现有的代码。当然,构建应用程序在容器中运行的架构问题,例如确保所有的应用程序数据都存储在容器之外,所以你必须做一些改进。但在实践中,进行适当的更改不应太困难 - 特别是在使用Windows Server或Azure的存储工具和API时。
# Windows Server的新计划符合DevOps的思路
每六个月发布一次新的Windows Server将不会满足每个人的口味(实在是众口难调)。虽然你可以跳过一个版本(例如,从1709跳到1809,忽略1803),但这并不会改变Windows Server将会每个版本只有18个月的支持而定期进行重大更新的事实。Windows Server新的节奏可能最适合那些已经转移到devops驱动流程的组织,在这个流程中,应用程序驱动整个策略。

DevOps的方法当然是与云优先发展一致的。一段时间以来,Windows Server需要与Linux的快速开发进度竞争,尤其是在使用容器镜像的情况下。这是捆绑的Nano服务器在Windows Server 1709中重新思考的主要原因; 支持基础架构角色的容器主机没有任何意义,特别是当主操作系统构建也变得更轻量级时。

尽管如此,微软对Windows Server的更改对于三年或五年发行版的系统管理员来说也是一个挑战。对他们来说,还有一个长期服务通道(LTSC),它将继续像Windows Server一样被发布。

你甚至可以在你的数据中心混合使用Windows Server版本,使用旧版应用程序的LTSC和Windows Server 1709,以及将来的新版本和云使用版本。尽管Windows Server 1709和更高版本包含基础架构角色,但你应该使用这些每年两次的版本来发布虚拟机中的应用程序托管以及容器基础镜像。为VM主机,存储和Active Directory继续使用Windows Server LTSC基础架构服务器是有意义的。服务器部署的混合方法很有意义,因为毕竟,基础架构服务器在部署后不应更改,除了获取安全更新之外。

如果我们将基础设施操作从DevOps中分离出来,这个分离模型更有意义。在DevOps领域,基本操作系统的相对迅速的变化不是问题,因为它们只是持续集成管道的另一个要素,还有代码和其他软件定义的基础架构。

旧的贝塔系统和社区预览已是昨日黄花。一些选定的客户仍然可以访问TAP构建,但其他人都应该加入Windows Insider计划,以迎合未来的变化。在新的每年两次的更新节奏中,参与Windows Insider程序比以往任何时候都更加重要,因为Windows Server的新计划将要求在每个新版本部署之前通过快速测试来验证应用程序。

即便如此,测试不应该是繁重的。毕竟,每隔两年一次的增量版本和大爆炸产品每隔几年就会有天壤之别。由于每台Windows Server新版本的新功能要少得多,所以它们对现有应用程序的影响很小。

原文链接:Windows Server 1709: Container-focused, devops-oriented(翻译:ds_sky2008)

docker for windows 使用 --net=host启动容器后,从主机无法访问

回复

karel 发起了问题 • 1 人关注 • 0 个回复 • 3131 次浏览 • 2017-09-29 17:19 • 来自相关话题

不得不知的容器生态圈发展趋势

Rancher 发表了文章 • 1 个评论 • 2399 次浏览 • 2017-05-08 11:57 • 来自相关话题

Docker于 2013年推出以来,给软件开发带来了极具传染性的振奋和创新,并获得了来自各个行业、各个领域的巨大的支持——从大企业到初创公司,从研发到各类IT人员,还有开源社区、ISV、最大的公共云供应商、软件堆栈上的每个工具等。自Docker推出以来,许多重 ...查看全部
Docker于 2013年推出以来,给软件开发带来了极具传染性的振奋和创新,并获得了来自各个行业、各个领域的巨大的支持——从大企业到初创公司,从研发到各类IT人员,还有开源社区、ISV、最大的公共云供应商、软件堆栈上的每个工具等。自Docker推出以来,许多重大的里程碑事件都推动了容器革命。让我们就其中一些作个简要回顾。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
容器编排工具的选择

容器入门非常简单。所需要的仅是笔记本电脑和Docker客户端。然而,运行微服务应用程序则要另当别论。其中最困难的是创建、管理和自动化临时容器集群。

解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon。即使在Docker之前就已经提供了分布式基础设施,Marathon也可以在Twitter和其他大型Web应用程序中的生产工作负载中使用。

下一个得到广泛认同的编排工具是Kubernetes。事实上,如今Kubernetes因为它的可扩展性已经领先于Docker编排工具。它支持广泛的编程语言、基础设施选项,并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来,从而能够跨多个云供应商和基础设施设置,实现真正的可移植性。

Docker Swarm随后也加入了容器编排领域,并且其覆盖率已经迎头赶上。Swarm很容易上手,并且能与Docker平台的其他部分很好地集成。初步迹象表明,这一竞争已经改变了Kubernetes。

对企业而言,编排工具是容器应用成功的关键。尽管这三个选择都不差,但您应该根据您的需求做出最合适的选择。

容器安全快速发展

在初期,容器默认的隔离性较弱。随着时间的推移,这一情况正在发生变化。与容器安全相关的一个关键进展,是出现了多个能力强大的容器 registry。registry通过存储和扫描容器镜像和存储库来发现漏洞。这是Docker安全性的重要组成部分,因为未经验证的发布商提供的公开存储库,极容易带来安全威胁。这也是开放的生态系统的缺点之一,因为在开放的生态系统中,镜像很容易共享。但使用 registry进行安全检查可以减少这种风险。

Docker Hub是大多数Docker用户开始使用的默认registry,也是目前最流行的。主要的IaaS提供商都有自己的registry。这很有必要,尤其是如果您大量投资AWS、Azure或Google Cloud。它们具有默认的存储库扫描功能、更成熟的访问控制,以及一系列用于联网、存储和监视的其他工具。除此之外,像Quay和GitLab容器 registry这样的第三方 registry也越来越受欢迎。registry的选择比编排工具多得多,市场也很开放。

除了 registry之外,TwistLock和Aqua security等第三方容器安全服务商也提供了超出默认值的安全性。

适用于Windows和Mac的原生Docker客户端

Docker最初是一种基于Linux的技术,它依赖于Linux内核中内置的特殊功能(这些功能只能在Linux上可用,而非其他类似Unix的内核)。如果要在Windows或Mac上运行Docker,则必须使用虚拟机引擎(如VirtualBox)和基于Linux的虚拟机来托管Docker环境。对于那些想在Windows或Mac机器上测试Docker应用程序的开发人员来说,这个设置非常方便,但作为Docker服务器部署解决方案却不实用。

2016年初,随着原生Docker对Windows的支持,情况发生了变化。这是一项重大进展,因为许多企业工作负载在Windows Server上运行。在这些环境中使用Docker的需求很强劲。

目前, Docker在Windows上本机运行时,仍存在一定局限性。网络尚未完全实现,仅支持Windows Server 2016和Windows 10。但是,Docker已经支持原生Windows,这一进展已经为Windows生态系统中的Docker提供了大量的新机遇。

内置VS开源Docker组件

Docker公司已经建立了企业版(包括Docker Datacenter,它现在已经集成到Docker的新企业版平台中),它们由Docker本身的组件组成,其中包括Swarm管理器,而Docker Engine并未内置这些组件。Docker对使用自己的工具来建造容器堆栈更感兴趣,而不是与容器生态系统中的其他组织合作,最初引起了一些人的担忧,即Docker将忽略社区标准。去年八月份,出于这方面的担忧,他们甚至还谈到了forking Docker。(不过至今并没有谁真的fork了Docker。)

最近,随着Docker采取措施向客户保证它不会垄断行业,这种紧张局势已经平息。它对CNCF的积极贡献,包括最近将底层的容器技术开源,都是朝这个方向发展的。在上个月的DockerCon大会上,该公司通过将代码转移到Moby项目,并引入LinuxKit,从而使它的主要项目更模块化,更便于社区访问。(这里分析了这些变更对Rancher Labs、Rancher产品以及各种各样用户的影响)

当然,Docker仍然有批评者。但相比一年前,Docker技术栈明显更加开放,并能与其他生态系统更好地集成。

结论

容器生态系统仍然在不断发展与改变。也许当我们刚弄清楚Docker对于跨所有类型组织的应用程序意味着什么时,新的标准又出现了。本文所强调的趋势是一个快速成熟的生态系统的指标。最值得关注的,是在这一领域中,Docker和各个供应商是如何进步,以推动容器生态系统的发展的。

原文来源:Rancher Labs

Docker for 开发:容器化你的应用

gaohongtao 发表了文章 • 0 个评论 • 9959 次浏览 • 2017-04-11 11:01 • 来自相关话题

【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。 【3 天烧脑式容器存储网络训练 ...查看全部
【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

作为开发者,我们总是寻找一个捷径或更容易的方法来快速起步,对吧?如果你是团队领导,付出最少的代价让团队站在同一个起点是很重要的。 Docker可以提供帮助。

在软件开发领域,一直越来越强调模块化,从单一责任的一般原则到更具体的实现,例如将JavaScript功能模块化为无状态组件。在这里,我将告诉你我们如何使用Docker来模块化我们的开发环境,以获得许多类似的好处,包括帮助我们快速起步。
# Docker 4 开发者
如你所知,为了加快项目进度,你有一个待办事项清单:

- 拉取代码基线
- 安装外部工具,如数据库、缓存和一些额外的工具和服务
- 给外部工具打补丁和升级
- 配置数据库和服务以使他们可以通信
- 开始祈祷(可能需要好几次)
- 调试问题(至少要30几次)

想象一下,如果在将应用程序的代码基线拉出存储库之后,您只需运行几个命令行(可能只有一个),可以使整个应用程序的环境准备就绪。听起来很酷,对吧?

这正是我们要完成的。不同于使用一个百科全书式的方法来使用Docker的所有功能和命令,我将介绍容器化开发人员的环境的主要的Docker功能。

这篇文章是关于利用Docker的容器化能力的一系列文章中的第一篇,它很容易构建一个可以在任何时间共享和运行的应用程序开发环境。
## Docker Toolbox 对 Docker for X
Docker Toolbox是可用于处理多个Docker资源的原始工具集合,并且会根据您选择的操作系统而有所不同。但在那之后,他们发布了新的Windows和Mac原生应用程序。因此,除了Linux、OS X和Windows Docker Toolbox变体之外,您还将看到“Doc​​ker for Mac”和“Docker for Windows”。

要理解和决定应该使用哪种工具,我想概述使用新的原生应用程序的前提。原来的Docker Toolbox将会设置一些工具以及使用VirtualBox。它还将提供在Linux Hypervisor上运行的虚拟机,用于Windows或Mac。
## VirtualBox、Hyper-V和Hyperkit,我的上帝啊!
原生应用程序,例如在Docker for Mac中,实际安装的是OS X原生应用程序。它也不再使用VirtualBox,而是使用OS X的hypervisor hyperkit。此外,共享接口和网络的管理更简单。还有一些用户体验更新以便于Docker更好的工作。在Docker for Windows原生应用程序中也会包含这些相同的更改,但是会使用Hyper-V作为hypervisor,以及其他类似的网络和工具更新的主机。

最后,原生应用的体验应该是一个更积极,更有效率的,而且更少的出错。但是,您会发现绝大多数与Toolbox相关的外部文档 - 因此了解Toolbox将是你的优势。
# 开始吧
这个初始教程将简单地使用一个开箱即用的express.js应用程序。当我们开始编辑源代码并在容器之间进行通信时,我将介绍一个运行Webpack的开发服务器的进阶的通用React.js应用程序,其中包含热模块重新加载,MongoDB数据库等。
# 步骤 1:安装
为了努力获得使用Docker并将开发人员环境与各种操作系统版本一起集中化的好处,我将让您选择需要下载的Docker版本(Toolbox或原生)和操作系统:

- Toolbox:https://www.docker.com/products/docker-toolbox (OS X and Windows)
- Docker for Windows:https://www.docker.com/products/docker#/windows
- Docker for Mac:https://www.docker.com/products/docker#/mac

TOOLBOX用户:Docker Toolbox配有“Docker快速入门终端”,并在运行时与Docker环境相关联。但是,通常在您选择的IDE中运行终端或独立运行终端。为了让Docker与另一个终端/提示进行交互,您需要通过运行“docker-machine env”来初始化Docker env。文本显示的末尾是一个命令,您需要从该同一终端中复制该命令以初始化Docker环境。



#步骤 2:源码/环境
下一步是获取要容器化的开发应用程序的源代码。

现在,您可以从GitHub抓取这个项目,这个项目保存了本教程的一些步骤。
# 步骤 3:创建Docker镜像文件
请记住,主要目标是在隔离和模块化的环境中运行我们的应用程序。为了让Docker创建这个环境,我们必须告诉它如何创建它。我们使用包含一组指令的Docker镜像文件

  1. 使用你的IDE,增加一个文件到工程根目录并命名为“Dockerfile”
  2. 拷贝下面的文件内容到这个文件

重要信息:该Docker镜像文件将允许我们创建一个镜像,该镜像将代表我们一直在讨论的容器化环境,并最终创建称为容器的该镜像的运行实例。但是,我们向前跳了一步,这些内容应该在第5步中。



##Dockerfile
FROM mhart/alpine-node:6.9.2
WORKDIR /var/app
COPY . /var/app
RUN npm install --production
EXPOSE 3000
ENV NODE_ENV=production
CMD ["node", "bin/www”]

Dockerfile是Docker在镜像文件中寻找的默认名称,但它可以是任何名称,我们将在稍后的步骤中看到。这些指令告诉Docker我们要创建一个镜像:

- 从一个基础的mhart/alpine-node镜像的6.9.2标签开始创建
- 设置应用程序初始运行的工作目录WORKDIR
- 拷贝当前本地目录“."中的内容到工作目录
- 然后从工作目录运行RUN命令npm install —production”
- 我们将对外暴露 EXPOSE3000端口从容器中,当它从镜像中被创建的时候
- 另外我们想要对容器设置本地环境变量ENV NODE_ENV的值为“production”
- 最后,我们启动express.js服务,它驻留在bin目录中的“www”文件中,执行命令“node bin/www”

提示:Docker总是需要一个基本的镜像,镜像保持尽可能小空间占用是关键。alpine-node镜像是非常小的(49.65mb),包括Node.js和NPM。



#步骤 4:构建一个镜像
现在我们有一个Docker镜像文件,它指定了有关如何创建镜像的详细信息,让我们停下来谈谈镜像是什么:
01.png

镜像是只读分层文件系统。它构成了我们不断追求的环境的基本文件系统。我们在上一步中创建的镜像文件将指示Docker如何去创建镜像的每层。

但如果它是一个只读的文件系统,我们如何去写它,(例如,执行代码的变化对我们的应用程序的代码在开发过程中)?好问题,我会在即将到来的步骤中回答。
## 步骤 4a:构建生产镜像

  1. 从一个终端中导航到项目根目录
  2. 运行命令(包含动图最后的命令)

docker build -t express-prod-i .

02.gif


提示:对于Docker Toolbox,从Docker Quickstart Terminal开始运行Docker命令会导致错误(根据操作系统而异)。为了从任何随机终端/提示符运行命令,您需要将终端/提示链接到docker环境。运行docker-machine env,并运行它提示的命令,例如“@FOR / f”tokens = *“%i IN('docker-machine env')DO @%i”



##我们做了什么?

  1. 我们运行build命令从我们在步骤3中创建的Docker镜像文件创建一个文件
  2. 使用标签开关-t,我们给镜像一个名称,我们可以使用它来引用它,而不必引用Docker生成的ID(例如50e8dde7e180)
  3. 我们指定了使用“.”指定的当前本地目录的镜像路径

## 步骤 4b:验证镜像
如果所有都按计划进行,我们应该看到(如.gif中的)一个“successful build ...”消息。我们现在可以运行一个命令来记住你的镜像:
docker images

03.png

在这种情况下,我们的组合镜像大小为61.26 MB,这是基本的alpine-node镜像和我们的express应用层的组合。
##步骤 4c:观察镜像文件层
如果我们想要看到为我们的镜像创建的文件层,我们可以运行命令:
docker history express-prod-i

04.png

# 步骤 5:运行镜像实例
既然我们已经创建了一个镜像,我们已经准备好创建一个隔离的,模块化的应用环境。正如我已经提到了很多次那样,那个环境是一个Docker容器。Docker容器实际上是镜像的运行实例。

在概念上,一个镜像和容器非常类似于我们如何想到一个JavaScript Prototype或一个OOP类。所以,我们来运行一个我们创建的镜像的实例。
##步骤 5a:生成并运行一个镜像实例

  1. 运行命令:

docker run -d --name express-prod-app -p 7000:3000 express-prod-i


  1. 登录浏览器访问http://localhost:7000。
05.png


## 我们做了什么?
我们创建并运行了一个express-prod-i镜像的实例而作为一个容器:

- 使用RUN命令
- 指定分离模式-d标志(所以我们不绑定当前终端/提示符)
- 并使用-name标志给我们的容器设置名字“express-prod-app”
- 将主机7000上的本地端口映射到使用-p标志显示的3000的内部容器端口
- 最后,指定我们要生成并运行我们的实例的“express-prod-i”镜像

注意:我使用不同的本地端口7000来向您展示您可以将主机上的任何未使用的端口映射到容器中暴露的内部端口。



提示:没有-d,我们将以贴合模式启动运行容器。这意味着它将从容器中直接输出到我们运行命令的终端/提示符。通过在分离模式下启动容器,我们可以继续从终端/提示符运行容器工作。



##顿悟#1
你明白了吗?我们不必在本地安装Node.js或NPM。我们没有必要运行npm安装本地使用的应用程序,我们没有从主机运行应用程序。所有这些都在主机内部发生,这是一个简单的express.js演示网站。
##步骤 5b:验证运行容器

  1. 我们可以使用这个命令观察运行时容器

docker ps

06.png


  1. 这将显示我们运行容器。我们还可以指定-a标志来查看所有容器。当事情出错时,可能会有用,我们想看看一个号称已经运行容器是否意外退出:

docker ps -a


#步骤 6:停止并启动容器

停止一个运行时容器是非常简单的...或许你已经猜到了:

docker stop express-prod-app


然后启动它

docker start express-prod-app

#步骤 7:删除镜像和容器
当我们浏览这些教程时,可以删除镜像或容器并重新开始。以下是步骤。另外,在“奖励”部分,还有一些有用的捷径:
## 步骤 7a:删除容器
删除一个容器,我们可以使用“rm”命令:
docker rm express-prod-app

让容器恢复回来,我们可以使用先前使用过的命令:
docker run -d --name express-prod-app -p 7000:3000 express-prod-i

## 步骤 7b:删除镜像
删除一个镜像,我们可以使用“rmi”命令:
docker rmi express-prod-i

让镜像恢复回来,我们可以使用先前使用过的命令:
docker build -t express-prod-i .


提示:删除镜像和容器命令可以使用镜像或容器ID,甚至可以使用ID的前几个字符。所以你可以任意选择。 (您还会看到我们在奖励部分中这样做。)



# 奖励
补充一些删除镜像和容器的其他手段,你可以使用一些我已经在用的有效的快捷方法。
## 删除所有容器
要删除所有容器,运行下面的“rm”命令,这条命令内部会返回所有的容器:
docker rm $(docker ps -a -q)

Windows用户:你需要是一个bash环境去运行这些命令。主要是因为只有GNU才能使用$()变量引用。你可以安装诸如“Bash on Ubuntu on Windows”甚至于 GIT bash。只要记得你需要运行docker-machine env来链接你的终端,并且运行显示在最后的eval命令。
## 我们做了什么?

  1. 我们想container提交了删除命令“rm”
  2. 但是我们提交的是一个容器ID的列表,而不是提供容器标签或是container ID
  3. 提供所有(-a)参数并组合静默(-q)将会返回数字类型的容器ID

## 删除所有镜像
删除所有的镜像我们可以类似于上面的做法,使用删除镜像命令“rmi”
docker rmi $(docker images -q)

## 我们做了什么?

  1. 这里我们使用了删除镜像命令但是入参是一个docker镜像ID列表……
  2. ……使用列出docker镜像的命令
  3. 并且设置静默(-q)参数,这样返回了数字型的Docker ID

## 这可以应用到生产吗?还是只是应用开发环境?
很明显能主要到我们刚刚创建的镜像通知Express.js和Node.js在生产环境中运行。那这是什么鬼?

记住我们是要为任何镜像制作基本镜像,并且谁会在开发环境中为每次修改而“重建”镜像呢?所以我们需要使用生产镜像来作为基本镜像构建我们的开发环境并且隔离开发修改到分层镜像中的开发层中。
# 总结
所以,我已经屏蔽了一大堆关于Docker的知识。创建镜像文件,构建镜像并生成该镜像的正在运行的容器。但是我们还有很多事情要去做。

因此,在本系列的下一篇文章中,我将针对我们的开发版本或应用程序创建一个镜像,但是基于我们的生产镜像。我们还将介绍如何利用容器中的脚本来帮助设置本地环境来更改源代码。

原文链接: Docker for Devs: Containerizing Your Application(翻译:高洪涛)

===========================================
译者介绍
高洪涛,当当网架构师,开源数据库分库分表中间件Sharding-JDBC作者。目前从事Docker,Mesos相关工作

Windows上该如何制作Dockefile

coagent 回复了问题 • 2 人关注 • 1 个回复 • 2073 次浏览 • 2017-03-01 11:13 • 来自相关话题

Rancher v1.3发布:Windows Container来了!

Rancher 发表了文章 • 1 个评论 • 1869 次浏览 • 2017-01-16 09:42 • 来自相关话题

2016年12月初,当我们发布Rancher v1.2时,就定下了未来「更频繁的迭代」的计划。就在上周,Rancher v1.3正式发布啦!除了对v1.2中一些bug的修复之外,它还有几个新的功能:1)用户界面修复;2)DNS引擎的更改;3)Kubernete ...查看全部
2016年12月初,当我们发布Rancher v1.2时,就定下了未来「更频繁的迭代」的计划。就在上周,Rancher v1.3正式发布啦!除了对v1.2中一些bug的修复之外,它还有几个新的功能:1)用户界面修复;2)DNS引擎的更改;3)Kubernetes及其相关工具的改进。

最重要的是,在Rancher v1.3中,我们开始解决从用户那里收到的一个频繁请求:对Windows 2016的支持!

Rancher v1.3中对Windows的支持仍是实验性质的,范围有限,但它是Rancher Labs向服务客户的需求迈出的重要一步。容器越来越在企业中被广泛采用,而在世界范围内,极大一部分的工作负载是运行在Windows服务器和客户端系统上的。并且,在可预见的未来之中,这一情况并不会改变。

Rancher Labs的目标,就是要让应用程序真正地达到云和基础设施之间的可移植化,而使工作负载运行于Windows容器之上,是Rancher Labs的愿景的一个关键部分。

Windows in Rancher教程

要在Rancher中部署Windows,首先需要创建一个新的环境,其中的环境模版里需要将容器编排设置为Windows。

目前,Rancher仅支持在特定主机上创建容器。一些可能出现在UI中的Cattle里的功能,如服务发现、健康检查、元数据、DNS和负载均衡器,在现阶段尚不支持。


注意:Rancher已为你提供了一个可用的默认的Windows环境模板。但如果你创建你自己的 Windows环境模板,你需要禁用所有其他基础架构服务,因为它们当前与Windows不兼容。



#创建Windows环境

在环境的下拉列表中,单击“Manage Environment(管理环境)”。要创建新环境,请单击“Add Environment(添加环境)”,提供名称、说明(可选),然后选择以Windows作为编排的环境模板。如果您开启了访问控制,您可以在此添加成员并选择其成员角色。成员列表中的任何人都可以访问您的环境。

创建Windows环境后,您需要导航到环境中去,此时你可以在位于左上角的环境下拉菜单中选择环境的名称,或在特定的环境下拉菜单中选择“Switch to this Environment(切换到此环境)”。

注意:Rancher支持多个容器编排框架,但在现阶段,若有些环境里已有服务正在运行,用户是不能切换环境的。



#添加Windows主机

若想将主机添加到Windows,您需要先安装一个运行着Windows Server 2016 with Docker的主机。

在“Infrastructure(基础架构)”选项卡中,您将获得一个自定义命令来启动Rancher代理服务。您可以按照说明在Windows中启动Rancher代理服务。

在主机上,代理二进制文件将下载到名为C:/Program Files/rancher的文件夹中,代理日志将位于C:/ProgramData/rancher/agent.log里。

#删除Windows主机

将主机添加到Rancher中时,Rancher代理是其中的一部分,它是以服务的形式被安装和注册于主机之上的。为了重新使用主机,您必须删除现有的服务。你可以在powershell中运行以下命令。删除服务后,你就可以在Windows环境中重新使用主机了。

```
&'C:\Program Files\rancher\agent.exe'-unregister-service
```

#Windows中的网络

默认情况下,我们支持NAT和透明网络

目前,默认的Windows环境模板支持名为transparent的透明网络,它是通过运行docker network create -d transparent transparent创建的。

如果要创建具有不同名称的透明网络,则需要使用Windows创建一个新的环境模板作为容器编排。选择Windows后,您可以单击“Edit Config(编辑配置)”更改透明网络的名称。默认名称为transparent。创建更新的环境模板后,您可以创建一个新环境,以支持新命名的透明网络。 UI将继续使用transparent作为默认名称,因此您需要将该命令更新为`docker network create -d transparent
更多的反馈与分享

在Rancher Labs正努力向服务客户的需求迈进时,我们无比期待收到您对这些早期努力的反馈。我们坚信,只有来自用户的更广泛的反馈,才可以让Rancher产品变得更好。

原文来源:Rancher Labs

睽违已久:Travis CI终于牵手Windows

大卫 发表了文章 • 0 个评论 • 1221 次浏览 • 2018-10-12 17:16 • 来自相关话题

在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。 Windows系统现已面向tarvis-ci.org或 ...查看全部
在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。

Windows系统现已面向tarvis-ci.org或者travis-ci.com上的全部开源及私有项目使用,我们亦有计划尽快将其引入企业环境。这是我们第一次发布Windows支持方案,因此相关工具链还不够完善——期待大家能够在我们的社区论坛上提供反馈。请马上加入吧!

我们知道,大家一直在期待对Windows系统的支持方案。在论坛上的2104号问题中,我们发布了一些关于初步规划的见解,而我们杰出的贡献者Hiro Asari于2013年也加入到项目中来。Hiro开发出多个早期概念验证方案以及一系列其它成果,同时快速成为我们在GitHub上的应答发言人,外加travis-build与dpl的维护者/开发者。经过这么长的时间,以及众多原型设计,Windows支持能力终于准备就绪——这样的结果令我们的激动之情溢于言表。

另外,我们在npm上的好朋友们同样对此抱有极高热情!

今天的公告带来了令人振奋的消息。我们知道,有超过40%的npm用户在使用Windows设备,但在此之前只有一小部分软件包能够在CI当中主动运行Windows测试。为Travis CI添加Windows支持能力将为JavaScript社区的主体带来更稳定的开发体验——更具体地讲,npm Registry中有32%的项目在使用Travis CI。我们期待着继续与Travis CI开展合作,从而降低开发人员的日常工作难度,并最终确保全球超过1000万开发者构建出令人惊叹的产品。 ——npm有限公司首席执行官Laurie Voss

我们迫不及待希望扩展Windows Build Environment,用以支持大家团队及社区中正在进行的一切出色工作!
#Windows Build Environment
这套Windows构建环境在发布之初支持Node.js、Rust以及Bash语言。我们还运行有一套git bash shell,用以维持与我们其它基于bash环境间的一致性。此外,Docker同样可用于各Windows build。

我们利用Chocolatey作为软件包管理器,同时预安装有Visual Studio 2017 Build Tools以帮助用户。大家现在可以点击此处通过文档查阅我们目前在Windows构建环境中提供的全部软件包。Windows构建环境目前基于Windows Server 1803,其中作为容器运行平台的系统版本为Windows Server 2016。

我们还在Google Compute Engine中托管我们的Windows虚拟机,不过我们发现其启动时间会有所差别。因此我们打算在接下来的基础设施调整工作当中,持续对其做出改进与优化。
##上手指南
要运行一套Windows build,请将以下内容添加至 .travis.yml当中:
os: windows

大家也可以利用以下内容对多套操作系统进行测试:
os:
- windows
- linux
- osx

我们还在Windows上为大家准备了其它一些酷炫的项目,例如:

* yargs/yargs
* npm/node-semver
* docker-library/golang -(请参阅PR for how docker-libary/golang added Windows support!

希望上述内容能够为大家带来更多启示与灵感!
#展望未来
在早期版本发布之后,我们将根据大家的反馈对构建环境及运行时工具的安装与配置做出持续改进。我们希望在接下来的3到6个月内进行快速迭代,并计划在2019年第二季度推出稳定版本。在同一时间点上,我们还希望能够推出Windows Build Environments for Enterprise。如果大家热切盼望其尽早推出,请与我们的企业团队!
#分享您的反馈!
要将Windows推向更高级别,我们需要您带来的反馈意见——特别是在Windows上进行开发的朋友们!您希望获得哪些工具?环境应当如何运作?您需要了解哪些内容才能保证自己的团队快速上手?请在社区论坛上给我们留言。我们正在努力为最好的CI社区构建最出色的CI方案,而您的意见是我们达成目标的必要前提。

此外,这里还要感谢一直为我们提供帮助的贡献者们——特别是Jordan Harband、Alex Crichton、Tianon Gravi以及其他无数参与者!

我们期待着听到您对Travis CI与Windows平台结合方面提出的宝贵建议!

原文链接:Windows is Available (Early Release)

如何在Windows 10上运行Docker和Kubernetes?

yahoon 发表了文章 • 1 个评论 • 12920 次浏览 • 2018-08-12 22:08 • 来自相关话题

在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。 但是 ...查看全部
在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。

但是不要担心!

这篇文章就是为在Winodws上刚刚入门容器和Kubernetes的同学而准备的。

你将会学习到如何做出正确的选择来搭建Windows上的容器开发环境。

让我们从Docker说起。
# 你正在使用Windows 10 Home版?你将无法运行Docker for Windows
当Docker的开发者们决定在Winodows上实现Docker时,他们选择了Hyper-V作为虚拟化技术。这个优点十分明显:优秀的性能和原生的hypvervisor。

不幸的是并不是所有的Windows版本带Hyper-V支持

如果你正在使用Windows 10 home版或者Student版,那么你就中招了。你将无法安装和运行Docker for Windows。

但是先别失望。

你有许多基于Docker Machine的替代品可用,例如Docker toolbox或者minikube。

Docker Machine的工作方式很简单:有一个VM装好了Linux和Docker给你。你可以从你的主机连到虚拟机上的Docker deamon。

Minikube可以说是基于Docker Machine的最有趣的VM之一——你可以在里面运行Kubernetes集群。

事实上,minikube是一个运行Docker和Kubernetes的VM。它通常是用来单独运行Kubernetes的,但是你也可以用它来跑Docker容器。

你可能不会拥有Docker for Windows那样的速度,但是毕竟你不需要Hyper-V就能够构建和运行容器了。
# 有了Windows 10 Pro,Docker for Windows是最佳选择(除了特殊情况)
你有最新的Win 10 Pro,你可以安装Docker for Windows。 你拥有了优秀的性能和开发者体验,一切都搞定了,是吗?

答案是不一定!

Docker for Windows使用的hypvervisor是相当强大的——它属于`Type-1 hypervisor`。 它确实很强大但是它却无法与Virtualbox这样的`Type-2 hypervisor`一起工作。

你不能在同一台机器上同时运行Type 1和Type 2的hypervisor。换句话说,如果你运行Docker for Windows,那你就无法启动VirtualBox里面的VM了。

这跟你的设置相关,影响可大可小。

如果你已经完全使用容器化了,你就不需要担心VM——过时的东西。

但是如果你仍然要使用VM,以及类似Vagrant这样的工具,那你可能就有麻烦了。

你可以随意的启用或者关闭Hyper-V hypervisor,但是你要重启机器

如果你频繁的要从容器切换到VM,那可能使用minikube更方便。当你从容器切换到VM的时候就不用重启电脑了。 缺点就是你没办法得到更高性能和更好体验。

最后,如果你要运行Windows容器——`base镜像是来自于Windows的容器`——Docker for Windows是唯一选择。 你只能使用Windows 10 Pro或者Enterprise版。
# 运行一个本地的Kubernetes集群
如果你想要跑一个本地的Kubernetes,那你应该考虑minikube。

Minikube是一个预装有嵌入式Linux(Buildroot)和Docker daemon的VM。

它是一个最小完整的Kubernetes环境

Minikube的VM可以通过VirtualBox或者Hyper-V来运行(当然也有其他选择)。如果你已经有Hyper-V也要用它来跑Docker和minikube的话就会很方便。

当然如果你不能跑Hyper-V也没关系,你可以用VirtualBox实现同样的功能。

有很多的选择和权衡,下图列出了一些:
1.png

# 前提
你可以从官网上下载安装Docker for Windows、Docker Toolbox、VirtualBox、kubectl、Docker CLI等,但是相当麻烦。

你要去到官网找到正确的下载地址,选择正确的版本,下载安装,最后加到你的path里面去。

这当然可行,但是我敢肯定你更愿意把时间花在编码而不是从网站上下载安装软件包上。

使用Chocolatey

Chocolatey是一个Widnows的包管理器。你告诉它想要安装的包,它会为你装好。你把软件安装的活外包给它了。

安装Chocolatey很简单,你可以在它的官方网站找到步骤。简单来说,就这么几步:

1、以管理员启动`cmd.exe`

2、执行下面这个命令:
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

3、重新加载`cmd.exe`

如果安装成功,那么你可以搜索软件包:
choco search docker

我们来试一把,安装Cmder——一个Windows上的时尚shell:
choco install cmder -y

Chocolatey会安装到`C:\tools`下。如果你要用Cinder做如下的练习,您可以以管理员启动它:
2.png

看起来不错!
# 1. 在Windows 10 Pro上安装Docker和Kubernetes
##安装Docker
安装Docker for Windows:
choco install docker-for-windows -y

重启你的电脑。Docker会问你是否要启用Hyper-V。
3.png

选择Yes。

你需要知道Docker需要启用VT-X/AMD-v的硬件虚拟化扩展来运行容器。你需要在重启电脑时在BIOS里面配置它。

你可以用systeminfo命令来检查VT-x/AMD-v是否打开。

如果你不确定VT-x/AMD-v是否打开,也不用担心。因为你没有的话,Docker会报错:

Hardware assisted virtualization and data execution protection must be enabled in the BIOS.



4.png

另一个常见问题是Hyper-V没有启用,这样你会见到如下错误:
5.png

你应该启用Hyper-V。以管理员打开新的命令提示符,敲入:
bcdedit /set hypervisorlaunchtype auto

你重启电脑之后Docker就应该可以启动了。

但如何知道Docker已经跑起来了呢?

打开命令提示符:
docker ps


如果一切正常,那么你会看见输出一个空的列表(正在运行的容器列表)。

如果Docker deamon没有运行的话,你可能就会遇到如下错误:
6.png

上面的错误表示你的Docker安装不正常,Docker无法启动。

你应该先启动Docker daemon,然后再连接它。
# 在Hyper-V上安装Minikube

安装minikube:
choco install minikube -y

在启动集群之前,你应该先创建一个外部的网络交换机。

第一步,你应该先查看你电脑的网络适配器。

你应该忽略掉虚拟网卡,而关注在真实活跃的物理网卡上,比如Ethernet或者WiFi。

选择好物理网卡让它与虚拟交换机共享网络连接。

要查看你当前的网络适配器,你可以在PowerShell里面使用Get-NetAdapter cmdlet。

点击左下角的Windows图标,输入PowerShell来打开它:

输入如下命令来列出所有的适配器:
Get-NetAdapter

7.png

如果你还是不知道该选哪个,那么就选择Up状态的那个。

一旦你选择好了适配器,你就可以开始创建外部虚拟交换机了:
New-Switch -Name "minikube" -AllowManagement $TRUE -NetAdapternmae "INSERT_HERE_ADAPTER"

别忘了填入之前选择的适配器名字。

如果你没有创建好网络交换机,那么启动minikube的时候会报如下错误:

E0427 09:06:16.000298 3252 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks. no External vswitch found. A valid vswitch must be available for this command to run. Check https://docs.docker.com/machine/drivers/hyper-v/.



你可以运行以下命令来测试minikube安装是否成功:
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube


请注意:`--vm-driver=hyperv --hyperv-virtual-switch=minikube` 只在第一次启动时需要。如果你希望更改driver或者内存,那么你需要执行`minkube destroy`然后用新的配置重新创建。

如果minikube启动失败,那么你可以通过以下命令调试:
minikube delete
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube --v=7 --alsologtostderr

更多的输出日志可以帮助你快速排错。我遇到过如下的问题:

E0427 09:19:10.114873 10012 start.go:159] Error starting host: Error starting stopped host: exit status 1.



这看不出来啥。我就打开详细的日志输出,错误就变得明显了:
+ Hyper-V\Start-VM minikube 
+ + ~~~~~~~~~~~~~~~~~~~~~~~~~
+ + CategoryInfo : FromStdErr: (:) [Start-VM], VirtualizationException
+ + FullyQualifiedErrorId : OutOfMemory,Microsoft.HyperV.PowerShell.Commands.StartVM

内存不够了!

这时可以看看安装成功了没。在命令提示符输入:
kubectl get nodes


你会看到Kubernetes里面有一个node显示出来。

在virtualbox里面运行虚拟机

因为你已经在设备上启用了Hyper-V,你就无法再通过virtualbox跑VM了。如果你强行要启用vm的话,会遇到如下错误:
8.png

如果你想用VirtualBox这种Type-2 的hypervisor, 你先要停掉Hyper-V然后重启电脑。

以管理员打开命令提示符:
bcdedit /set hypervisorlaunchtype off

当机器重启之后,你就可以正常使用VirtualBox了。

如果你又想要用Docker和minkube了,你要重新打开Hyper-V然后重启机器。

以管理员打开命令行,输入:
bcdedit /set hypervsiorlaunchtype auto

重启, 这样你就可以将容器部署到Kubernetes中了。

请跳到测试你的Docker 安装
#2. 在Win 10 Home版本上安装Docker和Kubernetes
如果你正使用Windows 10的Home版或者Student版,你可能不需要安装Docker Machine 工具(比如Docker Toolbox)。

你应该使用minikube作为远程的Docker deamon和本地的Kubernetes集群。

你可以下载安装minikube:
choco install minikube

在装完了以后,你可以启动:
minikube start

这个命令会下载一个VirtualBox要用到的ISO,然后启动VM。启动之后你就可以查看集群状态:
kubectl get nodes

看见一个node列出来。

要连接到远程的Docker deamon,你应该安装Docker客户端:
choco install docker -y

你可以连到minkube上远程的Docker daemon:
@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i


注意:每次你打开一个新的命令行窗口,你都需要以上命令。一种提醒你自己的简单方式是敲一下`minikube docker-env`。

如果连接成功,你可以列出当前正在运行的容器:
docker ps

你会看到很多容器正在运行。大部分属于Kubernetes。

你已经一切准备就绪!

但是在你继续之前,你需要清楚使用minikube作为你远程Docker daemon的一些限制。

Docker被设计为两个部分:

  • Docker daemon ——你可以将它理解为一个API server。你把命令发给它的API,Docker接收然后执行命令。
  • Docker CLI —— 将命令发送给Daemon API的可执行文件。

大部分时间你都只会跟Docker CLI 交互,你不会看到Docker daemon。

那么为什么要有客户端和服务器?为什么不用一个文件?

这都是为了灵活性

当你运行Docker for Windows时,Docker CLI连接的是本地的Docker daemon。
9.png

但是有时候你本地没有daemon

可能你需要在一台远端的机器上构建Docker容器。

可能你没有Hyper-V环境,你的Docker daemon是安装到VirtualBox里面的VM中的。

特别是你正在运行minikube。

你的Docker CLI会连接到远程的部署在minikube虚拟机里面的Docker Daemon上。
10.png

当你的容器运行在远程的Docker daemon上的时候,你需要调整端口绑定。

在Docker for Windows,你可以将容器端口绑定到8080:
docker run -ti -p 8080:80 nginx

注意:容器本身暴露的是80,你把它映射到了8080。

然后你可以访问http://localhost:8080然后看见Nginx的欢迎页面。

如果你在远程的Docker daemon上运行此命令然后访问这个URL时,你会发现什么也没有,URL不可达。

所以有什么不同?

Docker deamon负责运行容器和端口转发。

Docker for Windows的daemon是在本地运行的——你自己的本机

所以你可以访问本机上的容器。

Minikube则不同,它的Docker daemon是运行在VM里面的。

它是远程的deamon。


如果你想要看见你运行的容器你需要访问Docker daemon所在的机器。 你可以用以下命令找到IP:
minikube ip

你可以通过http://your_minikube_ip:8080来访问,看到Nignx的欢迎页面。
# 测试你的Docker安装
你已经安装好了Docker,那你如何知道它是否工作正常呢?

进入到终端,输入:
docker run -ti -p 8080:80 wordpress

一旦Docker下载完所有的包,你可以通过http://localhost:8080来访问。

注意:如果你在使用远程的minikube上的Docker daemon时,你应该使用http://your_minikube_ip:8080来访问。

你应该可以看到Wordpress的安装向导了。

万岁!恭喜你!

Wordress就在一个容器里面对外服务了。

注意:你还不能完成那个Wordpress的安装因为你还有数据库。
# 测试你的Kubernetes集群安装
是时候测试你的本地的Kubernetes集群了。在这一部分,你将会部署Smashing.io面板
11.png

## 部署Smashing到Kubernetes里面
你可以用如下命令部署:
kubectl run smashing --image=/visibilityspots/smashing --port=3030

一旦Kubernetes完成了容器的安装,你可以查看运行状态:
kubectl get pods

## 暴露面板
你可以将你部署的服务器暴露出来:
kubectl expose deployment smashing --type=NodePort

你可以通过浏览器打开面板:
minikube service smashing

这样你就可以从Kubernetes里面访问面板了! 万岁!
# 鸟瞰Kubernetes
Minikube本身自带了一些好东西。

你可以访问官方自带的面板
minikube dashboard

12.png

从这里,你可以查看你的集群详细信息和部署应用。
# 总结
现在你已经了解了在Windows上安装Docker和Kubernetes的所有选项。

如果你遇到了文章没提到的错误,请通过@learnk8s或者slack告诉我们。

接下来,你可以在你的环境里面部署更多应用了。请看文档

原文链接:Get started with Docker and Kubernetes on Windows 10(翻译:姚洪)

Docker公司新发布的多云战略,能让他在B端扳回一局吗?

大卫 发表了文章 • 0 个评论 • 1303 次浏览 • 2018-06-19 08:17 • 来自相关话题

在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。 ...查看全部
在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。

Docker公司推出的Docker企业版是一款用于管理容器化应用程序的商业产品,可帮助企业客户将部署在内部、云环境以及托管Kubernetes当中的应用程序联合起来。目前的主流云托管Kubernetes方案包括Azure Kubernetes Service(简称AKS)、AWS Elastic Conatiner Service for Kubernetes(简称EKS)以及谷歌Kubernetes引擎(简称GKE)。

根据Docker公司的介绍,Docker企业版是目前惟一能够通过安全供应链提供联合应用程序管理功能的容器平台。利用Docker企业版,客户可以任意选择Linux发行版或Windows Server、将其运行在虚拟机或者裸机之上,运行传统或微服务应用程序并配合Swarm或者Kubernetes编排工具,同时灵活选择用于运行容器化工作负载的云平台。

Docker企业版中提供的联合控制平台还能够进一步提升应用程序的可用性。部署在某一位置的应用程序将自动跨越多个集群进行复制。当主集群不可用时,Docker企业版会将流量以透明方式路由至另一正常集群处。除此之外,客户还能够利用Docker企业版无缝跨越不同开发、分段及生产环境以管理应用程序。

自决定对接Kubernetes以来,Docker公司一直努力寻找新的独特竞争优势。通过应用程序管理联合,Docker公司希望填补现有Kubernetes产品当中存在的空白。然而,这项功能并非Docker企业版独家所有。

事实上,Kubernetes社区一直在努力以对支持不同环境的运行集群进行联合。上游Kubernetes发布一套更为稳定且流畅的集群联合方案已经只是时间问题。因此,Docker公司不得不利用其企业平台正面对抗其它基于Kubernetes的产品。

Docker公司正与微软方面密切合作,旨在将Kuberntes与Windows容器相集成。微软已经通过Docker API与CLI公布原生Windows容器。Docker与微软目前亦着手将Windows工作负载运行在由Kubernetes与Docker企业版结合而来的平台之上。这意味着企业客户将能够选择Swarm或者Kubernetes部署自己的Windows与.NET应用程序,且确保其与Linux应用程序产行运作。

微软公司正在积极推动Windows成为Kubernetes世界中的一等公民。Azure Kubernetes Service作为由微软推出的云托管Kubernetes方案,目前已经能够支持Windows容器。客户现在可以注册以体验该功能的技术预览版本。

微软公司的目标是在Azure Stack私有云平台上实现Azure服务。最终,AKS也将正式登陆Azure Stack,并为Windows Server提供原生容器编排支持。当这一切成为现实后,市场态势将转变为Docker企业版与AKS on Azure Stack的对决。

Docker公司亦面对着来自红帽及Pivotal等专门面向企业客户的供应商的竞争压力。来自红帽的OpenShift容器平台与来自Pivotal的Pivotal容器服务(简称PKS)都直接将矛头指向Docker企业版。此外,AKS、EKS以及GKE等公有云托管型Kubernetes产品同样发展迅速。很明显,Docker公司必须建立自己的差异化优势才有机会力压其它各大Kubernetes供应商。

那么,将应用程序与Windows容器联合起来是否有助于该公司获取市场份额?我觉得Docker企业版的主旨并不在于此。事实上,Docker公司的核心任务在于推动创新,从而为其企业平台创造引人注目的价值主张。

容器生态系统已经变得非常拥挤。从主流平台厂商——例如红帽与微软,到早期初创企业,每个人都想在其中分一杯羹。而对Docker公司来说,赢取企业市场份额无疑将是一场艰苦的斗争。

原文链接:Will Multi-Cloud Strategy Help Docker Inc. Win The Enterprise?

LCOW —— 单一Docker引擎下可同时运行Linux和Windows容器啦!

tiny2017 发表了文章 • 0 个评论 • 4970 次浏览 • 2018-01-26 13:19 • 来自相关话题

【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。 ...查看全部
【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。

就在上周,Docker官方的master分支上新增了LCOW(Linux Containers on Windows)功能。启用这项功能,即可在单一的Docker引擎下,同时运行Linux和Windows容器。

下面赶紧跟小编一起,看看Windows 10将会发生哪些变化?
lcow-marked.jpg


  • 可以用Docker命令`docker ps`,列出所有正在运行的Linux或Windows容器。
  • 在容器和主机之间通过存储卷共享数据。
  • 容器之间可以通过容器网络互相通信。
  • 通过将端口映射到主机,实现本地访问。但目前,它还只是Windows 10 1803版预览体验计划(Windows Insider)的一项功能。

#运行Linux容器

现在,你需要指定`--platform`来拉取Linux镜像。如果拉取的是一个既有Linux又有Windows的多重架构的镜像,同样需要指定该选项。
docker pull --platform linux alpine

镜像拉取完毕即可运行,无需指定`--platform`选项。
docker run alpine uname -a

另外,Windows上运行Linux容器需要一台小型的Hyper-V虚拟机。同时,LinuxKit项目提供了LCOW的镜像,请参照:https://github.com/linuxkit/lcow
#共享存储

接下来我们看一下,如何用一种简单的方式,实现不同平台容器间的数据共享。

方法是把Linux和Windows容器,绑定到同一个存储卷。

下面的例子中,Linux和Windows容器通过主机的一个共享文件夹,实现数据共享。
2.gif

首先,在Windows 10 上新建一个文件夹。
cd \
mkdir host

##启动Linux容器

在Windows 10主机上启动一个Linux容器,并且将主机上的共享文件夹挂载到该容器的`/test`文件夹。
docker run -it -v C:\host:\test alpine sh

我们在`/test`文件夹下,新建一个名为hello-from-linux.txt的文件。
uname -a > test/hello-from-linux.txt

##启动Windows容器

在Windows 10主机上启动一个Windows容器,并且将主机上的共享文件夹挂载到该容器的`C:\test`文件夹。
docker run -i -v C:\host:C:\test microsoft/nanoserver:1709 cmd

我们在`C:\test`文件夹下,新建一个名为hello-from-windows.txt的文件。
ver > test\hello-from-windows.txt

##测试结果

上述两个容器中新建的文件,都保存在Windows 10 主机的共享文件夹。
PS C:\> dir host


Directory: C:\host


Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 1/21/2018 4:32 AM 85 hello-from-linux.txt
-a---- 1/21/2018 4:33 AM 46 hello-from-windows.txt

在开发过程中,如果需要共享配置文件或代码的话,这实在是太方便了有木有~
#混合编排

值得一提的是,使用Docker Compose还可混合编排容器。下面是一个混合编排Linux和Window web服务器的例子。
    version: "3.2"

services:

web1:
image: nginx
volumes:
- type: bind
source: C:\host
target: /test
ports:
- 80:80

web2:
image: stefanscherer/hello-dresden:0.0.3-windows-1709
volumes:
- type: bind
source: C:\host
target: C:\test
ports:
- 81:3000

networks:
default:
external:
name: nat

你也可以思考一下,如何编排一个Linux数据库和Windows前端,反过来也一样。
#如何搭建你的LCOW测试环境

如果你想试着玩一下LCOW,建议使用Windows 10 1709虚拟机。
##Azure

我在微软Azure上用Windows 10 1709虚拟机测试过LCOW。你可以选择具有嵌套式hypervisor的V3 机器以便运行Hyper-V容器。
##容器和Hyper-V

首先,启用容器和Hyper-V功能:
Enable-WindowsOptionalFeature -Online -FeatureName containers -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart

##LinuxKit

然后,为你的LCOW安装一个LinuxKit镜像。下面是我下载的最新版LinuxKit,你也可以自行从linuxkit/lcow下载。
Invoke-WebRequest -OutFile "$env:TEMP\linuxkit-lcow.zip" "https://23-111085629-gh.circle-artifacts.com/0/release.zip"
Expand-Archive -Path "$env:TEMP\linuxkit-lcow.zip" -DestinationPath "$env:ProgramFiles\Linux Containers" -Force

##创建Docker

现在,你可以下载并安装Docker引擎了。
Invoke-WebRequest -OutFile "$env:TEMP\docker-master.zip" "https://master.dockerproject.com/windows/x86_64/docker.zip"
Expand-Archive -Path "$env:TEMP\docker-master.zip" -DestinationPath $env:ProgramFiles -Force

接下来,安装Docker service并打开实验功能。
 . $env:ProgramFiles\docker\dockerd.exe --register-service --experimental

紧接着,配置PATH以便使用Docker CLI。
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";$($env:ProgramFiles)\docker", [EnvironmentVariableTarget]::Machine)

恭喜你!现在可以重启机器了。重启过程中会自动更新容器和Hyper-V的配置。如果一切顺利,重启完后Docker engine应该已经起来并处于运行状态了,这时你可以在PowerShell终端使用Docker CLI。
#本地的Vagrant环境

如果你的Vagrant安装了Hyper-V或VMware,那就更方便了。只需几个命令,就可轻松搭建本地测试环境。

你只需要从我的GitHub下载包含LCOW环境的docker-windows-box,执行以下命令就可以了。
git clone https://github.com/StefanScherer/docker-windows-box
cd docker-windows-box
cd lcow
vagrant up

如果你的Windows 10虚拟机上没有Vagrant base box,系统会自动下载安装。如果已经下载了,则只进行安装。
#总结

未来几个月,随着这些Docker新功能加入到Windows,Windows 10无疑将成为2018年最具吸引力的开发者平台。

想象一下,你用`docker-compose.yml`编排Linux和Windows容器,通过Visual Studio Code实时调试你的应用程序,等等。

如果您喜欢这篇文章,请分享给您的朋友。如果想了解Windows容器的最新情况,请关注原文作者的推特@stefscherer

原文链接:A sneak peek at LCOW (翻译:Tiny Guo)

Windows Server 1709:以容器为中心,向DevOps画圆

ds_sky2008 发表了文章 • 0 个评论 • 2853 次浏览 • 2017-11-05 16:58 • 来自相关话题

【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。 大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是 ...查看全部
【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。

大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是对Windows Server服务器的核心版本做了重大更新,其中包括企业版和数据中心版的新版本。新的Windows Server支持基于DevOps的组织并增强对容器和云部署的支持。

但是为了“尝鲜”新版本的好处,你将不得不放弃Windows Server UI,转而使用命令行(特别是通过PowerShell)和远程用户界面(如熟悉的RSAT和基于浏览器的新项目火奴鲁鲁Honolulu)来管理服务器。

下载InfoWorld Deep Dive:[基于Windows,Windows Server和Exchange 的PowerShell使用指南。]

千万别太惊讶:其实微软已经离开服务器GUI有一段时间了,而且其命令行工具在使用脚本进行远程管理多个服务器方面具有显著的优势。混合使用PowerShell和火奴鲁鲁(Honolulu)不会使管理变得更加困难,这将使Windows Server与各种基于Unix的竞争对手站在同一起跑线。它还将为微软提供一个新的管理基准,在这个基准上添加对容器的支持以及其他与服务器操作系统一起工作的新方法。

要安装Windows Server 1709,你必须进行全新安装(clean install),因为它会将你移至新的、每年两次的新版本发布频道。通过强制全新安装,Microsoft正在试图清楚地表明,你正在逐渐从Windows Server 2016的长期支持的5 + 5支持模式转向一个每年两次的新版本和18个月的支持模式。
# Windows Server 1709中的新容器功能
微软显然更钟情于正在使用Windows Server 1709的应用程序和容器开发人员。新的容器基础镜像包括服务器核心和纳米服务器;服务器核心,用于现有应用程序的“提升和移位”方案,以及用于基于.Net Core或Node.js的新应用程序的Nano Server。容器基础镜像也显著缩小 - 服务器核心镜像减少60%,纳米服务器减少80% - 使得在这些镜像之上部署新容器的速度更快。

“提升和移位”选项是一个有趣的选择,因为它可以让你用最少的工作容器化现有的代码。当然,构建应用程序在容器中运行的架构问题,例如确保所有的应用程序数据都存储在容器之外,所以你必须做一些改进。但在实践中,进行适当的更改不应太困难 - 特别是在使用Windows Server或Azure的存储工具和API时。
# Windows Server的新计划符合DevOps的思路
每六个月发布一次新的Windows Server将不会满足每个人的口味(实在是众口难调)。虽然你可以跳过一个版本(例如,从1709跳到1809,忽略1803),但这并不会改变Windows Server将会每个版本只有18个月的支持而定期进行重大更新的事实。Windows Server新的节奏可能最适合那些已经转移到devops驱动流程的组织,在这个流程中,应用程序驱动整个策略。

DevOps的方法当然是与云优先发展一致的。一段时间以来,Windows Server需要与Linux的快速开发进度竞争,尤其是在使用容器镜像的情况下。这是捆绑的Nano服务器在Windows Server 1709中重新思考的主要原因; 支持基础架构角色的容器主机没有任何意义,特别是当主操作系统构建也变得更轻量级时。

尽管如此,微软对Windows Server的更改对于三年或五年发行版的系统管理员来说也是一个挑战。对他们来说,还有一个长期服务通道(LTSC),它将继续像Windows Server一样被发布。

你甚至可以在你的数据中心混合使用Windows Server版本,使用旧版应用程序的LTSC和Windows Server 1709,以及将来的新版本和云使用版本。尽管Windows Server 1709和更高版本包含基础架构角色,但你应该使用这些每年两次的版本来发布虚拟机中的应用程序托管以及容器基础镜像。为VM主机,存储和Active Directory继续使用Windows Server LTSC基础架构服务器是有意义的。服务器部署的混合方法很有意义,因为毕竟,基础架构服务器在部署后不应更改,除了获取安全更新之外。

如果我们将基础设施操作从DevOps中分离出来,这个分离模型更有意义。在DevOps领域,基本操作系统的相对迅速的变化不是问题,因为它们只是持续集成管道的另一个要素,还有代码和其他软件定义的基础架构。

旧的贝塔系统和社区预览已是昨日黄花。一些选定的客户仍然可以访问TAP构建,但其他人都应该加入Windows Insider计划,以迎合未来的变化。在新的每年两次的更新节奏中,参与Windows Insider程序比以往任何时候都更加重要,因为Windows Server的新计划将要求在每个新版本部署之前通过快速测试来验证应用程序。

即便如此,测试不应该是繁重的。毕竟,每隔两年一次的增量版本和大爆炸产品每隔几年就会有天壤之别。由于每台Windows Server新版本的新功能要少得多,所以它们对现有应用程序的影响很小。

原文链接:Windows Server 1709: Container-focused, devops-oriented(翻译:ds_sky2008)

Docker for 开发:容器化你的应用

gaohongtao 发表了文章 • 0 个评论 • 9959 次浏览 • 2017-04-11 11:01 • 来自相关话题

【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。 【3 天烧脑式容器存储网络训练 ...查看全部
【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

作为开发者,我们总是寻找一个捷径或更容易的方法来快速起步,对吧?如果你是团队领导,付出最少的代价让团队站在同一个起点是很重要的。 Docker可以提供帮助。

在软件开发领域,一直越来越强调模块化,从单一责任的一般原则到更具体的实现,例如将JavaScript功能模块化为无状态组件。在这里,我将告诉你我们如何使用Docker来模块化我们的开发环境,以获得许多类似的好处,包括帮助我们快速起步。
# Docker 4 开发者
如你所知,为了加快项目进度,你有一个待办事项清单:

- 拉取代码基线
- 安装外部工具,如数据库、缓存和一些额外的工具和服务
- 给外部工具打补丁和升级
- 配置数据库和服务以使他们可以通信
- 开始祈祷(可能需要好几次)
- 调试问题(至少要30几次)

想象一下,如果在将应用程序的代码基线拉出存储库之后,您只需运行几个命令行(可能只有一个),可以使整个应用程序的环境准备就绪。听起来很酷,对吧?

这正是我们要完成的。不同于使用一个百科全书式的方法来使用Docker的所有功能和命令,我将介绍容器化开发人员的环境的主要的Docker功能。

这篇文章是关于利用Docker的容器化能力的一系列文章中的第一篇,它很容易构建一个可以在任何时间共享和运行的应用程序开发环境。
## Docker Toolbox 对 Docker for X
Docker Toolbox是可用于处理多个Docker资源的原始工具集合,并且会根据您选择的操作系统而有所不同。但在那之后,他们发布了新的Windows和Mac原生应用程序。因此,除了Linux、OS X和Windows Docker Toolbox变体之外,您还将看到“Doc​​ker for Mac”和“Docker for Windows”。

要理解和决定应该使用哪种工具,我想概述使用新的原生应用程序的前提。原来的Docker Toolbox将会设置一些工具以及使用VirtualBox。它还将提供在Linux Hypervisor上运行的虚拟机,用于Windows或Mac。
## VirtualBox、Hyper-V和Hyperkit,我的上帝啊!
原生应用程序,例如在Docker for Mac中,实际安装的是OS X原生应用程序。它也不再使用VirtualBox,而是使用OS X的hypervisor hyperkit。此外,共享接口和网络的管理更简单。还有一些用户体验更新以便于Docker更好的工作。在Docker for Windows原生应用程序中也会包含这些相同的更改,但是会使用Hyper-V作为hypervisor,以及其他类似的网络和工具更新的主机。

最后,原生应用的体验应该是一个更积极,更有效率的,而且更少的出错。但是,您会发现绝大多数与Toolbox相关的外部文档 - 因此了解Toolbox将是你的优势。
# 开始吧
这个初始教程将简单地使用一个开箱即用的express.js应用程序。当我们开始编辑源代码并在容器之间进行通信时,我将介绍一个运行Webpack的开发服务器的进阶的通用React.js应用程序,其中包含热模块重新加载,MongoDB数据库等。
# 步骤 1:安装
为了努力获得使用Docker并将开发人员环境与各种操作系统版本一起集中化的好处,我将让您选择需要下载的Docker版本(Toolbox或原生)和操作系统:

- Toolbox:https://www.docker.com/products/docker-toolbox (OS X and Windows)
- Docker for Windows:https://www.docker.com/products/docker#/windows
- Docker for Mac:https://www.docker.com/products/docker#/mac

TOOLBOX用户:Docker Toolbox配有“Docker快速入门终端”,并在运行时与Docker环境相关联。但是,通常在您选择的IDE中运行终端或独立运行终端。为了让Docker与另一个终端/提示进行交互,您需要通过运行“docker-machine env”来初始化Docker env。文本显示的末尾是一个命令,您需要从该同一终端中复制该命令以初始化Docker环境。



#步骤 2:源码/环境
下一步是获取要容器化的开发应用程序的源代码。

现在,您可以从GitHub抓取这个项目,这个项目保存了本教程的一些步骤。
# 步骤 3:创建Docker镜像文件
请记住,主要目标是在隔离和模块化的环境中运行我们的应用程序。为了让Docker创建这个环境,我们必须告诉它如何创建它。我们使用包含一组指令的Docker镜像文件

  1. 使用你的IDE,增加一个文件到工程根目录并命名为“Dockerfile”
  2. 拷贝下面的文件内容到这个文件

重要信息:该Docker镜像文件将允许我们创建一个镜像,该镜像将代表我们一直在讨论的容器化环境,并最终创建称为容器的该镜像的运行实例。但是,我们向前跳了一步,这些内容应该在第5步中。



##Dockerfile
FROM mhart/alpine-node:6.9.2
WORKDIR /var/app
COPY . /var/app
RUN npm install --production
EXPOSE 3000
ENV NODE_ENV=production
CMD ["node", "bin/www”]

Dockerfile是Docker在镜像文件中寻找的默认名称,但它可以是任何名称,我们将在稍后的步骤中看到。这些指令告诉Docker我们要创建一个镜像:

- 从一个基础的mhart/alpine-node镜像的6.9.2标签开始创建
- 设置应用程序初始运行的工作目录WORKDIR
- 拷贝当前本地目录“."中的内容到工作目录
- 然后从工作目录运行RUN命令npm install —production”
- 我们将对外暴露 EXPOSE3000端口从容器中,当它从镜像中被创建的时候
- 另外我们想要对容器设置本地环境变量ENV NODE_ENV的值为“production”
- 最后,我们启动express.js服务,它驻留在bin目录中的“www”文件中,执行命令“node bin/www”

提示:Docker总是需要一个基本的镜像,镜像保持尽可能小空间占用是关键。alpine-node镜像是非常小的(49.65mb),包括Node.js和NPM。



#步骤 4:构建一个镜像
现在我们有一个Docker镜像文件,它指定了有关如何创建镜像的详细信息,让我们停下来谈谈镜像是什么:
01.png

镜像是只读分层文件系统。它构成了我们不断追求的环境的基本文件系统。我们在上一步中创建的镜像文件将指示Docker如何去创建镜像的每层。

但如果它是一个只读的文件系统,我们如何去写它,(例如,执行代码的变化对我们的应用程序的代码在开发过程中)?好问题,我会在即将到来的步骤中回答。
## 步骤 4a:构建生产镜像

  1. 从一个终端中导航到项目根目录
  2. 运行命令(包含动图最后的命令)

docker build -t express-prod-i .

02.gif


提示:对于Docker Toolbox,从Docker Quickstart Terminal开始运行Docker命令会导致错误(根据操作系统而异)。为了从任何随机终端/提示符运行命令,您需要将终端/提示链接到docker环境。运行docker-machine env,并运行它提示的命令,例如“@FOR / f”tokens = *“%i IN('docker-machine env')DO @%i”



##我们做了什么?

  1. 我们运行build命令从我们在步骤3中创建的Docker镜像文件创建一个文件
  2. 使用标签开关-t,我们给镜像一个名称,我们可以使用它来引用它,而不必引用Docker生成的ID(例如50e8dde7e180)
  3. 我们指定了使用“.”指定的当前本地目录的镜像路径

## 步骤 4b:验证镜像
如果所有都按计划进行,我们应该看到(如.gif中的)一个“successful build ...”消息。我们现在可以运行一个命令来记住你的镜像:
docker images

03.png

在这种情况下,我们的组合镜像大小为61.26 MB,这是基本的alpine-node镜像和我们的express应用层的组合。
##步骤 4c:观察镜像文件层
如果我们想要看到为我们的镜像创建的文件层,我们可以运行命令:
docker history express-prod-i

04.png

# 步骤 5:运行镜像实例
既然我们已经创建了一个镜像,我们已经准备好创建一个隔离的,模块化的应用环境。正如我已经提到了很多次那样,那个环境是一个Docker容器。Docker容器实际上是镜像的运行实例。

在概念上,一个镜像和容器非常类似于我们如何想到一个JavaScript Prototype或一个OOP类。所以,我们来运行一个我们创建的镜像的实例。
##步骤 5a:生成并运行一个镜像实例

  1. 运行命令:

docker run -d --name express-prod-app -p 7000:3000 express-prod-i


  1. 登录浏览器访问http://localhost:7000。
05.png


## 我们做了什么?
我们创建并运行了一个express-prod-i镜像的实例而作为一个容器:

- 使用RUN命令
- 指定分离模式-d标志(所以我们不绑定当前终端/提示符)
- 并使用-name标志给我们的容器设置名字“express-prod-app”
- 将主机7000上的本地端口映射到使用-p标志显示的3000的内部容器端口
- 最后,指定我们要生成并运行我们的实例的“express-prod-i”镜像

注意:我使用不同的本地端口7000来向您展示您可以将主机上的任何未使用的端口映射到容器中暴露的内部端口。



提示:没有-d,我们将以贴合模式启动运行容器。这意味着它将从容器中直接输出到我们运行命令的终端/提示符。通过在分离模式下启动容器,我们可以继续从终端/提示符运行容器工作。



##顿悟#1
你明白了吗?我们不必在本地安装Node.js或NPM。我们没有必要运行npm安装本地使用的应用程序,我们没有从主机运行应用程序。所有这些都在主机内部发生,这是一个简单的express.js演示网站。
##步骤 5b:验证运行容器

  1. 我们可以使用这个命令观察运行时容器

docker ps

06.png


  1. 这将显示我们运行容器。我们还可以指定-a标志来查看所有容器。当事情出错时,可能会有用,我们想看看一个号称已经运行容器是否意外退出:

docker ps -a


#步骤 6:停止并启动容器

停止一个运行时容器是非常简单的...或许你已经猜到了:

docker stop express-prod-app


然后启动它

docker start express-prod-app

#步骤 7:删除镜像和容器
当我们浏览这些教程时,可以删除镜像或容器并重新开始。以下是步骤。另外,在“奖励”部分,还有一些有用的捷径:
## 步骤 7a:删除容器
删除一个容器,我们可以使用“rm”命令:
docker rm express-prod-app

让容器恢复回来,我们可以使用先前使用过的命令:
docker run -d --name express-prod-app -p 7000:3000 express-prod-i

## 步骤 7b:删除镜像
删除一个镜像,我们可以使用“rmi”命令:
docker rmi express-prod-i

让镜像恢复回来,我们可以使用先前使用过的命令:
docker build -t express-prod-i .


提示:删除镜像和容器命令可以使用镜像或容器ID,甚至可以使用ID的前几个字符。所以你可以任意选择。 (您还会看到我们在奖励部分中这样做。)



# 奖励
补充一些删除镜像和容器的其他手段,你可以使用一些我已经在用的有效的快捷方法。
## 删除所有容器
要删除所有容器,运行下面的“rm”命令,这条命令内部会返回所有的容器:
docker rm $(docker ps -a -q)

Windows用户:你需要是一个bash环境去运行这些命令。主要是因为只有GNU才能使用$()变量引用。你可以安装诸如“Bash on Ubuntu on Windows”甚至于 GIT bash。只要记得你需要运行docker-machine env来链接你的终端,并且运行显示在最后的eval命令。
## 我们做了什么?

  1. 我们想container提交了删除命令“rm”
  2. 但是我们提交的是一个容器ID的列表,而不是提供容器标签或是container ID
  3. 提供所有(-a)参数并组合静默(-q)将会返回数字类型的容器ID

## 删除所有镜像
删除所有的镜像我们可以类似于上面的做法,使用删除镜像命令“rmi”
docker rmi $(docker images -q)

## 我们做了什么?

  1. 这里我们使用了删除镜像命令但是入参是一个docker镜像ID列表……
  2. ……使用列出docker镜像的命令
  3. 并且设置静默(-q)参数,这样返回了数字型的Docker ID

## 这可以应用到生产吗?还是只是应用开发环境?
很明显能主要到我们刚刚创建的镜像通知Express.js和Node.js在生产环境中运行。那这是什么鬼?

记住我们是要为任何镜像制作基本镜像,并且谁会在开发环境中为每次修改而“重建”镜像呢?所以我们需要使用生产镜像来作为基本镜像构建我们的开发环境并且隔离开发修改到分层镜像中的开发层中。
# 总结
所以,我已经屏蔽了一大堆关于Docker的知识。创建镜像文件,构建镜像并生成该镜像的正在运行的容器。但是我们还有很多事情要去做。

因此,在本系列的下一篇文章中,我将针对我们的开发版本或应用程序创建一个镜像,但是基于我们的生产镜像。我们还将介绍如何利用容器中的脚本来帮助设置本地环境来更改源代码。

原文链接: Docker for Devs: Containerizing Your Application(翻译:高洪涛)

===========================================
译者介绍
高洪涛,当当网架构师,开源数据库分库分表中间件Sharding-JDBC作者。目前从事Docker,Mesos相关工作

Windows 容器对比:WinDocks vs. Microsoft

edge_dawn 发表了文章 • 0 个评论 • 3401 次浏览 • 2017-01-04 02:10 • 来自相关话题

【编者的话】介绍基于WinDocks的容器和Microsoft的容器之间的区别。 WinDocks是在Windows系统层面上的具有独立端的Docker开源应用。作为前微软工程师,我们致力于改善软件开发人员的工作,在2016年3月我们 ...查看全部
【编者的话】介绍基于WinDocks的容器和Microsoft的容器之间的区别。

WinDocks是在Windows系统层面上的具有独立端的Docker开源应用。作为前微软工程师,我们致力于改善软件开发人员的工作,在2016年3月我们开源了第一个基于Windows的Docker端。基于社区免费版我们培养了大量相关技术人员。

目前,微软发布了Windows Server 2016,并且支持Windows容器技术,那么许多人就想要详细探究WinDocks与微软的Windows容器到底在实现形式上有什么异同。以下的内容是基于微软SQL Server专业人士的公开演讲,以及对微软Windows Server 2016的容器测试。
#供开发和测试的容器
Windows容器与Linux容器带来同样的好处,因此我们希望Windows容器同样成为支持开发,测试和QA的首选基础设施。在不久的将来,容器可以引导持续集成,持续交付,DevOps的增长。

WinDocks容器提高了开发速度与效率,开发人员在一个共享的虚拟机使用隔离容器环境,每个实例化可以控制在秒级别。假设每个开发团队平均使用20个VM,应用容器技术的话,可以共用一个VM。20:1的比例缩减微软服务器许可证可以为Windocks的用户立即提高收益率(也可能不是 Mircosoft容器用户)。
#WinDocks vs. Microsoft
内置:微软的容器支持被包含在Windows Server 2016中,而且作为Windows 10专业版和企业版的附加,这就使得客户针对一个供应商提供服务支持。而对于容器本身支持则没有增加成本,他们实际上不一定是免费的。

WinDocks Windows支持:WinDocks对容器支持包括了所有版本的Windows 8、Windows 10、Windows Server 2012、Windows Server 2016,这样为开发人员提供了方便的接入。行业调查显示,客户计划逐步迁移到Windows Server 2016。这表明Windows Server 2012将继续扩大共享使用率到2020年,与Windows Server 2016同期逐渐增长。

SQL Server的支持:WinDocks的成立旨在解决开发人员所需有效的SQL服务器环境。超过80%的组织每月只测试SQL Server两次。WinDocks通过对SQL Server容器和镜像提供自动工作流的方式,来支持SQL Server 2008及以上所有版本的发布。WinDocks利用了微软成熟的DLL共享架构,使当前SQL Server通过容器发布而不变更工具或进程。

Windows Server 2016已经发布,但并没有有效的SQL Server支持。三个月后发布的SQL服务器镜像支持仍局限于SQL Server 2014 Express和SQL Server 2016 Express。其他悬而未决的问题包括缺乏支持SQL Server Management Studio 的Windows身份验证(目前仅限于SQL sa身份验证),以及缺乏IP回环的支持。简言之,微软对SQL Server的支持只能被形容为并不完善。

更大的问题还没有讨论是微软正在为未来的SQL Server容器镜像秘密计划新的SQL Server许可条款。新许可尚未透露,但考虑到减少VM来获取容器,不太可能是“免费”的。

应用程序容器vs. 微软臃肿软件:WinDocks容器通过“guards”容器和实施资源限制提供了用户和进程隔离。这个设计提供了类似于微软的安全服务器核心容器,为企业内提供了可信的工作负载。这个设计并不是为了不可信的多租户使用,这也解释了为什么微软提供hyper-v容器支持。

WinDocks应用级容器比Windows容器更加轻量级。微软容器背负重大的Windows文件,基本镜像平均> 9 GB,而WinDocks平均100 MB。微软容器需要20多额外的进程,而且比WinDocks容器额外多80 MB RAM。WinDocks .net IIS容器使用5 MB的RAM(16倍差),所以系统分级的影响是显著的。如果平均开发团队运行SQL Server和.NET,则微软容器主机需要比WinDocks服务器耗费更多的CPU和RAM!

微软这样的设计同时会导致镜像维护的增加,Windows更新迫使镜像重建(每个镜像包含大量Windows封装)。WinDocks的设计,相比之下,允许独立更新容器镜像。

镜像支持:除了支持所有SQL Server 2008及以上版本,WinDocks还支持Java及之上的Tomcat和Jetty,Nginx,node.js。正如我们已经指出的那样,微软缺乏镜像支持SQL Server发布的版本,以及Java的Tomcat服务。

其它应用程序支持:微软容器设计的一个优点是能够支持依赖注册表支持的Windows应用程序。WinDocks对SQL Server镜像的支持如何涉及到对Windows注册表的依赖,那么将是一个很大的工程量。微软的设计更好地支持范围广泛的依赖Windows注册表的应用程序。

容器发布:WinDocks利用本地安装.NET和SQL服务器实例来支持创建容器和镜像。这种方法实现起来比较简单高效,而且利用微软成熟的DLL共享架构。这种方法同时使用了现有的主机或基于SQL Server许可的核。当前SQL Server许可允许一个主机上的多个实例,而WinDocks使得这种多实例的使用更加快速和实用。对于开源的镜像,如Nginx,node.js或Java,WinDocks同时包含了可再发行的运行时支持。

微软的容器服务是基于新的设计模式,每个容器等于一个新安装的应用程序,容器镜像则是一个新的安装包。这就解释了微软引入新的许可条款的理由。

其他问题:微软对Windows容器的支持在不断的进步,但在发表这篇文章的时候仍然存在着缺乏支持IP回环,不支持mount,以及不支持SQL Server Management Studio的Windows身份验证。

#结论
WinDocks针对现有的系统和发行版本,可以简单的采用、使用和支持。开发人员可以在Windows 8,Windows10,Windows Server 2012,或Windows Server 2016上支持.NET、SQL Server和Java。WinDocks软件目前已经被广泛应用,开发人员平均减少VM使用比例为10:1,大大缩减了在微软许可证上的投入成本。

而相对来说,微软的容器之路并不完善,提供的可伸缩性很有限,这正是运维的痛点,并且其中还存在大量悬而未决的问题。客户如果使用微软的Windows容器应考虑等待新的SQL Server许可镜像,并且需要更多和更强大的系统来支持镜像维护。

原文链接: Windows Containers Compared: WinDocks vs. Microsoft(翻译:edge_dawn)

Windows下构建Node.js的Docker Nano Server基础镜像

iT2afL0rd 发表了文章 • 0 个评论 • 5409 次浏览 • 2016-07-31 20:22 • 来自相关话题

【编者的话】本文介绍了如何在Windows下制作Nano Server的Docker镜像,并用镜像来部署Node.js应用。 从Windows 10内测版14342开始,就可以开启Windows中新的容器功能了。这让你可以直接在W ...查看全部
【编者的话】本文介绍了如何在Windows下制作Nano Server的Docker镜像,并用镜像来部署Node.js应用。

从Windows 10内测版14342开始,就可以开启Windows中新的容器功能了。这让你可以直接在Windows 10里以Hyper-V容器的方式直接运行Windows容器。而且目前为止只支持Nano Server容器。因此,是时候开始适应Nano Server并创建一些基础镜像了。
containerswindows10-containers-feature.png

在这篇博客里,我将展示如何构建小的基础镜像,并用Nano Server Docker镜像部署Node.js应用。然后在Windows 10或者Windows Server 2016 TP5中运行这些应用。

什么是Nano Server ?


每个Docker镜像都必须使用两个OS镜像中的一个:`windowsservercore`或者`nanoserver`。

Windows Server Core镜像是和之前的安装版本高度兼容的。你没有GUI界面,但是什么都可以安装。但是这种兼容性是有代价的,这个OS镜像的大小有9.3GB,因为它几乎包含了整个服务器。

Nano Server镜像是一个经过高度优化的镜像。为了能在云服务器上部署更多这样的容器,它几乎把所有安装包都移除了。它的大小只有817MB,使得在Windows 10上安装Docker比用`windowsservercore`镜像快很多。

因此,如果有人问该如何选择,我想答案应该是更小的那个。

挑战:MSI安装包


当你开始尝试写Dockerfile往Docker镜像中安装一些软件的时候,你会注意到这个最小化的系统带来了新的挑战。``在Nano Server中无法安装MSI安装包``。

在上可以看到,会同时安装npm的只有MSI的安装包。

因此我们如何才可以基于Nano Server构建Node.js的Docker镜像呢?我试过很多方法,比如,在构建Nano Server镜像的时候同时安装lessmsi这样的工具,结果却发现lessmsi是一个32位的应用。Nano Server的另一个局限性就是只能运行64位应用。

另一个方法是在Docker主机上安装Node.js然后把这些文件拷贝到Docker镜像中。但是我不想在Docker主机上安装额外的工具。

因此,接下来我展示一下如何只用Docker命令和Windows Server 2016 TP5来构建Windows Server Core镜像和Nano Server镜像,并安装Node.js和npm。

# 第一步-在Windows Server Core镜像中安装MSI


从Windows Server Core镜像开始会更简单。你可以用下面这个Dockerfile下载安装Node.js MSI包。这个Dockerfile和Linux的版本很像,下载、验证、安装然后删除文件。

现在打开编辑器:
notepad Dockerfile.

然后输入下面的Dockerfile:
FROM windowsservercore

ENV NPM_CONFIG_LOGLEVEL info
ENV NODE_VERSION 4.4.5
ENV NODE_SHA256 7b2409605c871a40d60c187bd24f6f6ddf10590df060b7d905ef46b3b3aa7f81

RUN powershell -Command \
wget -Uri https://nodejs.org/dist/v%NODE_VERSION%/node-v%NODE_VERSION%-x64.msi -OutFile node.msi -UseBasicParsing ; \
if ((Get-FileHash node.msi -Algorithm sha256).Hash -ne $env:NODE_SHA256) {exit 1} ; \
Start-Process -FilePath msiexec -ArgumentList /q, /i, node.msi -Wait ; \
Remove-Item -Path node.msi

CMD [ "node.exe" ]

接下来构建Node.js的Docker镜像:
docker build -t node:4.4.5 .

这样,Node.js和npm已经在你的Docker镜像中安装好了。
# 第二步-提取Node.js目录

现在我们要从Docker镜像中提取Node.js的安装目录。我们需要运行一个Docker容器,然后把这个目录拷贝到宿主机的临时目录里:
docker run --name=node-temp node:4.4.5 node --version  
docker cp "node-temp:c:\Program Files\nodejs" nodejs
docker rm -vf node-temp

# 第三步-拷贝部署到Nano Server镜像

我们就用这个提取出来的目录构建Nano Server镜像。下面的`Dockerfile`会把这个临时目录拷贝到Windows的PATH路径里。你也许想要把这些文件放到其他的目录里,但不要忘了把目录加到PATH里去。

给Nano Server的Dockerfile创建一个子目录:
mkdir nano  
notepad nano\Dockerfile.

然后创建Dockerfile:
FROM nanoserver

COPY nodejs /windows/system32

CMD [ "node.exe" ]

运行下面的命令创建Nano Server镜像:
docker build -t node:4.4.5-nano nano  

现在我们有了两个Docker镜像,一个是Windows Server Core,另一个是Nano Server。

我画了一个简单的图,描述了在上面的三个步骤里我做了什么:
containersnodejs_nanoserver-2.png

我已经把这两个Docker镜像上传到DockerHub上了,并且发现Windows Server Core镜像大约55MB,Nano Server镜像只有9MB。

我把第一个Docker镜像的所有层提取出来后发现,安装MSI包会在cache里面保存一份安装包的拷贝。运行命令也会使本地数据库发生一些改变。

所以,如果要构建比较小的Windows Docker镜像,那就要避免安装MSI包。最好选择ZIP文件,甚至是使用COPY命令把文件拷贝到镜像。当然,MSI安装包会更方便,但是它的副作用就是镜像会比较大。

用ONBUILD命令构建应用


另一个Docker化Node.js应用的简单方法是使用Dockerfile的ONBUILD功能。在准备好的Docker镜像上使用这个功能是非常方便的,至少对于做个简单的例子来说是这样。

让我们再创建一个和官方的`node:onbuild`镜像一样的Dockerfile,这个Dockerfile和上面的Dockerfile一样安装应用和所有依赖的程序:

* 拷贝package.json
* 运行npm install
* 拷贝其他资源

因此我们为这个Dockerfile创建了一个独立的目录:
mkdir nano\onbuild  
notepad nano\onbuild\Dockerfile.

然后输入内容:
FROM node:4.4.5-nano

RUN mkdir \app
WORKDIR /app

ONBUILD COPY package.json package.json
ONBUILD RUN npm install
ONBUILD COPY . .

CMD [ "npm.cmd", "start" ]

现在可以用ONBUILD功能构建Nano Server镜像:
docker build --isolation=hyperv -t node:4.4.5-nano-onbuild nano/onbuild 

我已经用一个基于`Express`的小型Node.js Web Server测试过,没有任何问题。

现在要构建一个跑在Nano Server容器里的Docker化的Node.js应用,你只需要在你的Dockerfile上加一行:
FROM nano:4.4.5-nano-onbuild 

然后构建Docker应用:
docker build --isolation=hyperv -t mynodeapp:nano . 

优化

研究了这样的应用的镜像的所有层之后又发现了一些不必要的文件夹:

* npm-cache目录
* npm生产的很多临时目录

因此我们可以优化上面的那个ONBUILD Dockerfile,在构建Docker镜像的时候把这些临时目录删掉。本来可以用`npm cache clean`命令,但是对我这里不起作用,所以我改用了一些`rd`命令。下面是最终版本的ONBUILD Dockerfile:
FROM node:4.4.5-nano

RUN mkdir \app
WORKDIR /app

ONBUILD COPY package.json package.json
ONBUILD RUN npm install & rd /s /q %APPDATA%\npm-cache & for /d %G in ("%TEMP%\npm-*") do rd /s /q "%~G"
ONBUILD COPY . .

CMD [ "npm.cmd", "start" ]

用这个优化后的Docker镜像部署一个Express服务器,最终的镜像大小从24MB减少到15MB。而DockerHub上的未经优化的Windows Server Core镜像在部署了Express之后达到了82MB。
总结

如果你不想自己手动构建这些Node.js应用,可以在Docker Hub上找到它们,里面有Dockerfile在GitHub上的链接。

有了Docker Hub上这样的Node.js Nano Server基础镜像,你可以在你的Windows 10机器上进行开发了。你可以Docker化你的Node.js应用,把它们放到Nano Server容器里,然后在Docker Hub上分享给其他人。

Windows Server 2016只是用来安装MSI安装包,然后提取软件到Nano Server镜像的。

原文链接:How to Build Node.js Nano Server Image(翻译:Lambert Sun)

===========================================================
译者介绍
Lambert Sun,趋势科技DevOps Lead,敏捷开发实践者。

Windows容器网络

chilly_2016 发表了文章 • 0 个评论 • 4641 次浏览 • 2016-05-16 21:05 • 来自相关话题

【编者的话】下面请允许我激动的介绍Windows容器以及微软和Docker的合作。我们团队投入大量资源研发出Windows Server Technical Preview 5容器网络堆栈,除借鉴Docker的管理经验外,还研发出Windows容器特有的功能和 ...查看全部
【编者的话】下面请允许我激动的介绍Windows容器以及微软和Docker的合作。我们团队投入大量资源研发出Windows Server Technical Preview 5容器网络堆栈,除借鉴Docker的管理经验外,还研发出Windows容器特有的功能和特性。本文将围绕Windows容器的网络堆栈,讲述如何使用Docker让容器网络连通,以及微软如何使容器成为基于Microsoft Azure Stack所构建的现代数据中心的一阶对象。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、数人云、点融网、华为、轻元科技、中兴通讯、中国民生银行、长安汽车等公司的技术负责人将带来实践经验分享,欢迎感兴趣的同学参加。
#简介
Windows容器可应用在不同类型的应用场景下,从运行Node.js的Web服务器到数据库,再到视频流。这些应用都需要通过网络连接实现服务发布。那么Windows容器的网络堆栈是什么样子的呢?如何为一个容器分配IP地址或将容器Endpoint连接到网络?以及如何设置最大网络带宽和ACL规则等网络高级策略呢?

下面通过这张容器网络堆栈图(图1)帮助我们加深理解。
图1-Windows容器网络堆栈.jpg

图1 Windows容器网络堆栈

所有运行容器的宿主机可以是一台物理服务器、一个Windows客户端、或者一台虚拟机。假如容器宿主已经通过一张NIC卡接入WiFi或以太网实现了网络连接,并需将网络连接扩展到容器自身。容器宿主可使用Hyper-V虚拟交换机实现宿主机到容器的连接,并通过Host vNIC(Windows服务器容器)或Synthetic VM NIC (Hyper-V 容器)两种方式实现容器到vSwitch之间的连接。相比于此,Linux容器技术使用bridge设备而非Hyper-V虚拟交换机,使用veth 偶对而非 vNICs / vmNICs来提供容器间的基础2层(以太网)连接。

Hyper-V虚拟交换机本身并不允许外网访问运行在容器内的网络服务。我们需要3层(IP)连接性来确保数据包能正确路由到目的地。除IP外还需支持更高层的网络协议,如TCP和UDP协议,通过特定端口号寻址到容器中运行的服务(例如,TCP端口80通常用来访问WEB服务)。为了让容器更有用,还需在容器中提供4~7层服务,如DNS、DHCP、 HTTP、SMB等。所有以上特性均会在Windows容器网络中得到支持。
#Docker网络配置和管理堆栈
Windows Server Technical Preview 5 (TP5) 提供了通过Docker客户端及Dockers引擎RESTful API接口两种方式安装容器网络。网络配置根据设置的范围,既可在容器网络创建时配置也可在容器创建时配置。相关MDSN文章可提供更详细的信息。

Windows容器网络管理堆栈使用Docker作为管理入口,并将 Windows宿主网络服务( Host Network Service ,HNS)作为服务层,用来创建下层网络(如,vSwitch,WinNAT等)中的“管道”。Docker引擎通过一个网络插件(libnetwork)实现同HNS的通信。请参考图2了解管理堆栈。
图2-管理堆栈.jpg

图2 管理堆栈

管理堆栈使Docker网络通过HNS实现同Windows网络层的插件式对接。因为创建过程的自动化,用户无需自己设置静态端口映射或防火墙策略(如NAT转换)。
##举例:通过Docker创建静态端口映射
注意:NetNatStaticMapping (及防火墙策略)都将自创创建
NetNatStaticMapping.jpg

#网络模式
Windows容器的网络连接有四种不同的网络模式(或驱动)。不同模式的选择取决于容器如何被外网客户端访问,IP地址如何分配,网络策略如何执行等因素。

每种网络模式都将使用内部或外部虚拟交换机(由HNS自动创建)来打通容器到容器宿主的物理(或虚拟)网络。下面就四种模式以下给出使用建议。关于每种模式的详细信息请到MDSN文章中查找。

* NAT –默认模式,连接容器到私有IP子网,此模式可方便快捷的应用到任何环境;
* Transparent –此模式不经过任何网络转换,直接连接容器到物理网络。当一台宿主机上运行过多容器时,请小心使用此模式,可能会快速导致物理网络问题;
* L2 Bridge / L2 Tunnel –这两种模式通常用在公有云或私有云环境中,以租用虚拟机运行容器的场景下。

注: Windows Server 2016 或者Windows 10 客户端不再支持NAT 虚拟交换模式创建。NAT容器网络可通过在Docker中设定nat驱动或者在PowerShell环境下运行NAT模式来创建。

##举例:创建Docker ‘NAT’网络
请注意虚拟交换和NetNat如何被自动创建。
NetNat.jpg

#容器网络+软件定义网络(SDN)
容器逐步成为数据中心和企业的一阶实体,同虚拟机相提并论。而IaaS云租户或企业业务部门需要同时支持虚拟网卡和容器Endpoint两种模式下,程序化地定义网络策略(如ACLs、QoS、负载均衡等)。Windows Server 2016 版本的软件定义的网络(SDN)堆栈支持客户在Windows Network Controller使用PowerShell 脚本、SCVMM或微软 Azure Stack新出的Azure Portal 为容器Endpoint 定义网络策略。

在虚拟化环境下,容器宿主可以是一台物理服务器上的虚拟机。Network Controller通过标准的SouthBound 通道(如OVSDB)发送策略给运行在物理服务器上的宿主Agent,宿主Agent将策略传入物理服务器的vSwitch的VFP进行执行。由于网络策略是特定于具体某个IP地址(如,容器Endpoint)的,当多个容器Endpoint被连接到同一张容器宿主网卡时,网络策略仍然可以被细粒度地定义。

L2 Tunnel 网络模式下,所有容器宿主虚拟机的网络流量都将通过物理服务器的vSwitch收发,vSwitch 上的VFP转发扩展将会执行从Network Controller 以及Azure Stack中的高层组件(如Network Resource Provider、Azure Resource Manager、Azure Portal)接收到的网络策略。堆栈架构请参考图3。
图3-容器实现同SDN叠加虚拟网的连接.jpg

图3 容器实现同SDN叠加虚拟网的连接

这样容器可以加入由独立云租户创建的叠加虚拟网(如,VxLAN),实现跨节点集群内的通信以及同其他虚拟机的通信,还可以接收网络策略。
#美好未来
未来我们不仅会在Windows操作系统上不断创新,更会贡献更多的代码到GitHub的Docker 开源项目上。我们希望Windows的容器使用者可以使用到更加丰富的网络策略,并通过容器客户端来创建网络策略。我们也希望将网络策略的执行尽可能的更靠近容器Endpoint,来缩减数据路径,提升网络吞吐,降低网络时延。

原文链接:Windows Container Network(翻译:Chilly,审校:滕启明)

创建Windows 2016 TP5 Docker本地虚拟机

夕口夕 发表了文章 • 0 个评论 • 5404 次浏览 • 2016-05-08 15:26 • 来自相关话题

【编者的话】继Windows 2016 TP5上的Docker初次体验之后,作者接着写了这篇创建本地虚拟机的文章,给出了Packer和Vagrant的用法,并详细说明了Packer的功能。 @Container容器技术大会将于6月4日 ...查看全部
【编者的话】继Windows 2016 TP5上的Docker初次体验之后,作者接着写了这篇创建本地虚拟机的文章,给出了Packer和Vagrant的用法,并详细说明了Packer的功能。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、数人云、点融网、华为、轻元科技、中兴通讯、中国民生银行等公司的技术负责人将带来实践经验分享,欢迎感兴趣的同学参加。

越来越多的人开始试用Windows Docker容器,这太棒了。无论是想了解Windows上所运行的Docker引擎的当前状态,还是想亲身体验一下Windows容器来,最新的Windows Server 2016 Technical Preview 5都是一个很好的起点。

不久就会有很容易上手的微软Azure模板。一旦这个补丁被合并,就意味着用户可以很容易地在Azure上创建Docker Machine。
#教程
目前而言,创建本地的VM还是需要花费一点时间和精力的。有一些不错的教程可以指导你完成必要步骤。

* 在Windows Server 2016 VirtualBox中创建Docker (作者:Arun Gupta)
* Hyper-V中的Windows Docker 容器(作者:Gabriel Schenker)

#Packer + Vagrant = Automation
如果你不想全部采用手工方式完成创建工作,在你的计算机面前等待下一步操作提示,你也可以用Packer和Vagrant。

Packer使用ISO文件作为输入,制作用于Vagrant环境的基本虚拟机。使用Vagrant,你可以启动一个或者多个这样的虚拟机,甚至可以形成一个Windows Docker Swarm集群。

本文所使用的Packer模板可以用来创建含有Docker Engine的Windows 2016 TP5 虚拟机。这个模板已经用VirtualBox 5.0.20 和 VMware Fusion 8.1测试过。如果你用的是Windows系统,模板应该也可以在 VMware Workstation上使用。
##运行 Packer
使用Packer 0.10.0创建Vagrant基本虚拟机,只需要克隆下面的GitHub repo
git clone https://github.com/StefanScherer/packer-windows  
cd packer-windows

然后为VMware创建Vagrant基本虚拟机:
packer build --only=vmware-iso windows_2016_docker.json

或者为VirtualBox创建Vagrant基本虚拟机:
packer build --only=virtualbox-iso windows_2016_docker.json

这个过程大概要花上一个小时。
packer-build.png

上述步骤完成之后,当前路径中应该就会有一个box文件。将该文件添加到Vagrant:
vagrant box add windows_2016_tp5_docker windows_2016_docker_vmware.box

如果你既有VirtualBox环境,也有VMware环境,你也可以为这两种环境分别创建和添加基本虚拟机。你可以列出所有的base box:
$ vagrant box list
windows_2016_tp5_docker (virtualbox, 0)
windows_2016_tp5_docker (vmware_desktop, 0)

#运行 Vagrant
现在你可以使用新的基本虚拟机来执行一些测试工作了。这里,我们需要访问另一个GitHub repo。第一步是克隆代码:
git clone https://github.com/StefanScherer/docker-windows-box  
cd docker-windows-box

使用Vagrant 1.8.1,可以很容易地启动虚拟机,并让Docker在Windows 2016 TP5上运行:
vagrant up

Vagrant启动VM,安装其它的Docker工具(如Machine和Compose)。同时也安装Git以便访问一些在Github上的Windows Dockerfile。
vagrant-up-1.png

你可以打开PowerShell来执行一些命令,例如:
docker version  
docker images

docker-version.png

恭喜你!你现在可以用Windows 2016 TP5上的全新Docker引擎开始工作了!
#Packer能做什么
如果你想了解Packer在自动创建虚拟机的过程中做了什么,下面列出了Packer所运行的一些部署脚本。
##安装功能组件
在脚本文件enable-winrm.ps1中,在打开WinRM端口让Packer登录和进行进一步准备之前,将启用一些Windows配置,如Container支持和Hyper-V(仅针对VMware)支持。
##安装Docker
下一个脚本install-docker.ps1,用来安装Docker服务、Docker客户端和名为windowsservercore的Docker基础镜像。如果Hyper-V已启用,也会安装名为nanoserver的Docker基础镜像 。
##修补windowsservercore镜像
因为TP5和相关的文件以及镜像很新,并且还是预发布版本,保不定哪儿还有点问题。

目前我们需要这个脚本来为windowsservercore Docker镜像提速。脚本patch-boot-time-for-containers.ps1就是用来处理这个问题的。
##启用不安全的Docker端口2375
在本地的测试环境,我们用脚本enable-docker-insecure.ps1打开不安全的Docker端口2375。

你可以从运行该虚拟机的主机上远程控制Windows Docker引擎。平时使用Linux或者Mac的人更该尝试一下。

一旦将来有了本地Windows VM的Docker Machine驱动程序,我更倾向于使用它来建立安全的TLS连接。
##添加Docker群组
新的Windows Docker引擎会在一个Windows命名管道上监听消息,这与在Linux系统上监听 Unix套接字很相似。

普通用户不能访问这一命名管道,所以需要使用管理员Shell来操控Docker引擎。

脚本add-docker-group.ps1将选项-G docker添加到Docker引擎的启动命令,这样Windows用户组docker里的所有成员就都具有了访问命名管道的权限。

该脚本还在用户vagrant添加到这个docker用户组。所以,在Vagrant虚拟机中你就可以打开一个普通的PowerShell窗口来操控Docker引擎了。
##删除 key.json
最后一个脚本remove-docker-key-json.ps1负责删除初始安装的key.json文件。在第一次启动运行Docker引擎时,每个Vagrant虚拟机中都会创建这个文件,并且根据不同Docker引擎创建不同的ID。

如果你想要构建一个Windows Docker Swarm集群,记得每个Docker引擎都需要一个不同的ID。
#结论
由于Docker基础镜像和Docker引擎会持续更新,用Packer和Vagrant自动重建基本虚拟机就简单多了,不再需要执行那些手工操作的步骤。

如果这篇文章对你有用,请分享给朋友和同事。如果你有问题或更好的建议,请留下评论。你还可以在推特@stefscherer关注我。

原文链接:Setup a local Windows 2016 TP5 Docker VM(翻译:马远征 审校:滕启明)

docker for windows 使用 --net=host启动容器后,从主机无法访问

回复

karel 发起了问题 • 1 人关注 • 0 个回复 • 3131 次浏览 • 2017-09-29 17:19 • 来自相关话题

Windows上该如何制作Dockefile

回复

coagent 回复了问题 • 2 人关注 • 1 个回复 • 2073 次浏览 • 2017-03-01 11:13 • 来自相关话题

Windows中的Docker技术进展如何?

回复

wisen 回复了问题 • 10 人关注 • 7 个回复 • 7073 次浏览 • 2016-04-22 08:58 • 来自相关话题

Windows下用Boot2Docker安装Docker遇到问题

回复

markpeng 回复了问题 • 3 人关注 • 1 个回复 • 4986 次浏览 • 2015-06-04 11:40 • 来自相关话题

睽违已久:Travis CI终于牵手Windows

大卫 发表了文章 • 0 个评论 • 1221 次浏览 • 2018-10-12 17:16 • 来自相关话题

在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。 Windows系统现已面向tarvis-ci.org或 ...查看全部
在这里我们骄傲地宣布,从今天开始,Travis CI将支持Windows操作系统!您和您的团队如今可以在Linux、Mac以及Windows上经由同一套build实现测试运行了。

Windows系统现已面向tarvis-ci.org或者travis-ci.com上的全部开源及私有项目使用,我们亦有计划尽快将其引入企业环境。这是我们第一次发布Windows支持方案,因此相关工具链还不够完善——期待大家能够在我们的社区论坛上提供反馈。请马上加入吧!

我们知道,大家一直在期待对Windows系统的支持方案。在论坛上的2104号问题中,我们发布了一些关于初步规划的见解,而我们杰出的贡献者Hiro Asari于2013年也加入到项目中来。Hiro开发出多个早期概念验证方案以及一系列其它成果,同时快速成为我们在GitHub上的应答发言人,外加travis-build与dpl的维护者/开发者。经过这么长的时间,以及众多原型设计,Windows支持能力终于准备就绪——这样的结果令我们的激动之情溢于言表。

另外,我们在npm上的好朋友们同样对此抱有极高热情!

今天的公告带来了令人振奋的消息。我们知道,有超过40%的npm用户在使用Windows设备,但在此之前只有一小部分软件包能够在CI当中主动运行Windows测试。为Travis CI添加Windows支持能力将为JavaScript社区的主体带来更稳定的开发体验——更具体地讲,npm Registry中有32%的项目在使用Travis CI。我们期待着继续与Travis CI开展合作,从而降低开发人员的日常工作难度,并最终确保全球超过1000万开发者构建出令人惊叹的产品。 ——npm有限公司首席执行官Laurie Voss

我们迫不及待希望扩展Windows Build Environment,用以支持大家团队及社区中正在进行的一切出色工作!
#Windows Build Environment
这套Windows构建环境在发布之初支持Node.js、Rust以及Bash语言。我们还运行有一套git bash shell,用以维持与我们其它基于bash环境间的一致性。此外,Docker同样可用于各Windows build。

我们利用Chocolatey作为软件包管理器,同时预安装有Visual Studio 2017 Build Tools以帮助用户。大家现在可以点击此处通过文档查阅我们目前在Windows构建环境中提供的全部软件包。Windows构建环境目前基于Windows Server 1803,其中作为容器运行平台的系统版本为Windows Server 2016。

我们还在Google Compute Engine中托管我们的Windows虚拟机,不过我们发现其启动时间会有所差别。因此我们打算在接下来的基础设施调整工作当中,持续对其做出改进与优化。
##上手指南
要运行一套Windows build,请将以下内容添加至 .travis.yml当中:
os: windows

大家也可以利用以下内容对多套操作系统进行测试:
os:
- windows
- linux
- osx

我们还在Windows上为大家准备了其它一些酷炫的项目,例如:

* yargs/yargs
* npm/node-semver
* docker-library/golang -(请参阅PR for how docker-libary/golang added Windows support!

希望上述内容能够为大家带来更多启示与灵感!
#展望未来
在早期版本发布之后,我们将根据大家的反馈对构建环境及运行时工具的安装与配置做出持续改进。我们希望在接下来的3到6个月内进行快速迭代,并计划在2019年第二季度推出稳定版本。在同一时间点上,我们还希望能够推出Windows Build Environments for Enterprise。如果大家热切盼望其尽早推出,请与我们的企业团队!
#分享您的反馈!
要将Windows推向更高级别,我们需要您带来的反馈意见——特别是在Windows上进行开发的朋友们!您希望获得哪些工具?环境应当如何运作?您需要了解哪些内容才能保证自己的团队快速上手?请在社区论坛上给我们留言。我们正在努力为最好的CI社区构建最出色的CI方案,而您的意见是我们达成目标的必要前提。

此外,这里还要感谢一直为我们提供帮助的贡献者们——特别是Jordan Harband、Alex Crichton、Tianon Gravi以及其他无数参与者!

我们期待着听到您对Travis CI与Windows平台结合方面提出的宝贵建议!

原文链接:Windows is Available (Early Release)

如何在Windows 10上运行Docker和Kubernetes?

yahoon 发表了文章 • 1 个评论 • 12920 次浏览 • 2018-08-12 22:08 • 来自相关话题

在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。 但是 ...查看全部
在Windows上学习Docker和Kubernetes,开始的时候会让你觉得无从下手。最起码安装好这些软件都不是一件容易的事情。实际上,你应该对Docker和Kubernetes相当熟悉了才知道如何选择安装时启用哪些参数选项。

但是不要担心!

这篇文章就是为在Winodws上刚刚入门容器和Kubernetes的同学而准备的。

你将会学习到如何做出正确的选择来搭建Windows上的容器开发环境。

让我们从Docker说起。
# 你正在使用Windows 10 Home版?你将无法运行Docker for Windows
当Docker的开发者们决定在Winodows上实现Docker时,他们选择了Hyper-V作为虚拟化技术。这个优点十分明显:优秀的性能和原生的hypvervisor。

不幸的是并不是所有的Windows版本带Hyper-V支持

如果你正在使用Windows 10 home版或者Student版,那么你就中招了。你将无法安装和运行Docker for Windows。

但是先别失望。

你有许多基于Docker Machine的替代品可用,例如Docker toolbox或者minikube。

Docker Machine的工作方式很简单:有一个VM装好了Linux和Docker给你。你可以从你的主机连到虚拟机上的Docker deamon。

Minikube可以说是基于Docker Machine的最有趣的VM之一——你可以在里面运行Kubernetes集群。

事实上,minikube是一个运行Docker和Kubernetes的VM。它通常是用来单独运行Kubernetes的,但是你也可以用它来跑Docker容器。

你可能不会拥有Docker for Windows那样的速度,但是毕竟你不需要Hyper-V就能够构建和运行容器了。
# 有了Windows 10 Pro,Docker for Windows是最佳选择(除了特殊情况)
你有最新的Win 10 Pro,你可以安装Docker for Windows。 你拥有了优秀的性能和开发者体验,一切都搞定了,是吗?

答案是不一定!

Docker for Windows使用的hypvervisor是相当强大的——它属于`Type-1 hypervisor`。 它确实很强大但是它却无法与Virtualbox这样的`Type-2 hypervisor`一起工作。

你不能在同一台机器上同时运行Type 1和Type 2的hypervisor。换句话说,如果你运行Docker for Windows,那你就无法启动VirtualBox里面的VM了。

这跟你的设置相关,影响可大可小。

如果你已经完全使用容器化了,你就不需要担心VM——过时的东西。

但是如果你仍然要使用VM,以及类似Vagrant这样的工具,那你可能就有麻烦了。

你可以随意的启用或者关闭Hyper-V hypervisor,但是你要重启机器

如果你频繁的要从容器切换到VM,那可能使用minikube更方便。当你从容器切换到VM的时候就不用重启电脑了。 缺点就是你没办法得到更高性能和更好体验。

最后,如果你要运行Windows容器——`base镜像是来自于Windows的容器`——Docker for Windows是唯一选择。 你只能使用Windows 10 Pro或者Enterprise版。
# 运行一个本地的Kubernetes集群
如果你想要跑一个本地的Kubernetes,那你应该考虑minikube。

Minikube是一个预装有嵌入式Linux(Buildroot)和Docker daemon的VM。

它是一个最小完整的Kubernetes环境

Minikube的VM可以通过VirtualBox或者Hyper-V来运行(当然也有其他选择)。如果你已经有Hyper-V也要用它来跑Docker和minikube的话就会很方便。

当然如果你不能跑Hyper-V也没关系,你可以用VirtualBox实现同样的功能。

有很多的选择和权衡,下图列出了一些:
1.png

# 前提
你可以从官网上下载安装Docker for Windows、Docker Toolbox、VirtualBox、kubectl、Docker CLI等,但是相当麻烦。

你要去到官网找到正确的下载地址,选择正确的版本,下载安装,最后加到你的path里面去。

这当然可行,但是我敢肯定你更愿意把时间花在编码而不是从网站上下载安装软件包上。

使用Chocolatey

Chocolatey是一个Widnows的包管理器。你告诉它想要安装的包,它会为你装好。你把软件安装的活外包给它了。

安装Chocolatey很简单,你可以在它的官方网站找到步骤。简单来说,就这么几步:

1、以管理员启动`cmd.exe`

2、执行下面这个命令:
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

3、重新加载`cmd.exe`

如果安装成功,那么你可以搜索软件包:
choco search docker

我们来试一把,安装Cmder——一个Windows上的时尚shell:
choco install cmder -y

Chocolatey会安装到`C:\tools`下。如果你要用Cinder做如下的练习,您可以以管理员启动它:
2.png

看起来不错!
# 1. 在Windows 10 Pro上安装Docker和Kubernetes
##安装Docker
安装Docker for Windows:
choco install docker-for-windows -y

重启你的电脑。Docker会问你是否要启用Hyper-V。
3.png

选择Yes。

你需要知道Docker需要启用VT-X/AMD-v的硬件虚拟化扩展来运行容器。你需要在重启电脑时在BIOS里面配置它。

你可以用systeminfo命令来检查VT-x/AMD-v是否打开。

如果你不确定VT-x/AMD-v是否打开,也不用担心。因为你没有的话,Docker会报错:

Hardware assisted virtualization and data execution protection must be enabled in the BIOS.



4.png

另一个常见问题是Hyper-V没有启用,这样你会见到如下错误:
5.png

你应该启用Hyper-V。以管理员打开新的命令提示符,敲入:
bcdedit /set hypervisorlaunchtype auto

你重启电脑之后Docker就应该可以启动了。

但如何知道Docker已经跑起来了呢?

打开命令提示符:
docker ps


如果一切正常,那么你会看见输出一个空的列表(正在运行的容器列表)。

如果Docker deamon没有运行的话,你可能就会遇到如下错误:
6.png

上面的错误表示你的Docker安装不正常,Docker无法启动。

你应该先启动Docker daemon,然后再连接它。
# 在Hyper-V上安装Minikube

安装minikube:
choco install minikube -y

在启动集群之前,你应该先创建一个外部的网络交换机。

第一步,你应该先查看你电脑的网络适配器。

你应该忽略掉虚拟网卡,而关注在真实活跃的物理网卡上,比如Ethernet或者WiFi。

选择好物理网卡让它与虚拟交换机共享网络连接。

要查看你当前的网络适配器,你可以在PowerShell里面使用Get-NetAdapter cmdlet。

点击左下角的Windows图标,输入PowerShell来打开它:

输入如下命令来列出所有的适配器:
Get-NetAdapter

7.png

如果你还是不知道该选哪个,那么就选择Up状态的那个。

一旦你选择好了适配器,你就可以开始创建外部虚拟交换机了:
New-Switch -Name "minikube" -AllowManagement $TRUE -NetAdapternmae "INSERT_HERE_ADAPTER"

别忘了填入之前选择的适配器名字。

如果你没有创建好网络交换机,那么启动minikube的时候会报如下错误:

E0427 09:06:16.000298 3252 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks. no External vswitch found. A valid vswitch must be available for this command to run. Check https://docs.docker.com/machine/drivers/hyper-v/.



你可以运行以下命令来测试minikube安装是否成功:
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube


请注意:`--vm-driver=hyperv --hyperv-virtual-switch=minikube` 只在第一次启动时需要。如果你希望更改driver或者内存,那么你需要执行`minkube destroy`然后用新的配置重新创建。

如果minikube启动失败,那么你可以通过以下命令调试:
minikube delete
minikube start --vm-driver=hyperv --hyperv-virtual-switch=minikube --v=7 --alsologtostderr

更多的输出日志可以帮助你快速排错。我遇到过如下的问题:

E0427 09:19:10.114873 10012 start.go:159] Error starting host: Error starting stopped host: exit status 1.



这看不出来啥。我就打开详细的日志输出,错误就变得明显了:
+ Hyper-V\Start-VM minikube 
+ + ~~~~~~~~~~~~~~~~~~~~~~~~~
+ + CategoryInfo : FromStdErr: (:) [Start-VM], VirtualizationException
+ + FullyQualifiedErrorId : OutOfMemory,Microsoft.HyperV.PowerShell.Commands.StartVM

内存不够了!

这时可以看看安装成功了没。在命令提示符输入:
kubectl get nodes


你会看到Kubernetes里面有一个node显示出来。

在virtualbox里面运行虚拟机

因为你已经在设备上启用了Hyper-V,你就无法再通过virtualbox跑VM了。如果你强行要启用vm的话,会遇到如下错误:
8.png

如果你想用VirtualBox这种Type-2 的hypervisor, 你先要停掉Hyper-V然后重启电脑。

以管理员打开命令提示符:
bcdedit /set hypervisorlaunchtype off

当机器重启之后,你就可以正常使用VirtualBox了。

如果你又想要用Docker和minkube了,你要重新打开Hyper-V然后重启机器。

以管理员打开命令行,输入:
bcdedit /set hypervsiorlaunchtype auto

重启, 这样你就可以将容器部署到Kubernetes中了。

请跳到测试你的Docker 安装
#2. 在Win 10 Home版本上安装Docker和Kubernetes
如果你正使用Windows 10的Home版或者Student版,你可能不需要安装Docker Machine 工具(比如Docker Toolbox)。

你应该使用minikube作为远程的Docker deamon和本地的Kubernetes集群。

你可以下载安装minikube:
choco install minikube

在装完了以后,你可以启动:
minikube start

这个命令会下载一个VirtualBox要用到的ISO,然后启动VM。启动之后你就可以查看集群状态:
kubectl get nodes

看见一个node列出来。

要连接到远程的Docker deamon,你应该安装Docker客户端:
choco install docker -y

你可以连到minkube上远程的Docker daemon:
@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i


注意:每次你打开一个新的命令行窗口,你都需要以上命令。一种提醒你自己的简单方式是敲一下`minikube docker-env`。

如果连接成功,你可以列出当前正在运行的容器:
docker ps

你会看到很多容器正在运行。大部分属于Kubernetes。

你已经一切准备就绪!

但是在你继续之前,你需要清楚使用minikube作为你远程Docker daemon的一些限制。

Docker被设计为两个部分:

  • Docker daemon ——你可以将它理解为一个API server。你把命令发给它的API,Docker接收然后执行命令。
  • Docker CLI —— 将命令发送给Daemon API的可执行文件。

大部分时间你都只会跟Docker CLI 交互,你不会看到Docker daemon。

那么为什么要有客户端和服务器?为什么不用一个文件?

这都是为了灵活性

当你运行Docker for Windows时,Docker CLI连接的是本地的Docker daemon。
9.png

但是有时候你本地没有daemon

可能你需要在一台远端的机器上构建Docker容器。

可能你没有Hyper-V环境,你的Docker daemon是安装到VirtualBox里面的VM中的。

特别是你正在运行minikube。

你的Docker CLI会连接到远程的部署在minikube虚拟机里面的Docker Daemon上。
10.png

当你的容器运行在远程的Docker daemon上的时候,你需要调整端口绑定。

在Docker for Windows,你可以将容器端口绑定到8080:
docker run -ti -p 8080:80 nginx

注意:容器本身暴露的是80,你把它映射到了8080。

然后你可以访问http://localhost:8080然后看见Nginx的欢迎页面。

如果你在远程的Docker daemon上运行此命令然后访问这个URL时,你会发现什么也没有,URL不可达。

所以有什么不同?

Docker deamon负责运行容器和端口转发。

Docker for Windows的daemon是在本地运行的——你自己的本机

所以你可以访问本机上的容器。

Minikube则不同,它的Docker daemon是运行在VM里面的。

它是远程的deamon。


如果你想要看见你运行的容器你需要访问Docker daemon所在的机器。 你可以用以下命令找到IP:
minikube ip

你可以通过http://your_minikube_ip:8080来访问,看到Nignx的欢迎页面。
# 测试你的Docker安装
你已经安装好了Docker,那你如何知道它是否工作正常呢?

进入到终端,输入:
docker run -ti -p 8080:80 wordpress

一旦Docker下载完所有的包,你可以通过http://localhost:8080来访问。

注意:如果你在使用远程的minikube上的Docker daemon时,你应该使用http://your_minikube_ip:8080来访问。

你应该可以看到Wordpress的安装向导了。

万岁!恭喜你!

Wordress就在一个容器里面对外服务了。

注意:你还不能完成那个Wordpress的安装因为你还有数据库。
# 测试你的Kubernetes集群安装
是时候测试你的本地的Kubernetes集群了。在这一部分,你将会部署Smashing.io面板
11.png

## 部署Smashing到Kubernetes里面
你可以用如下命令部署:
kubectl run smashing --image=/visibilityspots/smashing --port=3030

一旦Kubernetes完成了容器的安装,你可以查看运行状态:
kubectl get pods

## 暴露面板
你可以将你部署的服务器暴露出来:
kubectl expose deployment smashing --type=NodePort

你可以通过浏览器打开面板:
minikube service smashing

这样你就可以从Kubernetes里面访问面板了! 万岁!
# 鸟瞰Kubernetes
Minikube本身自带了一些好东西。

你可以访问官方自带的面板
minikube dashboard

12.png

从这里,你可以查看你的集群详细信息和部署应用。
# 总结
现在你已经了解了在Windows上安装Docker和Kubernetes的所有选项。

如果你遇到了文章没提到的错误,请通过@learnk8s或者slack告诉我们。

接下来,你可以在你的环境里面部署更多应用了。请看文档

原文链接:Get started with Docker and Kubernetes on Windows 10(翻译:姚洪)

Docker公司新发布的多云战略,能让他在B端扳回一局吗?

大卫 发表了文章 • 0 个评论 • 1303 次浏览 • 2018-06-19 08:17 • 来自相关话题

在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。 ...查看全部
在最近召开的DockerCon大会上,Docker公司公布计划,旨在推动其企业容器管理平台对多云环境下部署的应用程序进行管理。该公司还强调了自家方案与Windows容器的集成能力,包括实现微软Windows Server与Linux操作系统间的互操作性。

Docker公司推出的Docker企业版是一款用于管理容器化应用程序的商业产品,可帮助企业客户将部署在内部、云环境以及托管Kubernetes当中的应用程序联合起来。目前的主流云托管Kubernetes方案包括Azure Kubernetes Service(简称AKS)、AWS Elastic Conatiner Service for Kubernetes(简称EKS)以及谷歌Kubernetes引擎(简称GKE)。

根据Docker公司的介绍,Docker企业版是目前惟一能够通过安全供应链提供联合应用程序管理功能的容器平台。利用Docker企业版,客户可以任意选择Linux发行版或Windows Server、将其运行在虚拟机或者裸机之上,运行传统或微服务应用程序并配合Swarm或者Kubernetes编排工具,同时灵活选择用于运行容器化工作负载的云平台。

Docker企业版中提供的联合控制平台还能够进一步提升应用程序的可用性。部署在某一位置的应用程序将自动跨越多个集群进行复制。当主集群不可用时,Docker企业版会将流量以透明方式路由至另一正常集群处。除此之外,客户还能够利用Docker企业版无缝跨越不同开发、分段及生产环境以管理应用程序。

自决定对接Kubernetes以来,Docker公司一直努力寻找新的独特竞争优势。通过应用程序管理联合,Docker公司希望填补现有Kubernetes产品当中存在的空白。然而,这项功能并非Docker企业版独家所有。

事实上,Kubernetes社区一直在努力以对支持不同环境的运行集群进行联合。上游Kubernetes发布一套更为稳定且流畅的集群联合方案已经只是时间问题。因此,Docker公司不得不利用其企业平台正面对抗其它基于Kubernetes的产品。

Docker公司正与微软方面密切合作,旨在将Kuberntes与Windows容器相集成。微软已经通过Docker API与CLI公布原生Windows容器。Docker与微软目前亦着手将Windows工作负载运行在由Kubernetes与Docker企业版结合而来的平台之上。这意味着企业客户将能够选择Swarm或者Kubernetes部署自己的Windows与.NET应用程序,且确保其与Linux应用程序产行运作。

微软公司正在积极推动Windows成为Kubernetes世界中的一等公民。Azure Kubernetes Service作为由微软推出的云托管Kubernetes方案,目前已经能够支持Windows容器。客户现在可以注册以体验该功能的技术预览版本。

微软公司的目标是在Azure Stack私有云平台上实现Azure服务。最终,AKS也将正式登陆Azure Stack,并为Windows Server提供原生容器编排支持。当这一切成为现实后,市场态势将转变为Docker企业版与AKS on Azure Stack的对决。

Docker公司亦面对着来自红帽及Pivotal等专门面向企业客户的供应商的竞争压力。来自红帽的OpenShift容器平台与来自Pivotal的Pivotal容器服务(简称PKS)都直接将矛头指向Docker企业版。此外,AKS、EKS以及GKE等公有云托管型Kubernetes产品同样发展迅速。很明显,Docker公司必须建立自己的差异化优势才有机会力压其它各大Kubernetes供应商。

那么,将应用程序与Windows容器联合起来是否有助于该公司获取市场份额?我觉得Docker企业版的主旨并不在于此。事实上,Docker公司的核心任务在于推动创新,从而为其企业平台创造引人注目的价值主张。

容器生态系统已经变得非常拥挤。从主流平台厂商——例如红帽与微软,到早期初创企业,每个人都想在其中分一杯羹。而对Docker公司来说,赢取企业市场份额无疑将是一场艰苦的斗争。

原文链接:Will Multi-Cloud Strategy Help Docker Inc. Win The Enterprise?

LCOW —— 单一Docker引擎下可同时运行Linux和Windows容器啦!

tiny2017 发表了文章 • 0 个评论 • 4970 次浏览 • 2018-01-26 13:19 • 来自相关话题

【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。 ...查看全部
【编者的话】本文来自微软的技术专家Stefan Scherer,主要介绍了LCOW这一新功能将给Windows 10带来哪些变化,这对基于Windows 10的开发、调试都意义非凡。本文作者还结合具体的实例,为我们演示了这一系列变化带来的诸多便利。

就在上周,Docker官方的master分支上新增了LCOW(Linux Containers on Windows)功能。启用这项功能,即可在单一的Docker引擎下,同时运行Linux和Windows容器。

下面赶紧跟小编一起,看看Windows 10将会发生哪些变化?
lcow-marked.jpg


  • 可以用Docker命令`docker ps`,列出所有正在运行的Linux或Windows容器。
  • 在容器和主机之间通过存储卷共享数据。
  • 容器之间可以通过容器网络互相通信。
  • 通过将端口映射到主机,实现本地访问。但目前,它还只是Windows 10 1803版预览体验计划(Windows Insider)的一项功能。

#运行Linux容器

现在,你需要指定`--platform`来拉取Linux镜像。如果拉取的是一个既有Linux又有Windows的多重架构的镜像,同样需要指定该选项。
docker pull --platform linux alpine

镜像拉取完毕即可运行,无需指定`--platform`选项。
docker run alpine uname -a

另外,Windows上运行Linux容器需要一台小型的Hyper-V虚拟机。同时,LinuxKit项目提供了LCOW的镜像,请参照:https://github.com/linuxkit/lcow
#共享存储

接下来我们看一下,如何用一种简单的方式,实现不同平台容器间的数据共享。

方法是把Linux和Windows容器,绑定到同一个存储卷。

下面的例子中,Linux和Windows容器通过主机的一个共享文件夹,实现数据共享。
2.gif

首先,在Windows 10 上新建一个文件夹。
cd \
mkdir host

##启动Linux容器

在Windows 10主机上启动一个Linux容器,并且将主机上的共享文件夹挂载到该容器的`/test`文件夹。
docker run -it -v C:\host:\test alpine sh

我们在`/test`文件夹下,新建一个名为hello-from-linux.txt的文件。
uname -a > test/hello-from-linux.txt

##启动Windows容器

在Windows 10主机上启动一个Windows容器,并且将主机上的共享文件夹挂载到该容器的`C:\test`文件夹。
docker run -i -v C:\host:C:\test microsoft/nanoserver:1709 cmd

我们在`C:\test`文件夹下,新建一个名为hello-from-windows.txt的文件。
ver > test\hello-from-windows.txt

##测试结果

上述两个容器中新建的文件,都保存在Windows 10 主机的共享文件夹。
PS C:\> dir host


Directory: C:\host


Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 1/21/2018 4:32 AM 85 hello-from-linux.txt
-a---- 1/21/2018 4:33 AM 46 hello-from-windows.txt

在开发过程中,如果需要共享配置文件或代码的话,这实在是太方便了有木有~
#混合编排

值得一提的是,使用Docker Compose还可混合编排容器。下面是一个混合编排Linux和Window web服务器的例子。
    version: "3.2"

services:

web1:
image: nginx
volumes:
- type: bind
source: C:\host
target: /test
ports:
- 80:80

web2:
image: stefanscherer/hello-dresden:0.0.3-windows-1709
volumes:
- type: bind
source: C:\host
target: C:\test
ports:
- 81:3000

networks:
default:
external:
name: nat

你也可以思考一下,如何编排一个Linux数据库和Windows前端,反过来也一样。
#如何搭建你的LCOW测试环境

如果你想试着玩一下LCOW,建议使用Windows 10 1709虚拟机。
##Azure

我在微软Azure上用Windows 10 1709虚拟机测试过LCOW。你可以选择具有嵌套式hypervisor的V3 机器以便运行Hyper-V容器。
##容器和Hyper-V

首先,启用容器和Hyper-V功能:
Enable-WindowsOptionalFeature -Online -FeatureName containers -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart

##LinuxKit

然后,为你的LCOW安装一个LinuxKit镜像。下面是我下载的最新版LinuxKit,你也可以自行从linuxkit/lcow下载。
Invoke-WebRequest -OutFile "$env:TEMP\linuxkit-lcow.zip" "https://23-111085629-gh.circle-artifacts.com/0/release.zip"
Expand-Archive -Path "$env:TEMP\linuxkit-lcow.zip" -DestinationPath "$env:ProgramFiles\Linux Containers" -Force

##创建Docker

现在,你可以下载并安装Docker引擎了。
Invoke-WebRequest -OutFile "$env:TEMP\docker-master.zip" "https://master.dockerproject.com/windows/x86_64/docker.zip"
Expand-Archive -Path "$env:TEMP\docker-master.zip" -DestinationPath $env:ProgramFiles -Force

接下来,安装Docker service并打开实验功能。
 . $env:ProgramFiles\docker\dockerd.exe --register-service --experimental

紧接着,配置PATH以便使用Docker CLI。
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";$($env:ProgramFiles)\docker", [EnvironmentVariableTarget]::Machine)

恭喜你!现在可以重启机器了。重启过程中会自动更新容器和Hyper-V的配置。如果一切顺利,重启完后Docker engine应该已经起来并处于运行状态了,这时你可以在PowerShell终端使用Docker CLI。
#本地的Vagrant环境

如果你的Vagrant安装了Hyper-V或VMware,那就更方便了。只需几个命令,就可轻松搭建本地测试环境。

你只需要从我的GitHub下载包含LCOW环境的docker-windows-box,执行以下命令就可以了。
git clone https://github.com/StefanScherer/docker-windows-box
cd docker-windows-box
cd lcow
vagrant up

如果你的Windows 10虚拟机上没有Vagrant base box,系统会自动下载安装。如果已经下载了,则只进行安装。
#总结

未来几个月,随着这些Docker新功能加入到Windows,Windows 10无疑将成为2018年最具吸引力的开发者平台。

想象一下,你用`docker-compose.yml`编排Linux和Windows容器,通过Visual Studio Code实时调试你的应用程序,等等。

如果您喜欢这篇文章,请分享给您的朋友。如果想了解Windows容器的最新情况,请关注原文作者的推特@stefscherer

原文链接:A sneak peek at LCOW (翻译:Tiny Guo)

Windows Server 1709:以容器为中心,向DevOps画圆

ds_sky2008 发表了文章 • 0 个评论 • 2853 次浏览 • 2017-11-05 16:58 • 来自相关话题

【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。 大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是 ...查看全部
【编者的话】微软正在改变的不仅是如何交付Windows服务器,而且正从服务器角色来思考如何改变。

大家都知道,今年早些时候,Windows Server的第一个半年度版本终于发布了。Windows Server 1709发行版的核心是对Windows Server服务器的核心版本做了重大更新,其中包括企业版和数据中心版的新版本。新的Windows Server支持基于DevOps的组织并增强对容器和云部署的支持。

但是为了“尝鲜”新版本的好处,你将不得不放弃Windows Server UI,转而使用命令行(特别是通过PowerShell)和远程用户界面(如熟悉的RSAT和基于浏览器的新项目火奴鲁鲁Honolulu)来管理服务器。

下载InfoWorld Deep Dive:[基于Windows,Windows Server和Exchange 的PowerShell使用指南。]

千万别太惊讶:其实微软已经离开服务器GUI有一段时间了,而且其命令行工具在使用脚本进行远程管理多个服务器方面具有显著的优势。混合使用PowerShell和火奴鲁鲁(Honolulu)不会使管理变得更加困难,这将使Windows Server与各种基于Unix的竞争对手站在同一起跑线。它还将为微软提供一个新的管理基准,在这个基准上添加对容器的支持以及其他与服务器操作系统一起工作的新方法。

要安装Windows Server 1709,你必须进行全新安装(clean install),因为它会将你移至新的、每年两次的新版本发布频道。通过强制全新安装,Microsoft正在试图清楚地表明,你正在逐渐从Windows Server 2016的长期支持的5 + 5支持模式转向一个每年两次的新版本和18个月的支持模式。
# Windows Server 1709中的新容器功能
微软显然更钟情于正在使用Windows Server 1709的应用程序和容器开发人员。新的容器基础镜像包括服务器核心和纳米服务器;服务器核心,用于现有应用程序的“提升和移位”方案,以及用于基于.Net Core或Node.js的新应用程序的Nano Server。容器基础镜像也显著缩小 - 服务器核心镜像减少60%,纳米服务器减少80% - 使得在这些镜像之上部署新容器的速度更快。

“提升和移位”选项是一个有趣的选择,因为它可以让你用最少的工作容器化现有的代码。当然,构建应用程序在容器中运行的架构问题,例如确保所有的应用程序数据都存储在容器之外,所以你必须做一些改进。但在实践中,进行适当的更改不应太困难 - 特别是在使用Windows Server或Azure的存储工具和API时。
# Windows Server的新计划符合DevOps的思路
每六个月发布一次新的Windows Server将不会满足每个人的口味(实在是众口难调)。虽然你可以跳过一个版本(例如,从1709跳到1809,忽略1803),但这并不会改变Windows Server将会每个版本只有18个月的支持而定期进行重大更新的事实。Windows Server新的节奏可能最适合那些已经转移到devops驱动流程的组织,在这个流程中,应用程序驱动整个策略。

DevOps的方法当然是与云优先发展一致的。一段时间以来,Windows Server需要与Linux的快速开发进度竞争,尤其是在使用容器镜像的情况下。这是捆绑的Nano服务器在Windows Server 1709中重新思考的主要原因; 支持基础架构角色的容器主机没有任何意义,特别是当主操作系统构建也变得更轻量级时。

尽管如此,微软对Windows Server的更改对于三年或五年发行版的系统管理员来说也是一个挑战。对他们来说,还有一个长期服务通道(LTSC),它将继续像Windows Server一样被发布。

你甚至可以在你的数据中心混合使用Windows Server版本,使用旧版应用程序的LTSC和Windows Server 1709,以及将来的新版本和云使用版本。尽管Windows Server 1709和更高版本包含基础架构角色,但你应该使用这些每年两次的版本来发布虚拟机中的应用程序托管以及容器基础镜像。为VM主机,存储和Active Directory继续使用Windows Server LTSC基础架构服务器是有意义的。服务器部署的混合方法很有意义,因为毕竟,基础架构服务器在部署后不应更改,除了获取安全更新之外。

如果我们将基础设施操作从DevOps中分离出来,这个分离模型更有意义。在DevOps领域,基本操作系统的相对迅速的变化不是问题,因为它们只是持续集成管道的另一个要素,还有代码和其他软件定义的基础架构。

旧的贝塔系统和社区预览已是昨日黄花。一些选定的客户仍然可以访问TAP构建,但其他人都应该加入Windows Insider计划,以迎合未来的变化。在新的每年两次的更新节奏中,参与Windows Insider程序比以往任何时候都更加重要,因为Windows Server的新计划将要求在每个新版本部署之前通过快速测试来验证应用程序。

即便如此,测试不应该是繁重的。毕竟,每隔两年一次的增量版本和大爆炸产品每隔几年就会有天壤之别。由于每台Windows Server新版本的新功能要少得多,所以它们对现有应用程序的影响很小。

原文链接:Windows Server 1709: Container-focused, devops-oriented(翻译:ds_sky2008)

不得不知的容器生态圈发展趋势

Rancher 发表了文章 • 1 个评论 • 2399 次浏览 • 2017-05-08 11:57 • 来自相关话题

Docker于 2013年推出以来,给软件开发带来了极具传染性的振奋和创新,并获得了来自各个行业、各个领域的巨大的支持——从大企业到初创公司,从研发到各类IT人员,还有开源社区、ISV、最大的公共云供应商、软件堆栈上的每个工具等。自Docker推出以来,许多重 ...查看全部
Docker于 2013年推出以来,给软件开发带来了极具传染性的振奋和创新,并获得了来自各个行业、各个领域的巨大的支持——从大企业到初创公司,从研发到各类IT人员,还有开源社区、ISV、最大的公共云供应商、软件堆栈上的每个工具等。自Docker推出以来,许多重大的里程碑事件都推动了容器革命。让我们就其中一些作个简要回顾。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
容器编排工具的选择

容器入门非常简单。所需要的仅是笔记本电脑和Docker客户端。然而,运行微服务应用程序则要另当别论。其中最困难的是创建、管理和自动化临时容器集群。

解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon。即使在Docker之前就已经提供了分布式基础设施,Marathon也可以在Twitter和其他大型Web应用程序中的生产工作负载中使用。

下一个得到广泛认同的编排工具是Kubernetes。事实上,如今Kubernetes因为它的可扩展性已经领先于Docker编排工具。它支持广泛的编程语言、基础设施选项,并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来,从而能够跨多个云供应商和基础设施设置,实现真正的可移植性。

Docker Swarm随后也加入了容器编排领域,并且其覆盖率已经迎头赶上。Swarm很容易上手,并且能与Docker平台的其他部分很好地集成。初步迹象表明,这一竞争已经改变了Kubernetes。

对企业而言,编排工具是容器应用成功的关键。尽管这三个选择都不差,但您应该根据您的需求做出最合适的选择。

容器安全快速发展

在初期,容器默认的隔离性较弱。随着时间的推移,这一情况正在发生变化。与容器安全相关的一个关键进展,是出现了多个能力强大的容器 registry。registry通过存储和扫描容器镜像和存储库来发现漏洞。这是Docker安全性的重要组成部分,因为未经验证的发布商提供的公开存储库,极容易带来安全威胁。这也是开放的生态系统的缺点之一,因为在开放的生态系统中,镜像很容易共享。但使用 registry进行安全检查可以减少这种风险。

Docker Hub是大多数Docker用户开始使用的默认registry,也是目前最流行的。主要的IaaS提供商都有自己的registry。这很有必要,尤其是如果您大量投资AWS、Azure或Google Cloud。它们具有默认的存储库扫描功能、更成熟的访问控制,以及一系列用于联网、存储和监视的其他工具。除此之外,像Quay和GitLab容器 registry这样的第三方 registry也越来越受欢迎。registry的选择比编排工具多得多,市场也很开放。

除了 registry之外,TwistLock和Aqua security等第三方容器安全服务商也提供了超出默认值的安全性。

适用于Windows和Mac的原生Docker客户端

Docker最初是一种基于Linux的技术,它依赖于Linux内核中内置的特殊功能(这些功能只能在Linux上可用,而非其他类似Unix的内核)。如果要在Windows或Mac上运行Docker,则必须使用虚拟机引擎(如VirtualBox)和基于Linux的虚拟机来托管Docker环境。对于那些想在Windows或Mac机器上测试Docker应用程序的开发人员来说,这个设置非常方便,但作为Docker服务器部署解决方案却不实用。

2016年初,随着原生Docker对Windows的支持,情况发生了变化。这是一项重大进展,因为许多企业工作负载在Windows Server上运行。在这些环境中使用Docker的需求很强劲。

目前, Docker在Windows上本机运行时,仍存在一定局限性。网络尚未完全实现,仅支持Windows Server 2016和Windows 10。但是,Docker已经支持原生Windows,这一进展已经为Windows生态系统中的Docker提供了大量的新机遇。

内置VS开源Docker组件

Docker公司已经建立了企业版(包括Docker Datacenter,它现在已经集成到Docker的新企业版平台中),它们由Docker本身的组件组成,其中包括Swarm管理器,而Docker Engine并未内置这些组件。Docker对使用自己的工具来建造容器堆栈更感兴趣,而不是与容器生态系统中的其他组织合作,最初引起了一些人的担忧,即Docker将忽略社区标准。去年八月份,出于这方面的担忧,他们甚至还谈到了forking Docker。(不过至今并没有谁真的fork了Docker。)

最近,随着Docker采取措施向客户保证它不会垄断行业,这种紧张局势已经平息。它对CNCF的积极贡献,包括最近将底层的容器技术开源,都是朝这个方向发展的。在上个月的DockerCon大会上,该公司通过将代码转移到Moby项目,并引入LinuxKit,从而使它的主要项目更模块化,更便于社区访问。(这里分析了这些变更对Rancher Labs、Rancher产品以及各种各样用户的影响)

当然,Docker仍然有批评者。但相比一年前,Docker技术栈明显更加开放,并能与其他生态系统更好地集成。

结论

容器生态系统仍然在不断发展与改变。也许当我们刚弄清楚Docker对于跨所有类型组织的应用程序意味着什么时,新的标准又出现了。本文所强调的趋势是一个快速成熟的生态系统的指标。最值得关注的,是在这一领域中,Docker和各个供应商是如何进步,以推动容器生态系统的发展的。

原文来源:Rancher Labs

Docker for 开发:容器化你的应用

gaohongtao 发表了文章 • 0 个评论 • 9959 次浏览 • 2017-04-11 11:01 • 来自相关话题

【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。 【3 天烧脑式容器存储网络训练 ...查看全部
【编者的话】这篇文章以极简的模式快速搭建一套使用与开发的Docker环境,特别面向了开发中常用的Mac和Windows环境。虽然本文模糊了大量的实现细节,但可作为在开发平台搭建Docker环境有力范本。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

作为开发者,我们总是寻找一个捷径或更容易的方法来快速起步,对吧?如果你是团队领导,付出最少的代价让团队站在同一个起点是很重要的。 Docker可以提供帮助。

在软件开发领域,一直越来越强调模块化,从单一责任的一般原则到更具体的实现,例如将JavaScript功能模块化为无状态组件。在这里,我将告诉你我们如何使用Docker来模块化我们的开发环境,以获得许多类似的好处,包括帮助我们快速起步。
# Docker 4 开发者
如你所知,为了加快项目进度,你有一个待办事项清单:

- 拉取代码基线
- 安装外部工具,如数据库、缓存和一些额外的工具和服务
- 给外部工具打补丁和升级
- 配置数据库和服务以使他们可以通信
- 开始祈祷(可能需要好几次)
- 调试问题(至少要30几次)

想象一下,如果在将应用程序的代码基线拉出存储库之后,您只需运行几个命令行(可能只有一个),可以使整个应用程序的环境准备就绪。听起来很酷,对吧?

这正是我们要完成的。不同于使用一个百科全书式的方法来使用Docker的所有功能和命令,我将介绍容器化开发人员的环境的主要的Docker功能。

这篇文章是关于利用Docker的容器化能力的一系列文章中的第一篇,它很容易构建一个可以在任何时间共享和运行的应用程序开发环境。
## Docker Toolbox 对 Docker for X
Docker Toolbox是可用于处理多个Docker资源的原始工具集合,并且会根据您选择的操作系统而有所不同。但在那之后,他们发布了新的Windows和Mac原生应用程序。因此,除了Linux、OS X和Windows Docker Toolbox变体之外,您还将看到“Doc​​ker for Mac”和“Docker for Windows”。

要理解和决定应该使用哪种工具,我想概述使用新的原生应用程序的前提。原来的Docker Toolbox将会设置一些工具以及使用VirtualBox。它还将提供在Linux Hypervisor上运行的虚拟机,用于Windows或Mac。
## VirtualBox、Hyper-V和Hyperkit,我的上帝啊!
原生应用程序,例如在Docker for Mac中,实际安装的是OS X原生应用程序。它也不再使用VirtualBox,而是使用OS X的hypervisor hyperkit。此外,共享接口和网络的管理更简单。还有一些用户体验更新以便于Docker更好的工作。在Docker for Windows原生应用程序中也会包含这些相同的更改,但是会使用Hyper-V作为hypervisor,以及其他类似的网络和工具更新的主机。

最后,原生应用的体验应该是一个更积极,更有效率的,而且更少的出错。但是,您会发现绝大多数与Toolbox相关的外部文档 - 因此了解Toolbox将是你的优势。
# 开始吧
这个初始教程将简单地使用一个开箱即用的express.js应用程序。当我们开始编辑源代码并在容器之间进行通信时,我将介绍一个运行Webpack的开发服务器的进阶的通用React.js应用程序,其中包含热模块重新加载,MongoDB数据库等。
# 步骤 1:安装
为了努力获得使用Docker并将开发人员环境与各种操作系统版本一起集中化的好处,我将让您选择需要下载的Docker版本(Toolbox或原生)和操作系统:

- Toolbox:https://www.docker.com/products/docker-toolbox (OS X and Windows)
- Docker for Windows:https://www.docker.com/products/docker#/windows
- Docker for Mac:https://www.docker.com/products/docker#/mac

TOOLBOX用户:Docker Toolbox配有“Docker快速入门终端”,并在运行时与Docker环境相关联。但是,通常在您选择的IDE中运行终端或独立运行终端。为了让Docker与另一个终端/提示进行交互,您需要通过运行“docker-machine env”来初始化Docker env。文本显示的末尾是一个命令,您需要从该同一终端中复制该命令以初始化Docker环境。



#步骤 2:源码/环境
下一步是获取要容器化的开发应用程序的源代码。

现在,您可以从GitHub抓取这个项目,这个项目保存了本教程的一些步骤。
# 步骤 3:创建Docker镜像文件
请记住,主要目标是在隔离和模块化的环境中运行我们的应用程序。为了让Docker创建这个环境,我们必须告诉它如何创建它。我们使用包含一组指令的Docker镜像文件

  1. 使用你的IDE,增加一个文件到工程根目录并命名为“Dockerfile”
  2. 拷贝下面的文件内容到这个文件

重要信息:该Docker镜像文件将允许我们创建一个镜像,该镜像将代表我们一直在讨论的容器化环境,并最终创建称为容器的该镜像的运行实例。但是,我们向前跳了一步,这些内容应该在第5步中。



##Dockerfile
FROM mhart/alpine-node:6.9.2
WORKDIR /var/app
COPY . /var/app
RUN npm install --production
EXPOSE 3000
ENV NODE_ENV=production
CMD ["node", "bin/www”]

Dockerfile是Docker在镜像文件中寻找的默认名称,但它可以是任何名称,我们将在稍后的步骤中看到。这些指令告诉Docker我们要创建一个镜像:

- 从一个基础的mhart/alpine-node镜像的6.9.2标签开始创建
- 设置应用程序初始运行的工作目录WORKDIR
- 拷贝当前本地目录“."中的内容到工作目录
- 然后从工作目录运行RUN命令npm install —production”
- 我们将对外暴露 EXPOSE3000端口从容器中,当它从镜像中被创建的时候
- 另外我们想要对容器设置本地环境变量ENV NODE_ENV的值为“production”
- 最后,我们启动express.js服务,它驻留在bin目录中的“www”文件中,执行命令“node bin/www”

提示:Docker总是需要一个基本的镜像,镜像保持尽可能小空间占用是关键。alpine-node镜像是非常小的(49.65mb),包括Node.js和NPM。



#步骤 4:构建一个镜像
现在我们有一个Docker镜像文件,它指定了有关如何创建镜像的详细信息,让我们停下来谈谈镜像是什么:
01.png

镜像是只读分层文件系统。它构成了我们不断追求的环境的基本文件系统。我们在上一步中创建的镜像文件将指示Docker如何去创建镜像的每层。

但如果它是一个只读的文件系统,我们如何去写它,(例如,执行代码的变化对我们的应用程序的代码在开发过程中)?好问题,我会在即将到来的步骤中回答。
## 步骤 4a:构建生产镜像

  1. 从一个终端中导航到项目根目录
  2. 运行命令(包含动图最后的命令)

docker build -t express-prod-i .

02.gif


提示:对于Docker Toolbox,从Docker Quickstart Terminal开始运行Docker命令会导致错误(根据操作系统而异)。为了从任何随机终端/提示符运行命令,您需要将终端/提示链接到docker环境。运行docker-machine env,并运行它提示的命令,例如“@FOR / f”tokens = *“%i IN('docker-machine env')DO @%i”



##我们做了什么?

  1. 我们运行build命令从我们在步骤3中创建的Docker镜像文件创建一个文件
  2. 使用标签开关-t,我们给镜像一个名称,我们可以使用它来引用它,而不必引用Docker生成的ID(例如50e8dde7e180)
  3. 我们指定了使用“.”指定的当前本地目录的镜像路径

## 步骤 4b:验证镜像
如果所有都按计划进行,我们应该看到(如.gif中的)一个“successful build ...”消息。我们现在可以运行一个命令来记住你的镜像:
docker images

03.png

在这种情况下,我们的组合镜像大小为61.26 MB,这是基本的alpine-node镜像和我们的express应用层的组合。
##步骤 4c:观察镜像文件层
如果我们想要看到为我们的镜像创建的文件层,我们可以运行命令:
docker history express-prod-i

04.png

# 步骤 5:运行镜像实例
既然我们已经创建了一个镜像,我们已经准备好创建一个隔离的,模块化的应用环境。正如我已经提到了很多次那样,那个环境是一个Docker容器。Docker容器实际上是镜像的运行实例。

在概念上,一个镜像和容器非常类似于我们如何想到一个JavaScript Prototype或一个OOP类。所以,我们来运行一个我们创建的镜像的实例。
##步骤 5a:生成并运行一个镜像实例

  1. 运行命令:

docker run -d --name express-prod-app -p 7000:3000 express-prod-i


  1. 登录浏览器访问http://localhost:7000。
05.png


## 我们做了什么?
我们创建并运行了一个express-prod-i镜像的实例而作为一个容器:

- 使用RUN命令
- 指定分离模式-d标志(所以我们不绑定当前终端/提示符)
- 并使用-name标志给我们的容器设置名字“express-prod-app”
- 将主机7000上的本地端口映射到使用-p标志显示的3000的内部容器端口
- 最后,指定我们要生成并运行我们的实例的“express-prod-i”镜像

注意:我使用不同的本地端口7000来向您展示您可以将主机上的任何未使用的端口映射到容器中暴露的内部端口。



提示:没有-d,我们将以贴合模式启动运行容器。这意味着它将从容器中直接输出到我们运行命令的终端/提示符。通过在分离模式下启动容器,我们可以继续从终端/提示符运行容器工作。



##顿悟#1
你明白了吗?我们不必在本地安装Node.js或NPM。我们没有必要运行npm安装本地使用的应用程序,我们没有从主机运行应用程序。所有这些都在主机内部发生,这是一个简单的express.js演示网站。
##步骤 5b:验证运行容器

  1. 我们可以使用这个命令观察运行时容器

docker ps

06.png


  1. 这将显示我们运行容器。我们还可以指定-a标志来查看所有容器。当事情出错时,可能会有用,我们想看看一个号称已经运行容器是否意外退出:

docker ps -a


#步骤 6:停止并启动容器

停止一个运行时容器是非常简单的...或许你已经猜到了:

docker stop express-prod-app


然后启动它

docker start express-prod-app

#步骤 7:删除镜像和容器
当我们浏览这些教程时,可以删除镜像或容器并重新开始。以下是步骤。另外,在“奖励”部分,还有一些有用的捷径:
## 步骤 7a:删除容器
删除一个容器,我们可以使用“rm”命令:
docker rm express-prod-app

让容器恢复回来,我们可以使用先前使用过的命令:
docker run -d --name express-prod-app -p 7000:3000 express-prod-i

## 步骤 7b:删除镜像
删除一个镜像,我们可以使用“rmi”命令:
docker rmi express-prod-i

让镜像恢复回来,我们可以使用先前使用过的命令:
docker build -t express-prod-i .


提示:删除镜像和容器命令可以使用镜像或容器ID,甚至可以使用ID的前几个字符。所以你可以任意选择。 (您还会看到我们在奖励部分中这样做。)



# 奖励
补充一些删除镜像和容器的其他手段,你可以使用一些我已经在用的有效的快捷方法。
## 删除所有容器
要删除所有容器,运行下面的“rm”命令,这条命令内部会返回所有的容器:
docker rm $(docker ps -a -q)

Windows用户:你需要是一个bash环境去运行这些命令。主要是因为只有GNU才能使用$()变量引用。你可以安装诸如“Bash on Ubuntu on Windows”甚至于 GIT bash。只要记得你需要运行docker-machine env来链接你的终端,并且运行显示在最后的eval命令。
## 我们做了什么?

  1. 我们想container提交了删除命令“rm”
  2. 但是我们提交的是一个容器ID的列表,而不是提供容器标签或是container ID
  3. 提供所有(-a)参数并组合静默(-q)将会返回数字类型的容器ID

## 删除所有镜像
删除所有的镜像我们可以类似于上面的做法,使用删除镜像命令“rmi”
docker rmi $(docker images -q)

## 我们做了什么?

  1. 这里我们使用了删除镜像命令但是入参是一个docker镜像ID列表……
  2. ……使用列出docker镜像的命令
  3. 并且设置静默(-q)参数,这样返回了数字型的Docker ID

## 这可以应用到生产吗?还是只是应用开发环境?
很明显能主要到我们刚刚创建的镜像通知Express.js和Node.js在生产环境中运行。那这是什么鬼?

记住我们是要为任何镜像制作基本镜像,并且谁会在开发环境中为每次修改而“重建”镜像呢?所以我们需要使用生产镜像来作为基本镜像构建我们的开发环境并且隔离开发修改到分层镜像中的开发层中。
# 总结
所以,我已经屏蔽了一大堆关于Docker的知识。创建镜像文件,构建镜像并生成该镜像的正在运行的容器。但是我们还有很多事情要去做。

因此,在本系列的下一篇文章中,我将针对我们的开发版本或应用程序创建一个镜像,但是基于我们的生产镜像。我们还将介绍如何利用容器中的脚本来帮助设置本地环境来更改源代码。

原文链接: Docker for Devs: Containerizing Your Application(翻译:高洪涛)

===========================================
译者介绍
高洪涛,当当网架构师,开源数据库分库分表中间件Sharding-JDBC作者。目前从事Docker,Mesos相关工作

Rancher v1.3发布:Windows Container来了!

Rancher 发表了文章 • 1 个评论 • 1869 次浏览 • 2017-01-16 09:42 • 来自相关话题

2016年12月初,当我们发布Rancher v1.2时,就定下了未来「更频繁的迭代」的计划。就在上周,Rancher v1.3正式发布啦!除了对v1.2中一些bug的修复之外,它还有几个新的功能:1)用户界面修复;2)DNS引擎的更改;3)Kubernete ...查看全部
2016年12月初,当我们发布Rancher v1.2时,就定下了未来「更频繁的迭代」的计划。就在上周,Rancher v1.3正式发布啦!除了对v1.2中一些bug的修复之外,它还有几个新的功能:1)用户界面修复;2)DNS引擎的更改;3)Kubernetes及其相关工具的改进。

最重要的是,在Rancher v1.3中,我们开始解决从用户那里收到的一个频繁请求:对Windows 2016的支持!

Rancher v1.3中对Windows的支持仍是实验性质的,范围有限,但它是Rancher Labs向服务客户的需求迈出的重要一步。容器越来越在企业中被广泛采用,而在世界范围内,极大一部分的工作负载是运行在Windows服务器和客户端系统上的。并且,在可预见的未来之中,这一情况并不会改变。

Rancher Labs的目标,就是要让应用程序真正地达到云和基础设施之间的可移植化,而使工作负载运行于Windows容器之上,是Rancher Labs的愿景的一个关键部分。

Windows in Rancher教程

要在Rancher中部署Windows,首先需要创建一个新的环境,其中的环境模版里需要将容器编排设置为Windows。

目前,Rancher仅支持在特定主机上创建容器。一些可能出现在UI中的Cattle里的功能,如服务发现、健康检查、元数据、DNS和负载均衡器,在现阶段尚不支持。


注意:Rancher已为你提供了一个可用的默认的Windows环境模板。但如果你创建你自己的 Windows环境模板,你需要禁用所有其他基础架构服务,因为它们当前与Windows不兼容。



#创建Windows环境

在环境的下拉列表中,单击“Manage Environment(管理环境)”。要创建新环境,请单击“Add Environment(添加环境)”,提供名称、说明(可选),然后选择以Windows作为编排的环境模板。如果您开启了访问控制,您可以在此添加成员并选择其成员角色。成员列表中的任何人都可以访问您的环境。

创建Windows环境后,您需要导航到环境中去,此时你可以在位于左上角的环境下拉菜单中选择环境的名称,或在特定的环境下拉菜单中选择“Switch to this Environment(切换到此环境)”。

注意:Rancher支持多个容器编排框架,但在现阶段,若有些环境里已有服务正在运行,用户是不能切换环境的。



#添加Windows主机

若想将主机添加到Windows,您需要先安装一个运行着Windows Server 2016 with Docker的主机。

在“Infrastructure(基础架构)”选项卡中,您将获得一个自定义命令来启动Rancher代理服务。您可以按照说明在Windows中启动Rancher代理服务。

在主机上,代理二进制文件将下载到名为C:/Program Files/rancher的文件夹中,代理日志将位于C:/ProgramData/rancher/agent.log里。

#删除Windows主机

将主机添加到Rancher中时,Rancher代理是其中的一部分,它是以服务的形式被安装和注册于主机之上的。为了重新使用主机,您必须删除现有的服务。你可以在powershell中运行以下命令。删除服务后,你就可以在Windows环境中重新使用主机了。

```
&'C:\Program Files\rancher\agent.exe'-unregister-service
```

#Windows中的网络

默认情况下,我们支持NAT和透明网络

目前,默认的Windows环境模板支持名为transparent的透明网络,它是通过运行docker network create -d transparent transparent创建的。

如果要创建具有不同名称的透明网络,则需要使用Windows创建一个新的环境模板作为容器编排。选择Windows后,您可以单击“Edit Config(编辑配置)”更改透明网络的名称。默认名称为transparent。创建更新的环境模板后,您可以创建一个新环境,以支持新命名的透明网络。 UI将继续使用transparent作为默认名称,因此您需要将该命令更新为`docker network create -d transparent
更多的反馈与分享

在Rancher Labs正努力向服务客户的需求迈进时,我们无比期待收到您对这些早期努力的反馈。我们坚信,只有来自用户的更广泛的反馈,才可以让Rancher产品变得更好。

原文来源:Rancher Labs

Windows 容器对比:WinDocks vs. Microsoft

edge_dawn 发表了文章 • 0 个评论 • 3401 次浏览 • 2017-01-04 02:10 • 来自相关话题

【编者的话】介绍基于WinDocks的容器和Microsoft的容器之间的区别。 WinDocks是在Windows系统层面上的具有独立端的Docker开源应用。作为前微软工程师,我们致力于改善软件开发人员的工作,在2016年3月我们 ...查看全部
【编者的话】介绍基于WinDocks的容器和Microsoft的容器之间的区别。

WinDocks是在Windows系统层面上的具有独立端的Docker开源应用。作为前微软工程师,我们致力于改善软件开发人员的工作,在2016年3月我们开源了第一个基于Windows的Docker端。基于社区免费版我们培养了大量相关技术人员。

目前,微软发布了Windows Server 2016,并且支持Windows容器技术,那么许多人就想要详细探究WinDocks与微软的Windows容器到底在实现形式上有什么异同。以下的内容是基于微软SQL Server专业人士的公开演讲,以及对微软Windows Server 2016的容器测试。
#供开发和测试的容器
Windows容器与Linux容器带来同样的好处,因此我们希望Windows容器同样成为支持开发,测试和QA的首选基础设施。在不久的将来,容器可以引导持续集成,持续交付,DevOps的增长。

WinDocks容器提高了开发速度与效率,开发人员在一个共享的虚拟机使用隔离容器环境,每个实例化可以控制在秒级别。假设每个开发团队平均使用20个VM,应用容器技术的话,可以共用一个VM。20:1的比例缩减微软服务器许可证可以为Windocks的用户立即提高收益率(也可能不是 Mircosoft容器用户)。
#WinDocks vs. Microsoft
内置:微软的容器支持被包含在Windows Server 2016中,而且作为Windows 10专业版和企业版的附加,这就使得客户针对一个供应商提供服务支持。而对于容器本身支持则没有增加成本,他们实际上不一定是免费的。

WinDocks Windows支持:WinDocks对容器支持包括了所有版本的Windows 8、Windows 10、Windows Server 2012、Windows Server 2016,这样为开发人员提供了方便的接入。行业调查显示,客户计划逐步迁移到Windows Server 2016。这表明Windows Server 2012将继续扩大共享使用率到2020年,与Windows Server 2016同期逐渐增长。

SQL Server的支持:WinDocks的成立旨在解决开发人员所需有效的SQL服务器环境。超过80%的组织每月只测试SQL Server两次。WinDocks通过对SQL Server容器和镜像提供自动工作流的方式,来支持SQL Server 2008及以上所有版本的发布。WinDocks利用了微软成熟的DLL共享架构,使当前SQL Server通过容器发布而不变更工具或进程。

Windows Server 2016已经发布,但并没有有效的SQL Server支持。三个月后发布的SQL服务器镜像支持仍局限于SQL Server 2014 Express和SQL Server 2016 Express。其他悬而未决的问题包括缺乏支持SQL Server Management Studio 的Windows身份验证(目前仅限于SQL sa身份验证),以及缺乏IP回环的支持。简言之,微软对SQL Server的支持只能被形容为并不完善。

更大的问题还没有讨论是微软正在为未来的SQL Server容器镜像秘密计划新的SQL Server许可条款。新许可尚未透露,但考虑到减少VM来获取容器,不太可能是“免费”的。

应用程序容器vs. 微软臃肿软件:WinDocks容器通过“guards”容器和实施资源限制提供了用户和进程隔离。这个设计提供了类似于微软的安全服务器核心容器,为企业内提供了可信的工作负载。这个设计并不是为了不可信的多租户使用,这也解释了为什么微软提供hyper-v容器支持。

WinDocks应用级容器比Windows容器更加轻量级。微软容器背负重大的Windows文件,基本镜像平均> 9 GB,而WinDocks平均100 MB。微软容器需要20多额外的进程,而且比WinDocks容器额外多80 MB RAM。WinDocks .net IIS容器使用5 MB的RAM(16倍差),所以系统分级的影响是显著的。如果平均开发团队运行SQL Server和.NET,则微软容器主机需要比WinDocks服务器耗费更多的CPU和RAM!

微软这样的设计同时会导致镜像维护的增加,Windows更新迫使镜像重建(每个镜像包含大量Windows封装)。WinDocks的设计,相比之下,允许独立更新容器镜像。

镜像支持:除了支持所有SQL Server 2008及以上版本,WinDocks还支持Java及之上的Tomcat和Jetty,Nginx,node.js。正如我们已经指出的那样,微软缺乏镜像支持SQL Server发布的版本,以及Java的Tomcat服务。

其它应用程序支持:微软容器设计的一个优点是能够支持依赖注册表支持的Windows应用程序。WinDocks对SQL Server镜像的支持如何涉及到对Windows注册表的依赖,那么将是一个很大的工程量。微软的设计更好地支持范围广泛的依赖Windows注册表的应用程序。

容器发布:WinDocks利用本地安装.NET和SQL服务器实例来支持创建容器和镜像。这种方法实现起来比较简单高效,而且利用微软成熟的DLL共享架构。这种方法同时使用了现有的主机或基于SQL Server许可的核。当前SQL Server许可允许一个主机上的多个实例,而WinDocks使得这种多实例的使用更加快速和实用。对于开源的镜像,如Nginx,node.js或Java,WinDocks同时包含了可再发行的运行时支持。

微软的容器服务是基于新的设计模式,每个容器等于一个新安装的应用程序,容器镜像则是一个新的安装包。这就解释了微软引入新的许可条款的理由。

其他问题:微软对Windows容器的支持在不断的进步,但在发表这篇文章的时候仍然存在着缺乏支持IP回环,不支持mount,以及不支持SQL Server Management Studio的Windows身份验证。

#结论
WinDocks针对现有的系统和发行版本,可以简单的采用、使用和支持。开发人员可以在Windows 8,Windows10,Windows Server 2012,或Windows Server 2016上支持.NET、SQL Server和Java。WinDocks软件目前已经被广泛应用,开发人员平均减少VM使用比例为10:1,大大缩减了在微软许可证上的投入成本。

而相对来说,微软的容器之路并不完善,提供的可伸缩性很有限,这正是运维的痛点,并且其中还存在大量悬而未决的问题。客户如果使用微软的Windows容器应考虑等待新的SQL Server许可镜像,并且需要更多和更强大的系统来支持镜像维护。

原文链接: Windows Containers Compared: WinDocks vs. Microsoft(翻译:edge_dawn)

在Windows 10上运行Linux及Windows容器

colstuwjx 发表了文章 • 0 个评论 • 12898 次浏览 • 2016-10-15 21:35 • 来自相关话题

【编者的话】DockerCon 2016上Docker官方发布了Docker for Windows的公开测试版本,在这一版本里,添加了对在Windows 10上运行Windows容器(包括nanoserver和servercore)、Linux容器以及两者并 ...查看全部
【编者的话】DockerCon 2016上Docker官方发布了Docker for Windows的公开测试版本,在这一版本里,添加了对在Windows 10上运行Windows容器(包括nanoserver和servercore)、Linux容器以及两者并存的支持,本文作者就这一话题为我们展示了一些具体的实例操作并进一步分析了背后的运行机制。

在西雅图举办的DockerCon 2016上,Docker官方发布了Docker Windows的公开测试版本。在这一版本里,你能够以一种非常简便的方式在安装了Hyper-V的Windows 10专业版上通过Docker运行Linux容器。在一段时间内这里会同时存在一个稳定版本以及一个测试版本渠道以获取新的版本。

并且,微软已经将容器功能添加到了Windows 10的年度更新补丁里。通过一些安装步骤,你便能在你的Windows 10机器上运行Windows Hyper-V容器

但是这里面可能存在点小疑问,那便是这两种安装方式对应启动的是哪类容器。而且,在不做任何调整的情况下你将无法并排运行两个Docker引擎。

由于两个安装版本使用的是同一个默认的命名通道```//./pipe/docker_engine```,这会导致其中的一个引擎启动失败。
## 统领一切的Beta 26
从Docker Windows Beta 26测试版本起,这里有一个更简单的方法来解决这个矛盾。你只需要通过MSI安装器装上Docker Windows版即可。在Docker的托盘图标上会有一个新的菜单选项支持在Linux及Windows容器间切换。
docker-for-windows-switch1.gif

正如你在视频里所看到的那样,你不用再通过更改环境变量或是利用Docker客户端的`-H`参数来和其他的Docker引擎通信。

如果你下载了Docker Windows测试版或是你在安装过程中切换到了测试频道,那么不妨亲身体验一下。

如果你之前还没有激活容器功能的话该安装器将会帮你激活它。为了添加这项特性,需要重启一次才能生效。

现在你可以轻松地通过点击托盘图标里的菜单栏来完成切换。

这里也提供了一个命令行工具来切换引擎。你可以打开一个PowerShell窗口然后键入:
& 'C:\Program Files\Docker\Docker\DockerCli.exe' -SwitchDaemon

这样它便完成了从Linux切换到Windows,反之亦然。注意按照上面展示的那样键入参数,它是大小写敏感的。
## 用代理来解围
但是,如何才能做到切换工作进行过程中无需Docker客户端改用其他的命名通道或是套接字呢?

答案便是,Docker会运行一个代理进程 `com.docker.proxy.exe`,它会监听默认的命名通道`//./pipe/docker_engine`。

如果你是从Linux切换到Windows,那么Windows Docker引擎`dockerd.exe`将会启动并监听在另外的命名通道`//./pipe/docker_engine_windows`,然后发起一个新的代理进程重定向到它。
## 探寻本质
为了探寻从Linux切换到Windows容器的过程中究竟发生了什么,我安装了sysinternals进程监控工具。通过进程树功能,你可以看到一个时间线,每个已启动或者已退出的进程都会有对应的绿色条。

下面这张截图展示了切换前后的进程情况。大概在绿色条的中间部分我就已经完成了切换。
switch-to-windows-dockerd.png

和MobyLinuxVM通信的`com.docker.proxy.exe`(列表里的`dockerd.exe`),正如深绿色条高亮展示的那样已然退出。

`dockerd.exe`,即Windows Docker引擎启动了,并且它还发起了一个新的和Windows Docker引擎通信的`com.docker.proxy.exe`(dockerd.exe下面)。

因此,在切换后你仍然可以用`docker.exe`客户端或者是集成在你喜爱的编辑器或IDE里的Docker插件,而无需作任何环境上的改动。
## 并行运转两个容器世界
代理进程只是切换了连接到的Docker引擎而已。在这样一个切换动作完成后实际上Linux和Windows两个Docker引擎均在运行。
## 运行一个Linux Web服务器
在体验之前我们首先得切换回Linux容器。现在我们可以在80端口上运行默认的nginx web容器:
docker run -p 80:80 -d nginx

然后再切换到Windows容器:
& 'C:\Program Files\Docker\Docker\DockerCli.exe' -SwitchDaemon

docker-run-nginx.png

现在,让我们跑一些Windows容器吧。但是首先我们还得试试看Linux容器是否仍然还在运行,并且服务是否是可以访问的:
start http://localhost  

通过这个`start`命令你可以打开Edge浏览器访问一个运行在Linux容器里的Nginx自带的欢迎页面。
nginx.png

是的,这个Linux容器一直在跑着。
## 构建一个Windows Web容器
在Windows 10上你~~只能运行Nanoserver容器。而这里并没有针对Nanoserver的IIS docker镜像~~。重大更新:你可以在Windows 10上运行Nanoserver以及windowsservercore容器。

但是为了演示nanoserver容器是如何的简单,我将仍然使用下面这个例子来做讲解。那么,我们现在来创建一个属于自己的小型Node.js Web服务器。首先,我们编写一个简单的web服务应用:
notepad app.js

在`app.js`文件里键入如下代码作为一个迷你web服务然后保存该文件。
var http = require('http');  
var port = 81;

function handleRequest(req, res) {
res.end('Hello from Windows container, path = ' + req.url);
}

var server = http.createServer(handleRequest);
server.listen(port);

现在我们来为这个应用构建一个Windows Docker镜像。我们另外打开一个编辑器然后通过如下命令创建`Dockerfile`:
notepad Dockerfile

键入下面的代码作为Dockerfile的内容。正如你所能看到的那样,只有`FROM`这一行和典型的Linux Dockerfile不太一样。它使用的是一个来自Docker Hub的Windows基础镜像。
 FROM stefanscherer/node-windows:6.7.0-nano

COPY app.js app.js

CMD [ "node", "app.js" ]

保存该文件然后通过如下熟悉的命令来构建Docker镜像:
docker build -t webserver .  

通过如下命令将Windows web服务跑在一个Docker容器里:
docker run -p 81:81 -d webserver  

docker-run-webserver-1.png

这时候你无法直接通过127.0.0.1连接到容器。但是可以使用容器的IP地址去访问。我们需要容器的ID或者名字,可以通过如下命令列出当前正在运行的容器:
docker ps  

然后打开浏览器输入对应容器的IP地址:
start http://$(docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" grave_thompson):81  

docker-inspect.png

此外,从宿主机到容器的端口转发使得你在其他机器上也可以通过81端口访问Web服务。
curl-to-windows-10.png

是的,Windows容器也在处理请求了。
## 结论
新版的Docker Windows测试版把两个容器世界结合在了一起,并且简化了Linux和Windows Docker镜像的构建,使得一台Windows 10机器对于两者而言均可算是一个不错的开发平台。

并且在切换到所需的Docker引擎时稍微注意一下便能发现,Linux和Windows容器可以同时在两侧运行。

原文链接:run-linux-and-windows-containers-on-windows-10(翻译:吴佳兴)