4 ms·

I like how nginx configuration works. It's simple, it's a DSL, it's a text file that's viewable by anyone, you can version it easily, you can comment in it, you

by amix 16y ago

I like how nginx configuration works. It's simple, it's a DSL, it's a text file that's viewable by anyone, you can version it easily, you can comment in it, you can quickly take backups or revert back to old configurations, you can send a kill -HUP to reload the configuration without taking your site down. The bottom line: The nginx, and the usual text based approach, is simple and it works, I can't really see what he is solving with this database approach other than adding a lot of additional complexity.

zedshaw 16y ago
So, everything you said applies to SQL. SQL is a DSL (and a standardized one). SQL is text, so it can be versioned, you can back it up, and you can do it also the .sqlite file. You can also do -HUP to reload configs, nothing about SQL or SQLite prevents that, and in fact, nginx has to completely restart its world to make this happen. Mongrel2 will probably be able to reload without kicking over the process. The problem I'm solving is one of operations automation and design. Go take a look at the nginx code for loading configurations and then go write an nginx module. Figuring out how to get configuration settings out of the thing is horrible. Then, come talk to me when you can change the nginx config on 100 hosts based on the hostname and three sections of the configuration file using sed and awk. Hell, let me know if you can load a random nginx config and tell me what version of nginx it works for. That'd be a trick.
- stcredzero 16y ago
  SQL is a DSL SQL is a DSL for dealing with Relations (n-tuples) and collections of Relations. In other words, its domain is Data in the most generic sense. It's not really Domain Specific to web server configuration per se. Maybe that doesn't matter, though. I know that Sinatra's config DSL is really doing nothing more than manipulating path data and associating that data with code. Ops people love manipulating stuff like that with SQL, so maybe it's a good fit.
- amix 16y ago
  nginx does restart, but without taking the site down which is the most important aspect and the most important feature. Brining us to another point, I have deployed a lot of servers that use textual configurations and I can't really see what problem you are solving and I can't see how storing the configuration in a relational database will solve any problems.
  - zedshaw 16y ago
    I'm solving the problem of migrations, automation, tooling, and simplicity. Yes, you can do the many of the same things in both, and if you're an old school "I-ssh-into-100-boxes-all-day" sysadmin then they're the same thing. If you're a modern system administrator who automates, automates, automates, then this is better. For example, my challenge still stands, load an nginx config and tell me what version of nginx it is for. If you can't even do that then how can you automate it better than a sqlite3 file (remember, sqlite3 file, NOT RDBMS).
    - amix 16y ago
      I use Fabric (fabfile.org) to automate deployments. It works pretty good and I don't see how it is going to work better with a relational database. Regarding your question: I don't really know or care what version a nginx config is written for (I could specify this in a comment if this was an issue and I can always test the config by running "nginx -t"). For the record, I have used nginx for years and this has never been an issue. Anyway, I am generally impressed by your other ideas in Mongrel2 and happy hacking :)
      - zedshaw 16y ago
        Using a SQLite database doesn't mean you can't use fabric, so it's not going to work better or worse. You see the difference? So far nothing you've said invalidates sqlite files or sql as a configuration interface. The version challenge points directly at what's wrong with config files: they aren't accessible to automation. If you can't even do this very simple thing from one programming language, then it means you can't do other things easily.
- cageface 16y ago
  Then, come talk to me when you can change the nginx config on 100 hosts based on the hostname and three sections of the configuration file using sed and awk. If I have a section of a config file that's host-specific I'll bust it out into an include and generate just the relevant parts. Go take a look at the nginx code for loading configurations and then go write an nginx module. Figuring out how to get configuration settings out of the thing is horrible. Putting settings into SQL doesn't magically solve this problem. As an admin I'm still going to have to know what fields and values each module expects. Much worse, I'm also going to have to manage tree-structures in SQL for directives with subdirectives, which is something even full-time SQL people often struggle with.
  - zedshaw 16y ago
    First, no, if you actually read the nginx code for modules they each have to define their own little schemas in raw C code using some undocumented or barely documented C structs. In the sqlite3 database any modules I do will be equal citizens, able to have their own tables, and query the database. Much more orthogonal solution. So yes, putting them in SQLite (not IN AND RDBMS), does magically solve it, and does it for all the languages that know sqlite3, which is all of them. As for having to know about the structure of the database and know trees and stanzas and things like that: Did you RTFA? I said there'd be handy tools for dealing with it so you don't need to know this stuff. Seriously, you think I'm going to foist a full on SQL schema on anyone? That'd be about the stupidest thing ever. Of course I'm going to have tooling that makes this easier to work with, and in fact you can write your own tools to manage it.
    - cageface 16y ago
      As for having to know about the structure of the database and know trees and stanzas and things like that: Did you RTFA? I said there'd be handy tools for dealing with it so you don't need to know this stuff. Seriously, you think I'm going to foist a full on SQL schema on anyone? So you are planning on wrapping this in some kind of reasonable DSL? If so, the fact that you're storing an intermediate representation in SQL seems uninteresting, although you also seem to suggest that the advantages of this approach are realized via direct manip via SQL. I can see some room for improvement and standardization in config languages, but any server that doesn't allow me to do config purely via text files and that doesn't have a config language rich enough to encompass directives with subdirectives and conditionals isn't useful to me. Why not just make everything Lua?

