TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How We Use AWS, Ansible, and Packer to Make Deployment Awesome

51 点作者 dmitrig01超过 10 年前

7 条评论

cddotdotslash超过 10 年前
This is interesting, but I find using a different AMI for each project to be tedious. My understanding is that instances should be ephemeral and agnostic to the project at hand. Initial bootstrap scripts should handle the installation of any dependencies and the project code itself.
评论 #8399464 未加载
daxhuiberts超过 10 年前
This setup is very similar to the setup I created at my previous job.<p>Instead of Ansible, I used a plain old shell script, but still idempotent. I did all the testing locally using vagrant&#x2F;virtualbox. Application deployment was separated in our setup as well, also retrieving the latest application codebase during boot, but using a tgz stored on s3 with the application all the application dependencies (ruby gems and precompiled assets) already in there.<p>All in all I am very happy with this setup being able to autoscale in a few minutes.
assaflavie超过 10 年前
Have you looked at docker as a replacement for creating all those AMIs? You could have one AMI (with Docker) installed, and then use Ansible to pull whichever container (app) you want onto each instance. Using docker also has the added advantage of letting you test your images in the development environment (and it&#x27;s much faster than vagrant-up for every service you want running locally for dev&#x2F;test).
Sanddancer超过 10 年前
The problem I see with using a mostly-baked AMI like this is what happens if your git repo is down when you&#x27;re trying to bring up a new instance? Bringing up a new server with old code is just asking for all sorts of little problems to spring up if, for example, the git server is down. Given your environment, partial failure seems to be a much worse scenario than an instance not coming up.
评论 #8399527 未加载
评论 #8402466 未加载
评论 #8401541 未加载
zwischenzug超过 10 年前
I&#x27;ve blogged about a similar exercise here:<p><a href="http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-and-docker-to-play-with-aws-part-one/" rel="nofollow">http:&#x2F;&#x2F;zwischenzugs.wordpress.com&#x2F;2014&#x2F;08&#x2F;09&#x2F;using-shutit-an...</a><p>This deploys in a reliable way using a docker container and ShutIt, a tool we use in my corp for fast development of reliable and composable iterative steps:<p><a href="http://ianmiell.github.io/shutit/" rel="nofollow">http:&#x2F;&#x2F;ianmiell.github.io&#x2F;shutit&#x2F;</a><p>Here&#x27;s more on the subject:<p><a href="https://github.com/ianmiell/shutit/blob/master/README.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ianmiell&#x2F;shutit&#x2F;blob&#x2F;master&#x2F;README.md</a> <a href="https://www.youtube.com/user/ianmiell" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;user&#x2F;ianmiell</a> <a href="http://zwischenzugs.wordpress.com/" rel="nofollow">http:&#x2F;&#x2F;zwischenzugs.wordpress.com&#x2F;</a>
krakensden超过 10 年前
I&#x27;m surprised you use fabric for the last mile instead of ansible. There&#x27;s really no sequence of run() commands that can&#x27;t be done better as a quick module.<p>Although I may have been more frustrated than most by paramiko&#x27;s performance and stability.
评论 #8399404 未加载
yourabi超过 10 年前
Hi. You don&#x27;t use SSL for the signup &#x2F; login form :-(
评论 #8399488 未加载