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: absentYeah, 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: absentYeah, 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.comall 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.
-
@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: absentYeah, 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: absentYeah, 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.comall 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.
-
@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.
-
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.
-
@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: absentYeah, 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: absentYeah, 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.comall 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,
-
@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: absentYeah, 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: absentYeah, 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.comall 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.
-
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?
-
@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: absentYeah, 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: absentYeah, 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.comall 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.
-
@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: absentYeah, 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: absentYeah, 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.comall 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.
-
@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: absentYeah, 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: absentYeah, 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.comall 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.
-
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.
