这篇文章主要讲解了“Docker容器下部署Git的步骤”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Docker容器下部署Git的步骤”吧!
老办法
我实在没办法在本地模拟一个完全真实的环境,但是我们只要看一下启动一台虚拟机使用的时间:
$time vagrant up Bringing machine 'default' up with 'virtualbox' provider... [default] Importing base box 'squeeze64-ruby193'... ... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. ... real 1m32.052s
启动一个镜像超过了一分半钟。那我要简单修改下配置怎么办啊?那我要验证下可行性呢,那是不是又得重启?又是一分半钟了啊。
这分明就是个残酷的惩罚嘛。
使用Docker
Docker到底有多么轻量级? 当你在Docker container中运行个进程时,你甚至都可能忘记这个进程竟然不是直接运行在主机上的。在下面的例子中,我运行一个叫“rails”的镜像在Docker container中,那里是个Rails App (Dockerfile):
root@precise64:~# docker run rails 2013-08-26 20:21:14,600 CRIT Supervisor running as root (no user in config file) 2013-08-26 20:21:14,603 WARN Included extra file "/srv/docker-rails/Supervisorfile" during parsing 2013-08-26 20:21:14,736 INFO RPC interface 'supervisor' initialized 2013-08-26 20:21:14,740 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2013-08-26 20:21:14,754 INFO supervisord started with pid 1 2013-08-26 20:21:15,783 INFO spawned: 'rails' with pid 10 2013-08-26 20:21:16,841 INFO success: rails entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
开始container和启动supervisor (这是负责开始Rails app的)一个只用了2秒
简而言之,Docker绝对胜任在你的开发电脑上虚拟出一个完整的生产环境,而且很快。既然这么简单,来,开动起来吧:我要彻底测试一下
构建镜像如此方便快捷 - 缓存万岁!
老方法
如果你想把从空镜像到一个功能镜像的构建过程脚本化(例如:在Ubuntu上怎么安装一个Rails stack),要是你不是经常干这事,那么正确获得所有的流,这绝对会是个痛苦的活儿。看看为Ruby安装依赖吧:
$time apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev Reading package lists... Building dependency tree... The following extra packages will be installed: .... Setting up libalgorithm-merge-perl (0.08-2) ... Processing triggers for libc-bin ... ldconfig deferred processing now taking place real 1m22.470s
然后,你想装了NodeJS的依赖,但是忘了给apt添加源了:
$apt-get install -y nodejs ... E: Unable to locate package nodejs
解决了源的问题后,你得确认你的脚本在新镜像中会不会有问题。那么你需要重装Ruby,好吧,又要浪费82秒了。正是神烦。
使用Docker
在Docker中,是把构建镜像的步骤放到Dockerfile. Dockerfiles是非常容易阅读的,因为你根本不需要学习DSL - 这就是些你输入时记录下来的基本命令。***次安装Ruby会有点麻烦,但是让我们看看,通过Dockerfile来构建余下的镜像会发生什么:
FROM ubuntu:12.04
RUN apt-get update
## MYSQL
RUN apt-get install -y -q mysql-client libmysqlclient-dev
## RUBY
RUN apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev
root@precise64:/# time docker build -t="dlite/appserver" . Uploading context 92160 bytes Step 1 : FROM ubuntu:12.04 ---> 8dbd9e392a96 Step 2 : RUN apt-get update ---> Using cache ---> b55e9ee7b959 Step 3 : RUN apt-get install -y -q mysql-client libmysqlclient-dev ---> Using cache ---> dc92be6158b0 Step 4 : RUN apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev ---> Using cache ---> 7038022227c0 Successfully built 7038022227c0 real 0m0.848s
部署镜像, 别更新基础环境
老办法
像许多其他部署一样,Scout也使用长期运行的虚拟机。我们通过Puppet来更新基础环境,但是, 这经常比我们想象得要痛苦:
如果我们要更新stack, Puppet将运行虚拟机然后更新。这将花费很长时间-即使只是一小部分的stack需要更新,但是Puppet仍然会检查全部。
部署过程中也可能有问题。如果我们正在安装Memcached,突然网络中断了一小下,那么apt-get install memcached的指令可能就会无效了。
回滚主要变化,这也时常不是想象中那么顺利(像更新Ruby版本).
这些都是Puppet's的毛病 - 像Puppet或者Chef这样的工具是非常重要,特别当你有着一些长时间运行的虚拟机,这些虚拟机可能随着时间的推移出现不一致的情况,那么这些工具就更重要了。
使用Docker
部署镜像 - 不用修改存在的虚拟机。你可以100%确保,本地运行什么,相应的生产环境就会运行什么。
但是镜像很大,对吗?不要整个Docker-记住containers不是运行在自己的操作系统上的,还有我们使用的是联合文件系统。当我们对于镜像做出改变时,我们只需要在上面添加新的层。
例如,我们安装Memcached在app服务器上。我们构建了一个新的镜像。我会标注asdlite/appserver-memcached,dliteis是我的index.docker.io用户名,这是基于dite/appserver镜像的。
root@precise64:/# time docker build -t="dlite/appserver-memcached" . Uploading context 92160 bytes Step 1 : FROM appserver ---> 8dbd9e392a96 Step 2 : RUN apt-get update ---> Using cache ---> b55e9ee7b959 Step 3 : RUN apt-get install -y -q memcached ---> Running in 2a2a689daee3 Reading package lists... Building dependency tree... ... Starting memcached: memcached. Processing triggers for libc-bin ... ldconfig deferred processing now taking place ---> 2a2a689daee3 Successfully built 2a2a689daee3 real 0m13.289s user 0m0.132s
只要13秒就能安装好Memcached,这是因为之前的Dockerfile被缓存了,我爱这种速度的感觉。
我会上传和提交这些:
root@precise64:/# time docker push dlite/appserver-memcached The push refers to a repository [dlite/appserver-memcached] (len: 1) Processing checksums Sending image list Pushing repository dlite/appserver-memcached (1 tags) Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c Image 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c already pushed, skipping ... Pushing tags for rev [ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8] on {https://registry-1.docker.io/v1/repositories/dlite/appserver-memcached/tags/latest} real 0m28.710s
在生产环境中的机器上,我把镜像下载下来:
root@prod:/# time docker pull dlite/appserver-memcached Pulling repository dlite/appserver-memcached Pulling image ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8 (latest) from dlite/appserver-memcached real 0m15.749s
只用了15秒就获得了dlite/appserver-memachedimage。注意那个镜像只有10MB大小,使用app服务器镜像作为基础镜像:
root@precise64:~# docker images REPOSITORY TAG ID CREATED SIZE appserver latest 7038022227c0 3 days ago 78.66 MB (virtual 427.9 MB) appserver-memcached latest 77dc850dcccc 16 minutes ago 10.19 MB (virtual 438.1 MB)
我们没有必要将整个Memcached镜像都下载下来, 只要将Memcached镜像中的改变添加到dlite/appserver镜像中。
绝大多数时间,我们做出的改变会小得多。所以下载一个新镜像会更快。
这些会有很大的作用:
开始新的Docker containers是非常快的
上传+下载新的Docker镜像要轻量级的
并非要改变现在运行的虚拟机,我们只是开始新的containers,停止旧的containers.
的确震惊! 这意味着我不需要担心一致性问题 - 我们不会修改运行的虚拟机,只是开始新的containers。这意味着可以轻松回滚!Memcached失败了?停止运行 dlite/appserver-memcached的container,开始一个新container运行dlite/appserver镜像。
不足之处
在短暂的containers上工作,这会导致一系列新问题- 分布式配置 / 协调和服务发现:
当一个新的app服务器containers开始后,我们改如何更新HAProxy配置?
当一个新的数据库container开始后,app服务器应该如何与数据container来通信?
如何跨越Docker宿主机器通信?
感谢各位的阅读,以上就是“Docker容器下部署Git的步骤”的内容了,经过本文的学习后,相信大家对Docker容器下部署Git的步骤这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。