Just got done deploying csgoisfail.com via do droplet, replete with nginx, mysql, php, drupal 8, and drush from scratch, and - since scripting this sort of basic deployment has been on my mind for over three to five years now... long before the convenience of digitalocean droplets - basically tried to standardize this sort of deployment via script. I didn't have time to follow through with that (at least, not entirely), especially since digitalocean.com's dashboard incentivizes me to be lazy via allowing me to simply snapshot deployments.

Generally, I use DO snapshots inthe following use cases:

1: Before implementing major or experimental configuration alterations in productions, I'll (usually, if there's any chance that an important site could be borked, remember to) take the extra 10-60 minutes to poweroff the site and use the digitalocean dashboard to take a snapshot of the (then currently working) configuration. This is great because I don't have to create a whole backup set (with mysql dumps, files, and the associated myriad of config files and all, all of which I invariably forget some important nut or widget which makes restoring from such backups a pain in the ass, plus it requires entire redeployment time overhead of the entire server environment etc. etc.; with a snapshot, I get a one-click-redeployable image of everything on that server AT THAT MOMENT).

2: For backups - NOT A BEST PRACTICE, I KNOW, I KNOW, but what I lose from not having proper backups, redundancy, and walk-through-able-ness, I gain in *MAYBEY* (when the excrement hits the AC) at least having a snapshot to fall back on. I run (and have run) *TONS* of servers; not just for myself, but as managed servers for others, etc.; there's simply no way that I can provide legit backup services for EVERYTHING (though, for some servers, I do my damndest) that's under my purview (and of course, I advise clients of this as well, clearly and up-front... backups are a motherfucker to manage if you're not the sysadmin/engineer directly in charge of the infrastructure necessary, blah blah blah)... so yes: I use DO snapshots for backups (always cognizant of the possible losses should DO itself disappear tomorrow/other catastrophic problems to not having 3 copies of everything at all times). So there's the backups use case.

3: For Templatizing Server Deployments: This is by far my favorite (and DO's intended) use case for DO snapshots: I can spin up a server from a template snapshot, iterate all the fuck over it like a grafitti artist, filling it with whatever crazy madness or garbage I wish (be it intentionally experimental with the intent to deploy some iteration of said madness in production at a later date, or be it purely for throw-away "what shit sticks" purposes), keep notes on what I've done, what worked, what didnt', then either save that new iteration (if it meets my goals) to a new snapshot, or scrap it and roll it back to the previous snapshot. Having this capability is so far beyond my wildest imaginings in terms of being a sysadmin back when I started with servers (pre-2010) that it blows my mind.

4: For Templatizing Deployment Configurations (For PRODUCTION DEPLOYMENTS): There is nothing I love more than when someone else's needs and my skillset meet... EXCEPT (!!!): for when they do so *AND* I have already gone through the trouble of templatizing said solution. The whole idea of computer science is doing the hard stuff once (hopefully with ample comments and a workbook if necessary, but still: do it once, then never again); I subscribe to this ideal wholeheartedly in ideology - if not in actual implementation. So, any time I start noticing majorly useful design patterns (progrommatically, or from a systems administrator's perspective), I try to formalize those solutions into one standardized solution. To be honest, there really isn't way I can stay in the game otherwise; it makes managing on going commitments much easier and better for all, allows me to focus on the solutions (to read: necesary tweaks to accomplish the objectives at hand) and makes me faster overall (which is always good).

So, to that end, I've recently begun spending a lot of time thinking about the best ways to protect account credentials for all of those standard sysadmin services, hoping to standardize them across my snapshotted images. I haven't fully investigated/researched what I'd like to do (outlined below) but will be making this a project next week (once my current workload is less demanding).

Ideally, what I'd like to do is have a tiny partition of my VPS drive chunked out and encrypted, containing (as a reference to me, for when redeploying a snapshot of said image, either for myself or for a client) a set of boilerplate credentials for that snapshot.... This sounds stupid, but it would go a long way:

1. It would make me totaLLY less reticent to create credentials specifically for that service by virtue of removing the fear that I may forget/lose my creds as generated through any number of best-practices-recommended packages: If I could know that, on any given VPS, there was an encrypted (and therefore, presumably secure) partition, protected by either a key or (as is my preference) a great password phrase that I'm able to remember (I won't go further into my password generation methodology than that, but just know that, having spent a lot of my life cracking passwords, I know that they are actually useful when they are of a certain length AND are also memorable enough to be recalled by the admin), I could store all the user names and passwords generated for services for that server (SQL, CMS, etc. etc. etc.) in a plain basically a plaintext file.

Sure, I know that (even if possible) this isn't ENTIRELLY SECURE, but given the parameters we're talking about (VPS, etc.), it would go SUCH A LONG WAY towards mitigating against possible compromise. Ok. Back to work on csgoisfail.com.