I think deploying computer direction changes over production environments. The main purpose for this automation tool would be:
- Deploying
- Controlling
- Ordering Change for the System
- IT Infrastructure
I think deploying computer direction changes over production environments. The main purpose for this automation tool would be:
Puppet Enterprise has reduced the time of production changes or environment changes. It is reducing the time that the engineers spend applying changes of our infrastructure. They set it all up, the next environment, and after they have been tested, when they have to promote a change, they just apply it, and it's turned on on many of hundreds of open sub-ports. To do it manually, reducing the operative time, is a really big part. I think that's the most valuable thing, because your engineers use their time with creative things, visionary things, not doing repetitive tasks.
There are two kind of Puppets: Enterprise and Open Source. So, I use Puppet Enterprise, it's helped promote the console and the recording, the reading, controlling, the checking of managed change and putting the things back together.
I like it as the main. I can be relaxed, knowing that everything is in the state that it should be without taking many steps to find out how and to fix the things where there were changes properly ensures that.
It saves us time, we can apply patches through Windows servers, with our tools. But, with Puppet, it can save us approximately 38 hours a month.
We are constantly improving new features, like deploying. But also, I think that they're very strange. It is how the community contributes with the models that they have in Puppet first. But it's a continuous improvement process. We are always discovering new things.
No. I haven't had any issue with the stability of the product.
Well, if you are going bigger, you need to have more master servers and perform a low balancing from the servers. Also, yes, I feel like the kind of example, there's a limit of nodes that can be managed from one server. So I don't remember exactly how many. But if you need to add more nodes, you need to deploy another server into a trust relationship. Then you can deploy more nodes. I've had no issues with that.
I haven't gone too big. So I'm only working with one master.
You always find an obstacle, but you to give the feedback to them. Then, they can guide you through this to fix things that can help you to get your goals.
Well at the beginning it was kind of complex. Because you had a lack of knowledge. So we would have to read a lot. Test many things, the configuration. After training, we saw things more clearly. We got to change the approach when they were working on. But no, it wasn't very complex. There's a lot of knowledge that you need to read in the documentation. There were no issues if someone with experience pitched the things together.
It was a learning curve. Not too hard. It's more like a not too high, not too low. It was a small learning curve.
Well I'm trying to do my job to grow the community around here. Even in Santo Domingo, Dominican Republic, where we recently deployed a project using puppet. The system manager, the assistant system manager right now is being pain when applying changes between environments. Tried creating a folder in 20 servers, for example.
I'm trying to create a community. More people know about the same, they can share experience and work together. This is part of the mantra we live by. I think that this thing is nice, these things can help you to get your goals quicker, to get these things managed in the proper way, to free up your time to use it in a more productive way.
I think that they can only imagine $120 for node. I think it's not expensive for me, from my perspective because of what you gain and all the balances I think it will cost more than that. If you are going bigger, the licensing stuff can be doable, but I think that you can manage in the license in all the high volumes. From my perspective, I think it's not expensive. I think it's fair.
I was trying to manage some drops raspberry pi from a Puppet master server. I wasn't able to reach that goal because there is no urgency for raspberry pi. I think I can block it, because you can use raspberry pi to manage many automation things. Many things from an IOT. I found that a couple of years ago, and I stopped playing with that.
When you're using the console, it is user friendly. When you have to go down to the folders and the configuring or creating or writing code, you have to use your text editor and get down into the code. So, when everything is already configured and the models are deployed and tested, and you're pretty sure that everything's working fine, you can create a configuration, create your environment groups deploy the changes, go around the changes, using the console, the web console and it works pretty easily.
Puppet3 and 4 series provides optimum deployment solutions for infrastructure and applications.
This product has vastly increased our company’s release management and product stability functionalities.
We would like Puppet to add more integration for applications.
I have used this product for 7+ years.
Need to align with Agent Less Setup.
I have not encountered any issues with stability.
I have not encountered any issues with scalability.
We are highly impressed with their technical support and I would give it a 9 out of 10 rating.
I found the setup to be quite simple and easy.
Implement through vendor as special skills required.
This solution supports more of agent based work.
Before choosing this product, I evaluated a lot of options.
I would recommend to make use of outsourced software solutions such as Atgen for ensuring a stable setup process.
When your company’s growing like a bean stalk on steroids (and weight gain supplements) and you live by Lean principles and practice JIT operations, you need to figure out how to efficiently manage a rapidly growing staff, and the IT infrastructure that comes with it, using a small, capable team of tech ops engineers.
A lot of ops people are rockstars when it comes to automating their production, testing, and dev environments and customer facing infrastructure, and the Conductor team is certainly in that category. But sitting in a standup (yes, sitting, legs were tired) a few months ago, we had this update from Ryan (the engineer who runs our internal IT):
Ryan: “Yesterday I provisioned two machines for new hires. Today I have some more to do.”Me: “How many are you doing today?”
Ryan: “Two.”
Me: “What about tomorrow?”
Ryan: “Two.”
Me: “And the rest of the week?”
Ryan: “Two, two, and two.”
If you’ve ever managed or worked in a help desk, IT service bureau, or NOC, this should sound familiar. We had 10 new machines to provision that week, and one guy to do them, two per day. Quick math can tell you why this moved my hairline back a millimeter or two:
10 computers x 4 hours per computer = 40 hours of work
40 hour work week – 40 hours of work = 0 hours of time to deal with the rest of the internal service requests
0 hours spent on service requests per week = 0 satisfied, productive, fellow employees who made those requests in the first place.
This was an extreme, but if this continued, we would be saturated: not able to cover any of the other, business-critical, internal IT services we provide, and one out-of-band request away from missing our OLAs (Operational Level Agreements). Hiring wasn’t going to slow, and we had to find a way to keep up with our normal ops work and still support the high rate of growth we were seeing.
Everyone in the meeting (almost at once): Hey, why don’t we just automate it?
The answer to the capacity problem came in the form of automation, and automation came in the form of two easy to use, reliable, and proven technologies that many ops engineers use and love already: Puppet and The Foreman.
The Foreman is a complete lifecycle management tool for physical and virtual servers.1
Puppet Open Source is a flexible, customizable framework available under the Apache 2.0 license designed to help system administrators automate the many repetitive tasks they regularly perform.2
The idea was to stop looking at these purely as server management tools, and to apply the same configuration management principles to our employees computers. This gave us a number of advantages:
I recently come across a situation where there was a change in DNS IP address and new IP address need to be updated on across 4000 linux servers on the network. Rather than going to each server one by one, we just modified the puppet module and there was updated /etc/resolv.conf file on all of the servers. With the help of puppet, I could do it in just 5 mins rather than spending a lot of days doing manual work.
:)
-KM
Nice explanation and example. Puppet has really made life easy for system administrators. It is a very nice automation tool used to build multiple computers at the same time.