使用Chef-solo在Ubuntu上配置Django应用

• 创建食谱
• 最后步骤

有许多方法可以自动化设置和配置盒子的过程。无论出于何种原因，如果此时我们的整个系统只包含一个盒子，那么建立完整的SCM（软件配置管理）基础架构就显得过头了。Shell脚本是一种选择，但是我们也可以使用SCM的简化版本，该版本在一些工具中可用。Chef是最受欢迎的选项之一，而“ chef-solo”是Chef的独立配置模式，我们不需要额外的节点来充当“ chef-server”。它所需要的只是一个URL或包含厨师食谱的tarball包的路径。与shell脚本相比，这种方法开箱即用，更具声明性和效率，并且是SCM或IaC（基础架构即代码）流程入门的很好的入门。

使用Chef-solo的其他一些好处：

• 可组合性：使用厨师超市或其他地方的社区食谱。
• 免费和开源；根据许可的Apache 2.0许可获得许可。
• 访问其余的厨师生态系统（InSpec，ChefSpec，Cookstyle，Foodcritic，chef-shell等）
• 菜谱和食谱稍后可以适应客户端/服务器模式。

还有一些缺点：

• Chef超市上的某些社区食谱已过时，损坏且未维护。
• Chef-solo无法自行解决依赖关系。

厨师“食谱”内部的“食谱”具有基于红宝石的DSL，该DSL将“资源”描述为处于节点上的特定状态。让我们继续进行演练，以了解一些同样适用于Chef-solo的Chef概念。我们的目标是使用Gunicorn和NGINX设置运行Python / Django Web应用程序的Ubuntu节点。

注意：我们不一定需要在我们的“ Chef工作站”（我们的机器）上安装ChefDK，尽管有了它，我们可以使用“ chef generate”命令来启动用于创建食谱，食谱等的目录结构。在本文中，我们将假定ChefDK已安装在我们的工作站上。使用ChefDK的4.7.26-1版本运行命令。

（此后，除非另有说明，否则所有内容都应在我们的机器上运行，也称为“厨师工作站”）

创建食谱

Chef中的食谱是可重用的单元，其中包含支持配置方案所需的一切。食谱可以包含多个“食谱”，而“食谱”主要由资源模式组成。default.rb是在运行列表中引用该菜谱时将运行的默认配方。不同的配方可以分离关注点。但是，对于本教程，我们将所有资源声明添加到一个主配方文件（即）中default.rb。

创建一个名为“ my-chef-project”的文件夹，并在其中创建一个名为“ cookbooks”的文件夹。从./my-chef-project/cookbooks/，运行：

$ chef generate cookbook my-cookbook

现在，我们的目录结构将如下所示：

.
└── my-chef-project
└── cookbooks
└── my-cookbook
├── CHANGELOG.md
├── LICENSE
├── Policyfile.rb
├── README.md
├── chefignore
├── kitchen.yml
├── metadata.rb
├── recipes
│ └── default.rb
├── spec
│ ├── spec_helper.rb
│ └── unit
│ └── recipes
│ └── default_spec.rb
└── test
└── integration
└── default
└── default_test.rb

添加包裹

设置节点的第一步是确定我们的应用程序需要哪些软件包。我们的节点被选为Ubuntu，因此我们可以依靠APT软件包管理器来收集依赖项。安装OS发行版提供的软件包非常容易：

apt_update
package 'python3'
package 'python3-pip'
package 'nginx'
package 'pkg-config'
package 'libcairo2-dev'
package 'libjpeg-dev'
package 'libgif-dev'
package 'libgirepository1.0-dev'

这些几乎是不言自明的。第一行将更新apt信息库，随后几行将安装这些软件包。

注意：nginx之后的软件包是通过pip编译某些python依赖项所必需的。这些可能会根据中指定的python / django项目依赖项而有所不同requirements.txt。您可以使用反复试验的方法来确定需要包含在食谱中的这些软件包。为此，sudo pip install -r requirements.txt请在新实例化的ubuntu计算机上执行手册（注意：这将在系统范围内安装软件包！），以查看其是否成功运行。如果没有，stderr应该为您提供有关缺少哪些软件包的提示。

创建Linux用户

添加完所需的软件包后，我们需要创建一个拥有应用程序源代码的非特权Linux用户。

user 'bob' do
  uid 1212
  gid 'users'
  home '/home/bob'
  shell '/bin/bash'
  password '$1$alilbito$C83FsODuq0A1pUMeFPeR10'
end

请注意，密码是Linux中使用的影子哈希格式。可以使用OpenSSL派生：

$ openssl passwd -1 -salt alilbitof mypassword

包括应用程序源

现在，将Django应用程序源代码包含到我们的食谱中。将源代码放入“ ./my-chef-project/cookbooks/my-cookbook/files/default/myapp/ 创建./my-chef-project/cookbooks/my-cookbook/files/default目录”（如果不存在）中。

使用remote_directory资源描述了将这些文件复制到节点上的远程位置的指令：

remote_directory '/home/bob/myapp' do
  source 'myapp' # This is the name of the folder containing our source code that we kept in ./my-cookbook/files/default/
  owner 'bob'
  group 'users'
  mode '0755'
  action :create
end

引入python依赖项

要在中安装python包requirements.txt，我们可以使用execute资源运行任意命令。在这种情况下，我们需要对其执行pip install命令：

execute 'install python dependencies' do
  command 'pip3 install -r requirements.txt'
  cwd '/home/bob/myapp'
end

注意：请记住，这将以root用户身份执行，并且python库将在系统范围内安装。如果将我们的节点指定为专门运行此单个python应用程序，那么这不是什么大问题。尽管如此，使事物保持清洁和理智的一个更好的选择是找到并使用管理python安装或“ virtualenvs”的社区食谱。（或者至少写一系列执行块来复制它）。在python中使用virtualenvs确保不会影响任何基于python的系统工具或其他python项目

