1 |
On 07/01/2015 22:30, Stefan G. Weichinger wrote: |
2 |
> Am 07.01.2015 um 20:06 schrieb Tomas Mozes: |
3 |
> |
4 |
>> Strange, I only have successful stories with upgrading old gentoo |
5 |
>> machines. If you have a machine which you update regularly then you know |
6 |
>> all the issues during the time and so upgrading "per partes" leads to no |
7 |
>> surprises but the same challenges you've handled before. But yes, it |
8 |
>> takes time. |
9 |
>> |
10 |
>> Moreover, if you use configuration management like Ansible, you can even |
11 |
>> automatically merge changes when applications ship new configuration. |
12 |
> |
13 |
> Thanks for that posting, it reminds me of some bigger issue I wanted to |
14 |
> discuss here for quite a while now. |
15 |
> |
16 |
> Over the years I am now responsible for dozens of servers and VMs |
17 |
> running gentoo linux ... and I wonder how to efficiently keep track of them. |
18 |
> |
19 |
> I learned my first steps with puppet and use it in a basic setup for my |
20 |
> own machines in my LAN. It seems to work better for many identical |
21 |
> servers, let's say in a hosting environment. |
22 |
> |
23 |
> The servers at my customers are somehow similar but not identical: |
24 |
> |
25 |
> different setups for services ... different update-cycles (which have to |
26 |
> be synchronized and shortened as we have seen in this thread!) ... |
27 |
> |
28 |
> I look for a way of tracking all these systems: |
29 |
> |
30 |
> a) central database/repo with all the systems and how to access them: |
31 |
> |
32 |
> * unique system id |
33 |
> * what IP, port, ssh-key, etc etc |
34 |
> |
35 |
> I use git for local tracking of /etc on most of my systems in the last |
36 |
> years, but I did never really come up with a clever way how to |
37 |
> centralize dozens of separate git-repos ... one repo per server pushed |
38 |
> to one central git-home on of my inhouse servers? |
39 |
> |
40 |
> b) in addition tracking of let's say "rules" or "services": |
41 |
> |
42 |
> * which server runs e.g. apache? So if there is a new security warning |
43 |
> out there for apache ... ask system "which servers/customers would need |
44 |
> that update?" |
45 |
> |
46 |
> etc etc |
47 |
> |
48 |
> c) when was my last access to that server? Have I looked into it lately? |
49 |
> |
50 |
> (or more business-oriented:) |
51 |
> Do I even have to / does the customer pay for that?) |
52 |
> This should lead to some SLA-kind-of-thing, yes ... a bit off-topic for now. |
53 |
> |
54 |
> - |
55 |
> |
56 |
> Puppet is more oriented to push configs out to systems. |
57 |
> |
58 |
> Maybe a combination would apply ... puppet for building the basement, |
59 |
> having stuff generalized (this path, that password/ssh-key ....) |
60 |
> |
61 |
> and some other components to track what has been done over time. |
62 |
> |
63 |
> I run OTRS ( http://en.wikipedia.org/wiki/OTRS ) for my daily work and |
64 |
> looked into their module "ITSM" ( |
65 |
> https://www.otrs.com/homepage/software/otrsitsm-features/ ) lately ... |
66 |
> it allows to create "configuration items" (think: ITIL) etc, so far I |
67 |
> think this is a bit of overkill and not really fitting the size of my |
68 |
> business. |
69 |
> |
70 |
> I'd love to keep it simple and CLI-oriented: |
71 |
> |
72 |
> Gentoo allows to define (nearly?) everything via text-files, combined |
73 |
> with the cleverness of git (and maybe puppet) this should give me a way of |
74 |
> |
75 |
> a) easily deploy new systems with configs according to some standards: |
76 |
> I want these packages/users/paths/files ... |
77 |
> |
78 |
> b) track these systems: what boxes am I responsible for, what is out |
79 |
> there and failing? ;-) (not talking monitoring here ... just what are my |
80 |
> active systems out there) |
81 |
> |
82 |
> from there I should slowly get into defining new contracts with my |
83 |
> clients including regular checks each 3 or 6 months ... what has to be |
84 |
> done, are there any bigger updates to do (think udev, baselayout ...) |
85 |
> and tell them if is possible to update the box within a few hours in |
86 |
> parallel to normal work or if we need a bigger maintenance window. |
87 |
> |
88 |
> --- |
89 |
> |
90 |
> I am sure there are many other gentoo-users out there with similar |
91 |
> challenges to face. And I am looking forward to your thoughts, |
92 |
> experiences and recommendations! |
93 |
|
94 |
|
95 |
In my opinion, ansible almost always beats puppet. |
96 |
|
97 |
Puppet is a) complex b) built to be able to deal with vast enterprise |
98 |
setups and c) has a definition language I never could wrap my brains |
99 |
around. It always felt to me like puppet was never a good fit for my needs. |
100 |
|
101 |
Then ansible hit the scene. Now ansible is designed to do what sysadmins |
102 |
do anyway, to do it in mostly the same way, and to do it in an automated |
103 |
fashion. It fits nicely into my brain and I can read a playbook at a |
104 |
glance to know what it does. |
105 |
|
106 |
Ansible deploys stuff and makes it like how you want it to be. It is |
107 |
equally good at managing 1000 identical machines as 100 mostly the same |
108 |
ones, or 20 totally different ones. How it manages this miracle is not |
109 |
easy to explain, so I urge you to give it a test drive. Fool around with |
110 |
a bunch of VMs to get a feel of how it works. A tip: keep it simple, and |
111 |
use roles everywhere. |
112 |
|
113 |
Ansible works nicely with other tools like vagrant and docker which |
114 |
build and deploy your base images. Once you have a base machine with |
115 |
sshd running and an administrative login account, ansible takes over an |
116 |
manages the rest. It works really well. |
117 |
|
118 |
On the business side of things, yes indeed you need to rationalize |
119 |
things and what you offer to customers. There comes a point where you |
120 |
the business grows and you just can't manage all these different things. |
121 |
Mistakes get made, SLAs slip, and everyone gets annoyed. |
122 |
|
123 |
On how to track all that real-world data you mentioned, I have a few |
124 |
rules of my own. Monitor and track everything I can, get and store as |
125 |
much info out of logs as I can. All the info you need is in there |
126 |
somewhere. But how to get it is a problem highly specific to your |
127 |
business. Maybe start some new threads each one with a specific |
128 |
question, and watch for common solutions in the answers? |
129 |
|
130 |
-- |
131 |
Alan McKinnon |
132 |
alan.mckinnon@×××××.com |