ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

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

    IT Discussion
    lamp proxy reverse proxy nginx salt saltstack devops web server lets encrypt ssl tls https https2
    4
    42
    6.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • scottalanmillerS
      scottalanmiller @stacksofplates
      last edited by

      @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:

      @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:

      @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.

      That breaks the point of a state machine.

      It doesn't have to be ad hoc. That was just an example to show how simple it would be.

      @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:

      @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.

      That breaks the point of a state machine.

      It doesn't have to be ad hoc. That was just an example to show how simple it would be.

      I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

      You will never convince me that this:

      worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

      Is easier to read than this:

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

      all of the traditional reasons don't apply any more

      Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

      I'm not trying to convince you of that. I'm not even discussing that.

      It's cleaner, easier to read,

      Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

      No, you argued that your way was cleaner and easier to read. I'm saying it's not.

      No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

      stacksofplatesS 1 Reply Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller @stacksofplates
        last edited by

        @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?

        This is where you started the discussion. It wasn't about a clear single dictionary file, it was about the resultant set of lots of files rather than just one. This is what I did not agree with, I don't see the value given that it'll be being generated by a single dictionary.

        1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller
          last edited by

          I immediately accepted the dictionary approach. It's only not used here because it's only a single server in the example. I'm trying to grow the example step by step, not throw advanced concepts in where they will just be confused.

          What we were discussing was assuming the use of your dictionary was there value to the sprawl of individual files.

          0_1491410800004_Screenshot from 2017-04-05 18-45-43.png

          1 Reply Last reply Reply Quote 0
          • stacksofplatesS
            stacksofplates @scottalanmiller
            last edited by

            @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:

            @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:

            @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.

            That breaks the point of a state machine.

            It doesn't have to be ad hoc. That was just an example to show how simple it would be.

            @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:

            @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.

            That breaks the point of a state machine.

            It doesn't have to be ad hoc. That was just an example to show how simple it would be.

            I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

            You will never convince me that this:

            worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

            Is easier to read than this:

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

            all of the traditional reasons don't apply any more

            Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

            I'm not trying to convince you of that. I'm not even discussing that.

            It's cleaner, easier to read,

            Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

            No, you argued that your way was cleaner and easier to read. I'm saying it's not.

            No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

            And I disagree that it's cleaner to edit the main config. It's set up correctly out of the box, you only edit that specific file if you need to make a change to the server itself. If nothing else have one monolithic file under conf.d, but don't change the servers config,

            scottalanmillerS 1 Reply Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @stacksofplates
              last edited by

              @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:

              @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:

              @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.

              That breaks the point of a state machine.

              It doesn't have to be ad hoc. That was just an example to show how simple it would be.

              @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:

              @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.

              That breaks the point of a state machine.

              It doesn't have to be ad hoc. That was just an example to show how simple it would be.

              I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

              You will never convince me that this:

              worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

              Is easier to read than this:

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

              all of the traditional reasons don't apply any more

              Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

              I'm not trying to convince you of that. I'm not even discussing that.

              It's cleaner, easier to read,

              Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

              No, you argued that your way was cleaner and easier to read. I'm saying it's not.

              No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

              And I disagree that it's cleaner to edit the main config. It's set up correctly out of the box, you only edit that specific file if you need to make a change to the server itself. If nothing else have one monolithic file under conf.d, but don't change the servers config,

              No, it does things that I needed to change out of the box. So it had to be modified and managed either way. Having extra files elsewhere would not solve that piece.

              stacksofplatesS 1 Reply Last reply Reply Quote 0
              • scottalanmillerS
                scottalanmiller
                last edited by

                Example... by default Nginx listens on port 80. I don't know how to stop that without modifying the main file. I don't think anything in conf.d can do that. Or can it?

                1 Reply Last reply Reply Quote 0
                • stacksofplatesS
                  stacksofplates @scottalanmiller
                  last edited by

                  @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:

                  @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:

                  @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.

                  That breaks the point of a state machine.

                  It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                  @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:

                  @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.

                  That breaks the point of a state machine.

                  It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                  I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

                  You will never convince me that this:

                  worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

                  Is easier to read than this:

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

                  all of the traditional reasons don't apply any more

                  Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

                  I'm not trying to convince you of that. I'm not even discussing that.

                  It's cleaner, easier to read,

                  Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

                  No, you argued that your way was cleaner and easier to read. I'm saying it's not.

                  No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

                  And I disagree that it's cleaner to edit the main config. It's set up correctly out of the box, you only edit that specific file if you need to make a change to the server itself. If nothing else have one monolithic file under conf.d, but don't change the servers config,

                  No, it does things that I needed to change out of the box. So it had to be modified and managed either way. Having extra files elsewhere would not solve that piece.

                  Ok so change those specific settings, and leave it alone. That shouldn't ever change. It should be set once and left alone. The server {} sections are dynamic. They will change.

                  scottalanmillerS 1 Reply Last reply Reply Quote 0
                  • scottalanmillerS
                    scottalanmiller @stacksofplates
                    last edited by

                    @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:

                    @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:

                    @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.

                    That breaks the point of a state machine.

                    It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                    @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:

                    @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.

                    That breaks the point of a state machine.

                    It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                    I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

                    You will never convince me that this:

                    worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

                    Is easier to read than this:

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

                    all of the traditional reasons don't apply any more

                    Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

                    I'm not trying to convince you of that. I'm not even discussing that.

                    It's cleaner, easier to read,

                    Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

                    No, you argued that your way was cleaner and easier to read. I'm saying it's not.

                    No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

                    And I disagree that it's cleaner to edit the main config. It's set up correctly out of the box, you only edit that specific file if you need to make a change to the server itself. If nothing else have one monolithic file under conf.d, but don't change the servers config,

                    No, it does things that I needed to change out of the box. So it had to be modified and managed either way. Having extra files elsewhere would not solve that piece.

                    Ok so change those specific settings, and leave it alone. That shouldn't ever change. It should be set once and left alone. The server {} sections are dynamic. They will change.

                    Okay, so the logic is one file for the static "boilerplate" header. And one file for the dynamic content? That makes more sense to me.

                    stacksofplatesS 1 Reply Last reply Reply Quote 1
                    • stacksofplatesS
                      stacksofplates @scottalanmiller
                      last edited by

                      @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:

                      @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:

                      @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.

                      That breaks the point of a state machine.

                      It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                      @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:

                      @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.

                      That breaks the point of a state machine.

                      It doesn't have to be ad hoc. That was just an example to show how simple it would be.

                      I understand that it isn't the ONLY option, but it highlights how complex and messy sprawling files are when they aren't needed. I'm not seeing any benefits since the entire file structure is managed by the state machine anyway - all of the traditional reasons don't apply any more. But now there seem to be real benefits to the single file approach and real caveats to the multiple file approach. The state machine really seems to reverse the traditional logic. It's cleaner, easier to read, easier to manage, etc.

                      You will never convince me that this:

                      worker_processes  1;

