Configuring MongoDB 4.x

In the previous section, you learned how to install and then start MongoDB. When starting MongoDB in this manner, you were actually using the default configuration options. It is extremely important that you understand some of the different startup options located in a file we will refer to as mongod.conf, or the MongoDB configuration file, throughout the rest of the book. In this section, we cover MongoDB configuration concepts that can be applied either at a customer site or inside a demo environment running in a Docker container on your own computer.

The name and location of the MongoDB configuration file

The name and location will vary slightly between operating systems. The table shown here describes the defaults for the four major operating systems covered in the previous section on installation:

Before getting into the details, let's have a look at the syntax.

YAML configuration file syntax

The MongoDB configuration file is an American Standard Code for Information Interchange (ASCII) text file using the YAML Ain't Markup Language (YAML) style of formatting, with the following features:

• Key-value pairs are specified as follows:

key : value

• Section headings are followed by a colon and a line feed, as follows:

heading:

• Key-value pairs that are subsets of a section are indented by two spaces, as follows:

heading:
  key1: value1
  key2: value2

• Comments can be added by starting the line with a # symbol, as follows:

# This is a comment

We will now examine some of the more important configuration options.

Configuration options

It is important to provide configuration to direct how the mongod server daemon starts. Although you could theoretically start mongod using command-line options, most DevOps prefer to place a permanent configuration into a configuration file. Configuration options fall into these major categories:

• Core: Storage, logging and network
• Process management
• Security
• Profiling
• Replication and sharding

In addition, the Enterprise (that is, paid) version of MongoDB features auditing and Simple Network Management Protocol (SNMP) options. Of these options in this chapter, we will only focus on the Core category. Other options will be covered in later chapters as those topics arise.

Storage configuration options

Under the storage key, the following table summarizes the more widely used options:

There are a number of other parameters as well; however, these are covered in other chapters in the book as appropriate.

Logging configuration options

It is important for troubleshooting and diagnostics purposes to activate MongoDB logging.  Accordingly, there are a number of parameters that can be activated under the systemLog key, as summarized in this table:

Let's now look at different network configuration options.

Network configuration options

The net configuration file key allows you to adjust network-related settings. Here are some of the core options:

Another important networking option is net.tls; however, this is not covered in this chapter, but rather in the next chapter, Chapter 3, Essential MongoDB Administration Techniques.

Example MongoDB configuration file

Here is an example using the three directives discussed in this section:

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 0.0.0.0

In this example, journaling is enabled, and the database files are stored in the /var/lib/mongodb directory. The system log is recorded in the /var/log/mongodb/mongod.log file,  and new entries are added to the existing file. The MongoDB server daemon listens on port 27017 to requests from all IP addresses.

Command-line options

It's important to note that there is a one-to-one correspondence between configuration file settings and command-line switches. Thus, for quick testing, you can simply start the MongoDB server daemon with a command-line switch. If successful, this can then be added to the configuration file.

For example, let's say you are testing IPv6 routing. To confirm that the MongoDB server will listen to requests on a given IPv6 address, from the command line you could start the server daemon as follows:

# mongod --ipv6 --bind_ip fe80::42:a6ff:fe0c:a377

The --ipv6 option enables IPv6 support, and the bind_ip option specifies the address. If successful, these commands could then be added to the mongod.conf file.

Expansion directives

First introduced in MongoDB 4.2, there are two magic keys added that are referred to as externally sourced or expansion directives. The two directives are __rest, allowing the use of a representational state transfer (REST) endpoint to obtain further configuration, and __exec, which loads configuration from the output of a shell or OS command.

Using the __rest expansion directive

The __rest expansion directive allows mongod or mongos to start with additional directives, or an entire configuration block, from an external REST request. Using parameters supplied with the directive, the server will issue an HTTP GET request to the REST application programming interface (API) endpoint specified and will receive its configuration in turn. The advantage of this approach is that it enables the centralization of startup directives across a large distributed MongoDB system. 

An obvious disadvantage when making requests to remote resources is that it opens a potentially huge security vulnerability. Thus, at a minimum, requests to any remote endpoint must use HTTPS. In addition, operating system permissions must restrict read access of the configuration file containing the __rest expansion directive to only the mongod or mongos user.

Here is a summary of parameters needed in conjunction with the __rest expansion directive:

Here is a brief example:

net:
  tls:
    certificateKeyFilePassword:
      __rest: "https://continuous-learning.com/api/cert/certPwd"
      type: "string"

In the preceding code example, the certificate key file password is provided by a REST request to continuous-learning.com.

Using the __exec expansion directive

The __exec expansion directive operates in much the same manner as the __rest directive. The main difference is that instead of consulting a REST endpoint, an operating system command is referenced, which in turn produces the result. Another difference is that the __exec directive could be used to load an entire configuration file. This gives DevOps the ability to automate mongod or mongos startup options.

As with the __rest directive, a number of parameters are associated with the __exec directive, as summarized here:

Here is a brief example:

net:
  tls:
    certificateKeyFilePassword:
      __exec: "python /usr/local/scripts/cert_pwd.py"
      type: "string"

In the preceding code example, the password for the certificate key file is provided by a cert_pwd.py Python script.