3 ms·

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

leonroy 9y ago
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.
- reacweb 9y ago
  A good (short) script can be a better documentation and at the same time be provably correct (just run it).
- dboreham 9y ago
  Deployment scripts existed before Docker.
  - reacweb 9y ago
    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.
dvfjsdhgfv 9y ago
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.
- rospaya 9y ago
  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.

leonroy 9y ago

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.

reacweb 9y ago
A good (short) script can be a better documentation and at the same time be provably correct (just run it).
dboreham 9y ago
Deployment scripts existed before Docker.
- reacweb 9y ago
  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.

dvfjsdhgfv 9y ago

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.

rospaya 9y ago
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.