Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

RSS

nginx_lwrp (3) Versions 3.0.0

Installs and configures nginx

Berkshelf/Librarian
Policyfile
Knife
cookbook 'nginx_lwrp', '= 3.0.0'
cookbook 'nginx_lwrp', '= 3.0.0', :supermarket
knife cookbook site install nginx_lwrp
knife cookbook site download nginx_lwrp
README
Dependencies
Changelog
Quality 56%

Description

Installs Nginx from package, sets up some default configuration and defines LWRP supposed to be used inside your own cookbooks, which you use to manage your infrastructure.

Requirements

Cookbooks

At the moment this cookbook doesn't depend on other cookbooks but it may change in the future.

Platform

The cookbook has been tested to work on Ubuntu 14.04, Ubuntu 16.04, Debian 8 and Debian 9

I suppose it should also work for CenOS/RHEL but no tests have been conducted yet.

Chef version

Chef version >= 13 has to be used.

Сhef 12 is reaching its EOL in April 2018 and will be removed from downloads.chef.io so it doesn't make sense to continue its support, so I'm dropping Chef 12 support starting from version 3.0.0 of this cookbook in favor of Chef 13.

Attributes

Defaults that are used to configure nginx. If you want to change one of this parameters in nginx consider using provided LWRP and definitions.

  • node['nginx']['config']['conf_dir'] - Base nginx config directory. Default /etc/nginx.
  • node['nginx']['config']['log_dir'] - Directory for nginx log files. Default /var/log/nginx.
  • node['nginx']['config']['user'] - Default user that nginx will use to run worker processes. Default: www-data.
  • node['nginx']['config']['worker_processes'] - Number of nginx workers. Default cpu['total'].
  • node['nginx']['config']['worker_connections'] - Number of simultaneous connections that one worker can serve. Default8192`.
  • node['nginx']['config']['worker_rlimit_nofile'] - Specifies the value for maximum file descriptors that can be opened by one worker process. Default 8192.
  • node['nginx']['config']['pid'] - Path to Nginx pid file. Default: /var/run/nginx.pid
  • node['nginx']['config']['mainconfig_include'] - Include files into the main context of nginx.conf. Default: nil
  • node['nginx']['config']['error_log'] - Path to a default error log file. Default: /var/log/nginx/error.log

Recipes

This cookbook provides only one recipe:

default.rb

This default recipe will make some basic steps:

  • installs Nginx from the package that is provided by your OS's package manager ("pin" the desired version using another cookbook);
  • creates all directories for configuration, directory for log files, etc;
  • creates default nginx.conf file and associated files;
  • configures log rotation for Nginx;
  • enables and starts Nginx service;
  • runs resource that removes Nginx configuration files for sites, which are not defined by this cookbook's LWRP.

Usage

Wrapper-cookbook way

This cookbook has been designed to provide LWRP for your own infrastructure recipes. First of all, we should make our infrastructure cookbook to load this one. * Do it by adding the line depends nginx_lwrp to your cookbook's metadata.rb. * To make all default preparations for using Nginx invoke include_recipe "nginx_lwrp" inside your designated recipe. * Now feel free to use all available LWRP provided by this cookbook.

Roles-based way

Another way to use this cookbook is just to add recipe[nginx_lwrp] to your run_list before your recipe, which is resonsible for your infrastructure.

I personally prefer the first way because if you stick to it you'll eventually get complete and explicit "documentation" for your specific server installation. But in any case, you'll get Nginx installed, nginx.conf configured from the default template we provide, LWRP defined and ready to use.

Official Nginx repo or default distro package

If you would like to use nginx package from official nginx repo, then just add recipe[nginx_lwrp::official-repo] or include_recipe 'nginx_lwrp::official-repo' before nginx_lwrp recipe invokation. Other wise default nginx package would be used from distro repository.

LWRP

nginx_site

This resource manages your Nginx sites configuraions.

Actions

<table> <thead> <tr> <th>Action</th> <th>Description</th> <th>Default</th> </tr> </thead> <tbody> <tr> <td>create</td> <td> Creates site configuration file inside "sites-available" directory, but doesn't enable it. </td> <td> </td> </tr> <tr> <td>enable</td> <td> Creates site configuration file inside "sites-available" directory, enables it (puts a symlink to it into "sites-enabled" directory) </td> <td>Yes</td> </tr> <tr> <td>disable</td> <td> Ensures that site configuration file is disabled. </td> <td> </td> </tr> <tr> <td>delete</td> <td> Disables and deletes site configuration file. </td> <td> </td> </tr> </tbody> </table>

Attributes

<table> <thead> <tr> <th>Attribute</th> <th>Description</th> <th>Default Value</th> </tr> </thead> <tbody> <tr> <td>name</td> <td><b>Name attribute:</b> the name of the site's configuration file.</td> <td><code>nil</code></td> </tr> <tr> <td>template</td> <td>Defines what erb template file from the cookbook that invokes this resource we should use.</td> <td><code>name</code>.conf.erb</td> </tr> <tr> <td>variables</td> <td>Variables to be used in the template.</td> <td><code>Hash.new</code></td> </tr> </tbody> </table>

Examples

# We want to use "example.com.conf.erb" template file, do not want to pass any variables.
nginx_site 'example.com'

# Using custom-named template file and passing some variables, which can be used inside the template.
nginx_site 'forum.example.com' do
  action :enable
  template 'forum-nginx.erb'
  variables(
    listen_ip: '10.0.0.10',
    remote_ips: [ '10.0.0.2', '10.0.0.4' ]
  )
end

# Making sure that old site's configuration is disabled even if somebody has enabled it by hands.
nginx_site 'old.example.com' do
  action :disable
end

nginx_stream

Resource is completle similar to nginx_site except it is made to manage stream section includes.

Actions

<table> <thead> <tr> <th>Action</th> <th>Description</th> <th>Default</th> </tr> </thead> <tbody> <tr> <td>create</td> <td> Creates site configuration file inside "streams-available" directory, but doesn't enable it. </td> <td> </td> </tr> <tr> <td>enable</td> <td> Creates site configuration file inside "streams-available" directory, enables it (puts a symlink to it into "streams-enabled" directory) </td> <td>Yes</td> </tr> <tr> <td>disable</td> <td> Ensures that site configuration file is disabled. </td> <td> </td> </tr> <tr> <td>delete</td> <td> Disables and deletes site configuration file. </td> <td> </td> </tr> </tbody> </table>

Attributes

<table> <thead> <tr> <th>Attribute</th> <th>Description</th> <th>Default Value</th> </tr> </thead> <tbody> <tr> <td>name</td> <td><b>Name attribute:</b> the name of the stream's configuration file.</td> <td><code>nil</code></td> </tr> <tr> <td>template</td> <td>Defines what erb template file from the cookbook that invokes this resource we should use.</td> <td><code>name</code>.conf.erb</td> </tr> <tr> <td>variables</td> <td>Variables to be used in the template.</td> <td><code>Hash.new</code></td> </tr> </tbody> </table>

Examples

# We want to use "example.com.conf.erb" template file, do not want to pass any variables.
nginx_stream 'stream-01'

# Using custom-named template file and passing some variables, which can be used inside the template.
nginx_stream 'tcp-stream' do
  action :enable
  template 'nginx-stream.erb'
  variables(
    listen_ip: '10.0.0.10',
    remote_ips: '10.0.0.2'
  )
end

# Making sure that old site's configuration is disabled even if somebody has enabled it by hands.
nginx_site 'old-stream' do
  action :disable
end

nginx_mainconfig

This resource is deprecated right now, use attributes instead.

node.default['nginx']['config']['OPTION'] = 'VALUE'

List of allowed attributes

There are also attributes that can accept either a string or an array of strings:

Small handy templates

As mentioned in the previous paragraph - main nginx config file acceps only limited set of options. But we always do some tuning like enabling compression, etc. I've created two small templates for a kind of configuration I usually use. It's a bit ugly and it's atemorary solution but may become usefull if you want some standart and clean confguration fast.

Invoke each of these templates only once otherwise you'll have invalid nginx config.

gzip.conf.erb

Defaults to: gzip on; gzip_http_version 1.0; gzip_comp_level 4; gzip_proxied any; gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json; gzip_disable msie6; gzip_vary off;

How to use:

# Use its default parameters.
nginx_site '00-gzip' do
  cookbook 'nginx_lwrp'
  template 'gzip.conf.erb'
end

# Or you can fine tune it.
nginx_site '01-gzip' do
  cookbook 'nginx_lwrp'
  template 'gzip.conf.erb'
  variables(
    enabled: true,
    http_version: '1.0',
    comp_version: 4,
    proxied: 'any',
    types: %w( text/plain text/css ),
    vary: 'off'
  )
end

some-handy-defaults.conf.erb

Defaults to:

sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
reset_timedout_connection off;

keepalive_timeout 65;

How to use:

# Use its default parameters.
nginx_site '02-some-handy-defaults' do
  cookbook 'nginx_lwrp'
  template 'some-handy-defaults.conf.erb'
end

# Or you can fine tune it.
nginx_site '03-some-handy-defaults' do
  cookbook 'nginx_lwrp'
  template 'some-handy-defaults.conf.erb'
  variables(
    sendfile: 'on',
    tcp_nopush: 'on',
    tcp_nodelay: 'on',
    server_tokens: 'off',
    reset_timedout_connection: 'off',
    keepalive_timeout: 65
  )
end

nginx_logrotate

This resource and definition are deprecated right now. There are new attributes for log rotation configuration now:

node.default['nginx']['logrotate']['OPTION'] = 'VALUE'

Default logrotate configuration:

/var/log/nginx/*.log {
    daily
    missingok
    notifempty
    rotate 7
    compress
    create 640 root adm
    delaycompress
    sharedscripts
    postrotate
      test -f /var/run/nginx.pid && kill -USR1 "$(cat /var/run/nginx.pid)"
    endscript
}

Attributes

<table> <thead> <tr> <th>Attribute</th> <th>Description</th> <th>Default Value</th> </tr> </thead> <tbody> <tr> <td>logs</td> <td>Log files to be rotated. Wildcards are allowed.</td> <td>/var/log/nginx/*.log</td> </tr> <tr> <td>how_often</td> <td>Defines how often we should rotate logs. Allowed values are <i>daily</i>, <i>weekly</i>, <i>monthly</i>.</td> <td>daily</td> </tr> <tr> <td>copytruncate</td> <td>If true truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one.</td> <td><code>false</code></td> </tr> <tr> <td>dateext</td> <td>If true archive old versions of log files adding a daily extension like YYYYMMDD instead of simply adding a number. The extension may be configured using the dateformat option.</td> <td><code>false</code></td> </tr> <tr> <td>delaycompress</td> <td>If true postpone compression of the previous log file to the next rotation cycle. This only has effect when used in combination with compress. It can be used when some program cannot be told to close its logfile and thus might continue writing to the previous log file for some time.</td> <td><code>true</code></td> </tr> <tr> <td>rotate</td> <td>Log files are rotated this number of times before being removed.</td> <td>7</td> </tr> <tr> <td>user</td> <td>Specifies the user name who will own the log file.</td> <td>root</td> </tr> <tr> <td>group</td> <td>Specifies the group the log file will belong to.</td> <td>adm</td> </tr> <tr> <td>mode</td> <td>Specifies the mode for the log file in octal.</td> <td>640</td> </tr> <tr> <td>pidfile</td> <td>Path to file that contains pid nuber of Nginx master process. If copytruncate is set to false we should send USR1 signal to that Nginx process to make it reopen log files after log rotation.</td> <td>/var/run/nginx.pid</td> </tr> </tbody> </table>

nginx_disable_cleanup

This resource is deprecated right now.

nginx_logrotate_template

This resource is deprecated right now.

nginx_cleanup

This definitions is deprecated right now. Use attribute to disable cleanup:

node.default['nginx']['enable_cleanup'] = false

Sponsored by Evil Martians

License and Author

Kirill Kouznetsov (agon.smith@gmail.com)

Copyright (C) 2012-2018 Kirill Kouznetsov

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Dependent cookbooks

apt >= 0.0.0

Contingent cookbooks

There are no cookbooks that are contingent upon this one.

nginx_lwrp cookbook CHANGELOG

3.0.0 (2018-03-20)

  • [Breaking change] Chef 12 is not supported anymore, see below for comments.
  • [Breaking change] no more nginx_disable_cleanup definition
  • [Breaking change] no more nginx_logrotate definition
  • Chef 13 support
  • cookbook name was changed to nginx_lwrp to add this cookbook to Supermarket.
  • new list of supported OSes:
    • Ubuntu 14.04
    • Ubuntu 16.04
    • Debian 8
    • Debian 9
  • LWRPs were rewritten using new style
  • Inspec is used instead of ServerSpec now
  • Gemfile update
  • Rubocop offences were fixed
  • Foodcritic offences were fixed

Please be warned!!! Сhef 12 is reaching its EOL in April 2018 and will be removed from downloads.chef.io so it doesn't make sense to continue its support, so I'm dropping Chef 12 support starting from version 3.0.0 of this cookbook in favor of Chef 13 support.

2.3.5 (2017-03-24)

  • nginx.conf template should accept load_module option.

2.3.4 (2016-11-02)

  • DH param file was renames to the expected one.

2.3.3 (2016-10-04)

  • Descent DH params file is generated after nginx package installation.

2.3.2 (2016-)

  • Test Kitchen: Debian 7 was added to the test suite.
  • mainconfig_include_file option was added.
  • Now using correct dummy template for config file for custom includes to main nginx config.

2.3.1 (2016-02-03)

  • Returned some back compatibility with Chef 11. As it was broken by me in previous release.

2.3.0 (2015-11-03)

  • New resource nginx_streams. Which uses the same provider as nginx_sites but manages streams-available & streams-enabled directories.
  • Provider Chef::Provider::NginxSites refactored to support logic for previously mentioned change.

2.2.7 (2015-06-07)

  • Bugfix: Making sure Nginx process is not stalled after initial installation.

2.2.6 (2015-06-07)

  • Issue #10 fix.

2.2.5 (2015-06-07)

  • Quotation marks around file modes in chef recipes.
  • New default mime type: woff2.

2.2.4

  • recipe[nginx::official-repo] that sets up official apt repository on Debian/Ubuntu.
  • First cookbook dependency cookbook[apt]

2.2.3

  • helper template with some handy default variables.
  • nginx logrotate accepts more options to be configured: dateext and delaycompress
  • gzip template default behaviour fix.

Collaborator Number Metric
            

3.0.0 failed this metric

Failure: Cookbook has 0 collaborators. A cookbook must have at least 2 collaborators to pass this metric.

Contributing File Metric
            

3.0.0 passed this metric

Foodcritic Metric
            

3.0.0 failed this metric

FC117: Do not use kind_of in custom resource properties: nginx_lwrp/resources/cleanup.rb:26
FC117: Do not use kind_of in custom resource properties: nginx_lwrp/resources/site_and_stream.rb:28
FC117: Do not use kind_of in custom resource properties: nginx_lwrp/resources/site_and_stream.rb:29
FC117: Do not use kind_of in custom resource properties: nginx_lwrp/resources/site_and_stream.rb:30
FC118: Resource property setting name_attribute vs. name_property: nginx_lwrp/resources/cleanup.rb:26
Run with Foodcritic Version 13.0.0 with tags metadata,correctness ~FC031 ~FC045 and failure tags any

License Metric
            

3.0.0 passed this metric

No Binaries Metric
            

3.0.0 passed this metric

Publish Metric
            

3.0.0 passed this metric

Supported Platforms Metric
            

3.0.0 passed this metric

Testing File Metric
            

3.0.0 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a TESTING.md file

Version Tag Metric
            

3.0.0 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must include a tag that matches this cookbook version number