设置Gunicorn和NGINX

现在是时候准备使用NGINX作为反向代理的Gunicorn WSGI HTTP服务器了。Nginx还用于处理Django中的所有静态资产。

要将Gunicorn作为Ubuntu上的服务捆绑，可以使用Systemd。自版本12.11起，systemd_unit资源包含在Chef中。

systemd_unit 'gunicorn.service' do
  content({
  Unit: {
    Description: 'Django on Gunicorn',
    After: 'network.target',
  },
  Service: {
    ExecStart: '/usr/local/bin/gunicorn --workers 3 --bind localhost:8080 myapp.wsgi:application',
    User: 'bob',
    Group: 'www-data',
    WorkingDirectory: '/home/bob/myapp'
    Restart: 'always',
  },
  Install: {
    WantedBy: 'multi-user.target',
  }
  })
  action [:create, :enable, :start]
end

现在，我们必须在此Gunicorn服务器中包括一个标准的NGINX代理配置，如下所示。这个片段可以进入./my-cookbook/templates/nginx.conf.erb。如果不存在，请创建模板目录。

注意：Chef的模板支持嵌入式ruby文件，该文件可以包含变量，ruby表达式和语句。尽管此文件具有'erb'扩展名，但我们并未使用任何ruby语句或表达式。另外，为简单起见，我们在此处仅提供了非HTTPS nginx配置（温和的提醒；请不要在生产中执行此操作！）

server {
  listen 80;
  server_name http://example.com/;

  location = /favicon.ico { access_log off; log_not_found off; }
  location /static/ {
    root /home/bob/myapp/myapp/static;
  }

  location / {
  include proxy_params;
    proxy_pass http://localhost:8080/;
  }
}

注意：还有另外一种更好的配置，例如，将Gunicorn服务器绑定到unix域套接字而不是TCP环回连接。出于性能原因，值得探讨一下。

要将此配置复制到节点上启用了站点的文件夹，请使用Chef 的模板资源。

template '/etc/nginx/sites-available/example.com.conf' do
  source 'nginx.conf.erb'
  owner 'root'
  group 'root'
  mode '0744'
end

在nginx上激活配置通常是通过sites-available在nginx的sites-enabled文件夹中创建一个指向该配置的符号链接来完成的。可以在厨师食谱中使用链接资源声明符号链接，如下所示：

link '/etc/nginx/sites-enabled/example.com.conf' do
  to '/etc/nginx/sites-available/example.com.conf'
end

并删除默认的配置符号链接：

link '/etc/nginx/sites-enabled/default' do
  action :delete
end

启动NGINX

最后，启动nginx服务：

service 'nginx' do
  action :enable
  action :start
end

运行清单

Chef中的运行列表是食谱中角色或配方的有序列表，将按顺序在节点上执行。我们有一个食谱“ my-cookbook”和其中的“默认”食谱，需要在Ubuntu机器上执行，因此项目目录（./my-chef-project/runlist.json）中的runlist.json 应该如下所示：

{
  "run_list": [
    "recipe[my-cookbook::default]"
  ]
}

最后步骤

我们为厨师独奏准备的菜谱已准备就绪。现在该配置Ubuntu 18.04机器并在其上安装ChefDK了：

$ ssh [email protected] 'apt-get update && yes | apt-get install curl && curl https://packages.chef.io/files/current/chefdk/4.7.45/ubuntu/18.04/chefdk_4.7.45-1_amd64.deb -o chefdk.deb && yes | dpkg -i chefdk.deb && rm chefdk.deb'

去回到我们的厨师工作站，我们需要做的就是把食谱文件夹压缩包，里面转移与一起打包文件runlist.json到我们供应的上方运行厨师独奏命令远程节点：

（以下命令将在节点或“ chef客户”而不是 Chef Workstation内部运行）

$ chef-solo --recipe-url $(pwd)/chef-solo.tar.gz -j $(pwd)/runlist.json --chef-license=accept

或以下是单线（将./my-chef-project/在Chef Workstation上从CWD 运行）：

tar zvcf chef-solo.tar.gz ./cookbooks &&\
scp chef-solo.tar.gz runlist.json [email protected]:~/ &&\
ssh [email protected] 'chef-solo --recipe-url $(pwd)/chef-solo.tar.gz -j $(pwd)/runlist.json --chef-license=accept'

而已！观察Chef活动如何填充标准输出，以使您的节点收敛到食谱中指定的内容。Chef-solo将安装所有食谱所需的所有宝石。如果chef-solo命令成功，我们将在Ubuntu框的nginx后面运行一个可运行的Django应用程序。导航到域/ IP进行测试。

注意：请记住，在django中，您可能需要在中的ALLOWED_HOSTS列表中设置此域/ ip settings.py。

应对变化

每当我们更改项目目录的内容（配方，模板或应用程序源代码等）时，只需在项目目录中运行上述单行代码即可。

提示：如果菜谱受git版本控制（应该如此），一个好的建议是设置git hooks来运行此单行代码。

托管tarball（可选）

如果您仔细查看最后一个Chef-solo命令，请注意，该命令--recipe-url用于获取URL。这意味着您可以拥有一个工作流，其中配置项将构建您的chef-solo tarball，将其上传到某个位置，并配置您的节点以定期从中提取。

提示：使用curl可以定期将更改过的tarball拉出作为cronjob。curl -z $file将If-Modified-Since保留标头，并且仅在自本地时间戳以来自时间戳以来更改远程文件的情况下下载tar球$file。