From 49c8f8eafe5353fd76c1904a41406716ab5a789e Mon Sep 17 00:00:00 2001 From: leslitagordita Date: Fri, 25 Jan 2019 17:00:33 -0500 Subject: [PATCH 1/3] Update guide and deprecate previous version --- .../index.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md index 3e9a2542bd5..2fb776e3941 100644 --- a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md @@ -2,7 +2,7 @@ author: name: Linode description: 'Learn how to efficiently use Puppet modules to manage files and services, create templates, and store data in Hiera in this simple tutorial.' -keywords: ["puppet", "automation", "lamp", "configuration management"] +keywords: ["puppet", "automation", "puppet master", "puppet agent", "modules", "configuration management"] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' aliases: ['applications/puppet/create-puppet-module/','applications/configuration-management/create-puppet-module/'] modified: 2019-01-25 @@ -20,7 +20,7 @@ In this guide, you will create an Apache and a PHP module. A MySQL module will b ## Before You Begin -Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and CentOS 7) by following the steps in the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup) guide. +1. Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and Centos 7) by following the steps in the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup) guide. ## Create the Apache Module @@ -29,12 +29,12 @@ Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and Ce cd /etc/puppetlabs/code/environments/production/modules/ sudo mkdir apache -1. From within the `apache` directory, create `manifests`, `templates`, `files`, and `examples` directories: +2. From within the `apache` directory, create `manifests`, `templates`, `files`, and `examples` directories: cd apache sudo mkdir {manifests,templates,files,examples} -1. Navigate to the `manifests` directory: +3. Navigate to the `manifests` directory: cd manifests @@ -57,9 +57,9 @@ class apache { {{< /file >}} - The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`apache`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. + The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`'apache'`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. -1. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. +2. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. Create a `params.pp` and add the following code: @@ -88,7 +88,7 @@ class apache::params { For the duration of this guide, when something needs to be added to the parameter list the variables needed for Red Hat and Debian will be provided, but the expanding code will not be shown. A complete copy of `params.pp` can be viewed [here](/docs/assets/params.pp). {{< /note >}} -1. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): +4. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} class apache ( @@ -107,7 +107,7 @@ The Apache configuration file will be different depending on whether you are wor 1. Copy the content of `httpd.conf` and `apache2.conf` in separate files and save them in the `files` directory located at `/etc/puppetlabs/code/environments/production/modules/apache/files`. -1. Both files need to be edited to disable keepalive. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: +2. Both files need to be edited to turn `KeepAlive` settings to `Off`. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf" aconf >}} # This file is managed by Puppet @@ -115,7 +115,7 @@ The Apache configuration file will be different depending on whether you are wor {{< /file >}} -1. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: +3. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} file { 'configuration-file': @@ -129,7 +129,7 @@ file { 'configuration-file': Because the configuration file is found in two different locations, the resource is given the generic name `configuration-file` with the file path defined as a parameter with the `path` attribute. `ensure` ensures that it is a file. `source` provides the location on the Puppet master of the files created above. -1. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: +4. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} if $::osfamily == 'RedHat' { @@ -154,7 +154,7 @@ else { These parameters will also need to be added to the beginning of the `apache` class declaration in the `init.pp` file, similar to the previous example. A complete copy of the `init.pp` file can be seen [here](/docs/assets/puppet_apacheinit.pp) for reference. -1. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: +5. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} file { 'configuration-file': @@ -197,7 +197,7 @@ class apache::vhosts { {{< /file >}} -1. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: +3. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: For Red Hat systems: @@ -234,7 +234,7 @@ class apache::vhosts { Only two variables are used in these files: `adminemail` and `servername`. These will be defined on a node-by-node basis, within the `site.pp` file. -1. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: +4. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { @@ -264,7 +264,7 @@ class apache::vhosts { Values containing variables, such as the name of the Debian file resource above, need to be wrapped in double quotes (`"`). Any variables in single quotes (`'`) are parsed exactly as written and will not pull in a variable. {{< /note >}} -1. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: +5. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { @@ -307,7 +307,7 @@ class apache::vhosts { It should return empty, barring any issues. -1. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: +2. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp" puppet >}} $serveremail = 'webmaster@example.com' @@ -319,19 +319,19 @@ include apache::vhosts {{< /file >}} -1. Test the module by running `puppet apply` with the `--noop` tag: +3. Test the module by running `puppet apply` with the `--noop` tag: sudo /opt/puppetlabs/bin/puppet apply --noop init.pp It should return no errors, and output that it will trigger refreshes from events. To install and configure apache on the Puppet master, this can be run again without `--noop` , if so desired. -1. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). +4. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). cd /etc/puppetlabs/code/environments/production/manifests If you are continuing this guide from the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, you should have a `site.pp` file already created. If not, create one now. -1. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: +5. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} node 'ubuntuhost.example.com' { @@ -401,14 +401,14 @@ node 'centospuppet.members.linode.com' { {{}} -1. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: +6. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: sudo /opt/puppetlabs/bin/puppet agent -t ## Using the MySQL Module -Many modules needed to run a server already exist within Puppet Labs' [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. +Many modules needed to run a server already exist within Puppet Lab's [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. Ensure you are in the `/etc/puppetlabs/code/environments/production/modules` directory and install the [Puppet Forge's MySQL module](https://forge.puppetlabs.com/puppetlabs/mysql) by PuppetLabs. This will also install any prerequisite modules. @@ -434,7 +434,7 @@ defaults: {{< /file >}} -1. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: +6. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: {{< file "/etc/puppetlabs/code/environments/production/common.yaml" yaml >}} mysql::server::root_password: 'password' @@ -444,7 +444,7 @@ mysql::server::root_password: 'password' The `common.yaml` file is used when a variable is not defined elsewhere. This means all servers will share the same MySQL root password. These passwords can also be hashed to increase security. -1. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: +7. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: {{< file >}} node 'ubupuppet.members.linode.com' { @@ -487,7 +487,7 @@ node 'centospuppet.members.linode.com' { } {{}} -1. You can run these updates manually on each node by SSHing into each node and issuing the following command: +8. You can run these updates manually on each node by SSHing into each node and issuing the following command: sudo /opt/puppetlabs/bin/puppet agent -t @@ -502,7 +502,7 @@ node 'centospuppet.members.linode.com' { cd php sudo mkdir {files,manifests,examples,templates} -1. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: +2. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: {{< file "/etc/puppetlabs/code/environments/production/modules/php/manifests/init.pp" puppet >}} class php { @@ -520,7 +520,7 @@ class php { {{< /file >}} -1. Add `include php` to the hosts in your `sites.pp` file: +5. Add `include php` to the hosts in your `sites.pp` file: {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} node 'ubupuppet.members.linode.com' { @@ -546,7 +546,7 @@ class php { } {{}} -1. Run the following command on your agent nodes to pull in any changes to your servers. +6. Run the following command on your agent nodes to pull in any changes to your servers. sudo /opt/puppetlabs/bin/puppet agent -t From 0d871f0dcd6393378dd7f6bf367cdec379be3a14 Mon Sep 17 00:00:00 2001 From: cwlinode Date: Tue, 29 Jan 2019 14:43:15 -0500 Subject: [PATCH 2/3] Copy edited --- .../index.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md index 2fb776e3941..3e9a2542bd5 100644 --- a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md @@ -2,7 +2,7 @@ author: name: Linode description: 'Learn how to efficiently use Puppet modules to manage files and services, create templates, and store data in Hiera in this simple tutorial.' -keywords: ["puppet", "automation", "puppet master", "puppet agent", "modules", "configuration management"] +keywords: ["puppet", "automation", "lamp", "configuration management"] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' aliases: ['applications/puppet/create-puppet-module/','applications/configuration-management/create-puppet-module/'] modified: 2019-01-25 @@ -20,7 +20,7 @@ In this guide, you will create an Apache and a PHP module. A MySQL module will b ## Before You Begin -1. Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and Centos 7) by following the steps in the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup) guide. +Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and CentOS 7) by following the steps in the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup) guide. ## Create the Apache Module @@ -29,12 +29,12 @@ In this guide, you will create an Apache and a PHP module. A MySQL module will b cd /etc/puppetlabs/code/environments/production/modules/ sudo mkdir apache -2. From within the `apache` directory, create `manifests`, `templates`, `files`, and `examples` directories: +1. From within the `apache` directory, create `manifests`, `templates`, `files`, and `examples` directories: cd apache sudo mkdir {manifests,templates,files,examples} -3. Navigate to the `manifests` directory: +1. Navigate to the `manifests` directory: cd manifests @@ -57,9 +57,9 @@ class apache { {{< /file >}} - The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`'apache'`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. + The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`apache`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. -2. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. +1. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. Create a `params.pp` and add the following code: @@ -88,7 +88,7 @@ class apache::params { For the duration of this guide, when something needs to be added to the parameter list the variables needed for Red Hat and Debian will be provided, but the expanding code will not be shown. A complete copy of `params.pp` can be viewed [here](/docs/assets/params.pp). {{< /note >}} -4. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): +1. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} class apache ( @@ -107,7 +107,7 @@ The Apache configuration file will be different depending on whether you are wor 1. Copy the content of `httpd.conf` and `apache2.conf` in separate files and save them in the `files` directory located at `/etc/puppetlabs/code/environments/production/modules/apache/files`. -2. Both files need to be edited to turn `KeepAlive` settings to `Off`. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: +1. Both files need to be edited to disable keepalive. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf" aconf >}} # This file is managed by Puppet @@ -115,7 +115,7 @@ The Apache configuration file will be different depending on whether you are wor {{< /file >}} -3. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: +1. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} file { 'configuration-file': @@ -129,7 +129,7 @@ file { 'configuration-file': Because the configuration file is found in two different locations, the resource is given the generic name `configuration-file` with the file path defined as a parameter with the `path` attribute. `ensure` ensures that it is a file. `source` provides the location on the Puppet master of the files created above. -4. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: +1. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} if $::osfamily == 'RedHat' { @@ -154,7 +154,7 @@ else { These parameters will also need to be added to the beginning of the `apache` class declaration in the `init.pp` file, similar to the previous example. A complete copy of the `init.pp` file can be seen [here](/docs/assets/puppet_apacheinit.pp) for reference. -5. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: +1. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} file { 'configuration-file': @@ -197,7 +197,7 @@ class apache::vhosts { {{< /file >}} -3. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: +1. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: For Red Hat systems: @@ -234,7 +234,7 @@ class apache::vhosts { Only two variables are used in these files: `adminemail` and `servername`. These will be defined on a node-by-node basis, within the `site.pp` file. -4. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: +1. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { @@ -264,7 +264,7 @@ class apache::vhosts { Values containing variables, such as the name of the Debian file resource above, need to be wrapped in double quotes (`"`). Any variables in single quotes (`'`) are parsed exactly as written and will not pull in a variable. {{< /note >}} -5. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: +1. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { @@ -307,7 +307,7 @@ class apache::vhosts { It should return empty, barring any issues. -2. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: +1. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: {{< file "/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp" puppet >}} $serveremail = 'webmaster@example.com' @@ -319,19 +319,19 @@ include apache::vhosts {{< /file >}} -3. Test the module by running `puppet apply` with the `--noop` tag: +1. Test the module by running `puppet apply` with the `--noop` tag: sudo /opt/puppetlabs/bin/puppet apply --noop init.pp It should return no errors, and output that it will trigger refreshes from events. To install and configure apache on the Puppet master, this can be run again without `--noop` , if so desired. -4. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). +1. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). cd /etc/puppetlabs/code/environments/production/manifests If you are continuing this guide from the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, you should have a `site.pp` file already created. If not, create one now. -5. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: +1. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} node 'ubuntuhost.example.com' { @@ -401,14 +401,14 @@ node 'centospuppet.members.linode.com' { {{}} -6. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: +1. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: sudo /opt/puppetlabs/bin/puppet agent -t ## Using the MySQL Module -Many modules needed to run a server already exist within Puppet Lab's [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. +Many modules needed to run a server already exist within Puppet Labs' [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. Ensure you are in the `/etc/puppetlabs/code/environments/production/modules` directory and install the [Puppet Forge's MySQL module](https://forge.puppetlabs.com/puppetlabs/mysql) by PuppetLabs. This will also install any prerequisite modules. @@ -434,7 +434,7 @@ defaults: {{< /file >}} -6. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: +1. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: {{< file "/etc/puppetlabs/code/environments/production/common.yaml" yaml >}} mysql::server::root_password: 'password' @@ -444,7 +444,7 @@ mysql::server::root_password: 'password' The `common.yaml` file is used when a variable is not defined elsewhere. This means all servers will share the same MySQL root password. These passwords can also be hashed to increase security. -7. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: +1. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: {{< file >}} node 'ubupuppet.members.linode.com' { @@ -487,7 +487,7 @@ node 'centospuppet.members.linode.com' { } {{}} -8. You can run these updates manually on each node by SSHing into each node and issuing the following command: +1. You can run these updates manually on each node by SSHing into each node and issuing the following command: sudo /opt/puppetlabs/bin/puppet agent -t @@ -502,7 +502,7 @@ node 'centospuppet.members.linode.com' { cd php sudo mkdir {files,manifests,examples,templates} -2. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: +1. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: {{< file "/etc/puppetlabs/code/environments/production/modules/php/manifests/init.pp" puppet >}} class php { @@ -520,7 +520,7 @@ class php { {{< /file >}} -5. Add `include php` to the hosts in your `sites.pp` file: +1. Add `include php` to the hosts in your `sites.pp` file: {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} node 'ubupuppet.members.linode.com' { @@ -546,7 +546,7 @@ class php { } {{}} -6. Run the following command on your agent nodes to pull in any changes to your servers. +1. Run the following command on your agent nodes to pull in any changes to your servers. sudo /opt/puppetlabs/bin/puppet agent -t From ce633d95afb285fb844ee59b0137d72d60c5f229 Mon Sep 17 00:00:00 2001 From: nmelehan Date: Tue, 12 Feb 2019 12:55:58 -0500 Subject: [PATCH 3/3] [Update] Use Puppet Modules to Create a LAMP Stack The previous PR (#2280) for this guide still had issues which needed a tech edit to resolve after the PR was merged. This commit represents that tech edit. --- .../apache2.conf | 223 +++++++++ .../httpd.conf | 360 +++++++++++++++ .../index.md | 431 ++++++++++-------- .../init.pp | 26 ++ .../params.pp | 15 + .../vhosts.pp | 34 ++ .../index.md | 2 +- 7 files changed, 901 insertions(+), 190 deletions(-) create mode 100644 docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/apache2.conf create mode 100644 docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/httpd.conf create mode 100644 docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/init.pp create mode 100644 docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/params.pp create mode 100644 docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/vhosts.pp diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/apache2.conf b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/apache2.conf new file mode 100644 index 00000000000..9017c316fd7 --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/apache2.conf @@ -0,0 +1,223 @@ +# This file is managed by Puppet +# +# This is the main Apache server configuration file. It contains the +# configuration directives that give the server its instructions. +# See http://httpd.apache.org/content/2.4/ for detailed information about +# the directives and /usr/share/doc/apache2/README.Debian about Debian specific +# hints. +# +# +# Summary of how the Apache 2 configuration works in Debian: +# The Apache 2 web server configuration in Debian is quite different to +# upstream's suggested way to configure the web server. This is because Debian's +# default Apache2 installation attempts to make adding and removing modules, +# virtual hosts, and extra configuration directives as flexible as possible, in +# order to make automating the changes and administering the server as easy as +# possible. + +# It is split into several files forming the configuration hierarchy outlined +# below, all located in the /etc/apache2/ directory: +# +# /etc/apache2/ +# |-- apache2.conf +# | `-- ports.conf +# |-- mods-enabled +# | |-- *.load +# | `-- *.conf +# |-- conf-enabled +# | `-- *.conf +# `-- sites-enabled +# `-- *.conf +# +# +# * apache2.conf is the main configuration file (this file). It puts the pieces +# together by including all remaining configuration files when starting up the +# web server. +# +# * ports.conf is always included from the main configuration file. It is +# supposed to determine listening ports for incoming connections which can be +# customized anytime. +# +# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/ +# directories contain particular configuration snippets which manage modules, +# global configuration fragments, or virtual host configurations, +# respectively. +# +# They are activated by symlinking available configuration files from their +# respective *-available/ counterparts. These should be managed by using our +# helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See +# their respective man pages for detailed information. +# +# * The binary is called apache2. Due to the use of environment variables, in +# the default configuration, apache2 needs to be started/stopped with +# /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not +# work with the default configuration. + + +# Global configuration +# + +# +# ServerRoot: The top of the directory tree under which the server's +# configuration, error, and log files are kept. +# +# NOTE! If you intend to place this on an NFS (or otherwise network) +# mounted filesystem then please read the Mutex documentation (available +# at ); +# you will save yourself a lot of trouble. +# +# Do NOT add a slash at the end of the directory path. +# +#ServerRoot "/etc/apache2" + +# +# The accept serialization lock file MUST BE STORED ON A LOCAL DISK. +# +Mutex file:${APACHE_LOCK_DIR} default + +# +# PidFile: The file in which the server should record its process +# identification number when it starts. +# This needs to be set in /etc/apache2/envvars +# +PidFile ${APACHE_PID_FILE} + +# +# Timeout: The number of seconds before receives and sends time out. +# +Timeout 300 + +# +# KeepAlive: Whether or not to allow persistent connections (more than +# one request per connection). Set to "Off" to deactivate. +# +KeepAlive On + +# +# MaxKeepAliveRequests: The maximum number of requests to allow +# during a persistent connection. Set to 0 to allow an unlimited amount. +# We recommend you leave this number high, for maximum performance. +# +MaxKeepAliveRequests 100 + +# +# KeepAliveTimeout: Number of seconds to wait for the next request from the +# same client on the same connection. +# +KeepAliveTimeout 5 + + +# These need to be set in /etc/apache2/envvars +User ${APACHE_RUN_USER} +Group ${APACHE_RUN_GROUP} + +# +# HostnameLookups: Log the names of clients or just their IP addresses +# e.g., www.apache.org (on) or 204.62.129.132 (off). +# The default is off because it'd be overall better for the net if people +# had to knowingly turn this feature on, since enabling it means that +# each client request will result in AT LEAST one lookup request to the +# nameserver. +# +HostnameLookups Off + +# ErrorLog: The location of the error log file. +# If you do not specify an ErrorLog directive within a +# container, error messages relating to that virtual host will be +# logged here. If you *do* define an error logfile for a +# container, that host's errors will be logged there and not here. +# +ErrorLog ${APACHE_LOG_DIR}/error.log + +# +# LogLevel: Control the severity of messages logged to the error_log. +# Available values: trace8, ..., trace1, debug, info, notice, warn, +# error, crit, alert, emerg. +# It is also possible to configure the log level for particular modules, e.g. +# "LogLevel info ssl:warn" +# +LogLevel warn + +# Include module configuration: +IncludeOptional mods-enabled/*.load +IncludeOptional mods-enabled/*.conf + +# Include list of ports to listen on +Include ports.conf + + +# Sets the default security model of the Apache2 HTTPD server. It does +# not allow access to the root filesystem outside of /usr/share and /var/www. +# The former is used by web applications packaged in Debian, +# the latter may be used for local directories served by the web server. If +# your system is serving content from a sub-directory in /srv you must allow +# access here, or in any related virtual host. + + Options FollowSymLinks + AllowOverride None + Require all denied + + + + AllowOverride None + Require all granted + + + + Options Indexes FollowSymLinks + AllowOverride None + Require all granted + + +# +# Options Indexes FollowSymLinks +# AllowOverride None +# Require all granted +# + + + + +# AccessFileName: The name of the file to look for in each directory +# for additional configuration directives. See also the AllowOverride +# directive. +# +AccessFileName .htaccess + +# +# The following lines prevent .htaccess and .htpasswd files from being +# viewed by Web clients. +# + + Require all denied + + + +# +# The following directives define some format nicknames for use with +# a CustomLog directive. +# +# These deviate from the Common Log Format definitions in that they use %O +# (the actual bytes sent including headers) instead of %b (the size of the +# requested file), because the latter makes it impossible to detect partial +# requests. +# +# Note that the use of %{X-Forwarded-For}i instead of %h is not recommended. +# Use mod_remoteip instead. +# +LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined +LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined +LogFormat "%h %l %u %t \"%r\" %>s %O" common +LogFormat "%{Referer}i -> %U" referer +LogFormat "%{User-agent}i" agent + +# Include of directories ignores editors' and dpkg's backup files, +# see README.Debian for details. + +# Include generic snippets of statements +IncludeOptional conf-enabled/*.conf + +# Include the virtual host configurations: +IncludeOptional sites-enabled/*.conf + +# vim: syntax=apache ts=4 sw=4 sts=4 sr noet diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/httpd.conf b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/httpd.conf new file mode 100644 index 00000000000..3bfbfae08f2 --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/httpd.conf @@ -0,0 +1,360 @@ +# This file is managed by Puppet +# +# This is the main Apache HTTP server configuration file. It contains the +# configuration directives that give the server its instructions. +# See for detailed information. +# In particular, see +# +# for a discussion of each configuration directive. +# +# Do NOT simply read the instructions in here without understanding +# what they do. They're here only as hints or reminders. If you are unsure +# consult the online docs. You have been warned. +# +# Configuration and logfile names: If the filenames you specify for many +# of the server's control files begin with "/" (or "drive:/" for Win32), the +# server will use that explicit path. If the filenames do *not* begin +# with "/", the value of ServerRoot is prepended -- so 'log/access_log' +# with ServerRoot set to '/www' will be interpreted by the +# server as '/www/log/access_log', where as '/log/access_log' will be +# interpreted as '/log/access_log'. + +# +# ServerRoot: The top of the directory tree under which the server's +# configuration, error, and log files are kept. +# +# Do not add a slash at the end of the directory path. If you point +# ServerRoot at a non-local disk, be sure to specify a local disk on the +# Mutex directive, if file-based mutexes are used. If you wish to share the +# same ServerRoot for multiple httpd daemons, you will need to change at +# least PidFile. +# +ServerRoot "/etc/httpd" + +# +# Listen: Allows you to bind Apache to specific IP addresses and/or +# ports, instead of the default. See also the +# directive. +# +# Change this to Listen on specific IP addresses as shown below to +# prevent Apache from glomming onto all bound IP addresses. +# +#Listen 12.34.56.78:80 +Listen 80 + +# +# Dynamic Shared Object (DSO) Support +# +# To be able to use the functionality of a module which was built as a DSO you +# have to place corresponding `LoadModule' lines at this location so the +# directives contained in it are actually available _before_ they are used. +# Statically compiled modules (those listed by `httpd -l') do not need +# to be loaded here. +# +# Example: +# LoadModule foo_module modules/mod_foo.so +# +Include conf.modules.d/*.conf + +# +# If you wish httpd to run as a different user or group, you must run +# httpd as root initially and it will switch. +# +# User/Group: The name (or #number) of the user/group to run httpd as. +# It is usually good practice to create a dedicated user and group for +# running httpd, as with most system services. +# +User apache +Group apache + +# 'Main' server configuration +# +# The directives in this section set up the values used by the 'main' +# server, which responds to any requests that aren't handled by a +# definition. These values also provide defaults for +# any containers you may define later in the file. +# +# All of these directives may appear inside containers, +# in which case these default settings will be overridden for the +# virtual host being defined. +# + +# +# ServerAdmin: Your address, where problems with the server should be +# e-mailed. This address appears on some server-generated pages, such +# as error documents. e.g. admin@your-domain.com +# +ServerAdmin root@localhost + +# +# ServerName gives the name and port that the server uses to identify itself. +# This can often be determined automatically, but we recommend you specify +# it explicitly to prevent problems during startup. +# +# If your host doesn't have a registered DNS name, enter its IP address here. +# +#ServerName www.example.com:80 + +# +# Deny access to the entirety of your server's filesystem. You must +# explicitly permit access to web content directories in other +# blocks below. +# + + AllowOverride none + Require all denied + + +# +# Note that from this point forward you must specifically allow +# particular features to be enabled - so if something's not working as +# you might expect, make sure that you have specifically enabled it +# below. +# + +# +# DocumentRoot: The directory out of which you will serve your +# documents. By default, all requests are taken from this directory, but +# symbolic links and aliases may be used to point to other locations. +# +DocumentRoot "/var/www/html" + +# +# Relax access to content within /var/www. +# + + AllowOverride None + # Allow open access: + Require all granted + + +# Further relax access to the default document root: + + # + # Possible values for the Options directive are "None", "All", + # or any combination of: + # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews + # + # Note that "MultiViews" must be named *explicitly* --- "Options All" + # doesn't give it to you. + # + # The Options directive is both complicated and important. Please see + # http://httpd.apache.org/content/2.4/mod/core.html#options + # for more information. + # + Options Indexes FollowSymLinks + + # + # AllowOverride controls what directives may be placed in .htaccess files. + # It can be "All", "None", or any combination of the keywords: + # Options FileInfo AuthConfig Limit + # + AllowOverride None + + # + # Controls who can get stuff from this server. + # + Require all granted + + +# +# DirectoryIndex: sets the file that Apache will serve if a directory +# is requested. +# + + DirectoryIndex index.html + + +# +# The following lines prevent .htaccess and .htpasswd files from being +# viewed by Web clients. +# + + Require all denied + + +# +# ErrorLog: The location of the error log file. +# If you do not specify an ErrorLog directive within a +# container, error messages relating to that virtual host will be +# logged here. If you *do* define an error logfile for a +# container, that host's errors will be logged there and not here. +# +ErrorLog "logs/error_log" + +# +# LogLevel: Control the number of messages logged to the error_log. +# Possible values include: debug, info, notice, warn, error, crit, +# alert, emerg. +# +LogLevel warn + + + # + # The following directives define some format nicknames for use with + # a CustomLog directive (see below). + # + LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined + LogFormat "%h %l %u %t \"%r\" %>s %b" common + + + # You need to enable mod_logio.c to use %I and %O + LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio + + + # + # The location and format of the access logfile (Common Logfile Format). + # If you do not define any access logfiles within a + # container, they will be logged here. Contrariwise, if you *do* + # define per- access logfiles, transactions will be + # logged therein and *not* in this file. + # + #CustomLog "logs/access_log" common + + # + # If you prefer a logfile with access, agent, and referer information + # (Combined Logfile Format) you can use the following directive. + # + CustomLog "logs/access_log" combined + + + + # + # Redirect: Allows you to tell clients about documents that used to + # exist in your server's namespace, but do not anymore. The client + # will make a new request for the document at its new location. + # Example: + # Redirect permanent /foo http://www.example.com/bar + + # + # Alias: Maps web paths into filesystem paths and is used to + # access content that does not live under the DocumentRoot. + # Example: + # Alias /webpath /full/filesystem/path + # + # If you include a trailing / on /webpath then the server will + # require it to be present in the URL. You will also likely + # need to provide a section to allow access to + # the filesystem path. + + # + # ScriptAlias: This controls which directories contain server scripts. + # ScriptAliases are essentially the same as Aliases, except that + # documents in the target directory are treated as applications and + # run by the server when requested rather than as documents sent to the + # client. The same rules about trailing "/" apply to ScriptAlias + # directives as to Alias. + # + ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" + + + +# +# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased +# CGI directory exists, if you have that configured. +# + + AllowOverride None + Options None + Require all granted + + + + # + # TypesConfig points to the file containing the list of mappings from + # filename extension to MIME-type. + # + TypesConfig /etc/mime.types + + # + # AddType allows you to add to or override the MIME configuration + # file specified in TypesConfig for specific file types. + # + #AddType application/x-gzip .tgz + # + # AddEncoding allows you to have certain browsers uncompress + # information on the fly. Note: Not all browsers support this. + # + #AddEncoding x-compress .Z + #AddEncoding x-gzip .gz .tgz + # + # If the AddEncoding directives above are commented-out, then you + # probably should define those extensions to indicate media types: + # + AddType application/x-compress .Z + AddType application/x-gzip .gz .tgz + + # + # AddHandler allows you to map certain file extensions to "handlers": + # actions unrelated to filetype. These can be either built into the server + # or added with the Action directive (see below) + # + # To use CGI scripts outside of ScriptAliased directories: + # (You will also need to add "ExecCGI" to the "Options" directive.) + # + #AddHandler cgi-script .cgi + + # For type maps (negotiated resources): + #AddHandler type-map var + + # + # Filters allow you to process content before it is sent to the client. + # + # To parse .shtml files for server-side includes (SSI): + # (You will also need to add "Includes" to the "Options" directive.) + # + AddType text/html .shtml + AddOutputFilter INCLUDES .shtml + + +# +# Specify a default charset for all content served; this enables +# interpretation of all content as UTF-8 by default. To use the +# default browser choice (ISO-8859-1), or to allow the META tags +# in HTML content to override this choice, comment out this +# directive: +# +AddDefaultCharset UTF-8 + + + # + # The mod_mime_magic module allows the server to use various hints from the + # contents of the file itself to determine its type. The MIMEMagicFile + # directive tells the module where the hint definitions are located. + # + MIMEMagicFile conf/magic + + +# +# Customizable error responses come in three flavors: +# 1) plain text 2) local redirects 3) external redirects +# +# Some examples: +#ErrorDocument 500 "The server made a boo boo." +#ErrorDocument 404 /missing.html +#ErrorDocument 404 "/cgi-bin/missing_handler.pl" +#ErrorDocument 402 http://www.example.com/subscription_info.html +# + +# +# EnableMMAP and EnableSendfile: On systems that support it, +# memory-mapping or the sendfile syscall may be used to deliver +# files. This usually improves server performance, but must +# be turned off when serving from networked-mounted +# filesystems or if support for these functions is otherwise +# broken on your system. +# Defaults if commented: EnableMMAP On, EnableSendfile Off +# +#EnableMMAP off +EnableSendfile on + +# +# KeepAlive: Whether or not to allow persistent connections (more than +# one request per connection). Set to "Off" to deactivate. +# +KeepAlive On + +# Supplemental configuration +# +# Load config files in the "/etc/httpd/conf.d" directory, if any. +IncludeOptional conf.d/*.conf diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md index 3e9a2542bd5..ba34ec237ae 100644 --- a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md @@ -8,13 +8,13 @@ aliases: ['applications/puppet/create-puppet-module/','applications/configuratio modified: 2019-01-25 modified_by: name: Linode -published: 2015-01-25 +published: 2019-01-25 title: Use Puppet Modules to Create a LAMP Stack --- ![Use Puppet Modules to Create a LAMP Stack](Use_Puppet_Modules_to_Create_a_LAMP_Stack_smg.jpg) -Puppet modules are the building blocks of your Puppet managed servers. Modules install and configure packages, create directories, and generate any other server changes that the user includes in the module. A Puppet module aims to perform all parts of a certain task, such as downloading the Apache package, configuring all files, changing the MPM data, and setting up virtual hosts. Modules are, in turn, broken down into classes that are `.pp` files meant to simplify the module into various tasks and improve the module's readability for any future users. +Puppet modules are the building blocks of your Puppet managed servers. Modules install and configure packages, create directories, and generate any other server changes that the user includes in the module. A Puppet module aims to perform all parts of a certain task, such as downloading the Apache package, configuring all files, changing the MPM data, and setting up virtual hosts. In this guide, you will create an Apache and a PHP module. A MySQL module will be adapted from the Puppet Lab's MySQL module found on the [Puppet Forge](https://forge.puppet.com/). These steps will create a full LAMP stack on your server and provide an overview of the various ways modules can be utilized. @@ -24,6 +24,8 @@ Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and Ce ## Create the Apache Module +Modules are composed of classes that represent various tasks and that improve the module's readability for any future users. These classes are stored within manifest files (ending in the `.pp` extension) that are located within specific directories inside the module. + 1. From the Puppet Master, navigate to Puppet's module directory and create the `apache` directory: cd /etc/puppetlabs/code/environments/production/modules/ @@ -38,13 +40,18 @@ Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and Ce cd manifests - From here, the module will be separated into classes, based on the goals of that particular section of code. In this instance, there will be an `init.pp` class for downloading the Apache package, a `params.pp` file to define any variables and parameters, `config.pp` to manage any configuration files for the Apache service itself, and a `vhosts.pp` file to define the virtual hosts. This module will also make use of [Hiera](http://docs.puppetlabs.com/hiera/latest/) data to store variables for each node. + Your module's classes are stored in the `manifests` directory. The manifests and classes that will be created for our example module include: + + - An `init.pp` manifest that contains the *main* class for the module. This module will download the Apache package and enable the service. + - A `params.pp` manifest that defines variables and parameters. + - A `config.pp` file that configuration files for the Apache service itself. + - A `vhosts.pp` file that defines the virtual hosts. ### Create the Initial Apache Class and Parameters -1. From within the `manifests` directory, create an `init.pp` file to hold the `apache` class. This class should share its name with the module name. This file will be used to install the Apache package. Since Ubuntu 18.04 and CentOS 7 use different package names for Apache, a variable will be used: +1. From within `/etc/puppetlabs/code/environments/production/modules/apache/manifests`, create an `init.pp` file to hold the module's main `apache` class. This class should share its name with the module's name. This file will be used to install the Apache package. Since Ubuntu 18.04 and CentOS 7 use different package names for Apache, a variable will be used: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} + {{< file "production/modules/apache/manifests/init.pp" puppet >}} class apache { package { 'apache': @@ -52,18 +59,23 @@ class apache { ensure => present, } -} + service { 'apache-service': + name => $apachename, + hasrestart => true, + enable => true, + ensure => running, + } +} {{< /file >}} + The [`package` resource](https://puppet.com/docs/puppet/6.2/types/package.html) is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`apache`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. - The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`apache`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. + The [`service` resource](https://puppet.com/docs/puppet/6.2/types/service.html) is used to run, stop, restart, enable, and disable services. The `service` resource in this example will also accept the `$apachename` variable to determine which service should be managed. -1. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. +1. Create a `params.pp` in the same directory as `init.pp` and add the following code: - Create a `params.pp` and add the following code: - - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} + {{< file "production/modules/apache/manifests/params.pp" puppet >}} class apache::params { if $::osfamily == 'RedHat' { @@ -82,106 +94,120 @@ class apache::params { Outside of the original `init.pp` class, each class name needs to branch off of `apache`. As such, this class is called `apache::params`. The name after the double colon should share a name with the file. - An `if` statement is used to define the parameters, pulling from information provided by [Facter](https://puppetlabs.com/facter), which is already installed on the Puppet master. In this case, Facter will be used to pull down the operating system family (`osfamily`), to discern if it is Red Hat or Debian-based. - - {{< note >}} -For the duration of this guide, when something needs to be added to the parameter list the variables needed for Red Hat and Debian will be provided, but the expanding code will not be shown. A complete copy of `params.pp` can be viewed [here](/docs/assets/params.pp). -{{< /note >}} + An `if` statement is used to define the parameters, pulling from information provided by [Facter](https://puppetlabs.com/facter), which is already installed on the Puppet master. In this case, Facter will be used to pull down the operating system family (`osfamily`) to discern if it is Red Hat or Debian-based. -1. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): +1. With the parameters defined, we need to call the `params.pp` file and add the parameters into `init.pp`. To do this, the parameters need to be added inside a set of parentheses after the class name, but before the opening curly bracket (`{`): - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} + {{< file "production/modules/apache/manifests/init.pp" puppet >}} class apache ( $apachename = $::apache::params::apachename, ) inherits ::apache::params { {{< /file >}} - - The value string `$::apache::params::value` tells Puppet to pull the values from the `apache` modules, `params` class, followed by the parameter name. The fragment `inherits ::apache::params` allows for `init.pp` to inherit these values. + The value string `$::apache::params::value` tells Puppet to pull the values from the `apache` module's `params` class, followed by the parameter name. The fragment `inherits ::apache::params` allows for `init.pp` to inherit these values. ### Manage Configuration Files -The Apache configuration file will be different depending on whether you are working on a Red Hat- or Debian-based system. These can be viewed here: [httpd.conf (Red Hat)](/docs/assets/httpd.conf), [apache2.conf (Debian)](/docs/assets/apache2.conf). +The Apache configuration file will be different depending on whether you are working on a Red Hat- or Debian-based system. These can be viewed here: [httpd.conf (Red Hat)](httpd.conf), [apache2.conf (Debian)](apache2.conf). -1. Copy the content of `httpd.conf` and `apache2.conf` in separate files and save them in the `files` directory located at `/etc/puppetlabs/code/environments/production/modules/apache/files`. +1. Copy the example `httpd.conf` and `apache2.conf` files provided above to the `files` directory located at `/etc/puppetlabs/code/environments/production/modules/apache/files`. -1. Both files need to be edited to disable keepalive. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: + {{< note >}} +A comment was included at the top of these configuration files: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf" aconf >}} +{{< file >}} # This file is managed by Puppet - {{< /file >}} +If someone were to log in to a Puppet node and then open this file, the comment would let them know that it should not be edited directly. +{{< /note >}} -1. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: +1. Open the `params.pp` file and define two new variables: `$conffile` and `$confsource`. These will map to the correct configuration file locations based on a node's distribution: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} -file { 'configuration-file': - path => $conffile, - ensure => file, - source => $confsource, -} + {{< file "production/modules/apache/manifests/params.pp" puppet >}} +class apache::params { -{{< /file >}} + if $::osfamily == 'RedHat' { + # ... + $conffile = '/etc/httpd/conf/httpd.conf' + $confsource = 'puppet:///modules/apache/httpd.conf' + } + elsif $::osfamily == 'Debian' { + # ... + $conffile = '/etc/apache2/apache2.conf' + $confsource = 'puppet:///modules/apache/apache2.conf' + } + else { + # ... + } +} +{{< /file >}} - Because the configuration file is found in two different locations, the resource is given the generic name `configuration-file` with the file path defined as a parameter with the `path` attribute. `ensure` ensures that it is a file. `source` provides the location on the Puppet master of the files created above. + {{< note >}} +Compare your file with the [completed `params.pp`](params.pp). +{{< /note >}} -1. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: +1. Open `init.pp`. Update the list of class parameters at the top to include your new `$conffile` and `$confsource` variables, and insert the `file` resource between the `package` and `service` resources: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} -if $::osfamily == 'RedHat' { + {{< file "production/modules/apache/manifests/init.pp" puppet >}} +class apache ( + $apachename = $::apache::params::apachename, + $conffile = $::apache::params::conffile, + $confsource = $::apache::params::confsource, +) inherits ::apache::params { -... + package { 'apache': + # ... + } - $conffile = '/etc/httpd/conf/httpd.conf' - $confsource = 'puppet:///modules/apache/httpd.conf' -} -elsif $::osfamily == 'Debian' { + file { 'configuration-file': + path => $conffile, + ensure => file, + source => $confsource, + } -... + service { 'apache-service': + # ... + } - $conffile = '/etc/apache2/apache2.conf' - $confsource = 'puppet:///modules/apache/apache2.conf' } -else { - -... {{< /file >}} + The [`file` resource](https://puppet.com/docs/puppet/6.2/types/file.html) manages files on your nodes. This example copies a file from the Puppet master (at the `source` location) to the Puppet node (at the `path` location). - These parameters will also need to be added to the beginning of the `apache` class declaration in the `init.pp` file, similar to the previous example. A complete copy of the `init.pp` file can be seen [here](/docs/assets/puppet_apacheinit.pp) for reference. +1. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` relationship. This will tell the `service` resource to refresh/restart whenever the configuration file is changed. Insert the `notify` relationship into your `file` resource in `init.pp`: -1. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: + {{< file "production/modules/apache/manifests/init.pp" puppet >}} +class apache ( + # ... +) inherits ::apache::params { - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} -file { 'configuration-file': - path => $conffile, - ensure => file, - source => $confsource, - notify => Service['apache-service'], -} + # ... -service { 'apache-service': - name => $apachename, - hasrestart => true, -} - -{{< /file >}} + file { 'configuration-file': + # ... + notify => Service['apache-service'], + } + # ... - The `service` resource uses the already-created parameter that defined the Apache name on Red Hat and Debian systems. The `hasrestart` attribute will trigger a restart of the defined service. +} +{{< /file >}} + {{< note >}} +Compare your file with the [completed `init.pp`](init.pp). +{{< /note >}} ### Create the Virtual Hosts Files -Depending on your systems distribution the virtual hosts files will be managed differently. Because of this, the code for virtual hosts will be encased in an `if` statement, similar to the one used in the `params.pp` class but containing actual Puppet resources. This will provide an example of an alternate use of `if` statements within Puppet's code. +Depending on your system's distribution, Apache's virtual hosts files will be managed differently. Because of this, the code for virtual hosts will be encased in an `if` statement, similar to the one used in the `params.pp` class, but containing actual Puppet resources. This will provide an example of an alternate use of `if` statements within Puppet's code. -1. From within the `apache/manifests/` directory, create and open a `vhosts.pp` file. Add the skeleton of the `if` statement: +1. From within the `/etc/puppetlabs/code/environments/production/modules/apache/manifests/` directory, create and open a `vhosts.pp` file. Add the skeleton of the `if` statement: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} + {{< file "production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { if $::osfamily == 'RedHat' { @@ -193,148 +219,164 @@ class apache::vhosts { } } - {{< /file >}} +1. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. -1. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: + Navigate to the `templates` file within the `apache` module (full filesystem path: `/etc/puppetlabs/code/environments/production/modules/apache/templates/`) and create two files for your virtual hosts: - For Red Hat systems: + - **CentOS 7** - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb" aconf >}} + {{< file "production/modules/apache/templates/vhosts-rh.conf.erb" aconf >}} ServerAdmin <%= @adminemail %> ServerName <%= @servername %> ServerAlias www.<%= @servername %> DocumentRoot /var/www/<%= @servername -%>/public_html/ - ErrorLog /var/www/<%- @servername -%>/logs/error.log + ErrorLog /var/www/<%= @servername -%>/logs/error.log CustomLog /var/www/<%= @servername -%>/logs/access.log combined - - + {{< /file >}} + - **Ubuntu 18.04** - For Debian systems: - - {{< file "/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb" aconf >}} + {{< file "production/modules/apache/templates/vhosts-deb.conf.erb" aconf >}} ServerAdmin <%= @adminemail %> ServerName <%= @servername %> ServerAlias www.<%= @servername %> - DocumentRoot /var/www/html/<%= @servername -%>/public_html/ - ErrorLog /var/www/html/<%- @servername -%>/logs/error.log - CustomLog /var/www/html/<%= @servername -%>/logs/access.log combined - /public_html> + DocumentRoot /var/www/<%= @servername -%>/public_html/ + ErrorLog /var/www/<%= @servername -%>/logs/error.log + CustomLog /var/www/<%= @servername -%>/logs/access.log combined + /public_html> Require all granted - - + {{< /file >}} - Only two variables are used in these files: `adminemail` and `servername`. These will be defined on a node-by-node basis, within the `site.pp` file. 1. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} + {{< file "production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { if $::osfamily == 'RedHat' { file { '/etc/httpd/conf.d/vhost.conf': ensure => file, content => template('apache/vhosts-rh.conf.erb'), + notify => Service['apache-service'], } } elsif $::osfamily == 'Debian' { file { "/etc/apache2/sites-available/$servername.conf": - ensure => file, - content => template('apache/vhosts-deb.conf.erb'), + ensure => file, + content => template('apache/vhosts-deb.conf.erb'), + notify => Service['apache-service'], + } + file { "/etc/apache2/sites-enabled/$servername.conf": + ensure => 'link', + target => "/etc/apache2/sites-available/$servername.conf", + notify => Service['apache-service'], } } else { fail('This is not a supported distro.') } } - {{< /file >}} - - Both distribution families call to the `file` resource and take on the title of the virtual host's location on the respective distribution. For Debian, this once more means referencing the `$servername` value. The `content` attribute calls to the respective templates. + Both distribution families declare a `file` resource to copy the virtual host configuration from the Puppet master to the node. The Debian family also declares a second `file` resource which creates a symlink from the `sites-enabled` directory to the virtual host in the `sites-available` directory. `notify` relationships are specified for all of these declarations so that Apache will restart when any of these files change. {{< note >}} Values containing variables, such as the name of the Debian file resource above, need to be wrapped in double quotes (`"`). Any variables in single quotes (`'`) are parsed exactly as written and will not pull in a variable. {{< /note >}} -1. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: +1. Both virtual host files reference directories under `/var/www` that do not exist on the Puppet nodes by default. These can be created through the use of the `file` resource, each located within the `if` statement. Add these new directory `file` resources at the top of each `if` clause in your `vhosts.pp`: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} + {{< file "production/modules/apache/manifests/vhosts.pp" puppet >}} class apache::vhosts { if $::osfamily == 'RedHat' { + file { [ "/var/www/$servername", + "/var/www/$servername/public_html", + "/var/www/$servername/log", ]: + ensure => directory, + } + file { '/etc/httpd/conf.d/vhost.conf': - ensure => file, - content => template('apache/vhosts-rh.conf.erb'), + # ... } - file { [ '/var/www/$servername', - '/var/www/$servername/public_html', - '/var/www/$servername/log', ]: + } elsif $::osfamily == 'Debian' { + file { [ "/var/www/$servername", + "/var/www/$servername/public_html", + "/var/www/$servername/logs", ]: ensure => directory, } - } elsif $::osfamily == 'Debian' { + file { "/etc/apache2/sites-available/$servername.conf": - ensure => file, - content => template('apache/vhosts-deb.conf.erb'), - } - file { [ '/var/www/$servername', - '/var/www/$servername/public_html', - '/var/www/$servername/logs', ]: - ensure => directory, + # ... } + # ... } else { - fail ( 'This is not a supported distro.') + # ... } } - {{< /file >}} - + {{< note >}} +Compare your file with the [completed `vhosts.pp`](vhosts.pp). +{{< /note >}} ### Test and Run the Module -1. From within the `apache/manifests/` directory, run the `puppet parser` on all files to ensure the Puppet coding is without error: +1. Run the `puppet parser` on all files to ensure the Puppet code does not contain syntax errors: + cd /etc/puppetlabs/code/environments/production/apache/manifests/ sudo /opt/puppetlabs/bin/puppet parser validate init.pp params.pp vhosts.pp - It should return empty, barring any issues. + If there are no issues, the parser will return with no output. + +1. Navigate to the `examples` directory within the `apache` module: + + cd /etc/puppetlabs/code/environments/production/modules/apache/examples/ -1. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: +1. Create an `init.pp` file with the contents of the following snippet. Replace the values for `$servername` and `$adminemail` with your own: - {{< file "/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp" puppet >}} + {{< file "production/modules/apache/examples/init.pp" puppet >}} $serveremail = 'webmaster@example.com' $servername = 'example.com' include apache include apache::vhosts - {{< /file >}} - 1. Test the module by running `puppet apply` with the `--noop` tag: sudo /opt/puppetlabs/bin/puppet apply --noop init.pp - It should return no errors, and output that it will trigger refreshes from events. To install and configure apache on the Puppet master, this can be run again without `--noop` , if so desired. + It should return no errors, and output that it will trigger refreshes from events. To install and configure Apache on the Puppet master, this can be run again without `--noop` , if desired. -1. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). +1. Navigate back to the main Puppet directory and then to the main `manifests` folder (**not** the one located in the Apache module): cd /etc/puppetlabs/code/environments/production/manifests - If you are continuing this guide from the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, you should have a `site.pp` file already created. If not, create one now. + If you are continuing this guide from the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, you should have a `site.pp` file already created in this directory. If not, create one now. + +1. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. + + - If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, your updated configuration should resemble: -1. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: + {{< file "production/manifests/site.pp" puppet >}} +node default { - {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} -node 'ubuntuhost.example.com' { +} + +node 'puppet.example.com' { + # ... +} + +node 'puppet-agent-ubuntu.example.com' { $adminemail = 'webmaster@example.com' $servername = 'hostname.example.com' @@ -352,10 +394,9 @@ node 'ubuntuhost.example.com' { } class { ['firewall::pre', 'firewall::post']: } +} - } - -node 'centoshost.example.com' { +node 'puppet-agent-centos.example.com' { $adminemail = 'webmaster@example.com' $servername = 'hostname.example.com' @@ -373,39 +414,38 @@ node 'centoshost.example.com' { } class { ['firewall::pre', 'firewall::post']: } - - } +} {{< /file >}} - If you did not follow the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, then your `site.pp` file should resemble the following example: + - If you did not follow [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/), then your new `site.pp` file should resemble: + + {{< file "production/manifests/site.pp" puppet >}} +node default { + +} - {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} -node 'ubupuppet.members.linode.com' { +node 'puppet-agent-ubuntu.example.com' { $adminemail = 'webmaster@example.com' $servername = 'hostname.example.com' include apache include apache::vhosts +} - } - -node 'centospuppet.members.linode.com' { +node 'puppet-agent-centos.example.com' { $adminemail = 'webmaster@example.com' $servername = 'hostname.example.com' include apache include apache::vhosts +} +{{}} - } - {{}} - - -1. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: +1. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually apply the new module to your agent nodes, **log in to the nodes** and run: sudo /opt/puppetlabs/bin/puppet agent -t - ## Using the MySQL Module Many modules needed to run a server already exist within Puppet Labs' [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. @@ -417,11 +457,13 @@ Ensure you are in the `/etc/puppetlabs/code/environments/production/modules` dir ### Use Hiera to Create Databases -Before you begin to create the configuration files for the MySQL module, consider that you may not want the same values to be used across all agent nodes. To supply Puppet with the correct data per node, Hiera is used. In this instance, you will be using a different root password per node, thus creating different MySQL databases. +[Puppet Hiera](https://puppet.com/docs/puppet/6.2/hiera_intro.html) is used to store data that you don't want to include in your Puppet classes. This can be sensitive data like passwords, or it can be non-sensitive but site-specific information. Refactoring site-specific information into Hiera can make your Puppet code more reusable. -1. Navigate to `/etc/puppet` and create Hiera's configuration file `hiera.yaml` in the main `puppet` directory. You will use Hiera's default values: +This example will store the root password for MySQL in Hiera: - {{< file "/etc/puppetlabs/code/environments/production/hiera.yaml" yaml >}} +1. Navigate to `/etc/puppetlabs/code/environments/production/` and create Hiera's configuration file `hiera.yaml`. You will use Hiera's default values: + + {{< file "production/hiera.yaml" yaml >}} --- version: 5 hierarchy: @@ -433,118 +475,129 @@ defaults: {{< /file >}} +1. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL. Enter your own complex and unique password in this file: -1. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: - - {{< file "/etc/puppetlabs/code/environments/production/common.yaml" yaml >}} + {{< file "production/common.yaml" yaml >}} mysql::server::root_password: 'password' - {{< /file >}} - The `common.yaml` file is used when a variable is not defined elsewhere. This means all servers will share the same MySQL root password. These passwords can also be hashed to increase security. -1. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: +1. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. - {{< file >}} -node 'ubupuppet.members.linode.com' { - $adminemail = 'webmaster@example.com' - $servername = 'hostname.example.com' + Edit `site.pp` with the following new declarations. Set your own values for the `user`, `password`, and `dbname` options in the `mysql::db` declaration in each node: + + {{< file "production/site.pp" puppet >}} +# ... + +node 'puppet-agent-ubuntu.example.com' { + # ... include apache include apache::vhosts - include php + + include mysql::server mysql::db { "mydb_${fqdn}": user => 'myuser', password => 'mypass', dbname => 'mydb', - host => $::fqdn, + host => 'localhost', grant => ['SELECT', 'UPDATE'], tag => $domain, } + # ... } -node 'centospuppet.members.linode.com' { - $adminemail = 'webmaster@example.com' - $servername = 'hostname.example.com' +node 'puppet-agent-centos.example.com' { + # ... include apache include apache::vhosts + include mysql::server - include php mysql::db { "mydb_${fqdn}": user => 'myuser', password => 'mypass', dbname => 'mydb', - host => $::fqdn, + host => 'localhost', grant => ['SELECT', 'UPDATE'], tag => $domain, } - } - {{}} - -1. You can run these updates manually on each node by SSHing into each node and issuing the following command: + # ... +} +{{}} - sudo /opt/puppetlabs/bin/puppet agent -t + {{< note >}} +You can also set values for your database's `user`, `password`, and `dbname` in Hiera. Review [Install and Manage MySQL Databases with Puppet Hiera on Ubuntu 18.04](/docs/applications/configuration-management/install-and-manage-mysql-databases-with-puppet-hiera-on-ubuntu-18-04/) for more information on this subject. +{{< /note >}} - Otherwise, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. +1. As before, you can run these updates manually on each node. **Log into each node** via SSH and run: + sudo /opt/puppetlabs/bin/puppet agent -t ## Create the PHP Module -1. Create the `php` directory in the `/etc/puppetlabs/code/environments/production/modules` path, and generate the `files`, `manifests`, `templates`, and `examples` directories afterward: +1. Create the `php` directory in the `/etc/puppetlabs/code/environments/production/modules` path: + cd /etc/puppetlabs/code/environments/production/modules sudo mkdir php + +1. Generate the `files`, `manifests`, `templates`, and `examples` directories that constitute your module's structure: + cd php sudo mkdir {files,manifests,examples,templates} -1. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: +1. Create the new module's `init.pp` inside its `manifests` directory. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository: - {{< file "/etc/puppetlabs/code/environments/production/modules/php/manifests/init.pp" puppet >}} + {{< file "production/modules/php/manifests/init.pp" puppet >}} class php { package { 'php': - name: $phpname, - ensure: present, + ensure => present, } package { 'php-pear': - ensure: present, + ensure => present, } } - {{< /file >}} -1. Add `include php` to the hosts in your `sites.pp` file: +1. Update your main `sites.pp` manifest and include the new `php` module: - {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} - node 'ubupuppet.members.linode.com' { - $adminemail = 'webmaster@example.com' - $servername = 'hostname.example.com' + {{< file "production/manifests/site.pp" puppet >}} +# ... - include apache - include apache::vhosts - include mysql::database - include php +node 'puppet-agent-ubuntu.example.com' { + # ... - } + include apache + include apache::vhosts + + include php - node 'centospuppet.members.linode.com' { - $adminemail = 'webmaster@example.com' - $servername = 'hostname.example.com' + include mysql::database - include apache - include apache::vhosts - include mysql::database - include php + # ... +} - } - {{}} +node 'puppet-agent-centos.example.com' { + # ... + + include apache + include apache::vhosts + + include php + + include mysql::database + + # ... +} +{{}} 1. Run the following command on your agent nodes to pull in any changes to your servers. diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/init.pp b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/init.pp new file mode 100644 index 00000000000..040484b74f0 --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/init.pp @@ -0,0 +1,26 @@ +class apache ( + $apachename = $::apache::params::apachename, + $conffile = $::apache::params::conffile, + $confsource = $::apache::params::confsource, +) inherits ::apache::params { + + package { 'apache': + name => $apachename, + ensure => present, + } + + file { 'configuration-file': + path => $conffile, + ensure => file, + source => $confsource, + notify => Service['apache-service'], + } + + service { 'apache-service': + name => $apachename, + hasrestart => true, + enable => true, + ensure => running + } + +} \ No newline at end of file diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/params.pp b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/params.pp new file mode 100644 index 00000000000..2b635a6a2d2 --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/params.pp @@ -0,0 +1,15 @@ +class apache::params { + + if $::osfamily == 'RedHat' { + $apachename = 'httpd' + $conffile = '/etc/httpd/conf/httpd.conf' + $confsource = 'puppet:///modules/apache/httpd.conf' + } elsif $::osfamily == 'Debian' { + $apachename = 'apache2' + $conffile = '/etc/apache2/apache2.conf' + $confsource = 'puppet:///modules/apache/apache2.conf' + } else { + print "This is not a supported distro." + } + +} diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/vhosts.pp b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/vhosts.pp new file mode 100644 index 00000000000..d084791800c --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/vhosts.pp @@ -0,0 +1,34 @@ +class apache::vhosts { + + if $::osfamily == 'RedHat' { + file { '/etc/httpd/conf.d/vhost.conf': + ensure => file, + content => template('apache/vhosts-rh.conf.erb'), + notify => Service['apache-service'], + } + file { [ "/var/www/$servername", + "/var/www/$servername/public_html", + "/var/www/$servername/logs", ]: + ensure => directory, + } + } elsif $::osfamily == 'Debian' { + file { [ "/var/www/$servername", + "/var/www/$servername/public_html", + "/var/www/$servername/logs", ]: + ensure => directory, + } + file { "/etc/apache2/sites-available/$servername.conf": + ensure => file, + content => template('apache/vhosts-deb.conf.erb'), + notify => Service['apache-service'], + } + file { "/etc/apache2/sites-enabled/$servername.conf": + ensure => 'link', + target => "/etc/apache2/sites-available/$servername.conf", + notify => Service['apache-service'], + } + } else { + fail ( 'This is not a supported distro.') + } + +} \ No newline at end of file diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md index 444cc8de381..35bc2a04baf 100644 --- a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md @@ -8,7 +8,7 @@ license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' aliases: ['applications/puppet/create-puppet-module/','applications/configuration-management/create-puppet-module/'] deprecated: true deprecated_link: 'applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/' -modified: 2015-11-12 +modified: 2019-02-04 modified_by: name: Elle Krout published: 2015-11-12