61–68 of 68 posts
anyone have any pointers for simple an API driven managment of DNS/DHCP? (like, I don't want to have to configure 1000 moving parts) typically this seems to fall into the 'roll your own' or 'giant lumbering enterprise behemoth' category that does 10 other things. I'm looking for the sweet spot.
When I was working as a sysadmin, I kept a spreadsheet. I was told later of a repository of information that supposedly was what my spreadsheet did, but it didn't add anything new and was much harder to keep up. I built it up using nmap and then shelling into each individual machine and poking around to see what it did. This was back in the days before everything became virtualized, so each machine on the network was…
So you have exactly those sorts of problems that RDBMS are designed to solve. Therefore it makes sense to move to a DCIM system using an RDBMS under the hood, that allows for concurrent edits, and also can be accessed by automation (cronjobs, CI, etc.) via some sort of API (or direct DB read access).
When I was working as a sysadmin, I kept a spreadsheet. I was told later of a repository of information that supposedly was what my spreadsheet did, but it didn't add anything new and was much harder to keep up. I built it up using nmap and then shelling into each individual machine and poking around to see what it did. This was back in the days before everything became virtualized, so each machine on the network was…
If you're by yourself, using spreadsheets and nmap is usually fine. If you're working in a team of 5 or 10 or 50 sysadmins, spreadsheets turn into a huge mess. You either have to distribute them via mail etc. after every change, but then you will have concurrent edits that need to be merged manually. Or you put the spreadsheets on a network share with file locking, but then it will always be locked when you want to e…
Earlier quoted context omitted.
I totally agree, but having "infrastructure as code" means less documentation. Instead of documenting all the commands involved in configuring a machine as service X (ssh, run apt-get, paste this, etc.), I have documentation on how work with the configuration management system (roles in the roles/ directory, each node gets one role, commit to git, open PR, etc.). That documentation is in .md files in the config manag…
Ah the good old "self-explanatory code that needs no documentation".
Earlier quoted context omitted.
If you're by yourself, using spreadsheets and nmap is usually fine. If you're working in a team of 5 or 10 or 50 sysadmins, spreadsheets turn into a huge mess. You either have to distribute them via mail etc. after every change, but then you will have concurrent edits that need to be merged manually. Or you put the spreadsheets on a network share with file locking, but then it will always be locked when you want to e…
Just use Google Docs.
When I was working as a sysadmin, I kept a spreadsheet. I was told later of a repository of information that supposedly was what my spreadsheet did, but it didn't add anything new and was much harder to keep up. I built it up using nmap and then shelling into each individual machine and poking around to see what it did. This was back in the days before everything became virtualized, so each machine on the network was…
If you're by yourself, using spreadsheets and nmap is usually fine. If you're working in a team of 5 or 10 or 50 sysadmins, spreadsheets turn into a huge mess. You either have to distribute them via mail etc. after every change, but then you will have concurrent edits that need to be merged manually. Or you put the spreadsheets on a network share with file locking, but then it will always be locked when you want to e…
This means you do not have two sources of truth to maintain (what is in the RDBMS, and how that relates to what is in the infrastructure code repository), the RDBMS system does not have to reinvent versioning, you can see exactly how your infrastructure evolves, you can do atomic changes to both the infrastructure code and the infrastructure information that the code relies on (obviously you need a modern version control system for this), and the infrastructure code can access the infrastructure information in a much more straightforward (and much easier to test) way.
Earlier quoted context omitted.
If you're by yourself, using spreadsheets and nmap is usually fine. If you're working in a team of 5 or 10 or 50 sysadmins, spreadsheets turn into a huge mess. You either have to distribute them via mail etc. after every change, but then you will have concurrent edits that need to be merged manually. Or you put the spreadsheets on a network share with file locking, but then it will always be locked when you want to e…
There is an even better alternative. You can put infrastructure information into the same version control repository where your infrastructure code lives, and you can even keep all the benefits of spreadsheets by using plain text format spreadsheets like Org-mode tables. This means you do not have two sources of truth to maintain (what is in the RDBMS, and how that relates to what is in the infrastructure code reposi…
I'm not saying your example is wrong, but "there is an even better alternative" doesn't always apply. For smaller scales, sure.
Earlier quoted context omitted.
There is an even better alternative. You can put infrastructure information into the same version control repository where your infrastructure code lives, and you can even keep all the benefits of spreadsheets by using plain text format spreadsheets like Org-mode tables. This means you do not have two sources of truth to maintain (what is in the RDBMS, and how that relates to what is in the infrastructure code reposi…
This would become very exhausting if working with very large infrastructures. 80 000 virtual and physical servers? Have fun keeping that data consistent, up to date and available with Org-mode and version control. I'm not saying your example is wrong, but "there is an even better alternative" doesn't always apply. For smaller scales, sure.