The KISS Blog
Welcome! For the most part our goal is to share with you some of the more interesting projects we work on, technical lessons learned, or otherwise things we find interesting related to technology. For now there is no ability to comment on posts though this may change in the future. Feel free to Contact Us directly with any questions or suggestions.
In our last post I provided an introduction to Ansible and some use cases for it. Today I will cover inventory configuration, both simple and advanced.
In Ansible, your inventory is essentially just a listing of your systems to be managed, including groupings as needed as well as variables. Ansible then uses this information to decide which systems to perform tasks on. Multiple inventory files can be defined and used independently or also together in the same run. Ansible also supports what is is called Dynamic Inventory which allows inventory to be pulled from dynamic sources, typically cloud platforms.
The following examples assume you have created the standard project layout as covered in the last post, though technically that is not required.
In this post I will show you how to configure Key-Based SSH authentication between a client and server system running Linux. While this may seem pretty simple to day to day Unix admins, I'm often surprised when I hear someone that I would think knows this says "Can you configure the keys for me?". In this example I will be configuring the user brian to connect from a system named client to a system named server. However, in the real world you can use this key to authenticate to any number of servers.
Ansible is a systems automation tool that has proven to be very powerful to our day to day work. It allows us to build more consistent environments as well as manage configurations using a much more structured approach. No more connecting to 10 web servers in a pool to make a configuration change. Make the change in the template and deploy it to all 10 of the servers using Ansible.
I intend on this being the first of what will be a series of posts covering various aspects and examples of how we use Ansible on a daily basis at KISS. In this introductory post I will cover some of the features and use cases of Ansible as well as the basic installation and configuration required to get running. All instructions are specific to CentOS 6.x, however, would be similar for all Unix based OS's that are supported.
Since the beginning of my days using a computer for something other than playing games I've been using a Unix based OS in some fashion. I'm mostly self taught, though I did have some help becoming comfortable with it at an enterprise level from State Farm right out of college managing their PeopleSoft servers on an AIX platform. Personally, I've always been a fan of the RedHat-like systems since they seem more server friendly. My desktop system of choice used to be SuSe. Then as I started focusing more on being productive than tinkering I realized Linux on the Desktop was a waste of my time with XP being a stable choice. Since that time, I've been a happy camper and focused mostly above the OS on things that matter to a business. I manage A LOT of Linux servers in some fashion, though all I need to do that with in terms of my desktop system is Putty or such.
Enter Systemd being forced down our throats. Honestly its not so much the technology, but instead that point about forcing it down our throats that really didn't sit well with me. I don't have a choice to turn it off and Linux is supposed to be about choice. Instead I must accept that the Linux boot process built on simple scripts has been deemed uncool and I must now do it their hip new way. Its like my Linux servers are being turned into Windows in many ways for reasons that to me are non issues on a server in the name of being more accessible on the desktop. I know, I know, I'm supposed to constantly want to learn new things and follow the trends. But I don't, at least not when what we currently have is not broken and doesn't need fixed. I've always wanted to try FreeBSD but never seemed to get around to it. Sadly one of the first things I learned is that it was a weekend I wish I had spent years ago.
Hello everyone! My name is Brian Carey, owner and sole proprietor of KISS IT Consulting. I wanted to take this opportunity to welcome you to our new site, by means of our new blog, as well as give you a brief history about us and what we're about.
KISS was officially founded almost two years ago now out of my desire to take what was at the time a 3 year side job full time. I've spent the majority of my career in full time positions for various companies from small to large. I did a stint at State Farm Insurance right out of college...a great place to work but too far away from family. I've worked for several start ups that were sold leaving me wanting to move on to another challenge. I spent some time with Expedient Data Centers, another great company to work for and also another role that planted the seed to do what i'm doing now. But what really started it was a call one day years ago from a previous employer of mine who needed some help. Essentially when I had left them years before, things continued to keep running smoothly and little was maintained. However they were now in need of some refreshes and such and asked if I would be interested in coming back on a 1099 basis, no pressure (since I was fully employed during business hours), to help get things up to speed from where they were left when I left years before. I was hesitant at first but agreed, and it turned out to be a great way to spend some of my free time...I enjoyed the work and got payed for it! That was about 5 years ago, and I still happily provide services to that client to this day.