Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack

scottalanmiller

Worth noting that in this example, Nginx is exclusively used for SSL / TLS handling and will not be touched if the site is accessed via HTTP on port 80. That require will, if following the previous examples, go directly to either Apache or Varnish (depending on which articles you do first.)

Also worth noting, HTTP2 is enabled here.

stacksofplates

Why edit the nginx.conf file directly instead of using the conf.d directory?

scottalanmiller

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

Why edit the nginx.conf file directly instead of using the conf.d directory?

I've been debating that, but a single file to manage rather than a directory and moving files about seems a lot easier for keeping track of s state machine. Otherwise you have to manage file removals, too.

JaredBusch

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

Why edit the nginx.conf file directly instead of using the conf.d directory?

I've been debating that, but a single file to manage rather than a directory and moving files about seems a lot easier for keeping track of s state machine. Otherwise you have to manage file removals, too.

Why are you not using certbot? Even LE recommends that.

travisdh1

You might want to start leaving out SSLv3 now as well, according to ssllabs.com at least.

scottalanmiller

@travisdh1 said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

You might want to start leaving out SSLv3 now as well, according to ssllabs.com at least.

I was wondering about that.

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

Why edit the nginx.conf file directly instead of using the conf.d directory?

I've been debating that, but a single file to manage rather than a directory and moving files about seems a lot easier for keeping track of s state machine. Otherwise you have to manage file removals, too.

You wouldn't need to. As long as the configs are similar, just template them and have a dictionary, don't hard code the values in files. I don't know how to do it with Salt, but with Ansible it would be like this:

vars:

configs:
  server1:
    domain: server1.test.com
  server2:
    domain: server2.test.com

tasks:

- name: Create nginx configs
  template:
    src: conf.j2
    dest: /etc/nginx/conf.d/{{ item.key }}.conf
    owner: root
    group: root
    mode: 0644
  with_dict: "{{ configs }}"

template (configs.j2):

server {
      listen 443 ssl http2;
      server_name {{ item.value.domain }};

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/{{ item.value.domain }}/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/{{ item.value.domain }}/privkey.pem;

      location / {
        proxy_pass http://127.0.0.1/; }
  }

scottalanmiller

If doing a dictionary, is there any benefit to splitting up the files?

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

scottalanmiller

@aaronstuder said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller It's recommended by your favorite VPS provider

https://www.linode.com/docs/websites/hosting-a-website#configure-name-based-virtual-hosts

Are they using Salt for context?

scottalanmiller

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

scottalanmiller

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

A dictionary is much easier to read than those configs. I couldn't care less how you do it, but you're breaking convention. And again, if you screw up your main config it will bring everything down.

And if you need to remove a site, it's much easier to have it remove that specific config than it is to take out a whole server {} section in your main config.

scottalanmiller

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

A dictionary is much easier to read than those configs. I couldn't care less how you do it, but you're breaking convention. And again, if you screw up your main config it will bring everything down.

And if you need to remove a site, it's much easier to have it remove that specific config than it is to take out a whole server {} section in your main config.

Maybe I'm missing something but doesn't the effect in the end act exactly the same?

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

A dictionary is much easier to read than those configs. I couldn't care less how you do it, but you're breaking convention. And again, if you screw up your main config it will bring everything down.

And if you need to remove a site, it's much easier to have it remove that specific config than it is to take out a whole server {} section in your main config.

Maybe I'm missing something but doesn't the effect in the end act exactly the same?

Not deleting. Doing it the way I had showed, it would have to know where the section is in the main config and be able to delete that section in the middle somehow. That's a ton more logic you have to create than

file:x.conf
state: absent

scottalanmiller

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

A dictionary is much easier to read than those configs. I couldn't care less how you do it, but you're breaking convention. And again, if you screw up your main config it will bring everything down.

And if you need to remove a site, it's much easier to have it remove that specific config than it is to take out a whole server {} section in your main config.

Maybe I'm missing something but doesn't the effect in the end act exactly the same?

Not deleting. Doing it the way I had showed, it would have to know where the section is in the main config and be able to delete that section in the middle somehow. That's a ton more logic you have to create than
file:x.conf
state: absent

Yeah, then I have to make a second bit like that to actively remove everything. So if there are multiple hosts, they need to have a list of everything that might need to be removed, not just what is supposed to be there.

Seems really messy and manual.

scottalanmiller

There is probably some config for "fill this directory with ONLY these files" but I've not found that yet.

stacksofplates

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:
@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

@scottalanmiller said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:

If doing a dictionary, is there any benefit to splitting up the files?

Abstraction. The main conf file is set up correctly, so it's harder to screw up if you don't edit that file. If you botch anything editing the main conf you risk taking down everything.

It's also easier to move configs between services (web servers in this case).

How is it easier?

You just plug your variables in the custom config for the other site. You don't need to know anything about the main config. It's already set up to correctly use other custom configs.

And it's much easier to figure out where something is wrong. You can pinpoint to certain configs not one monolithic config.

But if both are built from a single monolithic dictionary source, I don't get any of those benefits. That doesn't apply when building in this way. To me it remains one file, regardless of the end result.

A dictionary is much easier to read than those configs. I couldn't care less how you do it, but you're breaking convention. And again, if you screw up your main config it will bring everything down.

And if you need to remove a site, it's much easier to have it remove that specific config than it is to take out a whole server {} section in your main config.

Maybe I'm missing something but doesn't the effect in the end act exactly the same?

Not deleting. Doing it the way I had showed, it would have to know where the section is in the main config and be able to delete that section in the middle somehow. That's a ton more logic you have to create than
file:x.conf
state: absent
Yeah, then I have to make a second bit like that to actively remove everything. So if there are multiple hosts, they need to have a list of everything that might need to be removed, not just what is supposed to be there.

Seems really messy and manual.

It would just be an ad hoc command. Remove it from the dict and run the ad hoc.

Taking it out of the dict wouldn't remove it from the main config. You would still have to have a "second bit" to do that, which would be much messier.

JaredBusch

Just like you should not be editing httpd.conf for vhosts with Apache, you should not be editing nginx.conf for your hosts with Nginx.