Hi all! So this is going to be a pretty long post, sorry up front.
I have all of my automation in place for building, deploying, and maintaining our applications using bash scripts and a front end website I created to gather information and call the scripts (ease of use so that I'm not as much of a bottle neck). Well the website got flagged because I used joomla to write it and some extensions are locked with an old version of php and security wants it gone. So I decided to modernize and wanted to move over to chef. I want to ease in so thought I'd run my plan by folks here and see if it seems plausible. Here's what I'm planning at this point.
Run a chef server that manages one node originally, the RedHat server that houses all of my bash scripts that maintain the servers. I would write recipes that call these scripts to do the various things that they do (deploy apps, stop apps, start apps...). I would need parameters that change in time for things such as the deployments. My plan is to write a simple web app that gathers the necessary parameters and builds attribute files for the recipes to use at runtime. I actually already have this code from the current website, but would have to redesign it to build parameter files rather than calling the bash scripts directly. This would, in essence, reproduce what I currently have.
Once that was in place, I would start breaking out functionality in the bash scripts a little at a time putting it into chef until all of the bash scripts were replaced by chef so I could retire these. Does this seem like a good plan? I'm just learning this stuff via a Udemy class (Chef Fundamentals: A Recipe for Automating Infrastructure). Any advise would be greatly appreciated! Thanks - Eric
So either I'm so far off base that folks are embarassed to comment, or this is a good way to start and constructive criticism isn't necessary. Can someone give me some idea if I'm lost or not? I can take it, lol... Thanks!
Your plan to import bash scripts into chef and then incrementally move functionality into chef resources is solid.
There are some places where your current model and Chef's model don't align:
- Chef works best when you have a mostly static set of configuration policy that you want to apply
- Chef can be used with another tool for on-demand execution, but it's designed more to apply the desired policy on a schedule.
Both of these engineered around, but you might also want to add something like rundeck to the mix, assuming you want to continue to provide a self-service, push button kind of experience.
Thanks Kallistec! Looking at rundeck, it seems kind of like an alternative to the website I was writing. Is that what you mean? Rundeck would create the parameter file and call chef?
That's part of it. The other part is that your current workflow seems to involve some imperative actions, like starting and stopping apps, etc. Chef has a more declarative point of view, i.e., you tell Chef what you expect the final state of the system to be and Chef takes whatever actions needed to make it so. It's completely possible to translate from one thing to the other, e.g., you tell Chef the expected state of a service is running and then on the next run you tell it the expected state is stopped and it will do the right thing, but there is some complexity involved in managing the translation from imperative to declarative. So it may be the case that some portion of your existing automation can be expressed most simply in a declarative way and another portion can be expressed most simply in an imperative way. For the stuff that is naturally imperative, leaving it in bash might save you from making things too complicated without a lot of downside.