0

I would like to get better control over my deployment environments, but I share the system administration responsibility with an IT department that has their own (not fully automated) processes for bootstrapping VM-instances, managing organization users and performing security updates.

Can I still benefit from using Chef (probably Chef-Solo), even though the systems will have an initial state that is outside my control, and will periodically change due to security updates outside of Chef (and possibly also other manual intervention)? I'm not in a position to introduce a different workflow at the IT department.

Their responsibilities:

  • Provide the hardware and VM
  • Install an OS with a "basic set of features" (currently SLES 11)
  • Applying security updates from the same SLES-release
  • Manage access for any organization users
  • Backups

My responsibilities:

  • Install and manage application dependencies (with a policy to prefer packages from the SLES distribution)
  • Applying security updates to anything installed that are not part of the SLES distribution
  • Configure needed services
  • Deploying applications

As far as I can tell this goes against the idea of a fully controlled environment that is behind tools like Chef, and it will leave room for divergences between production environments and between them and my staging environment (a local VM that IT never touches).

Is using a tool like Chef still worth the "bother"? How would my workflow need to differ from that of a fully controlled environment?

Daniel
  • 165
  • 1
  • 1
  • 8
  • 2
    Your IT department really needs to start using chef, or puppet, or something other than 20 year old shell scripts. – Michael Hampton Nov 26 '13 at 07:20
  • Two independent teams working on the same server sounds like a recipe for downtime. Long-term, your goal should be to either use the same tools they have or take everything from the hardware up away from them. Setting up Chef may aid that transition. – Ladadadada Nov 26 '13 at 08:03

2 Answers2

2

I'd say you have even more use for Chef than in the case where you control everything. I think you have the wrong idea about what Chef is there to do for you.

Chef isn't about controlling the entire environment. In fact there are things that you probably shouldn't attempt to provide with Chef. Provisioning ( which is largely what your IT department is providing ) is a problem that Chef and other CM systems don't really address. Chef takes over after the OS is installed and the basic network connectivity is setup. Really there isn't a whole lot of difference between what your IT department is providing and what you'd get from AWS.

Chef (and other good cm's) are about ensuring that the configuration is both stable and reproducible. In your case it seems ideal as if something steps on your configuration, you want it restored ASAP. You can use Chef to control as much or as little of the configuration as you want.

If you have a production application that requires configuration, you need a configuration management system for that application. Chef may or may not be the right tool for you, but you need something. Your CM can be as simple as keeping the config files in version control and using a makefile to install them. ( Fine for a single service on a single machine, but not much else. )

The question you need to ask is what scale do you work at and how many services do you need to manage? Chef is a power multiplier, but it amplifies both the good and the bad. If you make a mistake, you make it EVERYWHERE. So this requires some means of testing and a fair amount of initial work. But this power enables you to work at a much larger scale.

If you've got more machines or more services to manage than you have fingers on one hand, then I'd at least try using Chef and see if it works for you.

Fred the Magic Wonder Dog
  • 2,035
  • 10
  • 17
1

Besides it not being "best practice" i would say that there could be some benefit with using chef(-solo).

Given you really "own" the application-stack that you would like manage you could manage it with chef. Security-updates should - AFAIK - not interfere with that since they are usually updates of the application(-binary) and not the configuration that you would like to manage. But if the other team would change the directory/file permissions of your application stack there would be a problem since they would probably not understand why that changes every hour.

Another possibility would be that you use the backups which chef does of every file it touches and diff them to the expected state - after that you could merge possible configuration changes of the team, but there would be some inconsistent state for the time you need to merge

so my conclusion would be: if you just want to manage - say - apache on some server i guess you could do that with any configuration management - if the other team is not trying to change the same configuration

Philipp
  • 116
  • 4