Separate config files per site in Nginx - Mini Project: Build & Apply

Separate Config Files Per Site in Nginx

📖 Scenario: You are managing a web server that hosts multiple websites. To keep things organized and easy to maintain, you want to create separate configuration files for each website instead of putting all settings in one big file.

🎯 Goal: Learn how to create individual Nginx configuration files for two different websites and enable them by including them in the main Nginx configuration.

📋 What You'll Learn

Create separate config files for two sites: site1.conf and site2.conf

Each config file must define a server block with the correct server_name and root directory

Add an include directive in the main Nginx config to load these site configs

Test the configuration by printing the included files

💡 Why This Matters

🌍 Real World

Web servers often host multiple websites. Keeping each site's configuration separate makes it easier to manage and update without affecting others.

💼 Career

System administrators and DevOps engineers use this technique daily to organize web server configurations and deploy multiple sites efficiently.

1

Create separate config files for two sites

Create two separate Nginx config files named site1.conf and site2.conf. In site1.conf, write a server block with server_name site1.example.com; and root /var/www/site1;. In site2.conf, write a server block with server_name site2.example.com; and root /var/www/site2;.

Nginx

# Your code here to create site1.conf and site2.conf with server blocks

Hint

Each config file should have a server block with listen 80;, server_name, and root directives.

2

Add include directive in main Nginx config

In the main Nginx configuration file (e.g., nginx.conf), add an include directive to load all config files from the /etc/nginx/sites-enabled/ directory.

Nginx

server {
    listen 80;
    server_name site1.example.com;
    root /var/www/site1;
}

server {
    listen 80;
    server_name site2.example.com;
    root /var/www/site2;
}

# Add include directive below
# Your code here

Hint

The include directive should point to the directory where your site config files are stored.

3

Simulate enabling site config files

Create symbolic links for site1.conf and site2.conf inside the /etc/nginx/sites-enabled/ directory to enable these sites.

Nginx

server {
    listen 80;
    server_name site1.example.com;
    root /var/www/site1;
}

server {
    listen 80;
    server_name site2.example.com;
    root /var/www/site2;
}

include /etc/nginx/sites-enabled/*;

# Your code here to create symbolic links

Hint

Use the ln -s command to create symbolic links for each site config file.

4

Print included config files to verify

Print the list of files included by the include /etc/nginx/sites-enabled/*; directive by running ls /etc/nginx/sites-enabled/.

Nginx

server {
    listen 80;
    server_name site1.example.com;
    root /var/www/site1;
}

server {
    listen 80;
    server_name site2.example.com;
    root /var/www/site2;
}

include /etc/nginx/sites-enabled/*;

ln -s /etc/nginx/sites-available/site1.conf /etc/nginx/sites-enabled/site1.conf
ln -s /etc/nginx/sites-available/site2.conf /etc/nginx/sites-enabled/site2.conf

# Your code here to list files

Hint

Use the ls command to list the files in the /etc/nginx/sites-enabled/ directory.

Practice

1. What is the main benefit of using separate config files per site in nginx?

easy

A. It makes nginx run faster by loading fewer files.

B. It allows nginx to serve only one site at a time.

C. It automatically secures each site with HTTPS.

D. It keeps the nginx setup organized and easier to manage.

Solution

1. Step 1: Understand config file organization

   Separate config files help keep settings for each site distinct and clear.

2. Step 2: Recognize management benefits

   This organization makes it easier to update or troubleshoot individual sites without affecting others.

3. Final Answer:

   It keeps the nginx setup organized and easier to manage. -> Option D

4. Quick Check:

   Separate configs = better organization [OK]

Hint: Separate files mean easier site management [OK]

Common Mistakes:

• Thinking separate files speed up nginx
• Assuming separate files enable HTTPS automatically
• Believing nginx serves only one site with separate files

2. Which nginx directive correctly includes all site config files from the sites-enabled directory?

easy

A. include /etc/nginx/conf.d/*;

B. include /etc/nginx/sites-available/*;

C. include /etc/nginx/sites-enabled/*;

D. include /etc/nginx/sites-enabled.conf;

Solution

1. Step 1: Identify the correct directory for active sites

   The sites-enabled directory holds active site configs linked from sites-available.

2. Step 2: Use the include directive properly

   Using include /etc/nginx/sites-enabled/*; loads all enabled site configs.

3. Final Answer:

   include /etc/nginx/sites-enabled/*; -> Option C

4. Quick Check:

   Include sites-enabled/* loads active sites [OK]

Hint: Include sites-enabled/* to load active sites [OK]

Common Mistakes:

• Including sites-available instead of sites-enabled
• Using wrong directory like conf.d for site configs
• Missing the wildcard * to include all files

3. Given the command ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/, what is the effect?

medium

A. It creates a symbolic link to enable example.com site.

B. It copies the example.com config to sites-enabled.

C. It deletes the example.com config file.

D. It disables the example.com site.

Solution

1. Step 1: Understand the ln -s command

   The command creates a symbolic link from the source to the target location.

2. Step 2: Link sites-available to sites-enabled

   Linking example.com config into sites-enabled activates the site in nginx.

3. Final Answer:

   It creates a symbolic link to enable example.com site. -> Option A

4. Quick Check:

   ln -s from sites-available to sites-enabled enables site [OK]

Hint: ln -s link enables site by linking config [OK]

Common Mistakes:

• Thinking ln -s disables the site
• Assuming ln -s deletes or copies files
• Confusing symbolic link with file copy

4. You added a new site config in sites-available but forgot to link it in sites-enabled. What happens when you reload nginx?

medium

A. The new site is ignored and not served.

B. Nginx throws a syntax error and fails to reload.

C. The new site is active and served by nginx.

D. Nginx deletes the config file automatically.

Solution

1. Step 1: Understand sites-available vs sites-enabled

   Sites-available holds configs but only linked sites in sites-enabled are active.

2. Step 2: Effect of missing link on reload

   Without a link, nginx ignores the new config and serves only enabled sites.

3. Final Answer:

   The new site is ignored and not served. -> Option A

4. Quick Check:

   Missing link means site ignored on reload [OK]

Hint: Link site config to sites-enabled to activate [OK]

Common Mistakes:

• Expecting nginx to auto-enable new configs
• Thinking nginx reload fails without link
• Assuming nginx deletes unlinked configs

5. You want to add a new site with config in /etc/nginx/sites-available/newsite. Which sequence correctly enables it and reloads nginx safely?

hard

A. Copy config to sites-enabled, then run nginx -s reload

B. Create symbolic link in sites-enabled, test config with nginx -t, then reload nginx

C. Edit nginx.conf directly to add newsite, then restart nginx

D. Move config to sites-enabled, then reload nginx without testing

Solution

1. Step 1: Enable site by linking config

   Create a symbolic link from sites-available/newsite to sites-enabled to activate it.

2. Step 2: Test nginx config before reload

   Run nginx -t to check for syntax errors and avoid downtime.

3. Step 3: Reload nginx to apply changes

   Use nginx -s reload to apply new config without stopping the server.

4. Final Answer:

   Create symbolic link in sites-enabled, test config with nginx -t, then reload nginx -> Option B

5. Quick Check:

   Link + test + reload = safe enable [OK]

Hint: Always test config before reload after linking site [OK]

Common Mistakes:

• Copying instead of linking config files
• Reloading nginx without testing config
• Editing nginx.conf instead of using sites-available