One place for hosting & domains

      How To Configure Jenkins with SSL Using an Nginx Reverse Proxy on Ubuntu 20.04


      Not using Ubuntu 20.04?


      Choose a different version or distribution.

      Introduction

      By default, Jenkins comes with its own built-in Winstone web server listening on port 8080, which is convenient for getting started. It’s also a good idea, however, to secure Jenkins with SSL to protect passwords and sensitive data transmitted through the web interface.

      In this tutorial, you will configure Nginx as a reverse proxy to direct client requests to Jenkins.

      Prerequisites

      To begin, you’ll need the following:

      Step 1 — Configuring Nginx

      In the prerequisite tutorial How to Secure Nginx with Let’s Encrypt on Ubuntu 20.04, you configured Nginx to use SSL in the /etc/nginx/sites-available/example.com file. Open this file to add your reverse proxy settings:

      • sudo nano /etc/nginx/sites-available/example.com

      In the server block with the SSL configuration settings, add Jenkins-specific access and error logs:

      /etc/nginx/sites-available/example.com

      . . . 
      server {
              . . .
              # SSL Configuration
              #
              listen [::]:443 ssl ipv6only=on; # managed by Certbot
              listen 443 ssl; # managed by Certbot
              access_log            /var/log/nginx/jenkins.access.log;
              error_log             /var/log/nginx/jenkins.error.log;
              . . .
              }
      

      Next let’s configure the proxy settings. Since we’re sending all requests to Jenkins, we’ll comment out the default try_files line, which would otherwise return a 404 error before the request reaches Jenkins:

      /etc/nginx/sites-available/example.com

      . . .
                 location / {
                      # First attempt to serve request as file, then
                      # as directory, then fall back to displaying a 404.
                      # try_files $uri $uri/ =404;        }
      . . . 
      

      Let’s now add the proxy settings, which include:

      • proxy_params: The /etc/nginx/proxy_params file is supplied by Nginx and ensures that important information, including the hostname, the protocol of the client request, and the client IP address, is retained and available in the log files.
      • proxy_pass: This sets the protocol and address of the proxied server, which in this case will be the Jenkins server accessed via localhost on port 8080.
      • proxy_read_timeout: This enables an increase from Nginx’s 60 second default to the Jenkins-recommended 90 second value.
      • proxy_redirect: This ensures that responses are correctly rewritten to include the proper host name.

      Be sure to substitute your SSL-secured domain name for example.com in the proxy_redirect line below:

      /etc/nginx/sites-available/example.com

      Location /  
      . . .
                 location / {
                      # First attempt to serve request as file, then
                      # as directory, then fall back to displaying a 404.
                      # try_files $uri $uri/ =404;
                      include /etc/nginx/proxy_params;
                      proxy_pass          http://localhost:8080;
                      proxy_read_timeout  90s;
                      # Fix potential "It appears that your reverse proxy setup is broken" error.
                      proxy_redirect      http://localhost:8080 https://example.com;
      

      Once you’ve made these changes, save the file and exit the editor. We’ll hold off on restarting Nginx until after we’ve configured Jenkins, but we can test our configuration now:

      If all is well, the command will return:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      If not, fix any reported errors until the test passes.

      Note:
      If you misconfigure the proxy_pass (by adding a trailing slash, for example), you will get something similar to the following in your Jenkins Configuration page.

      Jenkins error: Reverse proxy set up is broken

      If you see this error, double-check your proxy_pass and proxy_redirect settings in the Nginx configuration.

      Step 2 — Configuring Jenkins

      For Jenkins to work with Nginx, you will need to update the Jenkins configuration so that the Jenkins server listens only on the localhost interface rather than on all interfaces (0.0.0.0). If Jenkins listens on all interfaces, it’s potentially accessible on its original, unencrypted port (8080).

      Let’s modify the /etc/default/jenkins configuration file to make these adjustments:

      • sudo nano /etc/default/jenkins

      Locate the JENKINS_ARGS line and add --httpListenAddress=127.0.0.1 to the existing arguments:

      /etc/default/jenkins

      . . .
      JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT --httpListenAddress=127.0.0.1"
      

      Save and exit the file.

      To use the new configuration settings, restart Jenkins:

      • sudo systemctl restart jenkins

      Since systemctl doesn’t display output, check the status:

      • sudo systemctl status jenkins

      You should see the active (exited) status in the Active line:

      Output

      ● jenkins.service - LSB: Start Jenkins at boot time Loaded: loaded (/etc/init.d/jenkins; generated) Active: active (exited) since Mon 2018-07-09 20:26:25 UTC; 11s ago Docs: man:systemd-sysv-generator(8) Process: 29766 ExecStop=/etc/init.d/jenkins stop (code=exited, status=0/SUCCESS) Process: 29812 ExecStart=/etc/init.d/jenkins start (code=exited, status=0/SUCCESS)

      Restart Nginx:

      • sudo systemctl restart nginx

      Check the status:

      • sudo systemctl status nginx

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2018-07-09 20:27:23 UTC; 31s ago Docs: man:nginx(8) Process: 29951 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS) Process: 29963 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 29952 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 29967 (nginx)

      With both servers restarted, you should be able to visit the domain using either HTTP or HTTPS. HTTP requests will be redirected automatically to HTTPS, and the Jenkins site will be served securely.

      Step 3 — Testing the Configuration

      Now that you have enabled encryption, you can test the configuration by resetting the administrative password. Let’s start by visiting the site via HTTP to verify that you can reach Jenkins and are redirected to HTTPS.

      In your web browser, enter http://example.com, substituting your domain for example.com. After you press ENTER, the URL should start with https and the location bar should indicate that the connection is secure.

      You can enter the administrative username you created in How To Install Jenkins on Ubuntu 20.04 in the User field, and the password that you selected in the Password field.

      Once logged in, you can change the password to be sure it’s secure.

      Click on your username in the upper-right-hand corner of the screen. On the main profile page, select Configure from the list on the left side of the page:

      Navigate to Jenkins password page

      This will take you to a new page, where you can enter and confirm a new password:

      Jenkins create password page

      Confirm the new password by clicking Save. You can now use the Jenkins web interface securely.

      Conclusion

      In this tutorial, you configured Nginx as a reverse proxy to Jenkins’ built-in web server to secure your credentials and other information transmitted via the web interface. Now that Jenkins is secure, you can learn how to set up a continuous integration pipeline to automatically test code changes. Other resources to consider if you are new to Jenkins are the Jenkins project’s “Creating your first Pipeline” tutorial or the library of community-contributed plugins.



      Source link

      How To Install WordPress on Ubuntu 20.04 with a LAMP Stack


      Not using Ubuntu 20.04?


      Choose a different version or distribution.

      Introduction

      WordPress is an extremely popular open-source technology for making websites and blogs on the internet today. Used by 63% of all websites that use a content management system (CMS), WordPress sites represent 36% of all websites that are currently online.

      There are many different approaches to getting access to WordPress and some setup processes are more complex than others. This tutorial is intended for those who desire to install and administer a WordPress instance on an unmanaged cloud server via the command line. Though this approach requires more steps than a ready-made WordPress installation, it offers administrators greater control over their WordPress environment.

      If you are looking to access a ready-made WordPress installation, DigitalOcean Marketplace offers a one-click app to get you started with WordPress through installation when spinning up your server.

      Depending on your needs and goals, you may find other options that are more suitable. As open-source software, WordPress can be freely downloaded and installed, but to be available on the web, you will likely need to purchase cloud infrastructure and a domain name. Continue following this guide if you are interested in working through the server-side installation and set up of a WordPress site.

      This tutorial will be using a LAMP (Linux, Apache, MySQL, and PHP) stack, which is one option for a server architecture that supports WordPress by providing the Linux operating system, Apache web server, MySQL database, and PHP programming language. We’ll install and set up WordPress via LAMP on a Linux Ubuntu 20.04 server.

      Prerequisites

      In order to complete this tutorial, you will need access to an Ubuntu 20.04 server and will need to complete these steps before beginning this guide:

      • Set up your server by following our Ubuntu 20.04 initial server setup guide, and ensure you have a non-root sudo user.
      • Install a LAMP stack by following our LAMP guide to install and configure this software.
      • Secure your site: WordPress takes in user input and stores user data, so it is important for it to have a layer of security. TLS/SSL is the technology that allows you to encrypt the traffic from your site so that your and your users’ connection is secure. Here are two options available to you to meet this requirement:
        • If you have a domain name… you can secure your site with Let’s Encrypt, which provides free, trusted certificates. Follow our Let’s Encrypt guide for Apache to set this up.
        • If you do not have a domain… and you are just using this configuration for testing or personal use, you can use a self-signed certificate instead. This provides the same type of encryption, but without the domain validation. Follow our self-signed SSL guide for Apache to get set up.

      When you are finished with the setup steps, log into your server as your sudo user and continue below.

      Step 1 — Creating a MySQL Database and User for WordPress

      The first step that we will take is a preparatory one. WordPress uses MySQL to manage and store site and user information. We have MySQL installed already, but we need to make a database and a user for WordPress to use.

      To get started, log into the MySQL root (administrative) account by issuing this command (note that this is not the root user of your server):

      You will be prompted for the password you set for the MySQL root account when you installed the software.

      Note: If you cannot access your MySQL database via root, as a sudo user you can update your root user’s password by logging into the database like so:

      Once you receive the MySQL prompt, you can update the root user’s password. Here, replace new_password with a strong password of your choosing.

      • ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'new_password';

      You may now type EXIT; and can log back into the database via password with the following command:

      Within the database, we can create an exclusive database for WordPress to control. You can call this whatever you would like, but we will be using the name wordpress in this guide. Create the database for WordPress by typing:

      • CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

      Note: Every MySQL statement must end in a semi-colon (;). Check to make sure this is present if you are running into any issues.

      Next, we are going to create a separate MySQL user account that we will use exclusively to operate our new database. Creating specific databases and accounts can support us from a management and security standpoint. We will use the name wordpressuser in this guide, but feel free to use whatever name is relevant for you.

      We are going to create this account, set a password, and grant access to the database we created. We can do this by typing the following command. Remember to choose a strong password here for your database user where we have password:

      • CREATE USER 'wordpressuser'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

      Next, let the database know that our wordpressuser should have complete access to the database we set up:

      • GRANT ALL ON wordpress.* TO 'wordpressuser'@'%';

      You now have a database and user account, each made specifically for WordPress. We need to flush the privileges so that the current instance of MySQL knows about the recent changes we’ve made:

      Exit out of MySQL by typing:

      In the next step, we’ll lay some foundations for WordPress plugins by downloading PHP extensions for our server.

      Step 2 — Installing Additional PHP Extensions

      When setting up our LAMP stack, we only required a very minimal set of extensions in order to get PHP to communicate with MySQL. WordPress and many of its plugins leverage additional PHP extensions.

      We can download and install some of the most popular PHP extensions for use with WordPress by typing:

      • sudo apt update
      • sudo apt install php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip

      This will lay the groundwork for installing additional plugins into our WordPress site.

      Note: Each WordPress plugin has its own set of requirements. Some may require additional PHP packages to be installed. Check your plugin documentation to discover its PHP requirements. If they are available, they can be installed with apt as demonstrated above.

      We will need to restart Apache to load these new extensions, we’ll be doing more configurations on Apache in the next section, so you can wait until then, or restart now to complete the PHP extension process.

      • sudo systemctl restart apache2

      Step 3 — Adjusting Apache’s Configuration to Allow for .htaccess Overrides and Rewrites

      Next, we will be making a few minor adjustments to our Apache configuration. Based on the prerequisite tutorials, you should have a configuration file for your site in the /etc/apache2/sites-available/ directory.

      In this guide, we’ll use /etc/apache2/sites-available/wordpress.conf as an example here, but you should substitute the path to your configuration file where appropriate. Additionally, we will use /var/www/wordpress as the root directory of our WordPress install. You should use the web root specified in your own configuration. If you followed our LAMP tutorial, it may be your domain name instead of wordpress in both of these instances.

      Note: It’s possible you are using the 000-default.conf default configuration (with /var/www/html as your web root). This is fine to use if you’re only going to host one website on this server. If not, it’s better to split the necessary configuration into logical chunks, one file per site.

      With our paths identified, we can move onto working with .htaccess so that Apache can handle configuration changes on a per-directory basis.

      Enabling .htaccess Overrides

      Currently, the use of .htaccess files is disabled. WordPress and many WordPress plugins use these files extensively for in-directory tweaks to the web server’s behavior.

      Open the Apache configuration file for your website with a text editor like nano.

      • sudo nano /etc/apache2/sites-available/wordpress.conf

      To allow .htaccess files, we need to set the AllowOverride directive within a Directory block pointing to our document root. Add the following block of text inside the VirtualHost block in your configuration file, making sure to use the correct web root directory:

      /etc/apache2/sites-available/wordpress.conf

      <Directory /var/www/wordpress/>
          AllowOverride All
      </Directory>
      

      When you are finished, save and close the file. In nano, you can do this by pressing CTRL and X together, then Y, then ENTER.

      Enabling the Rewrite Module

      Next, we can enable mod_rewrite so that we can utilize the WordPress permalink feature:

      This allows you to have more human-readable permalinks to your posts, like the following two examples:

      http://example.com/2012/post-name/
      http://example.com/2012/12/30/post-name
      

      The a2enmod command calls a script that enables the specified module within the Apache configuration.

      Enabling the Changes

      Before we implement the changes we’ve made, check to make sure we haven’t made any syntax errors by running the following test.

      • sudo apache2ctl configtest

      You may receive output like the following:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      If you wish to suppress the top line, just add a ServerName directive to your main (global) Apache configuration file at /etc/apache2/apache2.conf. The ServerName can be your server’s domain or IP address. This is just a message, however, and doesn’t affect the functionality of your site. As long as the output contains Syntax OK, you are ready to continue.

      Restart Apache to implement the changes. Make sure to restart now even if you have restarted earlier in this tutorial.

      • sudo systemctl restart apache2

      Next, we will download and set up WordPress itself.

      Step 4 — Downloading WordPress

      Now that our server software is configured, we can download and set up WordPress. For security reasons in particular, it is always recommended to get the latest version of WordPress from their site.

      Change into a writable directory (we recommend a temporary one like /tmp) and download the compressed release.

      • cd /tmp
      • curl -O https://wordpress.org/latest.tar.gz

      Extract the compressed file to create the WordPress directory structure:

      We will be moving these files into our document root momentarily. Before we do, we can add a dummy .htaccess file so that this will be available for WordPress to use later.

      Create the file by typing:

      • touch /tmp/wordpress/.htaccess

      We’ll also copy over the sample configuration file to the filename that WordPress reads:

      • cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php

      We can also create the upgrade directory, so that WordPress won’t run into permissions issues when trying to do this on its own following an update to its software:

      • mkdir /tmp/wordpress/wp-content/upgrade

      Now, we can copy the entire contents of the directory into our document root. We are using a dot at the end of our source directory to indicate that everything within the directory should be copied, including hidden files (like the .htaccess file we created):

      • sudo cp -a /tmp/wordpress/. /var/www/wordpress

      Ensure that you replace the /var/www/wordpress directory with the directory you have set up on your server.

      Step 5 — Configuring the WordPress Directory

      Before we do the web-based WordPress setup, we need to adjust some items in our WordPress directory.

      Adjusting the Ownership and Permissions

      An important step that we need to accomplish is setting up reasonable file permissions and ownership.

      We’ll start by giving ownership of all the files to the www-data user and group. This is the user that the Apache web server runs as, and Apache will need to be able to read and write WordPress files in order to serve the website and perform automatic updates.

      Update the ownership with the chown command which allows you to modify file ownership. Be sure to point to your server’s relevant directory.

      • sudo chown -R www-data:www-data /var/www/wordpress

      Next we’ll run two find commands to set the correct permissions on the WordPress directories and files:

      • sudo find /var/www/wordpress/ -type d -exec chmod 750 {} ;
      • sudo find /var/www/wordpress/ -type f -exec chmod 640 {} ;

      These permissions should get you working effectively with WordPress, but note that some plugins and procedures may require additional tweaks.

      Setting Up the WordPress Configuration File

      Now, we need to make some changes to the main WordPress configuration file.

      When we open the file, our first task will be to adjust some secret keys to provide a level of security for our installation. WordPress provides a secure generator for these values so that you do not have to try to come up with good values on your own. These are only used internally, so it won’t hurt usability to have complex, secure values here.

      To grab secure values from the WordPress secret key generator, type:

      • curl -s https://api.wordpress.org/secret-key/1.1/salt/

      You will get back unique values that resemble output similar to the block below.

      Warning! It is important that you request unique values each time. Do NOT copy the values below!

      Output

      define('AUTH_KEY', '1jl/vqfs<XhdXoAPz9 DO NOT COPY THESE VALUES c_j{iwqD^<+c9.k<J@4H'); define('SECURE_AUTH_KEY', 'E2N-h2]Dcvp+aS/p7X DO NOT COPY THESE VALUES {Ka(f;rv?Pxf})CgLi-3'); define('LOGGED_IN_KEY', 'W(50,{W^,OPB%PB<JF DO NOT COPY THESE VALUES 2;y&,2m%3]R6DUth[;88'); define('NONCE_KEY', 'll,4UC)7ua+8<!4VM+ DO NOT COPY THESE VALUES #`DXF+[$atzM7 o^-C7g'); define('AUTH_SALT', 'koMrurzOA+|L_lG}kf DO NOT COPY THESE VALUES 07VC*Lj*lD&?3w!BT#-'); define('SECURE_AUTH_SALT', 'p32*p,]z%LZ+pAu:VY DO NOT COPY THESE VALUES C-?y+K0DK_+F|0h{!_xY'); define('LOGGED_IN_SALT', 'i^/G2W7!-1H2OQ+t$3 DO NOT COPY THESE VALUES t6**bRVFSD[Hi])-qS`|'); define('NONCE_SALT', 'Q6]U:K?j4L%Z]}h^q7 DO NOT COPY THESE VALUES 1% ^qUswWgn+6&xqHN&%');

      These are configuration lines that we can paste directly in our configuration file to set secure keys. Copy the output you received now.

      Next, open the WordPress configuration file:

      • sudo nano /var/www/wordpress/wp-config.php

      Find the section that contains the example values for those settings.

      /var/www/wordpress/wp-config.php

      . . .
      
      define('AUTH_KEY',         'put your unique phrase here');
      define('SECURE_AUTH_KEY',  'put your unique phrase here');
      define('LOGGED_IN_KEY',    'put your unique phrase here');
      define('NONCE_KEY',        'put your unique phrase here');
      define('AUTH_SALT',        'put your unique phrase here');
      define('SECURE_AUTH_SALT', 'put your unique phrase here');
      define('LOGGED_IN_SALT',   'put your unique phrase here');
      define('NONCE_SALT',       'put your unique phrase here');
      
      . . .
      

      Delete those lines and paste in the values you copied from the command line:

      /var/www/wordpress/wp-config.php

      . . .
      
      define('AUTH_KEY',         'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_KEY',  'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_KEY',    'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_KEY',        'VALUES COPIED FROM THE COMMAND LINE');
      define('AUTH_SALT',        'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_SALT', 'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_SALT',   'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_SALT',       'VALUES COPIED FROM THE COMMAND LINE');
      
      . . .
      

      Next, we are going to modify some of the database connection settings at the beginning of the file. You need to adjust the database name, the database user, and the associated password that you configured within MySQL.

      The other change we need to make is to set the method that WordPress should use to write to the filesystem. Since we’ve given the web server permission to write where it needs to, we can explicitly set the filesystem method to “direct”. Failure to set this with our current settings would result in WordPress prompting for FTP credentials when we perform some actions.

      This setting can be added below the database connection settings, or anywhere else in the file:

      /var/www/wordpress/wp-config.php

      . . .
      
      // ** MySQL settings - You can get this info from your web host ** //
      /** The name of the database for WordPress */
      define( 'DB_NAME', 'wordpress' );
      
      /** MySQL database username */
      define( 'DB_USER', 'wordpressuser' );
      
      /** MySQL database password */
      define( 'DB_PASSWORD', 'password' );
      
      /** MySQL hostname */
      define( 'DB_HOST', 'localhost' );
      
      /** Database Charset to use in creating database tables. */
      define( 'DB_CHARSET', 'utf8' );
      
      /** The Database Collate type. Don't change this if in doubt. */
      define( 'DB_COLLATE', '' );
      
      
      . . .
      
      define('FS_METHOD', 'direct');
      

      Save and close the file when you are finished.

      Step 6 — Completing the Installation Through the Web Interface

      Now that the server configuration is complete, we can complete the installation through the web interface.

      In your web browser, navigate to your server’s domain name or public IP address:

      https://server_domain_or_IP
      

      Select the language you would like to use:

      WordPress language selection

      Next, you will come to the main setup page.

      Select a name for your WordPress site and choose a username. It is recommended to choose something unique and avoid common usernames like “admin” for security purposes. A strong password is generated automatically. Save this password or select an alternative strong password.

      Enter your email address and select whether you want to discourage search engines from indexing your site:

      WordPress setup installation

      When you click ahead, you will be taken to a page that prompts you to log in:

      WordPress login prompt

      Once you log in, you will be taken to the WordPress administration dashboard:

      WordPress login prompt

      At this point, you can begin to design your WordPress website! If this is your first time using WordPress, explore the interface a bit to get acquainted with your new CMS.

      Conclusion

      Congratulations, WordPress is now installed and is ready to be used!

      At this point you may want to start doing the following:

      • Choose your permalinks setting for WordPress posts, which can be found in Settings > Permalinks.
      • Select a new theme in Appearance > Themes.
      • Install new plugins to increase your site’s functionality under Plugins > Add New.
      • If you are going to collaborate with others, you may also wish to add additional users at this time under Users > Add New.

      You can find additional resources for alternate ways to install WordPress, learn how to install WordPress on different server distributions, automate your WordPress installations, and scale your WordPress sites by checking out our WordPress Community tag.



      Source link

      How To Set Up Ansible Inventories


      Introduction

      Ansible is a modern configuration management tool that facilitates the task of setting up and maintaining remote servers, with a minimalist design intended to get users up and running quickly. Ansible uses an inventory file to keep track of which hosts are part of your infrastructure, and how to reach them for running commands and playbooks.

      There are multiple ways in which you can set up your Ansible inventory file, depending on your environment and project needs. In this guide, we’ll demonstrate how to create inventory files and organize servers into groups and subgroups, how to set up host variables, and how to use patterns to control the execution of Ansible commands and playbooks per host and per group.

      Prerequisites

      In order follow this guide, you’ll need:

      • One Ansible control node: an Ubuntu 20.04 machine with Ansible installed and configured to connect to your Ansible hosts using SSH keys. Make sure the control node has a regular user with sudo permissions and a firewall enabled, as explained in our Initial Server Setup guide. To set up Ansible, please follow our guide on How to Install and Configure Ansible on Ubuntu 20.04.
      • Two or more Ansible Hosts: two or more remote Ubuntu 20.04 servers.

      Step 1 — Creating a Custom Inventory File

      Upon installation, Ansible creates an inventory file that is typically located at /etc/ansible/hosts. This is the default location used by Ansible when a custom inventory file is not provided with the -i option, during a playbook or command execution.

      Even though you can use this file without problems, using per-project inventory files is a good practice to avoid mixing servers when executing commands and playbooks. Having per-project inventory files will also facilitate sharing your provisioning setup with collaborators, given you include the inventory file within the project’s code repository.

      To get started, access your home folder and create a new directory to hold your Ansible files:

      Move to that directory and open a new inventory file using your text editor of choice. Here, we’ll use nano:

      • cd ansible
      • nano inventory

      A list of your nodes, with one server per line, is enough for setting up a functional inventory file. Hostnames and IP addresses are interchangeable:

      ~/ansible/inventory

      203.0.113.111
      203.0.113.112
      203.0.113.113
      server_hostname
      

      Once you have an inventory file set up, you can use the ansible-inventory command to validate and obtain information about your Ansible inventory:

      • ansible-inventory -i inventory --list

      Output

      { "_meta": { "hostvars": {} }, "all": { "children": [ "ungrouped" ] }, "ungrouped": { "hosts": [ "203.0.113.111", "203.0.113.112", "203.0.113.113", "server_hostname" ] } }

      Even though we haven’t set up any groups within our inventory, the output shows 2 distinct groups that are automatically inferred by Ansible: all and ungrouped. As the name suggests, all is used to refer to all servers from your inventory file, no matter how they are organized. The ungrouped group is used to refer to servers that aren’t listed within a group.

      Running Commands and Playbooks with Custom Inventories

      To run Ansible commands with a custom inventory file, use the -i option as follows:

      • ansible all -i inventory -m ping

      This would execute the ping module on all hosts listed in your custom inventory file.

      Similarly, this is how you execute Ansible playbooks with a custom inventory file:

      • ansible-playbook -i inventory playbook.yml

      Note: For more information on how to connect to nodes and how to run commands and playbooks, please refer to our How to Use Ansible guide.

      So far, we’ve seen how to create a basic inventory and how to use it for running commands and playbooks. In the next step, we’ll see how to organize nodes into groups and subgroups.

      Step 2 — Organizing Servers Into Groups and Subgroups

      Within the inventory file, you can organize your servers into different groups and subgroups. Beyond helping to keep your hosts in order, this practice will enable you to use group variables, a feature that can greatly facilitate managing multiple staging environments with Ansible.

      A host can be part of multiple groups. The following inventory file in INI format demonstrates a setup with four groups: webservers, dbservers, development, and production. You’ll notice that the servers are grouped by two different qualities: their purpose (web and database), and how they’re being used (development and production).

      ~/ansible/inventory

      [webservers]
      203.0.113.111
      203.0.113.112
      
      [dbservers]
      203.0.113.113
      server_hostname
      
      [development]
      203.0.113.111
      203.0.113.113
      
      [production]
      203.0.113.112
      server_hostname
      

      If you were to run the ansible-inventory command again with this inventory file, you would see the following arrangement:

      Output

      { "_meta": { "hostvars": {} }, "all": { "children": [ "dbservers", "development", "production", "ungrouped", "webservers" ] }, "dbservers": { "hosts": [ "203.0.113.113", "server_hostname" ] }, "development": { "hosts": [ "203.0.113.111", "203.0.113.113" ] }, "production": { "hosts": [ "203.0.113.112", "server_hostname" ] }, "webservers": { "hosts": [ "203.0.113.111", "203.0.113.112" ] } }

      It is also possible to aggregate multiple groups as children under a “parent” group. The “parent” is then called a metagroup. The following example demonstrates another way to organize the previous inventory using metagroups to achieve a comparable, yet more granular arrangement:

      ~/ansible/inventory

      [web_dev]
      203.0.113.111
      
      [web_prod]
      203.0.113.112
      
      [db_dev]
      203.0.113.113
      
      [db_prod]
      server_hostname
      
      [webservers:children]
      web_dev
      web_prod
      
      [dbservers:children]
      db_dev
      db_prod
      
      [development:children]
      web_dev
      db_dev
      
      [production:children]
      web_prod
      db_prod
      

      The more servers you have, the more it makes sense to break groups down or create alternative arrangements so that you can target smaller groups of servers as needed.

      Step 3 — Setting Up Host Aliases

      You can use aliases to name servers in a way that facilitates referencing those servers later, when running commands and playbooks.

      To use an alias, include a variable named ansible_host after the alias name, containing the corresponding IP address or hostname of the server that should respond to that alias:

      ~/ansible/inventory

      server1 ansible_host=203.0.113.111
      server2 ansible_host=203.0.113.112
      server3 ansible_host=203.0.113.113
      server4 ansible_host=server_hostname
      

      If you were to run the ansible-inventory command with this inventory file, you would see output similar to this:

      Output

      { "_meta": { "hostvars": { "server1": { "ansible_host": "203.0.113.111" }, "server2": { "ansible_host": "203.0.113.112" }, "server3": { "ansible_host": "203.0.113.113" }, "server4": { "ansible_host": "server_hostname" } } }, "all": { "children": [ "ungrouped" ] }, "ungrouped": { "hosts": [ "server1", "server2", "server3", "server4" ] } }

      Notice how the servers are now referenced by their aliases instead of their IP addresses or hostnames. This makes it easier for targeting individual servers when running commands and playbooks.

      Step 4 — Setting Up Host Variables

      It is possible to use the inventory file to set up variables that will change Ansible’s default behavior when connecting and executing commands on your nodes. This is in fact what we did in the previous step, when setting up host aliases. The ansible_host variable tells Ansible where to find the remote nodes, in case an alias is used to refer to that server.

      Inventory variables can be set per host or per group. In addition to customizing Ansible’s default settings, these variables are also accessible from your playbooks, which enables further customization for individual hosts and groups.

      The following example shows how to define the default remote user when connecting to each of the nodes listed in this inventory file:

      ~/ansible/inventory

      server1 ansible_host=203.0.113.111 ansible_user=sammy
      server2 ansible_host=203.0.113.112 ansible_user=sammy
      server3 ansible_host=203.0.113.113 ansible_user=myuser
      server4 ansible_host=server_hostname ansible_user=myuser
      

      You could also create a group to aggregate the hosts with similar settings, and then set up their variables at the group level:

      ~/ansible/inventory

      [group_a]
      server1 ansible_host=203.0.113.111 
      server2 ansible_host=203.0.113.112
      
      [group_b]
      server3 ansible_host=203.0.113.113 
      server4 ansible_host=server_hostname
      
      [group_a:vars]
      ansible_user=sammy
      
      [group_b:vars]
      ansible_user=myuser
      

      This inventory arrangement would generate the following output with ansible-inventory:

      Output

      { "_meta": { "hostvars": { "server1": { "ansible_host": "203.0.113.111", "ansible_user": "sammy" }, "server2": { "ansible_host": "203.0.113.112", "ansible_user": "sammy" }, "server3": { "ansible_host": "203.0.113.113", "ansible_user": "myuser" }, "server4": { "ansible_host": "server_hostname", "ansible_user": "myuser" } } }, "all": { "children": [ "group_a", "group_b", "ungrouped" ] }, "group_a": { "hosts": [ "server1", "server2" ] }, "group_b": { "hosts": [ "server3", "server4" ] } }

      Notice that all inventory variables are listed within the _meta node in the JSON output produced by ansible-inventory.

      Step 5 — Using Patterns to Target Execution of Commands and Playbooks

      When executing commands and playbooks with Ansible, you must provide a target. Patterns allow you to target specific hosts, groups, or subgroups in your inventory file. They’re very flexible, supporting regular expressions and wildcards.

      Consider the following inventory file:

      ~/ansible/inventory

      [webservers]
      203.0.113.111
      203.0.113.112
      
      [dbservers]
      203.0.113.113
      server_hostname
      
      [development]
      203.0.113.111
      203.0.113.113
      
      [production]
      203.0.113.112
      server_hostname
      

      Now imagine you need to execute a command targeting only the database server(s) that are running on production. In this example, there’s only server_hostname matching that criteria; however, it could be the case that you have a large group of database servers in that group. Instead of individually targeting each server, you could use the following pattern:

      • ansible dbservers:&production -m ping

      This pattern would target only servers that are present both in the dbservers as well as in the production groups. If you wanted to do the opposite, targeting only servers that are present in the dbservers but not in the production group, you would use the following pattern instead:

      • ansible dbservers:!production -m ping

      The following table contains a few different examples of common patterns you can use when running commands and playbooks with Ansible:

      Pattern Result Target
      all All Hosts from your inventory file
      host1 A single host (host1)
      host1:host2 Both host1 and host2
      group1 A single group (group1)
      group1:group2 All servers in group1 and group2
      group1:&group2 Only servers that are both in group1 and group2
      group1:!group2 Servers in group1 except those also in group2

      For more advanced pattern options, such as using positional patterns and regex to define targets, please refer to the official Ansible documentation on patterns.

      Conclusion

      In this guide, we had a detailed look into Ansible inventories. We’ve seen how to organize nodes into groups and subgroups, how to set up inventory variables, and how to use patterns to target different groups of servers when running commands and playbooks.

      In the next part of this series, we’ll see how to manage multiple servers with Ansible ad-hoc commands.



      Source link