Opsworks 厨师 12 道菜谱

Posted 2023-03-04

【中文标题】Opsworks 厨师 12 道菜谱

【英文标题】：Opsworks Chef 12 recipes

【发布时间】：2016-07-19 02:38:48

【问题描述】：

是否有人尝试将 Opsworks Chef v11 食谱转换为 Chef v12？

我在 Chef 11 上运行多个堆栈，并决定开始将其中一些堆栈转换为 Chef 12。由于 AWS 放弃了他们的 opsworks 应用程序层，例如 rails 层配方，我们（opsworks 用户）现在负责创建 @987654322 @user，git checkout repos 到 deploy_to 等。

这一切都很好，具有灵活性并且没有更多的命名空间冲突，但我们错过了 opsworks 免费提供给我们的所有好东西。

想知道是否有人为 Chef 12 转换了食谱并开源了？否则，社区对这些食谱感兴趣吗？我很确定我在这里并不孤单。

提前谢谢你！

【参考方案1】：

我不了解旧的 OpsWorks 食谱，但请查看 https://github.com/poise/application_examples/，了解一些使用普通 Chef 进行 Rails（以及更多）部署的示例（也适用于 OpsWorks）。

【讨论】：

谢谢，这是一个很好的例子，但它非常基础。当我提到 Opsworks 配方的好处时，我的意思是 deploy 配方将创建模拟 capistrano 部署的目录结构（/srv/www/app/releases、/srv/www/app/shared、/srv/www/app/current），为每个应用程序准备 deploy 用户及其 ssh_key，将database.yml 替换为与环境相关的正确值。

你可以走那条路，但我不推荐。 deploy 资源比它的价值更脆弱。

【参考方案2】：

opsworks_ruby cookbook on the Supermarket 基本上是您需要的一切。它甚至将应用程序放入相同的目录（即/srv/www/app_name/），设置您的 database.yml 等。

此秘籍与其他非 OpsWorks 秘籍的主要区别在于，它将为您从 OpsWorks 配置中提取所有内容。您不必自定义配方，只需确保您的应用程序和图层名称正确 - 它会从那里构建所有内容 - 包括您的 database.yml 的 RDS 配置！

主要区别在于 OpsWorks 中的层不会“感知 Ruby”，因此您不会有 Rails 或 Ruby 的字段，而是需要在其他地方管理这些字段。 ENV vars 的加载方式也有些不同。

还请务必阅读 AWS 为 OpsWorks 实施 Chef 12。从技术上讲，他们有两本正在运行的厨师食谱，他们内部的和你的。他们的工作包括管理最新的代理、加载用户（用于 ssh）、连接监控等。您必须管理其余部分。

我们要么用超市的个别食谱替换了他们庞大的食谱中的内容，要么只是重写了它。例如，旧版 Chef 11 opsworks_initial_setup 在调整网络和 linux 设置方面做了一些事情——我们重新创建了。

它也确实使用部署用户，例如：

$ ps -eo user,command USER COMMAND // snip root nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf aws opsworks-agent: master 10820 aws opsworks-agent: keep_alive of master 10820 aws opsworks-agent: statistics of master 10820 aws opsworks-agent: process_command of master 10820 deploy unicorn_rails master --env production --daemonize -c /srv/www/app/shared/config/unicorn.conf deploy unicorn_rails worker[0] --env production --daemonize -c /srv/www/app/shared/config/unicorn.conf deploy unicorn_rails worker[1] --env production --daemonize -c /srv/www/app/shared/config/unicorn.conf deploy unicorn_rails worker[2] --env production --daemonize -c /srv/www/app/shared/config/unicorn.conf deploy unicorn_rails worker[3] --env production --daemonize -c /srv/www/app/shared/config/unicorn.conf nginx nginx: worker process nginx nginx: worker process

只是进程输出的一个小例子，但 root 会根据需要引导事物，并且每个进程都利用自己的用户来限制权限和访问。

【讨论】：

您是否必须在 opsworks 中指定使用 build-essentials、application_ruby 等...正如您在自述文件中所说，这是一个依赖项，而不是是否首先在层中运行它们？

它会为您安装所有这些，请参阅github.com/ajgon/opsworks_ruby/blob/…

将 repo 上传到我的 chef repo 与打包依赖项并从 S3 中提取有区别吗？我无法从我的回购中得到这个工作。它一直在要求一本 Windows 食谱，当然它不能在 Linux AMI 上运行......

【参考方案3】：

我认为最常用的方法是使用超市的“应用程序”食谱：https://supermarket.chef.io/cookbooks/application/versions/4.1.6（也是基于 Poise）。注意：使用版本 ~4，他们删除了 v5 中几乎所有好的功能。

它将创建目录结构，支持不同的部署策略并提供一些事件挂钩。 请注意：在我看来，关于“使用 opsworks 和 chef12 部署”主题，Opsworks 文档是半好的：来自 gui 的信息（如 repo-url 等）不在 node 对象上，而是在应用程序的数据包中。对于调试，查看/var/chef/runs/<run-id>/ 目录以查看从何处可用是非常有帮助的。 显示想法的小sn-p：

app = search("aws_opsworks_app").first
application "#app['shortname']" do
  owner 'root'
  group 'root'
  repository app['app_source']['url']
  revision   'master'
  path "/srv/#app['shortname']"
end

这将在/srv 上创建发布/当前目录结构并签出代码。注意：您可能会认为您在 GUI 中指定的 ssh-key 会以某种方式自动放置在适当的位置。不是，你必须自己处理。查看 chef11 opsworks 食谱：https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/scm_helper/libraries/git.rb