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?
-
@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.
-
@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.
-
@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. -
@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?
-
@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 -
@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.
-
There is probably some config for "fill this directory with ONLY these files" but I've not found that yet.
-
@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.
-
Just like you should not be editing httpd.conf for vhosts with Apache, you should not be editing nginx.conf for your hosts with Nginx.
-
@JaredBusch said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:
Just like you should not be editing httpd.conf for vhosts with Apache, you should not be editing nginx.conf for your hosts with Nginx.
And /etc/sudoers
Special sudo permissions goes in the conf.d directory. Or use the wheel group for ALL.
-
@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.
-
@JaredBusch said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:
Just like you should not be editing httpd.conf for vhosts with Apache, you should not be editing nginx.conf for your hosts with Nginx.
That's what I'm questioning. Once we move to state machines, all of the logic behind that approach seems to vanish. There were loads of reasons to do it this way when we manually managed them. But none apply in this scenario. I can't figure out the benefits, but I definitely see caveats.
-
@stacksofplates said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:
@JaredBusch said in Deploying an NGinx Reverse Proxy with SSL on a LAMP Server with SaltStack:
Just like you should not be editing httpd.conf for vhosts with Apache, you should not be editing nginx.conf for your hosts with Nginx.
And /etc/sudoers
Special sudo permissions goes in the conf.d directory. Or use the wheel group for ALL.
Again, that's an example from a different style of management. Why would that apply here when none of the factors are the same?
-
@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.
@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.
-
@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.
-
@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.
-
@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,
-
@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.