events {
    worker_connections  1024;
}

http {

  server {
      listen 443 ssl http2;
      server_name server1.com www.server1.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server1.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server1.com/privkey.pem;

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

server {
      listen 443 ssl http2;
      server_name server2.com www.server2.com;

      ssl on;
      include ssl.conf;
      ssl_certificate      /etc/letsencrypt/live/server2.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/server2.com/privkey.pem;

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

                      Is easier to read than this:

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

                      all of the traditional reasons don't apply any more

                      Until you want to remove a site. Show me the logic you would use to remove a server section buried in the middle of that config.

                      I'm not trying to convince you of that. I'm not even discussing that.

                      It's cleaner, easier to read,

                      Of course, I never said otherwise. I totally agree. When I get to having multiple servers, that's definitely the way to go.

                      No, you argued that your way was cleaner and easier to read. I'm saying it's not.

                      No I did not. I agreed with you on having a dictionary. I argued that having that dictionary create lots of files seemed pointless when making a single one was cleaner.

                      And I disagree that it's cleaner to edit the main config. It's set up correctly out of the box, you only edit that specific file if you need to make a change to the server itself. If nothing else have one monolithic file under conf.d, but don't change the servers config,

                      No, it does things that I needed to change out of the box. So it had to be modified and managed either way. Having extra files elsewhere would not solve that piece.

                      Ok so change those specific settings, and leave it alone. That shouldn't ever change. It should be set once and left alone. The server {} sections are dynamic. They will change.

                      Okay, so the logic is one file for the static "boilerplate" header. And one file for the dynamic content? That makes more sense to me.

                      Right. I'm not arguing like one line per file. It could be one big file in conf.d, or a bunch of small ones. I don't care either way. But conf.d abstracts the actual server from the dynamic configs, that's what I'm arguing.

                      1 Reply Last reply Reply Quote 0
                      • stacksofplatesS
                        stacksofplates
                        last edited by stacksofplates

                        This way you can share the config(s) under conf.d between multiple machines using the same roles (or whatever Salt calls them) and have different main NGINX server settings.

                        1 Reply Last reply Reply Quote 0
                        • 1
                        • 2
                        • 3
                        • 3 / 3
                        • First post
                          Last post