Hacker News new | comments | show | ask | jobs | submit login

I have a baremetal server and 99% of my admin task is apt-get update, apt-get upgrade. I have a diary where I write all the other admin tasks (the most complex one was configuring apache). When I buy a new server, I reread my notes to do some copy/paste. The freedom of a bare server is priceless ;-)



Transcribe those notes into Ansible and you'll have a one click solution for any new server. Or a thousand of them at once.


Cannot upvote this highly enough.

For old tech stacks we've had to maintain meticulous notes with setup and maintenance steps. They're very error prone and require constant upkeep to keep our build notes up to date.

With our new tech stack where we're (currently) using Docker and a BASH deployment script it's a breath of fresh air. We just keep our Dockerfile and setup scripts in Git. The script tracks the app version and is self documenting. We of course know it's always going to be correct because our CI server would complain if it wasn't.

The best part of it is that the ridiculously detailed document we used to have to maintain would take as much time as our automated strategy so in engineering resource the cost difference hasn't been very much at all.


A good (short) script can be a better documentation and at the same time be provably correct (just run it).


Deployment scripts existed before Docker.


Yes, but docker has created an incentive to publish them. When I want to install something, I search for a docker image that has it preinstalled and I read the dockerfile. I can choose either to use the docker image or to perform the installation globally on my main system. And, by the way, I have learned the installation procedure.


Out of curiosity, what is your usage scenario? In the place I work I use it for workstations (ca. 400 workstations and 10 servers), but I rarely use it for servers - neither for my employer nor for my customers. Somehow these servers are quite different from each other in terms of both hardware and software so I never quite understood the advantage in this case.


Ansible is clientless and the easiest orchestration system to setup, which is why I mentioned it, but I only use it in some scenarios like setting up a server for a specific task.

Services like the ELK (Elasticsearch, Logstash, Kibana) stack and their variables include adding repositories, installing the software, configuring it, and Ansible makes sure that I get the same result no matter if it's an older generation VM, or if it has a different Linux distro.

That way in case of any failure or if any service needs to be scaled, a single Ansible run will do all the tasks for me and get my machine(s) ready and identical to each other.

Chef is used on a daily basis in a similar manner, but basically for standardization, making sure all the settings, users, critical files are the same after every run.

This is very useful for bootstraping new VMs and keeping old ones in order in two main scenarios - a client/user makes changes that they shouldn't have and a regular Chef run makes it standardized again and making simple global changes like adding a new resolver, adding a cron job or installing a new package.

I can't imagine not using them on a daily basis, but that's because of the 1500+ servers I manage.


Well, that's all good until RAID goes down - your notes will only be partially useful then as there are many scenarios. Normally after the failed drive has been replaced the array should pick it up but if it doesn't the real fun begins.


if you have several servers you can either wait until the drive has been repaired (by the hosting provider) and just reinstall. If you need it more quickly you can spin up a new dedicated server. Many providers will set up bare metal servers within a few minutes (as long as the demand isn't too big). It doesn't give you the ability to scale 1000x within a few hours but that won't be a problem for most.


Software RAID is for you. Hardware RAID is only useful if you are buying the high end ones. Other than that software RAID is more flexible and is less susceptible to failure.


I also use software RAID. Nevertheless, it's not infallible. Recently a disk in one of the arrays went down, it got quickly replaced, but the server wouldn't boot. I had to connect via console and reinstall Grub - only then would the server boot and rebuild the array. A few weeks ago three disks failed at once. In cases like this the parent's notebook will be of limited use. In my experience traditional disks fail every 3-5 years - it's not something you can avoid.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: