72 lines
2.9 KiB
Markdown
72 lines
2.9 KiB
Markdown
|
---
|
||
|
|
date: 2014-11-21
|
||
|
|
title: DevOps Terminology
|
||
|
|
category: devops
|
||
|
|
---
|
||
|
|
|
||
|
|
Talking to a few people there seems to be a little confusion over the
|
||
|
|
various stages in the deployment pipeline. Specifically there seems to
|
||
|
|
be a little confusion over 3 things:
|
||
|
|
|
||
|
|
- Orchestration
|
||
|
|
- Provisioning
|
||
|
|
- Configuration Management
|
||
|
|
|
||
|
|
These seem to have got rather mixed up of late. I will put the blame
|
||
|
|
squarely at the doors of marketing departments because, well, why
|
||
|
|
not...
|
||
|
|
|
||
|
|
I should probably add that these are my opinions. It is all a little
|
||
|
|
grey, but this makes sense to me.
|
||
|
|
|
||
|
|
To me Configuration Management should be every single environment, no
|
||
|
|
matter how simple. By contrast the other 2 may not apply everywhere. Its
|
||
|
|
basic role is to take your basic system and prepare it for production.
|
||
|
|
|
||
|
|
It is also an ongoing process, because it does not only apply your
|
||
|
|
configuration. Once everything is going it continues to enforce that
|
||
|
|
configuration.
|
||
|
|
|
||
|
|
A benefit that comes from this is that it should also be effectively
|
||
|
|
self-documenting.
|
||
|
|
|
||
|
|
Personally I always head towards [Puppet](https://www.puppetlabs.com)
|
||
|
|
here. There are plenty of good options though, such as Ansible and
|
||
|
|
Saltstack.
|
||
|
|
|
||
|
|
Working back, provisioning should deploy the most basic system that can
|
||
|
|
hook up to your configuration management system.
|
||
|
|
|
||
|
|
> Personally I do not like templates, à la VMware. Rather I prefer to
|
||
|
|
> just to do fresh OS install. That way I do not need to perform a
|
||
|
|
> second pass to install updates. Having said that, when working with
|
||
|
|
> AWS or Openstack they are a very effective way to work
|
||
|
|
|
||
|
|
The key thing here is that it should link in with the next step
|
||
|
|
(configuration management). It is essentially that it hands the new
|
||
|
|
system over to CM with no input from the SysAdmin. As a Puppet user this
|
||
|
|
means that you should come out at the end with the Puppet agent
|
||
|
|
installed and configured.
|
||
|
|
|
||
|
|
I tend towards [Razor](https://github.com/puppetlabs/razor-server) which
|
||
|
|
is truly excellent. There are other good options such as
|
||
|
|
[Cobbler](https://www.cobblerd.org/), but basically anything that can
|
||
|
|
perform an OS install, add an agent and inject a config file is great.
|
||
|
|
In many environments, a simple PXE server with a bunch of kickstart
|
||
|
|
files may well be more than sufficient.
|
||
|
|
|
||
|
|
Orchestration is the first stage that provides an automated way of
|
||
|
|
launching your provisioning system. It also prepares the Configuration
|
||
|
|
Management. In my ver Puppet-centric world this means it should
|
||
|
|
configure Hiera data for what the new system(s) are to do.
|
||
|
|
|
||
|
|
It terms of tooling, there is always a certain amount of
|
||
|
|
cross-pollination. Puppet for example can be used as an excellent way of
|
||
|
|
[controlling your AWS
|
||
|
|
infrastucture](https://puppetlabs.com/blog/provision-aws-infrastructure-using-puppet)
|
||
|
|
which puts it firmly in the provisioning camp. I will not tell anyone
|
||
|
|
not to use it that way, but I personally see it as a little
|
||
|
|
*feature-creep*-like, so I will not be going there. I will be sticking
|
||
|
|
to the tried and tested UNIX philosophy of "do one thing and do it
|
||
|
|
well".
|