by amix 16y ago

zedshaw 16y ago

So, everything you said applies to SQL. SQL is a DSL (and a standardized one). SQL is text, so it can be versioned, you can back it up, and you can do it also the .sqlite file. You can also do -HUP to reload configs, nothing about SQL or SQLite prevents that, and in fact, nginx has to completely restart its world to make this happen. Mongrel2 will probably be able to reload without kicking over the process. The problem I'm solving is one of operations automation and design. Go take a look at the nginx code for loading configurations and then go write an nginx module. Figuring out how to get configuration settings out of the thing is horrible. Then, come talk to me when you can change the nginx config on 100 hosts based on the hostname and three sections of the configuration file using sed and awk. Hell, let me know if you can load a random nginx config and tell me what version of nginx it works for. That'd be a trick.

stcredzero 16y ago
SQL is a DSL SQL is a DSL for dealing with Relations (n-tuples) and collections of Relations. In other words, its domain is Data in the most generic sense. It's not really Domain Specific to web server configuration per se. Maybe that doesn't matter, though. I know that Sinatra's config DSL is really doing nothing more than manipulating path data and associating that data with code. Ops people love manipulating stuff like that with SQL, so maybe it's a good fit.
amix 16y ago
nginx does restart, but without taking the site down which is the most important aspect and the most important feature. Brining us to another point, I have deployed a lot of servers that use textual configurations and I can't really see what problem you are solving and I can't see how storing the configuration in a relational database will solve any problems.
- zedshaw 16y ago
  I'm solving the problem of migrations, automation, tooling, and simplicity. Yes, you can do the many of the same things in both, and if you're an old school "I-ssh-into-100-boxes-all-day" sysadmin then they're the same thing. If you're a modern system administrator who automates, automates, automates, then this is better. For example, my challenge still stands, load an nginx config and tell me what version of nginx it is for. If you can't even do that then how can you automate it better than a sqlite3 file (remember, sqlite3 file, NOT RDBMS).
  - amix 16y ago
    I use Fabric (fabfile.org) to automate deployments. It works pretty good and I don't see how it is going to work better with a relational database. Regarding your question: I don't really know or care what version a nginx config is written for (I could specify this in a comment if this was an issue and I can always test the config by running "nginx -t"). For the record, I have used nginx for years and this has never been an issue. Anyway, I am generally impressed by your other ideas in Mongrel2 and happy hacking :)
    - zedshaw 16y ago
      Using a SQLite database doesn't mean you can't use fabric, so it's not going to work better or worse. You see the difference? So far nothing you've said invalidates sqlite files or sql as a configuration interface. The version challenge points directly at what's wrong with config files: they aren't accessible to automation. If you can't even do this very simple thing from one programming language, then it means you can't do other things easily.
cageface 16y ago
Then, come talk to me when you can change the nginx config on 100 hosts based on the hostname and three sections of the configuration file using sed and awk. If I have a section of a config file that's host-specific I'll bust it out into an include and generate just the relevant parts. Go take a look at the nginx code for loading configurations and then go write an nginx module. Figuring out how to get configuration settings out of the thing is horrible. Putting settings into SQL doesn't magically solve this problem. As an admin I'm still going to have to know what fields and values each module expects. Much worse, I'm also going to have to manage tree-structures in SQL for directives with subdirectives, which is something even full-time SQL people often struggle with.
- zedshaw 16y ago
  First, no, if you actually read the nginx code for modules they each have to define their own little schemas in raw C code using some undocumented or barely documented C structs. In the sqlite3 database any modules I do will be equal citizens, able to have their own tables, and query the database. Much more orthogonal solution. So yes, putting them in SQLite (not IN AND RDBMS), does magically solve it, and does it for all the languages that know sqlite3, which is all of them. As for having to know about the structure of the database and know trees and stanzas and things like that: Did you RTFA? I said there'd be handy tools for dealing with it so you don't need to know this stuff. Seriously, you think I'm going to foist a full on SQL schema on anyone? That'd be about the stupidest thing ever. Of course I'm going to have tooling that makes this easier to work with, and in fact you can write your own tools to manage it.
  - cageface 16y ago
    As for having to know about the structure of the database and know trees and stanzas and things like that: Did you RTFA? I said there'd be handy tools for dealing with it so you don't need to know this stuff. Seriously, you think I'm going to foist a full on SQL schema on anyone? So you are planning on wrapping this in some kind of reasonable DSL? If so, the fact that you're storing an intermediate representation in SQL seems uninteresting, although you also seem to suggest that the advantages of this approach are realized via direct manip via SQL. I can see some room for improvement and standardization in config languages, but any server that doesn't allow me to do config purely via text files and that doesn't have a config language rich enough to encompass directives with subdirectives and conditionals isn't useful to me. Why not just make everything Lua?