-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathfeed.xml
More file actions
223 lines (185 loc) · 21 KB
/
feed.xml
File metadata and controls
223 lines (185 loc) · 21 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Practical Automation</title>
<description></description>
<link>http://practical-automation.com</link>
<atom:link href="http://practical-automation.com/feed.xml" rel="self" type="application/rss+xml" />
<item>
<title>Maturing Automation Part 1 - Scripting</title>
<description><p>Automation is one of those fun words. It&#39;s one of those things every one wants but no one ever sits down and defines what that means to them. Over my career my understanding of it has changed. When I was first starting out I didn&#39;t really view my one off scripts as &quot;automation&quot;. That word was reserved for fully developed applications not the boot script I used to map printers on branch PCs. Now a days I see automation as the umbrella, much like a DBA and an
Info Sec analyst both work under the IT umbrella. Around the office, I often hear &quot;automation&quot; as &quot;deployment automation&quot;. In a large scaling business, most people drift to the concerns of deployment time work. Last year I started a mission to correct that. Any time I heard some one refer to what I do as &quot;deployment automation&quot;, I would give a little rant about how the focus on deployment was all wrong. This is because deployment is only the beginning of this system&#39;s lifecycle and frankly is the easiest part of automation. But merely automating deploying of an application stack or toolset
doesn&#39;t begin to tame the chaos that is Operations. Enter the first stage in maturing automation, scripting.</p>
<p>Scripts are simultanously the best and worst tool in an Engineer&#39;s toolbox. The benefits are obvious, there are a plethera of languages out there that make scripting easy, they reduce manual efforts, and they enable operators to take some control over their daily tasks. They also provide a seemingly fast turn around. A manager needs something done, he just turns to his top Engineer and says give me a fast script. It is loved becauase there is no need to include an outside team. No need to talk to
those dreaded developers that just don&#39;t get operational pains. I believe the pains that make them the worst tool are more hidden.</p>
<p>First, lets ask why are the seemingly a faster turn around. One way I have seen is because the person is developing the script as he completes the work. So work is getting done as the script grows. Also, there is no need for gathering requirements or communicating needs to another developer. The engineer creating his script is also the subject matter expert, so no need for cross team communication. I say these things are hidden because since a script is usually developed and used with in a team, the growth pains of catching and resolving bugs are all internal, unlike when a team is asked to use another team&#39;s tool. The then simple hiccups caught and resolved by the engineer running the script change to the nasty bug that the absent minded developer put in my way.</p>
<p>Next, I rarely see production scripts controlled under code management and if they are it isn&#39;t a group repo but someone&#39;s private repo that they may have shared to a few collegues but probably isn&#39;t well know for any one to contribute back to or get the latest updates. If that is the case, controlling what version is being used on which system is harder and therefore a chance to introduce inconsistencies into your environment.</p>
<p>Speaking of inconsitencies, I claim scripts also have just as much chance to increase inconsistencies as they do to reduce them. Have you ever seen a build process that
is, run scripts A, B, C and D. Do you think those scripts were developed and maintained together, or is it more that they were created organically as engineers and systems grew? What if script A from 5 years ago set a simple setting to one thing and then the newer script D, which was developed by a completely different team than the 5 year old team, sets it to another. What happens if the implementor ran them in the wrong order, or forgot to run the last one? Scripts provide false security, but
hey you can already right another validation script to catch that right?</p>
<p>Neither are they regularly maintained. By maintenance, I mean tested as part of a system upgrade or release
processes to make sure that the new system doesn&#39;t break them, or worse, they break the new system. They don&#39;t grow with the system. If Engineer A likes python and wrote a script to complete a daily task, then left the company and his replacement is more comfortable with java then rather than extending the script they completely redo the script as a java tool and then add the new instruction set. </p>
<p>These things aren&#39;t horrible, but they are hidden. It is easier for us to forgive our own mistakes or burdens we put on ourselves than those we see put onto us by others. It is just easier to assume neglect or ignorance on others than assuming that person had the best of intentions to make our lives easier but lacked critical knowledge or just didn&#39;t share the same experience as ourselves. That is the horrible part. That is what breaks communication chains between teams and degrades operational stability and ultimately increases choas in production. Always assume
positive intent. Always try to build up relations with teams rather than tear them down in an act of frustration.</p>
</description>
<pubDate>Sat, 23 Jan 2016 00:00:00 -0600</pubDate>
<link>/2016/01/Maturing_Automation_Part1</link>
<guid isPermaLink="true">http://practical-automation.com/2016/01/Maturing_Automation_Part1</guid>
</item>
<item>
<title>A New Year, A New Style</title>
<description><p>I started this blog early last year, in a hope to make up for what I saw as a lack of public documentation around the VMware Puppet modules. For a number of years, I have enjoyed working with VMware products and when I was introduced to Puppet a few years ago I became equally fascinated. So the VMware modules are a great convergence of these interest, however, I feel it is hard for people not familiar with the vSphere APIs to get a lot out of them. The natural place to start seemed to discuss
<a href="http://practical-automation.com/2015/04/Transports">Transports</a> since all the resources rely on them. Then was my post on the <a href="https://github.com/vmware/vmware-vcsa">vmware-vcsa</a> module since it boot straps the VCSA and is a smaller module. After that things got fuzzy, and I lost focus. Honestly, I might have lost a bit of interest in documenting manifests. So in 2016 I plan on mixing it up a bit. I hope to get more involved in the community in order to understand if people have a desire to use these modules and if so what they find as a hinderance. I plan on including some editorials and expand to some other work I hope to be doing in some free time.&#39;</p>
</description>
<pubDate>Fri, 22 Jan 2016 00:00:00 -0600</pubDate>
<link>/2016/01/A_New_year</link>
<guid isPermaLink="true">http://practical-automation.com/2016/01/A_New_year</guid>
</item>
<item>
<title>VCSA Module</title>
<description><p>The <a href="https://github.com/vmware/vmware-vcsa">vmware-vcsa</a> module is centered around the initial configuration of the vCenter Server Appliance. The appliance itself comes with everything installed but there is some initial configuration before the vCenter is 100% up.</p>
<p>Note: The <a href="https://github.com/vmware/vmware-vcsa">vmware-vcsa</a> module currently only supports the 5.x versions of the VCSA. I am pretty sure the changes to the 6.0 VCSA module break some of these, but we will have to fix that soon so stay tuned.</p>
<h3 id="getting-started"><strong>Getting started</strong></h3>
<p>All these resources use the SSH transport previously discussed. Any manifest using these resources should start with creating the transport</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">transport { ‘ssh’ :
username =&gt; ‘root’,
password =&gt; ‘temppassword’,
server =&gt; ‘192.168.1.101’,
}
</code></pre></div>
<h3 id="vcsa_eula"><strong>vcsa_eula</strong></h3>
<p>Clearly this is used to accept the EULA for the appliance</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_eula { ‘accept’ :
ensure =&gt; accept,
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<h3 id="vcsa_db"><strong>vcsa_db</strong></h3>
<p>The vcsa_db resource sets the vCenter database settings. I am betting most appliances out there are just running embedded databases which is pretty simple.</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_db { ‘embedded_db’ :
ensure =&gt; present,
type =&gt; ‘embedded’,
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<p>I hope you are running an embedded database because while the type allows values ‘oracle’ and ‘PostgreSQL’ the provider doesn’t actually use the additional parameters that would be required to connect to a remote database. I hope we fix this as we retrofit the module for the 6.0 appliance but if you would like this feature I would encourage you to open an issue on GitHub.</p>
<h3 id="vcsa_java"><strong>vcsa_java</strong></h3>
<p>The vcsa_java resource is used to set the javaheap settings for the tomcat, inventory and SPS services. You should make sure to include all three because the command line tool uses them serially.</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_java { ‘settings’ :
ensure =&gt; present,
inventory =&gt; 2048,
sps =&gt; 512,
tomcat =&gt; 1024,
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<h3 id="vcsa_sso"><strong>vcsa_sso</strong></h3>
<p>The vcsa_sso resource configures where the SSO service will live and it was recently extended to support external SSO services.</p>
<p>For a simple embedded SSO server:</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_sso { ‘sso’ :
ensure =&gt; present,
dbtype =&gt; ‘embedded’,
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<p>Optionally when configuring a local SSO server you can use the password parameter to change the default password for <a href="mailto:administrator@vsphere.local">administrator@vsphere.local</a></p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_sso { ‘sso’ :
ensure =&gt; present,
dbtype =&gt; ‘embedded’,
password =&gt; ‘newpassword’,
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<p>Or for a connecting to an external SSO server:</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_sso { ‘sso’ :
ensure =&gt; present,
dbtype =&gt; ‘external’,
ls =&gt; ‘https://&lt;fqdn&gt;:7444/lookupservice/sdk’,
login =&gt; ‘administrator@vsphere.local’,
password =&gt; ‘mypassword’,
principal =&gt; ‘root@localos’, # This is the user or group that will be assigned as the vCenter admin
is_group =&gt; false, # True if the ‘principal’ is set to a user account
thumbprint =&gt; &#39;12 34 56 A5 5B 56 E1 4F 3C 6C D5 D0 78 90 D1 29’, # This can be set ‘insecure’ if you want to use an untrusted sort
transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<h3 id="vcsa_services"><strong>vcsa_services</strong></h3>
<p>The vcsa_services resource starts all the services.</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">vcsa_services { ‘start_services’ :
ensure =&gt; present, # Alternatively this can be set to &#39;running&#39;
Transport =&gt; Transport[‘ssh’],
}
</code></pre></div>
<h3 id="wrap-up"><strong>Wrap Up</strong></h3>
<p>All these resources are centered around the vpxd_servicecfg command line utility. If you want to know more about what can be substituted into each parameter feel free to run <em>vpxd_servicecfg -h</em> on your VCSA and see the detailed documentation around how to use the utility.</p>
</description>
<pubDate>Mon, 11 May 2015 00:00:00 -0500</pubDate>
<link>/2015/05/VCSA_Module</link>
<guid isPermaLink="true">http://practical-automation.com/2015/05/VCSA_Module</guid>
</item>
<item>
<title>Transports</title>
<description><p>Before I got involved with the VMware puppet modules, I had only been using Puppet for a few months and I had only used it to manage the system the Puppet agent was running on. But the original team behind the VMware modules was trying to manage a system that didn&#39;t run off local config files. They needed to hit a remote system where a local Puppet agent might not work, and so enter &quot;Transports.&quot; I won&#39;t dive too deep into transports as there are already some posts that do that which
I shall link below. But all the VMware modules to rely heavily on some type of transport, so I would be amiss in getting started with walking you through them without at least touching on transports.</p>
<p>So what makes a transport special? After all, I am sure that the VMware modules aren&#39;t the only ones to attempt to manage a remote system via API or some other interface. An over simplication might be a logical representation of your target system, i.e hostname and credentials. In reality they are also the entity that executes your desired state. For instance, the vSphere transport type would certainly hold the those details such as hostname and credentials, but when the provider needs
to execute a command it will pass it to the target system via the transport resource within Puppet. What this gets you is the ability to make that initial connection once, and then send all communication through that channel. Depending on the target protocol, that could save you some decent cycles. Currently the VMware modules utilize three transports which I want to introduce you to.</p>
<p><br></p>
<h3 id="ssh-transport"><strong>SSH Transport</strong></h3>
<p>The SSH transport is utilized by the <a href="https://github.com/vmware/vmware-vcsa">vmware-vcsa</a> module. This module is focused on getting the VMware vCenter Service Appliance bootstrapped so the services are configured and running. The view is that an appliance is a black box and so one shouldn&#39;t count on a puppet agent running local. It is for this reason the <a href="https://github.com/vmware/vmware-vcsa">vmware-vcsa</a> module uses the SSH transport to send commands to the remote system to bring up the vmware services. </p>
<p>The options can be a hash consisting of additional command line parameters to pass to the ssh session.</p>
<h4 id="example"><strong>Example</strong></h4>
<div class="highlight"><pre><code class="language-text" data-lang="text"> transport { &#39;ssh&#39;:
username =&gt; &#39;localuser&#39;,
password =&gt; &#39;mypassword&#39;,
server =&gt; &#39;fqdn&#39;,
# options =&gt; $ssh_options,
}
</code></pre></div>
<p><br></p>
<h3 id="vsphere-transport"><strong>vSphere Transport</strong></h3>
<p>The vSphere trasnport is, as expected, utilized by the <a href="https://github.com/vmware/vmware-vcenter">vmware-vcenter</a> module. This interacts with the vSphere API to configure vCenter or ESX hosts. The options here can be a hash of additional options for the connection. The example below shows setting the API revision and the insecure option to allow for self-signed certificates.</p>
<h4 id="example"><strong>Example</strong></h4>
<div class="highlight"><pre><code class="language-text" data-lang="text"> transport { &#39;vcenter&#39;:
username =&gt; &#39;localuser&#39;,
password =&gt; &#39;mypassword&#39;,
server =&gt; &#39;fqdn&#39;,
options =&gt; {
&quot;insecure&quot; =&gt; true,
&quot;rev&quot; =&gt; &quot;5.1&quot;,
},
}
</code></pre></div>
<p><br></p>
<h3 id="vshield-transport"><strong>vShield Transport</strong></h3>
<p>Again, clearly the vShield transport is used by the <a href="https://github.com/vmware/vmware-vshield">vmware-vshield</a> module and it interacts with the vShield API. This transport does not have an options parameter</p>
<h4 id="example"><strong>Example</strong></h4>
<div class="highlight"><pre><code class="language-text" data-lang="text"> transport { &#39;vshield&#39;:
username =&gt; &#39;localuser&#39;,
password =&gt; &#39;mypassword&#39;,
server =&gt; &#39;fqdn&#39;,
}
</code></pre></div>
<p><br></p>
<h3 id="additional-references"><strong>Additional References</strong></h3>
<ul>
<li><a href="https://github.com/vmware/vmware-vmware_lib/blob/master/lib/puppet_x/puppetlabs/transport/ssh.rb">SSH Transport</a> : Review the code for the SSH transport</li>
<li><a href="https://github.com/vmware/vmware-vcenter/blob/master/lib/puppet_x/puppetlabs/transport/vsphere.rb">vSphere Transport</a> : Review the code for the vSphere transport</li>
<li><a href="https://github.com/vmware/vmware-vshield/blob/master/lib/puppet_x/puppetlabs/transport/vshield.rb">vShield Transport</a> : Review the code for the vShield transport</li>
<li><a href="http://www.nanliu.me/blog/2013/02/27/puppet-managing-vcenter-and-vshield">Nan Liu</a> : See Nan Liu&#39;s original post on these modules and their transports</li>
</ul>
</description>
<pubDate>Wed, 29 Apr 2015 00:00:00 -0500</pubDate>
<link>/2015/04/Transports</link>
<guid isPermaLink="true">http://practical-automation.com/2015/04/Transports</guid>
</item>
<item>
<title>Introduction</title>
<description><p>I am sure my story is no different than most of yall. I am a technology geek that has been blessed enough to make his hobby his career, or was it making my career my hobby? In either case, I have spent my career learning from those that have come before me and I feel that I am finally able to give back in some small way. I hope this blog will help ease those getting started with some of the amazing tools out there, and to start with I am going to help introduce you to what we are doing with the VMware Puppet modules. I will try and keep each post from going too into the weeds, but if I don&#39;t explain things clearly or you have a request for me to cover a specific resource type feel free to reach out to me on <a href="https://twitter.com/IcanScriptThat">twitter</a>.</p>
<p>Yesterday, we updated the modules on the <a href="https://forge.puppetlabs.com/vmware">forge</a>. This was long overdue and moving forward they will be kept updated.</p>
</description>
<pubDate>Wed, 22 Apr 2015 00:00:00 -0500</pubDate>
<link>/2015/04/Introduction</link>
<guid isPermaLink="true">http://practical-automation.com/2015/04/Introduction</guid>
</item>
</channel>
</rss>